O uso de Shared Access Signatures (SAS) é uma prática comum para delegar acesso temporário e escopado a recursos do Azure Storage, eliminando a necessidade de expor account keys (chaves de conta). No entanto, o paradigma tradicional de SAS sempre trouxe um desafio inerente: uma vez gerado, o token é, por natureza, desvinculado de uma identidade específica. Quem detém o token, detém o acesso.
Para elevar o nível de segurança, a Microsoft anunciou a public preview da user-bound user delegation SAS. Esta funcionalidade permite que um token SAS seja restrito a uma identidade específica do Microsoft Entra ID (antigo Azure AD). Para times de engenharia e arquitetos de nuvem, essa é uma mudança tática importante, pois reforça o princípio do least privilege e melhora a auditabilidade do acesso a dados.
O Impacto Técnico
Até hoje, o User Delegation (UD) SAS permitia que usuários recuperassem uma chave delegada atrelada à sua identidade Entra ID para gerar tokens com validade máxima de 7 dias. O novo modelo de user-bound adiciona uma camada de verificação: o delegator (quem gera o token) especifica o security principal do usuário final. Consequentemente, para consumir esse token, o usuário final não apenas precisa possuir a string do token, mas também autenticar-se via Entra ID utilizando a identidade que foi vinculada ao momento da criação.
Essa abordagem mitiga drasticamente o risco de vazamento de tokens em logs ou repositórios de código, já que o token por si só é insuficiente para acessar o recurso sem a prova de identidade do usuário vinculado. O suporte a cenários cross-tenant também está presente, facilitando a colaboração externa mantendo o controle de acesso, desde que a configuração allowCrossTenantDelegationSas esteja devidamente habilitada no nível da conta de armazenamento.
Considerações Práticas e Implementação
Esta funcionalidade está disponível em todas as contas de armazenamento GPv2 nas regiões públicas. Não há custos adicionais pela adoção da policy de vinculação; o modelo de precificação permanece atrelado às transações de read/write padrão do Azure Storage.
Para implementar essa estratégia, o fluxo de trabalho exige atenção especial às RBAC roles:
- Permissões: O delegator deve possuir as roles apropriadas (Storage Service Data Contributor e Storage Service Delegator).
- Coleta de IDs: O processo exige a obtenção do OAuth object ID e do tenant ID do usuário final.
- Geração: Na criação do token, é necessário injetar esses campos no momento da construção da SAS string.
Pontos de Atenção:
- Integração: Certifique-se de que suas aplicações que consomem esses tokens estão integradas corretamente aos SDKs que suportam essa validação.
- Governança: A recomendação best practice continua sendo passar esses tokens via Key Vault ou através do fluxo de autenticação da aplicação, automatizando a gestão para evitar manipulação manual de strings.
Para times que operam em escala e com alta sensibilidade a dados, esta é a evolução natural do controle de acesso no Azure. A transição para tokens vinculados a identidades é um passo indispensável para reduzir ataques de movimentação lateral e garantir que a superfície de exposição seja mínima.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
