Uma vez que você sabe como uma service policy casa com uma requisição, a pergunta restante é o que acontece ao casar. Essa é a ação, e ela tem um pouco mais de nuance do que permitir-ou-bloquear.

As três ações

A action de uma regra é um de três valores. ALLOW deixa a requisição prosseguir. DENY termina o processamento e retorna um erro ao cliente. NEXT_POLICY para de avaliar a política atual e passa para a próxima política do conjunto, pulando as regras restantes da atual. (O framework de política mais amplo também documenta ações como NEXT_POLICY_SET, LAST_POLICY e GOTO_POLICY para encadeamento entre policy sets, mas a ação de regra inline é uma das três acima, com padrão DENY.)

O padrão vale notar: se uma regra não declara uma ação, ela nega. Negar é o padrão seguro em todos os níveis deste sistema.

Negação por padrão

O comportamento mais importante não está escrito em nenhuma regra individual. Se uma requisição não casa com nenhuma regra que a permita, ela é negada. Uma service policy é fundamentalmente uma lista de razões para permitir (ou explicitamente negar) uma requisição; a ausência de um casamento significa não.

É por isso que um rule_list vazio nega tudo, e por que um rule_list que contém apenas regras DENY, sem nada que permita o resto, também nega tudo que não é explicitamente capturado. Quando você audita uma política, a pergunta é sempre: o que, se é que algo, de fato permite o tráfego que você espera servir?

Atalhos no nível da política

Nem toda política usa uma lista de regras. A escolha de regra também pode ser um instrumento contundente: allow_all_requests permite tudo que chega até a política, e deny_all_requests bloqueia tudo. Esses são legítimos, mas vale sinalizar, porque uma política allow_all_requests não faz verificação nenhuma, e uma perdida em um policy set pode desfazer a intenção de tudo ao seu redor.

As formas allow_list e deny_list são atalhos baseados em origem. Elas casam por onde uma requisição vem (prefixos de IP, prefix sets, ASNs, países, fingerprints TLS) e carregam uma ação padrão para o caso sem casamento. Um allow_list permite origens que casam e aplica seu padrão ao resto; um deny_list nega origens que casam.

Modificadores: mais do que um veredito

Uma regra faz mais do que permitir ou negar. Ao casar, ela pode anexar modificadores que moldam como a requisição é tratada: um waf_action (pular ou customizar o processamento do App Firewall), um bot_action, rate limiters, uma ação de validação OpenAPI, mascaramento de resposta e outros. Esses não são o veredito; eles vêm junto com ele. Uma regra também pode carregar um expiration_timestamp, após o qual ela ainda existe na configuração mas não é mais aplicada, e um flag log_rule_evaluation que registra casamentos sem mudar a decisão.

O explicador separa isso claramente: mostra o veredito de cada regra como um selo de permitir, negar ou próxima-política, lista os predicados que precisam casar e observa os modificadores que disparam ao casar, de modo que a diferença entre "esta regra decide a requisição" e "esta regra também faz algo no caminho" nunca fica borrada.