Ограничение одного IP больше недостаточно для остановки современных злоупотреблений.
Традиционное rate limiting обычно реализуется как количество запросов на IP-адрес. Эта модель проста, но NAT, операторские сети, общие точки выхода и анонимные шлюзы могут объединять легитимных пользователей и источники злоупотреблений в одну корзину. Высокий трафик с одного IP — не всегда атака; равно как распределённый низкообъёмный трафик — не всегда невиновен.
Поведение приложений неоднородно. Короткий всплеск запросов ресурсов при загрузке страницы — норма, но та же скорость на платёжном, login или API endpoint может сигнализировать о злоупотреблении. Плоская модель «N запросов в минуту» может одновременно ухудшить пользовательский опыт и пропустить настоящую атаку.
Credential stuffing, перебор учётных записей и паттерны ботов нельзя прочитать из сырых счётчиков запросов. Большое количество неудачных попыток входа на endpoint аутентификации может выглядеть незначительным в общем трафике. Счётчики, не связанные с именем пользователя, сессией, API-ключом, произвольным заголовком или поведением ответов, теряют контекст безопасности.
Защита ресурсов — отдельная проблема. Даже когда распределённые клиенты отправляют запросы с низкой скоростью на каждого клиента, суммарная нагрузка может исчерпать пул соединений backend, поисковую инфраструктуру или ёмкость загрузки файлов. Rate limiting нужен не только для остановки злоумышленника, но и для справедливого и контролируемого распределения ёмкости backend.
Подход TR7 выводит rate limiting из грубого IP-порога в контролируемую политику безопасности, применимую в измерениях пользователя, endpoint, сессии, API-ключа, составного ключа и полосы пропускания.
Наш подход
TR7 реализует rate limiting как многомерный WAAP-контроль, спроектированный вокруг совместной работы охвата, модели счётчиков и выбора действия.
Модель скользящего окна отслеживает реальное поведение трафика
TR7 отслеживает скорость запросов, соединений, ошибок и полосы пропускания в настраиваемом временном окне. Разные длины окна позволяют оценивать кратковременные всплески и устойчивую высокую нагрузку независимо.
Ключ лимита выбирается под класс атаки
Разные охваты создаются с IP, IP и user agent, именем пользователя, API-ключом, cookie, заголовком или составными ключами. Это позволяет точнее выявлять злоупотребления без штрафа для легитимных пользователей за тем же IP.
Модель действий применяется постепенно в зависимости от тяжести
Политика может отклонить запрос, применить временную блокировку, перенаправить на CAPTCHA-верификацию или наложить ограничение полосы. Не каждое нарушение карается одинаковой реакцией.
Архитектура счётчиков в процессе держит задержку низкой
Счётчики хранятся внутри пути данных — в момент принятия решения внешний вызов базы данных не требуется. Для multi-instance развёртываний поддерживается синхронизация счётчиков, обеспечивая согласованное применение политик в распределённых конфигурациях.
Возможности
TR7 Rate Limiting охватывает различные сценарии злоупотреблений — от готовых bot-политик до пользовательских составных ключей — через единую модель управления.
Встроенные профили rate limiting обеспечивают готовый к production старт
TR7 поставляется с готовыми политиками для распространённых сценариев ботов и злоупотреблений. Профиль `bot_rateLimit` может возвращать HTTP 429 при 300 запросах в минуту на IP. `bot_rateLimitStrict` применяет временную блокировку на 5 минут после 100 запросов в минуту. `bot_rateLimitCaptcha` перенаправляет на self-hosted CAPTCHA после 150 запросов в минуту.
Мягкий лимит и жёсткий потолок — реакция это подъём, а не обрыв
У каждой защиты два порога. Переход мягкого лимита запускает соразмерную реакцию — задержку, проверку, ограничение полосы, — и только жёсткий потолок отбрасывает трафик. Режим наблюдения показывает их раздельно, поэтому пороги задаются по тому, что реально делал ваш трафик, а не по чьей-то догадке. Один порог каждый раз навязывает один и тот же выбор: пропустить атаку или отбросить вместе с ней своих клиентов.
Типы триггеров разделяют простые запросы, неудачные входы и risk score
Тип `requests` отслеживает сырую скорость запросов. `failedAuthAttempts` обрабатывает неудачные попытки аутентификации отдельным счётчиком. `riskScore` позволяет принимать решения на основе бот- или поведенческого скора. `static` используется для безусловных контролей — например, обязательного CAPTCHA на определённом потоке.
Охваты IP, пользователя и составного ключа можно использовать вместе
Охват `global` мониторит суммарную нагрузку по всему сервису. Охваты `ip`, `ip+ua`, `username` и `composite` создают более точные лимиты. Составная структура может объединять произвольный заголовок, cookie, API-ключ или поле из тела запроса для создания пользовательского ключа счётчика. Эта гибкость позволяет B2B API и multi-tenant приложениям точнее отражать реальные лимиты использования.
Один запрос можно оценивать одновременно по нескольким политикам rate
В пуле сервисов может быть несколько активных политик rate limiting одновременно. Например, один и тот же запрос может подпадать под IP-охватный DDoS-лимит и user-охватный fair-use лимит. Каждая политика ведёт собственный независимый счётчик. Эта структура позволяет строить многоуровневую модель защиты вместо единого порога.
Действие временной блокировки удерживает ключ заблокированным даже после снижения скорости
При срабатывании действия `block` затронутый ключ удерживается в таблице блокировок на настроенный срок. Это не даёт злоумышленнику генерировать короткий всплеск и сразу возвращаться после замедления. `blockDuration` задаётся на политику. Эта модель обеспечивает более жёсткий контроль против интенсивных волн ботов и повторных источников злоупотреблений.
Self-hosted CAPTCHA направляет подозрительный трафик на верификацию вместо жёсткой блокировки
Действие `captcha` может перенаправлять трафик, превысивший порог или отмеченный как рискованный, на поток верификации вместо полного отсечения. Провайдер по умолчанию — `tr7Standard`. После успешной верификации запрос пользователя продолжается. Этот подход предлагает более взвешенную альтернативу блокировке в сценариях, где приоритет — разделение реальных пользователей от автоматики.
Правило Bandwidth Limit обеспечивает условное шейпинг трафика
TR7 может отслеживать входящую и исходящую скорость полосы пропускания помимо счётчиков запросов. С действием `bwLimit` трафик, соответствующий условию, можно поместить под собственное ограничение полосы. Это полезно для endpoint загрузки файлов, endpoint с большими ответами или высокообъёмного потребления данных из одного источника — обеспечивая доступность backend без полного отсечения.
Переменные сессий AAM обеспечивают rate limiting на пользователя
Информация, такая как имя пользователя из сессии AAM, может использоваться как ключ rate limiting. Это позволяет назначать отдельный fair-use лимит каждому пользователю после входа. Бесплатные и платные планы, внутренние и внешние группы пользователей или разные уровни ролей — каждый может управляться своими лимитами. Это обеспечивает более точный контроль в API и портальных сценариях, где IP-лимиты недостаточны.
Операционная глубина
Чтобы политики rate limiting были эффективными, время жизни счётчиков, размер таблицы, синхронизация кластера, наблюдаемость и поведение при откате — всё это должно управляться с операционной ясностью.
Адаптивный размер таблицы счётчиков
Разные охваты работают с разными размерами таблиц. Глобальный охват использует один ключ, тогда как охваты IP и составной могут хранить значительно больше записей. Длинные ключи, такие как IP в сочетании с user agent, могут потреблять больше памяти, поэтому выбор охвата следует делать исходя из ожидаемого профиля трафика.
Multi-instance синхронизация
Синхронизация счётчиков между instance поддерживается в кластерных развёртываниях. Instance с одним ключом политики могут обнаруживать друг друга и обмениваться состоянием счётчиков. Это затрудняет злоумышленнику обход лимита переключением между instance в среде с балансировкой нагрузки.
Непрерывность счётчиков при перезагрузках
Стабильное именование таблиц, привязанное к идентификатору политики, помогает сохранить состояние счётчиков при циклах перезагрузки. Когда та же политика продолжается под тем же именем, счётчики не сбрасываются без необходимости. Это снижает риск появления пробела в безопасности при обслуживании или обновлении конфигурации.
Уровень валидации политики
Политики rate limiting проходят валидацию схемы перед развёртыванием. Недопустимые охваты, типы триггеров или определения действий не могут попасть в production-конфигурацию. Эта проверка снижает риск того, что неправильно настроенное правило безопасности нарушит живой трафик.
Совместимость цепочки действий
Политика ботов, правила блокировки учётных записей и решения WAAP могут одновременно применяться к одному запросу. Порядок приоритетов и поведение совпадений управляются конфигурацией. Rate limiting работает не изолированно, а как часть более широкого конвейера решений WAAP.
Аудит и наблюдаемость
При каждом срабатывании ID правила, действие, ключ и информация о скорости могут логироваться. Эти записи можно пересылать в SIEM для анализа инцидентов и отчётности. Операционные команды могут отслеживать наиболее часто срабатывающие ключи, самые загруженные endpoint и тенденции блокировок.
Когда применять
Многоуровневые лимиты на пользователя и IP для API-шлюза
Организации, предлагающие B2B API, могут одновременно применять лимит плана на пользователя и ограничение злоупотреблений на IP. TR7 выполняет user-охватную fair-use политику и IP-охватный жёсткий предел параллельно.
Контроль неудачных попыток на login endpoint
Большое количество неудачных вводов учётных данных на экране аутентификации может быть индикатором brute force. TR7 может отслеживать сбои по ключу имени пользователя + IP и применять нарастающие действия — сначала CAPTCHA, затем временная блокировка.
Защита по endpoint в e-commerce потоке
Короткий всплеск запросов на страницах товаров может быть нормой, но тот же паттерн на платёжном endpoint — риск. TR7 может использовать условия endpoint и разные временные окна, чтобы ограничить злоупотребления при оформлении заказа без ухудшения загрузки страниц.
Контроль полосы пропускания на трафике загрузки файлов
Один источник может исчерпать I/O-ёмкость backend через высокообъёмные загрузки. TR7 использует правило Bandwidth Limit, чтобы условно ограничить этот трафик, сохраняя доступность сервиса для других пользователей.
Часто задаваемые вопросы
Влияет ли лимит rate per-IP на реальных пользователей за NAT или общим выходом?
В чём разница между действием block и действием deny?
Как работает интеграция self-hosted CAPTCHA?
Может ли к одному endpoint применяться более одной политики rate?
Правило Bandwidth Limit работает иначе, чем счёт запросов?
Могут ли разные instance в кластере делить один счётчик?
Настройте rate limiting под контекст вашего приложения
Многоуровневая политика скорости по измерениям IP, пользователя, API-ключа и полосы пропускания. Проведём вас через живую конфигурацию на ваших собственных сервисах.