В разборе о доступе к API команда определяла разрешённые действия. Здесь договорённость уже есть: выбранная операция нужна клиентам. Следующий вопрос — кого объединяет защитное правило и чьи обращения оно ограничит. Практический результат — матрица последствий и шесть вопросов к одному правилу.
Опишите, что именно делит общий счётчик
В актуальной инструкции DDoS-Guard разделены условия отбора, лимит, ключи группировки и действие защиты. Совпавшие ключи объединяют обращения в один счётчик. Документация описывает несколько ключей, включая IP, cookies и Authorization; их выбор определяет группировку запросов.
Для обсуждения выпишите область правила: домен, операцию и метод, затем единицу учёта, интервал и последствие превышения. Отдельно уточните источник ключа и порядок обработки запросов без него. Не подменяйте эти решения одной цифрой частоты: непонятно, к кому она относится.
Та же инструкция предупреждает о погрешности распределённого ограничения: отдельные запросы сверх порога могут пройти. Следующий расчёт намеренно идеализирован; он не воспроизводит эту реализацию и не задаёт настройку продукта.
Одинаковая нагрузка, разные потерянные обращения
Представим условную операцию получения статуса. Сто легитимных клиентов делают по три запроса: всего 300. Автоматизация, нежелательная по договорённости примера, отправляет ещё 600. Все используют один внешний адрес. В одном условном интервале идеальный счётчик пропускает первые 600 подходящих запросов, остальные отклоняет. Начальный остаток полный, других правил и повторов нет.
| Порядок в одном интервале | Легитимные: прошло / отклонено | Автоматизация: прошло / отклонено |
|---|---|---|
| Сначала 600 автоматических, затем 300 легитимных | 0 / 300 | 600 / 0 |
| Сначала 300 легитимных, затем 600 автоматических | 300 / 0 | 300 / 300 |
В обеих строках пришло 900 запросов, прошло 600, отклонено 300. Но в первой отклонены все легитимные обращения, во второй — ни одного. Суммарное число отказов в этом интервале одинаково; распределение последствий противоположно. Сам счётчик в модели не определяет допустимость автоматизации: её статус задан отдельно.
Это арифметический пример, не запись трафика и не испытание защиты. Он считает запросы, а не пострадавших людей, завершённые покупки или потерянную выручку. Для таких выводов понадобились бы отдельные данные о пользовательском результате.
Сравните варианты по границе воздействия
Ниже — собственная матрица для обсуждения, а не перечень возможностей одного поставщика. Она не выбирает победителя: каждый вариант требует проверки в архитектуре сервиса. Повышение порога тоже меняет договорённость о допустимой нагрузке, поэтому само по себе не решает задачу.
| Рассматриваемое правило | Кто разделяет ограничение | Какой вопрос остаётся |
|---|---|---|
| Полный запрет для общего IP | Все обращения, попадающие под адресный запрет | Какие согласованные сценарии исчезнут вместе с нежелательными? |
| Общий лимит для IP | Подходящие обращения разных клиентов за адресом | Кто расходует остаток раньше остальных? |
| IP и более узкая операция | Клиенты того же адреса внутри выбранной области | Проверены ли другие операции и оставшийся общий эффект? |
| Лимит по проверенной учётной сущности | Обращения, действительно связанные с этой сущностью | Как подтверждается связь и обрабатываются отсутствующие сведения? |
Сужение области позволяет отдельно рассмотреть важную операцию, но не разделяет людей внутри того же IP автоматически. Разделение по учётной сущности, в свою очередь, требует надёжной связи запроса с ней. Не нужно превращать неизвестное значение в общее постоянное исключение.
Не выдавайте группировку за проверку прав
OWASP API1:2023 отдельно требует проверять право пользователя выполнить действие над запрошенным объектом. Доступ к самой функции API ещё не означает права на любой объект, идентификатор которого передал клиент.
В рабочей схеме разделяйте значение ключа, подтверждённую учётную сущность и разрешённое действие. Группировка по строке заголовка или cookie сама по себе не доказывает ни подлинность клиента, ни его права. Правило ограничения и антибот-анализ не заменяют авторизацию приложения. Секретные значения в матрицу не переносите: достаточно описания проверяемой связи.
Разберите одно правило шестью вопросами
Начните с описания существующей конфигурации и доступных наблюдений. До производственных изменений восстановите путь клиента: какую операцию он выполняет, как замечает ограничение и может ли завершить задачу. Любое изменение требует принятого в организации согласования, безопасной проверки и способа возврата.
- Область: какие домен, метод и операция учитываются, а какие обращения остаются вне правила?
- Группа: кто может делить ключ с другими клиентами и чем подтверждён этот состав?
- Последствие: что увидит клиент при превышении и какое действие сервиса перестанет выполняться?
- Наблюдение: как раздельно увидеть разрешённые обращения, отказы и завершение выбранной задачи?
- Неизвестность: какие пробелы мешают отличить клиента, группу запросов и нежелательную автоматизацию?
- Решение: кто согласует изменение, проверит результат, задаст условие остановки и выполнит возврат?
Если наблюдается только адресный счётчик, не записывайте его группы как число людей. При отсутствии разбивки по согласованным сценариям отметьте предел проверки. Достаточно выбрать одно недостающее наблюдение и назначить ответственного; собирать персональные профили для учебной матрицы не требуется.
Завершите разбор проверяемым решением
Полезный итог — запись об одном правиле: кого оно объединяет, какие операции затрагивает, что остаётся неизвестным и какое свидетельство нужно получить следующим. Заполненная матрица не доказывает отсутствие ошибочных ограничений. Она делает их возможную область понятной до того, как изменение затронет клиентов.
Сравнивайте результат по согласованному пользовательскому сценарию, а не только по снижению числа запросов. В учебных строках одинаковые 300 отказов означали совершенно разный результат. В рабочем сервисе эту разницу сначала нужно уметь наблюдать.
