Autorisieren des Zugriffs auf Blobs mithilfe von Microsoft Entra ID

Azure Storage unterstützt mithilfe von Microsoft Entra ID das Autorisieren von Anforderungen an Blob-Daten. Mit Microsoft Entra ID können Sie die rollenbasierte Zugriffssteuerung von Azure (Azure RBAC) zum Gewähren von Berechtigungen für einen Sicherheitsprinzipal verwenden, bei dem es sich um einen Benutzer, eine Gruppe oder einen Anwendungsdienstprinzipal handeln kann. Der Sicherheitsprinzipal wird von Microsoft Entra ID authentifiziert, und gibt ein OAuth 2.0-Token zurück. Das Token kann anschließend zum Autorisieren einer Anforderung an den Blob-Dienst verwendet werden.

Die Autorisierung mit Microsoft Entra ID bietet eine höhere Sicherheit und Benutzerfreundlichkeit als die Autorisierung mit gemeinsam verwendetem Schlüssel. Microsoft empfiehlt, nach Möglichkeit die Microsoft Entra-Autorisierung mit Ihren Blob-Anwendungen zu verwenden, um den Zugriff mit minimal erforderlichen Berechtigungen sicherzustellen.

Die Autorisierung mit Microsoft Entra ID ist für alle universellen Speicherkonten sowie alle Blob Storage-Konten in allen öffentlichen Regionen und nationalen Clouds verfügbar. Die Microsoft Entra-Autorisierung wird nur für Speicherkonten unterstützt, die mit dem Azure Resource Manager-Bereitstellungsmodell erstellt wurden.

Blob-Speicher unterstützt zudem das Erstellen von Shared Access Signatures (SAS), die mit Microsoft Entra-Anmeldeinformationen unterzeichnet werden. Weitere Informationen finden Sie unter Gewähren von eingeschränktem Zugriff auf Azure Storage-Ressourcen mithilfe von SAS (Shared Access Signature).

Übersicht über Microsoft Entra ID für Blobs

Wenn ein Sicherheitsprinzipal (ein Benutzer, eine Gruppe oder eine Anwendung) versucht, auf eine Blobressource zuzugreifen, muss die Anforderung autorisiert werden, sofern es sich nicht um ein Blob für den anonymen Zugriff handelt. Mit Microsoft Entra ID ist der Zugriff auf eine Ressource ein zweistufiger Prozess:

  1. Zunächst wird die Identität des Sicherheitsprinzipals authentifiziert, und ein OAuth 2.0-Token wird zurückgegeben.

    Für den Authentifizierungsschritt ist es erforderlich, dass eine Anwendung zur Laufzeit ein OAuth 2.0-Zugriffstoken anfordert. Wenn eine Anwendung in einer Azure-Entität, z. B. einer Azure-VM, einer VM-Skalierungsgruppe oder einer Azure Functions-App, ausgeführt wird, kann der Zugriff auf Blobdaten über eine verwaltete Identität erfolgen.

  2. Anschließend wird das Token als Teil einer Anforderung an den Blob-Dienst übergeben und von diesem verwendet, um den Zugriff auf die angegebene Ressource zu autorisieren.

    Der Autorisierungsschritt erfordert es, dass dem Sicherheitsprinzipal, der die Anforderung sendet, mindestens eine Azure RBAC-Rolle zugewiesen wird. Weitere Informationen finden Sie unter Zuweisen von Azure-Rollen für Zugriffsrechte.

Verwenden eines Microsoft Entra-Kontos mit dem Portal, PowerShell oder der Azure CLI

Wie Sie mit einem Microsoft Entra-Konto auf Daten im Azure-Portal zugreifen können, erfahren Sie unter Datenzugriff über das Azure-Portal. Informationen zum Aufrufen von Azure PowerShell- oder Azure CLI-Befehlen mit einem Microsoft Entra-Konto finden Sie unter Datenzugriff über PowerShell oder die Azure-Befehlszeilenschnittstelle.

