Ключевой кейс · Надёжность и безопасность
Многослойная DDoS-защита за пределами CDN
Как Cloudflare и отдельный слой анализа поведения защищали работающую платформу во время крупной DDoS-атаки.
Что можно раскрыть
Название клиента скрыто. Cloudflare принимал на себя большой объём атакующего трафика. Собственный слой за ним анализировал поведение в приложении и дополнял CDN, а не заменял его.
Коротко о результате
Многослойная защита сохранила работу платформы, от которой зависела выручка, при DDoS-нагрузке до 300 тыс. запросов в секунду и более 25 Гбит/с.
Что происходило и что было на кону
Работающая игровая платформа, пиковые часы. Простой означал потерю денег прямо сейчас и вопросы от регулятора потом. Неприятный график на дашборде был меньшей из проблем.
Исходные условия и ограничения
На уровне приложения атака имитировала реальное пользовательское поведение. Унаследованная защита состояла в основном из хрупких правил, написанных после прошлых инцидентов. Безопасно учиться методом проб и ошибок было негде.
Моя роль
Как CTO я отвечал за архитектуру многослойной защиты, реакцию на инцидент и чёткую границу между работой CDN и классификацией внутри платформы.
От проблемы к результату
- Ситуация
Инцидент в продакшене показал: правила на границе сети справляются с объёмом трафика, но не распознают атаки, которые используют бизнес-логику приложения.
- Ограничение
Платформа должна была оставаться доступной реальным пользователям, пока защита в реальном времени отделяет враждебные сессии от нормального трафика.
- Решение
Оставить обработку объёма трафика Cloudflare. За ним использовать Linux/BPF и ИИ-агентов для анализа поведения. При низкой уверенности передавать решение человеку.
- Что изменилось
Связка выдержала атаку до 300 тыс. запросов в секунду и более 25 Гбит/с. Роли Cloudflare и собственного слоя зафиксированы отдельно.
300 тыс. запросов в секунду / более 25 Гбит/с: многослойная DDoS-защита за пределами CDN.
Cloudflare справился со своей задачей по обработке объёма трафика. Собственный слой дополнял его анализом поведения приложения. Разделение этих ролей подтверждено владельцем в реестре источников.
- Контекст
- Работающая iGaming-платформа, от которой зависела выручка; название скрыто.
- Период
- Инцидент и одобренная формулировка; запись в реестре источников от 2 сентября 2026 года.
- Исходная ситуация и показатели
- Cloudflare обрабатывает объём атакующего трафика, собственный слой анализирует поведение приложения. При низкой уверенности решение принимает человек.
- Роль
- Как CTO я отвечал за архитектуру многослойной защиты, реакцию на инцидент и чёткую границу между работой CDN и классификацией внутри платформы.
- Источник
- Источники и подтверждения
- Откуда данные
- Авторский пост, основной профиль и утверждённое заявление владельца.
- Надёжность данных
- A: точная одобренная формулировка и данные автора о масштабе атаки.
- Ограничения публикации
- Анонимизированный кейс в пределах согласованного NDA.
Что изменилось
Мы отразили DDoS-атаку на работающую платформу, от которой зависела выручка. Пик достигал 300 тыс. запросов в секунду и более 25 Гбит/с. Cloudflare справлялся с объёмом трафика, а за ним фильтры Linux/BPF и ИИ-агенты адаптировали защиту по поведению. При низкой уверенности решение принимал человек.
Что подтверждает этот результат
Cloudflare справился со своей задачей по обработке объёма трафика. Собственный слой дополнял его анализом поведения приложения. Разделение этих ролей подтверждено владельцем в реестре источников.
Что осталось у команды
У команды осталась модель защиты, где понятно, за что отвечает каждый слой и кто его поддерживает. Можно было работать с новыми атаками, а не только дописывать правила по следам старых.
Связанная проблема и следующий кейс
Связанный кейс показывает, почему контроль над сетью стал важен, когда проявились стоимость и ограничения облака.