Microsoft AZ-500: Gestion des clés, cryptographie et certificats — Guide d'étude

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Security Engineer Associate AZ-500 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La gestion des clés sur Azure s’articule autour d’Azure Key Vault et d’Azure Managed HSM. Ces services fournissent un stockage sécurisé de matériel cryptographique, des API cohérentes et des opérations auditables qui sous-tendent le chiffrement au repos, en transit et au niveau de la couche applicative. L’objectif opérationnel est de séparer la garde des clés de l’environnement d’exécution des applications, de minimiser le rayon d’impact (blast radius) grâce à des autorisations et une mise en réseau délimitées, et d’appliquer la récupérabilité et la rotation pour réduire le risque lié aux secrets à longue durée de vie.

Architecture et autorisation d’Azure Key Vault et Managed HSM

Architecture d’Azure Key Vault

• Composition du service : frontaux multi-locataires, partitions régionales pour le plan de données, isolation par locataire et authentification adossée à Azure AD. Les clés sont soit protégées par logiciel (niveau Standard), soit protégées par HSM (niveau Premium). Les secrets et les certificats sont toujours protégés par logiciel.
• Niveaux : Standard (clés logicielles) pour un usage général et un bon rapport coût-efficacité ; Premium (clés adossées à un HSM) lorsqu’une protection équivalente à FIPS 140-2 Niveau 2/3 ou une frontière HSM dédiée pour le matériel de clé est requise. Choisissez Premium pour les exigences réglementaires ou lors de l’utilisation de clés avec « RSA-HSM » ou « EC-HSM ».
• Suppression réversible (soft delete) et protection contre la purge : La suppression réversible est toujours activée avec une rétention configurable (7 à 90 jours, généralement 90). La protection contre la purge, lorsqu’elle est activée, empêche la suppression permanente du coffre ou des objets jusqu’à l’expiration de la période de rétention, même par des utilisateurs hautement privilégiés. Raisonnement opérationnel : activez la protection contre la purge sur tout coffre contenant des clés gérées par le client (CMK). Sans cela, une purge accidentelle ou malveillante pourrait rendre les données dépendantes (par ex., le stockage ou les bases de données chiffrées avec cette clé) irrécupérables.
• Récupération : Les objets de coffre supprimés peuvent être listés et récupérés ; la récupération au niveau du coffre est prise en charge. Les sauvegardes produisent des blobs chiffrés qui peuvent être restaurés sur des coffres compatibles dans la même région et le même cloud Azure. Raisonnement : exportez périodiquement les sauvegardes de clés et sécurisez-les séparément ; testez les restaurations pour valider le RTO.

Modèle d’autorisation

• Modèles de permission : Stratégies d’accès au coffre (legacy) vs Azure RBAC (recommandé).
  • Stratégies d’accès : définies par coffre ; accordent des permissions granulaires pour les clés, les secrets et les certificats. Idéal lorsque vous avez besoin de droits d’exécution très stricts et spécifiques au type d’objet pour un petit ensemble de principaux.
  • Azure RBAC : définissez le modèle de permission du coffre sur le contrôle d’accès en fonction du rôle Azure pour utiliser les rôles RBAC du plan de données. Avantages : portée au niveau de l’abonnement/groupe de ressources/coffre ; attributions éligibles à PIM ; gouvernance et audit centralisés. Recommandé pour les nouveaux déploiements et pour les opérations administratives.
• Rôles de coffre intégrés (exemples) : Key Vault Administrator (gestion complète), Key Vault Crypto Officer (gestion des clés mais pas des stratégies d’accès), Key Vault Secrets Officer, Key Vault Certificates Officer, Key Vault Reader. Guide opérationnel :
  • Utilisez RBAC (par ex., Key Vault Administrator) lors de la délégation de la configuration des modèles d’accès et des ACL réseau.
  • Utilisez une stratégie d’accès ou un rôle RBAC du plan de données tel que Key Vault Certificates Officer pour l’insertion/suppression de certificats avec le moindre privilège dans un seul coffre.
