Или как мы строим для резервных копий «Бункер», который переживёт шифровальщика

Привет, Хабр! На связи команда инфраструктурного центра «Инфосистемы Джет».

Давайте договоримся сразу — мы любим, применяем и верим в правило «3-2-1», оно работает. Как базовая гигиена. Но важно то, что после «но». Правило «3-2-1» подробно отвечает на вопрос, как хранить резервные копии. Но почти ничего не говорит о том, что делать, если целью атаки становятся сами резервные копии.

Поэтому теперь мы считаем, что ему не хватает четвертого элемента — мы называем его «Бункер».

Что вообще происходит?

За последние пару лет шифровальщики и прочие wiper’ы перестали быть просто ворами. Они стали сапёрами. Им не нужны ваши данные — им нужно, чтобы ваш ИТ-ландшафт превратился в пепел. Вместе с резервными копиями, вместе с системой резервного копирования, вместе со всеми вашими «тремя копиями». При этом держим в уме, что бизнес требует гипердоступности сервисов с нулевым даунтаймом.

Мы участвовали в нескольких крупных операциях спасения после киберинцидентов, и наш опыт показывает: наличие номинальной резервной копии (даже отчуждённой) не гарантирует восстановление из неё. Как минимум — в ней может быть закладка, либо каталог СРК окажется уничтожен, и вы вообще не знаете, что с ней делать. А бывает и так — лента есть, а драйвер под неё никто не ставил года три.

Рассмотрим типового пострадавшего заказчика и относительно типовую инфру — виртуализация VMware, отсутствие сегментации, мастер-сервер и прокси в продуктивном VLAN'е без выделенных портов под трафик РК, интеграция мастера с доменом AD и горой непонятных учеток admin2/P@ssw0rd2 с админскими правами, потому что «ну так же удобно…». Что было дальше? А дальше любая CVE в MS AD с Remote Code Execution (RCE) или файл с логопассами на общем терминальном сервере — и резервные копии скомпрометированы или удалены. И вот вы уже попали в новости.

Злоумышленникам было бы значительно сложнее добраться до резервных копий в «Бункере», поскольку он предполагает минимум связей с продуктивом. А восстановление из него было бы значительно проще и быстрее, будь под рукой более или менее актуальные планы восстановления для ИС и план, который описывает, как поднять сетевую связность между РК в «Бункере» и виртуализацией в проде.

А еще мы посмотрели, что происходит в ИТ 120 российских компаний, и цифры там грустные. Почти половина уже нарушает правило «3-2-1», хотя сами знают, что так нельзя. Каждая четвёртая компания никогда не пробовала восстанавливаться из своей резервной копии. А у трети компаний резервный ЦОД — это просто строчка в договоре аренды стойки, которая торчит в той же доменной сети.

Это не значит, что правило «3-2-1» плохое. Это значит, что компании перестали проверять, работает ли оно на самом деле. И главная беда в том, что классическая схема «прод → СРК → лента или S3» становится уязвимой именно в тот момент, когда атакующий уже внутри. Потому что СРК — такая же операционная система, такой же сервер, такие же учётные записи. И если взломщик добрался до админа, он добрался и до ваших бэкапов.

Что такое «Бункер»?

Дисклеймер: Описанный ниже подход ни в коем случае не отменяет наличие полноценного набора ИБ-инструментов разных классов, ни в продуктиве, ни в «Бункере», а наоборот — подчеркивает их необходимость и тонкую настройку в связи с новыми угрозами. Но в статье мы опишем именно архитектурный подход с точки зрения ИТ-инфраструктуры, про ИБ будет минимум.

«Бункер» — полностью изолированный контур СРК, который не имеет прямого сетевого доступа из продуктивной среды и интернета. Его задача — создание доверенных резервных копий, гарантированно пригодных для восстановления даже после тотальной компрометации основной инфраструктуры.

Мы формулируем следующие принципы доверенной резервной копии:

• Из копии можно восстановиться.  Не должно быть такого, что задание восстановления заканчивается ошибкой, а виртуалка потом не включается, или ПО СРК видит эту копию в первый раз.

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

• Выполнена валидация чек-сумм образов.

• Копия актуальна на конкретную дату. Имеется ввиду на ту дату, которая нужна именно вам и вашему бизнесу, именно под вашу задачу (тест, регулятор и прочее), именно в нужный момент времени (учения, регулятор).

• Размещена на неизменяемом/отчуждаемом хранилище.

• Используется внешнее шифрование (опционально).

При наличии «Бункера» правило «3-2-1» можно уже превратить в «3-2-1-1-0». Добавляется наличие одной копии на неизменяемом носителе и 0 ошибок при тестовом восстановлении из РК.

Важно ли физическое расположение? Чем дальше «Бункер» от ЦОДа, тем выше требования к каналам связи и репликации. Поэтому если у вас нет техногенных рисков — можно размещаться в соседней стойке. Но золотой стандарт - общем случае это отдельное помещение. Важно, чтобы каналы между «Бункером» и ЦОДом не стали узким местом при восстановлении — кому-то будет достаточно 2х16G, кому-то этого будет мало. Они должны обеспечивать максимальную скорость, которую будет отдавать оперативный слой хранения РК — all flash массив — это 4-5Gb\s для западного midrange.

