L’implémentation d'un compte de stockage Azure (Azure Storage Account) dans un environnement hautement sécurisé exige une maîtrise parfaite des Private Endpoints (PE) et des rôles RBAC (Role-Based Access Control).

Ce guide répertorie de manière exhaustive les configurations réseau et les permissions nécessaires pour chaque sous-service d'Azure Storage, y compris les fonctionnalités avancées comme le SFTP et le Data Lake (ADLS Gen2).

1. Cartographie des Private Endpoints par Sous-Service

Un compte de stockage Azure est une entité polymorphe. Selon les fonctionnalités activées, vous devez créer un ou plusieurs Private Endpoints ciblant des sous-ressources (sub-resources) spécifiques.

Tableau de correspondance des ressources cibles

Pour chaque type de trafic, voici le sub-resource exact à configurer lors de la création de votre Private Endpoint, ainsi que la zone DNS privée correspondante :

Fonctionnalité / Option de Configuration	Sous-ressource cible (sub-resource)	Zone DNS Privée Azure Recommandée
Azure Blobs (Stockage standard d'objets)	blob	privatelink.blob.core.windows.net
Azure Files (Partages de fichiers SMB/NFS)	file	privatelink.file.core.windows.net
Azure Queues (Files d'attente de messages)	queue	privatelink.queue.core.windows.net
Azure Tables (Stockage NoSQL structuré)	table	privatelink.table.core.windows.net
Azure Data Lake Gen2 (Espace de noms hiérarchique activé)	dfs	privatelink.dfs.core.windows.net
Sites Web Statiques (Hébergement web natif)	web	privatelink.web.core.windows.net

Le cas crucial du SFTP sur Azure Storage

Le protocole SFTP (SSH File Transfer Protocol) s'appuie nativement sur le service Blob.

Quel Private Endpoint ?
Vous devez déployer un Private Endpoint avec la sous-ressource blob.
Il n'existe pas de sous-ressource dédiée nommée "sftp".

• Règle réseau importante : Le trafic SFTP passe par le port standard 22. Lors de l'accès via Private Endpoint, assurez-vous que vos Groupes de Sécurité Réseau (NSG) et pare-feux autorisent le port 22 vers l'IP privée du PE blob.

💡 Piège classique (ADLS Gen2) : Si vous activez l'espace de noms hiérarchique (Hierarchical Namespace), vos applications de Big Data (Databricks, Synapse) utiliseront le endpoint dfs.
Cependant, pour certaines opérations de gestion ou pour l'accès au stockage Blob standard sur ce même compte, le endpoint blob reste requis.

Il est fortement recommandé de créer les deux (blob et dfs) pour éviter des coupures de flux.

2. Matrice des Rôles RBAC par Fonctionnalité

Le contrôle d'accès réseau via Private Endpoint ne dispense pas d'une gestion stricte des identités. Le principe du moindre privilège impose d'utiliser les rôles RBAC intégrés (Built-in) plutôt que les clés d'accès globales du compte de stockage (Access Keys).

A. Rôles pour le service Blob et ADLS Gen2

Ces rôles s'appliquent au plan de données (Data Plane) pour la gestion et l'accès direct aux données :

• Storage Blob Data Reader : Accès en lecture seule aux conteneurs et aux blobs. Idéal pour les outils d'audit, de surveillance ou de reporting.

• Storage Blob Data Contributor : Accès complet en lecture, écriture et suppression. C'est le rôle standard requis pour la majorité des applications et des pipelines ETL.

• Storage Blob Data Owner : Permet le contrôle total des données ET la modification des ACL (Access Control Lists) spécifiques à POSIX dans ADLS Gen2. Requis pour la configuration initiale des répertoires du Data Lake.

B. Rôles pour la fonctionnalité SFTP

L'activation du SFTP repose sur la fonctionnalité des Local Users (utilisateurs locaux). L'authentification finale s'effectue par mot de passe ou par clé SSH. Néanmoins, pour configurer, provisionner et gérer ces utilisateurs au niveau de l'infrastructure, les administrateurs ont besoin de droits sur le plan de contrôle (Control Plane) :

• Storage Account Contributor : Ce rôle (ou un rôle personnalisé incluant les actions Microsoft.Storage/storageAccounts/localUsers/*) est obligatoire pour pouvoir créer les utilisateurs locaux, générer leurs mots de passe et leur assigner des répertoires de base (home directories).

C. Rôles pour Azure Files (SMB / NFS)

L'accès à Azure Files via Private Endpoint nécessite généralement une intégration avec un service d'annuaire (Active Directory Domain Services ou Microsoft Entra ID Kerberos) pour mapper les identités :

• Storage File Data SMB Share Reader : Permet l'accès en lecture aux partages de fichiers Azure via SMB.

• Storage File Data SMB Share Contributor : Permet l'accès en lecture, écriture et suppression sur les partages de fichiers.

• Storage File Data SMB Share Elevated Contributor : Permet de lire, écrire, supprimer des fichiers, mais surtout de modifier les permissions NTFS (ACL) sur les fichiers et dossiers à la racine du partage.

D. Rôles pour les Queues et Tables

• Storage Queue Data Contributor / Storage Queue Data Reader : Respectivement pour envoyer/lire/supprimer ou simplement lire les messages au sein des files d'attente.

• Storage Table Data Contributor / Storage Table Data Reader : Respectivement pour exécuter des opérations CRUD ou de simple lecture sur les entités des tables NoSQL.

3. Synthèse d'Architecture : Scénario d'usage

Imaginons un projet où vous devez configurer un compte de stockage sécurisé pour trois cas d'usage simultanés : une application Web qui dépose des images, un partenaire externe qui dépose des fichiers en SFTP, et une équipe Data qui analyse ces données via un Data Lake.

Voici la configuration cible à appliquer :

[Réseau Virtuel / VNet]
       │
       ├──► Private Endpoint (blob) ──► Application Web (Rôle: Storage Blob Data Contributor)
       │                                Partner SFTP    (Authentifié via Local User)
       │
       └──► Private Endpoint (dfs)  ──► Équipe Data     (Rôle: Storage Blob Data Owner)

1. Options activées sur le Storage Account : Hierarchical Namespace (ADLS Gen2) = Enabled ; SFTP = Enabled.

2. Private Endpoints à déployer :

   1. Un PE pour la sous-ressource blob (utilisé par le flux SFTP et l'application web).

   2. Un PE pour la sous-ressource dfs (utilisé par l'équipe Data pour bénéficier des performances analytiques de l'espace de noms hiérarchique).

3. Sécurité Réseau : Désactiver complètement l'accès public (Public network access = Disabled).

4. Gouvernance des accès :

   1. L'identité managée (Managed Identity) de l'application Web reçoit le rôle Storage Blob Data Contributor.

   2. Le partenaire SFTP est configuré comme Local User avec sa clé SSH publique, son accès étant restreint à son dossier d'atterrissage (landing zone).

   3. L'identité de la plateforme Data reçoit le rôle Storage Blob Data Owner pour gérer la structure du Data Lake.

Conclusion

Sécuriser un compte de stockage Azure ne se résume pas à cocher une case d'isolation réseau. Le succès de votre architecture repose sur l'alignement parfait entre vos flux réseau (Private Endpoints) et votre stratégie d'identité (Rôles RBAC).

Pour résumer la marche à suivre :

1. Anticipez les usages : Ne sous-estimez pas les dépendances entre sous-ressources, notamment le duo blob/dfs pour les architectures Data Lake ou l'usage exclusif du endpoint blob pour le SFTP.

2. Appliquez le moindre privilège : Utilisez systématiquement les rôles intégrés ciblant le Data Plane (comme Storage Blob Data Contributor) au lieu de distribuer les clés d'accès globales du compte.

3. Validez la couche réseau : Assurez-vous que vos résolutions DNS privées et vos règles de pare-feu (NSG) autorisent explicitement les ports applicatifs requis (comme le port 22 pour le SFTP).

En combinant une segmentation réseau stricte par Private Endpoints et une gouvernance des accès basée sur Entra ID, vous transformez Azure Storage en une véritable forteresse pour vos données d'entreprise.