Proteja os seus parâmetros
Às vezes, você precisa passar valores confidenciais para suas implantações, como senhas e chaves de API. Mas você precisa garantir que esses valores sejam protegidos. Em algumas situações, você não quer que a pessoa que está criando a implantação conheça os valores secretos. Outras vezes, alguém insere o valor do parâmetro quando criar a implantação, mas você precisa garantir que os valores secretos não sejam registrados. Nesta unidade, você aprenderá sobre as maneiras de proteger seus parâmetros.
Gorjeta
A melhor abordagem é evitar totalmente o uso de credenciais. As identidades gerenciadas para recursos do Azure podem permitir que os componentes de sua solução se comuniquem com segurança uns com os outros sem credenciais. As identidades gerenciadas não estão disponíveis para todos os recursos, mas é uma boa ideia usá-las sempre que puder. Onde não puder, você pode usar as abordagens descritas aqui.
Nota
Os comandos nesta unidade são mostrados para ilustrar conceitos. Não execute os comandos ainda. Você vai praticar o que você aprende aqui em breve.
Definir parâmetros seguros
O @secure decorador pode ser aplicado a parâmetros de cadeia de caracteres e objetos que podem conter valores secretos. Quando você define um parâmetro como @secure, o Azure não disponibiliza os valores de parâmetro 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 HR, você precisa implantar um servidor lógico SQL do Azure e um banco de dados. Você provisionará o servidor lógico com um login e senha de administrador. Como eles são sensíveis, você precisa que esses valores sejam protegidos. Aqui está um exemplo de declaração para criar dois parâmetros de 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ário, senhas e outros segredos. Caso contrário, se alguém implantar seu modelo e não perceber que deve substituir o valor, enfraquecerá sua segurança porque obterá o valor padrão em vez de algo que ele mesmo escolheu.
Gorjeta
Certifique-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. Geralmente, você cria arquivos de parâmetros para cada ambiente em que está implantando. Em geral, você deve evitar o uso de arquivos de parâmetros para especificar valores secretos. Os arquivos de parâmetros geralmente são salvos em um sistema centralizado de controle de versão, como o Git. Muitas pessoas poderão ter acesso a ele no futuro. Não salve dados confidenciais em sistemas de controle de versão porque eles não foram projetados para armazenar esse tipo de informação.
Integrar no Azure Key Vault
O Azure Key Vault é um serviço projetado para armazenar e fornecer acesso a segredos. Você pode integrar seus modelos Bicep com o Key Vault usando um arquivo de parâmetros com uma referência a um segredo do Key Vault.
Você pode usar este recurso referenciando o Key Vault e o secret no seu ficheiro de parâmetros. O valor nunca é exposto porque você apenas faz referência ao seu identificador, o que por si só não é nada secreto. Quando você implanta o modelo, o Azure Resource Manager entra em contato com o cofre de chaves e recupera os dados.
Gorjeta
Você pode consultar segredos em cofres de chaves localizados em um grupo de recursos ou assinatura diferente daquele em que você está implantando.
Aqui está um arquivo de parâmetros que usa referências do Cofre de Chaves para procurar o login e a senha do administrador do servidor lógico SQL a serem usados:
{
"$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 para cada um value dos parâmetros, esse arquivo tem um reference objeto, que contém detalhes do cofre de chaves e do segredo.
Importante
Seu cofre de chaves deve ser configurado para permitir que o Gerenciador de Recursos acesse os dados no cofre de chaves durante implantações de modelos. Além disso, o usuário que implanta o modelo deve ter permissão para acessar o cofre de chaves. Você aprenderá como fazer essas tarefas na próxima unidade.
Usar o Key Vault com módulos
Os módulos permitem criar arquivos 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 do Key Vault do Bícep para fornecer esses valores com segurança. Aqui está um exemplo de arquivo Bicep que implanta um módulo e fornece o valor do parâmetro secreto retirando-o ApiKey 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 neste arquivo Bicep, o recurso Key Vault é referenciado usando a existing palavra-chave. A palavra-chave informa ao Bicep que o Cofre da Chave já existe, e esse código é uma referência a esse cofre. O Bicep não irá reimplantá-lo. Além disso, observe que o código do módulo usa a getSecret() função no valor para o parâmetro do apiKey módulo. Esta é uma função especial do Bíceps que só pode ser usada com parâmetros de módulo seguros. Internamente, o Bicep traduz essa expressão para o mesmo tipo de referência do Cofre de Chaves que você aprendeu anteriormente.