Partilhar 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 usar o Azure. Frequentemente, estas regras impõem:

  • Práticas de segurança.
  • Gestão de custos.
  • Regras específicas da organização (como nomenclatura ou locais).

Seja qual for o fator de negócio que leve à criação de uma política personalizada, os passos para definir a nova política personalizada são os mesmos.

Antes de criar uma política personalizada, veja os exemplos de política para ver se já existe uma política que satisfaça as suas necessidades.

A abordagem para criar uma política personalizada segue estas etapas:

  • Identifique os seus requisitos de negócio
  • Mapeie cada requisito numa propriedade de recursos do Azure
  • Mapeie a propriedade num alias
  • Determine o efeito a utilizar
  • Componha a definição de política

Pré-requisitos

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

Identificar requisitos

Antes de criar a definição de política, é importante que compreenda a intenção da política. Para este tutorial, use um requisito de segurança empresarial comum como objetivo para ilustrar as etapas envolvidas:

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

Seus requisitos devem identificar claramente os estados de recurso "ser" e "não ser".

Embora tenhamos definido o estado esperado do recurso, não definimos o que queremos fazer com recursos não compatíveis. A Política do Azure suporta muitos efeitos. Para este tutorial, definimos o requisito de negócios como impedir a criação de recursos se eles não estiverem em conformidade com as regras de negócios. Para atingir esse objetivo, usamos o efeito negar . Também queremos a opção de suspender a política para atribuições específicas. Use o efeito desabilitado e torne o efeito um parâmetro na definição de política.

Determinar propriedades do recurso

Com base nos requisitos de negócio, o recurso do Azure a auditar com o Azure Policy é uma conta de armazenamento. No entanto, não sabemos as propriedades a serem usadas na definição da política. O Azure Policy avalia em relação à representação JSON do recurso, portanto, precisamos entender as propriedades disponíveis nesse recurso.

Há muitas maneiras de determinar as propriedades de um recurso do Azure. Analisamos cada um deles para este tutorial:

  • Extensão da Política do Azure para VS Code.
  • Modelos do Azure Resource Manager (modelos ARM).
    • Exporte o recurso existente.
    • Experiência de criação.
    • Modelos de início rápido (GitHub).
    • Documentos de referência de modelo.
  • Azure Resource Explorer.

Ver recursos na extensão do VS Code

Pode utilizar a extensão do VS Code para navegar pelos recursos do seu ambiente e ver as propriedades do Resource Manager em cada recurso.

Modelos do ARM

Há várias formas de olhar para um modelo do ARM que inclui a propriedade que quer gerir.

Recurso existente no portal

A forma mais simples de encontrar propriedades é procurar num recurso existente do mesmo tipo. Os recursos que já estão configurados com a definição que quer impor também fornecem o valor com o qual comparar. Observe a página Exportar modelo , em Configurações, no portal do Azure para esse recurso específico.

Aviso

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

Captura de ecrã da página Exportar modelo num recurso existente no portal do Azure.

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": []
  }
]

Under properties é um valor chamado supportsHttpsTrafficOnly definido como false. Esta propriedade parece ser a propriedade que estamos procurando. Além disso, o type recurso é Microsoft.Storage/storageAccounts. O tipo permite-nos limitar a política apenas a recursos deste tipo.

Criar um recurso no portal

Outra forma de utilizar o portal é a experiência de criação de recursos. Quando você cria uma conta de armazenamento através do portal, uma opção na guia Avançado é Transferência de segurança necessária. Esta propriedade tem as opções Desativado e Ativado. O ícone de informações tem mais texto que confirma que esta opção é provavelmente a propriedade que queremos. Mas o portal não nos diz o nome da propriedade nesta tela.

No separador Rever + criar, encontra uma ligação na parte inferior da página que lhe permite Transferir um modelo para automatização. Selecionar o link abre o modelo que cria o recurso que configuramos. Neste caso, vemos duas informações fundamentais:

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

Esta informação indica-nos o tipo de imóvel e também confirma supportsHttpsTrafficOnly que é o imóvel que procuramos.

Modelos de início rápido no GitHub

Os Modelos de Início Rápido do Azure no GitHub têm centenas de modelos ARM criados para diferentes recursos. Estes modelos podem ser uma ótima maneira de encontrar a propriedade de recurso de que está à procura. Algumas propriedades podem parecer o que você está procurando, mas controle outra coisa.

Documentos de referência do recurso

Para validar supportsHttpsTrafficOnly a propriedade correta, verifique a referência de modelo ARM para o recurso de conta de armazenamento no provedor de armazenamento. O objeto de propriedades tem uma lista de parâmetros válidos. Selecionar o StorageAccountPropertiesCreateParameters link do objeto mostra uma tabela de propriedades aceitáveis. supportsHttpsTrafficOnly está presente e a descrição corresponde ao que procuramos em relação aos requisitos de negócio.

Explorador de Recursos do Azure

