Zugriffssteuerung in Azure Data Lake Storage Gen1

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

Zugriffssteuerungslisten für Dateien und Ordner

Es gibt zwei Arten von Zugriffssteuerungslisten (Access Control Lists, ACLs): Zugriffs-ACLs und Standard-ACLs.

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

• Standard-ACLs: Hierbei handelt es sich um eine Art Vorlage für ACLs, die einem Ordner zugeordnet sind und die Zugriffs-ACLs für alle untergeordneten Elemente bestimmen, die in unter diesem Ordner erstellt werden. Dateien verfügen über keine Standard-ACLs.

Zugriffs- und Standard-ACLs besitzen die gleiche Struktur.

Berechtigungen

Die Berechtigungen für ein Dateisystemobjekt sind Lesen, Schreiben und Ausführen. Sie können wie in der folgenden Tabelle beschrieben auf Dateien und Ordner angewendet werden:

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.

Keine Vererbung bei Berechtigungen

Im von Data Lake Storage Gen1 verwendeten POSIX-basierten Modell werden Berechtigungen für ein Element direkt im Element gespeichert. Berechtigungen für ein Element können also nicht von den übergeordneten Elementen geerbt werden.

Allgemeine Szenarien im Zusammenhang mit Berechtigungen

Im Folgenden sind einige allgemeine Szenarien aufgeführt, die veranschaulichen, welche Berechtigungen zum Ausführen bestimmter Vorgänge für ein Data Lake Storage Gen1-Konto erforderlich sind.

Benutzer und Identitäten

Alle Dateien und Ordner verfügen über eigene Berechtigungen für folgende Identitäten:

• Der zuständige Benutzer
• Die zuständige 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.

Administrator

Ein Administrator verfügt über die meisten Rechte aller Benutzer im Data Lake Storage Gen1-Konto. Für einen Administrator gilt Folgendes:

• 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 der Rolle Besitzer für ein Data Lake Storage Gen1-Konto angehören, sind automatisch auch Administratoren.

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 zuständige Gruppe

Hintergrund

In den POSIX-Zugriffssteuerungslisten sind alle Benutzer*innen einer „primären Gruppe“ zugeordnet. So kann beispielsweise die Benutzerin „Alice“ der Gruppe „finance“ angehören. Alice kann außerdem mehreren Gruppen angehören, 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 den Benutzern in Data Lake Storage Gen1 keine „primäre Gruppe“ zugeordnet ist, wird die zuständige Gruppe wie unten angegeben zugewiesen.

Zuweisen der zuständigen Gruppe für eine neue Datei oder einen neuen Ordner

• 1. Fall: Der Stammordner „/“. Dieser Ordner wird erstellt, wenn ein Data Lake Storage Gen1-Konto erstellt wird. In diesem Fall wird die zuständige Gruppe auf eine GUID festgelegt, die nur aus Nullen besteht. Bei diesem Wert ist kein Zugriff zulässig. Es ist ein Platzhalter, der bis zur Zuweisung einer Gruppe gilt.
• 2. Fall (jeder andere Fall): Beim Erstellen eines neuen Elements wird die zuständige Gruppe aus dem übergeordneten Ordner kopiert.

Ändern der zuständigen Gruppe

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

• Beliebiger Administrator
• Zuständiger Benutzer, sofern er auch der Zielgruppe angehört

Algorithmus für die Zugriffsüberprüfung

Im folgenden Pseudocode wird der Zugriffsüberprüfungsalgorithmus für Data Lake Storage Gen1-Konten veranschaulicht.

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 Algorithmus für die Zugriffsüberprüfung gezeigt beschränkt die Maske den Zugriff auf benannte Benutzer, die zuständige Gruppe und benannte Gruppen.

Das Sticky Bit

Das Sticky Bit ist ein erweitertes Feature eines POSIX-Dateisystems. Im Kontext von Data Lake Storage Gen1 wird das Sticky Bit höchstwahrscheinlich nicht benötigt. Kurz gefasst kann ein untergeordnetes Element nur von den zuständigen Benutzer*innen gelöscht oder umbenannt werden, wenn das Sticky Bit für einen Ordner aktiviert ist.

