Журналисту нельзя светить источники: где хранить расшифровки интервью

MAATRIX

У вас на диске лежат часы разговоров с людьми, которые рискуют больше, чем вы. Источник согласился говорить откровенно, потому что вы пообещали: его слова не всплывут вместе с именем, должностью и городом. После интервью расшифровка едет в Google Docs с автосинхронизацией, в Dropbox «для бэкапа», в облачный сервис распознавания речи — и в этот момент ваше обещание перестаёт зависеть только от вас. Дальше решает политика хранения чужой компании, её сотрудники, её договор с третьими лицами и её готовность ответить на запрос, о котором вы можете и не узнать. Разберём, что именно вы отдаёте, когда расшифровка уходит в стороннее облако, и как устроить хранение и обработку на собственном сервере — так, чтобы решение о доступе к материалам принимали вы, а не безымянный support где-то в другой стране.

Что на самом деле происходит, когда файл уходит в облако

Когда вы загружаете аудио в облачный сервис распознавания речи или храните готовую расшифровку в общем диске, вы не просто «сохраняете файл». Вы передаёте копию данных в инфраструктуру, которую не контролируете, и подписываетесь под условиями, которые почти никто не читает целиком.

Что это значит на практике:

• У сервиса есть техническая возможность прочитать содержимое. Даже если политика обещает не заглядывать в файлы без причины, у сотрудников поддержки, у систем модерации и у самой платформы формы доступа к вашим данным остаются — это следует из самой архитектуры облачного сервиса, а не из злого умысла.
• Утечка у провайдера — это утечка и у вас. Если у сервиса случится взлом или неправильно настроенное хранилище (а такое происходит с сервисами любого масштаба), расшифровка интервью окажется в общей массе чужих утёкших данных — без разбора, кто из клиентов «важный», а кто нет.
• Запрос к сервису — это запрос в обход вас. Юридический запрос на раскрытие данных может прийти не к вам, а напрямую к площадке, где лежит файл. Вы как автор материала можете узнать об этом постфактум или не узнать вовсе — это зависит от политики конкретного сервиса и юрисдикции, в которой он работает.
• «Удалить» не всегда значит удалить. Кнопка удаления в интерфейсе облака убирает файл из вашего поля зрения, но не гарантирует немедленного и полного удаления из бэкапов и резервных копий провайдера — сроки и правила у каждого сервиса свои и обычно прописаны мелким шрифтом.
• Утилиты распознавания речи — отдельный риск. Отправляя аудио в облачный STT-сервис, вы отдаёте не только текст, но и голос источника, а обработка на сервере третьей стороны означает ещё одну копию данных вне вашего контроля — независимо от того, использует ли сервис эти данные для обучения моделей (это стоит уточнять в конкретном сервисе отдельно, единого правила тут нет).

Ни один из этих пунктов не означает, что облачные сервисы «плохие» сами по себе — для большинства задач они вполне разумный выбор. Но расшифровка интервью с уязвимым источником — не та задача, где стоит добавлять лишнее звено между источником и вами.

Что меняется, когда сервер свой

Собственный сервер не делает вас неуязвимым — и честно говоря, ни один инструмент этого не сделает. Но он убирает из цепочки целую категорию риска: постороннюю компанию с её персоналом, её политиками хранения и её обязательствами перед третьими лицами.

На своём сервере:

• Ключи доступа — только у вас (и у тех, кому вы сами их выдали). Нет отдела поддержки с техническим доступом «на всякий случай».
• Удаление — это действительно удаление. rm на вашем диске — не кнопка в чужом интерфейсе с неясными сроками хранения бэкапов.
• Вы видите, кто и когда заходил. Логи подключений — ваши, а не скрытая телеметрия чужого сервиса.
• Вы решаете, что вообще уезжает за пределы сервера. Расшифровка может вообще не покидать вашу инфраструктуру — ни для распознавания речи, ни для хранения.

Важная оговорка: сервер, оставленный с паролем «admin123» и открытым доступом отовсюду, не защищает вообще ничем — хуже того, создаёт ложное чувство безопасности. Ниже — минимальный, но осмысленный набор мер, а не разговор в общих словах.

Минимальный контур: сервер, доступ, шифрование

Начинать стоит не с расшифровки интервью, а с базовой гигиены самого сервера — иначе всё остальное не имеет смысла.

1. Выбор и расположение сервера. Для материалов, где важна защита источника, есть смысл сознательно выбирать юрисдикцию хостинга — например, сервер за пределами страны, где ведётся расследование, физически не может быть изъят по одному звонку местных структур. Это не панацея и не юридическая гарантия — сервер всё равно можно запросить через международные процедуры или напрямую у вас как у владельца данных, — но это дополнительный барьер по времени и по процедуре, а не пустой жест.

2. Доступ только по SSH-ключу, без пароля.

ssh-keygen -t ed25519 -C "editor-laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

На сервере в /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no

systemctl restart sshd

3. Файрвол — только нужные порты.

ufw default deny incoming
ufw allow OpenSSH
ufw enable

4. Защита от перебора.

apt install fail2ban
systemctl enable --now fail2ban

5. Шифрование диска или отдельного раздела под материалы. Смысл в том, что если физический носитель (диск сервера, снятый образ, флешка с бэкапом) окажется не у вас, содержимое без ключа останется нечитаемым набором байт.

cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 archive
mkfs.ext4 /dev/mapper/archive
mount /dev/mapper/archive /mnt/archive

