Autorizar com Chave Compartilhada

Todas as solicitações feitas em um serviço de armazenamento devem ser autorizadas, a menos que a solicitação seja para um recurso de blob ou contêiner que tenha sido disponibilizado para acesso público ou assinado. Uma opção para autorizar uma solicitação é usando a Chave Compartilhada, descrita neste artigo.

Importante

Para obter a segurança ideal, a Microsoft recomenda usar Microsoft Entra ID com identidades gerenciadas para autorizar solicitações contra dados de blob, fila e tabela, sempre que possível. A autorização com Microsoft Entra ID e identidades gerenciadas fornece segurança superior e facilidade de uso em relação à autorização de Chave Compartilhada. Para saber mais, confira Autorizar com Microsoft Entra ID. Para saber mais sobre identidades gerenciadas, confira O que são identidades gerenciadas para recursos do Azure.

Para recursos hospedados fora do Azure, como aplicativos locais, você pode usar identidades gerenciadas por meio do Azure Arc. Por exemplo, aplicativos em execução em servidores habilitados para Azure Arc podem usar identidades gerenciadas para se conectar aos serviços do Azure. Para saber mais, confira Autenticar em recursos do Azure com servidores habilitados para Azure Arc.

Para cenários em que as SAS (assinaturas de acesso compartilhado) são usadas, a Microsoft recomenda usar uma SAS de delegação de usuário. Uma SAS de delegação de usuário é protegida com Microsoft Entra credenciais em vez da chave de conta. Para saber mais sobre assinaturas de acesso compartilhado, consulte Create uma SAS de delegação de usuário.

Os serviços Blob, Fila, Tabela e Arquivo dão suporte aos seguintes esquemas de autorização de chave compartilhada para a versão 2009-09-19 e posterior (para o serviço Blob, Fila e Tabela) e a versão 2014-02-14 e posterior (para o serviço Arquivo):

• Chave Compartilhada para serviços Blob, Fila e Arquivo. Use o esquema de autorização de chave compartilhada para fazer solicitações nos serviços Blob, Fila e Arquivo. A autorização de chave compartilhada na versão 2009-09-19 e posterior dá suporte a uma cadeia de caracteres de assinatura aumentada para segurança aprimorada e exige que você atualize seu serviço para autorizar o uso dessa assinatura aumentada.

• Chave Compartilhada para o serviço Tabela. Use o esquema de autorização de chave compartilhada para fazer solicitações no serviço Tabela usando a API REST. A autorização de chave compartilhada para o serviço Tabela na versão 2009-09-19 e posterior usa a mesma cadeia de caracteres de assinatura que nas versões anteriores do serviço Tabela.

• Shared Key Lite. Use o esquema de autorização Lite de Chave Compartilhada para fazer solicitações nos serviços Blob, Fila, Tabela e Arquivo.

  Para a versão 2009-09-19 e posterior dos serviços blob e fila, a autorização de Chave Compartilhada Lite dá suporte ao uso de uma cadeia de caracteres de assinatura idêntica ao que era compatível com a Chave Compartilhada em versões anteriores dos serviços Blob e Fila. Assim, você pode usar a Shared Key Lite para fazer solicitações nos serviços Blob e Fila, sem atualizar a cadeia de caracteres da assinatura.

Uma solicitação autorizada requer dois cabeçalhos: o Date cabeçalho ou x-ms-date e o Authorization cabeçalho . As seções a seguir descrevem como construir esses cabeçalhos.

Importante

O Armazenamento do Azure dá suporte a HTTP e HTTPS, mas o uso de HTTPS é altamente recomendado.

Observação

Um contêiner ou blob pode ser disponibilizado para acesso público definindo as permissões de um contêiner. Para obter mais informações, consulte Gerenciar o acesso aos recursos de armazenamento do Azure. Um contêiner, blob, fila ou tabela pode ser disponibilizado para acesso assinado por meio de uma assinatura de acesso compartilhado; uma assinatura de acesso compartilhado é autorizada por meio de um mecanismo diferente. Confira Delegar acesso com uma assinatura de acesso compartilhado para obter mais detalhes.

Especificando o cabeçalho Date

Todas as solicitações autorizadas devem incluir o carimbo de data/hora UTC (Tempo Universal Coordenado) para a solicitação. Você pode especificar o carimbo de data/hora no cabeçalho x-ms-date ou no cabeçalho Date HTTP/HTTPS padrão. Se ambos os cabeçalhos forem especificados na solicitação, o valor x-ms-date será usado como a hora de criação da solicitação.

