Облако тоже может сломаться. Часть 3: как не потерять безопасность во время аварийного переезда

Представим обычное начало крупной аварии. Вместе с рабочими сервисами перестал отвечать внутренний мессенджер. Команда переходит в общую группу во внешнем приложении. Затем выясняется, что недоступно хранилище секретов, а ключи для восстановления лежат внутри него. Кто-то предлагает отправить пароль по почте. Другой — положить токен в чат, «а после переезда быстро поменять». GitLab и система сборки тоже недоступны, поэтому исправление собирают на ноутбуке разработчика. Журналы событий остались в старом облаке.

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

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

О чём эта часть

• Почему во время аварии меняется модель угроз

• Что делать, если пропал внутренний мессенджер

• Как действовать при отказе хранилища секретов

• Как сохранить доступ при отказе SSO и IAM

• Как безопасно выпускать изменения без GitLab и CI/CD

• Что делать без централизованных журналов и SIEM

• Как организовать временный административный доступ

• Какие проверки AppSec нужны перед возвращением трафика

• Как работать с временными исключениями

• Что подготовить заранее

• Кто принимает решения

1. Во время аварии меняется модель угроз

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

Появляются новые риски:

• участника внешнего чата сложнее надёжно связать с корпоративной личностью;

• уволенного сотрудника могли удалить из корпоративного каталога, но забыть во временной группе;

• секрет копируется на личное устройство и остаётся в резервной копии мессенджера;

• восстановленный IAM возвращает старые учётные записи и права;

• образ приложения собирается вне обычной цепочки поставки;

• временно открытый порт становится постоянным;

• журналы неполны, поэтому невозможно доказать, кто выполнил изменение;

• инфраструктурный сбой ошибочно считают чисто техническим, хотя причиной могла быть компрометация аккаунта.

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

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

1. Кто запросил действие и как подтверждена его личность?

2. Какой минимальный доступ ему действительно нужен?

3. Где останется след этого действия?

4. Когда временный доступ перестанет работать?

5. Что потребуется проверить или заменить после восстановления?

2. Внутренний мессенджер недоступен

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

Что может пойти не так

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

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

Как подготовить резервный канал

Организация должна выбрать внешний канал до аварии, а не во время неё. Для него нужны:

• заранее назначенные владельцы и как минимум два администратора;

• список людей, которых можно приглашать;

• второй способ подтверждения личности, например звонок по известному номеру;

• многофакторная аутентификация;

• запрет на передачу секретов и пользовательских данных;

• отдельные комнаты для координации, решений и технических событий;

• понятный срок хранения и порядок удаления временного пространства;

• возможность выгрузить итоговую хронологию в постоянную систему после аварии.

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

Сравнение способов аварийной связи

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

3. Хранилище секретов недоступно

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

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

Чего нельзя делать даже во время аварии

• отправлять пароль, токен или закрытый ключ в общую группу;

• пересылать секрет открытым текстом по почте;

• вставлять секрет в задачу, документ, командную строку со сбором истории или журнал CI/CD;

• использовать один общий пароль для всей команды;

• сохранять секрет в репозитории «на пять минут»;

• оставлять аварийный ключ действующим после завершения работ.

Удаление сообщения не гарантирует удаления уведомлений, экспортов, снимков экрана и резервных копий. Обещание «потом поменяем» тоже не является контролем, если не назначен ответственный и срок.

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

Хороший аварийный механизм обладает следующими свойствами:

• он находится вне основного хранилища и его облака;

• для использования нужны два уполномоченных человека либо иной принцип разделения полномочий;

• личность получателя подтверждается независимым способом;

• выдаётся отдельный краткоживущий секрет с минимальными правами;

• использование фиксируется в независимом журнале;

• после работ секрет автоматически истекает или немедленно заменяется;

• процедура регулярно проверяется без раскрытия боевых значений.

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

Если секрет всё же нужно передать человеку

Иногда готового резервного хранилища нет, а простой уже начался. Наименее плохой временный порядок выглядит так:

