Fundamentação Teórica: Manage access keys
1. Intuição Inicial
Pense em um cofre de banco. Você pode dar a alguém o direito de acessar o cofre de duas formas diferentes. A primeira: cadastrá-lo no sistema do banco, vinculado à sua identidade, com permissões específicas e log de cada acesso. A segunda: dar a ele uma cópia da chave física do cofre. Com a chave física, ele não precisa se identificar no sistema, não há log vinculado à sua identidade, e se ele perder a chave ou der uma cópia para alguém, você não sabe.
No Azure, as access keys (chaves de acesso) são exatamente a "chave física do cofre". São credenciais compartilhadas que concedem acesso completo a um serviço, sem identidade vinculada, sem granularidade de permissão e sem rastreabilidade de quem fez o quê.
O principal serviço que usa access keys no contexto do AZ-104 é o Azure Storage Account: toda conta de armazenamento tem duas chaves de acesso que, quando apresentadas, concedem controle total sobre todos os dados e configurações da conta.
2. Contexto
As access keys existem porque, antes do modelo de identidade baseado em Entra ID (RBAC e DataActions), era a única forma de autenticar acesso programático a serviços Azure. Aplicações precisavam de credenciais para acessar storage, e as access keys foram a solução inicial.
Hoje, com o Entra ID evoluído, as access keys são consideradas um mecanismo legado e menos seguro, mas ainda amplamente presentes em ambientes reais por motivos de compatibilidade e simplicidade.
As access keys são o ponto de partida para entender dois outros mecanismos: as SAS tokens (Shared Access Signatures) e a migração para autenticação baseada em identidade. Para o AZ-104, o foco está em entender as access keys, gerenciá-las com segurança e conhecer o processo de rotação.
3. Construção dos Conceitos
3.1 O Que São as Access Keys do Storage Account
Cada Storage Account tem sempre duas chaves de acesso: key1 e key2. Ambas têm exatamente o mesmo nível de permissão: acesso completo a tudo no storage account, sem exceção.
A existência de duas chaves não é para ter dois níveis de acesso. É para permitir a rotação sem downtime: você pode atualizar suas aplicações para usar a nova chave antes de invalidar a antiga, garantindo continuidade de serviço durante o processo de rotação.
Cada chave é uma string Base64 longa, como:
dGhpcyBpcyBhIHN0b3JhZ2Uga2V5IGV4YW1wbGU=...
Quem tiver essa string pode fazer qualquer operação na conta de storage: ler, escrever, excluir dados, criar containers, modificar configurações, gerar SAS tokens, tudo.
3.2 Connection Strings
Uma connection string é uma string que encapsula o nome da conta de storage e a access key em um formato conveniente para configuração de aplicações:
DefaultEndpointsProtocol=https;AccountName=minhaconta;AccountKey=<access-key>;EndpointSuffix=core.windows.net
É o equivalente de uma URL + credencial em uma única string. Muitas aplicações e frameworks esperam a connection string diretamente (Azure Functions, Azure Storage SDKs, etc.). A connection string exposta é equivalente a expor a access key diretamente.
3.3 Shared Access Signatures (SAS)
As SAS tokens (Shared Access Signatures) são credenciais derivadas das access keys, mas com escopo e prazo definidos. Elas merecem destaque porque são geradas a partir das access keys e seu ciclo de vida está vinculado a elas.
Uma SAS token tem:
- Permissões específicas: apenas leitura, apenas escrita, etc.
- Escopo específico: apenas um container, apenas um blob, apenas filas
- Prazo de validade: expira em uma data e hora definidas
- Restrições de IP (opcional): só pode ser usada de determinados IPs
Ponto crítico: quando você rotaciona (regenera) uma access key, todas as SAS tokens geradas a partir daquela chave são imediatamente invalidadas, mesmo que ainda estejam dentro do prazo de validade. Isso porque a SAS é matematicamente derivada da chave; sem a chave original, ela é inválida.
3.4 Tipos de SAS
Existem três tipos de SAS, relevantes para o AZ-104:
| Tipo | Base | Características | Quando usar |
|---|---|---|---|
| Account SAS | Access key | Escopo: todo o storage account ou serviços específicos (blob, file, queue, table) | Acesso amplo temporário a múltiplos serviços |
| Service SAS | Access key | Escopo: um serviço específico (ex: apenas blob) com permissões definidas | Acesso temporário a um serviço específico |
| User Delegation SAS | Credencial Entra ID | Não usa access key; usa identidade do usuário Entra ID para gerar | Abordagem moderna e recomendada; não depende das access keys |
O User Delegation SAS é importante porque representa a evolução: você pode ter a conveniência de uma SAS (escopo, expiração) sem depender das access keys. Para gerar um User Delegation SAS, o usuário precisa ter o papel Storage Blob Data Contributor ou Storage Blob Delegator.
3.5 Controle de Acesso às Access Keys
Por padrão, qualquer usuário com o papel Contributor ou Owner em um Storage Account pode visualizar as access keys. Isso é um risco: o plano de controle (RBAC) e o plano de dados (acesso via key) não estão completamente separados por padrão.
O Azure tem uma configuração chamada "Allow storage account key access" que, quando desabilitada, impede que as access keys sejam usadas para autenticação no storage account. Isso força o uso exclusivo de autenticação baseada em Entra ID.
4. Visão Estrutural
5. Funcionamento na Prática
Ciclo de Vida das Access Keys
Processo de Rotação Sem Downtime
A rotação de access keys sem interrupção de serviço segue uma sequência específica que aproveita a existência das duas chaves:
Por que essa ordem importa? Se você regenerar a chave que as aplicações estão usando sem primeiro migrar para a outra, todas as chamadas ao storage falharão imediatamente, pois a connection string ou token das aplicações contém a chave antiga que agora é inválida.
Comportamentos Importantes e Não Óbvios
Regenerar a key1 invalida todas as SAS Account e Service geradas a partir da key1. Se você tinha SAS tokens ativas com validade de 30 dias geradas a partir da key1, todas se tornam inválidas instantaneamente após a regeneração. Isso pode causar falhas em sistemas que usam SAS sem que ninguém perceba a conexão.
O portal mostra apenas as primeiras letras da chave por segurança: ao visualizar as access keys no portal, você precisa clicar em "Show" para ver a chave completa. Cada visualização é registrada no Activity Log, o que é um rastro de auditoria importante.
A rotação automática via Key Vault: o Azure Key Vault pode armazenar as access keys e configurar rotação automática programada. Quando a rotação ocorre, o Key Vault regenera automaticamente a chave no storage account e atualiza o segredo armazenado no Key Vault. Aplicações que buscam a chave do Key Vault em vez de tê-la embutida no código recebem automaticamente a nova versão.
6. Formas de Implementação
6.1 Portal do Azure
Quando usar: visualização manual, rotação pontual, emergência.
Caminho: Storage Account > Security + networking > Access keys
Nessa tela você pode:
- Ver key1 e key2 (clicando em "Show" para revelar)
- Copiar a chave ou a connection string
- Clicar em "Rotate key" para regenerar key1 ou key2
Vantagens: imediato, sem configuração adicional, útil para resposta a incidentes.
Limitações: manual, não escalável para múltiplos storage accounts, cada visualização é logada individualmente.
6.2 Azure CLI
Visualizar access keys:
az storage account keys list \
--account-name minhaconta \
--resource-group rg-producao \
--output table
Regenerar key1:
az storage account keys renew \
--account-name minhaconta \
--resource-group rg-producao \
--key key1
Regenerar key2:
az storage account keys renew \
--account-name minhaconta \
--resource-group rg-producao \
--key key2
Obter connection string (já com a chave embutida):
az storage account show-connection-string \
--account-name minhaconta \
--resource-group rg-producao \
--output tsv
Vantagens: scriptável, pode ser integrado a pipelines de rotação.
Limitações: a chave fica visível no output do terminal e no histórico de comandos.
6.3 PowerShell
Visualizar access keys:
Get-AzStorageAccountKey `
-ResourceGroupName "rg-producao" `
-Name "minhaconta"
Regenerar key1:
New-AzStorageAccountKey `
-ResourceGroupName "rg-producao" `
-Name "minhaconta" `
-KeyName "key1"
Obter connection string:
$key = (Get-AzStorageAccountKey `
-ResourceGroupName "rg-producao" `
-Name "minhaconta")[0].Value
$connectionString = "DefaultEndpointsProtocol=https;AccountName=minhaconta;AccountKey=$key;EndpointSuffix=core.windows.net"
6.4 Rotação Automática via Azure Key Vault
Esta é a abordagem mais segura e recomendada para produção. O Key Vault armazena a access key como um segredo e pode configurar rotação automática:
Configurar rotação automática via CLI:
# Adicionar a key como segredo no Key Vault
az keyvault secret set \
--vault-name meu-keyvault \
--name "storage-account-key1" \
--value $(az storage account keys list \
--account-name minhaconta \
--resource-group rg-producao \
--query "[0].value" -o tsv)
# Configurar rotação automática (via portal: Key Vault > Secrets > [segredo] > Rotation policy)
A política de rotação define:
- Frequência de rotação (ex: a cada 30, 60, 90 dias)
- Notificação X dias antes da expiração
- Ação automática: gerar nova versão e disparar evento para webhook ou Function App que execute a rotação no storage
7. Controle e Segurança
Desabilitar Acesso via Access Keys
Para forçar o uso exclusivo de autenticação baseada em Entra ID e eliminar o risco das access keys:
Via portal: Storage Account > Configuration > Allow storage account key access > Disabled
az storage account update \
--name minhaconta \
--resource-group rg-producao \
--allow-shared-key-access false
Quando desabilitado:
- As access keys ainda existem no sistema, mas não podem ser usadas para autenticação
- Connection strings baseadas em access keys falham
- SAS tokens Account e Service falham (derivadas das keys)
- User Delegation SAS continua funcionando (não usa access keys)
- RBAC DataActions continuam funcionando
Atenção: antes de desabilitar, garanta que todas as aplicações que acessam aquele storage já estão usando autenticação baseada em identidade (Managed Identity + RBAC DataActions). Do contrário, você vai quebrar as aplicações.
Azure Policy para Auditar e Bloquear Uso de Keys
O Azure tem políticas integradas relevantes:
| Política | Efeito | O que faz |
|---|---|---|
Storage accounts should prevent shared key access | Audit / Deny | Verifica se o acesso via key está habilitado |
Configure storage accounts to disable shared key access | DeployIfNotExists | Desabilita automaticamente o acesso via key em novas contas |
Essas políticas ajudam a garantir conformidade em toda a organização.
Monitoramento e Alertas
Activity Log: registra toda visualização e regeneração de access keys. Crie um alerta para quando qualquer key for regenerada:
az monitor activity-log alert create \
--name "alert-storage-key-rotated" \
--resource-group rg-monitoring \
--scopes "/subscriptions/<sub-id>" \
--condition category=Administrative and operationName=Microsoft.Storage/storageAccounts/regenerateKey/action \
--action-group "/subscriptions/<sub-id>/resourceGroups/rg-monitoring/providers/microsoft.insights/actionGroups/ag-security"
Microsoft Defender for Storage: detecta padrões suspeitos de uso das access keys, como acesso de localizações geográficas incomuns ou volumes anormais de operações, e gera alertas de segurança.
8. Tomada de Decisão
Access Key vs. Identidade vs. SAS: quando usar cada um?
| Situação | Abordagem recomendada | Motivo |
|---|---|---|
| Aplicação moderna em Azure (VM, Function App, Container) | Managed Identity + RBAC DataActions | Sem credencial para gerenciar, sem risco de vazamento |
| Aplicação legada que não suporta Entra ID | Access Key via Key Vault (não embutida no código) | Compatibilidade mantida com segurança adicionada |
| Acesso temporário de parceiro externo a um blob | User Delegation SAS | Escopo limitado, expira, não expõe a key |
| Migração de dados pontuais via AzCopy | SAS token de curta duração | Temporário e com escopo definido |
| Ambiente de desenvolvimento local | Access Key (temporariamente) | Conveniência, mas nunca em produção |
| Conformidade que exige zero shared credentials | Desabilitar key access + RBAC obrigatório | Elimina o risco da key completamente |
Quando rotacionar as access keys?
| Evento | Ação | Urgência |
|---|---|---|
| Chave encontrada em repositório Git ou log | Rotação imediata da chave exposta | Crítica: fazer agora |
| Saída de funcionário com acesso às chaves | Rotação preventiva | Alta: fazer no mesmo dia |
| Rotina de segurança periódica | Rotação programada | Normal: mensalmente ou conforme política |
| Migração de aplicação para identidade gerenciada | Rotação após migração | Após confirmar que app não usa mais a key |
| Auditoria de segurança detectou acesso suspeito | Rotação imediata | Crítica: fazer agora |
9. Boas Práticas
Nunca embutir access keys diretamente no código: hardcoding de credentials em código é uma das causas mais comuns de vazamento. Keys chegam ao GitHub, ficam em logs, aparecem em tickets. Armazene-as sempre no Key Vault ou no serviço de configuração da aplicação (App Configuration, App Settings de Function Apps).
Use Managed Identity sempre que possível: para aplicações rodando em Azure, Managed Identity elimina completamente a necessidade de gerenciar access keys. A aplicação obtém um token Entra ID automaticamente, sem credenciais para armazenar ou rotacionar.
Rotação regular e automatizada: mesmo sem incidentes, rotacione access keys regularmente. O Azure Key Vault com política de rotação automatiza isso completamente. 90 dias é uma frequência comum; ambientes de alta segurança podem exigir 30 dias.
Documente quais aplicações usam cada chave: antes de rotacionar, você precisa saber o que será impactado. Mantenha um inventário atualizado: "key1 do storage X é usada pelo sistema Y e pelo script Z". Sem esse inventário, uma rotação pode causar falhas inesperadas.
Desabilite o acesso via key em storage accounts que já migraram para RBAC: uma vez que todas as aplicações de um storage account estejam usando Managed Identity, desabilitar o acesso via key é uma camada adicional de proteção. Mesmo que alguém obtenha a key (por exemplo, via acesso indevido ao portal), ela não poderá ser usada.
10. Erros Comuns
Rotacionar a chave que as aplicações estão usando sem migrar primeiro para a outra chave
Este é o erro mais catastrófico. A aplicação estava usando key1, o administrador regenera key1, a connection string da aplicação aponta para a key1 antiga que agora é inválida, e todas as operações de storage falham imediatamente. O processo correto é: migrar as aplicações para key2, depois regenerar key1; ou migrar para key1 nova, depois regenerar key2.
Invalidar SAS tokens ao rotacionar key sem considerar quem as possui
Um sistema externo (parceiro, cliente) recebeu uma SAS token com validade de 30 dias. O administrador rotaciona a key1 da qual a SAS foi gerada. A SAS do parceiro é invalidada instantaneamente, mesmo com 25 dias de validade restantes. Isso causa falha no sistema do parceiro sem aviso prévio. Antes de rotacionar uma key, verifique se existem SAS tokens ativas derivadas dela e planeje a transição.
Expor a connection string em variáveis de ambiente de forma insegura
Em muitos ambientes, a connection string do storage é colocada em variáveis de ambiente do servidor ou em arquivos .env. Se esses arquivos ficam no repositório Git, ou se os logs do servidor registram variáveis de ambiente, a connection string (e portanto a access key) vaza. O correto é referenciar a key via Key Vault, nunca armazená-la diretamente em variáveis de ambiente de texto claro em produção.
Confundir regeneração de key com revogação de acesso a um usuário específico
As access keys não são vinculadas a um usuário. Regenerar key1 revoga o acesso de qualquer um que estava usando key1, incluindo sistemas legítimos. Se o objetivo era revogar o acesso de um usuário específico, a abordagem correta seria revogar a atribuição RBAC desse usuário, não regenerar uma key que afeta todos.
Não monitorar visualizações das access keys
Cada vez que alguém clica em "Show" para visualizar uma access key no portal, isso é registrado no Activity Log. Muitas organizações não monitoram esses eventos. Um atacante interno que está coletando credenciais pode visualizar as keys de múltiplos storage accounts sem nenhum alerta. Configure alertas para visualizações de access keys.
11. Operação e Manutenção
Auditoria de Uso das Access Keys
Para verificar se um storage account está tendo suas keys usadas (em vez de RBAC):
# Verificar a configuração atual
az storage account show \
--name minhaconta \
--resource-group rg-producao \
--query "allowSharedKeyAccess" \
--output tsv
Para auditar todos os storage accounts da assinatura que ainda permitem acesso via key:
az storage account list \
--query "[?allowSharedKeyAccess!=false].{Nome:name, RG:resourceGroup, KeyAccess:allowSharedKeyAccess}" \
--output table
Verificar Última Rotação das Keys
Infelizmente, o Azure não expõe diretamente a data da última rotação de cada key via CLI de forma simples. A melhor fonte é o Activity Log:
az monitor activity-log list \
--resource-group rg-producao \
--start-time $(date -d '90 days ago' +%Y-%m-%dT%H:%M:%S) \
--query "[?operationName.value=='Microsoft.Storage/storageAccounts/regenerateKey/action'].{Data:eventTimestamp, Conta:resourceId, Operador:caller}" \
--output table
Limites Importantes
| Item | Detalhe |
|---|---|
| Keys por storage account | Sempre exatamente 2 (key1 e key2) |
| Número máximo de SAS derivadas | Sem limite documentado |
| Duração máxima de uma Account SAS | 7 dias (limitação de segurança do serviço) |
| Duração máxima de uma User Delegation SAS | 7 dias (prazo máximo do delegation key) |
| Retenção dos logs de Activity Log | 90 dias padrão |
12. Integração e Automação
Rotação Automática Completa com Azure Functions + Key Vault + Event Grid
O padrão mais robusto para automação de rotação de keys é:
Esse padrão elimina completamente a rotação manual. O Key Vault dispara o evento, a Function executa o processo de rotação em sequência segura, e as aplicações que buscam a key do Key Vault automaticamente recebem a nova versão sem interrupção.
Migração Gradual para Managed Identity
Para organizações que querem eliminar o uso de access keys progressivamente:
- Habilitar Managed Identity na aplicação (VM, Function App, etc.)
- Atribuir papel
Storage Blob Data Contributor(ou o papel adequado) à Managed Identity no storage account - Atualizar a aplicação para usar o SDK do Azure com DefaultAzureCredential (que usa automaticamente a Managed Identity)
- Testar e validar o acesso via identidade
- Remover a access key da configuração da aplicação
- Após confirmar que nenhuma aplicação usa mais a key, desabilitar
allowSharedKeyAccessno storage account
13. Resumo Final
Pontos essenciais:
- Access keys são credenciais compartilhadas que concedem acesso completo e irrestrito a um Storage Account. Não há granularidade de permissão, não há identidade vinculada.
- Cada Storage Account tem sempre exatamente duas chaves (key1 e key2), ambas com o mesmo nível de acesso. Duas chaves existem para permitir rotação sem downtime.
- Rotacionar uma key invalida instantaneamente todas as SAS tokens (Account SAS e Service SAS) derivadas daquela key, mesmo que ainda estejam no prazo de validade.
- Connection strings encapsulam nome da conta + access key. Expor a connection string é equivalente a expor a access key.
- A configuração Allow shared key access pode ser desabilitada para forçar uso exclusivo de autenticação baseada em Entra ID.
Diferenças críticas:
- Account SAS e Service SAS são derivadas das access keys e são invalidadas quando a key é rotacionada. User Delegation SAS é derivada de uma credencial Entra ID e não é afetada pela rotação das access keys.
- Access Key vs. Managed Identity + RBAC: a key é um segredo compartilhado sem identidade; Managed Identity é autenticação sem credencial, com granularidade de permissão via DataActions.
- Rotação de key vs. revogação de acesso de usuário: rotacionar uma key afeta todos que a usavam, não um usuário específico. Para revogar acesso de um usuário, use RBAC (remover a role assignment).
O que precisa ser lembrado:
- Nunca embutir access keys no código. Sempre usar Key Vault para armazenamento seguro.
- Seguir a sequência correta de rotação: migrar para a key alternativa antes de regenerar a key em uso.
- Antes de rotacionar, identificar todas as SAS tokens derivadas da key que serão invalidadas.
- Configure alertas no Activity Log para regeneração de keys e para visualizações de keys.
- A meta de longo prazo é eliminar o uso de access keys em favor de Managed Identity + RBAC DataActions, e desabilitar
allowSharedKeyAccessnos storage accounts migrados. - Access keys não existem apenas no Storage; outros serviços como Azure Cosmos DB, Azure Cache for Redis e Azure Service Bus também usam mecanismos similares de chaves de acesso. O padrão de gestão e os riscos são os mesmos.