Autenticazione per i servizi di archiviazione di Azure
Il presente articolo è stato tradotto automaticamente. Passare il puntatore sulle frasi nell'articolo per visualizzare il testo originale. Ulteriori informazioni.
Traduzione
Originale

Autenticazione per i servizi di archiviazione di Azure

 

Ogni richiesta effettuata in un servizio di archiviazione deve essere autenticata, a meno che la richiesta non sia relativa a una risorsa BLOB o contenitore resa disponibile per l'accesso pubblico o firmato.

System_CAPS_importantImportante

I servizi di archiviazione di Microsoft Azure supportano sia HTTP sia HTTPS, anche se è consigliato l'utilizzo di HTTPS.

I servizi BLOB, di accodamento, tabelle e file supportano gli schemi di autenticazione Chiave condivisa seguenti a partire dalla versione 2009-09-19 (per i servizi BLOB, di accodamento e tabelle) e dalla versione 2014-02-14 (per il servizio file):

  • Chiave condivisa per i servizi BLOB, di accodamento e file. Utilizzare lo schema di autenticazione chiave condivisa per effettuare richieste nei servizi Blob, coda e File. L'autenticazione Chiave condivisa della versione 2009-09-19 e successive supporta una stringa di firma più estesa per offrire una migliore sicurezza e richiede l'aggiornamento del servizio per poter eseguire l'autenticazione usando questa firma più estesa.

  • Chiave condivisa per il servizio tabelle. Utilizzare lo schema di autenticazione chiave condivisa per effettuare richieste nel servizio tabelle utilizzando l'API REST. L'autenticazione Chiave condivisa per il servizio tabelle della versione 2009-09-19 e successive usa la stessa stringa di firma delle versioni precedenti del servizio tabelle.

  • Chiave condivisa versione Lite. Utilizzare lo schema di autenticazione chiave condivisa versione Lite per effettuare richieste nei servizi Blob, coda, tabella e File.

    A partire dalla versione 2009-09-19 dei servizi BLOB e di accodamento, l'autenticazione Chiave condivisa versione Lite supporta l'utilizzo di una stringa di firma identica a quella supportata nelle versioni precedenti dei servizi di accodamento e BLOB. È quindi possibile usare Chiave condivisa versione Lite per effettuare richieste nei servizi BLOB e di accodamento senza aggiornare la stringa di firma.

Una richiesta autenticata richiede due intestazioni: l'intestazione Date o x-ms-date e l'intestazione Authorization. Nelle sezioni seguenti viene descritto come creare queste intestazioni.

System_CAPS_noteNota

Un contenitore o un BLOB può essere reso disponibile per l'accesso pubblico impostando le autorizzazioni di un contenitore. Per ulteriori informazioni, vedere gestione dell'accesso alle risorse di archiviazione Azure. Un contenitore, un BLOB, una coda o una tabella possono essere resi disponibili per l'accesso firmato tramite una firma di accesso condiviso, la cui autenticazione avviene attraverso un meccanismo diverso. Per informazioni dettagliate, vedere Delega dell'accesso con una firma di accesso condiviso.

Tutte le richieste autenticate devono includere il timestamp UTC (Coordinated Universal Time) per la richiesta. È possibile specificare il timestamp nell'intestazione x-ms-date o nell'intestazione Date HTTP/HTTPS standard. Se entrambe le intestazioni sono specificate nella richiesta, il valore di x-ms-date viene usato come ora di creazione della richiesta.

I servizi di archiviazione garantiscono che non trascorrano più di 15 minuti prima che una richiesta raggiunga il servizio. Si tratta di una misura di sicurezza contro eventuali intrusioni, inclusi gli attacchi di tipo replay. Se questo controllo ha esito negativo, il server restituisce il codice di risposta 403 (Accesso negato).

System_CAPS_noteNota

