Zugriffssteuerungslisten (ACLs) in Azure Data Lake Storage

Azure Data Lake Storage implementiert ein Zugriffssteuerungsmodell, das sowohl die rollenbasierte Zugriffssteuerung in Azure (Azure RBAC) als auch POSIX-ähnliche Zugriffssteuerungslisten (ACLs) unterstützt. In diesem Artikel werden Zugriffssteuerungslisten in Data Lake Storage beschrieben. Informationen dazu, wie Sie Azure RBAC zusammen mit ACLs einbinden und wie diese vom System zum Treffen der Autorisierungsentscheidungen ausgewertet werden, finden Sie unter Zugriffssteuerungsmodell in Azure Data Lake Storage.

Informationen zu ACLs

Sie können einem Sicherheitsprinzipal eine Zugriffsebene für Dateien und Verzeichnisse zuordnen. Jede Zuordnung wird als Eintrag in einer Zugriffssteuerungsliste (Access Control List, ACL) erfasst. Jede Datei und jedes Verzeichnis in Ihrem Speicherkonto verfügt über eine Zugriffssteuerungsliste. Wenn ein Sicherheitsprinzipal einen Vorgang für eine Datei oder ein Verzeichnis durchführen möchte, wird per ACL-Überprüfung ermittelt, ob dieser Sicherheitsprinzipal (Benutzer, Gruppe, Dienstprinzipal oder verwaltete Identität) über die richtige Berechtigungsstufe für die Durchführung des Vorgangs verfügt.

Festlegen von ACLs

Informationen zum Festlegen von Berechtigungen auf Datei- und Verzeichnisebene finden Sie in den folgenden Artikeln:

Arten von ACLs

Es gibt zwei Arten von Zugriffssteuerungslisten: Zugriffs-ACLs und Standard-ACLs.

Zugriffs-ACLs steuern den Zugriff auf ein Objekt. Dateien und Verzeichnisse verfügen jeweils über Zugriffs-ACLs.

Standard-ACLs sind Vorlagen von ACLs, die einem Verzeichnis zugeordnet sind, das die Zugriffs-ACLs für alle unter diesem Verzeichnis erstellten untergeordneten Elemente festlegt. Dateien verfügen über keine Standard-ACLs.

Zugriffs- und Standard-ACLs haben die gleiche Struktur.

Berechtigungsebenen

Die Berechtigungen für Verzeichnisse und Dateien in einem Container sind Lesen, Schreiben und Ausführen. Sie können wie in der folgenden Tabelle beschrieben auf Dateien und Verzeichnisse 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.

Vererbung von Berechtigungen

Im von Data Lake Storage 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, wenn die Berechtigungen erst nach der Erstellung des untergeordneten Elements festgelegt werden. Berechtigungen werden nur dann geerbt, wenn für die übergeordneten Elemente Standardberechtigungen festgelegt wurden, bevor die untergeordneten Elemente erstellt werden.

Häufige Szenarien in Bezug auf ACL-Berechtigungen

Die folgende Tabelle enthält die ACL-Einträge, die benötigt werden, damit ein Sicherheitsprinzipal die in der Spalte Vorgang aufgeführten Vorgänge durchführen kann.

Diese Tabelle enthält eine Spalte, die die einzelnen Ebenen einer fiktiven Verzeichnishierarchie darstellt. Es gibt eine Spalte für das Stammverzeichnis des Containers (/), ein Unterverzeichnis mit dem Namen Oregon, ein Unterverzeichnis des Verzeichnisses „Oregon“ namens Portland und eine Textdatei im Verzeichnis „Portland“ mit dem Namen Data.txt.

Löschen von Dateien und Verzeichnissen

