Erstellen einer SAS für die Benutzerdelegierung

  • Artikel

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. Eine SAS, die mit Microsoft Entra Anmeldeinformationen gesichert ist, wird als Benutzerdelegierungs-SAS bezeichnet. Als bewährte Sicherheitsmethode wird empfohlen, nach Möglichkeit Microsoft Entra Anmeldeinformationen anstelle des Kontoschlüssels zu verwenden, der leichter kompromittiert werden kann. Wenn ihr Anwendungsentwurf Shared Access Signatures erfordert, verwenden Sie Microsoft Entra Anmeldeinformationen, um eine SAS für die Benutzerdelegierung zu erstellen, um eine bessere Sicherheit zu gewährleisten.

Jede SAS wird mit einem Schlüssel signiert. Um eine SAS für die Benutzerdelegierung zu erstellen, müssen Sie zuerst einen Benutzerdelegierungsschlüssel anfordern, den Sie dann zum Signieren der SAS verwenden. Der Benutzerdelegierungsschlüssel entspricht dem Kontoschlüssel, der zum Signieren einer Dienst-SAS oder einer Konto-SAS verwendet wird, mit der Ausnahme, dass er von Ihren Microsoft Entra Anmeldeinformationen abhängig ist. Um den Benutzerdelegierungsschlüssel anzufordern, rufen Sie den Vorgang Benutzerdelegierungsschlüssel abrufen 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 Gen2 unterstützt. Gespeicherte Zugriffsrichtlinien werden für eine Benutzerdelegierungs-SAS nicht unterstützt.

Achtung

Shared Access Signatures sind Schlüssel, die Speicherressourcen Berechtigungen erteilen, und Sie sollten sie genauso schützen wie einen Kontoschlüssel. Es ist wichtig, eine SAS vor böswilliger oder unbeabsichtigter Verwendung zu schützen. Verteilen Sie eine SAS mit Diskretion, und halten Sie einen Plan für den Widerruf einer kompromittierten SAS bereit. Vorgänge, die Shared Access Signatures verwenden, sollten nur über eine HTTPS-Verbindung ausgeführt werden, und freigegebene Zugriffssignatur-URIs sollten nur über eine sichere Verbindung wie HTTPS verteilt werden.

Informationen zur Verwendung Ihres Kontoschlüssels zum Sichern einer SAS finden Sie unter Erstellen einer Dienst-SAS und Erstellen einer Konto-SAS.

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 eine Benutzer-OID

Benutzerdelegierungs-SAS unterstützt einen optionalen Benutzerobjektbezeichner (User Object Identifier, OID), der saoid entweder im - oder suoid -Parameter übertragen wird, wenn die Autorisierungsversion (sv) 2020-02-10 oder höher ist. Dieser optionale Parameter bietet ein erweitertes Autorisierungsmodell für Clusterworkloads mit mehreren Benutzern wie Hadoop und Spark.

SAS-Token können auf einen bestimmten Dateisystemvorgang und einen bestimmten Benutzer beschränkt werden, was ein weniger anfälliges Zugriffstoken bietet, das sicherer über einen Cluster mit mehreren Benutzern verteilt werden kann. Ein Anwendungsfall für diese Features ist die Integration des Hadoop ABFS-Treibers in Apache Ranger.

Autorisieren einer Benutzerdelegierungs-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. Die Berechtigungen der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC), die für dieses Microsoft Entra-Konto gewährt werden, zusammen mit den Berechtigungen, die explizit für die SAS gewährt werden, bestimmen den Zugriff des Clients auf die Ressource. Dieser Ansatz bietet ein zusätzliches Maß an Sicherheit und hilft Ihnen, ihren Kontozugriffsschlüssel nicht mit Ihrem Anwendungscode speichern zu müssen. Aus diesen Gründen ist das Erstellen einer SAS mit Microsoft Entra Anmeldeinformationen eine bewährte Methode für die Sicherheit.

