От резервного копирования к киберустойчивости: эволюция модели «3-2-1» под современные атаки

27.03.2026

Евгения Шафоростова

Автор

Еще недавно резервное копирование считалось последней линией защиты от инцидентов. Сегодня оно само становится одной из первых целей атакующих. Современные вымогатели не просто шифруют рабочие станции — они заранее ищут и уничтожают механизмы восстановления, лишая компании «кнопки отката». В таких условиях классическая схема «3-2-1» остается важной основой, но требует серьезного пересмотра. Кибер Медиа разбирает, какие архитектурные изменения превращают бэкап из формальности в инструмент реальной киберустойчивости.

Содержание

Эволюция угроз: почему «просто бэкап» больше не работает

Лет 10-15 назад главным врагом данных были «кривые руки» пользователей, посыпавшиеся диски или пожар в серверной. Тогда и зародилась классическая формула «3-2-1», ставшая золотым стандартом отрасли. Она элегантна в своей простоте: храните 3 копии данных на 2 разных носителях и минимум 1 копию на удаленной площадке. Долгое время этого было достаточно, чтобы спать спокойно.

Однако современные программы-вымогатели превратили эту схему в мишень. Сегодня атакующие действуют как элитный спецназ: они понимают, что нет смысла шифровать файлы, пока у компании работает «кнопка спасения». Поэтому современная атака начинается с охоты на бэкап-инфраструктуру.

Злоумышленники месяцами сидят в сети, вычисляя учетные записи администраторов и доступ к сетевым шарам. Сценарий нападения изменился радикально:

Компрометация админов. Поиск паролей от консолей бэкапа для удаления цепочек копий.
Уничтожение сетевых шар. Мгновенное затирание данных на доступных SMB/NFS-ресурсах.
Ослепление мониторинга. Отключение уведомлений об ошибках перед началом шифрования.

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

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

Неизменяемость — фундамент современной защиты

Сегодня бэкап перестал быть «страховкой» и стал полноценной мишенью №1. Современные вымогатели действуют методично: сначала «ослепляют» ИТ-службу, удаляя теневые копии и затирая старые архивы, и только потом включают шифровальщик. В такой реальности обычное копирование — это просто отсрочка неизбежного. Чтобы выжить, данные должны стать «гранитными».

Анна Толмачева

Консультант по информационной безопасности, «КИТ» (Киберинтеллектуальная Трансформация)

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

В отличие от классических сетевых шар (SMB/NFS), где клиент имеет полный контроль над файлом, неизменяемое хранилище работает как «черная дыра» для деструктивных команд: оно принимает данные, но игнорирует любые попытки их уничтожить.

Битва за учетные данные: защита «прав на уничтожение»

Для Ransomware-группировок учетная запись с правами Domain Admin — это универсальный ключ, позволяющий парализовать инфраструктуру за считаные минуты. Если серверы бэкапа и репозитории включены в общий домен Active Directory, они становятся частью единого вектора атаки. Злоумышленник, получивший доступ к контроллеру домена, использует Kerberos или NTLM-аутентификацию для горизонтального перемещения и полной очистки бэкап-консоли.

Современная стратегия защиты требует внедрения концепции Zero Trust на уровне управления данными. Бэкап-инфраструктура должна функционировать как изолированный остров: она не доверяет внешним инстанциям аутентификации и требует локальной проверки прав для любой деструктивной операции.

Максим Федосенко

Ведущий инженер-аналитик аналитического центра кибербезопасности компании «Газинформсервис»

Давать администратору полный неразделенный доступ к бэкапам — все равно что хранить ключи от сейфа прямо в замке. Опасность обусловлена тем, что, если злоумышленник скомпрометирует основную учетную запись админа, например, через баг сброса пароля от технической учетной записи (KRBTGT) в Active Directory, под угрозой исчезновения окажется вся инфраструктура.

Поэтому при проектировании защиты важно не забывать про принципы изоляции и микросегментации, а сама архитектура системы защиты данных должна строиться на базе изолированного сегмента управления. Иначе говоря, хакер, получивший права Enterprise Admin, не должен физически иметь сетевой доступ и права Management Plane на системы резервного копирования. Таким образом, архитектура разделения полномочий и доступа обозначает, что полные права на управление сетью и управление бэкапами должны быть у разных, изолированных друг от друга сущностей.

Ключевые элементы такой архитектуры включают:

RBAC. Гранулярное распределение ролей, где «Backup Administrator» имеет право на создание заданий, но лишен права на удаление точек восстановления или изменение политик хранения.
Аутентификация без паролей. Переход на использование аппаратных токенов (FIDO2) или сертификатов. Это защищает от кражи хэшей паролей и атак типа Pass-the-Hash.
MFA и Four-Eyes Policy. Принудительная двухфакторная аутентификация для доступа к консоли управления и подтверждение критических изменений, например, сокращение срока хранения данных, вторым авторизованным сотрудником через независимый канал.

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

Тихая угроза: когда бэкап превращается в яд

Современные вымогатели сменили тактику с «ковровых бомбардировок» на скрытое закрепление. Самый опасный сценарий сегодня — это Delayed Encryption. Злоумышленники не блокируют данные сразу, а месяцами подменяют оригинальные блоки зашифрованными фрагментами. Цель проста: дождаться, пока срок хранения легитимных копий истечет, и в распоряжении компании останутся только «отравленные» архивы с бесполезным шумом.

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

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

Даниил Глушаков

Аналитик центра мониторинга киберугроз Спикател

Здесь работают сразу несколько механизмов: контрольные суммы и хэши, сравнение версий, обнаружение аномалий по объему и структуре изменений, а также отложенный бэкап — хранение цепочек версий за длительный период. Современные решения применяют поведенческую аналитику: если данные меняются нетипично, копия помечается как подозрительная. Это позволяет «откатиться» к последнему гарантированно чистому состоянию, а не к ближайшему бэкапу.

