У американских спецназовцев на этот счёт есть правило: «Два — это один, а один — это ноль». Их редко переплёвывают, но в мире компьютерных бэкапов и двух мало. Золотым стандартом до недавнего времени оставалось правило 3-2-1: три копии данных на двух разных носителях, одна копия — за пределами площадки.

Правило 3-2-1 всё ещё имеет ценность, особенно для тех, кто вообще не делает бэкап. Но сегодня золотой стандарт эволюционирует. Этот текст о том, почему 3-2-1 уступает место более продуманным стратегиям и в чём разница между классическим правилом и его наследниками — 3-2-1-1-0 и 4-3-2, — и как выбрать схему под конкретную задачу.

Почему 3-2-1 теряет популярность

Когда стратегия 3-2-1 только набирала вес, технологический ландшафт выглядел совсем иначе. Считается, что правило родом из фотографии — Питер Крог сформулировал его в книге «The DAM Book: Digital Asset Management for Photographers» 2009 года. В то время ленточные накопители всё ещё широко использовались на корпоративном уровне из-за низкой стоимости, ёмкости и долговечности носителя.

Схема 3-2-1 улучшила тогдашнюю практику «одна копия на ленте, и пусть лежит где-нибудь подальше». Она предписывала держать три копии данных (одну рабочую и две резервные) на двух разных носителях (например, внутренний диск + лента + внешний HDD или ещё одна лента) и одну копию — вне основной площадки (как правило, именно ту самую ленту).

Пока облачные хранилища не стали массовыми, чтобы вынести третью копию «наружу», приходилось нанимать выездную службу, которая забирала ленты и увозила их в хранилище, либо самостоятельно везти их в другую локацию (один из наших сооснователей отправлял копию бэкапа по почте своему брату). За счёт этого офсайтовые ленты были «air-gapped» — буквально физически отделены от сети, в которой жил основной экземпляр. Если первичные данные или локальный бэкап оказывались повреждены или скомпрометированы, можно было восстановиться с офсайтовой копии.

С развитием технологий хранения 3-2-1 стало немного… облачнее. Компания может развернуть локальное хранилище для бэкапа — сетевое хранилище NAS или специализированную сеть хранения SAN — и реплицировать содержимое в объектное хранилище в облаке. Частник реализует ту же схему через внешний диск и облачный сервис.

И всё бы хорошо, но при облачных офсайт-копиях схема 3-2-1 теряет тот самый воздушный зазор, который давала лента. Облачные бэкапы зачастую подключены к рабочей сети — а значит, уязвимы для цифровой атаки.

Шифровальщики — двигатель более жёстких стратегий

После нашумевших инцидентов последних месяцев уже мало кого удивишь тем, что атаки шифровальщиков на подъёме. Размер выкупа на 2021 год достиг рекордных $50 млн, а атаки на Colonial Pipeline и JBS Foods угрожали поставкам топлива и продовольствия. В отчёте 2021 года Detect, Protect, Recover: How Modern Backup Applications Can Protect You From Ransomware Gartner прогнозировал, что к 2025 году хотя бы с одной атакой столкнутся не менее 75% IT-организаций.

Бэкапы должны быть последней соломинкой при атаке шифровальщика — но они работают, только если сами не скомпрометированы. И атакующие это понимают. Известные группировки-шифровальщики — например, Sodinokibi (она же REvil), стоящая за атаками на JBS, Acer и Quanta, — теперь идут не только за рабочими данными, но и за резервными копиями.

Облачные бэкапы нередко завязаны на корпоративный Active Directory и виртуально не изолированы от рабочей сети. Стоит злоумышленнику закрепиться на машине, подключённой к сети, как он начинает перемещаться по ней горизонтально, чтобы добыть админские учётки — кейлоггерами, фишингом или просто из документации, валяющейся на серверах. Если в его руках окажутся админ-учётки AD, все бэкапы, защищённые этим AD, становятся уязвимы.

Жизнеспособна ли стратегия 3-2-1 сегодня?

