Zugriffssteuerung in Azure Data Lake Storage Gen1

Azure Data Lake Storage Gen1 implementiert ein Zugriffssteuerungsmodell, das von HDFS abgeleitet wird, das wiederum vom POSIX-Zugriffssteuerungsmodell abgeleitet wird. In diesem Artikel werden die Grundlagen des Zugriffssteuerungsmodells für Data Lake Storage Gen1 zusammengefasst.

Zugriffssteuerungslisten in Dateien und Ordnern

Es gibt zwei Arten von Zugriffssteuerungslisten (ACLs), Zugriffs-ACLs und Standard-ACLs.

• Access ACLs: Diese steuern den Zugriff auf ein Objekt. Dateien und Ordner verfügen über Zugriffs-ACLs.

• Standard-ACLs: Eine "Vorlage" von ACLs, die einem Ordner zugeordnet sind und die Access-ACLs für alle untergeordneten Elemente bestimmen, die in diesem Ordner erstellt werden. Dateien verfügen nicht über Standard-ACLs.

Sowohl Access-ACLs als auch Standard-ACLs weisen die gleiche Struktur auf.

Erlaubnisse

Die Berechtigungen für ein Dateisystemobjekt sind "Lesen", " Schreiben" und "Ausführen", und sie können in Dateien und Ordnern verwendet werden, wie in der folgenden Tabelle gezeigt:

Kurzformen für Berechtigungen

RWX steht für Lesen (Read), Schreiben (Write) und Ausführen (Execute) . Es gibt auch ein noch kürzeres numerisches Format. Hierbei steht 4 für Lesen, 2 für Schreiben und 1 für Ausführen, und Berechtigungen werden als Summe dieser Werte angegeben. Hier einige Beispiele.

Berechtigungen erben nicht

Im POSIX-Formatmodell, das von Data Lake Storage Gen1 verwendet wird, werden Berechtigungen für ein Element selbst auf dem Element gespeichert. Mit anderen Worten: Berechtigungen für ein Element können nicht von den übergeordneten Elementen geerbt werden.

Allgemeine Szenarien im Zusammenhang mit Berechtigungen

Im Folgenden finden Sie einige häufige Szenarien, die Ihnen helfen, zu verstehen, welche Berechtigungen zum Ausführen bestimmter Vorgänge für ein Data Lake Storage Gen1-Konto erforderlich sind.

Benutzer und Identitäten

Jede Datei und jeder Ordner verfügt über unterschiedliche Berechtigungen für diese Identitäten:

• Der Eigentümer-Benutzer
• Die besitzende Gruppe
• Benannte Benutzer
• Benannte Gruppen
• Alle anderen Benutzer

Die Identitäten von Benutzern und Gruppen sind Microsoft Entra-Identitäten. Sofern nicht anders angegeben, kann ein "Benutzer" im Kontext von Data Lake Storage Gen1 entweder einen Microsoft Entra-Benutzer oder eine Microsoft Entra-Sicherheitsgruppe bedeuten.

Superuser

Ein Superbenutzer hat die meisten Rechte aller Benutzer im Data Lake Storage Gen1-Konto. Ein Superuser:

• Er besitzt RWX-Berechtigungen für alle Dateien und Ordner.
• Er kann die Berechtigungen für jede Datei und jeden Ordner ändern.
• Er kann den zuständigen Benutzer und die zuständige Gruppe einer beliebigen Datei und eines beliebigen Ordners ändern.

Alle Benutzer, die Teil der Rolle "Besitzer " für ein Data Lake Storage Gen1-Konto sind, sind automatisch ein Superbenutzer.

Der zuständige Benutzer

Der Benutzer, der das Element erstellt hat, ist automatisch der zuständige Benutzer für das Element. Der zuständige Benutzer hat folgende Möglichkeiten:

• Er kann die Berechtigungen einer Datei ändern, für die er als Besitzer fungiert.
• Er kann die zuständige Gruppe einer Datei ändern, für die er als Besitzer fungiert, solange der zuständige Benutzer auch der Zielgruppe angehört.

Die besitzende Gruppe