Die Berechtigungen, die einem Client gewährt werden, der die SAS besitzt, sind die Schnittmenge zwischen den Berechtigungen, die dem Sicherheitsprinzipal erteilt wurden, der den Benutzerdelegierungsschlüssel angefordert hat, und den Berechtigungen, die der Ressource für das SAS-Token mithilfe des signedPermissions Felds (sp) erteilt wurden. Wenn eine Berechtigung, die dem Sicherheitsprinzipal über RBAC gewährt wurde, nicht auch dem SAS-Token gewährt wird, wird diese Berechtigung dem Client, der versucht, die SAS für den Zugriff auf die Ressource zu verwenden, nicht gewährt. Stellen Sie beim Erstellen einer Benutzerdelegierungs-SAS sicher, dass die über RBAC gewährten Berechtigungen und die berechtigungen, die über das SAS-Token gewährt werden, auf die vom Client erforderliche Zugriffsebene ausgerichtet sind.

Gehen Sie wie folgt vor, um eine SAS für die Benutzerdelegierung zu erstellen:

  1. Verwenden Sie RBAC, um dem Sicherheitsprinzipal, der den Benutzerdelegierungsschlüssel anfordern wird, die gewünschten Berechtigungen zu erteilen.
  2. Rufen Sie ein OAuth 2.0-Token von Microsoft Entra ID ab.
  3. Verwenden Sie das Token, um den Benutzerdelegierungsschlüssel anzufordern, indem Sie den Vorgang Benutzerdelegierungsschlüssel abrufen 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 dazu ü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 Aktion Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey zuweisen. Die folgenden integrierten RBAC-Rollen umfassen die Aktion Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey , entweder explizit oder als Teil einer Feldhalterdefinition:

Da der Vorgang Benutzerdelegierungsschlüssel abrufen auf der Ebene des Speicherkontos erfolgt, muss die Aktion Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey auf der Ebene des Speicherkontos, der Ressourcengruppe oder des Abonnements festgelegt werden. Wenn dem Sicherheitsprinzipal eine der zuvor aufgeführten, integrierten Rollen oder eine benutzerdefinierte Rolle zugewiesen wird, die die Aktion Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey 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 zusätzlich die Rolle Speicherblobdelegator auf der Ebene des Speicherkontos, der Ressourcengruppe oder des Abonnements zuweisen. Die Rolle Speicherblobdelegator gewährt dem Sicherheitsprinzipal Berechtigungen zum Anfordern des Benutzerdelegierungsschlüssels.

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

Abrufen eines OAuth 2.0-Tokens

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

Anfordern des Benutzerdelegierungsschlüssels

Ein Aufruf des Vorgangs Benutzerdelegierungsschlüssel abrufen gibt den Schlüssel als Satz von Werten zurück, die als Parameter für das SAS-Token der Benutzerdelegierung verwendet werden. Diese Parameter werden in der Referenz Zum Abrufen des Benutzerdelegierungsschlüssels und im nächsten Abschnitt "Erstellen einer Benutzerdelegierungs-SAS" beschrieben.

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

Nachdem Sie über den Benutzerdelegierungsschlüssel verfügen, können Sie ihn verwenden, um eine beliebige Anzahl von freigegebenen Zugriffssignaturen für die Benutzerdelegierung über die 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. In den folgenden Abschnitten finden Sie weitere Details zum Angeben dieser Parameter.

SAS-Feldname SAS-Tokenparameter Erforderlich oder optional Versionsunterstützung BESCHREIBUNG
signedVersion sv Erforderlich 09.11.2018 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 dieser SAS gestellt werden.
signedResource sr Erforderlich All Gibt an, auf welche Blobressourcen über die Shared Access Signature zugegriffen werden kann.
signedStart st Optional Alle Optional. Der Zeitpunkt, zu dem die Shared Access Signature gültig wird, ausgedrückt in einem der akzeptierten ISO 8601 UTC-Formate. Wenn dieser Wert weggelassen wird, wird die aktuelle UTC-Zeit als Startzeit verwendet. Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Formatieren von DateTime-Werten.
signedExpiry se Erforderlich Alle Der Zeitpunkt, zu dem die Shared Access Signature ungültig wird, ausgedrückt in einem der akzeptierten ISO 8601 UTC-Formate. Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Formatieren von DateTime-Werten.
signedPermissions sp Erforderlich Alle Gibt an, welche Vorgänge ein Client, der über die SAS verfügt, für die Ressource ausführen kann. Berechtigungen können kombiniert werden.
signedIp sip Optional 2015-04-05 und höher Gibt eine IP-Adresse oder einen inklusiven IP-Adressbereich an, von dem Anforderungen akzeptiert werden sollen. Wenn Sie einen Bereich angeben, denken Sie daran, dass der Bereich inklusiv ist. Es werden nur IPv4-Adressen unterstützt.

