Autorizar com chave compartilhada

Artigo
11/18/2024

Toda solicitação feita em relação a um serviço de armazenamento deve ser autorizada, 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 uma segurança ideal, a Microsoft recomenda o uso do 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 ID do Microsoft Entra e identidades gerenciadas oferece segurança superior e facilidade de uso em relação à autorização de chave compartilhada. Para saber mais, consulte Autorizar com o Microsoft Entra ID. Para saber mais sobre identidades gerenciadas, consulte 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, os aplicativos executados em servidores habilitados para Azure Arc podem usar identidades gerenciadas para se conectar aos serviços do Azure. Para saber mais, consulte Autenticar em recursos do Azure com servidores habilitados para Azure Arc.

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

Os serviços Blob, Fila, Tabela e Arquivo suportam os 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 versão 2014-02-14 e posterior (para o serviço de Arquivo):

Chave compartilhada para serviços de 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 oferece suporte a uma cadeia de caracteres de assinatura aumentada para segurança aprimorada e requer que você atualize seu serviço para autorizar o uso dessa assinatura aumentada.
Chave compartilhada para o serviço de 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.
Chave compartilhada Lite. Use o esquema de autorização Shared Key Lite para fazer solicitações nos serviços Blob, Fila, Tabela e Arquivo. O Shared Key Lite não é suportado para blobs de página premium.

Para a versão 2009-09-19 e posterior dos serviços de Blob e Fila, a autorização do Shared Key Lite suporta o uso de uma cadeia de caracteres de assinatura idêntica à que era suportada contra a Chave Compartilhada em versões anteriores dos serviços de Blob e Fila. Portanto, você pode usar o Shared Key Lite para fazer solicitações nos serviços de Blob e Fila sem atualizar sua cadeia de caracteres de assinatura.

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

Importante

O Armazenamento do Azure suporta 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. Consulte Delegar acesso com uma assinatura de acesso compartilhado para obter mais detalhes.

Especificando o cabeçalho Data

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 de x-ms-date será usado como o tempo de criação da solicitação.

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

Observação

O cabeçalho x-ms-date é fornecido porque algumas bibliotecas de cliente HTTP e proxies definem automaticamente o cabeçalho Date 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, construa a assinatura com um valor vazio para o cabeçalho Date.

Especificando o cabeçalho Authorization

Uma solicitação autorizada deve incluir o cabeçalho Authorization. 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 tenha sido fornecida para acesso delegado.

Para autorizar uma solicitação, você deve assinar a solicitação com a chave da 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 de autenticação de mensagem baseado em hash (HMAC) construído a partir da solicitação e calculado usando o algoritmo SHA256 e, em seguida, codificado usando a codificação Base64.

Observação

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

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 qual esquema de autorização você está usando. Ao construir a cadeia de caracteres de assinatura, tenha em mente o seguinte:

A parte VERB da 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 qualquer cabeçalho for 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 dos cabeçalhos. Esses cabeçalhos podem estar vazios se não estiverem sendo especificados como parte da solicitação; nesse caso, apenas o caractere de nova linha é necessário.
Se o cabeçalho x-ms-date for especificado, você poderá ignorar o cabeçalho Date, independentemente de ele estar especificado na solicitação, e simplesmente especificar uma linha vazia para a parte Date da cadeia de caracteres de assinatura. Nesse caso, siga as instruções na seção Construindo a cadeia de caracteres de cabeçalhos canonicalizados para adicionar o cabeçalho x-ms-date.

É aceitável especificar tanto x-ms-date como 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 são necessários dentro da cadeia de caracteres de assinatura.
A cadeia de caracteres de assinatura inclui cabeçalhos canonicalizados e cadeias de caracteres de recursos canonicalizados. A canonização dessas 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 mais adiante neste tópico.

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

Para codificar a cadeia de caracteres de assinatura de Chave Compartilhada para uma solicitação na versão 2009-09-19 e posterior do serviço Blob ou Fila e na versão 2014-02-14 e posterior do serviço de 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 deve 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 mais informações sobre o comportamento antigo.

O exemplo a seguir mostra uma cadeia de caracteres de assinatura para uma operação Get Blob. Onde não há 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 divisão dessa 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 codificada em 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 de Blob e Fila, você deve atualizar seu código para usar essa cadeia de caracteres de assinatura aumentada.

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

Importante

