DDoS-атаки развиваются не по принципу замены старых методов новыми, а по принципу накопления. Техники, появившиеся десятилетия назад, — например SYN flood, известный ещё с
К предупреждениям об ИБ-угрозах многие уже привыкли, но реальность остаётся прежней: успешная DDoS-атака по-прежнему способна привести к финансовым потерям, нарушению доступности сервисов и репутационному ущербу. Особенно заметно это в компаниях, для которых цифровые каналы напрямую связаны с выручкой, клиентским опытом и непрерывностью бизнес-процессов.
Защита от DDoS становится актуальной для всё большего числа организаций вне зависимости от их масштаба, и ключевым остаётся вопрос выбора подхода. Рынок предлагает широкий спектр решений: облачные сервисы, on-premise-системы и гибридные схемы. Критерии выбора между ними отличаются от тех, что обычно применяются при оценке SaaS-сервисов или облачных платформ. Экономика по-прежнему важна, но на первый план выходит технологический вопрос: насколько каждый из вариантов способен реально справиться с современными атаками — и для каких компаний он окажется наиболее подходящим.
Оговоримся сразу: речь пойдёт преимущественно о крупных заказчиках. Малый и средний бизнес чаще всего использует базовую защиту, которую предоставляет интернет-провайдер, — отдельно или в составе дополнительной услуги. Специализированные on-premise-решения для сегмента МСБ, как правило, технологически избыточны и экономически затратны. При этом облачные сервисы на стартовых тарифах могут быть вполне актуальны для небольших компаний, если доступность сайта, интернет-магазина, личного кабинета или другого цифрового сервиса напрямую влияет на выручку и клиентский опыт.
Всё сказанное ниже в первую очередь относится к компаниям крупного и корпоративного сегмента, где инвестиционные возможности шире, инфраструктура сложнее, а подход к информационной безопасности более системный.
Когда оправдан on-premise
Использование средств защиты, развёрнутых на собственной инфраструктуре, имеет смысл — но для весьма ограниченного круга компаний.
Прежде всего это крупные телеком-операторы. Такой оператор управляет развитой внешней связностью: несколькими апстримами, пиринговыми соединениями, стыками на точках обмена трафиком и большими объёмами клиентского трафика. Внешняя связность формируется за счёт IP-транзита, пиринга и прямых межсетевых соединений, а суммарная пропускная способность у крупных операторов может достигать десятков терабит в секунду.
Переход на внешнюю облачную защиту в такой модели меняет саму логику управления трафиком. Если значимую часть клиентского или магистрального трафика направлять через облачного провайдера защиты, именно он фактически становится основной точкой входа в сеть оператора для защищаемых префиксов. В результате оператор теряет часть контроля над тем, через какие апстримы, пиринговые соединения и маршруты этот трафик приходит в его сеть.
Для компании, чей бизнес построен на управлении внешней связностью, это принципиальное ограничение. Вместо самостоятельного выбора маршрутов, балансировки между апстримами и оптимизации стоимости трафика оператор получает зависимость от сетевой политики, пропускной способности и коммерческой модели провайдера защиты. В предельном случае облачный провайдер защиты превращается для него в единственного поставщика входящего интернет-трафика по защищаемым направлениям — а это противоречит самой сути операторского бизнеса.
Поэтому для крупных телеком-операторов on-premise-защита остаётся не просто допустимой альтернативой, а архитектурно оправданным решением. В первую очередь такие системы позволяют поддерживать устойчивость и работоспособность собственной сети, сохраняя управление внешней связностью, распределением трафика и экономикой апстримов внутри операторской инфраструктуры. На базе этой же инфраструктуры операторы нередко предоставляют клиентам услуги защиты от DDoS, однако в большинстве случаев речь идёт о базовой защите для enterprise-сегмента без жёстких SLA и с ограниченным набором функций по сравнению со специализированными облачными сервисами.
Гибридная схема: когда on-premise недостаточно
Вторая группа компаний, для которых собственные средства фильтрации остаются важной частью архитектуры, — крупные облачные провайдеры масштаба Yandex Cloud, VK Cloud и сопоставимых платформ. Как и телеком-операторы, они управляют развитой внешней связностью, большим количеством сетевых стыков и значительными объёмами входящего трафика. Поэтому им нужны собственные механизмы фильтрации объёмных L3/L4-атак на внешнем периметре сети — прежде всего для поддержания устойчивости сетевой инфраструктуры и базовых сервисов облачной платформы.
Но для защиты клиентских сервисов одной периметровой фильтрации недостаточно. Облачный провайдер продаёт не только инфраструктуру, но и доступность размещённых в ней систем, а полноценная защита каждого клиентского сервиса становится для него отдельной коммерческой услугой. При этом отсутствие в портфеле провайдера сервисов тонкой защиты от DDoS — включая L7-фильтрацию и гарантированный SLA — создаёт риск ухода клиентов к конкурентам, способным предоставить такой уровень защиты.
Поэтому для своих заказчиков облачный провайдер должен иметь отдельные механизмы «тонкой» очистки DDoS-трафика — включая защиту L7, поведенческий анализ, фильтрацию с учётом прикладной логики и гарантированный SLA на доступность защищаемого сервиса. Именно здесь классический on-premise, ориентированный в первую очередь на сетевой периметр, оказывается недостаточным.
Логичным выходом становится гибридная модель: собственную инфраструктуру облачного провайдера защищают внутренние средства фильтрации, а клиентские сервисы — специализированные облачные решения, обеспечивающие точную очистку трафика и понятные обязательства по качеству услуги.
Эдгар Микаелян, директор по клиентским решениям Curator
Curator с 2010 года занимается обеспечением непрерывной доступности веб-ресурсов и критичных цифровых сервисов. Формально мы предоставляем облачный сервис защиты, но в работе с крупными enterprise-заказчиками это не классическая SaaS-модель «подключил и забыл». Для таких компаний защита от DDoS — это managed-сервис с глубоким техническим онбордингом.
На этапе подключения наши инженеры по клиентским решениям подробно изучают архитектуру заказчика: внешнюю связность, DNS-инфраструктуру, схему маршрутизации, балансировку нагрузки, цепочки проксирования, origin-инфраструктуру, особенности веб-приложений и API, пользовательские сценарии и допустимые профили нагрузки. Это нужно для того, чтобы защита была настроена не абстрактно, а под конкретную инфраструктуру, бизнес-критичные сервисы и реальные векторы атак.
На практике мы видим, что выбор в пользу облачной защиты часто происходит не во время плановой оценки архитектуры, а после первого серьёзного инцидента. Типовой пример — компания из сегмента онлайн-ставок или игровой индустрии, у которой была собственная система фильтрации с фиксированной полосой очистки порядка
100–200 Гбит/с. При атаке в несколько сотен гигабит в секунду такая архитектура ещё может работать на пределе, но при переходе атакующего трафика в терабитный диапазон запас прочности быстро заканчивается. В результате страдает не только сетевой периметр, но и пользовательские сессии, платёжные сценарии и доступность сервиса в самый критичный момент.После перехода на облачную модель меняется не только доступная полоса очистки. Заказчик получает распределённую инфраструктуру фильтрации, постоянный мониторинг, централизованную видимость атаки и команду, которая понимает особенности его сервиса. Это позволяет противостоять атакам терабитного класса без критичной деградации для пользователей и в рамках согласованных параметров SLA.
Другой характерный сценарий — крупная финансовая или технологическая компания с распределённой инфраструктурой в нескольких дата-центрах. Когда средства защиты размещены отдельно на каждой площадке, атака видна фрагментарно: каждая точка наблюдает только свою часть трафика, а полной картины нет ни у одной системы. Облачная очистка даёт единую точку видимости и реагирования, помогает быстрее отличать легитимную нагрузку от атаки и снижает операционную нагрузку на внутреннюю ИБ-команду.
На мой взгляд, именно это главное преимущество облачного managed-подхода, которое часто недооценивают. Важно не только иметь большую ёмкость фильтрации, но и видеть атаку целиком, понимать прикладной контекст и заранее настраивать защиту под конкретную архитектуру заказчика. В современных DDoS-атаках выигрывает не тот, у кого больше отдельных устройств на периметре, а тот, кто способен управлять трафиком комплексно — от сетевого уровня до L7.
Распространенная ошибка: эшелонированная защита
Отдельно стоит остановиться на архитектурной ошибке, которую часто ошибочно принимают за эшелонированную защиту. Она выглядит так: компания последовательно ставит на пути трафика несколько независимых средств фильтрации — защиту от DDoS у интернет-провайдера, специализированное on-premise-решение, внешнее облачное решение для части веб-ресурсов, WAF или другие периметровые инструменты.
Логика кажется убедительной, но на практике такой подход почти всегда приводит к обратному результату. Защита от DDoS — это динамический процесс анализа и управления трафиком, где важно видеть максимально полную картину атаки: источники, распределение запросов, динамику трафика и поведение легитимных пользователей. Цепочка разнородных систем такой возможности не имеет. Первое решение фильтрует трафик по своим критериям, второе получает уже искажённую картину и работает некорректно: ошибается при фильтрации, конфликтует с предыдущим звеном. Чем длиннее цепочка, тем больше ошибок — и тем выше вероятность, что легитимный трафик будет заблокирован, а вредоносный — пропущен.
По экспертным оценкам, в крупном сегменте подобную ошибку допускает около 40% компаний, а в государственном секторе она встречается ещё чаще. Причина, как правило, управленческая: вместо того чтобы разобраться, почему первое решение не обеспечивает нужного качества фильтрации, компании добавляют второе, третье и последующие звенья. В результате архитектура становится сложнее, но ответственность за доступность сервиса и качество защиты остаётся размытой.
Где облако работает лучше всего
Для большинства компаний облачная защита от DDoS становится наиболее практичным вариантом: она позволяет быстро масштабировать полосу очистки, использовать экспертизу провайдера и снижать операционную нагрузку на внутренние команды. Есть несколько типов организаций и сценариев, где преимущества облачного подхода проявляются особенно заметно.
- Финтех, банки и платёжные системы. Это одни из наиболее атакуемых сегментов: по данным Curator, на них приходится более трети всех DDoS-инцидентов. Для таких компаний критична не только скорость реакции, но и точность фильтрации: ложные срабатывания могут напрямую влиять на клиентские операции, доступность дистанционных сервисов и качество пользовательского опыта. Облачные платформы с поведенческим анализом трафика и защитой L7 позволяют точнее отличать легитимные запросы от атакующих, чем решения, работающие преимущественно на сетевом периметре.
- Электронная коммерция и маркетплейсы. Нагрузка на инфраструктуру таких компаний неравномерна: в периоды распродаж, маркетинговых кампаний и сезонных пиков она может кратно превышать обычные значения. Облачная защита позволяет масштабировать фильтрацию вместе с трафиком без необходимости постоянно содержать избыточные мощности в собственной инфраструктуре.
- Онлайн-ставки и игровая индустрия. Для этих сегментов характерны атаки высокой интенсивности, а также повышенные требования к задержкам и непрерывности пользовательских сессий. Облачная защита с достаточной ёмкостью сети и корректной архитектурой подключения позволяет противостоять атакам терабитного класса и минимизировать их влияние на доступность сервиса. В отличие от on-premise-решений с фиксированной полосой очистки, такой подход лучше масштабируется под резкие всплески атакующего трафика.
- Компании без собственной ИБ-экспертизы. Облачный сервис снижает операционную нагрузку на внутреннюю команду: мониторинг, первичное реагирование, настройку правил фильтрации и сопровождение защитных механизмов берёт на себя провайдер. Для компаний, у которых нет выделенной команды безопасности или круглосуточного центра мониторинга, это особенно важно.
- Организации с распределённой инфраструктурой. Если сервисы компании размещены в нескольких дата-центрах, публичных облаках или гибридной среде, собственные on-premise-решения усложняют архитектуру защиты и требуют отдельного управления в каждой точке присутствия. Облачная защита подключается независимо от физического расположения инфраструктуры и позволяет централизованно управлять политиками фильтрации для разных площадок и сервисов.
Облако как выбор по умолчанию
Практика показывает, что для большинства крупных компаний облачная защита от DDoS становится наиболее оправданным выбором. Она даёт доступ к масштабируемой полосе очистки, особенно на фоне роста числа многотерабитных атак и многомиллионных ботнетов, более точной фильтрации, экспертизе провайдера и снижает операционную нагрузку на внутренние команды.
On-premise-решения сохраняют актуальность, но их область применения становится всё более специализированной. В первую очередь это крупные телеком-операторы, облачные провайдеры, которым необходимо защищать собственную сетевую инфраструктуру, а также компании с жёсткими регуляторными или архитектурными ограничениями на использование внешних сервисов защиты. Во всех остальных случаях выбор всё чаще склоняется в пользу облачной модели. Для компаний, чья основная задача — обеспечить доступность публичных сервисов, веб-приложений, API и клиентских цифровых каналов, облачный подход обычно оказывается и технологически более гибким, и экономически более обоснованным.
Вывод прост: облако становится выбором по умолчанию, а on-premise — решением для специфических сценариев, где компания действительно должна сохранять фильтрацию внутри собственной инфраструктуры.
