Freigeben über

Erstellen einer Benutzerdelegierungs-SAS

  • Artikel

Wichtig

Für eine optimale Sicherheit empfiehlt Microsoft die Verwendung der Microsoft Entra-ID mit verwalteten Identitäten, um Anforderungen für Blob-, Warteschlangen- und Tabellendaten zu autorisieren, wenn möglich. Die Autorisierung mit Microsoft Entra ID und verwalteten Identitäten bietet eine überlegene Sicherheit und Benutzerfreundlichkeit gegenüber der Shared Key-Autorisierung. Weitere Informationen finden Sie unter Autorisieren mit microsoft Entra ID. Weitere Informationen zu verwalteten Identitäten finden Sie unter Was sind verwaltete Identitäten für Azure-Ressourcen.

Für Ressourcen, die außerhalb von Azure gehostet werden, z. B. lokale Anwendungen, können Sie verwaltete Identitäten über Azure Arc verwenden. Beispielsweise können Apps, die auf Azure Arc-fähigen Servern ausgeführt werden, verwaltete Identitäten verwenden, um eine Verbindung mit Azure-Diensten herzustellen. Weitere Informationen finden Sie unter Authentifizieren von Azure-Ressourcen mit Azure Arc-fähigen Servern.

Sie können ein SAS-Token (Shared Access Signature) für den Zugriff auf einen Container, ein Verzeichnis oder ein BLOB sichern, indem Sie entweder Microsoft Entra-Anmeldeinformationen oder einen Kontoschlüssel verwenden. Ein SAS, das mit Microsoft Entra-Anmeldeinformationen gesichert ist, wird als Benutzerdelegierung SAS bezeichnet. Als bewährte Methode für die Sicherheit wird empfohlen, microsoft Entra-Anmeldeinformationen nach Möglichkeit anstelle des Kontoschlüssels zu verwenden, der einfacher kompromittiert werden kann. Wenn Ihr Anwendungsdesign freigegebene Zugriffssignaturen erfordert, verwenden Sie Microsoft Entra-Anmeldeinformationen, um eine Benutzerdelegierungs-SAS zu erstellen, um eine bessere Sicherheit zu gewährleisten.

Jede SAS ist mit einem Schlüssel signiert. Zum Erstellen einer Benutzerdelegierungs-SAS müssen Sie zuerst einen Benutzerdelegierungsschlüsselanfordern, den Sie dann zum Signieren der SAS verwenden. Der Benutzerdelegierungsschlüssel entspricht dem Kontoschlüssel, der zum Signieren eines Diensts SAS oder eines Kontos SAS verwendet wird, mit der Ausnahme, dass er auf Ihre Microsoft Entra-Anmeldeinformationen basiert. Rufen Sie zum Anfordern des Benutzerdelegierungsschlüssels den Abrufen des Benutzerdelegierungsschlüssels Vorgangs auf. Anschließend können Sie den Benutzerdelegierungsschlüssel verwenden, um die SAS zu erstellen.

Eine Benutzerdelegierungs-SAS wird für Azure Blob Storage und Azure Data Lake Storage unterstützt. Gespeicherte Zugriffsrichtlinien werden für eine Benutzerdelegierungs-SAS nicht unterstützt.

Vorsicht

Freigegebene Zugriffssignaturen sind Schlüssel, die Berechtigungen für Speicherressourcen gewähren, und Sie sollten diese genauso schützen, wie Sie einen Kontoschlüssel schützen würden. Es ist wichtig, ein SAS vor böswilliger oder unbeabsichtigter Verwendung zu schützen. Verwenden Sie die Diskretion bei der Verteilung einer SAS und haben Sie einen Plan zum Widerrufen einer kompromittierten SAS. Vorgänge, die freigegebene Zugriffssignaturen verwenden, sollten nur über eine HTTPS-Verbindung ausgeführt werden, und URIs für gemeinsame Zugriffssignaturen sollten nur in einer sicheren Verbindung wie HTTPS verteilt werden.

Informationen zur Verwendung Ihres Kontoschlüssels zum Sichern einer SAS finden Sie unter Erstellen eines SAS- und Erstellen eines Sas-Kontos.

Sas-Unterstützung der Benutzerdelegierung für den Verzeichniszugriff

Eine Benutzerdelegierungs-SAS unterstützt den Verzeichnisbereich (sr=d), wenn die Autorisierungsversion (sv) 2020-02-10 oder höher ist und ein hierarchischer Namespace (HNS) aktiviert ist. Die Semantik für den Verzeichnisbereich (sr=d) ähnelt dem Containerbereich (sr=c), mit der Ausnahme, dass der Zugriff auf ein Verzeichnis und alle Darin enthaltenen Dateien und Unterverzeichnisse beschränkt ist. Wenn sr=d angegeben wird, ist auch der sdd Abfrageparameter erforderlich.

Das Zeichenfolgen-zu-Sign-Format für die Autorisierungsversion 2020-02-10 ist unverändert.

Sas-Unterstützung der Benutzerdelegierung für einen Benutzer-OID

Die SAS der Benutzerdelegierung unterstützt einen optionalen Benutzerobjektbezeichner (OID), der entweder im saoid- oder suoid-Parameter übertragen wird, wenn die Autorisierungsversion (sv) 2020-02-10 oder höher ist. Die Parameter saoid und suoid entsprechen dem Sicherheitsprinzipal für den Endbenutzer, der die SAS verwendet, und stellt ein erweitertes Autorisierungsmodell für Multi-User-Clusterworkloads wie Hadoop und Spark bereit.

SAS-Token können auf einen bestimmten Dateisystemvorgang und einen bestimmten Benutzer beschränkt werden, wodurch ein weniger anfälliges Zugriffstoken bereitgestellt wird, das für die Verteilung über einen Multibenutzercluster sicherer ist. Ein Anwendungsfall für diese Features ist die Integration des Hadoop ABFS-Treibers mit Apache Ranger.

Weitere Informationen zu den optionalen saoid- und suoid-Parametern finden Sie unter Angeben einer signierten Benutzerobjekt-ID.

Autorisieren einer Benutzerdelegierung SAS

