# Explicador de service-policy do F5XC

> Cole uma service_policy do F5 Distributed Cloud e veja exatamente como ela casa: o escopo de servidor, a ordem das regras e a ação e as condições de cada regra. iRules para o XC, decodificado.

- Tool: https://ronutz.com/pt-BR/tools/f5xc-service-policy-explainer
- Family: Segurança e WAF

---

## O que faz

Cole uma `service_policy` do F5XC - F5 Distributed Cloud em JSON e a ferramenta detalha exatamente como ela casa: o escopo de servidor ao qual se aplica, a ordem em que suas regras são avaliadas e, para cada regra, sua ação e as condições que precisam valer. Ela lê a definição da política inteiramente no seu navegador e não avalia nada contra tráfego real.

## O que é uma service policy

Na plataforma F5 Distributed Cloud, uma service policy decide quais requisições chegam a um load balancer e quais são recusadas, o equivalente na plataforma à lógica de correspondência de requisições que você escreveria como uma iRule em um BIG-IP clássico. Uma política tem um **escopo de servidor** que diz quais servidores ela governa, uma **disposição** que define o comportamento padrão, e uma **lista de regras** ordenada. A ordem importa: as regras são avaliadas em sequência, e a primeira que casa decide o resultado, então lê-las de cima para baixo é como você entende o que a política de fato faz.

## Como uma regra casa

Cada regra combina uma **ação**, como permitir ou negar, com um conjunto de condições que precisam todas valer para a regra se aplicar. A ferramenta renderiza cada condição do jeito que o schema define:

- o **matcher** e o que ele inspeciona (uma origem, um cabeçalho, um caminho e assim por diante);
- seus **critérios**, se ele casa por valor exato, por expressão regular ou por prefixo;
- a **lógica e/ou** que combina múltiplos valores;
- qualquer **inversão**, em que a correspondência é negada; e
- a **sensibilidade a maiúsculas/minúsculas** da comparação.

Renderizar isso de forma clara é o valor: uma service policy em JSON bruto é difícil de ler, e um único matcher mal interpretado ou uma condição invertida é exatamente o tipo de coisa que permite ou bloqueia o tráfego errado.

## Fundamentada no schema

Os nomes e formatos de campo que a ferramenta entende seguem o schema OpenAPI oficial do F5 Distributed Cloud para a service policy e suas regras, então a decodificação reflete o objeto real, e não um palpite. A ferramenta é local e sem egresso de dados: ela analisa e explica o JSON que você cola, e nunca contata a plataforma nem testa a política contra requisições reais. Entradas malformadas são reportadas, em vez de gerar um erro.

## Como usar

Cole um spec de `service_policy` em JSON e leia o escopo de servidor, as regras ordenadas e a ação e as condições de cada regra. A decodificação é determinística e local.

## Standards and references

- [F5 Distributed Cloud - API for ves.io.schema.service_policy](https://docs.cloud.f5.com/docs-v2/api/service-policy)
- [F5 Distributed Cloud - API for ves.io.schema.service_policy_rule](https://docs.cloud.f5.com/docs-v2/api/service-policy-rule)
- [F5 Distributed Cloud - Create Service Policy](https://docs.cloud.f5.com/docs-v2/multi-cloud-app-connect/how-to/app-security/service-policy)

## Related reading

- [Ações e Negação por Padrão em Service Policies do XC](https://ronutz.com/pt-BR/learn/xc-service-policy-actions-and-default-deny.md): 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.
- [Algoritmos de Combinação de Regras do XC: FIRST_MATCH, ALLOW_OVERRIDES, DENY_OVERRIDES](https://ronutz.com/pt-BR/learn/xc-rule-combining-algorithms.md): Quando uma service policy guarda uma lista de regras, o algoritmo de combinação de regras decide a ordem em que são avaliadas. FIRST_MATCH percorre de cima para baixo e para no primeiro acerto. ALLOW_OVERRIDES e DENY_OVERRIDES reordenam primeiro por ação. A escolha muda qual regra vence quando várias poderiam casar.
- [Como uma Service Policy do F5 XC Casa com uma Requisição](https://ronutz.com/pt-BR/learn/how-xc-service-policies-match.md): Uma service_policy do F5 Distributed Cloud tem duas partes: um conjunto de predicados que definem a quais requisições a política se aplica, e uma lista de regras que decidem o que acontece. Uma requisição casa apenas quando todos os predicados no nível da política são verdadeiros e ela casa com uma das regras. Este é o modelo sobre o qual todo o resto se apoia.
- [Predicados e Lógica Booleana em Regras de Service Policy do XC](https://ronutz.com/pt-BR/learn/xc-service-policy-predicates-and-logic.md): Dentro de uma regra, todo predicado que você define é combinado com E (AND), e um predicado não definido é implicitamente verdadeiro. Dentro de um comparador, múltiplos valores são combinados com OU (OR). Entender esses dois níveis é a diferença entre uma regra que casa com o que você quis dizer e uma que silenciosamente casa demais ou de menos.
- [Sensibilidade a Maiúsculas e Transformadores em Comparadores do XC](https://ronutz.com/pt-BR/learn/xc-matcher-case-sensitivity-and-transformers.md): Em uma service policy do XC, nomes de cabeçalho não diferenciam maiúsculas de minúsculas, mas valores de cabeçalho, chaves de query e nomes de cookie diferenciam. Comparações exatas comparam byte a byte a menos que você aplique um transformador como LOWER_CASE antes. Esta é a razão mais comum de uma regra que parece certa não casar.
- [Service Policy do XC vs iRules do BIG-IP: Um Modelo Mental](https://ronutz.com/pt-BR/learn/xc-service-policy-vs-irules.md): iRules são scripts orientados a eventos que rodam código procedural enquanto uma requisição é processada. Uma service policy do XC é uma lista declarativa de regras com predicados e ações. Se você pensa em iRules, isto mapeia os conceitos para que você leia políticas do XC sem procurar o equivalente de um bloco when-HTTP_REQUEST.