Contrôle d’accès dans Azure Data Lake Storage Gen1

Azure Data Lake Storage Gen1 implémente un modèle de contrôle d’accès dérivé de HDFS, qui dérive à son tour du modèle de contrôle d’accès POSIX. Cet article récapitule les principes de base du modèle de contrôle d’accès pour Data Lake Storage Gen1.

Listes de contrôle d’accès sur les fichiers et dossiers

Il existe deux types de listes de contrôle d’accès (ACL), des listes de contrôle d’accès et des listes de contrôle d’accès par défaut.

• Listes de contrôle d'accès (ACL) : elles contrôlent l'accès à un objet. Les fichiers et les dossiers ont tous deux des listes de contrôle d’accès.

• Listes de contrôle d’accès par défaut : « modèle » de listes de contrôle d’accès associées à un dossier qui détermine les listes de contrôle d’accès pour tous les éléments enfants créés sous ce dossier. Les fichiers n’ont pas de listes de contrôle d’accès par défaut.

Les listes de contrôle d’accès et les listes de contrôle d’accès par défaut ont la même structure.

Autorisations

Les autorisations sur un objet de système de fichiers sont En lecture, écriture et exécution, et elles peuvent être utilisées sur des fichiers et des dossiers, comme indiqué dans le tableau suivant :

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.

Les autorisations n’héritent pas

Dans le modèle de style POSIX utilisé par Data Lake Storage Gen1, les autorisations d’un élément sont stockées sur l’élément lui-même. En d’autres termes, les autorisations d’un élément ne peuvent pas être héritées des éléments parents.

Scénarios courants liés aux autorisations

Voici quelques scénarios courants pour vous aider à comprendre les autorisations nécessaires pour effectuer certaines opérations sur un compte Data Lake Storage Gen1.

Utilisateurs et identités

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

• L’utilisateur propriétaire
• Le groupe propriétaire
• Les utilisateurs nommés
• Les groupes nommés
• Tous les autres utilisateurs

Les identités des utilisateurs et des groupes sont des identités associées à Microsoft Entra. Ainsi, sauf indication contraire, un « utilisateur » dans le contexte de Data Lake Storage Gen1, peut signifier un utilisateur Microsoft Entra ou un groupe de sécurité Microsoft Entra.

Le super utilisateur

Un super-utilisateur a le plus de droits de tous les utilisateurs dans le compte Data Lake Storage Gen1. 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.

Tous les utilisateurs qui font partie du rôle Propriétaires d’un compte Data Lake Storage Gen1 sont automatiquement un super-utilisateur.

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 d'un fichier dont vous êtes le propriétaire.
• 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

Arrière-plan

Dans les listes de contrôle d’accès POSIX, chaque utilisateur est associé à un « groupe principal ». Par exemple, l’utilisateur « alice » peut appartenir au groupe « finance ». Alice peut également 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.

Étant donné qu’il n’existe aucun « groupe principal » associé aux utilisateurs dans Data Lake Storage Gen1, le groupe propriétaire est affecté comme indiqué ci-dessous.

Affectation du groupe propriétaire pour un nouveau fichier ou dossier

• Cas 1 : Dossier racine « / ». Ce dossier est créé lorsqu’un compte Data Lake Storage Gen1 est créé. Dans ce cas, le groupe propriétaire est défini sur un GUID composé uniquement de zéros. Cette valeur n’autorise aucun accès. Il s’agit d’un espace réservé jusqu’à ce qu’un groupe soit affecté.
• Cas 2 (Tous les autres cas) : lorsqu’un nouvel élément est créé, le groupe propriétaire est copié à partir du dossier 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.

Algorithme de vérification d’accès

Le pseudocode suivant représente l’algorithme de vérification d’accès pour les comptes Data Lake Storage Gen1.

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 folder
  # Note: the "sticky bit" is not illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask IS NOT 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.permmissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
      member_count += 1
      perms | =  entry.permissions
  if (member_count>0) :
    return ((desired_perms & perms & mask ) == desired_perms)
 
  # 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 d’accès, le masque limite l’accès pour les utilisateurs nommés, le groupe propriétaire et les groupes nommés.

Le sticky bit

