Сегодня злоумышленники первым делом атакуют резервные копии. Как построить архитектуру резервного копирования, которая действительно выдержит атаку вымогателей: правило 3-2-1-1-0, неизменяемое хранилище, раздельное управление учетными записями и регулярная проверка восстановления.
Классический сценарий атаки программ-вымогателей изменился. Проникнув в инфраструктуру, злоумышленники больше не шифруют файлы сразу. Сначала они находят систему резервного копирования, удаляют или шифруют резервные копии и только потом переходят к рабочей среде. Компания, оставшаяся без резервных копий, вынуждена выбирать между выплатой выкупа и восстановлением с нуля, которое может занять месяцы. Поэтому фразы «у нас есть бэкапы» недостаточно — важно, переживут ли эти резервные копии атаку.
Что такое неизменяемая резервная копия?
Неизменяемую резервную копию никто не может удалить, зашифровать или перезаписать до истечения срока ее хранения. «Никто» включает и учетные записи администраторов. Даже если злоумышленник захватит учетную запись с наивысшими привилегиями, он не сможет повлиять на эти копии. Такой подход также называют WORM (Write Once, Read Many — «однократная запись, многократное чтение»).
Способы обеспечить неизменяемость
- Блокировка объектов (S3 Object Lock): в S3-совместимом хранилище каждому объекту назначается срок хранения. В режиме «compliance» никто не может удалить объект до окончания срока; в режиме «governance» это могут сделать учетные записи со специальными привилегиями. Для защиты от вымогателей правильный выбор — режим compliance.
- Защищенный Linux-репозиторий: выделенный сервер-репозиторий, использующий функцию неизменяемости ПО резервного копирования, с отключенным SSH и одноразовыми учетными данными (распространенный пример — Veeam Hardened Repository).
- Офлайн-копия (air gap): ленты или носители, физически отключенные от сети. Медленно, зато недоступно для злоумышленника, находящегося в сети.
- Управляемое внешнее резервное копирование: копия ваших резервных копий, которую поставщик хранит в неизменяемом виде независимо от вашей инфраструктуры учетных записей.
Правило 3-2-1-1-0
Классическое правило 3-2-1 в эпоху программ-вымогателей дополнилось еще двумя пунктами:
- 3 копии данных (включая рабочие)
- 2 разных типа носителей
- 1 копия в другом месте
- 1 неизменяемая или офлайн-копия
- 0 ошибок: резервные копии с проверенным восстановлением
Разделение учетных записей: самый недооцененный шаг
Если сервер резервного копирования входит в корпоративный домен Active Directory, злоумышленник, захвативший учетную запись администратора домена, получает доступ и к консоли резервного копирования. Поэтому:
- Не включайте инфраструктуру резервного копирования в домен; используйте отдельные локальные учетные записи.
- Обязательно включите многофакторную аутентификацию для доступа к консоли и репозиторию.
- Вынесите сеть резервного копирования в отдельный сегмент; сделайте консоль недоступной из интернета.
- Требуйте второго подтверждения (принцип «четырех глаз») для таких действий, как удаление резервных копий или сокращение срока хранения.
Выберите правильный срок хранения
Злоумышленники нередко проводят в инфраструктуре дни и даже недели, прежде чем начать шифрование. Если срок неизменяемого хранения короче, вы можете не найти чистую точку восстановления. Практичная отправная точка: не менее 30 дней неизменяемого хранения для ежедневных копий плюс еженедельные и ежемесячные копии сверх того. Чем дольше срок хранения, тем выше затраты на хранилище; найдите баланс, задав более длительные сроки для критически важных систем и более короткие — для остальных.
Нет проверки восстановления — нет резервной копии
- Не реже раза в квартал проводите полную проверку восстановления критически важных систем и замеряйте, сколько времени она занимает.
- Перед восстановлением проверяйте резервные копии на вредоносное ПО — вы же не хотите восстановить бэкдор, внедренный до шифрования.
- Задокументируйте, в каком порядке восстанавливаются системы (сначала учетные записи и DNS, затем базы данных, потом приложения).
Типичные ошибки
- Хранение резервных копий в той же системе хранения или в той же сетевой папке, что и рабочие данные
- Восприятие снапшотов как резервных копий
- Отсутствие обновлений ПО резервного копирования и операционной системы репозитория
- Оповещения о сбоях резервного копирования никто не отслеживает
- Нет четкого плана, кто и что делает во время атаки
CloudRUX Backup as a Service (BaaS)
С CloudRUX BaaS вы можете хранить копию своих резервных копий в дата-центрах в Турции — независимо от вашей собственной среды и инфраструктуры учетных записей. Наши инженеры помогут определить срок неизменяемого хранения, организовать проверки восстановления и разработать план восстановления после атаки вымогателей. Чтобы получить оценку, напишите нам на info@cloudrux.com.