(0) exportieren Drucken
Alle erweitern

Authentifizierung für die Azure-Speicherdienste

Letzte Aktualisierung: Mai 2014

Jede für einen Speicherdienst ausgeführte Anforderung muss authentifiziert werden, es sei denn, die Anforderung wird für eine BLOB- oder Containerressource ausgeführt, die für den öffentlichen oder signierten Zugriff bereitgestellt wurde.

ImportantWichtig
Die Microsoft Azure-Speicherdienste unterstützen HTTP und HTTPS; die Verwendung von HTTPS wird jedoch dringend empfohlen.

Ab Version 2009-09-19 (für den BLOB-, Warteschlangen- und Tabellendienst) und Version 2014-02-14 (für den Dateidienst) unterstützen die BLOB-, Warteschlangen-, Tabellen- und Dateidienste die folgenden Schemas für die Authentifizierung mit SKA (Shared Key Authentication)-Schemas:

  • Gemeinsam verwendeter Schlüssel für BLOB-, Warteschlangen- und Dateidienste. Verwenden Sie das Authentifizierungsschema mit gemeinsam verwendetem Schlüssel, um Anforderungen für BLOB-, Warteschlangen- und Dateidienste auszuführen. Die Authentifizierung mit gemeinsam verwendetem Schlüssel in Version 2009-09-19 unterstützt eine erweiterte Signaturzeichenfolge für verbesserte Sicherheit. Um diese erweiterte Signatur zu authentifizieren, müssen Sie den Dienst aktualisieren.

  • Gemeinsam verwendeter Schlüssel für den Tabellendienst. Verwenden Sie das Shared Key-Authentifizierungsschema, um Anforderungen für den Tabellendienst mithilfe der REST-API auszuführen. Bei der Authentifizierung mit gemeinsam verwendetem Schlüssel für den Tabellendienst in Version 2009-09-19 wird dieselbe Signaturzeichenfolge wie in früheren Versionen des Tabellendiensts verwendet.

  • Shared Key Lite. Verwenden Sie das Shared Key Lite-Authentifizierungsschema, um Anforderungen für BLOB-, Warteschlangen-, Tabellen- und Dateidienste auszuführen.

    Bei Version 2009-09-19 der BLOB- und Warteschlangendienste unterstützt die Shared Key Lite-Authentifizierung eine Signaturzeichenfolge, die identisch mit den in früheren Versionen der BLOB- und Warteschlangendienste unterstützten Signaturzeichenfolgen für gemeinsam verwendete Schlüssel ist. Daher können Sie Shared Key Lite verwenden, um Anforderungen für die BLOB- und Warteschlangendienste auszuführen, ohne die Signaturzeichenfolge zu aktualisieren.

Eine authentifizierte Anforderung erfordert zwei Header: den Header Date oder x-ms-date und den Header Authorization. In den folgenden Abschnitten wird beschrieben, wie diese Header erstellt werden.

noteHinweis
Container oder BLOB-Ressourcen können öffentlich verfügbar gemacht werden, indem die Berechtigungen des Containers festgelegt werden. Weitere Informationen finden Sie unter Manage Access to Azure Storage Resources. Container, Blobs, Warteschlangen oder Tabellen können über eine SAS (Shared Access Signature) für den signierten Zugriff verfügbar gemacht werden. Eine SAS wird mithilfe eines anderen Mechanismus authentifiziert. Weitere Informationen finden Sie unter Delegieren des Zugriffs mit einer SAS (Shared Access Signature).

Alle authentifizierten Anforderungen müssen den UTC-Zeitstempel (Coordinated Universal Time, koordinierte Weltzeit) für die Anforderung enthalten. Sie können den Zeitstempel entweder im x-ms-date-Header oder im standardmäßigen Date-HTTP/HTTPS-Header angeben. Wenn für die Anforderung beide Header angegeben werden, wird der Wert von x-ms-date als Zeitpunkt der Erstellung der Anforderung verwendet.

