Proteger seus parâmetros
Às vezes, você precisa enviar valores confidenciais para suas implantações, como senhas e chaves de API. Mas você precisa garantir que esses valores estejam protegidos. Em algumas situações, você não quer que a pessoa que está criando a implantação saiba os valores secretos. Em outras, alguém digitará o valor do parâmetro ao criar a implantação, mas você precisará garantir que os valores secretos não sejam registrados. Nesta unidade, você aprenderá sobre as maneiras de proteger seus parâmetros.
Dica
A melhor abordagem é evitar totalmente o uso das credenciais. As identidades gerenciadas para recursos do Azure podem permitir que os componentes da solução se comuniquem com segurança entre si sem credenciais. As identidades gerenciadas não estão disponíveis para todos os recursos, mas é uma boa ideia usá-las sempre que possível. Onde não for possível, você poderá usar as abordagens descritas aqui.
Observação
Os comandos nesta unidade são mostrados para ilustrar conceitos. Não execute os comandos ainda. Você praticará o que aprendeu aqui em breve.
Definir parâmetros seguros
O decorador @secure pode ser aplicado a parâmetros de cadeia de caracteres e de objeto que podem conter valores secretos. Quando você define um parâmetro como @secure, o Azure não disponibiliza os valores dos parâmetros nos logs de implantação. Além disso, se você criar a implantação interativamente usando a CLI do Azure ou o Azure PowerShell e precisar inserir os valores durante a implantação, o terminal não exibirá o texto na tela.
Como parte da migração do aplicativo de RH, você precisa implantar um banco de dados e servidor lógico do SQL do Azure. Você provisionará o servidor lógico com um logon de administrador e senha. Como eles são confidenciais, você precisa que esses valores sejam protegidos. Aqui está um exemplo de declaração para criar dois parâmetros da cadeia de caracteres para os detalhes do administrador do SQL Server:
@secure()
param sqlServerAdministratorLogin string
@secure()
param sqlServerAdministratorPassword string
Observe que nenhum parâmetro tem um valor padrão especificado. É uma boa prática evitar especificar valores padrão para nomes de usuários, senhas e outros segredos. Caso contrário, se alguém implantar seu modelo e não perceber que deve substituir o valor, ele enfraquecerá a segurança porque obterá o valor padrão em vez de algo que ele mesmo escolheu.
Dica
Lembre-se de não criar saídas para dados confidenciais. Os valores de saída podem ser acessados por qualquer pessoa que tenha acesso ao histórico de implantação. Eles não são apropriados para lidar com segredos.
Evite usar arquivos de parâmetros para segredos
Como você aprendeu na unidade anterior, os arquivos de parâmetros são uma ótima maneira de especificar um conjunto de valores de parâmetros. Você normalmente criará arquivos de parâmetros para cada ambiente no qual está implantando. Em geral, você deve evitar o uso de arquivos de parâmetros para especificar valores secretos. Os arquivos de parâmetros costumam ser salvos em um sistema de controle de versão centralizado, como o Git. Muitas pessoas podem ter acesso a eles no futuro. Não salve dados confidenciais em sistemas de controle de versão porque eles não são projetados para armazenar esse tipo de informação.
Integrar com o Azure Key Vault
O Azure Key Vault é um serviço projetado para armazenar e fornecer acesso aos segredos. Você pode integrar seus modelos do Bicep com Key Vault usando um arquivo de parâmetros com uma referência a um segredo do Key Vault.
Você pode usar esse recurso referindo-se ao cofre de chaves e ao segredo em seu arquivo de parâmetros. O valor nunca é exposto porque você só faz referência ao seu identificador, que por si só não é algo secreto. Quando você implantar o modelo, o Azure Resource Manager entrará em contato com o cofre de chaves e recuperará os dados.
Dica
Você pode consultar os segredos nos cofres de chaves que estão localizados em um grupo de recursos ou na assinatura diferente daquela na qual você está implantando.
Aqui está um arquivo de parâmetro que usa as referências de Key Vault para pesquisar o logon e a senha do administrador do servidor lógico de SQL para usar:
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"sqlServerAdministratorLogin": {
"reference": {
"keyVault": {
"id": "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/PlatformResources/providers/Microsoft.KeyVault/vaults/toysecrets"
},
"secretName": "sqlAdminLogin"
}
},
"sqlServerAdministratorPassword": {
"reference": {
"keyVault": {
"id": "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/PlatformResources/providers/Microsoft.KeyVault/vaults/toysecrets"
},
"secretName": "sqlAdminLoginPassword"
}
}
}
}
Observe que, em vez de especificar um value para cada um dos parâmetros, esse arquivo tem um objeto reference, que contém detalhes do cofre de chaves e do segredo.
Importante
O cofre de chaves deve ser configurado para permitir que o Resource Manager acesse os dados nele durante as implantações de modelo. Além disso, o usuário que implanta o modelo deve ter permissão para acessar o cofre de chaves. Você aprenderá como executar essas tarefas na próxima unidade.
Usar o Key Vault com módulos
Os módulos permitem que você crie arquivos do Bicep reutilizáveis que encapsulam um conjunto de recursos. É comum usar módulos para implantar partes da sua solução. Os módulos podem ter parâmetros que aceitam valores secretos e você pode usar a integração de Key Vault do Bicep para fornecer esses valores com segurança. Aqui está um exemplo de arquivo do Bicep que implanta um módulo e fornece o valor do parâmetro secreto ApiKey, pegando-o diretamente do Key Vault:
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
name: keyVaultName
}
module applicationModule 'application.bicep' = {
name: 'application-module'
params: {
apiKey: keyVault.getSecret('ApiKey')
}
}
Observe que, nesse arquivo do Bicep, o recurso do Key Vault é referenciado usando a palavra-chave existing. A palavra-chave informa ao Bicep que o Key Vault já existe e o código é apenas uma referência a esse cofre. O Bicep não o reimplantará. Além disso, observe que o código do módulo usa a função getSecret() no valor para o parâmetro apiKey do módulo. Essa é uma função especial do Bicep que só pode ser usada com parâmetros de módulo seguro. Internamente, o Bicep converte essa expressão para o mesmo tipo de referência de Key Vault que você aprendeu anteriormente.