Verwenden von Microsoft Entra ID zum Autorisieren des Zugriffs im Anwendungscode

Um den Zugriff auf Azure Storage mit Microsoft Entra ID zu autorisieren, können Sie eine der folgenden Client-Bibliotheken verwenden, um ein OAuth 2.0-Token abzurufen:

  • Die Azure Identity-Client-Bibliothek wird für die meisten Entwicklungsszenarien empfohlen.
  • Die Microsoft Authentication Library (MSAL) eignet sich möglicherweise für bestimmte erweiterte Szenarien.

Azure Identity-Clientbibliothek

Die Azure Identity-Clientbibliothek vereinfacht das Abrufen eines OAuth 2.0-Zugriffstokens für die Autorisierung mit Microsoft Entra ID über das Azure SDK. Die neuesten Versionen der Azure Storage-Clientbibliotheken für .NET, Java, Python, JavaScript und Go sind in die Azure Identity-Bibliotheken für jede dieser Sprachen integriert und bieten so eine einfache, sichere Möglichkeit zum Abrufen eines Zugriffstokens für die Autorisierung von Azure Storage-Anforderungen.

Ein Vorteil der Azure Identity-Clientbibliothek besteht darin, dass Sie das Zugriffstoken mit demselben Code abrufen können, um zu erfahren, ob Ihre Anwendung in der Entwicklungsumgebung oder in Azure ausgeführt wird. Die Azure Identity-Clientbibliothek gibt ein Zugriffstoken für einen Sicherheitsprinzipal zurück. Wenn Ihr Code in Azure ausgeführt wird, kann der Sicherheitsprinzipal eine verwaltete Identität für Azure-Ressourcen, ein Dienstprinzipal oder aber ein Benutzer oder eine Gruppe sein. In der Entwicklungsumgebung stellt die Clientbibliothek ein Zugriffstoken für einen Benutzer oder einen Dienstprinzipal zu Testzwecken zur Verfügung.

Das von der Azure Identity-Clientbibliothek zurückgegebene Zugriffstoken ist in Token-Anmeldeinformationen gekapselt. Sie können dann mithilfe der Token-Anmeldeinformationen ein Dienstclientobjekt abrufen, das zum Ausführen autorisierter Vorgänge für Azure Storage verwendet wird. Eine einfache Möglichkeit zum Abrufen des Zugriffstokens und der Token-Anmeldeinformationen ist die Verwendung der Klasse DefaultAzureCredential, die von der Azure Identity-Clientbibliothek bereitgestellt wird. DefaultAzureCredential versucht, die Tokenanmeldeinformationen abzurufen, indem mehrere verschiedene Anmeldeinformationstypen nacheinander ausprobiert werden. DefaultAzureCredential funktioniert sowohl in der Entwicklungsumgebung als auch in Azure.

Die folgende Tabelle enthält zusätzliche Informationen zum Autorisieren des Zugriffs auf Daten in verschiedenen Szenarien:

Sprache .NET Java JavaScript Python Go
Übersicht über die Authentifizierung mit Microsoft Entra ID Authentifizieren von .NET-Anwendungen mit Azure-Diensten Azure-Authentifizierung mit Java und Azure Identity Authentifizieren von JavaScript-Apps bei Azure mithilfe des Azure SDK Authentifizieren von Python-Apps bei Azure mithilfe des Azure SDK
Authentifizierung mithilfe von Entwicklerdienstprinzipalen Authentifizieren von .NET-Apps bei Azure-Diensten während der lokalen Entwicklung mithilfe von Dienstprinzipalen Azure-Authentifizierung mit Dienstprinzipal Authentifizieren von JS-Apps für Azure-Dienste mit einem Dienstprinzipal Authentifizieren von Python-Apps bei Azure-Diensten während der lokalen Entwicklung mithilfe von Dienstprinzipalen Authentifizierung per Azure SDK für Go mit einem Dienstprinzipal
Authentifizierung mithilfe von Entwickler- oder Benutzerkonten Authentifizieren von .NET-Apps bei Azure-Diensten während der lokalen Entwicklung mithilfe von Entwicklerkonten Azure-Authentifizierung mit Benutzeranmeldeinformationen Authentifizieren von JS-Apps für Azure-Dienste mit Entwicklerkonten Authentifizieren von Python-Apps bei Azure-Diensten während der lokalen Entwicklung mithilfe von Entwicklerkonten Azure-Authentifizierung mit dem Azure SDK für Go
Authentifizierung über von Azure gehostete Apps Authentifizieren von Azure gehosteten Apps bei Azure-Ressourcen mit dem Azure SDK für .NET Authentifizieren von in Azure gehosteten Java-Anwendungen Authentifizieren von Azure gehosteten JavaScript-Apps bei Azure-Ressourcen mit dem Azure SDK für JavaScript Authentifizieren von Azure gehosteten Apps bei Azure-Ressourcen mit dem Azure SDK für Python Authentifizierung mit dem Azure SDK für Go mithilfe einer verwalteten Identität
Authentifizierung über lokale Apps Authentifizieren bei Azure-Ressourcen mit lokal gehosteten .NET-Apps Authentifizieren lokaler JavaScript-Apps bei Azure-Ressourcen Authentifizieren bei Azure-Ressourcen mit lokal gehosteten Python-Apps
Identitätsclientbibliothek-Übersicht Azure Identity-Clientbibliothek für .NET Azure Identity-Clientbibliothek für Java Azure Identity-Clientbibliothek für JavaScript Azure Identity-Clientbibliothek für Python Azure Identity-Clientbibliothek für Go

Microsoft Authentication Library (MSAL)

Microsoft empfiehlt zwar, nach Möglichkeit die Azure Identity-Client-Bibliothek zu verwenden, aber die MSAL-Bibliothek kann für die Verwendung in bestimmten erweiterten Szenarien geeignet sein. Weitere Informationen finden Sie unter Weitere Informationen zu MSAL.

Wenn Sie MSAL zum Abrufen eines OAuth-Tokens für den Zugriff auf Azure Storage verwenden, müssen Sie eine Microsoft Entra-Ressourcen-ID angeben. Die Microsoft Entra-Ressourcen-ID gibt die Zielgruppe an, für die ein ausgegebenes Token verwendet werden kann, um den Zugriff auf eine Azure-Ressource zu ermöglichen. Im Fall von Azure Storage kann die Ressourcen-ID für ein einzelnes Speicherkonto spezifisch sein, oder sie kann für ein beliebiges Speicherkonto gelten.

Wenn Sie eine Ressourcen-ID angeben, die spezifisch für ein einzelnes Speicherkonto und einen einzelnen Dienst ist, wird die Ressourcen-ID verwendet, um ein Token für die Autorisierung von Anforderungen nur für das angegebene Konto und den angegebenen Dienst abzurufen. In der folgenden Tabelle ist der Wert aufgeführt, der für die Ressourcen-ID verwendet werden soll, basierend auf der Cloud, mit der Sie arbeiten. Ersetzen Sie <account-name> durch den Namen Ihres Speicherkontos.

Cloud Ressourcen-ID
Azure Global https://<account-name>.blob.core.windows.net
Azure Government https://<account-name>.blob.core.usgovcloudapi.net
Azure China 21Vianet https://<account-name>.blob.core.chinacloudapi.cn

Sie können auch eine Ressourcen-ID bereitstellen, die für jedes Speicherkonto gilt, wie in der folgenden Tabelle dargestellt. Diese Ressourcen-ID ist für alle öffentlichen Clouds und Sovereign Cloud identisch und wird verwendet, um ein Token für die Autorisierung von Anforderungen an ein beliebiges Speicherkonto zu erwerben.

Cloud Ressourcen-ID
Azure Global
Azure Government
Azure China 21Vianet
https://storage.azure.com/

Zuweisen von Azure-Rollen für Zugriffsrechte

