Если сайт взломали, бэкап нужно защитить прежде всего от доступов, которыми мог завладеть злоумышленник. Копия в другом каталоге или облаке не спасает, если с сервера можно удалить её, старые версии или ключ расшифрования.
Рабочая схема сочетает отдельное управление хранилищем, ограниченные права задания резервирования и копию, которую нельзя изменить в выбранный срок либо которая отключена от сети. Проверять нужно конкретный путь удаления, а не название услуги «защищённый бэкап».
Если взлом уже обнаружен
С чистого устройства проверьте, какие завершённые копии сохранились и когда они созданы. Не подключайте отключённый носитель к подозрительному серверу и не запускайте синхронизацию, способную заменить старые данные повреждёнными.
Согласуйте изоляцию заражённого узла, сохранение журналов и отзыв скомпрометированных доступов. Новые ключи не размещайте на нём до устранения причины взлома; восстановление поверх заражённой системы может вернуть проблему вместе с сайтом.
1. Определите, кто способен уничтожить копии
Составьте список доступов: пользователь CMS, учётная запись приложения, SSH/root сервера, ключ загрузки бэкапов, кабинет хранилища и почта восстановления доступа. Для каждого проверьте не только чтение и запись, но и следующие действия:
- удаление архивов и отдельных версий;
- перезапись файла под прежним именем;
- изменение срока хранения и правил автоматической очистки;
- выдача себе дополнительных прав;
- удаление или отключение ключа расшифрования.
Например, архив у другого поставщика остаётся уязвимым, если на сервере лежит его административный ключ. Независимость от основного хостинга решает задачу доступа при аварии, а запрет удаления требует отдельной проверки прав.
2. Разделите создание копии и управление хранением
Заданию резервирования выдайте только необходимые права на загрузку новых объектов. Чтение списка или старых данных допускайте лишь там, где этого требует программа; удаление прошлых копий и изменение защиты вынесите в отдельную роль вне рабочего сервера.
Очистку по сроку хранения выполняйте отдельно от загрузки. Используйте уникальные имена комплектов: запись нового архива не должна заменять единственную пригодную копию. Для программ с общим индексом или инкрементальными цепочками сначала проверьте поддерживаемый режим — произвольный запрет записи может сломать резервирование.
Административный вход защитите отдельным паролем и вторым фактором. Проверьте резервный вход и почту сброса: они не должны управляться из взломанного сайта. Второй фактор помогает защитить кабинет, но не ограничивает уже выданный API-ключ.
3. Выберите барьер для удаления
Неизменяемое хранение
Уточните, какие именно версии защищены, до какой даты и кто может обойти запрет. Версионирование само по себе недостаточно, если теми же доступами можно удалить все версии.
Например, в документации Amazon S3 Object Lock режим Governance допускает обход уполномоченным пользователем, а Compliance запрещает удаление защищённой версии до окончания срока даже root-пользователю аккаунта. Обычный DELETE может добавить маркер удаления, сохранив защищённую версию: инструкция восстановления должна учитывать её поиск. Эти свойства нельзя автоматически переносить на любое S3-совместимое хранилище.
До включения строгой блокировки испытайте её на тестовых данных. Соотнесите срок с нужной глубиной восстановления, объёмом и стоимостью: ошибочно сохранённый архив тоже может остаться заблокированным.
Отключённая копия
Носитель, постоянно подключённый к серверу, остаётся доступен атакующему. Для отключённой копии определите порядок подключения, безопасного обновления и хранения; пока она подключена к заражённой системе, изоляция не действует.
CISA рекомендует хранить офлайн-копии критичных данных в зашифрованном виде и регулярно проверять их доступность и целостность при восстановлении. Шифрование защищает содержимое, но само по себе не запрещает удалить архив.
4. Проверьте защиту без риска для рабочих архивов
Используйте отдельный тестовый контейнер или каталог и безвредный файл. Воспроизведите роли и правила рабочего хранилища, не направляя испытания на настоящие копии.
- Загрузите тестовый комплект ролью задания резервирования.
- Попробуйте удалить его, перезаписать и удалить старую версию.
- Проверьте возможность сократить срок защиты или изменить очистку.
- Зафиксируйте результат и причину отказа: ошибочный адрес или сеть не подтверждают запрет прав.
- Отдельной ролью восстановления получите исходную защищённую версию и прочитайте её.
Успех — опасные действия запрещены для выбранной роли, а восстановление доступно. Запишите, какие более сильные доступы этот тест не покрывает, и повторите проверку после изменения политик.
Что ещё может помешать восстановлению
Неизменяемый архив может быть повреждённым, устаревшим или уже содержать следы взлома. Выбирайте точку до предполагаемой компрометации, проверяйте данные и устраняйте уязвимость; одного успешного скачивания недостаточно. Затем проведите пробное восстановление на изолированном стенде.
Ключ расшифрования храните защищённо и отдельно от единственного рабочего сервера, с проверенным аварийным доступом. Блокировка архивов бесполезна, если атакующий способен уничтожить единственный ключ. Мониторинг доступности в Web-Puls помогает заметить отказ публичного сайта, но не проверяет права хранения и чистоту резервной копии.
Следующий шаг
Начните с ключа задания резервирования: выясните, может ли он удалить прошлый комплект, и устраните этот путь. Если безопасно разделить роли или проверить блокировку не получается, отправьте заявку на профессиональную поддержку: опишите схему хранения и проблемный шаг без паролей, ключей и архивов. Специалист оценит задачу и предложит формат работ.