Резервные копии, которые выдерживают программы-вымогатели ── правило 3-2-1, хранилище без перезаписи и проверка восстановления

При атаках программ-вымогателей часто бывает так, что резервные копии были, а восстановиться всё равно не удалось. Самая частая причина в том, что резервные копии зашифровали вместе со всем остальным. В этой статье разбирается, как построить резервное копирование, которое выдерживает атаку, для ПК под Windows и файловых серверов малых и средних компаний.

Главных пунктов три: иметь одну копию, которую заражённый ПК не может перезаписать, не использовать «Предыдущие версии» вместо резервных копий и проверять, что восстановление действительно работает. Правило 3-2-1 определяет, сколько копий держать и где, но само по себе оставляет пробелы в защите от программ-вымогателей.

Команды в статье работают только в Windows; их вывод проверен в командной строке администратора в Windows Server 2022. Экраны настроек и цены продуктов могут меняться, поэтому при внедрении сверяйтесь с актуальной документацией каждого производителя.

Многие организации имели резервные копии, но не смогли восстановиться

Национальное полицейское агентство Японии опрашивает пострадавшие от программ-вымогателей организации о состоянии их резервных копий. В отчёте за первое полугодие 2025 года 51 из 53 ответивших организаций делали резервные копии. Однако из 48 организаций, которых спросили, удалось ли восстановиться из резервной копии до состояния непосредственно перед атакой, это удалось только 7, а 41 — нет¹.

Из 35 организаций, назвавших причину неудачи, 23 ответили «резервные копии тоже были зашифрованы», 8 — «недостатки в эксплуатации», 4 — «другое»¹. В том же отчёте сказано, что группировки вымогателей удаляют журналы и резервные копии пострадавших, чтобы замести следы и не дать восстановиться. Затем отчёт призывает хранить резервные копии в офлайн-среде².

flowchart TB
        accTitle: Как можно иметь резервные копии и не восстановиться
        accDescr: Схема показывает, что даже при наличии резервных копий они шифруются вместе со всем остальным, если доступны с заражённого ПК, а если процедура восстановления не проверена, восстановиться мешают недостатки в эксплуатации.
        A["Резервные копии делаются"] --> B{"Доступны с заражённого ПК?"}
        B -->|"Доступны"| C["Тоже зашифрованы или удалены"]
        B -->|"Недоступны"| D{"Процедура восстановления проверена?"}
        D -->|"Не проверена"| E["Не восстановиться из-за недостатков в эксплуатации"]
        D -->|"Проверена"| F["Восстановиться можно"]

Рис. 1: Резервные копии пригодны, когда заражённый ПК до них не дотягивается, а процедура восстановления проверена.

Бывают и удачные случаи. В 4-й редакции «Руководства по информационной безопасности для малых и средних предприятий» IPA описан случай строительной компании, у которой после проникновения через VPN-устройство зашифровали файловые серверы и другие системы. Отчасти благодаря тому, что компания дважды в год проводила учения по восстановлению, она вернула основные системы из резервных копий через пять дней после обнаружения атаки. Тем не менее возобновление работы каждой внутренней системы заняло 41 день, удалённого доступа — четыре месяца, а компания потеряла чуть больше 20 процентов своих внутренних файлов³. Возможность восстановиться из резервных копий не отменяет ущерба.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 13, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

Злоумышленники удаляют резервные копии, до которых могут дотянуться

В руководстве #StopRansomware Guide, которое выпускают CISA и другие ведомства США, сказано, что многие программы-вымогатели ищут доступные резервные копии и пытаются удалить или зашифровать их, чтобы без выкупа восстановиться было нельзя. Поэтому, по словам руководства, важно хранить резервные копии офлайн⁴.

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

• Внешние диски, постоянно подключённые к ПК
• Общие папки NAS или файлового сервера, подключённые как сетевой диск с буквой
• Папки облачной синхронизации, в которые может писать повседневная учётная запись
• Теневые копии («Предыдущие версии») на том же томе

Удалить теневые копии и каталоги резервных копий можно даже встроенными командами ОС. В MITRE ATT&CK этот приём описан как «Inhibit System Recovery» (T1490). Там приводятся примеры удаления всех теневых копий командой vssadmin.exe delete shadows /all /quiet и удаления каталога резервных копий Windows командой wbadmin.exe delete catalog -quiet⁶. Руководство CISA также призывает отслеживать подозрительное использование vssadmin.exe, wbadmin.exe, wmic.exe (shadowcopy) и подобных средств⁴.

