Erstellen einer Benutzerdelegierungs-SAS

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.

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:

• Mitwirkender
• Speicherkontomitwirkender
• mitwirkender Speicher-BLOB-Daten
• des Speicherblobdatenbesitzers
• Storage Blob Delegator-

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.

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:

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:

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.

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.

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:

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:

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.

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

• Stellvertretungszugriff mit einer freigegebenen Zugriffssignatur
• Erstellen eines SAS-
• Erstellen eines SAS-
• SAS-Fehlercodes