Un account di archiviazione nasce raggiungibile da Internet e con la cifratura già attiva. Le due cose insieme spiegano dove sta il lavoro vero: non nell’accendere la crittografia, che non puoi nemmeno spegnere, ma nel chiudere la superficie di rete e nel decidere alla creazione le poche proprietà che dopo non si cambiano più.

Le scelte che non si rifanno dopo

La cifratura a riposo (SSE) è attiva su tutti gli account, usa AES a 256 bit in modalità GCM, copre blob, dischi, file, code e tabelle — metadati inclusi — in ogni livello di prestazioni e di accesso, archive compreso, e non è disattivabile. Non è quindi una voce da configurare: è il punto di partenza. Le domande utili vengono dopo.

La prima è chi possiede la chiave. Le chiavi gestite da Microsoft sono il default; le chiavi gestite dal cliente (CMK) vivono in Key Vault o in Managed HSM e coprono Blob e Azure Files, con ambito account, contenitore o blob tramite gli ambiti di crittografia. Le chiavi fornite dal cliente sono un’altra cosa ancora: viaggiano nella singola richiesta a Blob Storage. Se il requisito è la rotazione auditabile, MMK non basta — Microsoft ruota le proprie chiavi, ma non le governi tu.

La seconda è la crittografia dell’infrastruttura, il secondo strato con algoritmo e chiave distinti. Prerequisito nascosto e costoso da scoprire tardi: si abilita solo alla creazione dell’account. Stessa logica per il modello di distribuzione: solo Azure Resource Manager dà RBAC, identità gestite, autorizzazione Entra ID sui dati, blocchi e criteri.

Poi ci sono i due interruttori che chiudono il trasporto: Secure transfer required, che rifiuta ogni richiesta in HTTP (vale anche per SMB su Azure Files), e la versione minima di TLS portata a 1.2 o superiore. Vanno insieme: il primo impone il canale cifrato, il secondo esclude quelli deboli. Aggiungi la limitazione dell’ambito consentito per le operazioni di copia, che impedisce di spostare dati verso account di altri tenant a chi ha già i permessi sul piano dati.

Il firewall che non fa nulla: l’azione predefinita

Qui l’errore è ricorrente e silenzioso. Un account nuovo accetta connessioni da qualsiasi rete, e le regole di rete non hanno alcun effetto finché l’azione predefinita resta Allow. Puoi popolare cento regole IP e la porta rimane aperta a tutti. Il momento del passaggio a Deny è quindi il momento in cui l’account cambia comportamento, non quello in cui aggiungi le regole.

Portale: account > Sicurezza + rete > Rete > Gestisci
  Abilitato da tutte le reti | Abilitato da reti selezionate | Disabilitato | Protetto dal perimetro

az storage account update -g rg -n acct --default-action Deny
az storage account update -g rg -n acct --public-network-access Disabled
Update-AzStorageAccountNetworkRuleSet -ResourceGroupName rg -Name acct -DefaultAction Deny

Le regole di rete virtuale (fino a 400 per account) richiedono un endpoint di servizio sulla subnet, e qui c’è una scelta da fare consapevolmente: Microsoft.Storage raggiunge solo gli account nella stessa regione della rete virtuale, Microsoft.Storage.Global quelli in qualsiasi regione. Su una subnet puoi associarne uno solo: per passare all’altro devi prima rimuovere il primo. Effetto collaterale che rompe le configurazioni miste: quando la subnet ha l’endpoint di servizio, il traffico esce con un IP privato, quindi le regole IP che permettevano quella subnet smettono di valere.

Le regole IP (anch’esse fino a 400) accettano solo intervalli pubblici; per l’on-premises servono gli indirizzi affacciati a Internet, e con ExpressRoute gli IP NAT del Microsoft peering. Una SAS con IP firmato restringe il titolare del token, ma non gli concede nulla oltre le regole di rete. Dopo il salvataggio, le impostazioni possono impiegare fino a un minuto a diventare effettive.

Eccezioni: servizi attendibili contro istanze di risorsa

Con Deny attivo cadono anche i servizi Microsoft: Azure Backup, Log Analytics, Defender for Storage, la pipeline di diagnostica. L’eccezione «Consenti ai servizi Azure nell’elenco dei servizi attendibili» li riammette, ma è larga. La documentazione raccomanda le regole di istanza di risorsa: autorizzano una risorsa nominata e la sua identità gestita, quindi una superficie di fiducia molto più piccola. L’istanza deve stare nello stesso tenant dell’account, in qualsiasi sottoscrizione.

Il punto che si dimentica: passare il firewall non significa essere autorizzati. Per gli account senza namespace gerarchico devi comunque assegnare un ruolo Azure all’identità gestita della risorsa; con namespace gerarchico puoi in alternativa inserire quell’identità nelle ACL di directory o file. Rete e autorizzazione restano due filtri distinti, in serie.

Endpoint privati: fuori dal firewall

Un endpoint privato assegna all’account un IP della tua rete virtuale e porta il traffico sul backbone. Ne serve uno per servizio, cioè per sotto-risorsa di destinazione: blob, dfs, file, queue, table, web. Se usi Data Lake crea entrambi, dfs e blob, perché alcune operazioni vengono redirette e altre richiedono l’endpoint DFS.

Due comportamenti da tenere a mente. Il primo: creare un collegamento privato non chiude l’endpoint pubblico, devi comunque impostare l’azione predefinita su Deny o disabilitare l’accesso pubblico. Il secondo, speculare: il firewall governa solo l’endpoint pubblico, quindi non serve alcuna regola per la rete virtuale che ospita l’endpoint privato, e quel traffico passa anche con l’accesso pubblico disabilitato. Sul DNS, il record diventa un alias nella sottozona privatelink — ma i client devono continuare a usare il nome normale dell’account, mai l’URL privatelink.