Zum Beispiel: sip=168.1.5.65 oder sip=168.1.5.60-168.1.5.70.
signedProtocol spr Optional 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 ausgeführt werden, HTTPS verwenden.
signedObjectId skoid Erforderlich 09.11.2018 und höher Gibt einen Microsoft Entra Sicherheitsprinzipal an.
signedTenantId sktid Erforderlich 09.11.2018 und höher Gibt den Microsoft Entra Mandanten an, in dem ein Sicherheitsprinzipal definiert ist.
signedKeyStartTime skt Optional. 09.11.2018 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. Wenn der Wert ausgelassen wird, wird die aktuelle Uhrzeit angenommen. Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Formatieren von DateTime-Werten.
signedKeyExpiryTime ske Erforderlich 09.11.2018 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 Formatieren von DateTime-Werten.
signedKeyVersion skv Erforderlich 09.11.2018 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 09.11.2018 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 Optional 10.02.2020 und höher Gibt die Objekt-ID für einen Microsoft Entra Sicherheitsprinzipal an, der vom Besitzer des Benutzerdelegierungsschlüssels autorisiert wird, um die vom SAS-Token gewährte Aktion auszuführen. Es wird keine zusätzliche Berechtigungsprüfung für Zugriffssteuerungslisten (ACCESS Control Lists, ACLs) von PosIX (Portable Operating System Interface) durchgeführt.
signedUnauthorizedObjectId suoid Optional 10.02.2020 und höher Gibt die Objekt-ID für einen Microsoft Entra Sicherheitsprinzipal an, wenn ein hierarchischer Namespace aktiviert ist. Azure Storage führt eine POSIX-ACL-Überprüfung für die Objekt-ID durch, bevor der Vorgang autorisiert wird.
signedCorrelationId scid Optional 10.02.2020 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 10.02.2020 und höher Gibt die Anzahl der Verzeichnisse im Stammordner des Verzeichnisses an, das canonicalizedResource im Feld der Zeichenfolgen-zu-Sign angegeben ist.
signedEncryptionScope ses Optional 2020-12-06 und höher Gibt den Verschlüsselungsbereich an, der zum Verschlüsseln des Anforderungsinhalts verwendet werden soll.
signature sig Erforderlich All Die Signatur ist ein hashbasierter Nachrichtenauthentifizierungscode (Hash-Based Message Authentication Code, HMAC), der über die zu signierende Zeichenfolge und den Schlüssel mithilfe des SHA256-Algorithmus berechnet und dann mithilfe der Base64-Codierung codiert wird.
Cache-Control Antwortheader rscc Optional 15.08.2013 und höher Azure Storage legt den Cache-Control Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.
Content-Disposition Antwortheader rscd Optional 15.08.2013 und höher Azure Storage legt den Content-Disposition Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.
Content-Encoding Antwortheader rsce Optional 15.08.2013 und höher Azure Storage legt den Content-Encoding Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.
Content-Language Antwortheader rscl Optional 15.08.2013 und höher Azure Storage legt den Content-Language Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.
Content-Type Antwortheader rsct Optional 15.08.2013 und höher Azure Storage legt den Content-Type Antwortheader auf den Wert fest, der im SAS-Token angegeben ist.

Geben Sie das Feld "signierte Version" an.