Microsoft Entra autorisiert Zugriffsrechte für gesicherte Ressourcen über Azure RBAC. Azure Storage definiert eine Reihe von in Azure integrierten RBAC-Rollen mit allgemeinen Berechtigungssätzen für den Zugriff auf Blobdaten. Außerdem können Sie benutzerdefinierte Rollen für den Zugriff auf Blobdaten definieren. Weitere Informationen zum Zuweisen von Azure-Rollen für den Blobzugriff finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten.

Ein Microsoft Entra-Sicherheitsprinzipal kann einen Benutzer, eine Gruppe, ein Anwendungsdienstprinzipal oder eine verwaltete Identität für Azure-Ressourcen sein. Die möglichen Berechtigungen eines Sicherheitsprinzipals für eine bestimmte Ressource sind durch die ihm zugewiesenen RBAC-Rollen vorgegeben. Weitere Informationen zum Zuweisen von Azure-Rollen für den Blobzugriff finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten.

In einigen Fällen müssen Sie möglicherweise einen feinen Zugriff auf Blobressourcen aktivieren oder Berechtigungen vereinfachen, wenn Sie über eine große Anzahl von Rollenzuweisungen für eine Speicherressource verfügen. Mithilfe von attributbasierter Zugriffssteuerung für Azure (Azure Attribute-Based Access Control, Azure ABAC) können Sie Bedingungen für Rollenzuweisungen konfigurieren. Sie können Bedingungen bei einer benutzerdefinierten Rolle verwenden oder integrierte Rollen auswählen. Weitere Informationen zum Konfigurieren von Bedingungen für Azure-Speicherressourcen mit ABAC finden Sie unter Autorisieren des Zugriffs auf Blobs mithilfe von Bedingungen für die Azure-Rollenzuweisung (Vorschau). Einzelheiten zu unterstützten Bedingungen für Blobdatenvorgänge finden Sie unter Aktionen und Attribute für Azure-Rollenzuweisungsbedingungen in Azure Storage (Vorschau).

Hinweis

Wenn Sie ein Azure Storage-Konto erstellen, erhalten Sie nicht automatisch Berechtigungen für den Zugriff auf Daten über Microsoft Entra ID. Sie müssen sich selbst explizit eine Azure-Rolle für den Zugriff auf Blob Storage zuweisen. Sie können sie auf Ebene Ihres Abonnements, einer Ressourcengruppe, eines Speicherkontos oder eines Containers zuordnen.

Ressourcenumfang

Bevor Sie einem Sicherheitsprinzipal eine Azure RBAC-Rolle zuweisen, legen Sie den Zugriffsbereich fest, den der Sicherheitsprinzipal haben soll. Es hat sich als am besten bewährt, stets nur den kleinstmöglichen Umfang an Zugriffsrechten zu gewähren. Azure RBAC-Rollen, die in einem umfassenderen Bereich definiert sind, werden von den darunterliegenden Ressourcen geerbt.

Sie können den Zugriff auf Azure-Blobressourcen auf den folgenden Ebenen einschränken, beginnend mit dem kleinstmöglichen Bereich:

  • Ein einzelner Container. Bei diesem Umfang gilt eine Rollenzuweisung für alle Blobs im Container sowie für Containereigenschaften und Metadaten.
  • Das Speicherkonto Bei diesem Bereich gilt eine Rollenzuweisung für alle Container und deren Blobs.
  • Die Ressourcengruppe. Bei diesem Bereich gilt eine Rollenzuweisung für alle Container in allen Speicherkonten der Ressourcengruppe.
  • Das Abonnement. Bei diesem Bereich gilt eine Rollenzuweisung für alle Container in allen Speicherkonten in allen Ressourcengruppen des Abonnements.
  • Eine Verwaltungsgruppe. Bei diesem Bereich gilt eine Rollenzuweisung für alle Container in allen Speicherkonten in allen Ressourcengruppen und allen Abonnements in der Ressourcengruppe.

Weitere Informationen zum Bereich für Azure RBAC-Rollenzuweisungen finden Sie unter Grundlegendes zum Bereich für Azure RBAC.

In Azure integrierte Rollen für Blobs

