Правило 3-2-1 и ransomware: почему нужен суффикс «-1-0»

Прошлый год принёс волну RDP-атак. Схема отработанная: сканируют интернет, находят открытый 3389, брутят или покупают учётки, заходят, смотрят что интересного, запускают шифровальщик. Иногда - вайпер. У одного из клиентов эта история закончилась тем, что атакующий добрался до резервных копий раньше, чем кто-либо успел отреагировать.

Вот тут мы и начали предметно разговаривать о том, что правило 3-2-1, которое висит в каждой второй презентации по резервному копированию, в нынешних условиях неполное.

Что не так с 3-2-1

Правило простое: 3 копии данных, на 2 разных типах носителей, 1 из которых хранится offsite. Логика здравая - если горит датацентр или умирает массив, у тебя есть копия в другом месте.

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

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

У нашего клиента именно так и вышло. Бэкапы лежали на NAS в той же сети, под той же учёткой. RDP-сессия, права домен-админа, несколько часов работы - и резервные копии зашифрованы вместе со всем остальным. Восстанавливать было практически не из чего.

Что такое 3-2-1-1-0

Суффикс «-1-0» - это две дополнительных цифры:

• 1 - одна копия должна быть immutable (неизменяемой). Это копия, которую нельзя изменить или удалить даже из-под привилегированной учётки за пределами специального API. S3 Object Lock с режимом Compliance, репозиторий Veeam на Linux с неотзываемой блокировкой через immutability flag (chattr +i), ленточные библиотеки с WORM. Идея простая: даже если атакующий получил полные права - эта копия ему не по зубам.

• 0 - ноль ошибок при последней проверке восстановления. Резервная копия, которую никто не проверял, это не резервная копия - это надежда. Ноль означает, что restore реально тестировался и прошёл без ошибок.

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

Как это выглядит на практике

После инцидента мы пересмотрели подход для клиентов на managed-сопровождении. Общая логика такая:

Основная копия - локально, на выделенном хранилище, изолированном от домена. Veeam Backup Repository на Linux-сервере с аутентификацией через SSH-ключ, без членства в AD. Immutability на уровне файловой системы через chattr +i на завершённые задания.

Offsite-копия - в облачное хранилище с Object Lock. S3-совместимые хранилища у российских провайдеров поддерживают это. Retention в режиме Compliance: даже владелец бакета не может удалить объект до истечения срока.

Проверка восстановления - не «запуск задания верификации», а реальный mount и проверка целостности файлов на изолированной машине. Раз в месяц минимум, по ключевым системам - чаще.

Это не единственно возможная схема. Лента как WORM-носитель вполне рабочая история там, где объёмы большие. Главное - хотя бы одна копия должна быть физически или логически недоступна для того, кто скомпрометировал вашу доменную среду.

Что не решает 3-2-1-1-0

Честно: это всё равно реакция, а не превенция. Если атакующий сидит в сети три недели, а retention у вас две - вопрос о том, есть ли незашифрованная копия начала периода присутствия, становится неприятным.

Поэтому immutable бэкапы - это одна часть работы. Параллельно нужен нормальный мониторинг аномалий, сегментация сети (RDP в интернет в 2021-м - это просто приглашение), и понимание того, что домен-админ не должен иметь доступ к системе резервного копирования напрямую.

После той истории с клиентом мы закрыли RDP наружу, завели отдельную учётку только для бэкап-агентов без доменных прав, и переехали на схему с hardened repository. Больно было перестраивать. Инцидент был больнее.