Fundamentação Teórica: Configure Stored Access Policies

1. Intuição Inicial

No módulo anterior, aprendemos que um SAS Token é uma URL assinada com permissões e expiração embutidas diretamente no token. Uma vez emitido, esse token não pode ser alterado: se você deu acesso de leitura por 30 dias e precisa revogar no dia 10, a única saída é rotacionar a Account Key, o que interrompe todos os outros acessos que usam aquela chave.

Imagine que você emite cartões de acesso para um prédio comercial. Cada cartão tem a data de validade impressa plasticamente, impossível de apagar. Se um visitante perde o cartão no dia 3 de um acesso válido por 30 dias, você não tem como invalidar aquele cartão específico sem trocar a fechadura de todo o prédio (o que afeta todos os outros cartões).

Uma Stored Access Policy (SAP) resolve exatamente isso: em vez de imprimir as permissões e a expiração diretamente no SAS Token, você armazena essas definições em um registro centralizado no próprio container (ou fila, tabela, file share), e o SAS Token apenas referencia esse registro pelo nome. Se precisar revogar ou alterar as permissões, você modifica ou deleta o registro central, e todos os SAS que o referenciam são afetados imediatamente, sem precisar tocar nas Account Keys ou nos tokens em si.

2. Contexto

Onde Stored Access Policies se encaixam no ecossistema de SAS

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Por que Stored Access Policies existem

A necessidade nasce de um problema de governança: SAS Tokens são instrumentos de delegação de acesso que, por sua própria natureza criptográfica, não podem ser revogados individualmente sem impacto sistêmico (rotação de Account Key).

Em cenários reais, isso é um problema sério:

Um parceiro externo recebe um SAS de 90 dias e o contrato é rescindido no dia 15
Um token é acidentalmente exposto em logs ou código-fonte
Uma aplicação precisa ter suas permissões reduzidas sem interrupção de serviço

SAPs criam um ponto de controle centralizado que desacopla a emissão do token do controle de suas permissões.

O que depende de SAPs

Integrações B2B de longa duração que precisam de revogação seletiva
Ambientes com múltiplos parceiros cada um com acesso diferente ao mesmo container
Sistemas de auditoria que precisam rastrear quais acessos estão ativos
Cenários de compliance onde acesso de terceiros precisa ser removido rapidamente

3. Construção dos Conceitos

3.1 Estrutura de uma Stored Access Policy

Uma SAP é um objeto armazenado dentro de um recurso do storage com quatro campos:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O campo id é o identificador único da SAP dentro do recurso. É o nome que o SAS Token referencia no parâmetro si (signedIdentifier).

Os campos de permissão e expiração podem ser omitidos na SAP, desde que sejam fornecidos no próprio SAS Token. Porém, se estiverem na SAP, eles controlam o acesso efetivo.

3.2 Onde SAPs podem ser criadas

Recurso	Suporta SAP	Número máximo de SAPs
Container (Blob)	Sim	5
Blob individual	Não	N/A
Queue	Sim	5
Table	Sim	5
File Share	Sim	5
Storage Account (nível)	Não	N/A

O limite de 5 SAPs por recurso é fixo e não pode ser aumentado. Isso exige planejamento cuidadoso para organizações com muitos parceiros acessando o mesmo container.

Atenção: SAPs existem apenas para Service SAS. Não é possível criar uma SAP para Account SAS ou User Delegation SAS.

3.3 Como um SAS referencia uma SAP

O parâmetro si (signedIdentifier) no SAS Token contém o nome da SAP:

https://stgprod001.blob.core.windows.net/container1/arquivo.pdf
?sv=2022-11-02
&sr=b
&si=policy-parceiro-externo    ← nome da SAP
&sig=abc123...                  ← assinatura calculada incluindo o nome da SAP

Quando o storage recebe esta requisição:

Verifica a assinatura
Procura a SAP chamada policy-parceiro-externo no container container1
Aplica as permissões e expiração da SAP
Decide se a operação é permitida

3.4 Resolução de conflito: SAP vs. SAS

