Fundamentação Teórica: Implement and Manage Azure Policy

1. Intuição Inicial

Imagine que você é o diretor de TI de uma grande empresa e precisa garantir que todos os recursos criados na nuvem sigam um conjunto de regras: toda VM deve ter tag de centro de custo, nenhum recurso pode ser criado fora do Brasil, todos os storage accounts devem usar criptografia obrigatória.

Você poderia treinar cada administrador individualmente e confiar que seguirão as regras. Mas pessoas erram, esquecem, e equipes crescem. O que você precisa é de um sistema que aplique as regras automaticamente, independente de quem cria o recurso, quando ou como.

Isso é o Azure Policy: um sistema de governança que define regras sobre o que pode e o que deve existir na sua infraestrutura Azure, avaliando continuamente os recursos e podendo bloquear criações não conformes, corrigir configurações automaticamente e gerar relatórios de conformidade.

Se o RBAC responde "quem pode fazer o quê", o Azure Policy responde "o que pode existir e como deve ser configurado".

2. Contexto

Onde o Azure Policy se encaixa

O Azure Policy opera no nível do Azure Resource Manager (ARM), interceptando e avaliando toda operação de criação ou modificação de recursos. Ele é completamente independente do RBAC: um usuário pode ter permissão de Contributor e mesmo assim ter sua operação bloqueada por uma Policy.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O Azure Policy existe porque RBAC não é suficiente para governança. RBAC controla intenção humana; Policy controla estado da infraestrutura. Um administrador bem-intencionado pode criar uma VM sem tag por descuido. Policy captura esse erro independente da intenção.

O que depende do Azure Policy

Conformidade regulatória: LGPD, ISO 27001, CIS Benchmark são implementados como initiative definitions
FinOps: tags obrigatórias para rastreamento de custos
Segurança: garantir que recursos sensíveis não sejam expostos publicamente
Padronização: naming conventions, regiões permitidas, SKUs permitidos
Automatização de configuração: aplicar configurações padrão em recursos recém-criados

3. Construção dos Conceitos

3.1 Policy Definition

Uma Policy Definition é a regra em si. Ela define:

O que avaliar: qual tipo de recurso, qual propriedade
Como avaliar: qual condição deve ser verdadeira ou falsa
O que fazer se a condição for atendida: o efeito

Toda Policy Definition é um documento JSON com estrutura definida. O Azure fornece centenas de built-in policy definitions prontas para uso, e você pode criar custom definitions para necessidades específicas.

3.2 Efeitos (Effects)

O efeito é o coração de uma Policy Definition. Ele determina o que acontece quando um recurso é avaliado e a condição da policy é atendida.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Cada efeito tem comportamento e timing distintos:

Efeito	Timing	O que faz	Caso de uso típico
Deny	Na criação/modificação	Bloqueia a operação ARM	Proibir regiões não autorizadas
Audit	Avaliação contínua	Marca como não-conforme, não bloqueia	Identificar recursos sem tag
Append	Na criação/modificação	Adiciona campos ao recurso	Forçar tags adicionais
Modify	Na criação/modificação e remediation	Adiciona, remove ou substitui propriedades e tags	Garantir tag padrão em todos os recursos
DeployIfNotExists	Após criação (async)	Deploya um recurso relacionado se não existir	Instalar extension de monitoramento em VMs
AuditIfNotExists	Avaliação contínua	Audita se recurso relacionado não existe	Verificar se VM tem backup configurado
Disabled	N/A	Ignora todos os recursos	Desativar temporariamente uma policy

3.3 Diferença entre Modify e Append

Esta distinção causa muita confusão:

Append apenas adiciona campos ou itens a arrays em propriedades existentes. Ele não pode modificar um valor que já existe, apenas adicionar ao que já está lá. Se a propriedade já existir com um valor, Append pode resultar em conflito dependendo da propriedade.

Modify é mais poderoso: ele pode adicionar, substituir ou remover propriedades e tags. É o efeito recomendado para gerenciamento de tags, pois substitui valores incorretos e adiciona tags ausentes, em vez de apenas tentar adicionar.

3.4 Diferença entre DeployIfNotExists e AuditIfNotExists

Ambos avaliam a existência de um recurso relacionado (não o recurso em si), mas com respostas diferentes:

AuditIfNotExists (AINE): Se o recurso relacionado não existir, marca como não-conforme. Não faz nada automaticamente.
DeployIfNotExists (DINE): Se o recurso relacionado não existir, deploya ele automaticamente via template ARM. Requer uma Managed Identity com permissões para criar o recurso relacionado.

Exemplo prático: uma policy com DINE que garante que toda VM tenha o agente do Azure Monitor instalado. Quando uma VM é criada sem o agente, o Policy automaticamente o instala via ARM deployment.

3.5 Policy Initiative (Policy Set Definition)

Uma Initiative (também chamada de Policy Set Definition) é um agrupamento de múltiplas Policy Definitions relacionadas, tratadas como uma unidade.

Por que initiatives existem? Imagine que conformidade com ISO 27001 requer 120 policies individuais. Gerenciar 120 atribuições separadas seria inviável. A initiative agrupa todas elas em um único objeto que pode ser atribuído de uma vez, com um único relatório de conformidade.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.6 Policy Assignment

Uma Policy Assignment é o ato de aplicar uma Policy Definition ou Initiative a um escopo específico. O mesmo conceito de escopos do RBAC se aplica: Management Group, Subscription, Resource Group ou Resource.

A assignment é onde você:

Define qual policy/initiative é aplicada
Define em qual escopo
Configura os parâmetros da policy (ex: lista de regiões permitidas)
Define exclusões (escopos excluídos da avaliação)
Configura a Managed Identity para effects que precisam fazer deployments (DINE)

3.7 Parâmetros

Parâmetros tornam policies reutilizáveis. Em vez de criar uma policy diferente para cada lista de regiões permitidas, você cria uma policy paramétrica e passa a lista como parâmetro na assignment.

"parameters": {
  "allowedLocations": {
    "type": "Array",
    "metadata": {
      "displayName": "Allowed locations",
      "description": "The list of allowed locations for resources."
    },
    "defaultValue": ["brazilsouth", "eastus2"]
  }
}

Na assignment, você fornece os valores:

"parameters": {
  "allowedLocations": {
    "value": ["brazilsouth"]
  }
}

3.8 Exclusões (Exclusions / Not Scopes)

Ao criar uma assignment, você pode definir escopos excluídos (notScopes). Recursos dentro desses escopos não são avaliados pela policy. Isso é útil para exceções controladas, como um Resource Group de laboratório que não precisa seguir as mesmas regras de produção.

4. Visão Estrutural

Hierarquia e herança de Policy

Assim como RBAC, policies atribuídas em escopos superiores são herdadas pelos escopos abaixo:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

RG1 herda tudo do Management Group e da Subscription, sem assignments próprias. RG2 herda tudo e adiciona uma policy mais restritiva. RG3 herda tudo mas tem uma exclusão configurada na assignment de tags.

Ciclo de vida de avaliação de uma Policy

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

O ciclo de avaliação de conformidade

O Azure Policy avalia recursos em dois momentos distintos:

Avaliação síncrona (no momento da operação ARM): Acontece quando um recurso é criado ou modificado. Policies com efeito Deny, Append e Modify são avaliadas aqui. Se uma policy Deny bloqueia a operação, o usuário recebe um erro imediatamente com detalhes sobre qual policy rejeitou a requisição.

Avaliação assíncrona (contínua): O Azure reavalia todos os recursos de um escopo periodicamente, aproximadamente a cada 24 horas. Isso captura recursos que existiam antes da policy ser atribuída, ou que se tornaram não-conformes por mudanças na policy. O resultado é refletido no dashboard de conformidade.

