04 · Sécuriser les Azure Storage accounts

Version : 1.2 · Date : 2026-10-21 · Domaine 2 de l'examen : Stockage sécurisé, bases de données et mise en réseau (25 à 30 %)

En une phrase : un storage account se protège en couches : l'identité (Entra ID et rôles « Data » plutôt que la clé partagée), le réseau (accès public désactivé, private endpoints), le chiffrement (customer-managed key), la protection des données (soft delete, versions, WORM) et la détection (Defender for Storage).

Ce que l'examen demande#

Repris mot pour mot du guide d'étude SC-500, version anglaise (rubrique Implémenter la sécurité pour les storage accounts) :

1. Les bases à maîtriser avant tout#

1.1 Un compte, quatre services, deux plans#

Un storage account (en pratique StorageV2, usage général v2) regroupe quatre services de données, chacun avec son point de terminaison : Blob (<compte>.blob.core.windows.net, et dfs pour Data Lake Storage), Files (file), Queues (queue) et Tables (table).

Comme toute ressource Azure, il a deux plans d'accès, et c'est la base de presque toutes les questions sur le stockage :

Le piège n° 1 : Owner, Contributor et Storage Account Contributor ne donnent pas accès aux données par Entra ID. Mais ils contiennent l'action Microsoft.Storage/storageAccounts/listkeys/action : avec les clés du compte, on lit toutes les données par la Shared Key. D'où la recommandation : désactiver la Shared Key et attribuer des rôles « Data » au plus juste.

1.2 Les six façons d'autoriser une requête#

Les Microsoft Purview protection policies (sensitivity labels appliquées aux blobs et à Data Lake Storage) sont une méthode complémentaire, en préversion.

2. Les paramètres de sécurité du compte#

2.1 Les réglages à connaître par cœur#

2.2 La méthode « DRAG » de Microsoft pour couper un accès hérité#

Microsoft recommande la même démarche pour désactiver la Shared Key ou relever la version TLS : Détecter, Remédier, Auditer, Gouverner.

flowchart LR
    D["Détecter<br/>Métriques Transactions<br/>filtrées par Authentification<br/>+ journaux StorageBlobLogs"] --> R["Remédier<br/>migrer les clients vers Entra ID<br/>puis AllowSharedKeyAccess = false"]
    R --> A["Auditer<br/>Azure Policy en Audit<br/>« Les storage accounts doivent<br/>empêcher l'accès à la Shared Key »"]
    A --> G["Gouverner<br/>même stratégie en Deny<br/>(application en 30 min max)"]

Requête pour trouver les clients qui utilisent encore la clé ou une SAS (journaux envoyés dans Log Analytics par un paramètre de diagnostic) :

StorageBlobLogs
| where AuthenticationType in ("AccountKey", "SAS") and TimeGenerated > ago(7d)
| summarize count() by CallerIpAddress, UserAgentHeader, AccountName
| top 10 by count_ desc

Inventaire rapide de tous les comptes avec Azure Resource Graph (lecture seule) :

resources
| where type =~ 'Microsoft.Storage/storageAccounts'
| extend allowSharedKeyAccess = parse_json(properties).allowSharedKeyAccess,
         allowBlobPublicAccess = parse_json(properties).allowBlobPublicAccess,
         minimumTlsVersion = parse_json(properties).minimumTlsVersion
| project subscriptionId, resourceGroup, name, allowSharedKeyAccess, allowBlobPublicAccess, minimumTlsVersion

Attention avant de désactiver la Shared Key : certains outils l'utilisent encore. Le portail accède aux partages Azure Files par la clé si l'on n'a pas de rôle RBAC adapté, Cloud Shell stocke ses fichiers dans un Azure file share, et Terraform crée conteneurs et blobs par la clé sauf si storage_use_azuread = true dans le bloc provider.

2.3 Mise en œuvre#

Azure CLI (à lancer dans un abonnement de test) :

az storage account update --name stcontosoprd --resource-group rg-data-prd \
  --https-only true \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --allow-shared-key-access false \
  --public-network-access Disabled

Terraform (fournisseur azurerm 5.x, arguments vérifiés dans la documentation du registre) :

