Modelli di accesso a un account di storage

Un Azure Storage account espone i dati (Blob, File, Queue, Table) attraverso il data plane, distinto dal control plane gestito da Azure Resource Manager. Come amministratore devi scegliere, per ogni scenario, quale meccanismo di autorizzazione usare per il data plane. Le opzioni sono quattro e hanno implicazioni molto diverse in termini di sicurezza.

Account access key

Ogni account ha due chiavi simmetriche (key1, key2) che concedono accesso completo e illimitato a tutti i dati. Chiunque possieda la chiave è di fatto owner del data plane, senza granularità e senza scadenza. Sono comode per scenari legacy o per generare SAS, ma rappresentano il segreto più pericoloso da esporre. Le due chiavi esistono proprio per permettere la rotazione senza downtime: rigeneri key1 dopo aver spostato i client su key2, poi viceversa.

Shared Access Signature (SAS)

Una SAS è un token URL firmato che concede permessi delimitati (servizio, risorsa, permessi, finestra temporale, IP, protocollo HTTPS). Ne esistono tre tipi:

  • Service SAS: limitata a un singolo servizio (es. solo Blob), firmata con l’account key.
  • Account SAS: copre più servizi e operazioni a livello di account, firmata con l’account key.
  • User delegation SAS: firmata con una chiave di delega Microsoft Entra ID (non con l’account key). È l’unica SAS legata a un’identità Entra e ai suoi permessi RBAC, quindi revocabile e più tracciabile.

Poiché service e account SAS dipendono dall’account key, la loro compromissione richiede la rotazione della chiave (che invalida tutte le SAS derivate). La user delegation SAS è la scelta consigliata per l’accesso Blob delegato.

Microsoft Entra ID + RBAC data-plane

L’opzione più sicura è l’autenticazione Microsoft Entra ID con Azure RBAC applicato al data plane. Non ci sono segreti da distribuire: utenti, gruppi, service principal e managed identity ricevono ruoli come Storage Blob Data Reader, Storage Blob Data Contributor o Storage Blob Data Owner. Attenzione: i ruoli di control plane (es. Contributor, Owner) non concedono accesso ai dati Blob; servono i ruoli “Data”. Con questo modello ottieni Conditional Access, MFA e audit centralizzato. È possibile impostare allowSharedKeyAccess = false per disabilitare del tutto l’accesso via account key (e quindi anche service/account SAS), forzando solo Entra ID + user delegation SAS.

Protezione di rete: firewall e private endpoint

Anche con l’identità giusta, l’esposizione di rete conta. Lo storage firewall consente di negare l’accesso pubblico e ammettere solo IP/VNet selezionate (con service endpoint). Il private endpoint va oltre: assegna all’account un IP privato dentro la tua VNet tramite Azure Private Link, così il traffico non transita mai su Internet. Ricorda che ogni sotto-risorsa (blob, file, dfs…) richiede il proprio private endpoint e la relativa zona DNS privata. In scenari di data-protection tipici imposti Public network access = Disabled e accedi solo via private endpoint.

Key rotation e integrazione con Key Vault

Le chiavi non vanno lasciate statiche. Puoi:

  • Ruotarle manualmente alternando key1/key2, oppure
  • Delegare a Azure Key Vault con managed storage account keys, che rigenera e memorizza le chiavi automaticamente secondo una cadenza definita.

Per la crittografia a riposo, lo storage cripta sempre i dati; con customer-managed keys (CMK) la chiave risiede in Key Vault (o Managed HSM) e ne controlli tu il ciclo di vita. Le applicazioni dovrebbero recuperare segreti e connection string da Key Vault via managed identity, mai da file di configurazione.

Trappole tipiche d’esame

  • App deve leggere Blob senza gestire segreti → assegna una managed identity con ruolo Storage Blob Data Reader, non distribuire l’account key.
  • Serve un link temporaneo e revocabile a un Blob → user delegation SAS (firmata con Entra ID), non una service SAS con scadenza lunga e permessi ampi.
  • Ruotare la chiave senza interrompere i client → sposta i client su key2, rigenera key1, poi inverti: le due chiavi servono proprio a questo.
  • Massima sicurezza: nessun accesso via chiave condivisa → imposta allowSharedKeyAccess = false e accedi solo con Entra ID/user delegation SAS.
  • Traffico deve restare in rete privata, no Internet → private endpoint + DNS privato e Public network access = Disabled, non basta il firewall con regole IP.