Para forçar uma avaliação imediata:

az policy state trigger-scan --resource-group "rg-producao"

Compliance State: o que significa cada estado

Estado	Significado
Compliant	Recurso avaliado e em conformidade com todas as policies
Non-compliant	Recurso avaliado e violando uma ou mais policies
Exempt	Recurso explicitamente isentado de uma policy assignment
Conflicting	Duas policies com efeito Deny têm condições conflitantes
Not started	Avaliação ainda não foi executada para este recurso
Not registered	Resource provider não está registrado para avaliação

Comportamento pouco óbvio: recursos existentes antes da policy

Quando você atribui uma policy com efeito Deny a um escopo, recursos que já existem e violam a policy não são deletados ou bloqueados. Eles simplesmente aparecem como Non-compliant. A policy Deny só bloqueia novas criações e modificações. Para corrigir recursos existentes, você precisa de Modify ou DeployIfNotExists com uma Remediation Task.

Remediation Tasks

Uma Remediation Task é o mecanismo para aplicar efeitos DINE e Modify a recursos que já existem (Non-compliant). Sem uma Remediation Task, esses efeitos só se aplicam a recursos criados/modificados após a atribuição da policy.

O processo de remediation:

Azure Policy identifica recursos Non-compliant para policies com efeito Modify ou DINE
Você inicia uma Remediation Task manualmente ou configura auto-remediation
A Managed Identity associada à policy assignment executa as correções nos recursos
O status dos recursos é atualizado após a remediação

A Managed Identity precisa ter as permissões adequadas para modificar os recursos alvo. Por exemplo, uma policy DINE que instala uma extension em VMs precisa de uma Managed Identity com pelo menos Contributor no escopo das VMs.

6. Formas de Implementação

Portal do Azure

Quando usar: criação inicial, exploração de built-in policies, revisão de conformidade

Para criar uma assignment via portal:

Azure portal > Policy > Assignments > Assign Policy
Selecionar escopo (MG, Sub, RG)
Selecionar a Policy Definition ou Initiative
Configurar parâmetros
Definir exclusões se necessário
Para efeitos DINE/Modify: configurar Managed Identity (System-assigned recomendado)
Revisar e criar

Para verificar conformidade: Portal > Policy > Compliance: dashboard com visão geral de conformidade por escopo, policy e recurso.

Limitação: não é reproduzível, não tem controle de versão, difícil de escalar para muitas assignments.

Azure CLI

# Listar built-in policy definitions
az policy definition list \
  --query "[?policyType=='BuiltIn'].{Name:displayName, ID:name}" \
  --output table

# Ver detalhes de uma policy específica
az policy definition show \
  --name "e56962a6-4747-49cd-b67b-bf8b01975c4c"

# Criar uma policy assignment simples
az policy assignment create \
  --name "deny-non-brazil-resources" \
  --display-name "Deny resources outside Brazil" \
  --policy "e56962a6-4747-49cd-b67b-bf8b01975c4c" \
  --scope "/subscriptions/<sub-id>" \
  --params '{"listOfAllowedLocations": {"value": ["brazilsouth"]}}'

# Criar assignment com Managed Identity (para DINE)
az policy assignment create \
  --name "deploy-monitor-agent" \
  --policy "<policy-definition-id>" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-prod" \
  --mi-system-assigned \
  --location "brazilsouth"

# Atribuir role à Managed Identity da policy (necessário para DINE)
az role assignment create \
  --assignee-object-id "<managed-identity-object-id>" \
  --role "Contributor" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-prod"

# Verificar conformidade de um RG
az policy state list \
  --resource-group "rg-producao" \
  --filter "complianceState eq 'NonCompliant'" \
  --output table

# Criar uma remediation task
az policy remediation create \
  --name "remediate-tags" \
  --policy-assignment "/subscriptions/<sub-id>/providers/Microsoft.Authorization/policyAssignments/tag-policy" \
  --resource-discovery-mode ReEvaluateCompliance \
  --resource-group "rg-producao"

