As regras de tráfego tradicionais normalmente decidem com base em host, path, método e header. No tráfego moderno de API, no entanto, o valor de decisão real geralmente fica dentro do corpo JSON. O papel de um usuário, identidade de tenant, tipo de transação, valor, código de produto ou nome de operação GraphQL pode não aparecer na URL.
Isso deixa o operador com duas opções ruins. Ou lógica adicional de roteamento e segurança é inserida no código da aplicação, ou o ADC permanece cego no nível de header e path. Nenhuma abordagem é adequada para segurança moderna de API.
Em serviços que usam JWT, o mesmo problema existe dentro do token. Apenas o valor do header de Authorization é visível na superfície; o papel, grupo, tenant ou scope necessário para a decisão está armazenado no payload JWT. Se esses campos não puderem ser lidos, a política de tráfego não pode usar o contexto de identidade.
O modelo correto é tornar o corpo JSON e o conteúdo JWT uma parte nativa da linguagem de expressão. As consultas JSONPath devem ser usáveis junto com condições de tráfego, regras de segurança, enriquecimento de logs e ações de mascaramento de dados — tudo no mesmo lugar.
O TR7 JSON Path Operations oferece esse modelo: JSONQUERY, JWTHEADER e JWTPAYLOAD vinculam o conteúdo da API às decisões ADC e WAAP.
O TR7 lê conteúdo JSON por meio do motor de expressões FX e o leva a regras de tráfego, controles de segurança, enriquecimento de logs e edição de resposta.
JSONQUERY direciona campos específicos no corpo da requisição ou resposta usando uma expressão JSONPath. Esses campos podem então ser usados como condições de tráfego, entradas ACL ou valores de log.
Campos de header e payload dentro de um JWT podem ser lidos usando a mesma semântica JSONPath. Papel, scope, tenant ou identidade do usuário podem ser incorporados às decisões de tráfego.
Valores dentro do corpo se tornam condições tão naturais quanto verificações de path ou header. Ações podem ser selecionadas com base em `$.tenant_id`, `$.user.role` ou `$.operationName` como qualquer outra expressão.
Campos JSON sensíveis podem ser mascarados ou substituídos no lado da resposta. A prevenção de vazamento de dados é aplicada não apenas em logs, mas diretamente no corpo retornado ao cliente.
O JSON Path Operations conecta o corpo JSON e o conteúdo JWT às camadas de regra, segurança, log e mascaramento do TR7.
JSONQUERY consulta campos JSON aninhados diretamente dentro do corpo. Expressões como `$.user.role`, `$.items[0].sku` ou `$.payment.amount` podem ser avaliadas como condições de regra. Os operadores podem agir sobre dados de decisão que nunca aparecem na URL ou nos headers. Isso torna possível gerenciar o tráfego de API pelo seu contexto de conteúdo real.
O TR7 pode usar um campo lido do JSON como condição de uma regra de tráfego. Por exemplo, o tráfego pode ser roteado para diferentes pools de backend com base no valor de `tenant_id`. Se o valor de `role` não for aceitável, a requisição pode ser rejeitada. A política de tráfego consciente do corpo é estabelecida sem modificar o código da aplicação.
A função JWTPAYLOAD pode ler campos de claim dentro do token. Papel do usuário, grupo, scope, tenant ou identidade da aplicação podem ser incorporados à decisão de tráfego dessa forma. Isso impede que o header de Authorization seja tratado apenas como um token bruto. O TR7 transforma o conteúdo do token em um sinal de política.
A função JWTHEADER pode ler campos de header do token. Verificações de metadados de algoritmo, ID de chave ou tipo de token podem ser realizadas. Essas informações podem ser usadas em regras de segurança, entradas de log ou cenários de acesso condicional. O token se torna um objeto auditável, não apenas um valor de passagem.
Algumas aplicações carregam estruturas de dados semelhantes a JSON em campos de header personalizados. O TR7 pode tratar esses campos como sinais analisáveis dentro do motor de expressões também. Dados estruturados em headers — não apenas no corpo — se tornam parte da avaliação de regras. Essa flexibilidade importa em cenários de integração legada.
Em cenários de API gateway, valores como `operation`, `tenant`, `region` ou `product` dentro do corpo podem servir como sinais de roteamento. O TR7 pode encaminhar tráfego para diferentes pools de backend com base nesses campos. Isso permite separação multi-aplicação ou multi-tenant sob um único endpoint. A lógica de roteamento não precisa estar incorporada no código da aplicação.
Campos selecionados do corpo JSON ou JWT podem ser adicionados às linhas de log. Email do usuário, identidade de tenant, tipo de transação ou pontuação de risco podem aparecer como campos dedicados no log. Isso fortalece a correlação no SIEM. Extrair apenas os campos necessários em vez de registrar o corpo completo também suporta minimização de dados.
O TR7 pode proteger valores sensíveis no corpo JSON de resposta usando ações de máscara ou substituição. Números de cartão, identificações nacionais, IDs de pacientes, endereços de email ou campos semelhantes podem ser direcionados por regex ou por path. Isso reduz o risco de vazamento de dados sem exigir alterações de código da equipe de aplicação. Funciona em camadas juntamente com a capacidade de mascaramento de dados sensíveis.
Campos permitidos ou obrigatórios dentro do corpo JSON podem ser vinculados a uma política de segurança. Campos desconhecidos, parâmetros obrigatórios ausentes ou estruturas excessivamente aninhadas podem ser bloqueados. Isso reduz o desvio de schema de API e a superfície de injeção. A inspeção de conteúdo JSON vai além das assinaturas de segurança negativa.
Payloads JSON profundamente aninhados ou com chaves excessivas podem esgotar recursos de aplicação e parser. O TR7 pode impor limites como profundidade de aninhamento JSON e contagem de chaves como política de segurança. Isso reduz o impacto de tentativas de DoS de API e estruturas de corpo inesperadas. Os limites podem ser ajustados por sensibilidade do endpoint.
Se o JSON não puder ser analisado, a requisição não é tratada como um corpo de API confiável. O TR7 pode rejeitar ou registrar em log requisições com JSON malformado antes de encaminhá-las ao backend. Isso reduz erros de análise inesperados na camada de aplicação. Também fornece visibilidade para distinguir tráfego de ataque de clientes com mau funcionamento.
Um resultado JSONQUERY pode ser usado junto com funções de string, regex, map, list, IP ou hash. Por exemplo, um valor de tenant é extraído do JSON, pesquisado em uma tabela de mapa, e o resultado orienta uma decisão de roteamento ou bloqueio. Isso torna a consulta JSON parte do motor de política, não apenas um auxiliar independente. Decisões complexas de API podem ser expressas no editor visual de regras.
As operações JSON são operadas juntamente com buffering de corpo, tratamento de erros de análise, comportamento de campos JWT, minimização de logs, edição de resposta e limites de desempenho.
O corpo deve estar legível antes que uma consulta JSON possa ser executada. Regras conscientes do corpo, portanto, requerem mais processamento do que regras apenas de header. Devem ser aplicadas apenas em endpoints onde são genuinamente necessárias.
Se o JSON não puder ser analisado, a política pode produzir uma rejeição, uma entrada de log ou uma ação diferente. Se um endpoint de API espera JSON, um payload malformado não deve ser encaminhado ao backend. Esse comportamento melhora a segurança do endpoint.
Ler conteúdo JWT e verificar o token não são a mesma operação. Se os valores de claim JWT forem usados em decisões de tráfego, a verificação de assinatura e a política de fonte de confiança devem ser configuradas separadamente. Caso contrário, um atacante pode criar claims falsos.
Extrair apenas os campos necessários em vez de registrar o corpo JSON completo é a abordagem mais segura. Campos como tenant, operation ou status podem ser registrados; campos sensíveis devem ser mascarados. Isso equilibra a visibilidade no SIEM com a proteção de dados.
O mascaramento JSON de resposta opera no corpo, portanto o tamanho da resposta e o tipo de conteúdo importam. O impacto no desempenho e na memória em respostas muito grandes deve ser planejado. O direcionamento correto de endpoint e campo é necessário para aplicar a proteção de dados sensíveis de forma eficaz.
A análise JSON e a consulta de path custam mais do que verificações de header. Se múltiplas consultas JSON forem usadas dentro da mesma requisição, a reutilização de resultados é importante. As regras devem ser projetadas de modo que análises repetidas desnecessárias não ocorram.
Uma API SaaS pode receber tráfego de múltiplos tenants em um único endpoint. O TR7 pode ler o campo `$.tenant_id` e encaminhar o tráfego para o pool de backend correto para cada tenant.
O valor de papel ou scope dentro de um token de Authorization pode ser lido. O acesso a caminhos de administrador pode ser restrito a usuários cujo token carrega o valor de claim exigido.
Números de cartão, identificações ou dados de usuário retornados em uma resposta de API podem ser mascarados. O TR7 reduz a exposição de campos sensíveis em respostas de saída sem exigir alterações no código da aplicação.
Quando um endpoint que espera JSON recebe um corpo malformado, o TR7 pode rejeitar a requisição antecipadamente. Isso reduz erros de análise da aplicação e encolhe a superfície de ataque.
Em vez de registrar o corpo completo, apenas campos como `operationName`, `tenant` e `userId` são extraídos. A correlação no SIEM melhora e a minimização de dados é preservada.
JSONQUERY, JWTHEADER e JWTPAYLOAD transformam campos do corpo JSON e claims JWT em condições de regra, entradas de log e ações de mascaramento. Vamos fazer um tour em uma configuração ao vivo nos seus próprios serviços.