11 — Governance

Organiser, contrôler et sécuriser ton environnement Azure : hiérarchie, tags, locks, policies, cost management, templates, Key Vault.

A. Hiérarchie Azure

Tenant Entra ID (root)
  └─ Management Group (root MG)
        └─ Management Group (child) — jusqu'à 6 niveaux
              └─ Subscription
                    └─ Resource Group
                          └─ Resource

Héritage descendant : RBAC, Policy, Tags (Cost Mgmt) → tout ce qu'on assigne à un niveau s'applique aux niveaux inférieurs.

Management Groups

Conteneurs pour organiser plusieurs subscriptions → appliquer Policy / RBAC à grande échelle.

• Tenant Root Group : créé auto, 1 par tenant.
• Hiérarchie max : 6 niveaux sous le root + 10 000 MGs par tenant.
• 1 sub appartient à 1 seul MG à la fois.
• Pour activer la gestion des MGs : Tenant Root Group doit être activé (Access management for Azure resources sur ton compte Global Admin).

Use case : organiser par BU, prod/dev/test, region. Appliquer une policy "deny non-compliant SKU" au scope MG → s'applique à toutes les subs dessous.

Subscriptions

• Container de billing + container logique de ressources.
• Limites par sub (cores, public IPs, RGs, etc.) — voir Usage + quotas.
• 1 sub = 1 tenant (mais transférable vers un autre tenant).

Resource Groups (RG)

• Container logique pour ressources liées (lifecycle commun).
• Region du RG = région des metadata (les ressources peuvent être ailleurs, mais same region recommandé).
• Une ressource = 1 seul RG à la fois.

B. Tags

Métadonnées clé-valeur sur ressources / RGs / subs

Caractéristiques

• Max 50 tags par ressource.
• Key 512 chars max (RG: 128), value 256 chars max.
• ⚠️ Pas hérités par défaut : un tag sur le RG ne descend PAS sur les ressources.
• Certaines ressources ne supportent pas les tags ou les tags ne s'affichent pas dans le billing.
• Modifiables après création.

Use cases

• Cost allocation : costcenter=IT, project=Alpha
• Lifecycle : environment=prod/dev, [email protected]
• Compliance : dataclass=confidential

Tag inheritance

Deux mécanismes différents (à ne PAS confondre) :

Pour AZ-104 : retenir les tags ne sont PAS hérités automatiquement. Pour les enforcer → Azure Policy (Require a tag on resources, Inherit tag from RG, etc.).

C. Resource Locks

Empêcher la modification ou suppression accidentelle. Niveau gestion, pas RBAC.

Caractéristiques

