Conceder acesso limitado aos recursos do Armazenamento do Azure com assinaturas de acesso partilhado (SAS)

Artigo
10/18/2023

Uma assinatura de acesso compartilhado (SAS) fornece acesso delegado seguro aos recursos em sua conta de armazenamento. Com uma SAS, você tem controle granular sobre como um cliente pode acessar seus dados. Por exemplo:

Quais recursos o cliente pode acessar.
Que permissões eles têm para esses recursos.
Por quanto tempo o SAS é válido.

Tipos de assinaturas de acesso partilhado

O Armazenamento do Azure dá suporte a três tipos de assinaturas de acesso compartilhado:

Delegação de usuários SAS
Serviço SAS
Conta SAS

Importante

Para cenários em que as assinaturas de acesso compartilhado 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, o que fornece segurança superior. Para obter mais informações sobre autorização para acesso a dados, consulte Autorizar acesso a dados no Armazenamento do Azure.

Delegação de usuários SAS

Uma SAS de delegação de usuário é protegida com credenciais do Microsoft Entra e também pelas permissões especificadas para a SAS. Uma SAS de delegação de usuário aplica-se somente ao armazenamento de Blob.

Para obter mais informações sobre a SAS de delegação de usuário, consulte Criar uma delegação de usuário SAS (REST API).

Serviço SAS

Uma SAS de serviço é protegida com a chave da conta de armazenamento. Um SAS de serviço delega acesso a um recurso em apenas um dos serviços de Armazenamento do Azure: armazenamento de Blob, armazenamento de filas, armazenamento de tabelas ou arquivos do Azure.

Para obter mais informações sobre o serviço SAS, consulte Criar um serviço SAS (REST API).

Conta SAS

Uma conta SAS é protegida com a chave de conta de armazenamento. Uma conta SAS delega o acesso aos recursos em um ou mais dos serviços de armazenamento. Todas as operações disponíveis através de um SAS de serviço ou delegação de usuário também estão disponíveis através de uma conta SAS.

Você também pode delegar acesso ao seguinte:

Operações de nível de serviço (por exemplo, as operações Get/set Service Properties e Get Service Stats ).
Leia, escreva e elimine operações que não são permitidas com uma SAS de serviço.

Para obter mais informações sobre a conta SAS, crie uma conta SAS (REST API).

Uma assinatura de acesso compartilhado pode assumir uma das duas formas a seguir:

SAS ad hoc. Quando você cria uma SAS ad hoc, a hora de início, a hora de expiração e as permissões são especificadas no URI da SAS. Qualquer tipo de SAS pode ser um SAS ad hoc.
SAS de serviço com política de acesso armazenado. Uma política de acesso armazenado é definida em um contêiner de recursos, que pode ser um contêiner de blob, tabela, fila ou compartilhamento de arquivos. A política de acesso armazenado pode ser usada para gerenciar restrições para uma ou mais assinaturas de acesso compartilhado de serviço. Quando você associa uma SAS de serviço a uma política de acesso armazenado, a SAS herda as restrições — a hora de início, a hora de expiração e as permissões — definidas para a política de acesso armazenado.

Nota

Uma SAS de delegação de usuário ou uma SAS de conta deve ser uma SAS ad hoc. Não há suporte para políticas de acesso armazenado para a SAS de delegação de usuário ou a SAS de conta.

Como funciona uma assinatura de acesso compartilhado

Uma assinatura de acesso compartilhado é um token anexado ao URI de um recurso de Armazenamento do Azure. O token que contém um conjunto especial de parâmetros de consulta que indicam como os recursos podem ser acessados pelo cliente. Um dos parâmetros de consulta, a assinatura, é construído a partir dos parâmetros SAS e assinado com a chave que foi usada para criar o SAS. Essa assinatura é usada pelo Armazenamento do Azure para autorizar o acesso ao recurso de armazenamento.

Nota

Não é possível auditar a geração de tokens SAS. Qualquer usuário que tenha privilégios para gerar um token SAS, usando a chave da conta ou por meio de uma atribuição de função do Azure, pode fazê-lo sem o conhecimento do proprietário da conta de armazenamento. Tenha cuidado para restringir as permissões que permitem que os usuários gerem tokens SAS. Para impedir que os usuários gerem uma SAS assinada com a chave de conta para cargas de trabalho de blob e fila, você pode não permitir o acesso de Chave Compartilhada à conta de armazenamento. Para obter mais informações, consulte Impedir autorização com chave compartilhada.

Assinatura e autorização SAS

