6 — Storage Security (AZ-500)

Sécuriser un compte de stockage = verrouiller les trois plans (control / data / network), forcer l'identité Entra plutôt que les clés, et protéger la donnée (chiffrement, immutabilité, soft delete, menaces).

A. Modèle d'autorisation : le plan de données avant tout

Cross-ref AZ-104/305 : tu connais le compte, les blobs/files/queues/tables. Angle AZ-500 = qui peut lire/écrire la donnée et avec quelle preuve d'identité. Trois méthodes d'autorisation du data plane, par ordre de préférence sécurité :

🚨 Account key = accès total au compte ET capacité à générer des SAS. La compromission d'une clé = compromission de toute la donnée. 🚨 Les rôles ARM (Owner/Contributor/Storage Account Contributor) ne donnent pas accès data via Entra, MAIS ils incluent listkeys/action → ils peuvent récupérer l'account key et tout lire. Le contrôle « plan de gestion » ≠ « plan de données ».

Authorize access to data — MS Learn · SAS overview

B. RBAC data plane : les rôles à connaître

Distinguer rôles control plane (gèrent la ressource) des rôles data plane (lisent/écrivent la donnée) — c'est un piège classique.

🚨 generateUserDelegationKey (action Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey) est requis pour créer une User Delegation SAS. Les permissions effectives d'une UD-SAS = intersection RBAC du principal ∩ permissions du token SAS.

C. Désactiver Shared Key → forcer Entra

Propriété compte : AllowSharedKeyAccess = false → rejette toute requête signée par account key. Seules les requêtes Entra (et User Delegation SAS, qui est Entra) passent. Service/Account SAS → refusés (basés sur account key).

🚨 Prérequis Conditional Access : pour appliquer une policy CA (MFA, device) au storage, il faut d'abord désactiver Shared Key. Une account key ignore CA. 🚨 Impact Azure Files / Cloud Shell : le portail utilise Shared Key par défaut pour Files ; désactiver sans RBAC correct casse l'accès aux file shares et au Cloud Shell (qui persiste dans un file share). Migrer/autoriser avant. 🚨 AllowSharedKeyAccess est null par défaut → traité comme true. Le « non configuré » n'est PAS « désactivé ».

Prevent Shared Key authorization

D. Access keys du compte : rotation & Key Vault

Deux clés (key1/key2) pour rotation sans coupure : régénérer key2 pendant que les apps utilisent key1, basculer, régénérer key1.

• Si on doit utiliser des clés (connection strings legacy) : les stocker dans Key Vault, jamais en clair / hardcodées.
• Key Vault managed storage account keys (auto-rotation) : KV stocke les deux clés comme versions d'un même secret et régénère automatiquement la clé alternée via Event Grid SecretNearExpiry → Function App (rôle Storage Account Key Operator Service). Zéro-touch.

🚨 La meilleure « gestion de clés » reste de ne pas en avoir : Entra + Managed Identity. KV-managed keys est un palliatif pour les workloads qui exigent une connection string.

Manage storage account keys — protect · Auto-rotation tutorial

E. Azure Files : choisir la méthode d'accès

Files n'est pas Blob : SMB → Kerberos / NTFS, pas RBAC data plane sur les objets. Modèle à deux couches : RBAC share-level (qui monte le share) puis NTFS/Windows ACL (permissions fichier/dossier).

• Share-level RBAC : rôles Storage File Data SMB Share Reader/Contributor/Elevated Contributor, ou default share permission pour tous les authentifiés.
• NTFS : configuré via File Explorer / icacls (AD DS, EDS, Entra Kerberos hybride) ou portail/PowerShell RestSetAcls (Entra Kerberos).
• AES-256 Kerberos requis (AES-128 non supporté). Identity-based non supporté sur shares NFS.

🚨 Hybride : il faut synchroniser users ET groupes (Entra Connect Sync / Cloud Sync) — le share-level se résout contre l'identité Entra, le NTFS contre l'AD DS ; même utilisateur hybride des deux côtés.

Files identity-based auth overview · Assign share-level permissions

F. Réseau : firewall, Private Endpoint, public access

Stratégie : zéro accès public, autoriser de façon incrémentale.

🚨 Créer un Private Endpoint ne bloque pas automatiquement l'endpoint public — il faut explicitement désactiver/firewaller le public. 🚨 AllowBlobPublicAccess=false n'affecte pas le container $web (static site, toujours public). 🚨 Combiner avec un Resource Manager lock (CanNotDelete) : empêche la suppression du compte (pas la donnée).

Storage network security overview · Use private endpoints · Disallow anonymous access

