Governança com Azure Policy: definições, efeitos, conformidade e implantação segura

radio_button_uncheckedshort_text1. Azure Policy e o objetivo de governança

Azure Policy transforma padrões organizacionais em definições que Azure pode atribuir, avaliar e relatar em escala. Uma definição é expressa em JSON, compara propriedades de recurso ou contexto de solicitação com regras de negócios e aplica um efeito como auditoria, negação, modificação ou implantação. Isto torna a governação repetível em vez de depender de uma revisão manual de cada recurso.

Uma iniciativa, também chamada de conjunto de políticas, agrupa diversas definições sob um único resultado. As iniciativas simplificam a atribuição e a geração de relatórios para metas como uma linha de base de segurança, marcação obrigatória ou uma estrutura regulatória. Iniciativas integradas e personalizadas podem ser colocadas em camadas para criar barreiras de proteção para o setor público, financeiro e outros ambientes regulamentados, incluindo controles focados na soberania e mapeamentos de conformidade.

• Atribua uma política que controle os recursos criados no futuro.
• Crie e atribua uma iniciativa para que muitas definições sejam rastreadas como um objetivo de conformidade.
• Investigue e resolva um recurso que foi negado ou relatado como não conforme.
• Implemente uma nova política em uma organização com exposição controlada e resultados mensuráveis.

Azure Policy é um controle técnico, não um aconselhamento jurídico. Cada organização permanece responsável por identificar as leis aplicáveis, validar sua implementação e consultar profissionais jurídicos e de conformidade qualificados.

radio_button_uncheckedshort_text2. Cloud Adoption Framework e governança contínua

O Microsoft Cloud Adoption Framework para o Azure fornece orientação, ferramentas, documentação e práticas completas para estratégia, planejamento, preparação, adoção, governança, segurança e gerenciamento de nuvem. Na metodologia Governar, a governança da nuvem significa controlar o uso aceitável da nuvem por meio de proteções documentadas que apoiam os resultados de negócios e, ao mesmo tempo, reduzem os riscos regulatórios, de segurança, operacionais, de custos, de dados, de gerenciamento de recursos e de IA.

A governação não é uma implementação única. A tecnologia, as prioridades organizacionais, os modelos de ameaças e as regulamentações mudam. A estrutura, portanto, estabelece primeiro a apropriação e repete a avaliação de riscos, a manutenção de políticas, a aplicação e o monitoramento como um ciclo operacional contínuo.

radio_button_uncheckedshort_text3. As cinco etapas da governança da nuvem

1. Crie uma equipe de governança em nuvem. Dê a uma equipe dedicada a responsabilidade pela propriedade, manutenção, envolvimento das partes interessadas, métricas e relatórios das políticas.
2. Avalie os riscos da nuvem. Avalie riscos regulatórios, de segurança, operacionais, de custos, de dados, de recursos e de IA no próprio contexto da organização.
3. Documente políticas de governança. Indique o uso aceitável da nuvem, o escopo, a justificativa, a propriedade, a aplicação, as exceções e as regras que reduzem cada risco relevante.
4. Aplique políticas de governança. Combine proteções automatizadas com controles manuais quando a automação for inadequada e torne a responsabilidade explícita entre as equipes de plataforma e de carga de trabalho.
5. Monitore a governança da nuvem. Estabeleça uma linha de base de conformidade, detecte violações e desvios, meça a eficácia das políticas e alimente as descobertas na próxima revisão de riscos e políticas.

Conclua todas as cinco etapas para estabelecer o modelo operacional. Em seguida, revise as etapas 2 a 5 regularmente. O monitoramento sem um responsável pela remediação produz relatórios, mas não governança; a aplicação sem contexto de risco pode bloquear o trabalho legítimo.

radio_button_uncheckedshort_text4. Do risco empresarial às disciplinas de governança

Uma política de governança corporativa começa com o risco comercial e a tolerância ao risco, informada pela classificação dos dados e pela criticidade da aplicação. As decisões de risco tornam-se declarações políticas inequívocas e os processos definem como as violações são detectadas, escaladas, corrigidas, aceitas e revisadas.

O Cloud Adoption Framework atual também trata conformidade regulatória, operações, gerenciamento de dados, provisionamento de recursos e IA como domínios explícitos de governança. As cinco disciplinas continuam sendo um modelo de estudo útil, mas um programa real deve cobrir todo o portfólio de riscos.

radio_button_uncheckedshort_text5. O que Azure Policy pode governar

