Adotar diretrizes orientadas por política

Antes de usar políticas, você precisa entender onde elas são usadas nas implementações de referência da zona de destino do Azure e por quê. Este artigo ajudará você a entender se deseja impedir que as políticas DeployIfNotExists (ZH) ou Modify realizem alterações em seu ambiente do Azure.

Por que usar as políticas DINE e Modify?

As políticas ARD e Modify fazem parte das implementações de referência da zona de destino do Azure. Elas ajudam você e sua organização a garantir que suas zonas de destino, que também são conhecidas como assinaturas, e os recursos dentro delas são compatíveis. Essas políticas também removem a carga operacional para as equipes de plataforma e zona de destino à medida que seu ambiente do Azure é dimensionado.

Por exemplo, considere um cenário em que uma nova assinatura de zona de destino é provisionada e colocada no grupo de gerenciamento "corp". Em seguida, as políticas ADOBE e Modify tomarão as seguintes ações para a assinatura da zona de destino:

• Habilitar o Microsoft Defender para Nuvem. Configure as exportações do Defender para Nuvem para o workspace central do Log Analytics na assinatura de gerenciamento.
• Habilite o Defender para Nuvem para as diferentes ofertas com suporte com base nos parâmetros de política configurados na atribuição de política.
• Configure os logs de atividades do Azure a serem enviados para o workspace central do Log Analytics na assinatura de gerenciamento.
• Configure as definições de diagnóstico para todos os recursos a serem enviados para o workspace central do Log Analytics na assinatura de gerenciamento.
• Implante os agentes de Azure Monitor necessários para máquinas virtuais e Conjuntos de Dimensionamento de Máquinas Virtuais do Azure, incluindo servidores Azure Arc conectados. Conecte-os ao workspace central do Log Analytics na assinatura de gerenciamento.

Observação

Você pode desabilitar as opções anteriores a qualquer momento ou durante as implantações de referência da zona de destino do Azure.

A lista anterior mostra um subconjunto de todas as políticas atribuídas como parte do acelerador de zona de destino do Azure. Para obter uma lista completa de políticas que podem ser atribuídas pela implementação de referência de zona de aterrissagem do Azure, consulte Políticas incluídas em implementações de referência de zonas de aterrissagem do Azure.

O repositório bicep das zonas de aterrissagem do Azure é modular. As políticas padrão acima podem ser implantadas com o módulo ALZ Default Policy Assignments.

Todas as políticas atribuídas ajudam você e os proprietários da zona de destino a permanecerem em conformidade. Nenhum recurso de carga de trabalho real é implantado por meio de políticas DINE ou Modify. Também não recomendamos isso. Para obter mais informações, consulte Devemos usar o Azure Policy para implantar cargas de trabalho?. Somente recursos auxiliares ou de suporte ou configurações são implantados ou configurados por essas políticas de DINE.

As implementações de referência de zonas de destino do Azure usam políticas do Azure DINE para ajudar você a obter governança controlada por políticas em seu ambiente do Azure. Mas talvez você não possa usar políticas DINE ou Modify ou não está pronto para habilitar esse tipo de efeito de política do Azure devido a:

• Políticas de conformidade regulatória, padrões ou restrições legais.
• Processos rigorosos de controle de alterações que exigem aprovação humana para cada ação em seu ambiente do Azure.
• Falta de experiência, experiência e compreensão de como gerenciar e usar políticas DINE.
• Requisitos organizacionais que toda a configuração de recursos de carga de trabalho, incluindo recursos auxiliares, recursos de suporte e configurações, são definidos na infraestrutura como código (IaC) pelas equipes de aplicativos de carga de trabalho.

Se o seu caso for exemplos anteriores ou cenários semelhantes, este artigo ajudará você a entender como adotar a arquitetura conceitual da zona de destino do Azure e seguir seus princípios de design. Embora você não use determinadas políticas inicialmente, você pode optar por habilita-las gradualmente no futuro. A meta é ajudar você a obter governança controlada por políticas.

Importante

Ao longo deste artigo, você verá dois valores possíveis usados para os termos de modo de imposição:

• Desabilitado ou DoNotEnforce
• Habilitado ou Padrão