Но «Бункер» - это не только про технологии.

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

Именно поэтому в «Бункере» должен храниться не только набор резервных копий, но и план восстановления, понятная инструкция. Что поднимать первым? Что может подождать? Кто принимает решения? Во время аварии искать ответы на эти вопросы уже поздно.

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

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

Каждая тренировка делает лучше и команду, и сам план.

В итоге «Бункер» хранит не только резервные копии. Он хранит всё, без чего резервные копии бесполезны: план, опыт и команду, которая уже проходила этот сценарий. И это сокращает время простоя гораздо сильнее, чем кажется.

Архитектурная схема (на пальцах и кулаках)

Краткий as is левой части с продуктивом, где у нас крутятся БД, приклад и весь бизнес

В левом углу ринга — «текущая инфраструктура», это основной контур СРК, он же ОСРК, выглядит шаблоном и должен включать в себя:

• Сервер управления СРК, медиа-агенты, SAN-сеть.

• Слой хранения с репозиториями резервных копий. Оперативные — на дисках побыстрее, долгосрочные — на дисках помедленнее, архивные/отчуждаемые — на лентах или на S3 с object lock.

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

В правом углу ринга — собственно наш «Бункер», это изолированный контур СРК, он же ИСРК.

• Отдельная инсталляция ПО СРК со своей БД каталога мастер-сервера, свои медиа-агенты, своя SAN-сеть.

• Отдельный слой хранения с репозиториями резервных копий. Оперативные — на дисках побыстрее, долгосрочные — на дисках помедленнее, архивные/отчуждаемые — на лентах или на S3 с object lock.

Продуктив правой части — набор ресурсов, минимально необходимых для запуска того, что мы собираемся проверить. Предположим, это 20% от левой части — так как свои гипервизоры, своя физика, свой продуктивный массив и собственные инфраструктурные службы (AD, DNS, DHCP), отличные от продуктивного домена. То есть это небольшая часть ИТ-инфраструктуры — «прод на минималках», которая позволяет проводить тестовые восстановления и отрабатывать DRP-планы. Ну а в момент аварии в принципе может использоваться в качестве ИТ-ресурсов для продуктива, пока идет расследование в основном контуре. Изолированные сети передачи данных, изолированные УЗ с выделенным терминальным сервером для управления, мультифактор, МСЭ.

Итого: fully isolated на уровне любых подключений и общих инфраструктурных доменов среда — это залог максимально возможной гарантии восстановления.

Краткий to be левой части

Для того чтобы обеспечивать максимальные скорости передачи резервных копий, необходимы all flash-массивы — самые быстрые на Диком Западе (или на цивилизованном Востоке). Для этого в оперативный уровень хранения РК в ОСРК мы добавляем новый массив, куда будем писать бэкапы только критичных ИС. Но это не всё. Логику хранения РК и политики в ОСРК нужно будет переделать — пустить новые задания на новые тома, презентованные медиа-агентам, при этом РК каталога ОСРК пишем на отдельный LUN Итоговая схема взаимодействия выглядит так:

Далее передача данных осуществляется с помощью асинхронной репликации через протокол FC — как наиболее устойчивый к компрометации и шифровальщикам. В качестве дополнительной защиты после репликации отключаем порты — либо с помощью portdisable, либо физически, в зависимости от того, как часто будет выполняться репликация.

Далее:

• Окно РК завершилось

• Сделали РК критичных ИС и положили на LUN массива

• Сделали РК каталога и тоже положили на LUN массива

• Стартует асинхронная реплика, после её окончания post-скрипты выключают линки на SAN свичах в ОСРК

В правой части обратная последовательность:

• Восстанавливаем из РК каталог мастер-сервера, чтобы он знал про эти копии

• Монтируем LUN на медиа-агенты

• Инвентаризируем устройства хранения в ПО СРК

А что с процессом переключения/восстановления?

Тут всё зависит от реализации.

Вариант 1: всё пропало. Буквально всё. Вайпер снёс весь продуктив (всю левую часть), и у нас остался только «Бункер» и его доверенные копии, которые мы заранее проверили, и они нам подойдут. В таком случае достаточно завершить расследование, понять, как зловред к нам пробрался, залатать дыры, перезалить гипервизоры, поставить агенты СРК и начать восстановление из «Бункера». Критичный момент в этом сценарии — сетевая связность, каналы, проходы, всё это должно быть тщательно спроектировано и проверено на испытаниях. Точно так же, как вы проверяете работоспособность бизнеса, переключая нагрузку из ОЦОД в РЦОД и наоборот.

Вариант 2: «Бункер» имеет достаточно ресурсов и большой запас прочности с точки зрения инфобеза. Ничто не мешает нам запускать приложения и бизнес-процессы непосредственно в нём.

Бонус для хитрых