Os serviços de armazenamento garantem que uma solicitação não tenha mais de 15 minutos antes de atingir o serviço. Isso protege contra certos ataques de segurança, incluindo ataques de reprodução. Quando essa verificação falha, o servidor retorna o código de resposta 403 (Proibido).

Observação

O x-ms-date cabeçalho é fornecido porque algumas bibliotecas de cliente HTTP e proxies definem automaticamente o Date cabeçalho e não dão ao desenvolvedor a oportunidade de ler seu valor para incluí-lo na solicitação autorizada. Se você definir x-ms-date, criará a assinatura com um valor vazio para o cabeçalho Date.

Especificando o cabeçalho authorization

Uma solicitação autorizada deve incluir o Authorization cabeçalho . Se esse cabeçalho não estiver incluído, a solicitação será anônima e só terá êxito em um contêiner ou blob marcado para acesso público ou em um contêiner, blob, fila ou tabela para o qual uma assinatura de acesso compartilhado foi fornecida para acesso delegado.

Para autorizar uma solicitação, você deve assinar a solicitação com a chave para a conta que está fazendo a solicitação e passar essa assinatura como parte da solicitação.

O formato do cabeçalho Authorization é o seguinte:

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

onde SharedKey ou SharedKeyLite é o nome do esquema de autorização, AccountName é o nome da conta que solicita o recurso e Signature é um código HMAC (Hash-based Message Authentication Code) construído com base na solicitação e computado com o uso do algoritmo SHA256 e codificado na Base64.

Observação

É possível solicitar um recurso que resida sob uma conta diferente, se esse recurso estiver publicamente acessível.

As seções a seguir descrevem como construir o cabeçalho Authorization.

Construindo a cadeia de caracteres de assinatura

A forma como você constrói a cadeia de caracteres de assinatura depende de qual serviço e versão você está autorizando e em qual esquema de autorização você está usando. Ao construir a cadeia de caracteres de assinatura, tenha em mente o seguinte:

• A parte VERB de cadeia de caracteres é o verbo HTTP, como GET ou PUT, e deve ser maiúscula.

• Para autorização de chave compartilhada para os serviços blob, fila e arquivo, cada cabeçalho incluído na cadeia de caracteres de assinatura pode aparecer apenas uma vez. Se um cabeçalho estiver duplicado, o serviço retornará o código de status 400 (Solicitação Incorreta).

• Os valores de todos os cabeçalhos HTTP padrão devem ser incluídos na cadeia de caracteres na ordem mostrada no formato de assinatura, sem os nomes de cabeçalho. Esses cabeçalhos poderão estar vazios se não estiverem sendo especificados como parte da solicitação; nesse caso, somente o caractere de nova linha é necessário.

• Se o x-ms-date cabeçalho for especificado, você poderá ignorar o Date cabeçalho, independentemente de ele ser especificado na solicitação e simplesmente especificar uma linha vazia para a Date parte da cadeia de caracteres de assinatura. Nesse caso, siga as instruções na seção Construindo a cadeia de caracteres de cabeçalhos canônicos para adicionar o x-ms-date cabeçalho.

  É aceitável especificar x-ms-date e Date; nesse caso, o serviço usa o valor de x-ms-date.

• Se o cabeçalho x-ms-date não for especificado, especifique o cabeçalho Date na cadeia de caracteres de assinatura, sem incluir o nome do cabeçalho.

• Todos os caracteres de nova linha (\n) mostrados devem estar dentro da cadeia de caracteres da assinatura.

• A cadeia de caracteres da assinatura inclui cabeçalhos canonizado e cadeias de caracteres de recurso canonizadas. Canonizar estas cadeias de caracteres as coloca em um formato padrão que é reconhecido pelo Armazenamento do Azure. Para obter informações detalhadas sobre como construir as cadeias de caracteres CanonicalizedHeaders e CanonicalizedResource que fazem parte da cadeia de caracteres de assinatura, consulte as seções apropriadas posteriormente neste tópico.

Blob, Fila e Serviços de Arquivos (autorização de chave compartilhada)

Para codificar a cadeia de caracteres da assinatura de Chave Compartilhada para uma solicitação na versão 2009-09-19 e posterior ou superior do serviço Blob ou Fila e versão 2014-02-14 e posterior do serviço Arquivo, use o seguinte formato:

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;  

Importante