# Forçar scan de conformidade
az policy state trigger-scan \
  --resource-group "rg-producao"

Azure PowerShell

# Listar built-in policies
Get-AzPolicyDefinition -BuiltIn | Select-Object -Property DisplayName, Name

# Criar uma policy assignment
$policy = Get-AzPolicyDefinition -Name "e56962a6-4747-49cd-b67b-bf8b01975c4c"

New-AzPolicyAssignment `
  -Name "deny-non-brazil" `
  -DisplayName "Deny resources outside Brazil South" `
  -Scope "/subscriptions/<sub-id>" `
  -PolicyDefinition $policy `
  -PolicyParameterObject @{
    listOfAllowedLocations = @{
      value = @("brazilsouth")
    }
  }

# Criar assignment com Managed Identity para DINE
$assignment = New-AzPolicyAssignment `
  -Name "deploy-diagnostics" `
  -Scope "/subscriptions/<sub-id>/resourceGroups/rg-prod" `
  -PolicyDefinition $policy `
  -AssignIdentity `
  -Location "brazilsouth"

# Ver recursos não-conformes
Get-AzPolicyState `
  -ResourceGroupName "rg-producao" `
  -Filter "ComplianceState eq 'NonCompliant'" |
  Select-Object ResourceId, PolicyAssignmentName, ComplianceState

