7 — Database Security (AZ-500)

Ensemble des contrôles de sécurité applicatifs d'Azure SQL Database et SQL Managed Instance : authentification Entra, audit, et les trois couches de protection des données (masquage à la présentation, chiffrement at-rest, chiffrement côté client).

A. Microsoft Entra database authentication

Tu connais déjà Entra ID (AZ-104/305). Angle DB : sortir de l'auth SQL (login/mot de passe) pour éliminer les secrets et centraliser RBAC + Conditional Access + MFA sur la base.

🚨 Pièges :

• CONNECT accordé par défaut au user créé, rien d'autre — toute autre permission est explicite. Préférer accorder aux rôles de base de données, pas aux users directement.
• Risque de conflation : un contained user du même nom qu'un login serveur n'hérite pas des permissions du login → comportement indéfini en connexion. Aligner alias login/user.
• L'Entra admin est requis même pour une simple Managed Identity d'app.
• ALTER ANY USER (ou db_owner) nécessaire pour qu'un user Entra puisse en créer d'autres.

B. Database auditing

Trace les événements DB vers un log externe. Sert compliance + investigation (prérequis de l'enquête ATP, section H).

🚨 Pièges :

• LAW/Event Hub → crée une Diagnostic Setting (SQLSecurityAuditEvents). Si elle est supprimée, l'audit échoue silencieusement → poser une alerte sur la suppression.
• Activer server + database audit ensemble = logs en double (sauf besoin spécifique).
• DB-level audit vers LAW/Event Hub non conservé sur database copy, PITR, geo-replication (secondaire sans DB-level audit).
• Optimisé pour la disponibilité : sous charge réseau très forte, des événements peuvent ne pas être enregistrés.

C. Dynamic Data Masking (DDM) — cosmétique

Masquage à la présentation : les données restent en clair en base, seul l'affichage est obfusqué pour les non-privilégiés. Ce n'est PAS du chiffrement.

🚨 Pièges :

• Les admins (sysadmin, db_owner, CONTROL) voient toujours le clair → DDM n'est pas un contrôle d'accès.
• Le masque n'empêche pas l'UPDATE : un user sans UNMASK mais avec write peut écraser la donnée. Garder un access control séparé.
• SELECT INTO/INSERT INTO/export → propage la donnée masquée dans la cible (statiquement masquée).
• Impossible sur colonnes Always Encrypted, computed, FILESTREAM, COLUMN_SET. Cross-DB joins sur colonnes masquées = résultats faux.

D. Transparent Data Encryption (TDE) — at-rest

Chiffre fichiers de données, logs et backups at-rest. Transparent pour l'app (pas de changement de code). Activé par défaut pour toute base créée après 2017.

🚨 Pièges :

• Prérequis Key Vault : soft-delete + purge protection obligatoires (mêmes que pour Disk Encryption — cf. fiches Storage/KV).
• Révoquer la clé / supprimer le KV / casser le réseau (NSG, DNS, private endpoint) → base Inaccessible, toutes données chiffrées illisibles. Délai ~10 min pour propager un changement de permission.
• Suppression d'incident : toujours rotater vers une nouvelle clé et vérifier que toutes les bases l'utilisent avant de supprimer/désactiver la clé compromise.
• master ne peut pas être chiffrée par TDE → ne pas y stocker de données sensibles.
• TDE protège l'at-rest, pas contre un admin DB légitime qui requête (≠ Always Encrypted).

E. Always Encrypted — chiffrement côté client (vrai chiffrement)

Chiffre les colonnes sensibles côté client ; le moteur SQL ne voit jamais le clair ni les clés. Sépare ceux qui gèrent la donnée (DBA, cloud ops) de ceux qui peuvent la voir.

🚨 Pièges :

• Sans enclave, toute (re)chiffrement / changement de type / rotation CEK déplace les données hors base côté client → long, fragile sur grosses tables.
• Activer ADR (Accelerated Database Recovery) avant le premier index sur colonne randomized enclave-enabled (ADR par défaut sur SQL DB/MI).
• DDM incompatible avec colonnes Always Encrypted.
• Always Encrypted protège in-use/at-rest/in-transit côté moteur, mais ne remplace pas TDE (qui couvre fichiers/logs/backups globalement).

F. Distinguer les trois couches 🚨

G. Microsoft Defender for SQL (→ fiche 9)

Pack de sécurité avancé activé en un clic au niveau serveur (toutes bases). Rôle requis : SQL Security Manager. Deux composants :

• Vulnerability Assessment : découvre/suit/remédie les vulnérabilités et misconfigurations. Express config (sans storage account) ou classic (storage account, scans hebdo + rapports email). Baselines comparatives.
• Advanced Threat Protection (ATP) : alertes sur anomalies — SQL injection, accès depuis localisation/principal inhabituel, brute force de credentials. Intégré à Defender for Cloud + Sentinel. Activer l'auditing pour l'expérience d'investigation complète.

Détail dans la fiche 9 (Defender for Cloud).

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

Scénario 1 : SaaS — zéro secret + numéros de carte invisibles

Contexte business : Une app web doit se connecter à SQL DB sans mot de passe en dur, et les numéros de carte ne doivent jamais être lisibles côté Azure (DBA compris). Choix architectural : Connexion via Managed Identity (Entra-only) et chiffrement des colonnes carte côté client avec Always Encrypted, plus TDE CMK pour le reste. Architecture / pattern :

• Entra-only auth + Managed Identity pour l'app (contained user FROM EXTERNAL PROVIDER)
• Colonnes carte en Always Encrypted (randomized + Secure Enclaves), clé en Key Vault
• TDE CMK pour chiffrer toute la base at-rest
• Le DBA gère la base mais ne voit jamais les colonnes en clair Trade-offs assumés :
• Gain : pas de secret de connexion, DBA aveugle aux données sensibles, confidentialité même face au cloud
• Perte : Always Encrypted limite ce qu'on peut faire en SQL (les enclaves aident sans tout couvrir) ; driver client plus complexe Pièges à éviter :
• Chiffrer en randomized une colonne utilisée pour jointure/recherche hors enclave → requêtes impossibles
• Mettre la Column Master Key hors Key Vault ou sans rotation → on perd la séparation
• Oublier d'attester les Secure Enclaves côté client → opérations rejetées 📐 Réf. CAF/WAF — WAF Azure SQL Database service guide (Security) : « Use features like Always Encrypted and Always Encrypted with secure enclaves to protect highly sensitive information… prevent encryption keys from being exposed to the database engine » Lien

Scénario 2 : Compliance — clés maîtrisées et accès révocable

Contexte business : Un audit impose de maîtriser tout le cycle de vie des clés de chiffrement et de pouvoir couper l'accès aux données à tout moment. Choix architectural : TDE avec clé du client (BYOK) stockée dans Key Vault / Managed HSM, accès serveur par identité managée, rotation automatique. Architecture / pattern :

• TDE CMK (BYOK) — clé RSA (TDE protector) dans Key Vault / Managed HSM (soft-delete + purge protection)
• Accès serveur via User-Assigned Managed Identity en RBAC (Key Vault Crypto Service Encryption User)
• Auto-rotation de la clé
• L'admin Key Vault peut révoquer l'accès → la base devient inaccessible (kill switch) Trade-offs assumés :
• Gain : cycle de vie des clés maîtrisé et auditable, coupure immédiate possible, admin DB séparé de l'admin clés
• Perte : une erreur sur la clé (suppression, révocation, purge) rend la base totalement indisponible Pièges à éviter :
• Key Vault sans purge protection : clé supprimée = base irrécupérable
• Gérer la clé par access policies au lieu de RBAC → modèle incohérent et dur à auditer
• Oublier l'auto-rotation alors que la conformité l'exige 📐 Réf. CAF/WAF — MCSB Data Protection (DP-5) : « Use customer-managed key option in data at rest encryption when required » Lien

Scénario 3 : Centre de support — masquer la PII aux agents + tracer les accès

Contexte business : Les agents N1 ne voient que des données masquées, les superviseurs les voient en clair, et chaque accès à la PII doit laisser une trace inaltérable. Choix architectural : Masquage dynamique (DDM) levé seulement pour un groupe Entra superviseur, audit centralisé vers Log Analytics sur stockage immuable, détection d'exfiltration par Defender for SQL. Architecture / pattern :

• DDM (default()/partial()), UNMASK accordé au seul groupe Entra superviseur
• Audit serveur vers Log Analytics (actions SELECT sur les tables sensibles)
• Stockage d'audit immuable (anti-falsification)
• Defender for SQL pour repérer une exfiltration anormale Trade-offs assumés :
• Gain : PII moins exposée au support, traçabilité opposable, détection comportementale des fuites
• Perte : DDM n'est pas une vraie barrière (un agent avec SELECT peut déduire les valeurs) ; surcoût Defender + ingestion logs Pièges à éviter :
• Compter sur DDM seul : sans limiter les privilèges, l'agent peut extraire les valeurs masquées
• Donner UNMASK à un rôle large plutôt qu'à un groupe Entra précis
• Mettre l'audit dans un container non immuable → preuves altérables 📐 Réf. CAF/WAF — Azure security baseline for Azure SQL (Data Protection) : référence MCSB pour DDM, audit et CMK Lien

DEMO — chemins portail

1. Configurer l'Entra admin + Entra-only auth

SQL Server (logical server) → Settings → Microsoft Entra ID → Set admin (choisir un groupe Entra) → Save. Cocher Support only Microsoft Entra authentication for this server pour désactiver l'auth SQL → Save.

2. Activer l'audit serveur vers Log Analytics

SQL Server → Security → Auditing → Enable Azure SQL Auditing : ON → cocher Log Analytics → sélectionner le workspace → Save. (S'applique à toutes les bases du serveur.)

3. Basculer TDE en customer-managed key (BYOK)

SQL Server → Security → Transparent data encryption → Customer-managed key → Select a key (Key Vault avec soft-delete + purge protection) → cocher Auto-rotate key → Save. (Server identity doit avoir l'accès KV en RBAC/policy.)

4. Définir une règle Dynamic Data Masking

SQL Database → Security → Dynamic Data Masking → + Add mask → choisir colonne + masking function → renseigner SQL users excluded from masking (liste minimale) → Save.

5. Activer Microsoft Defender for SQL + Vulnerability Assessment

SQL Server → Security → Microsoft Defender for Cloud → Configure → Enable Microsoft Defender for SQL → activer Vulnerability Assessment (express) → renseigner les emails de rapport → Save.