L'intestazione x-ms-date viene fornita perché alcuni proxy e librerie client HTTP impostano automaticamente l'intestazione Date e non offrono allo sviluppatore la possibilità di leggere il relativo valore per includerlo nella richiesta autenticata. Se si imposta x-ms-date, creare la firma con un valore vuoto per l'intestazione Date.

Una richiesta autenticata deve includere l'intestazione Authorization. Se questa intestazione non è inclusa, la richiesta è anonima e può avere esito positivo solo in un contenitore o in un BLOB contrassegnato per l'accesso pubblico oppure in un contenitore, un BLOB, una coda o una tabella per cui è stato specificata una firma di accesso condiviso per l'accesso delegato.

Per autenticare una richiesta, è necessario firmare la richiesta con la chiave dell'account che effettua la richiesta e passare la firma come parte della richiesta.

Il formato dell'intestazione Authorization è il seguente:

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

dove SharedKey o SharedKeyLite è il nome dello schema di autorizzazione, AccountName è il nome dell'account che richiede la risorsa e Signature è un codice HMAC (Hash-based Message Authentication Code) creato dalla richiesta e calcolato usando l'algoritmo SHA256 e codificato con Base64.

System_CAPS_noteNota

È possibile richiedere una risorsa che risiede in un altro account, se questa risorsa è accessibile pubblicamente.

Nelle sezioni seguenti viene descritto come creare l'intestazione Authorization.

La modalità di creazione della stringa di firma dipende dal servizio e dalla versione che si desidera autenticare e dallo schema di autenticazione che si desidera usare. Quando si crea una stringa di firma, tenere presente quanto segue:

  • La parte VERB della stringa è il verbo HTTP, ad esempio GET o PUT e deve essere scritta in maiuscolo.

  • Per l'autenticazione Chiave condivisa per i servizi BLOB, di accodamento e file, ogni intestazione inclusa nella stringa di firma può comparire una sola volta. Se sono presenti intestazioni duplicate, il servizio restituisce il codice di stato 400 (Richiesta non valida).

  • I valori di tutte le intestazioni HTTP standard devono essere inclusi nella stringa nell'ordine indicato nel formato della firma, senza i nomi delle intestazioni. Queste intestazioni possono essere vuote se non vengono specificate come parte della richiesta. In questo caso, è obbligatorio solo il carattere di nuova riga.

  • Se l'intestazione x-ms-date è specificata, è possibile ignorare l'intestazione Date, indipendentemente dal fatto che sia o meno specificata nella richiesta e specificare semplicemente una riga vuota per la parte Date della stringa di firma. In questo caso, seguire le istruzioni riportate nella sezione Creazione dell'elemento CanonicalizedHeaders relative all'aggiunta dell'intestazione x-ms-date.

    Si noti che è accettabile specificare sia x-ms-date sia Date. In questo caso, il servizio usa il valore di x-ms-date.

  • Se l'intestazione x-ms-date non viene specificata, specificare l'intestazione Date nella stringa di firma, senza includere il nome dell'intestazione.

  • Tutti i caratteri di nuova riga (\n) mostrati sono obbligatori nella stringa di firma.

  • La stringa di firma include intestazioni in forma canonica e stringhe di risorsa in forma canonica. Con la canonicalizzazione, tali stringhe acquisiscono un formato standard riconosciuto da Archiviazione di Azure. Per informazioni dettagliate sulla creazione delle stringhe CanonicalizedHeaders e CanonicalizedResource che compongono parte della stringa di firma, vedere le sezioni appropriate più avanti in questo argomento.

Per codificare la stringa di firma basata su Chiave condivisa per una richiesta nella versione 2009-09-19 e successive del servizio BLOB o di accodamento e nella versione 2014-02-14 e successive del servizio file, usare il formato seguente:

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;

Nell'esempio seguente viene illustrata una stringa di firma per un'operazione Get Blob. Si noti che in assenza di un valore di intestazione, viene specificato solo il carattere di nuova riga.

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/ mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

Se lo si scompone riga per riga si mostra ogni parte della stessa stringa:


GET\n /*HTTP Verb*/ \n    /*Content-Encoding*/ \n    /*Content-Language*/ \n    /*Content-Length (include value 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:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n    /*CanonicalizedHeaders*/ /myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

In seguito, codificare questa stringa usando l'algoritmo HMAC-SHA256 sulla stringa di firma con codifica UTF-8, creare l'intestazione Authorization e aggiungere l'intestazione alla richiesta. Nell'esempio seguente viene illustrata intestazione Authorization per la stessa operazione:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Si noti che per usare l'autenticazione Chiave condivisa con la versione 2009-09-19 e successive dei servizi BLOB e di accodamento, è necessario aggiornare il codice affinché venga usata la stringa di firma estesa.

Se si preferisce la migrazione del codice alla versione 2009-09-19 o successive di servizi di accodamento e Blob con il minor numero di possibili modifiche, è possibile modificare quella esistente Authorization intestazioni utilizzare chiave condivisa versione Lite anziché chiave condivisa. Il formato della firma richiesto da Chiave condivisa versione Lite è identico a quello richiesto da Chiave condivisa nelle versioni dei servizi di accodamento e BLOB precedenti alla 2009-09-19.

System_CAPS_importantImportante

Se si intende accedere alla posizione secondaria in un account di archiviazione per cui è abilitata la replica geografica con accesso in lettura (RA-GRS), non includere la designazione -secondary nell'intestazione dell'autorizzazione. Ai fini dell'autorizzazione, il nome dell'account corrisponde sempre al nome della posizione primaria, anche per l'accesso secondario.

Quando si utilizza la versione 2015-02-21 o versione successiva, se Content-Length è zero, quindi impostare il Content-Length in parte il StringToSign su una stringa vuota.

Ad esempio, per la richiesta seguente, il valore del Content-Length intestazione viene omesso dal StringToSign quando è zero.

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1 x-ms-version: 2015-02-21 x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08= Content-Length: 0

Il StringToSign costruita nel modo seguente:

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

Mentre nelle versioni precedenti 2015-02-21, il StringToSign deve includere il valore zero per Content-Length:

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:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

È necessario usare l'autenticazione Chiave condivisa per autenticare una richiesta effettuata nel servizio tabelle se il servizio usa l'API REST per effettuare la richiesta. Il formato della stringa di firma per l'autenticazione Chiave condivisa nel servizio tabelle è lo stesso per tutte le versioni.

Si noti che la stringa di firma basata su Chiave condivisa per una richiesta effettuata nel servizio tabelle varia leggermente da quella per una richiesta effettuata nel servizio BLOB o di accodamento perché non include la parte CanonicalizedHeaders della stringa. Inoltre, in questo caso l'intestazione Date non è mai vuota anche se la richiesta imposta l'intestazione x-ms-date. Se la richiesta imposta x-ms-date, lo stesso valore viene usato come valore dell'intestazione Date.

Per codificare la stringa di firma per una richiesta nel servizio tabelle effettuata usando l'API REST, usare il formato seguente:

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

System_CAPS_noteNota

A partire dalla versione 2009-09-19, il servizio tabelle richiede che tutte le chiamate REST includano le intestazioni DataServiceVersion e MaxDataServiceVersion. Per altre informazioni, vedere Impostazione delle intestazioni della versione di OData Data Service.

È possibile usare l'autenticazione Chiave condivisa versione Lite per autenticare una richiesta effettuata nella versione 2009-09-19 e successive dei servizi BLOB e di accodamento e nella versione 2014-02-14 e successive dei servizi file.

Il formato di firma per Chiave condivisa versione Lite è identico a quello richiesto per l'autenticazione Chiave condivisa nelle versioni dei servizi di accodamento e Blob precedenti alla 2009-09-19. Pertanto, se si desidera eseguire la migrazione del codice con il minor numero possibile di modifiche alla versione 2009-09-19 dei servizi di accodamento e Blob, è possibile modificare il codice per utilizzare chiave condivisa versione Lite, senza modificare la stringa di firma stessa. Si noti che usando Chiave condivisa versione Lite, non si potrà usufruire della funzionalità di sicurezza migliorata garantita dall'autenticazione Chiave condivisa della versione 2009-09-19 e successive dell'API.

