Noções básicas de efeito de definições de Política do Azure

  • Artigo

Cada definição de política na Política do Azure tem um único effectarquivo . Isso effect determina o que acontece quando a regra de política é avaliada para corresponder. Os efeitos se comportam de forma diferente se forem para um novo recurso, um recurso atualizado ou um recurso existente.

A seguir estão os efeitos de definição da Política do Azure com suporte:

Efeitos intercambiais

Por vezes, podem ser válidos efeitos múltiplos para uma determinada definição de política. Os parâmetros são frequentemente usados para especificar valores de efeito permitidos para que uma única definição possa ser mais versátil. No entanto, é importante notar que nem todos os efeitos são intercambiáveis. As propriedades e a lógica do recurso na regra de política podem determinar se um determinado efeito é considerado válido para a definição de política. Por exemplo, as definições de política com efeito auditIfNotExists exigem outros detalhes na regra de política que não são necessários para políticas com efeito audit. Os efeitos também se comportam de forma diferente. audit as políticas avaliam a conformidade de um recurso com base em suas próprias propriedades, enquanto as políticas 'auditIfNotExists avaliam a conformidade de um recurso com base nas propriedades de um recurso filho ou de extensão.

A lista a seguir contém algumas orientações gerais sobre efeitos intercambiáveis:

  • audit, denye ou modifyappend são frequentemente intercambiáveis.
  • auditIfNotExists e deployIfNotExists são frequentemente permutáveis.
  • Manual não é intercambiável.
  • disabled é permutável com qualquer efeito.

Ordem de avaliação

A primeira avaliação da Política do Azure é para solicitações para criar ou atualizar um recurso. O Azure Policy cria uma lista de todas as atribuições aplicáveis ao recurso e, em seguida, avalia o recurso em relação a cada definição. Para um modo do Gerenciador de Recursos, a Política do Azure processa vários dos efeitos antes de entregar a solicitação ao Provedor de Recursos apropriado. Essa ordem evita o processamento desnecessário por um Provedor de Recursos quando um recurso não atende aos controles de governança projetados da Política do Azure. Com um modo de Provedor de Recursos, o Provedor de Recursos gerencia a avaliação e o resultado e relata os resultados de volta à Política do Azure.

  • disabled é verificado primeiro para determinar se a regra de política deve ser avaliada.
  • append e modify , em seguida, são avaliados. Como qualquer um deles pode alterar a solicitação, uma alteração feita pode impedir que uma auditoria ou negar o efeito seja acionado. Estes efeitos só estão disponíveis com um modo Resource Manager.
  • deny é então avaliado. Ao avaliar a negação antes da auditoria, é evitado o duplo registo de um recurso indesejado.
  • audit é avaliada.
  • manual é avaliada.
  • auditIfNotExists é avaliada.
  • denyAction é avaliado em último lugar.

Depois que o Provedor de Recursos retornar um código de êxito em uma solicitação auditIfNotExists de modo do Gerenciador de Recursos e deployIfNotExists avaliar para determinar se mais log ou ação de conformidade é necessária.

PATCH Solicitações que modificam tags apenas campos relacionados Restringe a avaliação de políticas a políticas que contenham condições que inspecionam tags campos relacionados.

Definições de política em camadas

Várias atribuições podem afetar um recurso. Essas atribuições podem estar no mesmo escopo ou em escopos diferentes. É provável que cada uma destas tarefas também tenha um efeito diferente definido. A condição e o efeito de cada política são avaliados de forma independente. Por exemplo:

  • Política 1
    • Restringe a localização do recurso a westus
    • Atribuído à subscrição A
    • Negar efeito
  • Política 2
    • Restringe a localização do recurso a eastus
    • Atribuído ao grupo de recursos B na subscrição A
    • Efeito da auditoria

Essa configuração resultaria no seguinte resultado:

  • Qualquer recurso que já esteja no grupo de recursos B em eastus está em conformidade com a política 2 e não está em conformidade com a política 1
  • Qualquer recurso que já esteja no grupo de recursos B não esteja em eastus conformidade com a política 2 e não esteja em conformidade com a política 1 se não estiver em westus
  • A Política 1 nega qualquer novo recurso na subscrição A e não na westus
  • Qualquer novo recurso na subscrição A e no grupo de recursos B é westus criado e não está em conformidade com a política 2

Se tanto a política 1 como a política 2 tiveram efeito de negação, a situação muda para:

  • Qualquer recurso que já esteja no grupo de recursos B não esteja em eastus conformidade com a política 2
  • Qualquer recurso que já esteja no grupo de recursos B não esteja em westus conformidade com a política 1
  • A Política 1 nega qualquer novo recurso na subscrição A e não na westus
  • Qualquer novo recurso no grupo de recursos B da assinatura A é negado

Cada trabalho é avaliado individualmente. Como tal, não há uma oportunidade para um recurso escapar através de uma lacuna de diferenças no escopo. O resultado líquido das definições de políticas em camadas é considerado cumulativamente mais restritivo. Por exemplo, se ambas as políticas 1 e 2 tivessem efeito deny , um recurso seria bloqueado pelas definições de política sobrepostas e conflitantes. Se você ainda precisar que o recurso seja criado no escopo de destino, revise as exclusões em cada atribuição para validar se as atribuições de política corretas estão afetando os escopos corretos.

Próximos passos