Wie in der vorherigen Tabelle gezeigt, sind Schreibberechtigungen für die Datei nicht erforderlich, um sie zu löschen, wenn die Verzeichnisberechtigungen korrekt eingestellt sind. Um jedoch ein Verzeichnis und seinen gesamten Inhalt zu löschen, muss das übergeordnete Verzeichnis über Schreib- und Ausführungsberechtigungen verfügen. Das zu löschende Verzeichnis und alle darin enthaltenen Verzeichnisse müssen über Lese-, Schreib- und Ausführungsberechtigungen verfügen.

Benutzer und Identitäten

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

• Der zuständige Benutzer
• Die zuständige Gruppe
• Benannte Benutzer
• Benannte Gruppen
• Benannte Dienstprinzipale
• Benannte verwaltete Identitäten
• Alle anderen Benutzer

Die Identitäten von Benutzern und Gruppen sind Microsoft Entra-Identitäten. Sofern nicht anderes angegeben, kann ein Benutzer im Data Lake Storage-Kontext also ein Benutzer, ein Dienstprinzipal, eine verwaltete Identität oder eine Sicherheitsgruppe in Microsoft Entra sein.

Administrator

Ein Superuser hat die meisten Rechte von allen Benutzern. 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.

Wenn ein Container, eine Datei oder ein Verzeichnis mithilfe eines gemeinsam verwendeten Schlüssels, einer Konto-SAS oder Dienst-SAS erstellt wird, werden der Besitzer und die zuständige Gruppe auf $superuser festgelegt.

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

In den POSIX-Zugriffssteuerungslisten ist jeder Benutzer einer primären Gruppe zugeordnet. So kann beispielsweise der Benutzer „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.

Zuweisen der zuständigen Gruppe für eine neue Datei oder ein neues Verzeichnis

• Fall 1: Das Stammverzeichnis /. Dieses Verzeichnis wird erstellt, wenn ein Data Lake Storage-Container erstellt wird. In diesem Fall wird die zuständige Gruppe auf den Benutzer festgelegt, der den Container erstellt hat, sofern dies mithilfe von OAuth erfolgt ist. Wenn der Container mithilfe eines gemeinsam verwendeten Schlüssels, einer Konto-SAS oder Dienst-SAS erstellt wird, werden der Besitzer und die zuständige Gruppe auf $superuser festgelegt.
• Fall 2 (jeder andere Fall): Beim Erstellen eines neuen Elements wird die zuständige Gruppe aus dem übergeordneten Verzeichnis 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

Auswerten von Berechtigungen

Identitäten werden in der folgenden Reihenfolge ausgewertet:

1. Superuser
2. zuständige Benutzer
3. Benannter Benutzer, Dienstprinzipal oder verwaltete Identität
4. Besitzende Gruppe oder benannte Gruppe
5. Alle anderen Benutzer

Wenn ein Sicherheitsprinzipal mehrere Identitäten innehat, wird die der ersten Identität zugeordnete Berechtigungsstufe zugewiesen. Wenn beispielsweise ein Sicherheitsprinzipal gleichzeitig der zuständige Benutzer und der benannte Benutzer ist, wird ihm die dem zuständigen Benutzer zugeordnete Berechtigungsstufe zugewiesen.

Benannte Gruppen werden alle gemeinsam berücksichtigt. Wenn ein Sicherheitsprinzipal Mitglied mehrerer benannter Gruppen ist, wertet das System jede Gruppe aus, bis die gewünschte Berechtigung erteilt wird. Wenn keine der genannten Gruppen die gewünschte Berechtigung bereitstellt, geht das System dazu über, eine Anforderung anhand der Berechtigung auszuwerten, die allen anderen Benutzern zugeordnet ist.

Im folgenden Pseudocode wird der Zugriffsüberprüfungsalgorithmus für Speicherkonten veranschaulicht. Mit diesem Algorithmus wird die Reihenfolge angezeigt, in der die Identitäten ausgewertet werden.

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)

Die Maske

