Erstellen einer Dienst-SAS

Eine Sas (Shared Access Signature) delegiert den Zugriff auf eine Ressource nur in einem der Speicherdienste: Azure Blob Storage, Azure Queue Storage, Azure Table Storage oder Azure Files. Der URI für eine SAS auf Dienstebene besteht aus dem URI an die Ressource, für die die SAS den Zugriff delegiert, gefolgt vom SAS-Token.

Das SAS-Token ist die Abfragezeichenfolge, die alle Informationen enthält, die zum Autorisieren einer Anforderung erforderlich sind. Das Token gibt die Ressource an, auf die ein Client zugreifen kann, die erteilten Berechtigungen und den Zeitraum, in dem die Signatur gültig ist.

Eine SAS kann auch die unterstützte IP-Adresse oder den Adressbereich angeben, aus dem Anforderungen stammen können, das unterstützte Protokoll, mit dem eine Anforderung gestellt werden kann, oder einen optionalen Zugriffsrichtlinienbezeichner, der der Anforderung zugeordnet ist.

Schließlich enthält jedes SAS-Token eine Signatur.

Autorisieren einer Dienst-SAS

Sie sichern eine Konto-SAS mithilfe eines Speicherkontoschlüssels. Wenn Sie eine Konto-SAS erstellen, muss Ihre Clientanwendung über den Kontoschlüssel verfügen.

Um Microsoft Entra Anmeldeinformationen zum Sichern einer SAS für einen Container oder Blob zu verwenden, erstellen Sie eine Benutzerdelegierungs-SAS.

Service SAS-Unterstützung für verzeichnisbezogenen Zugriff

Eine Dienst-SAS unterstützt den Verzeichnisbereich (sr=d), wenn die Autorisierungsversion (sv) 2020-02-10 oder höher ist und ein hierarchischer Namespace aktiviert ist. Die Semantik für den Verzeichnisbereich (sr=d) ähnelt denen für den 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.

Erstellen einer Dienst-SAS

Die folgende Abbildung stellt die Teile des Shared Access Signature-URI dar. Die erforderlichen Teile werden orange angezeigt. Die Felder, aus denen das SAS-Token besteht, werden in den folgenden Abschnitten beschrieben.

In den folgenden Abschnitten wird beschrieben, wie Sie die Parameter angeben, aus denen das Dienst-SAS-Token besteht.

Geben Sie das Feld an.signedVersion

Das signedVersion Feld (sv) enthält die Dienstversion der Shared Access Signature. Dieser Wert gibt die Version der Shared Key-Autorisierung an, die von dieser Shared Access Signature (im signature Feld) verwendet wird. Der Wert gibt auch die Dienstversion für Anforderungen an, die mit dieser Shared Access Signature gestellt werden.

Informationen dazu, welche Version verwendet wird, wenn Sie Anforderungen über eine Freigegebene Zugriffssignatur ausführen, finden Sie unter Versionsverwaltung für Azure Storage-Dienste.

Informationen dazu, wie sich dieser Parameter auf die Autorisierung von Anforderungen mit einer Shared Access Signature auswirkt, finden Sie unter Delegieren des Zugriffs mit einer Shared Access Signature.

Feldname	Query parameter (Abfrageparameter)	BESCHREIBUNG
signedVersion	sv	Erforderlich. Unterstützt in Version 2012-02-12 und höher. Die Speicherdienstversion, die zum Autorisieren und Behandeln von Anforderungen verwendet werden soll, die Sie mit dieser Freigegebenen Zugriffssignatur stellen. Weitere Informationen finden Sie unter Versionsverwaltung für Azure Storage-Dienste.

Ermitteln der Version einer LEGACY-SAS-Anforderung

In Legacyszenarien, in denen signedVersion nicht verwendet wird, wendet Blob Storage Regeln an, um die Version zu bestimmen. Weitere Informationen zu diesen Regeln finden Sie unter Versionsverwaltung für Azure Storage-Dienste.

Geben Sie die signierte Ressource an (nur Blob Storage)

