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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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çõ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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.