Immutable-снапшоты и офлайн-хранилище: архитектура бекапа после WannaCry

Среди всех вопросов, которые прилетели к нам после 12 мая, один звучал чаще остальных: «у нас были бекапы, но WannaCry добрался и до них - что не так с нашей схемой?». Ответ в большинстве случаев одинаковый: бекапы были доступны по сети как обычная шара, и для шифровальщика это неотличимо от обычного сетевого диска.

Это не баг в конкретном бекап-продукте. Это архитектурная проблема: если бекап-хранилище постоянно примонтировано к продакшн-хосту или доступно без дополнительного слоя защиты - оно уязвимо ровно так же, как и сами данные.

Где именно ломается типичная схема

Классическая схема небольшой компании выглядит так: Windows-агент собирает бекап на сетевую шару \\backup-server\backups, где хранятся файлы за последние 30 дней. Агент работает постоянно, шара примонтирована или доступна через UNC-путь. WannaCry запускается на рабочей станции, перебирает доступные сетевые ресурсы и шифрует всё, до чего дотягивается - включая 30 дней бекапов.

Схема с Veeam или аналогичным продуктом на Windows-сервере с CIFS-репозиторием ломается примерно так же, если репозиторий открыт как шара и агент работает от учётной записи с доступом к ней.

Три точки, в которых архитектура разваливается:

• Постоянное подключение к хранилищу. Шара или диск с бекапами доступны 24/7, никакого окна «только во время бекап-задания».
• Нет иммутабельности. Файлы бекапов - обычные файлы, их можно перезаписать, удалить, зашифровать с теми же правами, которые нужны для записи.
• Один контекст безопасности. Та же учётная запись, тот же домен, то же доверие, что и у продакшн-хостов.

Архитектура, которая это решает

Мы прошлись по нашим managed-клиентам после WannaCry и проверили, где что нужно доделать. Общая схема, к которой пришли, строится на трёх принципах.

Offline-хранилище как последний рубеж. Хотя бы одна копия должна быть недоступна по сети вообще. Это может быть ленточная библиотека (LTO-6/7 сейчас вполне живые), съёмные диски по ротации, или отдельный хост, который не в домене и принимает данные только по push от изолированного бекап-сервера - но сам ни к чему не подключается. Модель «write-only с одной стороны, read-only с другой» здесь важна принципиально.

Immutable snapshots на уровне хранилища. Если вы на Linux - ZFS и его zfs snapshot + zfs hold. Снапшоты защищены от удаления через hold, и агент, у которого скомпрометирован доступ к данным, не может их удалить без отдельного набора прав на сам ZFS-хост. Для тех, кто на Veeam с Scale-Out Backup Repository, - логика похожая, но это уже про другой масштаб.

На практике схема выглядит так:

продакшн-хост -> бекап-агент (push) -> бекап-сервер (Linux/ZFS)
                                              |
                             zfs snapshot ежедневно
                             zfs hold на 30 дней
                                              |
                             еженедельный export на offline-носитель

Ключевое: бекап-сервер не в домене Windows, не монтирует ничего обратно на продакшн, агент работает от выделенной учётки с минимальными правами.

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

Минимальный регламент, который мы сейчас рекомендуем для управляемой инфраструктуры:

• проверка статуса заданий ежедневно (алерт на failure, не только ручной просмотр)
• тестовое восстановление одного случайного элемента раз в месяц
• полный тест восстановления критичного сервера раз в квартал с измерением реального RTO

«Реального» - потому что цифры в документе и цифры в реальности расходятся регулярно.

Права и изоляция

Отдельно про учётные записи. Типичная ситуация: бекап-агент работает от domain admin или от учётки с правами локального администратора на всех хостах - «чтобы точно всё бекапилось». При компрометации такой учётки через шифровальщик или вручную - у атакующего оказываются права на все хосты сразу.

Минимально разумная схема: выделенная бекап-учётка с правами ровно на те объекты, которые нужно бекапить, без прав на удаление или запись в репозиторий с продакшн-хостов. Push-модель, где инициатива всегда от бекап-сервера, а не от агентов на хостах - это дополнительный барьер.

Где мы сейчас

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

За последнюю неделю мы прошлись по нескольким клиентам и начали переводить их хранилища на ZFS с ротацией снапшотов. Это не быстро и не делается за один вечер - нужно спланировать migration окно, проверить объём данных, настроить мониторинг нового репозитория. Но делать это лучше сейчас, пока атака только что произошла и всем очевидна проблема, а не потом, когда всё забудется.

Следующий шаг, который мы планируем - описать конкретный рецепт ZFS-репозитория с holds и ротацией, который можно взять и развернуть. Пока это внутренний плейбук - оформим отдельным постом, как только устаканится.