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 du RBAC Azure avec les listes de contrôle d’accès et sur la façon dont le système les évalue pour prendre des décisions d’autorisation, consultez Modèle de contrôle d’accès 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 capturée comme une entrée d’une liste de contrôle d’accès. 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 d’ACL 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 dans un conteneur sont Lecture, Écriture et Exécution. Elles peuvent être utilisées sur les fichiers et les répertoires comme l’indique le tableau ci-dessous :

Formes abrégées des autorisations

RWX correspond à Lecture + Écriture + Exécution. Il existe une forme numérique plus condensée dans laquelle Lecture = 4, Écriture = 2 et Exécution = 1. Les autorisations sont représentées par la somme de ces chiffres. 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 de liste de contrôle d'accès

Le tableau suivant vous montre les entrées de liste de contrôle d’accès requises pour permettre à un principal de sécurité d’effectuer les opérations indiquées dans la colonne Opérations.

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.

Suppression de fichiers et de répertoires

Comme le montre le tableau précédent, il n’est pas nécessaire d’avoir des droits d’écriture sur le fichier pour le supprimer si les droits d’accès au répertoire sont correctement définis. 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 :

• possède les autorisations RWX sur 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 un conteneur, un fichier ou un répertoire est créé à l'aide d'une clé partagée, d'un compte SAS ou d'un service SAS, le propriétaire et le groupe propriétaire sont définis sur $superuser.

L’utilisateur propriétaire

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

• modifier les autorisations de leurs fichiers ;
• modifier le groupe propriétaire d’un fichier détenu, 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, lorsqu’Alice crée un fichier, son groupe principal est défini comme groupe propriétaire de ce fichier (en l’occurrence, « finance »). Sinon, le groupe propriétaire se comporte comme pour les autorisations assignées à d’autres utilisateurs/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 celui de l’utilisateur qui a créé le conteneur si l’opération est réalisée avec OAuth. Si le conteneur est créé à l’aide d’une clé partagée, d’une SAS de compte ou d’une SAS de service, le propriétaire et le groupe propriétaire sont définis avec la valeur $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 :

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

Évaluation des autorisations

Les identités sont évaluées 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 niveau d’autorisation associé à la première identité est accordé. 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.

Les groupes nommés sont tous considérés comme étant ensemble. Si un principal de sécurité est membre de plusieurs groupes nommés, le système évalue chaque groupe jusqu’à ce que l’autorisation souhaitée soit accordée. Si aucun des groupes nommés ne fournit l’autorisation souhaitée, le système évalue alors une requête 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

Comme illustré dans l’algorithme de vérification des accès, le masque limite l’accès pour les utilisateurs nommés, le groupe propriétaire et les groupes nommés.

Pour un nouveau conteneur Data Lake Storage, la valeur par défaut du masque 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 est sans importance pour les fichiers dans un système de stockage uniquement.

Le masque peut être spécifié par appel. Ainsi, différents systèmes de consommation, tels que les clusters, peuvent être associés à différents masques plus efficaces pour leurs opérations de fichier. Si un masque est spécifié sur une requête 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 le sticky bit soit nécessaire. En résumé, si le sticky bit est activé sur un répertoire, un élément enfant peut uniquement être supprimé ou renommé par l’utilisateur propriétaire de l’élément enfant, le propriétaire du répertoire ou le superutilisateur ($superuser).

Le sticky bit n’est pas affiché dans le Portail Azure. Pour en savoir plus sur le sticky bit et la manière de le définir, consultez Qu’est-ce que le sticky bit Data Lake Storage ?.

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

Lorsqu’un nouveau fichier ou répertoire est créé dans un dossier existant, l’ACL par défaut sur le répertoire parent détermine :

• La liste ACL par défaut et la liste ACL d’accès d’un répertoire enfant.
• L’ACL d’accès d’un fichier enfant (les fichiers n’ont pas d’ACL par défaut).

umask

Lors de la création d’une liste de contrôle d’accès par défaut, l’umask est appliqué à la liste de contrôle d’accès pour déterminer les autorisations initiales d’une liste de contrôle d’accès par défaut. Si une liste de contrôle d’accès par défaut est définie sur le répertoire parent, l’umask est ignoré et la liste de contrôle d’accès par défaut du répertoire parent est utilisée à la place pour définir ces 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 sur 007. Cette valeur se traduit par :

Forum aux questions

Dois-je activer la prise en charge des ACL ?

Non. Le contrôle d’accès via ACL est activé pour un compte de stockage tant que la fonctionnalité d’espace de noms hiérarchique est activée.

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

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

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 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 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 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 du RBAC Azure ?

Les affectations de rôle Azure peuvent être 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 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 les listes de contrôle d’accès 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 des autorisations de « super utilisateur »,

ou

• L’utilisateur doit disposer des autorisations Écriture + Exécution sur le répertoire parent.
• L’utilisateur doit disposer des autorisations Lecture + Écriture + Exécution sur le répertoire à supprimer et sur tous ses sous-répertoires.

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, il s’agit de l’identité de l’utilisateur ayant 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 dans lequel le fichier ou le 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 enregistrées 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 sur l’obtention de l’OID du principal du service qui correspond à une inscription d’application avec l’ID d’application = ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0. Dans Azure CLI, exécutez la commande suivante :

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

L’OID s’affiche.

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 la liste de contrôle d’accès 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 demandes de données blob. Pour plus d’informations, consultez Présentation : Correction 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)
• Forum aux questions 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