Wenn ein Client mit einer Benutzerdelegierungs-SAS auf eine Blob Storage-Ressource zugreift, wird die Anforderung an Azure Storage mit den Microsoft Entra-Anmeldeinformationen autorisiert, die zum Erstellen der SAS verwendet wurden. Der Zugriff des Clients auf die Ressource wird durch die folgenden Berechtigungen bestimmt:

  • Die rollenbasierten Zugriffssteuerungsberechtigungen (RBAC), die dem Microsoft Entra-Sicherheitsprinzipal gewährt werden, der den Benutzerdelegierungsschlüssel angefordert hat.
  • Die POSIX-Zugriffssteuerungslistenberechtigungen (Access Control List, ACL), die dem Sicherheitsprinzipal gewährt werden, der den Benutzerdelegierungsschlüssel angefordert hat. Diese zusätzliche Überprüfung erfolgt nur, wenn RBAC-Berechtigungen keinen Zugriff gewähren können, und nur, wenn der hierarchische Namespace für das Speicherkonto aktiviert ist.
  • Die Berechtigungen, die explizit für das SAS-Token erteilt werden.

Dieser Ansatz bietet eine zusätzliche Sicherheitsstufe und hilft Ihnen zu vermeiden, dass Sie Ihren Kontozugriffsschlüssel mit Ihrem Anwendungscode speichern müssen. Aus diesen Gründen ist das Erstellen eines SAS mithilfe von Microsoft Entra-Anmeldeinformationen eine bewährte Methode für die Sicherheit.

Die Berechtigungen, die einem Client gewährt werden, der über die SAS verfügt, sind die Schnittmenge der Berechtigungen, die dem Sicherheitsprinzipal gewährt wurden, der den Benutzerdelegierungsschlüssel angefordert hat, und die Berechtigungen, die der Ressource im SAS-Token mit dem Feld signedPermissions (sp) erteilt wurden. Wenn dem Sicherheitsprinzipal eine Berechtigung über RBAC oder POSIX ACLs nicht auch für das SAS-Token gewährt wird, wird diese Berechtigung nicht dem Client gewährt, der versucht, die SAS für den Zugriff auf die Ressource zu verwenden. Stellen Sie beim Erstellen einer Benutzerdelegierungs-SAS sicher, dass die über RBAC und POSIX ACLs gewährten Berechtigungen und die über das SAS-Token erteilten Berechtigungen beide auf die Vom Client erforderliche Zugriffsebene ausgerichtet sind.

Gehen Sie wie folgt vor, um eine Benutzerdelegierungs-SAS zu erstellen:

  1. Verwenden Sie RBAC oder POSIX ACLs, um dem Sicherheitsprinzipal die gewünschten Berechtigungen zu erteilen, die den Benutzerdelegierungsschlüssel anfordern.
  2. Erwerben Sie ein OAuth 2.0-Token aus der Microsoft Entra-ID.
  3. Verwenden Sie das Token, um den Benutzerdelegierungsschlüssel anzufordern, indem Sie den vorgang Abrufen des Benutzerdelegierungsschlüssels aufrufen.
  4. Verwenden Sie den Benutzerdelegierungsschlüssel, um das SAS-Token mit den entsprechenden Feldern zu erstellen.

Zuweisen von Berechtigungen mit RBAC

Der Sicherheitsprinzipal, der den Benutzerdelegierungsschlüssel anfordert, muss über die entsprechenden Berechtigungen verfügen. Ein Microsoft Entra ID-Sicherheitsprinzipal kann ein Benutzer, eine Gruppe, ein Dienstprinzipal oder eine verwaltete Identität sein.

Um den Benutzerdelegierungsschlüssel anzufordern, müssen Sie einem Sicherheitsprinzipal die Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey Aktion zuweisen. Zu den folgenden integrierten RBAC-Rollen gehören die Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey-Aktion, entweder explizit oder als Teil einer Wildcarddefinition:

Da der vorgang Get User Delegation Key operation at the level of the storage account, the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action must be scoped at the level of the storage account, the resource group, or the subscription. Wenn dem Sicherheitsprinzipal eine der zuvor aufgeführten, integrierten Rollen oder eine benutzerdefinierte Rolle zugewiesen wird, die den Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey Aktion auf der Ebene des Speicherkontos, der Ressourcengruppe oder des Abonnements enthält, kann der Sicherheitsprinzipal dann den Benutzerdelegierungsschlüssel anfordern.

Wenn dem Sicherheitsprinzipal eine Rolle zugewiesen wird, die den Datenzugriff zulässt, aber auf die Ebene eines Containers festgelegt ist, können Sie dem Sicherheitsprinzipal auf der Ebene des Speicherkontos, der Ressourcengruppe oder des Abonnements zusätzlich die rolle Storage Blob Delegator Rolle zuweisen. Der Rolle "Storage Blob Delegator" gewährt den Sicherheitsprinzipalberechtigungen, um den Benutzerdelegierungsschlüssel anzufordern.

Weitere Informationen zu RBAC-Rollen für Azure Storage finden Sie unter Autorisieren mit Microsoft Entra.

Abrufen eines OAuth 2.0-Tokens

Um den Benutzerdelegierungsschlüssel abzurufen, fordern Sie zuerst ein OAuth 2.0-Token von Microsoft Entra ID an. Stellen Sie das Token mit dem Bearer-Schema bereit, um den Aufruf des Abrufen des Benutzerdelegierungsschlüssels Vorgangs zu autorisieren. Weitere Informationen zum Anfordern eines OAuth-Tokens von der Microsoft Entra-ID finden Sie unter Authentifizierungsflüsse und Anwendungsszenarien.

Anfordern des Benutzerdelegierungsschlüssels

Ein Aufruf des Abrufen des Benutzerdelegierungsschlüssels Vorgangs gibt den Schlüssel als Wertesatz zurück, der als Parameter für das SAS-Token der Benutzerdelegierung verwendet wird. Diese Parameter werden im Abrufen des Benutzerdelegierungsschlüssels Referenz und im nächsten Abschnitt "Konstruieren einer Benutzerdelegierung SAS" beschrieben.

Wenn ein Client einen Benutzerdelegierungsschlüssel mithilfe eines OAuth 2.0-Tokens anfordert, gibt Azure Storage den Benutzerdelegierungsschlüssel im Namen des Sicherheitsprinzipals zurück. Der SAS, der mit dem Benutzerdelegierungsschlüssel erstellt wurde, erhält die Berechtigungen, die dem Sicherheitsprinzipal gewährt werden.

Nachdem Sie über den Benutzerdelegierungsschlüssel verfügen, können Sie ihn verwenden, um eine beliebige Anzahl freigegebener Zugriffssignaturen für die Benutzerdelegierung während der Lebensdauer des Schlüssels zu erstellen. Der Benutzerdelegierungsschlüssel ist unabhängig vom OAuth 2.0-Token, das Sie zum Abrufen verwenden, sodass das Token nicht erneuert werden muss, solange der Schlüssel noch gültig ist. Sie können angeben, dass der Schlüssel für einen Zeitraum von bis zu sieben Tagen gültig ist.

Erstellen einer Benutzerdelegierungs-SAS