Azure RBAC stellt mehrere integrierte Rollen zum Autorisieren des Zugriffs auf Warteschlangendaten mit Microsoft Entra ID und OAuth bereit. Beispiele für Rollen, die Berechtigungen für Datenressourcen in Azure Storage bereitstellen:

Informationen zum Zuweisen einer integrierten Azure-Rolle zu einem Sicherheitsprinzipal finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten. Informationen zum Auflisten von Azure RBAC-Rollen und deren Berechtigungen finden Sie unter Auflisten von Azure-Rollendefinitionen.

Weitere Informationen dazu, wie integrierte Rollen für Azure Storage definiert sind, finden Sie unter Grundlegendes zu Rollendefinitionen. Informationen zum Erstellen von benutzerdefinierten Azure-Rollen finden Sie unter Benutzerdefinierte Azure-Rollen.

Nur Rollen, die explizit für den Datenzugriff definiert sind, ermöglichen einem Sicherheitsprinzipal den Zugriff auf Blobdaten. Integrierte Rollen wie Besitzer, Mitwirkender und Speicherkontomitwirkender gestatten einem Sicherheitsprinzipal die Verwaltung eines Speicherkontos, gewähren aber keinen Zugriff auf die Blob-Daten in diesem Konto über Microsoft Entra ID. Wenn eine Rolle jedoch Microsoft.Storage/storageAccounts/listKeys/action enthält, kann ein Benutzer, dem diese Rolle zugewiesen ist, über die Autorisierung mit gemeinsam verwendetem Schlüssel mit den Kontozugriffsschlüsseln auf Daten im Speicherkonto zugreifen. Weitere Informationen finden Sie unter Auswählen der Autorisierung des Zugriffs auf Blobdaten im Azure-Portal.

Ausführliche Informationen zu integrierten Azure-Rollen für Azure Storage für die Datendienste und den Verwaltungsdienst finden Sie im Artikel In Azure integrierte Rollen für Azure RBAC im Abschnitt Storage. Informationen zu den verschiedenen Typen von Rollen, die Berechtigungen in Azure bereitstellen, finden Sie zusätzlich unter Azure-Rollen, Microsoft Entra-Rollen und Administratorrollen für klassische Abonnements.

Wichtig

Die Verteilung von Azure-Rollenzuweisungen kann bis zu 30 Minuten dauern.

Zugriffsberechtigungen für Datenvorgänge

Einzelheiten zu den Berechtigungen, die für spezifische Vorgänge des Blob-Diensts erforderlich sind, finden Sie unter Berechtigungen für das Aufrufen von Datenvorgängen.

Zugreifen auf Daten mit einem Microsoft Entra-Konto

Der Zugriff auf Blob-Daten über das Azure-Portal, PowerShell oder die Azure-Befehlszeilenschnittstelle kann über das Microsoft Entra-Konto von Benutzern oder über die Kontozugriffsschlüssel (Autorisierung mit gemeinsam verwendetem Schlüssel) autorisiert werden.

Achtung

Eine Autorisierung mit einem gemeinsam verwendeten Schlüssel wird nicht empfohlen, da sie möglicherweise weniger sicher ist. Um optimale Sicherheit zu gewährleisten, deaktivieren Sie die Autorisierung über gemeinsam genutzten Schlüssel für Ihr Speicherkonto. Eine Anleitung finden Sie unter Verhindern der Autorisierung mit gemeinsam verwendeten Schlüsseln für ein Azure Storage-Konto.

Sie sollten die Verwendung von Zugriffsschlüsseln und Verbindungszeichenfolgen auf vorläufige Proof-of-Concept-Anwendungen oder Entwicklungsprototypen beschränken, die keinen Zugriff auf Produktionsdaten oder vertrauliche Daten haben. In allen anderen Fällen sollten Sie immer die tokenbasierten Authentifizierungsklassen, die im Azure SDK verfügbar sind, für die Authentifizierung bei Azure-Ressourcen verwenden.

