Красная папка: что должно быть под рукой, если админ недоступен

MAATRIX

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

Что такое красная папка и зачем она нужна

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

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

• Админ временно недоступен (болезнь, форс-мажор, нет связи неделю-две) — систему просто нужно не уронить: продлить домен, отбить DDoS, перезапустить упавший сервис, ответить хостеру на abuse-жалобу.
• Админ не вернётся (увольнение, конфликт, худший случай) — нужен полный перехват контроля: смена всех паролей, отзыв SSH-ключей, аудит того, что вообще происходит на сервере.

Красная папка закрывает оба сценария, но акцент этой статьи — на первом: у вас есть доверенный человек, ситуация не враждебная, просто нужно быстро дать ему то, что нужно для action. Если ситуация конфликтная и с админом нет контакта вовсе, это уже отдельная задача восстановления доступа — про неё подробно в статье «Админ ушёл со всеми паролями: план возврата контроля».

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

Какие доступы должны быть под рукой

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

• SSH/root-доступ к каждому серверу — IP-адрес, порт (если нестандартный), логин, метод входа (пароль или приватный ключ) и, если ключ, — сам файл ключа и его passphrase отдельно.
• Панель хостинга/облака — логин, пароль, метод входа во 2FA (см. отдельно ниже — это отдельная головная боль).
• Регистратор домена и DNS — доступ туда важнее, чем к самому серверу: если домен не продлить или запись DNS сломается, сервер может быть жив, а сервис — недоступен для всех.
• Панель управления БД (phpMyAdmin, pgAdmin, консоль облачной СУБД) или хотя бы пароль root/postgres пользователя.
• Git-репозиторий (GitHub/GitLab/self-hosted) — логин с правами deploy, токен доступа, адрес репозитория.
• CI/CD и деплой-скрипты — где лежат, как запустить деплой вручную, если пайплайн упал.
• VPN/бастион, если прямого доступа к серверам нет — конфиг клиента, ключи.
• Email-аккаунт, на который зарегистрирован домен и хостинг — часто это забывают, а именно туда приходит письмо о истечении оплаты или подозрительной активности.
• Платёжный метод, привязанный к хостингу и домену — какая карта, кто плательщик, где посмотреть баланс, чтобы сервис не отключили за неуплату в самый неподходящий момент.

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

1. При настройке 2FA сохранить backup-коды восстановления
   (их обычно 8-10 одноразовых кодов) в красную папку отдельно
   от основного пароля.
2. Там, где сервис это поддерживает, добавить второй метод 2FA
   на доверенное устройство (например, TOTP в приложении на
   телефоне доверенного лица) или email-резерв.
3. Проверить раз в полгода, что коды ещё валидны — часть
   сервисов инвалидирует их при смене пароля.

Держите доступы структурированными, а не единой простынёй текста — это сильно ускоряет работу в стрессе:

credentials.md
├── 01-hosting-panel.md     — панель хостинга, 2FA-коды
├── 02-ssh-servers.md       — список серверов, ключи, порты
├── 03-domain-dns.md        — регистратор, DNS-зона
├── 04-database.md          — доступы к БД, дампы бэкапов
├── 05-git-cicd.md          — репозиторий, деплой
├── 06-email-payment.md     — почта домена, платёжный метод
└── 07-vpn-bastion/         — конфиги VPN-клиента

Контакты провайдеров: хостер, регистратор, DNS, банк

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

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

Более подробный разбор, как собрать именно контакты (а не доступы) на случай аварии сервера, — в статье «Список контактов на случай аварии сервера»: она хорошо дополняет красную папку блоком, специфичным именно для общения с провайдерами.

Базовая документация: как это всё устроено

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

• Список серверов с их ролью (веб, БД, почта, бэкап) и IP.
• Какие сервисы на каком сервере запущены — nginx/Apache, СУБД, очереди, кэш.
• Как выглядит нормальная работа — что проверить в первую очередь, чтобы понять, всё ли сломано или просто один сервис.
• Где лежат бэкапы и как их восстановить — конкретная команда, не абзац прозы.
• Порядок запуска/остановки сервисов, если это не просто systemctl start, а последовательность (сначала БД, потом кэш, потом приложение).