# Criar remediation task
Start-AzPolicyRemediation `
  -Name "remediate-tags" `
  -PolicyAssignmentId "/subscriptions/<sub-id>/providers/Microsoft.Authorization/policyAssignments/tag-policy" `
  -ResourceGroupName "rg-producao"

Custom Policy Definitions em JSON/Bicep

Quando nenhuma built-in policy atende à necessidade, você cria uma custom policy definition. A estrutura JSON de uma policy tem as seguintes seções principais:

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Compute/virtualMachines"
        },
        {
          "field": "tags['CostCenter']",
          "exists": "false"
        }
      ]
    },
    "then": {
      "effect": "[parameters('effect')]"
    }
  },
  "parameters": {
    "effect": {
      "type": "String",
      "defaultValue": "Audit",
      "allowedValues": ["Audit", "Deny", "Disabled"]
    }
  }
}

A propriedade mode define quais tipos de recursos são avaliados:

Mode	O que avalia
All	Todos os tipos de recursos, incluindo grupos de recursos e subscriptions
Indexed	Apenas tipos de recursos que suportam tags e localização (recomendado para policies de tag e localização)

Usar Indexed em vez de All quando a policy é sobre tags ou localização evita falsos positivos em tipos de recursos que não suportam essas propriedades.

Criando uma custom policy via Bicep:

resource customPolicy 'Microsoft.Authorization/policyDefinitions@2021-06-01' = {
  name: 'require-costcenter-tag'
  properties: {
    displayName: 'Require CostCenter tag on VMs'
    policyType: 'Custom'
    mode: 'Indexed'
    parameters: {
      effect: {
        type: 'String'
        defaultValue: 'Audit'
        allowedValues: ['Audit', 'Deny', 'Disabled']
      }
    }
    policyRule: {
      if: {
        allOf: [
          {
            field: 'type'
            equals: 'Microsoft.Compute/virtualMachines'
          }
          {
            field: 'tags[\'CostCenter\']'
            exists: 'false'
          }
        ]
      }
      then: {
        effect: '[parameters(\'effect\')]'
      }
    }
  }
}

7. Controle e Segurança

Quem pode gerenciar policies

Gerenciar Policy Definitions e Assignments requer permissões específicas de RBAC:

Ação	Role necessária
Criar/editar Policy Definitions	Resource Policy Contributor ou Owner
Criar Policy Assignments	Resource Policy Contributor ou Owner
Ver conformidade	Reader (apenas visualização)
Criar Remediation Tasks	Resource Policy Contributor + permissões nos recursos alvo

Managed Identity e segurança de DINE

Policies com efeito DeployIfNotExists ou Modify precisam de uma Managed Identity para executar as ações corretivas. Há dois tipos:

System-assigned Managed Identity: criada automaticamente junto com a policy assignment e deletada quando a assignment é removida. Recomendada para a maioria dos casos.

User-assigned Managed Identity: criada separadamente e reutilizável em múltiplas assignments. Útil quando você quer controle preciso sobre as permissões ou reutilizar a identidade.

Em ambos os casos, a Managed Identity precisa ter as permissões adequadas (via RBAC) para executar as ações que a policy define. A Microsoft recomenda seguir o princípio do menor privilégio: dar apenas as permissões necessárias para as ações específicas da policy.

Isenções (Exemptions)

Diferente de exclusões (notScopes), as Isenções são um recurso mais sofisticado que permite marcar um recurso específico como isento de uma policy por um período de tempo ou permanentemente, com justificativa registrada.

az policy exemption create \
  --name "vm-legacy-exemption" \
  --display-name "Legacy VM exemption - ticket #12345" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-prod/providers/Microsoft.Compute/virtualMachines/vm-legacy-01" \
  --policy-assignment "/subscriptions/<sub-id>/providers/Microsoft.Authorization/policyAssignments/require-tags" \
  --exemption-category "Waiver" \
  --expires-on "2026-12-31"

As categorias de isenção são:

Categoria	Quando usar
Waiver	O recurso não pode ser corrigido (legado, técnico impossível)
Mitigated	O requisito é atendido por um controle compensatório externo

8. Tomada de Decisão

Escolha do efeito

Situação	Efeito recomendado	Motivo
Proibir recursos em regiões não autorizadas	Deny	Prevenção absoluta, sem exceção
Identificar VMs sem tag, sem bloquear	Audit	Fase inicial de governança, não impactar produção
Adicionar uma tag padrão se não existir	Modify	Corrige automaticamente na criação e via remediation
Garantir que toda VM tenha extension de monitoramento	DeployIfNotExists	Cria recurso relacionado que não existe
Verificar se VM tem backup mas não criar automaticamente	AuditIfNotExists	Alerta sem automatizar (decisão requer humano)
Desativar policy temporariamente	Disabled	Evita deletar e recriar a policy
Forçar propriedade em recurso (não tag)	Append	Adiciona ao array de propriedades existente

Quando usar Policy vs. RBAC

Necessidade	Ferramenta	Motivo
Impedir que usuário X crie recursos	RBAC	Controle de quem pode agir
Impedir que VMs sejam criadas sem tag	Policy	Controle de como recursos podem existir
Garantir que toda VM tenha criptografia	Policy (Deny/Modify)	Controle de estado da infraestrutura
Restringir acesso a dados em storage	RBAC (DataActions)	Controle de acesso a dados
Proibir criação de recursos em região errada	Policy (Deny)	Regra de infraestrutura, não de identidade

Quando usar built-in vs. custom policy

Situação	Escolha	Motivo
Requisito comum de segurança (HTTPS, criptografia, MFA)	Built-in	Testadas, mantidas pela Microsoft, gratuitas
Requisito regulatório padrão (ISO, CIS, NIST)	Initiative built-in	Pacote completo pronto
Regra de negócio específica da empresa	Custom	Nenhuma built-in cobre o caso
Naming convention personalizado	Custom	Regra proprietária
Tag obrigatória com valores permitidos específicos	Custom	Parâmetros de built-in podem não ser suficientes

9. Boas Práticas

Comece com Audit, migre para Deny. Nunca implemente uma policy Deny diretamente em produção sem antes avaliar o impacto. Atribua com efeito Audit primeiro, analise o relatório de não-conformidade por alguns dias, corrija os recursos existentes, e então mude para Deny.

Parametrize tudo que pode variar. Policies devem ser genéricas e configuradas via parâmetros nas assignments. Uma única policy definition "Require specific tag" com parâmetro de nome e valor é mais sustentável do que 10 policy definitions para 10 tags diferentes.

Use initiatives para agrupamento lógico. Agrupe policies relacionadas em initiatives mesmo que você tenha apenas 3 ou 4 policies. Isso facilita relatórios de conformidade e futuras expansões.

Nunca atribua policies no nível de Resource. O escopo mais restrito recomendado para atribuição é o Resource Group. Atribuições no nível de Resource individual são difíceis de gerenciar e escalar.

Documente exclusões e isenções. Toda exclusão (notScope) ou Exemption deve ter uma justificativa documentada, um dono responsável e, quando possível, uma data de expiração. Isenções permanentes sem justificativa são riscos de conformidade.

Use Managed Identity com menor privilégio para DINE. A Managed Identity da policy deve ter apenas as permissões necessárias para a ação específica que a policy executa, no escopo mais restrito possível.

Prefira System-assigned Managed Identity para simplificar. Para a maioria dos casos, a System-assigned MI é suficiente e tem o ciclo de vida ligado à assignment, eliminando o risco de identidades órfãs.

Mantenha custom policies versionadas. Armazene custom policy definitions em um repositório Git e use CI/CD para deployment. Mudanças em policy definitions têm impacto amplo e precisam de revisão e rastreabilidade.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Aplicar Deny diretamente em produção	Confiança excessiva na policy	Sempre começar com Audit, analisar, depois Deny
Esquecer de dar permissões à Managed Identity de DINE	Policy criada mas remediation falha silenciosamente	Verificar sempre o status das remediation tasks
Usar `mode: All` em policy de tags	Avalia tipos sem suporte a tags, gera non-compliant em recursos de sistema	Usar `mode: Indexed` para policies de tag e localização
Confundir Assignment exclusion (notScopes) com Exemption	Ambos excluem escopos, mas Exemption é por recurso e rastreável	Use Exemption quando precisar de auditoria da exceção
Criar policy com condição sempre verdadeira	Erro na lógica do policyRule, afeta todos os recursos	Testar a policy com Audit antes de Deny
Não usar parâmetros e criar policies duplicadas	Falta de design; uma policy por tag, por região, etc.	Parametrizar desde o início
Acreditar que remediation é automática para Modify/DINE	Remediation não acontece sozinha para recursos existentes	Criar Remediation Tasks explicitamente para recursos existentes
Não verificar Non-compliant resources antes de Deny	Ao mudar de Audit para Deny, operações legítimas podem ser bloqueadas	Sempre resolver non-compliance antes de ativar Deny

11. Operação e Manutenção

Dashboard de conformidade

O portal de Policy > Compliance mostra:

Overall compliance percentage: percentual de recursos conformes
Non-compliant resources: lista detalhada com links para cada recurso
Non-compliant policies: quais policies têm mais violações
Compliance by initiative: visão agregada por initiative

Você pode filtrar por escopo, initiative, policy individual e estado.

Consultar conformidade via CLI

# Resumo de conformidade da subscription
az policy state summarize \
  --subscription "<sub-id>"

# Listar recursos não-conformes em um RG
az policy state list \
  --resource-group "rg-producao" \
  --filter "complianceState eq 'NonCompliant'" \
  --select "resourceId, policyAssignmentName, policyDefinitionName" \
  --output table

# Ver detalhes de uma remediation task em andamento
az policy remediation show \
  --name "remediate-tags" \
  --resource-group "rg-producao"

# Listar deployment criados por remediation tasks (para DINE)
az policy remediation deployment list \
  --name "remediate-monitoring" \
  --resource-group "rg-producao"

Limites importantes

Limite	Valor
Policy definitions por tenant	500 (custom)
Initiative definitions por tenant	200 (custom)
Policy assignments por escopo	200
Parâmetros por policy definition	20
Parâmetros por initiative	100
Conditions por policy rule	512

O limite de 500 custom policy definitions é suficiente para a maioria das organizações, mas deve ser monitorado em tenants grandes com muitas equipes criando policies independentemente. Governance de policies (quem pode criar, processo de aprovação) é tão importante quanto as policies em si.

Monitorar mudanças em policies

Assim como role assignments, mudanças em policy assignments são registradas no Activity Log:

az monitor activity-log list \
  --resource-provider "Microsoft.Authorization" \
  --query "[?operationName.value=='Microsoft.Authorization/policyAssignments/write']" \
  --output table

12. Integração e Automação

Azure Policy como parte de um pipeline de Landing Zone

Em organizações que usam o padrão de Landing Zone (como o Azure Landing Zone da Microsoft), policies são aplicadas em camadas via Management Groups:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Integração com Terraform

# Custom policy definition
resource "azurerm_policy_definition" "require_tag" {
  name         = "require-costcenter-tag"
  policy_type  = "Custom"
  mode         = "Indexed"
  display_name = "Require CostCenter tag"

  policy_rule = jsonencode({
    if = {
      allOf = [
        { field = "type", equals = "Microsoft.Compute/virtualMachines" },
        { field = "tags['CostCenter']", exists = "false" }
      ]
    }
    then = { effect = "Deny" }
  })
}

# Policy assignment
resource "azurerm_resource_group_policy_assignment" "enforce_tag" {
  name                 = "enforce-costcenter-tag"
  resource_group_id    = azurerm_resource_group.prod.id
  policy_definition_id = azurerm_policy_definition.require_tag.id
}

Integração com Azure DevOps / GitHub Actions

Policies podem ser validadas em pipeline antes do deploy, usando a extensão Azure Policy Compliance Scan:

# GitHub Actions
- name: Azure Policy Compliance Scan
  uses: azure/policy-compliance-scan@v0
  with:
    scopes: |
      /subscriptions/<sub-id>/resourceGroups/rg-prod
    wait: true
    credentials: ${{ secrets.AZURE_CREDENTIALS }}

Isso permite que um pipeline falhe se recursos não conformes forem detectados após um deploy, criando um gate de conformidade automatizado.

Integração com Microsoft Defender for Cloud

O Defender for Cloud (anteriormente Azure Security Center) usa Azure Policy por baixo. As recomendações de segurança do Defender são, na prática, policies com efeito AuditIfNotExists. Ao habilitar o Defender for Cloud, uma initiative de segurança é atribuída automaticamente à subscription.

Isso significa que ao ver recomendações no Defender for Cloud, você está vendo resultados de avaliação de Azure Policy. Você pode visualizar e gerenciar essas policies diretamente no portal de Policy.

13. Resumo Final

Pontos essenciais:

Azure Policy controla o que pode existir e como deve ser configurado na infraestrutura, complementando o RBAC que controla quem pode agir
Toda policy tem três partes: condição (if), efeito (then) e parâmetros opcionais
Efeitos preventivos (Deny, Append, Modify) atuam sincronamente na operação ARM; efeitos informativos e corretivos (Audit, AINE, DINE) atuam assincronamente
Policies são herdadas de cima para baixo na hierarquia de escopos, assim como RBAC
Recursos existentes antes da atribuição de uma policy não são bloqueados; aparecem como Non-compliant e precisam de Remediation Tasks para correção

Diferenças críticas:

Deny vs. Audit: Deny bloqueia na operação; Audit registra sem bloquear
Modify vs. Append: Modify substitui valores existentes; Append apenas adiciona sem modificar o que existe
DINE vs. AINE: DINE deploya o recurso relacionado ausente; AINE apenas audita a ausência
Exclusion (notScopes) vs. Exemption: notScopes exclui um escopo inteiro da assignment; Exemption isenta um recurso específico com justificativa rastreável
Mode All vs. Indexed: All avalia todo tipo de recurso; Indexed avalia apenas tipos que suportam tags e localização

O que precisa ser lembrado para o AZ-104:

A sequência correta é: Audit primeiro, Deny depois de validar o impacto
Policies com efeito DINE e Modify precisam de Managed Identity com permissões adequadas
Remediation Tasks devem ser criadas explicitamente para corrigir recursos existentes não-conformes
O portal Policy > Compliance é o principal dashboard para verificar o estado de conformidade
az policy state trigger-scan força uma reavaliação imediata sem esperar o ciclo de 24 horas
Initiatives são agrupamentos de policies atribuíveis como uma unidade, com relatório de conformidade consolidado
O limite de assignments por escopo é 200 e o de custom policy definitions por tenant é 500

1. Intuição Inicial​

2. Contexto​

Onde o Azure Policy se encaixa​

O que depende do Azure Policy​

3. Construção dos Conceitos​

3.1 Policy Definition​

3.2 Efeitos (Effects)​

3.3 Diferença entre Modify e Append​

3.4 Diferença entre DeployIfNotExists e AuditIfNotExists​

3.5 Policy Initiative (Policy Set Definition)​

3.6 Policy Assignment​

3.7 Parâmetros​

3.8 Exclusões (Exclusions / Not Scopes)​

4. Visão Estrutural​

Hierarquia e herança de Policy​

Ciclo de vida de avaliação de uma Policy​

5. Funcionamento na Prática​

O ciclo de avaliação de conformidade​

Compliance State: o que significa cada estado​

Comportamento pouco óbvio: recursos existentes antes da policy​

Remediation Tasks​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Custom Policy Definitions em JSON/Bicep​

7. Controle e Segurança​

Quem pode gerenciar policies​

Managed Identity e segurança de DINE​

Isenções (Exemptions)​

8. Tomada de Decisão​

Escolha do efeito​

Quando usar Policy vs. RBAC​

Quando usar built-in vs. custom policy​

9. Boas Práticas​

10. Erros Comuns​

11. Operação e Manutenção​

Dashboard de conformidade​

Consultar conformidade via CLI​

Limites importantes​

Monitorar mudanças em policies​

12. Integração e Automação​

Azure Policy como parte de um pipeline de Landing Zone​

Integração com Terraform​

Integração com Azure DevOps / GitHub Actions​

Integração com Microsoft Defender for Cloud​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Onde o Azure Policy se encaixa

O que depende do Azure Policy

3. Construção dos Conceitos

3.1 Policy Definition

3.2 Efeitos (Effects)

3.3 Diferença entre Modify e Append

3.4 Diferença entre DeployIfNotExists e AuditIfNotExists

3.5 Policy Initiative (Policy Set Definition)

3.6 Policy Assignment

3.7 Parâmetros

3.8 Exclusões (Exclusions / Not Scopes)

4. Visão Estrutural

Hierarquia e herança de Policy

Ciclo de vida de avaliação de uma Policy

5. Funcionamento na Prática

O ciclo de avaliação de conformidade

Compliance State: o que significa cada estado

Comportamento pouco óbvio: recursos existentes antes da policy

Remediation Tasks

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Custom Policy Definitions em JSON/Bicep

7. Controle e Segurança

Quem pode gerenciar policies

Managed Identity e segurança de DINE

Isenções (Exemptions)

8. Tomada de Decisão

Escolha do efeito

Quando usar Policy vs. RBAC

Quando usar built-in vs. custom policy

9. Boas Práticas

10. Erros Comuns

11. Operação e Manutenção

Dashboard de conformidade

Consultar conformidade via CLI

Limites importantes

Monitorar mudanças em policies

12. Integração e Automação

Azure Policy como parte de um pipeline de Landing Zone

Integração com Terraform

Integração com Azure DevOps / GitHub Actions

Integração com Microsoft Defender for Cloud

13. Resumo Final