O portal do Azure usa Desabilitado e Habilitado para o modo de imposição. Azure Resource Manager (ARM) e outras interfaces de API usam DoNotEnforce e Default para as mesmas opções.

Para mais informações, confira Modo de imposição.

Se você ainda tiver certeza de que sua organização não pode usar políticas de DINE ou Modify, este artigo explica como impedir (também conhecido como desabilitar) as políticas de fazer alterações automáticas em seu ambiente do Azure.

Observação

Essa operação não é permanente. As políticas podem ser reativadas a qualquer momento por um membro de sua equipe de plataforma se você decidir usar as políticas DINE ou Modify posteriormente.

Para obter mais informações, consulte fase 2 e fase 3.

O suporte para seletores de recursos também é aplicável à governança orientada por políticas para garantir que as Práticas de Implantação Segura (SDP) estejam sendo cumpridas. Os seletores de recursos trazem a funcionalidade de implantação gradual de atribuições de política com base em fatores como local do recurso, tipo de recurso ou se o recurso tem um local. Mais informações podem ser encontradas neste documento.

Visão geral da abordagem

O diagrama a seguir resume a abordagem em fases sugerida:

1. Defina o modo de imposição como em atribuições de DoNotEnforce política:
   • Usando esse recurso, você pode modificar o comportamento das atribuições para se tornar efetivamente uma política somente auditoria, sem modificar a definição de política subjacente.
   • Essa abordagem também permite que você faça tarefas de correção manual em recursos não compatíveis usando tarefas de correção, se quiser.
2. Defina o modo de imposição como Default em atribuições de política para reativar a correção automática de atribuições de política DINE em um escopo reduzido:
   • Você pode optar por usar um ambiente inteiro, por exemplo, o grupo de gerenciamento de Área restrita.
   • Ou você pode usar uma assinatura de carga de trabalho não crítica.
3. Defina o modo de imposição como Default nas atribuições de política nas políticas DINE restantes em todo o ambiente do Azure.

Devido às restrições de conformidade regulatória, alguns clientes podem não passar da fase 1. Esse não é um problema e tem suporte para permanecer nesse estado, se necessário. Outros clientes podem avançar para as fases 2 e 3 para adotar totalmente as políticas DINE e Modify para auxiliar na governança controlada por políticas para seu ambiente do Azure.

Observação

O cenário e a abordagem descritos neste artigo não se destinam nem são recomendados para a maioria dos clientes. Revise a seção Por que usar as políticas DINE e Modify? antes de decidir se essas políticas são adequadas e necessárias para seu ambiente.

Fase 1: desabilitar ações automatizadas de políticas DINE e Modify

Quando você atribui uma política, por padrão, o efeito definido na definição de política será aplicado. Recomendamos que você não altere a definição de política. Por exemplo, deixe o efeito de atribuição de política como DeployIfNotExists.

Em vez de alterar a definição de política ou seu efeito, você pode influenciar esse comportamento com esforço mínimo usando o recurso em atribuições de política.

Use o portal do Azure para definir o modo de imposição como Desabilitado

Esta captura de tela mostra como usar o portal do Azure para definir o modo de imposição como Desabilitado em uma atribuição de política. Desabilitado também é conhecido como DoNotEnforce.

Use o modelo do ARM para definir o modo de imposição como DoNotEnforce

Este exemplo de código mostra como usar um modelo do ARM para definir enforcementMode como em DoNotEnforce uma atribuição de política. DoNotEnforce também é conhecida como Disabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "DoNotEnforce"
    … // other properties removed for display purposes
  }
}

Usando o modo de imposição, você pode ver o efeito de uma política em recursos existentes sem iniciá-la ou disparar entradas no log de atividades do Azure. Esse cenário é conhecido como “What If” e alinha-se às práticas de implantação seguras.

Mesmo quando o modo de imposição é definido como DoNotEnforce, as tarefas de correção podem ser disparadas manualmente. Você pode corrigir recursos incompatíveis específicos. Você também poderá ver o que a política DINE ou Modify teria feito se o modo de imposição fosse definido como Default.

Importante

Quando o modo de imposição é definido como DoNotEnforce, as entradas no log de atividades do Azure não são geradas. Considere esse fator se você quiser ser notificado quando um recurso não compatível for criado.

Permanecer no estado da fase 1 permanentemente

