Sicherheitsüberlegungen zu Azure-Rollenzuweisungsbedingungen in Azure Blob Storage
Wenn Sie Ressourcen mithilfe der attributbasierten Zugriffssteuerung von Azure (Attribute-Based Access Control, Azure ABAC) vollständig schützen möchten, müssen Sie auch die Attribute schützen, die in den Bedingungen für die Azure-Rollenzuweisung verwendet werden. Basiert Ihre Bedingung beispielsweise auf einem Dateipfad, sollten Sie beachten, dass der Zugriff gefährdet sein kann, wenn der Prinzipal eine uneingeschränkte Berechtigung zum Umbenennen eines Dateipfads hat.
In diesem Artikel werden Sicherheitsüberlegungen beschrieben, die Sie in Ihren Bedingungen für Rollenzuweisungen berücksichtigen sollten.
Wichtig
Die attributbasierte Zugriffssteuerung (Attribute-Based Access Control, ABAC) in Azure ist allgemein verfügbar, um den Zugriff auf Azure Blob Storage, Azure Data Lake Storage Gen2 und Azure-Warteschlangen mithilfe der Attribute request, resource, environment und principal sowohl auf der standardmäßigen als auch auf der Premium-Speicherkonto-Leistungsstufe zu steuern. Derzeit befinden sich das Ressourcenattribut für Containermetadaten und das Listen-BLOB-Anforderungsattribut in der VORSCHAU. Vollständige Informationen zum Status des ABAC-Features für Azure Storage finden Sie unter Status der Bedingungsfeatures in Azure Storage.
Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.
Verwendung von anderen Autorisierungsmechanismen
Rollenzuweisungsbedingungen werden nur ausgewertet, wenn Azure RBAC zur Autorisierung verwendet wird. Diese Bedingungen können umgangen werden, wenn Sie den Zugriff mithilfe alternativer Autorisierungsmethoden zulassen:
- Autorisierung mit gemeinsam verwendetem Schlüssel
- Konto-SAS (Shared Access Signature)
- Dienst-SAS.
Ebenso werden Bedingungen nicht ausgewertet, wenn der Zugriff über Zugriffssteuerungslisten (Access Control Lists, ACLs) in Speicherkonten mit einem hierarchischen Namespace (HNS) gewährt wird.
Sie können eine Autorisierung mit gemeinsam verwendetem Schlüssel, SAS auf Kontoebene und SAS auf Dienstebene verhindern, indem Sie bei Ihrem Speicherkonto die Autorisierung mit gemeinsam verwendetem Schlüssel deaktivieren. Da SAS für die Benutzerdelegierung von Azure RBAC abhängt, werden Bedingungen für die Rollenzuweisung ausgewertet, wenn diese Autorisierungsmethode verwendet wird.
Sichern von Speicherattributen, die in Bedingungen verwendet werden
Blobpfad
Wenn Sie „Blobpfad“ als @Resource-Attribut für eine Bedingung verwenden, sollten Sie auch verhindern, dass Benutzer*innen ein Blob umbenennen und so Zugriff auf eine Datei erhalten, wenn sie Konten mit einem hierarchischen Namespace verwenden. Wenn Sie beispielsweise eine auf dem Blobpfad basierende Bedingung erstellen möchten, sollten Sie auch den Zugriff des Benutzers auf die folgenden Aktionen einschränken:
| Aktion | BESCHREIBUNG |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action |
Bei dieser Aktion können Kunden eine Datei mithilfe der Pfaderstellungs-API umbenennen. |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action |
Diese Aktion ermöglicht den Zugriff auf verschiedene Dateisystem- und Pfadvorgänge. |
Blobindextags
Blobindextags werden als Freiformattribute für Bedingungen im Speicher verwendet. Wenn Sie Zugriffsbedingungen mithilfe dieser Tags erstellen, müssen Sie auch die Tags schützen. Insbesondere ermöglicht die „DataAction“ Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write Benutzern, die Tags für ein Speicherobjekt zu ändern. Sie können diese Aktion einschränken und so verhindern, dass Benutzer einen Tagschlüssel oder -wert bearbeiten, um Zugriff auf nicht autorisierte Objekte zu erhalten.
Werden Blobindextags in Bedingungen verwendet, können Daten außerdem gefährdet sein, wenn die Daten und zugeordneten Indextags in separaten Vorgängen aktualisiert werden. Sie können @Request-Bedingungen für Blobschreibvorgänge verwenden, um zu verlangen, dass Indextags in demselben Aktualisierungsvorgang festgelegt werden. Dieser Ansatz kann dazu beitragen, dass Daten sofort nach dem Schreiben in den Speicher geschützt werden.
Tags für kopierte Blobs
Standardmäßig werden Blobindextags aus einem Quellblob nicht in das Ziel kopiert, wenn Sie die API Copy Blob (Blob kopieren) oder eine ihrer Varianten verwenden. Wenn Sie den Zugriffsbereich für Blobs beim Kopieren beibehalten möchten, sollten Sie auch die Tags kopieren.
Tags für Momentaufnahmen
Tags für Blobmomentaufnahmen können nicht geändert werden. Daher müssen Sie die Tags für ein Blob aktualisieren, bevor Sie die Momentaufnahme erstellen. Wenn Sie die Tags für ein Basisblob ändern, behalten die Tags für dessen Momentaufnahme ihren vorherigen Wert bei.
Wenn ein Tag für ein Basisblob geändert wird, nachdem eine Momentaufnahme erstellt wurde, kann der Zugriffsbereich für das Basisblob und die Momentaufnahme unterschiedlich sein.
Tags für Blobversionen
Blobindextags werden nicht kopiert, wenn eine Blobversion über die APIs Put Blob (Blob festlegen), Put Block List (Blockliste festlegen) oder Copy Blob (Blob kopieren) erstellt wird. Sie können Tags über den Header für diese APIs angeben.
Tags können einzeln für ein aktuelles Basisblob und jede Blobversion festgelegt werden. Wenn Sie Tags in einem Basisblob ändern, werden die Tags in früheren Versionen nicht aktualisiert. Wenn Sie den Zugriffsbereich für ein Blob und alle zugehörigen Versionen mithilfe von Tags ändern möchten, müssen Sie die Tags für jede Version aktualisieren.
Abfrage- und Filtereinschränkungen bei Versionen und Momentaufnahmen
Wenn Sie Tags zum Abfragen und Filtern von Blobs in einem Container verwenden, werden nur die Basisblobs in die Antwort einbezogen. Blobversionen oder Momentaufnahmen mit den angeforderten Schlüsseln und Werten werden nicht einbezogen.
Rollen und Berechtigungen
Wenn Sie Rollenzuweisungsbedingungen für integrierte Azure-Rollen verwenden, sollten Sie alle Berechtigungen, die die Rolle einem Prinzipal erteilt, sorgfältig überprüfen.
Geerbte Rollenzuweisungen
Rollenzuweisungen können für eine Verwaltungsgruppe, ein Abonnement, eine Ressourcengruppe, ein Speicherkonto oder einen Container konfiguriert werden, und sie werden auf jeder Ebene in der angegebenen Reihenfolge geerbt. Weil Azure RBAC ein additives Modell enthält, sind die effektiven Berechtigungen die Summe aus Rollenzuweisungen auf jeder Ebene. Wenn einem Prinzipal dieselbe Berechtigung über mehrere Rollenzuweisungen zugewiesen wurde, wird der Zugriff für einen Vorgang, der diese Berechtigung verwendet, für jede Zuweisung auf jeder Ebene separat ausgewertet.
Da Bedingungen als Bedingungen für Rollenzuweisungen implementiert werden, kann jede beliebige bedingungslose Rollenzuweisung Benutzern ermöglichen, die Bedingung zu umgehen. Angenommen, Sie weisen einem Benutzer die Rolle Mitwirkender an Speicherblobdaten für ein Speicherkonto und ein Abonnement zu, fügen aber nur der Zuweisung für das Speicherkonto eine Bedingung hinzu. Dies führt dazu, dass der Benutzer durch die Rollenzuweisung auf der Abonnementebene uneingeschränkten Zugriff auf das Speicherkonto hat.
Deshalb sollten Sie Bedingungen konsistent für alle Rollenzuweisungen in einer Ressourcenhierarchie anwenden.
Weitere Überlegungen
Bedingungsvorgänge, die Blobs schreiben
Viele Vorgänge, die Blobs schreiben, erfordern entweder die Berechtigung Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write oder die Berechtigung Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action. Integrierte Rollen, z. B. Besitzer von Speicherblobdaten und Mitwirkender an Speicherblobdaten, erteilen einem Sicherheitsprinzipal beide Berechtigungen.
Wenn Sie eine Rollenzuweisungsbedingung für diese Rollen definieren, sollten Sie für beide Berechtigungen identische Bedingungen verwenden, um konsistente Zugriffseinschränkungen für Schreibvorgänge sicherzustellen.
Verhalten bei „Copy Blob“(Blob kopieren) und „Copy Blob from URL“ (Blob aus URL kopieren)
Bei den Vorgängen Copy Blob (Blob kopieren) und Copy Blob From URL (Blob aus URL kopieren) werden @Request-Bedingungen, die den Blobpfad als Attribut für die Aktion Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write verwenden,und deren Untervorgänge nur für das Zielblob ausgewertet.
Bei Bedingungen im Quellblob werden @Resource-Bedingungen für die Aktion Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read ausgewertet.