Le bit sticky est une fonctionnalité plus avancée d’un système de fichiers POSIX. Dans le contexte de Data Lake Storage Gen1, il est peu probable que le bit collant soit nécessaire. En résumé, si le bit sticky est activé sur un dossier, un élément enfant ne peut être supprimé ou renommé que par l’utilisateur propriétaire de l’élément enfant.

Le bit collant n’est pas affiché dans le portail Azure.

Autorisations par défaut sur les nouveaux fichiers et dossiers

Lorsqu’un nouveau fichier ou dossier est créé sous un dossier existant, la liste de contrôle d’accès par défaut sur le dossier parent détermine :

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

umask

Lors de la création d’un fichier ou d’un dossier, umask est utilisé pour modifier la façon dont les listes de contrôle d’accès par défaut sont définies sur l’élément enfant. umask est une valeur 9 bits sur les dossiers parents qui contient une valeur RWX pour l'utilisateur propriétaire, le groupe propriétaire et les autres.

La valeur umask pour Azure Data Lake Storage Gen1 est constamment fixée à 007. Cette valeur se traduit par

La valeur umask utilisée par Azure Data Lake Storage Gen1 signifie efficacement que la valeur d’autres n’est jamais transmise par défaut sur les nouveaux enfants, quelle que soit la liste de contrôle d’accès par défaut.

Le pseudocode suivant montre comment l’umask est appliqué lors de la création des ACL pour un élément enfant.

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

Questions courantes sur les listes de contrôle d’accès dans Data Lake Storage Gen1

Dois-je activer la prise en charge des ACL ?

Non. Le contrôle d’accès via les listes de contrôle d’accès est toujours activé pour un compte Data Lake Storage Gen1.

Quelles autorisations sont requises pour supprimer de manière récursive un dossier et son contenu ?

• Le dossier parent doit disposer d’autorisations Write + Execute .
• Le dossier à supprimer et chaque dossier dans celui-ci nécessite des autorisations Lecture + Écriture + Exécution .

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

Le créateur d’un fichier ou d’un dossier devient le propriétaire.

Quel groupe est défini comme groupe propriétaire d’un fichier ou d’un dossier lors de la création ?

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

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

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

Quand je regarde les listes de contrôle d’accès dans le portail Azure, je vois des noms d’utilisateur, mais par le biais d’API, je vois des GUID, pourquoi ?

Les entrées des listes de contrôle d’accès sont stockées en tant que GUID qui correspondent aux utilisateurs dans Microsoft Entra ID. Les API retournent les GUID comme c’est le cas. Le portail Azure tente de faciliter l’utilisation des listes de contrôle d’accès en convertissant les GUID en noms conviviaux lorsque cela est possible.

Pourquoi est-ce que je vois parfois des GUID dans les listes de contrôle d’accès quand j’utilise le portail Azure ?

Un GUID s’affiche lorsque l’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. Vérifiez également que vous utilisez l’ID approprié pour définir des listes de contrôle d’accès (détails en question ci-dessous).

Lors de l’utilisation du principal de service, quel ID dois-je utiliser pour définir des listes de contrôle d’accès ?

Dans le portail Azure, accédez à Microsoft Entra ID -> Applications d’entreprise et sélectionnez votre application. L’onglet Vue d’ensemble doit afficher un ID d’objet et il s’agit de ce qui doit être utilisé lors de l’ajout de listes de contrôle d’accès aux données (et non d’ID d’application).

Data Lake Storage Gen1 prend-il en charge l’héritage des listes de contrôle d’accès ?

Non, mais les listes de contrôle d’accès par défaut peuvent être utilisées pour définir des listes de contrôle d’accès pour les fichiers enfants et le dossier nouvellement créés sous le dossier parent.

Quelles sont les limites des entrées des listes de contrôle d’accès sur les fichiers et dossiers ?

32 ACL peuvent être définies par fichier et par répertoire. Les ACL d’accès et par défaut disposent chacune de leur propre limite d’entrée de 32 ACL. Si possible, utilisez des groupes de sécurité pour les affectations de liste de contrôle d'accès (ACL). En utilisant des groupes, vous êtes moins susceptible de dépasser le nombre maximal d’entrées ACL par fichier ou répertoire.

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

• Vue d’ensemble d’Azure Data Lake Storage Gen1