Quando tanto a SAP quanto o SAS Token definem permissões ou expiração, o mais restritivo prevalece:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Esta regra de "mais restritivo prevalece" é importante para entender o comportamento quando SAPs são atualizadas.

3.5 Mecanismo de revogação via SAP

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Este é o fluxo central de valor das SAPs: revogação instantânea e cirúrgica, sem afetar outros tokens ou serviços.

4. Visão Estrutural

Como SAPs coexistem em um container

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Note que policy-auditoria tem permissões e datas vazias na SAP: a expiração é fornecida no próprio SAS Token que a referencia. Isso é válido, mas significa que a SAP sozinha não controla nada além do nome do identificador. A revogação ainda é possível: se você deletar a SAP, o SAS para de funcionar mesmo que a data do token ainda não tenha expirado.

5. Funcionamento na Prática

Ciclo de vida de uma Stored Access Policy

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamentos não óbvios críticos

Modificar uma SAP pode ter efeito em até 30 segundos. Após criar, modificar ou deletar uma SAP, o Azure precisa de até 30 segundos para propagar a mudança. Durante esse período, o comportamento pode ser inconsistente: alguns servidores do Azure já reconhecem a mudança, outros ainda não. Em operações de segurança urgente (revogar acesso de parceiro comprometido), espere 30 segundos após deletar a SAP antes de considerar o acesso efetivamente bloqueado.

Uma SAP vazia (sem permissões nem expiração) ainda tem valor. Uma SAP com apenas o id (nome), sem permissões e sem expiração, ainda serve como âncora de revogação: se você deletar essa SAP, todos os SAS que a referenciam param de funcionar, mesmo que o SAS Token em si ainda tenha data de expiração válida e permissões definidas nele.

Atualizar uma SAP não cria uma nova versão. Ao modificar permissões ou expiração de uma SAP existente, o Azure substitui a definição anterior. Não há histórico de versões. SAS Tokens já emitidos que referenciam aquela SAP passam a usar as novas configurações imediatamente (após a propagação de até 30 segundos).

Deletar e recriar uma SAP com o mesmo nome é diferente de modificar. Se você deletar policy-parceiro-a e criar uma nova SAP com o mesmo nome, os SAS Tokens que referenciavam a política anterior continuam funcionando, pois eles referenciam pelo nome. Isso significa que deletar e recriar com o mesmo nome não revoga os tokens existentes.

SAPs em containers não se aplicam a blobs individuais com SAS. Se você cria uma SAP no container e emite um Service SAS com sr=b (recurso = blob), referenciando a SAP do container, funciona. Mas SAPs são armazenadas no container, não no blob individual. Isso é esperado: a SAP é um atributo do container.

6. Formas de Implementação

Portal do Azure

Quando usar: gerenciamento pontual, verificação visual do estado das SAPs

O portal do Azure não tem uma interface direta para gerenciar Stored Access Policies em containers de blob. Para gerenciar SAPs de containers via interface gráfica, você precisa usar o Azure Storage Explorer (aplicativo desktop gratuito da Microsoft).

No portal, SAPs podem ser indiretamente verificadas ao gerar um SAS Token de container, onde as políticas existentes aparecem como opção.

Limitação do portal: sem gerenciamento completo de SAPs via browser; requer Storage Explorer ou CLI/PowerShell.

Azure CLI

# Criar SAP em um container (com permissões e expiração)
az storage container policy create \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --container-name "dados-parceiros" \
  --name "policy-parceiro-a" \
  --permissions r \
  --start "2026-03-24T00:00:00Z" \
  --expiry "2026-06-30T23:59:59Z"

# Criar SAP com apenas o nome (âncora de revogação)
az storage container policy create \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --container-name "dados-parceiros" \
  --name "policy-auditoria"
# Sem --permissions, --start, --expiry: SAP válida sem restrições próprias

# Listar todas as SAPs de um container
az storage container policy list \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --container-name "dados-parceiros" \
  --output table