Die Speicherdienste stellen sicher, dass eine Anforderung nicht älter als 15 Minuten ist, bis sie den Dienst erreicht. Dies bietet Schutz vor bestimmten Sicherheitsangriffen, einschließlich von Wiedergabenangriffen. Wenn diese Überprüfung fehlschlägt, gibt der Server den Antwortcode 403 (Verboten) zurück.

noteHinweis
Der x-ms-date-Header wird bereitgestellt, da einige HTTP-Clientbibliotheken und -Proxys den Date-Header automatisch festlegen. Somit hat der Entwickler nicht die Möglichkeit, dessen Wert zu lesen, um ihn in die authentifizierte Anforderung einzuschließen. Wenn Sie x-ms-date festlegen, erstellen Sie die Signatur mit einem leeren Wert für den Date-Header.

Eine authentifizierte Anforderung muss den Authorization-Header einschließen. Wenn der Header nicht enthalten ist, ist die Anforderung anonym und wird möglicherweise nur für einen BLOB-Container erfolgreich ausgeführt, der für den öffentlichen Zugriff gekennzeichnet ist, oder für Container, Blobs, Warteschlangen oder Tabellen, für die eine SAS für delegierten Zugriff bereitgestellt wurde.

Um eine Anforderung zu authentifizieren, müssen Sie die Anforderung mit dem Schlüssel für das Konto signieren, das die Anforderung ausführt, und diese Signatur als Teil der Anforderung übergeben.

Der Authorization-Header weist das folgende Format auf:

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

wobei SharedKey oder SharedKeyLite der Name des Autorisierungsschemas ist. AccountName ist der Name des Kontos, das die Ressource anfordert, und Signature ist ein hashbasierter Nachrichtenauthentifizierungscode (HMAC), der aus der Anforderung erstellt, mit dem SHA256-Algorithmus berechnet und anschließend mit der Base64-Codierung codiert wird.

noteHinweis
Es ist möglich, eine Ressource anzufordern, die sich unter einem anderen Konto befindet, sofern diese Ressource öffentlich zugänglich ist.

In den folgenden Abschnitten wird beschrieben, wie der Authorization-Header erstellt wird.

Die Erstellung der Signaturzeichenfolge hängt davon ab, welchen Dienst und welche Version Sie für die Authentifizierung und welches Authentifizierungsschema Sie verwenden. Beachten Sie beim Erstellen der Signaturzeichenfolge Folgendes:

  • Der VERB-Teil der Zeichenfolge ist das HTTP-Verb, z. B. GET oder PUT. Dieses muss in Großbuchstaben geschrieben werden.

  • Bei der Authentifizierung mit gemeinsam verwendetem Schlüssel für die BLOB-, Warteschlangen- und Dateidienste wird jeder in der Signaturzeichenfolge enthaltene Header möglicherweise nur einmal angezeigt. Wenn ein Header dupliziert wird, gibt der Dienst den Statuscode 400 (Ungültige Anforderung) zurück.

  • Die Werte aller HTTP-Standardheader müssen in der Zeichenfolge ohne die Headernamen in der Reihenfolge enthalten sein, die im Signaturformat aufgeführt wird. Diese Header sind möglicherweise leer, wenn sie nicht als Teil der Anforderung angegeben werden. In diesem Fall ist nur das Neue-Zeile-Zeichen erforderlich.

  • Wenn der x-ms-date-Header angegeben ist, können Sie den Date-Header ignorieren, unabhängig davon, ob dieser für die Anforderung angegeben ist, und einfach eine Leerzeile für den Date-Teil der Signaturzeichenfolge angeben. Folgen Sie in diesem Fall den Anweisungen im Abschnitt Erstellen der CanonicalizedHeaders-Zeichenfolge zum Hinzufügen des x-ms-date-Headers.

    Beachten Sie, dass es zulässig ist, sowohl x-ms-date als auch Date anzugeben. In diesem Fall verwendet der Dienst den Wert von x-ms-date.

  • Wenn der x-ms-date-Header nicht angegeben ist, geben Sie den Date-Header in der Signaturzeichenfolge ohne den Headernamen an.

  • Alle angezeigten Neue-Zeile-Zeichen (\n) sind innerhalb der Signaturzeichenfolge erforderlich.

  • Weitere Informationen zum Erstellen der CanonicalizedHeaders-Zeichenfolge und der CanonicalizedResource-Zeichenfolge, die Teil der Signaturzeichenfolge sind, finden Sie in den entsprechenden Abschnitten weiter unten in diesem Thema.