Das feld required signedVersion (sv) gibt die Dienstversion für die Shared Access Signature an. Dieser Wert gibt die Version des Diensts an, der zum Erstellen des signature Felds verwendet wird, und gibt die Dienstversion an, die eine Mit dieser Shared Access Signature durchgeführte Anforderung verarbeitet. Der Wert des sv Felds muss Version 2018-11-09 oder höher sein.

Geben Sie das signierte Ressourcenfeld an.

Das erforderliche signedResource Feld (sr) gibt an, auf welche Ressourcen über die Shared Access Signature zugegriffen werden kann. In der folgenden Tabelle wird beschrieben, wie Sie auf eine Blob-, Container- oder Verzeichnisressource im SAS-Token verweisen:

Resource Parameterwert Unterstützte Versionen BESCHREIBUNG
Blob b All Gewährt Zugriff auf den Inhalt und die Metadaten des Blobs.
Blobversion Bv 09.11.2018 und höher Gewährt Zugriff auf den Inhalt und die Metadaten der Blobversion, aber nicht auf das Basisblob.
Momentaufnahme eines Blobs bs 09.11.2018 und höher Gewährt Zugriff auf den Inhalt und die Metadaten des Blob-Momentaufnahme, aber nicht auf das Basisblob.
Container c Alle Gewährt Zugriff auf den Inhalt und die Metadaten eines beliebigen Blobs im Container sowie auf die Liste der Blobs im Container.
Verzeichnis T 10.02.2020 und höher Gewährt Zugriff auf den Inhalt und die Metadaten eines beliebigen Blobs im Verzeichnis sowie auf die Liste der Blobs im Verzeichnis in einem Speicherkonto mit aktiviertem hierarchischen Namespace. Wenn für das signedResource Feld ein Verzeichnis angegeben wird, ist auch der signedDirectoryDepth Parameter (sdd) erforderlich. Ein Verzeichnis befindet sich immer in einem Container.

Angeben der Gültigkeitsdauer der Signatur

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

Bei einer Benutzerdelegierungs-SAS sollten die Start- und Ablaufzeiten für die SAS innerhalb des für den Benutzerdelegierungsschlüssel definierten Intervalls erfolgen. Wenn ein Client versucht, eine 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 Formatieren von DateTime-Werten.

Berechtigungen angeben

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

Berechtigungen können kombiniert werden, damit ein Client mehrere Vorgänge mit derselben SAS ausführen kann. 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, wdund wlrl. Beispiele für ungültige Einstellungen sind wr, dr, lrund dw. Das Angeben einer Berechtigungsbezeichnung mehr als einmal ist 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 eine SAS zu erstellen, die Zugriff auf diese Vorgänge gewährt, verwenden Sie eine Konto-SAS. Weitere Informationen finden Sie unter Erstellen einer SAS für ein Konto.

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

