Autorizar com chave compartilhada

Artigo
11/18/2024

Cada solicitação feita em 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 é usar a Chave Compartilhada, descrita neste artigo.

Importante

Para obter a segurança ideal, a Microsoft recomenda usar a ID do Microsoft Entra com identidades gerenciadas para autorizar solicitações contra dados de blob, fila e tabela, sempre que possível. A autorização com a ID do Microsoft Entra e identidades gerenciadas fornece segurança superior e facilidade de uso sobre a 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, 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, consulte 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 as credenciais do Microsoft Entra em vez da chave da conta. Para saber mais sobre assinaturas de acesso compartilhado, consulte Criar 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 Blob, Fila e Serviços de Arquivos. 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 maior segurança e exige 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 Lite de Chave Compartilhada para fazer solicitações nos serviços blob, fila, tabela e arquivo. Não há suporte para Lite de Chave Compartilhada 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 Lite de Chave Compartilhada dá suporte ao uso de uma cadeia de caracteres de assinatura idêntica ao que foi suportado em relação à Chave Compartilhada em versões anteriores dos serviços blob e fila. Portanto, você pode usar a Chave Compartilhada 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 dá suporte a HTTP e HTTPS, mas o uso de HTTPS é altamente recomendado.

Nota

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 Acesso de delegado 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 HTTP/HTTPS Date 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 quando chegar ao serviço. Isso protege contra certos ataques de segurança, incluindo ataques de repetição. Quando essa verificação falha, o servidor retorna o código de resposta 403 (Proibido).

Nota

O cabeçalho x-ms-date é fornecido porque algumas bibliotecas e proxies de cliente HTTP 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 de autorização

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 foi 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>"

em que SharedKey ou SharedKeyLite é o nome do esquema de autorização, AccountName é o nome da conta que solicita o recurso e Signature é um HMAC (Código de Autenticação de Mensagem baseado em Hash) construído a partir da solicitação e computado usando o algoritmo SHA256 e codificado usando a codificação Base64.

Nota

É possível solicitar um recurso que resida abaixo de uma conta diferente, se esse recurso estiver 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 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 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 algum 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 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 cabeçalho x-ms-date for especificado, você poderá ignorar o cabeçalho Date, independentemente de ele ser 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 Construir a cadeia de caracteres de cabeçalhos canônicos seção para adicionar o cabeçalho x-ms-date.

É 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 são necessários dentro da cadeia de caracteres de assinatura.
A cadeia de caracteres de assinatura inclui cabeçalhos canônicos e cadeias de caracteres de recurso canônicas. A canonização dessas cadeias de caracteres as coloca em um formato padrão reconhecido pelo Armazenamento do Azure. Para obter informações detalhadas sobre como construir as cadeias de caracteres CanonicalizedHeaders e CanonicalizedResource que compõem parte da cadeia de caracteres de assinatura, consulte as seções apropriadas mais adiante neste tópico.

Blob, Fila e Serviços de Arquivos (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 a 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 anterior, 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 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 quebra de 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 na 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 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 seus cabeçalhos de Authorization existentes para usar a Chave Compartilhada Lite em vez de Chave Compartilhada. O formato de assinatura exigido pelo Shared Key Lite é idêntico ao necessário para a Chave Compartilhada por versões dos serviços blob e fila antes de 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 primário, 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 parte Content-Length do StringToSign como 0. Normalmente, essa 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 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 nas 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 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 no 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 é ligeiramente diferente daquela de uma solicitação no serviço Blob ou Fila, pois ela não inclui a parte CanonicalizedHeaders da cadeia de caracteres. Além disso, o cabeçalho Date nesse caso nunca estará vazio mesmo se a solicitação definir o cabeçalho x-ms-date. Se os conjuntos de solicitação x-ms-date, esse valor também será usado para o valor do cabeçalho Date.

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

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

Nota

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 Definir 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 do Lite de Chave Compartilhada)