Die Maske gilt nur für den ACL-Eintrag eines benannten Benutzenden, einer benannten Gruppe und der eigenen Gruppe. Die Maske gibt an, welche der Berechtigungen im ACL-Eintrag verwendet werden, um den Zugriff zu autorisieren. Diese angewendeten Berechtigungen werden als effektive Berechtigungen des ACL-Eintrags bezeichnet. Alle anderen Berechtigungen im ACL-Eintrag werden ignoriert. Mithilfe der Maske können Sie eine Obergrenze für Berechtigungsstufen festlegen.

Die Maske kann aufrufbezogen festgelegt werden. Dies ermöglicht verschiedenen verarbeitenden Systemen, wie beispielsweise Clustern, für ihre Dateivorgänge unterschiedliche effektive Masken zu verwenden. Wenn eine Maske für eine bestimmte Anforderung angegeben wird, überschreibt sie die Standardmaske vollständig.

Das Sticky Bit

Das Sticky Bit ist ein erweitertes Feature eines POSIX-Containers. Im Kontext von Data Lake Storage wird das Sticky Bit höchstwahrscheinlich nicht benötigt. Kurz gefasst kann ein untergeordnetes Element nur vom jeweiligen zuständigen Benutzer, dem Verzeichnisbesitzer oder dem Superuser ($superuser) gelöscht oder umbenannt werden, wenn das Sticky Bit für ein Verzeichnis aktiviert ist.

Das Sticky Bit wird im Azure-Portal nicht angezeigt. Weitere Informationen zum Sticky Bit und seiner Festlegung finden Sie unter Was ist das Sticky Bit in Data Lake Storage?.

Standardberechtigungen des Stammverzeichnisses

Bei einem neuen Data Lake Storage-Container wird die Zugriffs-ACL des Stammverzeichnisses („/“) für Verzeichnisse standardmäßig auf 750 und für Dateien auf 640 festgelegt. In der folgenden Tabelle ist die Symbolnotation dieser Berechtigungsstufen angegeben.

Dateien erhalten nicht das X-Bit, da es für Dateien in einem reinen Speichersystem irrelevant ist.

Standardberechtigungen für neue Dateien und Verzeichnisse

Wenn in einem bereits vorhandenen Verzeichnis eine neue Datei oder ein Verzeichnis erstellt wird, bestimmt die Standard-ACL des übergeordneten Verzeichnisses Folgendes:

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

umask

Beim Erstellen einer Standard-ACL wird „umask“ auf die Zugriffs-ACL angewendet, um die anfänglichen Berechtigungen einer Standard-ACL zu ermitteln. Wenn eine Standard-ACL für das übergeordnete Verzeichnis definiert ist, wird „umask“ effektiv ignoriert, und die Standard-ACL des übergeordneten Verzeichnisses wird verwendet, um stattdessen diese anfänglichen Werte zu definieren.

„umask“ ist ein 9-Bit-Wert für übergeordnete Verzeichnisse, der einen RWX-Wert für den zuständigen Benutzer, die zuständige Gruppe und andere enthält.

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

Häufig gestellte Fragen

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

Nein. Die Zugriffssteuerung über ACLs ist für ein Speicherkonto so lange aktiviert, wie die Funktion „Hierarchischer Namespace“ (HNS) aktiviert ist.

Wenn HNS deaktiviert ist, gelten weiterhin die RBAC-Autorisierungsregeln von Azure.

Wie werden ACLs am besten angewendet?

Verwenden Sie Microsoft Entra-Sicherheitsgruppen stets als den zugewiesenen Prinzipal in einem ACL-Eintrag. Widerstehen Sie der Möglichkeit, einzelne Benutzer oder Dienstprinzipale direkt zuzuweisen. Die Verwendung dieser Struktur ermöglicht Ihnen, Benutzer oder Dienstprinzipale hinzuzufügen und zu entfernen, ohne dass Sie ACLs erneut auf eine gesamte Verzeichnisstruktur anwenden müssen. Stattdessen können Sie Benutzer und Dienstprinzipale zur entsprechenden Microsoft Entra-Sicherheitsgruppe hinzufügen oder aus dieser entfernen.

