Второй контур защиты: независимое резервирование MFA

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

2026

Главный результат проекта — устранена зависимость восстановления MFA исключительно от возвращения в работу основного ЦОД. Для отказа всей площадки подготовлен отдельный сценарий восстановления на ресурсах другого облачного провайдера.

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

Дополнительные параметры реализованного решения:

— 10 минут — установленный TTL DNS-записи, используемой для перевода клиентских запросов;

— один раз в сутки — создание резервных копий с дополнительным хранением на внешней площадке;

— один раз в полгода — предусмотренная периодичность проверки сценария восстановления;

— без изменения настроек MFA-агентов — перевод клиентов на резервную площадку.

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

Для многофакторной аутентификации используется MFASOFT SAS, для хранения и репликации данных — MariaDB. Прикладные компоненты подготовлены к запуску в контейнерах Docker на Rocky Linux.

Межплощадочный обмен защищён IPsec-соединением на базе strongSwan. Мониторинг осуществляется с помощью Zabbix, перенаправление клиентских запросов — через DNS.

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

В проекте не используются решения из каталога Global CIO

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

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

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

•       Исходная ситуация

Облачный MFA-сервис Nubes находился в промышленной эксплуатации. Его прикладные компоненты и база данных были зарезервированы внутри основного ЦОД, что позволяло продолжать работу при отказах отдельных серверов.

Однако отказ всей площадки оставался общим риском для компонентов сервиса. В таком случае новые подключения к защищенным корпоративным ресурсам могли оказаться недоступны до восстановления основного ЦОД. 

•       Реализованное решение

В отдельном ЦОД у независимого облачного провайдера была подготовлена резервная площадка с базой данных и компонентами MFASOFT SAS. В штатном режиме изменения основной БД непрерывно передаются на резерв через асинхронную репликацию. Прикладные контейнеры готовы к запуску, но не обслуживают пользовательские запросы.

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

Непрерывная асинхронная репликация поддерживает актуальность резервной БД и позволяет не восстанавливать ее с нуля в момент аварии. При этом потенциальная потеря последних изменений зависит от фактической задержки репликации на момент отказа: такая архитектура не предполагает гарантии нулевой потери данных. Поэтому проверка состояния резервной базы входит в процедуру переключения.

Для активации резерва разработан скрипт. После оценки масштаба инцидента ответственный администратор запускает последовательность действий: остановку репликации, проверку резервной БД, снятие режима read_only и запуск прикладных компонентов. После проверки аутентификации DNS-запись переводится на резервную площадку.

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

•       Изменения после внедрения

У эксплуатационной команды Nubes появился заранее подготовленный способ восстановить MFA независимо от сроков устранения аварии в основном ЦОД. Вместо развертывания инфраструктуры во время инцидента используются готовые резервные ресурсы, актуализируемая база данных и согласованная последовательность действий.

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

Для клиентов восстановление происходит в рамках уже настроенной интеграции с MFA.

Россия