Compartilhar via

Tutorial: Criar uma definição de política personalizada

  • Artigo

Uma definição de política personalizada permite que os clientes definam suas próprias regras para uso do Azure. Geralmente, essas regras impõem:

  • Práticas de segurança.
  • Gerenciamento de custos.
  • Regras específicas da organização (como nomenclatura ou localizações).

Seja qual for o fator empresarial para a criação de uma política personalizada, as etapas serão as mesmas para definição da nova política personalizada.

Antes de criar uma política personalizada, verifique os exemplos de política para ver se uma política que atende às suas necessidades já existe.

A abordagem para criação de uma política personalizada segue estas etapas:

  • Identificar seus requisitos de negócios
  • Mapear cada requisito para uma propriedade de recurso do Azure
  • Mapear a propriedade para um alias
  • Determinar qual efeito será usado
  • Redigir a definição de política

Pré-requisitos

Se você não tiver uma assinatura do Azure, crie uma conta gratuita antes de começar.

Identificar os requisitos

Antes de criar a definição de política, é importante entender a intenção dela. Este tutorial usa um requisito comum de segurança corporativa com o objetivo de ilustrar as etapas envolvidas:

  • Cada conta de armazenamento precisa ser habilitada para HTTPS.
  • Cada conta de armazenamento precisa ser desabilitada para HTTP.

Seus requisitos devem identificar claramente os estados de recursos como eles "devem ser" e "não devem ser".

Embora o estado esperado do recurso tenha sido definido, não foi definido o que deve ser feito com os recursos não compatíveis. O Azure Policy dá suporte a muitos efeitos. Neste tutorial, você define o requisito de negócios que evita a criação de recursos quando eles não estão em conformidade com as regras de negócios. Para cumprir essa meta, você usará o efeito negar. Também queremos ter a opção de suspender a política para atribuições específicas. Use o efeito desabilitado e transforme-o em um parâmetro na definição de política.

Determinar as propriedades de recurso

Com base nos requisitos de negócios, o recurso do Azure para auditoria com o Azure Policy é uma conta de armazenamento. No entanto, não sabemos quais propriedades devemos usar na definição de política. O Azure Policy realiza a avaliação com base na representação JSON do recurso, portanto é importante entender as propriedades disponíveis no recurso.

Há várias maneiras de determinar as propriedades de um recurso do Azure. Neste tutorial, você analisará cada um dos seguintes:

  • Extensão do Azure Policy para VS Code.
  • Modelos do ARM (modelos do Azure Resource Manager).
    • Exportação de um recurso atual.
    • Experiência de criação.
    • Modelos de início rápido (GitHub).
    • Documentação de referência do modelo.
  • Azure Resource Explorer.

Exibir recursos na extensão do VS Code

A extensão do VS Code pode ser usada para procurar recursos em seu ambiente e ver as propriedades do Resource Manager em cada recurso.

Modelos de ARM

Há várias maneiras de examinar um modelo do ARM que inclui a propriedade que você deseja gerenciar.

Recurso existente no portal

A maneira mais simples de encontrar propriedades é examinar um recurso existente do mesmo tipo. Os recursos já definidos com a configuração que você deseja impor também fornecem o valor para comparação. Para acessar esse recurso específico, confira a página Exportar modelo em Configurações no portal do Azure.

Aviso

O modelo ARM exportado pelo portal do Azure não pode ser conectado diretamente à propriedade deployment para um modelo do ARM em uma definição de política de deployIfNotExists.

Captura de tela da página Exportar modelo em um recurso existente do portal do Azure.

Fazer isso para uma conta de armazenamento revela um modelo semelhante a este exemplo:

"resources": [
  {
    "comments": "Generalized from resource: '/subscriptions/{subscriptionId}/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount'.",
    "type": "Microsoft.Storage/storageAccounts",
    "sku": {
      "name": "Standard_LRS",
      "tier": "Standard"
    },
    "kind": "Storage",
    "name": "[parameters('storageAccounts_mystorageaccount_name')]",
    "apiVersion": "2018-07-01",
    "location": "westus",
    "tags": {
      "ms-resource-usage": "azure-cloud-shell"
    },
    "scale": null,
    "properties": {
      "networkAcls": {
        "bypass": "AzureServices",
        "virtualNetworkRules": [],
        "ipRules": [],
        "defaultAction": "Allow"
      },
      "supportsHttpsTrafficOnly": false,
      "encryption": {
        "services": {
          "file": {
            "enabled": true
          },
          "blob": {
            "enabled": true
          }
        },
        "keySource": "Microsoft.Storage"
      }
    },
    "dependsOn": []
  }
]

Em properties, há um valor chamado supportsHttpsTrafficOnly definido como false. Essa é a propriedade relevante. Além disso, o type do recurso é Microsoft.Storage/storageAccounts. O tipo permite limitar a política somente aos recursos desse tipo.