• Conception de la portée : Préférez l’attribution de RBAC à la portée du coffre pour éviter un excès de privilèges. Utilisez la portée du groupe de ressources uniquement lorsque plusieurs coffres partagent des équipes d’opérateurs identiques ; évitez les attributions à la portée de l’abonnement pour l’accès en exécution.

Managed HSM

• Architecture et domaines de sécurité : Managed HSM est un cluster HSM mono-locataire, validé FIPS 140-2 Niveau 3, par client. Un domaine de sécurité protège la portabilité du matériel de clé du cluster ; la sauvegarde/restauration entre clusters nécessite un quorum de clés privées du domaine de sécurité. Raisonnement : générez et placez sous séquestre les clés de domaine auprès de dépositaires distincts ; testez la restauration vers un HSM de reprise d’activité (DR).
• Modèle de rôle : Intégré à Azure RBAC. Les rôles incluent Managed HSM Administrator, Crypto Officer, Crypto User et Reader. Séparation des tâches : les administrateurs gèrent le cluster ; les responsables de la cryptographie (crypto officers) gèrent les clés ; les utilisateurs de la cryptographie (crypto users) utilisent les clés pour les opérations.
• Haute disponibilité : Redondance régionale avec plusieurs partitions HSM et un service adossé à un SLA ; redondance de zone disponible dans les régions prises en charge. Pour la reprise d’activité inter-régions, s’appuyer sur les sauvegardes + le domaine de sécurité.
• Cas d’utilisation : Traitement des paiements, signature de code, enveloppement de clés (key wrapping) pour le chiffrement d’enveloppe, et charges de travail réglementées nécessitant des frontières HSM de niveau 3.

Objets et cycle de vie : Clés, secrets, certificats et rotation

Clés, secrets, certificats

• Clés : Pour les opérations cryptographiques (signer, vérifier, wrapper/déwrapper, chiffrer/déchiffrer). Choisir le type/la taille de la clé en fonction de la force de l’algorithme et des performances (par ex., RSA 3072/4096 pour la conformité, ou ECC P-256/P-384 pour les performances).
• Secrets : Octets/chaînes arbitraires tels que les mots de passe, les chaînes de connexion et les jetons d’API. Non utilisés pour les opérations cryptographiques.
• Certificats : X.509 avec des clés privées. Stockés à la fois comme un objet certificat et un secret correspondant (PFX/PEM). Utiles pour les cycles de vie TLS/MTLS et de signature de code.

Opérations de cycle de vie et rotation

• Gestion des versions : Chaque définition ou importation génère une version immuable. Les applications doivent référencer des secrets versionnés pour un comportement déterministe ou des URI sans version pour une prise en compte automatique de la dernière version, en fonction des besoins de gestion du changement.
• Stratégies de rotation :
  • Clés : Préférer les URI de clé sans version pour les services Azure qui les prennent en charge (par ex., Storage, SQL TDE, secrets gérés par AKV). Effectuer la rotation en ajoutant une nouvelle version ; les services se relient automatiquement lorsque cela est pris en charge. Si un service nécessite une version épinglée, automatiser une étape de reconfiguration. Appliquer la rotation avec les stratégies de rotation AKV et les alertes.
  • Secrets : Effectuer la rotation via Azure Automation, Functions ou Logic Apps déclenchés par des notifications Event Grid, ou utiliser la rotation native du fournisseur (par ex., rotation des SAS ou des mots de passe de base de données). Éviter les secrets statiques à longue durée de vie en les remplaçant par des identités managées partout où c’est possible.
  • Certificats : Définir des stratégies de certificat avec des « actions de durée de vie » pour un renouvellement automatique avant l’expiration ; utiliser des émetteurs intégrés pour un renouvellement sans intervention manuelle.

Gestion des certificats

