Listes de contrôle d’accès (ACL) dans Azure Data Lake Storage

Azure Data Lake Storage implémente un modèle de contrôle d’accès qui prend en charge le contrôle d’accès en fonction du rôle Azure (RBAC Azure) et les listes de contrôle d’accès (ACL) POSIX. Cet article décrit les listes de contrôle d’accès disponibles dans Data Lake Storage. Pour en savoir plus sur l’incorporation de Azure RBAC avec les listes de contrôle d’accès et la façon dont le système les évalue pour prendre des décisions d’autorisation, consultez Modèle de contrôleAccess dans Azure Data Lake Storage.

À propos des listes de contrôle d’accès

Vous pouvez associer un principal de sécurité à un niveau d’accès pour les fichiers et répertoires. Chaque association est une entrée dans une liste de contrôle d’accès (ACL). Chaque fichier et répertoire de votre compte de stockage a une liste de contrôle d’accès. Lorsqu’un principal de sécurité tente une opération sur un fichier ou un répertoire, une vérification de la liste de contrôle d’accès détermine si ce principal de sécurité (utilisateur, groupe, principal du service ou identité managée) a le niveau d’autorisation approprié pour effectuer l’opération.

Comment définir des listes de contrôle d’accès

Pour définir des autorisations au niveau des fichiers et des répertoires, consultez l’un des articles suivants :

Types de listes de contrôle d'accès

Il existe deux types de listes de contrôle d’accès : les ACL d’accès et les ACL par défaut.

Les ACL d’accès contrôlent l’accès à un objet. Les fichiers et les répertoires ont tous des ACL d’accès.

Les ACL par défaut sont des modèles d’ACL associés à un répertoire, qui déterminent les ACL d’accès pour tous les éléments enfants créés dans ce répertoire. Les fichiers n’ont pas de listes de contrôle d’accès par défaut.

Les ACL d’accès et les ACL par défaut ont la même structure.

Niveaux d’autorisation

Les autorisations sur les répertoires et les fichiers d’un conteneur sont en lecture, écriture et exécution. Vous pouvez utiliser ces autorisations sur les fichiers et les répertoires, comme indiqué dans le tableau suivant :

Formes abrégées des autorisations

Utilisez RWX pour afficher les autorisations Lecture + Écriture + Exécution . Il existe également un formulaire numérique où Read=4, Write=2 et Execute=1. Ajoutez ces numéros pour afficher les autorisations. Voici quelques exemples :

Héritage des autorisations

Dans le modèle POSIX utilisé par Data Lake Storage, les autorisations d’un élément sont stockées sur l’élément lui-même. En d’autres termes, les autorisations sur un élément ne peuvent pas être héritées à partir des éléments parents si les autorisations sont définies après la création de l’élément enfant. Les autorisations sont héritées uniquement si les autorisations par défaut ont été définies sur les éléments parents avant la création des éléments enfants.

Scénarios courants liés aux autorisations ACL

Le tableau suivant présente les entrées ACL requises pour permettre à un principal de sécurité d’effectuer les opérations répertorié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.

Supprimer des fichiers et des répertoires

Comme indiqué dans le tableau précédent, vous n’avez pas besoin d’autorisations d’écriture sur le fichier pour le supprimer tant que les autorisations de répertoire sont correctement définies. Toutefois, pour supprimer un répertoire et tout son contenu, le répertoire parent doit disposer d’autorisations d’écriture et d’exécution. L’utilisateur doit disposer des autorisations Lecture + Écriture + Exécution sur le répertoire à supprimer et sur tous ses sous-répertoires.

Utilisateurs et identités

Chaque fichier et répertoire dispose d’autorisations distinctes pour ces identités :

• L’utilisateur propriétaire
• Le groupe propriétaire
• Les utilisateurs nommés
• Les groupes nommés
• Les principaux de service nommés
• Identités managées nommées
• Tous les autres utilisateurs

Les identités des utilisateurs et des groupes sont des identités Microsoft Entra. Ainsi, sauf indication contraire, un utilisateur, dans le contexte de Data Lake Storage, peut faire référence à un utilisateur Microsoft Entra, un principal de service, une identité managée ou un groupe de sécurité.

Le super utilisateur

Un super-utilisateur possède le plus de droits parmi tous les utilisateurs. Un super utilisateur :

• Dispose des autorisations RWX pour tous les fichiers et dossiers.