In der folgenden Tabelle sind die Felder zusammengefasst, die für ein SAS-Token der Benutzerdelegierung unterstützt werden. Nachfolgende Abschnitte enthalten zusätzliche Details zur Angabe dieser Parameter.

SAS-Feldname SAS-Tokenparameter Erforderlich oder optional Versionsunterstützung Beschreibung
signedVersion sv Erforderlich 2018-11-09 und höher Gibt die Version des Diensts an, der zum Erstellen des Signaturfelds verwendet wird. Außerdem wird die Dienstversion angegeben, die Anforderungen verarbeitet, die mit diesem SAS vorgenommen werden.
signedResource sr Erforderlich Alle Gibt an, auf welche Blobressourcen über die Signatur für den freigegebenen Zugriff zugegriffen werden kann.
signedStart st Wahlfrei Alle Wahlfrei. Der Zeitpunkt, zu dem die Signatur des freigegebenen Zugriffs gültig wird, ausgedrückt in einem der akzeptierten ISO 8601 UTC-Formate. Wenn dieser Wert nicht angegeben wird, wird die aktuelle UTC-Zeit als Startzeit verwendet. Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Format DateTime-Werte.
signedExpiry se Erforderlich Alle Der Zeitpunkt, zu dem die Signatur für den freigegebenen Zugriff ungültig wird, ausgedrückt in einem der akzeptierten ISO 8601 UTC-Formate. Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Format DateTime-Werte.
signedPermissions sp Erforderlich Alle Gibt an, welche Vorgänge ein Client besitzt, der über die SAS verfügt, für die Ressource ausgeführt werden kann. Berechtigungen können kombiniert werden.
signedIp sip Wahlfrei 2015-04-05 und höher Gibt eine IP-Adresse oder einen inklusiven Bereich von IP-Adressen an, aus denen Anforderungen akzeptiert werden sollen. Beachten Sie beim Angeben eines Bereichs, dass der Bereich inklusive ist. Es werden nur IPv4-Adressen unterstützt.

Beispiel: sip=198.51.100.0 oder sip=198.51.100.10-198.51.100.20.
signedProtocol spr Wahlfrei 2015-04-05 und höher Gibt das Protokoll an, das für eine Anforderung mit der SAS zulässig ist. Schließen Sie dieses Feld ein, damit Anforderungen, die mit dem SAS-Token vorgenommen wurden, HTTPS verwenden.
signedObjectId skoid Erforderlich 2018-11-09 und höher Gibt die Objekt-ID für einen Microsoft Entra-Sicherheitsprinzipal an. Diese Objekt-ID entspricht dem Sicherheitsprinzipal, der den Benutzerdelegierungsschlüssel angefordert hat.

Vor der Autorisierung des Vorgangs überprüft Azure Storage RBAC-Berechtigungen anhand der Objekt-ID. Wenn RBAC-Berechtigungen keinen Zugriff gewähren können, überprüft Azure Storage POSIX ACL-Berechtigungen anhand der Objekt-ID.
signedTenantId sktid Erforderlich 2018-11-09 und höher Gibt den Microsoft Entra-Mandanten an, in dem ein Sicherheitsprinzipal definiert ist.
signedKeyStartTime skt Erforderlich. 2018-11-09 und höher Der Wert wird vom Vorgang "Benutzerdelegierungsschlüssel abrufen" zurückgegeben. Gibt den Beginn der Lebensdauer des Benutzerdelegierungsschlüssels an, ausgedrückt in einem der akzeptierten ISO 8601 UTC-Formate. Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Format DateTime-Werte.
signedKeyExpiryTime ske Erforderlich 2018-11-09 und höher Der Wert wird vom Vorgang "Benutzerdelegierungsschlüssel abrufen" zurückgegeben. Gibt das Ende der Lebensdauer des Benutzerdelegierungsschlüssels an, ausgedrückt in einem der akzeptierten ISO 8601 UTC-Formate. Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Format DateTime-Werte.
signedKeyVersion skv Erforderlich 2018-11-09 und höher Der Wert wird vom Vorgang "Benutzerdelegierungsschlüssel abrufen" zurückgegeben. Gibt die Speicherdienstversion an, die zum Abrufen des Benutzerdelegierungsschlüssels verwendet wurde. Dieses Feld muss Version 2018-11-09 oder höher angeben.
signedKeyService sks Erforderlich 2018-11-09 und höher Gibt den Dienst an, für den der Benutzerdelegierungsschlüssel gültig ist. Derzeit wird nur Blob Storage unterstützt.
signedAuthorizedObjectId saoid Wahlfrei 2020-02-10 und höher Gibt die Objekt-ID eines Microsoft Entra-Sicherheitsprinzipals an, der vom Besitzer des Benutzerdelegierungsschlüssels autorisiert wurde, um die vom SAS-Token gewährte Aktion auszuführen. Diese Objekt-ID entspricht dem Sicherheitsprinzipal für den Endbenutzer der SAS. Es wird keine zusätzliche Berechtigungsprüfung für POSIX-Zugriffssteuerungslisten (ACLs) durchgeführt.
signedUnauthorizedObjectId suoid Wahlfrei 2020-02-10 und höher Gibt die Objekt-ID für einen Microsoft Entra-Sicherheitsprinzipal an, wenn ein hierarchischer Namespace aktiviert ist. Diese Objekt-ID entspricht dem Sicherheitsprinzipal für den Endbenutzer der SAS. Azure Storage führt eine POSIX ACL-Überprüfung anhand der Objekt-ID durch, bevor sie den Vorgang autorisiert.
signedCorrelationId scid Wahlfrei 2020-02-10 und höher Korrelieren Sie die Speicherüberwachungsprotokolle mit den Überwachungsprotokollen, die vom Prinzipal verwendet werden, der die SAS generiert und verteilt.
signedDirectoryDepth sdd Erforderlich, wenn sr=d 2020-02-10 und höher Gibt die Anzahl der Verzeichnisse innerhalb des Stammordners des Verzeichnisses an, das im feld canonicalizedResource des Zeichenfolgen-zu-Signierens angegeben ist.
signedEncryptionScope ses Wahlfrei 2020-12-06 und höher Gibt den Verschlüsselungsbereich an, der zum Verschlüsseln des Anforderungsinhalts verwendet werden soll.
signature sig Erforderlich Alle Die Signatur ist ein hashbasierter Nachrichtenauthentifizierungscode (HMAC), der mithilfe des SHA256-Algorithmus über die Zeichenfolgen-zu-Signierung und den Schlüssel berechnet und dann mithilfe der Base64-Codierung codiert wird.
Cache-Control Antwortheader rscc Wahlfrei 2013-08-15 und höher Azure Storage legt den Cache-Control Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.
Content-Disposition Antwortheader rscd Wahlfrei 2013-08-15 und höher Azure Storage legt den Content-Disposition Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.
Content-Encoding Antwortheader rsce Wahlfrei 2013-08-15 und höher Azure Storage legt den Content-Encoding Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.
Content-Language Antwortheader rscl Wahlfrei 2013-08-15 und höher Azure Storage legt den Content-Language Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.
Content-Type Antwortheader rsct Wahlfrei 2013-08-15 und höher Azure Storage legt den Content-Type Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.

