Key Vault sembra il posto dove si mettono le password, ed è per questo che viene configurato male: i tre tipi di oggetto hanno cicli di vita diversi, il modello di autorizzazione ha appena cambiato default, e il rischio più concreto, i segreti fuori dal vault, non si vede dal vault.

Chiavi, segreti e certificati: dove finisce l’analogia

Sono “oggetti” indirizzati da una URL, con o senza versione; senza versione significa “l’ultima”.

https://nomevault.vault.azure.net/secrets/nome-segreto/versione
https://nomehsm.managedhsm.azure.net/keys/nome-chiave/versione

Un Managed HSM ospita solo chiavi: segreti e certificati vivono solo nei vault. E i certificati non sono un silo separato — quando ne crei uno, Key Vault crea anche una chiave e un segreto con lo stesso nome. Il ruolo Key Vault Secrets User legge anche la parte segreta di un certificato con chiave privata: se pensavi di dare “solo le password”, hai dato le chiavi private.

Le chiavi hanno una rotation policy propria: intervallo di rotazione (minimo sette giorni dalla creazione e sette dalla scadenza), expiry time e un evento Event Grid di prossima scadenza. Serve Key Vault Crypto Officer (con le access policy: Rotate, Set e Get Rotation Policy).

Due trappole: i servizi devono puntare alla URI senza versione, altrimenti la nuova non la vedono mai; e la rotazione riavvolge le chiavi di cifratura dati senza ricifrare i dati, quindi la vecchia versione resta abilitata finché il re-wrap non è finito. Le chiavi importate da un HSM on-premise non si autoruotano: lì configuri la notifica e ruoti a mano.

Il default è cambiato: RBAC, non access policy

Dalla versione API 2026-02-01 i vault nuovi nascono con enableRbacAuthorization a true; quelli esistenti non cambiano modello, nemmeno aggiornandoli con la nuova API. Conta di più il secondo pezzo: le versioni API del control plane precedenti vanno in ritiro il 27 febbraio 2027, quindi ARM, Bicep, Terraform e REST vanno aggiornati comunque.

La raccomandazione non è estetica: con le access policy chiunque abbia Microsoft.KeyVault/vaults/write — Contributor, Key Vault Contributor — si assegna da solo l’accesso al piano dati. Con RBAC concedere accesso resta a Owner e User Access Administrator e può passare da PIM.

Nel piano dati i ruoli sono separati per oggetto e per verbo: Secrets User legge, Secrets Officer amministra, idem per Crypto e Certificates; Key Vault Reader vede solo metadati; Purge Operator elimina definitivamente. Key Vault Contributor è control plane puro: gestisce il vault e non legge un segreto. Le assegnazioni sul singolo segreto non isolano i team: la regola è un vault per applicazione, ambiente e regione. Convertire un vault vivo a RBAC invalida in blocco le access policy: mappa i ruoli prima.

Cancellare non basta, recuperare non ripristina tutto

Il soft delete è attivo di default sui vault nuovi e non si disattiva più. La retention va da 7 a 90 giorni, default 90, e si sceglie solo alla creazione. La purge protection invece non è attiva di default: accendendola nessuno elimina definitivamente prima della scadenza della retention, ed è quello che pretendono i servizi Azure con chiavi gestite dal cliente.

Il dettaglio che rompe i ripristini: soft-deletando un vault vengono cancellati anche i servizi integrati (assegnazioni RBAC e sottoscrizioni Event Grid) e recuperare il vault non le ricrea.

Il backup è per oggetto: l’intero vault in un’operazione non si fa. Il blob è cifrato e si ripristina solo nella stessa sottoscrizione e geografia Azure. Una copia ripristinata è indipendente: disabilitare l’originale non la revoca. Quindi tieni strettissimi i permessi di backup e restore e allerta sulle operazioni KeyBackup e SecretBackup.

I segreti che stanno fuori dal vault: scansione con Defender CSPM

La scansione dei segreti sulle macchine è agentless: uno snapshot del disco analizzato senza agente e senza impatto sulle prestazioni. Vale con Defender CSPM o con Defender for Servers Plan 2, su VM Azure e istanze AWS e GCP; per le risorse di deployment infrastructure-as-code e per i repository Azure DevOps serve invece Defender CSPM.

Trova chiavi private SSH, stringhe di connessione SQL, PostgreSQL, MySQL, Cosmos DB e storage account, token SAS, access key AWS, client secret Entra, PAT GitHub e Azure DevOps. Verifica anche se una chiave SSH è davvero usabile per muoversi lateralmente: le altre restano marcate come non verificate.

Si legge in quattro posti: inventario, la raccomandazione “Machines should have secrets findings resolved”, i percorsi di attacco e il cloud security explorer.

Defender for Key Vault è un piano, non un’impostazione del vault

Si abilita per sottoscrizione, non per vault:

Microsoft Defender for Cloud > Environment settings > sottoscrizione > Defender plans > Key Vault: On

Rileva accessi anomali al piano dati; gli alert compaiono nella pagina Security del vault, nelle Workload protections e negli alert di Defender for Cloud.

Ogni alert porta Object ID e UPN o indirizzo IP, ma alcuni campi mancano per costruzione: un’applicazione non ha UPN, il traffico da fuori Azure non ha Object ID. E poiché le VM Azure hanno IP Microsoft, un IP Microsoft non vuol dire “è Microsoft”.

La regola che in produzione si ignora: non chiudere l’alert perché riconosci l’utente o l’applicazione — il servizio esiste per intercettare credenziali rubate, e per il rumore ci sono le regole di soppressione. Identifica la sorgente, abilita il firewall del vault se l’IP è sconosciuto, rimuovi il principal non autorizzato, misura l’impatto dalla pagina Security — che elenca oggetti e orari — e ruota tutto ciò a cui ha avuto accesso.