Berechtigung URI-Symbol Resource 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 für einen Kopiervorgang.
Hinzufügen a Container
Verzeichnis
Blob		 Alle Fügen Sie einem Anfügeblob einen Block hinzu.
Erstellen c Container
Verzeichnis
Blob		 Alle Schreiben Sie ein neues Blob, Momentaufnahme ein Blob, 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 Leasen des BLOBs. Ändern der BLOB-Größe (nur Seitenblob). Verwenden Sie das Blob als Ziel eines Kopiervorgangs.
Löschen T Container
Verzeichnis
Blob		 Alle Löschen eines Blobs Ab Version 2017-07-29 ermöglicht die Delete-Berechtigung auch das Unterbrechen einer Lease für ein Blob. Weitere Informationen finden Sie unter Lease Blob-Vorgang .
Version löschen x Container
Blob		 12.12.2019 und höher Löschen einer Blobversion.
Dauerhaftes Löschen j Blob 10.02.2020 und höher Löschen Sie ein Blob Momentaufnahme oder -Version endgültig.
List l Container
Verzeichnis		 Alle Listet Blobs nicht rekursiv auf.
Tags t Blob 12.12.2019 und höher Lesen oder Schreiben der Tags in einem Blob.
Move m Container
Verzeichnis
Blob		 10.02.2020 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 Blobs, Verzeichnisses oder übergeordneten Verzeichnisses beschränkt werden, wenn der saoid Parameter im SAS-Token enthalten ist und das sticky Bit im übergeordneten Verzeichnis festgelegt ist.
Execute e Container
Verzeichnis
Blob		 10.02.2020 und höher Rufen Sie die Systemeigenschaften ab, und rufen Sie die POSIX-ACL eines Blobs ab, wenn der hierarchische Namespace für das Speicherkonto aktiviert ist. Wenn der hierarchische Namespace aktiviert ist und der Aufrufer der Besitzer eines Blobs ist, gewährt diese Berechtigung die Möglichkeit, die besitzende Gruppe, POSIX-Berechtigungen und POSIX-ACL des Blobs festzulegen. Der Aufrufer kann keine benutzerdefinierten Metadaten lesen.
Besitz o Container
Verzeichnis
Blob		 10.02.2020 und höher Wenn der hierarchische Namespace aktiviert ist, ermöglicht diese Berechtigung dem Aufrufer, den Besitzer oder die besitzende Gruppe festzulegen oder als Besitzer zu fungieren, wenn der Aufrufer ein Verzeichnis oder Blob in einem Verzeichnis umbenennt oder löscht, in dem das sticky Bit festgelegt ist.
Berechtigungen p Container
Verzeichnis
Blob		 10.02.2020 und höher Wenn der hierarchische Namespace aktiviert ist, ermöglicht diese Berechtigung dem Aufrufer das Festlegen von Berechtigungen und POSIX-ACLs für Verzeichnisse und Blobs.
Festlegen der Unveränderlichkeitsrichtlinie i Container
Blob		 12.06.2020 und höher Festlegen oder Löschen der Unveränderlichkeitsrichtlinie oder des gesetzlichen Aufbewahrungsrechts für ein Blob.

Angeben einer IP-Adresse oder eines IP-Adressbereichs

Das optionale signedIp Feld (sip) gibt eine öffentliche IP-Adresse oder einen Bereich öffentlicher IP-Adressen an, von denen Anforderungen akzeptiert werden sollen. Wenn die IP-Adresse, von 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 beispielsweise oder sip=168.1.5.60-168.1.5.70 auf der SAS angebensip=168.1.5.65, wird die Anforderung auf diese IP-Adressen beschränkt.

In der folgenden Tabelle wird anhand der Clientumgebung und des signedIp Speicherorts des Speicherkontos beschrieben, ob das Feld in ein SAS-Token für ein bestimmtes Szenario eingeschlossen werden soll.

Clientumgebung Standort des Speicherkontos Empfehlung
Client, der in Azure ausgeführt wird In derselben Region wie der Client Eine SAS, die in diesem Szenario für den Client bereitgestellt wird, sollte keine ausgehende IP-Adresse für das signedIp Feld enthalten. Anforderungen, die Sie aus derselben Region mithilfe einer SAS mit einer angegebenen ausgehenden IP-Adresse senden, schlagen fehl.

Verwenden Sie stattdessen ein virtuelles Azure-Netzwerk, um Netzwerksicherheitseinschränkungen zu verwalten. Anforderungen an Azure Storage aus derselben Region erfolgen immer über eine private IP-Adresse. Weitere Informationen finden Sie unter Konfigurieren von Firewalls und virtuellen Netzwerken in Azure Storage.
Client, der in Azure ausgeführt wird In einer anderen Region als der Client Eine SAS, die in diesem Szenario für den Client bereitgestellt wird, kann eine öffentliche IP-Adresse oder einen Adressbereich für das signedIp Feld 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 jeder Azure-Region Eine SAS, die in diesem Szenario für den Client bereitgestellt wird, kann eine öffentliche IP-Adresse oder einen Adressbereich für das signedIp Feld 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, geben Sie die öffentliche ausgehende IP-Adresse dieses Proxys oder Gateways für das signedIp Feld an.

Angeben des HTTP-Protokolls

Das optionale signedProtocol Feld (spr) gibt das Protokoll an, das für Anforderungen zulässig ist, die mit der SAS durchgeführt werden. Mögliche Werte sind HTTPS und HTTP (https,http) oder nur HTTPS (https). Standardwert: https,http.