# Ver detalhes de uma SAP específica
az storage container policy get \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --container-name "dados-parceiros" \
  --name "policy-parceiro-a"

# MODIFICAR uma SAP existente (substitui in-place)
az storage container policy update \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --container-name "dados-parceiros" \
  --name "policy-parceiro-a" \
  --permissions rl \
  --expiry "2026-09-30T23:59:59Z"
# Permissões ampliadas de r para rl e expiração estendida

# REVOGAR: deletar a SAP imediatamente invalida todos os SAS que a referenciam
az storage container policy delete \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --container-name "dados-parceiros" \
  --name "policy-parceiro-a"

# Gerar Service SAS referenciando uma SAP
az storage container generate-sas \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --name "dados-parceiros" \
  --policy-name "policy-parceiro-a" \
  --https-only \
  --output tsv

# Gerar SAS de blob referenciando SAP do container
az storage blob generate-sas \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --container-name "dados-parceiros" \
  --name "relatorio-q1.pdf" \
  --policy-name "policy-parceiro-a" \
  --https-only \
  --output tsv

# SAP em uma Queue
az storage queue policy create \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --queue-name "fila-processos" \
  --name "policy-processador" \
  --permissions raup \
  --expiry "2026-12-31T23:59:59Z"

# SAP em uma File Share
az storage share policy create \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --share-name "compartilhamento-externo" \
  --name "policy-leitura-share" \
  --permissions rl \
  --expiry "2026-06-30T23:59:59Z"

# SAP em uma Table
az storage table policy create \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --table-name "dadosoperacionais" \
  --name "policy-leitura-tabela" \
  --permissions r \
  --expiry "2026-12-31T23:59:59Z"

Azure PowerShell

# Criar contexto de storage
$ctx = New-AzStorageContext `
  -StorageAccountName "stgprod001" `
  -StorageAccountKey "<account-key>"

# Criar SAP em container
New-AzStorageContainerStoredAccessPolicy `
  -Context $ctx `
  -Container "dados-parceiros" `
  -Policy "policy-parceiro-a" `
  -Permission "r" `
  -StartTime (Get-Date "2026-03-24") `
  -ExpiryTime (Get-Date "2026-06-30T23:59:59Z")

# Listar SAPs de um container
Get-AzStorageContainerStoredAccessPolicy `
  -Context $ctx `
  -Container "dados-parceiros" |
  Select-Object Policy, Permissions, SharedAccessStartTime, SharedAccessExpiryTime

# Modificar SAP existente
Set-AzStorageContainerStoredAccessPolicy `
  -Context $ctx `
  -Container "dados-parceiros" `
  -Policy "policy-parceiro-a" `
  -Permission "rl" `
  -ExpiryTime (Get-Date "2026-09-30T23:59:59Z")

# Deletar SAP (revoga todos os SAS que a referenciam)
Remove-AzStorageContainerStoredAccessPolicy `
  -Context $ctx `
  -Container "dados-parceiros" `
  -Policy "policy-parceiro-a"

# Gerar SAS referenciando SAP
$sas = New-AzStorageContainerSASToken `
  -Context $ctx `
  -Name "dados-parceiros" `
  -Policy "policy-parceiro-a"

# URL completa com SAS
$containerUrl = "https://stgprod001.blob.core.windows.net/dados-parceiros$sas"

# SAP em Queue
New-AzStorageQueueStoredAccessPolicy `
  -Context $ctx `
  -Queue "fila-processos" `
  -Policy "policy-processador" `
  -Permission "raup" `
  -ExpiryTime (Get-Date).AddMonths(9)