Es gibt viele verschiedene Möglichkeiten zum Einrichten von Gruppen. Angenommen, Sie haben ein Verzeichnis namens /LogData, das Protokolldaten enthält, die von Ihrem Server generiert werden. Azure Data Factory (ADF) erfasst Daten in diesem Ordner. Bestimmte Benutzer aus dem IT-Support-Team laden Protokolle hoch und verwalten andere Benutzer dieses Ordners, und in verschiedenen Databricks-Clustern werden die Protokolle aus diesem Ordner analysiert.

Um diese Aktivitäten zu aktivieren, können Sie eine LogsWriter-Gruppe und eine LogsReader-Gruppe erstellen. Anschließend können Sie die Berechtigungen wie folgt zuweisen:

• Fügen Sie die LogsWriter-Gruppe zur ACL des Verzeichnisses /LogData mit rwx-Berechtigungen hinzu.
• Fügen Sie die LogsReader-Gruppe zur ACL des Verzeichnisses /LogData mit r-x-Berechtigungen hinzu.
• Fügen Sie das Dienstprinzipalobjekt oder die verwaltete Dienstidentität (Managed Service Identity, MSI) für ADF zur LogsWriters-Gruppe hinzu.
• Fügen Sie Benutzer aus dem IT-Support-Team zur LogsWriter-Gruppe hinzu.
• Fügen Sie das Dienstprinzipalobjekt oder die MSI für Databricks zur LogsReader-Gruppe hinzu.

Wenn ein Benutzer des IT-Support-Teams das Unternehmen verlässt, können Sie ihn einfach aus der LogsWriter-Gruppe entfernen. Wenn Sie diesen Benutzer nicht zu einer Gruppe hinzugefügt, sondern stattdessen einen dedizierten ACL-Eintrag für den Benutzer hinzugefügt hätten, müssten Sie diesen ACL-Eintrag aus dem /LogData- -Verzeichnis entfernen. Außerdem müssten Sie den Eintrag aus allen Unterverzeichnissen und Dateien in der gesamten Verzeichnishierarchie des /LogData-Verzeichnisses entfernen.

Um eine Gruppe zu erstellen und Mitglieder hinzuzufügen, finden Sie weitere Informationen unter Erstellen einer Basisgruppe und Hinzufügen von Mitgliedern mithilfe von Microsoft Entra ID.

Wie werden Azure RBAC- und ACL-Berechtigungen ausgewertet?

Informationen dazu, wie Azure RBAC und ACLs gemeinsam ausgewertet werden, um Autorisierungsentscheidungen für Speicherkontoressourcen treffen zu können, finden Sie unter Auswerten von Berechtigungen.

Welche Grenzwerte gelten für Azure-Rollenzuweisungen und ACL-Einträge?

Die folgende Tabelle enthält eine Zusammenfassung der Grenzwerte, die Sie beim Verwenden von Azure RBAC zum Verwalten von „groben“ Berechtigungen (für Speicherkonten oder Container) und von ACLs zum Verwalten von „präzisen“ Berechtigungen (für Dateien und Verzeichnisse) berücksichtigen sollten. Verwenden Sie Sicherheitsgruppen für ACL-Zuweisungen. Wenn Sie Gruppen verwenden, ist es weniger wahrscheinlich, dass die maximale Anzahl von Rollenzuweisungen pro Abonnement und die maximale Anzahl von ACL-Einträgen pro Datei oder Verzeichnis überschritten werden.

Unterstützt Data Lake Storage die Vererbung von Azure RBAC?

Azure-Rollenzuweisungen werden vererbt. Zuweisungen werden aus Abonnement-, Ressourcengruppen und Speicherkontenressourcen an die Containerressource übertragen.

Unterstützt Data Lake Storage die Vererbung von ACLs?

