В пособии «Методы и стратегии обороны от DDoS-атак» выбору облачного поставщика посвящены страницы 44–45. На этих страницах предложено оценивать потребности, производительность, поддержку, стоимость и проверку услуги. Здесь эти критерии превращены в вопросы к конкретному предложению. Результатом обсуждения должна стать сопоставимая запись: ответ поставщика, документ или проверка, ограничение и открытый вопрос.
Передайте кандидатам одинаковое описание уже выбранного сервиса и нагрузки. Если исходные условия различаются, более подробное или дешёвое предложение может оказаться просто предложением на другой объём работ. Открытые вопросы отмечайте прямо; отсутствие ответа не равно наличию нужной возможности.
1. Что именно входит в защиту?
Попросите перечислить защищаемые домены, IP-адреса и протоколы, а рядом — классы атак и исключения. Слова «DDoS-защита включена» без этой расшифровки оставляют слишком много неизвестного. Отдельно отметьте, входит ли защита веб-приложения в предложение и нужны ли для неё другие услуги.
Например, документация Yandex Cloud разграничивает базовую защиту сетевого и транспортного уровней и расширенную защиту, включающую прикладной уровень. Это свойство конкретных услуг. Для любого рассматриваемого предложения полезен тот же вопрос: каким документом подтверждено покрытие именно вашего ресурса?
Перечень ресурсов, протоколов, классов атак и исключений со ссылкой на спецификацию услуги.
2. По какому пути трафик попадёт к сервису?
Попросите показать схему до и после подключения: где начинается фильтрация, как очищенный трафик доходит до приложения, какие изменения требуются в DNS, маршрутизации или сетевых настройках. Уточните, фильтруется ли трафик постоянно либо требуется переключение, и что должно произойти, чтобы оно началось. Для схемы с включением по событию нужен понятный порядок перехода и возврата.
У веб-прокси отдельно проверьте путь к исходному серверу — origin. В документации Cloudflare защита соединений с ним и ограничение прямого доступа рассматриваются отдельно. Поэтому наличие защищённого домена само по себе не закрывает вопрос о других доступных путях к приложению. Конкретное решение должен подтвердить инженер для вашей схемы.
Схема прохождения трафика, условия переключения и проверка альтернативных путей к исходному серверу.
3. К чему относятся заявленные пределы?
Если в предложении указана большая пропускная способность, попросите объяснить, что именно измерено: возможности всей сети поставщика, конкретной услуги или доступный вашему сервису очищенный поток. Отдельно запишите показатели в битах, пакетах и запросах в секунду. Разные единицы описывают разные характеристики; их нельзя свести к одному числу «мощности защиты».
Уточните условия измерения, ограничения по типам соединений и поведение при превышении согласованного объёма. Есть ли ограничение скорости, смена режима или дополнительные действия команды? Ответ нужен применительно к вашей конфигурации. Универсальный достаточный предел здесь не задаётся: сравнивать предложения следует с одним и тем же профилем нагрузки.
Показатели с единицами, областью применения, условиями измерения и поведением при превышении.
4. Как проверят влияние на обычных пользователей?
Запросите способ проверить фильтрацию на типичных сценариях вашего приложения до окончательного включения. Важны не только счётчики отброшенных запросов, но и обычные действия пользователей: удаётся ли завершить нужную операцию, какие ошибки появляются, меняется ли время ответа. Исходные значения и допустимые отклонения согласуют для конкретного сервиса.
В AWS WAF, например, документирован режим Count для наблюдения совпадений правил перед их активным применением. Это пример средства проверки, а не обязательная возможность всех решений. Спросите у кандидата, как он предлагает обнаруживать ошибочные блокировки, какие данные покажет для разбора и как исправление проверят без поспешного снятия всей защиты.
Порядок проверки обычного трафика, доступные данные об ошибочных блокировках и способ проверки исправления.
5. Какой результат обозначают сроки и SLA?
Разделите обещания по событиям: принятие обращения, начало работы инженера, применение меры защиты и восстановление нужного действия сервиса. Если в предложении есть время реакции, выясните, между какими событиями оно считается, кто фиксирует начало и конец и какие условия исключаются из расчёта. Быстрый ответ поддержки сам по себе не означает восстановленную работу приложения.
Попросите пример отчёта об инциденте без данных чужих клиентов. В нём должны быть понятны временная шкала, наблюдавшееся воздействие, принятые меры и оставшиеся ограничения. Согласуйте, какие сведения доступны вашей команде во время события, а какие появятся только в итоговом отчёте. Все конкретные обязательства проверяются по документам выбранной услуги.
Определения измеряемых событий, условия SLA и обезличенный образец отчёта.
6. Что изменится в обработке трафика и данных?
Сначала выясните, предполагает ли выбранная схема раскрытие TLS. Если да, попросите описать, где завершается соединение клиента, как устанавливается соединение с исходным сервером, какие сертификаты нужны и кто их обновляет. Если раскрытия нет, уточните, какие сигналы доступны для анализа и какие ограничения это создаёт. В обоих случаях спросите о составе журналов, доступе к ним и сроке хранения.
В методичке отдельно рассматриваются возможности и ограничения анализа с раскрытием шифрования и без него. Поэтому вместо общего ответа «поддерживаем HTTPS» нужен ответ для выбранной схемы. Необходимые настройки, роли и ограничения следует зафиксировать до подключения; само название технологии не подтверждает выполнение внутренних требований.
Наличие или отсутствие раскрытия TLS, доступные сигналы и ограничения; при раскрытии — схема соединений и сертификатов; состав журналов и доступ.
7. За что изменится счёт?
Попросите расчёт для одной конфигурации и двух сценариев: обычного периода и периода с атакой. В обоих случаях должны быть видны подключение, регулярная плата, учитываемый трафик, дополнительные функции и сопровождение. Отдельно выясните, какие расходы возникают при превышении включённых объёмов и какие условия действуют для компенсации дополнительных затрат, если она предусмотрена.
Модели оплаты различаются: например, у AWS Shield Advanced официально описаны подписка и плата за использование, а дополнительные возможности имеют свои условия. Этот пример не задаёт бюджет и не переносится на другого поставщика. Для сравнения попросите кандидатов указать все допущения расчёта и срок действия предложения.
Два расчёта на одинаковых исходных данных, все допущения и условия дополнительных начислений.
8. Чем подтвердят результат до окончательного решения?
Запросите программу проверки с заранее заданными вопросами и измеряемыми результатами. Для каждого пункта укажите, что именно он подтверждает: подключение, работу приложения, изменение фильтрации или поведение при согласованной нагрузке. Демонстрация панели и чужой успешный кейс не заменяют проверку вашей конфигурации. Результат отдельного испытания относится к его условиям и не гарантирует защиту от любой будущей атаки.
Техническое испытание согласуют с владельцами систем и задействованными провайдерами: область, исполнителя, нагрузку, время, условия остановки и возврат настроек. У AWS, например, существует отдельная политика DDoS-проверок с ограничениями ресурсов и исполнителей. Применяются правила вашей площадки; универсального разрешения или безопасного профиля нагрузки из этого примера не следует.
Программа и протокол проверки, ограничения испытания, условия остановки и возврата настроек.
Учебный пример: одинаковое название, разный объём
Представим вымышленную ситуацию: команда получила два предложения для одного веб-сервиса. В первом перечислены защищаемые IP-адреса и сетевая фильтрация. Во втором отдельно описаны обработка HTTP-запросов и условия работы с исходным сервером. В обоих заголовках написано «DDoS-защита». Это не история клиента и не характеристика каких-либо реальных компаний.
Команда не присваивает второму предложению победу по числу функций. Сначала она проверяет, какой объём нужен этому сервису, запрашивает у первого кандидата недостающие сведения и приводит оба расчёта к одинаковой конфигурации. Если нужный сценарий не покрыт или его покрытие не подтверждено, это остаётся явным ограничением решения, а не исчезает в общей оценке.
Одна карточка для двух предложений
Для каждого вопроса заполните отдельно поля для кандидата А и кандидата Б: ответ → подтверждающий документ или протокол → ограничение → оставшийся вопрос. Ниже можно раскрыть карточку, заполнить поля и сохранить результат в TXT. Одинаковый формат помогает увидеть, где сравниваются факты, а где пока только обещания.
| Вопрос | Что положить рядом с ответом |
|---|---|
| Что именно входит в защиту? | Перечень ресурсов, протоколов, классов атак и исключений со ссылкой на спецификацию услуги. |
| По какому пути трафик попадёт к сервису? | Схема прохождения трафика, условия переключения и проверка альтернативных путей к исходному серверу. |
| К чему относятся заявленные пределы? | Показатели с единицами, областью применения, условиями измерения и поведением при превышении. |
| Как проверят влияние на обычных пользователей? | Порядок проверки обычного трафика, доступные данные об ошибочных блокировках и способ проверки исправления. |
| Какой результат обозначают сроки и SLA? | Определения измеряемых событий, условия SLA и обезличенный образец отчёта. |
| Что изменится в обработке трафика и данных? | Наличие или отсутствие раскрытия TLS, доступные сигналы и ограничения; при раскрытии — схема соединений и сертификатов; состав журналов и доступ. |
| За что изменится счёт? | Два расчёта на одинаковых исходных данных, все допущения и условия дополнительных начислений. |
| Чем подтвердят результат до окончательного решения? | Программа и протокол проверки, ограничения испытания, условия остановки и возврата настроек. |
Перед выбором вернитесь к обязательным требованиям своего сервиса. Для каждого неподтверждённого пункта получите уточнение или явно зафиксируйте, кто принимает решение с этим ограничением. Пустая строка — повод продолжить проверку, а не автоматически отдать преимущество одному из кандидатов.
Обсудить задачу выбора защиты
Если нужно разобрать границы предложений, начните с краткого описания сервиса и вопроса, который поставщики пока не прояснили.
Описать задачуИсточники
- Методы и стратегии обороны от DDoS-атак
Артём Избаенков · Проверено .
Страницы PDF: 28, 29, 30, 44, 45, 46.
- Yandex DDoS Protection в Virtual Private Cloud
Yandex Cloud · Проверено .
- Protect your origin server
Cloudflare · Проверено .
- Testing and deploying Anti-DDoS
Amazon Web Services · Проверено .
- AWS Shield pricing
Amazon Web Services · Проверено .
- DDoS Simulation Testing Policy
Amazon Web Services · Проверено .
