Conceder acesso limitado aos recursos de Armazenamento do Azure usando assinaturas de acesso compartilhado (SAS)
Uma assinatura de acesso compartilhado (SAS) fornece acesso delegado protegido aos recursos da 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.
Quais as permissões que eles têm para esses recursos.
Por quanto tempo a SAS é válida.
Tipos de assinaturas de acesso compartilhado
O Armazenamento do Azure dá suporte a três tipos de assinaturas de acesso compartilhado:
SAS de delegação do usuário
SAS de serviço
SAS de Conta
SAS de delegação do usuário
Uma SAS de delegação do usuário é protegida com as credenciais do Microsoft Entra e também pelas permissões especificadas para a SAS. Uma SAS de delegação do usuário se aplica somente ao armazenamento de blobs.
Para obter mais informações sobre a SAS de delegação do usuário, consulte Criar uma SAS de delegação de usuário de (API REST).
SAS de serviço
Uma SAS de serviço é protegida com a chave da conta de armazenamento. Uma SAS de serviço delega acesso a um recurso em apenas um dos serviços de Armazenamento do Azure: armazenamento de blobs, armazenamento de filas, armazenamento de tabelas ou arquivos do Azure.
Para obter mais informações sobre a SAS de serviço, consulte Criar um serviço SAS (API REST).
SAS de Conta
Uma SAS de conta é protegida com a chave da conta de armazenamento. Uma SAS de conta delega acesso a recursos em um ou mais dos serviços de armazenamento. Todas as operações disponíveis através de uma SAS de serviço ou de delegação do usuário também estão disponíveis por meio de uma SAS de conta.
Também é possível delegar acesso ao seguinte:
Operações de nível de serviço (por exemplo, as operações de Obter/Definir Propriedades do Serviço e Obter estatística do serviço ).
Operações de leitura, gravação e exclusão que não são permitidas com uma SAS de serviço.
Para obter mais informações sobre a SAS de conta, consulte Criar uma SAS de conta (API REST).
Observação
A Microsoft recomenda que você use as credenciais do Microsoft Entra quando possível como uma prática recomendada de segurança, em vez de usar a chave da conta, que pode ser comprometida com mais facilidade. Quando o design do aplicativo exigir assinaturas de acesso compartilhado para acesso ao armazenamento de Blobs, use as credenciais do Microsoft Entra para criar uma SAS de delegação do usuário, quando possível, para maior segurança. Para saber mais, confira Autorizar o acesso a dados no Armazenamento do Azure.
Uma assinatura de acesso compartilhado pode assumir uma destas duas formas:
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 uma SAS ad hoc.
SAS de serviço com política de acesso armazenada. Uma política de acesso armazenada é definida em um contêiner de recurso, que pode ser um contêiner de blobs, tabela, fila ou compartilhamento de arquivos. Uma política de acesso armazenada pode ser usada para gerenciar as restrições de uma ou mais assinaturas de serviço de acesso compartilhado. Quando você associa uma SAS de serviço a uma política de acesso armazenada, 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 armazenada.
Observação
Uma SAS de delegação de usuário ou uma SAS de conta deve ser uma SAS ad hoc. As políticas de acesso armazenadas não têm suporte para a SAS de delegação do usuário ou a SAS de conta.
Como funciona uma assinatura de acesso compartilhado
Uma assinatura de acesso compartilhado é um token que é acrescentado ao URI de um recurso do 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 desses parâmetros de consulta, a assinatura, é construído a partir dos parâmetros da SAS e assinado com a chave de conta. Esta assinatura é usada pelo armazenamento do Azure para autorizar o acesso ao recurso de armazenamento.
Observação
Não é possível auditar a geração de tokens SAS. Qualquer usuário que tenha privilégios para gerar um token SAS, seja usando a chave de conta ou por meio de uma atribuição de uma função do Azure, pode fazê-lo sem o conhecimento do proprietário da conta de armazenamento. Tenha cuidado ao restringir as permissões que permitem aos usuários gerar 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, é possível impedir acesso de chave compartilhada à conta de armazenamento. Para obter mais informações, consulte Impedir autorização com chave compartilhada.
Assinatura e autorização SAS
É possível 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
É possível assinar um token SAS usando uma chave de delegação de usuário criada usando as credenciais do Microsoft Entra. Uma SAS de delegação do 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 ser atribuída a uma função do Azure que inclui a ação Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey. Para obter mais informações, consulte Criar uma SAS de delegação do usuário (API REST).
Assinar um token SAS com uma chave de conta
Uma SAS de serviço e uma SAS de conta são assinadas com a chave de 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, ela é autorizada com base em como o 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 possua a SAS.
A tabela a seguir resume como cada tipo de token SAS é autorizado.
| Tipo de SAS | Tipo de autorização |
|---|---|
| SAS de delegação de usuário (somente armazenamento de blobs) | ID do Microsoft Entra |
| SAS de serviço | Chave compartilhada |
| SAS de Conta | Chave compartilhada |
A Microsoft recomenda usar uma SAS de delegação de usuário quando possível para maior segurança.
Token SAS
O token SAS é uma cadeia de caracteres que você gera no lado do cliente, por exemplo, usando uma das bibliotecas de cliente de 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, é possível distribuí-la aos aplicativos cliente que exigem acesso aos recursos em sua conta de armazenamento.
Os aplicativos cliente fornecem o URI da SAS para o Armazenamento do Azure como parte de uma solicitação. Em seguida, o serviço verifica os parâmetros da SAS e a assinatura para verificar se eles são válidos. Se o serviço verificar que 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).
Veja a seguir um exemplo de um URI da SAS de serviço, mostrando o URI do recurso, o caractere delimitador (“?”) e o token SAS.
Observação
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, do PowerShell, da CLI do Azure ou de 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 fornecer acesso seguro aos recursos em sua conta de armazenamento para qualquer cliente que não tenha permissões para esses recursos.
Um cenário comum em que uma SAS é útil é um serviço onde os usuários leem e gravam seus próprios dados na sua conta de armazenamento. Em um cenário em que uma conta de armazenamento armazena dados do usuário, há dois padrões de design comuns:
Os clientes carregam e baixam dados por meio de um serviço de proxy front-end, que executa a autenticação. Esse serviço de proxy de front-end tem a vantagem de permitir a validação de regras de negócios. Mas, para grandes quantidades de dados ou transações de alto volume, criar um serviço que pode ser dimensionado para corresponder a demanda pode ser caro ou difícil.
Um serviço leve autentica o cliente conforme necessário e 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 pela SAS e para o intervalo permitido pela SAS. A SAS reduz a necessidade de roteamento de todos os dados por meio do serviço de proxy front-end.
Muitos serviços reais podem usar uma combinação dessas duas abordagens. Por exemplo, alguns dados podem ser processados e validados por meio do proxy de front-end. Outros dados são salvos e/ou lidos diretamente usando SAS.
Além disso, será necessário usar uma SAS para autorizar 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.
Outra opção é usar uma SAS para também autorizar acesso ao blob de destino.
Quando você copia um arquivo para outro arquivo que reside em uma conta de armazenamento diferente.
Outra opção é usar uma SAS para também autorizar acesso ao arquivo de destino.
Quando você copia um blob para um arquivo ou um arquivo para um blob.
É necessário 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 nos seus aplicativos, você precisará estar ciente de dois riscos possíveis:
Se ocorrer perda de uma SAS, ela poderá ser usada por qualquer pessoa que a obtiver, o que poderá comprometer a sua conta de armazenamento.
Se uma SAS fornecida para 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 recomendações a seguir para usar assinaturas de acesso compartilhado podem ajudar a atenuar esses riscos:
Sempre use HTTPS para criar ou distribuir uma SAS. Se uma SAS é transmitida por HTTP e interceptada, um invasor que executa um ataque man-in-the-middle pode lê-la. Em seguida, ele pode usar essa SAS da mesma forma que o usuário pretendido. Isso pode comprometer potencialmente dados confidenciais ou permitir dados corrompidos 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 maior segurança a uma SAS de serviço ou a uma SAS de conta. Uma SAS de delegação de usuário é protegida com as 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 uma SAS. Verifique se você está preparado para responder se uma SAS está comprometida.
Configure uma política de expiração de SAS para a conta de armazenamento. Uma política de expiração de SAS especifica um intervalo recomendado durante o qual a SAS é válida. As políticas de expiração de SAS se aplicam a uma SAS de serviço ou a uma SAS de conta. Quando um usuário gera uma SAS de serviço ou uma SAS de conta com um intervalo de validade maior que o intervalo recomendado, ele verá um aviso. Se o log de Armazenamento do Microsoft Azure com Azure Monitor estiver habilitado, uma entrada será gravada nos logs de Armazenamento do Microsoft Azure. Para saber mais, consulte Criar uma política de expiração para assinaturas de acesso compartilhado.
Crie uma política de acesso armazenada para uma SAS de serviço. As políticas de acesso armazenadas permitem que você revogue permissões de serviço SAS sem precisar regenerar as chaves de conta de armazenamento. Defina o vencimento para um momento muito distante no futuro (ou infinito) e certifique-se de que ela seja atualizada regularmente para uma data ainda mais além no futuro. Há um limite de cinco políticas de acesso armazenadas por contêiner.
Use tempos de expiração de curto prazo em uma SAS do serviço SAS ad hoc ou SAS da conta. Dessa forma, mesmo se uma SAS for comprometida, ela será válida apenas por um breve período. Esta prática será especialmente importante se você não puder fazer referência a uma política de acesso armazenada. Períodos de vencimento breves também limitam a quantidade de dados que podem ser gravados em um blob, limitando o tempo disponível para carregá-los.
Faça com que os clientes renovem a SAS automaticamente, se necessário. Os clientes devem renovar a SAS bem antes da expiração, para que haja tempo para novas tentativas, caso o serviço que fornece a SAS não esteja disponível. Isso pode ser desnecessário em alguns casos. Por exemplo, é possível pretender que a SAS seja usada 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 a SAS seja renovada. No entanto, se você tiver um cliente que esteja sempre fazendo solicitações via SAS, surge a possibilidade de expiração.
Tenha cuidado com a hora de início da SAS. Se você definir a hora de início de uma SAS como a hora atual, poderão ocorrer falhas intermitentemente pelos primeiros minutos. Isso ocorre devido a diferentes máquinas que têm tempos de corrente ligeiramente diferentes (conhecidos como distorção de relógio). Em geral, defina a hora de início para pelo menos 15 minutos no passado. Ou então, simplesmente não a defina, o que a tornará imediatamente válida em todos os casos. Em geral, o mesmo também se aplica à hora de vencimento – lembre-se de que pode haver até 15 minutos de defasagem horária em um dos dois sentidos em qualquer solicitação. Para clientes que usam uma versão de 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 armazenada é de uma hora. Todas as políticas que especificam um período maior que uma hora falharão.
Tenha cuidado com o formato de data e hora da SAS. Para alguns utilitários (como AzCopy), os valores de data/hora devem ser formatados como '+%Y-%m-%dT%H:%M:%SZ'. Esse formato inclui, especificamente, os segundos.
Conceda os mínimos privilégios possíveis com a SAS. Uma melhor prática de segurança consiste em fornecer 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 só precisar ter o acesso de leitura em um objeto, permita o acesso de leitura nesse objeto e não o acesso de leitura/gravação/exclusão em todos os objetos. Isso também ajuda a reduzir o dano caso uma SAS seja comprometida, pois a SAS terá 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, os campos IP assinado (
sip), início assinado (st) e expiração assinada (se) para acompanhar o acesso. Por exemplo, você pode gerar um token SAS com um tempo de expiração exclusivo, que você pode correlacionar com o cliente para o qual ele foi emitido.É importante que você entenda que a sua conta será cobrada por qualquer uso, incluindo por meio da 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 tiver concedido o acesso de leitura, será possível baixá-la 10 vezes, incorrendo em 2 TB de custos de saída. Como mencionado, forneça permissões limitadas para ajudar a reduzir a ações em potencial de usuários mal-intencionados. Use SAS de curta duração para reduzir essa ameaça (mas, tenha cuidado com a defasagem horária na hora de término).
Valide os dados gravados com a SAS. Quando um aplicativo cliente gravar dados na sua conta de armazenamento, tenha em mente de que poderá haver problemas com esses dados. Se você planeja validar dados, execute essa validação depois de os dados serem gravados e antes de serem usados pelo seu aplicativo. Essa prática também protegerá contra dados corrompidos ou mal-intencionados que estiverem sendo gravados na sua conta por um usuário que adquiriu a SAS de forma adequada ou por um usuário que estiver explorando uma SAS vazada.
Saiba quando não usar uma SAS. Às vezes, os riscos associados a uma determinada operação em relação à sua conta de armazenamento superam os benefícios de usar uma SAS. Para essas operações, crie um serviço de camada intermediária que grave na sua conta de armazenamento após a validação, a autenticação e a auditoria da regra de negócio. Além disso, algumas vezes é mais simples de gerenciar o acesso de outras maneiras. Por exemplo, se quiser tornar todos os blobs de um contêiner publicamente legíveis, você poderá tornar o contêiner Público, em vez de fornecer uma SAS para o acesso de cada cliente.
Use logs de Armazenamento do Azure e do Azure Monitor para monitorar seu aplicativo. Podem ocorrer falhas de autorização devido a uma interrupção no serviço do provedor de SAS. Eles também podem ocorrer a partir de uma remoção inadvertida de uma política de acesso armazenada. É possível usar o Azure Monitor e o log da análise de armazenamento para observar qualquer pico nesses tipos de falhas de autorização. Para obter mais informações, consulte Métricas de Armazenamento do Azure nos logs do Azure monitor e de análise de Armazenamento do Azure.
Configure uma política de expiração de SAS para a conta de armazenamento. As melhores práticas recomendam que você limite o intervalo de uma SAS em caso de comprometimento. Ao definir uma política de expiração de SAS para as contas de armazenamento, você poderá fornecer um limite de expiração superior recomendado quando um usuário criar uma SAS de serviço ou uma SAS de conta. Para obter mais informações, confira Criar uma política de expiração para assinaturas de acesso compartilhado.
Observação
O armazenamento não rastreia o número de assinaturas de acesso compartilhado que foram geradas para uma conta de armazenamento e nenhuma API pode fornecer esse detalhe. Se precisar saber o número de assinaturas de acesso compartilhado que foram geradas para uma conta de armazenamento, é necessário controlar o número manualmente.
Introdução à SAS
Para começar a usar as assinaturas de acesso compartilhado, consulte os artigos a seguir para cada tipo de SAS.
SAS de delegação do usuário
- Criar uma SAS de delegação de usuário para um contêiner ou blob com o PowerShell
- Criar uma SAS de delegação de usuário para um contêiner ou blob com o CLI do Azure
- Criar uma SAS de delegação de usuário para um contêiner ou blob com .NET