Иммутабельные бэкапы: как защитить резервные копии от удаления и подмены

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

Зачем нужна неизменяемость, если бэкап и так есть?

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

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

Как технически устроена защита от изменения?

Чаще всего иммутабельность реализуется на уровне хранилища, а не приложения. Система хранения помечает файл как «write once, read many» — записать один раз, читать сколько угодно, изменить или стереть нельзя. Такая логика встроена в саму файловую систему или объектное хранилище, и обойти её через интерфейс управления или консоль не получится: запрет действует на самом низком уровне.

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

Чем это отличается от обычного запрета на удаление в настройках?

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

Как это помогает при атаке шифровальщика?

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

Нужно ли защищать иммутабельностью абсолютно все данные?

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

На что смотреть при выборе хранилища с поддержкой immutable-бэкапов?

Стоит обратить внимание на несколько моментов:

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

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

А если данные всё же нужно удалить раньше срока — например, по требованию закона?

Это действительно частый вопрос, особенно у компаний, которые работают с персональными данными и обязаны соблюдать сроки хранения по 152-ФЗ. Решение — заранее продумывать срок неизменяемости под конкретный тип данных и требования законодательства, а не ставить один универсальный период на всё. Для данных с ограниченным сроком хранения задаётся более короткий период иммутабельности, для стратегически важных архивов — более длинный. Грамотное планирование политики хранения на старте избавляет от ситуации, когда нужно удалить данные, а технически это невозможно.

С чего начать компании, у которой пока обычное резервное копирование?

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