Angeben des Felds für die signierte Version

Das erforderliche feld signedVersion (sv) gibt die Dienstversion für die Signatur für den freigegebenen Zugriff an. Dieser Wert gibt die Version des Diensts an, der zum Erstellen des felds signature verwendet wird, und gibt die Dienstversion an, die eine Anforderung verarbeitet, die mit dieser gemeinsamen Zugriffssignatur vorgenommen wurde. Der Wert des Felds sv muss Version 2018-11-09 oder höher sein.

Angeben des signierten Ressourcenfelds

Das erforderliche feld signedResource (sr) gibt an, auf welche Ressourcen über die Signatur für den freigegebenen Zugriff zugegriffen werden kann. In der folgenden Tabelle wird beschrieben, wie Sie auf eine BLOB-, Container- oder Verzeichnisressource im SAS-Token verweisen:

Ressource Parameterwert Unterstützte Versionen Beschreibung
Blob b Alle Gewährt Zugriff auf den Inhalt und die Metadaten des Blobs.
BLOB-Version Bv 2018-11-09 und höher Gewährt Zugriff auf den Inhalt und die Metadaten der BLOB-Version, aber nicht auf das Basis-Blob.
Blob-Momentaufnahme Bs 2018-11-09 und höher Gewährt Zugriff auf den Inhalt und die Metadaten der Blob-Momentaufnahme, aber nicht auf das Basis-Blob.
Container c Alle Gewährt Zugriff auf den Inhalt und die Metadaten eines beliebigen Blobs im Container und auf die Liste der Blobs im Container.
Verzeichnis d 2020-02-10 und höher Gewährt Zugriff auf den Inhalt und die Metadaten eines beliebigen Blobs im Verzeichnis und auf die Liste der Blobs im Verzeichnis in einem Speicherkonto mit aktiviertem hierarchischen Namespace. Wenn für das feld signedResource ein Verzeichnis angegeben ist, ist auch der parameter signedDirectoryDepth (sdd) erforderlich. Ein Verzeichnis befindet sich immer innerhalb eines Containers.

Angeben der Gültigkeitsdauer der Signatur

Die Felder signedStart (st) und signedExpiry (se) geben die Start- und Ablaufzeiten für die SAS an. Das feld signedExpiry ist erforderlich. Das feld signedStart ist optional. Wenn sie weggelassen wird, wird die aktuelle UTC-Zeit als Startzeit verwendet.

Bei einer Benutzerdelegierungs-SAS sollte die Start- und Ablaufzeit für die SAS innerhalb des Intervalls sein, das für den Benutzerdelegierungsschlüssel definiert ist. Wenn ein Client versucht, ein SAS zu verwenden, nachdem der Benutzerdelegierungsschlüssel abgelaufen ist, schlägt die SAS mit einem Autorisierungsfehler fehl, unabhängig davon, ob die SAS selbst noch gültig ist.

Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Format DateTime-Werte.

Berechtigungen angeben

Die Berechtigungen, die für das Feld signedPermissions (sp) im SAS-Token angegeben sind, geben an, welche Vorgänge ein Client, der die SAS besitzt, für die Ressource ausführen kann.

Berechtigungen können kombiniert werden, um einem Client zu ermöglichen, mehrere Vorgänge mit demselben SAS auszuführen. Wenn Sie die SAS erstellen, müssen Sie Berechtigungen in der folgenden Reihenfolge einschließen:

racwdxltmeop

Beispiele für gültige Berechtigungseinstellungen für einen Container sind rw, rd, rl, wd, wlund rl. Beispiele für ungültige Einstellungen sind wr, dr, lrund dw. Die Angabe einer Berechtigungsbezeichnung ist mehrmals nicht zulässig.

Eine Benutzerdelegierungs-SAS kann keinen Zugriff auf bestimmte Vorgänge gewähren:

  • Container können nicht erstellt, gelöscht oder aufgelistet werden.
  • Containermetadaten und -eigenschaften können nicht gelesen oder geschrieben werden.
  • Container können nicht geleast werden.

Um ein SAS zu erstellen, das Zugriff auf diese Vorgänge gewährt, verwenden Sie ein Konto-SAS. Weitere Informationen finden Sie unter Erstellen eines SAS-eines Kontos.

Die berechtigungen, die für jeden Ressourcentyp unterstützt werden, werden in der folgenden Tabelle beschrieben:

Erlaubnis URI-Symbol Ressource Versionsunterstützung Zulässige Vorgänge
Lesen r Container
Verzeichnis
Blob		 Alle Lesen Sie den Inhalt, die Blockliste, die Eigenschaften und Metadaten eines beliebigen Blobs im Container oder Verzeichnis. Verwenden Sie ein BLOB als Quelle eines Kopiervorgangs.
Hinzufügen ein Container
Verzeichnis
Blob		 Alle Fügen Sie einem Anfüge-BLOB einen Block hinzu.
Schaffen c Container
Verzeichnis
Blob		 Alle Schreiben Sie ein neues Blob, eine Momentaufnahme eines Blobs oder kopieren Sie ein Blob in ein neues Blob.
Schreiben w Container
Verzeichnis
Blob		 Alle Erstellen oder Schreiben von Inhalten, Eigenschaften, Metadaten oder Blocklisten. Momentaufnahme oder Lease des Blobs. Ändern Sie die Größe des Blobs (nur Seitenblob). Verwenden Sie das Blob als Ziel eines Kopiervorgangs.
Löschen d Container
Verzeichnis
Blob		 Alle Löschen eines Blobs. Für Version 2017-07-29 und höher ermöglicht die Berechtigung "Löschen" auch das Unterbrechen einer Lease für ein Blob. Weitere Informationen finden Sie im vorgang Lease Blob.
Version löschen x Container
Blob		 2019-12-12 und höher Löschen sie eine BLOB-Version.
Dauerhaftes Löschen y Blob 2020-02-10 und höher Endgültiges Löschen einer Blob-Momentaufnahme oder -Version.
Liste l Container
Verzeichnis		 Alle Blobs nicht rekursiv auflisten.
Schilder t Blob 2019-12-12 und höher Lesen oder Schreiben der Tags in einem Blob.
Bewegen m Container
Verzeichnis
Blob		 2020-02-10 und höher Verschieben sie ein BLOB oder ein Verzeichnis und dessen Inhalt an einen neuen Speicherort. Dieser Vorgang kann optional auf den Besitzer des untergeordneten BLOB-, Verzeichnis- oder übergeordneten Verzeichnisses beschränkt werden, wenn der parameter saoid im SAS-Token enthalten ist und das Sticky-Bit im übergeordneten Verzeichnis festgelegt ist.
Ausführen e Container
Verzeichnis
Blob		 2020-02-10 und höher Rufen Sie die Systemeigenschaften ab, und rufen Sie, wenn der hierarchische Namespace für das Speicherkonto aktiviert ist, die POSIX-ACL eines Blobs ab. Wenn der hierarchische Namespace aktiviert ist und der Aufrufer der Besitzer eines Blobs ist, gewährt diese Berechtigung die Möglichkeit, die besitzereigene Gruppe, POSIX-Berechtigungen und POSIX-ACL des Blobs festzulegen. Der Aufrufer kann keine benutzerdefinierten Metadaten lesen.
Eigentum o Container
Verzeichnis
Blob		 2020-02-10 und höher Wenn der hierarchische Namespace aktiviert ist, kann der Aufrufer den Besitzer oder die Besitzergruppe festlegen oder als Besitzer fungieren, wenn der Aufrufer ein Verzeichnis oder blob innerhalb eines Verzeichnisses umbenennt oder löscht, in dem das Sticky-Bit festgelegt ist.
Erlaubnisse p Container
Verzeichnis
Blob		 2020-02-10 und höher Wenn der hierarchische Namespace aktiviert ist, kann der Aufrufer Berechtigungen und POSIX ACLs für Verzeichnisse und Blobs festlegen.
Festlegen der Unveränderlichkeitsrichtlinie Ich Container
Blob		 2020-06-12 und höher Festlegen oder Löschen der Unveränderbarkeitsrichtlinie oder der gesetzlichen Aufbewahrungspflicht für ein Blob.

Angeben einer IP-Adresse oder eines IP-Bereichs

Das optionale feld signedIp (sip) gibt eine öffentliche IP-Adresse oder einen Bereich von öffentlichen IP-Adressen an, aus denen Anforderungen akzeptiert werden sollen. Wenn die IP-Adresse, aus der die Anforderung stammt, nicht mit der IP-Adresse oder dem Adressbereich übereinstimmt, die im SAS-Token angegeben ist, ist die Anforderung nicht autorisiert. Es werden nur IPv4-Adressen unterstützt.

Wenn Sie einen Bereich von IP-Adressen angeben, ist der Bereich inklusive. Wenn Sie z. B. sip=198.51.100.0 oder sip=198.51.100.10-198.51.100.20 für die SAS angeben, wird die Anforderung auf diese IP-Adressen beschränkt.

In der folgenden Tabelle wird beschrieben, ob das feld signedIp in ein SAS-Token für ein bestimmtes Szenario einbezogen werden soll, basierend auf der Clientumgebung und dem Speicherort des Speicherkontos.

Clientumgebung Speicherort des Speicherkontos Empfehlung
Client, der in Azure ausgeführt wird In derselben Region wie der Client Eine SAS, die dem Client in diesem Szenario bereitgestellt wird, sollte keine ausgehende IP-Adresse für das feld signedIp enthalten. Anforderungen, die Sie innerhalb derselben Region vornehmen, indem Sie eine SAS mit einer angegebenen ausgehenden IP-Adresse verwenden, schlagen fehl.

Verwenden Sie stattdessen ein virtuelles Azure-Netzwerk, um Netzwerksicherheitseinschränkungen zu verwalten. Anforderungen an Azure Storage innerhalb derselben Region erfolgen immer über eine private IP-Adresse. Weitere Informationen finden Sie unter Konfigurieren von Azure Storage-Firewalls und virtuellen Netzwerken.
Client, der in Azure ausgeführt wird In einer anderen Region als der Client Eine SAS, die dem Client in diesem Szenario bereitgestellt wird, kann eine öffentliche IP-Adresse oder einen Adressbereich für das Feld signedIp enthalten. Anforderungen, die Sie mit der SAS vornehmen, müssen von der angegebenen IP-Adresse oder dem angegebenen Adressbereich stammen.
Client, der lokal oder in einer anderen Cloudumgebung ausgeführt wird In einer beliebigen Azure-Region Eine SAS, die dem Client in diesem Szenario bereitgestellt wird, kann eine öffentliche IP-Adresse oder einen Adressbereich für das Feld signedIp enthalten. Anforderungen, die Sie mit der SAS vornehmen, müssen von der angegebenen IP-Adresse oder dem angegebenen Adressbereich stammen.

Wenn die Anforderung einen Proxy oder ein Gateway durchläuft, stellen Sie die öffentliche ausgehende IP-Adresse dieses Proxys oder Gateways für das feld signedIp bereit.

Angeben des HTTP-Protokolls

Das optionale signedProtocol (spr) -Feld gibt das Protokoll an, das für Anforderungen zulässig ist, die mit der SAS vorgenommen werden. Mögliche Werte sind sowohl HTTPS als auch HTTP (https,http) oder NUR HTTPS (https). Der Standardwert ist https,http.

Anmerkung

Es ist nicht möglich, HTTP für das feld spr anzugeben.

Angeben der signierten Objekt-ID

Das feld signedObjectId (skoid) ist für eine Benutzerdelegierung SAS erforderlich. Der Get User Delegation Key Operation gibt diesen Wert als Teil der Antwort zurück. Die signierte Objekt-ID ist ein GUID-Wert, der dem unveränderlichen Bezeichner für einen Sicherheitsprinzipal in der Microsoft Identity Platform dient.

Angeben der signierten Mandanten-ID

Das feld signedTenantId (sktid) ist für eine Benutzerdelegierung SAS erforderlich. Der Get User Delegation Key Operation gibt diesen Wert als Teil der Antwort zurück. Die signierte Mandanten-ID ist ein GUID-Wert, der den Microsoft Entra-Mandanten darstellt, in dem ein Sicherheitsprinzipal definiert ist.

Angeben der Startzeit des signierten Schlüssels

Das erforderliche feld signedKeyStartTime (skt) gibt den Anfang der Lebensdauer des Benutzerdelegierungsschlüssels im ISO-Datumsformat an. Der Get User Delegation Key Operation gibt diesen Wert als Teil der Antwort zurück.

Angeben der Ablaufzeit des signierten Schlüssels