Conforme mencionado na seção Visão geral da abordagem, alguns clientes talvez precisem permanecer na fase 1 por um longo período, ou até mesmo permanentemente, devido a seus requisitos. Esse estado é válido e os clientes podem permanecer nele por qualquer período.

Talvez você precise permanecer nesse estado permanentemente ou por um longo período, como anos. Em caso afirmativo, talvez seja melhor adotar o efeito da política (AINE) AuditIfNotExists e as definições associadas e definir o modo de imposição de volta como Default.

Observação

Ao alterar para usar uma política AINE e definir o modo de imposição como Default, você ainda atingirá a mesma meta de desabilitar DINE.

Quando você alterar de DINE para AINE e definir o modo de imposição de volta como Default uma abordagem permanente ou de longo prazo para a fase 1, obterá novamente as entradas do log de atividades do Azure para os status de conformidade da política. Você pode criar fluxos de trabalho de automação com base nessas entradas de log em suas operações gerais de gerenciamento de plataforma.

Você perderá a capacidade de realizar tarefas manuais de correção. Ao contrário das políticas DINE, as políticas AINE não executam nenhuma implantação, seja automatizada ou manual.

Lembre-se de atualizar a definição de política para aceitar e permitir o efeito de atribuição de política AuditIfNotExists.

A tabela a seguir resume as opções e implicações para os diferentes tipos de efeitos de política e combinações de modo de imposição:

Efeito de política	Modo de imposição	Entrada do log de atividades	Ação de correção
DINE	Habilitado ou Padrão	Sim	Correção acionada por plataforma em escala após a criação ou atualização de recurso. Criação manual de uma tarefa de correção necessária, se o recurso dependente for modificado ou preexistente antes da atribuição de política.
DINE	Desabilitado ou DoNotEnforce	Não	Criação manual de uma tarefa de correção necessária.
Modificar	Habilitado ou Padrão	Sim	Correção automática durante a criação ou atualização.
Modificar	Desabilitado ou DoNotEnforce	Não	Criação manual de uma tarefa de correção necessária.
Negar	Habilitado ou Padrão	Sim	Criação ou atualização negada.
Negar	Desabilitado ou DoNotEnforce	Não	Criação ou atualização permitida. Correção manual necessária.
Auditoria/AINE	Habilitado ou Padrão	Sim	Correção manual necessária.
Auditoria/AINE	Desabilitado ou DoNotEnforce	Não	Correção manual necessária.

Observação

Examine as diretrizes em Reagir a eventos de alteração de estado do Azure Policy para entender se o uso da integração da Grade de Eventos do Azure com o Azure Policy fornece uma abordagem adequada, caso você planeje criar sua própria automação com base em eventos de estado de política.

Fase 2: habilitar DINE e modificar as políticas em uma política específica ou escopo reduzido

Nesta fase, você aprenderá a definir o modo de imposição como Default em atribuições de política.

Depois de concluir a fase 1, você decide que deseja testar e experimentar os recursos completos de automação das políticas DINE e Modify em uma política específica ou em um escopo reduzido. Você deseja usar o grupo de gerenciamento da área restrita ou uma assinatura de carga de trabalho de não produção.

Para executar esse procedimento, primeiro você precisa identificar a política ou o escopo reduzido que será usado para testar e experimentar as funcionalidades de automação completa das políticas DINE e Modify.

Observação

Talvez você queira examinar e implementar uma abordagem de teste para uma plataforma de escala empresarial. Dessa forma, você pode testar políticas e outras alterações de plataforma em uma hierarquia de grupo de gerenciamento separada dentro do mesmo locatário.

Essa abordagem também é conhecida como implantação "canário".

Alguns exemplos sugeridos de escopos e políticas são mostrados na tabela a seguir:

Quando você quiser...	...escolha entre essas opções	Exemplo de políticas a serem usadas
- Testar os recursos de correção automatizada DINE/Modify. - Verificar como seus processos de implantação completos e pipelines de CI/CD, incluindo testes, podem ser afetados. - Verificar como sua carga de trabalho pode ser afetada.	- Assinatura Sandbox - Grupo de gerenciamento de sandbox - Assinatura da zona de aterrissagem de carga de trabalho de não produção - Ambiente de "canário" de escala empresarial	Configurar logs de atividades do Azure para transmissão para o workspace especificado do Log Analytics. - Implantar a configuração do Defender for Cloud. - Habilitar o Azure Monitor para VMs ou Conjuntos de Dimensionamento de Máquinas Virtuais do Azure. - Implantar configurações de diagnóstico nos serviços do Azure. - Possivelmente habilitar apenas para serviços específicos dentro da iniciativa.

