Как хранить бэкапы в S3, чтобы их не удалил сбой или вирус

По данным лаборатории цифровой криминалистики F.A.C.C.T., в 2024 году количество атак программ-вымогателей выросло на 44% по сравнению с предыдущим годом. Во время атаки скомпрометированные учётные записи могут дать злоумышленнику доступ в том числе к системе резервного копирования и самому хранилищу. Если эти записи разрешают изменять и удалять копии, компания теряет точки восстановления вместе с рабочими данными. К такому же результату может привести неправильная настройка или сбой сценария автоматического удаления.

Где резервная копия теряет защиту

Копия в доступном для записи хранилище зависит от выданных пользователям и приложениям прав. Получив подходящие реквизиты доступа, злоумышленник может удалить объекты, перезаписать их или изменить настройки хранения.

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

Быстрая синхронизация снижает RPO, то есть допустимый объём потери данных. Одновременно сокращается время, за которое команда может заметить заражение до записи данных на резервной площадке. Для восстановления нужна история версий, защищённая от изменений после записи.

Как Object Lock сохраняет версии

Object Lock реализует модель WORM, Write Once, Read Many. Записанную версию объекта нельзя изменить или удалить до окончания установленного срока. Подробно эта механика описана в документации Amazon Web Services S3.

Object Lock работает вместе с версионированием. При записи объекта под существующим ключом хранилище создаёт новую версию, а защищённая версия сохраняется. Если для бакета задано правило удержания по умолчанию, оно применяется к новым версиям автоматически. Без такого правила срок удержания нужно устанавливать для каждой версии объекта отдельно.

Само включение Object Lock ещё не защищает записанные объекты. После этого необходимо настроить retention для отдельных версий или для всех новых версий, попадающих в бакета. Примеры обеих конфигураций приведены в базе знаний Linx Cloud.

При обычном запросе на удаление S3 может создать delete marker. Объект перестанет отображаться как текущий, но его заблокированная версия сохранится. Для восстановления потребуется выбрать нужную версию или удалить маркер. Поведение delete marker при включённом Object Lock разобрано в документации AWS.

Как выбрать режим удержания

Object Lock поддерживает два режима:

• Governance: защищённую версию может удалить пользователь с разрешением s3:Bypass Governance Retention, если он явно запросит обход защиты. Это разрешение следует отделить от повседневных административных и резервных учётных записей.
• Compliance: защищённую версию нельзя удалить до окончания срока удержания, включая действиями root-пользователя. Режим также запрещает сокращать уже установленный срок.

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

Как рассчитать срок хранения

Правило 3-2-1 определяет структуру резервирования: три копии данных, два типа носителей и одна копия за пределами основной площадки. Такое определение приводит CISA в рекомендациях по резервному копированию. Глубина истории рассчитывается отдельно.

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

При отсутствии собственной статистики архитекторы Linx Cloud рекомендуют рассматривать 30 дней как начальный ориентир. Затем срок корректируют с учётом частоты копирования, времени обнаружения инцидентов, внутренних регламентов и результатов тестовых восстановлений. Если компания может обнаружить компрометацию позже, историю увеличивают.

Увеличение срока влияет на стоимость: заблокированные версии занимают место и не могут быть удалены правилами жизненного цикла до окончания retention. Расчёт должен учитывать объём ежедневных изменений и количество создаваемых версий.

Что проверить перед восстановлением

Object Lock сохраняет записанную версию, но не проверяет её содержимое. Если заражённые данные попали в копию до блокировки, хранилище сохранит их вместе с остальными объектами.

Шифрование может начаться спустя некоторое время после проникновения. Поэтому точку восстановления выбирают раньше самого раннего обнаруженного признака компрометации.

Перед восстановлением:

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

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

Бэкапы Шрёдингера

Народная мудрость гласит: “Если никто не проверяет бэкапы, они одновременно существуют и не существуют. Чаще всего — второе.”

Чтобы минимизировать вероятность неудачного боевого восстановления, рекомендуется регулярно проверять, что восстановить данные из бэкапов возможно, и после восстановления они пригодны для использования. Рекомендации CISA также предусматривают регулярную проверку доступности и целостности резервных копий.

Как часто надо проверять? Чем чаще, тем лучше.

Идеальный вариант — сразу после завершения создания резервной копии. Да, это непросто в настройке (хотя некоторые СРК умеют в автоматическую проверку), да, это затратно с точки зрения ресурсов и стоимости исходящего трафика (если он есть в тарифе). Но все эти недостатки нивелируются максимальным снижением риска, что в час X что-то пойдёт не так.

Компромиссный вариант — восстанавливаться из резервных копий хотя бы раз в месяц. Так получится выявить системные ошибки в архитектуре, баги ПО, недоработки в самом процессе восстановления да и сверится с целевой скоростью восстановления (RTO) поможет.

Как сервисы Linx Cloud участвуют в этой схеме

В Linx Cloud задачи хранения, создания копий и аварийного запуска инфраструктуры разделены между разными сервисами.

Объектное хранилище S3 поддерживает версионирование и Object Lock. Режим Governance или Compliance, а также срок удержания задаются для отдельных объектов или всего бакета. А вариант тарификации без дополнительной оплаты за исходящий трафик позволит на регулярной основе тестировать восстановление, не боясь переплатить за трафик.

Резервное копирование для бизнеса используется для создания и хранения копий виртуальных машин, серверов и баз данных.Аварийное восстановление (DRaaS) отвечает за максимально быстрый запуск инфраструктуры на резервной площадке при аварии. Набор сервисов зависит от требуемой глубины хранения, времени восстановления и устройства основной инфраструктуры.

Порядок действий во время атаки шифровальщика отдельно разобран в материале Linx Cloud «Киберсхватка: как действовать во время атаки вируса-шифровальщика».

Что должно быть настроено

Object Lock добавляет к резервному копированию защищённую историю версий. Для её использования нужно назначить срок удержания с учётом времени обнаружения атаки, отделить право обхода Governance от рабочих учётных записей и регулярно проверять восстановление в изолированной среде. После ошибочного удаления или шифрования команда сможет выбрать версию, записанную до начала инцидента.