Hinweis

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

Geben Sie die signierte Objekt-ID an.

Das signedObjectId Feld (skoid) ist für eine SAS für die Benutzerdelegierung erforderlich. Der Vorgang Benutzerdelegierungsschlüssel abrufen gibt diesen Wert als Teil der Antwort zurück. Die signierte Objekt-ID ist ein GUID-Wert, der den unveränderlichen Bezeichner für einen Sicherheitsprinzipal im Microsoft Identity Platform.

Geben Sie die signierte Mandanten-ID an.

Das signedTenantId Feld (sktid) ist für eine SAS für die Benutzerdelegierung erforderlich. Der Vorgang Benutzerdelegierungsschlüssel abrufen 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.

Geben Sie die Startzeit des signierten Schlüssels an.

Das optionale signedKeyStartTime Feld (skt) gibt den Beginn der Lebensdauer des Benutzerdelegierungsschlüssels im ISO-Datumsformat an. Der Vorgang Benutzerdelegierungsschlüssel abrufen gibt diesen Wert als Teil der Antwort zurück. Wenn die Startzeit ausgelassen wird, wird davon ausgegangen, dass die Startzeit des signierten Schlüssels die aktuelle Uhrzeit ist.

Geben Sie die Ablaufzeit des signierten Schlüssels an.

Das signedKeyExpiryTime Feld (ske) ist für eine SAS für die Benutzerdelegierung im ISO-Datumsformat erforderlich. Der Vorgang Benutzerdelegierungsschlüssel abrufen 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 der SAS betragen.

Angeben des signierten Schlüsseldiensts

Das signedKeyService Feld (sks) ist für eine SAS für die Benutzerdelegierung erforderlich. Der Vorgang Benutzerdelegierungsschlüssel abrufen 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 Feld "Signierter Schlüsseldienst" für Blob Storage ist b.

Angeben der Signierten Schlüsselversion

Das signedkeyversion Feld (skv) ist für eine SAS für die Benutzerdelegierung erforderlich. Der Vorgang Benutzerdelegierungsschlüssel abrufen gibt diesen Wert als Teil der Antwort zurück. Das signedkeyversion Feld 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 Objekt-ID für einen Sicherheitsprinzipal

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

  • Das saoid Feld gibt die Objekt-ID für einen Microsoft Entra Sicherheitsprinzipal an, der vom Besitzer des Benutzerdelegierungsschlüssels autorisiert wird, 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 durchgeführt.
  • Das suoid Feld gibt die Objekt-ID für einen Microsoft Entra Sicherheitsprinzipal an, wenn ein hierarchischer Namespace für ein Speicherkonto aktiviert ist. Das suoid Feld ist nur für Konten gültig, die über einen hierarchischen Namespace verfügen. Wenn das suoid Feld im SAS-Token enthalten ist, führt Azure Storage eine POSIX-ACL-Überprüfung der Objekt-ID durch, bevor der Vorgang autorisiert wird. 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 suoid Feld 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 saoid Feld oder suoid anzugeben, muss dem im Feld identifizierten Sicherheitsprinzipal eine RBAC-Rolle zugewiesen werden, die Microsoft.Storage/storageAccounts/blobServices/containers/blobs/blobs/runAsSuperUser/action oder Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action enthält.skoid Weitere Informationen zu diesen Aktionen finden Sie unter Vorgänge des Azure-Ressourcenanbieters.

