Il problema: dare accesso senza distribuire le chiavi

Ogni storage account nasce con due account key che concedono controllo completo su tutto il servizio. Distribuirle a client o applicazioni è l’anti-pattern classico: chi possiede la chiave può leggere, scrivere ed eliminare qualsiasi blob, non c’è granularità e l’unica revoca possibile è la rigenerazione della chiave, che invalida ogni altro utilizzatore. In uno scenario AZ-204 la domanda è quasi sempre come concedere accesso limitato e temporaneo a un blob o container senza mai esporre credenziali persistenti.

I tre tipi di Shared Access Signature (SAS)

Una SAS è un token firmato che incapsula permessi, finestra temporale e risorsa. Esistono tre varianti che si distinguono per cosa firma il token:

  • Account SAS: firmata con la account key, può coprire più servizi (Blob, Queue, Table, File) e operazioni a livello di account. È la più potente e la più pericolosa.
  • Service SAS: firmata anch’essa con la account key, ma limitata a un singolo servizio e a una risorsa specifica (un container o un blob). Può essere legata a una stored access policy.
  • User delegation SAS: firmata con una user delegation key ottenuta da Microsoft Entra ID, non con la account key. È disponibile solo per Blob Storage ed è la scelta raccomandata quando serve una SAS.

Perché preferire la user delegation SAS

Poiché non usa la account key, la user delegation SAS eredita il principio di least privilege dall’identità Entra che la emette: il chiamante deve possedere il ruolo RBAC Storage Blob Data Contributor (o simile) e l’azione dati generateUserDelegationKey. I permessi effettivi del token sono l’intersezione tra ciò che chiede la SAS e ciò che l’identità può realmente fare. La user delegation key ha una scadenza massima di 7 giorni: la revoca è immediata e centralizzata perché basta ruotarla o rimuovere il ruolo RBAC, senza toccare le account key né gli altri consumatori.

az storage blob generate-sas --auth-mode login --as-user \
  --account-name <acct> -c <container> -n <blob> \
  --permissions r --expiry 2026-07-18T00:00Z

Quando invece NON serve la SAS: RBAC + managed identity

Se il consumatore è un componente Azure (Function, App Service, container), la risposta migliore è spesso nessuna SAS e nessuna chiave: si assegna una managed identity e si concede il ruolo RBAC data-plane appropriato sul container. DefaultAzureCredential nell’SDK negozia il token OAuth automaticamente. Riservare la SAS ai casi in cui il client non può autenticarsi con Entra (browser, terze parti, dispositivi) e serve un URL a tempo.

Stored access policy: revoca centralizzata per le service SAS

Una service SAS con permessi e scadenza incorporati nel token non è revocabile se non rigenerando la chiave. La soluzione è la stored access policy, definita sul container: la SAS referenzia la policy per nome e ne eredita permessi e finestra temporale. Modificando o eliminando la policy si revocano istantaneamente tutte le SAS ad essa collegate. Si possono avere al massimo 5 stored access policy per container.

Lifecycle management: automazione basata sull’età

Le lifecycle management policy sono regole JSON a livello di storage account che spostano o eliminano automaticamente i blob in base all’età o all’ultimo accesso. Si applicano solo agli account general-purpose v2 / premium block blob e agiscono sui tier:

  • tierToCool / tierToCold: sposta blob rari verso tier più economici.
  • tierToArchive: archiviazione offline per dati raramente letti (richiede rehydrate per rileggerli).
  • delete: elimina blob, snapshot o versioni dopo N giorni.

I filtri usano daysAfterModificationGreaterThan, daysAfterLastAccessTimeGreaterThan (richiede last access time tracking attivo) e prefissi/blob index tag per limitare l’ambito. È il meccanismo corretto per il data retention automatico, non uno script schedulato.

Trappole tipiche d’esame

  • Scenario: un client di terze parti deve scaricare un blob per pochi minuti e il token deve poter essere revocato subito → user delegation SAS (firmata con Entra ID), non account-key SAS a lunga scadenza.
  • Scenario: una Function nello stesso tenant deve leggere blob in modo sicuro e permanente → managed identity + ruolo RBAC Storage Blob Data Reader, niente SAS né connection string con chiave.
  • Scenario: devi poter invalidare centralmente molte service SAS già emesse → definisci una stored access policy sul container e falla referenziare dalle SAS (rigenerare la account key è la risposta sbagliata).
  • Scenario: spostare i log in archive dopo 90 giorni ed eliminarli dopo un anno → lifecycle management policy con tierToArchive e delete, non un job custom.
  • Trappola: la user delegation key dura al massimo 7 giorni; una SAS con scadenza più lunga richiederebbe una account/service SAS, meno sicura.