Zugriffssteuerungsmodell in Azure Data Lake Storage Gen2
Data Lake Storage Gen2 unterstützt die folgenden Autorisierungsmechanismen:
- Autorisierung mit gemeinsam verwendetem Schlüssel
- SAS-Authentifizierung (Shared Access Signature)
- Rollenbasierte Zugriffssteuerung (Azure Role-Based Access Control, Azure RBAC)
- Attributbasierte Zugriffssteuerung (Azure ABAC)
- Zugriffssteuerungslisten (Access Control List, ACL)
Autorisierung mit gemeinsam verwendetem Schlüssel und SAS-Autorisierung gewähren Benutzern (oder Anwendungen) Zugriff, ohne dass diese über eine Identität in Microsoft Entra ID verfügen müssen. Bei diesen beiden Authentifizierungsarten haben Azure RBAC, Azure ABAC und ACLs keinerlei Auswirkungen.
Bei Azure RBAC und ACL muss der Benutzer (oder die Anwendung) über eine Identität in Microsoft Entra ID verfügen. Mit Azure RBAC können Sie einen „groben“ Zugriff auf die Daten eines Speicherkontos gewähren, z. B. Lese- oder Schreibzugriff auf alle Daten in einem Speicherkonto. Mit Azure ABAC können Sie RBAC-Rollenzuweisungen durch Hinzufügen von Bedingungen verfeinern. Sie können beispielsweise Lese- oder Schreibzugriff auf alle Datenobjekte in einem Speicherkonto gewähren, die über ein bestimmtes Tag verfügen. Mit ACLs können Sie „differenzierten“ Zugriff gewähren, z. B. Schreibzugriff auf ein bestimmtes Verzeichnis oder eine bestimmte Datei.
Der Schwerpunkt dieses Artikels liegt auf Azure RBAC und ACLs und es wird erläutert, wie das System diese auswertet, um Entscheidungen über die Autorisierung für Speicherkontoressourcen zu treffen.
Rollenbasierte Zugriffssteuerung (Azure Role-Based Access Control, Azure RBAC)
Für Azure RBAC werden Rollenzuweisungen verwendet, um Sicherheitsprinzipalen Berechtigungen zuzuweisen. Ein Sicherheitsprinzipal ist ein Objekt, das einen Benutzer, eine Gruppe, einen Dienstprinzipal oder eine verwaltete Identität darstellt, der bzw. die in Microsoft Entra ID definiert ist. Mit einem Berechtigungssatz kann einem Sicherheitsprinzipal eine „grobkörnige“ Zugriffsebene zugewiesen werden, z. B. Lese- oder Schreibzugriff auf alle Daten in einem Speicherkonto oder alle Daten in einem Container.
Die folgenden Rollen ermöglichen einem Sicherheitsprinzipal den Zugriff auf Daten in einem Speicherkonto.
| Role | BESCHREIBUNG |
|---|---|
| Besitzer von Speicherblobdaten | Vollzugriff auf Blobspeichercontainer und -daten. Dieser Zugriff erlaubt es dem Sicherheitsprinzipal, den Besitzer eines Elements festzulegen und die ACLs aller Elemente zu ändern. |
| Mitwirkender an Speicherblobdaten | Lesen, Schreiben und Löschen von Blobspeichercontainern und -blobs. Dieser Zugriff gestattet es dem Sicherheitsprinzipal nicht, den Besitzer eines Elements festzulegen, er kann jedoch die ACL von Elementen ändern, deren Besitzer der Sicherheitsprinzipal ist. |
| Leser von Speicherblobdaten | Lesen und Auflisten von Blobspeichercontainern und -blobs. |
Rollen wie Besitzer, Mitwirkender, Leser und Speicherkontomitwirkender gestatten einem Sicherheitsprinzipal die Verwaltung eines Speicherkontos, gewähren jedoch keinen Zugriff auf Daten in diesem Konto. Allerdings können diese Rollen (mit Ausnahme von Leser) Zugriff auf die Speicherschlüssel erhalten, die in verschiedenen Clienttools für den Datenzugriff verwendet werden können.
Attributbasierte Zugriffssteuerung (Azure ABAC)
Azure ABAC baut auf Azure RBAC auf und fügt Rollenzuweisungsbedingungen auf der Grundlage von Attributen im Kontext bestimmter Aktionen hinzu. Eine Rollenzuweisungsbedingung ist eine zusätzliche Überprüfung, die Sie Ihrer Rollenzuweisung optional hinzufügen können, um eine präzisere Zugriffssteuerung zu ermöglichen. Bedingungen können nicht dazu verwendet werden, den Zugriff auf bestimmte Ressourcen explizit zu verweigern.
Weitere Informationen zur Verwendung von Azure ABAC zum Steuern des Zugriffs auf Azure Storage finden Sie unter Autorisieren des Zugriffs auf Azure Blob Storage mithilfe von Bedingungen für die Azure-Rollenzuweisung.
Zugriffssteuerungslisten (ACLs)
ACLs ermöglichen Ihnen die Anwendung einer „feinkörnigen“ Zugriffsebene auf Verzeichnisse und Dateien. Eine ACL ist ein Berechtigungskonstrukt, das eine Reihe von ACL-Einträgen enthält. Jeder ACL-Eintrag ordnet den Sicherheitsprinzipal einer Zugriffsebene zu. Weitere Informationen finden Sie unter Zugriffssteuerung in Azure Data Lake Storage Gen2.
Auswerten von Berechtigungen
Während der auf Sicherheitsprinzipalen beruhenden Autorisierung werden Berechtigungen wie im nachstehenden Diagramm dargestellt ausgewertet.
- Azure bestimmt, ob eine Rollenzuweisung für den Prinzipal vorhanden ist.
- Wenn eine Rollenzuweisung vorhanden ist, werden die Rollenzuweisungsbedingungen (2) als Nächstes ausgewertet.
- Andernfalls werden die ACLs (4) als Nächstes ausgewertet.
- Azure bestimmt, ob ABAC-Rollenzuweisungsbedingungen vorhanden sind.
- Wenn keine Bedingungen vorhanden sind, wird der Zugriff gewährt.
- Wenn Bedingungen vorhanden sind, werden sie ausgewertet, um festzustellen, ob sie mit der Anforderung (3) übereinstimmen.
- Azure bestimmt, ob alle ABAC-Rollenzuweisungsbedingungen mit den Attributen der Anforderung übereinstimmen.
- Wenn alle übereinstimmen, wird der Zugriff gewährt.
- Wenn mindestens eine von ihnen nicht übereinstimmt, werden als nächstes die ACLs (4) ausgewertet.
- Wenn der Zugriff nach Auswertung der Rollenzuweisungen und -bedingungen nicht explizit gewährt wurde, werden die ACLs ausgewertet.
- Wenn die ACLs die angeforderte Zugriffsebene zulassen, wird der Zugriff gewährt.
- Andernfalls wird der Zugriff verweigert.
Wichtig
Aufgrund der Art und Weise, wie Zugriffsberechtigungen vom System ausgewertet werden, können Sie keine ACL verwenden, um den Zugriff einzuschränken, der bereits durch eine Rollenzuweisung und deren Bedingungen gewährt wurde. Der Grund hierfür ist, dass das System die Azure-Rollenzuweisungen zuerst auswertet. Wenn die Zuweisung ausreichende Zugriffsberechtigungen gewährt, werden ACLs ignoriert.
Das folgende Diagramm zeigt den Berechtigungsflow für drei häufige Vorgänge: Auflisten von Verzeichnisinhalten, Lesen einer Datei und Schreiben einer Datei.
Berechtigungstabelle: Kombinieren von Azure RBAC, ABAC und ACLs
Die folgende Tabelle zeigt, wie Sie Azure-Rollen, Bedingungen und ACL-Einträge kombinieren, damit ein Sicherheitsprinzipal die Vorgänge ausführen kann, die in der Spalte Vorgang aufgelistet sind. 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. Diese Spalten enthalten Darstellungen des ACL-Eintrags, der zum Erteilen von Berechtigungen erforderlich ist, in Kurzform. – (nicht zutreffend) steht in der Spalte, wenn der ACL-Eintrag zum Ausführen des Vorgangs nicht erforderlich ist.
| Vorgang | Zugewiesene Azure-Rolle (mit oder ohne Bedingungen) | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Lesen von „Data.txt“ | Besitzer von Speicherblobdaten | – | – | – | – |
| Mitwirkender an Storage-Blobdaten | – | – | – | – | |
| Leser von Speicherblobdaten | – | – | – | Nicht zutreffend | |
| Keine | --X |
--X |
--X |
R-- |
|
| Anfügen an „Data.txt“ | Besitzer von Speicherblobdaten | – | – | – | – |
| Mitwirkender an Storage-Blobdaten | – | – | – | – | |
| Leser von Speicherblobdaten | --X |
--X |
--X |
-W- |
|
| Keine | --X |
--X |
--X |
RW- |
|
| Löschen von „Data.txt“ | Besitzer von Speicherblobdaten | – | – | – | – |
| Mitwirkender an Storage-Blobdaten | – | – | – | – | |
| Leser von Speicherblobdaten | --X |
--X |
-WX |
Nicht zutreffend | |
| Keine | --X |
--X |
-WX |
– | |
| Erstellen von „Data.txt“ | Besitzer von Speicherblobdaten | – | – | – | – |
| Mitwirkender an Storage-Blobdaten | – | – | – | – | |
| Leser von Speicherblobdaten | --X |
--X |
-WX |
Nicht zutreffend | |
| Keine | --X |
--X |
-WX |
– | |
| Auflisten von „/“ | Besitzer von Speicherblobdaten | – | – | – | – |
| Mitwirkender an Storage-Blobdaten | – | – | – | – | |
| Leser von Speicherblobdaten | – | – | – | Nicht zutreffend | |
| Keine | R-X |
– | – | – | |
| List /Oregon/ | Besitzer von Speicherblobdaten | – | – | – | – |
| Mitwirkender an Storage-Blobdaten | – | – | – | – | |
| Leser von Speicherblobdaten | – | – | – | Nicht zutreffend | |
| Keine | --X |
R-X |
– | – | |
| List /Oregon/Portland/ | Besitzer von Speicherblobdaten | – | – | – | – |
| Mitwirkender an Storage-Blobdaten | – | – | – | – | |
| Leser von Speicherblobdaten | – | – | – | Nicht zutreffend | |
| Keine | --X |
--X |
R-X |
– |
Hinweis
Um den Inhalt eines Containers in Azure Storage-Explorer anzuzeigen, müssen sich Sicherheitsprinzipale mit Microsoft Entra ID bei Storage-Explorer anmelden und mindestens über Lesezugriff (R--) für den Stammordner (\) eines Containers verfügen. Diese Berechtigungsebene erlaubt ihnen, den Inhalt des Stammordners aufzulisten. Wenn Sie nicht möchten, dass der Inhalt des Stammordners sichtbar ist, können Sie ihnen die Rolle Leser zuweisen. Mit dieser Rolle können sie die Container im Konto, aber nicht die Inhalte der Container auflisten. Anschließend können Sie mithilfe von ACLs Zugriff auf bestimmte Verzeichnisse und Dateien gewähren.
Sicherheitsgruppen
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.
Begrenzungen für Azure-Rollenzuweisungen und ACL-Einträge
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. Die Einschränkungen sind in der folgenden Tabelle beschrieben.
| 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 |
Autorisierung mit gemeinsam verwendetem Schlüssel und SAS (Shared Access Signature)
Azure Data Lake Storage Gen2 unterstützt für die Authentifizierung auch die Methoden Gemeinsam verwendeter Schlüssel und SAS. Ein Merkmal dieser Authentifizierungsmethoden ist, dass dem Aufrufer keine Identität zugeordnet wird und daher keine auf Sicherheitsprinzipalberechtigungen basierende Autorisierung erfolgen kann.
Im Falle des gemeinsam verwendeten Schlüssels erhält der Aufrufer faktisch Administratorzugriff, was Vollzugriff zum Anwenden sämtlicher Vorgänge auf alle Ressourcen bedeutet, einschließlich Daten, Festlegung des Besitzers und Änderung von ACLs.
SAS-Token enthalten zulässige Berechtigungen als Teil des Tokens. Die im SAS-Token enthaltenen Berechtigungen fließen effektiv in alle Berechtigungsentscheidungen ein, ohne dass zusätzliche ACL-Prüfungen erfolgen.
Nächste Schritte
Weitere Informationen zu Zugriffssteuerungslisten finden Sie unter Zugriffssteuerungslisten (ACLs) in Azure Data Lake Storage Gen2.