Break-glass режим: как восстановить сервисы и не устроить вторую аварию

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

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

Старой среде нельзя доверять по умолчанию

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

Для каждого аварийного действия полезно ответить на пять вопросов:

Кто запросил действие и как подтверждена его личность?
Какой минимальный доступ ему нужен?
Где останется след?
Когда доступ перестанет работать?
Что придётся проверить или заменить после восстановления?

Резервный канал связи выбирают до аварии

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

Минимальный набор для запасного канала:

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

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

Секреты, когда Vault недоступен

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

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

Для Vault это защищённая копия снапшота Raft, доли unseal/recovery-ключей у разных хранителей и описанный порядок запуска чистого кластера. Отдельно проверьте auto-unseal: если он завязан на облачный KMS, при отказе KMS копия данных Vault без ключа шифрования секреты не вернёт.

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

Правило на потом: любой секрет, покинувший штатный контур во время аварии, считается раскрытым и подлежит ротации.

SSO и IAM

Если облако, GitLab, VPN, DNS и хранилище секретов логинятся через один identity provider, его отказ запирает команду снаружи. На критичных системах нужны именованные локальные аварийные учётки: независимые от SSO, с длинным уникальным паролем в аварийном контуре и вторым фактором, который не привязан к тому же телефону или каталогу. Каждый вход должен генерировать заметный алерт во внешнем мониторинге, а после использования пароль меняется.

Общий аккаунт admin с паролем в сейфе даёт доступ, но лишает действия авторства. Если причиной могла быть компрометация IAM, после восстановления проверьте роли, MFA-методы, ключи приложений и доверенные интеграции, завершите старые сессии и замените привилегированные реквизиты.

Сборка без GitLab и CI/CD

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

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

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

Журналы и административный доступ

На случай потери основной системы наблюдения нужны локальная очередь логов с лимитом размера, внешний приёмник для ключевых событий, синхронизированное время на узлах и отдельная запись админских входов, сетевых изменений, выдачи секретов и переключения DNS. Пароли, токены и строки подключения в логи не пишутся. Включённый на всякий случай максимальный debug с полными заголовками запросов превращает диагностику в утечку.

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

Что проверить перед возвратом трафика

Зелёный healthcheck означает, что приложение отвечает. Вместе с данными могли вернуться старые сессии, лишние администраторы и отозванный ключ подписи. Список проверок: версия приложения и базового образа, порядок миграций, аутентификация и восстановление пароля, авторизация на админских маршрутах, инвалидация сессий после смены ключей, TLS, CORS, CSRF, подписи входящих вебхуков, rate limit на логин и OTP, отключённый debug, исходящие соединения, целостность образов.

Проверки удобно заранее разложить на три уровня:

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

Реестр исключений

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

Исключение	Компенсирующая мера	Срок	После стабилизации
Бастион с публичным IP	allowlist, ключи, запись входов	6 часов	удалить VM и правило, проверить логи
Аварийный облачный токен	минимальные права, один владелец	2 часа	отозвать, проверить операции
Сборка вне CI/CD	чистое окружение, второй проверяющий	до возврата GitLab	ревью и штатная пересборка
Локальные журналы	шифрование, лимит диска	24 часа	загрузить в SIEM, удалить копию

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

Учения

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