Em ambientes corporativos, uma policy raramente vai direto para Deny. Ela começa em Audit, acumula evidências e, em algum momento, precisa evoluir. É nessa passagem que surgem as perguntas difíceis: preciso duplicar o assignment para testar uma região? Como manter outra região apenas em observação? E como tratar uma exceção sem criar uma exclusão invisível?
Resource Selectors e Overrides resolvem boa parte desse problema. Embora estejam disponíveis no Azure Policy, ainda aparecem pouco nas implementações do dia a dia. O primeiro controla quais recursos participam de cada fase do rollout; o segundo permite alterar o efeito ou a versão de policies específicas sem duplicar a initiative ou o assignment.
Para colocar isso à prova, usei East US como canário para uma policy de tag em Deny, mantive Brazil South em Audit e apliquei uma exemption temporária a uma única VNet. O resultado é um modelo simples de reproduzir e, principalmente, fácil de explicar para os times impactados.
O problema que esses recursos resolvem
Scope, Resource Selectors, Overrides e Exemptions podem aparecer na mesma configuração, mas não fazem a mesma coisa.
| Recurso | Papel no rollout |
|---|---|
| Scope do assignment | Define a fronteira administrativa dos recursos potencialmente avaliados |
| Resource Selectors | Escolhem quais recursos dessa fronteira entram na fase atual |
| Overrides | Alteram o efeito ou a versão aplicável a um subconjunto |
| Policy Exemptions | Registram por que uma não conformidade foi aceita |
enforcementMode | Define se os efeitos serão aplicados ou apenas avaliados |
A vantagem desse desenho é manter um único assignment e avançar por etapas. Isso reduz duplicação, facilita o rollback e deixa explícito qual parte do ambiente já está sob enforcement.
Como o cenário foi desenhado
A initiative [Lab] Azure Policy Safe Deployment reúne duas policies built-in:
| Referência | Policy | O que ela verifica |
|---|---|---|
requireTag | Require a tag on resources | Presença da tag sdp-governed |
storageDisablePublicNetwork | Storage accounts should disable public network access | Estado de publicNetworkAccess |
O assignment [Lab] SDP – Complete East US + Brazil South está no resource group rg-policy-sdp-lab-001, usa enforcementMode=Default, não possui notScopes e recebe estes parâmetros:
| Parâmetro | Valor |
|---|---|
requiredTagName | sdp-governed |
storageEffect | Audit |
Foram usados dez recursos de controle, divididos igualmente entre as duas regiões:
| Região | Storage PNA Enabled | Storage PNA Disabled | VNet com tag | VNet sem tag | NSG sem tag |
|---|---|---|---|---|---|
| East US | 1 | 1 | 1 | 1 | 1 |
| Brazil South | 1 | 1 | 1 | 1 | 1 |
Essa combinação produz controles positivos e negativos conhecidos. Storage com acesso público habilitado deve ficar não conforme; com acesso público desabilitado, conforme. O mesmo raciocínio vale para as VNets com e sem a tag. Os NSGs servem para provar a exclusão por tipo.
Assignment da initiative com os parâmetros requiredTagName e storageEffect configurados.
Resource Selectors: AND dentro, OR entre eles
Resource Selectors reduzem o conjunto avaliado sem alterar o scope do assignment. Eles podem filtrar por localização, tipo de recurso ou recursos sem localização.
Neste cenário há dois selectors:
| Selector | Localizações | Tipo |
|---|---|---|
AuditRegionsStorage | East US e Brazil South | Microsoft.Storage/storageAccounts |
AuditRegionsVNet | East US e Brazil South | Microsoft.Network/virtualNetworks |
A lógica é o ponto mais importante: as condições dentro do mesmo resource selector são combinadas com AND; selectors diferentes funcionam como OR.
((eastus OR brazilsouth) AND Storage Account)
OR
((eastus OR brazilsouth) AND Virtual Network)Um Storage precisa atender à localização e ao tipo do primeiro selector. Uma VNet entra pelo segundo. Os NSGs estão no mesmo resource group e nas mesmas regiões, mas não atendem a nenhum dos tipos; por isso, não recebem estado de policy.
Dois Resource Selectors combinam localização e tipo, com AND dentro de cada selector e OR entre eles.
Override: Audit e Deny no mesmo assignment
Um override altera o efeito ou a versão efetiva sem modificar a policy definition. Neste caso, a built-in de tag mantém seu efeito original Deny em East US, enquanto um override troca o efeito para Audit apenas no Brazil South:
policyDefinitionReferenceId = requireTag
AND
resourceLocation = brazilsouthO resultado final fica assim:
| Região | Policy de tag | Policy de Storage |
|---|---|---|
| East US | Deny | Audit |
| Brazil South | Audit por override | Audit por parâmetro |
Isso evita manter duas initiatives ou dois assignments apenas para variar o efeito por região. Overrides também podem controlar policyVersion, o que abre espaço para testar uma nova versão em um subconjunto antes de ampliar a adoção.
Override mantém a policy de tag em Audit somente no Brazil South, sem alterar a definition.
Exemption não é exclusão
A VNet sem tag de East US recebeu uma Policy Exemption do tipo Waiver, válida por sete dias e limitada à referência requireTag.
Esse detalhe muda a leitura do compliance. Um recurso excluído por notScopes ou que não atende aos Resource Selectors não recebe estado. O recurso isento aparece como Exempt, conta no resultado geral e mantém o motivo da decisão registrado.
As duas categorias disponíveis atendem situações diferentes:
Waiver: a não conformidade foi aceita, normalmente de forma temporária;Mitigated: outro controle atende à intenção da policy.
Exemption temporária do tipo Waiver aplicada somente à VNet sem tag de East US.
O que o compliance mostrou
O assignment encontrou oito recursos aplicáveis: quatro Storage Accounts e quatro VNets. Os dois NSGs ficaram fora dos selectors.
Esses oito recursos produziram doze estados, porque cada Storage é avaliado pelas duas policies e cada VNet apenas pela policy de tag.
| Estado | Quantidade |
|---|---|
Compliant | 8 |
NonCompliant | 3 |
Exempt | 1 |
| Total | 12 |
Oito recursos aplicáveis geram doze estados de policy: oito conformes, três não conformes e um isento.
Também foram confirmadas oito avaliações com ação efetiva Audit e quatro com Deny. Na visão agregada por recurso, cinco dos oito aparecem como conformes — incluindo a VNet isenta —, resultando em 62,5% de compliance.
No detalhe da VNet, o Azure informou complianceReasonCode=Waiver e isCompliant=true. Já os NSGs não aparecem, confirmando que exclusão e exemption produzem comportamentos diferentes.
A VNet isenta aparece como Exempt e conta no resultado geral; recursos fora dos selectors não recebem estado.
Deny só está pronto quando o teste passa
O dashboard comprova a avaliação, mas não substitui o teste de enforcement. Como o assignment usa enforcementMode=Default, o Deny precisa bloquear uma operação real.
Vale separar os conceitos: Audit registra uma não conformidade sem impedir a operação. DoNotEnforce mantém a avaliação, mas não aplica os efeitos configurados. Aqui, Default foi necessário para validar a negação no canário.
| Teste | Resultado | O que foi comprovado |
|---|---|---|
Criar VNet sem sdp-governed em East US | Negada por RequestDisallowedByPolicy | Deny ativo no canário |
| Criar VNet com a tag em East US | Permitida | Recurso conforme não é bloqueado |
| Criar VNet sem a tag em Brazil South | Permitida | Override regional em Audit |
| Atualizar a VNet isenta sem a tag | Permitida | Waiver aplicada ao recurso correto |
Os recursos temporários usados nesses testes foram removidos, e o inventário voltou aos dez recursos originais.
Onde esse desenho ajuda em ambiente corporativo
O mesmo padrão pode ser aplicado a outros controles:
| Caso de uso | Aplicação prática |
|---|---|
| Tags obrigatórias | Ativar Deny primeiro em uma região canário |
| Acesso público | Restringir o rollout por região e tipo de recurso |
| Tamanhos ou SKUs permitidos | Validar impacto antes de bloquear novos provisionamentos |
| Nova versão de policy | Usar override de policyVersion em um subconjunto |
| Initiatives extensas | Alterar somente policies escolhidas por policyDefinitionReferenceId |
| Workloads legados | Criar Waiver com owner, justificativa e expiração |
| Controle compensatório | Usar Mitigated quando outro controle aprovado cobre o risco |
O que eu levaria para produção
- Começar em
AuditouDoNotEnforce, de acordo com o que precisa ser validado. - Escolher um canário pequeno e alterar uma dimensão por vez: efeito, região, tipo ou versão.
- Usar recursos conformes e não conformes conhecidos para validar o resultado.
- Testar criação e atualização; compliance sozinho não comprova
Deny. - Aguardar a nova avaliação e conferir os timestamps, pois o processamento é assíncrono.
- Manter exemptions no menor escopo possível, com owner, justificativa e expiração.
- Registrar a configuração anterior do assignment para tornar o rollback simples.
Resource Selectors definem quem entra no rollout. Overrides determinam como uma policy se comporta nesse subconjunto. Exemptions registram por que uma exceção foi aceita. Quando essas três capacidades são tratadas como parte do processo de mudança, a passagem de Audit para Deny deixa de ser uma aposta e passa a ser uma decisão baseada em evidências.
Na sua organização, esse avanço já acontece por canário ou o efeito ainda é alterado para todo o scope de uma vez?
