9 — Data Protection and Security

Protéger les données → chiffrement at-rest/in-transit/in-use, gestion des clés (Microsoft-managed vs CMK dans Key Vault), stockage immuable WORM et Confidential VMs : choisir selon confiance, réglementation et menace à couvrir.

A. Vocabulaire encryption

A.1 At-rest / In-transit / In-use

A.2 Qui gère la clé ?

A.3 Key envelope — pourquoi 2 niveaux

• DEK chiffre les data réelles (AES-256) ; KEK / CMK chiffre la DEK (dans KV)
• Rotation KEK = re-chiffrer juste la DEK (pas des millions de rows)

A.4 Types de clés supportés par Key Vault

🎯 Au 305 : CMK = RSA dans 100% des cas concrets (TDE, SSE, Disk Encryption, AE). Si une question propose "EC key" ou "symmetric key" comme CMK → mauvaise réponse.

A.5 Tailles RSA acceptées par service Azure (CMK)

🚨 Piège 305 : RSA 1024 retiré depuis longtemps, ne marche plus. RSA 2048 = minimum partout, 3072 = recommandé pour compliance moderne, 4096 = ultra-strict (perf moindre).

A.6 HSM (Hardware Security Module)

• FIPS 140-2 Level 1 = Standard KV (clés software)
• FIPS 140-3 Level 3 = Premium KV (HSM Marvell, firmware mis à jour) ET Managed HSM (HSM single-tenant dédié) → PCI-DSS HSM, defense, gov
• 🚨 Premium et Managed HSM sont au même niveau FIPS (140-3 L3) : le vrai différenciateur = tenancy/root of trust (Premium = multi-tenant, root MS ; Managed HSM = single-tenant, security domain client + key sovereignty)

💡 Enclave + Attestation (pour Always Encrypted with Secure Enclaves) : zone mémoire isolée où même l'admin Azure ne lit pas ; un attestation provider (Microsoft Azure Attestation) vérifie qu'elle est authentique. Détail = AZ-500.

📚 Azure Key Vault = traité dans la fiche 4 - App Security (section 0). Rappel court pour cette fiche : KV stocke Secrets / Keys / Certificates. 3 variantes (Standard / Premium HSM-backed / Managed HSM). Accès via RBAC (recommandé) ou Access Policies (legacy). Soft-delete + Purge protection obligatoires pour CMK SQL/Storage.

B. Transparent Data Encryption (TDE)

B.1 C'est quoi

Encryption at-rest des fichiers DB + backups + transaction logs. Activé par défaut sur Azure SQL DB / MI / Synapse Dedicated SQL pool. Protège vol disque/backup, pas DBA.

⚠️ TDE ≠ TLS ≠ Always Encrypted (defense in depth) :

• TLS (1.2+) = chiffre connexion réseau (app ⇄ SQL), default PaaS
• TDE = chiffre fichiers sur disque (default ON, AES-256)
• Always Encrypted = chiffre data dans la colonne, déchiffrée côté app uniquement

B.2 Architecture (key envelope)

• DEK (chiffre data) = AES 256 symétrique
• TDE Protector (wrappe DEK) en mode CMK = RSA asymétrique 2048 ou 3072 dans KV / Managed HSM

Prérequis CMK :

• KV avec soft-delete + purge protection activés
• Key RSA 2048 ou 3072, même région que SQL Server
• SQL Server accède via Managed Identity (UMI pour database-level)

B.3 PMK vs CMK

B.4 Pièges TDE 305

• ⚠️ TDE ne protège PAS contre DBA qui SELECT * FROM Patients → pour cacher aux DBAs → Always Encrypted.
• 🚨 KV dans région ≠ SQL server → failover Geo-DR cassé.
• 🚨 TDE Protector révoqué par accident → DB inaccessible.
• 🚨 CMK database-level = UMI obligatoire (System-assigned non supporté à ce niveau).

C. Always Encrypted (AE)

C.1 C'est quoi

Encryption client-side : la DB ne voit jamais la donnée en clair (DBAs Azure inclus). Chiffrement/déchiffrement par driver app, SQL stocke et retourne chiffré. (Ne se fait pas sur Azure mais il faut se connecté a la DB)

[App + driver AE] → chiffre AVANT envoi → [SQL stocke chiffré] → retourne chiffré → [App déchiffre]

C.2 Architecture — 2 clés

C.3 Les 3 variantes

📖 Mémo des 3 modes