1. Создать новый секрет специально для одной операции, с минимальными правами и коротким сроком жизни.

2. Зашифровать его открытым ключом конкретного получателя.

3. Проверить отпечаток ключа через независимый канал, например голосовой звонок по заранее известному номеру.

4. Передать только зашифрованный файл, не открытый текст.

5. Зафиксировать выдачу, назначение, получателя и время истечения.

6. После операции отозвать секрет и проверить журналы его использования.

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

Сравнение временных способов передачи секрета

Любой секрет, который покинул штатный контур во время аварии, после восстановления считается потенциально раскрытым и заменяется.

4. SSO или IAM не пускает команду

Централизованный вход удобен, пока доступен поставщик удостоверений. Если от него зависят облако, GitLab, VPN, DNS и хранилище секретов, один отказ может запереть команду снаружи.

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

• учётная запись не зависит от основного SSO;

• пароль длинный, уникальный и хранится в аварийном контуре;

• второй фактор также не зависит от того же телефона, каталога или облака;

• вход создаёт заметное оповещение во внешнем канале мониторинга;

• действия записываются;

• аккаунт нельзя использовать незаметно для обычной работы;

• доступ проверяется на учениях и меняется после каждого применения.

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

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

5. GitLab и конвейер сборки недоступны

Когда основной GitLab лежит, исходный код часто остаётся в локальных клонах разработчиков. Это помогает спасти историю, но не делает ноутбук доверенной системой сборки. На нём могут быть незакоммиченные изменения, другая версия зависимостей или вредоносное расширение.

Аварийный выпуск должен отвечать на вопросы:

• из какого коммита собран артефакт;

• кто проверил изменение;

• откуда получены зависимости и базовый образ;

• совпадают ли файлы фиксации версий;

• кто подписал результат;

• где сохранены журнал сборки и контрольная сумма;

• можно ли повторить сборку после восстановления обычного конвейера.

Если резервного GitLab нет, полезен небольшой независимый репозиторий только для аварийного набора: код инфраструктуры, сценарии восстановления, манифесты зависимостей и проверенные инструменты. Он не должен содержать боевые секреты.

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

Что происходит с цепочкой поставки

6. Мониторинг и журналы тоже могут исчезнуть

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

На случай потери основной системы наблюдения нужны:

• локальная очередь журналов с ограничением размера;

• независимый внешний приёмник для ключевых событий;

• единое время на узлах;

• защита журналов от изменения и удаления;

• отдельная запись административных входов, изменений сети, выдачи секретов и переключения DNS;

• процедура последующей загрузки аварийных журналов в постоянную систему.

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

Журнал инцидента и технические журналы решают разные задачи. Первый объясняет решения людей. Вторые показывают действия систем. Для расследования нужны оба.

7. Потеряны VPN, межсетевой экран или обычный путь администрирования

Когда привычный VPN недоступен, самый быстрый соблазн — открыть SSH или административную панель всему интернету. Такой доступ сканируется почти сразу и часто переживает сам инцидент.

Лучше заранее иметь независимый административный путь:

• временный бастион, создаваемый из кода;

• ограничение по известным адресам или отдельной защищённой сети;

• ключи вместо паролей;

• многофакторную аутентификацию там, где она поддерживается;

• короткий срок жизни узла и правил;

• запись сеансов и команд;

• отдельный канал оповещения о входах.

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

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

8. AppSec проверяет не только то, что сервис открылся

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

Перед переключением пользовательского трафика нужно проверить:

• ожидаемую версию приложения и базового образа;

• порядок миграций базы и совместимость схемы;

• аутентификацию, многофакторный вход и восстановление пароля;

• авторизацию на обычных и административных маршрутах;

• завершение старых сеансов при смене ключей;

• настройки TLS, защитные заголовки, CORS и CSRF;

• проверку подписей входящих уведомлений;

• ограничения частоты запросов на вход, OTP и восстановление доступа;

