Compartilhar via

Fundamentos dos Efeitos das Definições de Política no Azure

Cada definição de política no Azure Policy tem um único effect em seu policyRule. Esse effect determina o que acontece quando a regra de política é avaliada para corresponder. Os efeitos se comportam de modo diferente caso sejam para um novo recurso, um recurso atualizado ou um recurso existente.

A seguir estão os efeitos de definição do Azure Policy com suporte:

Efeitos de intercâmbio

Às vezes, vários efeitos podem ser válidos em uma determinada definição de política. Os parâmetros geralmente são usados para especificar valores de efeito permitidos (allowedValues) para que uma única definição possa ser mais versátil durante a atribuição. No entanto, é importante observar que nem todos os efeitos são intercambiáveis. As propriedades e a lógica de 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. As políticas audit 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 extensão.

A lista a seguir é uma orientação geral sobre efeitos intercambiáveis:

  • audit, deny e modify ou append geralmente são intercambiáveis.
  • auditIfNotExists e deployIfNotExists geralmente são intercambiáveis.
  • manual não é intercambiável.
  • disabled é intercambiável com qualquer efeito.

Ordem de avaliação

A primeira avaliação do Azure Policy é para solicitações de criação ou atualização de um recurso. O Azure Policy cria uma lista de todas as atribuições que se aplicam ao recurso e o avalia em relação a cada definição. Para um modo do Resource Manager, o Azure Policy processa vários dos efeitos antes de encaminhar a solicitação para o provedor de recursos apropriado. Essa ordem impede o processamento desnecessário por um provedor de recursos quando um recurso não atende aos controles de governança criados pelo Azure Policy. Com um modo do provedor de recursos, o provedor de recursos gerencia a avaliação e o resultado e relata os resultados novamente ao Azure Policy.

  • disabled é verificado primeiro para determinar se a regra de política deve ser avaliada.
  • append e modify são então avaliados. Como cada um pode alterar a solicitação, a alteração realizada pode impedir uma auditoria ou negar o efeito do gatilho. Esses efeitos só estão disponíveis em um modo do Resource Manager.
  • deny é então avaliado. Ao avaliar o efeito negar antes da auditoria, evita-se o log duplo de um recurso indesejado.
  • audit é avaliado.
  • manual é avaliado.
  • auditIfNotExists é avaliado.
  • denyAction é avaliado por último.

Após o Provedor de Recursos retornar um código de êxito em uma solicitação no modo Resource Manager, auditIfNotExists e deployIfNotExists são avaliados para determinar se mais logs de conformidade ou ação são necessários.

As solicitações de PATCH que modificam apenas os campos relacionados a tags restringem a avaliação da política às políticas que contêm condições que inspecionam campos relacionados a tags.

Definições de políticas em camadas

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

  • Política 1
    • Restringe o local do recurso a westus
    • Atribuída à assinatura A
    • Efeito deny
  • Política 2
    • Restringe o local do recurso a eastus
    • Atribuída ao grupo de recursos B na assinatura A
    • Efeito audit

Essa configuração resultaria no seguinte:

  • Os recursos já presentes no grupo de recursos B em eastus estão em conformidade em relação à política 2 e fora de conformidade em relação à política 1
  • Os recursos presentes no grupo de recursos B e fora de eastus estão fora de conformidade em relação à política 2 e fora de conformidade em relação à política 1 se não estiverem em westus
  • A política 1 nega qualquer novo recurso na assinatura A que não esteja em westus
  • Novos recursos na assinatura A e no grupo de recursos B em westus são criados e estão fora de conformidade em relação à política 2

Se ambas as políticas 1 e 2 tiveram o efeito negar, a situação será alterada para:

  • Os recursos já presentes no grupo de recursos B fora de eastus serão marcados como fora de conformidade com a política 2
  • Os recursos já presentes no grupo de recursos B fora de westus serão marcados como fora de conformidade com a política 1
  • A política 1 nega qualquer novo recurso na assinatura A que não esteja em westus
  • Os novos recursos no grupo de recursos B da assinatura A são negados

Cada atribuição é avaliada individualmente. Assim, não existe chance de um recurso passar por uma brecha nas diferenças de escopo. O resultado das definições de políticas em camadas é considerado cumulativo mais restritivo. Por exemplo, se ambas as políticas 1 e 2 tivessem um efeito deny, um recurso seria bloqueado pelas definições de política sobrepostas e conflitantes. Caso ainda precise que o recurso seja criado no escopo de destino, revise as exclusões em cada atribuição para validar que as políticas corretas de atribuição estão afetando os escopos corretos.

Próximas etapas

  • Last updated on