Outra maneira de explorar seus recursos do Azure é por meio do Gerenciador de Recursos do Azure (Visualização). Esta ferramenta utiliza o contexto da sua subscrição, pelo que tem de se autenticar no site com as suas credenciais do Azure. Depois de se autenticar, pode procurar por fornecedores, subscrições, grupos de recursos e recursos.

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

Encontre o alias da propriedade

Identificamos a propriedade do recurso, mas precisamos mapear essa propriedade para um alias.

Há algumas maneiras de determinar os aliases para um recurso do Azure. Analisamos cada um deles para este tutorial:

  • Extensão da Política do Azure 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 nos seus recursos e a deteção de aliases.

Nota

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

CLI do Azure

Na CLI do Azure, o grupo de comandos az provider é utilizado para procurar aliases de recursos. Filtramos o Microsoft.Storage namespace com base nos detalhes que obtivemos sobre o recurso do Azure anteriormente.

# 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, vemos um alias suportado pelas contas de armazenamento chamadas supportsHttpsTrafficOnly. Esta existência deste alias significa que podemos escrever a política para fazer cumprir os nossos requisitos de negócio!

Azure PowerShell

No Azure PowerShell, o cmdlet Get-AzPolicyAlias é utilizado para procurar aliases de recursos. Filtre o Microsoft.Storage namespace com base nos detalhes que obtivemos sobre o recurso do Azure anteriormente.

# 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

Como a CLI do Azure, os resultados mostram um alias suportado pelas contas de armazenamento chamadas supportsHttpsTrafficOnly.

Determinar o efeito a utilizar

Decidir o que fazer com seus recursos não compatíveis é quase tão importante quanto decidir o que avaliar em primeiro lugar. Cada resposta possível a um recurso não compatível é chamada de efeito. O efeito controla se o recurso não compatível é registrado, bloqueado, tem dados anexados ou tem uma implantação associada a ele para colocar o recurso de volta em um estado compatível.

Para o nosso exemplo, é o efeito que queremos, deny pois não queremos recursos não compatíveis criados em nosso ambiente do Azure. A auditoria é uma boa primeira opção para um efeito de política para determinar qual é o efeito de uma política antes de defini-la como deny. Uma maneira de facilitar a alteração do efeito por atribuição é parametrizar o efeito. Consulte os parâmetros para obter os detalhes.

Compor a definição

Agora temos os detalhes da propriedade e o alias para o que planejamos gerenciar. Em seguida, compomos a própria regra política. Se você não estiver familiarizado com a linguagem da política, consulte a estrutura de definição da política para saber como estruturar a definição da política. Aqui está um modelo vazio de como é uma definição de política:

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

Metadados

Os primeiros três componentes são metadados da política. Esses componentes são fáceis de fornecer valores, pois sabemos para que estamos criando a regra. O modo é principalmente sobre tags e localização de recursos. Como não precisamos limitar a avaliação a recursos que suportam 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 não tenhamos usado um parâmetro para alterar a avaliação, queremos usar um parâmetro para permitir a alteração do effect para solução de problemas. Você define um effectType parâmetro e o limita a apenas deny e disabled. Estas duas opções correspondem aos nossos requisitos de negócio. O bloco de parâmetros concluídos é semelhante a 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

Compor a regra de política é a etapa final na construção de nossa definição de política personalizada. Identificamos duas afirmações para testar:

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

Como precisamos que ambas as afirmações sejam verdadeiras, use o allOf operador lógico. Passe o effectType parâmetro para o efeito em vez de fazer uma declaração estática. Nossa regra concluída se parece 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 as três partes da política definidas, aqui está a nossa definição completa:

{
  "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')]"
      }
    }
  }
}

Pode utilizar a definição concluída para criar uma nova política. O portal e cada SDK (CLI do Azure, Azure PowerShell e API REST) aceitam a definição de maneiras diferentes, portanto, revise os comandos de cada um para validar o uso correto. Em seguida, atribua-a, com o efeito parametrizado, a recursos adequados para gerir a segurança das suas contas de armazenamento.

Clean up resources (Limpar recursos)

Se tiver terminado de trabalhar com recursos deste tutorial, use as seguintes etapas para excluir qualquer uma das atribuições ou definições criadas:

  1. Selecione Definições (ou Atribuições, se estiver a tentar eliminar uma atribuição) em Criação no lado esquerdo da página Política do Azure.

  2. Procure a nova definição de iniciativa ou de política (ou atribuição) que acabou de remover.

  3. Clique com o botão direito do rato na linha ou selecione as reticências no fim da definição (ou atribuição) e selecione Eliminar definição (ou Eliminar atribuição).

Rever

Neste tutorial conseguiu realizar com êxito as seguintes tarefas:

  • Identificou os requisitos do seu negócio
  • Mapeado cada requisito para uma propriedade de recurso do Azure
  • Mapeado a propriedade para um alias
  • Determinado o efeito a utilizar
  • Compôs a definição da política

Próximos passos

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