02 · Sécuriser les secrets et les clés avec Azure Key Vault

Version : 1.2 · Date : 2026-10-21 · Domaine 1 de l'examen : Manage identity, access, and governance (20 à 25 %)

En une phrase : Azure Key Vault garde les clés, les secrets et les certificats hors du code ; on le protège couche par couche (réseau privé, identité Entra, rôle de données minimal, protection contre la suppression, journaux et Defender), et l'on fait tourner ce qu'il contient avant que cela n'expire ou ne fuie.

Ce que l'examen demande#

Repris mot pour mot du guide d'étude SC-500 (section Secure secrets and keys by using Azure Key Vault) :

Les sections 9 (journaux, Azure Policy) et 10 (Managed HSM) sont des compléments de l'ancienne AZ-500, utiles en entreprise et souvent cachés dans une question.

1. Les bases à maîtriser#

1.1 Ce que range un Key Vault#

Key Vault est un service PaaS qui stocke et contrôle l'accès à trois types d'objets :

Chaque objet est versionné : une modification crée une nouvelle version, l'ancienne reste lisible par son URI avec version.

1.2 Deux types de ressources, deux niveaux#

Piège : le niveau Standard ne fait pas de clés protégées par HSM. Une question qui exige des clés « dans un HSM » pour une CMK appelle Premium (minimum recommandé pour les CMK) ou Managed HSM (souveraineté des clés, monolocataire).

1.3 Plan de contrôle et plan de données#

Les deux plans authentifient par Microsoft Entra ID ; les contrôles d'accès sont indépendants. Exemple : le rôle Key Vault Contributor gère le Key Vault mais ne donne aucun accès aux secrets.

1.4 Choisir la bonne solution de gestion des clés#

flowchart TD
    A[Besoin de stocker une clé, un secret ou un certificat] --> B{Traitement des codes PIN de paiement ?<br/>PCI PIN, cartes}
    B -- Oui --> P[Azure Payment HSM]
    B -- Non --> C{"Application IaaS existante en PKCS 11,<br/>JCA, CNG, AD CS ou TDE Oracle sur VM ?"}
    C -- Oui --> H[Azure Cloud HSM]
    C -- Non --> D{Souveraineté des clés, monolocataire,<br/>contrôle de la racine de confiance ?}
    D -- Oui --> M[Key Vault Managed HSM<br/>clés uniquement]
    D -- Non --> E{Clés protégées par HSM<br/>par exemple pour une CMK ?}
    E -- Oui --> K2[Key Vault Premium]
    E -- Non --> K1[Key Vault Standard]

2. Déployer Key Vault#

2.1 Les règles de conception#

• Un Key Vault par application, par région et par environnement (dev, préproduction, production) : le Key Vault est une limite de sécurité ; tout mettre dans un seul Key Vault augmente le rayon d'impact d'une compromission.
• Solution SaaS multilocataire : un Key Vault par client.
• Key Vault n'est pas un magasin de configuration (prendre App Configuration) ni de données client (Azure Storage, Cosmos DB).
• Ne pas stocker un certificat en tant que secret : utiliser l'objet Certificate et son renouvellement automatique.
• Nom : 3 à 24 caractères (lettres, chiffres, tirets), unique au monde ; un nom supprimé de façon réversible reste réservé pendant toute la période de rétention.

2.2 Le changement de 2026 : Azure RBAC par défaut#

2.3 Mise en œuvre#

Azure CLI :

az keyvault create \
  --name kv-app-prd-frc --resource-group rg-app-prd --location francecentral \
  --sku premium \
  --enable-rbac-authorization true \
  --enable-purge-protection true \
  --retention-days 90 \
  --public-network-access Disabled

Azure PowerShell :