flowchart TB
        accTitle: Резервные копии, до которых заражённый ПК может и не может дотянуться
        accDescr: Схема показывает, что заражённый ПК может писать на постоянно подключённые внешние диски, подключённые общие папки, папки синхронизации и теневые копии, но не может писать на отключённые носители и в хранилища, которые нельзя перезаписать.
        P["Заражённый ПК"] --> R["Места, куда он может писать"]
        P -.-x N["Отключённые носители, хранилища без перезаписи"]
        R --> A["Постоянно подключённый внешний диск"]
        R --> B["Подключённая общая папка"]
        R --> C["Папка облачной синхронизации"]
        R --> D["Теневые копии"]

Рис. 2: Резервные копии в местах, куда может писать заражённый ПК, становятся целью атаки.

Нужно остерегаться и атак, растянутых во времени. Microsoft пишет, что программа-вымогатель иногда шифрует данные постепенно, оставляя ключ в системе. Всё это время пользователи работают с данными как обычно, поэтому резервные копии уже зашифрованных данных незаметно накапливаются. Когда всё зашифровано и ключ удалён, прочитать нельзя даже свежие резервные копии⁵. Если хранить только последнее поколение, в таком случае откатиться будет некуда.

«Предыдущие версии» не заменяют резервные копии

«Предыдущие версии» Windows и теневые копии общих папок используют службу теневого копирования тома (VSS). Системный поставщик VSS, входящий в Windows, работает по принципу копирования при записи: перед перезаписью блока его содержимое сохраняется в разностную область, и так воспроизводится состояние тома на определённый момент⁷.

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

flowchart TB
        accTitle: Разница между теневыми копиями и резервными копиями
        accDescr: Схема показывает, что теневая копия — это разностные данные исходного тома, которые удаляются при нехватке места или злоумышленником, тогда как резервная копия, перенесённая на отдельный носитель, сохраняется даже при потере исходного тома.
        V["Исходный том"] --> S["Теневая копия (разность)"]
        S --> L["Удаляется от старых к новым при нехватке места"]
        S --> K["Удаляется злоумышленником через vssadmin"]
        S -->|"Перенос на отдельный носитель"| B["Резервная копия"]
        B --> R["Сохраняется даже при потере исходного тома"]

Рис. 3: Теневые копии зависят от данных исходного тома; резервной копией становится то, что перенесено на отдельный носитель.

Теневые копии удобны, чтобы пользователи сами возвращали файлы, перезаписанные по ошибке. Однако, как сказано в предыдущем разделе, злоумышленники иногда их удаляют. Устройство и эксплуатация подробно описаны в статье «Служба теневого копирования тома (VSS)».

Чтобы увидеть, какие теневые копии сохранились, выполните vssadmin list shadows в командной строке администратора. Эта подкоманда доступна и на клиентах, и на серверах⁸.

vssadmin list shadows

Журнал версий и корзина в OneDrive и SharePoint тоже позволяют пользователям вернуть файлы. Microsoft советует научить пользователей восстанавливать весь OneDrive на более ранний момент времени. Кроме того, Microsoft советует разрешать пользователям восстановление только тогда, когда вы уверены, что злоумышленник вытеснен, и подготовиться к случаю, когда пользователи вместе с файлами восстановят и вредоносную программу⁵.

Правило 3-2-1 определяет, сколько копий и где

Правило 3-2-1 — это эмпирическое правило о том, как держать копии резервных данных. Документ «Data Backup Options», подготовленный для US-CERT в 2012 году, объясняет его так⁹.

• 3: важных файлов должно быть три копии — оригинал и две резервные.
• 2: хранить их на двух разных типах носителей на случай разных видов бедствий.
• 1: одну копию держать вне дома или офиса.

В качестве источника документ называет книгу фотографа Питера Крога (Peter Krogh) об управлении цифровыми фотографиями «The DAM Book»⁹. Microsoft тоже приводит это правило в документации о резервном копировании для защиты от программ-вымогателей и описывает «1» как «внешнюю или холодную копию»⁵.

Правило 3-2-1 требует держать копию вне офиса. Оно не требует, чтобы эта внешняя копия была офлайн или защищена от перезаписи. Поэтому если внешняя копия лежит в облаке, куда заражённый ПК всегда может писать, её могут зашифровать вместе с локальными копиями. Руководство CISA и документация Microsoft называют офлайн-хранение мерой защиты от программ-вымогателей. Microsoft также называет хранилища, в которых данные нельзя перезаписать⁴⁵.

