Decisões modernas de tráfego não podem mais ser tomadas apenas com base em IP e porta.
A lógica de ACL clássica de ADC e firewall foi construída em IP, sub-rede, porta e protocolo por muito tempo. Esse modelo é suficiente para controle de acesso de rede simples, mas o tráfego moderno de web, API, bot e WAAP não é tão simples.
Ao tomar uma decisão hoje, perguntar apenas "qual é o IP de origem?" não é suficiente. De qual país vem a requisição? Qual ASN? Para qual path está indo? Qual cookie está presente? Qual papel está escrito no JWT? O conjunto de headers se assemelha a um browser real? O fingerprint TLS é suspeito? Quantos pontos de pontuação WAAP esta requisição recebeu? Como o mecanismo de bot classificou este usuário?
Na maioria dos produtos, esses sinais ficam em lugares separados. A regra de roteamento está em um lugar, a pontuação WAAP em outro, a decisão de bot em outro, a reescrita de header em outro ainda, e a limitação de taxa em outro. Isso complica as operações e produz decisões inconsistentes.
O problema maior é que condições complexas geralmente requerem código. Escrever uma regra como "se este header está presente, este cookie está ausente, o path começa com /api/, a pontuação WAAP está acima de 5, mas a origem não é um bot conhecido" requer scripts, linguagens de política proprietárias ou programação específica do fornecedor na maioria dos produtos.
A camada de Condições Smart ACL do TR7 ADC resolve esse problema: decisões de tráfego são definidas a partir da UI usando mais de 60 critérios, cadeias de Smart Functions e grupos AND/OR/NOT. A regra se torna não apenas uma lista de IPs, mas uma estrutura de decisão que lê o significado do tráfego.
Nossa abordagem
O TR7 trata as condições ACL como a unidade fundamental das decisões de aplicação e segurança — não como um filtro de endereços de rede.
Reconhecimento de tráfego em mais de 60 critérios
O mecanismo Smart ACL vai muito além de IP e porta. IP de origem, país, cidade, IP de destino, porta de destino, método HTTP, URL, path, query, header, cookie, corpo da requisição, corpo da resposta, TLS SNI, cifra TLS, protocolo TLS, fingerprint JA3, ID de ataque WAAP, grupo de ataque WAAP, classe de bot, categoria de lista negra e estado de cache podem ser todos usados como condições. Isso permite que decisões de segurança e roteamento sejam tomadas em contexto de aplicação completo.
Grupos de condições AND / OR / NOT
Uma ACL pode ser usada sozinha ou combinada com outras ACLs em grupos lógicos. Um grupo interno funciona com AND ou OR; uma condição pode ser invertida para dar comportamento NOT. Por exemplo: "Path começa com /login" AND "País de origem não está na lista de permissões" AND "Pontuação de bot é alta" MAS "Não é um bot conhecido" — essa estrutura torna as políticas de segurança complexas legíveis.
Encadeamento de Smart Functions
As Smart Functions do TR7 transformam valores brutos de tráfego em entradas acionáveis. Operações de decodificação Base64, consulta JSON path, análise de header/payload JWT, consulta XML, correspondência regex, substituição de string, lowercase/uppercase, digest, máscara de IP, IP para país e lookup de mapa/lista podem ser todas encadeadas. A ACL não apenas pergunta "este valor de header corresponde?"; ela analisa JSON dentro do header, extrai um claim JWT ou consulta um campo dentro do corpo.
Grupos ACL reutilizáveis
Condições frequentemente usadas são definidas uma vez e reutilizadas em diferentes regras. ACLs integradas ou personalizadas como "é uma extensão de arquivo estático?", "um cookie de autenticação está presente?", "é um cache hit?", ou "foi bloqueado pelo WAAP?" podem ser compartilhadas em muitas regras. Esse padrão reduz a duplicação de regras, centraliza mudanças e reduz o risco de erro operacional.
Capacidades
As Condições Smart ACL transformam sinais de tráfego em condições legíveis e ações executáveis em mais de 60 critérios.
Correspondência de path HTTP, URL e método
O TR7 pode escrever condições contra path, path+query, URL completa e método HTTP. Os tipos de correspondência podem ser prefixo, sufixo, substring ou regex. Requisições que começam com /api/, o path /admin, o método POST ou padrões de URL específicos contendo uma query string são todos expressos dentro de uma única definição de ACL.
Inspeção de headers e cookies
Headers de requisição, headers de resposta, cookies do usuário e cookies provenientes do backend podem ser todos usados dentro de uma ACL. Seleção de rota baseada no header X-Tenant-ID, redirecionamento para login quando o cookie session_id está ausente, verificação de bot baseada no conteúdo do User-Agent e comportamento de segurança personalizado baseado em um cookie de resposta são todos escritos nessa camada.
IP de origem, país, cidade e ASN
Os critérios de ACL não se limitam a IP de origem ou CIDR. Condições baseadas em país, cidade e ASN também podem ser definidas. Restrição de acesso a países específicos, roteamento personalizado para usuários de cidades específicas, verificação adicional para tráfego de ASNs específicos ou uma política de bot mais agressiva para ASNs de datacenter são todos suportados.
Condições de TLS e fingerprint
Sinais de TLS SNI, cifra TLS, protocolo TLS, presença de SNI e fingerprint JA3 podem ser incluídos em condições. Atribuir uma pontuação de confiança menor a clientes usando TLS 1.0, rejeitar conexões sem SNI, enviar tráfego que corresponde a uma lista de fingerprint JA3 conhecido como ruim para CAPTCHA, ou colocar clientes usando cifras fracas em modo de monitoramento são todos expressáveis.
Inspeção de corpo de requisição e resposta
A ACL pode operar sobre conteúdo amostrado do corpo de requisição ou resposta. Correspondência de string ou regex dentro do corpo é suportada. Verificação de transação de alto valor dentro de um corpo JSON, captura de um padrão específico em um campo de formulário, adição de um header quando um marcador específico está presente no corpo da resposta ou aplicação de limitação de taxa baseada no conteúdo de payload de API são todos possíveis.
Consultas JSON / XML / JWT
Com Smart Functions, conteúdo JSON, XML e JWT pode ser transformado em condições ACL. JWT payload.role == "admin", transaction.amount > 10000 em um corpo JSON, verificar se um path específico existe em XML ou verificar o algoritmo em um header JWT são todas condições que fornecem flexibilidade significativa para segurança de API e política de acesso.
Integração com WAAP
O mecanismo Smart ACL também pode usar decisões WAAP como condições: ID de ataque WAAP, grupo de ataque WAAP, pontuação WAAP, se o WAAP bloqueou a requisição, se foi sinalizada como um ataque WAAP. Mostrar CAPTCHA quando a pontuação WAAP é 5+, rotear requisições no grupo de SQL injection para um formato de log especial ou enviar resultados WAAP em modo monitor para um backend separado são cenários de exemplo.
Classificação de bot e cliente
Classificações de browser, móvel, bot e user agent podem ser usadas dentro de uma ACL. Enviar usuários móveis para um backend móvel, aplicar um limite de taxa menor para tráfego sinalizado como bot, conceder exceções a mecanismos de busca conhecidos e aplicar um perfil de segurança diferente para clientes não-browser podem ser todos definidos.
Critérios de taxa e tamanho
O mecanismo ACL pode usar sinais de volume e tamanho de tráfego: tamanho da requisição, tamanho da resposta, contagem de conexões de frontend, taxa de requisição, taxa de sessão, tempo de resposta, contagem de servidores ativos de backend e código de status HTTP. Mover novo tráfego para um pool de fallback quando a contagem de backends ativos cai para 1, ou fazer cache de um endpoint específico quando o tempo de resposta aumenta, são ambos expressos por esses critérios.
Uso de mapa e lista personalizados
A correspondência baseada em mapa e lista é suportada. É usada para grandes listas de IP, listas de domínio, listas de URL, listas de ID de cliente ou tabelas chave-valor personalizadas. Roteamento diferente baseado em uma lista de clientes VIP, bloqueio de IPs em uma lista de bloqueio ou aplicação de uma política CORS baseada em uma lista de domínios de parceiros são todos gerenciados com esse padrão.
Correspondência de categoria de IP em lista negra
Categorias de reputação de IP ou de lista negra podem ser incluídas em condições. Categorias de botnet, proxy, Tor, malware ou spam podem ser vinculadas a comportamentos diferentes. Servir CAPTCHA para um IP de categoria de proxy aberto, colocar nós de saída Tor em modo de monitoramento ou rejeitar diretamente IPs na categoria de malware são usos de exemplo.
ACLs integradas
O TR7 fornece diversas ACLs comuns prontas para uso: é uma extensão de arquivo estático, um cookie de autenticação está presente, é um cache hit, foi bloqueado pelo WAAP. Essas ACLs integradas evitam que os operadores reescrevam suas condições mais frequentemente necessárias e mantêm os conjuntos de regras mais enxutos.
Condição manual — modo especialista
Em casos extremos onde os critérios padrão da UI não são suficientes, um usuário especialista pode escrever uma condição manual. Isso preserva o mecanismo visual de regras do TR7 enquanto fornece flexibilidade de saída de escape. Esse modo não é para uso diário — destina-se a operações avançadas e integrações personalizadas.
Condições de limitação de taxa baseadas em usuário
Valores de taxa de requisição, taxa de conexão e taxa de erro baseados em usuário podem ser usados dentro de uma ACL. Quando combinados com um claim JWT, cookie, header ou ID de usuário, políticas de limitação de taxa no nível de tenant ou usuário podem ser construídas.
Condições de estado de cache e estado de autenticação
Comportamentos diferentes podem ser acionados com base em se uma requisição ou resposta é um cache hit. Presença de cookie de autenticação ou valores de auth HTTP também podem ser usados no mecanismo ACL. Isso unifica o comportamento de AAM e ADC sob a mesma lógica de regras.
Profundidade operacional
As Condições Smart ACL não são apenas sintaxe de regras — abrangem estrutura de grupos de condições, tipos de correspondência, modelo de atualização e limites de amostragem de corpo.
Estrutura de grupos de condições
As condições Smart ACL são definidas em grupos. As condições dentro de um grupo são combinadas com AND ou OR. Uma condição pode ser invertida para dar comportamento NOT. Os grupos externos formam uma estrutura lógica mais ampla. Essa abordagem divide políticas complexas em peças pequenas e legíveis.
ID de ACL e reutilização
Cada ACL é identificada por um ID único. As regras referenciam esse ID. A mesma ACL pode ser reutilizada em diferentes regras de tráfego, políticas de limitação de taxa, regras de redirect ou ações de segurança. Quando a ACL muda, a atualização é propagada automaticamente para todas as regras vinculadas.
Tipos de correspondência
Diferentes tipos de correspondência são suportados para condições baseadas em texto: correspondência por prefixo, sufixo, substring, regex e correspondência com ou sem diferenciação de maiúsculas/minúsculas. Essa flexibilidade cobre tanto estruturas de regras simples quanto complexas.
Encadeamento de Smart Functions
As Smart Functions podem ser usadas individualmente ou encadeadas. Por exemplo: analisar o payload JWT, extrair o campo de papel, converter para minúsculas, comparar com uma lista específica. Isso transforma dados brutos de tráfego em entradas de decisão significativas.
Limite de amostragem de corpo
A inspeção do corpo de requisição e resposta opera sobre um tamanho de conteúdo amostrado. Isso fornece um modelo equilibrado entre desempenho e consciência de conteúdo. Para corpos muito grandes, capacidades dedicadas de modificação ou mascaramento de corpo são usadas separadamente.
Modelo de atualização L7 e L3
As condições Smart ACL podem ser usadas em diferentes camadas. Regras no lado L7 podem exigir um soft-reload na mudança de configuração. Regras no lado do firewall L3 são aplicadas por meio de seu próprio ciclo de sincronização de firewall. Nem toda mudança é aplicada pelo mesmo mecanismo — um modelo de atualização por camada se aplica.
ACL integrada de extensão de arquivo estático
Extensões comuns para detecção de conteúdo estático são fornecidas de fábrica: .css, .js, .jpg, .png, .svg, .woff, .pdf, .mp4, .webp, .docx, .xlsx e tipos de arquivo similares. Isso é frequentemente usado em cenários de cache, redução de log e exceções de limitação de taxa.
Flexibilidade do conversor Lua
Algumas Smart Functions funcionam diretamente com o mecanismo de tráfego integrado; algumas funções especializadas rodam por uma camada adicional de conversor. Isso dá às operações JSON, XML, JWT e de string personalizada uma superfície de expressão mais ampla.
Quando usar
Limitação de taxa de API por claim JWT
Em uma camada de API, usuários admin recebem um limite maior e usuários comuns um limite menor. A Smart ACL lê o campo de papel do payload JWT e seleciona a política de limitação de taxa adequadamente. JWTPAYLOAD(role) == admin → limite de taxa alto; caso contrário → limite de taxa padrão.
CAPTCHA baseado em pontuação WAAP
Uma requisição é sinalizada como suspeita pelo WAAP, mas não claramente o suficiente para ser bloqueada imediatamente. A Smart ACL avalia a pontuação WAAP e a classe de bot juntas. Quando wafScore >= 5 AND NOT knownBot, o CAPTCHA é apresentado.
Separação de backend móvel vs. desktop
Usuários móveis são roteados para um backend e usuários de desktop para outro. A Smart ACL usa o user agent e o sinal de classificação móvel. mobile == true → backend móvel; mobile == false → backend desktop.
Detecção de bot via fingerprint JA3
Um mapa personalizado de fingerprints de clientes maliciosos conhecidos é definido como uma ACL. Quando o fingerprint TLS de entrada corresponde a essa lista, o tráfego é bloqueado ou enviado para CAPTCHA. ja3 in bad_fingerprint_list → deny / captcha.
Controle adicional baseado em valor no corpo JSON
Em uma API financeira, o valor de transferência é lido de dentro do corpo JSON. Quando o valor excede um limite definido, um MFA adicional é acionado no lado do AAM ou a transação é roteada para um backend separado. JSONQUERY(transaction.amount) > 10000 → step-up MFA.
Combinando sinais de país, ASN e WAAP
Tráfego de certos países é normalmente permitido, mas quando o mesmo tráfego chega de um ASN de hospedagem e a pontuação WAAP está elevada, um desafio adicional é aplicado. country in allowedCountries AND asn in hostingProviders AND wafScore >= 4 → challenge.
Perguntas frequentes
Quantos tipos de critérios diferentes podem ser usados com Smart ACL?
Como os grupos de condições AND/OR/NOT são configurados?
O que o encadeamento de Smart Functions faz?
A mesma ACL pode ser reutilizada em múltiplas regras?
Como as atualizações de ACL afetam o tráfego ao vivo?
Como a pontuação WAAP e o sinal de bot são usados dentro de uma ACL?
Leve suas decisões de tráfego além do endereço IP
Segurança, roteamento e limitação de taxa em um único mecanismo de regras — em mais de 60 critérios, cadeias de Smart Functions e grupos AND/OR/NOT. Vamos percorrer uma configuração ao vivo no seu próprio ambiente.