Auktorisera med delad nyckel
Varje begäran som görs mot en lagringstjänst måste auktoriseras, såvida inte begäran gäller 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.
Viktigt
För optimal säkerhet rekommenderar Microsoft att du använder Microsoft Entra ID med hanterade identiteter för att auktorisera begäranden mot blob-, kö- och tabelldata när det är möjligt. Auktorisering med Microsoft Entra ID och hanterade identiteter ger överlägsen säkerhet och enkel användning via auktorisering med delad nyckel. Mer information finns i Auktorisera med Microsoft Entra ID. Mer information om hanterade identiteter finns i Vad är hanterade identiteter för Azure-resurser.
För resurser som finns utanför Azure, till exempel lokala program, kan du använda hanterade identiteter via Azure Arc. Appar som körs på Azure Arc-aktiverade servrar kan till exempel använda hanterade identiteter för att ansluta till Azure-tjänster. Mer information finns i Autentisera mot Azure-resurser med Azure Arc-aktiverade servrar.
För scenarier där signaturer för delad åtkomst (SAS) används rekommenderar Microsoft att du använder en SAS för användardelegering. En SAS för användardelegering skyddas med Microsoft Entra autentiseringsuppgifter i stället för kontonyckeln. Mer information om signaturer för delad åtkomst finns i Skapa en SAS för användardelegering.
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-, kö- och filtjänster. 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 table-tjä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 Table-tjänsten.
Delad nyckel Lite. Använd auktoriseringsschemat Lite för delad nyckel 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 att använda en signatursträng som är identisk med den som stöds mot delad nyckel i tidigare versioner av blob- och kötjänsterna. Du kan därför använda Shared Key Lite 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 https rekommenderas starkt.
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 rubriken eller i HTTP/HTTPS-standardrubriken Date . Om båda huvudena anges i begäran används värdet x-ms-date för som begärans tidpunkt då 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 rubriken.
Ange auktoriseringsrubriken
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 som en signatur för delad åtkomst har angetts för delegerad åtkomst för.
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.
Konstruera 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ågon rubrik 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 bara det nya radtecknet.
x-ms-dateOm rubriken anges kan du ignoreraDaterubriken, oavsett om den har angetts i 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 den kanoniska rubriksträngenx-ms-dateför att lägga till huvudet.Det är acceptabelt att ange både
x-ms-dateochDate. I det här fallet använder tjänsten värdetx-ms-date.Om rubriken
x-ms-dateinte anges 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. Genom att kanonisera dessa strängar hamnar de i ett standardformat som identifieras 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 Content-Length 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 det här 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 hjälp av 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 med 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 din kod till version 2009-09-19 eller senare av blob- och kötjänsterna med minst möjliga ändringar, kan du ändra dina befintliga Authorization huvuden 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 i 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 aktiverat ska du inte ta med -secondary beteckningen i auktoriseringshuvudet. I auktoriseringssyfte är kontonamnet alltid namnet på den primära platsen, även för sekundär åtkomst.
Content-Length-huvudet 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 delen av till StringToSign0. Normalt skulle detta vara en tom sträng.
För följande begäran inkluderas till exempel värdet Content-Length för 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 Konstrueras 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 2014-02-14 StringToSign måste innehålla 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 med 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 table-tjänsten är detsamma för alla versioner.
Signatursträngen för delad nyckel för en begäran mot table-tjä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 även det värdet 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 huvudena 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 som görs mot versionen 2009-09-19 och senare av blob- och kötjänsterna och 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 Shared Key Lite, utan att ändra själva signatursträngen. Genom att använda Lite för delad nyckel 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 huvudraden 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 hjälp av 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 table-tjä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 Skapa tabellåtgärd.
Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables
Koda sedan strängen med hjälp av 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=
Konstruera den kanoniska huvudsträ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-daterubriken.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
Lexikalisk ordningsföljd kanske inte alltid sammanfaller med konventionell alfabetisk ordning.
Ersätt alla linjära blanksteg i rubrikvärdet med ett enda blanksteg.
Linjärt tomt utrymme innehåller vagnretur/radmatning (CRLF), blanksteg och flikar. Mer information finns i RFC 2616, avsnitt 4.2 . Ersätt inte blanksteg i en citerad sträng.
Trimma alla blanksteg runt kolonet i rubriken.
Slutligen lägger du till ett nytt radtecken i varje kanonisk rubrik i den resulterande listan. Konstruera strängen
CanonicalizedHeadersgenom att sammanfoga alla rubriker i den här listan till en enda sträng.
Nedan visas 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.
Konstruera den kanoniska resurssträngen
Delen CanonicalizedResource av signatursträngen representerar lagringstjänstresursen som begäran riktar sig mot. Alla delar av strängen CanonicalizedResource som härleds från resursens URI ska 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 stöder 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.
Information om hur du skapar URI:n för den resurs som du använder finns i något av följande avsnitt:
Blob-tjänst: Namnge och referera till containrar, blobar och metadata
Kötjänst: Adressering av 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äsbehörighet (RA-GRS) och du har åtkomst till en resurs på den sekundära platsen ska du inte ta med –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 kö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 följer några exempel som visar CanonicalizedResource delen av signatursträngen, eftersom den kan konstrueras från en viss 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 stöder Lite för delad nyckel och delad nyckel för alla versioner av table-tjänsten och Shared Key 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 ska 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 din lagringskontonyckel. Använd följande format (visas som pseudokod):
Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))