Standard-ACLs können zum Festlegen von ACLs für neue untergeordnete Unterverzeichnisse und Dateien verwendet werden, die im übergeordneten Verzeichnis erstellt wurden. Zum Aktualisieren von ACLs für vorhandene untergeordnete Elemente müssen Sie ACLs für die gewünschte Verzeichnishierarchie rekursiv hinzufügen, aktualisieren oder entfernen. Eine Anleitung hierzu finden Sie in diesem Artikel im Abschnitt Festlegen von ACLs.

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

• Der Aufrufer verfügt über die Berechtigung „super-user“.

oder

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

Wer ist der Besitzer einer Datei oder eines Verzeichnisses?

Der Ersteller einer Datei oder eines Verzeichnisses wird als Besitzer festgelegt. Im Falle des Stammverzeichnisses ist dies die Identität des Benutzers, der den Container erstellt hat.

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

Die zuständige Gruppe wird aus der zuständigen Gruppe des übergeordneten Verzeichnisses kopiert, in dem die neue Datei oder das neue Verzeichnis 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.

Warum werden im Portal mitunter GUIDs in ACLs angezeigt?

Eine GUID wird angezeigt, wenn der Eintrag einen Benutzer darstellt, der in Microsoft Entra ID nicht mehr 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. Darüber hinaus haben Dienstprinzipale und Sicherheitsgruppen keinen Benutzerprinzipalnamen (UPN), um sie zu identifizieren, und werden daher durch ihr OID-Attribut (eine GUID) abgebildet. Um die ACLs zu bereinigen, löschen Sie diese GUID-Einträge manuell.

Wie lege ich ACLs für einen Dienstprinzipal richtig fest?

Beim Definieren von ACLs für Dienstprinzipale ist es wichtig, die Objekt-ID (OID) des Dienstprinzipals für die von Ihnen erstellte App-Registrierung zu verwenden. Sie müssen beachten, dass registrierte Apps über einen separaten Dienstprinzipal im jeweiligen Microsoft Entra-Mandanten verfügen. Registrierte Apps haben eine OID, die im Azure-Portal angezeigt wird, doch hat der Dienstprinzipal eine andere (davon abweichende) OID. Artikel: Mit dem Befehl az ad sp show können Sie die OID für den Dienstprinzipal abrufen, der einer App-Registrierung entspricht. Geben Sie die Anwendungs-ID als Parameter an. Es folgt ein Beispiel für das Abrufen der OID für den Dienstprinzipal, der einer App-Registrierung mit der App-ID „00001111-aaaa-2222-bbbb-3333cccc4444“ entspricht. Führen Sie in der Azure CLI den folgenden Befehl aus:

az ad sp show --id 00001111-aaaa-2222-bbbb-3333cccc4444 --query objectId

Die OID wird angezeigt.

Wenn Sie über die richtige OID für den Dienstprinzipal verfügen, wechseln Sie zur Seite Zugang verwalten im Storage-Explorer, um die OID hinzuzufügen und entsprechende Berechtigungen für die OID zuzuweisen. Wählen Sie unbedingt Speichern aus.

Kann ich die ACL eines Containers festlegen?

Nein. Ein Container verfügt nicht über eine ACL. Sie können aber die ACL für das Stammverzeichnis des Containers festlegen. Jeder Container verfügt über ein Stammverzeichnis, das den gleichen Namen wie der Container hat. Wenn der Container beispielsweise den Namen my-container hat, lautet das Stammverzeichnis my-container/.

Die Azure Storage-REST-API enthält einen Vorgang mit dem Namen Set Container ACL, der aber nicht verwendet werden kann, um die ACL oder das Stammverzeichnis eines Containers festzulegen. Stattdessen wird dieser Vorgang verwendet, um anzugeben, ob auf Blobs in einem Container mit einer anonymen Anforderung zugegriffen werden kann. Es wird empfohlen, für alle Blobdatenanforderungen eine Autorisierung zu verlangen. Weitere Informationen finden Sie unter Übersicht: Korrigieren des anonymen öffentlichen Lesezugriffs für Blob-Daten.

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

• Zugriffssteuerungsmodell in Azure Data Lake Storage