Criar um recurso no portal

Outra maneira por meio do portal é a experiência de criação de recursos. Ao criar uma conta de armazenamento por meio do portal, há uma opção Transferência de segurança necessária na guia Avançado. Essa propriedade tem as opções Desabilitado e Habilitado. De acordo com as informações no ícone de informações, essa opção provavelmente é a propriedade necessária. No entanto, o portal não informa o nome da propriedade nessa tela.

Na guia Examinar + criar, há um link na parte inferior da página para Baixar um modelo para automação. A seleção do link abre o modelo que cria o recurso que configuramos. Nesse caso, vemos duas informações essenciais:

...
"supportsHttpsTrafficOnly": {
  "type": "bool"
}
...
"properties": {
  "accessTier": "[parameters('accessTier')]",
  "supportsHttpsTrafficOnly": "[parameters('supportsHttpsTrafficOnly')]"
}
...

De acordo com essas informações, é possível saber o tipo de propriedade e também confirmar que supportsHttpsTrafficOnly é a propriedade relevante.

Modelos de Início Rápido no GitHub

Os modelos de início rápido do Azure no GitHub contêm centenas de modelos do ARM criados para diferentes recursos. Esses modelos podem ser uma ótima maneira de encontrar a propriedade de recurso que você está procurando. Algumas propriedades podem parecer o que você deseja, mas controlar outra coisa.

Documentação de referência de recurso

Para validar se supportsHttpsTrafficOnly é a propriedade correta, verifique a referência do modelo do ARM quanto ao recurso da conta de armazenamento no provedor de armazenamento. O objeto de propriedades tem uma lista de parâmetros válidos. Ao selecionar o link do objeto StorageAccountPropertiesCreateParameters, é exibida uma tabela de propriedades aceitáveis. supportsHttpsTrafficOnly está presente e a descrição corresponde aos requisitos de negócios desejados.

Azure Resource Explorer

Outra maneira de explorar os recursos do Azure é por meio do Azure Resource Explorer (versão prévia). Essa ferramenta usa o contexto de sua assinatura e, portanto, você precisa se autenticar no site com suas credenciais do Azure. Depois de autenticado, você poderá procurar por provedores, assinaturas, grupos de recursos e recursos.

Localize um recurso de conta de armazenamento e examine as propriedades. A propriedade supportsHttpsTrafficOnly também é exibida aqui. Selecionando a guia Documentação, vemos que a descrição da propriedade corresponde ao que encontramos na documentação de referência anteriormente.

Encontrar o alias de propriedade

A propriedade do recurso foi identificada, mas é preciso mapeá-la para um alias.

Há algumas maneiras de determinar os aliases para um recurso do Azure. Neste tutorial, você analisará cada um dos seguintes:

  • Extensão do Azure Policy para VS Code.
  • CLI do Azure.
  • Azure PowerShell.

Obter aliases na extensão do VS Code

A extensão do Azure Policy para a extensão do VS Code facilita a navegação de seus recursos e a descoberta de aliases.

Observação

A extensão VS Code apenas expõe as propriedades do modo Resource Manager e não exibe nenhuma propriedade do modo de Provedor de Recursos.

CLI do Azure

Na CLI do Azure, o grupo de comandos az provider é usado para pesquisar aliases de recurso. Filtramos o namespace Microsoft.Storage com base nos detalhes obtidos anteriormente sobre o recurso do Azure.

# Login first with az login if not using Cloud Shell

# Get Azure Policy aliases for type Microsoft.Storage
az provider show --namespace Microsoft.Storage --expand "resourceTypes/aliases" --query "resourceTypes[].aliases[].name"

Nos resultados, é possível observar um alias compatível com as contas de armazenamento denominadas supportsHttpsTrafficOnly. A existência desse alias significa que podemos escrever a política para impor nossos requisitos de negócios.

Azure PowerShell

No Azure PowerShell, o cmdlet Get-AzPolicyAlias é usado para pesquisar aliases de recurso. Faça a filtragem do namespace Microsoft.Storage com base nos detalhes obtidos anteriormente sobre o recurso do Azure.

# Login first with Connect-AzAccount if not using Cloud Shell

# Use Get-AzPolicyAlias to list aliases for Microsoft.Storage
(Get-AzPolicyAlias -NamespaceMatch 'Microsoft.Storage').Aliases

Assim como na CLI do Azure, os resultados mostram um alias compatível com as contas de armazenamento denominadas supportsHttpsTrafficOnly.

Determinar o efeito a ser usado

Decidir o que fazer com os recursos fora de conformidade é tão importante quanto decidir o que deve ser avaliado em primeiro lugar. Cada resposta possível para um recurso fora de conformidade é chamada de efeito. O efeito controla se o recurso fora de conformidade está conectado, bloqueado, tem dados acrescentados ou tem uma implantação associada a ele para colocar o recurso novamente em um estado de conformidade.

