Uma service policy com um rule_list guarda uma lista ordenada de regras. O algoritmo de combinação de regras decide como essa lista é percorrida e, portanto, qual ação de regra vence quando mais de uma regra pode casar com uma requisição.

Os três algoritmos

FIRST_MATCH é o padrão e o que a maioria das pessoas raciocina. As regras são avaliadas sequencialmente de cima para baixo até uma casar. A ação dessa regra é aplicada e a avaliação para. A ordem na lista é tudo: uma regra ampla perto do topo pode ofuscar uma regra mais específica abaixo, que nunca tem a chance de rodar.

ALLOW_OVERRIDES avalia todas as regras com ação ALLOW antes de qualquer regra com ação DENY. O efeito prático é que se qualquer regra ALLOW casar, a requisição é permitida, mesmo que uma regra DENY também casasse. A permissão vence os empates.

DENY_OVERRIDES é o espelho: todas as regras DENY são avaliadas antes de qualquer regra ALLOW. Se qualquer regra DENY casar, a requisição é negada, independentemente de um ALLOW que casa. A negação vence os empates.

Por que a ordem importa

Considere duas regras: uma nega um (número de sistema autônomo, do inglês autonomous system number) ruim específico, e uma permite tudo de um país parceiro. Sob FIRST_MATCH, o que aparecer primeiro decide. Sob DENY_OVERRIDES, a negação é considerada primeiro, então uma requisição do ASN ruim é bloqueada mesmo que também venha do país parceiro. Sob ALLOW_OVERRIDES, a mesma requisição é permitida, porque a permissão é considerada primeiro.

As mesmas regras, três resultados diferentes para a requisição que se sobrepõe. É por isso que ler uma política sem conhecer seu algoritmo pode enganar você.

A restrição do App Firewall

Há uma regra rígida a conhecer. Se qualquer regra na política é configurada com uma ação de App Firewall (), o algoritmo de combinação precisa ser FIRST_MATCH. Os modos de override não são permitidos junto com ações WAF, porque o processamento WAF está atrelado à avaliação sequencial. Se você vê ações WAF nas regras, pode assumir FIRST_MATCH.

Onde o algoritmo vive

Um ponto sutil: no schema do objeto service_policy, o algoritmo de combinação de regras não é um campo no spec da própria política. Ele é definido no nível do service policy set, o contêiner ordenado ao qual a política pertence. O rule_list dentro de uma política documenta que suas regras são avaliadas de cima para baixo, que é o comportamento FIRST_MATCH, e esse é o padrão seguro a assumir quando você está lendo uma única política isoladamente.

Por essa razão o explicador neste site assume, por padrão, a avaliação FIRST_MATCH de cima para baixo, e mostra um algoritmo explícito apenas se o JSON colado carregar um. Quando você está auditando um deployment real, verifique o policy set que a contém para confirmar o algoritmo em vigor.

O algoritmo decide quais erros são sobrevivíveis

Ordenação não é só precedência; ela decide quanto custa uma regra fora de lugar.

Sob primeira-correspondência, um ALLOW amplo acima de um DENY específico desliga o DENY em silêncio — e a configuração continua contendo os dois, então quem revisa a lista vê a proteção que espera. A regra está presente, correta e inalcançável.

É por isso que específico antes de geral não é conselho de estilo. É a ordenação sob a qual um erro fica visível: uma regra específica errada para de casar e é notada, enquanto uma regra geral cedo demais continua funcionando perfeitamente enquanto sombreia tudo abaixo.

Leia uma política de baixo para cima quando estiver procurando o que NÃO está sendo aplicado. De cima para baixo você vê o que acontece; de baixo para cima, o que nunca pode acontecer.