O rate limiting tradicional geralmente é aplicado como uma contagem de requisições por endereço IP. Esse modelo é simples, mas NAT, redes de operadoras, pontos de saída compartilhados e gateways anônimos podem colocar usuários legítimos e fontes de abuso no mesmo balde. Alto tráfego de um único IP nem sempre é um ataque; da mesma forma, tráfego distribuído de baixo volume nem sempre é inocente.
O comportamento da aplicação não é uniforme. Uma rajada curta de requisições de assets durante o carregamento de uma página é normal, mas a mesma taxa em um endpoint de pagamento, login ou API pode sinalizar abuso. Um modelo simples de "N requisições por minuto" pode prejudicar a experiência do usuário e também deixar passar ataques reais.
Credential stuffing, enumeração de contas e padrões de bots não podem ser lidos apenas a partir de contagens brutas de requisições. Um grande número de tentativas de login com falha em um endpoint de autenticação pode parecer baixo no total de tráfego. Contadores não correlacionados com nome de usuário, sessão, chave de API, header personalizado ou comportamento de resposta perdem seu contexto de segurança.
A proteção de recursos é uma preocupação separada. Mesmo quando clientes distribuídos enviam requisições a uma taxa baixa por cliente, a carga agregada pode esgotar o pool de conexões de um backend, a infraestrutura de busca ou a capacidade de download de arquivos. O rate limiting é necessário não apenas para impedir um atacante, mas para distribuir a capacidade do backend de forma justa e controlada.
A abordagem do TR7 eleva o rate limiting de um limite grosseiro baseado em IP para uma política de segurança controlada que pode ser aplicada em dimensões de usuário, endpoint, sessão, chave de API, chave composta e largura de banda.
O TR7 implementa o rate limiting como um controle WAAP multidimensional projetado em torno do escopo, do modelo de contador e da seleção de ação trabalhando juntos.
O TR7 rastreia taxas de requisições, conexões, erros e largura de banda dentro de uma janela de tempo configurável. Diferentes comprimentos de janela permitem que picos de curta duração e carga elevada sustentada sejam avaliados de forma independente.
Diferentes escopos podem ser criados usando IP, IP e user agent, nome de usuário, chave de API, cookie, header ou chaves compostas. Isso permite que o abuso seja detectado com mais precisão sem penalizar usuários legítimos por trás do mesmo IP.
Uma política pode negar a requisição, aplicar um bloqueio temporário, redirecionar para verificação CAPTCHA ou impor um limite de largura de banda. Nem toda violação é tratada com o mesmo nível de resposta.
Os contadores são mantidos dentro do caminho de dados — nenhuma chamada a banco de dados externo é necessária no momento da decisão. Implantações de múltiplas instâncias são suportadas por sincronização de contadores, permitindo aplicação consistente de políticas em configurações distribuídas.
O TR7 Rate Limiting cobre diferentes cenários de abuso — desde políticas prontas para bots até chaves compostas personalizadas — por meio de um único modelo de gerenciamento.
O TR7 vem com políticas prontas para cenários comuns de bots e abusos. O perfil `bot_rateLimit` pode retornar HTTP 429 com 300 requisições por minuto por IP. `bot_rateLimitStrict` pode aplicar um bloqueio temporário de 5 minutos após 100 requisições por minuto. `bot_rateLimitCaptcha` pode redirecionar para um fluxo CAPTCHA self-hosted após 150 requisições por minuto.
O tipo `requests` rastreia a taxa bruta de requisições. `failedAuthAttempts` lida com tentativas de autenticação com falha com um contador dedicado. `riskScore` pode tomar decisões com base em uma pontuação de bot ou comportamental. `static` é usado para controles incondicionais, como CAPTCHA obrigatório em um fluxo específico.
O escopo `global` monitora a carga agregada em um serviço inteiro. Os escopos `ip`, `ip+ua`, `username` e `composite` criam limites mais direcionados. A estrutura composta pode combinar um header personalizado, cookie, chave de API ou um campo do corpo da requisição para produzir uma chave de contador personalizada. Essa flexibilidade permite que aplicações B2B de API e multi-tenant reflitam limites de uso real com mais precisão.
Um pool de serviço pode ter múltiplas políticas de rate limiting ativas ao mesmo tempo. Por exemplo, a mesma requisição pode estar sujeita tanto a um limite de DDoS com escopo de IP quanto a um limite de uso justo com escopo de usuário. Cada política rastreia seu próprio contador independente. Essa estrutura possibilita um modelo de proteção em camadas em vez de um único limite.
Quando a ação `block` é acionada, a chave afetada é mantida na tabela de bloqueios pela duração configurada. Isso impede que um atacante gere uma rajada curta e retorne imediatamente depois de diminuir a velocidade. O `blockDuration` é definido por política. Esse modelo oferece controle mais rígido contra ondas intensas de bots e fontes de abuso repetidas.
A ação `captcha` pode redirecionar tráfego que excedeu o limite ou foi sinalizado como arriscado para um fluxo de verificação em vez de cortá-lo completamente. O provedor padrão é `tr7Standard`. Após verificação bem-sucedida, a requisição do usuário prossegue. Essa abordagem oferece uma alternativa mais equilibrada ao bloqueio em cenários onde separar usuários reais da automação é a prioridade.
O TR7 pode rastrear taxas de largura de banda de entrada e saída além das contagens de requisições. Com a ação `bwLimit`, o tráfego que corresponde a uma condição específica pode ser colocado sob seu próprio limite de largura de banda. Isso é útil para endpoints de download de arquivos, endpoints que produzem respostas grandes ou consumo de dados de alto volume de uma única fonte — mantendo o backend disponível sem cortá-lo completamente.
Informações como o nome de usuário de uma sessão do AAM podem ser usadas como chave de rate limiting. Isso permite que um limite de uso justo separado seja atribuído a cada usuário após o login. Planos gratuitos e pagos, grupos de usuários internos e externos, ou diferentes níveis de função podem ser governados por limites diferentes. Isso fornece controle mais preciso em cenários de API e portal onde os limites baseados em IP ficam aquém.
Para que as políticas de rate limiting sejam eficazes, o tempo de vida dos contadores, o tamanho das tabelas, a sincronização de cluster, a observabilidade e o comportamento de rollback devem ser gerenciados com clareza operacional.
Diferentes escopos operam com diferentes tamanhos de tabela. O escopo global usa uma única chave, enquanto os escopos de IP e compostos podem conter um número muito maior de entradas. Chaves longas como IP combinado com user agent podem consumir mais memória, portanto a seleção do escopo deve ser feita em relação ao perfil de tráfego esperado.
A sincronização de contadores entre instâncias é suportada em implantações de cluster. Instâncias que compartilham a mesma chave de política podem se descobrir e trocar o estado do contador. Isso dificulta para um atacante ignorar um limite alternando entre instâncias em um ambiente com carga distribuída.
A nomenclatura estável de tabelas vinculada à identidade da política ajuda a preservar o estado do contador entre os ciclos de recarga. Quando a mesma política continua com o mesmo nome, os contadores não são redefinidos desnecessariamente. Isso reduz o risco de uma brecha de segurança se abrir durante manutenção ou atualizações de configuração.
As políticas de rate limiting passam por validação de esquema antes de serem implantadas. Definições inválidas de escopo, tipo de trigger ou ação não podem entrar na configuração de produção. Essa verificação reduz o risco de uma regra de segurança mal configurada interromper o tráfego em produção.
Política de bots, regras de bloqueio de conta e decisões do WAAP podem ser executadas simultaneamente na mesma requisição. A ordem de prioridade e o comportamento de correspondência são governados pela configuração. O rate limiting, portanto, opera não isoladamente, mas como parte do pipeline de decisão mais amplo do WAAP.
Em cada acionamento, o ID da regra, a ação, a chave e as informações de taxa podem ser registrados. Esses registros podem ser encaminhados para um SIEM para análise de incidentes e relatórios. As equipes de operações podem monitorar as chaves acionadas com mais frequência, os endpoints mais movimentados e as tendências de bloqueio ao longo do tempo.
Organizações que oferecem APIs B2B podem impor um limite de plano por usuário e um limite de abuso por IP simultaneamente. O TR7 executa uma política de uso justo com escopo de usuário e um limite rígido com escopo de IP em paralelo.
Um alto número de credenciais incorretas em uma tela de autenticação pode ser um indicador de brute force. O TR7 pode rastrear falhas usando uma chave combinada de nome de usuário e IP e aplicar ações escalonadas — CAPTCHA primeiro, depois um bloqueio temporário.
Uma rajada curta de requisições em páginas de produtos pode ser normal, mas o mesmo padrão em um endpoint de pagamento é um risco. O TR7 pode usar condições de endpoint e diferentes janelas de tempo para limitar o abuso no checkout sem degradar a experiência de carregamento de página.
Uma única fonte pode consumir a capacidade de I/O de um backend por meio de downloads de alto volume. O TR7 usa a Regra de Limite de Largura de Banda para limitar condicionalmente esse tráfego, mantendo o serviço disponível para outros usuários.
Política de rate em múltiplas camadas entre dimensões de IP, usuário, chave de API e largura de banda. Vamos mostrar uma configuração ao vivo nos seus próprios serviços.