• Deterministic = "même valeur → même chiffré". Permet WHERE col = ? mais leak de fréquence si valeurs répétées. → colonnes uniques (SSN, email).
• Randomized = "même valeur → chiffré différent à chaque fois". Sécu max mais aucune query possible. → colonnes lues, jamais filtrées (salaire, notes).
• Secure Enclaves = Randomized + enclave CPU isolée qui déchiffre temporairement pour la query. Sécu max + queries riches (=, <, >, LIKE, ORDER BY). → réponse prod moderne.

C.4 TDE vs AE

C.5 Pièges AE 305

• 🚨 Deterministic + colonne faible cardinalité (genre, statut) → leak fréquence évident.
• 🚨 Sans Secure Enclaves, Randomized = aucune query (WHERE, ORDER BY, JOIN).
• 🚨 CMK perdue / KV purgé → data irrécupérables (même MS ne peut rien).
• 🚨 App sans Column Encryption Setting=Enabled dans conn string → driver ne déchiffre pas.
• 🚨 Secure Enclaves sans attestation provider → handshake refusé, AE bloqué.

D. Dynamic Data Masking (DDM)

D.1 C'est quoi

Masque les données dans résultats query selon user — couche présentation (pas chiffrement). Conformité d'affichage cosmétique, pas vraie sécurité.

D.2 Architecture

• Données stockées en clair (≠ AE)
• Affichage masqué au SELECT pour users sans permission UNMASK
• Users dans SQL users excluded from masking voient en clair
• Perf overhead quasi nul

D.3 Types de masques

D.4 TDE vs AE vs DDM

D.5 Pièges DDM 305

• ⚠️ DDM ≠ vrai chiffrement : pour réelle protection → AE.
• 🚨 DBAs / db_owner voient tout.
• 🚨 Inference attack : WHERE Email LIKE 'a%' retourne lignes même masquées → leak partiel.
• 🚨 Backups / TDE : data en clair dans le fichier (DDM = juste vue applicative).

E. Récap : TDE / AE / DDM sur SQL DB vs MI vs VM

Les 3 features (TDE, AE, DDM) existent sur les 3 plateformes SQL Azure. Mais avec des nuances importantes selon la plateforme.

🎯 Nuances clés 305

TDE

• SQL DB / MI : MS gère, ON par défaut. CMK via clic portail + KV.
• SQL VM : tu actives toi-même comme on-prem. Pour CMK via KV → utiliser EKM (Extensible Key Management) avec KV connector.

Always Encrypted

• Même feature SQL Server partout, pas de différence majeure entre DB/MI/VM.
• Secure Enclaves :
  • SQL DB/MI = MS gère l'enclave hardware
  • SQL VM = besoin VBS enclaves Windows Server 2019+ ou Intel SGX (à toi)

Dynamic Data Masking

• SQL DB / MI : blade Azure portail simple à utiliser.
• SQL VM : pas de blade Azure (c'est ton SQL Server IaaS) → config T-SQL :

  ALTER TABLE Customers ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');
  

🎯 Questions type 305

🎯 TL;DR : Les 3 features existent partout. SQL DB / MI = managé MS, facile (clics portail). SQL VM = à toi de config comme on-prem (plus de flexibilité, plus de boulot, mais control total).

F. Storage encryption (rappel + extensions 305)

F.1 Storage Service Encryption (SSE) — default

• Default ON, gratuit, AES-256. Tous les blobs/files/tables/queues chiffrés au repos.
• Géré par MS (PMK) par défaut. CMK optionnel via KV.

F.2 Encryption Scopes (granularité par container)

• Différent CMK par container/blob dans un même Storage Account.
• Use case : multi-tenant SaaS (1 client = 1 scope = 1 CMK).
• Configuration : Storage Account > Encryption > Encryption scopes.

F.3 Infrastructure encryption (double encryption)

• Active une 2ème couche de chiffrement AES-256 sous le SSE.
• Use case : compliance ultra-stricte (defense, gov), zero-trust hardware.
• Activable à la création seulement, irréversible.

F.4 Container Access Policy vs Immutable Policy

🚨 Une Immutable Policy Locked = définitif (même MS ne peut rien). Tester en Unlocked d'abord.

F.5 Pièges Storage encryption 305

• 🚨 CMK pour Storage : besoin KV avec soft-delete + purge protection (comme SQL TDE).
• 🚨 Infrastructure encryption activable seulement à la création.
• 🚨 Encryption Scopes = granularité per-container/blob, pas per-account.

G. SAS tokens

G.1 Les 3 types

🚨 Précision User Delegation SAS : "user" = l'user Entra qui a généré/signé le SAS, PAS un user autorisé à l'utiliser. Une fois généré, n'importe qui avec l'URL peut s'en servir (comme les autres SAS). Le bénéfice : pas de storage key exposée + audit du signataire + révocation via Entra (désactiver l'user → ses SAS deviennent invalides) + permissions limitées au RBAC de l'user signataire. Expiry max 7 jours.