• Scope : Sub / RG / Resource
• Hérités : un lock sur le RG s'applique à toutes les ressources dedans.
• Le plus restrictif gagne : si Delete au RG + ReadOnly sur la VM → la VM est ReadOnly.
• Override : nécessite la permission Microsoft.Authorization/locks/* (ex: Owner ou User Access Administrator). Contributor ne peut pas les modifier.
• ⚠️ Les locks n'empêchent pas les opérations data plane (ex: ReadOnly sur Storage = peut toujours upload des blobs, ça empêche juste de modifier le SA).

D. Cost Management

Suite d'outils pour analyser, budgéter et optimiser les coûts.

Outils principaux

Budgets

• Scope : Sub / RG / MG / billing account.
• Période : monthly / quarterly / annually.
• Threshold alerts : 5 niveaux d'alerte par budget (ex 50%, 75%, 90%, 100%, 110%).
• Types : Cost (€) ou Usage (consommation, ex: hours).
• ⚠️ Un budget n'arrête rien automatiquement — c'est juste une alerte. Pour stopper : action group qui invoque un Logic App / Function.

Advisor (côté coût)

Recommandations type :

• Right-size / shutdown VMs sous-utilisées
• Acheter des Reserved Instances pour workloads stables
• Supprimer ressources inutilisées (Public IPs, NICs, disks orphelins, disks non attachés)

💡 Cibler les recommandations à des RG spécifiques : Advisor > Configuration > Resources → décocher les RG/subs dont tu ne veux PAS voir les recommandations. Utile si tu veux focus sur "RG prod uniquement" ou "trouver les disks orphelins dans 2-3 RG précis" sans bruit du reste de la sub.

⚠️ À ne pas confondre :

• Azure Cost Management > Advisor recommendations = vue agrégée des recommandations cost (filtres possibles mais l'activation/scope se fait via Advisor Configuration, pas Cost Management).
• Billing Administrator role = gère le billing, pas un outil pour filtrer Advisor.
• Azure Monitor custom log query = trop complexe pour un cas natif Advisor (= mauvaise réponse aux QCM "réduire le coût en identifiant disks unattached").

E. Azure Policy

Imposer des règles sur les ressources : ce qu'on peut créer, où, comment, avec quels tags. Audit ou enforcement.

Concepts

Policy Definition  (la règle, JSON)
   ↓ groupée dans
Initiative (Set Definition)  (groupe de policies, ex "ISO 27001 baseline")
   ↓ assignée à un
Scope (MG / Sub / RG / Resource) avec parameters + exclusions
   ↓ génère
Compliance state (Compliant / Non-compliant / Conflict / Exempt)

Effects (à connaître pour AZ-104)

Modify et DINE = nécessitent une Managed Identity côté policy assignment + le rôle Contributor (ou plus) pour pouvoir agir.

Initiatives (Set Definitions)

• Groupe plusieurs policy definitions → assignement unique.
• Built-in : Azure Security Benchmark, CIS, ISO 27001, NIST, PCI DSS, HIPAA HITRUST, etc.
• Recommandation MS : toujours assigner via une initiative, même pour 1 policy → tu pourras en ajouter d'autres sans réassigner.

Remediation

• DINE / Modify : n'agit que sur les nouvelles ressources créées après l'assignment.
• Pour les ressources existantes non-compliant → créer une Remediation Task depuis l'assignment.
• Permission : Resource Policy Contributor ou Owner au scope.

Exemptions

• Permet d'exclure une ressource spécifique d'une policy (avec justification + date d'expiration).
• 2 catégories : Waiver (accepté tel quel) ou Mitigated (compliant via un autre moyen).

Compliance evaluation

• Trigger : création/update de ressource, scan périodique (~24h), ou trigger manuel (az policy state trigger-scan).
• Vue : Policy > Compliance → drill-down par initiative/policy/ressource.

F. ARM Templates & Bicep

Infrastructure as Code (IaC) natif Azure.

ARM Templates (JSON)

• Format historique : JSON déclaratif décrivant les ressources Azure.
• Sections : parameters, variables, resources, outputs, functions.
• Verbose mais portable.

Parameter constraints (validation au déploiement)

Les paramètres ARM/Bicep peuvent imposer des contraintes de validation rejetées au déploiement si non respectées :

💡 Piège exam : "quel attribut pour limiter le param vmSize à 3 SKUs au choix ?" → allowedValues (pas defaultValue, pas minLength). Pour nom SA (3-24 chars) → minLength + maxLength.

Bicep

• DSL moderne au-dessus d'ARM, plus lisible. Transpile en JSON ARM avant déploiement.
• Avantages : syntaxe concise, modules, type safety, IntelliSense (VS Code), pas de gestion dependsOn (auto).
• Recommandé MS pour tout nouveau IaC sur Azure.

// Exemple Bicep
param location string = resourceGroup().location
resource sa 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'mystorage${uniqueString(resourceGroup().id)}'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

Deployment scopes

Deployment modes

Pour AZ-104 : retenir que Complete peut supprimer des ressources non listées. À utiliser avec précaution.

Templates avancés

Linked templates

• Un template principal référence un autre via Microsoft.Resources/deployments avec une URL externe.
• Avantage : modularité, réutilisation cross-projets.
• ⚠️ Le template lié doit être accessible publiquement ou via SAS (pas un fichier local).

Nested templates

• Template inline dans un autre (pas d'URL externe).
• Use case : appliquer un template à un scope différent (sub-level deployment depuis un RG-level template).

Bicep Modules

• Équivalent moderne des linked templates en Bicep.
• Référence un fichier local : module sa './storage.bicep' = { ... }.
• Plus propre que linked/nested templates ARM.

Outils de déploiement

• Portal : Custom deployment > Build your own template
• CLI : az deployment group create -g rg --template-file main.bicep --parameters @params.json
• PowerShell : New-AzResourceGroupDeployment
• What-if : az deployment group what-if → simule sans déployer

G. Moving Resources

Déplacer des ressources entre RG / Sub / Region.

Process

1. Validate : az resource invoke-action --action validateMoveResources → check si déplaçable.
2. Move : tous les ressources dépendantes doivent suivre (NIC + VM + Disk + IP).
3. Source et destination LOCKED pendant le move.

Limitations

• Toutes les ressources ne sont pas déplaçables (ex: certaines GW, ASE, certaines DBs).
• Liste : MS Learn → "Move operation support for resources".
• RBAC assignments : pas déplacés (à recréer côté destination).
• Resource locks : à recréer.
• Tags : conservés.

Resource Mover

• Service Azure pour orchestrer des moves complexes (cross-region surtout).
• Gère les dépendances, génère les templates ARM nécessaires.
• Use case : migration région A → région B.

H. Azure Key Vault

Coffre managé pour secrets, keys, certificates. Utilisé par toutes les ressources Azure qui ont besoin de creds (SQL CMK, Storage CMK, App Service settings, etc.).

Types d'objets

SKUs

Auth / Access — 2 modèles

🚨 Changement 2026 : à partir de l'API version 2026-02-01, les nouveaux Key Vaults créés sont par défaut en Azure RBAC (enableRbacAuthorization = true, au lieu d'Access Policies historiquement). Les KVs existants ne changent pas. Pour forcer les access policies sur un nouveau KV : --enable-rbac-authorization false.

⚠️ Toutes les API control plane KV antérieures à 2026-02-01 sont retirées le 27 février 2027 → maj tes scripts/templates ARM/Bicep/Terraform vers 2026-02-01+ (le data plane n'est pas affecté).

Roles RBAC clés

• Key Vault Administrator : full data plane (clés/secrets/certs) sans gérer le vault lui-même.
• Key Vault Secrets Officer : R/W/D des secrets.
• Key Vault Secrets User : R seulement.
• Key Vault Crypto Officer : R/W/D des keys.
• Key Vault Crypto User : utiliser les keys (decrypt, sign).
• Key Vault Certificates Officer / User : idem pour certs.
• Key Vault Purge Operator : purger après soft-delete.

Distinction : Owner / Contributor (control plane) gèrent le KV mais n'ont pas accès aux data par défaut en mode RBAC. Il faut des rôles data plane.

Soft-delete & Purge protection

⚠️ Purge protection irréversible une fois activée → impossible de désactiver. Si tu actives par erreur, faut attendre l'expiration de la rétention soft-delete.

Networking

• Public access : Allow / Selected networks (Service Endpoint + IPs) / Disabled.
• Private Endpoint : recommandé pour prod.
• Trusted Microsoft services : permet à des services Azure (Disk Encryption, Backup, etc.) d'accéder même si firewall activé.

Encryption sur ressources Azure

• CMK : key dans KV, utilisée par Storage / SQL / Disks / etc. → besoin de :
  • Soft-delete + Purge protection ACTIVÉS sur le KV (sinon création CMK refusée).
  • Une Managed Identity sur la ressource source qui a accès au KV.

I. Tools admin transverses

Azure Cloud Shell

Shell navigateur intégré au portail Azure → Bash ou PowerShell sans rien installer localement.

Caractéristiques :

• Authentifié auto avec ton compte Azure (pas de az login).
• Stockage persistant : nécessite un Storage Account (5 GB Azure Files mounté sur $HOME/clouddrive) — créé à la 1ère utilisation. Sans ce SA, les fichiers persistent pas entre sessions.
• Timeout : 20 min d'inactivité → session terminée (les fichiers clouddrive restent).
• Outils pré-installés : az, Azure PowerShell, kubectl, helm, terraform, bicep, Docker, Git, Python, .NET…
• Editor intégré : Monaco editor (code command) — VS Code light.
• Accessible via : shell.azure.com, le portail (icône en haut), VS Code, mobile app.

Use case AZ-104 : exécuter des scripts admin sans setup local, faire des démos, runner des commandes one-shot.

Azure Resource Graph

Service de requête KQL pour explorer toutes tes ressources Azure cross-sub à grande échelle (rapide, indexé).

Use case :

• Inventaire : "Liste toutes les VMs sans tag owner"
• Compliance : "Quels SAs n'ont pas le secure transfer activé ?"
• Reporting : "Coût total des disques non attachés"

Exemples KQL :

// Toutes les VMs et leur taille + region
Resources
| where type =~ "microsoft.compute/virtualmachines"
| project name, location, vmSize=tostring(properties.hardwareProfile.vmSize)

// Storage Accounts sans HTTPS forcé
Resources
| where type =~ "microsoft.storage/storageaccounts"
| where properties.supportsHttpsTrafficOnly == false
| project name, resourceGroup, subscriptionId

Accès : Azure Resource Graph Explorer dans le portail, ou az graph query.

Différent de Log Analytics (qui interroge des logs) : Resource Graph interroge l'état (config) des ressources.

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

Scenario 1 : Groupe multinational (3 régions, 12 filiales)

Contexte business : un groupe industriel FR-DE-US a 12 filiales autonomes côté IT, mais veut une base commune de sécurité et de coût (chiffrement au repos, régions autorisées, tag CostCenter obligatoire). Audit et facturation centralisés, mais chaque filiale reste autonome sur ses abonnements. Choix architectural : une hiérarchie de Management Groups sur 3 niveaux + des Policy posées au niveau MG + héritage RBAC + chargeback via Cost Management. Architecture / pattern :

• Tenant Root MG → Corp MG (règles pour tout le groupe) → MGs par région (EMEA / NA / APAC) → MGs par filiale → abonnements (prod/dev/test).
• Au Corp MG, on pose : Allowed locations (bloque hors UE+US), Require tag CostCenter, Audit encryption at rest. Tout en dessous en hérite.
• RBAC : Reader au Root pour les auditeurs (vue globale), Contributor par filiale pour ses responsables IT.
• Cost Management : héritage de tags activé au niveau facturation, ce qui permet la refacturation mensuelle par filiale via CostCenter. Trade-offs assumés :
• Gain : base commune de sécurité/coût imposée par héritage, filiales autonomes sous les guardrails.
• Perte : hiérarchie MG à concevoir et maintenir, et l'héritage de policy peut surprendre en cas de conflit. Pièges à éviter :
• Les tags ne sont pas hérités automatiquement par les ressources : il faut la policy Inherit a tag from RG (effet Modify + tâche de remédiation).
• Ordre d'héritage des Policy : MG > Sub > RG > Resource. En cas de conflit, le Deny le plus spécifique l'emporte.
• Activer le Tenant Root Group au départ (Global Admin → "Access management for Azure resources"), sinon impossible de bâtir une vraie hiérarchie.

📐 Réf. CAF — Management group hierarchy + policy-driven governance : structurer les Management Groups par geo/BU et appliquer les policies (allowed locations, require tags, encryption) au scope MG pour héritage descendant est le pattern CAF de gouvernance à l'échelle. Lien

Scenario 2 : Healthcare US — compliance HIPAA/HITRUST automatisée

Contexte business : un hôpital privé US stocke des données de santé (PHI) sur Azure et subit des audits HHS réguliers. Il doit prouver sa conformité HIPAA en continu, pas seulement une fois par an. Choix architectural : l'initiative Azure Policy intégrée HIPAA HITRUST appliquée au MG de prod + un Key Vault Premium HSM pour les clés + des Resource Locks sur les ressources PHI critiques. Architecture / pattern :

• Initiative HIPAA HITRUST 9.2 appliquée au MG Prod-Healthcare : ~600 contrôles évalués automatiquement.
• Effets : surtout Audit au début, plus quelques Deny clés (Disable public network access on Storage, Require HTTPS only).
• Key Vault Premium adossé à un HSM (FIPS 140-2 L2) avec purge protection verrouillée (Locked) + soft-delete 90 jours.
• Resource Lock CanNotDelete sur les comptes de stockage des imageries DICOM et sur le Key Vault PHI.
• Tableau de bord de conformité ouvert aux auditeurs en lecture seule (Reader au niveau de l'initiative). Trade-offs assumés :
• Gain : conformité HIPAA évaluée en continu et prouvable, clés protégées en HSM.
• Perte : la purge protection verrouillée est irréversible, et les Deny peuvent bloquer des déploiements légitimes. Pièges à éviter :
• Ne pas confondre Azure certifié HIPAA (vrai, avec BAA signé avec Microsoft) et ta config conforme HIPAA : c'est à TOI de le prouver.
• Audit ne bloque rien : si l'exigence est « personne ne peut créer un stockage public », il faut un Deny, pas un Audit.
• La purge protection s'active mais ne se désactive plus : en dev ça crée des Key Vaults coincés en soft-delete. Solution : 2 Key Vaults séparés (dev sans, prod avec).

📐 Réf. — Azure Policy regulatory compliance (built-in initiatives) : assigner une initiative built-in (HIPAA HITRUST, ISO 27001, PCI-DSS…) au scope MG pour une compliance continue auditée est la méthode native recommandée. Lien

Scenario 3 : Scale-up SaaS — FinOps & chargeback dev teams

Contexte business : un SaaS B2B de 200 personnes, 15 équipes de dev, paie ~80k€/mois sur Azure et ça grimpe. Le CTO veut refacturer chaque équipe pour les responsabiliser, sans ralentir les livraisons. Choix architectural : Cost Management + tags imposés par Policy + Budgets + Advisor ciblé par équipe. Architecture / pattern :

• Policy Require tag CostCenter / Squad / Environment (effet Deny) sur l'abonnement de prod.
• Héritage de tags activé dans Cost Management : les enregistrements de facturation récupèrent les tags du RG vers la ressource.
• 1 Budget par RG d'équipe (limite mensuelle = quota négocié) + alertes à 50/75/90/100% envoyées sur Teams via un Action Group.
• Advisor : on décoche les RG non-prod pour éviter le bruit, et on se concentre sur le right-sizing et les disques orphelins par équipe.
• Étape 1 : showback (chaque équipe voit ses coûts). Étape 2 : chargeback (refacturation interne) une fois 3 mois de données stables. Trade-offs assumés :
• Gain : chaque équipe responsabilisée sur ses coûts via tags imposés et budgets, sans ralentir les livraisons.
• Perte : les budgets n'arrêtent rien (juste des alertes) et le tagging Deny ajoute une friction au déploiement. Pièges à éviter :
• Lancer le chargeback sans 3 mois de showback propre = conflits internes (« ce n'est pas mon coût ! »).
• Un Budget n'arrête rien, c'est juste une alerte. Pour couper automatiquement : Action Group → Logic App qui désactive le RG (mais risqué en prod).
• Tags posés par Policy Modify : il faut une tâche de remédiation pour les ressources existantes, sinon seules les nouvelles sont taggées.

📐 Réf. CAF — Track costs (FinOps) + WAF Cost optimization : tags enforced par Policy + tag inheritance Cost Management + budgets par équipe + Advisor ciblé suivent la discipline FinOps showback→chargeback recommandée. Lien

DEMO — chemins portail

Management Group

1. Management groups > + Add management group → choisir parent + name + display name
2. Move sub : Management groups > [MG] > Add subscription
3. Assigner Policy/RBAC au scope MG → s'applique à toutes les subs dessous

Tags

1. Resource > Tags > + Add (clé+value) ou en bulk depuis All resources > [select] > Assign tags
2. Tag inheritance Cost Management : Cost Management > Configuration > Tag inheritance > Enable
3. Tag inheritance Policy : assigner la policy built-in Inherit a tag from the resource group (effect Modify)
4. Require tag : assigner Require a tag on resources (effect Deny si absent)

Resource Locks

1. Resource (ou RG / Sub) > Locks > + Add → choisir Type (CanNotDelete / ReadOnly), nom, note
2. Tester : essayer de delete → erreur
3. Pour modifier/supprimer le lock : permission Microsoft.Authorization/locks/*

Cost Management

1. Cost analysis : Cost Management + Billing > Cost analysis → grouper par service / RG / tag / location
2. Créer un budget : Cost Management > Budgets > + Add
   • Scope : Sub / RG / MG
   • Amount + period (monthly/quarterly/annually)
   • Alerts : 50%, 75%, 90%, 100% → email + action group
3. Advisor cost : Advisor > Cost → liste recommandations

Azure Policy

1. Assigner une built-in : Policy > Definitions > [search] > Assign
2. Scope (MG/Sub/RG) + exclusions + parameters
3. Initiative : Definitions > + Initiative definition → group N policies
4. Remediation : Assignments > [assignment] > Create remediation task (si effect = Modify ou DINE)
5. Compliance : Compliance blade → drill-down par scope

ARM / Bicep deployment

# Login + RG
az login
az group create -n myrg -l eastus

# Bicep deployment (incremental par défaut)
az deployment group create \
  -g myrg \
  --template-file main.bicep \
  --parameters @params.json

# What-if (dry run)
az deployment group what-if \
  -g myrg \
  --template-file main.bicep

# Sub-level deployment (créer un RG par exemple)
az deployment sub create -l eastus --template-file rg.bicep

# Compiler Bicep en ARM JSON
az bicep build --file main.bicep

💡 Récupérer le template ARM d'un déploiement existant (utile si qqn d'autre a déployé via ARM, tu veux le réutiliser) :

• Au niveau RG : Resource Group > Settings > Deployments > [deployment] > Template > Download / Add to library
• Au niveau Sub : Subscriptions > Deployments > [deployment] > Template
• Au niveau ressource : Resource > Automation > Export template (mais moins fiable, parfois incomplete)

⚠️ Le template ARM est toujours stocké au niveau du RG/Sub où le déploiement a tourné, jamais au niveau de la ressource individuelle (Storage Account, VM, container, etc.).

Linked templates (ARM)

{
  "type": "Microsoft.Resources/deployments",
  "apiVersion": "2021-04-01",
  "name": "linkedTemplate",
  "properties": {
    "mode": "Incremental",
    "templateLink": {
      "uri": "https://storage.blob.core.windows.net/templates/storage.json"
    }
  }
}

Move resources

1. RG > Move > Move to another resource group ou ... another subscription
2. Cocher les ressources à déplacer (toutes les dépendantes)
3. Validate → confirm
4. RG source/destination locked pendant le move
5. Cross-region : utiliser Resource Mover ou ASR

Key Vault

1. Key vaults > Create
2. Permission model : Azure RBAC (recommandé) ou Vault access policy
3. Soft-delete activé (forcé), Purge protection : à activer pour prod
4. Networking : Public / Selected (Service Endpoint + IP) / Private Endpoint

KV — créer un secret + utiliser depuis VM

1. KV > Secrets > + Generate/Import → name + value
2. Donner à la Managed Identity de la VM le rôle Key Vault Secrets User sur le KV
3. Depuis la VM (CLI Azure) :

az login --identity
az keyvault secret show --vault-name myvault --name mysecret --query value -o tsv

KV — soft-delete + recover

# Lister les KVs supprimés
az keyvault list-deleted

# Recover un KV
az keyvault recover --name myvault

# Recover un secret
az keyvault secret recover --vault-name myvault --name mysecret

# Purge (si purge protection désactivé)
az keyvault purge --name myvault

KV — créer une clé RSA pour CMK (encryption VM/Storage/SQL)

# Prérequis : KV avec Soft-delete + Purge protection ACTIVÉS (obligatoires CMK)
az keyvault create -g myrg -n myvault \
  --enable-rbac-authorization \
  --enable-purge-protection \
  --enable-soft-delete

# Créer la clé RSA (2048/3072/4096) — type RSA obligatoire pour CMK
az keyvault key create --vault-name myvault \
  --name mycmkkey \
  --kty RSA \
  --size 2048 \
  --ops wrapKey unwrapKey encrypt decrypt

# Activer rotation auto (optionnel, recommandé)
az keyvault key rotation-policy update --vault-name myvault --name mycmkkey \
  --value @rotation-policy.json

🚨 Prérequis CMK universels (VM Disk / Storage Account / SQL TDE / etc.) :

1. KV avec Soft-delete ACTIVÉ (default depuis 2020, non désactivable).
2. Purge protection ACTIVÉE (irréversible une fois ON).
3. Clé RSA (pas EC), min 2048 bits.
4. Identité sur la ressource cible (Managed Identity sur SA, Disk Encryption Set sur VM, etc.) avec permissions Get, WrapKey, UnwrapKey sur la clé.

Sans ces 4 → refus de création CMK.

KV — usages typiques par ressource Azure