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.
Hinweis
ACLs gelten nur für Sicherheitsprinzipale im gleichen Mandanten. ACLs gelten nicht für Benutzer, die die Autorisierung mit gemeinsam verwendeten Schlüssel verwenden, da dem Aufrufer keine Identität zugeordnet ist und daher keine auf Berechtigungen basierende Sicherheitsprinzipalautorisierung ausgeführt werden kann. Das gleiche gilt für SAS-Token (Shared Access Signature), außer wenn ein benutzerdelegiertes SAS-Token verwendet wird. In diesem Fall führt Azure Storage eine POSIX-ACL-Überprüfung anhand der Objekt-ID durch, bevor der Vorgang autorisiert wird, sofern der optionale Parameter „suoid“ verwendet wird. Weitere Informationen finden Sie unter Konstruieren einer SAS für die Benutzerdelegierung.
Festlegen von ACLs
Informationen zum Festlegen von Berechtigungen auf Datei- und Verzeichnisebene finden Sie in den folgenden Artikeln:
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. Der Dienstprinzipal wird als benannter Benutzer behandelt. Sie fügen diese ID der ACL wie jeder benannte Benutzer hinzu. Benannte Benutzer werden weiter unten in diesem Artikel beschrieben.
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 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 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.
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, ABAC und ACLs 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 |
--- |
| Löschen Sie /Oregon/ | -WX |
RWX |
RWX |
--- |
| Löschen Sie /Oregon/Portland/ | --X |
-WX |
RWX |
--- |
| Erstellen von „Data.txt“ | --X |
--X |
-WX |
--- |
| Auflisten von „/“ | R-X |
--- |
--- |
--- |
| List /Oregon/ | --X |
R-X |
--- |
--- |
| List /Oregon/Portland/ | --X |
--X |
R-X |
--- |
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.
Hinweis
Außerdem kann das Stammverzeichnis „/“ nicht gelöscht werden.
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.
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-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$superuserfestgelegt. - 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:
- Superuser
- zuständige Benutzer
- Benannter Benutzer, Dienstprinzipal oder verwaltete Identität
- Besitzende Gruppe oder benannte Gruppe
- 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
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-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-- |
| Sonstiges | --- |
--- |
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 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 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:
| umask-Komponente | Numerische Form | Kurzform | Bedeutung |
|---|---|---|---|
| umask.owning_user | 0 | --- |
Für zuständige Benutzer wird die Zugriffs-ACL des übergeordneten Elements für die Standard-ACL des untergeordneten Elements kopiert. |
| umask.owning_group | 0 | --- |
Für die zuständige Gruppe wird die Zugriffs-ACL des übergeordneten Elements für die Standard-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. |
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 mitrwx-Berechtigungen hinzu. - Fügen Sie die
LogsReader-Gruppe zur ACL des Verzeichnisses /LogData mitr-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.
Wichtig
Azure Data Lake Storage Gen2 hängt von der Microsoft Entra ID ab, um Sicherheitsgruppen zu verwalten. Microsoft Entra ID empfiehlt, die Gruppenmitgliedschaft für einen bestimmten Sicherheitsprinzipal auf weniger als 200 zu beschränken. Diese Empfehlung ist auf eine Einschränkung von JSON-Webtoken (JWT) zurückzuführen, die Informationen über die Gruppenmitgliedschaft eines Sicherheitsprinzipals in Microsoft Entra-Anwendungen bereitstellen. Das Überschreiten dieses Grenzwerts kann zu unerwarteten Leistungsproblemen bei Data Lake Storage Gen2 führen. Informationen dazu finden Sie unter Konfigurieren von Gruppenansprüchen für Anwendungen mit 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.
| Mechanismus | `Scope` | Einschränkungen | Unterstützte Berechtigungsebene |
|---|---|---|---|
| Azure RBAC | Speicherkonten, Container. Ressourcenübergreifende Azure-Rollenzuweisungen auf Abonnement- oder Ressourcengruppenebene. |
4.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 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.
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 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