Modèle de contrôle d’accès dans Azure Data Lake Storage Gen2

Data Lake Storage Gen2 prend en charge les mécanismes d’autorisation suivants :

• Autorisation de clé partagée
• Autorisation de signature d’accès partagé (SAP)
• Contrôle d’accès en fonction du rôle (Azure RBAC)
• Contrôle d’accès en fonction des attributs (Azure ABAC)
• Listes de contrôle d’accès (ACL)

L’autorisation Shared Key et SAS accorde l’accès à un utilisateur (ou une application) sans qu’il n’ait besoin d’une identité dans Microsoft Entra ID. Avec ces deux formes d’authentification, Azure RBAC, Azure ABAC et les ACL n’ont aucun effet.

Azure RBAC et ACL nécessitent l’utilisation d’une identité dans Microsoft Entra ID de l’utilisateur (ou de l’application). Azure RBAC vous permet d'accorder un accès « grossier » aux données d'un compte de stockage, par exemple un accès en lecture ou en écriture à toutes les données d'un compte de stockage. Azure ABAC vous permet d’affiner les attributions de rôles RBAC en ajoutant des conditions. Par exemple, vous pouvez accorder un accès en lecture ou en écriture à tous les objets de données d’un compte de stockage qui comporte une étiquette spécifique. Les listes de contrôle d'accès vous permettent d'accorder un accès « fin », tel que l'accès en écriture à un répertoire ou à un fichier spécifique.

Cet article se concentre sur le RBAC, l’ABAC, et les ACL Azure et sur la façon dont le système les évalue pour prendre des décisions d’autorisation pour les ressources de compte de stockage.

Contrôle d’accès en fonction du rôle (Azure RBAC)

Azure RBAC utilise des attributions de rôles pour appliquer des ensembles d’autorisations aux principaux de sécurité. Un principal de sécurité est un objet qui représente un utilisateur, un groupe, un principal de service ou une identité managée défini(e) dans Microsoft Entra ID. Un jeu d’autorisations peut accorder à un principal de sécurité un niveau d’accès à « granularité grossière », tel qu’un accès en lecture ou en écriture à toutes les données dans un compte de stockage ou toutes les données dans un conteneur.

Les rôles suivants permettent à un principal de sécurité d’accéder aux données dans un compte de stockage.

Rôle	Description
Propriétaire des données Blob du stockage	Accès complet aux conteneurs de stockage d’objets BLOB et aux données. Cet accès permet au principal de sécurité de définir le propriétaire d’un élément, et de modifier les listes de contrôle d’accès de tous les éléments.
Contributeur aux données Blob du stockage	Lire, écrire et supprimer des conteneurs et objets blob du stockage Azure. Cet accès ne permet pas au principal de sécurité de définir la propriété d’un élément, mais il peut modifier la liste de contrôle d’accès des éléments appartenant au principal de sécurité.
Lecteur des données blob du stockage	Lire et répertorier les conteneurs de stockage Blob et les objets Blob.

Les rôles tels que Propriétaire, Contributeur, Lecteuret Contributeur de compte de stockage permettent à un principal de sécurité de gérer un compte de stockage, mais ne fournissent pas l’accès aux données dans ce compte. Toutefois, ces rôles (à l’exclusion de Lecteur) peuvent obtenir l’accès aux clés de stockage, qui peuvent être utilisées dans différents outils clients pour accéder aux données.

Contrôle d’accès en fonction des attributs (Azure ABAC)

Azure ABAC s’appuie sur Azure RBAC en ajoutant des conditions d’attribution de rôle en fonction des attributs dans le contexte d’actions spécifiques. Une condition d’attribution de rôle est une autre vérification que vous pouvez éventuellement ajouter à votre attribution de rôle pour fournir un contrôle d’accès encore plus précis. Vous ne pouvez pas refuser explicitement l’accès à des ressources spécifiques en utilisant des conditions.

Pour plus d'informations sur l'utilisation d'Azure ABAC pour contrôler l'accès à Stockage Azure, voir Autoriser l’accès au Stockage Blob Azure à l’aide des conditions d’attribution de rôle Azure.

Listes ACL

Les listes de contrôle d’accès vous permettent d’appliquer un niveau d’accès à « granularité plus fine » aux répertoires et aux fichiers. Une liste de contrôle d’accès est une construction d’autorisation qui contient une série d’entrées ACL. Chaque entrée de liste de contrôle d’accès associe le principal de sécurité à un niveau d’accès. Pour plus d’informations, consultez les listes de contrôle d’accès (ACL) dans Azure Data Lake Storage Gen2.

Évaluation des autorisations

Au cours de l’autorisation basée sur les entités de sécurité, les autorisations sont évaluées comme indiqué dans le diagramme suivant.

1. Azure détermine s’il existe une attribution de rôle pour le principal.
   • S’il existe une attribution de rôle, les conditions d’attribution de rôle (2) sont alors évaluées.
   • Si ce n’est pas le cas, les listes de contrôle d’accès (4) sont évaluées.