Azure Policy fornece definições centralizadas, atribuições, resultados de conformidade, investigação de alterações e correção. Seu painel pode agregar o ambiente e depois detalhar por atribuição, definição e recurso. Como o Azure Policy está integrado à plataforma, uma barreira de proteção automatizada pode substituir com segurança determinadas etapas de aprovação manual.

• Restrinja a implantação a regiões aprovadas e implemente proteções de residência de dados.
• Permita apenas tamanhos de máquinas virtuais ou tipos de recursos aprovados.
• Exija e, com o efeito correto, adicione ou herde tags padronizadas como AppName.
• Audite criptografia, configurações de diagnóstico, atualizações, configuração de rede e linhas de base de segurança.
• Exija que os dados de diagnóstico sejam enviados a um workspace do Logs do Azure Monitor.
• Avalie os recursos existentes, bem como os recursos criados ou redimensionados após a atribuição da política.
• Conecte práticas de política como código aos fluxos de trabalho do Azure DevOps ou GitHub antes e depois da implantação.

O export menciona autenticação multifator para contas de assinatura como exemplo de política. Na arquitetura atual, o Acesso Condicional do Microsoft Entra é o controle principal para exigir autenticação multifator; o Azure Policy governa principalmente propriedades e ações compatíveis dos recursos do Azure. Use o plano de controle correto para cada requisito.

O desenho da política equilibra o controle e a estabilidade com a velocidade de entrega e os resultados de negócios. Teste o efeito, estime o impacto operacional, forneça mensagens de não conformidade compreensíveis e defina um processo de isenção controlado antes da aplicação ampla.

radio_button_uncheckedshort_text6. Hierarquia de governança, escopo e herança

O Azure fornece uma hierarquia de grupos de gerenciamento, assinaturas, grupos de recursos e recursos sob o grupo raiz do locatário. Um recurso pertence a um grupo de recursos; uma assinatura é um limite de gerenciamento, cobrança, cota e escala; grupos de gerenciamento organizam assinaturas para que acesso e políticas sejam administrados de forma consistente em escala empresarial.

As atribuições de escopo superior se aplicam aos descendentes elegíveis, exceto quando um filho é excluído ou isento. Uma política atribuída a uma assinatura pode afetar seus grupos de recursos e recursos; uma política em um grupo de recursos não afeta automaticamente um grupo vizinho. Os grupos de gerenciamento podem se estender por até seis níveis abaixo do grupo raiz do locatário.

Uma definição de política ou iniciativa é armazenada em um local de definição: um grupo de gerenciamento ou uma assinatura. Ela só pode ser atribuída a esse contêiner ou aos seus descendentes. Coloque uma definição reutilizável no nível mais baixo que ainda contenha todos os escopos de atribuição pretendidos.

radio_button_uncheckedshort_text7. Azure Resource Manager, plano de controle e plano de dados

Azure Resource Manager é a camada de implantação e gerenciamento para criar, atualizar e excluir recursos do Azure. O portal do Microsoft Azure, Azure PowerShell, CLI do Azure, APIs REST e SDKs de cliente usam as APIs do Resource Manager, que autenticam e autorizam uma solicitação de gerenciamento antes de encaminhá-la ao provedor de recursos apropriado.

Implantações de modelo, controle de acesso baseado em função do Azure (RBAC do Azure), auditoria, monitoramento, marcação e avaliação Azure Policy no modo Resource Manager participam do plano de controle. RBAC do Azure é avaliado antes de Azure Policy: se o chamador não estiver autorizado a executar a operação, a solicitação falhará antes da avaliação da política.

O plano de dados lida diretamente com dados de serviço, como carregar um blob, consultar um banco de dados ou ler um segredo do Azure Key Vault. Essas chamadas usam endpoints do serviço e RBAC específico ou listas de controle de acesso, em vez de passar pelo plano de controle do Azure Resource Manager. Os modos de política do Provedor de Recursos estendem o Azure Policy a planos de dados selecionados.

radio_button_uncheckedshort_text8. Modos de provedor de recursos e cenários de plano de dados suportados

A menos que a documentação diga explicitamente o contrário, os modos do Provedor de Recursos dão suporte apenas a definições internas e não dão suporte a isenções em nível de componente. O status do produto pode mudar, portanto verifique o suporte de modo e efeito antes de projetar um controle.

radio_button_uncheckedshort_text9. Fluxos de avaliação Greenfield e Brownfield

Em um fluxo Greenfield, ou policy-first, já existe uma atribuição quando um recurso é criado ou atualizado. Depois da autorização, o Azure Policy avalia o estado pretendido. Para uma atualização que contém apenas um delta, o serviço lê o recurso atual, mescla esse estado com as alterações solicitadas e avalia o estado de destino resultante.

