«На случай, когда всё остальное не работает, нужно оставить простой документ с планом выхода — чтобы хотя он был.»
Не то, что думают
Когда говорят об экстренной миграции, первое, что приходит в голову — данные. Каталоги, таблицы, файлы. Это логично, но это второстепенно. Главный вопрос, который на самом деле стоит задать: что держит ваши системы вместе и позволяет им работать, кроме самих данных?
Ответ обычно сводится к трём элементам: управление доступом (IAM), сетевые правила и система управления конфигурациями. Именно эти компоненты, часто абстрактные и распределённые, становятся якорями, когда основная инфраструктура недоступна.
IAM: ключи вместо лиц
В нормальном режиме управление доступом работает через пользователей, группы, роли. Но при полной потере среды — например, когда административная консоль провайдера заблокирована или уничтожена — эта модель перестаёт существовать. На что её можно заменить?
Многие организации хранят резервные ключи API в зашифрованном виде вне облака. Это стандартная практика. Однако в ситуации атаки на провайдера эти ключи могут быть отозваны централизовано или их целевые сервисы могут быть недоступны. Тогда резервным механизмом становится не ключ, а предварительно настроенный доверенный канал. Например, отдельный сервис управления доступом, развернутый на независимой инфраструктуре (например, на собственном аппаратном кластере или у другого, меньшего провайдера), который может временно выдавать токены для критичных операций по восстановлению. Он должен знать только идентификаторы ваших ресурсов (аккаунты, проекты), но не зависеть от их исходной системы авторизации.
Что должно быть в резервном плане IAM
- Список аккаунтов или проектов с их уникальными идентификаторами (не названиями).
- Адреса или точки подключения к резервному сервису авторизации.
- Процедура получения временного токена для операций восстановления данных и конфигурации.
- Список минимально необходимых ролей (например, только права на чтение данных из бакетов и экспорт баз) с указанием их идентификаторов в новой системе.
Сеть: маршруты вместо фаерволов
Сетевые правила в облаке, это часто сложные конструкции: фаерволы, группы безопасности, таблицы маршрутизации, пиринги. При потере управления они могут либо исчезнуть, либо стать непроходимыми. Однако ваши ресурсы — виртуальные машины, базы данных — всё ещё физически где-то находятся и имеют IP-адреса. Их можно достичь, если знать точный маршрут, минуя стандартные правила.
Один из мало обсуждаемых методов — использование резервных, «скрытых» маршрутов, настроенных заранее. Например, прямое соединение между вашим локальным центром и определённым подсетью облака через отдельный, непубличный канал (например, через прямой линк другого телеком-оператора). Этот канал должен быть настроен так, чтобы не зависеть от основного облачного маршрутизатора. Его задача — только обеспечить транспортный доступ к конкретным IP-блокам ваших ресурсов. Правила безопасности тогда будут реализованы уже на стороне вашего оборудования.
Для этого в плане нужно указать не логические правила, а физические адреса и пути:
- Список критичных подсетей с их CIDR-блоками.
- Адреса конечных точек резервного сетевого канала.
- Простые инструкции по установке маршрута на вашем локальном маршрутизаторе или сервере.
- Минимальный набор портов, которые нужно открыть для восстановления (например, только 443 для API или специфичный порт для прямого копирования данных).
Конфигурация: шаблон вместо состояния
Современные облачные среды управляются через декларативные конфигурации: Terraform, CloudFormation, шаблоны Ansible. В катастрофическом сценарии эти конфигурации могут быть недоступны, так как хранятся в том же облаке или зависят от его API. Но сама логика размещения ресурсов — какие компоненты должны быть рядом, какие зависимости между ними — может быть сохранена в виде простого, независимого документа.
Этот документ не должен пытаться воспроизвести всю сложность исходной системы. Его цель — дать достаточно информации для ручного или полуавтоматического восстановления критичных цепочек. Например, он может содержать:
- Таблицу зависимостей ресурсов (например, «База данных А должна быть создана перед приложением Б, потому что приложение берёт из нее параметры подключения»).
- Минимальные характеристики каждого ресурса (тип инстанса, объём диска, версия ПО).
- Список конфигурационных файлов или переменных, которые нужно установить в первую очередь.
- Порядок операций восстановления: от сети и хранилища к приложениям.
Документ должен быть написан так, чтобы его можно было использовать без доступа к исходным инструментам управления. Часто это означает переход от декларативного описания к процедурному списку шагов.
План выхода: форма и содержание
Такой план, это не техническая спецификация. Это оперативный документ, который должен быть понятен тем, кто будет его исполнять в стрессовой ситуации. Поэтому он должен избегать сложных аббревиатур, ссылок на внутренние инструменты и предположений о доступности каких-либо систем.
Основные разделы плана:
- Констатация: краткое описание катастрофического сценария (например, «полная потеря доступа к административным интерфейсам основного облачного провайдера»).
- Цель: что мы пытаемся спасти и в каком порядке (например, сначала данные транзакций, затем систему аутентификации, потом основное приложение).
- Инструменты и доступ: список независимых инструментов и каналов, которые гарантированно остаются у нас (например, наш собственный VPN, резервный сервис управления ключами, физический доступ к аппаратному хранилищу).
- Последовательность действий: шаги в виде простых команд или инструкций, с указанием «что делать, если этот шаг не работает». Каждый шаг должен иметь альтернативный вариант.
- Критерии успеха: как понять, что мы восстановили достаточно для продолжения работы (например, «приложение отвечает на запросы по основному функционалу, данные последних 24 часов доступны»).
План должен храниться в нескольких физически разделённых местах: не только в облаке, но и на локальных серверах, в защищённых файловых хранилищах, и даже в бумажной форме в сейфе. Он должен регулярно обновляться, но его структура должна оставаться простой и устойчивой к изменениям в основной инфраструктуре.
Что не работает
Некоторые подходы, которые часто предлагаются, в реальной экстренной ситуации оказываются бесполезными:
- Полные резервные копии конфигураций в том же облаке: если провайдер недоступен, эти копии тоже недоступны.
- Сложные автоматические сценарии восстановления: они обычно зависят от множества сервисов и API, которые в момент катастрофы могут быть нарушены.
- Документация, которая ссылается только на внутренние идентификаторы или названия ресурсов: при потере среды эти идентификаторы могут потерять смысл.
- Планы, требующие участия специалистов провайдера: в момент широкой атаки поддержка может быть перегружена или недоступна.
Проверка плана
План выхода должен проверяться не в идеальных условиях, а в условиях частичной деградации. Например, можно провести упражнение, где административные консоли провайдера искусственно считаются недоступными, а доступ к ресурсам возможен только через резервные каналы. В таком упражнении часто обнаруживаются неявные зависимости, которые не были учтены.
Ключевые вопросы для проверки:
- Можем ли мы получить список наших ресурсов без использования API провайдера?
- Можем ли мы установить соединение с этими ресурсами по альтернативному пути?
- Можем ли мы извлечь данные, используя только резервные ключи или токены?
- Можем ли мы воссоздать минимальную рабочую конфигурацию на другой инфраструктуре, имея только наш документ?
Если хотя бы на один из этих вопросов нет уверенного ответа, план нужно корректировать.
Итог: простота как запас прочности
Экстренная миграция, это не попытка спасти всё. Это попытка спасти самое необходимое, используя максимально простые и независимые средства. Главная цель такого плана — не восстановить инфраструктуру в полном объёме, а обеспечить непрерывность ключевых бизнес-процессов до того момента, когда можно будет провести полноценное восстановление или переход на другую платформу.
Поэтому лучший план выхода, это не самый технологически продвинутый, а самый понятный и прямой. Он должен быть таким, чтобы его могли выполнить люди, которые возможно не являются основными архитекторами системы, но знают её ключевые точки. Он должен использовать не самые умные инструменты, а самые доступные и надёжные в условиях неопределённости.
И он должен существовать в форме, которая не зависит от того, что атаковано или потеряно. Именно это даёт реальную возможность выйти из ситуации, когда ваш облачный провайдер под атакой.