Autorizace s využitím sdíleného klíče
Každý požadavek provedený vůči službě úložiště musí být autorizovaný, pokud se nejedná o prostředek objektu blob nebo kontejneru, který byl zpřístupněn pro veřejný nebo podepsaný přístup. Jednou z možností autorizace požadavku je použití sdíleného klíče popsaného v tomto článku.
Tip
Azure Storage poskytuje integraci s Microsoft Entra ID pro autorizaci požadavků na služby Blob, File, Queue a Table na základě identit. S Microsoft Entra ID můžete pomocí řízení přístupu na základě role (RBAC) udělit uživatelům, skupinám nebo aplikacím přístup k prostředkům objektů blob, souborů, front a tabulek. Microsoft Entra ID můžete použít k autorizaci přístupu k prostředkům úložiště bez ukládání přístupových klíčů účtu do aplikací, jako je tomu u sdíleného klíče. Další informace najdete v tématu Autorizace pomocí Microsoft Entra ID.
Služby Blob, Queue, Table a File podporují následující schémata autorizace sdíleného klíče pro verzi 2009-09-19 a novější (pro službu Blob, Queue a Table Service) a verzi 2014-02-14 a novější (pro službu File):
Sdílený klíč pro objekty blob, fronty a souborové služby. Pomocí schématu autorizace sdíleného klíče můžete vytvářet požadavky na služby Blob, Queue a File. Autorizace sdíleného klíče ve verzi 2009-09-19 a novějších podporuje řetězec rozšířeného podpisu kvůli rozšířenému zabezpečení a vyžaduje, abyste aktualizovali službu tak, aby autorizaci používala tento rozšířený podpis.
Sdílený klíč pro službu Table Service. Pomocí schématu autorizace sdíleného klíče můžete vytvářet požadavky na službu Table pomocí rozhraní REST API. Autorizace sdíleného klíče pro službu Table ve verzi 2009-09-19 a novější používá stejný řetězec podpisu jako v předchozích verzích služby Table Service.
Sdílený klíč Lite. Pomocí autorizačního schématu Sdílený klíč Lite můžete vytvářet požadavky na služby Blob, Queue, Table a File.
Pro verzi 2009-09-19 a novější služby Blob a Queue podporuje autorizace sdíleného klíče Lite použití řetězce podpisu, který byl stejný jako u sdíleného klíče v předchozích verzích služby Blob a Queue. Proto můžete použít sdílený klíč Lite k vytváření požadavků na služby Blob a Queue bez aktualizace řetězce podpisu.
Autorizovaný požadavek vyžaduje dvě hlavičky: hlavičku Date nebo x-ms-date a hlavičku Authorization . Následující části popisují, jak tyto hlavičky vytvořit.
Důležité
Azure Storage podporuje protokoly HTTP i HTTPS, ale důrazně doporučujeme používat protokol HTTPS.
Poznámka
Kontejner nebo objekt blob je možné zpřístupnit pro veřejný přístup nastavením oprávnění kontejneru. Další informace najdete v tématu Správa přístupu k prostředkům služby Azure Storage. Kontejner, objekt blob, fronta nebo tabulka lze zpřístupnit pro podepsaný přístup prostřednictvím sdíleného přístupového podpisu. sdílený přístupový podpis je autorizován jiným mechanismem. Další podrobnosti najdete v tématu Delegování přístupu pomocí sdíleného přístupového podpisu .
Určení záhlaví Date
Všechny oprávněné žádosti musí obsahovat časové razítko koordinovaného univerzálního času (UTC). Časové razítko můžete zadat buď v x-ms-date hlavičce, nebo ve standardní hlavičce HTTP/HTTPS Date . Pokud jsou v požadavku zadány obě hlavičky, hodnota se x-ms-date použije jako čas vytvoření požadavku.
Služby úložiště zajišťují, aby požadavek nebyl starší než 15 minut v okamžiku, kdy dorazí ke službě. To chrání před určitými útoky na zabezpečení, včetně útoků přehrání. Pokud tato kontrola selže, server vrátí kód odpovědi 403 (Zakázáno).
Poznámka
Hlavička x-ms-date je k dispozici, protože některé klientské knihovny a proxy servery HTTP automaticky nastaví hlavičku Date a nedávají vývojáři příležitost přečíst její hodnotu, aby ji mohl zahrnout do autorizovaného požadavku. Pokud nastavíte x-ms-date, sestavte podpis s prázdnou hodnotou pro hlavičku Date .
Zadání hlavičky autorizace
Autorizovaná žádost musí obsahovat hlavičku Authorization . Pokud tato hlavička není zahrnutá, požadavek je anonymní a bude úspěšný pouze u kontejneru nebo objektu blob, který je označen pro veřejný přístup, nebo pro kontejner, objekt blob, frontu nebo tabulku, pro které byl pro delegovaný přístup poskytnut sdílený přístupový podpis.
Pokud chcete žádost autorizovat, musíte žádost podepsat klíčem pro účet, který žádost vytváří, a předat tento podpis jako součást žádosti.
Authorization Formát záhlaví je následující:
Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
kde SharedKey nebo SharedKeyLite je název autorizačního schématu, AccountName je název účtu žádajícího o prostředek a Signature jedná se o kód HMAC (Hash-based Message Authentication Code) vytvořený z požadavku a vypočítaný pomocí algoritmu SHA256 a následně kódovaný pomocí kódování Base64.
Poznámka
Pokud je tento prostředek veřejně přístupný, je možné požádat o prostředek, který se nachází pod jiným účtem.
Následující části popisují, jak vytvořit hlavičku Authorization .
Vytvoření řetězce podpisu
Způsob vytvoření řetězce podpisu závisí na tom, pro kterou službu a verzi autorizujete a jaké schéma autorizace používáte. Při vytváření řetězce podpisu mějte na paměti následující:
Část řetězce VERB je příkaz HTTP, například GET nebo PUT, a musí být velká písmena.
V případě autorizace sdíleného klíče pro služby Blob, Queue a File se každá hlavička zahrnutá v řetězci podpisu může zobrazit jenom jednou. Pokud je nějaká hlavička duplikovaná, služba vrátí stavový kód 400 (Chybný požadavek).
Hodnoty všech standardních hlaviček HTTP musí být zahrnuty v řetězci v pořadí uvedeném ve formátu podpisu bez názvů hlaviček. Tyto hlavičky mohou být prázdné, pokud nejsou zadány jako součást požadavku; v takovém případě se vyžaduje pouze znak nového řádku.
Pokud je hlavička
x-ms-datezadaná, můžete ji ignorovatDatebez ohledu na to, jestli je zadána v požadavku, a jednoduše zadat prázdný řádek proDatečást řetězce podpisu. V tomto případě postupujte podle pokynů v části Vytvoření řetězce kanonalizovaných hlaviček pro přidáníx-ms-datehlavičky.Je přijatelné zadat i
x-ms-date.DateV tomto případě služba používá hodnotux-ms-date.Pokud hlavička
x-ms-datenení zadána, zadejteDatezáhlaví v řetězci podpisu bez zahrnutí názvu záhlaví.Všechny zobrazené znaky nového řádku (\n) jsou v řetězci podpisu povinné.
Řetězec podpisu obsahuje kanonické hlavičky a kanonické řetězce prostředků. Kanonizací těchto řetězců se přemísťují do standardního formátu, který služba Azure Storage rozpozná. Podrobné informace o vytváření
CanonicalizedHeadersřetězců aCanonicalizedResource, které tvoří část řetězce podpisu, najdete v příslušných částech dále v tomto tématu.
Objekty blob, fronty a souborové služby (autorizace sdíleného klíče)
Pokud chcete kódovat řetězec podpisu sdíleného klíče pro požadavek pro verzi 2009-09-19 a novější služby Blob nebo Queue a verzi 2014-02-14 a novější služby File, použijte následující formát:
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;
Důležité
V aktuální verzi musí být pole Content-Length prázdný řetězec, pokud je délka obsahu požadavku nulová. Ve verzi 2014-02-14 a starších verzích byla délka obsahu zahrnuta i v případě nuly. Další informace o starém chování najdete níže.
Následující příklad ukazuje řetězec podpisu pro operaci Get Blob . Tam, kde není žádná hodnota záhlaví, je zadán pouze znak nového řádku.
GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20
Když rozdělíte tento řádek po řádku, zobrazí se každá část stejného řetězce:
GET\n /*HTTP Verb*/
\n /*Content-Encoding*/
\n /*Content-Language*/
\n /*Content-Length (empty string when zero)*/
\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:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n /*CanonicalizedHeaders*/
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20 /*CanonicalizedResource*/
Dále tento řetězec zakódujte pomocí algoritmu HMAC-SHA256 přes řetězec podpisu s kódováním UTF-8, sestavte hlavičku Authorization a přidejte ji do požadavku. Následující příklad ukazuje hlavičku Authorization stejné operace:
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
Pokud chcete používat autorizaci sdíleného klíče ve službě Blob a Queue verze 2009-09-19 a novější, musíte aktualizovat kód tak, aby používal tento řetězec rozšířeného podpisu.
Pokud dáváte přednost migraci kódu na verzi 2009-09-19 nebo novější služby Blob a Queue s co nejmenším možnými změnami, můžete upravit stávající Authorization hlavičky tak, aby místo sdíleného klíče používaly sdílený klíč Lite. Formát podpisu vyžadovaný sdíleným klíčem Lite je shodný s formátem vyžadovaným pro sdílený klíč verzemi služeb Blob a Queue před 19. 9. 2009.
Důležité
Pokud přistupujete k sekundárnímu umístění v účtu úložiště, pro který je povolená geografická replikace s přístupem pro čtení (RA-GRS), nezahrnujte -secondary toto označení do hlavičky autorizace. Pro účely autorizace je název účtu vždy název primárního umístění, a to i pro sekundární přístup.
Hlavička Content-Length ve verzi 2014-02-14 a starší
Pokud používáte verzi 2014-02-14 nebo starší, pokud Content-Length je nula, nastavte Content-Length část na StringToSign0hodnotu . Za normálních okolností by to byl prázdný řetězec.
Například pro následující požadavek je hodnota hlavičky Content-Length zahrnuta v hodnotě i v případě StringToSign , že je nulová.
PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1
x-ms-version: 2014-02-14
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
Content-Length: 0
Objekt StringToSign je vytvořen takto:
Version 2014-02-14 and earlier:
PUT\n\n\n\n0\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2014-02-14\n/myaccount/mycontainer\nrestype:container\ntimeout:30
Vzhledem k tomu, StringToSign že ve verzích po 2014-02-2014 musí obsahovat prázdný řetězec pro Content-Length:
Version 2015-02-21 and later:
PUT\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30
Table Service (autorizace sdíleného klíče)
Pokud vaše služba k vytvoření požadavku používá rozhraní REST API, musíte použít autorizaci sdíleného klíče k autorizaci požadavku vytvořeného vůči službě Table. Formát řetězce podpisu pro sdílený klíč pro službu Table service je stejný pro všechny verze.
Řetězec podpisu sdíleného klíče pro požadavek na službu Table service se mírně liší od řetězce pro požadavek na službu Blob nebo Queue v tom, že nezahrnuje CanonicalizedHeaders část řetězce. Navíc hlavička Date v tomto případě není nikdy prázdná, i když požadavek nastaví hlavičku x-ms-date . Pokud požadavek nastaví x-ms-date, použije se tato hodnota také pro hodnotu hlavičky Date .
K zakódování řetězce podpisu pro požadavek na službu Table service vytvořeného pomocí rozhraní REST API použijte následující formát:
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedResource;
Poznámka
Počínaje verzí 2009-09-19 služba Table vyžaduje, aby všechna volání REST obsahovala DataServiceVersion hlavičky a MaxDataServiceVersion . Další informace najdete v tématu Nastavení hlaviček verze datové služby OData .
Služby Blob, Queue a File (autorizace sdíleného klíče Lite)
Autorizaci sdíleného klíče Lite můžete použít k autorizaci požadavku vytvořeného ve verzi 2009-09-19 a novějších služeb Blob a Queue a ve službě File verze 2014-02-14 a novější.
Řetězec podpisu pro Sdílený klíč Lite je stejný jako řetězec podpisu vyžadovaný pro autorizaci sdíleného klíče ve verzích služeb Blob a Queue před 19. 9. 2009. Pokud tedy chcete migrovat kód s nejmenším počtem změn do verze 2009-09-19 služeb Blob a Queue, můžete kód upravit tak, aby používal sdílený klíč Lite, aniž byste museli změnit samotný řetězec podpisu. Používáním sdíleného klíče Lite nezískáte rozšířené funkce zabezpečení poskytované používáním sdíleného klíče s verzí 2009-09-19 a novější.
K zakódování řetězce podpisu pro požadavek pro službu Blob nebo Queue použijte následující formát:
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
Následující příklad ukazuje řetězec podpisu pro operaci Put Blob . Všimněte si, že řádek záhlaví Content-MD5 je prázdný. Hlavičky zobrazené v řetězci jsou páry název-hodnota, které určují hodnoty vlastních metadat pro nový objekt blob.
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
Dále tento řetězec zakódujte pomocí algoritmu HMAC-SHA256 přes řetězec podpisu s kódováním UTF-8, sestavte hlavičku Authorization a přidejte ji do požadavku. Následující příklad ukazuje hlavičku Authorization stejné operace:
Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
Table Service (autorizace sdíleného klíče Lite)
Autorizaci sdíleného klíče Lite můžete použít k autorizaci požadavku vytvořeného pro libovolnou verzi služby Table.
Pokud chcete kódovat řetězec podpisu pro požadavek na službu Table service pomocí sdíleného klíče Lite, použijte následující formát:
StringToSign = Date + "\n"
CanonicalizedResource
Následující příklad ukazuje řetězec podpisu pro operaci Create Table .
Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables
Dále tento řetězec zakódujte pomocí algoritmu HMAC-SHA256, sestavte hlavičku Authorization a pak přidejte hlavičku do požadavku. Následující příklad ukazuje hlavičku Authorization stejné operace:
Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=
Vytvoření řetězce kanonizovaných hlaviček
Pokud chcete vytvořit CanonicalizedHeaders část řetězce podpisu, postupujte takto:
Načtěte všechna záhlaví pro prostředek, který začíná
x-ms-na , včetněx-ms-datezáhlaví.Převeďte názvy hlaviček HTTP na malá písmena.
Seřaďte záhlaví lexicograficky podle názvu záhlaví ve vzestupném pořadí. Každé záhlaví se může v řetězci zobrazit pouze jednou.
Poznámka
Lexicografické řazení se nemusí vždy shodovat s konvenčním abecedním řazením.
Nahraďte všechny lineární prázdné znaky v hodnotě záhlaví jednou mezerou.
Lineární prázdné znaky zahrnují návratový znak nebo podávání řádků (CRLF), mezery a tabulátory. Podrobnosti najdete v dokumentu RFC 2616, oddíl 4.2 . Nenahrazujte žádné prázdné znaky uvnitř řetězce s uvozovými znaky.
Ořízněte všechny prázdné znaky kolem dvojtečky v záhlaví.
Nakonec ke každému kanonizovanému záhlaví ve výsledném seznamu připojte znak nového řádku.
CanonicalizedHeadersSestavte řetězec zřetězením všech hlaviček v tomto seznamu do jednoho řetězce.
Následující příklad ukazuje řetězec kanonizovaných hlaviček:
x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n
Poznámka
Před verzí služby 2016-05-31 byly hlavičky s prázdnými hodnotami vynechány z řetězce podpisu. Ty jsou nyní reprezentovány v CanonicalizedHeaders okamžitě za znakem dvojtečky s ukončující nový řádek.
Vytvoření kanonického řetězce prostředků
Část CanonicalizedResource řetězce podpisu představuje prostředek služeb úložiště, na který cílí požadavek. Jakákoli část CanonicalizedResource řetězce odvozená z identifikátoru URI prostředku by měla být zakódovaná přesně tak, jak je v identifikátoru URI.
Řetězec má dva podporované formáty CanonicalizedResource :
Formát, který podporuje autorizaci sdíleného klíče pro verzi 2009-09-19 a novější služby Blob a Queue a pro verzi 2014-02-14 a novější služby File.
Formát, který podporuje sdílený klíč a sdílený klíč Lite pro všechny verze služby Table a sdílený klíč Lite pro verzi 2009-09-19 a novější služby Blob a Queue. Tento formát je shodný s předchozími verzemi služeb úložiště.
Nápovědu k vytvoření identifikátoru URI pro prostředek, ke který přistupujete, najdete v jednom z následujících témat:
Blob Service: Pojmenování kontejnerů, objektů blob a metadat a odkazování na nich
Frontová služba: Adresování prostředků služby fronty
Table service: Adresování prostředků služby Table Service
Souborová služba: Pojmenování sdílených složek, adresářů, souborů a metadat a odkazování na nich
Důležité
Pokud se váš účet úložiště replikuje s geografickou replikací s přístupem pro čtení (RA-GRS) a přistupujete k prostředku v sekundárním umístění, nezahrnujte –secondary do řetězce toto označení CanonicalizedResource . Identifikátor URI prostředku použitý v řetězcovém CanonicalizedResource identifikátoru URI by měl být identifikátorem URI prostředku v primárním umístění.
Poznámka
Pokud autorizujete v emulátoru úložiště, název účtu se v řetězci CanonicalizedResource zobrazí dvakrát. To se očekává. Pokud autorizujete služby Azure Storage, název účtu se v řetězci CanonicalizedResource zobrazí jenom jednou.
Formát sdíleného klíče pro 2009-09-19 a novější
Tento formát podporuje autorizaci sdíleného klíče pro verze 2009-09-19 a novější služby Blob a Queue a souborové služby z 14. 2. 2014 a novější. CanonicalizedResource Sestavte řetězec v tomto formátu následujícím způsobem:
Počínaje prázdným řetězcem (""), připojte lomítko (/) následované názvem účtu, který vlastní prostředek, ke kterému se přistupuje.
Připojte cestu URI kódovaného prostředku bez jakýchkoli parametrů dotazu.
Načtěte všechny parametry dotazu pro identifikátor URI prostředku, včetně parametru
comp, pokud existuje.Převeďte všechny názvy parametrů na malá písmena.
Seřaďte parametry dotazu lexicograficky podle názvu parametru ve vzestupném pořadí.
Adresa URL dekóduje název a hodnotu každého parametru dotazu.
Před každou dvojici název-hodnota zahrňte znak nového řádku (\n).
Přidejte název a hodnotu každého parametru dotazu k řetězci v následujícím formátu a nezapomeňte zahrnout dvojtečku (:) mezi názvem a hodnotou:
parameter-name:parameter-valuePokud má parametr dotazu více než jednu hodnotu, seřaďte všechny hodnoty lexicograficky a pak je zahrňte do seznamu odděleného čárkami:
parameter-name:parameter-value-1,parameter-value-2,parameter-value-n
Mějte na paměti následující pravidla pro vytvoření kanonického řetězce prostředku:
Nepoužívejte znak nového řádku (\n) v hodnotách pro parametry dotazu. Pokud je nutné použít, ujistěte se, že nemá vliv na formát kanonizovaného řetězce prostředku.
Nepoužívejte čárky v hodnotách parametrů dotazu.
Tady je několik příkladů, které ukazují CanonicalizedResource část řetězce podpisu, protože je možné ji vytvořit z daného identifikátoru URI požadavku:
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
Get Blob operation against a resource in the secondary location:
GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob
CanonicalizedResource:
/myaccount/mycontainer/myblob
Formát služby Shared Key Lite a Table Service pro 19. 9. 2009 a novější
Tento formát podporuje sdílený klíč a sdílený klíč Lite pro všechny verze služby Table a sdílený klíč Lite pro verzi 2009-09-19 a novější služby Blob a Queue a verze 2014-02-14 a novější služby File. Tento formát je shodný s předchozími verzemi služeb úložiště. CanonicalizedResource Sestavte řetězec v tomto formátu následujícím způsobem:
Počínaje prázdným řetězcem (""), připojte lomítko (/) následované názvem účtu, který vlastní prostředek, ke kterému se přistupuje.
Připojte cestu URI kódovaného prostředku. Pokud identifikátor URI požadavku řeší součást prostředku, připojte příslušný řetězec dotazu. Řetězec dotazu by měl obsahovat otazník a
compparametr (například?comp=metadata). V řetězci dotazu by neměly být zahrnuty žádné další parametry.
Kódování podpisu
Pokud chcete zakódovat podpis, zavolejte algoritmus HMAC-SHA256 v řetězci podpisu s kódováním UTF-8 a zakódujte výsledek jako Base64. Mějte na paměti, že musíte také dekódovat klíč účtu úložiště Base64. Použijte následující formát (zobrazený jako pseudokód):
Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))