Na versão atual, o campo Content-Length deverá ser uma cadeia de caracteres vazia se o comprimento do conteúdo da solicitação for zero. Na versão 2014-02-14 e anteriores, o comprimento do conteúdo foi incluído mesmo que zero. Veja abaixo para obter mais informações sobre o comportamento antigo.

O exemplo a seguir mostra uma cadeia de caracteres de assinatura para uma operação Obter Blob . Quando não há nenhum valor de cabeçalho, o caractere de nova linha é especificado apenas.

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  

A análise disso linha por linha mostra cada parte da mesma cadeia de caracteres:

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*/  

Em seguida, codifique essa cadeia de caracteres usando o algoritmo HMAC-SHA256 sobre a cadeia de caracteres de assinatura com codificação UTF-8, construa o cabeçalho Authorization e adicione o cabeçalho à solicitação. O exemplo a seguir mostra o cabeçalho Authorization para a mesma operação:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Para usar a autorização de chave compartilhada com a versão 2009-09-19 e posterior dos serviços blob e fila, você deve atualizar seu código para usar essa cadeia de caracteres de assinatura aumentada.

Se você preferir migrar seu código para a versão 2009-09-19 ou posterior dos serviços Blob e Fila com o menor número possível de alterações, poderá modificar os cabeçalhos existentes Authorization para usar a Chave Compartilhada Lite em vez da Chave Compartilhada. O formato de assinatura necessário para a Shared Key Lite é idêntico ao necessário para a Chave Compartilhada por versões dos serviços Blob e Fila anteriores à versão 2009-09-19.

Importante

Se você estiver acessando o local secundário em uma conta de armazenamento para os quais o acesso de leitura à replicação geográfica (RA-GRS) está habilitado, não inclua a designação -secondary no cabeçalho de autorização. Para fins de autorização, o nome da conta é sempre o nome do local principal, mesmo para acesso secundário.

Cabeçalho Content-Length na versão 2014-02-14 e anterior

Ao usar a versão 2014-02-14 ou anterior, se Content-Length for zero, defina a Content-Length parte do StringToSign como 0. Normalmente, essa seria uma cadeia de caracteres vazia.

Por exemplo, para a solicitação a seguir, o valor do Content-Length cabeçalho é incluído no StringToSign mesmo quando é zero.

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

O StringToSign é construído da seguinte maneira:

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

Enquanto em versões posteriores a 2014-02-14, o StringToSign deve conter uma cadeia de caracteres vazia para 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

Serviço tabela (autorização de chave compartilhada)

Você deve usar a autorização de Chave Compartilhada para autorizar uma solicitação feita no serviço Tabela se o serviço estiver usando a API REST para fazer a solicitação. O formato da cadeia de caracteres de assinatura para a Chave Compartilhada no serviço Tabela é igual para todas as versões.

A cadeia de caracteres de assinatura de Chave Compartilhada para uma solicitação no serviço Tabela difere ligeiramente daquela de uma solicitação em relação ao serviço Blob ou Fila, pois não inclui a CanonicalizedHeaders parte da cadeia de caracteres. Além disso, o cabeçalho Date nesse caso nunca fica vazio, mesmo que a solicitação defina o cabeçalho x-ms-date. Se a solicitação definir x-ms-date, esse valor será usado também para o valor do cabeçalho Date.

Para codificar a cadeia de caracteres de assinatura para uma solicitação no serviço Tabela feita com a API REST, use o seguinte formato:

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

Observação

A partir da versão 2009-09-19, o serviço Tabela exige que todas as chamadas REST incluam os cabeçalhos DataServiceVersion e MaxDataServiceVersion. Consulte Configurando os cabeçalhos de versão do serviço de dados OData para obter mais informações.

Serviços de Blob, Fila e Arquivo (autorização de Chave Compartilhada Lite)

Você pode usar a autorização Lite de Chave Compartilhada para autorizar uma solicitação feita na versão 2009-09-19 e posterior dos serviços de Blob e Fila e versão 2014-02-14 e posterior dos serviços de Arquivo.

A cadeia de caracteres de assinatura para a Chave Compartilhada Lite é idêntica à cadeia de caracteres de assinatura necessária para autorização de Chave Compartilhada em versões dos serviços blob e fila antes de 2009-09-19. Portanto, se você quiser migrar seu código com o menor número de alterações para a versão 2009-09-19 dos serviços blob e fila, poderá modificar seu código para usar a Chave Compartilhada Lite, sem alterar a própria cadeia de caracteres de assinatura. Usando a Chave Compartilhada Lite, você não obterá a funcionalidade de segurança aprimorada fornecida usando a Chave Compartilhada com a versão 2009-09-19 e posterior.