• Importation/génération : Importer un PFX/PEM existant (avec clé privée) ou générer un CSR et laisser Key Vault finaliser l’émission avec une autorité de certification (CA) configurée.
• Renouvellement automatique et émetteurs : Configurer des émetteurs tels que DigiCert, GlobalSign ou une autorité de certification Microsoft d’entreprise via Key Vault. Activer le renouvellement automatique avec des seuils de notification et de renouvellement.
• Intégration applicative :
  • App Service et Functions : utiliser des références Key Vault avec une identité managée ; la plateforme synchronise automatiquement les secrets après rotation.
  • Application Gateway/WAF : référencer l’ID du secret de certificat depuis Key Vault ; la Gateway récupère automatiquement les nouvelles versions.
  • AKS : monter les certificats via le pilote CSI Secrets Store et le fournisseur Azure Key Vault.

Exemple d’attribution RBAC pour des opérations de certificat avec le moindre privilège :

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

Sécurité réseau et intégration des services

Mise en réseau de Key Vault

• Règles de pare-feu : Définir sur Réseaux sélectionnés pour restreindre aux sources approuvées. Justification : empêche le trafic provenant d’Internet même avec des jetons valides.
• Points de terminaison de service de réseau virtuel : Autoriser le trafic depuis des sous-réseaux spécifiques sans adresses IP privées. Simple à activer et réduit l’exposition. À utiliser lorsque vous avez besoin d’une isolation rapide et ne nécessitez pas de modifications DNS.
• Points de terminaison privés : Attribuer une adresse IP privée au coffre dans votre VNet pour une connectivité véritablement privée. Bloquer l’accès au réseau public. Justification : contrôle d’exfiltration le plus strict, requis dans les environnements à haute confiance et lorsque l’accès sortant à Internet est restreint.
• Services de confiance : « Autoriser les services Microsoft de confiance » permet à des services Azure spécifiques d’atteindre le coffre malgré les restrictions réseau. Requis pour des scénarios comme l’analyse des clés de chiffrement de Storage lors de la rotation. Activer de manière ciblée et documenter les dépendances.

Clés gérées par le client (CMK) et URI de clé

• Services pris en charge : Azure Storage, SQL Database (TDE), Synapse, Databricks, chiffrement au repos des secrets AKS, App Configuration, Event Hubs, Service Bus et Managed Disks via un Disk Encryption Set.
• Stratégie d’URI de clé :
  • URI sans version : À préférer lorsque le service prend en charge la liaison automatique aux nouvelles versions de clé ; permet une rotation transparente sans mise à jour du service.
  • URI avec version : Requis par certains services ; automatiser une mise à jour de la configuration du service liée aux événements de rotation.
• Modèles de rotation :
  • Rotation échelonnée : Créer une nouvelle version de clé ; valider que le service peut y accéder ; surveiller les erreurs ; puis désactiver éventuellement les anciennes versions après une période de sécurité.
  • Pilotée par les événements : Utiliser Event Grid sur les événements de nouvelle version de clé pour déclencher des workflows de validation ou de reconfiguration de service.

Intégration du chiffrement d’enveloppe

• Les services Azure utilisent une clé de chiffrement de données (DEK) localement (par ex., AES-256) et une clé de chiffrement de clé (KEK) dans Key Vault/HSM pour wrapper la DEK. Sur le plan opérationnel, assurez la disponibilité de la KEK et l’accès réseau, car la perte ou le blocage de l’accès peut interrompre les opérations du service.

Exemple : wrapper une DEK avec une clé AKV

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

Cryptographie, options pour les données au repos et hygiène des secrets

Concepts cryptographiques fondamentaux

• Chiffrement symétrique : Une seule clé utilisée pour chiffrer/déchiffrer (ex: AES-GCM/CTR). Rapide ; idéal pour les données en masse.
• Chiffrement asymétrique : Paires de clés publique/privée (RSA/ECC) utilisées pour l’échange de clés et les signatures. Plus lent ; idéal pour établir la confiance et envelopper les DEK (Data Encryption Keys).
• Hachage : Condensat unidirectionnel (ex: SHA-256). Pour l’intégrité ; ce n’est pas du chiffrement.
• Signature : La clé privée produit une signature ; la clé publique la vérifie. Non-répudiation et intégrité.
• Chiffrement d’enveloppe : Combine une KEK (Key Encryption Key) asymétrique avec une DEK symétrique pour la performance et l’isolation de la garde des clés.

Azure Disk Encryption et chiffrement du stockage

