Auktorisera med delad nyckel
Varje begäran som görs mot en lagringstjänst måste auktoriseras, såvida inte begäran gäller för en blob- eller containerresurs som har gjorts tillgänglig för offentlig eller signerad åtkomst. Ett alternativ för att auktorisera en begäran är att använda delad nyckel, som beskrivs i den här artikeln.
Tips
Azure Storage tillhandahåller integrering med Microsoft Entra ID för identitetsbaserad auktorisering av begäranden till blob-, fil-, kö- och tabelltjänsterna. Med Microsoft Entra ID kan du använda rollbaserad åtkomstkontroll (RBAC) för att ge åtkomst till blob-, fil-, kö- och tabellresurser till användare, grupper eller program. Microsoft Entra ID kan användas för att auktorisera åtkomst till lagringsresurser utan att lagra dina kontoåtkomstnycklar i dina program, som du gör med delad nyckel. Mer information finns i Auktorisera med Microsoft Entra ID.
Tjänsterna Blob, Queue, Table och File stöder följande auktoriseringsscheman för delad nyckel för version 2009-09-19 och senare (för blob-, kö- och tabelltjänst) och version 2014-02-14 och senare (för filtjänst):
Delad nyckel för Blob, Queue och File Services. Använd auktoriseringsschemat för delad nyckel för att göra begäranden mot blob-, kö- och filtjänsterna. Auktorisering av delad nyckel i version 2009-09-19 och senare stöder en förhöjd signatursträng för förbättrad säkerhet och kräver att du uppdaterar tjänsten för att auktorisera med den här förhöjda signaturen.
Delad nyckel för Table Service. Använd auktoriseringsschemat för delad nyckel för att göra begäranden mot tabelltjänsten med hjälp av REST-API:et. Auktorisering av delad nyckel för tabelltjänsten i version 2009-09-19 och senare använder samma signatursträng som i tidigare versioner av Tabelltjänsten.
Delad nyckel Lite. Använd auktoriseringsschemat För delad nyckel Lite för att göra begäranden mot blob-, kö-, tabell- och filtjänsterna.
För version 2009-09-19 och senare av blob- och kötjänsterna stöder Lite-auktorisering med delad nyckel en signatursträng som är identisk med vad som stöds mot delad nyckel i tidigare versioner av Blob- och Queue-tjänsterna. Du kan därför använda Lite för delad nyckel för att göra begäranden mot blob- och kötjänsterna utan att uppdatera din signatursträng.
En auktoriserad begäran kräver två huvuden: Date eller x-ms-date -huvudet och Authorization huvudet. I följande avsnitt beskrivs hur du skapar dessa rubriker.
Viktigt
Azure Storage stöder både HTTP och HTTPS, men det rekommenderas starkt att du använder HTTPS.
Anteckning
En container eller blob kan göras tillgänglig för offentlig åtkomst genom att ange en containers behörigheter. Mer information finns i Hantera åtkomst till Azure Storage-resurser. En container, blob, kö eller tabell kan göras tillgänglig för signerad åtkomst via en signatur för delad åtkomst. en signatur för delad åtkomst auktoriseras via en annan mekanism. Mer information finns i Delegera åtkomst med en signatur för delad åtkomst .
Ange datumrubriken
Alla auktoriserade begäranden måste innehålla tidsstämpeln Coordinated Universal Time (UTC) för begäran. Du kan ange tidsstämpeln x-ms-date antingen i huvudet eller i http/HTTPS-standardrubriken Date . Om båda rubrikerna anges i begäran används värdet x-ms-date för som begärans tidpunkt när begäran skapades.
Lagringstjänsterna ser till att en begäran inte är äldre än 15 minuter när den når tjänsten. Detta skyddar mot vissa säkerhetsattacker, inklusive reprisattacker. När den här kontrollen misslyckas returnerar servern svarskoden 403 (Förbjuden).
Anteckning
Rubriken x-ms-date tillhandahålls eftersom vissa HTTP-klientbibliotek och proxyservrar automatiskt anger Date huvudet och inte ger utvecklaren möjlighet att läsa dess värde för att inkludera det i den auktoriserade begäran. Om du anger x-ms-dateskapar du signaturen med ett tomt värde för Date huvudet.
Ange auktoriseringshuvudet
En auktoriserad begäran måste innehålla Authorization huvudet. Om det här huvudet inte ingår är begäran anonym och lyckas bara mot en container eller blob som har markerats för offentlig åtkomst, eller mot en container, blob, kö eller tabell för vilken en signatur för delad åtkomst har angetts för delegerad åtkomst.
Om du vill auktorisera en begäran måste du signera begäran med nyckeln för det konto som gör begäran och skicka signaturen som en del av begäran.
Formatet för Authorization rubriken är följande:
Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
där SharedKey eller SharedKeyLite är namnet på auktoriseringsschemat, AccountName är namnet på det konto som begär resursen och Signature är en Hash-baserad kod för meddelandeautentisering (HMAC) som skapats från begäran och beräknats med hjälp av SHA256-algoritmen och sedan kodats med hjälp av Base64-kodning.
Anteckning
Det går att begära en resurs som finns under ett annat konto, om resursen är offentligt tillgänglig.
I följande avsnitt beskrivs hur du Authorization skapar huvudet.
Skapa signatursträngen
Hur du skapar signatursträngen beror på vilken tjänst och version du auktoriserar mot och vilket auktoriseringsschema du använder. Tänk på följande när du skapar signatursträngen:
VERB-delen av strängen är HTTP-verbet, till exempel GET eller PUT, och måste vara versaler.
För auktorisering av delad nyckel för blob-, kö- och filtjänsterna kan varje rubrik som ingår i signatursträngen bara visas en gång. Om något huvud dupliceras returnerar tjänsten statuskod 400 (felaktig begäran).
Värdena för alla HTTP-standardrubriker måste inkluderas i strängen i den ordning som visas i signaturformatet, utan rubriknamnen. Dessa rubriker kan vara tomma om de inte anges som en del av begäran. I så fall krävs endast det nya radtecknet.
x-ms-dateOm rubriken har angetts kan du ignoreraDaterubriken, oavsett om den har angetts för begäran eller inte, och helt enkelt ange en tom rad förDatedelen av signatursträngen. I det här fallet följer du anvisningarna i avsnittet Skapa strängen för kanoniska rubriker för att lägga tillx-ms-datehuvudet.Det är acceptabelt att ange både
x-ms-dateochDate. I det här fallet använder tjänsten värdetx-ms-date.x-ms-dateOm rubriken inte har angetts anger duDaterubriken i signatursträngen, utan att inkludera rubriknamnet.Alla nya radtecken (\n) som visas krävs i signatursträngen.
Signatursträngen innehåller kanoniska rubriker och kanoniska resurssträngar. Kanoniskisering av dessa strängar placerar dem i ett standardformat som känns igen av Azure Storage. Detaljerad information om hur du skapar strängarna
CanonicalizedHeadersochCanonicalizedResourcesom utgör en del av signatursträngen finns i lämpliga avsnitt senare i det här avsnittet.
Blob-, kö- och filtjänster (auktorisering av delad nyckel)
Om du vill koda signatursträngen för delad nyckel för en begäran mot versionen 2009-09-19 och senare av blob- eller kötjänsten och version 2014-02-14 och senare av filtjänsten använder du följande 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;
Viktigt
I den aktuella versionen måste fältet Innehållslängd vara en tom sträng om innehållslängden för begäran är noll. I version 2014-02-14 och tidigare inkluderades innehållslängden även om noll. Se nedan för mer information om det gamla beteendet.
I följande exempel visas en signatursträng för en Get Blob-åtgärd . Om det inte finns något rubrikvärde anges endast det nya radtecknet.
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
Om du delar upp detta rad för rad visas varje del av samma sträng:
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*/
Koda sedan den här strängen med HMAC-SHA256-algoritmen över DEN UTF-8-kodade signatursträngen Authorization , konstruera huvudet och lägg till huvudet i begäran. I följande exempel visas Authorization rubriken för samma åtgärd:
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
Om du vill använda auktorisering av delad nyckel med version 2009-09-19 och senare av blob- och kötjänsterna måste du uppdatera koden för att använda den här förhöjda signatursträngen.
Om du föredrar att migrera koden till version 2009-09-19 eller senare av blob- och kötjänsterna med minst möjliga ändringar, kan du ändra dina befintliga Authorization rubriker så att de använder Lite för delad nyckel i stället för Delad nyckel. Signaturformatet som krävs av Shared Key Lite är identiskt med det som krävs för delad nyckel av versioner av blob- och kötjänsterna före 2009-09-19.
Viktigt
Om du har åtkomst till den sekundära platsen i ett lagringskonto där geo-replikering med läsbehörighet (RA-GRS) är aktiverad ska du inte inkludera -secondary beteckningen i auktoriseringshuvudet. I auktoriseringssyfte är kontonamnet alltid namnet på den primära platsen, även för sekundär åtkomst.
Innehållslängdsrubrik i version 2014-02-14 och tidigare
När du använder version 2014-02-14 eller tidigare, om Content-Length är noll, anger du Content-Length sedan delen av till StringToSign0. Normalt skulle detta vara en tom sträng.
För följande begäran inkluderas till exempel värdet för Content-Length huvudet i StringToSign även när det är noll.
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
StringToSign Är konstruerad på följande sätt:
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
I versioner efter till 2014-02-14 måste innehålla StringToSign en tom sträng för 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
Tabelltjänst (auktorisering av delad nyckel)
Du måste använda auktorisering för delad nyckel för att auktorisera en begäran som görs mot Table-tjänsten om tjänsten använder REST-API:et för att göra begäran. Formatet för signatursträngen för delad nyckel mot tabelltjänsten är detsamma för alla versioner.
Signatursträngen för delad nyckel för en begäran mot tabelltjänsten skiljer sig något från den för en begäran mot blob- eller kötjänsten, eftersom den CanonicalizedHeaders inte innehåller delen av strängen. Dessutom Date är huvudet i det här fallet aldrig tomt även om begäran anger x-ms-date huvudet. Om begäran anger x-ms-dateanvänds det värdet också för värdet för Date huvudet.
Om du vill koda signatursträngen för en begäran mot tabelltjänsten som görs med hjälp av REST-API:et använder du följande format:
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedResource;
Anteckning
Från och med version 2009-09-19 kräver tabelltjänsten att alla REST-anrop innehåller rubrikerna DataServiceVersion och MaxDataServiceVersion . Mer information finns i Ange versionshuvuden för OData-datatjänsten .
Blob-, kö- och filtjänster (lite-auktorisering för delad nyckel)
Du kan använda lite-auktorisering för delad nyckel för att auktorisera en begäran mot 2009-09-19-versionen och senare av blob- och kötjänsterna samt version 2014-02-14 och senare av filtjänsterna.
Signatursträngen för Shared Key Lite är identisk med signatursträngen som krävs för auktorisering av delad nyckel i versioner av blob- och kötjänsterna före 2009-09-19. Så om du vill migrera koden med minst antal ändringar i version 2009-09-19 av blob- och kötjänsterna kan du ändra koden så att den använder Delad nyckel Lite, utan att ändra själva signatursträngen. Med hjälp av Shared Key Lite får du inte de förbättrade säkerhetsfunktioner som tillhandahålls med hjälp av delad nyckel med version 2009-09-19 och senare.
Om du vill koda signatursträngen för en begäran mot blob- eller kötjänsten använder du följande format:
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
I följande exempel visas en signatursträng för en Put Blob-åtgärd . Observera att rubrikraden Content-MD5 är tom. Rubrikerna som visas i strängen är namn/värde-par som anger anpassade metadatavärden för den nya bloben.
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
Koda sedan den här strängen med HMAC-SHA256-algoritmen över DEN UTF-8-kodade signatursträngen Authorization , konstruera huvudet och lägg till huvudet i begäran. I följande exempel visas Authorization rubriken för samma åtgärd:
Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
Tabelltjänst (lite-auktorisering för delad nyckel)
Du kan använda lite-auktorisering för delad nyckel för att auktorisera en begäran som görs mot valfri version av Table-tjänsten.
Om du vill koda signatursträngen för en begäran mot tabelltjänsten med hjälp av Shared Key Lite använder du följande format:
StringToSign = Date + "\n"
CanonicalizedResource
I följande exempel visas en signatursträng för en create table-åtgärd .
Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables
Koda sedan den här strängen med HMAC-SHA256-algoritmen Authorization , konstruera huvudet och lägg sedan till huvudet i begäran. I följande exempel visas Authorization rubriken för samma åtgärd:
Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=
Skapa den kanoniska sidhuvudsträngen
Så här skapar CanonicalizedHeaders du delen av signatursträngen:
Hämta alla rubriker för resursen som börjar med
x-ms-, inklusivex-ms-datehuvudet.Konvertera varje HTTP-huvudnamn till gemener.
Sortera rubrikerna lexicographically efter rubriknamn, i stigande ordning. Varje rubrik kan bara visas en gång i strängen.
Anteckning
Lexikografiska ordningsföljder kanske inte alltid sammanfaller med konventionell alfabetisk ordning.
Ersätt alla linjära blanksteg i rubrikvärdet med ett enda blanksteg.
Linjärt blanksteg innehåller vagnretur/radmatning (CRLF), blanksteg och flikar. Mer information finns i RFC 2616, avsnitt 4.2 . Ersätt inte något blanksteg i en citerad sträng.
Trimma alla blanksteg runt kolonet i rubriken.
Lägg slutligen till ett nytt radtecken i varje kanonisk rubrik i den resulterande listan. Skapa strängen
CanonicalizedHeadersgenom att sammanfoga alla rubriker i den här listan till en enda sträng.
Följande visar ett exempel på en kanonisk rubriksträng:
x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n
Anteckning
Före tjänstversion 2016-05-31 utelämnades rubriker med tomma värden från signatursträngen. Dessa representeras nu i CanonicalizedHeaders genom att omedelbart följa kolontecknet med den avslutande nya raden.
Skapa den kanoniska resurssträngen
Delen CanonicalizedResource av signatursträngen representerar den lagringstjänstresurs som begäran avser. Alla delar av strängen CanonicalizedResource som härleds från resursens URI bör kodas exakt som i URI:n.
Det finns två format som stöds för strängen CanonicalizedResource :
Ett format som stöder auktorisering av delad nyckel för version 2009-09-19 och senare av blob- och kötjänsterna, och för version 2014-02-14 och senare av filtjänsten.
Ett format som har stöd för Delad nyckel och Delad nyckel Lite för alla versioner av tabelltjänsten och Lite för delad nyckel för version 2009-09-19 och senare av blob- och kötjänsterna. Det här formatet är identiskt med det som används med tidigare versioner av lagringstjänsterna.
Mer information om hur du skapar URI:n för den resurs som du använder finns i något av följande avsnitt:
Blobtjänst: Namnge och referera till containrar, blobar och metadata
Kötjänst: Hantera kötjänstresurser
Tabelltjänst: Hantera tabelltjänstresurser
Filtjänst: Namnge och referera till resurser, kataloger, filer och metadata
Viktigt
Om ditt lagringskonto replikeras med geo-replikering med läsåtkomst (RA-GRS) och du har åtkomst till en resurs på den sekundära platsen ska du inte inkludera –secondary beteckningen i strängen CanonicalizedResource . Resurs-URI:n som används i sträng-URI CanonicalizedResource :n ska vara resursens URI på den primära platsen.
Anteckning
Om du auktoriserar mot lagringsemulatorn visas kontonamnet två gånger i strängen CanonicalizedResource . Detta är förväntat. Om du auktoriserar mot Azure Storage-tjänster visas kontonamnet bara en gång i strängen CanonicalizedResource .
Format för delad nyckel för 2009-09-19 och senare
Det här formatet stöder auktorisering av delad nyckel för 2009-09-19-versionen och senare av Blob- och Queue-tjänsterna, samt 2014-02-14-versionen och senare av filtjänsterna. Skapa strängen CanonicalizedResource i det här formatet på följande sätt:
Från och med en tom sträng (""), lägger du till ett snedstreck (/), följt av namnet på det konto som äger resursen som används.
Lägg till resursens kodade URI-sökväg utan några frågeparametrar.
Hämta alla frågeparametrar på resurs-URI:n, inklusive parametern
compom den finns.Konvertera alla parameternamn till gemener.
Sortera frågeparametrarna lexicographically efter parameternamn, i stigande ordning.
URL-avkoda varje frågeparameternamn och värde.
Inkludera ett nytt radtecken (\n) före varje namn/värde-par.
Lägg till varje frågeparameternamn och värde i strängen i följande format och se till att inkludera kolonet (:) mellan namnet och värdet:
parameter-name:parameter-valueOm en frågeparameter har fler än ett värde sorterar du alla värden lexicographically och tar sedan med dem i en kommaavgränsad lista:
parameter-name:parameter-value-1,parameter-value-2,parameter-value-n
Tänk på följande regler för att skapa den kanoniska resurssträngen:
Undvik att använda det nya radtecknet (\n) i värden för frågeparametrar. Om den måste användas kontrollerar du att den inte påverkar formatet för den kanoniska resurssträngen.
Undvik att använda kommatecken i frågeparametervärden.
Här är några exempel som visar CanonicalizedResource delen av signatursträngen, eftersom den kan konstrueras från en angiven begärande-URI:
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
Shared Key Lite- och Table-tjänstformat för 2009-09-19 och senare
Det här formatet har stöd för Delad nyckel och Delad nyckel Lite för alla versioner av tabelltjänsten och Delad nyckel Lite för version 2009-09-19 och senare av blob- och kötjänsterna och version 2014-02-14 och senare av filtjänsten. Det här formatet är identiskt med det som används med tidigare versioner av lagringstjänsterna. Skapa strängen CanonicalizedResource i det här formatet på följande sätt:
Från och med en tom sträng (""), lägger du till ett snedstreck (/), följt av namnet på det konto som äger resursen som används.
Lägg till resursens kodade URI-sökväg. Om begärans URI adresserar en komponent i resursen lägger du till lämplig frågesträng. Frågesträngen bör innehålla frågetecknet och parametern
comp(till exempel?comp=metadata). Inga andra parametrar ska ingå i frågesträngen.
Koda signaturen
Om du vill koda signaturen anropar du HMAC-SHA256-algoritmen på DEN UTF-8-kodade signatursträngen och kodar resultatet som Base64. Observera att du också behöver Base64-avkoda lagringskontonyckeln. Använd följande format (visas som pseudokod):
Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))