Você pode assinar um token SAS com uma chave de delegação de usuário ou com uma chave de conta de armazenamento (Chave compartilhada).

Assinando um token SAS com uma chave de delegação de usuário

Você pode assinar um token SAS usando uma chave de delegação de usuário que foi criada usando credenciais do Microsoft Entra. Uma SAS de delegação de usuário é assinada com a chave de delegação do usuário.

Para obter a chave e, em seguida, criar a SAS, uma entidade de segurança do Microsoft Entra deve receber uma função do Azure que inclua a Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey ação. Para obter mais informações, consulte Criar uma delegação de usuário SAS (REST API).

Assinando um token SAS com uma chave de conta

Tanto uma SAS de serviço quanto uma SAS de conta são assinadas com a chave da conta de armazenamento. Para criar uma SAS assinada com a chave de conta, um aplicativo deve ter acesso à chave de conta.

Quando uma solicitação inclui um token SAS, essa solicitação é autorizada com base em como esse token SAS é assinado. A chave de acesso ou as credenciais que você usa para criar um token SAS também são usadas pelo Armazenamento do Azure para conceder acesso a um cliente que possui a SAS.

A tabela a seguir resume como cada tipo de token SAS é autorizado.

Tipo de SAS	Tipo de autorização
Delegação de usuário SAS (somente armazenamento de Blob)	Microsoft Entra ID
Serviço SAS	Chave Partilhada
Conta SAS	Chave Partilhada

A Microsoft recomenda o uso de uma SAS de delegação de usuário quando possível para segurança superior.

Token de SAS

O token SAS é uma cadeia de caracteres que você gera no lado do cliente, por exemplo, usando uma das bibliotecas de cliente do Armazenamento do Azure. O token SAS não é rastreado pelo Armazenamento do Azure de forma alguma. Você pode criar um número ilimitado de tokens SAS no lado do cliente. Depois de criar uma SAS, você pode distribuí-la para aplicativos cliente que exigem acesso a recursos em sua conta de armazenamento.

Os aplicativos cliente fornecem o URI SAS para o Armazenamento do Azure como parte de uma solicitação. Em seguida, o serviço verifica os parâmetros SAS e a assinatura para verificar se ela é válida. Se o serviço verificar se a assinatura é válida, a solicitação será autorizada. Caso contrário, a solicitação será recusada com o código de erro 403 (Proibido).

Aqui está um exemplo de um URI SAS de serviço, mostrando o URI do recurso, o caractere delimitador ('?') e o token SAS.

Diagrama mostrando os componentes de um URI de recurso com token SAS.

Nota

O caractere delimitador ('?') para a cadeia de caracteres de consulta não faz parte do token SAS. Se você gerar um token SAS do portal, PowerShell, CLI do Azure ou um dos SDKs de Armazenamento do Azure, talvez seja necessário acrescentar o caractere delimitador à URL do recurso.

Quando usar uma assinatura de acesso compartilhado

Use uma SAS para dar acesso seguro aos recursos em sua conta de armazenamento a qualquer cliente que, de outra forma, não tenha permissões para esses recursos.

Um cenário comum em que uma SAS é útil é um serviço em que os usuários leem e gravam seus próprios dados em sua conta de armazenamento. Num cenário em que uma conta de armazenamento armazene dados de utilizador, existem dois padrões de conceção típicos:

Os clientes carregam e transferem dados através de um serviço de proxy de front-end, o qual realiza a autenticação. Este serviço de proxy front-end permite a validação de regras de negócio. Mas para grandes quantidades de dados ou transações de alto volume, criar um serviço que possa ser dimensionado para atender à demanda pode ser caro ou difícil.
Um serviço simples autentica o cliente conforme necessário e, em seguida, gera uma SAS. Depois que o aplicativo cliente recebe a SAS, ele pode acessar os recursos da conta de armazenamento diretamente. As permissões de acesso são definidas pelo SAS e para o intervalo permitido pelo SAS. A SAS reduz a necessidade de encaminhamento de todos os dados através do serviço de proxy de front-end.

Muitos serviços do mundo real podem usar um híbrido dessas duas abordagens. Por exemplo, alguns dados podem ser processados e validados através do proxy front-end. Outros dados são salvos e/ou lidos diretamente usando o SAS.

Além disso, uma SAS é necessária para autorizar o acesso ao objeto de origem em uma operação de cópia em determinados cenários:

Quando você copia um blob para outro blob que reside em uma conta de armazenamento diferente.

Opcionalmente, você também pode usar uma SAS para autorizar o acesso ao blob de destino.
Quando você copia um arquivo para outro arquivo que reside em uma conta de armazenamento diferente.