Пример минимальной карточки сервера, которая экономит часы в критический момент:

Сервер: web-01 (продакшн)
IP: 203.0.113.10, SSH порт 22322
Роль: nginx + PHP-FPM + приложение
Зависит от: db-01 (PostgreSQL), redis-01 (кэш/сессии)
Бэкапы: BorgBackup, ежедневно в 03:00, хранится на backup-01
  Восстановление: borg extract /mnt/backup::web-01-2026-08-30
Мониторинг: Uptime Kuma на monitor.example.com
Если не открывается: 1) проверить nginx -t, 2) проверить
  systemctl status php-fpm, 3) проверить место на диске df -h

Такая документация полезна не только на случай ЧП — она вообще снижает bus factor команды. Если у вас её пока нет, отдельная статья «Документация сервера: что нужно вести» даёт более широкий список того, что стоит фиксировать постоянно, а не только для красной папки.

Кого звать, если своих сил не хватает

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

• Контакт запасного администратора или подрядчика — не обязательно нанимать кого-то заранее на ставку, но полезно иметь на примете фрилансера или небольшую DevOps-компанию, с которой хотя бы раз был контакт, чтобы не искать исполнителя с нуля в момент аварии.
• Явный порог эскалации — сформулируйте прямо: «если через 2 часа сайт не поднялся — звонить [контакт], не пытаться чинить самостоятельно». Это снимает с доверенного лица давление решать, когда сдаваться.
• Бюджет на экстренную помощь — если платить будет тот же доверенный человек с личной карты, стоит заранее оговорить сумму, на которую можно соглашаться без согласования (например, «до 10 000 рублей на разовую консультацию — окей без звонка мне»).
• Что НЕ трогать без крайней необходимости — явно укажите зоны риска: не удалять базы, не менять DNS без второй проверки, не выполнять rm -rf даже по инструкции из интернета без понимания, что она делает.

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

Как хранить красную папку — безопасно, но доступно в критический момент

Это главное противоречие всей концепции: информация должна быть достаточно защищена, чтобы не утекла при обычной работе, и достаточно доступна, чтобы её реально можно было использовать в 3 часа ночи без звонка недоступному админу. Универсального решения нет, но есть рабочие варианты, которые можно комбинировать:

На практике для большинства небольших команд рабочая комбинация такая:

1. Основной способ — общий сейф в менеджере паролей
   (Vaultwarden на своём сервере или Bitwarden), доступный
   и админу, и доверенному лицу постоянно, с 2FA у обоих.
2. Резервный способ — зашифрованный файл-дубликат:

   gpg --symmetric --cipher-algo AES256 red-folder.md

   Файл лежит в облаке (например, в личном Dropbox доверенного
   лица), пароль от расшифровки передан отдельно — на бумаге
   в закрытом конверте, или устно один раз при личной встрече.
3. Раз в квартал — сверка: актуальны ли пароли, не поменялся
   ли IP сервера, не истекли ли 2FA-коды восстановления.

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

Отдельно про то, кто должен иметь доступ к самой папке. Правило простое — минимум людей, но не один человек:

• Не только админ — если доступ к красной папке есть только у него самого, весь смысл теряется.
• Не весь коллектив — чем больше людей видят root-пароли, тем выше риск утечки без всякой аварии. Один-два доверенных лица достаточно для малого бизнеса.
• Владелец бизнеса или руководитель — даже если он не технический специалист, у него должен быть доступ хотя бы к списку «кому звонить», если и доверенное лицо, и админ одновременно недоступны.
• Пересматривайте список раз в год — доверенные лица меняются вместе с командой; папка, к которой имеет доступ бывший сотрудник, — это не резерв, а уязвимость.

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