Azure Key Vault è il servizio gestito per centralizzare la custodia dei dati sensibili di un’applicazione, isolandoli dal codice e dalla configurazione. Per l’AZ-204 devi saper scegliere il tipo di oggetto giusto, il modello di autorizzazione corretto e il pattern di accesso senza credenziali.

I tre tipi di oggetti

Un vault ospita tre categorie distinte, ciascuna con il proprio piano dati e le proprie API:

  • Secret: valori arbitrari opachi (connection string, password, token API). Il vault li conserva e restituisce così come sono; non ne conosce la semantica.
  • Key: chiavi crittografiche (RSA, EC) usate per operazioni wrap/unwrap, sign/verify, encrypt/decrypt direttamente nel vault. La chiave privata non lascia mai il confine di sicurezza — è l’opzione corretta per scenari come Always Encrypted, CMK (customer-managed keys) su Storage/SQL o firma. Per requisiti FIPS 140-2 Level 3 usi la SKU Premium con backing HSM.
  • Certificate: oggetto composito che unisce una chiave e un certificato X.509, con gestione del ciclo di vita (emissione, rinnovo, integrazione con CA come DigiCert). Un certificato genera automaticamente un secret e una key collegati.

Regola pratica: se ti serve usare materiale crittografico senza estrarlo, scegli una key; se devi solo leggere un valore in chiaro nell’app, un secret.

Autorizzazione: RBAC vs Access Policy

Ogni vault usa un solo modello di autorizzazione sul piano dati, scelto a livello di risorsa:

  • Azure RBAC (raccomandato): i permessi sono ruoli Entra ID assegnabili a subscription/resource group/vault/singolo oggetto, con audit centralizzato in Entra. Ruoli tipici: Key Vault Secrets User (lettura secret in runtime), Key Vault Secrets Officer (gestione), Key Vault Administrator.
  • Vault access policy (legacy): lista di permessi per-principal definita nel vault stesso, senza granularità sul singolo oggetto e senza ereditarietà dallo scope Azure.

Il piano di gestione (creare/eliminare il vault) è invece sempre governato da RBAC, indipendentemente dal modello del piano dati.

Accesso senza credenziali con managed identity

Il pattern corretto è non memorizzare mai una credenziale per accedere al vault. Assegni una managed identity (di preferenza user-assigned, riusabile tra più risorse) ad App Service, Functions, Container Apps o VM, e le concedi il ruolo Key Vault Secrets User. Nel codice usi DefaultAzureCredential dell’SDK Azure.Identity, che in cloud risolve automaticamente il token della managed identity:

var client = new SecretClient(
    new Uri("https://myvault.vault.azure.net/"),
    new DefaultAzureCredential());

Nessun secret circola per leggere gli altri secret: è il principio di eliminazione della “credenziale zero”.

Key Vault reference nelle app settings

Per App Service e Functions esiste un’integrazione dichiarativa: metti nell’app setting il riferimento, non il valore. La piattaforma risolve il secret al runtime usando l’identità dell’app:

@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/DbConn/)

L’app legge la variabile d’ambiente normalmente e non conosce Key Vault. Perché funzioni servono: managed identity attiva sull’app, permesso di lettura (RBAC o access policy) sul vault e, se il vault è protetto da firewall, l’accesso di rete o l’esenzione “Allow trusted Microsoft services”. Omettere la versione nell’URI fa sì che l’app segua sempre la versione corrente del secret.

Best practice operative

  • Soft delete: sempre attivo (non disattivabile); un vault o oggetto eliminato resta recuperabile per il periodo di retention (7-90 giorni).
  • Purge protection: impedisce la cancellazione definitiva prima della scadenza della retention — obbligatorio quando il vault ospita CMK, per evitare perdita irreversibile dei dati cifrati.
  • Rotazione: sfrutta le versioni degli oggetti e le rotation policy; per i secret gestiti internamente puoi automatizzare via Event Grid (evento SecretNearExpiry) + Functions.
  • Preferisci RBAC e identità user-assigned per una governance pulita.

Trappole tipiche d’esame

  • Connection string messa in chiaro nelle app settings → sbagliato: usa un Key Vault reference @Microsoft.KeyVault(...), così il valore resta nel vault e non appare nella configurazione.
  • Vault con RBAC e access policy usati insieme sullo stesso vault → incoerente: il piano dati adotta un solo modello; se è su RBAC, aggiungere access policy non concede alcun permesso.
  • App che riceve 403/Forbidden leggendo un secret pur avendo la managed identity → manca l’assegnazione del ruolo Key Vault Secrets User (o l’access policy), non un problema di autenticazione.
  • Serve cifrare/firmare senza esporre la chiave privata → scegli un oggetto key con operazioni nel vault, non un secret che contiene la chiave.
  • Vault che ospita CMK e va protetto da cancellazioni accidentali → abilita soft delete + purge protection, non solo un lock sulla risorsa.