Se você estiver acessando o local secundário em uma conta de armazenamento para a qual a replicação geográfica de acesso de leitura (RA-GRS) está habilitada, 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 anteriores

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

Por exemplo, para a solicitação a seguir, o valor do cabeçalho Content-Length é 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 forma:

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

Considerando que nas versões posteriores a 2014-02-14, o StringToSign deve conter uma string 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 de 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 Chave Compartilhada em relação ao serviço Tabela é o mesmo 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 para uma solicitação no serviço Blob ou Fila, pois não inclui a parte CanonicalizedHeaders da cadeia de caracteres. Além disso, o cabeçalho Date neste caso nunca está vazio, mesmo que a solicitação defina o cabeçalho x-ms-date. Se a solicitação definir x-ms-date, esse valor também será usado para o valor do cabeçalho Date.

Para codificar a cadeia de caracteres de assinatura de uma solicitação em relação ao serviço Tabela feita usando 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 requer que todas as chamadas REST incluam os cabeçalhos DataServiceVersion e MaxDataServiceVersion. Consulte Definindo os cabeçalhos de versão do OData Data Service para obter mais informações.

Serviços de Blob, Fila e Arquivo (autorização Shared Key Lite)

Você pode usar a autorização do Shared Key Lite para autorizar uma solicitação feita na versão 2009-09-19 e posterior dos serviços Blob e Queue e na versão 2014-02-14 e posterior dos serviços de arquivo. O Shared Key Lite não é suportado para blobs de página premium.

A cadeia de caracteres de assinatura do Shared Key Lite é idêntica à cadeia de assinatura necessária para a autorização de Chave Compartilhada em versões dos serviços de Blob e Fila anteriores a 2009-09-19. Portanto, se você deseja migrar seu código com o menor número de alterações para a versão 2009-09-19 dos serviços de Blob e Fila, você pode modificar seu código para usar o Shared Key Lite, sem alterar a cadeia de caracteres de assinatura em si. Ao usar o Shared Key Lite, você não obterá a funcionalidade de segurança aprimorada fornecida pelo uso da Shared Key com a versão 2009-09-19 e posterior.

Para codificar a cadeia de caracteres de assinatura de 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 Put Blob. Observe que a linha de cabeçalho Content-MD5 está vazia. Os cabeçalhos mostrados na cadeia de caracteres são pares nome-valor que especificam valores de metadados personalizados 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

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Serviço de tabela (autorização Shared Key Lite)

Você pode usar a autorização do Shared Key Lite para autorizar uma solicitação feita contra qualquer versão do serviço Tabela.

Para codificar a cadeia de caracteres de assinatura de uma solicitação no serviço Tabela usando o 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 Create Table .

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 canonicalizados

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

Recupere todos os cabeçalhos do recurso que começam com x-ms-, incluindo o cabeçalho x-ms-date.
Converta cada nome de cabeçalho HTTP em minúsculas.
Classifique os cabeçalhos lexicograficamente pelo nome do cabeçalho, em ordem crescente. Cada cabeçalho pode aparecer apenas uma vez na cadeia de caracteres.

Observação

de ordenação lexicográfica pode nem sempre coincidir com a ordem alfabética convencional.
Substitua qualquer espaço em branco linear no valor do cabeçalho por um único espaço.

O espaço em branco linear inclui retorno de carro/alimentação de linha (CRLF), 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.

Corte qualquer espaço em branco ao redor dos dois pontos no cabeçalho.
Finalmente, acrescente um caractere de nova linha a cada cabeçalho canonicalizado na lista resultante. Construa a cadeia de CanonicalizedHeaders concatenando todos os cabeçalhos desta lista em uma única cadeia de caracteres.

A seguir mostra um exemplo de uma cadeia de caracteres de cabeçalhos canonicalizada:

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. Estes agora são representados em CanonicalizedHeaders imediatamente após o caractere de dois pontos com a nova linha de terminação.

Construindo a cadeia de caracteres de recurso canonicalizada

A parte CanonicalizedResource da cadeia de caracteres de assinatura representa o recurso de serviços de armazenamento direcionado pela solicitação. Qualquer parte da cadeia de caracteres CanonicalizedResource derivada do URI do recurso deve ser codificada exatamente como está no URI.

Há dois formatos suportados para a cadeia de CanonicalizedResource:

Um formato que suporta a autorização de Chave Partilhada para a versão 2009-09-19 e posterior dos serviços de Blob e Fila e para a versão 2014-02-14 e posterior do serviço de Ficheiros.
Um formato que suporta Shared Key e Shared Key Lite para todas as versões do serviço Table e Shared Key Lite para a versão 2009-09-19 e posterior dos serviços Blob e Queue. Esse formato é idêntico ao usado com versões anteriores dos serviços de armazenamento.

Para obter ajuda na construção do URI para o recurso que você está acessando, consulte um dos seguintes tópicos:

Serviço de Blob: nomeando e referenciando contêineres, blobs e de metadados
Serviço de fila: de recursos do serviço de fila de endereçamento
Serviço de tabela: de recursos de serviço de tabela de endereçamento
Serviço de arquivo: nomeando e referenciando compartilhamentos, diretórios, arquivos e de metadados

Importante

Se sua conta de armazenamento for replicada com replicação geográfica de acesso de leitura (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 da cadeia de caracteres CanonicalizedResource deve ser o URI do recurso no local primário.

Observação

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

Formato de chave partilhada para 2009-09-19 e posteriores

Este formato suporta a autorização de Chave Partilhada para a versão 2009-09-19 e posterior dos serviços de Blob e Fila e para a versão 2014-02-14 e posterior dos serviços de Ficheiro. Construa a cadeia de caracteres CanonicalizedResource neste formato da seguinte maneira:

Começando com uma cadeia de caracteres vazia (""), acrescente uma barra (/), seguida pelo nome da conta proprietária do recurso que está sendo acessado.
Anexe o caminho de URI codificado do recurso, sem quaisquer parâmetros de consulta.
Recupere todos os parâmetros de consulta no URI do recurso, incluindo o parâmetro comp, se existir.
Converta todos os nomes de parâmetros em minúsculas.
Classifique os parâmetros de consulta lexicograficamente por nome de parâmetro, em ordem crescente.
URL-decodificar o nome e o valor de cada parâmetro de consulta.
Inclua um caractere de nova linha (\n) antes de cada par nome-valor.
Anexe o nome e o valor de cada parâmetro de consulta à cadeia de caracteres no seguinte formato, certificando-se de incluir os dois pontos (:) entre o nome e o valor:

parameter-name:parameter-value
Se um parâmetro de consulta tiver mais de um valor, classifique todos os valores lexicograficamente e inclua-os em uma lista separada por vírgula:

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

Tenha em mente as seguintes regras para construir a cadeia de caracteres de recurso canonicalizada:

Evite usar o caractere de nova linha (\n) em valores para parâmetros de consulta. Se ele deve ser usado, certifique-se de que ele não afeta o formato da cadeia de caracteres de recurso canonicalizado.
Evite usar vírgulas em valores de parâmetros de consulta.

Aqui estão alguns exemplos que mostram a parte CanonicalizedResource 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 Shared Key Lite and Table para 2009-09-19 e posterior

Este formato suporta Shared Key e Shared Key Lite para todas as versões do serviço Table e Shared Key Lite para a versão 2009-09-19 e posterior dos serviços Blob e Queue e versão 2014-02-14 e posterior do serviço File. Esse formato é idêntico ao usado com versões anteriores dos serviços de armazenamento. Construa a cadeia de caracteres CanonicalizedResource neste formato da seguinte maneira:

Começando com uma cadeia de caracteres vazia (""), acrescente uma barra (/), seguida pelo nome da conta proprietária do recurso que está sendo acessado.
Anexe o caminho de URI codificado do recurso. Se o URI da solicitação abordar um componente do 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 de consulta.

Codificando a assinatura

Para codificar a assinatura, chame o algoritmo HMAC-SHA256 na cadeia de caracteres de assinatura codificada em UTF-8 e codifique o resultado como Base64. Observe que você também precisa decodificar Base64-decodificar 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>)))

Partilhar via

Autorizar com chave compartilhada

Especificando o cabeçalho Data

Especificando o cabeçalho Authorization

Construindo a cadeia de caracteres de assinatura

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

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

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

Serviços de Blob, Fila e Arquivo (autorização Shared Key Lite)

Serviço de tabela (autorização Shared Key Lite)

Construindo a cadeia de caracteres de cabeçalhos canonicalizados

Construindo a cadeia de caracteres de recurso canonicalizada

Formato de chave partilhada para 2009-09-19 e posteriores

Formato de serviço Shared Key Lite and Table para 2009-09-19 e posterior

Codificando a assinatura

Ver também

Recursos adicionais