G. Protection de la donnée : soft delete, versioning, immutabilité

Défense contre suppression accidentelle/malveillante et ransomware.

Immutabilité WORM — deux saveurs :

• Container-level WORM : policy au container (time-based + legal hold) ; aucun prérequis.
• Version-level WORM : policy account/container/version ; versioning requis ; précédence Blob → Container → Account.

États time-based retention :

• Unlocked : protège write/delete MAIS modifiable/supprimable → test seulement.
• Locked : conforme SEC 17a-4(f) / FINRA / CFTC ; on peut étendre la rétention, jamais la réduire ni supprimer. Verrouiller < 24 h après test.

🚨 Activer soft delete AVANT les policies d'immutabilité (protection supplémentaire). Un blob déjà soft-deleted sera purgé à expiration malgré WORM. 🚨 WORM incompatible avec point-in-time restore et last-access tracking ; non supporté sur NFS/SFTP ; version-level pas (encore) sur hierarchical namespace (ADLS).

Immutable storage overview · Security recommendations Blob — data protection

H. Chiffrement : SSE, CMK (BYOK), double encryption

Toute donnée at-rest est chiffrée par défaut (SSE, AES-256, FIPS 140-2, Microsoft-managed keys). Angle 500 = qui contrôle la clé.

• CMK : Key Vault + Managed Identity (system/user-assigned) pour que le compte accède à la clé. KV/HSM peut être dans tenant/région/abonnement différent.
• Auto-rotation CMK : si on configure CMK sans préciser la version, Azure prend la nouvelle version sous 24 h (combiner avec KV key autorotation). Si version figée → rotation manuelle.
• Infrastructure encryption = double chiffrement (service + infra, 2 algos, 2 clés). Ne s'active qu'à la création du compte ou de l'encryption scope.