# SAP em File Share
New-AzStorageShareStoredAccessPolicy `
  -Context $ctx `
  -ShareName "compartilhamento-externo" `
  -Policy "policy-leitura-share" `
  -Permission "rl" `
  -ExpiryTime (Get-Date).AddMonths(3)

Bicep (ARM Template)

SAPs podem ser definidas como parte do recurso container em templates ARM/Bicep:

resource storageAccount 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: 'stgprod001'
  location: 'brazilsouth'
  kind: 'StorageV2'
  sku: { name: 'Standard_LRS' }
  properties: {}
}

resource blobService 'Microsoft.Storage/storageAccounts/blobServices@2023-01-01' = {
  parent: storageAccount
  name: 'default'
}

resource container 'Microsoft.Storage/storageAccounts/blobServices/containers@2023-01-01' = {
  parent: blobService
  name: 'dados-parceiros'
  properties: {
    publicAccess: 'None'
  }
}

// SAPs são definidas via operação separada no ARM
// Não há suporte direto em Bicep para SAPs em containers
// Use deployment scripts ou pós-deploy via CLI
resource deploymentScript 'Microsoft.Resources/deploymentScripts@2023-08-01' = {
  name: 'create-sap-parceiro-a'
  location: 'brazilsouth'
  kind: 'AzureCLI'
  properties: {
    azCliVersion: '2.50.0'
    retentionInterval: 'P1D'
    scriptContent: '''
      az storage container policy create \
        --account-name ${STORAGE_NAME} \
        --container-name dados-parceiros \
        --name policy-parceiro-a \
        --permissions r \
        --expiry 2026-06-30T23:59:59Z \
        --auth-mode login
    '''
    environmentVariables: [
      { name: 'STORAGE_NAME', value: storageAccount.name }
    ]
  }
  dependsOn: [container]
}

SAPs não têm suporte nativo como recursos ARM standalone. A abordagem recomendada para IaC é usar Deployment Scripts ou configurá-las via pipeline pós-deploy.

7. Controle e Segurança

Estratégia de revogação granular

Com SAPs, você pode ter múltiplos parceiros acessando o mesmo container com revogação independente:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O limite de 5 SAPs e como gerenciá-lo

Quando você tem mais de 5 parceiros ou casos de uso, as opções são:

Consolidar parceiros em SAPs compartilhadas: se dois parceiros têm as mesmas permissões e expiração, usam a mesma SAP. O SAS Token deles é diferente (assinado em momentos diferentes), mas a SAP é a mesma.
Segregar em múltiplos containers: em vez de um único container com 5 SAPs, use containers separados por parceiro ou grupo de parceiros.
Aceitar SAS sem SAP para casos de baixo risco: parceiros com acesso de curta duração (horas) não precisam de SAP, pois o acesso expira naturalmente.
Usar User Delegation SAS: para parceiros com identidade Azure AD, elimina a necessidade de SAP completamente.

Auditoria de SAPs ativas

# Relatório completo de SAPs em todos os containers de um storage account
for container in $(az storage container list \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --query "[].name" -o tsv); do
  echo "=== Container: $container ==="
  az storage container policy list \
    --account-name "stgprod001" \
    --account-key "<account-key>" \
    --container-name "$container" \
    --output table
done

8. Tomada de Decisão

Quando usar SAP vs. SAS ad hoc

Situação	Escolha	Motivo
Acesso de poucas horas para envio de arquivo	SAS ad hoc	Expiração automática torna SAP desnecessária
Contrato de 6 meses com parceiro externo	SAP	Possibilidade de rescisão antecipada requer revogação
Múltiplos parceiros com permissões diferentes no mesmo container	SAPs separadas por parceiro	Revogação granular por parceiro
Pipeline interno com Managed Identity	RBAC (sem SAS)	Managed Identity é mais seguro que qualquer SAS
Parceiro externo com acesso de leitura recorrente	SAP sem expiração na SAP, com expiração no SAS	Emite SAS de curta duração que referenciam SAP de longa duração; revoga pela SAP se necessário
Limite de 5 SAPs atingido	Criar container adicional	Não há como aumentar o limite
Acesso a blob individual por hora	SAS ad hoc de blob	SAP não é necessária para duração tão curta

SAS com SAP vs. SAS sem SAP: comparação estrutural

Aspecto	SAS ad hoc (sem SAP)	SAS com SAP
Revogação antes da expiração	Apenas rotacionando Account Key	Deletar a SAP
Impacto da revogação	Todos os SAS com aquela key	Apenas os SAS que referenciam aquela SAP
Expiração máxima	Determinada na criação	Pode ser indeterminada (expiração no SAS)
Auditoria de acessos ativos	Difícil (tokens espalhados)	Possível via listagem de SAPs
Modificar permissões sem revogar	Impossível	Modificar a SAP (afeta imediatamente)
Complexidade de implementação	Baixa	Média
Ideal para	Acessos temporários de horas	Acessos de dias, semanas ou meses

9. Boas Práticas

Use uma SAP por parceiro/sistema externo, não por tipo de acesso. Nomear SAPs por parceiro (não por permissão) facilita a revogação seletiva. policy-parceiro-acme é mais gerenciável que policy-read que é compartilhada por cinco parceiros.

Mantenha um registro externo de qual SAS referencia qual SAP. As SAPs ficam no storage, mas não há como saber quais tokens foram emitidos contra elas. Mantenha uma planilha ou banco de dados: quem recebeu, qual SAP, quando foi gerado, data de validade esperada. Isso é essencial para saber quem é afetado quando você precisa revogar.

Prefira colocar expiração na SAP, não apenas no SAS. Se a expiração está na SAP, você pode estendê-la sem precisar emitir novos tokens para o parceiro. Se está apenas no SAS, quando o SAS expira você precisa emitir um novo token e entregá-lo ao parceiro.

Use SAPs para qualquer SAS com duração acima de 24 horas. Um dia é o limite prático razoável: se algo der errado em menos de 24 horas, a espera pelo vencimento natural é aceitável. Para qualquer coisa além disso, o risco de precisar revogar justifica o uso de SAP.

Nomeie SAPs com contexto de negócio, não técnico. policy-parceiro-acme-leitura-2026 é muito melhor que p1 ou sap-r. O nome é o único identificador em logs e auditorias.

Documente o processo de revogação antes de precisar dele. Em situações de incidente de segurança, executar o procedimento correto sob pressão é difícil. Tenha um runbook documentado: "para revogar acesso do parceiro X: executar az storage container policy delete...". Isso reduz o tempo de resposta crítico.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Deletar e recriar SAP com mesmo nome esperando revogar acesso	Não entender que o nome é o identificador; recriar restaura o acesso	Para revogar, deletar sem recriar (ou criar com nome diferente)
Atingir limite de 5 SAPs sem planejar	Criar SAPs ad hoc sem estrutura	Planejar SAPs antes de ter parceiros; consolidar onde possível
SAP modificada mas acesso ainda funciona por 30 segundos	Não conhecer o delay de propagação	Aguardar 30 segundos após mudanças críticas
SAP sem nenhum campo (vazia) não revoga acesso por si só	Confundir SAP como mecanismo de bloqueio; SAP vazia concede acesso indefinido	Entender que a revogação ocorre pela DELEÇÃO da SAP, não pelo esvaziamento dela
SAS gerado sem referenciar SAP para parceiro de longa duração	Pressa, não planejar para revogação	Usar SAP para qualquer parceiro externo com acesso > 24h
Não documentar quais SAS foram emitidos contra cada SAP	Confiança na memória ou comunicação informal	Manter registro externo centralizado
Expiração muito longa na SAP sem SAP como âncora de revogação	Otimismo sobre manutenção de parceria	Sempre ter a SAP como mecanismo de controle, independente da expiração

O erro mais perigoso

Acreditar que modificar as permissões de uma SAP (por exemplo, de r para ``) vai bloquear o acesso. Não existe permissão vazia que significa "negar tudo". Para bloquear o acesso, a SAP precisa ser deletada, não esvaziada. Uma SAP com campos vazios resulta em comportamento indefinido dependendo de como o SAS que a referencia foi configurado.

11. Operação e Manutenção

Rotina de revisão de SAPs

# Verificar SAPs expiradas que ainda existem (limpeza)
CURRENT_DATE=$(date -u +%Y-%m-%dT%H:%M:%SZ)
az storage container policy list \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --container-name "dados-parceiros" \
  --query "[?expiry != null && expiry < '$CURRENT_DATE'].{Name: id, Expirou_em: expiry}" \
  --output table

# Listar SAPs que expiram nos próximos 30 dias (para renovação proativa)
EXPIRY_THRESHOLD=$(date -u -d '+30 days' +%Y-%m-%dT%H:%M:%SZ)
az storage container policy list \
  --account-name "stgprod001" \
  --account-key "<account-key>" \
  --container-name "dados-parceiros" \
  --query "[?expiry != null && expiry < '$EXPIRY_THRESHOLD' && expiry > '$CURRENT_DATE'].{Name: id, Expira_em: expiry}" \
  --output table

# Script de auditoria completa: SAPs em todos os containers de todos os storage accounts
for storage in $(az storage account list --query "[].name" -o tsv); do
  KEY=$(az storage account keys list \
    --account-name "$storage" \
    --query "[0].value" -o tsv 2>/dev/null)
  
  if [ -n "$KEY" ]; then
    echo "=== Storage: $storage ==="
    for container in $(az storage container list \
      --account-name "$storage" \
      --account-key "$KEY" \
      --query "[].name" -o tsv 2>/dev/null); do
      POLICIES=$(az storage container policy list \
        --account-name "$storage" \
        --account-key "$KEY" \
        --container-name "$container" \
        --output tsv 2>/dev/null)
      if [ -n "$POLICIES" ]; then
        echo "  Container: $container"
        echo "$POLICIES"
      fi
    done
  fi
done

Limite a monitorar

Limite	Valor	Impacto
SAPs por container	5	Planejamento obrigatório para múltiplos parceiros
SAPs por queue	5	Idem
SAPs por table	5	Idem
SAPs por file share	5	Idem
Delay de propagação	Até 30 segundos	Considerar em operações de segurança urgente
Tamanho máximo do nome da SAP	64 caracteres	Nomes descritivos cabem facilmente

12. Integração e Automação

Padrão: Gerenciamento de acesso de parceiros via portal interno

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Automação de rotação de SAPs próximas da expiração

# Runbook: Notificar administradores sobre SAPs que expiram em 7 dias
$ctx = New-AzStorageContext -StorageAccountName "stgprod001" -StorageAccountKey "<key>"

$containers = Get-AzStorageContainer -Context $ctx
$expiringPolicies = @()

foreach ($container in $containers) {
  $policies = Get-AzStorageContainerStoredAccessPolicy -Context $ctx -Container $container.Name

  foreach ($policy in $policies) {
    if ($policy.SharedAccessExpiryTime -ne $null) {
      $daysUntilExpiry = ($policy.SharedAccessExpiryTime - (Get-Date)).Days
      if ($daysUntilExpiry -le 7 -and $daysUntilExpiry -ge 0) {
        $expiringPolicies += [PSCustomObject]@{
          Container = $container.Name
          Policy    = $policy.Policy
          ExpiresIn = "$daysUntilExpiry dias"
          ExpiryDate = $policy.SharedAccessExpiryTime
        }
      }
    }
  }
}

if ($expiringPolicies.Count -gt 0) {
  $body = $expiringPolicies | ConvertTo-Html -Property Container, Policy, ExpiresIn, ExpiryDate
  # Enviar email ou notificação Teams com $body
  Write-Output "Políticas expirando em 7 dias:"
  $expiringPolicies | Format-Table
} else {
  Write-Output "Nenhuma SAP expirando nos próximos 7 dias."
}

13. Resumo Final

Pontos essenciais:

Stored Access Policy (SAP) é uma política de acesso armazenada no próprio recurso (container, queue, table, file share) que Service SAS Tokens podem referenciar pelo nome
A principal função da SAP é habilitar revogação granular: deletar a SAP invalida todos os SAS que a referenciam, sem afetar Account Keys ou outros acessos
SAPs só funcionam com Service SAS; não se aplicam a Account SAS nem User Delegation SAS
O limite é de 5 SAPs por recurso (container, queue, table, file share); limite fixo e não configurável
Após criar, modificar ou deletar uma SAP, a propagação leva até 30 segundos

Diferenças críticas:

SAP vs. SAS ad hoc: SAS ad hoc tem permissões embutidas e é irrevogável; SAS com SAP tem permissões em política externa e é revogável via deleção da SAP
Deletar SAP vs. modificar SAP: deletar revoga todos os SAS que referenciam; modificar altera permissões/expiração mas mantém os SAS funcionando com os novos parâmetros
SAP vazia vs. SAP deletada: SAP vazia ainda existe como âncora e os SAS que a referenciam continuam funcionando (com permissões/expiração do próprio SAS Token); SAP deletada invalida todos os SAS imediatamente
Deletar e recriar SAP com mesmo nome vs. revogar: recriar com o mesmo nome restaura o acesso para SAS existentes; para revogar permanentemente, não recriar

O que precisa ser lembrado para o AZ-104:

SAPs existem apenas para Service SAS
O parâmetro no SAS Token que referencia a SAP é si (signedIdentifier)
Quando há conflito entre SAP e SAS Token, o mais restritivo prevalece (menor expiração, menor conjunto de permissões)
Máximo de 5 SAPs por recurso (container, queue, table, file share)
SAPs não existem em nível de storage account (apenas nos recursos individuais dentro dela)
O delay de propagação após mudanças em SAPs é de até 30 segundos
Nomes de SAPs têm tamanho máximo de 64 caracteres

1. Intuição Inicial​

2. Contexto​

Onde Stored Access Policies se encaixam no ecossistema de SAS​

Por que Stored Access Policies existem​

O que depende de SAPs​

3. Construção dos Conceitos​

3.1 Estrutura de uma Stored Access Policy​

3.2 Onde SAPs podem ser criadas​

3.3 Como um SAS referencia uma SAP​

3.4 Resolução de conflito: SAP vs. SAS​

3.5 Mecanismo de revogação via SAP​

4. Visão Estrutural​

Como SAPs coexistem em um container​

5. Funcionamento na Prática​

Ciclo de vida de uma Stored Access Policy​

Comportamentos não óbvios críticos​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep (ARM Template)​

7. Controle e Segurança​

Estratégia de revogação granular​

O limite de 5 SAPs e como gerenciá-lo​

Auditoria de SAPs ativas​

8. Tomada de Decisão​

Quando usar SAP vs. SAS ad hoc​

SAS com SAP vs. SAS sem SAP: comparação estrutural​

9. Boas Práticas​

10. Erros Comuns​

O erro mais perigoso​

11. Operação e Manutenção​

Rotina de revisão de SAPs​

Limite a monitorar​

12. Integração e Automação​

Padrão: Gerenciamento de acesso de parceiros via portal interno​

Automação de rotação de SAPs próximas da expiração​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Onde Stored Access Policies se encaixam no ecossistema de SAS

Por que Stored Access Policies existem

O que depende de SAPs

3. Construção dos Conceitos

3.1 Estrutura de uma Stored Access Policy

3.2 Onde SAPs podem ser criadas

3.3 Como um SAS referencia uma SAP

3.4 Resolução de conflito: SAP vs. SAS

3.5 Mecanismo de revogação via SAP

4. Visão Estrutural

Como SAPs coexistem em um container

5. Funcionamento na Prática

Ciclo de vida de uma Stored Access Policy

Comportamentos não óbvios críticos

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep (ARM Template)

7. Controle e Segurança

Estratégia de revogação granular

O limite de 5 SAPs e como gerenciá-lo

Auditoria de SAPs ativas

8. Tomada de Decisão

Quando usar SAP vs. SAS ad hoc

SAS com SAP vs. SAS sem SAP: comparação estrutural

9. Boas Práticas

10. Erros Comuns

O erro mais perigoso

11. Operação e Manutenção

Rotina de revisão de SAPs

Limite a monitorar

12. Integração e Automação

Padrão: Gerenciamento de acesso de parceiros via portal interno

Automação de rotação de SAPs próximas da expiração

13. Resumo Final