9 — Data Protection and Security (AZ-305)

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 2 = Standard KV (software) ou Premium KV (HSM-backed)
• FIPS 140-3 Level 3 = Managed HSM (HSM physique dédié) → PCI-DSS HSM, defense, gov

💡 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.

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).

D.bis 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).

E. Storage encryption (rappel + extensions 305)

E.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.

E.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.

E.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.

E.4 Container Access Policy vs Immutable Policy

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

E.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.

F. SAS tokens ⭐

F.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.

F.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).

🎯 Use case design 305 : "plusieurs SAS clients (B2B partners) avec révocation possible par client" → Stored Access Policy (1 policy par client).

⚠️ Distractors exam "révoquer accès à un seul client" :

• RBAC = exige identité Entra (SAS = anonyme, pas Entra)
• ReadOnly lock = bloque TOUTES modifs du SA, pas ciblé
• SAS direct (sans policy) = révocation = rotation storage key → casse tout
• Stored Access Policy ⭐ = LA bonne réponse

💡 Distinct de Immutable Policy (WORM) = empêche modif/delete data (compliance), pas une question d'accès SAS.

F.3 Pièges SAS 305

• 🚨 User Delegation SAS = la moderne. Account SAS / Service SAS sans Stored Policy = legacy.
• 🚨 Account SAS donne accès à tout le compte → dangereux, éviter.
• 🚨 Révoquer un SAS sans Stored Access Policy = rotation storage key (casse tous les autres SAS).

G. VM Encryption ⭐

G.1 Les 4 couches d'encryption VM

G.2 ADE vs Encryption at Host

G.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".

G.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).

G.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).

H. Defender for Cloud — protection data services

H.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

H.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

H.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

H.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

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).