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 / MGs.

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 (au lieu d'Access Policies historiquement). Les KVs existants ne changent pas.

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.

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

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix techniques (uniquement les services traités dans la fiche) → pièges typiques.

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

Contexte business : groupe industriel FR-DE-US, 12 filiales avec autonomie IT mais besoin de baseline sécu+coût commune (encryption at rest, regions autorisées, tags CostCenter obligatoires). Audit central, billing centralisé, autonomie sub-niveau. Choix techniques : hiérarchie Management Groups 3 niveaux + Policy au scope MG + RBAC inheritance + Cost Management chargeback. Architecture / pattern :

• Tenant Root MG → Corp MG (policies enterprise-wide) → Region MGs (EMEA / NA / APAC) → BU MGs (filiales) → Subs (prod/dev/test par BU)
• Policies au Corp MG : Allowed locations (deny non-EU+US), Require tag CostCenter, Audit encryption at rest → héritées partout
• RBAC : Reader au Root pour les auditeurs (vue cross-tenant), Contributor par BU MG aux IT leads filiales
• Cost Management : tag inheritance activée au scope billing → chargeback mensuel par filiale via CostCenter Pièges à éviter :
• Tags PAS hérités par défaut sur les ressources : penser à la policy Inherit a tag from RG (effect Modify + remediation task)
• Ordre d'héritage Policy : MG > Sub > RG > Resource — le scope le plus restrictif/spécifique gagne sur conflits Deny
• Activer le Tenant Root Group au démarrage (Global Admin → "Access management for Azure resources") sinon impossible de créer une vraie hiérarchie

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

Contexte business : hôpital privé US — PHI (Protected Health Info) sur Azure, audit HHS récurrent. Besoin de prouver compliance HIPAA en continu, pas seulement à l'audit annuel. Choix techniques : Azure Policy initiative built-in HIPAA HITRUST assignée au MG prod + Key Vault Premium HSM pour CMK + Resource Locks sur ressources PHI critiques. Architecture / pattern :

• Initiative HIPAA HITRUST 9.2 assignée au MG Prod-Healthcare → ~600 controls auto-évalués
• Effects : majoritairement Audit pour démarrer + quelques Deny clés (Disable public network access on Storage, Require HTTPS only)
• KV Premium HSM-backed (FIPS 140-2 L2) avec Purge protection LOCKED + soft-delete 90j
• Resource Lock CanNotDelete sur les SAs contenant les imageries DICOM + KV PHI
• Compliance dashboard exposé aux auditeurs (read-only RBAC Reader au scope initiative) Pièges à éviter :
• Confondre certifié HIPAA (Azure l'est, BAA signé avec MS) et compliant HIPAA (ta config — c'est TOI qui dois prouver)
• Audit ≠ enforcement : si exigence = "personne ne peut créer un SA public", il faut Deny, pas Audit
• Purge protection activable mais pas désactivable sur KV → erreurs en dev (KV en boucle infinie soft-deleted) → 2 KVs séparés (dev sans purge protection, prod avec)

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

Contexte business : SaaS B2B 200 personnes, 15 squads dev, facture Azure ~80k€/mois en croissance. CTO veut chargeback par squad pour responsabiliser (sans casser la vitesse delivery). Choix techniques : Cost Management + tag policy enforcement + Budgets + Advisor ciblé par squad. Architecture / pattern :

• Policy Require tag CostCenter / Squad / Environment (effect Deny) au scope sub prod
• Tag inheritance Cost Management activée au billing (records billing récupèrent tags RG→ressource)
• 1 Budget par RG squad (limite mensuelle = quota négocié) + alertes 50/75/90/100% vers Teams via Action Group
• Advisor Configuration : décocher RG non-prod pour éviter le bruit, focus right-sizing + disks orphelins par squad
• Phase 1 : showback (visibilité par squad), Phase 2 : chargeback (refacturation interne) une fois données stables 3 mois Pièges à éviter :
• Démarrer chargeback sans 3 mois de showback propre = guerre interne ("c'est pas mon coût !")
• Budget n'arrête rien : c'est juste une alerte. Pour stop auto → Action Group → Logic App qui désactive le RG (mais dangereux en prod)
• Tags appliqués via Policy Modify : faut remediation task pour les ressources existantes (sinon seules les nouvelles sont taggées)

Scenario 4 : PME — startup en hyper-croissance, IaC discipline

Contexte business : fintech 30 personnes, mono-sub, prod+dev mélangés au début. Vient de lever, doit pro le setup en 3 mois (séparer prod/dev, IaC tout, lock le critique, secrets centralisés). Choix techniques : split en 2 subs via MG, Bicep modules pour IaC repo, Resource Locks sur prod, Key Vault + RBAC pour secrets, Naming convention via Policy. Architecture / pattern :

• MG Fintech-Root → 2 subs : prod-sub (locked, Owner restreint) + dev-sub (Contributor large)
• Repo Bicep avec modules : network.bicep, compute.bicep, kv.bicep → déploiement via az deployment group create en pipeline
• Lock CanNotDelete sur RGs prod + KV prod ; Lock ReadOnly sur KV legal-vault
• KV Premium en RBAC mode (Key Vault Secrets User aux MIs des App Services, Key Vault Administrator à 2 humains max)
• Policy Allowed resource types + naming pattern {type}-{app}-{env}-{region}-{n} (deny si non-conforme) Pièges à éviter :
• Bicep en mode Complete au lieu de Incremental → supprime tout ce qui n'est pas dans le template (catastrophe en prod)
• Lock ReadOnly sur Storage Account → casse certaines apps qui mettent à jour leurs propres settings (bouger en CanNotDelete)
• Migrer du legacy KV Access Policies vers RBAC sans tester : les MI doivent avoir les bons rôles data plane avant la bascule

Sources :

• CAF — Management Groups
• Azure Policy regulatory compliance
• FinOps Chargeback