Zugriffssteuerungslisten (ACLs) in Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 implementiert ein Zugriffssteuerungsmodell, das sowohl die rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) in Azure als auch POSIX-ähnliche Zugriffssteuerungslisten (Access Control Lists, ACLs) unterstützt. In diesem Artikel werden Zugriffssteuerungslisten in Data Lake Storage Gen2 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 Gen2.

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.

Hinweis

ACLs gelten nur für Sicherheitsprinzipale auf demselben Mandanten und nicht für Benutzer, die die Authentifizierung per gemeinsam verwendetem Schlüssel oder SAS-Token (Shared Access Signature) nutzen. Dies liegt daran, dass dem Aufrufer keine Identität zugeordnet ist und daher keine berechtigungsbasierte Autorisierung per Sicherheitsprinzipal durchgeführt werden kann.

Festlegen von ACLs

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

Environment Artikel
Azure Storage-Explorer Verwenden von Azure Storage-Explorer zum Verwalten von Zugriffssteuerungslisten in Azure Data Lake Storage Gen2
Azure-Portal Verwenden des Azure-Portals zum Verwalten von Zugriffssteuerungslisten in Azure Data Lake Storage Gen2
.NET Verwenden von .NET zum Verwalten von Zugriffssteuerungslisten in Azure Data Lake Storage Gen2
Java Verwenden von Java zum Verwalten von Zugriffssteuerungslisten in Azure Data Lake Storage Gen2
Python Verwenden von Python zum Verwalten von Zugriffssteuerungslisten in Azure Data Lake Storage Gen2
JavaScript (Node.js) Verwenden des JavaScript SDK in Node.js zum Verwalten von Zugriffssteuerungslisten in Azure Data Lake Storage Gen2
PowerShell Verwenden von PowerShell zum Verwalten von Zugriffssteuerungslisten in Azure Data Lake Storage Gen2
Azure CLI Verwenden der Azure CLI zum Verwalten von Zugriffssteuerungslisten in Azure Data Lake Storage Gen2
REST-API Pfad – Aktualisierung

Wichtig

Wenn der Sicherheitsprinzipal ein Dienstprinzipal ist, muss die Objekt-ID des Dienstprinzipals verwendet werden, nicht die Objekt-ID der zugehörigen App-Registrierung. Um die Objekt-ID des Dienstprinzipals abzurufen, öffnen Sie die Azure-Befehlszeilenschnittstelle, und verwenden Sie diesen Befehl: az ad sp show --id <Your App ID> --query objectId. Achten Sie darauf, den Platzhalter <Your App ID> durch die App-ID der App-Registrierung zu ersetzen.

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.

Hinweis

Änderungen an der Standard-ACL für ein übergeordnetes Element haben keine Auswirkungen auf die Zugriffs- oder Standard-ACL bereits vorhandener untergeordneter Elemente.

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:

Datei Verzeichnis
Lesen (Read, R) Berechtigt zum Lesen von Dateiinhalten Erfordert Lesen und Ausführen, um den Inhalt des Verzeichnisses aufzulisten.
Schreiben (Write, W) Berechtigt zum Schreiben in eine Datei sowie zum Anfügen an eine Datei Erfordert Schreiben und Ausführen, um untergeordnete Elemente in einem Verzeichnis zu erstellen.
Ausführen (Execute, X) Hat im Kontext von Data Lake Storage Gen2 keine Bedeutung Erfordert das Durchlaufen der untergeordneten Elemente eines Verzeichnisses

Hinweis

Wenn Sie Berechtigungen ausschließlich mithilfe von Zugriffssteuerungslisten (ohne Azure RBAC) erteilen, müssen Sie zum Erteilen von Lese- oder Schreibzugriff auf eine Datei für einen Sicherheitsprinzipal dem Prinzipal die Berechtigung Ausführen für den Stammordner des Containers und für jeden Ordner in der Ordnerhierarchie erteilen, der zu der betreffenden Datei führt.

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.

Numerische Form Kurzform Bedeutung
7 RWX Lesen, Schreiben und Ausführen
5 R-X Lesen und Ausführen
4 R-- Lesen
0 --- Keine Berechtigungen

Vererbung von Berechtigungen

Im von Data Lake Storage Gen2 verwendeten POSIX-basierten Modell werden Berechtigungen für ein Element direkt im Element selbst gespeichert. Berechtigungen für ein Element können also nicht von den übergeordneten Elementen geerbt werden, wenn die Berechtigungen festgelegt werden, nachdem das untergeordnete Element bereits erstellt wurde. Berechtigungen werden nur dann geerbt, wenn für die übergeordneten Elemente Standardberechtigungen festgelegt wurden, bevor die untergeordneten Elemente erstellt werden.

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, in der die einzelnen Ebenen einer fiktiven Verzeichnishierarchie dargestellt sind. Es gibt eine Spalte für das Stammverzeichnis des Containers (/), ein Unterverzeichnis mit dem Namen /, ein Unterverzeichnis des Verzeichnisses „Oregon“ namens Portland und eine Textdatei im Verzeichnis „Portland“ mit dem Namen Data.txt.

Wichtig

Für diese Tabelle gilt die Annahme, dass Sie ausschließlich ACLs ohne Azure-Rollenzuweisungen verwenden. Eine ähnliche Tabelle, in der Azure RBAC mit ACLs kombiniert ist, finden Sie unter Berechtigungstabelle: Azure RBAC und ACL kombinieren.

Vorgang / Oregon/ Portland/ Data.txt
Lesen von „Data.txt“ --X --X --X R--
Anfügen an „Data.txt“ --X --X --X RW-
Löschen von „Data.txt“ --X --X -WX ---
Erstellen von „Data.txt“ --X --X -WX ---
Auflisten von „/“ R-X --- --- ---
List /Oregon/ --X R-X --- ---
List /Oregon/Portland/ --X --X R-X ---