Hintergrund

In den POSIX ACLs ist jeder Benutzer einer "primären Gruppe" zugeordnet. Beispielsweise kann der Benutzer "alice" zur Gruppe "Finanzen" gehören. Alice gehört möglicherweise auch zu mehreren Gruppen, aber eine Gruppe wird immer als ihre primäre Gruppe festgelegt. Wenn Alice in POSIX eine Datei erstellt, wird die besitzende Gruppe dieser Datei auf ihre primäre Gruppe festgelegt, in diesem Fall „Finanzen“. Die besitzende Gruppe verhält sich andernfalls ähnlich wie zugewiesene Berechtigungen für andere Benutzer/Gruppen.

Da Benutzern in Data Lake Storage Gen1 keine "primäre Gruppe" zugeordnet ist, wird die Eigentümergruppe wie unten beschrieben zugewiesen.

Zuweisen der eigenen Gruppe für eine neue Datei oder einen neuen Ordner

• Fall 1: Der Stammordner "/". Dieser Ordner wird erstellt, wenn ein Data Lake Storage Gen1-Konto erstellt wird. In diesem Fall wird die Besitzergruppe auf eine GUID mit allen Nullen festgelegt. Dieser Wert lässt keinen Zugriff zu. Es handelt sich um einen Platzhalter, bis eine Solche Gruppe zugewiesen wird.
• Fall 2 (Alle anderen Fälle): Wenn ein neues Element erstellt wird, wird die eigene Gruppe aus dem übergeordneten Ordner kopiert.

Ändern der Besitzergruppe

Die zuständige Gruppe kann von folgenden Benutzern geändert werden:

• Beliebige Superbenutzer
• Der verantwortliche Benutzer, wenn der verantwortliche Benutzer auch Mitglied der Zielgruppe ist.

Zugriffsüberprüfungsalgorithmus

Der folgende Pseudocode stellt den Zugriffsüberprüfungsalgorithmus für Data Lake Storage Gen1-Konten dar.

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)

Die Maske

Wie im Zugriffsüberprüfungsalgorithmus dargestellt, schränkt die Maske den Zugriff auf benannte Benutzer, die Besitzergruppe und benannte Gruppen ein.

Das Sticky Bit

Das Sticky-Bit ist ein komplexeres Feature eines POSIX-Dateisystems. Im Kontext von Data Lake Storage Gen1 ist es unwahrscheinlich, dass das Sticky-Bit benötigt wird. Wenn das Sticky-Bit in einem Ordner aktiviert ist, kann ein untergeordnetes Element nur vom eigenen Benutzer des untergeordneten Elements gelöscht oder umbenannt werden.

Das klebige Bit wird nicht im Azure-Portal angezeigt.

Standardberechtigungen für neue Dateien und Ordner

Wenn eine neue Datei oder ein neuer Ordner unter einem vorhandenen Ordner erstellt wird, bestimmt die Standard-ACL im übergeordneten Ordner Folgendes:

• Standard-ACL und Access-ACL eines untergeordneten Ordners.
• Die Zugriffs-ACL einer untergeordneten Datei (Dateien haben keine Standard-ACL).

umask

Beim Erstellen einer Datei oder eines Ordners wird umask verwendet, um zu ändern, wie die Standard-ACLs für das untergeordnete Element festgelegt werden. umask ist ein 9-Bit-Wert für übergeordnete Ordner, der einen RWX-Wert für den besitzenden Benutzer, die besitzende Gruppe und andere enthält.

Der Umask für Azure Data Lake Storage Gen1 ist auf den konstanten Wert 007 festgelegt. Dieser Wert entspricht

Der von Azure Data Lake Storage Gen1 verwendete Umask-Wert bedeutet effektiv, dass Berechtigungen für andere standardmäßig nie auf neue Dateien oder Verzeichnisse gewährt werden – unabhängig davon, was die Standard-ACL angibt.

Der folgende Pseudocode zeigt, wie der Umask beim Erstellen der ACLs für ein untergeordnetes Element angewendet wird.

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 )

Allgemeine Fragen zu ACLs in Data Lake Storage Gen1

