Ogni applicazione moderna ha bisogno di segreti per funzionare: password di database, connection string, chiavi API, certificati TLS. Il problema nasce da come questi segreti vengono conservati. La pratica più pericolosa e diffusa è l’hardcoding, cioè scrivere le credenziali direttamente nel codice sorgente o in file di configurazione. Se quel codice finisce in un repository Git, in un log o in un backup non protetto, la credenziale è compromessa e va ruotata ovunque. Azure risponde a questo problema con due servizi complementari: Azure Key Vault per centralizzare i segreti e le managed identity per accedervi senza a loro volta gestire altre credenziali.

Azure Key Vault

Azure Key Vault è il servizio gestito di Azure che centralizza in un contenitore sicuro tre tipi di oggetti sensibili:

  • Chiavi crittografiche (keys): chiavi asimmetriche/simmetriche usate per operazioni di encryption, firma o wrapping. La chiave non lascia mai il vault; le operazioni avvengono al suo interno.
  • Segreti (secrets): valori testuali come password, connection string, token e chiavi API.
  • Certificati (certificates): certificati TLS/SSL, con supporto al rinnovo automatico tramite CA integrate.

I vantaggi chiave per l’esame sono la centralizzazione (un unico punto da proteggere, monitorare e ruotare invece di credenziali sparse), il controllo degli accessi granulare, la rotazione semplificata e l’audit logging completo di ogni accesso tramite integrazione con Microsoft Purview e Azure Monitor.

Sicurezza e livelli di protezione

Key Vault protegge il materiale crittografico a riposo. È disponibile in due tier: Standard, dove le chiavi sono protette a livello software, e Premium, che aggiunge protezione tramite hardware security module (HSM) validati FIPS 140-2 Level 2/3. L’accesso al vault è governato da Azure RBAC (o dalle legacy access policy) e le identità che vi accedono sono autenticate tramite Microsoft Entra ID. Questo significa che nessuno accede a un segreto senza prima essere autenticato e autorizzato dal control plane di identità di Azure.

Managed identity

Centralizzare i segreti in Key Vault risolve metà del problema, ma resta una domanda: come fa l’applicazione ad autenticarsi verso Key Vault senza a sua volta possedere una credenziale hardcoded? La risposta è la managed identity.

Una managed identity è un’identità in Microsoft Entra ID associata automaticamente a una risorsa Azure (una Virtual Machine, una Function App, un’App Service, un container). Azure gestisce interamente il ciclo di vita delle credenziali sottostanti: creazione, rotazione ed eliminazione avvengono in modo trasparente, senza che uno sviluppatore debba mai vedere o gestire una password. Esistono due tipi:

  • System-assigned: legata al ciclo di vita di una singola risorsa; nasce e muore con essa.
  • User-assigned: risorsa Entra ID indipendente, riutilizzabile su più servizi.

Lo scenario tipico: managed identity + Key Vault

Lo scenario che l’esame ti chiederà di riconoscere è la combinazione dei due servizi:

  1. Un’applicazione ospitata su una VM o App Service ha una managed identity abilitata.
  2. A quella identità viene concesso l’accesso in lettura ai segreti del Key Vault (via Azure RBAC).
  3. A runtime l’applicazione richiede un token a Microsoft Entra ID usando la managed identity e con quel token legge la connection string direttamente dal vault.

Il risultato: nessuna credenziale nel codice, nessun segreto nei file di configurazione. Il ciclo si chiude perché l’unica “credenziale” è l’identità gestita da Azure, che non è mai visibile né gestita manualmente.

Trappole tipiche d’esame

  • Scenario: uno sviluppatore ha messo la password del database nel codice sorgente e vuoi eliminarla. → Risposta giusta: sposta il segreto in Azure Key Vault e recuperalo a runtime.
  • Scenario: un’app su una VM deve accedere a Key Vault senza credenziali memorizzate. → Risposta giusta: abilita una managed identity sulla VM e concedile l’accesso al vault (non una service principal con secret gestito a mano).
  • Scenario: devi conservare chiavi crittografiche con protezione hardware certificata FIPS. → Risposta giusta: Azure Key Vault Premium con HSM, non lo Standard tier.
  • Scenario: la domanda distingue tra keys, secrets e certificates. → Risposta giusta: password e connection string sono secrets; le chiavi di encryption sono keys; i certificati TLS sono certificates.
  • Scenario: “gestire manualmente la rotazione delle credenziali della managed identity”. → Trappola: è automatica, Azure gestisce tutto; nessuna rotazione manuale è richiesta.