Правило 3-2-1-1-0 и требования страховщиков: пересматриваем схемы резервного копирования клиентов

Несколько клиентов в январе-феврале получили письма от страховщиков с одинаковым смыслом: чтобы продлить полис киберстрахования или получить новый, нужно предоставить документальное подтверждение схемы резервного копирования. Причём не просто «бэкапы есть», а конкретно: наличие неизменяемых (immutable) копий, изолированного хранилища и задокументированных процедур восстановления с реальными результатами тестирования.

Это не самодеятельность конкретного андеррайтера. После Colonial Pipeline в мае 2021 и последовавшей волны REvil требования к backup-инфраструктуре стали частью стандартных опросников большинства страховщиков, работающих с киберрисками. Раньше хватало общих слов про «регулярное резервное копирование». Теперь хотят технические детали.

Откуда взялось 3-2-1-1-0

Правило 3-2-1 - старое и всем известное: 3 копии данных, на 2 разных типах носителей, 1 из них вне площадки. Долгое время это считалось достаточным.

Ransomware изменил картину. Шифровальщик, который работает в инфраструктуре несколько недель до активации, успевает добраться до примонтированных сетевых хранилищ, до NFS/SMB-шар с бэкапами, до агентов резервного копирования с широкими правами. Классическое 3-2-1 против этого не работает, если все три копии доступны из заражённой сети.

Расширение 3-2-1-1-0 добавляет два требования:

• +1 offline или air-gapped копия - носитель, физически отключённый от сети или среды, откуда может прийти атака. Tape, отключённый диск, object storage с заблокированной записью через политику.
• 0 ошибок при верификации - каждый бэкап проверяется на целостность и восстанавливаемость, и результат документируется. Не «мы проверяем», а логи проверки с датами и результатами.

Страховщики проверяют оба пункта. И именно здесь у большинства клиентов обнаружились пробелы.

Что нашли при аудите схем

Прошлись по нескольким клиентским конфигурациям в рамках managed-сопровождения. Картина предсказуемая, но всё равно неприятная.

Immutable storage отсутствует у большинства. Бэкапы хранятся в сетевых хранилищах или S3-совместимых хранилищах без включённого Object Lock или аналога. Технически они перезаписываемые - то есть ransomware, получив доступ с нужными правами, может их уничтожить или зашифровать.

Offline-копии есть, но не проверяются. У части клиентов есть tape или внешние диски, которые вывозятся офсайт. Хорошо. Но когда последний раз с них восстанавливали данные в тест-окружении? В нескольких случаях ответ был «не помним» или «давно». Это не бэкап - это надежда.

Документация не ведётся или ведётся формально. Регламент есть, но в нём написано «бэкап делается ежедневно» без указания, что конкретно бэкапируется, в какое хранилище, с каким retention, кто отвечает за проверку и что считается успешным результатом. Такой документ для страховщика бесполезен.

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

Что приводим в порядок

Работа идёт по нескольким направлениям одновременно, и в зависимости от клиента конфигурация разная, но общая логика одна.

Включаем Object Lock там, где S3-совместимое хранилище. Если клиент использует MinIO, Ceph с S3-интерфейсом или облачный S3 - включаем WORM-режим (Write Once Read Many) с retention-периодом. После этого бэкап за период нельзя удалить или перезаписать даже с административными правами на уровне приложения. Это не защита от всего, но это именно то, что страховщики называют immutable backup.

Для тех, у кого нет S3, - tape или отключаемые диски с ротацией. Здесь важна схема ротации: одна копия всегда физически офлайн, не подключена к сети. Периодичность подключения для записи - минимально необходимая. Это дешевле, чем кажется, если уже есть инфраструктура.

Изолируем агенты резервного копирования. Переводим на выделенные сервисные аккаунты с минимально необходимыми правами. Доступ агента - только к тому, что он должен бэкапить, и только к тому хранилищу, куда пишет. Никакого domain admin.

Запускаем регулярные тесты восстановления с логированием. Не «убедиться что файлы есть», а поднять тест-окружение и восстановить в него реальные данные. Раз в квартал минимум, для критичных систем - чаще. Результат фиксируется: дата, что восстанавливалось, время восстановления, кто проверял, результат. Этот лог - часть документации для страховщика.

Про документацию для андеррайтера

Страховые опросники обычно запрашивают конкретный набор: схему резервного копирования (что, куда, как часто, retention), подтверждение наличия offline/immutable копии (не декларацию, а технические детали конфигурации), и историю тестирования восстановления за последние 12 месяцев.

Хорошая новость: если инфраструктура настроена правильно, документация собирается относительно легко - это выгрузки из конфигураций и логи. Плохая новость: если инфраструктура не настроена - никакая красиво написанная бумага ситуацию не спасёт. Андеррайтеры, которые специализируются на киберрисках, задают уточняющие технические вопросы и умеют отличать реальное от декларативного.

Где мы сейчас

Работа с несколькими клиентами ещё идёт - переход на immutable storage требует тестирования совместимости с конкретными версиями Veeam и проверки производительности записи через Object Lock. Не везде это быстро. Но базовая структура 3-2-1-1-0 у большинства уже выстраивается.

Наблюдение, которое хочется зафиксировать: страховщики оказались эффективнее регуляторов в части создания реального стимула для приведения backup-инфраструктуры в порядок. Регуляторные требования к резервному копированию существуют давно и в основном игнорировались как «галочка». Требование страховой компании перед выдачей полиса действует иначе - потому что за ним стоят деньги, а не абстрактный штраф когда-нибудь потом.