Hinweis

Wenn die beiden obigen Bedingungen erfüllt sind, werden zum Löschen der Datei keine Schreibberechtigungen für die Datei benötigt.

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 Azure AD-Identitäten (Azure Active Directory). Sofern nicht anderes angegeben, kann ein Benutzer im Data Lake Storage Gen2-Kontext also ein Benutzer, ein Dienstprinzipal, eine verwaltete Identität oder eine Sicherheitsgruppe in Azure AD sein.

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.

Hinweis

Der zuständige Benutzer kann den zuständigen Benutzer einer Datei oder eines Verzeichnisses nicht ändern. Nur Administratoren können den zuständigen Benutzer einer Datei oder eines Verzeichnisses ändern.

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 Gen2-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

Hinweis

Die zuständige Gruppe kann die ACLs einer Datei oder eines Verzeichnisses nicht ändern. Im Fall des Stammordners (Fall 1 weiter oben) wird die zuständige Gruppe zwar auf den Benutzer festgelegt, der das Konto erstellt hat, für die Bereitstellung von Berechtigungen über die zuständige Gruppe ist jedoch kein einzelnes Benutzerkonto zulässig. Sie können diese Berechtigung ggf. einer gültigen Benutzergruppe zuweisen.

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.

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

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.

Für einen neuen Data Lake Storage Gen2-Container wird die Maske für 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.

Entität Verzeichnisse Dateien
zuständige Benutzer rwx rw-
zuständige Gruppe r-x r--
Andere --- ---

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

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 Gen2 wird das Sticky Bit höchstwahrscheinlich nicht benötigt. Kurz gefasst kann ein untergeordnetes Element nur vom jeweiligen zuständigen Benutzer gelöscht oder umbenannt werden, wenn das Sticky Bit für ein Verzeichnis aktiviert ist.

Das Sticky Bit wird im Azure-Portal nicht angezeigt.

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 Datei oder eines Verzeichnisses wird „umask“ verwendet, um zu ändern, wie Standard-ACLs für das untergeordnete Element festgelegt werden. „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 Gen2 ist „umask“ ein konstanter Wert, der auf „007“ festgelegt ist. Dieser Wert wird wie folgt übersetzt:

umask-Komponente Numerische Form Kurzform Bedeutung
umask.owning_user 0 --- Für zuständige Benutzer wird die Standard-ACL des übergeordneten Elements für die Zugriffs-ACL des untergeordneten Elements kopiert.
umask.owning_group 0 --- Für die zuständige Gruppe wird die Standard-ACL des übergeordneten Elements für die Zugriffs-ACL des untergeordneten Elements kopiert.
umask.other 7 RWX Für „other“ (andere) werden alle Berechtigungen für die Zugriffs-ACL des untergeordneten Elements entfernt.

Der Wert von „umask“, der von Azure Data Lake Storage Gen2 verwendet wird, bedeutet, dass der Wert für other nie standardmäßig an untergeordnete Elemente übertragen wird, sofern im übergeordneten Verzeichnis keine Standard-ACL definiert wurde. In diesem Fall wird umask ignoriert, und die von der Standard-ACL definierten Berechtigungen werden auf das untergeordnete Element angewandt.

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 )

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 in einem ACL-Eintrag immer Azure AD-Sicherheitsgruppen als den zugewiesenen Prinzipal. 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 einfach Benutzer und Dienstprinzipale zur entsprechenden Azure AD-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 LogsWriter mit rwx-Berechtigungen hinzu.
  • Fügen Sie die LogsReader-Gruppe zur ACL des Verzeichnisses LogsReader 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.

Weitere Informationen dazu, wie eine Gruppe erstellt wird und Mitglieder hinzugefügt werden, finden Sie unter Erstellen einer Basisgruppe und Hinzufügen von Mitgliedern mit Azure Active Directory.

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.

Mechanismus `Scope` Einschränkungen Unterstützte Berechtigungsebene
Azure RBAC Speicherkonten, Container.
Ressourcenübergreifende Azure-Rollenzuweisungen auf Abonnement- oder Ressourcengruppenebene.
2.000 Azure-Rollenzuweisungen in einem Abonnement Azure-Rollen (integriert oder benutzerdefiniert)
ACL Verzeichnis, Datei 32 ACL-Einträge (im Grunde 28 ACL-Einträge) pro Datei und pro Verzeichnis. Für Zugriffs- und Standard-ACLs gilt jeweils ein eigener Zugriffsgrenzwert von 32 ACLs. ACL-Berechtigung

Unterstützt Data Lake Storage Gen2 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 Gen2 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.

Hinweis

Sie benötigen zum Löschen von Dateien in Verzeichnissen keine Schreibberechtigungen. Außerdem kann das Stammverzeichnis„/“ kann nicht gelöscht werden.

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 Azure AD nicht mehr vorhanden ist. Dies ist meist der Fall, wenn der Benutzer aus dem Unternehmen ausgeschieden ist oder sein Konto in Azure AD 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.

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 Azure AD-Mandanten verfügen. Registrierte Apps haben eine OID, die im Azure-Portal angezeigt wird, doch hat der Dienstprinzipal eine andere (davon abweichende) OID.

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 „18218b12-1895-43e9-ad80-6e8fc1ea88ce“ entspricht. Führen Sie in der Azure CLI den folgenden Befehl aus:

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --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. Klicken Sie auf Speichern.

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 öffentlich zugegriffen werden kann.

Wo finde ich weitere Informationen zum POSIX-Zugriffssteuerungsmodell?

Weitere Informationen