Muss ich die Unterstützung für ACLs aktivieren?

Nein. Die Zugriffssteuerung über ACLs ist für ein Data Lake Storage Gen1-Konto immer aktiviert.

Welche Berechtigungen sind erforderlich, um einen Ordner und dessen Inhalt rekursiv zu löschen?

• Der übergeordnete Ordner muss über Schreib- und Ausführungsberechtigungen verfügen.
• Der zu löschende Ordner und jeder Ordner darin erfordert Lese-+Schreib-+Ausführen-Berechtigungen .

Wer ist der Besitzer einer Datei oder eines Ordners?

Der Ersteller einer Datei oder eines Ordners wird der Besitzer.

Welche Gruppe wird bei der Erstellung als Besitzergruppe einer Datei oder eines Ordners festgelegt?

Die Eigentümergruppe wird von der Eigentümergruppe des übergeordneten Ordners kopiert, unter dem die neue Datei oder der neue Ordner erstellt wird.

Ich bin der Besitzer einer Datei, aber ich habe nicht die erforderlichen RWX-Berechtigungen. Was soll ich tun?

Der zuständige Benutzer kann die Berechtigungen der Datei ändern und sich so selbst die erforderlichen RWX-Berechtigungen gewähren.

Wenn ich ACLs im Azure-Portal sehe, sehe ich Benutzernamen, aber über APIs sehe ich GUIDs, warum ist das?

Einträge in den ACLs werden als GUIDs gespeichert, die Benutzern in der Microsoft Entra-ID entsprechen. Die APIs geben die GUIDs wie folgt zurück. Das Azure-Portal versucht, die Verwendung von ACLs benutzerfreundlicher zu gestalten, indem die GUIDs nach Möglichkeit in vertraute Namen übersetzt werden.

Warum werden GUIDs manchmal in den ACLs angezeigt, wenn ich das Azure-Portal verwende?

Eine GUID wird angezeigt, wenn der Benutzer nicht mehr in Microsoft Entra vorhanden ist. Dies ist meist der Fall, wenn der Benutzer aus dem Unternehmen ausgeschieden ist oder sein Konto in Microsoft Entra ID gelöscht wurde. Stellen Sie außerdem sicher, dass Sie die richtige ID zum Festlegen von ACLs verwenden (Details unten).

Welche ID sollte ich verwenden, um ACLs festzulegen, wenn der Dienst-Principal verwendet wird?

Wechseln Sie im Azure-Portal zu Microsoft Entra ID –> Unternehmensanwendungen , und wählen Sie Ihre Anwendung aus. Auf der Registerkarte "Übersicht " sollte eine Objekt-ID angezeigt werden, und dies sollte beim Hinzufügen von ACLs für den Datenzugriff (und nicht bei der Anwendungs-ID) verwendet werden.

Unterstützt Data Lake Storage Gen1 die Vererbung von ACLs?

Nein, aber Standard-ACLs können verwendet werden, um ACLs für untergeordnete Dateien und Ordner festzulegen, die neu unter dem übergeordneten Ordner erstellt wurden.

Welche Grenzwerte gelten für ACL-Einträge in Dateien und Ordnern?

32 ACLs können pro Datei und pro Verzeichnis festgelegt werden. Es gibt jeweils ein eigenes Limit von 32 Einträgen für Zugriffs- und Standard-ACLs. Verwenden Sie nach Möglichkeit Sicherheitsgruppen für ACL-Zuordnungen. Durch die Verwendung von Gruppen ist es weniger wahrscheinlich, die maximale Anzahl von ACL-Einträgen pro Datei oder Verzeichnis zu überschreiten.

Wo finde ich weitere Informationen zum POSIX-Zugriffssteuerungsmodell?

• POSIX-Zugriffssteuerungslisten (ACLs) unter Linux
• HDFS Permission Guide (Handbuch zu HDFS-Berechtigungen)
• POSIX FAQ (Häufig gestellte Fragen zu POSIX)
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• POSIX-ACL unter Ubuntu

Siehe auch

• Übersicht über Azure Data Lake Storage Gen1