• Chiffrement par défaut des Managed Disks : Chiffrement côté serveur (SSE) avec des clés gérées par la plateforme (PMK). Surcharge opérationnelle minimale.
• CMK avec un Disk Encryption Set (DES) : Utiliser un DES référençant une clé Key Vault ou Managed HSM pour les disques, les instantanés et les images. Justification : contrôle centralisé du cycle de vie et de la révocation des clés ; répond aux exigences de conformité pour le contrôle par le client.
• ADE (Azure Disk Encryption) : BitLocker (Windows) ou dm-crypt (Linux) dans le système d’exploitation invité. À utiliser lorsque vous avez besoin d’une posture de chiffrement au niveau de l’OS, de protecteurs de clé au niveau du disque liés à un domaine, ou de mandats de conformité existants. Compromis opérationnel : complexité plus élevée, gestion des extensions et impact potentiel sur le provisionnement des VM.
• Double chiffrement :
  • Disques : Combiner le SSE avec PMK au niveau de la couche d’infrastructure et une CMK via un DES pour obtenir deux couches de chiffrement indépendantes.
  • Comptes de stockage : Utiliser des étendues de chiffrement avec des CMK distinctes par conteneur/charge de travail ; combiner avec le chiffrement d’infrastructure là où il est disponible pour obtenir deux couches.
• Étendues de chiffrement (Azure Storage) : Définir des étendues par conteneur ou par blob avec des CMK distinctes pour isoler le risque locataire/charge de travail et permettre une rotation ciblée sans impact généralisé.

Hygiène des secrets et pratiques opérationnelles

• Identités managées : Utiliser des identités managées affectées par le système ou par l’utilisateur pour les ressources Azure afin d’obtenir des jetons pour Key Vault et d’autres services, éliminant ainsi les informations d’identification intégrées. Définir des stratégies d’accès ou RBAC avec une portée restreinte.
• Analyse des secrets : Activer Microsoft Defender for DevOps, l’analyse des secrets de GitHub Advanced Security et les protections de dépôt. Intégrer avec les pull requests pour bloquer les modèles d’informations d’identification connus.
• Pipelines et IaC : Utiliser les intégrations de tâches Key Vault dans Azure Pipelines et les identifiants fédérés basés sur OIDC de GitHub Actions pour éviter les secrets persistants. Ne pas afficher les secrets dans les journaux ; masquer les sorties. Effectuer immédiatement la rotation de tout matériel divulgué.
• Conception d’application : Préférer les références sans version lorsque c’est sûr ; mettre en cache de manière minimale et gérer les erreurs 401/403 en ré-acquérant les jetons et en récupérant à nouveau les secrets pour prendre en charge les événements de rotation.

Plongée dans la gestion des certificats

• Émission basée sur des stratégies : Définir le sujet, les SAN, l’utilisation de la clé, les EKU, le type/taille de la clé et les paramètres de réutilisation de la clé dans une stratégie de certificat Key Vault. Raisonnement : posture TLS cohérente sur l’ensemble des parcs.
• Intégration de l’émetteur : Configurer un profil d’autorité de certification (CA) dans Key Vault. Pour une PKI privée, intégrer avec Microsoft ADCS via un émetteur personnalisé ou utiliser le Certificate Connector d’Azure Key Vault. Les CA publiques permettent un renouvellement automatisé sans exposer les clés privées en dehors d’AKV.
• Opérations de renouvellement automatique : Utiliser des actions de cycle de vie (par ex., renouveler 60 jours avant l’expiration ; notifier à 90 jours). Sur le plan opérationnel, aligner les fenêtres de renouvellement avec les gels des modifications et s’assurer que les services dépendants se synchronisent automatiquement.
• Consommation par les applications : Récupérer en tant que secret (PFX/PEM) ou lier par référence dans les services de la plateforme. Préférer les liaisons natives à la plateforme (App Service, Application Gateway) pour un basculement sans interruption lors des nouvelles versions. Pour Kubernetes, monter via CSI pour déclencher des redémarrages progressifs lors de la rotation.

Scénario de problème pratique

Siemens AG doit protéger la télémétrie IoT dans Azure, appliquer une garde stricte des clés pour les données au repos, et automatiser la rotation des certificats et des secrets sur une flotte distribuée mondialement.

1. Établir les coffres et les périmètres HSM

• Créer des Key Vaults Premium régionaux pour les secrets/certificats d’application et un Managed HSM pour les opérations de KEK.
• Justification : Les coffres Premium permettent d’utiliser des clés adossées à un HSM si nécessaire ; le Managed HSM fournit une assurance de niveau 3 et une garde de clé indépendante pour les opérations de wrapping.

2. Appliquer la récupérabilité et les garde-fous

• Activer la protection contre la purge sur tous les coffres et Managed HSM ; définir la rétention de la suppression réversible (soft-delete) à 90 jours. Appliquer Azure Policy pour auditer/refuser les coffres sans protection contre la purge.
• Justification : Empêche la perte de données catastrophique due aux purges ; la stratégie garantit qu’aucune dérive ne peut se produire.

3. Centraliser l’autorisation à l’aide de RBAC

• Définir le modèle de permission Azure RBAC pour les coffres. Attribuer le rôle Administrateur Key Vault à une petite équipe plateforme via PIM ; attribuer le rôle Responsable des secrets Key Vault aux équipes applicatives au niveau du coffre ; attribuer le rôle Responsable de la cryptographie Managed HSM aux ingénieurs en sécurité.
• Justification : RBAC + PIM permettent d’appliquer le moindre privilège, l’élévation de privilèges limitée dans le temps et un audit cohérent. La séparation des tâches empêche les administrateurs d’utiliser les clés.

4. Verrouiller le réseau avec des points de terminaison privés

• Créer des points de terminaison privés dans les VNets hub ; désactiver l’accès au réseau public. Activer les « services approuvés » uniquement pour les comptes de stockage utilisant une CMK.
• Justification : Les points de terminaison privés éliminent l’exposition publique et bloquent les chemins d’exfiltration de données tout en préservant les flux nécessaires entre les services et les coffres.

5. Mettre en œuvre la stratégie de CMK et de chiffrement

• Pour le stockage, définir des étendues de chiffrement par charge de travail avec des URI de KEK sans version dans le coffre Premium ; pour les disques managés, utiliser des Disk Encryption Sets avec une CMK provenant du HSM. Activer le chiffrement au niveau de l’infrastructure pour un double chiffrement.
• Justification : Des clés par charge de travail réduisent le rayon d’impact ; les URI sans version permettent une rotation transparente ; le double chiffrement satisfait les exigences de conformité strictes.

6. Automatiser la rotation des clés et des secrets

• Configurer les stratégies de rotation des clés AKV (par ex., expiration annuelle, rotation à 9 mois) et les notifications Event Grid qui déclenchent des tâches de validation. Utiliser des identités managées dans les services ; supprimer les informations d’identification statiques.
• Justification : Une rotation prévisible et automatisée réduit le risque lié aux clés et secrets à longue durée de vie ; les identités managées remplacent les secrets partagés fragiles.

7. Opérationnaliser les certificats

• Utiliser les stratégies de certificat Key Vault avec l’intégration de l’émetteur DigiCert ; définir le renouvellement automatique 60 jours avant l’expiration. Lier les certificats par référence dans Application Gateway et App Service.
• Justification : Le renouvellement automatisé prévient les pannes et évite la manipulation manuelle des clés ; les liaisons de plateforme prennent en compte les nouvelles versions sans redéploiement.

8. Valider et surveiller

• Activer les journaux de diagnostic de Key Vault et Managed HSM vers Log Analytics ; alerter sur les tentatives non autorisées, les refus de pare-feu et les événements de quasi-expiration. Exécuter des tests de restauration trimestriels pour les sauvegardes de coffre et de HSM en utilisant le quorum du domaine de sécurité.
• Justification : La surveillance continue détecte rapidement les mauvaises configurations ou les attaques ; les tests de restauration garantissent la capacité de récupération sous pression.

← Sécurité des données · Tous les domaines · Gestion de la posture de sécurité et gouvernance →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Microsoft →