Раздел монтируется вручную после перезагрузки — сознательно, чтобы сервер не расшифровывал архив автоматически при каждом старте без вашего участия.

Про сам ssh-доступ и практические грабли настройки ключей подробнее в статье про SSH-ключи вместо пароля.

Расшифровка аудио без стороннего сервиса

Отдельная привычка, от которой стоит отказаться, — загружать аудиозапись интервью в облачный сервис распознавания речи «просто чтобы получить черновой текст». Даже черновик — это уже голос источника и содержание разговора, переданные третьей стороне.

Альтернатива — открытая модель Whisper, запущенная прямо на вашем сервере. Аудио не покидает вашу инфраструктуру вообще: файл приходит на сервер, обрабатывается локально, текст остаётся там же.

Минимальная установка (пример для faster-whisper на CPU):

apt install python3-pip ffmpeg
pip install faster-whisper

Скрипт расшифровки:

from faster_whisper import WhisperModel

model = WhisperModel("medium", device="cpu", compute_type="int8")
segments, info = model.transcribe("interview_2026-08-19.mp3", language="ru")

with open("interview_2026-08-19.txt", "w") as f:
    for s in segments:
        f.write(f"[{s.start:.1f}-{s.end:.1f}] {s.text.strip()}\n")

Честно про качество: результат зависит от размера модели, качества записи и посторонних шумов — на чистом студийном звуке крупная модель даёт вполне читаемый черновик, на полевой записи с уличным шумом придётся вычитывать и править руками в любом случае, локально или в облаке. Это не повод отказываться от локальной обработки — это повод не относиться к автоматической расшифровке как к финальному тексту без вычитки, независимо от того, где она сделана.

Если вы регулярно расшифровываете длинные записи и хотите разобрать тему подробнее — отдельно про настройку Whisper на своём сервере есть статья про расшифровку звонков через Whisper — логика для интервью та же.

Как хранить и структурировать расшифровки

Готовый текст — не менее чувствительная вещь, чем аудио, а иногда и более удобная для случайной утечки, потому что его проще скопировать, переслать по ошибке не в тот чат или оставить открытым в редакторе на общем ноутбуке.

Кодовые имена вместо настоящих. В именах файлов, папках и внутри самого текста расшифровки используйте псевдоним источника, а не имя. Отдельно, в другом месте и с отдельным шифрованием, храните сопоставление «псевдоним → реальный человек» — так, чтобы доступ к самому массиву расшифровок не давал автоматически возможность деанонимизировать всех, кто в нём упомянут.

Структура по темам, а не по людям. Папка на материал/расследование внутри неё — расшифровки по датам и псевдонимам источников. Это упрощает и работу, и последующую чистку — когда материал вышел и часть записей больше не нужна держать «горячими».

Точечное шифрование для архивных записей. Диск уже зашифрован на уровне раздела (см. выше), но для материалов, которые не нужны в ежедневной работе, есть смысл добавить ещё один слой — персональный ключ на конкретный файл или папку:

gpg --symmetric --cipher-algo AES256 interview_2026-08-19.txt

Так файл остаётся зашифрованным даже при смонтированном разделе — расшифровать его может только тот, у кого есть кодовая фраза именно от этого файла, а не от всего архива разом.

Бэкап — тоже зашифрованный и в другом месте. Резервная копия без шифрования на другом сервере — это просто второе место, откуда можно украсть те же данные. Инструменты вроде restic шифруют репозиторий по умолчанию:

restic init --repo sftp:backup-user@backup-host:/archive
restic backup /mnt/archive --repo sftp:backup-user@backup-host:/archive

Пароль от репозитория бэкапа стоит держать отдельно от самого бэкапа — иначе шифрование не защищает ни от чего, если оба элемента попадут в одни руки. Подробный разбор настройки такого бэкапа — в статье про бэкап с шифрованием на VPS, а что именно даёт и чего не даёт шифрование диска само по себе — в материале про то, что защищает шифрование дисков.

Доступ, аудит и что делать в нештатной ситуации

Ограничьте круг людей с доступом. Если к архиву нужен доступ редактору или коллеге по расследованию — заведите ему отдельный SSH-ключ и отдельную учётную запись, а не общий пароль «на редакцию». Отдельный ключ означает, что при уходе человека из проекта вы просто удаляете один ключ, не трогая доступ остальных.

Смотрите, кто и когда заходил. Даже без сложных систем аудита у вас уже есть журнал подключений по SSH — journalctl -u ssh или /var/log/auth.log. Периодически проверяйте его на подключения, которые вы не ожидали.

Держите план на случай форс-мажора. Ноутбук с рабочей сессией может потеряться или быть изъят, сервер может стать недоступен, доступ может понадобиться срочно отозвать. У вас должно быть заранее понятно: как быстро сменить ключи доступа, как убедиться, что зашифрованный архив остаётся нечитаемым без парольной фразы, и с кем в редакции согласовывать действия в такой ситуации до того, как она случится, а не во время неё.

Это не замена юридической защиты источника, а её техническая часть. Правила и механизмы защиты источников — предмет профессиональной этики, редакционной политики и законодательства, которое сильно различается по странам и обстоятельствам конкретного материала. Технический контур, описанный здесь, снижает риск утечки через третью сторону, но не отменяет необходимости консультации с юристом редакции по конкретному случаю — особенно если материал резонансный или источник в реальной опасности.

Частые вопросы