Em um fluxo Brownfield, ou resource-first, os recursos já existem quando uma nova atribuição é introduzida. Uma verificação de conformidade lê os recursos aplicáveis e registra seu estado. Uma política deny que permita apenas Oeste da Europa não exclui recursos existentes em outros locais; ela os marca como não conformes e bloqueia solicitações futuras de criação ou atualização incompatíveis.

radio_button_uncheckedshort_text10. Os seis tipos de recursos do Azure Policy

radio_button_uncheckedshort_text11. Iniciativas, atribuições e controles de implementação

Definições e iniciativas internas são fornecidas pelos provedores de recursos do Azure. Definições e iniciativas personalizadas cobrem requisitos sem um item interno adequado. Microsoft for Sovereignty publica iniciativas e mapeamentos adicionais, que podem ser combinados com os itens internos depois que a organização validar suas próprias obrigações.

As atribuições podem ser criadas pelo portal, por API, Azure PowerShell ou CLI do Azure. Além do escopo e da definição de destino, uma atribuição pode incluir valores de parâmetros, versão da definição, seletores de recursos para exposição progressiva, substituições de efeito ou versão, enforcementMode, escopos excluídos em notScopes, mensagens de não conformidade e identidade gerenciada para correção com modify ou deployIfNotExists.

• Os seletores de recursos incluem gradualmente os recursos por propriedades como localização ou tipo, sem alterar o escopo da atribuição.
• As substituições alteram um efeito permitido ou uma versão de definição para referências selecionadas sem editar a iniciativa subjacente.
• Uma exclusão remove um descendente do escopo da atribuição; uma isenção é um recurso filho separado que documenta uma exceção aprovada.
• Os parâmetros permitem que a mesma definição imponha valores comerciais diferentes em atribuições diferentes.
• A identidade gerenciada atribuída pelo sistema ou pelo usuário fornece as permissões necessárias para os efeitos de remediação.

radio_button_uncheckedshort_text12. Isenções, atestados e remediações

Uma isenção é criada depois da atribuição e pode abranger uma hierarquia ou um recurso. O item isento permanece representado nos resultados agregados, mas não é avaliado pela atribuição. Use a categoria Mitigated quando outro controle satisfizer a intenção da política; use Waiver quando o estado não conforme for aceito temporariamente. Registre proprietário, justificativa, vencimento e controle compensatório.

O efeito manual depende de atestados. Cada recurso aplicável necessita de um atestado para cada atribuição manual, pelo que as definições manuais devem visar um âmbito cujo limite corresponda à evidência e ao modelo de propriedade.

Uma tarefa de correção coloca recursos existentes em conformidade com modify ou deployIfNotExists. Recursos aplicáveis recém-criados ou atualizados podem ser corrigidos automaticamente; os existentes exigem descoberta e uma tarefa. A identidade da atribuição executa as operações, portanto conceda somente as funções necessárias. Uma tarefa de deployIfNotExists ainda pode ser iniciada quando enforcementMode estiver definido como DoNotEnforce.

radio_button_uncheckedshort_text13. Anatomia de uma definição do Azure Policy

Nos modos do Resource Manager, all avalia assinaturas, grupos de recursos e todos os tipos de recurso. Indexed avalia somente tipos que oferecem suporte a tags e localização. O export fornecido descreve incorretamente os dois modos da mesma forma; a orientação atual recomenda all na maioria dos casos e indexed principalmente para regras de tag ou localização. Quando a regra tiver como alvo assinaturas ou os próprios grupos de recursos, use all e teste explicitamente o tipo correspondente.

Uma versão de definição usa Major.Minor.Patch. Uma versão principal pode introduzir alterações incompatíveis; uma secundária pode adicionar comportamentos ou valores compatíveis; e um patch normalmente altera textos ou metadados. Considere os indicadores preview e deprecated antes de uma atribuição em produção.

radio_button_uncheckedshort_text14. Regra de política, aliases, operadores lógicos e condições

O bloco if pode inspecionar um campo de recurso por meio de um alias do Azure Policy, comparar um valor calculado ou contar membros de uma matriz. Campos comuns incluem name, fullName, kind, type, location, id, identity.type, tags, tags nomeadas e aliases específicos do provedor. Aliases de matriz e expressões count permitem avaliar cada membro relevante.

Um erro de função ou expressão pode causar falha na avaliação e produzir uma negação implícita durante a avaliação no momento da solicitação. Teste com enforcementMode desabilitado, valide tipos e valores vazios e mantenha expressões complexas legíveis.