2. Azure détermine s’il existe des conditions d’attribution de rôle ABAC.
   • Si aucune condition n’existe, l’accès est accordé.
   • Si des conditions existent, elles sont évaluées pour voir si elles correspondent à la demande (3).
3. Azure détermine si toutes les conditions d’attribution de rôle ABAC correspondent aux attributs de la requête.
   • Si elles correspondent toutes, l’accès est accordé.
   • Si au moins l’une d’elles ne correspond pas, les ACL (4) sont évalués.
4. Si l’accès n’a pas été explicitement accordé après l’évaluation des attributions de rôles et des conditions, les listes de contrôle d’accès sont évaluées.
   • Si les listes de contrôle d’accès autorisent le niveau d’accès demandé, l’accès est accordé.
   • Si ce n’est pas le cas, l’accès est refusé.

Important

En raison de la façon dont les autorisations d’accès sont évaluées par le système, vous ne pouvez pas utiliser une liste de contrôle d’accès pour limiter l’accès qui a déjà été accordé par une attribution de rôle et ses conditions. Cela est dû au fait que le système évalue d’abord les attributions de rôles Azure et les conditions, et si l’attribution accorde une autorisation d’accès suffisante, les ACL sont ignorées.

Le diagramme suivant illustre le flux d’autorisation pour trois opérations courantes : lister le contenu des répertoires, lire un fichier et écrire un fichier.

Tableau des autorisations : combinaison d’Azure RBAC, ABAC et ACL

Le tableau suivant vous montre comment combiner des rôles Azure, des conditions et des entrées de liste de contrôle d’accès afin qu’un principal de sécurité puisse effectuer les opérations indiquées dans la colonne Opération. Ce tableau présente une colonne qui illustre chaque niveau d’une hiérarchie de répertoires fictifs. Il existe une colonne pour le répertoire racine du conteneur (/), un sous-répertoire nommé Oregon, un sous-répertoire du répertoire Oregon nommé Portlandet un fichier texte dans le répertoire Portland nommé Data. txt. Dans ces colonnes s’affichent des représentations sousforme abrégée de l’entrée ACL requise pour accorder des autorisations. N/A (pas applicable) apparaît dans la colonne si aucune entrée de liste de contrôle d’accès n’est requise pour effectuer l’opération.

Opération	Rôle Azure attribué (avec ou sans conditions)	/	Oregon/	Portland/	Data.txt
Lire Data.txt	Propriétaire des données Blob du stockage	N/A	N/A	N/A	N/A
	Contributeur aux données Blob du stockage	N/A	N/A	N/A	N/A
	Lecteur des données blob du stockage	N/A	N/A	N/A	N/A
	None	--X	--X	--X	R--
Ajouter à Data.txt	Propriétaire des données Blob du stockage	N/A	N/A	N/A	N/A
	Contributeur aux données Blob du stockage	N/A	N/A	N/A	N/A
	Lecteur des données blob du stockage	--X	--X	--X	-W-
	None	--X	--X	--X	RW-
Supprimer Data.txt	Propriétaire des données Blob du stockage	N/A	N/A	N/A	N/A
	Contributeur aux données Blob du stockage	N/A	N/A	N/A	N/A
	Lecteur des données blob du stockage	--X	--X	-WX	N/A
	None	--X	--X	-WX	N/A
Créer Data.txt	Propriétaire des données Blob du stockage	N/A	N/A	N/A	N/A
	Contributeur aux données Blob du stockage	N/A	N/A	N/A	N/A
	Lecteur des données blob du stockage	--X	--X	-WX	N/A
	None	--X	--X	-WX	N/A
Répertorier /	Propriétaire des données Blob du stockage	N/A	N/A	N/A	N/A
	Contributeur aux données Blob du stockage	N/A	N/A	N/A	N/A
	Lecteur des données blob du stockage	N/A	N/A	N/A	N/A
	None	R-X	N/A	N/A	N/A
Répertorier /Oregon/	Propriétaire des données Blob du stockage	N/A	N/A	N/A	N/A
	Contributeur aux données Blob du stockage	N/A	N/A	N/A	N/A
	Lecteur des données blob du stockage	N/A	N/A	N/A	N/A
	None	--X	R-X	N/A	N/A
Répertorier /Oregon/Portland/	Propriétaire des données Blob du stockage	N/A	N/A	N/A	N/A
	Contributeur aux données Blob du stockage	N/A	N/A	N/A	N/A
	Lecteur des données blob du stockage	N/A	N/A	N/A	N/A
	None	--X	--X	R-X	N/A

Remarque

Pour afficher le contenu d’un conteneur dans l’Explorateur de Stockage Azure, les principaux de sécurité doivent se connecter à l’Explorateur de Stockage à l’aide de Microsoft Entra ID et (au minimum) disposer d’un accès en lecture (R--) au dossier racine (\) d’un conteneur. Ce niveau d’autorisation leur donne la possibilité de répertorier le contenu du dossier racine. Si vous ne souhaitez pas que le contenu du dossier racine soit visible, vous pouvez lui attribuer le rôle Lecteur. Avec ce rôle, ils peuvent répertorier les conteneurs dans le compte, mais pas le contenu du conteneur. Vous pouvez ensuite accorder l’accès à des répertoires et des fichiers spécifiques à l’aide de listes de contrôle d’accès.

Groupes de sécurité

Utilisez toujours les groupes de sécurité Microsoft Entra comme principal attribué dans une entrée ACL. Résistez à la possibilité d’attribuer directement des utilisateurs ou des principaux de service individuels. L’utilisation de cette structure vous permettra d’ajouter et de supprimer des utilisateurs ou des principaux de service sans devoir réappliquer les ACL sur la structure de répertoires dans son ensemble. Au lieu de cela, vous pouvez juste ajouter ou supprimer des utilisateurs et des principaux de service dans le groupe de sécurité Microsoft Entra approprié.

Il existe plusieurs façons de configurer des groupes. Par exemple, imaginez que vous disposez d’un répertoire nommé /LogData qui contient les données de journal générées par votre serveur. Azure Data Factory (ADF) ingère les données dans ce dossier. Des utilisateurs spécifiques de l’équipe d’ingénierie des services chargent les journaux et gèrent les autres utilisateurs de ce dossier, et divers clusters Databricks analysent les journaux à partir de ce dossier.

Pour activer ces activités, vous pouvez créer un groupe LogsWriter et un groupe LogsReader. Ensuite, vous pouvez affecter des autorisations comme suit :

• Ajoutez le groupe LogsWriter à l’ACL du répertoire /LogData avec les autorisations rwx.
• Ajoutez le groupe LogsReader à l’ACL du répertoire /LogData avec les autorisations r-x.
• Ajoutez l’objet de principal de service ou l’Identité du service administré (MSI) pour ADF au groupe LogsWriters.
• Ajoutez les utilisateurs de l’équipe d’ingénierie des services au groupe LogsWriter.
• Ajoutez l’objet de principal de service ou la MSI pour Databricks au groupe LogsReader.

Si un utilisateur de l’équipe d’ingénierie des services quitte l’entreprise, vous pouvez simplement le supprimer du groupe LogsWriter. Si vous n’avez pas ajouté cet utilisateur à un groupe, mais que vous avez ajouté une entrée ACL dédiée pour cet utilisateur, vous devez supprimer cette entrée ACL du répertoire /LogData. Vous devez également supprimer l’entrée de tous les sous-répertoires et fichiers de l’ensemble de la hiérarchie de répertoires du répertoire /LogData.

Pour créer un groupe et y ajouter des membres, consultez Créer un groupe de base et ajouter des membres avec Microsoft Entra ID.

Important

Azure Data Lake Storage Gen2 dépend de Microsoft Entra ID pour la gestion des groupes de sécurité. Microsoft Entra ID vous recommande de limiter l’appartenance à un groupe pour un principal de sécurité donné à moins de 200. Cette recommandation est due à une limitation des jetons Web JSON (JWT) qui fournissent les informations d’appartenance au groupe d’un principal de sécurité dans des applications Microsoft Entra. Le dépassement de cette limite peut entraîner des problèmes inattendus de performances avec Data Lake Storage Gen2. Pour en savoir plus, consultez Configurer des revendications de groupe pour des applications en utilisant Microsoft Entra ID.

Limites sur les affectations de rôle Azure et les entrées ACL

En utilisant des groupes, vous êtes moins susceptible de dépasser le nombre maximal d’attributions de rôles par abonnement et le nombre maximal d’entrées ACL par fichier ou par répertoire. Le tableau suivant décrit ces limites.

Mechanism	Étendue	Limites	Niveau d’autorisation pris en charge
Azure RBAC	Comptes de stockage, conteneurs. Attributions de rôles Azure de ressources croisées au niveau de l’abonnement ou du groupe de ressources.	4 000 attributions de rôles Azure dans un abonnement	Rôles Azure (intégrés ou personnalisés)
ACL	Répertoire, fichier	32 entrées ACL (28 entrées ACL effectives) par fichier et par annuaire. Les ACL d’accès et par défaut disposent chacune de leur propre limite d’entrée de 32 ACL.	Autorisation ACL

Autorisation de clé partagée et de signature d’accès partagé (SAP)

Azure Data Lake Storage Gen2 prend également en charge les méthodes Shared Key et SAS pour l’authentification. Une caractéristique de ces méthodes d’authentification est qu’aucune identité n’est associée à l’appelant. Par conséquent, aucune permission basée sur une autorisation de principal de sécurité ne peut être accordée.

Dans le cas d’une clé partagée, l’appelant obtient effectivement l’accès « super utilisateur », ce qui signifie un accès complet à toutes les opérations sur toutes les ressources, notamment les données, la définition du propriétaire et la modification des ACL.

Les jetons SAP incluent les autorisations accordées dans le jeton. Les autorisations incluses dans le jeton SAP sont appliquées à toutes les décisions d’autorisation, mais aucune vérification ACL supplémentaire n’est effectuée.

Étapes suivantes

Pour en savoir plus sur les listes de contrôle d’accès, consultez les listes de contrôle d’accès (ACL) dans Azure Data Lake Storage Gen2.