Um die Signaturzeichenfolge für den gemeinsam verwendeten Schlüssel einer Anforderung an den BLOB- oder Warteschlangendienst mit Version 2009-09-19 oder höher und an den Dateidienst mit Version 2014-02-14 oder höher zu codieren, verwenden Sie folgendes Format:

StringToSign = VERB + "\n" +
               Content-Encoding + "\n"
               Content-Language + "\n"
               Content-Length + "\n"
               Content-MD5 + "\n" +
               Content-Type + "\n" +
               Date + "\n" +
               If-Modified-Since + "\n"
               If-Match + "\n"
               If-None-Match + "\n"
               If-Unmodified-Since + "\n"
               Range + "\n"
               CanonicalizedHeaders + 
               CanonicalizedResource;

Im folgenden Beispiel wird eine Signaturzeichenfolge für einen Get Blob-Vorgang gezeigt. Beachten Sie, dass nur das Neue-Zeile-Zeichen angegeben wird, wenn kein Headerwert vorhanden ist.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n/myaccount/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

In der detaillierten Anzeige der einzelnen Zeilen wird jeder Teil derselben Zeichenfolge aufgeführt:


GET\n /*HTTP Verb*/
\n    /*Content-Encoding*/
\n    /*Content-Language*/
\n    /*Content-Length*/
\n    /*Content-MD5*/
\n    /*Content-Type*/
\n    /*Date*/
\n    /*If-Modified-Since */
\n    /*If-Match*/
\n    /*If-None-Match*/
\n    /*If-Unmodified-Since*/
\n    /*Range*/
x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n    /*CanonicalizedHeaders*/
/myaccount/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

Als Nächstes codieren Sie diese Zeichenfolge mit dem HMAC-SHA256-Algorithmus über der in UTF-8 codierten Signaturzeichenfolge, erstellen den Authorization-Header und fügen den Header der Anforderung hinzu. Im folgenden Beispiel wird der Authorization-Header für denselben Vorgang gezeigt:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Beachten Sie, dass Sie für die Verwendung der Authentifizierung mit gemeinsam verwendetem Schlüssel mit den Versionen 2009-09-19 der BLOB- und Warteschlangendienste den Code aktualisieren müssen, sodass die erweiterte Signaturzeichenfolge verwendet wird.

Wenn Sie es vorziehen, den Code mit möglichst wenigen Änderungen zu den Versionen 2009-09-19 der BLOB- und Warteschlangendienste zu migrieren, können Sie die vorhandenen Authorization-Header ändern, sodass Shared Key Lite anstelle von gemeinsam verwendeten Schlüsseln verwendet wird. Das für Shared Key Lite erforderliche Signaturformat ist mit dem identisch, das für gemeinsam verwendete Schlüssel in früheren Versionen als 2009-09-19 der BLOB- und Warteschlangendienste benötigt wird.

Sie müssen die Authentifizierung mit gemeinsam verwendetem Schlüssel verwenden, um eine für den Tabellendienst ausgeführte Anforderung zu authentifizieren, wenn der Dienst die REST-API für die Anforderung verwendet. Das Format der Signaturzeichenfolge für gemeinsam verwendete Schlüssel für den Tabellendienst ist für alle Versionen identisch.