Para codificar a cadeia de caracteres de assinatura para uma solicitação no serviço Blob ou Fila, use o seguinte formato:

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

O exemplo a seguir mostra uma cadeia de caracteres de assinatura para uma operação Colocar Blob . Observe que a linha de cabeçalho Content-MD5 está vazia. Os cabeçalhos mostrados na cadeia de caracteres são os pares de nome-valor que especificam valores personalizados de metadados para o novo 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  

Em seguida, codifique essa cadeia de caracteres usando o algoritmo HMAC-SHA256 sobre a cadeia de caracteres de assinatura com codificação UTF-8, construa o cabeçalho Authorization e adicione o cabeçalho à solicitação. O exemplo a seguir mostra o cabeçalho Authorization para a mesma operação:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  

Serviço de tabela (autorização de Chave Compartilhada Lite)

Você pode usar a autorização de Chave Compartilhada Lite para autorizar uma solicitação feita em qualquer versão do serviço Tabela.

Para codificar a cadeia de caracteres de assinatura para uma solicitação no serviço Tabela usando Shared Key Lite, use o seguinte formato:

StringToSign = Date + "\n"
               CanonicalizedResource  

O exemplo a seguir mostra uma cadeia de caracteres de assinatura para uma operação de tabela de Create.

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

Em seguida, codifique essa cadeia de caracteres usando o algoritmo HMAC-SHA256, construa o cabeçalho Authorization e adicione o cabeçalho à solicitação. O exemplo a seguir mostra o cabeçalho Authorization para a mesma operação:

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

Construindo a cadeia de caracteres de cabeçalhos canonizados

Para construir a parte CanonicalizedHeaders de cadeia de caracteres de assinatura, siga estas etapas:

1. Recupere todos os cabeçalhos para o recurso que começam com x-ms-, incluindo o cabeçalho x-ms-date.

2. Converta cada nome de cabeçalho HTTP em minúsculas.

3. Classifique os cabeçalhos de modo lexicográfico pelo nome do cabeçalho, em ordem crescente. Cada cabeçalho pode aparecer apenas uma vez na cadeia de caracteres.

   Observação

   A ordenação lexicográfica pode nem sempre coincidir com a ordenação alfabética convencional.

4. Substitua qualquer espaço em branco linear no valor do cabeçalho por um único espaço.

O espaço em branco linear inclui CRLF (retorno de carro/alimentação de linha), espaços e guias. Consulte RFC 2616, seção 4.2 para obter detalhes. Não substitua nenhum espaço em branco dentro de uma cadeia de caracteres entre aspas.

1. Corte qualquer espaço em branco ao redor dos dois-pontos no cabeçalho.

2. Finalmente, acrescente um caractere de nova linha para cada cabeçalho canonizado na lista resultante. Construa a cadeia de caracteres CanonicalizedHeaders concatenando todos os cabeçalhos nessa lista em uma única cadeia de caracteres.

A seguir é exibido um exemplo de cadeia de caracteres dos cabeçalhos canonizados:

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

Observação

Antes da versão de serviço 2016-05-31, cabeçalhos com valores vazios eram omitidos da cadeia de caracteres de assinatura. Eles agora são representados em CanonicalizedHeaders seguindo imediatamente o caractere de dois-pontos com a nova linha de terminação.

Construindo a cadeia de caracteres de recurso canonizada

A parte CanonicalizedResource da cadeia de caracteres de assinatura representa o recurso de serviços de armazenamento de destino da solicitação. Qualquer parte da cadeia de caracteres de CanonicalizedResource que seja derivada do URI do recurso deverá ser codificada exatamente como em seu URI.

Há dois formatos com suporte para a cadeia de caracteres de CanonicalizedResource:

• Um formato que dá suporte à autorização de Chave Compartilhada para a versão 2009-09-19 e posterior dos serviços blob e fila e para a versão 2014-02-14 e posterior do serviço arquivo.

• Um formato que oferece suporte à Chave Compartilhada e à Shared Key Lite para todas as versões do serviço Tabela, e Shared Key Lite para a versão 2009-09-19 e posterior dos serviços Blob e Fila. Esse formato é idêntico àquele usado com as versões anteriores dos serviços de armazenamento.

Para obter ajuda ao construir o URI do recurso que você está acessando, consulte um dos seguintes tópicos:

• Serviço blob: nomeando e referenciando contêineres, blobs e metadados

