Журнал "Information Security/ Информационная безопасность" #4, 2026

Неизменяемые и изолированные копии Один из заметных трендов последних лет – закрепление в тактиках и техниках операторов шифровальщиков действий, направленных на уничтожение возмож- ностей восстановления. Получив необходимые привилегии, атакующие пытаются удалить или изменить резерв- ные копии и снапшоты, отключить меха- низмы восстановления и политики резервного копирования. В MITRE ATT&CK такие действия относятся к тех- нике T1490 Inhibit System Recovery в рамках тактики Impact. Ее смысл – лишить организацию штатных средств восстановления после атаки: злоумыш- ленник может удалять или повреждать резервные копии и снапшоты, отклю- чать службы восстановления, изменять конфигурацию или политики резервного копирования. В результате даже при сохранении части инфраструктуры доступ к точкам восстановления может оказаться заблокирован, что существен- но усложняет или делает невозможным возврат систем к рабочему состоянию. И это не теория – согласно исследо- ваниям, в прошлом году в девяти из десяти случаев злоумышленники целе- направленно атаковали репозитории резервного копирования, причем при- мерно в 40% случаев им удавалось изменить или удалить хранящиеся там данные. Расчет понятен: если пригодная для восстановления резервная копия сохранилась, последствия шифрования основной инфраструктуры будут значи- тельно меньше. Из-за этого меняются требования к архитектуре хранения резервных копий. Если репозиторий постоянно доступен из производственного контура и управ- ляется теми же учетными записями, компрометация привилегированной УЗ может открыть атакующему доступ сразу и к продуктивным данным, и к средствам их восстановления. Поэтому недостаточно просто иметь дополни- тельную копию – она должна пережить атаку даже в том случае, если зло- умышленник уже получил высокие при- вилегии. Для этого используют два дополняю- щих друг друга подхода – неизменяе- мость и изолированное хранение. Неизменяемость (Immutability) озна- чает, что записанную резервную копию в течение заданного периода нельзя изменить или удалить штат- ными средствами, даже с админи- стративными правами в системе резервного копирования. Для этого, например, используют WORM-меха- низмы (Write Once, Read Many): дан- ные можно читать, но нельзя переза- писать или удалить до окончания срока хранения. В объектных S3- совместимых хранилищах ту же зада- чу решает Object Lock, который запре- щает изменение и удаление объектов на заданный период. Аналогичные механизмы могут работать и на уров- не СХД. В любом случае смысл один: даже если атакующий получит доступ к системе резервного копирования или ее административным учетным записям, уже созданные точки вос- становления должны сохраниться. Изоляция решает другую задачу – делает резервную копию максимально недоступной из скомпрометированной среды. Самый наглядный пример – физический воздушный зазор, напри- мер картридж, выгруженный из лен- точной библиотеки. Но изоляция может быть и логической: отдельный контур хранения с собственными учетными записями и административным доме- ном, сетевой сегментацией, независи- мым аккаунтом или площадкой. MITRE ATT&CK для защиты от T1490 рекомендует хранить копии вне исходной системы, а в облачной среде – в том числе использовать другие учетные записи или регионы. CISA также реко- мендует офлайн-копии критичных дан- ных и механизмы неизменяемых хранищ и Object Lock там, где они доступны. Эти подходы важно не отождествлять. Неизменяемая копия не обязательно изолирована, а изолированная – не обязательно неизменяема. Например, WORM может защитить данные в онлайн-репозитории от удаления, но сам репозиторий по-прежнему остается доступен из сети. И наоборот, копия в отдельном сегменте может быть недо- ступна из основной инфраструктуры, но оставаться уязвимой при компроме- тации учетной записи, которая ею управляет. Поэтому надежнее сочетать оба механизма и разделять контуры управления. Такая логика появляется и в рос- сийских СРК. Например, в RuBackup 3.0 1 в рамках одной стратегии можно создавать резервную копию сразу в двух независимых файловых пулах. Для S3 предусмотрено размещение копий в отдельных бакетах, а при работе с ленточными библиотеками можно использовать съемные носите- ли и выгружать картриджи, физически выводя копию из онлайн-контура. Однако важно понимать, что второй пул или отдельный S3-бакет еще не делают копию неизменяемой или изо- лированной. Разделение данных нужно дополнять возможностями хра- нилища, сетевой сегментацией и раз- делением административных полно- мочий. Архитектуру стоит строить так, чтобы компрометация одного контура управления не давала атакующему доступ сразу ко всем резервным копиям. 34 • СПЕЦПРОЕКТ Три тренда в области систем резервного копирования т СРК ждут уже не только надежного создания копий и соблюдения RPO и RTO, но и защиты инфраструктуры резервного копирования, автоматизации и глубокой интегра- ции с ИТ-ландшафтом. На российском рынке к этому добав- ляется переход от быстрого импортозамещения к более осо- знанному выбору технологий. На этом фоне особенно замет- ны три тренда, которые мы рассмотрим более внимательно. О Андрей Кузнецов, генеральный директор "Рубэкап" Фото: Рубэкап 1 https://www.rubackup.ru/