Indem Sie die Objekt-ID im saoid Feld oder suoid angeben, schränken Sie auch Vorgänge im Zusammenhang mit dem Verzeichnis- oder Blobbesitz auf folgende Weise ein:

  • Wenn durch einen Vorgang ein Verzeichnis oder blob erstellt wird, legt Azure Storage den Besitzer des Verzeichnisses oder Blobs auf den Wert fest, der von der Objekt-ID angegeben wird. Wenn die Objekt-ID nicht angegeben wird, legt Azure Storage den Besitzer des Verzeichnisses oder Blobs auf den Wert fest, der durch den skoid Parameter angegeben wird.
  • Wenn das persistente Bit für das übergeordnete Verzeichnis festgelegt ist und der Vorgang ein Verzeichnis oder Blob löscht oder umbenannt, muss die Objekt-ID des Besitzers des übergeordneten Verzeichnisses oder des Besitzers der Ressource mit dem Wert übereinstimmen, der von der Objekt-ID angegeben wird.
  • 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 x-ms-owner vom 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 x-ms-group vom Header angegeben wird.
  • Wenn ein Vorgang die Berechtigungen oder die 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 signedPermissions Felds (sp) muss zusätzlich Ownership zur Berechtigung () die Permissions Berechtigung (op) enthalten.

Die objekt-ID, die saoid im Feld oder suoid angegeben ist, wird in Diagnoseprotokollen eingeschlossen, wenn Sie Anforderungen mithilfe des SAS-Tokens stellen.