flowchart TB
        accTitle: Правило 3-2-1 и защита от программ-вымогателей
        accDescr: Схема показывает, что к правилу 3-2-1 — три копии, два типа носителей, одна вне офиса — добавляется одна офлайн-копия или копия без перезаписи, а затем проверяется возможность восстановления.
        A["Три копии"] --> B["Два типа носителей"]
        B --> C["Одна вне офиса"]
        C --> D["Одна офлайн или без перезаписи"]
        D --> E["Проверить, что восстановление работает"]

Рис. 4: К правилу 3-2-1 добавьте копию, которую заражённый ПК не может перезаписать, и проверку восстановления.

Производитель средств резервного копирования Veeam продвигает это под названием «правило 3-2-1-1-0». В документации Veeam дополнительная «1» означает одну копию офлайн, в изолированной среде (air gap) или без возможности перезаписи, а «0» — отсутствие ошибок при регулярной проверке восстановления¹⁰. Это название из документации производителя, а не официальный стандарт. Тем не менее два дополнительных пункта совпадают с тем, чего требуют CISA и IPA.

Держите одну копию, которую заражённый ПК не может перезаписать

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

Отключить носитель от ПК и хранить отдельно

В качестве примера меры для самооценки руководство IPA предлагает подключать устройства и носители для резервного копирования к ПК только на время создания копии. Там же названы определение порядка резервного копирования, хранение копий в безопасном месте и регулярная проверка возможности восстановления¹¹.

Для тех, кто подходит к делу основательнее, руководство называет «физическую изоляцию». Это хранение резервных копий в месте, физически удалённом от исходной системы: внешние накопители или ленты держат как можно дальше. В качестве мест хранения приводятся банковская ячейка, надёжный деловой партнёр или аффилированная компания¹².

Резервную копию, которая хранится отключённой от рабочих систем, называют офлайн-копией. Заражённый ПК не может писать на отключённый носитель. Зато подключать, отключать и перевозить носители приходится людям, поэтому копии забывают сделать или носитель забывают вывезти. Заранее определите, кто и когда подключает носитель, отключает его и отвозит в место хранения.

Использовать облачное хранилище без перезаписи

У облачных хранилищ есть функции, которые в течение заданного срока не дают перезаписать или удалить данные. Данные хранятся в состоянии, которое называют WORM (Write Once, Read Many).

В неизменяемом хранилище Azure Blob Storage после задания политики хранения на основе времени данные в течение этого срока можно создавать и читать, но нельзя изменять или удалять¹³. Политика сначала создаётся в разблокированном состоянии, а после проверки её блокируют. Заблокированную политику нельзя удалить, а срок хранения можно продлить, но нельзя сократить¹³. Microsoft поясняет, что изменить или удалить данные не могут даже пользователи с правами администратора учётной записи¹³.

У Amazon S3 Object Lock два режима. В режиме соответствия (compliance mode) никто, включая корневого пользователя учётной записи AWS, не может перезаписать или удалить версию объекта в течение срока хранения. В режиме управления (governance mode) изменять или удалять настройки хранения могут только пользователи с особыми правами¹⁴. Object Lock можно использовать только в бакетах с включённым управлением версиями S3¹⁴.

