Partilhar via

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

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 aliases. 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 integrados e padrões da Política do Azure estão em Exemplos de Política do Azure.

Nome de exibição 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. Buscar a definição de política via SDK retorna as propriedades id, type e name como parte do JSON, mas cada uma é uma informação de leitura apenas, 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 sob 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 Gestor de Recursos

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 definir mode para all na 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 garantir compatibilidade retroativa.

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 para all e direcionar especificamente para o tipo Microsoft.Resources/subscriptions/resourceGroups 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:

Os seguintes modos de Fornecedor de Recursos são atualmente suportados como uma pré-visualização:

  • Microsoft.ManagedHSM.Data para gerenciar chaves HSM (Managed Hardware Security Module) usando a Política do Azure.
  • Microsoft.DataFactory.Data para utilizar a Política do Azure para negar nomes de domínio de tráfego de saída do Azure Data Factory que não estejam especificados numa lista de permitidos. Este modo do Provedor de Recursos é apenas para aplicação e não reporta conformidade na pré-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.
  • Microsoft.LoadTestService.Data para restringir instâncias do Azure Load Testing a pontos de extremidade privados.

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 definitionID. 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 recurso embutido, é necessário especificá-lo na API, SDK ou IU. 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, o sufixo preview é anexado à propriedade version e tratado como um valor boolean. 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): introduzir alterações significativas, como alterações na lógica de regras principais, remoção de parâmetros e adição de um efeito de aplicação por padrão.
  • Versão secundária (exemplo: 2.1.0): introduz alterações como pequenas alterações na lógica da regra, adição de novos valores permitidos para os parâmetros, alteração de roleDefinitionIds, e adição ou movimentação de definições dentro de uma iniciativa.
  • Versão do patch (exemplo: 2.1.4): introduz alterações em strings ou metadados e cenários de segurança de emergência (raros).

Para obter mais informações sobre versões incorporadas da Política do Azure, consulte Versionamento incorporado. Para saber mais sobre o significado de uma política estar descontinuada ou em versão preliminar, consulte Políticas em versão preliminar e descontinuadas.

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 Azure Policy e nas opções predefinidas. 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): Indicador verdadeiro ou falso para determinar se a definição da política está em pré-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