|
Professor Seleznov
|
Это второй материал в нашей мини-серии про эволюцию правила 3-2-1: в предыдущей статье мы переводили технический разбор классической схемы и в концовке упоминали, что современная индустрия достроила к ней этажи в виде 3-2-1-1-0 и 4-3-2. Этот перевод подробно раскрывает первую из двух надстроек — схему 3-2-1-1-0. Про 4-3-2 (мультиоблачный вариант, продвигаемый в первую очередь Commvault) подготовим отдельный материал.
Все суждения и оценки в основном тексте принадлежат автору. Комментарии команды Cloud4Y вынесены в отдельные плашки и явно помечены как «Прим. перев.» либо «От Cloud4Y».
Правило резервного копирования 3-2-1 предписывает хранить три копии данных на двух разных типах носителей, при этом одна копия должна находиться вне основной площадки. Это самый часто цитируемый принцип в области бэкапов, но сегодня его одного уже недостаточно. Шифровальщики изменили математику. Современный стандарт — правило 3-2-1-1-0, которое добавляет к классической схеме одну неизменяемую (immutable) копию, отключённую от сети, и обязательную проверку того, что данные действительно восстанавливаются. Эта статья объясняет оба правила, причины эволюции и то, как реализация выглядит на практике.
Что такое правило 3-2-1
Правило 3-2-1 — это базовая схема резервного копирования, изначально популяризированная фотографом Питером Крогом и впоследствии широко распространившаяся в IT. Цифры означают:
- 3 — поддерживайте как минимум три копии данных (продакшн-копия плюс две резервные).
- 2 — храните копии минимум на двух разных типах носителей (например, локальный диск и облако или диск и лента).
- 1 — держите как минимум одну копию вне основной площадки, в географически отдельной локации.
Логика проста: у большинства сбоев одна точка отказа. Сломался диск, затопило здание, шифровальщик заблокировал сервер. Правило 3-2-1 гарантирует, что один инцидент не уничтожит все копии одновременно. Если основные данные и локальный бэкап уничтожены, удалённая копия остаётся.
Почему 3-2-1 уже недостаточно
Правило 3-2-1 проектировалось под аппаратные сбои и локальные катастрофы. Атаки шифровальщиков работают по совсем другой модели угроз.
Современный шифровальщик не просто шифрует основные данные. Сначала он находит и шифрует подключённые к сети хранилища с резервными копиями. Злоумышленники знают учебник по 3-2-1 и целенаправленно идут за удалённой копией, облачным хранилищем и учётными записями бэкап-сервера ещё до того, как запустить шифрование основных систем.
В атаке на Colonial Pipeline в 2021 году (Colonial Pipeline — крупнейший оператор магистральных нефтепроводов на восточном побережье США; та атака на несколько дней парализовала поставки топлива в полутора десятках штатов) злоумышленники находились внутри сети несколько дней до удара. В инциденте с Kaseya VSA в том же 2021 году (Kaseya VSA — IT-платформа для удалённого мониторинга и управления, на которую опираются сервис-провайдеры (MSP, managed service providers) при обслуживании своих клиентов) шифровальщик распространялся через провайдеров услуг на их клиентов, включая бэкап-инфраструктуру. Стандартные конфигурации 3-2-1, в которых все копии подключены к сети, никакой защиты не дали.
Правило 3-2-1-1-0: современный стандарт
Обновлённая схема добавляет два критичных компонента:
- 3 — три копии данных.
- 2 — два разных типа носителей.
- 1 — одна копия вне основной площадки.
- 1 — одна копия, отключённая от сети, физически изолированная (air-gapped) или неизменяемая (immutable) — недоступная для шифровальщика.
- 0 — ноль ошибок, подтверждённых через автоматическое тестирование восстановления.
Четвёртая «1» — это и есть защита от шифровальщиков. Неизменяемый бэкап в объектном хранилище с WORM-защитой (Write Once Read Many — «записал один раз, читай сколько угодно») или физически изолированная лента, увезённая на хранение, не могут быть зашифрованы вредоносным ПО — в них в принципе нельзя ничего записать или удалить через сетевые процессы.
«Ноль ошибок» — не менее важный пункт. Непроверенный бэкап — это не бэкап. Автоматическое тестирование восстановления после каждого задания подтверждает, что бэкап действительно можно развернуть, ещё до того, как он вам реально понадобится.
Как реализовать правило 3-2-1-1-0
Копия 1: Локальный бэкап на диске
Быстрый, доступный, используется для повседневных восстановлений. Должен лежать на выделенном бэкап-репозитории — не на том же сервере, что продакшн-данные. RPO (Recovery Point Objective — целевая точка восстановления, то есть максимальный допустимый объём данных, который можно потерять, выраженный во времени) в 15–60 минут достижим за счёт ежечасных инкрементальных заданий.
Копия 2: Вторичный бэкап на другом носителе или площадке
Задание копирования бэкапа (backup copy job) во второй репозиторий — на другое железо, на резервную площадку или в облачное объектное хранилище. Защищает от отказа локальной инфраструктуры.
Копия 3: Удалённая (offsite) или облачная копия
Третья копия — в географически отдельной локации. Это ваша копия для аварийного восстановления, она используется, когда основная площадка недоступна. Облачное объектное хранилище (Azure Blob, AWS S3) с включённым версионированием — хороший вариант.
Прим. перев. Для российских пользователей замечание про Azure Blob и AWS S3 в этом месте имеет один важный нюанс: с 2022 года прямой доступ к этим сервисам из РФ затруднён, многие функции (включая часть платных тарифов и ряд регионов) ограничены или недоступны. Использовать их в качестве удалённого хранилища для бэкапов сейчас — это либо серые схемы, либо повышенный риск того, что в нужный момент вы не получите доступ к собственным резервным копиям. Для российской инфраструктуры разумнее смотреть в сторону локальных провайдеров S3-совместимого объектного хранилища или просто арендовать сервер у локального облачного провайдера и поднять на нём собственное хранилище для бэкапов.
От Cloud4Y. Один из вариантов локального решения для удалённой копии — у нас. Сейчас для читателей Хабра идёт акция: новым клиентам — скидка 20% на аренду облачных серверов для бизнеса по промокоду HABR20. Серверы размещаются в ЦОД уровня TIER III, SLA — 99,982%, можно взять готовую конфигурацию или собрать машину под задачу. Условия — на странице акции. На таком сервере удобно поднять собственное хранилище для бэкапов — и закрыть третий пункт правила 3-2-1 без зависимости от иностранных гиперскейлеров.
Неизменяемая копия (новая «1»)
Настройте облачный репозиторий с включённой защитой object lock / WORM. Большинство крупных облачных провайдеров эту функцию поддерживают. Альтернативный вариант — лента, физически вывезенная за пределы площадки и отключённая от сети: она тоже считается air-gapped. Ключевое свойство такой копии: её нельзя ни изменить, ни удалить никаким сетевым процессом, включая ваше собственное программное обеспечение для резервного копирования и админские учётные записи.
Верификация (тот самый «0»)
Автоматизируйте тестирование восстановления после каждого бэкап-задания. Минимум — проверить, что файл бэкапа читается и контрольная сумма совпадает. Идеально — поднять бэкап в изолированной песочнице и убедиться, что приложение в нём корректно стартует. Делать это нужно автоматически, а не вручную.
3-2-1 для Microsoft 365: пробел, который у вас, скорее всего, есть
Большинство организаций реализуют 3-2-1-1-0 для собственной (on-prem) инфраструктуры и забывают, что Microsoft 365 — это отдельная поверхность данных, требующая такого же отношения.
Модель разделённой ответственности у Microsoft сформулирована явно: Microsoft защищает платформу, клиенты защищают свои данные. Встроенные в Microsoft 365 политики хранения и история версий — это не бэкапы. Они не защищают от:
- Шифровальщика, добравшегося до содержимого SharePoint и OneDrive через клиенты с включённой синхронизацией.
- Случайного или злонамеренного массового удаления в течение срока хранения.
- Потери данных через сторонние интеграции с правом записи.
Применить 3-2-1-1-0 к среде Microsoft 365 означает наладить автоматизированный бэкап Exchange Online, SharePoint, OneDrive, Teams и других сервисов по заданным политикам, с неизменяемым хранилищем и проверяемым восстановлением. AvePoint Cloud Backup закрывает это для всей поверхности Microsoft 365.
Лучшие практики правила 3-2-1-1-0
- Тестируйте восстановление по расписанию — минимум ежемесячно, ежеквартально проводите проверку полного восстановления на уровне приложений.
- Активно мониторьте статусы заданий — самые опасные сбои — тихие: задание, завершившееся с ошибками, но не пойманное мониторингом, оставляет вас уязвимыми.
- Разделяйте админские учётные записи бэкапа и продакшна — злоумышленники, идущие за бэкапами, часто используют скомпрометированные учётные записи доменного администратора.
- Включайте immutability на уровне хранилища, а не только приложения — блокировки на уровне приложения часто можно обойти с правами администратора.
- Документируйте порядок восстановления — правило 3-2-1-1-0 говорит, как хранить данные, но не как их восстанавливать; сценарий аварийного восстановления (DR-runbook) нужен отдельно.
- Распространите подход на SaaS — Microsoft 365, Salesforce и другие облачные платформы требуют той же бэкап-дисциплины, что и собственная инфраструктура.
Часто задаваемые вопросы
Что означает правило 3-2-1?
Правило 3-2-1 означает: три копии данных, два разных типа носителей, одна копия вне основной площадки. Это базовая стратегия резервного копирования для защиты от аппаратных сбоев, локальных катастроф и повреждения данных.
Актуально ли правило 3-2-1 сегодня?
Да, но оно обновилось до 3-2-1-1-0, чтобы отвечать на угрозы со стороны шифровальщиков. Изначальное правило не учитывало, что злоумышленники целенаправленно идут за подключённой к сети бэкап-инфраструктурой. Дополнительная «1» (неизменяемая или отключённая от сети копия) и «0» (проверенные бэкапы) этот пробел закрывают.
Что такое неизменяемый бэкап?
Неизменяемый бэкап — это копия данных, которую нельзя модифицировать, перезаписать или удалить в течение заданного периода, даже из-под административных учётных записей. Чаще всего это объектное хранилище с WORM-защитой (например, AWS S3 Object Lock или неизменяемое хранилище в Azure Blob). Ещё один вариант — физически изолированная (air-gapped) лента.
Как правило 3-2-1 применять к Microsoft 365?
Данные в Microsoft 365 требуют такой же бэкап-дисциплины, как и данные в собственной инфраструктуре. Microsoft не предоставляет детального резервного копирования с восстановлением на точку во времени для нагрузок Microsoft 365. Чтобы покрыть Exchange Online, SharePoint, OneDrive и Teams по схеме 3-2-1-1-0, нужно отдельное стороннее решение.
В чём разница между 3-2-1 и 3-2-1-1-0?
Изначальное правило 3-2-1 фокусируется на избыточности и хранении копии вне основной площадки. Обновлённое 3-2-1-1-0 добавляет неизменяемую или отключённую от сети копию (защита от шифровальщиков) и автоматизированную проверку восстановимости (гарантия целостности бэкапа). Эволюция была вызвана атаками шифровальщиков, которые продемонстрировали уязвимость архитектур, в которых все бэкапы подключены к сети.
Как часто должны запускаться бэкапы, чтобы соответствовать 3-2-1-1-0?
Частота резервного копирования определяется RPO (целевой точкой восстановления), а не самим правилом 3-2-1-1-0. Для критичных систем может потребоваться непрерывная защита данных или ежечасные инкременты. Правило 3-2-1-1-0 определяет, сколько копий и где они должны быть; RPO определяет, как часто они создаются.
Заключение
Правило 3-2-1 заложило фундамент современной стратегии защиты данных. Обновление 3-2-1-1-0 закрывает пробел в защите от шифровальщиков. Три копии, два носителя, одна удалённая, одна неизменяемая, ноль непроверенных бэкапов — внедрите все пять компонентов и получите бэкап-архитектуру, которая одновременно защищает от аппаратного сбоя, региональной катастрофы и целевой атаки шифровальщика.
И не забывайте, что Microsoft 365 (а в более широком смысле — любые SaaS-сервисы, где хранятся ваши бизнес-данные) должны быть внутри этой схемы, а не за её пределами. Это уже не вспомогательная среда, а место, где хранится большая часть данных компании, и дисциплина в отношении этих данных должна быть той же, к которой вы привыкли в собственной инфраструктуре.-Источник
|