Дополнительным фильтром выступает контроль метаданных и Change Rate. Аномальный всплеск числа измененных или переименованных файлов должен автоматически блокировать цикл резервного копирования до выяснения причин. Внедрение проактивной верификации и регулярного хеширования позволяет выявить «тихую порчу» еще до того, как поврежденная копия вытеснит здоровую версию из хранилища.

Безопасное восстановление: «чистая комната» для данных

Главный парадокс кибербезопасности: бэкап, который должен стать спасением, часто превращается в троянского коня. Ransomware может находиться в системе неделями, попадая в каждую резервную копию. Если просто нажать кнопку «Restore», вы вернете в сеть не только файлы, но и спящий код вымогателя, который мгновенно запустит повторный цикл шифрования.

Процесс восстановления сегодня — это не просто копирование данных из точки А в точку Б, а полноценная «дезактивация». Чтобы разорвать этот замкнутый круг, необходимо внедрение Secure Restore и изолированных контуров проверки.

Максим Федосенко

Ведущий инженер-аналитик аналитического центра кибербезопасности компании «Газинформсервис»

Восстанавливать систему из бэкапа напрямую в production-среду — это все равно что заново «сажать сорняки» на прополотую грядку. Это ключевая ошибка администраторов, которая приводит к возвращению ransomware. Обусловлено это тем, что в бэкапе почти всегда сидит то самое «спящее зерно» (исходник) вируса, попавшего туда задолго до момента своего начала активного заражения системы.

Чтобы восстановление в случае атаки шифровальщика не становилось повторной точкой заражения, сам процесс восстановления должен сначала проходить через изолированную «песочницу». Иными словами — сначала мы восстанавливаем копию в изолированной защищенной среде, затем сканируем на предмет наличия артефактов атак и сигнатур вредоносной активности, и только убедившись в чистоте бэкапа, переносим его данные в production-среду.

Такой подход исключает риск реинфекции и позволяет вычистить зловред еще на этапе его извлечения из архива.

Облако как «последний рубеж»

Перенос бэкапов в облако часто воспринимается как автоматическое решение всех проблем безопасности, но это опасное заблуждение. Облако не является «магическим щитом» по умолчанию; это лишь расширение вашей поверхности атаки. Если злоумышленник скомпрометировал учетные записи с доступом к Cloud Console, он получает возможность уничтожить всю инфраструктуру хранения парой кликов, обходя любые локальные политики безопасности.

Главный риск здесь — единая точка отказа в виде панели управления провайдера. Без специфических настроек облачная копия так же уязвима для удаления, как и локальный сетевой диск. Чтобы облако действительно стало «последним рубежом», оно должно быть архитектурно отделено от основной ИТ-среды клиента. Чтобы облачная копия выжила даже при полной потере контроля над офисным аккаунтом, необходимо внедрить несколько уровней технической изоляции.

Айрат Мухаметшин

Начальник отдела методологии и комплексной экспертизы Cloud Networks

Применительно к данной ситуации, облачный сервис мы рассматриваем только как место хранения статичных данных (резервной копии). И задачей провайдера здесь является обеспечение целостности, подотчетности и неизменяемости хранимых данных, а также доступность инфраструктуры облака как сервиса.

Базовыми мерами, не требующими больших капитальных вложений, являются настройка встроенных механизмов безопасности на уровне ОС и приложений АРМ-администратора — инструментов контроля доступа, регистрации и учета событий, контроля целостности. Также необходимо реализовать двухфакторную аутентификацию администратора при доступе к инструментам управления функционалом облачного хранилища на стороне клиента — относительно простая в реализации мера способна существенно затруднить реализацию злоумышленниками угрозы перехвата доступа/приобретения административных прав путем оперативного оповещения о попытке доступа к инструментам управления.

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

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

Правильно настроенное облако работает по принципу «билета в один конец»: данные могут уходить туда по расписанию, но ни один процесс или человек из локальной сети не имеет полномочий на их досрочное уничтожение.

От «3-2-1» к «3-2-1-1-0»: новая формула защиты

Классическая формула «3-2-1» безнадежно устарела. В мире RaaS это лишь «базовый уровень», который профессиональные вымогатели обходят в первую очередь. Если все ваши бэкапы доступны по сети, они умрут одновременно с основной инфраструктурой. Настоящая киберустойчивость требует перехода к расширенному стандарту «3-2-1-1-0».

Андрей Кузнецов

Генеральный директор ООО «РуБэкап» (входит в «Группу Астра»)

Классическая модель 3-2-1, предполагающая 3 копии данных на 2 разных типах носителей и 1 копию офлайн, перестает эффективно защищать от современных ransomware из-за их целенаправленной охоты за бэкапами и способности к латеральному перемещению по сети. Современные вымогатели действуют поэтапно: сначала проникают через фишинг или уязвимости и эскалируют привилегии, затем сканируют сеть, включая NAS, облачные сервисы и виртуальные машины, чтобы зашифровать или удалить все доступные копии данных. При этом офлайн-копия часто оказывается подключенной через NAS или SMB, что делает ее уязвимой для атаки. Переход к расширенной модели 3-2-1-1-0 решает ключевые проблемы, добавляя: +1 — неизменяемую копию (Object Lock/air-gapped), +0 — отсутствие ошибок благодаря SureBackup и тестовым восстановлениям.

Такая модель меняет саму парадигму: мы перестаем просто «сохранять данные» и начинаем строить архитектуру выживания, которая заранее предполагает взлом периметра и компрометацию админов.

Заключение

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

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