{
  "properties": {
    "displayName": "Limit workload regions",
    "mode": "Indexed",
    "parameters": {
      "approvedRegions": { "type": "Array" }
    },
    "policyRule": {
      "if": {
        "allOf": [
          { "field": "location", "notIn": "[parameters('approvedRegions')]" },
          { "field": "location", "notEquals": "global" }
        ]
      },
      "then": { "effect": "deny" }
    }
  }
}

Este exemplo original mantém os recursos localizados globalmente fora da verificação regional. Uma definição de produção também deve levar em conta os tipos de recursos cuja semântica de localização difere e deve ser testada em relação a recursos representativos.

radio_button_uncheckedshort_text15. Funções de política

As regras podem usar muitas funções de modelos do Azure Resource Manager, mas funções definidas pelo usuário e algumas exceções específicas não estão disponíveis. No Azure Policy, utcNow() pode ser usado fora de defaultValue e retorna o carimbo de data e hora UTC atual no formato ISO 8601.

radio_button_uncheckedshort_text16. Efeitos e ordem de avaliação

Em solicitações do Resource Manager, o Azure Policy verifica disabled primeiro; depois processa efeitos que alteram a solicitação, como append e modify; e então deny, audit e os demais efeitos aplicáveis. auditIfNotExists e deployIfNotExists são executados depois do sucesso do provedor de recursos. Várias atribuições são avaliadas de modo independente, e o resultado combinado é cumulativo e geralmente o mais restritivo.

audit, deny e modify ou append muitas vezes podem compartilhar uma definição parametrizada. auditIfNotExists e deployIfNotExists são alternativas frequentemente combinadas. manual não é intercambiável, enquanto disabled pode desativar qualquer efeito parametrizado.

radio_button_uncheckedshort_text17. Gatilhos e prazos de avaliação

• Uma política ou iniciativa foi atribuída recentemente ou uma atribuição existente foi atualizada.
• Um recurso é criado ou atualizado por meio de Azure Resource Manager, REST ou um SDK compatível.
• Uma assinatura é criada ou movida dentro de uma hierarquia de grupos de gerenciamento abrangida por uma atribuição.
• Uma isenção é criada, atualizada ou excluída.
• A Configuração da Máquina envia detalhes de conformidade atualizados.
• O ciclo de conformidade recorrente padrão é executado normalmente uma vez a cada 24 horas.
• Um administrador ou automação inicia uma verificação sob demanda.

O export diz que uma nova atribuição pode levar até 30 minutos para entrar em vigor e sugere sair e entrar novamente para atualizar o cache de sessão do Resource Manager. A documentação atual apresenta expectativas mais específicas: uma atribuição normalmente leva cerca de cinco minutos para ser aplicada antes do início da avaliação; um resultado de criação ou atualização pode aparecer aproximadamente 15 minutos depois; e a avaliação direcionada a uma assinatura pode levar cerca de 30 minutos. Um escopo grande não tem prazo fixo de conclusão, e a reautenticação não é uma garantia de nível de serviço.

A complexidade da definição, o número de atribuições, o tamanho do escopo, a carga do sistema e a baixa prioridade da verificação de conformidade afetam a duração. Consulte o portal, Logs do Azure Monitor, Azure Resource Graph, PolicyStates e PolicyEvents em vez de presumir a conclusão apenas pelo tempo decorrido.

az policy state trigger-scan --resource-group "example-rg"
Start-AzPolicyComplianceScan -ResourceGroupName 'example-rg'

A CLI do Azure e o Azure PowerShell podem iniciar verificações sob demanda. GitHub Actions também pode acionar uma verificação de conformidade e usar o resultado como critério de aprovação do fluxo de trabalho.

radio_button_uncheckedshort_text18. Estados e resultados agregados de conformidade

Os resultados agregados classificam os estados para que o mais significativo prevaleça; um resultado não conforme pode dominar vários resultados em conformidade dentro de uma iniciativa. Não registrado e Não iniciado não entram nesses cálculos.

A porcentagem de conformidade geral atual é calculada como (Conforme + Isento + Desconhecido + Protegido) dividido por (Conforme + Isento + Desconhecido + Não conforme + Conflitante + Erro + Protegido). Sempre examine as contagens e o escopo da atribuição junto com a porcentagem para que as exclusões e os estados manuais não escondam o risco.

radio_button_uncheckedshort_text19. enforcementMode e uma fase segura de simulação

enforcementMode é uma propriedade de atribuição. Habilitado mapeia para o valor JSON Default e impõe o efeito selecionado, suporta correção manual e pode criar entradas de log de atividades. Desativado mapeia para DoNotEnforce: a definição ainda avalia e relata a conformidade, mas o efeito não é executado e nenhuma entrada de efeito é gravada no log de atividades.

