Key Vault è uno dei pochi servizi Azure in cui diverse scelte fatte al momento della creazione sono definitive. Conviene sapere quali.

Deploy: il nome è globale e il tier si sceglie subito

Un vault vive in una regione e risponde su un URI di questa forma; il nome è quindi univoco a livello globale.

https://nome-del-vault.vault.azure.net/

I tier sono due. Standard cifra con librerie software validate FIPS 140 Level 1. Premium aggiunge chiavi protette da HSM — RSA-HSM, EC-HSM, OCT-HSM — generate in HSM Marvell LiquidSecurity validati FIPS 140-3 Level 3, che non lasciano mai il confine dell’HSM. Se il requisito di conformità parla di HSM, Standard non basta.

Sul dimensionamento la raccomandazione ufficiale è netta: un vault per applicazione, per regione e per ambiente. Il vault è un confine di sicurezza; mettere tutto insieme allarga il raggio d’esplosione di un incidente. E non è un archivio dati: niente contenuti dei clienti, niente configurazione applicativa, e i certificati vanno salvati come oggetti certificate, non come segreti.

Impostazioni: soft delete acceso, purge protection spento

Su un vault nuovo il soft delete è attivo per impostazione predefinita e non può più essere disattivato. La retention va da 7 a 90 giorni, il default è 90, si imposta solo alla creazione e dopo non si tocca più. Durante quel periodo il nome del vault resta prenotato e non è riutilizzabile.

La purge protection invece non è attiva per default. Richiede il soft delete e, una volta accesa, non si spegne: nessuno può fare purge prima della scadenza della retention. Molti servizi Azure che usano customer-managed key, Storage in testa, la pretendono.

Due cose che quasi nessuno si aspetta. La prima: quando un vault finisce in soft delete, i servizi integrati vengono eliminati — assegnazioni di ruolo RBAC e sottoscrizioni Event Grid comprese — e il ripristino del vault non le ricrea. Vanno rifatte a mano. La seconda: cancellare davvero un oggetto richiede due operazioni distinte, delete e poi purge, e il purge richiede un permesso apposito (per esempio il ruolo Key Vault Purge Operator).

Fra le impostazioni c’è poi la rotation policy delle chiavi, che gestisce un Key Vault Crypto Officer: genera una nuova versione della chiave, con intervallo minimo di sette giorni. I servizi che la consumano devono usare un URI senza versione per seguirla. E attenzione a che cosa fa davvero: riavvolge le data encryption key con la nuova versione, non ricifra i dati, quindi entrambe le versioni devono restare abilitate finché il re-wrap non è completo.

Accesso: RBAC è ora il default, e Contributor è una scorciatoia

Key Vault ha due piani separati. Il control plane, su management.azure.com, gestisce il vault come risorsa e usa Azure RBAC. Il data plane, sull’URI del vault, gestisce chiavi, segreti e certificati e usa Azure RBAC oppure le access policy legacy. Un permesso su un piano non vale sull’altro.

La novità da conoscere: a partire dalla versione API 2026-02-01, per i vault nuovi il modello predefinito è Azure RBAC, cioè enableRbacAuthorization a true. I vault esistenti non cambiano, e quelli con la proprietà a null continuano con le access policy. Tutte le versioni API del control plane precedenti alla 2026-02-01 vanno in ritiro il 27 febbraio 2027: template ARM, Bicep, Terraform e SDK vanno aggiornati.

I ruoli data plane da riconoscere: Key Vault Administrator (tutto sui dati, non sulla risorsa né sulle assegnazioni), Secrets Officer e Secrets User, Crypto Officer e Crypto User, Certificates Officer e Certificate User, Reader, Purge Operator, più Key Vault Data Access Administrator per delegare solo l’assegnazione di questi ruoli. Key Vault Contributor è control plane e non dà accesso ai dati — ma nel modello access policy chi ha Contributor può concedersi l’accesso ai dati da solo, scrivendosi una access policy.

Due avvertenze prima di migrare: passare al modello RBAC invalida tutte le access policy, quindi senza i ruoli equivalenti già assegnati provochi un’interruzione; e cambiare modello richiede un Microsoft.Authorization/roleAssignments/write non ristretto, cioè Owner o User Access Administrator. Infine, assegnare ruoli sul singolo segreto non isola team diversi: le operazioni amministrative richiedono comunque permessi a livello di vault.

Firewall: disabilitato per default, e non tocca il control plane

Su un vault nuovo il firewall è disabilitato: tutte le applicazioni e i servizi Azure possono inviare richieste. Restano autenticazione e autorizzazione Entra, ma la superficie di rete è aperta.

Key Vault > Networking > Firewalls and virtual networks

Le opzioni sono tre: accesso pubblico da tutte le reti, accesso pubblico solo da reti virtuali e indirizzi IP selezionati, oppure accesso pubblico disabilitato con soli private endpoint. L’eccezione “Allow trusted Microsoft services to bypass this firewall” copre solo i servizi dell’elenco ufficiale — Azure DevOps, per esempio, non c’è — e continua a valere anche quando l’accesso pubblico è disabilitato. Solo l’associazione a un Network Security Perimeter la annulla.

I limiti: 200 regole di rete virtuale e 1000 regole IPv4, solo indirizzi pubblici (gli intervalli RFC 1918 sono rifiutati), solo IPv4.

Il punto che vale l’esame: le regole del firewall si applicano solo al data plane. Il control plane non ne è soggetto, incluso il deployment di segreti e chiavi via template ARM, che passa da management.azure.com. Conseguenza pratica dal portale: vedi il vault ma non riesci a elencarne i segreti se il tuo client non è consentito, e lo stesso vale per il Key Vault Picker usato da altri servizi. Ultima nota, che genera falsi allarmi: disabilitare l’accesso pubblico non rimuove i record DNS pubblici del vault, che continuano a risolversi per progetto.