Beachten Sie, dass sich die Signaturzeichenfolge für gemeinsam verwendete Schlüssel einer Anforderung für den Tabellendienst insofern geringfügig von der Signaturzeichenfolge einer Anforderung für die BLOB- oder Warteschlangendienste unterscheidet, als dass der CanonicalizedHeaders-Teil der Zeichenfolge nicht enthalten ist. Außerdem ist der Date-Header in diesem Fall niemals leer, auch dann nicht, wenn die Anforderung den x-ms-date-Header festlegt. Wenn die Anforderung x-ms-date festlegt, wird dieser Wert auch für den Wert des Date-Headers verwendet.

Um die Signaturzeichenfolge für eine mithilfe der REST-API ausgeführten Anforderung für den Tabellendienst zu codieren, verwenden Sie folgendes Format:

StringToSign = VERB + "\n" + 
               Content-MD5 + "\n" + 
               Content-Type + "\n" +
               Date + "\n" +
               CanonicalizedResource;

noteHinweis
Ab Version 2009-09-19 müssen alle REST-Aufrufe für den Tabellendienst den DataServiceVersion-Header und den MaxDataServiceVersion-Header enthalten. Weitere Informationen finden Sie unter Festlegen der Header für die OData-Datendienstversion.

Sie können die Shared Key Lite-Authentifizierung verwenden, um eine Anforderung zu authentifizieren, die an den BLOB- und Warteschlangendienst mit Version 2009-09-19 und an die Dateidienste mit Version 2014-02-14 gerichtet ist.

Die Signaturzeichenfolge für Shared Key Lite ist mit der Signaturzeichenfolge identisch, die für die Shared Key-Authentifizierung in früheren Versionen als 2009-09-19 der BLOB- und Warteschlangendienste benötigt wird. Wenn Sie daher den Code mit der geringsten Anzahl von Änderungen zu den 2009-09-19-Versionen der BLOB- und Warteschlangendienste migrieren möchten, können Sie den Code so ändern, dass Shared Key Lite verwendet wird, ohne die Signaturzeichenfolge selbst zu ändern. Beachten Sie, dass bei Verwendung von Shared Key Lite nicht die verbesserten Sicherheitsfunktionen verfügbar sind, die bei der Verwendung von gemeinsam verwendeten Schlüsseln mit der Version 2009-09-19 der API bereitgestellt werden.

Um die Signaturzeichenfolge für eine Anforderung für den BLOB- oder Warteschlangendienst zu codieren, verwenden Sie folgendes Format:

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +
               Date + "\n" +
               CanonicalizedHeaders + 
               CanonicalizedResource;

Im folgenden Beispiel wird eine Signaturzeichenfolge für einen Put Blob-Vorgang gezeigt. Beachten Sie, dass die Headerzeile Content-MD5 leer ist. Die in der Zeichenfolge gezeigten Header sind Name-Wert-Paare, die benutzerdefinierte Metadatenwerte für das neue BLOB angeben.

PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/testaccount1/mycontainer/hello.txt

Als Nächstes codieren Sie diese Zeichenfolge mit dem HMAC-SHA256-Algorithmus über der in UTF-8 codierten Signaturzeichenfolge, erstellen den Authorization-Header und fügen den Header der Anforderung hinzu. Im folgenden Beispiel wird der Authorization-Header für denselben Vorgang gezeigt:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Sie können die Shared Key Lite-Authentifizierung verwenden, um eine Anforderung zu authentifizieren, die für eine beliebige Version des Tabellendiensts ausgeführt wird.

Um die Signaturzeichenfolge für eine Anforderung für den Tabellendienst mit Shared Key Lite zu codieren, verwenden Sie folgendes Format:

StringToSign = Date + "\n" 
               CanonicalizedResource