Isso difere do efeito desativado. Uma definição cujo efeito está desabilitado não é avaliada; uma atribuição com enforcementMode desabilitado é avaliada como um teste hipotético. Se enforcementMode for omitido, Default será aplicado.

radio_button_uncheckedshort_text20. Implantação segura com anéis e política como código

Trate definições e atribuições como código: controle suas versões, revise alterações por pares, teste recursos representativos, automatize a validação e promova por ambientes controlados. Comece atribuições impactantes, como deny e modify, com enforcementMode desabilitado; depois amplie a exposição por anéis de implantação.

1. Crie e valide a definição em um local de definição apropriado.
2. Crie uma atribuição com seletores de recursos para o primeiro anel pequeno de não produção e defina enforcementMode como DoNotEnforce.
3. Verifique os resultados de conformidade e a integridade do aplicativo; falsos positivos e regressões operacionais são modos de falha separados.
4. Repita as verificações para cada anel de não produção e atualize a definição ou atribuição quando necessário.
5. Habilite a aplicação para um anel validado e repita as verificações de conformidade e integridade.
6. Progrida através dos anéis de não produção restantes.
7. Expanda gradualmente para produção, começando com o subconjunto menor e menos crítico.
8. Monitore mudanças de estado, correções, sinais de suporte e impacto nos negócios durante a implementação.

Os seletores de recursos e as substituições de atribuição suportam a implementação gradual sem duplicar definições. Mantenha um procedimento de reversão de emergência ou de substituição de efeito e documente quem pode aprová-lo.

radio_button_uncheckedshort_text21. Reação a mudanças de estado com a Grade de Eventos

O Azure Policy pode publicar mudanças de estado pela Grade de Eventos para que aplicativos reajam sem sondagem ineficiente. Uma assinatura da Grade de Eventos cuida de roteamento, filtragem, novas tentativas, multicast e entrega em dead-letter ao destino configurado.

Os manipuladores de eventos podem incluir Azure Functions, Aplicativos Lógicos, serviços Azure suportados, ouvintes HTTP personalizados e webhooks. Mantenha o manipulador idempotente, autentique-o, valide o escopo do evento, registre dados de correlação e separe um alerta de uma correção aprovada automaticamente.

radio_button_uncheckedshort_text22. Verificação de conhecimento explicada

radio_button_uncheckedshort_text23. Resumo, recuperação ativa e recursos oficiais

• Conecte as decisões políticas ao risco comercial, clarifique a propriedade, a aplicação, o monitoramento e um ciclo de revisão.
• Coloque definições e atribuições em escopos que forneçam herança deliberada sem raio de explosão desnecessário.
• Entenda a avaliação de solicitações do plano de controle, as extensões do plano de dados e a diferença entre os fluxos que priorizam a política e os que priorizam os recursos.
• Use definições, iniciativas, atribuições, isenções, atestados e correções para responsabilidades de governança distintas.
• Crie regras a partir de aliases, condições, funções e efeitos e teste erros de função e casos extremos.
• Observe os atuais estados e prazos de conformidade, em vez de presumir que a atribuição significa uma avaliação completa imediata.
• Comece com DoNotEnforce, valide a conformidade e a integridade do aplicativo e promova por meio de anéis de implantação.
• Use a Grade de Eventos para reações oportunas, mantendo controles de aprovação, identidade e auditoria.

Exercícios de recuperação ativa

• Desenhe o fluxo completo de uma solicitação de gerenciamento pelo RBAC do Azure, Azure Policy, Azure Resource Manager, um provedor de recursos, dados de conformidade e correção.
• Projete uma iniciativa para regiões permitidas, tags obrigatórias, configurações de diagnóstico e proteção contra exclusão acidental. Identifique o efeito, o escopo, os parâmetros, as exclusões e os anéis de implementação de cada definição.
• Explique a diferença entre notScopes, isenções, enforcementMode, efeito: desabilitado e um atestado manual sem consultar o artigo.
• Compare as avaliações Greenfield e Brownfield e indique qual gatilho atualiza a conformidade em cada cenário.

• O que é o Azure Policy?
• Governança no Cloud Adoption Framework
• Conceitos básicos da estrutura de definição do Azure Policy
• Conceitos básicos dos efeitos do Azure Policy
• Estrutura de atribuição do Azure Policy
• Estados de conformidade do Azure Policy
• Obter dados de conformidade do Azure Policy
• Implantação segura de atribuições do Azure Policy
• Estrutura da tarefa de correção do Azure Policy
• Eventos de mudança de estado do Azure Policy