Правило 3-2-1 не устарело — устарело представление, что его достаточно

3 часа назад

© mt cloud

Правило 3-2-1 многие годы считалось негласным стандартом резервного копирования. Сегодня оно по-прежнему остается базой, но уже недостаточной. О том, почему классическое правило перестало защищать от современных угроз и что пришло ему на смену, журналу RUБЕЖ рассказал Виктор Виноградов, директор по информационной безопасности mt cloud.

RUБЕЖ: Что такое правило 3-2-1 и почему оно долгое время работало?

Виктор Виноградов:  Классическое правило звучит просто: три копии данных, на двух разных носителях, одна из которых хранится вне основной площадки. Основные данные — на сервере, копия — на NAS в той же серверной, еще одна — например, на ленте у подрядчика или в соседнем здании.

Когда правило создавалось, главными угрозами были отказ железа, пожар в серверной и случайное удаление. С каждой из них оно справлялось: сгорела серверная — лента у подрядчика цела, сломался диск — есть NAS, случайно удалили данные — восстановили из копии. Каждая из этих угроз била в одно место, а копии лежали в разных. Что бы ни случилось, хотя бы одна копия оставалась цела. Поэтому правило работало.

RUБЕЖ: Как правило 3-2-1 потеряло свою главную защиту?

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

Потом удобство альтернатив начало вытеснять ленту: она оставалась востребованной, но перестала быть вариантом по умолчанию. Копии переехали на дисковые хранилища — дешевле, и восстанавливать быстрее. Выносную копию стали отправлять во второй ЦОД по каналу связи или в облако — без коробок и курьеров.

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

RUБЕЖ: Как шифровальщики воспользовались этим слабым местом?

В. Виноградов: Потом появились шифровальщики. Первые серьезные атаки на бизнес случились в 2016–2017 годах. А в 2020-х они воспользовались той самой незащищенностью: атаки стали целенаправленными — прицельно по резервным копиям.

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

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

По данным F6, в 2025 году зафиксировано более 450 атак на российские компании с использованием шифровальщиков — с суммами выкупов от 4 до 40 млн рублей. По данным Positive Technologies, доля успешных атак с использованием шифровальщиков выросла с 25 до 35%. Эти цифры проявляют масштаб проблемы: шифровальщики стали не редкостью, и цена атаки для бизнеса может быть высокой.

 RUБЕЖ: Где именно правило 3-2-1 перестало работать?

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

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

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

Правило 3-2-1 решало задачи своего времени. Но угрозы изменились, плюс практика вскрыла пробелы применения правила, и подход обновился: бэкап должен быть изолирован, неизменяем и проверен восстановлением. Без этого защита существует условно, и последствия могут быть критичными.

RUБЕЖ: Что пришло на смену классическому подходу?

В. Виноградов: Ответом стала модель 3-2-1-1-0. Первые три цифры — прежние и означают то же: три копии, два носителя, одна вне основной инфраструктуры. Добавились две последние — и за каждой стоит новое требование.

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

Второе требование — ноль ошибок при проверке восстановления. Бэкап без проверки — не бэкап. Проверка должна быть регулярной практикой.

Разница с классическим правилом принципиальная. 3-2-1 отвечало на вопросы: «Сколько копий и где они физически находятся?» 3-2-1-1-0 добавляет два новых аспекта: «Можно ли эти копии уничтожить?» и «Можно ли из них реально восстановиться?» Физическое наличие копий — еще не их защищенность и не гарантия восстановления. Именно этих различий в старом правиле не было.

RUБЕЖ: Как реализовать неизменяемость на практике?

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

Второй — программный: immutable-хранилище, S3 с Object Lock. Хранилище доступно по сети, но данные защищены на уровне политики хранения — до истечения срока их нельзя изменить или удалить.

Здесь важно не перепутать настоящую неизменяемость с ее имитацией. Настоящий immutable нельзя отключить даже с правами администратора. Бывает иначе: галочка в интерфейсе, которую тот же администратор и снимает. Внешне выглядит как защита, по сути ею не является.

Но Object Lock защищает содержимое копии, а само хранилище остается в сети и подчиняется чьим-то правам. Поэтому его выносят из системы еще и логически: заводят отдельные учетные записи, которых нет в основном домене. Тогда взлом рабочей сети не открывает вход в бэкапы.

«Вне системы» теперь читается шире: не только физически вне инфраструктуры, но и логически — вне ее управления.

RUБЕЖ: С какими сложностями сталкиваются российские компании при организации офлайн-хранения?

В. Виноградов: Стандарт физической изоляции — ленточные накопители. Их в мире производят буквально две-три компании. Российских производителей нет. Альтернатив лентам для офлайн-хранения по большому счету не придумано.

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

Отдельная история — картриджи. Это расходный материал, который нужно закупать постоянно, и он тоже импортный.

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

RUБЕЖ: Может ли облачное хранилище стать альтернативой ленточным накопителям?

В. Виноградов: Есть рабочая альтернатива — облачное хранение с immutable-защитой, S3 Object Lock. Но нужно понимать: облако — это не офлайн-хранение, это другой формат, и подходит он не под все требования.

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

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

RUБЕЖ: Закрывает ли правило 3-2-1-1-0 вопрос скорости восстановления?

В. Виноградов: Есть еще один аспект, который правило 3-2-1-1-0 не закрывает, — скорость восстановления.

Косвенно оно касается ее через «ноль»: регулярная проверка восстановления заодно показывает, сколько оно реально длится, и вскрывает узкие места до инцидента. Но само правило не описывает, как эту скорость обеспечить.

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

За скорость отвечают два показателя. RTO — целевое время восстановления: сколько времени допустимо потратить на возврат системы в строй. RPO — допустимый период приемлемой потери данных: как далеко назад можно откатиться.

Можно полностью соблюдать 3-2-1-1-0 и не уложиться ни в один из них: копия рабочая и защищенная, но перекачка большого объема занимает дни, а бизнес ждать не может.

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

RUБЕЖ: Можно ли в итоге сказать, что правило 3-2-1 устарело?

В. Виноградов: Само правило 3-2-1 не устарело — оно осталось фундаментом. Устарело представление, что его достаточно.

Вокруг него выросли новые слои: копию защищают от изменения, изолируют от общей сети и регулярно проверяют восстановлением. Все это — не замена правилу, а ответ на то, как изменились угрозы.

В России к этому добавляется структурная проблема с ленточными накопителями, у которой пока нет отечественного решения. Одни компании работают с единственным оставшимся поставщиком, принимая риски зависимости от него. Другие выбирают облачную immutable-копию там, где регулятор это разрешает.

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

О компании

mt cloud — облачный провайдер для бизнеса. Справочный блок с перечнем услуг, географией присутствия и другими сведениями о компании рекомендуется согласовать с представителем mt cloud перед публикацией, поскольку в исходном документе эти данные не приведены.

Читайте также: Скрытые ИТ-риски, о которых СЕО узнает слишком поздно