🚨 Prérequis KV pour CMK : soft delete + purge protection activés (sinon perte de clé = perte d'accès donnée). Attendre 24 h avant de désactiver l'ancienne version. 🚨 Disk Encryption (ADE) ne s'applique pas ici — c'est pour les disques VM, pas les comptes de stockage.

Customer-managed keys overview · Infrastructure encryption

I. Microsoft Defender for Storage (détection menaces)

Couche de détection Azure-native (Defender for Cloud). Voir fiche 9 pour Defender for Cloud global.

• Agentless, activable au niveau abonnement (tous comptes) ou par compte ; pas besoin d'activer les resource logs (analyse data + control plane telemetry).
• Activity monitoring : anomalies (IP malicieuses, Tor, SAS compromis/fuités, exfiltration, suppression de masse, blob-hunting).
• Malware scanning (add-on, payant/GB, MDAV) : on-upload + on-demand ; détecte ransomware/virus dans les blobs.
• Sensitive data threat detection : priorise les alertes selon sensibilité (Sensitive Data Discovery / Purview SITs).
• Hash reputation analysis : tous plans, compare hash aux signatures connues (mais pas SMB Files, pas Put Block).

🚨 Defender for Storage détecte, ne prévient pas — il complète (pas remplace) le durcissement (Entra, no-public, WORM). Alertes → Sentinel/SIEM.

What is Defender for Storage

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

Scénario 1 : Bancaire — rétention réglementaire WORM des relevés

Contexte business : Une banque doit garder 7 ans de relevés en « écriture unique » (WORM), prouvable à un auditeur. Même un admin ne doit pas pouvoir les modifier ou les supprimer avant terme. Choix architectural : Verrouiller chaque version du blob en WORM pendant 7 ans, et n'autoriser l'accès que via Entra ID (plus de clés de compte). Architecture / pattern :

• Versioning activé → WORM version-level, rétention 7 ans, policy verrouillée (Locked) après test
• Soft delete activé d'abord : filet contre les suppressions accidentelles avant le verrouillage
• Clés de compte désactivées (AllowSharedKeyAccess=false)
• Accès des apps via Entra ID + Managed Identity Trade-offs assumés :
• Gain : inaltérabilité prouvable à l'auditeur, aucune clé partagée à voler
• Perte : une fois Locked, on ne peut plus réduire la durée ; stockage payé 7 ans Pièges à éviter :
• Verrouiller sans phase de test (Unlocked) : une mauvaise durée devient impossible à corriger
• Oublier le versioning : le WORM version-level en dépend
• Couper AllowSharedKeyAccess avant d'avoir migré les apps vers Entra → apps legacy cassées 📐 Réf. CAF/WAF — WAF Security, service guide Blob Storage : « Protect critical objects: apply immutability policies… for legal, compliance, or other business purposes. » Lien

Scénario 2 : SaaS — storage accessible au backend seul, zéro clé

Contexte business : Un SaaS multi-tenant veut zéro secret et zéro storage exposé sur Internet, mais doit parfois laisser un client télécharger un fichier. Choix architectural : Storage privé (pas d'accès public + Private Endpoint), accès backend par Managed Identity, et téléchargement client par lien temporaire (SAS court). Architecture / pattern :

• Public network access = Disabled + Private Endpoint par service
• Shared Key désactivée → seul Entra ID autorisé
• Backend via Managed Identity + RBAC Storage Blob Data Contributor scopé au conteneur
• Téléchargement client → User Delegation SAS court (+ SAS expiration policy)
• Defender for Storage + scan malware à l'upload des fichiers utilisateurs Trade-offs assumés :
• Gain : aucun secret à gérer, storage invisible depuis Internet, menaces détectées sur les uploads
• Perte : réseau plus complexe (DNS privé, un PE par service), surcoût Defender + scan facturé au Go Pièges à éviter :
• Private Endpoint sans DNS privé correct → la connexion retombe sur l'IP publique, qui est bloquée
• User Delegation SAS basée sur une identité trop large → grosse fuite si le token est volé
• Oublier le PE du bon sous-service (blob, file, dfs) : chacun a son propre endpoint 📐 Réf. CAF/WAF — MCSB Data Protection (security baseline Storage) : DP-2 « Defender for Storage continually analyzes the telemetry stream… security alerts are generated. » Lien

Scénario 3 : Santé — file share hybride + clés du client

Contexte business : Un hôpital migre un file server NTFS. Il veut garder ses droits d'accès AD existants et chiffrer avec ses propres clés (souveraineté). Choix architectural : Azure Files avec authentification AD DS, droits sur deux niveaux (share + NTFS), et chiffrement avec clé client (CMK) + double chiffrement. Architecture / pattern :

• Azure Files AD DS identity-based (Kerberos AES-256)
• Share-level RBAC (qui peut monter le partage) + NTFS ACL (qui accède à quoi), mêmes identités hybrides
• CMK dans Key Vault (soft delete + purge protection), accédée par Managed Identity
• Infrastructure encryption (double chiffrement) activée à la création
• Soft delete du share activé Trade-offs assumés :
• Gain : mêmes droits AD qu'avant, clés maîtrisées et révocables, double chiffrement at-rest
• Perte : si Key Vault tombe ou la clé est révoquée, le share devient inaccessible ; double chiffrement non activable après coup Pièges à éviter :
• Vouloir activer l'infrastructure encryption après création : impossible, c'est à la création du compte
• CMK sans purge protection : une clé supprimée = données irrécupérables
• Confondre share-level RBAC et NTFS ACL → droits effectifs mal calculés 📐 Réf. CAF/WAF — WAF Security, service guide Blob Storage (encryption) : « Consider using your own encryption key… store encryption keys in Key Vault and automatically rotate them. » Lien

DEMO — chemins portail

1. Désactiver Shared Key + anonymous (forcer Entra)

Storage account → Settings › Configuration → Allow Blob anonymous access = Disabled, Allow storage account key access = Disabled → Save. (Vérifier au préalable que les apps utilisent Entra/MI, sinon coupure Files/Cloud Shell.)

2. Verrouiller le réseau (firewall + Private Endpoint)

Storage account → Security + networking › Networking → onglet Firewalls and virtual networks : Public network access = Disabled (ou Enabled from selected networks, cocher Allow trusted Microsoft services) → Save. Puis onglet Private endpoint connections › + Private endpoint → choisir Target sub-resource (blob/file…), VNet/subnet, DNS privé → Create.

3. Activer soft delete + immutabilité WORM

Storage account → Data management › Data protection → cocher Enable soft delete for blobs / containers / file shares (définir rétention) + Enable versioning. Pour WORM : conteneur → Access policy › Add policy (Time-based retention, jours) → tester en Unlocked → Lock policy quand prêt.

4. Chiffrement CMK (BYOK) + infrastructure encryption

À la création : Create storage account → onglet Encryption → Encryption type = Customer-managed keys, sélectionner Key Vault + clé + Managed Identity ; cocher Enable infrastructure encryption (double). (Infra encryption impossible après création.) Sur compte existant : Security + networking › Encryption → CMK uniquement.

5. Activer Microsoft Defender for Storage

Microsoft Defender for Cloud → Environment settings → abonnement → plan Storage = On → Settings : activer Malware scanning (cap GB/mois) + Sensitive data threat detection. Ou par compte : Storage account → Security + networking › Microsoft Defender for Cloud → Enable.