Opcionalmente, você também pode usar uma SAS para autorizar o acesso ao arquivo de destino.
Quando você copia um blob para um arquivo ou um arquivo para um blob.

Você deve usar uma SAS mesmo que os objetos de origem e destino residam na mesma conta de armazenamento.

Práticas recomendadas ao usar SAS

Ao usar assinaturas de acesso compartilhado em seus aplicativos, você precisa estar ciente de dois riscos potenciais:

Se um SAS for vazado, ele pode ser usado por qualquer pessoa que o obtenha, o que pode comprometer sua conta de armazenamento.
Se uma SAS fornecida a um aplicativo cliente expirar e o aplicativo não conseguir recuperar uma nova SAS do seu serviço, a funcionalidade do aplicativo poderá ser prejudicada.

As seguintes recomendações para o uso de assinaturas de acesso compartilhado podem ajudar a reduzir esses riscos:

Sempre use HTTPS para criar ou distribuir uma SAS. Se uma SAS for passada sobre HTTP e intercetada, um invasor que executa um ataque man-in-the-middle é capaz de ler a SAS. Em seguida, eles podem usar esse SAS exatamente como o usuário pretendido poderia ter. Isso pode comprometer dados confidenciais ou permitir a corrupção de dados pelo usuário mal-intencionado.
Use uma SAS de delegação de usuário quando possível. Uma SAS de delegação de usuário fornece segurança superior a uma SAS de serviço ou uma SAS de conta. Uma SAS de delegação de usuário é protegida com credenciais do Microsoft Entra, para que você não precise armazenar sua chave de conta com seu código.
Tenha um plano de revogação em vigor para um SAS. Certifique-se de que está preparado para responder se um SAS for comprometido.
Configure uma política de expiração SAS para a conta de armazenamento. Uma política de expiração SAS especifica um intervalo recomendado durante o qual a SAS é válida. As políticas de expiração do SAS aplicam-se a um SAS de serviço ou a um SAS de conta. Quando um usuário gera uma SAS de serviço ou uma SAS de conta com um intervalo de validade maior do que o intervalo recomendado, ele verá um aviso. Se o log do Armazenamento do Azure com o Azure Monitor estiver habilitado, uma entrada será gravada nos logs do Armazenamento do Azure. Para saber mais, consulte Criar uma política de expiração para assinaturas de acesso compartilhado.
Crie uma política de acesso armazenado para uma SAS de serviço. As políticas de acesso armazenado oferecem a opção de revogar permissões para uma SAS de serviço sem ter que regenerar as chaves da conta de armazenamento. Defina a expiração neles muito longe no futuro (ou infinito) e certifique-se de que ele seja atualizado regularmente para movê-lo mais longe no futuro. Há um limite de cinco políticas de acesso armazenadas por contêiner.
Use tempos de expiração de curto prazo em um SAS de serviço SAS ad hoc ou SAS de conta. Desta forma, mesmo que um SAS seja comprometido, ele é válido apenas por um curto período de tempo. Essa prática é especialmente importante se você não puder fazer referência a uma política de acesso armazenada. Os tempos de expiração de curto prazo também limitam a quantidade de dados que podem ser gravados em um blob, limitando o tempo disponível para carregar nele.
Peça aos clientes que renovem automaticamente o SAS, se necessário. Os clientes devem renovar o SAS bem antes da expiração, a fim de dar tempo para novas tentativas se o serviço que fornece o SAS não estiver disponível. Isto pode ser desnecessário em alguns casos. Por exemplo, você pode pretender que o SAS seja usado para um pequeno número de operações imediatas e de curta duração. Espera-se que essas operações sejam concluídas dentro do período de expiração. Como resultado, você não está esperando que o SAS seja renovado. No entanto, se você tem um cliente que está rotineiramente fazendo solicitações via SAS, então a possibilidade de expiração entra em jogo.
Tenha cuidado com a hora de início do SAS. Se você definir a hora de início de uma SAS para a hora atual, as falhas podem ocorrer intermitentemente nos primeiros minutos. Isto é devido a máquinas diferentes com tempos de corrente ligeiramente diferentes (conhecido como inclinação do relógio). Em geral, defina a hora de início para ser de pelo menos 15 minutos no passado. Ou não o defina de todo, o que o tornará válido imediatamente em todos os casos. O mesmo geralmente se aplica ao tempo de expiração também - lembre-se de que você pode observar até 15 minutos de inclinação do relógio em qualquer direção em qualquer solicitação. Para clientes que usam uma versão REST anterior a 2012-02-12, a duração máxima de uma SAS que não faz referência a uma política de acesso armazenado é de 1 hora. Todas as políticas que especificarem um prazo superior a 1 hora falharão.
Tenha cuidado com o formato datetime SAS. Para alguns utilitários (como AzCopy), os valores de data/hora devem ser formatados como '+%Y-%m-%dT%H:%M:%SZ'. Este formato inclui especificamente os segundos.
Conceda o mínimo de privilégios possível com o SAS. Uma prática recomendada de segurança é fornecer a um usuário os privilégios mínimos necessários para o menor número possível de recursos. Use uma SAS somente leitura quando possível. Se um usuário precisar apenas de acesso de leitura a um único objeto, conceda-lhe acesso de leitura a esse único objeto e não acesso de leitura/gravação/exclusão a todos os objetos. Isso também ajuda a diminuir o dano se um SAS for comprometido porque o SAS tem menos poder nas mãos de um invasor.