Você pode usar a autorização do Lite de Chave Compartilhada para autorizar uma solicitação feita na versão 2009-09-19 e posterior dos serviços blob e fila e versão 2014-02-14 e posterior dos serviços de Arquivo. Não há suporte para Lite de Chave Compartilhada para blobs de página premium.

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 de colocar 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 de Chave Compartilhada Lite)

Você pode usar a autorização Lite de Chave Compartilhada 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 a Chave Compartilhada Lite, use o seguinte formato:

StringToSign = Date + "\n"
               CanonicalizedResource

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

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 canônicos

Para construir a parte CanonicalizedHeaders da cadeia de caracteres de assinatura, siga 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 letras minúsculas.
Classifique os cabeçalhos lexicograficamente por nome de cabeçalho, em ordem crescente. Cada cabeçalho pode aparecer apenas uma vez na cadeia de caracteres.

Nota

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 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.

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

O seguinte mostra um exemplo de uma cadeia de caracteres de cabeçalhos canônicos:

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

Nota

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

Construindo a cadeia de caracteres de recurso canônica

O CanonicalizedResource parte 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 com suporte para a cadeia de caracteres CanonicalizedResource:

Um formato que dá suporte à autorização de Chave Compartilhada 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 arquivo.
Um formato que dá suporte à Chave Compartilhada e à Chave Compartilhada Lite para todas as versões do serviço Tabela e à Chave Compartilhada Lite para a versão 2009-09-19 e posterior dos serviços de Blob e Fila. Esse formato é idêntico ao usado com versões anteriores dos serviços de armazenamento.

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

Serviço blob: contêineres de nomenclatura e referência, blobs e metadados
Serviço fila: endereçando recursos do serviço fila
Serviço tabela: endereçando recursos de serviço de tabela
Serviço de arquivo: compartilhamentos, diretórios, arquivos e 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 de –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.

Nota

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 em serviços de armazenamento do Azure, o nome da conta será exibido apenas uma vez na cadeia de caracteres CanonicalizedResource.

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 arquivo. 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 que possui o recurso que está sendo acessado.
Acrescente o caminho de URI codificado do recurso, sem parâmetros de consulta.
Recupere todos os parâmetros de consulta no URI do recurso, incluindo o parâmetro comp se ele existir.
Converta todos os nomes de parâmetro em letras minúsculas.
Classifique os parâmetros de consulta lexicograficamente pelo nome do parâmetro, em ordem crescente.
Decodificar URL de cada nome e valor do parâmetro de consulta.
Inclua um caractere de nova linha (\n) antes de cada par nome-valor.
Acrescente 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írgulas:

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 canônica:

Evite usar o caractere de nova linha (\n) em valores para parâmetros de consulta. Se ele precisar ser usado, verifique se ele não afeta o formato da cadeia de caracteres de recurso canônica.
Evite usar vírgulas em valores de parâmetro 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 de Tabela e Chave Compartilhada para 2009-09-19 e posterior

Esse formato dá suporte à Chave Compartilhada e à Chave Compartilhada Lite para todas as versões do serviço Tabela e à Chave Compartilhada Lite para a versão 2009-09-19 e posterior dos serviços blob e fila e versão 2014-02-14 e posterior do serviço Arquivo. 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 que possui o recurso que está sendo acessado.
Acrescente o caminho de URI codificado do recurso. Se o URI de 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 a chave da conta de armazenamento do Base64. Use o seguinte formato (mostrado como pseudocódigo):

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

Consulte também

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

Compartilhar via

Autorizar com chave compartilhada

Especificando o cabeçalho Date

Especificando o cabeçalho de autorização

Construindo a cadeia de caracteres de assinatura

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

Cabeçalho content-length na versão 2014-02-14 e anterior

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

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

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

Construindo a cadeia de caracteres de cabeçalhos canônicos

Construindo a cadeia de caracteres de recurso canônica

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

Formato de serviço de Tabela e Chave Compartilhada para 2009-09-19 e posterior

Codificando a assinatura

Consulte também

Recursos adicionais