Sécuriser vos paramètres
Parfois, vous devez transmettre des valeurs sensibles dans vos déploiements, comme des mots de passe et des clés API. Toutefois, vous devez vous assurer que ces valeurs sont protégées. Dans certains cas, vous ne souhaitez pas que la personne qui crée le déploiement connaissent les valeurs secrètes. Dans d’autres cas, une personne entre la valeur du paramètre lors de la création du déploiement, mais vous devez vous assurer que les valeurs secrètes ne sont pas journalisées. Dans cette leçon, vous allez découvrir des méthodes pour protéger vos paramètres.
Conseil
La meilleure approche consiste à éviter entièrement d’utiliser les informations de connexion. Les identités managées pour les ressources Azure peuvent permettre aux composants de votre solution de communiquer en toute sécurité entre eux sans informations d’identification. Les identités managées ne sont pas disponibles pour toutes les ressources, mais il est judicieux de les utiliser quand vous le pouvez. Quand c’est impossible, vous pouvez utiliser les approches décrites ici.
Notes
Les commandes de cette unité sont présentées pour illustrer les concepts. N’exécutez pas encore les commandes. Vous allez bientôt mettre en pratique ce que vous apprenez ici.
Définir des paramètres sécurisés
L’élément décoratif @secure peut être appliqué à des paramètres de chaîne et d’objet pouvant contenir des valeurs secrètes. Quand vous définissez un paramètre en tant que @secure, Azure ne rend pas les valeurs de paramètres disponibles dans les journaux de déploiement. En outre, si vous créez le déploiement de manière interactive à l’aide d’Azure CLI ou d’Azure PowerShell et que vous devez entrer les valeurs pendant le déploiement, le terminal n’affiche pas le texte sur votre écran.
Dans le cadre de la migration de l’application RH, vous devez déployer un serveur logique et une base de données Azure SQL. Vous allez provisionner le serveur logique avec des informations de connexion et un mot de passe d’administrateur. Étant donné qu’elles sont sensibles, vous devez sécuriser ces valeurs. Voici un exemple de déclaration pour créer deux paramètres de chaîne pour les détails de l’administrateur du SQL Server :
@secure()
param sqlServerAdministratorLogin string
@secure()
param sqlServerAdministratorPassword string
Notez qu’aucun de ces paramètres n’a de valeur par défaut spécifiée. Il est recommandé d’éviter de spécifier des valeurs par défaut pour les noms d’utilisateur, les mots de passe et autres secrets. Dans le cas contraire, si une personne déploie votre modèle et ne se rend pas compte qu’elle doit remplacer la valeur, elle affaiblira sa sécurité, car elle obtiendra la valeur par défaut au lieu d’une valeur qu’elle a choisie.
Conseil
Veillez à ne pas créer de sorties pour les données sensibles. Les valeurs de sortie sont accessibles à toute personne ayant accès à l’historique de déploiement. Elles ne sont pas appropriées pour gérer les secrets.
Évitez d’utiliser des fichiers de paramètres pour les secrets
Comme vous l’avez découvert dans la leçon précédente, les fichiers de paramètres sont un excellent moyen de spécifier un ensemble de valeurs de paramètres. Vous allez souvent créer des fichiers de paramètres pour chaque environnement sur lequel vous effectuez le déploiement. En général, vous devez éviter d’utiliser des fichiers de paramètres pour spécifier des valeurs secrètes. Les fichiers de paramètres sont souvent enregistrés dans un système de gestion de version centralisé, comme Git. De nombreuses personnes pourront y avoir accès à l’avenir. N’enregistrez pas de données sensibles dans des systèmes de gestion de version, car ils ne sont pas conçus pour stocker ce type d’informations.
Intégrer avec Azure Key Vault
Azure Key Vault est un service conçu pour stocker et fournir l’accès aux secrets. Vous pouvez intégrer vos modèles Bicep au coffre Key Vault à l’aide d’un fichier de paramètres qui fait référence à une clé secrète Key Vault.
Vous pouvez utiliser cette fonctionnalité en faisant référence au coffre de clés et au secret dans votre fichier de paramètres. La valeur n’est jamais exposée, car vous faites uniquement référence à son identificateur, qui n’est pas confidentiel en lui-même. Quand vous déployez le modèle, Azure Resource Manager contacte le coffre de clés et récupère les données.
Conseil
Vous pouvez faire référence à des secrets dans des coffres de clés qui se trouvent dans un autre groupe de ressources ou un autre abonnement que celui sur lequel vous effectuez le déploiement.
Voici un fichier de paramètres qui utilise des références à Key Vault pour rechercher les informations de connexion et le mot de passe de l’administrateur du serveur logique SQL à utiliser :
{
"$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"
}
}
}
}
Notez qu’au lieu de spécifier value pour chacun des paramètres, ce fichier contient un objet reference qui contient les détails du coffre de clés et du secret.
Important
Votre coffre de clés doit être configuré pour autoriser Resource Manager à accéder aux données du coffre de clés lors des déploiements de modèles. En outre, l’utilisateur qui déploie le modèle doit avoir l’autorisation d’accéder au coffre de clés. Vous allez découvrir comment effectuer ces tâches dans la leçon suivante.
Utiliser Key Vault avec des modules
Les modules vous permettent de créer des fichiers Bicep réutilisables qui encapsulent un ensemble de ressources. Il est courant d’utiliser des modules pour déployer certaines parties de votre solution. Les modules peuvent disposer de paramètres qui acceptent les valeurs secrètes. Vous pouvez utiliser l’intégration de Key Vault dans Bicep pour fournir ces valeurs en toute sécurité. Voici un exemple de fichier Bicep qui déploie un module et fournit la valeur du paramètre secret ApiKey en le prenant directement dans le coffre 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')
}
}
Notez que dans ce fichier Bicep, la ressource Key Vault est référencée avec le mot clé existing. Le mot clé indique à Bicep que le coffre de clés existe déjà, et ce code est une référence à ce coffre. Bicep ne le redéploie pas. Notez également que le code du module utilise la fonction getSecret() dans la valeur du paramètre apiKey du module. Il s’agit d’une fonction Bicep spéciale qui ne peut être utilisée qu’avec des paramètres de module sécurisés. En interne, Bicep traduit cette expression dans le même type de référence de Key Vault que vous avons vu précédemment.