# Ações e Negação por Padrão em Service Policies do XC

> A ação de uma regra é ALLOW, DENY ou NEXT_POLICY. Além do veredito, uma regra pode anexar modificadores como WAF, defesa contra bots ou rate limiting que disparam ao casar. E o sistema inteiro é negar-por-padrão: uma requisição que não casa com nada é negada. Conhecer isso torna o efeito real de uma política legível.

Source: https://ronutz.com/pt-BR/learn/xc-service-policy-actions-and-default-deny  
Updated: 2026-07-01  
Related tools: https://ronutz.com/pt-BR/tools/f5xc-service-policy-explainer

---

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.