Partilhar via

Noções básicas da estrutura de definição da Política do Azure

  • Artigo

As definições de Política do Azure descrevem as condições de conformidade de recursos e o efeito a ter se uma condição for atendida. Uma condição compara a propriedade campo ou valor de um recurso com um valor necessário. Pode aceder aos campos de propriedade dos recursos através de alias. Quando o campo de propriedade de um recurso é uma matriz, pode utilizar um alias de matriz especial para selecionar valores de todos os membros da matriz e aplicar uma condição a cada um. Saiba mais sobre as condições.

Usando atribuições de política, você pode controlar custos e gerenciar seus recursos. Por exemplo, você pode especificar que apenas determinados tipos de máquinas virtuais são permitidos. Ou, você pode exigir que os recursos tenham uma tag específica. As atribuições em um escopo se aplicam a todos os recursos nesse escopo e abaixo. Se for aplicada uma atribuição de política a um grupo de recursos, esta é aplicável a todos os recursos desse grupo de recursos.

Use JSON para criar uma definição de política que contenha elementos para:

  • displayName
  • description
  • mode
  • version
  • metadata
  • parameters
  • policyRule
    • avaliações lógicas
    • effect

Por exemplo, o JSON a seguir mostra uma política que limita onde os recursos são implantados:

{
  "properties": {
    "displayName": "Allowed locations",
    "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
    "mode": "Indexed",
    "metadata": {
      "version": "1.0.0",
      "category": "Locations"
    },
    "parameters": {
      "allowedLocations": {
        "type": "array",
        "metadata": {
          "description": "The list of locations that can be specified when deploying resources",
          "strongType": "location",
          "displayName": "Allowed locations"
        },
        "defaultValue": [
          "westus2"
        ]
      }
    },
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

Para obter mais informações, vá para o esquema de definição de política. Os padrões e internos da Política do Azure estão em Exemplos de Política do Azure.

Nome a apresentar e descrição

Você usa displayName e description para identificar a definição de política e fornecer contexto para quando a definição é usada. O displayName tem um comprimento máximo de 128 caracteres e description um comprimento máximo de 512 caracteres.

Nota

Durante a criação ou atualização de uma definição de política, id, type, e name são definidas por propriedades externas ao JSON e não são necessárias no arquivo JSON. Obter a definição de política via SDK retorna as idpropriedades , typee name como parte do JSON, mas cada uma é uma informação somente leitura relacionada à definição de política.

Tipo de política

Embora a policyType propriedade não possa ser definida, há três valores retornados pelo SDK e visíveis no portal:

  • Builtin: A Microsoft fornece e mantém estas definições de política.
  • Custom: Todas as definições de política criadas pelos clientes têm esse valor.
  • Static: Indica uma definição de política de Conformidade Regulatória com Propriedade da Microsoft. Os resultados de conformidade para essas definições de política são os resultados de auditorias que não são da Microsoft sobre a infraestrutura da Microsoft. No portal do Azure, esse valor às vezes é exibido como gerenciado pela Microsoft. Para obter mais informações, consulte Responsabilidade compartilhada na nuvem.

Modo

O mode é configurado dependendo se a política está direcionada a uma propriedade do Azure Resource Manager ou a uma propriedade do Provedor de Recursos.

Modos do Resource Manager

O mode determina quais tipos de recursos são avaliados para uma definição de política. Os modos suportados são:

  • all: avaliar grupos de recursos, assinaturas e todos os tipos de recursos
  • indexed: avalie apenas os tipos de recursos que suportam tags e localização

Por exemplo, o recurso Microsoft.Network/routeTables suporta tags e localização e é avaliado em ambos os modos. No entanto, o recurso Microsoft.Network/routeTables/routes não pode ser marcado e não é avaliado no indexed modo.

Recomendamos que você defina mode como na all maioria dos casos. Todas as definições de política criadas através do portal utilizam o all modo. Se você usar o PowerShell ou a CLI do Azure, poderá especificar o mode parâmetro manualmente. Se a definição de política não incluir um mode valor, ela assumirá all como padrão no Azure PowerShell e null na CLI do Azure. Um null modo é o mesmo que usar indexed para suportar compatibilidade com versões anteriores.

indexed deve ser usado ao criar políticas que imponham tags ou locais. Embora não seja necessário, ele impede que recursos que não suportam tags e locais apareçam como não compatíveis nos resultados de conformidade. A exceção são os grupos de recursos e as assinaturas. As definições de política que impõem localização ou tags em um grupo de recursos ou assinatura devem definir mode e all direcionar especificamente o Microsoft.Resources/subscriptions/resourceGroups tipo ou Microsoft.Resources/subscriptions . Para obter um exemplo, consulte Pattern: Tags - Sample #1. Para obter uma lista de recursos que dão suporte a tags, consulte Suporte de tags para recursos do Azure.

Modos de provedor de recursos

Os seguintes modos de Provedor de Recursos são totalmente suportados:

  • Microsoft.Kubernetes.Data para gerenciar clusters e componentes do Kubernetes, como pods, contêineres e ingressos. Com suporte para clusters do Serviço Kubernetes do Azure e clusters do Kubernetes habilitados para Azure Arc. As definições que usam esse modo de Provedor de Recursos usam os efeitos auditoria, negação e desabilitação.
  • Microsoft.KeyVault.Data para gerenciar cofres e certificados no Cofre da Chave do Azure. Para obter mais informações sobre essas definições de política, consulte Integrar o Azure Key Vault à Política do Azure.
  • Microsoft.Network.Data para gerenciar políticas de associação personalizadas do Azure Virtual Network Manager usando a Política do Azure.

Os seguintes modos de Provedor de Recursos são atualmente suportados como uma visualização:

  • Microsoft.ManagedHSM.Data para gerenciar chaves HSM (Managed Hardware Security Module) usando a Política do Azure.
  • Microsoft.DataFactory.Data para usar a Política do Azure para negar nomes de domínio de tráfego de saída do Azure Data Factory não especificados em uma lista de permissões. Este modo Provedor de Recursos é apenas imposição e não relata conformidade na visualização pública.
  • Microsoft.MachineLearningServices.v2.Data para gerenciar implantações de modelo do Azure Machine Learning . Este modo Provedor de Recursos relata a conformidade para componentes recém-criados e atualizados. Durante a pré-visualização pública, os registos de conformidade permanecem por 24 horas. As implantações de modelo que existem antes que essas definições de política sejam atribuídas não relatam a conformidade.

Nota

A menos que explicitamente declarado, os modos de Provedor de Recursos suportam apenas definições de política internas e isenções não são suportadas no nível do componente.

Quando o controle de versão da Política do Azure é lançado, os seguintes modos de Provedor de Recursos não oferecem suporte ao controle de versão interno:

  • Microsoft.DataFactory.Data
  • Microsoft.MachineLearningServices.v2.Data
  • Microsoft.ManagedHSM.Data

Versão (pré-visualização)

As definições de política incorporadas podem alojar várias versões com o mesmo definitionIDficheiro . Se nenhum número de versão for especificado, todas as experiências mostrarão a versão mais recente da definição. Para ver uma versão específica de um built-in, ele deve ser especificado em API, SDK ou UI. Para fazer referência a uma versão específica de uma definição dentro de uma atribuição, consulte Versão da definição dentro da atribuição

O serviço de Política do Azure usa version, previewe deprecated propriedades para transmitir o estado e o nível de alteração para uma definição ou iniciativa de política interna. O formato do version é: {Major}.{Minor}.{Patch}. Quando uma definição de política está no estado de visualização, a visualização do sufixo é anexada version à propriedade e tratada como booleana. Quando uma definição de política é preterida, a depreciação é capturada como um booleano nos metadados da definição usando "deprecated": "true".

  • Versão principal (exemplo: 2.0.0): introduz alterações de quebra, como alterações de lógica de regras principais, remoção de parâmetros, adição de um efeito de imposição por padrão.
  • Versão secundária (exemplo: 2.1.0): introduz alterações como pequenas alterações na lógica da regra, adicionando novos valores permitidos de parâmetros, alterando , roleDefinitionIdsadicionando ou movendo definições dentro de uma iniciativa.
  • Versão do patch (exemplo: 2.1.4): introduz alterações de cadeia de caracteres ou metadados e quebra de vidro em cenários de segurança (raros).

Para obter mais informações sobre versões internas da Política do Azure, consulte Controle de versão interno. Para saber mais sobre o que significa uma política ser preterida ou estar em pré-visualização, consulte Pré-visualização e políticas preteridas.

Metadados

A propriedade opcional metadata armazena informações sobre a definição de política. Os clientes podem definir quaisquer propriedades e valores úteis para sua organização no metadata. No entanto, há algumas propriedades comuns usadas pela Política do Azure e em internos. Cada metadata propriedade tem um limite de 1.024 caracteres.

Propriedades comuns de metadados

  • version (string): rastreia detalhes sobre a versão do conteúdo de uma definição de política.
  • category (string): determina em qual categoria no portal do Azure a definição de política é exibida.
  • preview (booleano): Sinalizador verdadeiro ou falso para se a definição de política for visualização.
  • deprecated (booleano): Sinalizador verdadeiro ou falso para se a definição de política estiver marcada como obsoleta.
  • portalReview (string): Determina se os parâmetros devem ser revisados no portal, independentemente da entrada necessária.

Localização da definição

Ao criar uma iniciativa ou política, é necessário especificar o local da definição. O local de definição deve ser um grupo de gerenciamento ou uma assinatura. Esse local determina o escopo ao qual a iniciativa ou política pode ser atribuída. Os recursos devem ser membros diretos ou filhos dentro da hierarquia do local de definição a ser direcionado para a atribuição.

Se a localização da definição for uma:

  • Subscrição - Apenas os recursos dentro dessa subscrição podem ser atribuídos à definição de política.
  • Grupo de gerenciamento - Somente recursos dentro de grupos de gerenciamento filho e assinaturas filho podem ser atribuídos à definição de política. Se você planeja aplicar a definição de política a várias assinaturas, o local deve ser um grupo de gerenciamento que contenha cada assinatura.

Para obter mais informações, veja Compreender o âmbito no Azure Policy.

Próximos passos