Im folgenden Beispiel wird eine Signaturzeichenfolge für einen Create Table-Vorgang gezeigt.

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables

Als Nächstes codieren Sie diese Zeichenfolge mit dem HMAC-SHA256-Algorithmus, erstellen den Authorization-Header und fügen dann der Anforderung den Header hinzu. Im folgenden Beispiel wird der Authorization-Header für denselben Vorgang gezeigt:

Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=

Führen Sie zum Erstellen des CanonicalizedHeaders-Teils der Signaturzeichenfolge folgende Schritte aus:

  1. Rufen Sie alle Header der Ressource ab, die mit x-ms- beginnen, einschließlich des x-ms-date-Headers.

  2. Konvertieren Sie alle HTTP-Headernamen in Kleinbuchstaben.

  3. Sortieren Sie die Header lexikografisch und in aufsteigender Reihenfolge nach Headernamen. Beachten Sie, dass jeder Header möglicherweise nur einmal in der Zeichenfolge angezeigt wird.

  4. Erweitern Sie die Zeichenfolge, indem Sie nicht geschützte Leerräume durch ein einzelnes Leerzeichen ersetzen.

  5. Entfernen Sie alle Leerräume um den Doppelpunkt im Header.

  6. Fügen Sie schließlich jedem kanonisierten Header in der resultierenden Liste ein Neue-Zeile-Zeichen an. Erstellen Sie die CanonicalizedHeaders-Zeichenfolge, indem Sie alle Header in dieser Liste zu einer einzelnen Zeichenfolge verketten.

Der CanonicalizedResource-Teil der Signaturzeichenfolge stellt die Speicherdienstressource dar, die das Ziel der Anforderung ist. Jeder Teil der CanonicalizedResource-Zeichenfolge, der aus dem URI der Ressource abgeleitet wird, sollte identisch mit dem URI codiert werden.

Für die CanonicalizedResource-Zeichenfolge werden zwei Formate unterstützt:

  • Ein Format, das die Authentifizierung mit gemeinsam verwendetem Schlüssel für Version 2009-09-19 des BLOB- und Warteschlangendiensts und für Version 2014-02-14 des Dateidiensts unterstützt.

  • Ein Format, das gemeinsam verwendete Schlüssel und Shared Key Lite für alle Versionen des Tabellendiensts unterstützt sowie Shared Key Lite für die Version 2009-09-19 der BLOB- und Warteschlangendienste. Dieses Format ist mit dem in früheren Versionen der Speicherdienste verwendeten Format identisch.

Hilfe zum Erstellen des URI für die Ressource, auf die Sie zugreifen, finden Sie in einem der folgenden Themen:

noteHinweis
Wenn Sie eine Authentifizierung mit dem Speicheremulator durchführen, wird der Kontoname in der CanonicalizedResource-Zeichenfolge zweimal angezeigt. Dies ist ein erwartetes Verhalten. Wenn Sie eine Authentifizierung mit den Windows Azure-Speicherdiensten durchführen, wird der Kontoname in der CanonicalizedResource-Zeichenfolge nur einmal angezeigt.

2009-09-19-Format für gemeinsam verwendete Schlüssel