Das feld signedKeyExpiryTime (ske) ist für eine Benutzerdelegierung SAS im ISO-Datumsformat erforderlich. Der Get User Delegation Key Operation gibt diesen Wert als Teil der Antwort zurück. Die Ablaufzeit des signierten Schlüssels gibt das Ende der Lebensdauer des Benutzerdelegierungsschlüssels an. Der Wert der Ablaufzeit kann maximal sieben Tage ab der Startzeit des SAS betragen.

Angeben des signierten Schlüsseldiensts

Das feld signedKeyService (sks) ist für eine Benutzerdelegierung SAS erforderlich. Der Get User Delegation Key Operation gibt diesen Wert als Teil der Antwort zurück. Das Feld "Signierter Schlüsseldienst" gibt den Dienst an, für den der Benutzerdelegierungsschlüssel gültig ist. Der Wert für das signierte Schlüsseldienstfeld für Blob Storage ist b.

Angeben der signierten Schlüsselversion

Das feld signedkeyversion (skv) ist für eine Benutzerdelegierung SAS erforderlich. Der Get User Delegation Key Operation gibt diesen Wert als Teil der Antwort zurück. Das Feld signedkeyversion gibt die Speicherdienstversion an, die zum Abrufen des Benutzerdelegierungsschlüssels verwendet wird. Dieses Feld muss Version 2018-11-09 oder höher angeben.

Angeben einer signierten Benutzerobjekt-ID für einen Sicherheitsprinzipal

Die optionalen signedAuthorizedObjectId (saoid) und signedUnauthorizedObjectId (suoid) Felder ermöglichen die Integration mit Apache Hadoop und Apache Ranger für Azure Data Lake Storage-Workloads. Verwenden Sie eines der folgenden Felder im SAS-Token, um die Objekt-ID für einen Sicherheitsprinzipal anzugeben:

  • Das Feld saoid gibt die Objekt-ID für einen Microsoft Entra-Sicherheitsprinzipal an, der vom Besitzer des Benutzerdelegierungsschlüssels autorisiert ist, um die vom SAS-Token gewährte Aktion auszuführen. Azure Storage überprüft das SAS-Token und stellt sicher, dass der Besitzer des Benutzerdelegierungsschlüssels über die erforderlichen Berechtigungen verfügt, bevor Azure Storage Zugriff gewährt. Es wird keine zusätzliche Berechtigungsprüfung für POSIX ACLs ausgeführt.
  • Das feld suoid gibt die Objekt-ID für einen Microsoft Entra-Sicherheitsprinzipal an, wenn ein hierarchischer Namespace für ein Speicherkonto aktiviert ist. Das feld suoid ist nur für Konten gültig, die über einen hierarchischen Namespace verfügen. Wenn das feld suoid im SAS-Token enthalten ist, führt Azure Storage eine POSIX ACL-Überprüfung anhand der Objekt-ID durch, bevor er den Vorgang autorisiert. Wenn diese ACL-Überprüfung nicht erfolgreich ist, schlägt der Vorgang fehl. Ein hierarchischer Namespace muss für das Speicherkonto aktiviert werden, wenn das feld suoid im SAS-Token enthalten ist. Andernfalls schlägt die Berechtigungsprüfung mit einem Autorisierungsfehler fehl.

Die Objekt-ID für den Sicherheitsprinzipal, der den Benutzerdelegierungsschlüssel anfordert, wird im erforderlichen skoid Feld erfasst. Um eine Objekt-ID im SAS-Token mit dem Feld saoid oder suoid anzugeben, muss dem im Feld skoid Feld identifizierten Sicherheitsprinzipal eine RBAC-Rolle zugewiesen werden, die Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action oder Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/actionenthält. Weitere Informationen zu diesen Aktionen finden Sie unter Azure-Ressourcenanbietervorgänge.

Wenn Sie die Objekt-ID im Feld saoid oder suoid angeben, beschränken Sie auch Vorgänge, die mit Verzeichnis- oder Blobbesitz zusammenhängen, wie folgt:

  • Wenn ein Vorgang ein Verzeichnis oder blob erstellt, legt Azure Storage den Besitzer des Verzeichnisses oder Blobs auf den Wert fest, der durch die Objekt-ID angegeben wird. Wenn die Objekt-ID nicht angegeben ist, legt Azure Storage den Besitzer des Verzeichnisses oder BLOB auf den Wert fest, der durch den parameter skoid angegeben wird.
  • Wenn das Sticky-Bit im übergeordneten Verzeichnis festgelegt ist und der Vorgang ein Verzeichnis oder blob löscht oder umbenannt, muss die Objekt-ID des Besitzers des übergeordneten Verzeichnisses oder der Besitzer der Ressource mit dem durch die Objekt-ID angegebenen Wert übereinstimmen.
  • Wenn ein Vorgang den Besitzer für ein Verzeichnis oder blob festlegt und der x-ms-owner Header angegeben wird, muss der durch die Objekt-ID angegebene Wert mit dem wert übereinstimmen, der durch den x-ms-owner-Header angegeben wird.
  • Wenn ein Vorgang die Gruppe für ein Verzeichnis oder blob festlegt und der x-ms-group Header angegeben wird, muss der durch die Objekt-ID angegebene Wert ein Mitglied der Gruppe sein, die durch den x-ms-group Header angegeben wird.
  • Wenn ein Vorgang die Berechtigungen oder ACL für ein Verzeichnis oder blob festlegt, muss auch eine der folgenden beiden Bedingungen erfüllt sein:
    • Der für die Objekt-ID angegebene Wert muss der Besitzer des Verzeichnisses oder Blobs sein.
    • Der Wert des Felds signedPermissions (sp) muss zusätzlich zur berechtigung Ownership (o) die berechtigung Permissions (p) enthalten.

Die im feld saoid oder suoid angegebene Objekt-ID ist in Diagnoseprotokollen enthalten, wenn Sie Anforderungen mithilfe des SAS-Tokens ausführen.

Das feld saoid oder suoid wird nur unterstützt, wenn das feld signedVersion (sv) auf Version 2020-02-10 oder höher festgelegt ist. Nur eines dieser Felder kann im SAS-Token enthalten sein.

Angeben einer Korrelations-ID

Das Feld signedCorrelationId (scid) gibt eine Korrelations-ID an, die verwendet werden kann, um die Speicherüberwachungsprotokolle mit den Überwachungsprotokollen zu korrelieren, die vom Prinzipal verwendet werden, der die SAS generiert und verteilt. Beispielsweise verfügt ein vertrauenswürdiger Autorisierungsdienst über eine verwaltete Identität, die Benutzer authentifiziert und autorisiert, eine SAS generiert, einen Eintrag zum lokalen Überwachungsprotokoll hinzufügt und die SAS an einen Benutzer zurückgibt, der dann die SAS für den Zugriff auf Azure Storage-Ressourcen verwenden kann. Indem Sie sowohl im lokalen Überwachungsprotokoll als auch im Speicherüberwachungsprotokoll eine Korrelations-ID einschließen, können diese Ereignisse später korreliert werden. Der Wert ist eine GUID ohne geschweifte Klammern und mit Kleinbuchstaben.