New-AzKeyVault -Name "kv-app-prd-frc" -ResourceGroupName "rg-app-prd" -Location "francecentral" `
  -Sku Premium -EnablePurgeProtection -SoftDeleteRetentionInDays 90

Bicep :

resource coffre 'Microsoft.KeyVault/vaults@2026-02-01' = {
  name: 'kv-app-prd-frc'
  location: 'francecentral'
  properties: {
    tenantId: subscription().tenantId
    sku: { family: 'A', name: 'premium' }
    enableRbacAuthorization: true      // RBAC Azure (défaut à partir de 2026-02-01, écrit pour être explicite)
    enablePurgeProtection: true        // irréversible : obligatoire pour les CMK
    softDeleteRetentionInDays: 90      // fixé à la création, non modifiable ensuite
    publicNetworkAccess: 'Disabled'    // accès par private endpoint uniquement
    networkAcls: { bypass: 'AzureServices', defaultAction: 'Deny' }
  }
}

Terraform (fournisseur azurerm 5.x, arguments vérifiés dans le registre) :

resource "azurerm_key_vault" "app" {
  name                          = "kv-app-prd-frc"
  location                      = "francecentral"
  resource_group_name           = "rg-app-prd"
  tenant_id                     = data.azurerm_client_config.current.tenant_id
  sku_name                      = "premium"
  rbac_authorization_enabled    = true  # obligatoire en 5.x (s'appelait enable_rbac_authorization en 4.x)
  purge_protection_enabled      = true
  soft_delete_retention_days    = 90
  public_network_access_enabled = false

  network_acls {
    bypass         = "AzureServices"
    default_action = "Deny"
  }
}

3. Configurer les paramètres de Key Vault#

3.1 Soft delete et purge protection#

stateDiagram-v2
    state "Actif" as A
    state "Soft-deleted, 7 à 90 jours" as S
    state "Supprimé définitivement" as P
    A --> S : supprimer
    S --> A : récupérer
    S --> P : purger, interdit si purge protection
    S --> P : fin de la période de rétention

Pièges :

• La plupart des services qui utilisent une customer-managed key (Azure Storage, Azure Backup, Azure AI services…) exigent le soft delete et la purge protection.
• Quand un Key Vault est supprimé de façon réversible, ses role assignments Azure RBAC et ses Event Grid subscriptions sont supprimés ; la récupération du Key Vault ne les restaure pas.
• Sans soft delete (anciens Key Vaults), supprimer une clé la supprime définitivement : imposer le paramètre par Azure Policy.

az keyvault list-deleted                                  # Key Vaults en soft delete
az keyvault recover --name kv-app-prd-frc                 # récupérer un Key Vault
az keyvault secret list-deleted --vault-name kv-app-prd-frc
az keyvault secret recover --vault-name kv-app-prd-frc --name sql-password

3.2 Les autres paramètres du Key Vault#

4. Configurer l'accès à Key Vault#

4.1 S'authentifier auprès de Key Vault#

sequenceDiagram
    participant App as Application (managed identity)
    participant E as Microsoft Entra ID
    participant KV as Key Vault (plan de données)
    App->>E: Demande un jeton pour https://vault.azure.net
    E-->>App: Jeton d'accès (aucun secret côté application)
    App->>KV: GET /secrets/sql-password + jeton (HTTPS, TLS 1.2 ou 1.3)
    KV->>KV: Key Vault firewall, puis rôle Azure RBAC du principal
    KV-->>App: Valeur de la dernière version du secret

4.2 Azure RBAC ou access policies#

Changer de modèle exige Microsoft.Authorization/roleAssignments/write sans condition (Owner ou User Access Administrator) ; le Key Vault Data Access Administrator ne peut pas. Passer en RBAC invalide toutes les access policies : attribuer d'abord les rôles équivalents (sinon panne). Guide de migration : Migrate from vault access policy to an Azure role-based access control permission model.

4.3 Les built-in roles du plan de données#

Bonnes pratiques :

• Attribuer les rôles à l'étendue du Key Vault (un Key Vault par application) ; les attributions sur un secret individuel sont réservées à des cas précis (clé SSH personnelle lue via Azure Bastion, secret partagé entre deux applications).
• Une attribution au niveau d'un objet ne donne que la lecture ; réseau, supervision et gestion des objets demandent des droits sur le Key Vault. Les attributions par objet ne suffisent pas à isoler des équipes : un Key Vault par application.
• Rendre les rôles d'administration éligibles dans PIM, avec MFA et approbation ; Conditional Access s'applique aussi.
• Dans les scripts, utiliser l'ID du rôle plutôt que son nom (exemple : Key Vault Secrets User = 4633458b-17de-408a-b874-0445c86b69e6).
• ABAC (préversion) : des conditions limitent un rôle, par exemple aux secrets dont le nom suit un modèle ; uniquement pour les actions sur les secrets pour l'instant.

# Donner la lecture des secrets à une managed identity, à l'étendue du Key Vault
az role assignment create --role "Key Vault Secrets User" \
  --assignee-object-id <principalId> --assignee-principal-type ServicePrincipal \
  --scope /subscriptions/<sub>/resourceGroups/rg-app-prd/providers/Microsoft.KeyVault/vaults/kv-app-prd-frc

# Vérifier le permission model de tous les Key Vaults d'un abonnement (lecture seule)
az keyvault list --query "[].{nom:name, rbac:properties.enableRbacAuthorization}" --output table

Custom role (actions de données, donc DataActions) :

{
  "Name": "Backup Keys Operator",
  "Description": "Sauvegarder et restaurer les clés",
  "Actions": [],
  "DataActions": [
    "Microsoft.KeyVault/vaults/keys/read",
    "Microsoft.KeyVault/vaults/keys/backup/action",
    "Microsoft.KeyVault/vaults/keys/restore/action"
  ],
  "NotDataActions": [],
  "AssignableScopes": ["/subscriptions/{subscriptionId}"]
}

5. Configurer le pare-feu et le réseau#

5.1 Les options, de la plus restrictive à la plus ouverte#

Limites et règles :

• 200 virtual network rules et 1 000 règles IPv4 au maximum ; IPv4 uniquement.
• Les règles IP n'acceptent que des IP publiques (pas de 10.x, 172.16-31.x, 192.168.x) : depuis un réseau privé, utiliser un service endpoint ou un private endpoint.
• L'activation d'un service endpoint sur un sous-réseau peut prendre jusqu'à 15 minutes.
• Le pare-feu filtre aussi le portail : un administrateur hors des réseaux autorisés voit le Key Vault mais ne peut pas lister les secrets.
• Le pare-feu ne filtre que le plan de données : créer un Key Vault, changer le réseau, ou déployer un secret par un modèle ARM (qui passe par management.azure.com) n'est pas bloqué.

5.2 Les trusted Microsoft services#

L'exception Allow trusted Microsoft services to bypass this firewall (--bypass AzureServices) laisse passer une liste fermée de services dont tout le code est contrôlé par Microsoft. Exemples : Azure Storage, Azure SQL Database (TDE avec CMK), Azure Backup, Azure Disk Encryption, Azure Disk Storage (Disk Encryption Set), Application Gateway, API Management, Front Door, Azure Firewall Premium, Azure Policy, ARM template deployment, Event Hubs, Service Bus, Azure Container Registry, Azure Monitor (cluster Log Analytics avec CMK).

Pièges : Azure DevOps n'est pas un trusted service (on peut y exécuter du code personnalisé) : il lui faut une règle IP, une règle VNet ou un private endpoint. App Service n'est approuvé que pour le déploiement de certificats ; pour les Key Vault references, il faut la VNet integration. Un trusted service doit toujours présenter un jeton Entra et avoir un rôle sur le Key Vault. L'exception continue de s'appliquer quand l'accès public est désactivé, mais pas avec un Network Security Perimeter en mode Enforced.

5.3 Le private endpoint et le DNS#

1. Créer le private endpoint (Target sub-resource vault) dans un sous-réseau du VNet.
2. Intégrer la Private DNS zone privatelink.vaultcore.azure.net, liée au VNet, avec un enregistrement A au nom simple du Key Vault (exemple kv-app-prd-frc) qui pointe vers l'IP privée.
3. Depuis le VNet, nslookup kv-app-prd-frc.vault.azure.net doit renvoyer l'IP privée (alias kv-app-prd-frc.privatelink.vaultcore.azure.net).
4. Désactiver l'accès public une fois la connexion validée.
5. Depuis un réseau local : redirecteurs conditionnels pour vault.azure.net et vaultcore.azure.net vers un Azure DNS Private Resolver.

États d'une private endpoint connection : Pending (demande manuelle), Approved, Rejected, Disconnected.

Même accès public désactivé, le nom du Key Vault reste résolu publiquement (CNAME vers privatelink.vaultcore.azure.net) : c'est voulu et cela ne révèle ni l'IP privée ni les données. Ne pas mettre d'informations sensibles dans le nom du Key Vault.

# Pare-feu : refuser par défaut, autoriser un sous-réseau et une IP publique, garder les trusted services
az network vnet subnet update -g rg-app-prd --vnet-name vnet-app --name snet-app --service-endpoints "Microsoft.KeyVault"
az keyvault network-rule add -g rg-app-prd --name kv-app-prd-frc --subnet <id-sous-réseau>
az keyvault network-rule add -g rg-app-prd --name kv-app-prd-frc --ip-address "191.10.18.0/24"
az keyvault update -g rg-app-prd --name kv-app-prd-frc --default-action Deny --bypass AzureServices

# Private endpoint, puis fermeture de l'accès public
az network private-endpoint create -g rg-app-prd --vnet-name vnet-app --subnet snet-pe --name pe-kv-app \
  --private-connection-resource-id <id-du-coffre> --group-ids vault --connection-name kv-app
az keyvault update -g rg-app-prd --name kv-app-prd-frc --public-network-access Disabled

6. Gérer les clés, les secrets et les certificats#

6.1 Les clés#

• Une HSM-protected key n'est pas exportable.
• Bonne pratique Microsoft : faire tourner une clé de chiffrement au moins tous les deux ans.
• Les débits sont limités par Key Vault et par région sur 10 secondes (exemple : 4 000 GET de clé logicielle RSA 2048 ; 2 000 pour une clé HSM RSA 2048 ; 250 pour une HSM RSA 4096) ; au-delà, le service répond HTTP 429 (throttling). La limite d'abonnement vaut cinq fois celle du Key Vault.

az keyvault key create --vault-name kv-app-prd-frc --name cmk-stockage --kty RSA-HSM --size 3072

6.2 Les secrets#

• Valeur de 25 Ko maximum, chiffrée au repos par une hiérarchie de clés protégée par des modules validés FIPS.
• contentType (255 caractères) pour indiquer la nature du secret (mot de passe, chaîne de connexion…) ; jusqu'à 15 tags.
• Attributs exp (expiration), nbf (pas avant), enabled. exp et nbf sont informatifs : un get fonctionne même sur un secret expiré (utile en récupération) ; c'est Azure Policy ou le code qui doivent faire respecter l'expiration.
• Ne jamais passer la valeur en clair dans la ligne de commande ou le code : la lire d'un fichier ou d'une variable protégée.

az keyvault secret set --vault-name kv-app-prd-frc --name sql-password \
  --file ./sql-password.txt --content-type "mot de passe" --expires 2027-04-30T00:00:00Z

6.3 Les certificats#

• À la création d'un certificat, Key Vault crée une clé adressable et un secret du même nom : la clé sert aux opérations (signer…), le secret permet de récupérer le certificat (PFX ou PEM) avec la clé privée si la stratégie la dit exportable.
• La certificate policy décrit : sujet et SAN, type et taille de clé, exportable ou non, réutilisation de la clé au renouvellement, lifetime actions (déclencheur en jours avant expiration ou en pourcentage de durée de vie ; action emailContacts ou autoRenew), émetteur.
• Émetteurs partenaires avec renouvellement automatique : DigiCert et GlobalSign. Une autre autorité est possible, mais sans renouvellement automatique. Autosigné : régénéré automatiquement.
• Les Certificate contacts sont communs à tout le Key Vault.

az keyvault certificate create --vault-name kv-app-prd-frc --name cert-site \
  --policy "$(az keyvault certificate get-default-policy)"

6.4 La rotation automatique#

Exemple de rotation policy (rotation à 18 mois, expiration à 2 ans, notification 30 jours avant) :

{
  "lifetimeActions": [
    { "trigger": { "timeAfterCreate": "P18M" }, "action": { "type": "Rotate" } },
    { "trigger": { "timeBeforeExpiry": "P30D" }, "action": { "type": "Notify" } }
  ],
  "attributes": { "expiryTime": "P2Y" }
}

az keyvault key rotation-policy update --vault-name kv-app-prd-frc --name cmk-stockage --value ./policy.json
az keyvault key rotate --vault-name kv-app-prd-frc --name cmk-stockage     # rotation à la demande

La rotation d'une CMK réenveloppe les clés de chiffrement des données (DEK) avec la nouvelle version : les données ne sont pas rechiffrées. Garder l'ancienne version activée jusqu'à la fin du réenveloppement ; selon le service, la nouvelle version est prise en compte en 1 à 24 heures ou plus.

Événements Event Grid publiés par un Key Vault (il faut s'abonner sur le Key Vault) :

6.5 Les customer-managed keys (CMK) et le BYOK#

Principe de l'envelope encryption (chiffrement d'enveloppe) : le service (Azure Storage, Azure SQL, disques managés…) chiffre les données avec une DEK (data encryption key) ; la KEK (key encryption key) gardée dans Key Vault enveloppe la DEK. Le service passe par sa managed identity (rôle Key Vault Crypto Service Encryption User, ou en access policy : get, wrapKey, unwrapKey).

Exigences pour une CMK d'Azure Storage : soft delete et purge protection ; clé RSA ou RSA-HSM de 2048, 3072 ou 4096 bits ; à la création du compte, il faut une managed identity user-assigned. Azure SQL TDE n'accepte que 2048 ou 3072 bits.

BYOK (Bring Your Own Key) : importer dans Key Vault une clé générée dans un HSM local, sans qu'elle existe jamais en clair hors d'un HSM.

sequenceDiagram
    actor A as Administrateur
    participant KV as Key Vault Premium ou Managed HSM
    participant H as HSM local (outil BYOK du fabricant)
    A->>KV: 1. Crée la KEK (RSA-HSM, opération import uniquement)
    KV-->>A: 2. Clé publique de la KEK (fichier .pem)
    A->>H: 3. Enveloppe la clé cible avec la KEK publique
    H-->>A: Fichier de transfert .byok
    A->>KV: 4. az keyvault key import --byok-file
    Note over KV: La clé cible n'a jamais existé en clair hors d'un HSM

6.6 Consommer les secrets sans les copier#

Key Vault references dans App Service, Azure Functions et Logic Apps (Standard) :

@Microsoft.KeyVault(SecretUri=https://kv-app-prd-frc.vault.azure.net/secrets/sql-password)
@Microsoft.KeyVault(VaultName=kv-app-prd-frc;SecretName=sql-password)

• L'application utilise par défaut son identité system-assigned ; pour une identité user-assigned, renseigner keyVaultReferenceIdentity.
• Rôle Key Vault Secrets User (ou Get sur les secrets en access policy).
• Sans version dans la référence : la dernière version est prise dans les 24 heures (cache) ; une modification de la configuration ou l'API config/configreferences/appsettings/refresh force la relecture.
• Key Vault fermé au réseau : l'application doit sortir par la VNet integration (sur Linux, vnetRouteAllEnabled sauf plan Flex Consumption) ; ne pas compter sur ses IP sortantes publiques.
• Si la référence ne se résout pas, la chaîne @Microsoft.KeyVault(...) elle-même est passée à l'application.

AKS : le fournisseur Azure Key Vault du Secrets Store CSI Driver monte les secrets dans le pod (SecretProviderClass), avec une workload identity ou une managed identity (détails au chapitre 09).

6.7 Sauvegarder et restaurer#

• Sauvegarde objet par objet (pas de sauvegarde d'un Key Vault entier) ; le fichier est chiffré et ne se restaure que dans un Key Vault du même abonnement et de la même geography Azure.
• Au plus 500 versions par objet sauvegardé.
• Microsoft conseille de ne sauvegarder que sur besoin réel (déplacement, exigence réglementaire, région sans réplication) : redondance automatique et soft delete suffisent le plus souvent.
• Une copie restaurée est indépendante : désactiver ou purger l'original n'a aucun effet sur elle. Surveiller KeyBackup, KeyRestore, SecretBackup, SecretRestore, CertificateBackup dans les journaux.

Réponse à la compromission d'une clé (piège : ne pas désactiver tout de suite) :

flowchart LR
    A[Clé suspectée compromise] --> B[Contenir : retirer les droits<br/>backup et restore, lire les journaux]
    B --> C[Créer une NOUVELLE clé<br/>dans un Key Vault distinct]
    C --> D[Reconfigurer les services<br/>dépendants vers la nouvelle clé]
    D --> E[Vérifier que tout fonctionne]
    E --> F[Seulement alors désactiver<br/>l'ancienne clé]

Désactiver trop tôt met hors service tout ce qui en dépend (bases TDE inaccessibles, storage accounts en erreur, VM ADE qui ne démarrent plus), sans gêner un attaquant qui aurait restauré une copie ailleurs.

7. Rechercher les secrets exposés avec Defender CSPM#

Les attaquants cherchent des secrets en clair (fichiers, disques de VM, conteneurs, déploiements) pour se déplacer latéralement. Defender for Cloud les trouve sans agent :

Prérequis pour les machines : l'agentless scanning for machines activé. Rôles pour consulter : Security Reader, Security Admin, Reader, Contributor ou Owner.

Où voir les résultats :

• Recommendations (security control Remediate vulnerabilities) : Machines should have secrets findings resolved, Azure Resource Manager deployments should have secrets findings resolved (et équivalents AWS, GCP) ;
• Inventory ;
• Cloud security explorer (requêtes sur le cloud security graph, templates intégrés) ;
• Attack paths (un secret exposé qui mène à une ressource critique).

Secrets détectés (extrait) : clés privées SSH, chaînes de connexion Azure SQL, PostgreSQL, MySQL, Cosmos DB, chaînes de connexion et SAS tokens de stockage, clés d'accès AWS, client secrets Entra ID, personal access tokens Azure DevOps et GitHub, clés d'API OpenAI. Le moteur vérifie si une clé SSH permet réellement un mouvement latéral ; sinon elle est classée unverified. Remédiation : supprimer le secret, appliquer le moindre privilège, le déplacer dans Key Vault, préférer des secrets courts (SAS token plutôt que chaîne de connexion).

8. Implémenter Defender for Key Vault#

8.1 Activer le plan#

Prérequis : Defender for Cloud sur l'abonnement. Portail : Defender for Cloud > Environment settings > abonnement > Defender plans > Key Vault = On. Le plan s'appelle KeyVaults dans l'API.

az security pricing create --name KeyVaults --tier standard

Le workbook Coverage de Defender for Cloud montre quels plans sont actifs sur quels abonnements.

8.2 Les alertes#

Defender for Key Vault analyse les accès et lève des alertes (page Security du Key Vault, page Security alerts de Defender for Cloud, e-mail facultatif) :

Tester : accéder au Key Vault depuis le navigateur TOR déclenche une alerte après un certain délai.

8.3 Répondre à une alerte#

1. Identifier la source : le trafic vient-il du locataire ? Une alerte peut porter une IP Microsoft (les VM Azure ont des IP Microsoft) : enquêter quand même. Ne pas ignorer une alerte parce que l'on connaît l'utilisateur : le but est de détecter le vol d'identifiants.
2. Répondre : IP inconnue → activer le Key Vault firewall ; application ou utilisateur suspect → retirer ou réduire son accès ; rôle Entra en cause → voir avec l'administrateur.
3. Mesurer l'impact : liste des secrets consultés et horodatage dans l'alerte, diagnostic logs.
4. Agir : faire tourner immédiatement les secrets, clés et certificats consultés, les désactiver ou les supprimer, auditer les applications qui les utilisaient.

Une suppression rule peut réduire le bruit d'une alerte connue et légitime.

9. Journalisation et gouvernance#

9.1 Les journaux (Complément AZ-500)#

• Diagnostic setting sur le Key Vault, catégorie AuditEvent (groupes audit et allLogs), vers Log Analytics, un storage account (conteneur insights-logs-auditevent) ou Event Hubs. Journaux disponibles en 10 minutes au plus.
• Dans Log Analytics : table AzureDiagnostics (mode historique) ou tables spécifiques AZKVAuditLogs et AZKVPolicyEvaluationDetailsLogs.
• Noms d'opérations au format ObjetVerbe : VaultPut, SecretGet, SecretList, KeySign, KeyRotateIfDue, CertificateRenew, SecretNearExpiryEventGridNotification…
• L'Activity log d'Azure, lui, ne voit que le plan de contrôle.

az monitor diagnostic-settings create --name diag-kv --resource <id-du-coffre> \
  --logs '[{"category": "AuditEvent","enabled": true}]' --workspace <id-espace-log-analytics>

// Qui lit ou liste les secrets, et avec quel résultat ?
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| where OperationName in ("SecretGet", "SecretList")
| summarize nb = count() by CallerIPAddress, OperationName, ResultSignature

La même question sur la table spécifique AZKVAuditLogs (colonnes documentées OperationName, CallerIpAddress, Identity, HttpStatusCode, IsRbacAuthorized) :

AZKVAuditLogs
| where OperationName in ("SecretGet", "SecretList")
| summarize nb = count() by CallerIpAddress, OperationName, HttpStatusCode, IsRbacAuthorized

9.2 Azure Policy pour Key Vault#

Les stratégies qui portent sur les objets (secrets, clés) s'évaluent dans le plan de données : Azure Policy scan fait partie des trusted services. L'évaluation d'une nouvelle policy assignment peut prendre jusqu'à 24 heures. Détails sur Azure Policy au chapitre 03.

10. Le Managed HSM (Complément AZ-500)#

• Monolocataire, haute disponibilité, HSM validés FIPS 140-3 niveau 3, clés uniquement (pas de secrets ni de certificats), mêmes API que Key Vault pour les clés.
• Managed HSM local RBAC : les administrateurs du HSM gardent la main que même les Owners de l'abonnement ou du management group ne peuvent pas contourner. Rôles : Managed HSM Administrator, Managed HSM Crypto Officer, Managed HSM Crypto User (crée des clés mais ne peut pas en supprimer), Managed HSM Crypto Service Encryption User (identité d'un service avec CMK).
• Activation par le téléchargement du security domain : au moins 3 et au plus 10 clés publiques RSA, et un quorum (nombre minimal de clés privées pour le déchiffrer, algorithme de partage de secret de Shamir). Sans activation, aucune opération de données n'est possible. Microsoft ne peut pas récupérer le security domain : le perdre peut faire perdre l'accès aux clés.
• Limites : 5 HSM par région et par abonnement, 5 000 clés par HSM, 100 versions par clé.
• Secure Key Release : libérer une clé exportable uniquement vers une charge de travail attestée (informatique confidentielle, lancement approuvé).
• External Key Management : la KEK reste dans un HSM du client hors de Microsoft (dernier recours réglementaire ; le SLA du Managed HSM ne couvre pas la disponibilité de bout en bout).

11. Labs conseillés#

À faire dans un abonnement de test (coût de quelques euros ; tout supprimer à la fin, et ne pas activer la purge protection sur un Key Vault que l'on veut supprimer tout de suite : il resterait réservé pendant la rétention).

Lab 1. Un secret lu sans secret.

1. Créer un Key Vault Standard en Azure RBAC, vous donner Key Vault Secrets Officer, créer le secret sql-password.
2. Créer une App Service (plan Basic), activer sa system-assigned managed identity.
3. Donner Key Vault Secrets User à cette identité, à l'étendue du Key Vault.
4. Ajouter le paramètre d'application DB_PASSWORD = @Microsoft.KeyVault(VaultName=<coffre>;SecretName=sql-password).
5. Résultat attendu : dans Environment variables, la source du paramètre est la Key Vault reference, marquée d'une coche verte ; retirez le rôle, redémarrez l'application et observez l'erreur de résolution.

Lab 2. Key Vault firewall, private endpoint et DNS.

1. Mettre le Key Vault firewall en Selected networks (refus par défaut), sans votre IP : la liste des secrets échoue dans le portail.
2. Ajouter votre IP publique : la liste revient.
3. Créer un VNet, une petite VM et un private endpoint (vault) avec la zone privatelink.vaultcore.azure.net.
4. Depuis la VM : nslookup <coffre>.vault.azure.net renvoie l'IP privée ; puis désactiver l'accès public.
5. Résultat attendu : la VM lit le secret, votre poste ne le peut plus.

Lab 3. Soft delete et récupération.

1. Supprimer le secret, puis az keyvault secret list-deleted : il apparaît avec sa date de purge prévue.
2. az keyvault secret recover : il revient avec toutes ses versions.
3. Supprimer un second Key Vault de test, le retrouver avec az keyvault list-deleted, le récupérer.
4. Résultat attendu : le Key Vault revient, mais ses role assignments ont disparu (à recréer).

Lab 4. Rotation d'une clé.

1. Créer une clé RSA, définir une rotation policy (JSON de la section 6.4).
2. az keyvault key rotate, puis az keyvault key list-versions : une nouvelle version existe.
3. Résultat attendu : l'URI sans version de la clé pointe vers la nouvelle version.

Lab 5. Journaux et Defender for Key Vault.

1. Diagnostic setting AuditEvent vers un Log Analytics workspace (Resource specific).
2. Activer le plan Defender for Key Vault sur l'abonnement de test.
3. Lire le secret plusieurs fois, puis lancer la requête AZKVAuditLogs de la section 9.1.
4. Facultatif (test documenté par Microsoft) : accéder au Key Vault depuis le navigateur Tor et attendre l'alerte KV_TORAccess.

12. Les pièges d'examen#

13. Scénarios d'entraînement#

1. Contoso crée des Key Vaults par Terraform avec une version récente de l'API. L'équipe s'étonne que ses blocs access_policy ne donnent aucun accès. Pourquoi ?

À partir de l'API 2026-02-01, un nouveau Key Vault est en Azure RBAC par défaut : les access policies sont ignorées. Soit attribuer des rôles RBAC (recommandé), soit mettre rbac_authorization_enabled = false (Terraform azurerm 5.x).

2. Une Function App doit lire une chaîne de connexion. Le Key Vault a l'accès public désactivé et un private endpoint. La référence Key Vault affiche la chaîne @Microsoft.KeyVault(...) au lieu de la valeur. Que vérifier ?

La managed identity de la fonction a-t-elle Key Vault Secrets User ? La fonction sort-elle par la VNet integration (Route All) vers un VNet qui résout privatelink.vaultcore.azure.net ? La syntaxe et le nom du secret sont-ils justes ? Le détecteur Key Vault Application Settings Diagnostics aide.

3. Fabrikam veut chiffrer un storage account avec sa propre clé RSA 4096, créée dans un HSM, et que personne ne puisse purger la clé. Configuration ?

Key Vault Premium (ou Managed HSM), clé RSA-HSM 4096, soft delete et purge protection activées, managed identity user-assigned (création du compte) avec Key Vault Crypto Service Encryption User, rotation policy sur la clé.

4. Un auditeur doit voir la liste des secrets et leurs dates d'expiration, sans jamais lire leur valeur. Quel rôle ?

Key Vault Reader (métadonnées uniquement) à l'étendue du Key Vault.

5. Une équipe sécurité veut savoir si des mots de passe SQL traînent dans des fichiers sur des VM Azure et AWS, et dans les paramètres de déploiements ARM. Quoi activer ?

Le plan Defender CSPM avec l'agentless scanning for machines ; consulter les recommandations secrets findings resolved, le Cloud security explorer et les Attack paths, puis déplacer les secrets dans Key Vault.

6. Une alerte KV_ListGetAnomaly concerne un service principal de production. L'équipe applicative dit « c'est nous ». Que faire ?

Ne pas ignorer : vérifier avec le propriétaire que l'activité est légitime (le but est de détecter un vol d'identifiants) ; sinon couper l'accès du principal, lister les secrets lus, les faire tourner. Si l'activité est confirmée légitime et récurrente, créer une suppression rule.

7. Après la suppression accidentelle d'un Key Vault, l'administrateur le récupère ; les applications reçoivent des erreurs 403. Pourquoi ?

Le soft delete du Key Vault a supprimé ses role assignments Azure RBAC (et Event Grid subscriptions) : la récupération ne les restaure pas. Il faut les recréer (d'où l'intérêt de l'IaC).

8. Le pipeline Azure DevOps (agents hébergés par Microsoft) doit lire un secret d'un Key Vault dont le pare-feu refuse par défaut, avec l'exception trusted Microsoft services. Il échoue. Solution ?

Azure DevOps n'est pas un trusted service. Utiliser des agents auto-hébergés dans un VNet avec private endpoint (ou service endpoint), ou autoriser des IP publiques fixes ; l'identité du pipeline (fédération, chapitre 01) a besoin de Key Vault Secrets User.

14. Pour aller plus loin (au-delà de l'examen)#

• Chiffrement côté client et TLS sans clé avec les bibliothèques Key Vault (la clé privée ne quitte jamais le HSM).
• Cryptographie post-quantique : les clés symétriques AES 256 bits (oct-HSM) sont considérées comme résistantes aux attaques quantiques.
• Multilocataire : un Key Vault par client et le guide d'architecture La multilocation et Azure Key Vault.
• Conditional Access : Key Vault le prend en charge (emplacement, appareil) pour les accès des utilisateurs.
• Key Vault VM extension (Windows, Linux) pour déployer et renouveler des certificats sur des VM.
• Microsoft Sentinel : règles d'analyse sur AZKVAuditLogs (lecture massive de secrets, changement de permission model), voir le chapitre 11.
• Épingler les clients en TLS 1.2 ou 1.3 et surveiller les versions TLS dans les journaux.

15. Fiche à retenir#

• Key Vault = clés, secrets (25 Ko), certificats ; Managed HSM = clés uniquement, monolocataire, FIPS 140-3 niveau 3.
• Standard = clés logicielles ; Premium = clés protégées par HSM (minimum recommandé pour les CMK).
• Un Key Vault par application, région et environnement ; nom 3 à 24 caractères, unique au monde.
• API 2026-02-01 : Azure RBAC par défaut sur les nouveaux Key Vaults ; anciennes API retirées le 27/02/2027.
• Plan de contrôle (ARM, Azure RBAC, pas filtré par le pare-feu) ≠ plan de données (vault.azure.net, filtré).
• Access policies : un Contributor peut s'accorder les secrets ; RBAC : seuls Owner, User Access Administrator, Key Vault Data Access Administrator.
• Rôles clés : Secrets User (lire), Crypto Service Encryption User (CMK), Crypto Officer (rotation), Reader (métadonnées), Contributor (gestion, pas de données).
• Soft delete toujours actif, 7 à 90 jours (90), fixé à la création ; purge protection désactivée par défaut, irréversible, exigée par les CMK.
• Récupérer un Key Vault ne restaure ni les rôles RBAC ni Event Grid.
• Pare-feu : 200 règles VNet, 1 000 règles IPv4, IP publiques et IPv4 uniquement ; trusted services (pas Azure DevOps) ; NSP en Enforced = plus d'exception.
• Private endpoint : sous-ressource vault, zone privatelink.vaultcore.azure.net liée au VNet ; accès public désactivé ensuite.
• Rotation : clés = rotation policy (min 7 jours, Crypto Officer, facturée) ; secrets = Event Grid + Function ; certificats = autoRenew (DigiCert, GlobalSign).
• SecretNearExpiry / CertificateNearExpiry : 30 jours avant ; références App Service : cache 24 h.
• Sauvegarde objet par objet, même abonnement et même zone géographique, 500 versions max ; copie restaurée indépendante.
• Defender CSPM : secrets en clair sur VM (aussi Defender for Servers P2), déploiements ARM, dépôts Azure DevOps.
• Defender for Key Vault (plan KeyVaults) : TOR, IP suspecte, vidage de secrets, anomalies ; répondre puis faire tourner.
• Journaux : catégorie AuditEvent ; tables AzureDiagnostics ou AZKVAuditLogs.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Guide d'étude de l'examen SC-500
• Concepts de base d'Azure Key Vault
• Sécuriser votre Azure Key Vault
• Azure RBAC pour les opérations de plan de données Key Vault
• Azure RBAC et access policies (héritées)
• Azure RBAC comme modèle de contrôle d'accès par défaut (API 2026-02-01)
• Vue d'ensemble du soft delete
• Configurer la sécurité réseau pour Azure Key Vault
• Service endpoints et trusted services
• Intégrer Key Vault à Azure Private Link
• À propos des clés
• Informations sur les secrets
• À propos des certificats
• Comprendre l'autorotation dans Azure Key Vault
• Configurer la rotation automatique des clés
• Azure Key Vault comme source Event Grid
• Spécification BYOK
• Customer-managed keys pour le chiffrement du Stockage Azure
• Key Vault references dans App Service, Functions et Logic Apps
• Sauvegarde et restauration Azure Key Vault
• Limites du service Azure Key Vault
• Journalisation Azure Key Vault
• Référence de la table AZKVAuditLogs
• Référence Azure CLI : az keyvault, az keyvault secret, az security pricing
• Définitions Azure Policy intégrées pour Key Vault
• Protection des secrets dans Defender for Cloud
• Vue d'ensemble de Microsoft Defender for Key Vault
• Alertes pour Azure Key Vault
• Qu'est-ce qu'Azure Key Vault Managed HSM ?
• Domaine de sécurité du Managed HSM
• Choisir la solution de gestion des clés Azure
• Migrer depuis Azure Dedicated HSM
• Registre Terraform : azurerm_key_vault (fournisseur 5.10.0)