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.
Viktig
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 av 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, Queue och Table Service) 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 utökade 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 Table-tjänsten.
Lite för delad nyckel. Använd auktoriseringsschemat För delad nyckel Lite för att göra begäranden mot blob-, kö-, tabell- och filtjänsterna. Delad nyckel lite stöds inte för premium-sidblobar.
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 konstruerar dessa rubriker.
Viktig
Azure Storage stöder både HTTP och HTTPS, men det rekommenderas starkt att använda HTTPS.
Not
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 antingen i x-ms-date-huvudet eller i http/HTTPS-standardrubriken för Date. Om båda rubrikerna anges i begäran används värdet för x-ms-date 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).
Not
x-ms-date-huvudet 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 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 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-huvudet ä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.
Not
Det är möjligt att begära en resurs som finns under ett annat konto, om resursen är offentligt tillgänglig.
I följande avsnitt beskrivs hur du skapar Authorization-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 standard-HTTP-huvuden 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.
Om
x-ms-date-huvudet anges kan du ignoreraDate-huvudet, oavsett om det har angetts i begäran, och helt enkelt ange en tom rad för denDatedelen av signatursträngen. I det här fallet följer du anvisningarna i avsnittet Konstruera den kanoniska sidhuvudsträngen för att lägga tillx-ms-date-huvudet.Det är acceptabelt att ange både
x-ms-dateochDate. I det här fallet använder tjänsten värdet förx-ms-date.Om
x-ms-date-huvudet inte har angetts anger duDate-huvudet 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
CanonicalizedHeadersochCanonicalizedResourcesträngar som 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 2009-09-19-versionen 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;
Viktig
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 åtgärden Hämta blob. 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 strängen med hjälp av HMAC-SHA256-algoritmen över den UTF-8-kodade signatursträngen, konstruera Authorization-huvudet och lägg till huvudet i begäran. I följande exempel visas Authorization-huvudet 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 utökade signatursträngen.
Om du föredrar att migrera koden till version 2009-09-19 eller senare av Blob- och Queue-tjänsterna med minst möjliga ändringar kan du ändra dina befintliga Authorization-huvuden så att de använder Delad nyckellitter 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 Queue-tjänsterna före 2009-09-19.
Viktig
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 ta med -secondary-beteckningen i auktoriseringshuvudet. I auktoriseringssyfte är kontonamnet alltid namnet på den primära platsen, även för sekundär åtkomst.
Rubrik för innehållslängd 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 del av StringToSign till 0. 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 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 måste StringToSign 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 behörighet för delad nyckel för att auktorisera en begäran mot tabelltjä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 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 inte innehåller CanonicalizedHeaders delen av strängen. Dessutom är Date-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;
Not
Från och med version 2009-09-19 kräver tabelltjänsten att alla REST-anrop innehåller DataServiceVersion- och MaxDataServiceVersion-huvuden. 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. Delad nyckel lite stöds inte för premium-sidblobar.
Signatursträngen för Delad nyckel Lite är identisk med signatursträngen som krävs för auktorisering av delad nyckel i versioner av Blob- och Queue-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 strängen med hjälp av HMAC-SHA256-algoritmen över den UTF-8-kodade signatursträngen, konstruera Authorization-huvudet och lägg till huvudet i begäran. I följande exempel visas Authorization-huvudet 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 Delad nyckel Lite använder du följande format:
StringToSign = Date + "\n"
CanonicalizedResource
I följande exempel visas en signatursträng för en åtgärden Skapa tabell.
Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables
Koda sedan strängen med hjälp av HMAC-SHA256-algoritmen, konstruera Authorization-huvudet och lägg sedan till huvudet i begäran. I följande exempel visas Authorization-huvudet för samma åtgärd:
Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=
Konstruera den kanoniska sidhuvudsträngen
Så här skapar du CanonicalizedHeaders delen av signatursträngen:
Hämta alla rubriker för resursen som börjar med
x-ms-, inklusivex-ms-date-huvudet.Konvertera varje HTTP-rubriknamn till gemener.
Sortera rubrikerna lexicographically efter rubriknamn i stigande ordning. Varje rubrik kan bara visas en gång i strängen.
Not
Lexicographical ordering 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/linjematning (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.
Slutligen lägger du till ett nytt radtecken i varje kanonisk rubrik i den resulterande listan. Konstruera
CanonicalizedHeaderssträngen genom 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
Not
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
Den CanonicalizedResource delen av signatursträngen representerar lagringstjänstresursen som begäran avser. Alla delar av CanonicalizedResource strängen som härleds från resursens URI ska kodas exakt som i URI:n.
Det finns två format som stöds för CanonicalizedResource strängen:
Ett format som stöder auktorisering av delad nyckel för version 2009-09-19 och senare av Blob- och Queue-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 Delad nyckel Lite för version 2009-09-19 och senare av Blob- och Queue-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 kommer åt finns i något av följande avsnitt:
Blob-tjänst: namngivning och referens av containrar, blobar och metadata
Kötjänst: adressera kötjänstresurser
Tabelltjänst: adressering av tabelltjänstresurser
Filtjänst: namngivning och referensresurser, kataloger, filer och metadata
Viktig
Om ditt lagringskonto replikeras med read-access geo-replikering (RA-GRS) och du har åtkomst till en resurs på den sekundära platsen ska du inte ta med –secondary-beteckningen i CanonicalizedResource strängen. Resurs-URI:n som används i CanonicalizedResource sträng-URI:n ska vara resursens URI på den primära platsen.
Not
Om du auktoriserar mot lagringsemulatorn visas kontonamnet två gånger i CanonicalizedResource strängen. Detta är förväntat. Om du auktoriserar mot Azure Storage-tjänster visas kontonamnet bara en gång i CanonicalizedResource strängen.
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 CanonicalizedResource strängen 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 mer ä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 konstruera 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 den CanonicalizedResource delen av signatursträngen, eftersom den kan konstrueras från en viss URI för begäran:
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
Format för delad nyckellitter och tabelltjänst för 2009-09-19 och senare
Det här formatet stöder 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 Queue-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 CanonicalizedResource strängen 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ärande-URI:n 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>)))