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

Article
10/16/2024

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.

Remarque

Les listes de contrôle d’accès s’appliquent uniquement aux principaux de sécurité du même locataire. Les listes ACL ne s’appliquent pas aux utilisateurs qui se servent d’une autorisation Clé partagée parce qu’aucune identité n’est associée à l’appelant et par conséquent, aucune permission basée sur une autorisation de principal de sécurité ne peut être accordée. Il en va de même pour les jetons de signature d’accès partagé (SAS), sauf lorsqu’un jeton SAS de délégation utilisateur est employé. Dans ce cas, le Stockage Azure effectue une vérification ACL POSIX par rapport à l’ID d’objet avant d’autoriser l’opération tant que le suoid de paramètre facultatif est utilisé. Pour en savoir plus, consultez Créer une SAS de délégation utilisateur.

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 :

Environnement	Article
Explorateur de stockage Azure	Utiliser l’Explorateur Stockage Azure pour gérer les listes de contrôle d’accès dans Azure Data Lake Storage
Portail Azure	Utiliser le portail Azure pour gérer les listes de contrôle d’accès dans Azure Data Lake Storage
.NET	Utiliser .NET pour gérer les listes de contrôle d’accès dans Azure Data Lake Storage
Java	Utiliser Java pour gérer les listes de contrôle d’accès dans Azure Data Lake Storage
Python	Utiliser Python pour gérer les listes de contrôle d’accès dans Azure Data Lake Storage
JavaScript (Node.js)	Utiliser le SDK JavaScript dans Node.js pour gérer les listes de contrôle d’accès dans Azure Data Lake Storage
PowerShell	Utiliser PowerShell pour gérer les listes de contrôle d’accès dans Azure Data Lake Storage
Azure CLI	Utiliser Azure CLI pour gérer les listes de contrôle d’accès dans Azure Data Lake Storage
REST API	Chemin d’accès – Mise à jour

Important

Si le principal de sécurité est un principal de service, il est important d’utiliser l’ID d’objet du principal du service et non l’ID d’objet de l’inscription d’application connexes. Pour obtenir l’ID d’objet du principal du service, ouvrez l’interface Azure CLI, puis utilisez cette commande : az ad sp show --id <Your App ID> --query objectId. Assurez-vous de remplacer l’espace réservé <Your App ID> par l’ID d’application de votre inscription d’application. Le principal de service est traité comme un utilisateur nommé. Vous allez ajouter cet ID à l’ACL comme pour n’importe quel utilisateur nommé. Les utilisateurs nommés sont décrits plus loin dans cet article.

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.

Notes

La modification de l’ACL par défaut d’un parent n’affecte pas l’ACL d’accès ni l’ACL par défaut des éléments enfants qui existent déjà.

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 :

	Fichier	Répertoire
Lecture (R)	Permet de lire le contenu d’un fichier	Requiert les autorisations Lecture et Exécution pour répertorier le contenu du répertoire
Écriture (W)	Permet d’écrire ou d’ajouter du contenu dans un fichier	Requiert les autorisations Écriture et Exécution pour créer des éléments enfants dans un répertoire
Exécution (X)	Ne signifie rien dans le contexte de Data Lake Storage	Requise pour parcourir les éléments enfants d’un répertoire

Notes

Si vous accordez des autorisations en utilisant uniquement des ACL (sans Azure RBAC), alors, pour accorder un accès en lecture ou en écriture sur un fichier à un principal de sécurité, vous devez donner au principal de sécurité des autorisations Exécution sur le dossier racine du conteneur et sur chaque dossier de la hiérarchie de dossiers qui mène au fichier.

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.

Forme numérique	Forme abrégée	Signification
7	`RWX`	Lecture + Écriture + Exécution
5	`R-X`	Lecture + Exécution
4	`R--`	Lire
0	`---`	Aucune autorisation

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.

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.

Important

Ce tableau suppose que vous utilisez uniquement des ACL sans attributions de rôle Azure. Pour voir une table similaire qui combine Azure RBAC avec des ACL, consultez Tableau des autorisations : combinaison d’Azure RBAC, ABAC, et ACL.

