Chiuso il perimetro di rete, resta la domanda che decide il resto: con quale credenziale è firmata la richiesta. L’ordine giusto è prima togliere la chiave simmetrica, poi mettere il rilevamento minacce su ciò che resta.

Shared Key: la chiave che nessuno può revocare

Di default ogni richiesta può essere autorizzata con credenziali Entra ID oppure con la chiave dell’account. La proprietà AllowSharedKeyAccess non è impostata di default e non restituisce alcun valore finché non la tocchi: l’account accetta Shared Key sia quando è null sia quando è true. Portandola a false, le richieste firmate con la chiave falliscono con 403.

Il divieto non colpisce tutte le SAS allo stesso modo: service SAS e account SAS sono firmate con Shared Key e vengono negate su tutti i servizi, la user delegation SAS è autorizzata da Entra ID e continua a funzionare. Attenzione alle metriche: il filtro SAS non distingue i tipi, quindi un picco «SAS» non dice che stai per rompere qualcosa.

Prima di premere l’interruttore, tre punti. Le Conditional Access su un account di archiviazione richiedono proprio che Shared Key sia vietata: è un prerequisito, non un effetto collaterale. Il portale accede alle condivisioni di Azure Files in Shared Key: senza le assegnazioni RBAC corrette, quei file non sono più raggiungibili. E i file di Cloud Shell, che vivono in una condivisione, diventano inaccessibili.

Il metodo di transizione, nell’ordine:

Chi sta ancora usando la chiave (Log Analytics):
  StorageBlobLogs
  | where AuthenticationType in ("AccountKey", "SAS") and TimeGenerated > ago(7d)
  | summarize count() by CallerIpAddress, UserAgentHeader, AccountName
  | top 10 by count_ desc

Portale: account > Impostazioni > Configurazione > Consenti accesso con chiave = Disabilitato
Criterio: «Storage accounts should prevent shared key access», prima in Audit poi in Deny

Un’ultima trappola sui ruoli: Owner, Contributor e Storage Account Contributor non danno accesso ai dati via Entra ID, ma includono listkeys — e con le chiavi si leggono tutti i dati. Assegnare i ruoli dati (Storage Blob Data Reader, Storage Queue Data Contributor) all’ambito più stretto — contenitore, coda, condivisione — serve a poco se il piano di gestione resta largo.

Le tre SAS e i criteri di accesso archiviati

La user delegation SAS è firmata con una chiave di delega ottenuta da Entra ID: per crearla serve un ruolo che includa l’azione Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey, e revocando la chiave di delega si invalidano in blocco tutte le SAS emesse da essa. La service SAS delega su un solo servizio, l’account SAS su più servizi e anche su operazioni a livello di servizio: entrambe firmate con la chiave dell’account, e se compromesse si revocano solo rigenerando la chiave — cioè rompendo tutto il resto.

Da qui l’unica via di mezzo praticabile: il criterio di accesso archiviato. Si definisce sul contenitore (o coda, tabella, condivisione) e porta inizio, scadenza e permessi fuori dal token; la SAS associata li eredita, e modificando o eliminando il criterio le revochi tutte senza toccare le chiavi. I due limiti da sapere: vale solo per la service SAS — user delegation SAS e account SAS devono essere ad hoc — e se ne possono definire al massimo cinque per contenitore.

Due dettagli sostanziali: la generazione di una SAS non è auditabile, chi può firmarla lo fa all’insaputa del proprietario dell’account; e il criterio di scadenza SAS avvisa e scrive nei log quando qualcuno supera l’intervallo consigliato.

Defender for Storage: che cosa si accende, che cosa si paga

Il piano è agentless e si paga per numero di account protetti. Abilitarlo sulla sottoscrizione è la scelta consigliata — copre anche gli account futuri, con esclusioni puntuali; dal piano classico occorre migrare per avere le funzioni attuali. Il monitoraggio delle attività non richiede log diagnostici: Defender analizza già la telemetria di piano dati e di controllo di Blob, Azure Files e Data Lake, e rileva anche gli accessi con SAS trapelate o troppo permissive, cioè entità senza identità.

Le due funzioni configurabili si comportano in modo opposto sul costo. La rilevazione minacce sui dati sensibili si attiva senza costo aggiuntivo: motore agentless a campionamento, integrato con i tipi di informazioni sensibili e le etichette di Microsoft Purview, primi risultati entro 24 ore, riscansioni settimanali. Per Azure Files richiede Defender CSPM.

La ricerca malware invece si paga al GB analizzato ed esiste solo nel piano nuovo. Da non confondere con l’analisi della reputazione degli hash, presente in tutti i piani ma cieca sulle condivisioni SMB e sui blob creati con Put Block e Put Block List.

Prerequisiti: ruolo Owner o Contributor; provider Microsoft.EventGrid registrato
Trigger: eventi BlobCreated e BlobRenamed (PutBlock e AppendFile da soli non scatenano nulla)
Tetto predefinito: 10.000 GB al mese per account, stop con deriva fino a 20 GB, reset a mezzanotte UTC
Filtri di esclusione: fino a 24 valori per prefisso, suffisso o dimensione
Avvisi sul tetto: al 75% e al raggiungimento

Il malinteso più costoso: la scansione non blocca e non cancella da sola. Restituisce l’esito con tag di indice del blob, avvisi in Defender for Cloud, eventi Event Grid e voci in Log Analytics; la rimozione la fai tu, con l’eliminazione temporanea dei blob dannosi o con un’automazione Event Grid più Logic Apps. Se il flusso applicativo dipende dall’esito, ricorda che la durata varia col file e col carico (limite: 50 GB al minuto per account).