Данные пережили компанию, но не пережили пароль от архива

MAATRIX

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

Чёрный ход, которого нет

Разница между «забыл пароль от почты» и «забыл passphrase от зашифрованного архива» кажется несущественной, пока не понадобится её на себе прочувствовать. У почтового сервиса есть процедура восстановления: подтверждение по телефону, резервный email, служба поддержки, которая после проверки личности выдаст новый доступ. У AES-256 внутри 7-Zip, GPG или VeraCrypt такой процедуры нет в принципе — не потому что разработчики поленились её сделать, а потому что при правильной реализации сильного симметричного шифрования её невозможно сделать так, чтобы шифрование при этом осталось стойким.

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

Отсюда практический вывод: если пароль от зашифрованного .7z, .zip с AES-256, GPG-контейнера или VeraCrypt-тома забыт и нигде больше не сохранён — техподдержка производителя архиватора, хостинг, на котором лежит файл, и любой сторонний специалист ничем не помогут. Не потому что не умеют, а потому что решить эту задачу математически нельзя. Единственный рабочий путь — предотвратить ситуацию заранее, а не искать выход из неё постфактум.

Как этот риск копится на длинном горизонте

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

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

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

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

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

Где физически теряются пароли от архивов

Если разобрать типичные случаи потери, они укладываются в несколько повторяющихся сценариев.

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

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

Пароль в личном менеджере паролей уволившегося сотрудника. Более дисциплинированный вариант — человек честно сохранил пароль в личный Bitwarden или 1Password, а не в голове. Проблема та же: доступ к хранилищу принадлежит человеку, а не компании, и после увольнения организация туда заглянуть не может, даже зная, что пароль там есть.

Пароль записан, но не там, где ищут архив. Иногда пароль честно записан — в файле на рабочем столе, в облачной заметке, в Excel-таблице «пароли (не публиковать)». Проблема не в отсутствии записи, а в отсутствии связи между архивом и указанием, где искать пароль к нему конкретно. Через три года никто не помнит, что «пароли.xlsx» вообще существует, а тем более — что строка 47 в нём относится именно к этому файлу.

Во всех четырёх случаях причина одна: пароль от долгосрочного архива хранился как временный секрет одного человека, а не как актив организации с понятным жизненным циклом.

Менеджер паролей организации, а не личная память

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

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

С Vaultwarden запись пароля от архива в командное хранилище через CLI выглядит так:

bw login --apikey
bw sync
bw create item '{
  "type": 2,
  "name": "Архив: buhgalteria-2023-export.7z",
  "notes": "Пароль от зашифрованного архива с первичкой за 2023 год. Расположение файла: backup-server:/archives/2023/. Ответственный за проверку: см. реестр архивов.",
  "login": null,
  "secureNote": {"type": 0}
}' --organizationid <org-id>

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

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

Если организация уже использует HashiCorp Vault для секретов приложений, пароль от архива можно хранить там же как обычный key-value секрет с TTL, который не истекает:

vault kv put secret/archives/buhgalteria-2023 \
  password="<пароль>" \
  location="backup-server:/archives/2023/buhgalteria-2023-export.7z" \
  created="2026-08-15" \
  owner="finance-team"

Подробнее про развёртывание и модель доступа такого хранилища — в статье про управление секретами через HashiCorp Vault.

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

Реестр зашифрованных архивов: что и где документировать

Организационное хранилище паролей решает половину задачи. Вторая половина — знать вообще, что архивы существуют, что они зашифрованы и каким инструментом. Без этого через несколько лет находят файл export_final_v2.7z.enc на полке холодного хранения и не могут ответить даже на вопрос, стоит ли вообще пытаться его открывать и кому там писать за паролем.

Минимальный реестр — это таблица (в вики компании, в общей гугл-таблице или в том же организационном хранилище паролей как заметка), где на каждый зашифрованный архив заведена строка:

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

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

Проверка, что архив реально открывается

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

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

Практика простая: раз в квартал или раз в полгода (для архивов с длительным сроком хранения — реже, но не реже раза в год) кто-то из ответственных берёт пароль из организационного хранилища и на тестовом окружении реально распаковывает архив.

Для 7-Zip с AES-256:

7z t -p archive.7z
# Everything is Ok — пароль подошёл, целостность подтверждена

Флаг t (test) не распаковывает файлы на диск, но полностью проверяет и пароль, и целостность содержимого — быстрый способ для регулярной проверки без лишнего расхода места.

Для GPG-контейнера:

gpg --decrypt --output /dev/null archive.tar.gz.gpg

Вывод в /dev/null избавляет от необходимости хранить где-то временную распакованную копию — достаточно убедиться, что команда завершилась без ошибки ввода пароля.

Для VeraCrypt-тома проверка чуть более явная — том нужно смонтировать и убедиться, что файловая система читается:

veracrypt --text --mount archive.hc /mnt/verify --password="<пароль из хранилища>"
ls /mnt/verify
veracrypt --text --dismount /mnt/verify

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

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

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