Dieses Format unterstützt die Authentifizierung mit gemeinsam verwendetem Schlüssel für Version 2009-09-19 des BLOB- und Warteschlangendiensts und für Version 2014-02-14 des Dateidiensts. Erstellen Sie die CanonicalizedResource-Zeichenfolge wie folgt in diesem Format:

  1. Beginnen Sie mit einer leeren Zeichenfolge (""), fügen Sie einen Schrägstrich (/) an, gefolgt vom Namen des Kontos, das die Ressource besitzt, auf die zugegriffen wird.

  2. Fügen Sie den codierten URI-Pfad der Ressource ohne Abfrageparameter an.

  3. Rufen Sie alle Abfrageparameter für den Ressourcen-URI ab, ggf. einschließlich des comp-Parameters.

  4. Konvertieren Sie alle Parameternamen in Kleinbuchstaben.

  5. Sortieren Sie die Abfrageparameter lexikografisch und in aufsteigender Reihenfolge nach Parameternamen.

  6. Führen Sie für die Namen und Werte der einzelnen Abfrageparameter eine URL-Decodierung durch.

  7. Fügen Sie der Zeichenfolge jeden Abfrageparameternamen und -wert im folgenden Format an, und vergewissern Sie sich, den Doppelpunkt (:) zwischen dem Namen und dem Wert einzuschließen:

    parameter-name:parameter-value

  8. Wenn ein Abfrageparameter mehr als einen Wert aufweist, sortieren Sie alle Werte lexikografisch, und schließen Sie sie dann in eine durch Trennzeichen getrennte Liste ein:

    parameter-name:parameter-value-1,parameter-value-2,parameter-value-n

  9. Fügen Sie nach jedem Name-Wert-Paar ein Neue-Zeile-Zeichen (\n) an.

Beachten Sie die folgenden Regeln zum Erstellen der kanonisierten Ressourcenzeichenfolge:

  • Verwenden Sie das Neue-Zeile-Zeichen (\n) nach Möglichkeit nicht in den Werten für Abfrageparameter. Wenn Sie es verwenden müssen, vergewissern Sie sich, dass es sich nicht auf das Format der kanonisierten Ressourcenzeichenfolge auswirkt.

  • Vermeiden Sie die Verwendung von Kommas in den Abfrageparameterwerten.

Im Folgenden finden Sie einige Beispiele, die den CanonicalizedResource-Teil der Signaturzeichenfolge zeigen, wie er über einen angegebenen Anforderungs-URI erstellt werden könnte:


Get Container Metadata
   GET http://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata 
CanonicalizedResource:
    /myaccount/mycontainer\ncomp:metadata\nrestype:container
List Blobs operation:
    GET http://myaccount.blob.core.windows.net/container?restype=container&comp=list&include=snapshots&include=metadata&include=uncommittedblobs
CanonicalizedResource:
    /myaccount/mycontainer\ncomp:list\ninclude:metadata,snapshots,uncommittedblobs\nrestype:container

2009-09-19-Format für Shared Key Lite und Tabellendienst

Dieses Format unterstützt Shared Key und Shared Key Lite für alle Versionen des Tabellendiensts sowie Shared Key Lite für die Version 2009-09-19 des BLOB- und Warteschlangendiensts sowie Version 2014-02-14 des Dateidiensts. Dieses Format ist mit dem in früheren Versionen der Speicherdienste verwendeten Format identisch. Erstellen Sie die CanonicalizedResource-Zeichenfolge wie folgt in diesem Format:

  1. Beginnen Sie mit einer leeren Zeichenfolge (""), fügen Sie einen Schrägstrich (/) an, gefolgt vom Namen des Kontos, das die Ressource besitzt, auf die zugegriffen wird.

  2. Fügen Sie den codierten URI-Pfad der Ressource an. Wenn der Anforderungs-URI eine Komponente der Ressource adressiert, fügen Sie die entsprechende Abfragezeichenfolge an. Die Abfragezeichenfolge sollte das Fragezeichen und den comp-Parameter enthalten (z. B. ?comp=metadata). Andere Parameter sollten nicht in der Abfragezeichenfolge enthalten sein.

Um die Signatur zu codieren, rufen Sie den HMAC-SHA256-Algorithmus für die in UTF-8 codierte Signaturzeichenfolge auf, und codieren Sie das Ergebnis als Base64. Verwenden Sie folgendes Format (als Pseudocode angezeigt):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))

Siehe auch

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur MSDN-Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die MSDN-Website verlassen.

Möchten Sie an der Umfrage teilnehmen?
Anzeigen:
© 2014 Microsoft