Não há uma maneira direta de identificar quais clientes acessaram um recurso. No entanto, você pode usar os campos exclusivos no SAS, o IP assinado (sip), início assinado (st) e expiração assinada (se) para controlar o acesso. Por exemplo, você pode gerar um token SAS com um tempo de expiração exclusivo que pode ser correlacionado com o cliente para o qual ele foi emitido.
Entenda que sua conta será cobrada por qualquer uso, inclusive por meio de um SAS. Se você fornecer acesso de gravação a um blob, um usuário poderá optar por carregar um blob de 200 GB. Se você também lhes deu acesso de leitura, eles podem optar por baixá-lo 10 vezes, incorrendo em 2 TB em custos de saída para você. Novamente, forneça permissões limitadas para ajudar a mitigar as ações potenciais de usuários mal-intencionados. Use SAS de curta duração para reduzir essa ameaça (mas esteja atento à distorção do relógio na hora de término).
Valide dados gravados usando uma SAS. Quando um aplicativo cliente grava dados em sua conta de armazenamento, lembre-se de que pode haver problemas com esses dados. Se você planeja validar dados, execute essa validação depois que os dados forem gravados e antes de serem usados pelo seu aplicativo. Essa prática também protege contra dados corrompidos ou maliciosos sendo gravados em sua conta, seja por um usuário que adquiriu corretamente o SAS, ou por um usuário que explora um SAS vazado.
Saiba quando não usar um SAS. Às vezes, os riscos associados a uma operação específica em relação à sua conta de armazenamento superam os benefícios do uso de uma SAS. Para essas operações, crie um serviço de camada intermediária que grave em sua conta de armazenamento depois de executar a validação, autenticação e auditoria de regras de negócios. Além disso, às vezes é mais simples gerenciar o acesso de outras maneiras. Por exemplo, se você quiser tornar todos os blobs em um contêiner publicamente legíveis, poderá torná-lo público, em vez de fornecer uma SAS a cada cliente para acesso.
Use o Azure Monitor e os logs do Armazenamento do Azure para monitorar seu aplicativo. Falhas de autorização podem ocorrer devido a uma interrupção no serviço do provedor SAS. Eles também podem ocorrer a partir de uma remoção inadvertida de uma política de acesso armazenado. Você pode usar o Azure Monitor e o log de análise de armazenamento para observar qualquer pico nesses tipos de falhas de autorização. Para obter mais informações, consulte Métricas do Armazenamento do Azure no Azure Monitor e no log do Azure Storage Analytics.
Configure uma política de expiração SAS para a conta de armazenamento. As práticas recomendadas recomendam que você limite o intervalo para uma SAS caso ela seja comprometida. Ao definir uma política de expiração SAS para suas contas de armazenamento, você pode fornecer um limite máximo de expiração recomendado quando um usuário cria uma SAS de serviço ou uma SAS de conta. Para obter mais informações, consulte Criar uma política de expiração para assinaturas de acesso compartilhado.

Nota

O armazenamento não monitoriza o número de assinaturas de acesso partilhadas que foram geradas para uma conta de armazenamento e nenhuma API pode fornecer este detalhe. Se você precisar saber o número de assinaturas de acesso compartilhado que foram geradas para uma conta de armazenamento, deverá rastrear o número manualmente.

Introdução ao SAS

Para começar a usar assinaturas de acesso compartilhado, consulte os seguintes artigos para cada tipo de SAS.

Partilhar via

Conceder acesso limitado aos recursos do Armazenamento do Azure com assinaturas de acesso partilhado (SAS)