• загрузку и скачивание файлов, включая проверку типа и размера;

• отсутствие отладочного режима и подробных ошибок;

• отсутствие секретов и персональных данных в журналах;

• исходящие соединения и адреса внешних интеграций;

• целостность образов и зависимостей;

• работу аудита для привилегированных операций.

Не все проверки должны блокировать восстановление одинаково. Полезно заранее разделить их на три уровня.

AppSec помогает команде не выбирать между «безопасно» и «быстро», а определить минимальный безопасный набор, без которого запуск действительно опасен.

9. Каждое временное решение должно иметь срок жизни

Во время аварии исключения неизбежны. Проблема начинается, когда о них забывают.

Для каждого исключения запишите:

• что изменено;

• почему обычный процесс невозможен;

• какой риск появился;

• кто согласовал решение;

• кто отвечает за устранение;

• точное время окончания;

• как система вернётся в штатное состояние;

• какие секреты потребуется заменить;

• какие журналы и доказательства нужно сохранить.

Удобно вести единый реестр.

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

10. План на случай аварии

Безопасный аварийный режим нельзя придумать в разгар сбоя. Минимальная подготовка выглядит так.

До инцидента

1. Утвердить независимый канал связи и правила его использования.

2. Подготовить список контактов вне корпоративного каталога.

3. Создать именованные аварийные учётные записи с независимым вторым фактором.

4. Подготовить второй контур хранения аварийных секретов или разделённые ключи восстановления.

5. Настроить резервное копирование Vault и провести восстановление на чистой площадке.

6. Сохранить вне GitLab минимальный набор кода и документации для его восстановления.

7. Определить доверенные источники образов и зависимостей.

8. Подготовить внешний приёмник для ключевых журналов и оповещений.

9. Описать обязательные AppSec-проверки перед переключением DNS.

10. Провести учение, в котором внутренний чат, SSO и Vault считаются недоступными.

В первые часы аварии

1. Подтвердить личности участников и открыть резервный канал.

2. Классифицировать инцидент как технический, связанный с безопасностью или пока неизвестный.

3. Назначить руководителя, ответственного за безопасность и секретаря журнала.

4. Запретить публикацию секретов и пользовательских данных во временном чате.

5. Зафиксировать все аварийные доступы и исключения.

6. Сохранить доступные доказательства до изменения старой среды.

7. Использовать отдельные краткоживущие реквизиты для восстановления.

8. Проверить безопасность новой площадки до пользовательского трафика.

После стабилизации

1. Отозвать аварийные аккаунты, токены, ключи и сертификаты.

2. Завершить старые сеансы пользователей и администраторов.

3. Вернуть сетевые правила к штатной конфигурации.

4. Повторно собрать аварийные артефакты обычным конвейером.

5. Загрузить журналы и восстановить полную хронологию.

6. Проверить, не остались ли секреты в чатах, письмах, терминалах и временных файлах.

7. Провести анализ причин и обновить модель угроз.

8. Исправить аварийные инструкции по фактическим затруднениям.

11. Эта тема не принадлежит одной команде

DevOps поднимает сеть и вычислительные ресурсы. Но DevOps не может единолично решить, допустимо ли перенести персональные данные в другую страну, можно ли запустить приложение без части аудита и насколько опасно временно отключить определённую проверку.

AppSec знает, какие свойства приложения нельзя потерять. ИБ отвечает за доверие к людям, ключам, образам и доказательствам. Разработчики понимают совместимость кода и данных. Владелец продукта определяет, какие функции критичны. Юристы оценивают место обработки информации и обязательства по уведомлению. Руководство принимает остаточный риск.

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

Источники

• NIST SP 800-61 Rev. 3: рекомендации по реагированию на инциденты

• OWASP: управление секретами

• OWASP: безопасное журналирование

• OWASP: безопасность CI/CD

• HashiCorp Vault: высокая доступность

• HashiCorp Vault: рекомендации по распечатыванию хранилища

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