G.2 Stored Access Policy

• Politique au niveau container Blob (ou file share / queue / table) qui groupe N SAS Service sous une même policy.
• Permet de :
  • Révoquer un SAS (ou groupe de SAS) sans rotation de la storage key → révoque la policy = tous les SAS générés depuis deviennent invalides instantanément
  • Modifier permissions / expiration centralement
• Sans Stored Access Policy → SAS valide jusqu'à son expiry, révocation = rotation storage key (casse TOUS les SAS de tout le compte, impact massif).

H. VM Encryption

H.1 Les 4 couches d'encryption VM

H.2 ADE vs Encryption at Host

H.3 Confidential Computing — awareness 305

• Confidential VMs : RAM chiffrée, AMD SEV-SNP, attestation par Azure Attestation Service.
• DC-series / DCsv3 : SKUs avec Intel SGX (enclaves CPU pour code+data isolés).
• Confidential containers (AKS) : pods isolés via Confidential Computing.
• Use case 305 : workload financier/gov/santé qui demande "data invisible même au cloud provider".

H.4 Trusted Launch

• Pas vraiment "encryption", mais secure boot + vTPM pour VMs Gen2.
• Protège contre rootkits/bootkits.
• Activé par défaut sur nouvelles VMs Gen2 dans portail (2026).

H.5 Pièges VM encryption 305

• 🚨 Encryption at Host > ADE en prod moderne (recommandation MS).
• 🚨 Confidential VMs ≠ encryption at-rest classique → c'est in-use (RAM chiffrée).
• 🚨 ADE nécessite KV configuré pour disk encryption (paramètre spécifique).
• 🚨 Trusted Launch ≠ encryption (anti-rootkit boot-level).

I. Defender for Cloud — protection data services

I.1 Defender for SQL (rappel — détaillé fiche 13)

• Vulnerability Assessment : scan baseline régulier
• Advanced Threat Protection (ATP) : SQL injection, anomalous access, brute force
• Activable per-server ou subscription-level

I.2 Defender for Storage

• Anomalous access : alerte sur patterns suspects (exfiltration, IP étrange)
• Malware scanning (preview/GA selon région) : scan AV sur blobs uploadés
• Sensitive data discovery : détecte PII dans blobs (intégré Purview)
• Activation : Defender for Cloud > Environment settings > Storage : ON

I.3 Defender for Key Vault

• Anomalous access : alerte sur volume inhabituel d'opérations, IP étrange
• Suspicious access patterns : grosse vague de get-secret = signe d'exfiltration
• Activation : Defender for Cloud > Environment settings > Key Vault : ON

I.4 Pièges Defender 305

• 🚨 Subscription-level recommandé : couvre toutes les ressources présentes + futures auto.
• 🚨 Defender for Storage = payant per-storage-account ou per-million-transactions.
• 🚨 Defender for KV essentiel pour détecter exfiltration de secrets.

J. Decision tree AZ-305

Par besoin

Compliance avec own keys (CMK) ?
├─ Standard (HIPAA/PCI typique)  → KV Premium HSM-backed + CMK
└─ Ultra (PCI HSM, defense)      → Managed HSM (FIPS 140-3 L3) + CMK

Données ultra-sensibles invisibles aux DBAs ?
├─ Queries SQL riches            → AE Secure Enclaves 
├─ Simple equality lookups       → AE Deterministic
├─ Lecture brute, no queries     → AE Randomized
└─ Affichage masqué par user     → Dynamic Data Masking (cosmétique)

VM encryption ?
├─ Default at-rest               → SSE managed disks (gratuit, ON)
├─ OS-level compliance           → ADE (BitLocker/DM-Crypt) [legacy]
├─ Prod moderne                  → Encryption at Host 
└─ Workload in-use ultra         → Confidential VMs

Storage encryption ?
├─ Default                       → SSE PMK (ON, gratuit)
├─ CMK compliance                → SSE CMK (KV)
├─ Multi-tenant per-container    → Encryption Scopes
└─ Double encryption gov         → Infrastructure encryption (à la création)