Dieses Feld wird mit Version 2020-02-10 und höher unterstützt.

Angeben der Verzeichnistiefe

Wenn das feld signedResource ein Verzeichnis (sr=d) angibt, müssen Sie auch das feld signedDirectoryDepth (sdd) angeben, um die Anzahl der Unterverzeichnisse unter dem Stammverzeichnis anzugeben. Der Wert des Felds sdd muss eine nicht negative ganze Zahl sein.

Beispielsweise weist das Stammverzeichnis https://{account}.blob.core.windows.net/{container}/ eine Tiefe von 0 auf. Jedes Unterverzeichnis im Stammverzeichnis fügt der Tiefe um 1 hinzu. Das Verzeichnis https://{account}.blob.core.windows.net/{container}/d1/d2 hat eine Tiefe von 2.

Dieses Feld wird mit Version 2020-02-10 und höher unterstützt.

Angeben von Abfrageparametern zum Überschreiben von Antwortheadern

Um Werte für bestimmte Antwortheader zu definieren, die zurückgegeben werden sollen, wenn die Freigegebene Zugriffssignatur in einer Anforderung verwendet wird, können Sie Antwortheader in Abfrageparametern angeben. Die Antwortheader und die entsprechenden Abfrageparameter sind wie folgt:

Antwortheadername Entsprechender SAS-Abfrageparameter
Cache-Control rscc
Content-Disposition rscd
Content-Encoding rsce
Content-Language rscl
Content-Type rsct

Wenn Sie beispielsweise den rsct=binary Abfrageparameter für ein SAS-Token angeben, wird der Content-Type Antwortheader auf binaryfestgelegt. Dieser Wert setzt den Content-Type Kopfzeilenwert außer Kraft, der für das Blob für eine Anforderung gespeichert ist, nur mit dieser signatur für den freigegebenen Zugriff.

Wenn Sie eine Freigegebene Zugriffssignatur erstellen, die Antwortheader als Abfrageparameter angibt, müssen Sie diese Antwortheader in das Zeichenfolgen-zu-Signieren einschließen, das zum Erstellen der Signaturzeichenfolge verwendet wird. Weitere Informationen finden Sie im Abschnitt "Angeben der Signatur".

Angeben des Verschlüsselungsbereichs

Das Feld signed encryption scope (ses) gibt einen Verschlüsselungsbereich an, den die Clientanwendung verwendet, wenn Sie Blobs mithilfe des SAS-Tokens über den Vorgang Put Blob hochladen. Das feld signed encryption scope wird unterstützt, wenn das Signierte Versionsfeld (sv) im SAS-Token Version 2020-12-06 oder höher ist. Wenn das Feld "signierte Version" eine Version angibt, die älter als die unterstützte Version ist, gibt der Dienst den Fehlerantwortcode 403 (Verboten) zurück.

Wenn der Standardverschlüsselungsbereich für den Container oder das Dateisystem festgelegt ist, berücksichtigt das feld ses die Containerverschlüsselungsrichtlinie. Wenn ein Konflikt zwischen dem ses Abfrageparameter und x-ms-default-encryption-scope Header besteht und der x-ms-deny-encryption-scope-override-Header auf truefestgelegt ist, gibt der Dienst den Fehlerantwortcode 403 (Verboten) zurück.

Wenn der x-ms-encryption-scope-Header und der ses Abfrageparameter sowohl in der PUT-Anforderung bereitgestellt werden, als auch ein Konflikt vorliegt, gibt der Dienst den Fehlerantwortcode 400 (ungültige Anforderung) zurück.

Angeben der Signatur

Das Feld signature (sig) wird verwendet, um eine Anforderung eines Clients mit der Signatur für den freigegebenen Zugriff zu autorisieren. Das Zeichenfolgen-zu-Zeichen ist eine eindeutige Zeichenfolge, die aus den Feldern erstellt wird, die überprüft werden müssen, um die Anforderung zu autorisieren. Die Signatur ist ein HMAC, der mithilfe des SHA256-Algorithmus über die Zeichenfolge und den Schlüssel berechnet und dann mithilfe der Base64-Codierung codiert wird.

Um die Signaturzeichenfolge einer Benutzerdelegierungs-SAS zu erstellen, erstellen Sie die Zeichenfolge für das Signieren aus den Feldern, aus denen die Anforderung besteht, codieren Sie die Zeichenfolge als UTF-8, und berechnen Sie dann die Signatur mithilfe des HMAC-SHA256 Algorithmus. Die Felder, die im Zeichenfolgen-zu-Signieren enthalten sind, müssen URL-decodiert sein.

Die Felder, die im Zeichenfolgen-zu-Signieren erforderlich sind, hängen von der Dienstversion ab, die für die Autorisierung verwendet wird (sv Feld). In den folgenden Abschnitten wird die Zeichenfolgen-zu-Sign-Konfiguration für Versionen beschrieben, die die Sas der Benutzerdelegierung unterstützen.

Version 2020-12-06 und höher

Die Zeichenfolge für die Autorisierungsversion 2020-12-06 und höher weist das folgende Format auf:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                signedEncryptionScope + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Version 2020-02-10

Das Zeichenfolgen-zu-Signieren für die Autorisierungsversion 2020-02-10 weist das folgende Format auf:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Versionen vor 2020-02-10

Die Zeichenfolge für Autorisierungsversionen, die älter als 2020-02-10 sind, weist das folgende Format auf:

StringToSign =  signedPermissions + "\n" +  
                signedStart + "\n" +  
                signedExpiry + "\n" +  
                canonicalizedResource + "\n" +  
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +  
                signedProtocol + "\n" +  
                signedVersion + "\n" +  
                signedResource + "\n" +
                rscc + "\n" +
                rscd + "\n" +  
                rsce + "\n" +  
                rscl + "\n" +  
                rsct

Kanonische Ressource

Der canonicalizedResource Teil der Zeichenfolge ist ein kanonischer Pfad zur signierten Ressource. Er muss den Blob Storage-Endpunkt und den Ressourcennamen enthalten, und er muss URL-decodiert sein. Ein BLOB-Pfad muss seinen Container enthalten. Ein Verzeichnispfad muss die Anzahl der Unterverzeichnisse enthalten, die dem parameter sdd entsprechen.