Несмотря на технологические перемены, ключевые принципы 3-2-1 по-прежнему верны:

• Копий данных должно быть несколько.

• Копии должны быть географически разнесены.

• Хотя бы одна копия должна лежать под рукой, чтобы быстро восстановиться после физического сбоя или случайного удаления.

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

Чем заменяют 3-2-1?

3-2-1 — всё ещё рабочая схема, но появились более полные стратегии, закрывающие уязвимости, которые добавила постоянная сетевая связность. Они звучат не так бойко, как 3-2-1, но дают больше защиты в эпоху облачных бэкапов и шифровальщиков. Это 3-2-1-1-0 и 4-3-2.

Что такое 3-2-1-1-0 (кратко)

Прим. перев. Этот раздел в оригинале довольно подробный, но мы детально разобрали схему 3-2-1-1-0 в предыдущем переводе материала AvePoint. Здесь даём только краткую сводку. Если хочется глубже — лучше прочитать ту статью целиком.

Схема предписывает:

• хранить минимум 3 копии данных,

• на 2 разных типах носителей,

• 1 копию — вне основной площадки,

• ещё 1 копию — офлайн или с воздушным зазором (это может быть лента или иммутабельная облачная копия),

• и обеспечить 0 ошибок: ежедневный мониторинг бэкапов, мгновенное исправление ошибок и регулярные тестовые восстановления.

Главная мысль: 3-2-1-1-0 возвращает идею «недосягаемой» копии — той самой, до которой шифровальщик не дотянется, даже если получит админский доступ ко всему остальному. Реализовать иммутабельность в облаке проще всего через Object Lock — настройку, которая запрещает изменять или удалять файл до указанной даты, причём даже владельцу учётной записи или взломщику с его учётными данными.

Что такое 4-3-2

А вот этот раздел — тот, ради которого мы подготовили наш материал.

Если вашими данными управляет специализированный провайдер услуг аварийного восстановления вроде Continuity Centers, то ваши бэкапы, скорее всего, живут по правилу 4-3-2:

• 4 копии данных,

• данные в 3 локациях (на вашей собственной площадке, на площадке сервис-провайдера вроде Continuity Centers и у внешнего облачного провайдера),

• 2 из этих локаций находятся за пределами вашей основной площадки.

Предостережение

Некоторые провайдеры облачных сервисов любят намекать, что использование нескольких вендоров — это признак недоверия к их собственной надёжности. На самом деле резервные подстраховки должны быть всегда. Правда в том, что упасть может что угодно. Жёсткие диски выходят из строя. Хорошие сотрудники совершают плохие ошибки. Плохие сотрудники — ещё худшие. Даже крупнейшие облачные провайдеры регулярно ловят громкие сбои, тянущие за собой существенную часть интернета и популярные сервисы. Здравомыслящие люди исходят из этого, какого бы поставщика ни выбрали.

Какая стратегия подходит вам

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

• Несколько копий данных — минимум три.

• Копии в географически разнесённых локациях.

• Хотя бы одна копия — на месте, для быстрого восстановления.

С такими инструментами, как Object Lock, вы можете надстроить ядро принципами 3-2-1-1-0 или 4-3-2: дать данным дополнительный слой защиты, виртуально изолировав их так, чтобы их нельзя было удалить или зашифровать в течение заданного времени. Если шифровальщик всё же доберётся до ваших систем, бэкап под Object Lock позволит восстановиться.

От Cloud4Y. Если на бумаге у вас уже выстраивается 4-3-2, но не хватает одной из «трёх локаций» — мы как раз закрываем эту роль. Cloud4Y — российский облачный провайдер с собственными дата-центрами на территории РФ; на нашей инфраструктуре можно разместить ту самую вторую офсайтовую копию. Для читателей Хабра действует акция: скидка 20% на аренду облачных серверов по промокоду HABR20. Условия — на странице акции. На арендованной инфраструктуре можно поднять собственный бэкап-таргет и проверить схему 4-3-2 на боевых данных, прежде чем закладывать её в постоянную архитектуру.