Доступная копия может стать частью инцидента
Если сервер резервного копирования использует те же административные учётные данные, постоянно доступен из пользовательской сети или хранит копии в обычной общей папке, злоумышленник может удалить или зашифровать их вместе с рабочими данными.
Поэтому как минимум одна копия должна быть изолирована: офлайн, неизменяемая или находящаяся в отдельном контуре с независимым управлением доступом.
Успешное задание не подтверждает восстановление
Статус «успешно» говорит только о завершении операции записи. Он не проверяет целостность приложения, последовательность базы данных, наличие ключей и возможность развернуть систему на доступном оборудовании.
Восстановление нужно репетировать. Для критичных систем проводят технические тесты отдельных файлов, баз и целых сервисов, а периодически — комплексное учение с фиксацией фактического времени.
RPO и RTO переводят разговор в измерения
RPO отвечает на вопрос, сколько данных допустимо потерять. RTO — за какое время необходимо вернуть сервис. Эти показатели задаёт бизнес, а ИТ-архитектура должна обеспечить их технически. Без них невозможно понять, достаточно ли ежедневной копии и одного резервного хранилища.
Защита требует нескольких слоёв
- многофакторная аутентификация и отдельные аккаунты администраторов копирования;
- сегментация и ограничение управляющих портов;
- неизменяемость или физическое отключение части копий;
- шифрование и отдельное хранение ключей;
- мониторинг массового удаления и изменения политик;
- проверенный план восстановления и контакты ответственных.
Резервное копирование — последний рубеж, а не замена обновлениям, защите учётных записей, мониторингу и реагированию. Его ценность определяется не объёмом сохранённых данных, а способностью вернуть бизнес в работу.