Neste exemplo, deny é o efeito desejado porque evita a criação de recursos fora de conformidade no ambiente do Azure. A auditoria é uma boa primeira escolha para o efeito de uma política, porque ajuda a determinar o efeito dela antes da definição como deny. Uma forma de facilitar a alteração do efeito por atribuição é parametrizar o efeito. Confira parâmetros para saber mais.

Redigir a definição

Agora, temos os detalhes da propriedade e um alias para o que planejamos gerenciar. Em seguida, você precisa criar a regra de política. Se você não tiver familiaridade com a linguagem da política, confira a estrutura de definição de política para saber como estruturar a definição. Confira um modelo vazio de como seria uma definição de política:

{
  "properties": {
    "displayName": "<displayName>",
    "description": "<description>",
    "mode": "<mode>",
    "parameters": {
              <parameters>
    },
    "policyRule": {
      "if": {
              <rule>
      },
      "then": {
        "effect": "<effect>"
      }
    }
  }
}

Metadados

Os três primeiros componentes são os metadados da política. É fácil fornecer valores para esses componentes, pois sabemos para o que estamos criando a regra. O modo trata principalmente das marcas e da localização dos recursos. Como não é preciso limitar a avaliação aos recursos compatíveis com tags, use o valor all para mode.

"displayName": "Deny storage accounts not using only HTTPS",
"description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
"mode": "all",

Parâmetros

Embora um parâmetro não tenha sido usado para alterar a avaliação, você usará um parâmetro para permitir a alteração de effect para a solução de problemas. Defina um parâmetro effectType e limite-o apenas a deny e disabled. Essas duas opções correspondem aos nossos requisitos de negócios. O bloco de parâmetros concluído é parecido com este exemplo:

"parameters": {
  "effectType": {
    "type": "string",
    "defaultValue": "Deny",
    "allowedValues": [
      "Deny",
      "Disabled"
    ],
    "metadata": {
      "displayName": "Effect",
      "description": "Enable or disable the execution of the policy"
    }
  }
},

Regra de política

A redação da regra de política é a etapa final na criação de nossa definição de política personalizada. Duas instruções foram identificadas para teste:

  • A conta de armazenamento type é Microsoft.Storage/storageAccounts.
  • A conta de armazenamento supportsHttpsTrafficOnly não é true.

Como ambas as instruções precisam ser verdadeiras, use o operador lógico allOf. Transmita o parâmetro effectType para o efeito em vez de fazer uma declaração estática. Nossa regra concluída é parecida com este exemplo:

"if": {
  "allOf": [
    {
      "field": "type",
      "equals": "Microsoft.Storage/storageAccounts"
    },
    {
      "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
      "notEquals": "true"
    }
  ]
},
"then": {
  "effect": "[parameters('effectType')]"
}

Definição concluída

Com todas as três partes da política definida, esta é a nossa definição concluída:

{
  "properties": {
    "displayName": "Deny storage accounts not using only HTTPS",
    "description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
    "mode": "all",
    "parameters": {
      "effectType": {
        "type": "string",
        "defaultValue": "Deny",
        "allowedValues": [
          "Deny",
          "Disabled"
        ],
        "metadata": {
          "displayName": "Effect",
          "description": "Enable or disable the execution of the policy"
        }
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
          },
          {
            "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
            "notEquals": "true"
          }
        ]
      },
      "then": {
        "effect": "[parameters('effectType')]"
      }
    }
  }
}

A definição concluída pode ser usada para criar uma política. O portal e cada SDK (CLI do Azure, Azure PowerShell e API REST) aceitam a definição de diferentes maneiras. Portanto, examine os comandos de cada um para validar o uso correto. Em seguida, atribua-o, usando o efeito parametrizado, aos recursos adequados para gerenciar a segurança de suas contas de armazenamento.

Limpar os recursos

Quando terminar de trabalhar com os recursos deste tutorial, siga as seguintes etapas para excluir qualquer uma das atribuições ou definições criadas:

  1. Selecione Definições (ou Atribuições se você estiver tentando excluir uma atribuição) em Criação no lado esquerdo da página Azure Policy.

  2. Pesquisar pela nova iniciativa ou definição de política (ou atribuição) que você quer remover.

  3. Clique com o botão direito na linha e selecione as reticências no final da definição ou da atribuição e selecione Excluir Definição (ou Excluir Atribuição).

Revisão

Neste tutorial, você realizou as seguintes tarefas com sucesso:

  • Identificou seus requisitos de negócios
  • Mapeou cada requisito para uma propriedade de recurso do Azure
  • Mapeou a propriedade para um alias
  • Determinou o efeito a ser usado
  • Redigiu a definição de política

Próximas etapas

Em seguida, use sua definição de política personalizada para criar e atribuir uma política:

Criar e atribuir uma definição de política