12 — Comparatif SKU / plans / options (AZ-500)
Fiche transversale : tous les choix de SKU, plans et options chiffrés qui tombent en QCM, avec la différence discriminante et quand choisir. Consolide les fiches 1, 3-10. Mode cours, dense.
A. Key Vault — Standard vs Premium vs Managed HSM
| KV Standard | KV Premium | Managed HSM | |
|---|---|---|---|
| Tenancy | Multitenant | Multitenant | Single-tenant (dédié) |
| Compliance | FIPS 140-2 L1 | FIPS 140-3 L3 | FIPS 140-3 L3 |
| Clés | Software | Software + HSM-backed | HSM uniquement |
| Root of trust | Microsoft | Microsoft | Client (security domain) |
| RBAC data plane | ARM RBAC / access policy | ARM RBAC / access policy | RBAC local enforcé par le HSM (isolé du control plane ARM) |
La différence : Premium et Managed HSM sont tous deux FIPS 140-3 L3 → le discriminant n'est PAS le niveau FIPS mais la tenancy (single vs multi) + le contrôle du root of trust / security domain par le client. Quand choisir : Standard = secrets/certs courants (software). Premium = besoin de clés HSM-backed restant en vault multitenant. Managed HSM = isolation single-tenant, contrôle total du security domain, séparation control plane ↔ accès clés (donner du management plane ≠ accès aux clés). 🚨 Security domain à télécharger immédiatement après provisioning (quorum ≥3 holders) — sa perte = perte définitive des clés.
B. Defender for Cloud — CSPM : Foundational (gratuit) vs Defender CSPM (payant)
| Capacité | Foundational CSPM (gratuit) | Defender CSPM (payant) |
|---|---|---|
| Secure score, recommandations MCSB | ✅ | ✅ |
| Asset inventory, multicloud insight | ✅ | ✅ |
| DevOps security (connecteurs) | ✅ | ✅ |
| Attack path analysis | ❌ | ✅ |
| Cloud security explorer (graph queries) | ❌ | ✅ |
| Agentless scanning (machines) | ❌ | ✅ |
| Security governance (governance rules) | ❌ | ✅ |
| DSPM (Data Security Posture Mgmt) | ❌ | ✅ (ou Defender for Storage) |
| CIEM (permissions management) | ❌ | ✅ |
| AI-SPM / AI BOM | ❌ | ✅ |
| EASM | ressource Azure distincte (pas un simple plan CSPM) |
La différence : Foundational = posture de base + score gratuit (MCSB par défaut). Defender CSPM = analyse proactive du risque (attack path, graph, agentless, CIEM). 🚨 Agentless scanner exige que le Subscription Owner active Defender CSPM, sinon attack path & security explorer restent vides. Custom recommendations KQL exigent Defender CSPM (Azure Policy-based = gratuit).
C. Defender for Servers — Plan 1 vs Plan 2
| Fonctionnalité | P1 | P2 |
|---|---|---|
| Intégration MDE (EDR / Defender for Endpoint P2) | ✅ (auto) | ✅ |
| Vulnerability assessment (MDVM core) | ✅ | ✅ + premium MDVM |
| Agentless scanning (posture, vuln, malware, secrets) | ❌ | ✅ (par défaut) |
| JIT VM access | ❌ | ✅ |
| FIM (File Integrity Monitoring) | ❌ | ✅ (à activer, pas auto) |
| OS config assessment vs baselines MCSB | ❌ | ✅ |
| Compliance assessment réglementaire | ❌ | ✅ |
| Free data ingestion 500 MB/jour | ❌ | ✅ |
| Facturation | par heure | par heure |
La différence : P1 = essentiellement EDR (MDE) + VA de base. P2 = ajoute tout l'agentless + posture + JIT + FIM + premium MDVM. Quand choisir : P2 dès qu'on veut JIT, FIM, ou agentless scanning (cf. scénarios « réduire surface d'attaque »). 🚨 FIM PAS activé par défaut même en P2 → à configurer. MDE et VA core sont auto. Essai 30 j non extensible. P1 n'ouvre PAS la compliance réglementaire (≥1 plan payant « complet » requis).
D. Plans Defender (vue d'ensemble — ce que chacun protège)
| Plan | Protège | À retenir |
|---|---|---|
| Servers | VM Azure / Arc (on-prem, AWS, GCP) | P1 EDR vs P2 (JIT/FIM/agentless) |
| Storage | Blob, Files, ADLS | Activity monitoring + malware scan on-upload (par GB) + sensitive data |
| Databases | Azure SQL DB, SQL on VM/Arc, OSS RDB (PG/MySQL/MariaDB), Cosmos (NoSQL only) | SQLi, brute force, exfiltration ; 4 offres facturées séparément |
| Containers | AKS / ACI / ACA + registres ACR | Sensor runtime eBPF + scan registry + agentless + admission gating |
| Key Vault | Accès anormaux aux secrets/clés | Détecte enum/exfiltration de secrets |
| App Service | Web apps | Détecte exploits, reconnaissance |
| Resource Manager | Plan de contrôle ARM | Opérations suspectes (élévation, masse) |
| DNS | Requêtes DNS (legacy → intégré Servers) | Tunneling, comm C2, crypto-mining |
| APIs | APIM | API non authentifiées, endpoints inutilisés >30 j ; Plan 1 n'ouvre PAS la compliance |
| AI | Workloads IA (Foundry / OpenAI) | Prompt injection, abus (cf. SC-500) |
🚨 Tous = CWPP (détection/alertes runtime), distinct du CSPM (posture). Activables au niveau souscription (recommandé) ou ressource.
E. Microsoft Sentinel — pricing & log plans
Pricing d'ingestion
| Modèle | Logique | Quand |
|---|---|---|
| Pay-As-You-Go | Facturé au GB ingéré | Volume faible/imprévisible |
| Commitment tiers | Engagement de volume/jour (100 GB, 200 GB…) à tarif réduit | Volume stable et élevé → économie |
Log plans (table Log Analytics)
| Plan | Requêtable | Rétention | Coût / usage |
|---|---|---|---|
| Analytics | ✅ KQL complet, alimente les règles analytiques | jusqu'à 2 ans (+ archive) | Le plus cher ; logs de détection/corrélation |
| Basic | KQL limité (pas d'alertes analytiques en continu) | rétention courte | Logs verbeux à valeur de troubleshooting |
| Auxiliary | KQL très limité, requêtes ad-hoc | rétention longue à bas coût | Logs volumineux peu interrogés (compliance, forensics) |
La différence : Analytics = logs « chauds » exploités par les détections (le plus cher). Basic/Auxiliary = logs « tièdes/froids », moins chers, mais pas dans les règles analytiques continues. 🚨 Sentinel n'a pas de stockage propre : rétention/RBAC/coûts = ceux du LAW. Tout ingérer en Analytics tier sans Basic/Archive → facture qui explose.
F. Chiffrement — LE comparatif clé AZ-500
F.1 — Storage / au repos
| Option | Couvre | Clé | Quand |
|---|---|---|---|
| SSE (défaut) | Toute donnée at-rest (AES-256, FIPS 140-2) | Microsoft-managed (PMK) | Toujours actif, gratuit, zéro config |
| CMK / BYOK | Idem at-rest, clé contrôlée par le client | Key Vault / Managed HSM + Managed Identity | Audit, révocation, rotation, conformité |
| Infrastructure encryption (double) | 2e couche AES-256 (2 algos, 2 clés) | Microsoft (clé séparée) | Conformité exigeant double chiffrement — à activer à la création |
🚨 CMK exige KV avec soft-delete + purge protection. Infra encryption impossible après création du compte.
F.2 — VM / disques
| Option | Couvre | Clé | Prérequis / note |
|---|---|---|---|
| SSE (managed disks) | OS + data disks at-rest. PAS temp disk/cache | PMK ou CMK via Disk Encryption Set (DES) | Toujours actif, gratuit. SSE seul → Defender Unhealthy |
| Encryption at Host | + temp disks + caches, flux Compute↔Storage chiffré | PMK (temp) / CMK via DES (OS/data) | Recommandé (n'utilise pas le CPU VM). Activer VM désallouée |
| ADE (BitLocker / dm-crypt) | OS + data (volume-level, dans la VM) | KEK dans Key Vault | Utilise le CPU VM. En dépréciation — retraite 15 sept 2028 → migrer vers EaH |
| Confidential disk encryption | OS disk lié au vTPM de la Confidential VM | CMK via DES | Contenu accessible uniquement à la VM ; clés bypass hyperviseur/host |
La différence : SSE ne couvre pas le temp/cache ; EaH = SSE + temp/cache + flux, sans coût CPU. ADE chiffre dans l'OS (BitLocker/dm-crypt, coûte du CPU) et est en fin de vie. 🚨 EaH ≠ ADE (piège classique). ADE incompatible avec EaH ou SSE+CMK sur la même VM. CMK requiert DES (SSE/EaH/Confidential) ou KEK (ADE).
F.3 — SQL — TDE vs Always Encrypted vs DDM vs RLS
| DDM | TDE | Always Encrypted (AE) | RLS | |
|---|---|---|---|---|
| Nature | Cosmétique (présentation) | Chiffrement at-rest | Chiffrement côté client | Filtre de lignes |
| Donnée en base | En clair | Chiffrée (fichiers/logs/backups) | Chiffrée (colonnes) | En clair |
| Moteur SQL voit le clair ? | Oui | Oui (en mémoire) | Non, jamais | Oui |
| Protège contre admin DB ? | Non | Non (admin requête le clair) | Oui | Non (limite les lignes vues, pas le contenu) |
| Granularité | Colonne | Base entière | Colonne | Ligne (prédicat) |
| Perf | Nulle (affichage) | Quasi nulle (transparent) | Lourde : randomized = pas de search/index hors enclave ; deterministic = =/join/index |
Légère (filtre au query) |
| Usage | Limiter affichage non-privilégiés | Compliance at-rest, vol fichiers/backup | PII/PCI ultra-sensible, séparation des rôles | Multi-tenant, cloisonner par tenant/user |
La différence : DDM masque l'affichage (pas une barrière). TDE protège contre le vol de fichiers/backup (pas contre l'admin). AE = seul à protéger contre l'admin DB (moteur aveugle). RLS limite quelles lignes un user voit. 🚨 AE ≠ TLS : AE chiffre la donnée elle-même côté client (in-use/at-rest/in-transit côté moteur) ; TLS ne chiffre que le transport. AE ne remplace pas TDE. DDM incompatible avec colonnes AE. TDE/AE CMK exigent KV soft-delete + purge protection.
G. Accès Storage — Access keys vs SAS vs Entra RBAC
| Méthode | Secret | Révocation | Identité | Verdict 500 |
|---|---|---|---|---|
| Entra ID + RBAC (OAuth) | Aucun (token) | Retrait de rôle | Entra (user/MI/app) | ✅ Préféré |
| User-delegation SAS | Clé de délégation Entra-backed | Révoquer la user-delegation key | Entra | ✅ Le plus sûr des SAS |
| Service / Account SAS | Account key | Stored Access Policy ou régén clé | Aucune (clé) | ⚠️ Basé account key |
| Shared Key (account key) | Account key | Régén clé seulement | Aucune | 🚨 Accès total au compte |
| Anonymous / public blob | Aucun | — | — | 🚨 Désactiver (sauf $web) |
La différence / quand : RBAC = pas de secret, révocable par retrait de rôle → défaut. User-delegation SAS = quand un SAS est imposé (lien temporaire client) : signée par Entra donc révocable + auditable, contrairement aux SAS basés account key. Account key = accès total et capacité à générer des SAS → à désactiver (AllowSharedKeyAccess=false).
🚨 Désactiver Shared Key est un prérequis pour appliquer une Conditional Access au storage (une account key ignore CA). UD-SAS = intersection RBAC du principal ∩ permissions du token.
H. Entra ID — Free vs P1 vs P2
| Fonctionnalité | Free | P1 | P2 |
|---|---|---|---|
| User/group mgmt, SSO, MFA (basic via Security Defaults) | ✅ | ✅ | ✅ |
| Conditional Access | ❌ | ✅ | ✅ |
| Dynamic groups, self-service group mgmt, App Proxy, SSPR (write-back on-prem) | ❌ | ✅ | ✅ |
| Entra custom roles | ❌ | ✅ | ✅ |
| Identity Protection (risk-based CA, sign-in/user risk) | ❌ | ❌ | ✅ |
| PIM (JIT, eligible roles, approbation) | ❌ | ❌ | ✅ |
| Access Reviews | ❌ | ❌ | ✅ |
| Entitlement Management | ❌ | ❌ | ✅ (capacités avancées → Entra ID Governance) |
La différence : P1 = Conditional Access + admin avancée. P2 = ajoute le risk-based (Identity Protection) + la gouvernance des privilèges (PIM, Access Reviews, Entitlement). Quand choisir : P1 dès qu'on veut de la CA conditionnelle. P2 dès qu'on veut PIM (JIT admin), risque adaptatif, ou access reviews. 🚨 Security Defaults (gratuit) ⇄ CA mutuellement exclusifs. Risk-based CA = P2 (signaux ID Protection) ; CA simple = P1.
I. Réseau sécu (rappel court)
Azure Firewall — Basic / Standard / Premium
| SKU | Ajoute |
|---|---|
| Basic | NAT/Network/App rules, Threat Intel (alert), IP Groups |
| Standard | + DNS proxy/custom DNS, Web Categories (FQDN), TI alert + deny |
| Premium | + TLS Inspection, IDPS (signatures, Alert / Alert+deny), URL filtering, Web Categories (URL complète) |
🚨 IDPS « Alert seul » ne bloque pas → Zero Trust = Alert and deny. URL filtering complet exige TLS inspection (CA dans Key Vault).
Azure Bastion — Developer / Basic / Standard / Premium
| SKU | IP publique | Spécifique |
|---|---|---|
| Developer | Non (infra partagée) | Dev/test, 1 VM, pas de peering, gratuit |
| Basic | Oui | Dédié, fixe |
| Standard | Oui | Native client, IP-Connect, custom ports, file transfer, disable copy/paste |
| Premium | Non (private-only) | Session recording + déploiement private-only |
🚨 Session recording = Premium uniquement. Private-only et Developer se choisissent à la création (pas de downgrade). Subnet AzureBastionSubnet ≥ /26 (sauf Developer).
WAF — Detection vs Prevention
| Mode | Comportement |
|---|---|
| Detection | Évalue et logge les matches, ne bloque pas → phase de tuning |
| Prevention | Bloque quand anomaly score ≥ 5 (1 règle Critical suffit) |
🚨 Toujours déployer en Detection → analyser logs/exclusions → Prevention. App Gateway WAF_v2 = CRS/OWASP régional (body jusqu'à 2 Mo) ; Front Door = DRS managé global (body 128 Ko seulement).
DDoS — IP Protection vs Network Protection
| DDoS IP Protection | DDoS Network Protection | |
|---|---|---|
| Modèle | par IP publique | par plan (jusqu'à 100 IP / tenant) |
| Tuning adaptatif, mitigation L3/4 | ✅ | ✅ |
| DDoS Rapid Response (DRR) | ❌ | ✅ |
| Cost protection | ❌ | ✅ |
| WAF discount (App Gateway v2) | ❌ | ✅ |
Règle de décision : <15 IP publiques → IP Protection (per-IP plus économique) ; ≥15 IP ou besoin DRR/cost protection/WAF discount → Network Protection. 🚨 Front Door a son propre DDoS intégré. Infrastructure protection (gratuite) protège la plateforme, pas tes ressources.
🚨 Pièges / réflexes sécu AZ-500
- KV RBAC vs access policy : RBAC = control + data plane, PIM, deny assignments, octroi réservé à Owner/UAA ; access policy (legacy) = data plane only, Contributor peut s'auto-élever → préférer RBAC (défaut API 2026-02-01+).
- MI system-assigned vs user-assigned : system = liée au cycle de vie de la ressource, 1:1, location immuable ; user-assigned = réutilisable multi-ressources, recommandée pour TDE/CMK et ACR pull (survit à la recréation).
- SAS user-delegation = le plus sûr car Entra-backed (révocable, auditable), contrairement aux SAS basés account key.
- Encryption-at-host ≠ ADE : EaH chiffre temp/cache/flux sans coût CPU et est recommandé ; ADE = BitLocker/dm-crypt dans l'OS, coûte du CPU, retraite 15 sept 2028.
- AE ≠ TLS : Always Encrypted chiffre la donnée côté client (moteur aveugle) ; TLS ne protège que le transport. AE ≠ TDE (ne le remplace pas).
- TDE ≠ protection anti-admin : l'admin DB requête toujours le clair ; seul AE l'en empêche.
- DDM n'est pas un contrôle d'accès : sysadmin/db_owner voient le clair, et un user avec write peut écraser une valeur masquée.
- P2 requis pour JIT / FIM (Defender for Servers) ; P2 Entra requis pour PIM / Identity Protection / Access Reviews ; P1 Entra pour Conditional Access.
- Defender CSPM (payant) ≠ Foundational CSPM (gratuit) : attack path, security explorer, agentless, CIEM, DSPM = payants.
- Premium ET Managed HSM = FIPS 140-3 L3 : le discriminant est la tenancy (single-tenant + security domain client), pas le niveau FIPS.
- CMK partout exige KV soft-delete + purge protection (Storage, VM/DES, SQL TDE) — clé perdue = données irrécupérables.
- Sentinel = pas de stockage propre : coûts/rétention/RBAC = ceux du LAW ; choisir Basic/Auxiliary tier pour les logs verbeux peu requêtés.