resource "azurerm_storage_account" "data" {
  name                              = "stcontosoprd"
  resource_group_name               = azurerm_resource_group.data.name
  location                          = azurerm_resource_group.data.location
  account_tier                      = "Standard"
  account_replication_type          = "ZRS"
  https_traffic_only_enabled        = true
  min_tls_version                   = "TLS1_2"
  allow_nested_items_to_be_public   = false    # accès anonyme aux blobs
  shared_access_key_enabled         = false    # exige storage_use_azuread = true dans le provider
  default_to_oauth_authentication   = true
  cross_tenant_replication_enabled  = false
  public_network_access             = "Disabled"
  infrastructure_encryption_enabled = true     # double chiffrement, seulement à la création

  sas_policy {
    expiration_period = "00.01:00:00"          # 1 heure, format JJ.HH:MM:SS
    expiration_action = "Block"
  }

  blob_properties {
    versioning_enabled  = true
    change_feed_enabled = true
    delete_retention_policy { days = 14 }
    container_delete_retention_policy { days = 14 }
    restore_policy { days = 7 }                 # inférieur à la suppression réversible
  }
}

3. Le chiffrement des données#

3.1 Au repos : toujours actif#

Toutes les données (blobs, fichiers, queues, tables, disques, métadonnées) sont chiffrées par le chiffrement côté service (SSE) en AES-256 (mode GCM), conforme FIPS 140-2, quel que soit le niveau de performance, d'accès ou de redondance. Il est impossible à désactiver et sans surcoût.

3.2 Qui gère la clé#

Ce qu'il faut savoir sur la CMK :

• elle n'est pas la clé qui chiffre les données : elle enveloppe (wrap) la clé de chiffrement du compte ; changer de clé ou de version ne rechiffre pas les données et ne coupe pas le service ;
• le compte accède au Key Vault par une managed identity : affectée par l'utilisateur à la création du compte, affectée par l'utilisateur ou par le système pour un compte existant ; autorisations minimales get, wrapKey, unwrapKey (rôle Key Vault Crypto Service Encryption User avec le modèle RBAC du Key Vault) ;
• exigences du Key Vault : soft delete et purge protection activées, clé RSA ou RSA-HSM de 2048, 3072 ou 4096 bits ;
• Key Vault et compte peuvent être dans des abonnements, régions et locataires différents (CMK multilocataire) ;
• version omise dans l'URI de la clé = mise à jour automatique : le stockage vérifie une fois par jour (attendre 24 h avant de désactiver l'ancienne version) ; version précisée = mise à jour manuelle ;
• révoquer : désactiver la clé dans le Key Vault ; lectures et écritures échouent alors en 403 ;
• Azure Policy propose des stratégies intégrées pour exiger la CMK sur les comptes et sur les encryption scopes.

3.3 Aller plus loin dans le chiffrement#

• Infrastructure encryption (double chiffrement) : une seconde couche AES-256 au niveau de l'infrastructure, avec un autre algorithme et une autre clé (toujours gérée par Microsoft). Se choisit à la création du compte (ou d'un encryption scope).
• Encryption scopes : une clé (Microsoft ou client) par conteneur ou par blob, pour séparer les données de plusieurs clients dans un même compte. Un conteneur peut imposer son encryption scope par défaut (--prevent-encryption-scope-override true). Un encryption scope se désactive mais ne se supprime pas.
• Client-side encryption : chiffrer avant l'envoi avec les bibliothèques Blob et Queues ; utiliser la version 2 (AES-GCM), la version 1 (CBC) n'est plus recommandée.
• En transit : HTTPS obligatoire, TLS 1.2 minimum, SMB 3.x avec chiffrement pour Azure Files.

4. Gérer l'accès aux données#

4.1 Microsoft Entra ID et les rôles « Data »#

Points d'examen :

• étendue possible : conteneur, compte, resource group, abonnement, management group ;
• délai de propagation des attributions : jusqu'à 10 minutes habituellement (jusqu'à 30 minutes, beaucoup plus au niveau d'un management group) ;
• pour naviguer dans le portail avec Entra ID, il faut aussi le rôle Reader (plan de contrôle) sur le compte ;
• un resource lock ReadOnly bloque listKeys (opération POST) : les utilisateurs doivent alors passer par Entra ID.

