25 апреля 11.00
Вебинар "Как запустить 1С с нуля по технологии быстрого внедрения?"
 

Восстановление данных после DDoS-атаки

Восстановление данных после DDoS-атаки
Время на прочтение: 6 минут

9 мая 2022 г видеосервис Rutube пережил крупнейшую в истории компании кибератаку. Она поразила  более 75% инфраструктуры основной версии и 90% резервных копий. Спустя 10 дней после атаки Rutube все еще не восстановился. Сложившаяся ситуация как нельзя лучше иллюстрирует предмет сегодняшнего обзора — что должно быть у бизнеса для восстановления данных после мощной DDoS-атаки.

Защита от DDoS

Защита от DDoS работает по принципу: «Чем меньше ущерб, тем быстрей восстановление». Это главный аргумент в пользу комплексной защиты от DDoS-атаки.

Когда ситуация развивается по оптимистичному сценарию, атаку удается задушить в зародыше. В худшем случае система защиты минимизирует ущерб, не допуская полного отказа серверов и кражи данных. Кстати, кража данных под прикрытием DDoS — «модный» тренд последних месяцев. Не так давно российские ритейлеры отразили массированную атаку ботнета, при этом вредоносная сеть шла в наступление «не для нанесения ущерба IT-инфраструктуре компаний с помощью DDoS-атак, а для сбора внутренней информации».

Базовые решения для защиты от DDoS контролируют IT-периметр. Продвинутые системы безопасности действуют одновременно по нескольким фронтам и работают на опережение:

1. Фильтруют трафик HTTP(S) для защиты от высокочастотных атак, которые истощают ресурсы серверов.

2. Нейтрализуют атаки ботов на сайт.

3. Фильтруют подозрительный трафик с помощью искусственного интеллекта. При каждой атаке ИИ анализирует метрики, выявляет аномалии данных и поведения пользователей, запускает сигнатурный анализ.

4. Big Data-аналитики контролируют решения ИИ и детектируют угрозы.

Как показывает практика наших клиентов, сервис защиты от DDoS-атак с алгоритмом Machine learning эффективен против HTTP и Basic Floods, Low-and-slow атак, Randomized HTTP, WordPress XMLRPC и Randomized HTTP Floods.

Сервис защиты от DDoS-атак
Две недели бесплатного тест-драйва

Бэкап, каким он должен быть

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

  • Делайте бэкапы сервера и не забывайте про отдельный бэкап баз данных. Не во всех решениях получится развернуть систему с нуля и просто импортировать в нее бэкапы.
  • Дополнительно к облачным создавайте офлайновые серверные бэкапы. Они выручат в ситуации, когда  программа-вымогатель зашифровывает данные, доступные по сети.
  • Тестируйте резервные копии. Нередко после тестирования оказывается, что бэкапилось не то, что нужно.
  • Следите за настройками бэкапов сервера, выполненными заданиями и местом под хранение копий. Иначе в один непрекрасный день компании понадобится бэкап, а его не получится развернуть из-за ошибки резервного копирования.
  • Выделите для резервного копирования виртуальных машин отдельное хранилище. Держать резерв на той же СХД, где хранится основная информация — не лучшая идея.

Бэкап должен быть у каждого бизнеса. Но не каждому достаточно бэкапа. У классического резервного копирования RTO и RPO составляют несколько часов. Это значит, что резервные копии виртуальных машин и копии баз данных сохраняются, например, каждые 3, 6, 9, 12 или 24 часа. Соответственно после распаковки бэкапов система восстановится без данных за последние 3, 6, 9, 12 или 24 часа.

Когда мы рассказываем о бэкапах на консультациях с клиентом, в этом месте обычно слышим два вопроса:

1. Восстановление с потерей данных за 1,3...24 часа это плохо?

2. Почему не резервировать все и без пауз?

Потеря данных за 1-24 часа — плохо для компаний с моделью «работа без остановок». Это банки, государственные структуры, медицинские организации, ритейл — все, чья деятельность плотно завязана на стабильной работе цифровых сред и постоянной доступности данных.

В то же время 1, 3...24 часа могут быть нормальными метриками RPO для малого и среднего бизнеса с невысоким уровнем цифровизации. Здесь действует простое правило: если потеря данных за несколько часов не несет прямых финансовых и репутационных потерь, компании достаточно резервной копии.

Что касается периодичности копирования, то чаще — не всегда лучше. Частое копирование очень ресурсоемкая вещь. Под него выделяют собственную инфраструктуру и сеть, что требует расходов. Кроме того, приходится учитывать затраты на хранение данных.

Оптимальный вариант — просчитать RTO и RPO и настроить бэкапы сервера по графику с учетом полученных метрик.

Сервис Disaster Recovery
Две недели бесплатного тест-драйва

План аварийного восстановления

Метрики RTO и RPO пригодятся не только для настройки графика бэкапа. По ним можно рассчитать показатель воздействия аварии на бизнес (BIA) и понять, нужен компании полноценный Disaster Recovery Plan (DRP) или достаточно плана восстановления из резервной копии.

BIA считается для каждого бизнес-процесса, а последствия оцениваются с нескольких позиций: безопасность, деловая репутация, финансы, административная ответственность и пр. Показатель прогнозирует убытки от DDos-атаки и ее последствий. Например, после атаки и утечки данных пользователей в сеть компании придется вложить в 3 раза больше денег в маркетинг, чтобы нивелировать негатив аудитории, а также потратить в 2 раза больше средств на юридическое улаживание проблемы.

Есть несколько подходов к расчету BIA, но если просто — когда операционные риски прогнозируются выше стоимости Disaster Recovery Plan, план аварийного восстановления однозначно нужен.

В первом приближении он состоит из четырех блоков:

1. Оценить, документировать инфраструктуру и основные объекты защиты.

2. Определить последовательность действий персонала и подрядчиков, установить KPI и критерии аварийной ситуации.

3. Прописать сценарии потенциальных атак и сбоев, определить ключевые факторы риска.

4. Разработать порядок актуализации DRP, составить график аудитов и тестирования при пробных запусках.

Это скелетные, базовые блоки. В зависимости от выбранного DR-решения они обрастают дополнительными шагами и операциями. Так что для компаний с Disaster Recovery в формате асинхронной репликации план будет одним, для бизнеса с синхронным зеркалированием — другим. Главное, чтобы документ соответствовал текущим бизнес-задачам, был понятен сотрудникам, известен подрядчикам и помогал оперативно отвечать на кибератаки.


Надежная защита, правильные бэкапы и продуманный план аварийного восстановления — программа минимум для восстановления данных после DDoS-атак. Больше можно, меньше — опасно.

Чтобы подобрать оптимальный баланс между операционными рисками и расходами на цифровую безопасность напишите или позвоните нам: поможем с выбором экономически оправданных решений под конкретные задачи защиты и восстановления после DDoS.

Новые статьи и анонсы вебинаров в нашем Телеграм-канале