Você também pode decidir usar uma tarefa de correção manual em um escopo limitado ou conjunto de recursos para testar como essas políticas afetarão seu ambiente. Para obter mais informações sobre como criar uma tarefa de correção, consulte a documentação do Azure Policy Criar uma tarefa de correção.

Depois de identificar uma política, ou políticas, e o escopo reduzido para atribuí-las, a próxima etapa é atribuir a política e definir o modo de imposição como Default. Deixe o efeito de política, por exemplo, DeployIfNotExists ou Modify, como está no escopo reduzido que você selecionou.

Use o portal do Azure para definir o modo de imposição como Habilitado

Esta captura de tela mostra como usar o portal do Azure para definir o modo de imposição como Habilitado em uma atribuição de política. Habilitado também é conhecido como padrão.

Use um modelo do ARM para definir o modo de aplicação como padrão

Este exemplo de código mostra como usar um modelo do ARM para definir enforcementMode como em Default uma atribuição de política. Default também é conhecida como Enabled.

{
  "type": "Microsoft.Authorization/policyAssignments",
  "apiVersion": "2019-09-01",
  "name": "PolicyAssignmentName",
  "location": "[deployment().location]",
  "properties": {
    "description": "PolicyAssignmentDescription",
    "policyDefinitionId": "[parameters('policyDefinitionId')]",
    "enforcementMode": "Default"
    … // other properties removed for display purposes
  }
}

Testando

A última etapa desta fase é fazer os testes necessários. Você deseja verificar se e como as políticas DINE ou Modify podem ter sido afetadas e alterado as cargas de trabalho, código, ferramentas e processos.

Execute vários testes para capturar todo o ciclo de vida de sua carga de trabalho. Você deseja garantir que compreende totalmente se e como as políticas DINE ou Modify.

Alguns exemplos de teste são:

• Implantação inicial da carga de trabalho.
• Implantação de código/aplicativo na carga de trabalho.
• Operações do dia 2 e gerenciamento de carga de trabalho.
• Encerramento da carga de trabalho.

Fase 3: habilitar as políticas DINE e Modify em qualquer lugar

Nesta fase, você aprenderá a definir o modo de imposição como Default em atribuições de política.

Supomos que seu teste no final da fase 2 foi aprovado com êxito. Ou talvez você esteja convencido de que agora entendeu como as políticas DINE e Modify interagem com sua carga de trabalho. Agora você pode expandir o uso das políticas DINE e Modify no restante do seu ambiente do Azure.

Para continuar, siga as etapas que são semelhantes às etapas na fase 2. Desta vez, você define o modo de imposição como Default em todas as atribuições da política DINE e Modify em todo o seu ambiente do Azure.

Aqui está uma visão geral de alto nível das etapas que você faz nesta fase:

• Remova as atribuições usadas especificamente para teste durante a fase 2.
• Percorra cada atribuição de política DINE e Modify em seu ambiente do Azure e defina o modo de imposição como Default. Esse processo é mostrado nos exemplos na fase 2.
• Crie tarefas de correção para recursos existentes que não estão em conformidade seguindo as orientações em Criar uma tarefa de correção. Novos recursos serão corrigidos automaticamente se corresponderem às regras de política e condições de existência.

Embora, na fase 3, seja recomendável que você defina o modo de imposição como Default para todas as políticas DINE e Modify em seu ambiente do Azure, essa opção ainda é opcional. Você pode fazer essa escolha de acordo com a política para atender às suas necessidades e requisitos.

Gerenciamento avançado de políticas

Para obter gerenciamento avançado da Política do Azure em escala, considere implementar a Política Empresarial como Código (EPAC) para gerenciar a política. O EPAC fornece uma experiência de gerenciamento com monitoração de estado que usa IaC. Geralmente, ele se adapta a grandes cenários de gerenciamento de políticas com requisitos complexos.