Attribute-based access control (ABAC) : on ajoute une condition à une attribution de rôle sur les blobs, par exemple « lire seulement les blobs dont le blob index tag Projet = Cascade », « seulement dans le conteneur contoso et le chemin uploads/* », ou « seulement via un private endpoint ». Une condition affine un rôle, elle ne crée pas de refus explicite.

# Attribuer Storage Blob Data Reader limité aux blobs étiquetés Projet = Cascade (exemple de condition ABAC)
# En PowerShell, chaque $ de la condition se préfixe d'un accent grave (`)
$condition = "((!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'} AND NOT SubOperationMatches{'Blob.List'})) OR " +
             "(@Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Projet<`$key_case_sensitive`$>] StringEquals 'Cascade'))"
New-AzRoleAssignment -ObjectId "<id-objet-groupe>" -RoleDefinitionName "Storage Blob Data Reader" `
  -Scope "/subscriptions/<sub>/resourceGroups/rg-data-prd/providers/Microsoft.Storage/storageAccounts/stcontosoprd" `
  -Condition $condition -ConditionVersion "2.0"

4.2 Les clés d'accès du compte#

• Deux clés (key1, key2) pour tourner sans interruption : basculer les applications sur la seconde, régénérer la première, et ainsi de suite.
• Régénérer une clé invalide les service SAS et de compte signées avec elle (pas les user delegation SAS).
• Key expiration policy (keyExpirationPeriodInDays, « Set rotation reminder » dans le portail) : un rappel, pas un blocage ; il faut avoir fait tourner chaque clé au moins une fois (keyCreationTime renseigné). Contrôle avec la stratégie intégrée « Les clés de storage account ne doivent pas être expirées ».
• Si la clé est inévitable : la stocker dans Key Vault et la récupérer à l'exécution, jamais dans le code.

4.3 Les shared access signatures (SAS)#

Une SAS est un jeton ajouté à l'URL d'une ressource : il dit quelles ressources, quelles autorisations et pendant combien de temps. Le stockage ne garde aucune trace des SAS émises : on ne peut ni les lister ni auditer leur création.

Règles importantes :

• la user delegation key vaut 7 jours maximum ; une user delegation SAS ne vit jamais au-delà ;
• pour obtenir la clé, il faut l'action .../blobServices/generateUserDelegationKey (rôle Storage Blob Delegator ou un rôle « Data ») ; la SAS ne donne jamais plus que les droits de celui qui l'a créée ;
• stored access policy : définie sur un conteneur, une table, une queue ou un partage, 5 au maximum ; la SAS de service en hérite (début, fin, autorisations) ; la supprimer, la renommer ou mettre sa fin dans le passé révoque toutes les SAS liées ;
• une service SAS sans stored access policy ne peut pas être révoquée (sauf en tournant la clé) : Microsoft conseille alors une validité d'une heure ou moins ;
• SAS expiration policy du compte (sasExpirationPeriod, format JJ.HH:MM:SS, action Log ou Block) : concerne les SAS de service et de compte ; au-delà, avertissement et journalisation, ou blocage ;
• toujours HTTPS (spr=https), heure de début 15 minutes dans le passé (décalage d'horloge), droits minimaux, champ sip pour limiter à une adresse IP (la SAS ne contourne pas le firewall).

sequenceDiagram
    participant App as Application (managed identity)
    participant Entra as Microsoft Entra ID
    participant Blob as Blob Storage
    participant Client as Client externe
    App->>Entra: Demande un jeton OAuth
    Entra-->>App: Jeton d'accès
    App->>Blob: Get User Delegation Key (rôle Storage Blob Delegator)
    Blob-->>App: User delegation key (7 jours max)
    App->>App: Signe la SAS (lecture seule, 1 h, HTTPS)
    App-->>Client: URL + SAS
    Client->>Blob: GET blob?sv=…&se=…&sig=…
    Blob-->>Client: 200 si signature, droits du créateur et firewall valides

Créer une user delegation SAS en lecture seule sur un conteneur, avec ses identifiants Entra :

az storage container generate-sas --account-name stcontosoprd --name rapports \
  --permissions r --expiry 2026-10-22T12:00Z --https-only \
  --auth-mode login --as-user

Révoquer toutes les user delegation SAS d'un compte :

Revoke-AzStorageAccountUserDelegationKeys -ResourceGroupName rg-data-prd -StorageAccountName stcontosoprd

flowchart TD
    A["Une SAS a fuité"] --> B{"Type de SAS ?"}
    B -- "User delegation SAS" --> C["Révoquer les user delegation keys<br/>du compte"]
    B -- "Service SAS" --> D{"Liée à une<br/>stored access policy ?"}
    D -- Oui --> E["Supprimer ou modifier<br/>la stratégie"]
    D -- Non --> F["Régénérer la clé qui l'a signée<br/>(invalide toutes ses SAS)"]
    B -- "Account SAS" --> F

4.4 Data Lake Storage : RBAC, ABAC puis ACL#

Avec l'hierarchical namespace (Data Lake Storage), on ajoute des ACL de type POSIX (lecture R, écriture W, exécution X) sur les répertoires et fichiers. Elles ne s'appliquent qu'aux identités Entra du même locataire, pas à la Shared Key ni aux service SAS ou account SAS.

flowchart TD
    A["Requête d'une identité Entra"] --> B{"Un rôle Azure donne<br/>l'accès demandé ?"}
    B -- Oui --> C{"Conditions ABAC ?"}
    C -- "Aucune" --> OK["Accès accordé"]
    C -- "Toutes vérifiées" --> OK
    C -- "Une non vérifiée" --> D
    B -- Non --> D{"Les ACL POSIX<br/>donnent l'accès ?"}
    D -- Oui --> OK
    D -- Non --> KO["Accès refusé"]

Conséquences :

• une ACL ne peut pas restreindre ce qu'un rôle Azure accorde déjà (le rôle est évalué d'abord) ;
• pour lire un fichier par ACL seule, il faut X sur la racine et sur chaque répertoire du chemin, puis R sur le fichier ;
• les ACL par défaut ne s'appliquent qu'aux éléments créés après leur définition ;
• 32 entrées d'ACL par fichier ou répertoire : utiliser des groupes.

4.5 Azure Files et les identités#

• Une seule source d'identité par compte, pour tous ses partages ; Kerberos doit être activé dans les paramètres SMB.
• Deux niveaux d'autorisation : niveau partage = rôle Azure RBAC (SMB Share Reader, Contributor, Elevated Contributor) et niveau fichier = ACL NTFS Windows. Le plus restrictif s'applique.
• Default share-level permission : une permission pour tous les utilisateurs authentifiés (utile si les identités ne sont pas synchronisées, pour les comptes ordinateurs ou les gMSA) ; elle vaut None au départ.
• Pas d'authentification par identité pour les partages NFS ; une managed identity peut aussi accéder en SMB sans clé.

5. Azure Storage firewall et réseau#

5.1 Les modes de public network access#

5.2 Les quatre types de règles#

Points clés :

• le firewall ne remplace pas l'autorisation : une requête autorisée par le réseau doit encore être authentifiée ;
• une SAS limitée à une IP (sip) n'ouvre pas le firewall ;
• pour la reprise après sinistre, préparer des VNet dans la région jumelée avec leurs règles (accès RA-GRS).

5.3 Les private endpoints#

Un private endpoint donne au compte une adresse IP privée du VNet, une par sub-resource (blob, dfs, file, queue, table, web, et leurs _secondary). Le trafic reste sur le réseau Microsoft. Sa création ne bloque pas le public endpoint : il faut aussi désactiver l'accès public ou restreindre le firewall.

Le DNS fait tout : stcontoso.blob.core.windows.net est un CNAME vers stcontoso.privatelink.blob.core.windows.net, résolu en IP privée depuis les VNet liés à la zone privée, en public IP ailleurs. Les applications gardent la même chaîne de connexion (ne jamais utiliser le nom privatelink directement). En local : redirecteur conditionnel vers Azure DNS ou Azure DNS Private Resolver. Les détails réseau sont au chapitre 06.

5.4 Complément AZ-500 : service endpoint policies#

Une service endpoint policy s'applique à un sous-réseau qui a un service endpoint Microsoft.Storage : elle limite la sortie vers une liste de storage accounts précis (par compte, resource group ou abonnement), contre l'exfiltration. Plusieurs stratégies sur un sous-réseau s'additionnent ; elles ne filtrent pas le trafic venant du local.

5.5 Le network security perimeter (NSP)#

Un network security perimeter est une frontière logique autour de ressources PaaS (stockage, SQL, Key Vault…) : les membres communiquent entre eux, le reste du trafic public est bloqué sauf règles d'accès entrantes et sortantes. Mode Transition (anciennement apprentissage : retombe sur le firewall du compte) puis mode Enforced (même les trusted services sont bloqués sans règle explicite).

# Restreindre le compte aux réseaux choisis, avec un sous-réseau et une IP publique
az storage account update -g rg-data-prd -n stcontosoprd --default-action Deny --bypass AzureServices
az storage account network-rule add -g rg-data-prd --account-name stcontosoprd \
  --vnet-name vnet-app-prd --subnet snet-app
az storage account network-rule add -g rg-data-prd --account-name stcontosoprd --ip-address 203.0.113.10

6. La protection des données#

L'immutable storage (WORM : écrire une fois, lire plusieurs fois) :

• time-based retention : 1 jour à 146 000 jours (400 ans) ; on peut créer et lire, ni modifier ni supprimer ;
• legal hold : jusqu'à levée explicite, avec des balises (numéro d'affaire) ;
• une stratégie déverrouillée sert aux tests (durée modifiable, stratégie supprimable) ; verrouillée, elle est conforme SEC 17a-4(f), CFTC 1.31(d), FINRA : durée allongeable (5 fois au plus pour une stratégie de conteneur), jamais réductible, stratégie impossible à supprimer ; Microsoft conseille de verrouiller en moins de 24 h ;
• container-level WORM (sans prérequis) ou version-level WORM (au niveau compte, conteneur ou version, blob versioning requis) ;
• même un administrateur ne peut pas supprimer un blob protégé ; un conteneur ou un compte avec WORM ne se supprime que vide.

7. Defender for Storage#

7.1 Ce qu'il fait#

Microsoft Defender for Storage est un plan de Defender for Cloud qui protège Blob, Azure Files et Data Lake Storage, sans agent et sans activer les journaux de diagnostic (il lit lui-même la télémétrie des plans de contrôle et de données) :

Le Malware Scanning en détail :

• tous les types de fichiers, archives ZIP et RAR comprises, jusqu'à 50 Go par fichier ;
• plafond par défaut 10 000 Go par mois et par compte (alertes à 75 % et à 100 %) ; -1 = illimité ;
• résultats : blob index tags (No threats found, Malicious, Error, Not scanned + heure ; non infalsifiables, jamais seul contrôle), alertes Defender for Cloud, Event Grid, table StorageMalwareScanningResults dans Log Analytics ;
• réponses : soft delete automatique intégrée, blocage par ABAC des fichiers non analysés ou malveillants, quarantaine par Logic App (sur alerte) ou Function (sur événement Event Grid) ;
• non pris en charge : comptes v1, blobs d'ajout et de pages, client-side encryption (la CMK est prise en charge), NFS 3.0, analyse au chargement pour Azure Files ;
• ressources créées : une Event Grid system topic (à ne pas supprimer) et une ressource StorageDataScanner à managed identity, ajoutée aux resource instances du firewall du compte pour analyser même si l'accès public est restreint.

7.2 Activer et régler#

• Niveau abonnement (recommandé) : tous les comptes existants et futurs (protection des nouveaux comptes sous 24 h) ; niveau compte pour des réglages particuliers.
• À grande échelle : Azure Policy intégrée (méthode recommandée par Microsoft), IaC (Terraform, Bicep, ARM), PowerShell, API REST.
• Exclure ou personnaliser un compte : sur le compte, Microsoft Defender for Cloud > Paramètres > « Remplacer les paramètres Defender for Storage de l'abonnement », puis désactiver ou changer le plafond.
• Droits : Security Admin suffit pour la activity monitoring ; le Malware Scanning et la détection des données sensibles demandent Owner de l'abonnement (ou un rôle personnalisé avec les actions de création d'attributions de rôles), car le service crée des attributions pour son identité.
• L'ancien plan Defender for Storage (classic), facturé à la transaction, est à migrer vers le plan actuel (prix par compte, plus d'éventuels frais pour les comptes à très fort volume de transactions).

# Activer le plan sur l'abonnement (analyse des malwares et données sensibles activées par défaut)
Set-AzSecurityPricing -Name "StorageAccounts" -PricingTier "Standard" -SubPlan "DefenderForStorageV2"

# Compte particulier : remplacer les réglages de l'abonnement, plafond à 5 000 Go par mois
Update-AzSecurityDefenderForStorage `
  -ResourceId "/subscriptions/<sub>/resourceGroups/rg-data-prd/providers/Microsoft.Storage/storageAccounts/stcontosoprd" `
  -IsEnabled -OverrideSubscriptionLevelSetting -OnUploadIsEnabled -OnUploadCapGbPerMonth 5000 -SensitiveDataDiscoveryIsEnabled

8. Journaliser et surveiller#

• Diagnostic settings par service (blob, file, queue, table) : catégories StorageRead, StorageWrite, StorageDelete, vers Log Analytics (tables StorageBlobLogs, StorageFileLogs, StorageQueueLogs, StorageTableLogs), un storage account ou Event Hubs. Ils indiquent le type d'autorisation de chaque requête (OAuth, clé, SAS, anonyme) et la version TLS.
• Métriques : Transactions filtrées par Authentification (clé du compte, SAS, OAuth) pour mesurer l'usage de la clé.
• Activity log : les opérations du plan de contrôle (listKeys, regenerateKey, modification du firewall).
• Alertes Azure Monitor sur ces requêtes ; envoi des alertes Defender vers Microsoft Sentinel (chapitre 11).
• Azure Policy : stratégies intégrées utiles pour le stockage, à auditer puis à imposer :
  • Storage accounts should prevent shared key access ;
  • Les storage accounts doivent avoir la Minimum TLS version spécifiée ;
  • Les clés de storage account ne doivent pas être expirées ;
  • stratégies qui exigent la CMK, qui configurent la Blob soft delete et des conteneurs, et qui déploient Defender pour le stockage.

9. Labs conseillés#

À faire dans un abonnement de test, avec un storage account jetable.

Lab 1 · Couper la Shared Key sans rien casser

1. Créer un compte, un conteneur et un blob ; s'attribuer Storage Blob Data Contributor sur le compte.
2. Lister le blob avec az storage blob list --auth-mode key, puis --auth-mode login : les deux marchent.
3. Passer AllowSharedKeyAccess à false et relancer les deux commandes.
4. Attendu : --auth-mode key échoue (403), --auth-mode login marche toujours ; une service SAS générée avant échoue aussi.

Lab 2 · Les trois SAS et leur révocation

1. Créer une stored access policy sur le conteneur, puis une service SAS liée à elle, et une user delegation SAS (--as-user --auth-mode login).
2. Ouvrir les deux URL dans un navigateur : le blob s'affiche.
3. Supprimer la stored access policy : la service SAS échoue. Lancer Revoke-AzStorageAccountUserDelegationKeys : la SAS de délégation échoue à son tour.

Lab 3 · Firewall et private endpoint

1. Passer le compte en « selected networks » sans règle : l'accès depuis votre poste échoue (403 AuthorizationFailure).
2. Créer une VM dans un VNet, un private endpoint blob et la zone privatelink.blob.core.windows.net liée au VNet.
3. Depuis la VM : nslookup <compte>.blob.core.windows.net renvoie une IP privée ; l'accès aux données marche.
4. Désactiver l'accès public : votre poste reste bloqué, la VM fonctionne.

Lab 4 · Defender for Storage et fichier de test

1. Activer Defender for Storage sur le compte avec le Malware Scanning au chargement.
2. Téléverser le fichier de test EICAR (chaîne publique, inoffensive).
3. Attendu : blob index tag Malicious sur le blob et alerte dans Defender for Cloud après quelques minutes.

Lab 5 · Immuabilité et soft delete

1. Activer le soft delete (7 jours) et le blob versioning ; supprimer un blob puis le restaurer.
2. Poser une stratégie de rétention déverrouillée d'un jour sur un conteneur et tenter de supprimer un blob : refus.
3. Supprimer la stratégie (possible car déverrouillée) ; ne pas la verrouiller sur un compte de test que l'on veut supprimer.

10. Les pièges d'examen#

11. Scénarios d'entraînement#

1. Contoso veut que plus aucune application n'utilise les clés du compte stfinance, sans rien casser. Démarche ?

Détecter avec la métrique Transactions filtrée sur Authentification et la requête StorageBlobLogs (types AccountKey, SAS) ; remédier en passant les applications sur Entra ID (managed identity + rôle Data) et les SAS en user delegation SAS ; désactiver la Shared Key (AllowSharedKeyAccess = false) ; auditer (Audit) puis refuser (Deny) avec Azure Policy.

2. Une application web hébergée dans App Service doit écrire dans un conteneur factures, et seulement celui-là. Solution ?

Managed identity sur l'App Service, rôle Storage Blob Data Contributor à l'étendue du conteneur factures (ou au compte avec une condition ABAC sur le nom du conteneur). Aucune clé, aucune SAS.

3. Un partenaire doit déposer des fichiers pendant 48 h. L'équipe sécurité veut pouvoir couper l'accès immédiatement.

user delegation SAS en écriture (w, c) sur le conteneur, expirée à 48 h (sous les 7 jours), HTTPS ; en cas de problème, révoquer les user delegation keys. Si une service SAS était imposée : l'adosser à une stratégie d'accès stockée.

4. Des VM d'un VNet de production et des serveurs locaux reliés par ExpressRoute (peering privé) doivent accéder au compte ; Internet doit être exclu.

Private endpoints (blob, et file si besoin) dans le VNet, zone privatelink.blob.core.windows.net liée au VNet, redirecteur conditionnel des DNS locaux vers Azure DNS Private Resolver, puis Public network access : Disabled.

5. Après avoir activé « selected networks », les sauvegardes Azure Backup et les journaux de diagnostic d'un autre service échouent.

Ajouter l'exception « Allow Azure services on the trusted services list to access this storage account » (ou, plus fin, une règle d'instance de ressource pour la ressource concernée).

6. Une banque doit garder des journaux de transactions 10 ans sans modification possible, même par un Global Administrator.

Immutable storage : stratégie de time-based retention de 3 650 jours, testée déverrouillée puis verrouillée rapidement ; activer aussi le soft delete et un resource lock sur le compte.

7. Le RSSI veut chiffrer les données avec une clé qu'il contrôle et pouvoir tout rendre illisible en cas de compromission.

CMK dans un Key Vault avec soft delete et purge protection, clé RSA 3072, managed identity affectée par l'utilisateur avec Key Vault Crypto Service Encryption User, URI sans version (rotation automatique). Pour tout couper : désactiver la clé (les opérations échouent en 403).

8. Une plateforme reçoit des fichiers d'utilisateurs anonymes sur le web. Comment éviter qu'elle diffuse des malwares ?

Defender for Storage avec Malware Scanning au chargement ; plafond mensuel adapté ; une condition ABAC empêche la lecture des blobs non marqués No threats found, et une Function abonnée à Event Grid met les fichiers malveillants en quarantaine.

9. Les postes Windows sont joints à Entra ID uniquement ; les utilisateurs sont synchronisés depuis AD DS. Ils doivent ouvrir un Azure file share avec leurs droits NTFS habituels.

Activer Microsoft Entra Kerberos sur le compte, attribuer les rôles SMB Share aux groupes au niveau du partage, garder les ACL NTFS ; exclure l'application du storage account des stratégies MFA de Conditional Access.

10. Un auditeur demande la preuve que plus aucune requête n'utilise TLS 1.0 ou 1.1.

Diagnostic setting vers Log Analytics, puis StorageBlobLogs | where TimeGenerated > ago(30d) | summarize count() by TlsVersion, CallerIpAddress (colonne TlsVersion) ; enfin MinimumTlsVersion = TLS1_2 et la stratégie Azure Policy de TLS minimal en mode Deny.

12. Pour aller plus loin (au-delà de l'examen)#

• Complément AZ-500 · AzCopy et Storage Explorer avec Entra ID : azcopy login (ou azcopy login --identity sur une VM à managed identity, ou la session Azure CLI avec AZCOPY_AUTO_LOGIN_TYPE=AZCLI) ; il faut un rôle Data, être propriétaire du compte ne suffit pas. Le Storage Explorer accepte Entra ID pour Blob, Queues, Tables et Data Lake, mais pas pour Azure Files.
• Complément AZ-500 · Redondance : LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS ; les données sont chiffrées dans les deux régions ; un customer-managed failover réinitialise le point de restauration le plus ancien de la PITR.
• Object replication et routing preference (réseau Microsoft ou Internet) : à interdire entre locataires si non nécessaire.
• Local users (SFTP) : authentification par mot de passe ou clé SSH, permissions au niveau conteneur ; à désactiver (local_user_enabled = false) si inutile.
• Microsoft Purview protection policies sur les blobs (préversion) : autoriser ou refuser selon le sensitivity label ; lien avec la DSPM du chapitre 07.
• Clés dans Key Vault, rotation automatique : le chapitre 02 détaille la rotation des clés et des secrets (y compris le modèle à deux clés pour les storage accounts).

13. Fiche à retenir#

• Plan de contrôle ≠ plan de données ; listKeys = accès total ; rôles Storage Blob Data … pour les données, Reader en plus pour le portail.
• Méthode recommandée : Entra ID + managed identity ; SAS si nécessaire : user delegation SAS (7 jours max, révocable).
• service SAS + stored access policy (5 max) = révocable ; account SAS = rotation de clé seulement.
• Shared Key désactivée : service SAS et account SAS refusées, user delegation SAS acceptée ; requise pour le Conditional Access.
• HTTPS obligatoire, TLS 1.2 minimum, accès anonyme désactivé (le compte l'emporte sur le conteneur).
• SSE AES-256 toujours actif ; CMK = Key Vault/Managed HSM, soft delete + purge protégée, RSA 2048/3072/4096, managed identity (get, wrapKey, unwrapKey), version omise = rotation auto.
• Infrastructure encryption et CMK queues/tables : à la création ; encryption scopes par conteneur ou blob.
• Azure Storage firewall : selected networks (Deny) ; règles VNet (service endpoint), IP (publiques), resource instances, trusted services ; 400 règles max par type.
• Private endpoint : un par sub-resource, private DNS zone privatelink.<service>.core.windows.net, même chaîne de connexion, ne ferme pas le public.
• Service endpoint = tout le service ; service endpoint policy contre l'exfiltration ; NSP Transition puis Enforced.
• Soft delete blob/conteneur/partage 1 à 365 jours ; versions ; PITR (3 prérequis, durée < soft delete).
• WORM : time-based retention (1 jour à 400 ans) ou legal hold ; verrouillée = SEC 17a-4(f), jamais réductible.
• Resource lock = protège le compte, pas les données ; Recovery of a deleted storage account sous 14 jours.
• Azure Files : une source d'identité (AD DS, Entra DS, Entra Kerberos) ; RBAC partage + NTFS, le plus restrictif.
• Data Lake : RBAC → ABAC → ACL ; une ACL ne retire pas ce que donne un rôle.
• Defender for Storage : sans agent ni journaux ; activité, données sensibles (gratuit), malwares (au Go, 50 Go/fichier, 10 000 Go/mois par défaut) ; niveau abonnement + remplacement par compte ; pas de on-upload scanning pour Azure Files.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Guide d'étude de l'examen SC-500
• Recommandations de sécurité pour le Blob Storage
• Autoriser l'accès aux données dans le Stockage Azure
• Autoriser l'accès aux blobs avec Microsoft Entra ID
• Choisir comment autoriser l'accès aux données blob dans le portail Azure
• Empêcher l'autorisation avec Shared Key
• Appliquer une version minimale de TLS
• Migrer vers TLS 1.2 pour le Blob Storage
• Corriger l'anonymous read access aux données blob
• Gérer les clés d'accès du storage account
• Accorder un accès limité avec des shared access signatures (SAS)
• Créer une user delegation SAS (API REST)
• Configurer une stratégie d'expiration pour les SAS
• Conditions d'attribution de rôle Azure pour le Blob Storage (exemples)
• Modèle de contrôle d'accès dans Azure Data Lake Storage
• Listes de contrôle d'accès (ACL) dans Azure Data Lake Storage
• Authentification basée sur l'identité pour l'accès SMB à Azure Files
• Attribuer des autorisations au niveau du partage
• Chiffrement du Stockage Azure pour les données au repos
• Customer-managed keys pour le chiffrement du Stockage Azure
• Encryption scopes pour le Blob Storage
• Règles de firewall du Stockage Azure et contrôle d'accès réseau
• Utiliser des private endpoints pour le Stockage Azure
• Valeurs de private DNS zone des private endpoints
• Service endpoint policies de réseau virtuel pour le Stockage Azure
• Network security perimeter pour le Stockage Azure
• Vue d'ensemble de la protection des données (blobs)
• Blob soft delete et des conteneurs
• Soft delete des partages Azure Files
• Point-in-time restore pour les objets blob de blocs
• Stocker des données critiques avec un immutable storage (WORM)
• Présentation de Microsoft Defender for Storage
• Analyse des programmes malveillants dans Defender for Storage
• Configurations avancées de le Malware Scanning
• Prérequis de Defender for Storage (autorisations)
• Activer Defender for Storage avec Azure PowerShell
• Autoriser AzCopy avec une managed identity
• Registre Terraform : azurerm_storage_account (fournisseur 5.10.0)