Защита DDoS и резервные копии: выстройте две независимые линии обороны
Доступная сеть и восстановимые данные решают разные задачи. HM Bastion включает защиту DDoS в свою инфраструктуру, но продуманный операционный план всё равно требует контроля доступа, обслуживания приложений и проверенной копии для восстановления.
Практический вывод
Используйте фильтрацию для снижения вредоносного трафика, поддерживайте приложение для снижения риска компрометации и храните независимо восстановимые данные на случай сбоев, которые защита предотвратить не может.
Сначала определите сбой, затем выбирайте защиту
Объёмная атака трафиком может исчерпать пропускную способность сети. Дорогостоящий запрос к приложению способен перегрузить сервис при куда меньшем трафике. Похищённые учётные данные администратора позволяют изменить или удалить содержимое, пока сеть остаётся в норме. У этих событий разные причины, поэтому одна функция защиты не заменит полноценный операционный план.
Фильтрация DDoS направлена на выявление и снижение атакующего трафика при пропуске полезного. Точная обработка зависит от атаки и защищаемого сервиса. Постоянная защита не означает, что каждое приложение неуязвимо, что все протоколы ведут себя одинаково или что создана гарантия доступности.
Поддерживайте приложение за периметром в рабочем состоянии
Для VPS или выделенного сервера сохраняйте осознанный подход к административному доступу. Удаляйте ненужные службы, устанавливайте обновления операционной системы и приложений, ограничивайте привилегированный доступ кругом людей и систем, которым он действительно нужен. Не храните секреты в публичных папках и проверяйте журналы при изменении поведения.
Для веб-приложения наряду с сетевой фильтрацией учитывайте средства аутентификации, ограничения запросов и поведение кэша. Дорогостоящие некэшируемые эндпоинты заслуживают внимания, даже если пропускной способности сети достаточно. Легитимный всплеск трафика может выявить то же узкое место приложения, что и злоупотребляющие запросы, поэтому обычное планирование мощности по-прежнему важно.
Зафиксируйте порты, домены и протоколы, которые действительно нужны приложению. При обращении в поддержку по инциденту укажите затронутый сервис, примерное время, видимые симптомы и безопасные диагностические сведения. Никогда не включайте в обращение секрет кошелька, пароль учётной записи или закрытый ключ восстановления.
Дайте каждому уровню восстановления свою задачу
| Уровень | Для чего полезен | Что учитывать |
|---|---|---|
| Реплицированное хранилище | Непрерывность при некоторых отказах оборудования хранения | Нежелательное изменение данных тоже может реплицироваться |
| Снимок | Возврат к зафиксированному состоянию системы | Срок хранения и независимость отличаются от отдельной резервной копии |
| Независимая резервная копия | Восстановление данных из отдельной копии | Она должна включать нужные файлы, базы данных и знания о процедуре восстановления |
Спецификации облака HM Bastion описывают хранилище с репликацией Ceph и снимки. Тарифы веб-хостинга предусматривают ежедневные резервные копии с числом точек восстановления до десяти. Изучайте функцию, прилагаемую к приобретаемому сервису; не предполагайте, что одинаковый порядок резервного копирования действует во всех семействах хостинга.
Выбирайте график восстановления исходя из того, сколько недавней работы проект может потерять и сколько времени может занять восстановление. Сайт-визитка и активная база заказов имеют разные потребности. Храните учётные данные для восстановления отдельно от работающего приложения и обеспечьте, чтобы более одного уполномоченного лица знали, где хранится процедура.
Проверьте восстановление, пока система в норме
- Определите файлы сайта, базу данных, загрузки и конфигурацию, необходимые для перезапуска.
- Создайте независимую копию с доступом только для уполномоченных лиц.
- Восстанавливайте в безопасную тестовую среду, а не поверх рабочей.
- Проверьте содержимое, доступ к приложению и важные пользовательские сценарии.
- Зафиксируйте результат, затраченное время и всё, чего не хватает в процедуре.
Файл в хранилище резервных копий служит подтверждением наличия копии, но успешное восстановление — более весомое доказательство восстановимости. Повторяйте проверку после существенных изменений приложения или хранилища. Так расплывчатое обещание восстановить позже превращается в процедуру, которой команда действительно может следовать.
Когда инцидент всё же происходит, ведите сетевую фильтрацию, диагностику приложения и восстановление данных как отдельные направления работ с явным ответственным для каждого. Такая структура помогает команде реагировать на фактический сбой, а не прибегать каждый раз к одному и тому же сбросу или откату.