Microsoft empfiehlt, dass Clients entweder Microsoft Entra ID oder eine SAS (Shared Access Signature) verwenden, um den Zugriff auf Daten in Azure Storage zu autorisieren. Weitere Informationen finden Sie unter Autorisieren von Vorgängen für den Datenzugriff.

Datenzugriff über das Azure-Portal

Im Azure-Portal können Sie über Ihr Microsoft Entra-Konto oder die Kontozugriffsschlüssel auf Blob-Daten in einem Azure-Speicherkonto zugreifen. Welches Autorisierungsschema im Azure-Portal verwendet wird, hängt von den Ihnen zugewiesenen Azure-Rollen ab.

Wenn Sie versuchen, auf Blobdaten zuzugreifen, wird im Azure-Portal zunächst überprüft, ob Ihnen eine Azure-Rolle mit Microsoft.Storage/storageAccounts/listkeys/action zugewiesen ist. Wenn Ihnen eine Rolle mit dieser Aktion zugewiesen wurde, wird im Azure-Portal der Kontoschlüssel für den Zugriff auf Blobdaten per Authentifizierung mit gemeinsam verwendetem Schlüssel verwendet. Wenn Ihnen keine Rolle mit dieser Aktion zugewiesen wurde, wird im Azure-Portal versucht, über Ihr Microsoft Entra-Konto auf die Daten zuzugreifen.

Für den Zugriff auf Blob-Daten über das Azure-Portal mithilfe Ihres Microsoft Entra-Kontos benötigen Sie Berechtigungen für den Zugriff auf Blob-Daten sowie das Navigieren durch die Ressourcen des Speicherkontos im Azure-Portal. Die integrierten Rollen, die von Azure Storage bereitgestellt werden, gewähren Zugriff auf Blobressourcen, aber nicht auf die Speicherkontoressourcen. Aus diesem Grund erfordert der Zugriff auf das Portal außerdem die Zuweisung einer Azure Resource Manager-Rolle (z. B. Leser) mindestens auf Ebene des Speicherkontos. Die Rolle Leser erteilt die am stärksten eingeschränkten Berechtigungen. Eine andere Azure Resource Manager-Rolle, die den Zugriff auf Ressourcen zur Verwaltung von Speicherkonten gewährt, ist jedoch ebenfalls akzeptabel. Weitere Informationen zum Zuweisen von Berechtigungen zu Benutzern für den Datenzugriff im Azure-Portal über ein Microsoft Entra-Konto finden Sie unter Zuweisen einer Azure-Rolle für den Zugriff auf Blobdaten.

Wenn Sie zu einem Container navigieren, wird im Azure-Portal angegeben, welches Autorisierungsschema verwendet wird. Weitere Informationen zum Datenzugriff im Portal finden Sie unter Auswählen der Autorisierung des Zugriffs auf Blobdaten im Azure-Portal.

Datenzugriff über PowerShell oder die Azure-Befehlszeilenschnittstelle

In der Azure-Befehlszeilenschnittstelle und PowerShell ist die Anmeldung mit Microsoft Entra-Anmeldeinformationen möglich. Nach der Anmeldung wird Ihre Sitzung unter diesen Anmeldeinformationen ausgeführt. Weitere Informationen finden Sie in den folgenden Artikeln:

Featureunterstützung

Die Unterstützung für dieses Features kann durch die Aktivierung von Data Lake Storage Gen2, dem Network File System (NFS) 3.0-Protokoll oder dem SSH File Transfer Protocol (SFTP) beeinträchtigt werden. Wenn Sie eine dieser Funktionen aktiviert haben, lesen Sie bitte den Abschnitt Unterstützung der Blob Storage-Funktion in Azure Storage-Konten, um die Unterstützung für dieses Features zu bewerten.

Das Autorisieren von Blob-Datenvorgängen mit Microsoft Entra ID wird nur für die REST-API-Versionen 2017-11-09 und höher unterstützt. Weitere Informationen finden Sie unter Versionsverwaltung für die Azure-Speicherdienste.

Nächste Schritte