Workload régulé (HIPAA / PCI Level 1) ?
└─ Combo : TDE CMK + AE Secure Enclaves + Defender for SQL + Audit + Private Endpoint

Par data type

Secret app (conn string, API key)    → KV Secrets + Managed Identity
Cert TLS (App Gateway/Front Door)    → KV Certificates + integration AGW/FD
Clé symétrique pour wrap/unwrap      → KV Keys (RSA)
SAS pour blob temporaire             → User Delegation SAS (Entra) 
PII en colonne SQL                   → Always Encrypted
Compliance retention WORM blob       → Immutable Policy Locked

K. Scénarios 305 → solution

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

Scénario 1 : Banque d'investissement — Archivage anti-ransomware conforme SEC 17a-4

Contexte business : Un broker-dealer doit garder 7 ans les confirmations de trades dans un format non modifiable (SEC 17a-4(f), FINRA 4511, CFTC 1.31). Menaces visées : un ransomware qui chiffre/supprime les archives, ou un admin malveillant qui détruit le compte de stockage. Choix architectural : Blob Storage (tier Cool/Archive) avec Immutable Policy time-based retention en mode Locked (WORM, écrire une fois, ne plus modifier) + soft-delete + infrastructure encryption (double couche AES-256). Locked = personne ne peut supprimer avant l'échéance, pas même un admin. Architecture / pattern :