Das saoid Feld oder suoid wird nur unterstützt, wenn das signedVersion Feld (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 signedCorrelationId Feld (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 in der Regel über eine verwaltete Identität, die Benutzer authentifiziert und autorisiert, eine SAS generiert, dem lokalen Überwachungsprotokoll einen Eintrag hinzufügt und die SAS an einen Benutzer zurückgibt, der die SAS dann für den Zugriff auf Azure Storage-Ressourcen verwenden kann. Indem Sie eine Korrelations-ID sowohl in das lokale Überwachungsprotokoll als auch in das Speicherüberwachungsprotokoll einschließen, lassen Sie zu, dass diese Ereignisse später korreliert werden. Der Wert ist eine GUID ohne geschweifte Klammern und mit Kleinbuchstaben.

Dieses Feld wird ab Version 2020-02-10 unterstützt.

Angeben der Verzeichnistiefe

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

Das Stammverzeichnis https://{account}.blob.core.windows.net/{container}/ hat beispielsweise eine Tiefe von 0. Jedes Unterverzeichnis innerhalb des Stammverzeichnisses wird der Tiefe um 1 hinzugefügt. Das Verzeichnis https://{account}.blob.core.windows.net/{container}/d1/d2 hat eine Tiefe von 2.

Dieses Feld wird ab Version 2020-02-10 unterstützt.

Angeben von Abfrageparametern zum Überschreiben von Antwortheadern

Um Werte für bestimmte Antwortheader zu definieren, die zurückgegeben werden sollen, wenn die SAS in einer Anforderung verwendet wird, können Sie Antwortheader in Abfrageparametern angeben. Die Antwortheader und die entsprechenden Abfrageparameter lauten 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. Durch diesen Wert wird der für das BLOB gespeicherte Content-Type-Headerwert für eine Anforderung überschrieben, indem nur diese SAS verwendet wird.

Wenn Sie eine Shared Access Signature erstellen, die Antwortheader als Abfrageparameter angibt, müssen Sie diese Antwortheader in die Zeichenfolge einschließen, die zum Erstellen der Signaturzeichenfolge verwendet wird. Weitere Informationen finden Sie im Abschnitt "Signatur angeben".

Angeben des Verschlüsselungsbereichs

Das signed encryption scope Feld (ses) gibt einen Verschlüsselungsbereich an, den die Clientanwendung verwendet, wenn Sie Blobs mithilfe des SAS-Tokens über den Vorgang Blob put hochladen. Das signed encryption scope Feld wird unterstützt, wenn das Feld mit der signierten Version (sv) im SAS-Token Version 2020-12-06 oder höher ist. Wenn das Feld mit der signierten Version eine Version angibt, die vor der unterstützten Version liegt, gibt der Dienst den Fehlerantwortcode 403 (Unzulässig) zurück.

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

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

Angeben der Signatur

Das signature Feld (sig) wird verwendet, um eine Anforderung eines Clients mit der Shared Access Signature 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 zu signierende Zeichenfolge und den Schlüssel berechnet und dann mithilfe der Base64-Codierung codiert wird.

Um die Signaturzeichenfolge einer SAS für die Benutzerdelegierung zu erstellen, erstellen Sie die Zeichenfolge zu 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 in der Zeichenfolge enthalten sind, müssen URL-decodiert sein.

Die felder, die im Zeichenfolgen-to-Sign 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 für die Benutzerdelegierung unterstützen.

Version 2020-12-06 und höher

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

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

Die Zeichenfolge für die Autorisierungsversion 2020-02-10 hat das folgende Format:

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

Frühere Versionen als 10.02.2020

Die Zeichenfolge für Autorisierungsversionen vor 2020-02-10 hat das folgende Format:

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

Vereinheitlichte Ressource

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

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

Die folgenden Beispiele zeigen, wie der canonicalizedResource Teil der Zeichenfolge je nach Ressourcentyp erstellt wird.

Containerbeispiel (Azure Blob Storage)
URL = https://myaccount.blob.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Blobbeispiel (Azure Blob Storage)
URL = https://myaccount.blob.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"
Containerbeispiel (Azure Data Lake Storage Gen2)
URL = https://myaccount.dfs.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Verzeichnisbeispiel (Azure Data Lake Storage Gen2)
URL = https://myaccount.dfs.core.windows.net/music/instruments/guitar/  
canonicalizedResource = "/blob/myaccount/music/instruments/guitar/"
Blobbeispiel (Azure Data Lake Storage Gen2)
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, nach der leeren Zeichenfolge das Neue-Zeile-Zeichen (\n) einzufügen.

Beispiel für eine SAS für die Benutzerdelegierung

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

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=168.1.5.60-168.1.5.70&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 Blob-Adresse. Es wird dringend empfohlen, HTTPS zu verwenden.
Trennzeichen ? Das Trennzeichen, das der Abfragezeichenfolge vorangestellt ist. Das Trennzeichen ist nicht Teil des SAS-Tokens.
Berechtigungen sp=rw Die SAS verleiht die Berechtigungen zum Lesen (r) und Schreiben (w).
Startzeit st=2023-05-24T01:13:55Z Angegeben im UTC-Zeitformat. Lassen Sie diesen Parameter aus, wenn die SAS sofort gültig sein soll.
Ablaufzeit se=2023-05-24T09:13:55Z Angegeben im UTC-Zeitformat.
ObjectID skoid=<object-id> Ein Microsoft Entra Sicherheitsprinzipal.
Mandanten-ID sktid=<tenant-id> Der Microsoft Entra Mandant, in dem der Sicherheitsprinzipal registriert ist.
Startzeit des Schlüssels skt=2023-05-24T01:13:55Z Der Beginn 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 Blobdienst 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=168.1.5.60-168.1.5.70 Der Bereich der IP-Adressen, von denen eine Anforderung akzeptiert wird.
Protocol spr=https Nur Anforderungen, die HTTPS verwenden, sind zulässig.
Blobdienstversion sv=2022-11-02 Für Azure Storage ab Version 2012-02-12 gibt dieser Parameter die zu verwendende Version an.
Resource sr=b Die Ressource ist ein Blob.
Signatur sig=<signature> Wird verwendet, um den Zugriff auf das Blob zu autorisieren. Die Signatur ist ein HMAC, der mithilfe des SHA256-Algorithmus über eine zu signierende Zeichenfolge und einen Schlüssel berechnet und dann mithilfe der Base64-Codierung codiert wird.

Widerrufen einer SAS für die Benutzerdelegierung

Wenn Sie der Meinung sind, dass eine SAS kompromittiert wurde, sollten Sie sie widerrufen. Sie können eine SAS für die Benutzerdelegierung widerrufen, indem Sie entweder den Benutzerdelegierungsschlüssel widerrufen oder RBAC-Rollenzuweisungen 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 der Initiierung des Sperrprozesses und dem Zeitpunkt kommen, zu dem eine SAS für die Benutzerdelegierung ungültig wird.

Widerrufen des Benutzerdelegierungsschlüssels

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

Ändern oder Entfernen von Rollenzuweisungen

Sie können die RBAC-Rollenzuweisung 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.

Weitere Informationen