Das feld required signedResource (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- oder Containerressource im SAS-Token verweisen.

Resource	Parameterwert	Unterstützte Versionen	BESCHREIBUNG
Blob	b	Alle	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 wird immer in einem Container geschachtelt.

Geben Sie die signierte Ressource an (Azure Files)

SAS wird für Azure Files Version 2015-02-21 und höher unterstützt.

Das signedResource-Feld gibt die Ressourcen an, auf die über die SAS zugegriffen werden kann. In der folgenden Tabelle wird beschrieben, wie Sie auf eine Datei- oder Freigaberessource im URI verweisen.

Feldname	Query parameter (Abfrageparameter)	BESCHREIBUNG
signedResource	sr	Erforderlich. Geben Sie an f , ob es sich bei der freigegebenen Ressource um eine Datei handelt. Dadurch wird Zugriff auf den Inhalt und die Metadaten der Datei gewährt. Geben Sie an s , ob es sich bei der freigegebenen Ressource um eine Freigabe handelt. Dadurch wird Zugriff auf den Inhalt und die Metadaten jeder Datei in der Freigabe sowie auf die Liste der Verzeichnisse und Dateien in der Freigabe gewährt.

Angeben von Abfrageparametern zum Überschreiben von Antwortheadern (nur Blob Storage und Azure Files)

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. Dieses Feature wird ab Version 2013-08-15 für Blob Storage und Version 2015-02-21 für Azure Files unterstützt. Shared Access Signaturen, die dieses Feature verwenden, müssen den Parameter enthalten, der sv auf 2013-08-15 oder höher für Blob Storage oder auf 2015-02-21 oder höher für Azure Files festgelegt ist.

Die Antwortheader und die entsprechenden Abfrageparameter sind in der folgenden Tabelle aufgeführt:

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 eine Shared Access Signature angeben, die mit Version 2013-08-15 oder höher erstellt wurde, wird der Content-Type Antwortheader auf binaryfestgelegt. Dieser Wert überschreibt den Headerwert, der Content-Type für das Blob für eine Anforderung gespeichert wird, die nur diese Shared Access Signature verwendet.

Wenn Sie eine Shared Access Signature erstellen, die Antwortheader als Abfrageparameter angibt, müssen Sie sie in die Zeichenfolge einfügen, die zum Erstellen der Signaturzeichenfolge verwendet wird. Weitere Informationen finden Sie im Abschnitt "Erstellen der Signaturzeichenfolge" weiter unten in diesem Artikel. Weitere Beispiele finden Sie unter Service SAS-Beispiele.

Angeben des Tabellennamens (nur Tabellenspeicher)

Im tableName-Feld wird der Name der freizugebenden Tabelle angegeben.

Feldname	Query parameter (Abfrageparameter)	BESCHREIBUNG
tableName	tn	Erforderlich. Der Name der freizugebenden Tabelle.

Angeben der Zugriffsrichtlinie

Der Teil der Zugriffsrichtlinie des URI gibt den Zeitraum an, in dem die Shared Access Signature gültig ist, und die Berechtigungen, die dem Benutzer gewährt werden sollen. Die Teile des URI, aus denen die Zugriffsrichtlinie besteht, werden in der folgenden Tabelle beschrieben:

Feldname	Query parameter (Abfrageparameter)	BESCHREIBUNG
signedStart	st	Optional. Der Zeitpunkt, zu dem die Shared Access Signature gültig wird, ausgedrückt in einem der akzeptierten ISO 8601 UTC-Formate. Wenn dieser Parameter ausgelassen wird, wird die aktuelle UTC-Zeit als Startzeit verwendet. In Versionen, die älter als 2012-02-12 sind, darf die Dauer zwischen signedStart und signedExpiry eine Stunde nur überschreiten, wenn eine Containerrichtlinie verwendet wird. Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Formatieren von Datums-/Uhrzeitwerten.
signedExpiry	se	Erforderlich. Der Zeitpunkt, zu dem die Shared Access Signature ungültig wird, ausgedrückt in einem der akzeptierten ISO 8601 UTC-Formate. Sie müssen dieses Feld weglassen, wenn es in einer zugeordneten gespeicherten Zugriffsrichtlinie angegeben wurde. Weitere Informationen zu akzeptierten UTC-Formaten finden Sie unter Formatieren von Datums-/Uhrzeitwerten.
signedPermissions 1	sp	Erforderlich. Die Berechtigungen, die der Shared Access Signature zugeordnet sind. Der Benutzer ist auf Vorgänge beschränkt, die durch die Berechtigungen zulässig sind. Sie müssen dieses Feld weglassen, wenn es in einer zugeordneten gespeicherten Zugriffsrichtlinie angegeben wurde.
startPk 2 startRk 2	spk srk	Nur Tabellenspeicher. Optional, startPk und startRk müssen jedoch zusammen verwendet werden. Die Mindestpartitions- und Zeilenschlüssel, auf die mit dieser Shared Access Signature zugegriffen werden kann. Schlüsselwerte verstehen sich als inklusive Werte. Wenn sie weggelassen werden, gibt es keine Untergrenze für die Tabellenentitäten, auf die zugegriffen werden kann.
endPk 2 endRk 2	epk erk	Nur Tabellenspeicher. Optional, endPk und endRk müssen jedoch zusammen verwendet werden. Die maximalen Partitions- und Zeilenschlüssel, auf die mit dieser Shared Access Signature zugegriffen werden kann. Schlüsselwerte verstehen sich als inklusive Werte. Wenn sie weggelassen werden, gibt es keine Obergrenze für die Tabellenentitäten, auf die zugegriffen werden kann.

¹ Das signedPermissions Feld ist für den URI erforderlich, es sei denn, es wird als Teil einer gespeicherten Zugriffsrichtlinie angegeben.
² Die startPkFelder , startRk, endPkund endRk können nur für Table Storage-Ressourcen angegeben werden.

Berechtigungen angeben

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

Sie können Berechtigungen kombinieren, 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, wdrl, wl, und rl. Beispiele für ungültige Einstellungen sind wr, dr, lrund dw. Sie können eine Berechtigungsbezeichnung nicht mehr als einmal angeben.

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

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

Verwenden Sie eine Konto-SAS, um eine SAS zu erstellen, die Zugriff auf diese Vorgänge gewährt. Weitere Informationen finden Sie unter Erstellen einer SAS für ein Konto.

Die Berechtigungen, die für jeden Ressourcentyp unterstützt werden, werden in den folgenden Abschnitten beschrieben.

Berechtigungen für ein Verzeichnis, einen Container oder ein Blob

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	Create oder schreiben Sie Inhalte, Eigenschaften, Metadaten oder Blockliste. 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.
Permanent delete	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.
Suchen	f	Container	12.12.2019 und höher	Suchen sie Blobs mit Indextags.
Move	m	Container Verzeichnis Blob	10.02.2020 und höher	Verschieben Sie ein Blob oder ein Verzeichnis und seinen 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 Klebbit 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. erlaubt dem Aufrufer nicht, benutzerdefinierte Metadaten zu 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 ein Verzeichnis oder Blob in einem Verzeichnis umbenannt oder gelöscht wird, 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 einer Unveränderlichkeitsrichtlinie	i	Container Blob	12.06.2020 und höher	Legen Sie die Unveränderlichkeitsrichtlinie oder den gesetzlichen Haltevorgang für ein Blob fest, oder löschen Sie sie.

Berechtigungen für eine Datei

Berechtigung	URI-Symbol	Zulässige Vorgänge
Lesen	r	Lesen Sie den Inhalt, die Eigenschaften und die Metadaten. Verwenden Sie die Datei als Quelle eines Kopiervorgangs.
Erstellen	c	Create eine neue Datei oder kopieren Sie eine Datei in eine neue Datei.
Schreiben	w	Create oder schreiben Sie Inhalte, Eigenschaften, Metadaten. Ändern Sie die Größe der Datei. Verwenden Sie die Datei als Ziel eines Kopiervorgangs.
Löschen	T	Löschen der Datei

Berechtigungen für eine Freigabe

Berechtigung	URI-Symbol	Zulässige Vorgänge
Lesen	r	Liest den Inhalt, die Eigenschaften oder Metadaten einer beliebigen Datei in der Freigabe. Verwenden Sie eine beliebige Datei in der Freigabe als Quelle eines Kopiervorgangs.
Erstellen	c	Create eine neue Datei in der Freigabe, oder kopieren Sie eine Datei in eine neue Datei in der Freigabe.
Schreiben	w	Erstellen oder schreiben Sie für jede Datei in der Freigabe Inhalte, Eigenschaften oder Metadaten. Ändern Sie die Größe der Datei. Verwenden Sie die Datei als Ziel eines Kopiervorgangs. Hinweis: Sie können keine Berechtigungen zum Lesen oder Schreiben von Freigabeeigenschaften oder Metadaten mithilfe einer Dienst-SAS erteilen. Verwenden Sie stattdessen eine Konto-SAS.
Löschen	T	Löschen Sie eine beliebige Datei in der Freigabe. Hinweis: Sie können keine Berechtigungen zum Löschen einer Freigabe mithilfe einer Dienst-SAS erteilen. Verwenden Sie stattdessen eine Konto-SAS.
List	l	Auflisten von Dateien und Verzeichnissen in der Freigabe.

Berechtigungen für eine Warteschlange

Berechtigung	URI-Symbol	Zulässige Vorgänge
Lesen	r	Lesen von Metadaten und Eigenschaften einschließlich der Nachrichtenanzahl. Überprüfung auf vorliegende Nachrichten.
Hinzufügen	a	Hinzufügen von Nachrichten zur Warteschlange
Aktualisieren	u	Aktualisieren von Nachrichten in der Warteschlange. Hinweis: Verwenden Sie die Berechtigung Verarbeiten mit Update, damit Sie zuerst die Meldung abrufen können, die Sie aktualisieren möchten.
Prozess	p	Abrufen und Löschen von Nachrichten aus der Warteschlange

Berechtigungen für eine Tabelle

Berechtigung	URI-Symbol	Zulässige Vorgänge
Abfrage	r	Abrufen und Abfragen von Entitäten
Hinzufügen	a	Hinzufügen von Entitäten Hinweis: Für Upsert-Vorgänge sind Die Berechtigungen "Hinzufügen" und "Aktualisieren" erforderlich.
Aktualisieren	u	Aktualisieren von Entitäten Hinweis: Für Upsert-Vorgänge sind Die Berechtigungen "Hinzufügen" und "Aktualisieren" erforderlich.
Löschen	T	Löschen von Entitäten

Angeben einer IP-Adresse oder eines IP-Adressbereichs

Ab Version 2015-04-05 gibt das optionale signedIp Feld (sip) 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 IP-Adressbereich angeben, beachten Sie, dass der Bereich inklusiv ist. 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 basierend auf der Clientumgebung und dem signedIp Speicherort des Speicherkontos beschrieben, ob das Feld in ein SAS-Token für ein angegebenes 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 aus derselben Region erfolgen, die 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 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. Eine mit der SAS durchgeführte Anforderung muss 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. Eine mit der SAS durchgeführte Anforderung muss 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

Ab Version 2015-04-05 gibt das optionale signedProtocol Feld (spr) das Protokoll an, das für eine Anforderung mit der SAS zulässig ist. Mögliche Werte sind HTTPS und HTTP (https,http) oder nur HTTPS (https). Standardwert: https,http. Beachten Sie, dass HTTP allein kein zulässiger Wert ist.

Angeben von Tabellenzugriffsbereichen

Die startPkFelder , startRk, endPkund endRk definieren einen Bereich von Tabellenentitäten, die einer Shared Access Signature zugeordnet sind. Tabellenabfragen geben nur Ergebnisse zurück, die innerhalb des Bereichs liegen, und Versuche, die Shared Access Signature zum Hinzufügen, Aktualisieren oder Löschen von Entitäten außerhalb dieses Bereichs zu verwenden, schlagen fehl.

Wenn startPk gleich endPkist, autorisiert die Shared Access Signature den Zugriff auf Entitäten in nur einer Partition in der Tabelle.

Wenn startPk gleich endPk und startRk gleich endRkist, kann die Shared Access Signature nur auf eine Entität in einer Partition zugreifen.

Informationen dazu, wie diese Felder den Zugriff auf Entitäten in einer Tabelle einschränken, finden Sie in der folgenden Tabelle:

Vorhandene Felder	Einschränkungsbereich
startPk	partitionKey >= startPk
endPk	partitionKey <= endPk
startPk, startRk	(partitionKey >startPk) || (partitionKey == startPk && rowKey >= startRk)
endPk, endRk	(partitionKey <endPk) || (partitionKey == endPk && rowKey <= endRk)

Angeben der Verzeichnistiefe

Wenn ein hierarchischer Namespace aktiviert ist und das signedResource Feld ein Verzeichnis angibt (sr=d), müssen Sie auch das signedDirectoryDepth Feld (sdd) angeben, um die Anzahl der Unterverzeichnisse unter dem 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 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 ab Version 2020-02-10 unterstützt.

Geben Sie den signierten Bezeichner an.

Wenn Sie das Feld für den signedIdentifier URI angeben, verknüpfen Sie die angegebene Shared Access Signature mit einer entsprechenden gespeicherten Zugriffsrichtlinie. Eine gespeicherte Zugriffsrichtlinie ist eine zusätzliche Kontrollmaßnahme für eine oder mehrere SAS. Sie bietet die Möglichkeit, die Signatur bei Bedarf zu widerrufen. Jeder Container, jede Warteschlange, Tabelle oder Freigabe kann über bis zu fünf gespeicherte Zugriffsrichtlinien verfügen.

In der folgenden Tabelle wird beschrieben, wie Sie auf einen signierten Bezeichner für den URI verweisen:

Feldname	Query parameter (Abfrageparameter)	BESCHREIBUNG
signedIdentifier	si	Optional. Ein eindeutiger Wert von bis zu 64 Zeichen, der mit einer Zugriffsrichtlinie korreliert, die für den Container, die Warteschlange oder die Tabelle angegeben ist.

Eine gespeicherte Zugriffsrichtlinie enthält einen signierten Bezeichner, einen Wert von bis zu 64 Zeichen, der innerhalb der Ressource eindeutig ist. Sie können den Wert dieses signierten Bezeichners für das signedidentifier Feld im URI für die Shared Access Signature angeben. Wenn Sie einen signierten Bezeichner für den URI angeben, ordnen Sie die Signatur der gespeicherten Zugriffsrichtlinie zu. Informationen zum Einrichten einer Zugriffsrichtlinie auf Containerebene mithilfe der REST-API finden Sie unter Delegieren des Zugriffs mit einer freigegebenen Zugriffssignatur.

Angeben des Verschlüsselungsbereichs

Mithilfe des signedEncryptionScope Felds für den URI können Sie den Verschlüsselungsbereich angeben, den die Clientanwendung verwenden kann. Es erzwingt die serverseitige Verschlüsselung mit dem angegebenen Verschlüsselungsbereich, wenn Sie Blobs (PUT) mit dem SAS-Token hochladen. Die GET- und HEAD werden nicht wie zuvor eingeschränkt und ausgeführt.

In der folgenden Tabelle wird beschrieben, wie Sie auf einen signierten Verschlüsselungsbereich für den URI verweisen:

Feldname	Query parameter (Abfrageparameter)	BESCHREIBUNG
signedEncryptionScope	ses	Optional. Gibt den Verschlüsselungsbereich an, der zum Verschlüsseln des Anforderungsinhalts verwendet werden soll.

Dieses Feld wird ab Version 2020-12-06 unterstützt. Wenn Sie die ses vor der unterstützten Version hinzufügen, gibt der Dienst den Fehlerantwortcode 403 (Verboten) zurück.

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

Wenn Sie den x-ms-encryption-scope Header und den Abfrageparameter in der ses PUT-Anforderung angeben, gibt der Dienst den Fehlerantwortcode 400 (Ungültige Anforderung) zurück, wenn ein Konflikt vorliegt.

Geben Sie die Signatur an

Sie verwenden den Signaturteil des URI, um die Anforderung zu autorisieren, die mit der Shared Access Signature gestellt wird. Azure Storage verwendet ein Autorisierungsschema für gemeinsam genutzte Schlüssel, um eine Dienst-SAS zu autorisieren.

In der folgenden Tabelle wird beschrieben, wie Die Signatur für den URI angegeben wird:

Feldname	Query parameter (Abfrageparameter)	BESCHREIBUNG
signature	sig	Das Zeichen von Zeichenfolge zu Vorzeichen ist eine eindeutige Zeichenfolge, die aus den Feldern erstellt wird und die überprüft werden muss, um die Anforderung zu autorisieren. Die Signatur ist ein hashbasierter Nachrichtenauthentifizierungscode (Hash-Based Message Authentication Code, HMAC), den Sie mithilfe des SHA256-Algorithmus über die Zeichenfolge und den Schlüssel berechnen und dann mithilfe der Base64-Codierung codieren.

Erstellen der Signaturzeichenfolge

Um die Signaturzeichenfolge einer Shared Access Signature zu erstellen, erstellen Sie zuerst die Zeichenfolge zu Sign aus den Feldern, aus denen die Anforderung besteht, und 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.

Version 2020-12-06 und höher

Version 2020-12-06 fügt Unterstützung für das Feld für den signierten Verschlüsselungsbereich hinzu. Verwenden Sie das folgende Format, um die Zeichenfolge für Blob Storage-Ressourcen zu erstellen:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion + "\n" +  
               signedResource + "\n" +
               signedSnapshotTime + "\n" +
               signedEncryptionScope + "\n" +
               rscc + "\n" +  
               rscd + "\n" +  
               rsce + "\n" +  
               rscl + "\n" +  

Version 2018-11-09 und höher

Version 2018-11-09 fügt Unterstützung für die signierte Ressource und das signierte Blob Momentaufnahme Zeitfeldern hinzu. Diese Felder müssen in der Zeichenfolge enthalten sein. Verwenden Sie das folgende Format, um die Zeichenfolge für Blob Storage-Ressourcen zu erstellen:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion + "\n" +  
               signedResource + "\n"
               signedSnapshotTime + "\n" +
               rscc + "\n" +  
               rscd + "\n" +  
               rsce + "\n" +  
               rscl + "\n" +  
               rsct  

Version 2015-04-05 und höher

Version 2015-04-05 fügt Unterstützung für die Felder mit signierter IP-Adresse und signiertem Protokoll hinzu. Diese Felder müssen in der Zeichenfolge enthalten sein. Verwenden Sie das folgende Format, um die Zeichenfolge für Blob Storage oder Azure Files Ressourcen zu erstellen:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion + "\n" +  
               rscc + "\n" +  
               rscd + "\n" +  
               rsce + "\n" +  
               rscl + "\n" +  
               rsct  

Verwenden Sie das folgende Format, um die Zeichenfolge für Tabellenspeicherressourcen zu erstellen:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion + "\n" +  
               startingPartitionKey + "\n"  
               startingRowKey + "\n"  
               endingPartitionKey + "\n"  
               endingRowKey  
  

Verwenden Sie das folgende Format, um die Zeichenfolge für Warteschlangenspeicherressourcen zu erstellen:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedIP + "\n" +  
               signedProtocol + "\n" +  
               signedVersion  
  

Version 2013-08-15 bis 2015-02-21

Verwenden Sie das folgende Format, um die Zeichenfolge für Blob Storage oder Azure Files Ressourcen mithilfe der Version 2013-08-15 bis 2015-02-21 zu erstellen. Für Azure Files wird SAS ab Version 2015-02-21 unterstützt.

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedVersion + "\n" +  
               rscc + "\n" +  
               rscd + "\n" +  
               rsce + "\n" +  
               rscl + "\n" +  
               rsct  

Um die StringToSign-Zeichenfolge für eine Tabelle zu erstellen, halten Sie folgende Formatvorgaben ein:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedVersion + "\n" +  
               startPk + "\n" +  
               startRk + "\n" +  
               endPk + "\n" +  
               endRk  
  

Verwenden Sie das folgende Format, um die Zeichenfolge für eine Warteschlange zu erstellen:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedVersion 

Version 2012-02-12

Verwenden Sie das folgende Format, um die Zeichenfolgen-zu-Sign für Blob Storage-Ressourcen für Version 2012-02-12 zu erstellen:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier + "\n" +  
               signedVersion  

Versionen vor 12.02.2012

Verwenden Sie das folgende Format, um die Zeichenfolgen-zu-Sign für Blob Storage-Ressourcen für Versionen zu erstellen, die älter als 2012-02-12 sind:

StringToSign = signedPermissions + "\n" +  
               signedStart + "\n" +  
               signedExpiry + "\n" +  
               canonicalizedResource + "\n" +  
               signedIdentifier  
  

Beachten Sie beim Erstellen der zu signierten Zeichenfolge Folgendes:

• Wenn ein Feld optional ist und nicht als Teil der Anforderung 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.

• Zeichenfolgen-zu-Vorzeichen für eine Tabelle müssen die zusätzlichen Parameter enthalten, auch wenn es sich um leere Zeichenfolgen handelt.

• Der signedpermission Teil der Zeichenfolge muss die Berechtigungsbezeichnungen in einer festen Reihenfolge enthalten, die für jeden Ressourcentyp spezifisch ist. Beliebige Kombinationen dieser Berechtigungen sind zulässig, aber die Reihenfolge der Buchstaben muss der Reihenfolge in der folgenden Tabelle entsprechen.

  Ressourcentyp	Reihenfolge der Berechtigungen
  Blob	racwd
  Container	racwdl
  Warteschlange	raup
  Datei	rcwd
  Teilen	rcwdl
  Tabelle	raud

  Beispiele für gültige Berechtigungseinstellungen für einen Container sind rwbeispielsweise , , rdrl, wdund wlrl. Beispiele für ungültige Einstellungen sind wr, dr, lrund dw. Das Angeben einer Berechtigungsbezeichnung mehr als einmal ist nicht zulässig.

• Geben Sie einen Wert für den signedIdentifier Teil der Zeichenfolge an, wenn Sie die Anforderung einer gespeicherten Zugriffsrichtlinie zuordnen.

• Eine Shared Access Signature, die eine Speicherdienstversion angibt, die älter als 2012-02-12 ist, kann nur ein Blob oder Container gemeinsam nutzen, und sie muss und das Zeilenumbruchzeichen davor weglassen signedVersion .

• Der canonicalizedResource-Teil der Zeichenfolge ist ein kanonischer Pfad zur signierten Ressource. Er muss den Dienstnamen (Blob Storage, Tabellenspeicher, Warteschlangenspeicher oder Azure Files) für Version 2015-02-21 oder höher, den Namen des Speicherkontos und den Ressourcennamen enthalten und muss URL-decodiert sein. Der BLOB-Container muss in den Namen der BLOBs enthalten sein. Tabellennamen müssen Kleinbuchstaben sein.

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

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

Container

Für Version 2015-02-21 und höher:

URL = https://myaccount.blob.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"  

Für Versionen vor 2015-02-21:

URL = https://myaccount.blob.core.windows.net/music
canonicalizedResource = "/myaccount/music"  

Blobs

Für Version 2015-02-21 und höher:

URL = https://myaccount.blob.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"  

Für Versionen vor 2015-02-21:

URL = https://myaccount.blob.core.windows.net/music/intro.mp3
canonicalizedResource = "/myaccount/music/intro.mp3"  

Dateifreigaben

URL = https://myaccount.file.core.windows.net/music
canonicalizedResource = "/file/myaccount/music"  

Dateien

URL = https://myaccount.file.core.windows.net/music/intro.mp3
canonicalizedResource = "/file/myaccount/music/intro.mp3"  

Warteschlangen

Für Version 2015-02-21 und höher:

URL = https://myaccount.queue.core.windows.net/thumbnails  
canonicalizedResource = "/queue/myaccount/thumbnails"  

Für Versionen vor 2015-02-21:

URL = https://myaccount.queue.core.windows.net/thumbnails  
canonicalizedResource = "/myaccount/thumbnails"  

Tabellen

Wenn es sich bei der signierten Ressource um eine Tabelle handelt, stellen Sie sicher, dass der Tabellenname im kanonisierten Format klein geschrieben ist.

Für Version 2015-02-21 und höher:

URL = https://myaccount.table.core.windows.net/Employees(PartitionKey='Jeff',RowKey='Price')  
canonicalizedResource = "/table/myaccount/employees"  

Für Versionen vor 2015-02-21:

URL = https://myaccount.table.core.windows.net/Employees(PartitionKey='Jeff',RowKey='Price')  
canonicalizedResource = "/myaccount/employees"  

Lebensdauer und Sperrung einer Shared Access Signature

Über eine SAS werden dem Benutzer Zugriffsberechtigungen für Speicherkontoressourcen gewährt. Wenn Sie planen, eine SAS zu verwenden, überlegen Sie sich die Lebensdauer der SAS und ob Ihre Anwendung unter bestimmten Umständen Zugriffsrechte widerrufen muss.

Ad-hoc-SAS im Vergleich zur gespeicherten Zugriffsrichtlinie

Eine Dienst-SAS kann eine von zwei Formen annehmen:

• Ad-hoc-SAS: Wenn Sie eine Ad-hoc-SAS erstellen, werden Startzeit, Ablaufzeit und Berechtigungen für die SAS alle im SAS-URI angegeben (oder impliziert, wenn die Startzeit ausgelassen wird). Jede Art von SAS kann eine Ad-hoc-SAS sein.

  Sie können die Lebensdauer einer Ad-hoc-SAS mithilfe des signedExpiry Felds verwalten. Wenn Sie einem Client nach der Ablaufzeit weiterhin Zugriff auf die Ressource gewähren möchten, müssen Sie eine neue Signatur ausstellen. Es wird empfohlen, die Lebensdauer einer Shared Access Signature kurz zu halten. Vor Version 2012-02-12 konnte eine Shared Access Signature, die keiner gespeicherten Zugriffsrichtlinie zugeordnet ist, keinen aktiven Zeitraum aufweisen, der eine Stunde überschreitet.

• SAS mit gespeicherter Zugriffsrichtlinie: Eine gespeicherte Zugriffsrichtlinie wird für einen Ressourcencontainer definiert, bei dem es sich um einen Blobcontainer, eine Tabelle, eine Warteschlange oder eine Dateifreigabe handelt. Sie können die gespeicherte Zugriffsrichtlinie verwenden, um Einschränkungen für eine oder mehrere Shared Access Signatures zu verwalten. Wenn Sie eine SAS einer gespeicherten Zugriffsrichtlinie zuordnen, erbt die SAS die Einschränkungen (d. h. Startzeit, Ablaufzeit und Berechtigungen), die für die gespeicherte Zugriffsrichtlinie definiert sind.

  Die gespeicherte Zugriffsrichtlinie wird durch das signedIdentifier-Feld des URIs dargestellt. Eine gespeicherte Zugriffsrichtlinie ist eine zusätzliche Kontrollmaßnahme für eine oder mehrere SAS. Sie bietet die Möglichkeit, die Signatur bei Bedarf zu widerrufen.

Widerrufen einer SAS

Da ein SAS-URI eine URL ist, kann jeder, der die SAS erhält, sie verwenden, unabhängig davon, wer sie ursprünglich erstellt hat. Wenn eine SAS veröffentlicht wird, kann diese von beliebiger Stelle weltweit verwendet werden. Eine SAS gewährt allen Personen, die über sie verfügen, Zugriff auf Ressourcen, bis eines von vier Dingen geschieht:

• Die für eine Ad-hoc-SAS angegebene Ablaufzeit wird erreicht.

• Die für die gespeicherte Zugriffsrichtlinie angegebene Ablaufzeit, auf die von der SAS verwiesen wird, wird erreicht, wenn auf eine gespeicherte Zugriffsrichtlinie verwiesen wird und die Zugriffsrichtlinie eine Ablaufzeit angibt.

  Die Ablaufzeit kann entweder erreicht werden, weil das Intervall verstrichen ist oder weil Sie die gespeicherte Zugriffsrichtlinie in der Vergangenheit so geändert haben, dass sie in der Vergangenheit eine Ablaufzeit hat. Dies ist eine Möglichkeit, die SAS zu widerrufen.

• Die gespeicherte Zugriffsrichtlinie, auf die von der SAS verwiesen wird, wird gelöscht, wodurch die SAS widerrufen wird. Wenn Azure Storage die gespeicherte Zugriffsrichtlinie, die in der Shared Access Signature angegeben ist, nicht finden kann, kann der Client nicht auf die ressource zugreifen, die durch den URI angegeben wird.

  Wenn Sie die gespeicherte Zugriffsrichtlinie mit genau dem gleichen Namen wie die gelöschte Richtlinie neu erstellen, sind alle vorhandenen SAS-Token gemäß den Berechtigungen, die dieser gespeicherten Zugriffsrichtlinie zugeordnet sind, erneut gültig. Dabei wird davon ausgegangen, dass die Ablaufzeit auf der SAS nicht abgelaufen ist. Wenn Sie beabsichtigen, die SAS zu widerrufen, achten Sie darauf, einen anderen Namen zu verwenden, wenn Sie die Zugriffsrichtlinie in Zukunft mit einer Ablaufzeit neu erstellen.

• Der Kontoschlüssel, mit dem die SAS erstellt wurde, wird erneut generiert. Das Erneute Generieren eines Kontoschlüssels führt dazu, dass alle Anwendungskomponenten, die diesen Schlüssel verwenden, nicht autorisiert werden, bis sie aktualisiert werden, um entweder den anderen gültigen Kontoschlüssel oder den neu generierten Kontoschlüssel zu verwenden. Das Erneute Generieren des Kontoschlüssels ist die einzige Möglichkeit, eine Ad-hoc-SAS sofort zu widerrufen.

Als bewährte Methode wird empfohlen, eine gespeicherte Zugriffsrichtlinie mit einer Dienst-SAS zu verwenden. Wenn Sie sich dafür entscheiden, keine gespeicherte Zugriffsrichtlinie zu verwenden, sollten Sie den Zeitraum, in dem die Ad-hoc-SAS gültig ist, kurz halten. Weitere Informationen zum Zuordnen einer Dienst-SAS zu einer gespeicherten Zugriffsrichtlinie finden Sie unter Definieren einer gespeicherten Zugriffsrichtlinie.

Beispiel für Dienst-SAS

Das folgende Beispiel zeigt einen Blob-URI, an den ein Dienst-SAS-Token angefügt ist. Das DIENST-SAS-Token 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&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.
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.
Azure Storage-Version	sv=2023-05-24	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.

Weitere Informationen

• Delegieren des Zugriffs mit einer Shared Access Signature
• Erstellen einer SAS für die Benutzerdelegierung
• Erstellen einer Konto-SAS
• SAS-Fehlercodes