• Container dédié, rétention Locked ≥ 7 ans → écriture OK, modif/suppression bloquées même pour Owner/admin
• Soft-delete activé AVANT la policy d'immutabilité (filet de sécurité supplémentaire)
• Écriture en append blob + allowProtectedAppendWrites pour les logs en flux continu
• Defender for Storage ON pour alerter sur les anomalies (exfiltration, suppression massive) Trade-offs assumés :
• Gain : vraie protection ransomware (donnée non supprimable même avec une clé de compte volée) + preuve de conformité
• Perte : une policy Locked est irréversible (impossible de raccourcir la rétention ou de supprimer avant l'échéance) → stockage payé jusqu'au bout ; tester en Unlocked d'abord Pièges à éviter :
• Locker avant la fin des tests → définitif, même Microsoft ne peut rien faire
• Appliquer le WORM sur un page blob de VHD actif → écritures bloquées (réservé aux block/append blobs)
• Croire qu'on peut supprimer le compte : un container Locked bloque aussi la suppression du storage account 📐 Réf. WAF — Azure Blob Storage / Data protection : configurer redondance + protections d'immutabilité pour durabilité et conformité ; le WAF recommande explicitement immutable storage pour les exigences légales/réglementaires. Lien

Scénario 2 : Santé (HIPAA) — TDE CMK + Always Encrypted avec séparation des devoirs

Contexte business : Un SaaS santé stocke des dossiers patients en Azure SQL Database. HIPAA exige : chiffrement at-rest avec des clés contrôlées (et révocables) par le client, ET que personne côté DBA — même Microsoft — ne voie le SSN/diagnostic en clair. Choix architectural : TDE en mode CMK (clé RSA dans Key Vault Premium) pour un chiffrement at-rest révocable, complété par Always Encrypted with Secure Enclaves sur les colonnes ultra-sensibles. Deux couches : TDE protège tout le fichier, Always Encrypted cache les colonnes même au DBA. Architecture / pattern :

• Key Vault Premium (HSM) avec soft-delete + purge protection ; clé RSA 3072 (TDE accepte seulement 2048/3072)
• SQL Server avec identité managée → rôle Key Vault Crypto Service Encryption User ; clé TDE dans la même région que le serveur
• Always Encrypted Secure Enclaves sur SSN/Diagnosis : enclave hardware managée MS + attestation, requêtes riches (=, <, LIKE) possibles
• DDM côté présentation pour le helpdesk (masquage cosmétique), à ne pas confondre avec un vrai chiffrement Trade-offs assumés :
• Gain : séparation des rôles (admin données ≠ admin clés) ; révoquer la clé coupe l'accès ; colonnes AE vraiment invisibles au DBA
• Perte : si KV purgé ou clé perdue → DB inaccessible (TDE) et colonnes AE irrécupérables (même Microsoft) ; surcoût et complexité driver côté AE Pièges à éviter :
• KV dans une région ≠ SQL Server → géo-DR cassé
• Oublier Column Encryption Setting=Enabled (et Attestation Url= pour les enclaves) dans la conn string → déchiffrement KO
• Clé RSA 4096 pour le TDE protector → non supporté (TDE = 2048/3072 seulement) 📐 Réf. CAF — Secure methodology / Adopt confidentiality (CIA Triad) : appliquer strong encryption (CMK) + access controls sur les data stores régulés, avec TDE en couche additionnelle. Lien

Scénario 3 : Défense / Aérospatiale — Données ITAR « invisibles au cloud provider »

Contexte business : Un sous-traitant défense traite des données techniques export-controlled (ITAR) sur des VMs. Exigence : la donnée doit rester chiffrée même pendant son traitement (en RAM), inaccessible à l'opérateur cloud, avec une preuve cryptographique (attestation). Choix architectural : Confidential VMs (DCasv5/ECasv5 AMD SEV-SNP ou DCesv6 Intel TDX) avec confidential OS disk encryption liée au vTPM + Encryption at Host pour les disques de données, clés CMK en Managed HSM (FIPS 140-3 Level 3). Les Confidential VMs chiffrent la mémoire au niveau matériel → l'hyperviseur et les admins ne la voient pas. Architecture / pattern :

• Confidential VM SEV-SNP : chiffrement de la mémoire en hardware, isolée de l'hyperviseur/host/admins
• Confidential disk encryption (clé liée au vTPM) + Trusted Launch (Secure Boot + vTPM) pour l'intégrité du boot (anti-rootkit)
• CMK en Managed HSM (single-tenant, contrôlé par le client) pour le besoin HSM dédié gov/defense
• Attestation hardware via Azure Attestation avant déverrouillage Trade-offs assumés :
• Gain : protection "in-use" (le vrai différenciateur vs at-rest) + attestation prouvable + isolation vis-à-vis de Microsoft
• Perte : choix de SKUs limité (familles DC/EC), coût plus élevé, pas dans toutes les régions ; Managed HSM cher (cluster dédié) Pièges à éviter :
• Confondre Confidential VM (chiffre la RAM, in-use) et SSE/Encryption at Host (at-rest seulement) → ne couvre pas "invisible pendant le traitement"
• Croire que Trusted Launch = chiffrement : c'est de l'intégrité de boot (anti-rootkit), pas du chiffrement de données
• Prendre Key Vault Premium en pensant avoir un HSM "dédié" → Premium est multi-tenant ; pour du single-tenant → Managed HSM 📐 Réf. WAF — Security pillar / Encrypt data in use (SE:07) : pour workloads haute sécurité, le WAF recommande confidential computing + attestation pour le chiffrement in-use dans des frontières hardware. Lien

DEMO

Demo Portail — Activer une Managed Identity sur une VM/App Service

System-assigned (SAMI) :

1. VM/App Service > Settings > Identity
2. Toggle System assigned : On → Save → un Object ID Entra est généré
3. Utiliser cet Object ID pour assigner un rôle (ex Key Vault Secrets User sur le KV)

User-assigned (UMI) :

1. Create a resource > Managed Identity > + Create → name umi-prod, RG, region
2. Assigner cette UMI à une ressource : VM > Identity > User assigned > + Add > umi-prod
3. Donner les rôles RBAC à l'UMI (pas à la VM) sur les ressources cibles

💡 Mémo : SAMI lié à la VM (supprimé si VM supprimée), UMI indépendante (survit, réutilisable).

Demo Portail — TDE CMK (Customer Managed Key) au Server level

1. Créer Key Vault :
   • Key Vaults > + Create
   • Basics tab : RG, Key vault name mysqlkv, Region = même que SQL Server, Pricing tier Standard (ou Premium HSM-backed)
   • Access configuration tab : Permission model = Azure RBAC
   • Recovery options : Soft-delete Enabled + Purge protection ON (irréversible, obligatoire CMK)
   • Review + create
2. Créer la key RSA :
   • mysqlkv > Objects > Keys > + Generate/Import
   • Generate, Name MyTDEKey, Key type RSA, RSA key size 3072 (ou 2048) → Create
3. Activer Managed Identity sur SQL Server :
   • SQL Server > Settings > Identity
   • System assigned managed identity > Status : On → Save
4. Donner le rôle au SQL Server sur KV :
   • mysqlkv > Access control (IAM) > + Add > Add role assignment
   • Role : Key Vault Crypto Service Encryption User → Next
   • Members : Assign access to = Managed identity → + Select members → SQL server → mysrv-demo → Select
   • Review + assign
5. Configurer TDE CMK :
   • SQL Server > Security > Transparent data encryption
   • Toggle Customer-managed key ON
   • Change key → KV mysqlkv → key MyTDEKey → version (ou versionless) → Select
   • (Optionnel) Make this key the default TDE protector + Auto-rotate key
   • Save

Pour TDE CMK au database level : à la création de la DB > Security tab > Configure transparent data encryption > Database level CMK (UMI obligatoire, System-assigned non supporté à ce niveau).

Demo Portail / SSMS — Always Encrypted

⚠️ Always Encrypted nécessite SSMS / Azure Data Studio pour générer CEK et chiffrer les colonnes (opération client-side). Le portail Azure ne crée que la CMK dans Key Vault + les permissions.

Étape 1 — Créer la Column Master Key dans Key Vault (Portail)

1. Key Vaults > mysqlkv > Objects > Keys > + Generate/Import
2. Generate, Name CMK1, Key type RSA, RSA key size 3072 (ou 2048) → Create
3. Donner au user qui lance le wizard le rôle Key Vault Crypto Officer sur le KV

Étape 2 — Wizard SSMS

1. Ouvrir SSMS ou Azure Data Studio > connecter à la SQL DB (auth Entra)
2. Clic droit DB > Tasks > Encrypt Columns…
3. Column Selection : cocher colonnes + choisir Encryption Type (Deterministic / Randomized) + Encryption Key (CEK_Auto1 généré auto)
4. Master Key Configuration : Azure Key Vault > sign in > sub + KV mysqlkv + key CMK1
5. Run Settings : Proceed to finish now → Finish (génère CMK + CEK + alter colonnes)
6. Côté app : ajouter Column Encryption Setting=Enabled à la connection string

Pour Secure Enclaves : ajouter Attestation Url=https://... dans connection string + activer enclave côté server.

💡 Au 305 tu n'as pas à coder le DDL T-SQL ni le code .NET. Le wizard SSMS suffit pour comprendre + savoir que c'est implémenté côté client.

Demo Portail — Dynamic Data Masking

1. SQL databases > mydb > Security > Dynamic Data Masking
2. Le portail liste les Recommended fields to mask (auto-détection email, credit card, name) → cliquer Add mask sur chaque suggestion
3. Ou cliquer + Add mask pour un mask manuel :
   • Schema : dbo
   • Table : Customers
   • Column : Email
   • Masking field format :
     • Default value (0, xxxx) : selon type
     • Credit card value : XXXX-XXXX-XXXX-1234
     • Email : [email protected]
     • Random number (range min-max, numérique seulement)
     • Custom string : partial(prefix, "padding", suffix), ex partial(0,"XXX-XXX-",4) → XXX-XXX-1234
   • Add
4. SQL users excluded from masking : list ;-separated des admins/analytics qui voient en clair
5. Save en haut de la blade
6. Test : SELECT depuis un user non-exempt → data masquée ; depuis un user exempt ou avec GRANT UNMASK → data en clair

Demo Portail — Storage CMK avec KV

1. Pré-requis : KV avec soft-delete + purge protection, key RSA, Storage Account
2. Storage Account > Settings > Encryption
3. Encryption key type : Customer-managed keys
4. Encryption key : Select from Key Vault → choisir KV + key
5. Identity : System-assigned managed identity du Storage Account (auto activée)
6. Vérifier rôle RBAC : SA MI a Key Vault Crypto Service Encryption User sur le KV
7. Save

Demo Portail — User Delegation SAS

1. Storage Account > Data storage > Containers > [container] > Shared access tokens (n'utilise PAS la storage key)
2. Signing method : User delegation key (Entra-based)
3. Permissions : Read, List, etc.
4. Start/expiry : durée
5. Allowed IP addresses + Allowed protocols (HTTPS only)
6. Generate SAS token and URL → token signé par Entra (pas par storage key)

💡 Avantage User Delegation SAS : audit user Entra, révocable via désactivation user, jamais d'exposition de storage key.

Demo Portail — Encryption at Host (VM)

1. VM > + Create
2. Basics : config standard
3. Disks > Encryption type : Encryption at host (toggle visible si feature subscription registered)
4. Review + create

Pré-requis subscription : Set-AzProviderFeature -ProviderNamespace "Microsoft.Compute" -FeatureName "EncryptionAtHost" (une fois par sub).