Das Sticky Bit wird im Azure-Portal nicht angezeigt.

Standardberechtigungen für neue Dateien und Ordner

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

• Eine Standard- und eine Zugriffs-ACL des untergeordneten Ordners
• Eine Zugriffs-ACL der untergeordneten Datei (Dateien besitzen keine Standard-ACL)

umask

Beim Erstellen einer Datei oder eines Ordners wird „umask“ verwenden, um zu ändern, wie 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 Besitzer, Gruppe des Besitzers und Andere enthält.

Für Azure Data Lake Storage Gen1 ist „umask“ ein konstanter Wert, der auf „007“ festgelegt ist. Dieser Wert wird wie folgt übersetzt

Der umask-Wert, der von Azure Data Lake Storage Gen1 verwendet wird, bedeutet, dass der Wert für „Andere“ nie standardmäßig an untergeordnete Elemente übertragen wird, unabhängig davon, was die Standard-ACL angibt.

Im folgenden Pseudocode wird gezeigt, wie der umask-Wert angewendet wird, wenn die ACLs für ein untergeordnetes Element erstellt werden.

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 ACL-basierte Zugriffssteuerung ist für ein Data Lake Storage Gen1-Konto immer aktiviert.

Welche Berechtigungen werden zum rekursiven Löschen eines Ordners und seines Inhalts benötigt?

• Der übergeordnete Ordner muss über Schreib- und Ausführungsberechtigungen verfügen.
• Der zu löschende Ordner und alle darin enthaltenen Ordner müssen über Lese-, Schreib- und Ausführungsberechtigungen verfügen.

Wer ist der Besitzer einer Datei oder eines Ordners?

Der Ersteller einer Datei oder eines Ordners wird als Besitzer festgelegt.

Welche Gruppe wird bei der Erstellung als zuständige Gruppe einer Datei oder eines Ordners festgelegt?

Die zuständige Gruppe wird aus der zuständigen Gruppe des übergeordneten Ordners kopiert, unter dem die neue Datei oder der neue Ordner erstellt wird.

Ich bin der zuständige Benutzer einer Datei, verfüge aber nicht über die erforderlichen RWX-Berechtigungen. Wie gehe ich vor?

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

Wenn ich mir die ACLs im Azure-Portal ansehe, sehe ich dort Benutzernamen, aber über APIs werden mir GUIDs angezeigt. Warum ist das so?

Einträge in den ACLs werden als GUIDs gespeichert, die Benutzern in Microsoft Entra ID entsprechen. Die APIs geben die GUIDs unverändert zurück. Das Azure-Portal wandelt die GUIDs zur Vereinfachung der ACL-Verwendung nach Möglichkeit in benutzerfreundliche Namen um.

Warum werden im Azure-Portal manchmal GUIDs in den ACLs angezeigt?

Eine GUID wird angezeigt, wenn der Benutzer in Microsoft Entra nicht mehr vorhanden ist. In der Regel geschieht dies, wenn der Benutzer das Unternehmen verlassen hat oder wenn sein Konto in Microsoft Entra ID gelöscht wurde. Stellen Sie außerdem sicher, dass Sie die richtige ID zum Festlegen von ACLs verwenden (Informationen dazu finden Sie unter der folgenden Frage).

Welche ID sollte ich bei Verwendung des Dienstprinzipals zum Festlegen von ACLs verwenden?

Navigieren 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, die beim Hinzufügen von ACLs für den Datenzugriff zu verwenden ist (und nicht die Anwendungs-ID).

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

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

Was sind die Grenzwerte für ACL-Einträge in Dateien und Ordnern?

Pro Datei und pro Verzeichnis können 32 ACLs festgelegt werden. Für Zugriffs- und Standard-ACLs gilt jeweils ein eigener Zugriffsgrenzwert von 32 ACLs. Verwenden Sie nach Möglichkeit Sicherheitsgruppen für ACL-Zuweisungen. Durch die Verwendung von Gruppen ist es weniger wahrscheinlich, dass Sie die maximale Anzahl von ACL-Einträgen pro Datei oder Verzeichnis ü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

Weitere Informationen

• Übersicht über Azure Data Lake Storage Gen1