Die kanonische Ressourcenzeichenfolge für einen Container muss den nachfolgenden Schrägstrich (/) für eine SAS weglassen, die Zugriff auf diesen Container ermöglicht.

In den folgenden Beispielen wird gezeigt, wie Sie je nach Ressourcentyp den canonicalizedResource Teil der Zeichenfolge erstellen.

Containerbeispiel (Azure Blob Storage)
URL = https://myaccount.blob.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Blob-Beispiel (Azure Blob Storage)
URL = https://myaccount.blob.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"
Containerbeispiel (Azure Data Lake Storage)
URL = https://myaccount.dfs.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Verzeichnisbeispiel (Azure Data Lake Storage)
URL = https://myaccount.dfs.core.windows.net/music/instruments/guitar/  
canonicalizedResource = "/blob/myaccount/music/instruments/guitar/"
Blob-Beispiel (Azure Data Lake Storage)
URL = https://myaccount.dfs.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"

Optionale Felder

Wenn ein Feld optional ist und nicht als Teil des SAS-Tokens bereitgestellt wird, geben Sie eine leere Zeichenfolge für das Feld an. Achten Sie darauf, das Zeilenumbruchzeichen (\n) nach der leeren Zeichenfolge einzuschließen.

Beispiel für die Sas-Stellvertretung der Benutzerdelegierung

Das folgende Beispiel zeigt einen BLOB-URI, an den ein SAS-Token der Benutzerdelegierung angefügt ist. Das SAS-Token der Benutzerdelegierung stellt Lese- und Schreibberechtigungen für das Blob bereit.

https://myaccount.blob.core.windows.net/sascontainer/blob1.txt?sp=rw&st=2023-05-24T01:13:55Z&se=2023-05-24T09:13:55Z&skoid=<object-id>&sktid=<tenant-id>&skt=2023-05-24T01:13:55Z&ske=2023-05-24T09:13:55Z&sks=b&skv=2022-11-02&sip=198.51.100.10-198.51.100.20&spr=https&sv=2022-11-02&sr=b&sig=<signature>

Jeder Teil des URI wird in der folgenden Tabelle beschrieben:

Name SAS-Teil Beschreibung
Ressourcen-URI https://myaccount.blob.core.windows.net/sascontainer/blob1.txt Die Adresse des Blobs. Es wird dringend empfohlen, HTTPS zu verwenden.
Trennzeichen ? Das Trennzeichen, das vor der Abfragezeichenfolge steht. Das Trennzeichen ist nicht Teil des SAS-Tokens.
Erlaubnisse sp=rw Die von der SAS gewährten Berechtigungen umfassen Lese-/Schreibzugriff (r) und Write (w).
Startzeit st=2023-05-24T01:13:55Z In UTC-Zeit angegeben. Wenn die SAS sofort gültig sein soll, lassen Sie die Startzeit aus.
Ablaufzeit se=2023-05-24T09:13:55Z In UTC-Zeit angegeben.
Objekt-ID skoid=<object-id> Ein Microsoft Entra-Sicherheitsprinzipal.
Mandanten-ID sktid=<tenant-id> Der Microsoft Entra-Mandant, in dem der Sicherheitsprinzipal registriert ist.
Schlüsselanfangszeit skt=2023-05-24T01:13:55Z Der Anfang der Lebensdauer des Benutzerdelegierungsschlüssels.
Ablaufzeit des Schlüssels ske=2023-05-24T09:13:55Z Das Ende der Lebensdauer des Benutzerdelegierungsschlüssels.
Schlüsseldienst sks=b Nur der BLOB-Dienst wird für den Dienstwert unterstützt.
Schlüsselversion skv=2022-11-02 Die Speicherdienstversion, die zum Abrufen des Benutzerdelegierungsschlüssels verwendet wurde.
IP-Bereich sip=198.51.100.10-198.51.100.20 Der Bereich der IP-Adressen, von denen eine Anforderung akzeptiert wird.
Protokoll spr=https Es sind nur Anforderungen zulässig, die HTTPS verwenden.
BLOB-Dienstversion sv=2022-11-02 Für Azure Storage Version 2012-02-12 und höher gibt dieser Parameter die zu verwendende Version an.
Ressource sr=b Die Ressource ist ein Blob.
Unterschrift sig=<signature> Wird verwendet, um den Zugriff auf das Blob zu autorisieren. Die Signatur ist ein HMAC, der mithilfe des SHA256-Algorithmus über eine Zeichenfolge und einen Schlüssel berechnet und dann mithilfe der Base64-Codierung codiert wird.

Widerrufen einer Benutzerdelegierungs-SAS

Wenn Sie der Meinung sind, dass eine SAS kompromittiert wurde, sollten Sie es widerrufen. Sie können eine Benutzerdelegierungs-SAS widerrufen, indem Sie den Benutzerdelegierungsschlüssel widerrufen oder RBAC-Rollenzuweisungen und POSIX ACLs für den Sicherheitsprinzipal ändern oder entfernen, der zum Erstellen der SAS verwendet wird.

Wichtig

Sowohl der Benutzerdelegierungsschlüssel als auch die RBAC-Rollenzuweisungen werden von Azure Storage zwischengespeichert. Daher kann es zu einer Verzögerung zwischen dem Initiieren des Sperrvorgangs und dem Ungültigkeit einer vorhandenen Benutzerdelegierungs-SAS kommen.

Widerrufen des Benutzerdelegierungsschlüssels

Sie können den Benutzerdelegierungsschlüssel widerrufen, indem Sie den Vorgang Benutzerdelegierungsschlüssel widerrufen. Wenn Sie den Benutzerdelegierungsschlüssel widerrufen, werden alle freigegebenen Zugriffssignaturen, die auf diesem Schlüssel basieren, ungültig. Anschließend können Sie die Vorgang "Benutzerdelegierungsschlüssel abrufen" erneut aufrufen und den Schlüssel verwenden, um neue Signaturen für den freigegebenen Zugriff zu erstellen. Dies ist die schnellste Möglichkeit, eine Benutzerdelegierungs-SAS zu widerrufen.

Ändern oder Entfernen von Rollenzuweisungen oder ACLs

Sie können die RBAC-Rollenzuweisung und POSIX ACLs für den Sicherheitsprinzipal ändern oder entfernen, der zum Erstellen der SAS verwendet wird. Wenn ein Client die SAS für den Zugriff auf eine Ressource verwendet, überprüft Azure Storage, ob der Sicherheitsprinzipal, dessen Anmeldeinformationen zum Sichern der SAS verwendet wurden, über die erforderlichen Berechtigungen für die Ressource verfügt.

Siehe auch