flowchart TB
        accTitle: Два примера хранилищ, которые нельзя перезаписать
        accDescr: Схема показывает, что в неизменяемом хранилище Azure Blob Storage заблокированную политику нельзя удалить и срок хранения нельзя сократить, а в S3 Object Lock в режиме соответствия удалить не может даже корневой пользователь, тогда как в режиме управления изменения возможны при особых правах.
        W["Хранилище без перезаписи"] --> AZ["Неизменяемое хранилище Azure Blob Storage"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["После блокировки срок нельзя сократить"]
        S3 --> C["Режим соответствия"]
        S3 --> G["Режим управления"]
        C --> C1["Не может удалить даже корневой пользователь"]
        G --> G1["Изменения возможны при особых правах"]

Рис. 5: Оба хранилища отклоняют перезапись и удаление в течение заданного срока; насколько строго — зависит от настроек.

В Azure, даже если ошибка в настройке обнаружится после блокировки политики, срок хранения сократить нельзя¹³. Руководство CISA, упоминая, что некоторые облачные провайдеры предлагают хранилища без перезаписи, предупреждает, что ошибка в настройке может обойтись очень дорого. Там также сказано, что такие хранилища могут не соответствовать требованиям отдельных регуляторов⁴. Если задать долгий срок хранения и заблокировать его, удалить данные в течение этого срока будет нельзя, и плата за хранение будет начисляться всё это время. Сначала проверьте всё без блокировки или с коротким сроком, убедитесь, что восстановление работает, и только потом применяйте рабочие настройки.

Разделите права на управление резервными копиями

Даже при использовании хранилища без перезаписи злоумышленник может изменить настройки и политики резервного копирования, если их можно менять повседневной учётной записью администратора. Microsoft рекомендует требовать дополнительный шаг, например многофакторную проверку подлинности или PIN-код безопасности, прежде чем онлайн-копии можно будет изменить или удалить. Также названы ограничение операций резервного копирования и восстановления пользователями в назначенных ролях и сокращение числа общих папок, в которые многие пользователи могут писать и в которых могут удалять файлы⁵.

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

Храните несколько поколений

Руководство IPA называет «управление поколениями» — хранение резервных копий на несколько моментов времени. Это позволяет при повреждении или потере данных вернуться к определённому моменту¹². Как сказано в одном из предыдущих разделов, если шифрование замечают не сразу, самые свежие резервные копии уже содержат зашифрованные данные. Сколько поколений хранить, определяйте исходя из того, сколько времени может пройти до обнаружения шифрования, и из стоимости хранения.

flowchart TB
        accTitle: Три меры, чтобы иметь копию без перезаписи
        accDescr: Схема показывает хранение отключённых носителей или использование хранилища без перезаписи, отделение прав на управление резервными копиями от повседневных учётных записей и хранение нескольких поколений.
        A["Копия, которую нельзя перезаписать"] --> B["Хранить отключённый носитель"]
        A --> C["Хранилище без перезаписи"]
        B --> D["Разделить права на управление"]
        C --> D
        D --> E["Хранить несколько поколений"]

Рис. 6: Определив место хранения, разделите права на управление и храните поколения, чтобы вернуться назад, даже если шифрование заметили поздно.

Проверяйте, что восстановление работает

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

Руководство IPA делит работу с резервными копиями на три части: создание, хранение и восстановление. Для восстановления оно требует составить план восстановления и убедиться, что восстановление проходит правильно³. Для систем, важных для бизнеса, руководство требует выстроить создание резервных копий и процедуры в соответствии с целевым временем восстановления (RTO) и целевой точкой восстановления (RPO) и проверять их действенность на учениях. RTO — это время, за которое нужно восстановиться до целевого уровня, а RPO — момент, на который выполняется восстановление, то есть время последней резервной копии¹⁵. Руководство CISA также требует с прицелом на аварийное восстановление регулярно проверять, что резервные копии доступны и не повреждены⁴.

flowchart TB
        accTitle: Как проводить тест восстановления
        accDescr: Схема показывает последовательность: определить порядок восстановления, восстановить в отдельную среду, сравнить затраченное время и точку восстановления с RTO и RPO и исправить инструкцию.
        A["Определить порядок восстановления"] --> B["Восстановить в отдельную среду"]
        B --> C["Сравнить затраченное время с RTO"]
        B --> D["Сравнить точку восстановления с RPO"]
        C --> E["Исправить инструкцию"]
        D --> E
        E -.->|"Следующая проверка"| A

Рис. 7: Попробуйте восстановиться, проверьте, укладываются ли время и точка в цели, и внесите результаты в инструкцию.

Что проверять

По документам IPA и Microsoft проверяемое можно свести к следующему.

Microsoft рекомендует сначала определить системы, критически важные для бизнеса, и регулярно делать их резервные копии. Получившийся список резервных копий по приоритету и становится порядком восстановления. Среди приоритетных Microsoft первыми называет системы аутентификации, например Active Directory, без которых нельзя войти ни в одну другую систему⁵. Также рекомендуется регулярно проводить учения по запуску бизнеса из состояния, когда остановлены все системы. При этом исходят из того, что электронная почта и чат тоже недоступны⁵.

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

Осторожность при восстановлении после атаки

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

flowchart TB
        accTitle: Порядок восстановления из резервной копии после атаки
        accDescr: Схема показывает удаление самой программы-вымогателя и пути проникновения, выбор резервной копии на момент без заражения, проверку её на вредоносные программы и восстановление начиная с систем с наивысшим приоритетом.
        A["Удалить саму программу-вымогатель"] --> B["Выяснить путь проникновения и оставленное"]
        B --> C["Выбрать момент без заражения"]
        C --> D["Проверить резервную копию"]
        D --> E["Восстанавливать начиная с наивысшего приоритета"]

Рис. 8: После атаки уберите то, что оставили злоумышленники, и убедитесь, что выбранный момент был без заражения, прежде чем восстанавливаться.

Как часто проверять

И руководство IPA, и руководство CISA требуют «регулярно» проверять, что восстановление возможно, но не называют конкретного числа¹¹⁴. Компания из случая IPA, о котором говорилось выше, проводила учения по восстановлению дважды в год³. Определите, как долго бизнес может простаивать и насколько старой может быть точка восстановления, и проверяйте с такой частотой, которая позволяет убедиться, что эти цели выполняются.

Что решить в первую очередь

Сведём сказанное к тому, что малой и средней компании нужно решить в первую очередь.

flowchart TB
        accTitle: Порядок решений о резервных копиях, выдерживающих программы-вымогатели
        accDescr: Схема показывает порядок: определить объём, определить места хранения копий и копию без перезаписи, определить права и поколения, определить RTO и RPO и проверить, что восстановление работает.
        A["Определить объём"] --> B["Определить места хранения копий"]
        B --> C["Определить копию без перезаписи"]
        C --> D["Определить права и поколения"]
        D --> E["Определить RTO и RPO"]
        E --> F["Проверить, что восстановление работает"]

Рис. 9: Решайте всё одной последовательностью — от объёма до заключительной проверки восстановления.

В 4-й редакции руководства IPA к «пяти правилам информационной безопасности», с которых организации начинают, добавили пункт «Делайте резервные копии!», и правил стало шесть¹⁶. Как работать с руководством в целом, описано в статье «С чего малому и среднему бизнесу начать информационную безопасность». Если вы планируете замену серверов, посмотрите также «Preparing for Windows Server 2016 End of Support».

Похожие статьи

• С чего малому и среднему бизнесу начать информационную безопасность — редакция 4.0 руководства IPA
• Служба теневого копирования тома (VSS): как снимают резервную копию занятого файла
• Preparing for Windows Server 2016 End of Support

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

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

Услуги по этой теме

Эта статья ведёт к следующим страницам услуг. Начните с ближайшей к вашей задаче.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Если я делаю резервные копии, смогу ли я всё восстановить после заражения программой-вымогателем?

Часто одного наличия резервных копий недостаточно. В сводке Национального полицейского агентства Японии о случаях за первое полугодие 2025 года 41 из 48 ответивших организаций, которые делали резервные копии, не смогли восстановиться до состояния, бывшего непосредственно перед атакой. Самая частая причина — резервные копии тоже оказались зашифрованы. Нужна копия, которую заражённый ПК не может перезаписать, и нужно заранее убедиться, что из неё можно восстановиться.

Если в Windows есть «Предыдущие версии», нужны ли ещё резервные копии?

Нужны. «Предыдущие версии» — это теневые копии тома, то есть разностные данные на том же исходном томе. Microsoft считает резервной копией данные, перенесённые из теневой копии на носитель вроде ленты. Программы-вымогатели иногда удаляют теневые копии с помощью vssadmin и подобных средств, поэтому сочетайте их с резервными копиями на отдельных носителях.

Достаточно ли соблюдать правило 3-2-1, чтобы защититься от программ-вымогателей?

Иногда нет. Правило 3-2-1 требует трёх копий, двух типов носителей и одной копии вне офиса, но не требует, чтобы внешняя копия была офлайн или защищена от перезаписи. Облачная копия, в которую заражённый ПК всегда может писать, может быть зашифрована точно так же. Добавьте одну копию на отключённом носителе или в хранилище, где её нельзя перезаписать.

Как часто нужно проверять, что из резервных копий можно восстановиться?

И руководство IPA, и руководство CISA говорят «регулярно» и не называют конкретного числа. В руководстве IPA приводится случай, когда компания, дважды в год проводившая учения по восстановлению, вернула основные системы через пять дней после обнаружения атаки. Определите, как долго бизнес может простаивать и насколько старой может быть точка восстановления, и проверяйте с такой частотой, которая позволяет убедиться, что эти цели выполняются.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Работает в основном с разработкой ПО для Windows, техническими консультациями и поиском причин неисправностей; сильные стороны — проекты, где остаются существующие активы, и расследование сбоев, причину которых трудно увидеть.