Per codificare la stringa di firma per una richiesta effettuata nel servizio BLOB o di accodamento, usare il formato seguente:

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

Nell'esempio seguente viene illustrata una stringa di firma per un'operazione Put Blob. Si noti che la riga dell'intestazione Content-MD5 è vuota. Le intestazioni visualizzate nella stringa sono coppie nome-valore che specificano valori di metadati personalizzati per il nuovo 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

In seguito, codificare questa stringa usando l'algoritmo HMAC-SHA256 sulla stringa di firma con codifica UTF-8, creare l'intestazione Authorization e aggiungere l'intestazione alla richiesta. Nell'esempio seguente viene illustrata intestazione Authorization per la stessa operazione:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

È possibile usare l'autenticazione Chiave condivisa versione Lite per autenticare una richiesta effettuata in una qualsiasi versione del servizio tabelle.

Per codificare la stringa di firma per una richiesta nel servizio tabelle effettuata usando Chiave condivisa versione Lite, usare il formato seguente:

StringToSign = Date + "\n" CanonicalizedResource

Nell'esempio seguente viene illustrata una stringa di firma per un'operazione Create Table.

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

In seguito, codificare questa stringa usando l'algoritmo HMAC-SHA256, creare l'intestazione Authorization e aggiungere l'intestazione alla richiesta. Nell'esempio seguente viene illustrata intestazione Authorization per la stessa operazione:

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

Per creare la parte CanonicalizedHeaders della stringa di firma, effettuare le operazioni seguenti:

  1. Recuperare tutte le intestazioni per la risorsa che iniziano con x-ms-, inclusa l'intestazione x-ms-date.

  2. Scrivere tutti i nomi delle intestazioni HTTP in caratteri minuscoli.

  3. Ordinare le intestazioni in modo lessicografico per nome di intestazione, in ordine crescente. Ogni intestazione può comparire una sola volta nella stringa.

    System_CAPS_noteNota

    L'ordine lessicografico può non coincidere sempre con l'ordinamento alfabetico convenzionale.

  4. Espandere la stringa sostituendo eventuali spazi vuoti con uno spazio singolo.

  5. Rimuovere eventuali spazi vuoti intorno ai due punti nell'intestazione.

  6. Infine, aggiungere un carattere di nuova riga a ogni intestazione in forma canonica nell'elenco risultante. Creare la stringa CanonicalizedHeaders concatenando tutte le intestazioni in questo elenco in una singola stringa.

Di seguito viene illustrato un esempio di stringa di intestazioni in forma canonica:

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

La parte CanonicalizedResource della stringa di firma rappresenta la risorsa dei servizi di archiviazione a cui è destinata la richiesta. Tutte le parti della stringa CanonicalizedResource che derivano dall'URI della risorsa devono essere codificate esattamente come nell'URI.

Due sono i formati supportati per la stringa CanonicalizedResource:

  • Un formato che supporta l'autenticazione Chiave condivisa per la versione 2009-09-19 e successive dei servizi BLOB e di accodamento e per la versione 2014-02-14 e successive del servizio file.

  • Un formato che supporta l'autenticazione Chiave condivisa e quella basata sulla versione Lite della Chiave condivisa per tutte le versioni del servizio tabelle e la versione Lite della Chiave condivisa per la versione 2009-09-19 e successive dei servizi di accodamento e BLOB. Questo formato è identico a quello usato con le versioni precedenti dei servizi di archiviazione.

Per informazioni sulla creazione dell'URI per la risorsa a cui si accede, vedere uno degli argomenti seguenti:

System_CAPS_importantImportante