• peut modifier les autorisations sur n’importe quel fichier ou dossier ;

• peut modifier l’utilisateur ou le groupe propriétaire d’un fichier ou d’un dossier.

Si vous créez un conteneur, un fichier ou un répertoire à l’aide de la clé partagée, d’une SAP de compte ou d’une SAP de service, le propriétaire et le groupe propriétaire sont définis sur $superuser.

L’utilisateur propriétaire

L’utilisateur qui crée l’élément est automatiquement l’utilisateur propriétaire de l’élément. Les utilisateurs propriétaires peuvent :

• Modifiez les autorisations d’un fichier qu’ils possèdent.
• Modifiez le groupe propriétaire d’un fichier qu’il possède, tant que l’utilisateur propriétaire est également membre du groupe cible.

Le groupe propriétaire

Dans les ACL POSIX, chaque utilisateur est associé à un groupe principal. Par exemple, l’utilisateur « Alice » peut appartenir au groupe « Finance ». Alice peut appartenir à plusieurs groupes, mais un groupe est toujours désigné comme son groupe principal. Dans POSIX, lorsque Alice crée un fichier, le groupe propriétaire de ce fichier est défini sur son groupe principal, qui dans ce cas est « finance ». Sinon, le groupe propriétaire se comporte de la même façon que les autorisations attribuées pour d’autres utilisateurs et groupes.

Affectation du groupe propriétaire pour un nouveau fichier ou répertoire

• Cas 1 : Le répertoire racine /. Ce répertoire est créé lors de la création d’un conteneur Data Lake Storage. Dans ce cas, le groupe propriétaire est défini sur l’utilisateur qui a créé le conteneur s’il utilise OAuth. Si l’utilisateur crée le conteneur à l’aide de la clé partagée, d’une SAP de compte ou d’une SAP de service, le propriétaire et le groupe propriétaire sont définis sur $superuser.
• Cas 2 (tous les autres cas) : lorsqu’un nouvel élément est créé, le groupe propriétaire est copié à partir du répertoire parent.

Modification du groupe propriétaire

Le groupe propriétaire peut être modifié par :

• Tout super-utilisateur.
• l’utilisateur propriétaire, si l’utilisateur propriétaire est également membre du groupe cible.

Évaluation des autorisations

Le système évalue les identités dans l’ordre suivant :

1. Superutilisateur
2. Utilisateur propriétaire
3. Utilisateur nommé, principal de service ou identité managée
4. Groupe propriétaire ou groupe nommé
5. Tous les autres utilisateurs

Si plusieurs de ces identités s’appliquent à un principal de sécurité, le système accorde le niveau d’autorisation associé à la première identité. Par exemple, si un principal de sécurité est à la fois l’utilisateur propriétaire et un utilisateur nommé, le niveau d’autorisation associé à l’utilisateur propriétaire s’applique.

Le système considère tous les groupes nommés ensemble. Si un principal de sécurité est membre de plusieurs groupes nommés, le système évalue chaque groupe jusqu’à ce qu’il trouve l’autorisation souhaitée. Si aucun des groupes nommés ne fournit l’autorisation souhaitée, le système passe à évaluer une demande par rapport à l’autorisation associée à tous les autres utilisateurs.

Le pseudocode suivant représente l’algorithme de vérification des accès pour les comptes de stockage. Cet algorithme indique l’ordre dans lequel les identités sont évaluées.

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

Le masque

Le masque s’applique uniquement à l’entrée ACL d’un utilisateur nommé, d’un groupe nommé et du groupe propriétaire. Le masque spécifie les autorisations de l’entrée ACL utilisées pour autoriser l’accès. Ces autorisations appliquées sont appelées autorisations effectives de l’entrée ACL. Le système ignore toutes les autres autorisations dans l’entrée ACL. En utilisant le masque, vous pouvez établir une limite supérieure sur les niveaux d’autorisation.

Vous pouvez spécifier le masque pour chaque appel. Cette flexibilité permet à différents systèmes consommants, tels que les clusters, d’avoir différents masques efficaces pour leurs opérations de fichier. Si vous spécifiez un masque sur une demande donnée, il remplace complètement le masque par défaut.

Le sticky bit

Le sticky bit est une fonctionnalité avancée d’un conteneur POSIX. Dans le contexte de Data Lake Storage, il est peu probable que vous avez besoin du bit collant. En résumé, si vous activez le bit sticky sur un répertoire, seul l’utilisateur propriétaire de l’élément enfant, le propriétaire du répertoire ou le Superutilisateur ($superuser) peut supprimer ou renommer un élément enfant.

Le portail Azure n'affiche pas le bit collant. Pour en savoir plus sur le bit sticky et comment le définir, consultez Qu’est-ce que le bit sticky Data Lake Storage ?

Autorisations par défaut du répertoire racine

Pour un nouveau conteneur Data Lake Storage, la valeur par défaut de l’ACL d’accès du répertoire racine ("/") est de 750 pour les répertoires et 640 pour les fichiers. Le tableau suivant présente la notation symbolique de ces niveaux d’autorisation.

Les fichiers ne reçoivent pas le bit X, car il n’est pas pertinent pour les fichiers d’un système store uniquement.

Autorisations par défaut sur les nouveaux fichiers et répertoires

Lorsque vous créez un fichier ou un répertoire sous un répertoire existant, la liste de contrôle d’accès par défaut sur le répertoire parent détermine :

• L'ACL par défaut et l'ACL d'accès d'un répertoire enfant.
• ACL d’accès d’un fichier enfant (les fichiers n’ont pas de liste de contrôle d’accès par défaut).

umask

Lorsque vous créez une ACL par défaut, le système applique l’umask à l’ACL d’accès afin de déterminer les autorisations initiales de l’ACL par défaut. Si vous définissez une liste de contrôle d’accès par défaut sur le répertoire parent, le système ignore l’umask et utilise la liste de contrôle d’accès par défaut du répertoire parent pour définir les valeurs initiales.

L’umask est une valeur de 9 bits sur les répertoires parents qui contient une valeur RWX pour utilisateur propriétaire, groupe propriétaire et autre.

L’umask pour Azure Data Lake Storage est une valeur constante définie à 007. Cette valeur se traduit par :

Foire aux questions

Dois-je activer la prise en charge des ACL ?

Non. Tant que la fonctionnalité d’espace de noms hiérarchique (HNS) est activée, le contrôle d’accès via les listes de contrôle d’accès est activé pour un compte de stockage.

Si HNS est désactivé, les règles d’autorisation RBAC Azure s’appliquent toujours.

Quelle est la meilleure façon d’appliquer des ACL ?

Utilisez toujours les groupes de sécurité Microsoft Entra comme principal affecté dans les entrées 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 simplement ajouter ou supprimer des utilisateurs et des principaux de service du 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 principal de service ou l'Identité de Service Géré (MSI) pour Azure Data Factory au groupe LogsWriters.
• Ajoutez les utilisateurs de l’équipe d’ingénierie des services au groupe LogsWriter.
• Ajoutez l'objet principal de service ou le 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 ajouter des membres, consultez Créer un groupe de base et ajouter des membres à l'aide de Microsoft Entra ID.

Comment les autorisations Azure RBAC et ACL sont-elles évaluées ?

Pour savoir comment le système évalue le RBAC et les ACL Azure pour prendre des décisions d’autorisation pour les ressources de compte de stockage, consultez Comment les autorisations sont évaluées.

Quelles sont les limites sur les affectations de rôle Azure et les entrées ACL ?

Le tableau suivant fournit une vue de synthèse des limites à prendre en compte lors de l’utilisation d’Azure RBAC pour gérer les autorisations « grossièrement granulaires » (autorisations qui s’appliquent aux comptes de stockage ou aux conteneurs) et l’utilisation des ACL pour gérer les autorisations « affinées » (autorisations qui s’appliquent aux fichiers et aux répertoires). Utilisez des groupes de sécurité pour les attributions des 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.

Data Lake Storage prend-il en charge l’héritage d’Azure RBAC ?

Les affectations de rôles Azure sont héritées. Les affectations passent de l’abonnement, du groupe de ressources et des ressources du compte de stockage à la ressource du conteneur.

Data Lake Storage prend-il en charge l'héritage des listes de contrôle d'accès (ACL) ?

Les ACL par défaut peuvent être utilisées pour définir les ACL des sous-répertoires et fichiers enfants nouvellement créés sous le répertoire parent. Pour mettre à jour les listes de contrôle d’accès pour les éléments enfants existants, vous devez ajouter, mettre à jour ou supprimer des ACL de manière récursive pour la hiérarchie de répertoires souhaitée. Pour obtenir de l’aide, consultez la section Comment définir des listes de contrôle d’accès de cet article.

Quelles sont les autorisations nécessaires pour supprimer de manière récursive un répertoire et son contenu ?

• L’appelant dispose d’autorisations super-utilisateur,

ou

• Le répertoire parent dispose d’autorisations d’écriture et d’exécution.
• Le répertoire à supprimer et chaque répertoire dans celui-ci nécessite des autorisations Lecture, Écriture et Exécution.

Qui est le propriétaire d’un fichier ou d’un répertoire ?

Le créateur d’un fichier ou d’un répertoire en devient le propriétaire. Dans le cas du répertoire racine, cette identité est l’utilisateur qui a créé le conteneur.

Quel groupe est propriétaire d’un fichier ou d’un répertoire lors de sa création ?

Le groupe propriétaire est copié à partir du groupe propriétaire du répertoire parent sous lequel le nouveau fichier ou répertoire est créé.

Je suis l’utilisateur propriétaire d’un fichier, mais je n’ai pas les autorisations RWX dont j’ai besoin. Que faire ?

L’utilisateur propriétaire peut modifier les autorisations du fichier pour s’accorder les autorisations RWX dont il a besoin.

Pourquoi vois-je parfois des GUID dans les ACL ?

Un GUID s’affiche si l’entrée représente un utilisateur et que cet utilisateur n’existe plus dans Microsoft Entra. Cela se produit généralement lorsque l'utilisateur a quitté l'entreprise ou si son compte a été supprimé dans Microsoft Entra ID. En outre, les principaux de service et les groupes de sécurité ne sont identifiés par aucun UPN. Par conséquent, ils sont représentés par leur attribut OID (un GUID). Pour nettoyer les ACL, supprimez manuellement ces entrées GUID.

Comment définir correctement les ACL pour un principal de service ?

Lorsque vous définissez des ACL pour des principaux de service, il est important d’utiliser l’ID d’objet (OID) du principal du service pour l’inscription d’application que vous avez créée. Il est important de noter que les applications inscrites ont un principal de service distinct dans le locataire Microsoft Entra spécifique. Les applications inscrites ont un OID qui est visible dans le Portail Azure, mais le principal du service a un autre OID (différent). Article - Pour obtenir l’OID du principal du service qui correspond à une inscription d’application, vous pouvez utiliser la commande az ad sp show. Spécifiez l’ID d’application comme paramètre. Voici un exemple pour obtenir l’OID du principal du service qui correspond à un enregistrement d'application avec l’ID d’application = 00001111-aaaa-2222-bbbb-3333cccc4444. Dans Azure CLI, exécutez la commande suivante :

az ad sp show --id 00001111-aaaa-2222-bbbb-3333cccc4444 --query objectId

L’OID s'affichera.

Si vous avez le bon OID pour le principal du service, accédez à la page Gérer l’accès de l’Explorateur Stockage pour ajouter l’OID et attribuer des autorisations appropriées pour l’OID. Veillez à sélectionner Enregistrer.

Puis-je définir la liste de contrôle d’accès d’un conteneur ?

Non. Un conteneur n’a pas de liste de contrôle d'accès. Toutefois, vous pouvez définir le contrôle d'accès (ACL) du répertoire racine du conteneur. Chaque conteneur possède un répertoire racine et il partage le même nom que le conteneur. Par exemple, si le conteneur est nommé my-container, le répertoire racine est nommé my-container/.

L’API REST de stockage Azure contient une opération nommée Set Container ACL, mais cette opération ne peut pas être utilisée pour définir la liste de contrôle d’accès d’un conteneur ou le répertoire racine d’un conteneur. Au lieu de cela, cette opération est utilisée pour indiquer si les blobs dans un conteneur sont accessibles avec une requête anonyme. Nous vous recommandons d’exiger une autorisation pour toutes les requêtes relatives aux données blob. Pour plus d’informations, consultez le document Présentation : Rémédiation de l’accès en lecture anonyme pour les données blob.

Comment en savoir plus sur le modèle de contrôle d’accès POSIX ?

• Listes de contrôle d’accès (ACL) POSIX sur Linux
• HDFS Permission Guide (Guide des autorisations HDFS)
• FAQ POSIX
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• ACL POSIX sous Ubuntu

Voir aussi

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