Opération	/	Oregon/	Portland/	Data.txt
Lire Data.txt	`--X`	`--X`	`--X`	`R--`
Ajouter à Data.txt	`--X`	`--X`	`--X`	`RW-`
Supprimer Data.txt	`--X`	`--X`	`-WX`	`---`
Supprimer / Oregon/	`-WX`	`RWX`	`RWX`	`---`
Supprimer / Oregon / Portland/	`--X`	`-WX`	`RWX`	`---`
Créer Data.txt	`--X`	`--X`	`-WX`	`---`
Répertorier /	`R-X`	`---`	`---`	`---`
Répertorier /Oregon/	`--X`	`R-X`	`---`	`---`
Répertorier /Oregon/Portland/	`--X`	`--X`	`R-X`	`---`

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.

Remarque

Le répertoire racine « / » ne peut jamais être supprimé.

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.

Notes

L’utilisateur propriétaire ne peut pas modifier l’utilisateur propriétaire d’un fichier ou d’un répertoire. Seuls les super utilisateurs peuvent modifier l’utilisateur propriétaire d’un fichier ou d’un répertoire.

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.

Notes

Le groupe propriétaire ne peut pas modifier les ACL d’un fichier ou d’un répertoire. Alors que le groupe d’appartenance est défini sur l’utilisateur qui a créé le compte dans le cas du répertoire racine, Cas 1 ci-dessus, un seul compte d’utilisateur n’est pas valide pour accorder des autorisations via le groupe d’appartenance. Si applicable, vous pouvez assigner cette autorisation à un groupe d’utilisateurs valide.

Évaluation des autorisations

Les identités sont évaluées dans l’ordre suivant :

Superutilisateur
Utilisateur propriétaire
Utilisateur nommé, principal de service ou identité managée
Groupe propriétaire ou groupe nommé
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.

Entité	Répertoires	Files
Utilisateur propriétaire	`rwx`	`rw-`
groupe propriétaire	`r-x`	`r--`
Autre	`---`	`---`

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 :

Composant umask	Forme numérique	Forme abrégée	Signification
umask.owning_user	0	`---`	Pour l’utilisateur propriétaire, copiez l’ACL d’accès du parent dans l’ACL par défaut de l’enfant
umask.owning_group	0	`---`	Pour le groupe propriétaire, copiez l’ACL d’accès du parent dans l’ACL par défaut de l’enfant
umask.other	7	`RWX`	Pour d’autres rôles, supprimez toutes les autorisations de l’ACL d’accès de l’enfant

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.

Important

Azure Data Lake Storage Gen2 dépend de Microsoft Entra ID pour gérer les groupes de sécurité. Microsoft Entra ID vous recommande de limiter l'adhésion à un groupe pour un principal de sécurité donné à moins de 200. Cette suggestion est due à une limitation des jetons Web JSON (JWT) qui fournissent des informations sur l'appartenance à un groupe d'entité de sécurité dans les 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 les revendications de groupe pour les applications à 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.

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

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 »,

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.

Notes

L’autorisation Écriture n’est pas nécessaire pour supprimer des fichiers situés dans des répertoires. En outre, le répertoire racine « / » ne peut jamais être supprimé.

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 ?

Voir aussi

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

Partager via

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

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

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

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

Niveaux d’autorisation

Formes abrégées des autorisations

Héritage des autorisations

Suppression de fichiers et de répertoires

Utilisateurs et identités

Le super utilisateur

L’utilisateur propriétaire

Le groupe propriétaire

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

Modification du groupe propriétaire

Évaluation des autorisations

Le masque

Le sticky bit

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

umask

Forum aux questions

Dois-je activer la prise en charge des ACL ?

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

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

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

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

Data Lake Storage prend-il en charge l’héritage des listes ACL ?

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

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

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

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

Pourquoi vois-je parfois des GUID dans les ACL ?

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

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

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

Voir aussi

Commentaires

Ressources supplémentaires

Partager via

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

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

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

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

Niveaux d’autorisation

Formes abrégées des autorisations

Héritage des autorisations

Scénarios courants liés aux autorisations de liste de contrôle d'accès

Suppression de fichiers et de répertoires

Utilisateurs et identités

Le super utilisateur

L’utilisateur propriétaire

Le groupe propriétaire

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

Modification du groupe propriétaire

Évaluation des autorisations

Le masque

Le sticky bit

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

umask

Forum aux questions

Dois-je activer la prise en charge des ACL ?

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

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

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

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

Data Lake Storage prend-il en charge l’héritage des listes ACL ?

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

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

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

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

Pourquoi vois-je parfois des GUID dans les ACL ?

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

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

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

Voir aussi

Commentaires

Ressources supplémentaires