Если РК каталога ОСРК писать на ленту, то можно будет проводить тестовые восстановления в ИСРК и с лент, переместив их в библиотеку ИСРК. Это будет небыстро, но позволит актуализировать DRP и провести учения.

Ещё один бонус. Если предусмотреть х2 места на массивах, можно передавать проверенные РК и РК каталога обратно — из ИСРК в ОСРК без подмонтирования LUN на медиа-агенты. Это сократит время восстановления из РК, если «Бункер» находится на другом конце Москвы и связь с ним только по FC.

Восстанавливаем данные, убеждаемся, что с ними всё ОК. Повторяем упражнение раз в квартал.

Типовой таймлайн восстановления после ЧС

Процесс работы киберкриминалистов оставим за скобками, но будьте готовы к тому, что пока не завершится расследование в «левой» части схемы (в основном контуре продуктива), работать в проде, скорее всего, не дадут. И это ещё одна из фич «Бункера». У нас уже есть прод на минималках, и в более короткие сроки мы можем пустить туда пользователей. ИЛИ, когда будет принято решение перезалить все гипервизоры в проде правой части — у нас уже будет готовая к бою СРК.

• Восстановление ключевой инфраструктуры | Х часов | Зачистка продуктивной среды, развёртывание виртуализации, AD/DNS/DHCP, перенастройка СХД, SAN, firewall

• Восстановление данных критичных ИС | Y часов | Восстановление из последней доверенной копии (All-Flash, SAN не является узким местом). По сути — это процесс восстановления из вашей резервной копии, где бы она ни лежала.

• Проверка и запуск | Z часов | Запуск ИС, проверка администратором, предоставление доступа пользователям. Можно восстановить 10 критичных ИС за два дня, а можно за 20 дней. Тут речь про качественные DRP, понимание зон ответственности, обученную команду, правильную последовательность восстановления и взаимосвязи между компонентами.

Подставьте сюда ваши реальные цифры, исходя из объёма данных, пропускной способности каналов, сложности ИС и качества DRP-планов. 

Это всё — время восстановления (RTO). А что с потерянными данными и RPO? Потеря данных будет зависеть от частоты РК, а в случае инцидента ИБ и потери прода речь идёт только про полные копии, поэтому максимум — 24 часа.

Что вы получите и чем за это заплатите

Преимущества, на наш взгляд, перевешивают. Вы можете проверять восстановление в любое время, не трогая прод. Можете переиспользовать старое оборудование. Да, потеряете в скорости, но сэкономите бюджет. У вас гарантированная совместимость, потому что вы восстанавливаетесь в ту же платформу. Вы можете отработать сценарий полного разрушения без риска для продуктивной среды. В час «Х» «Бункер» становится вашим новым продуктивом. И вы наконец-то получаете реальные цифры RTO.

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

Минимальный набор юного выживальщика, или «Собери свой "Бункер"»

• 2х all flash-массивов по 200 ТБ

• 2х пар коммутаторов FC Brocade Gen6 с растянутой сетью до 40 км

• Пара коммутаторов Huawei под СПД в самом «Бункере»

• Пара CheckPoint-ов в части МСЭ

• Мастер- и медиа-сервера на физике — минимум по 1 штуке

• Пара коммутаторов Huawei под управление в самом «Бункере»

• Сервера виртуализации — для запуска ИС в минимальной конфигурации — 3–4 штуки, но тут сильно зависит от объёма и переподписки

• В идеале — ленточка, чтобы откидывать проверенные и восстановленные РК и делать их доверенными

• Работы и поддержка на железо в течение трёх лет

  

  Дополнительно нужно предусмотреть SIEM, АВЗ, EDR и, как вариант проверки на закладки, PT SandBox.

  К чему мы пришли

  Правило «3-2-1» не умерло, но мы целимся в «3-2-1-1-0».

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

  Да, это дороже и сложнее. Но, когда ваш основной ЦОД будет опечатан, а бизнес потребует «вернуть всё к обеду», вы будете благодарны себе из прошлого, не поленившемуся это построить. Потому что большинство изолированных копий, которые мы наблюдаем в последнее время (а мы их наблюдаем много), — это просто ещё один диск по iSCSI в той же подсети.

  И шифровальщики про это знают.

  Пароли админа СРК заведены в общем AD? Резервные копии хранятся на массивах, включенных в общую сеть управления? Хотя бы одна резервная копия и каталог СРК вывозятся с продуктивной площадки физически? Как вы проверяете, что внутри копий уже нет закладок? Как вы проверяете, что из вашей офлайн-копии действительно можно восстановиться? Как часто вы проводите учения — раз в квартал, раз в полгода или «когда-нибудь потом»?

  Если вы отвечаете за работу ИТ в вашей организации — то по итогу нашей статьи это тот минимальный список вопросов, который мы бы хотели, чтобы вы задали себе и честно порефлексировали над ответами.

  Новые угрозы требуют новых ответов.

  Над статьей работали:

  Игорь Шконда, руководитель направления систем резервного копирования «Инфосистемы Джет»

  Антон Шипулин, начальник отдела комплексных проектов «Инфосистемы Джет»