Tutorial: Criar uma definição de política personalizada
Uma definição de política personalizada permite que os clientes definam as suas próprias regras para a utilização do Azure. Frequentemente, estas regras impõem:
- Práticas de segurança
- Gestão de custos
- Regras específicas da organização (como nomenclatura ou localizações)
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 estes passos:
- 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. Neste tutorial, vamos utilizar um requisito de segurança empresarial comum como objetivo para ilustrar os passos envolvidos:
- Cada conta de armazenamento tem de estar ativada para HTTPS
- Cada conta de armazenamento tem de ser desativada para HTTP
Os seus requisitos devem identificar claramente os estados de recursos "a ser" e "não ser".
Apesar de termos definido o estado esperado do recurso, ainda não definimos o que queremos que seja feito com recursos não conformes. Azure Policy suporta muitos efeitos. Neste tutorial, vamos definir o requisito de negócio como impedindo a criação de recursos se não estiverem em conformidade com as regras de negócio. Para cumprir este objetivo, vamos utilizar o efeito Negar . Também queremos a opção de suspender a política para atribuições específicas. Como tal, vamos utilizar o efeito Desativado e tornar o efeito num parâmetro na definição de política.
Determinar as 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 utilizar na definição de política. Azure Policy é avaliada em relação à representação JSON do recurso, pelo que teremos de compreender as propriedades disponíveis nesse recurso.
Existem várias formas de determinar as propriedades de um recurso do Azure. Vamos analisar cada um destes tutoriais:
- Extensão do Azure Policy para o VS Code
- Modelos de Resource Manager do Azure (modelos do ARM)
- Exportar recurso existente
- Experiência de criação
- Modelos de início rápido (GitHub)
- Documentos de referência de modelo
- Explorador de Recursos do Azure
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 de 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. Veja a página Exportar modelo (em Definições) no portal do Azure para esse recurso específico.
Aviso
O modelo arm exportado por portal do Azure não pode ser ligado diretamente à deployment propriedade de um modelo arm numa definição de política deployIfNotExists.
Ao fazê-lo para uma conta de armazenamento, é apresentado 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 propriedades está um valor com o nome supportsHttpsTrafficOnly definido como falso. Esta propriedade parece ser a propriedade que procuramos. Além disso, o tipo de 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. Ao criar uma conta de armazenamento através do portal, verá uma opção no separador Avançado, que é a opção Transferência de segurança necessária. Esta propriedade tem as opções Desativado e Ativado. O ícone de informações tem texto adicional que confirma que esta opção é provavelmente a propriedade que queremos. No entanto, o portal não nos indica o nome da propriedade neste ecrã.
No separador Rever + criar, encontra uma ligação na parte inferior da página que lhe permite Transferir um modelo para automatização. Selecionar a ligação abre o modelo que cria o recurso que configurámos. Neste caso, vemos duas informações importantes:
...
"supportsHttpsTrafficOnly": {
"type": "bool"
}
...
"properties": {
"accessTier": "[parameters('accessTier')]",
"supportsHttpsTrafficOnly": "[parameters('supportsHttpsTrafficOnly')]"
}
...
Estas informações dizem-nos o tipo de propriedade e também confirma que o suporteHttpsTrafficOnly é a propriedade 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 do 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 procura, mas controlam outra coisa.
Documentos de referência do recurso
Para validar suportesHttpsTrafficOnly está correta, verifique a referência de modelo do ARM para o recurso da conta de armazenamento no fornecedor de armazenamento. O objeto de propriedades tem uma lista de parâmetros válidos. Selecionar a ligação StorageAccountPropertiesCreateParameters-object mostra uma tabela de propriedades aceitáveis. supportsHttpsTrafficOnly está presente e a descrição corresponde ao que procuramos para cumprir os requisitos empresariais.
Explorador de Recursos do Azure
Outra forma de explorar os recursos do Azure é através do Azure Resource Explorer (Pré-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 veja as propriedades. Também vemos a propriedade supportsHttpsTrafficOnly aqui. Ao selecionar o separador Documentação , vemos que a descrição da propriedade corresponde ao que encontrámos nos documentos de referência anteriormente.
Localizar o alias da propriedade
Identificámos a propriedade do recurso, mas precisamos de mapear essa propriedade para um alias.
Existem algumas formas de determinar os aliases de um recurso do Azure. Vamos analisar cada um destes tutoriais:
- Extensão do Azure Policy para o VS Code
- CLI do Azure
- Azure PowerShell
Obter aliases na extensão do VS Code
A extensão Azure Policy para a extensão do VS Code facilita a procura dos seus recursos e a deteção de aliases.
Nota
A extensão do VS Code expõe apenas as propriedades do modo Resource Manager e não apresenta quaisquer propriedades do modo fornecedor de recursos.
CLI do Azure
Na CLI do Azure, o grupo de comandos az provider é utilizado para procurar aliases de recursos. Vamos filtrar o espaço de nomes Microsoft.Storage 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 com o nome supportsHttpsTrafficOnly. Esta existência deste alias significa que podemos escrever a política para impor os nossos requisitos empresariais!
Azure PowerShell
No Azure PowerShell, o cmdlet Get-AzPolicyAlias é utilizado para procurar aliases de recursos. Vamos filtrar o espaço de nomes Microsoft.Storage 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
Tal como a CLI do Azure, os resultados mostram um alias suportado pelas contas de armazenamento com o nome supportsHttpsTrafficOnly.
Determinar o efeito a utilizar
Decidir o que fazer com os seus recursos não conformes é quase tão importante como decidir o que avaliar em primeiro lugar. Cada resposta possível a um recurso não conforme é denominada efeito. O efeito controla se o recurso não conforme é registado, bloqueado, tem dados anexados ou tem uma implementação associada ao mesmo para colocar o recurso novamente num estado em conformidade.
Para o nosso exemplo, Negar é o efeito que queremos, uma vez que não queremos que os recursos não conformes sejam criados no nosso ambiente do Azure. A auditoria é uma boa primeira opção para um efeito de política para determinar qual é o impacto de uma política antes de defini-la como Negar. Uma forma de facilitar a alteração do efeito por atribuição é parametrizar o efeito. Veja os parâmetros abaixo para obter os detalhes sobre como.
Compor a definição
Agora, temos os detalhes da propriedade e o alias para o que planeamos gerir. Em seguida, vamos compor a própria regra de política. Se ainda não está familiarizado com a linguagem da política, veja a estrutura da definição de política para saber como estruturar a definição de política. Eis um modelo vazio do aspeto de 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. Estes componentes são fáceis de fornecer valores para, uma vez que sabemos para o que estamos a criar a regra. O modo é principalmente sobre etiquetas e localização de recursos. Uma vez que não precisamos de limitar a avaliação aos recursos que suportam etiquetas, vamos utilizar todo o valor para o modo.
"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 utilizado um parâmetro para alterar a avaliação, queremos utilizar um parâmetro para permitir a alteração do efeito para a resolução de problemas. Vamos definir um parâmetro effectType e limitá-lo apenas a Negar e Desativado. Estas duas opções correspondem aos nossos requisitos comerciais. O bloco de parâmetros concluído tem o seguinte aspeto:
"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 é o passo final na criação da nossa definição de política personalizada. Identificámos duas instruções para testar:
- O tipo de conta de armazenamento é Microsoft.Storage/storageAccounts
- A conta de armazenamento suportaHttpsTrafficOnly não é verdadeira
Uma vez que precisamos que ambas as instruções sejam verdadeiras, vamos utilizar o operador allOf logical. Vamos transmitir o parâmetro effectType para o efeito em vez de fazer uma declaração estática. A nossa regra concluída tem o seguinte aspeto:
"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, eis 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 formas diferentes, pelo que reveja os comandos de cada um para validar a utilização correta. Em seguida, atribua-a, com o efeito parametrizado, a recursos adequados para gerir a segurança das suas contas de armazenamento.
Limpar os recursos
Se tiver terminado de trabalhar com recursos deste tutorial, utilize os seguintes passos para eliminar qualquer uma das atribuições ou definições criadas acima:
Selecione Definições (ou Atribuições se estiver a tentar eliminar uma atribuição) em Criação no lado esquerdo da página Azure Policy.
Procure a nova definição de iniciativa ou de política (ou atribuição) que acabou de remover.
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).
Revisão
Neste tutorial conseguiu realizar com êxito as seguintes tarefas:
- Identificou os seus requisitos comerciais
- Mapeou cada requisito para uma propriedade de recurso do Azure
- Mapeou a propriedade para um alias
- Determinou o efeito a utilizar
- Compôs a definição de política
Passos seguintes
Em seguida, utilize a definição de política personalizada para criar e atribuir uma política: