8 — Governance & Key Vault (AZ-500)

Gouvernance = appliquer/auditer des garde-fous à l'échelle (Azure Policy) ; Key Vault = stockage durci et géré des secrets, clés et certificats — les deux forment le socle de l'enforcement de sécurité et de la protection des matériels cryptographiques sur Azure.

A. Azure Policy — l'enforcement de sécurité à l'échelle

Vous connaissez déjà Policy (AZ-104/305) pour le coût/conformité. Angle AZ-500 : Policy est le moteur des « security policies » de Defender for Cloud. Toute recommandation MCSB = une définition Azure Policy. Maîtriser les effets = comprendre si un contrôle bloque, corrige ou audite.

Ordre d'évaluation (clé d'examen) : disabled → append/modify → deny → audit → manual → auditIfNotExists → denyAction. Deny avant audit pour éviter le double-logging. DINE/AINE s'évaluent après le succès du Resource Provider.

Initiatives = regroupement de policies (= « initiative » sur Azure, « policy set » techniquement). Built-in security : la MCSB initiative est l'initiative par défaut assignée automatiquement dès que Defender for Cloud est activé (>420 définitions en v2 preview, mapping CIS/NIST/PCI-DSS).

🚨 Pièges

• audit ≠ auditIfNotExists : audit évalue les propres propriétés de la ressource ; AINE évalue une ressource enfant/extension. Non interchangeables (AINE exige un bloc existenceCondition).
• Une policy assignée au management group ne s'évalue que sur les ressources subscription/RG en dessous — le MG lui-même n'est jamais évalué.
• Compliance state ≠ enforcement : un effet Deny apparaît compliant pour les nouvelles ressources (bloquées au request time) mais non-compliant pour l'existant pré-existant qui violait déjà la règle.

B. Remediation tasks & Managed Identity

Modify et DeployIfNotExists ne corrigent automatiquement que les ressources nouvelles/mises à jour. L'existant non-conforme exige une remediation task explicite.

• La remédiation utilise la Managed Identity de l'assignation (system-assigned ou user-assigned), à qui on assigne le rôle RBAC minimal nécessaire au déploiement/à la modification.
• Portail : accorde automatiquement les rôles listés à la MI lors de l'assignation. SDK/CLI/Bicep : il faut accorder les rôles manuellement.
• Nuance d'identité : pour DINE, c'est la MI de l'assignation qui déploie, mais c'est l'identité de l'appelant (requestor) qui évalue la condition d'existence. → l'appelant a besoin du read, l'assignation du write.
• MI system-assigned ⇒ propriété location obligatoire (≠ global, immuable).

🚨 Pièges

• Changer une définition ne met pas à jour automatiquement l'assignation ni les rôles de la MI.
• Remediation task supprimée par Azure 60 j après dernière modif (les ressources déployées, elles, restent).
• Sur un MG, la remédiation au moment de l'assignation n'est pas supportée → créer la tâche après l'évaluation (option Remediation page / assignation non-conforme).

C. Lien Azure Policy ↔ Defender for Cloud

Les « security policies » de Defender for Cloud sont des assignations Azure Policy. La MCSB est l'initiative par défaut ; elle pilote le Secure Score et le Regulatory compliance dashboard. Activer/désactiver un contrôle de sécurité dans Defender = toggler l'assignation Policy correspondante (Environment settings → Security policies → MCSB → Status On).

🚨 La MCSB doit être appliquée (Foundational CSPM activé) pour voir les paramètres de sécurité dans le portail ; l'évaluation prend ~1 h après assignation.

D. Key Vault — modèle d'accès (RBAC vs access policies)

KV expose deux plans : control plane (gérer le vault, via Azure RBAC/ARM) et data plane (lire/écrire clés-secrets-certs).

Roles data-plane clés : Key Vault Administrator (tout), et par type — Crypto Officer / Crypto User (clés), Secrets Officer / Secrets User (secrets), Certificates Officer / Certificate User (certs), + Reader, Purge Operator. Officer = gère l'objet (hors permissions) ; User = lit le contenu/utilise.

🚨 Pièges

• API 2026-02-01+ : RBAC est désormais le défaut pour les nouveaux vaults (enableRbacAuthorization=true). Pour rester en access policies → forcer enableRbacAuthorization=false à la création. Les vaults existants ne changent pas tout seuls (null/false = access policies).
• API control plane < 2026-02-01 retirées le 27 fév. 2027 (data plane non affectée) → migrer ARM/Bicep/Terraform/scripts Cloud Shell.
• Access policies = pas de PIM, droit d'auto-élévation via Contributor → considérées vulnérables, à éviter en prod.
• Propagation RBAC : ~10 min après assignation, source classique de « Access denied » trompeur.

E. Key Vault — sécurité réseau

Du plus restreint au moins restreint :

🚨 Pièges

• Trusted services ≠ tous les services Microsoft : Azure DevOps, par ex., n'est pas dans la liste → exige une IP rule / VNet rule / Private Endpoint. La liste couvre seulement les services dont MS contrôle tout le code.
• Le bypass trusted services persiste même quand publicNetworkAccess=Disabled. Mais en mode Secure by perimeter (Network Security Perimeter), le bypass est annulé — même les trusted services sont bloqués sauf règle d'accès explicite du périmètre.
• Trafic Private Endpoint = considéré hautement sécurisé, non soumis aux règles NSP.
• Firewall actif ⇒ le portail peut lister les vaults mais pas leurs objets si votre IP cliente n'est pas autorisée (idem Key Vault Picker des autres services). Cloud Shell = IP distante, non couverte par Private Link.

F. Clés / secrets / certificats — cycle de vie

• 3 types d'objets : keys (RSA/EC, software ou HSM-backed en Premium), secrets (chaînes arbitraires), certificates (X.509, gèrent leur key+secret en interne).
• Versioning automatique : chaque MAJ crée une nouvelle version ; les anciennes restent référençables (rotation sans casser le déchiffrement de données existantes).
• Soft-delete : activé par défaut, non désactivable une fois actif. Rétention 7–90 j (défaut 90), fixée à la création (immuable ensuite). Recyclage corbeille : recover ou purge.
• Purge protection : optionnelle, exige soft-delete. Une fois active, personne (ni admin, ni Microsoft) ne peut purger avant la fin de la rétention. Requis par la plupart des services (Storage CMK, etc.).

🚨 Pièges

• Noms globalement uniques (vault) et uniques dans le vault (objets) : un objet soft-deleted bloque la réutilisation du nom jusqu'à purge/expiration.
• Recover d'un vault soft-deleted ne restaure pas les services intégrés (role assignments RBAC, Event Grid subscriptions) → à recréer.
• Purger un objet exige la permission purge (rôle Key Vault Purge Operator) — distincte du delete.

G. Rotation automatique des clés

• Rotation policy native pour les clés : rotation auto selon une fréquence (recommandé ≤ 2 ans), génère une nouvelle version sans downtime applicatif.
• Événements Event Grid : KeyNearExpiryEventGridNotification (near-expiry) et KeyExpiredEventGridNotification — émis même sans abonnement Event Grid (visibles dans les logs). Permettent d'automatiser une réaction.
• Secrets/certs : autorotation via tutoriels (single/dual credentials, certificate autorotation) — pas la même mécanique « rotation policy » que les clés.

🚨 Opérations à logger : KeyRotate (manuel), KeyRotateIfDue (planifié), KeyRotationPolicySet/Get.

G-bis. Monitoring Key Vault

Deux couches complémentaires : logging (visibilité/forensique, gratuit) et Defender for Key Vault (détection de menaces, payant).

Diagnostic settings (logging) — à activer sur le vault :

• Sans diagnostic setting, les resource logs ne sont pas collectés (les métriques/activity log le sont automatiquement). Tables Log Analytics : AZKVAuditLogs, AZKVPolicyEvaluationDetailsLogs (ou AzureDiagnostics).
• Alertes utiles (Azure Monitor sur les logs) : Authentication failed (accès refusés répétés), pics de SecretGet / listing de secrets, modifications d'access-policies, accès depuis IP inattendue.

Defender for Key Vault (plan CWPP de Defender for Cloud, GA) :

• Détecte les accès anormaux/suspects au vault par analyse comportementale + Threat Intelligence, sans gérer de système tiers. Alertes (préfixe KV_) : accès depuis IP suspecte (KV_SuspiciousIPAccess) ou nœud TOR (KV_TORAccess), utilisateur inhabituel (KV_UserAnomaly), volume anormal d'opérations (KV_OperationVolumeAnomaly), secret listing + get typique d'un secret dumping (KV_ListGetAnomaly), changement de policy suivi d'un get (KV_PutGetAnomaly).
• Réponse type : ne pas dismiss sur simple reconnaissance de l'utilisateur (les alertes ciblent les credentials volés) ; investiguer la source, puis rotater/désactiver les secrets-clés-certs accédés.

🚨 Pièges

• Logging (diagnostic settings) ≠ Defender for Key Vault : le 1er enregistre, le 2nd détecte et alerte. Les deux sont complémentaires (Defender s'appuie d'ailleurs sur l'activité du vault).
• AuditEvent est la catégorie historique ; penser à inclure aussi AzurePolicyEvaluationDetails pour tracer la conformité Policy.
• Defender for Key Vault est payant et pas activé par défaut (responsabilité client).

📌 Monitor Azure Key Vault · Enable Key Vault logging · Defender for Key Vault · Alerts for Azure Key Vault

H. Backup / recovery des objets KV

Trois couches de protection, par ordre de préférence :

1. Redondance auto + failover (cross-region, géré par KV) — suffisant dans la plupart des cas.
2. Soft-delete + purge protection (cf. §F) — protection principale contre la suppression.
3. Backup/restore manuel par objet (key/secret/cert) — uniquement si justification métier forte.

🚨 Pièges backup

• Un backup est chiffré, opaque, par objet ; un restore ne fonctionne que vers un vault de la même subscription et même géographie/region pair.
• Un objet restauré dans un autre vault devient totalement indépendant de l'original (multiplie logs/permissions/expirations à gérer) → n'accorder l'opération backup qu'aux identités qui en ont vraiment besoin.
• Backup ≠ versioning : un backup capture l'objet, pas l'historique opérationnel complet.

I. Protéger les backups (anti-ransomware) — Immutable Vault + MUA

Pour les Recovery Services Vault et Backup Vault (sauvegardes VM/SQL/Files/etc.), trois contrôles cumulatifs contre un admin rogue / ransomware :

🚨 Pièges

• MUA repose sur une séparation des rôles : l'owner du vault ≠ owner du Resource Guard (sinon pas de barrière). Désactiver MUA est lui-même une opération protégée.
• Opérations mandatory du Resource Guard (Disable soft delete, Remove MUA) ne peuvent pas être exclues ; les optional (Restore, etc.) oui.
• Soft-delete RSV (14 j) ≠ soft-delete Key Vault (7–90 j) — mécaniques distinctes.

J. Asset management — contrôles de sécurité de gouvernance

Garde-fous transverses (cross-ref AZ-104) avec angle sécurité :

• Resource locks : CanNotDelete / ReadOnly (portail : Delete / Read-only). Override tous les utilisateurs/rôles (≠ RBAC). Anti-suppression accidentelle des ressources critiques (vault, RG prod).
• Tags : enforcés via Azure Policy (effet Modify/Append) — classification (sensibilité), ownership, cost center.
• Inventory / naming / secure baselines : Azure Resource Graph pour l'inventaire ; baselines de sécurité (Azure compute security baseline via Guest Configuration) auditées par la MCSB.

🚨 Pièges locks

• Locks = plan de gestion uniquement (management.azure.com). Un ReadOnly sur un vault empêche de le modifier/supprimer mais n'empêche pas les opérations data-plane (lire/écrire des secrets).
• L'héritage va du parent vers l'enfant ; le lock le plus restrictif gagne. Penser à retirer les locks avant un terraform destroy (sinon échec).
• ReadOnly peut casser des opérations légitimes (un vault ReadOnly bloque la création de nouveaux secrets).

K. Niveaux Key Vault & Managed HSM

🚨 Pièges Managed HSM

• Premium ET Managed HSM sont tous deux FIPS 140-3 L3 (fleet mise à jour) — la différence n'est pas le niveau FIPS mais la tenancy (single vs multi) et le contrôle du root of trust / security domain par le client.
• Managed HSM = RBAC local (data-plane) propre, enforcé par le HSM lui-même, isolé du control plane ARM : donner un accès management plane ne donne aucun accès aux clés (≠ Key Vault). Séparation des privilèges by design.
• Security domain à télécharger/sécuriser immédiatement après provisioning (quorum ≥3 key holders) — requis pour le disaster recovery ; sa perte = perte définitive des clés.

🏢 Scénarios d'entreprise (CAF/WAF)

Scénario 1 : Bancaire — imposer le chiffrement et bloquer les écarts sur la landing zone

Contexte business : Une banque veut que toute ressource sensible soit chiffrée et qu'aucun Storage/Key Vault ne soit créé sans firewall, sur toute la hiérarchie de souscriptions. Choix architectural : Une initiative Azure Policy assignée au management group, qui bloque ET corrige, déployée par étapes (Audit puis Deny). Architecture / pattern :

• Initiative assignée au management group (héritée par toutes les souscriptions enfants)
• Policies Deny : refuser KV sans firewall, ressources non chiffrées
• Policies Modify/DeployIfNotExists : forcer les tags, activer les diagnostic settings
• Remediation tasks + Managed Identity pour remettre l'existant en conformité
• D'abord en Audit pour mesurer l'impact, puis bascule en Deny Trade-offs assumés :
• Gain : conformité imposée dès la création, écarts bloqués, legacy corrigé automatiquement
• Perte : un Deny posé trop tôt peut bloquer des déploiements légitimes ; gestion des exemptions à assurer Pièges à éviter :
• Passer en Deny sans phase Audit → blocage massif des équipes en production
• Oublier la Managed Identity / les rôles requis par DeployIfNotExists/Modify → remédiation en échec
• Assigner à la souscription au lieu du management group → nouvelles souscriptions non couvertes 📐 Réf. CAF/WAF — CAF Govern (enforce policies) : automatiser l'enforcement via Azure Policy, restreindre types/régions, IaC + landing zones contre le drift Lien

Scénario 2 : Multi-souscription — pilotage de la conformité via MCSB & Defender for Cloud

Contexte business : Un groupe multi-souscription veut une vue unique de conformité et un Secure Score suivi dans le temps, mappé sur des référentiels réglementaires. Choix architectural : Activer Defender for Cloud (qui assigne l'initiative MCSB automatiquement) et utiliser le dashboard de conformité réglementaire pour prioriser les remédiations. Architecture / pattern :

• Defender for Cloud activé → initiative MCSB assignée automatiquement, évaluation continue
• Regulatory compliance dashboard mappant CIS / NIST / PCI-DSS
• Les contrôles non conformes guident les remédiations (Secure Score)
• Les « security policies » restent des assignations Azure Policy personnalisables Trade-offs assumés :
• Gain : conformité centralisée et continue, mapping réglementaire prêt à l'emploi, priorisation par Secure Score
• Perte : le Secure Score est indicatif (ne prouve pas la conformité réelle) ; coût des plans Defender à l'échelle Pièges à éviter :
• Confondre Secure Score et conformité réglementaire réelle (deux choses distinctes)
• Modifier l'initiative MCSB sans mesurer l'impact sur l'évaluation Defender
• Activer des standards sans process de remédiation → dashboard rouge ignoré 📐 Réf. CAF/WAF — CAF Secure (govern estate) + MCSB : Azure Policy + Defender for Cloud pour enforcer les standards et automatiser la conformité Lien · MCSB intro

Scénario 3 : Fintech — protéger secrets et sauvegardes contre vol et ransomware

Contexte business : Une fintech veut durcir Key Vault et garantir que même un admin compromis ne puisse ni voler les secrets ni détruire les sauvegardes. Choix architectural : Isoler et durcir Key Vault (un vault par app, RBAC + PIM, Private Endpoint, anti-suppression) et rendre les sauvegardes immuables avec validation à deux personnes. Architecture / pattern :

• Key Vault : un vault par application, RBAC + PIM (accès juste-à-temps), Private Endpoint
• Soft-delete + purge protection + rotation automatique des clés
• Sauvegardes : Immutable Vault + Multi-User Authorization (MUA) + enhanced soft delete Trade-offs assumés :
• Gain : surface de vol réduite, secrets isolés par app, sauvegardes inaltérables même par un admin compromis
• Perte : friction (PIM/MUA imposent approbations et délais) ; purge protection rend toute suppression définitive Pièges à éviter :
• Un seul Key Vault partagé entre apps → impact énorme si compromis
• Activer immutabilité/MUA sans procédure break-glass → restaurations légitimes bloquées
• Oublier le Private Endpoint / laisser le firewall ouvert → vol possible malgré le RBAC 📐 Réf. CAF/WAF — WAF Security (secrets) + Key Vault service guide : durcir le stockage des secrets, rotation régulière, isolation par scope ; un Key Vault par application, RBAC recommandé Lien · Secure Key Vault

DEMO — chemins portail

1. Assigner la MCSB et créer une remediation task

Microsoft Defender for Cloud → Environment settings → sélectionner la subscription → Security policies → activer Microsoft cloud security benchmark (Status → On). Puis Policy → Remediation → onglet Policies to remediate → choisir une assignation DeployIfNotExists/Modify non-conforme → configurer la Managed Identity + scope → Remediate.

2. Basculer un Key Vault d'access policies vers RBAC

Key vaults → votre vault → Access configuration → choisir Azure role-based access control → Apply. Puis Access control (IAM) → Add role assignment → ex. Key Vault Secrets Officer → assigner au principal/Managed Identity. (Vérifier qu'aucune app ne dépend encore d'une access policy avant de basculer.)

3. Durcir le réseau d'un Key Vault (Private Endpoint)

Key vaults → vault → Networking → Public access : Disable (ou Selected networks + cocher Allow trusted Microsoft services to bypass this firewall) → onglet Private endpoint connections → + Create → choisir VNet/subnet + Private DNS zone → valider.

4. Activer soft-delete, purge protection et rotation de clé

Key vaults → vault → Properties : confirmer Soft-delete (rétention 7–90 j) + activer Purge protection → Save. Puis Keys → clé → Rotation policy → définir Expiry time + Auto-rotation (fréquence) → Save. (Optionnel : Events → abonner KeyNearExpiry à une action.)

5. Protéger un vault de sauvegarde (Immutable Vault + MUA)

Backup vaults (ou Recovery Services vaults) → vault → Properties → Immutability : Enabled (puis irréversible si voulu). Puis Multi-User Authorization → associer un Resource Guard (créé dans un autre tenant/sub avec owner distinct) → confirmer que Disable soft delete et Disable immutability deviennent des opérations protégées.