• Serviço de fila: Endereçando recursos do serviço fila

• Serviço de tabela: Endereçando recursos de serviço de tabela

• Serviço de arquivo: nomenclatura e referência de compartilhamentos, diretórios, arquivos e metadados

Importante

Se sua conta de armazenamento é replicada com acesso de leitura à replicação geográfica (RA-GRS) e você estiver acessando um recurso no local secundário, não inclua a designação –secondary na cadeia de caracteres CanonicalizedResource. O URI do recurso usado no URI de cadeia de caracteres CanonicalizedResource deve ser o URI do recurso no local principal.

Observação

Se você estiver autorizando no emulador de armazenamento, o nome da conta aparecerá duas vezes na CanonicalizedResource cadeia de caracteres. Isso é esperado. Se você estiver autorizando em serviços de armazenamento do Azure, o nome da conta aparecerá apenas uma vez na CanonicalizedResource cadeia de caracteres.

Formato de chave compartilhada para 2009-09-19 e posterior

Esse formato dá suporte à autorização de Chave Compartilhada para a versão 2009-09-19 e posterior dos serviços blob e fila e a versão 2014-02-14 e posterior dos serviços de arquivos. Construa a cadeia de caracteres de CanonicalizedResource nesse formato, da seguinte maneira:

1. Comece com uma cadeia de caracteres vazia (""), acrescente uma barra (/), seguida pelo nome da conta que tem o recurso sendo acessado.

2. Acrescente o caminho do URI codificado do recurso, sem nenhum parâmetro de consulta.

3. Recupere todos os parâmetros de consulta no URI de recurso, incluindo o parâmetro comp, se existir.

4. Converta todos os nomes de parâmetro em minúsculas.

5. Classifique os parâmetros de consulta de modo lexicográfico pelo nome do parâmetro, em ordem crescente.

6. Decodifique com URL todos os nomes e valores de parâmetro de consulta.

7. Inclua um caractere de nova linha (\n) antes de cada par nome-valor.

8. Acrescente cada nome e valor de parâmetro de consulta à cadeia de caracteres no seguinte formato, certificando-se incluir os dois-pontos (:) entre o nome e o valor:

   parameter-name:parameter-value

9. Se um parâmetro de consulta tiver mais de um valor, classifique todos os valores de modo lexicográfico e inclua-os em uma lista separada por vírgulas:

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

Lembre-se das seguintes regras para construir a cadeia de caracteres de recurso canonizado:

• Evite usar o caractere de nova linha (\n) nos valores de parâmetros de consulta. Se for necessário usá-lo, verifique se não afeta o formato da cadeia de caracteres de recurso canonizado.

• Evite usar vírgulas em valores de parâmetro de consulta.

Aqui estão alguns exemplos que mostram a CanonicalizedResource parte da cadeia de caracteres de assinatura, pois ela pode ser construída a partir de um determinado URI de solicitação:

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

Formato de serviço chave compartilhada Lite e Tabela para 2009-09-19 e posterior

Este formato que oferece suporte à Chave Compartilhada e à Shared Key Lite para todas as versões do serviço Tabela e Shared Key Lite para a versão 2009-09-19 e posterior dos serviços Blob e Fila e para a versão 2014-02-14 e posterior do serviço Arquivo. Esse formato é idêntico àquele usado com as versões anteriores dos serviços de armazenamento. Construa a cadeia de caracteres de CanonicalizedResource nesse formato, da seguinte maneira:

1. Comece com uma cadeia de caracteres vazia (""), acrescente uma barra (/), seguida pelo nome da conta que tem o recurso sendo acessado.

2. Acrescente o caminho de URI codificado do recurso. Se o URI da solicitação abordar um componente de recurso, acrescente a cadeia de caracteres de consulta apropriada. A cadeia de caracteres de consulta deve incluir o ponto de interrogação e o parâmetro comp (por exemplo, ?comp=metadata). Nenhum outro parâmetro deve ser incluído na cadeia de caracteres da consulta.

Codificando a assinatura

Para codificar a assinatura, chame o algoritmo HMAC-SHA256 na cadeia de caracteres de assinatura de com codificação UTF-8 codificar o resultado na Base64. Observe que você também precisa decodificar base64 sua chave de conta de armazenamento. Use o seguinte formato (mostrado como pseudocódigo):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))  

Confira também

• API REST do serviço Blob
• API REST do serviço Fila
• API REST de Serviço Tabela
• REST dos Serviços de Armazenamento