В 2026 году DDoS-атаки остаются одним из самых доступных инструментов давления на онлайн-бизнес - для организации атаки не нужны сложные ресурсы, а последствия для сайта чувствуются мгновенно. Для оператора персональных данных вопрос не сводится к «упадёт сайт или нет»: атака способна повлиять на доступность сервиса, а иногда становится прикрытием для попытки взлома. Разбираемся, как DDoS-угрозы связаны с требованиями 152-ФЗ и что стоит проверить уже сейчас.
Коротко
- DDoS-атака не крадёт данные напрямую, но нарушает доступность сайта и сервисов, где обрабатываются ПДн.
- Атаку иногда используют как отвлекающий манёвр, пока параллельно пытаются получить несанкционированный доступ к данным.
- Защита от DDoS - часть общих технических мер по ст. 19 152-ФЗ, а не отдельная обязанность с собственным штрафом.
- Прямого штрафа «за отсутствие DDoS-защиты» не существует - ответственность наступает, если атака привела к утечке и оператор не уведомил РКН вовремя.
- Базовые меры защиты - это набор организационных и технических решений, а не разовая настройка.
Что такое DDoS-атака и почему это риск для доступности сервиса
DDoS (Distributed Denial of Service) - это распределённая атака, при которой на сайт или инфраструктуру одновременно направляется огромный поток запросов с множества источников. Цель атакующих - исчерпать ресурсы сервера, канал связи или приложение так, чтобы обычные пользователи не смогли получить доступ к сайту.
Для оператора персональных данных доступность сервиса - это не абстрактное требование, а часть обязанности обеспечивать сохранность данных. Если личный кабинет, форма подачи заявления или сервис работы с обращениями субъектов недоступны из-за атаки, это уже нарушение нормальной работы системы обработки ПДн, даже если сами данные никуда не делись.
| Тип DDoS-атаки | Что перегружается | Типичное последствие |
|---|---|---|
| Сетевые атаки (например, UDP-флуд) | Канал связи, сетевое оборудование | Полная недоступность сайта |
| Атаки на транспортный уровень (SYN-флуд) | Ресурсы сервера, число соединений | Сайт открывается медленно или не открывается |
| Атаки на уровень приложения (HTTP-флуд) | Веб-сервер, база данных, формы | Ошибки на сайте, сбои конкретных функций |
Связь с обязанностью обеспечить сохранность данных по 152-ФЗ
Статья 19 152-ФЗ обязывает оператора принимать необходимые правовые, организационные и технические меры для защиты персональных данных от неправомерного доступа, уничтожения, блокирования и иных незаконных действий. Блокирование доступа к данным из-за DDoS-атаки прямо подпадает под этот перечень рисков.
Отдельно стоит помнить про статью 18.1, которая требует от оператора внутреннего контроля за соответствием обработки ПДн требованиям закона, включая оценку рисков и принятие мер по их снижению. DDoS-угрозы логично входят в эту оценку - как один из сценариев нарушения доступности.
Важно: закон не устанавливает отдельного штрафа именно за отсутствие защиты от DDoS. Но если атака привела к реальной утечке персональных данных (например, злоумышленники воспользовались перегрузкой системы, чтобы получить доступ к базе), а оператор не уведомил Роскомнадзор в течение 24 часов с момента обнаружения инцидента, наступает ответственность по части 3.2 статьи 13.11 КоАП РФ - штраф от 100 000 до 150 000 рублей. Поэтому DDoS-защита рассматривается как превентивная мера в рамках общей обязанности защищать данные, а не как отдельное требование с собственной санкцией.
Базовые меры защиты
Полноценная защита от DDoS строится на нескольких уровнях - от сетевой инфраструктуры до логики приложения. Не обязательно внедрять всё сразу, но важно понимать, какие меры доступны и зачем они нужны.
- Фильтрация трафика на уровне провайдера или CDN - позволяет отсекать вредоносные запросы до того, как они достигнут сервера.
- Ограничение частоты запросов (rate limiting) - защищает формы, API и критичные страницы от массовых обращений с одного источника.
- Резервирование канала и масштабируемая инфраструктура - снижают риск полного отказа при кратковременных пиках нагрузки.
- Мониторинг аномалий трафика - помогает обнаружить атаку на раннем этапе, а не постфактум по жалобам пользователей.
- План реагирования на инциденты - заранее прописанный порядок действий сокращает время простоя и помогает соблюсти сроки уведомления РКН, если атака сопровождалась утечкой.
Эти меры не заменяют, а дополняют базовую защиту персональных данных: шифрование, разграничение доступа, резервное копирование. Вместе они формируют комплексный подход к обеспечению доступности и сохранности данных.
Что проверить у себя на сайте
- Подключена ли защита от DDoS на уровне хостинга, CDN или провайдера.
- Настроено ли ограничение количества запросов для форм обратной связи и авторизации.
- Есть ли мониторинг доступности сайта с уведомлением ответственных лиц при сбоях.
- Прописан ли в организации порядок действий при недоступности сайта или подозрении на атаку.
- Учтён ли сценарий DDoS-атаки в модели угроз для информационной системы персональных данных.
- Есть ли резервный канал связи или запасная инфраструктура на случай отказа основной.
- Проверено ли, что при сбоях сайта данные пользователей не остаются в незащищённом состоянии (например, в логах или временных файлах).
- Назначен ли ответственный, который в течение 24 часов оценит инцидент на предмет утечки данных и необходимости уведомления РКН.
Частые вопросы
DDoS-атака - это утечка персональных данных?
Сама по себе нет. DDoS нарушает доступность сервиса, но не означает автоматического доступа злоумышленников к данным. Утечка возможна, если атака сопровождалась другими действиями - например, попыткой взлома на фоне перегруженной защиты.
Нужно ли уведомлять Роскомнадзор при каждой DDoS-атаке?
Нет. Уведомление требуется только при инциденте, который привёл к неправомерному доступу, распространению или иной компрометации персональных данных. Кратковременная недоступность сайта без признаков утечки к таким инцидентам не относится.
Есть ли отдельный штраф за отсутствие DDoS-защиты?
Отдельного штрафа именно за это нет. Ответственность может наступить, если из-за атаки произошла утечка данных, а оператор не уведомил РКН в установленный срок - тогда применяется часть 3.2 статьи 13.11 КоАП РФ.
Можно ли ограничиться защитой на уровне хостинга?
Базовая защита провайдера снижает риски, но не покрывает все сценарии, особенно атаки на уровне приложения. Для полноценной картины стоит оценивать риски комплексно, вместе с другими мерами обеспечения безопасности.
Как понять, какие меры защиты нужны именно моему сайту?
Это зависит от объёма обрабатываемых данных, архитектуры сайта и текущей инфраструктуры. Оценить состояние сайта и получить структурированный список рекомендаций можно через форму аудита или изучив базовые требования в разделе документов.
Проверка доступности и защищённости сайта - лишь часть общей картины соответствия 152-ФЗ. Если хотите разобраться, какие меры уже есть, а каких не хватает, начните с бесплатной формы аудита.