Se l'account di archiviazione viene replicato con la replica geografica con accesso in lettura (RA-GRS) e si intende accedere a una risorsa nella posizione secondaria, non includere la designazione –secondary nella stringa CanonicalizedResource. L'URI della risorsa usato nell'URI della stringa CanonicalizedResource deve essere uguale a quello della risorsa nella posizione primaria.

System_CAPS_noteNota

Se l'autenticazione viene effettuata nell'emulatore di archiviazione, il nome dell'account viene visualizzato due volte nella stringa CanonicalizedResource. Tale comportamento è previsto. Se l'autenticazione viene effettuata nei servizi di archiviazione di Azure, il nome dell'account viene visualizzato una sola volta nella stringa CanonicalizedResource.

Versione 2009-09-19 e successive del formato della chiave condivisa

Questo formato supporta l'autenticazione Chiave condivisa per la versione 2009-09-19 e successive dei servizi BLOB e di accodamento e per la versione 2014-02-14 e successive dei servizi file. Creare la stringa CanonicalizedResource nel formato seguente:

  1. Da una stringa vuota (""), aggiungere una barra (/), seguita dal nome dell'account proprietario della risorsa a cui si desidera accedere.

  2. Aggiungere il percorso URI codificato della risorsa, senza parametri di query.

  3. Aggiungere un carattere di nuova riga (\n) dopo il nome della risorsa.

  4. Recuperare tutti i parametri di query nell'URI della risorsa, incluso il parametro comp se esistente.

  5. Scrivere tutti i nomi dei parametri in caratteri minuscoli.

  6. Ordinare i parametri di query in modo lessicografico per nome di parametro, in ordine crescente.

  7. Decodificare come URL il nome e il valore di ogni parametro di query.

  8. Aggiungere il nome e il valore di ogni parametro di query alla stringa nel formato seguente, assicurandosi di includere due punti (:) tra il nome e il valore:

    parameter-name:parameter-value

  9. Se un parametro di query presenta più di un valore, ordinare tutti i valori in modo lessicografico, quindi includerli in un elenco separato da virgole:

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

  10. Aggiungere un carattere di nuova riga (\n) dopo ogni coppia nome-valore.

Tenere presente le seguenti regole per la creazione della stringa di risorsa in forma canonica:

  • Evitare di usare il carattere di nuova riga (\n) nei valori per i parametri di query. Se è necessario usarlo, assicurarsi che non influisca sul formato della stringa di risorsa in forma canonica.

  • Evitare di usare virgole nei valori dei parametri di query.

Di seguito sono riportati alcuni esempi che illustrano la parte CanonicalizedResource della stringa di firma, come può essere creata da un URI di richiesta specificato:


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


Versione 2009-09-19 e successive del formato del servizio tabelle e della versione Lite della Chiave condivisa

Questo formato supporta l'autenticazione Chiave condivisa e Chiave condivisa versione Lite per tutte le versioni del servizio tabelle e Chiave condivisa versione Lite per la versione 2009-09-19 e successive dei servizi BLOB e di accodamento e per la versione 2014-02-14 e successive del servizio file. Questo formato è identico a quello usato con le versioni precedenti dei servizi di archiviazione. Creare la stringa CanonicalizedResource nel formato seguente:

  1. Da una stringa vuota (""), aggiungere una barra (/), seguita dal nome dell'account proprietario della risorsa a cui si desidera accedere.

  2. Aggiungere il percorso URI codificato della risorsa. Se l'URI della richiesta indirizza un componente della risorsa, aggiungere la stringa di query appropriata. La stringa di query deve includere il punto interrogativo e il parametro comp, ad esempio ?comp=metadata. Nessun altro parametro deve essere incluso nella stringa di query.

Per codificare la firma, chiamare l'algoritmo HMAC-SHA256 nella stringa di firma con codifica UTF-8 e codificare il risultato come Base 64. Usare il formato seguente (indicato come pseudocodice):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))
Mostra:
© 2016 Microsoft