Partilhar via

Fundamentos dos efeitos das definições de política do Azure

Cada definição de política na Política do Azure tem uma única effect no seu policyRule. 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.

Os seguintes são os efeitos suportados na definição da Política do Azure:

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 permitido (allowedValues) para que uma única definição possa ser mais versátil durante a atribuição. 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 auditIfNotExists as políticas 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 mudança feita pode impedir que uma auditoria seja realizada ou que um 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 é avaliado.
  • manual é avaliado.
  • 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, deployIfNotExists avalia para determinar se mais log ou ação de conformidade são necessários.

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 que não esteja em eastus não cumpre a política 2 e não cumpre a política 1 se não estiver em westus.
  • A Política 1 nega qualquer novo recurso na subscrição A se não estiver em westus.
  • Qualquer novo recurso na subscrição A e no grupo de recursos B westus é criado e não cumpre 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 e não esteja em `eastus`, não está em conformidade com a política 2.
  • Qualquer recurso que já esteja no grupo de recursos B mas não esteja em westus está em não conformidade com a política 1.
  • A Política 1 nega qualquer novo recurso na subscrição A que não esteja em westus
  • Qualquer novo recurso no grupo de recursos B da assinatura A é negado

Cada trabalho é avaliado individualmente. Como tal, não existe uma oportunidade para um recurso passar por uma falha devido a variações 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