Связаться с редакцией
Раньше архитектуру аварийного восстановления (DR) проектировали преимущественно на случай отказа оборудования, а также для возобновления работы после происшествий на площадке и стихийных бедствий. Сегодня главной угрозой для компаний стали кибератаки. И все чаще Минотавр устремляется в сердце цифрового лабиринта — в систему управления резервным копированием, чтобы уничтожить саму возможность восстановления. В новых условиях непрерывность бизнеса требует комплексного подхода, в рамках которого доверие к резервным копиям не менее важно, чем их сохранность, что позволяет запускать сервисы в максимально короткий срок после инцидента. Именно для решения этой задачи мы сконструировали «Бункер» и «Цитадель». Они дополняют традиционные меры защиты, которых теперь уже недостаточно.
Классическая стратегия DR, опирающаяся на правило резервного копирования «3-2-1» (три копии, два типа носителей, одна копия вне основной площадки), а также наличие основного и резервного ЦОД с настроенной репликацией перестали быть универсальной защитой бизнеса. Современные кибератаки нацелены на остановку работы компаний: используя программы-шифровальщики и вайперы, преступники в первую очередь пытаются проникнуть в систему резервного копирования, чтобы заразить или уничтожить все резервные копии данных и лишить бизнес возможности их использовать для восстановления после того, как будут стерты все основные данные. По результатам расследований Jet CSIRT (центра кибербезопасности компании «Инфосистемы Джет») с 2025 года, в 96% инцидентов целенаправленная атака на бэкапы проводилась заранее — до перехода к активной фазе.
При таком сценарии резервный ЦОД, имеющий постоянную сетевую связность с основной инфраструктурой, сам становится частью зоны поражения. Если злоумышленник получает административные права в домене, под угрозой оказываются обе площадки. Восстанавливать приходится уже не только данные или сервисы, но и доверие к самой инфраструктуре. Именно этот опыт, через который проходят многие компании, сподвиг нас пересмотреть классические способы защиты резервных копий и СРК.
Разумеется, в нашем новом подходе по-прежнему важны заранее подготовленные планы возвращения к работе ИТ-систем (DRP) и бизнес-процессов (BCP). Кроме того, существенную роль играет и харденинг — базовая мера по повышению устойчивости ИТ-инфраструктуры. Однако даже хорошо защищенная среда не исключает успешной атаки, поэтому мы добавили в концепцию «Непрерывность 2.0» создание изолированных контуров для хранения данных и восстановления систем — «Бункер» и «Цитадель».
«Бункер»: доверенная среда для восстановления
Вот первые вопросы, на которые необходимо получить ответ после кибератаки: получил ли злоумышленник административный доступ и сохранились ли резервные копии, которым можно доверять? Если доступ получен, обычная система резервного копирования оказывается такой же скомпрометированной, как и продуктивная среда.
Чтобы обеспечить гарантированное восстановление, мы спроектировали «Бункер» — киберустойчивую систему резервного копирования (СРК). Физически она может располагаться как на удаленной площадке, так и в любом из ЦОД, потому что принципиальное значение имеет не место ее размещения, а независимость и логическая изоляция от продуктивной инфраструктуры.
Главная задача «Бункера» — хранить доверенные резервные копии, пригодность которых подтверждена заранее, и быть средой для тестового восстановления. Его основное отличие от традиционной СРК — не в используемом оборудовании, а в архитектуре. Это полностью автономный контур с собственными серверами управления системой резервного копирования, базой каталогов, медиаагентами, SAN и инфраструктурными сервисами, такими как:
- Active Directory (AD) — служба каталогов, управляющая учетными записями и правами доступа;
- Domain Name System (DNS)— система, преобразующая имена серверов в IP-адреса;
- Dynamic Host Configuration Protocol (DHCP)— протокол для автоматической выдачи сетевым устройствам IP-адресов и настроек.
«Бункер» оснащен средствами защиты информации разных классов: антивирусной защитой, межсетевыми экранами, песочницами (sandbox), EDR, — а также имеет изолированное управление (терминальный доступ, второй фактор, специальные учетные записи).
Отдельные административные учетные записи, предназначенные для управления «Бункером», никак не связаны с продуктивным доменом. Это исключает ситуацию, когда компрометация основной инфраструктуры автоматически означает компрометацию резервной площадки. На архитектурной схеме «Бункера» хорошо видно, что контур резервного копирования отделен от продуктивной среды не только логически, но и административно.
По другому принципу организована и передача данных между продуктивной средой и «Бункером». Мы используем асинхронную репликацию по Fiber Channel, поскольку она значительно устойчивее к сетевым атакам. После завершения резервного копирования резервные копии на уровне блочных устройств реплицируются в изолированный контур, а затем соединение между площадками разрывается — программно или физически. Постоянной сетевой связности между средами нет. После передачи в «Бункер» резервные копии восстанавливают (это актуализирует DRP и повышает компетенцию команды) и проверяют на полноту, актуальность и консистентность — вплоть до запуска отдельных экземпляров приложений.
До завершения расследования кибератаки нельзя возвращать системы к работе. Однако «Бункер» позволяет начать восстановление немедленно, поскольку у компании остается независимый источник доверенных данных. Благодаря этому целевое время восстановления (Recovery Time Objective, RTO) сокращается.
Этот процесс включает:
- «зачистку» прода и развертывание ключевой инфраструктуры (виртуализация, AD, перенастройка СХД);
- восстановление данных критичных ИС из последней доверенной копии (All-Flash + SAN дают максимальную скорость);
- проверку и запуск систем.
Как упоминалось выше, «Бункер» не только служит хранилищем данных, но и используется для тестового восстановления критичных информационных систем. В изолированном контуре запускаются виртуальные машины, проверяется целостность баз данных, отрабатываются процедуры DRP. На схеме этот этап выделен как отдельный процесс: только после проверки резервные копии становятся доверенными и могут использоваться при аварийном восстановлении. Таким образом, можно заранее убедиться в их пригодности, и ИТ-команда уже будет знать, что именно восстанавливать, и не станет во время атаки тратить время на проверку работоспособности копий.
«Цитадель»: ЦОД последней надежды
Хотя «Бункер» решает проблему сохранности данных, возвращение сервисов к работе занимает время: нужно развернуть инфраструктуру, восстановить системы и проверить их работоспособность. А что делать, если бизнесу важно возобновить работу критичных информационных систем за считанные часы? В некоторых отраслях даже пара часов простоя означает серьезные финансовые потери. И вот здесь не обойтись без «Цитадели» — доверенного ЦОД последней надежды.
По сути, «Цитадель» — это отдельный изолированный контур, который, в отличие от резервного ЦОД, проектируется как безопасная среда, готовая принять нагрузку после серьезной чрезвычайной ситуации, в том числе киберинцидента, в результате которого основная инфраструктура заказчика стала недоступна или была скомпрометирована.
Основной актив «Цитадели» — уже запущенные и подготовленные к запуску экземпляры информационных систем. Благодаря этому для переключения не приходится заново разворачивать всю инфраструктуру: значительная часть сервисов уже готова к работе.
Контур «Цитадели» не имеет открытого доступа в интернет и проектируется таким образом, что для злоумышленников он невидим. Доверенный ЦОД можно построить хоть за Уралом: для него неактуально минимальное время задержки, поскольку архитектура предполагает несинхронную репликацию данных. В связи с этим часть из них может быть утрачена, но такой вариант все же лучше, чем потерять все данные.
Архитектура «Цитадели» строится в соответствии с несколькими ключевыми принципами.
Первый — полная изоляция и самостоятельность. Как и «Бункер», «Цитадель» не является продолжением продуктивной инфраструктуры. Это максимально изолированная от внешнего мира инфраструктура. Она имеет собственные служебные сервисы, сервисы мониторинга, резервного копирования, управления доступом, виртуальные рабочие места для администраторов и пользователей, а также службу каталога. То есть это отдельная экосистема, способная функционировать независимо от основной площадки, что мы и видим на схеме: практически все инфраструктурные сервисы продублированы внутри защищенного контура. В идеале для обслуживания контура нужно иметь выделенную команду, а доступ обеспечивать не через интернет или корпоративную сеть (КСПД), а с отдельных АРМ из офисов заказчика по отдельным сетевым линкам.
Второй — карантинная зона и доставка данных. Как и в «Бункере», здесь используется блочная асинхронная репликация на уровне СХД по Fiber Channel или iSCSI. При этом, если необходим iSCSI, предполагается подключать дисковые массивы напрямую порт в порт — чтобы исключить передачу данных через общую корпоративную сеть. Информация передается в формате файлов — никакой классической репликации по сети на уровне прикладных систем. Каждую ИС и бизнес-процесс предварительно обследуют, изучая весь жизненный цикл данных (Data Life Cycle) и проверяя всю последовательность этапов их обработки — от генерации до удаления или архивирования (тип данных, места их расположения и пр.). Необходимо четко понимать, какие данные и как часто необходимо переносить в «Цитадель» для обеспечения нужного уровня RPO. Мы исходим из того, что поступающие извне данные по умолчанию нельзя считать безопасными, поэтому все файлы ИС, журналы транзакций, WAL-файлы СУБД (журналы предзаписи) и другая информация проходят многоступенчатую проверку до попадания в изолированный контур. В архитектуре для этого предусмотрена отдельная карантинная зона с антивирусной проверкой, песочницами, Honeypots (серверы-ловушки) и другими средствами анализа. Только после прохождения всех проверок данные могут использоваться внутри «Цитадели».
Третий — работающие критичные ИС. В «Цитадели» развернуты и функционируют экземпляры наиболее критичных информационных систем. Часть из них могут находиться в состоянии максимальной готовности к запуску. Во время полного отключения основной инфраструктуры и проведения там расследования инцидента, в «Цитадели» полным ходом выполняется детальный план по переключению (DRP) и идет подготовка к переключению продуктивной нагрузки (включение ИС, корректировка настроек сети и информационной безопасности, сбрасывание паролей и т. д.). И как только коллеги из ИБ дают разрешение, мы уже готовы подключать пользователей.
Четвертый — своя система информационной безопасности. В «Цитадели» развернут собственный набор защитных средств. Минимально это:
- Next Generation Firewall (NGFW) — умный фильтр трафика, который блокирует атаки на уровне приложений;
- Web Application Firewall (WAF) — межсетевой экран для веб-приложений, который пропускает только легитимный пользовательский трафик;
- Security Information and Event Management (SIEM)— анализатор логов и событий, который бьет тревогу при аномалиях;
- Endpoint Detection and Response (EDR) — антивирус, который отслеживает подозрительные процессы и позволяет изолировать зараженную машину от сети;
- средства контроля привилегированного доступа, мониторинга и реагирования.
Благодаря тому, что при штатной работе системы у нас нет продуктивной нагрузки, можно повысить уровень обеспечения ИТ: включить проактивный контроль трафика (NTA), выполнить расширенный сбор и анализ событий, оценить активность, применить несколько разных антивирусных решений, ввести контроль целостности и задать максимально жесткие параметры харденинга и настроек ИБ.
Часть механизмов защиты постоянно работают внутри контура, часть — активируются непосредственно перед переключением пользователей на «Цитадель». Благодаря этому после запуска сервисов инфраструктура находится под контролем собственной системы безопасности и не зависит от состояния основной площадки.
На схеме «Цитадели» представлены несколько подсистем. Есть компоненты, обеспечивающие работу критичных информационных систем: доверенные резервные копии, служебные сервисы, контур восстановления, системы удаленного доступа пользователей и администраторов. Отдельно — работающие и готовые к запуску приложения. Кроме того — имеются собственные средства защиты и управления (системы контроля доступа, мониторинга, анализа угроз, управления конфигурациями и уязвимостями). Между внешней основной инфраструктурой и «Цитаделью» располагается карантинная зона, через которую проходят все поступающие данные. Такой подход позволяет одновременно обеспечить высокий уровень защищенности и сохранить готовность сервисов к запуску.
Таким образом, «Цитадель» позволяет существенно сократить время восстановления. Если при использовании «Бункера» необходимо сначала развернуть инфраструктуру из доверенных резервных копий, то здесь значительная часть работы уже выполнена заранее. Целевое время восстановления (Recovery Time Objective, RTO) в такой архитектуре составляет четыре-шесть часов, но в любом случае оно должно быть скоординировано с временем проведения расследования в скомпрометированной основной инфраструктуре.
Поскольку в «Цитадели» нет боевой нагрузки (пользовательской активности), в этом ЦОД можно проводить проверки и тестовые восстановления, анализировать сетевой трафик и пр.
«Бункер» и «Цитадель» в архитектуре «Непрерывности 2.0» не конкурируют, а дополняют друг друга. Для самых критичных систем можно организовать защиту на уровне «Цитадели» (в составе доверенного изолированного ЦОД), а для остальных ИС достаточно иметь проверенные резервные копии в «Бункере». Возможность восстановления гарантируется сохранностью данных, а наличие доверенного ЦОД позволяет вернуть системы к работе максимально быстро. Да, создание «Цитадели» требует значительных инвестиций. Однако даже несколько часов простоя могут обойтись многим компаниям существенно дороже, и для них такая защита — не роскошь, а необходимость.
