Compartilhar via

Conceitos básicos da estrutura de definição do Azure Policy

  • Artigo

As definições do Azure Policy descrevem as condições de conformidade de recursos e o efeito a ser realizado se uma condição for atendida. Uma condição compara um field ou um value da propriedade de recurso com um valor obrigatório. Os campos de propriedade de recurso são acessados por meio de aliases. Quando um campo de propriedade de recurso é uma matriz, um alias de matriz especial pode ser usado para selecionar valores de todos os membros da matriz e aplicar uma condição a cada um. Saiba mais sobre as condições.

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

Use o 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 os locais em que 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, acesse o esquema de definição de política. Os padrões e os itens internos do Azure Policy estão em Amostras do Azure Policy.

Nome de exibição e descrição

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

Observação

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

Tipo de política

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

  • Builtin: a Microsoft fornece e mantém essas definições de política.
  • Custom: Todas as definições de política criadas por clientes têm esse valor.
  • Static: Indica uma definição de política de Conformidade Regulatória com a Propriedade da Microsoft. Os resultados de conformidade para essas definições de política são os resultados de auditorias de terceiros na 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.

Mode

O mode é configurado dependendo do fato de a política ser direcionada a uma propriedade do Azure Resource Manager ou 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: avalia grupos de recursos, assinaturas e todos os tipos de recursos
  • indexed: avaliar apenas os tipos de recursos que oferecem suporte a marcas e local

Por exemplo, o recurso Microsoft.Network/routeTables dá suporte às marcas 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 modo indexed.

É recomendável definir o mode como all na maioria dos casos. Todas as definições de políticas criadas através do portal usam o modo all. Se você usar a CLI do Azure ou PowerShell, será necessário especificar o parâmetro mode manualmente. Se a definição de política não incluir um valor mode, ela usará como padrão all no Azure PowerShell e null na CLI do Azure. Um modo null é o mesmo que usar indexed para dar suporte à compatibilidade com versões anteriores.

indexed deve ser usado ao criar políticas que vão impor marcas ou locais. Embora não seja obrigatório, impedirá que recursos que não oferecem suporte a marcas nem locais apareçam como não compatíveis nos resultados de conformidade. Os grupos de recursos e as assinaturas são exceções a essa regra. As definições de política que impõem localização ou marcas em um grupo de recursos ou uma assinatura devem definir o mode como all e, especificamente, direcionar o tipo Microsoft.Resources/subscriptions/resourceGroups ou Microsoft.Resources/subscriptions. Para obter um exemplo, confira Padrão: Marcas – Amostra nº 1. Para obter uma lista de recursos que dão suporte a marcas, confira Suporte de marcas para recursos do Azure.

Modos do Provedor de Recursos

Os modos do Provedor de Recursos a seguir têm suporte completo:

Atualmente, há suporte para os seguintes modos do Provedor de Recursos como uma versão prévia:

  • Microsoft.ManagedHSM.Data para gerenciar as chaves Managed HSM (Hardware Security Module) usando o Azure Policy.
  • Microsoft.DataFactory.Data por usar o Azure Policy 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. Esse modo de Provedor de Recursos é somente imposição e não relata a conformidade na visualização pública.
  • Microsoft.MachineLearningServices.v2.Data para gerenciar implantações de modelo do Azure Machine Learning. Esse modo de Provedor de Recursos relata a conformidade para componentes recém-criados e atualizados. Durante a visualização pública, os registros 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 Teste de Carga do Azure a pontos de extremidade privados.

Observação

A menos que explicitamente indicado, os modos do Provedor de Recursos só dão suporte a definições de política internas, e as isenções não têm suporte no nível de componente.

Quando o controle de versão do Azure Policy for lançado, os seguintes modos do Provedor de Recursos não darão suporte ao controle de versão interno:

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

Versão (versão prévia)

Definições de política internas podem hospedar várias versões com o mesmo definitionID. Se nenhum número de versão for especificado, todas as experiências mostrarão a última versão da definição. Para ver uma versão específica de um item interno, ela deve ser especificada na API, no SDK ou na interface do usuário. Para fazer referência a uma versão específica de uma definição dentro de uma atribuição, consulte versão de definição dentro da atribuição

O serviço do Azure Policy usa as propriedades version, preview e deprecated para transmitir o estado e o nível de alteração para uma definição ou uma iniciativa de política interna. O formato de version é: {Major}.{Minor}.{Patch}. Quando uma definição de política está em estado de visualização, o sufixo preview é anexado à propriedade version e tratado como um booliano. Quando uma definição de política é preterida, a substituição é capturada como um booliano nos metadados da definição por meio de "deprecated": "true".

  • Versão principal (exemplo: 2.0.0): introduz alterações interruptivas, como alterações principais da lógica de regra, 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 alterações secundárias da lógica de regra, adição de novos valores permitidos de parâmetro, alteração em roleDefinitionIds, adição ou movimentação de definições em uma iniciativa.
  • Versão do patch (exemplo: 2.1.4): introduz alterações de cadeia de caracteres ou metadados e cenários de emergência de segurança (raro).

Para obter mais informações sobre itens internos de versões do Azure Policy, consulte Controle de versão de itens internos. Para saber o que significa uma política ser preterida ou estar em versão prévia, confira Políticas preteridas e em versão prévia.

Metadados

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

Propriedades de metadados comuns

  • version(cadeia de caracteres): Controla os detalhes sobre a versão do conteúdo de uma definição de política.
  • category (cadeia de caracteres): Determina em qual categoria do portal do Azure a definição de política é exibida.
  • preview (booleano): Sinalizador true ou false para se a definição for versão preliminar.
  • deprecated (booleano): sinalizador true ou false, se a definição de política estiver marcada como preterida.
  • portalReview (string): determina se os parâmetros devem ser conferidos no portal, independentemente da entrada necessária.

Local da definição

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

Se o local da definição for:

  • Assinatura - Somente os recursos dentro dessa assinatura podem ser atribuídos à definição de política.
  • Grupo de gerenciamento - Somente os recursos dentro de grupos de gerenciamento filho e assinaturas secundárias podem ser atribuídos à política. Se você planeja aplicar esta definição de política a diversas assinaturas, o local deve ser um grupo de gerenciamento que contém as assinaturas.

Para obter mais informações, veja Noções básicas do escopo no Azure Policy.

Próximas etapas