Шифровальщик опасен для резервных копий не только тем, что зашифрованные файлы могут попасть в очередное задание. При серьезной компрометации злоумышленник ищет backup-сервер, сетевые хранилища, облачные кабинеты и учетные данные, чтобы удалить точки восстановления, сократить срок хранения или отключить задания до основной атаки.
Поэтому вопрос «сколько у нас копий» недостаточен. Важно понять, сколько копий останутся пригодными, если production, доменные администраторы и повседневный контур управления уже нельзя считать доверенными.
Пути атаки на backup
| Путь | Что происходит | Какая граница нужна |
|---|---|---|
| Файловый доступ к репозиторию | Скомпрометированный сервер или пользователь изменяет доступные файлы копий | Репозиторий не должен быть обычной общей папкой с постоянной записью из production |
| Учетная запись администратора | Злоумышленник входит в консоль backup и удаляет задания или точки | Отдельные административные идентификаторы, MFA и минимальные роли |
| Сервисная учетная запись | Секрет извлекается с сервера и используется вне штатного задания | Ограничение назначения, ротация и отсутствие интерактивного применения |
| Облачный кабинет | Меняются retention, object lock, ключи или политика удаления | Разделение ролей, защищенные настройки и журнал административных действий |
| Репликация повреждения | Зашифрованные либо удаленные данные быстро копируются на вторую площадку | Исторические точки и независимый срок хранения |
| Компрометация самого backup-сервера | Отключаются задания, уведомления и очистка следов | Патчи, сегментация, мониторинг и копия, которой сервер не может распоряжаться после записи |
Правило 3-2-1 полезно, но не описывает доверие
Три копии на двух типах хранения и одна копия отдельно снижают риск общей аварии. Но если все хранилища доступны одной учетной записи, постоянно подключены к одному административному контуру и позволяют немедленное удаление, они могут исчезнуть одновременно.
Для защиты от шифровальщика к количеству добавляют независимость: отдельные права, ограниченный путь записи, защищенный retention и хотя бы одну копию, которую нельзя изменить тем же способом, что production.
Три уровня хранения
| Уровень | Назначение | Допустимый компромисс |
|---|---|---|
| Production | Рабочие данные и сервисы | Высокая доступность для приложений, но не считается backup |
| Оперативная копия | Быстрое восстановление файлов, виртуальных машин и баз | Может быть доступна backup-системе постоянно, поэтому требует сегментации и отдельных прав |
| Защищенная копия | Переживание компрометации production и управляющего контура | Восстановление может быть медленнее, зато изменение и удаление ограничены |
У небольшой компании это не обязательно три дорогих устройства. Важнее реальные границы: отдельное хранилище с неизменяемыми точками, внешняя площадка или носитель, который подключается только на контролируемое окно и после записи снова становится недоступным.
Offline, immutable, object lock и реплика - не одно и то же
| Механизм | Что защищает | Что проверить |
|---|---|---|
| Offline-копия | Нет постоянного сетевого пути для изменения | Кто и когда подключает носитель, не остается ли он доступным после задания |
| Неизменяемая копия | Записанные точки нельзя переписать или удалить до окончания срока | Может ли скомпрометированный администратор сократить retention или обойти режим |
| Object lock | Объекты хранятся по политике запрета изменения или удаления | Режим блокировки, срок, версия объектов, права и стоимость ошибочно длинного хранения |
| Логический air gap | Путь к копии открывается только ограниченному процессу и времени | Кто управляет открытием и не зависит ли эта роль от production |
| Реплика | Дает вторую актуальную систему или набор данных | Есть ли исторические точки, если удаление и шифрование реплицируются |
Название функции в интерфейсе не является доказательством. При приемке нужно попытаться удалить защищенную точку учетной записью, которой может завладеть обычный администратор backup, и убедиться, что политика действительно запрещает действие. Такой тест проводят на специально созданных данных, не рискуя единственной рабочей копией.
Разделите учетные записи и административные роли
Backup не должен полностью зависеть от тех же привилегий, которыми ежедневно управляют рабочими станциями и серверами. Практическая модель включает:
- отдельные административные учетные записи для backup, не используемые на пользовательских компьютерах;
- минимальные роли: оператор задания, просмотр отчетов, восстановление и изменение retention не обязаны быть одной ролью;
- MFA для интерактивного управления, если платформа его поддерживает;
- отдельное хранение аварийных реквизитов с контролем использования;
- сервисные учетные записи без интерактивного входа и без лишних прав;
- журнал изменений политик, пользователей, хранилищ и сроков хранения;
- ограниченный административный сетевой путь к backup-инфраструктуре.
Отдельный пароль сам по себе мало помогает, если он хранится на том же сервере, доступен тому же доменному администратору и никогда не меняется. Независимость оценивают по всей цепочке идентификации и восстановления доступа.
Retention должен переживать позднее обнаружение
Компания может заметить компрометацию не в день первого проникновения. Если все точки хранятся коротко, к моменту расследования доступными останутся только копии уже измененных данных. Поэтому нужны точки разного возраста: частые оперативные для обычных ошибок и более редкие долгосрочные для поздно обнаруженных событий.
Сроки нельзя выбирать только по свободному месту. Их связывают с:
- допустимой потерей данных и частотой изменения систем;
- временем обнаружения технической ошибки или инцидента;
- размером полного и инкрементального набора;
- скоростью передачи на внешнюю площадку;
- временем поиска чистой точки и проверки ее целостности;
- реальной стоимостью хранения и извлечения.
Успешное задание - только один из сигналов
Мониторинг защищенного backup должен замечать не только ошибку копирования.
| Событие | Почему важно |
|---|---|
| Удаление точки или массовая очистка | Может быть подготовкой к атаке либо ошибкой администратора |
| Сокращение retention или отключение immutability | Защита исчезает до того, как пропадут данные |
| Добавление администратора или изменение MFA | Меняется контроль над всей системой |
| Резкий рост измененных данных | Может указывать на массовое шифрование или перезапись |
| Длительное отсутствие защищенной копии | Оперативные задания могут быть зелеными, а независимый уровень давно не обновлялся |
| Ошибка проверки целостности или восстановления | Копия существует, но не подтверждает возможность возврата сервиса |
| Отключение репозитория или уведомлений | Инцидент может скрываться отсутствием данных, а не красным статусом |
Уведомление должно приходить по каналу, который не исчезает вместе с backup-сервером. Если отчет формируется только внутри скомпрометированной консоли, отсутствие сообщения легко принять за отсутствие проблемы.
Проверяйте три уровня восстановления
| Проверка | Что доказывает | Чего не доказывает |
|---|---|---|
| Файл или папка | Точка читается, отдельные данные можно извлечь | Работу приложения и зависимостей |
| Приложение или база | Данные согласованы, сервис запускается и проходит функциональную проверку | Восстановление всей инфраструктуры после потери площадки |
| Сценарий аварии | Команда знает порядок, доступы, зависимости, время и ограничения полного возврата | Автоматическую безопасность всех будущих копий |
Тестовая среда должна быть отделена от production, чтобы восстановленный узел не конфликтовал с рабочими адресами, именами и заданиями. Для баз данных и бизнес-приложений результат подтверждает не только администратор, но и владелец процесса: открывается нужный период, выполняется операция, присутствуют ожидаемые документы.
После подтвержденного инцидента нельзя сразу доверять старой среде
Восстановление копии в скомпрометированный домен или сеть может повторно заразить систему. План должен предусматривать чистую площадку или изолированный сегмент, проверенные установочные образы, восстановление идентификации и административного доступа, а затем сервисов по приоритету.
Порядок зависит от инфраструктуры, но обычно сначала возвращают доверенный контур управления, сеть, DNS, время и необходимые учетные записи, после чего - критичные приложения и данные. Параллельно сохраняют журналы и другие свидетельства, необходимые для расследования. Конкретные действия при активном инциденте должны выполняться по отдельному плану реагирования, а не по универсальной статье.
Пример архитектуры для небольшой компании
Рабочие серверы копируются на отдельный локальный репозиторий для быстрого восстановления. Backup-сервер использует отдельную административную учетную запись и доступен для управления только из выделенного сегмента. По расписанию создается вторая копия во внешнем хранилище с неизменяемым сроком; production не имеет права удалять эти объекты. Ежедневно контролируются задания и наличие свежей защищенной точки, ежемесячно восстанавливается выбранный сервис в изолированную среду, а полный сценарий аварии проверяется по утвержденному графику, зависящему от критичности.
Если бюджет ограничен, сначала полезнее обеспечить одну действительно независимую копию и регулярный тест, чем покупать еще одно быстрое хранилище, доступное тем же учетным данным.
Критерии приемки
- описаны данные, системы, владельцы, RPO, RTO и порядок восстановления;
- есть хотя бы одна копия, независимая от обычного административного контура;
- retention защищенной копии нельзя незаметно сократить повседневной учетной записью;
- production не имеет прямого произвольного доступа к файлам репозитория;
- административные роли разделены и их изменения журналируются;
- контролируются удаление точек, изменение политик и отсутствие свежей защищенной копии;
- восстановлены файл, приложение и согласованный аварийный сценарий;
- известно, где развернуть чистую среду и кто принимает бизнес-результат;
- конфигурация backup и документы восстановления тоже защищены.
Первичные источники
При проектировании резервного копирования и восстановления защищенность нужно оценивать вместе со сроками возврата сервисов. Копия, которую невозможно уничтожить, но невозможно вовремя извлечь и запустить, решает только половину задачи.
Итог: защита backup от шифровальщика строится на независимости, а не на количестве заданий. Отдельные доступы, неизменяемая или offline-копия, разнообразный retention, контроль административных изменений и регулярное восстановление должны работать как единый контур.