Microsoft AZ-500: Gestione delle chiavi, crittografia e certificati — Guida allo studio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-500 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure Security Engineer Associate AZ-500 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La gestione delle chiavi su Azure è incentrata su Azure Key Vault e Azure Managed HSM. Questi servizi forniscono un’archiviazione sicura del materiale crittografico, API coerenti e operazioni verificabili che sono alla base della crittografia at-rest, in-transit e a livello di applicazione. L’obiettivo operativo è separare la custodia delle chiavi dall’ambiente di esecuzione delle applicazioni, minimizzare il raggio d’impatto con autorizzazioni e networking mirati, e imporre la recuperabilità e la rotazione per ridurre il rischio associato a segreti di lunga durata.

Architettura e Autorizzazione di Azure Key Vault e Managed HSM

Architettura di Azure Key Vault

• Composizione del servizio: front-end multi-tenant, partizioni regionali per il piano dati, isolamento per-tenant e autenticazione basata su Azure AD. Le chiavi sono protette via software (livello Standard) o protette da HSM (livello Premium). I segreti e i certificati sono sempre protetti via software.
• Livelli: Standard (chiavi software) per uso generico ed efficienza dei costi; Premium (chiavi supportate da HSM) quando è richiesta una protezione equivalente a FIPS 140-2 Livello 2/3 o un perimetro HSM dedicato per il materiale crittografico. Scegliere il livello Premium per requisiti normativi o quando si utilizzano chiavi con “RSA-HSM” o “EC-HSM”.
• Eliminazione temporanea e protezione dall’eliminazione definitiva: L’eliminazione temporanea (soft delete) è sempre attiva con una conservazione configurabile (7–90 giorni, comunemente 90). La protezione dall’eliminazione definitiva (purge protection), se abilitata, impedisce la cancellazione permanente del vault o degli oggetti fino alla scadenza del periodo di conservazione, anche da parte di utenti con privilegi elevati. Logica operativa: abilitare la protezione dall’eliminazione definitiva su qualsiasi vault che supporta chiavi gestite dal cliente (CMK). Senza di essa, un’eliminazione accidentale o malevola potrebbe rendere irrecuperabili i dati dipendenti (ad es. storage o database crittografati con quella chiave).
• Recupero: Gli oggetti eliminati dal vault possono essere elencati e recuperati; è supportato il recupero a livello di vault. I backup producono blob crittografati che possono essere ripristinati su vault compatibili nella stessa regione e cloud di Azure. Logica: esportare periodicamente i backup delle chiavi e metterli in sicurezza separatamente; testare i ripristini per convalidare l’RTO.

Modello di autorizzazione

• Modelli di autorizzazione: Criteri di accesso del vault (legacy) vs Azure RBAC (consigliato).
  • Criteri di accesso: definiti per ogni vault; concedono autorizzazioni granulari per chiavi, segreti e certificati. Ideali quando sono necessari diritti di runtime molto restrittivi e specifici per tipo di oggetto per un piccolo insieme di principal.
  • Azure RBAC: impostare il modello di autorizzazione del vault su “Controllo degli accessi in base al ruolo di Azure” per utilizzare i ruoli del piano dati RBAC. Vantaggi: ambito a livello di sottoscrizione/gruppo di risorse/vault; assegnazioni idonee per PIM; governance e auditing centralizzati. Consigliato per nuove implementazioni e per operazioni amministrative.
• Ruoli predefiniti del vault (esempi): Key Vault Administrator (gestione completa), Key Vault Crypto Officer (gestione delle chiavi ma non dei criteri di accesso), Key Vault Secrets Officer, Key Vault Certificates Officer, Key Vault Reader. Guida operativa:
  • Utilizzare RBAC (ad es. Key Vault Administrator) quando si delega la configurazione dei modelli di accesso e delle ACL di rete.
  • Utilizzare un criterio di accesso o un ruolo RBAC del piano dati come Key Vault Certificates Officer per l’inserimento/eliminazione di certificati con il minimo privilegio in un singolo vault.
• Progettazione dell’ambito: Preferire l’assegnazione di RBAC a livello di vault per evitare privilegi eccessivi. Utilizzare l’ambito del gruppo di risorse solo quando più vault condividono team di operatori identici; evitare assegnazioni a livello di sottoscrizione per l’accesso in fase di esecuzione.

Managed HSM

• Architettura e domini di sicurezza: Managed HSM è un cluster HSM single-tenant, convalidato FIPS 140-2 Livello 3, per ogni cliente. Un dominio di sicurezza protegge la portabilità del materiale crittografico del cluster; il backup/ripristino tra cluster richiede un quorum di chiavi private del dominio di sicurezza. Logica: generare e depositare le chiavi del dominio presso custodi distinti; testare il ripristino su un HSM di DR.
• Modello di ruolo: Integrato con Azure RBAC. I ruoli includono Managed HSM Administrator, Crypto Officer, Crypto User e Reader. Separazione dei compiti: gli amministratori gestiscono il cluster; i crypto officer gestiscono le chiavi; i crypto user utilizzano le chiavi per le operazioni.
• Alta disponibilità: Ridondanza a livello di regione con più partizioni HSM e un servizio supportato da SLA; ridondanza di zona disponibile nelle regioni supportate. Per il disaster recovery tra regioni, fare affidamento sui backup + dominio di sicurezza.
• Casi d’uso: Elaborazione di pagamenti, firma del codice (code signing), wrapping di chiavi per la crittografia a involucro e carichi di lavoro regolamentati che richiedono perimetri HSM di Livello 3.

Oggetti e ciclo di vita: chiavi, segreti, certificati e rotazione

Chiavi, segreti, certificati

• Chiavi: per operazioni crittografiche (firma, verifica, wrapping/unwrapping, crittografia/decrittografia). Scegliere il tipo/dimensione della chiave in base alla robustezza dell’algoritmo e alle prestazioni (es. RSA 3072/4096 per la conformità, o ECC P-256/P-384 per le prestazioni).
• Segreti: byte/stringhe arbitrarie come password, stringhe di connessione e token API. Non utilizzati per operazioni crittografiche.
• Certificati: X.509 con chiavi private. Memorizzati sia come oggetto certificato sia come segreto corrispondente (PFX/PEM). Utili per i cicli di vita di TLS/MTLS e della firma del codice.

Operazioni del ciclo di vita e rotazione

• Controllo delle versioni: ogni impostazione o importazione genera una versione immutabile. Le applicazioni dovrebbero fare riferimento a segreti con versione per un comportamento deterministico o a URI senza versione per il recupero automatico della versione più recente, a seconda delle esigenze di gestione delle modifiche.
• Strategie di rotazione:
  • Chiavi: preferire URI di chiave senza versione per i servizi Azure che li supportano (es. Storage, SQL TDE, segreti gestiti da AKV). Eseguire la rotazione aggiungendo una nuova versione; i servizi si ricollegano automaticamente quando supportato. Se un servizio richiede una versione bloccata, automatizzare un passaggio di riconfigurazione. Imporre la rotazione con le policy di rotazione di AKV e gli avvisi.
  • Segreti: eseguire la rotazione tramite Azure Automation, Functions o Logic Apps, attivati da notifiche di Event Grid, oppure utilizzare la rotazione nativa del provider (es. rotazione di SAS o password di database). Evitare segreti statici a lunga durata sostituendoli con identità gestite ove possibile.
  • Certificati: definire policy per i certificati con “azioni del ciclo di vita” per il rinnovo automatico prima della scadenza; utilizzare autorità di certificazione (issuer) integrate per un rinnovo automatico senza intervento manuale.

Gestione dei certificati

• Importazione/generazione: importare PFX/PEM esistenti (con chiave privata) o generare una CSR e far completare l’emissione a Key Vault con una CA configurata.
• Rinnovo automatico e autorità di certificazione (issuer): configurare autorità di certificazione come DigiCert, GlobalSign o una CA Microsoft aziendale tramite Key Vault. Abilitare il rinnovo automatico con soglie di notifica e rinnovo.
• Integrazione con le applicazioni:
  • App Service e Functions: utilizzare riferimenti a Key Vault con identità gestita; la piattaforma sincronizza automaticamente i segreti ruotati.
  • Application Gateway/WAF: fare riferimento all’ID del segreto del certificato da Key Vault; il Gateway rileva automaticamente le nuove versioni.
  • AKS: montare i certificati tramite il driver CSI Secrets Store e il provider Azure Key Vault.

Esempio di assegnazione RBAC per operazioni sui certificati con privilegi minimi:

az role assignment create \
  --assignee <userObjectId> \
  --role "Key Vault Certificates Officer" \
  --scope $(az keyvault show -n kv-prod --query id -o tsv)

Sicurezza di rete e integrazione dei servizi

Networking di Key Vault

• Regole del firewall: impostare su Reti selezionate per limitare l’accesso a origini approvate. Motivazione: impedisce il traffico proveniente da Internet anche con token validi.
• Endpoint di servizio di rete virtuale: consentire il traffico da subnet specifiche senza IP privati. Semplice da abilitare e riduce l’esposizione. Utilizzare quando è necessario un isolamento rapido e non sono richieste modifiche al DNS.
• Endpoint privati: assegnare un IP privato al vault nella VNet per una connettività realmente privata. Bloccare l’accesso dalla rete pubblica. Motivazione: controllo più robusto contro l’esfiltrazione dei dati, richiesto in ambienti ad alta affidabilità e quando l’accesso a Internet in uscita è limitato.
• Servizi attendibili: l’opzione “Consenti servizi Microsoft attendibili” consente a specifici servizi Azure di raggiungere il vault nonostante le restrizioni di rete. Richiesto per scenari come la scansione delle chiavi di crittografia di Storage durante la rotazione. Abilitare in modo restrittivo e documentare le dipendenze.

Chiavi gestite dal cliente (CMK) e URI delle chiavi

• Servizi supportati: Azure Storage, SQL Database (TDE), Synapse, Databricks, crittografia dei segreti at-rest di AKS, App Configuration, Event Hubs, Service Bus e Managed Disks tramite Disk Encryption Set.
• Strategia per gli URI delle chiavi:
  • URI senza versione: da preferire quando il servizio supporta il ricollegamento automatico alle nuove versioni della chiave; consente una rotazione trasparente senza aggiornamenti del servizio.
  • URI con versione: richiesto da alcuni servizi; automatizzare un aggiornamento della configurazione del servizio legato agli eventi di rotazione.
• Pattern di rotazione:
  • Rotazione graduale: creare una nuova versione della chiave; convalidare l’accesso da parte del servizio; monitorare gli errori; quindi, opzionalmente, disabilitare le versioni precedenti dopo un periodo di sicurezza.
  • Guidato dagli eventi: utilizzare Event Grid su eventi di nuova versione della chiave per attivare flussi di lavoro di convalida o riconfigurazione del servizio.

Integrazione della crittografia envelope

• I servizi Azure utilizzano una chiave di crittografia dei dati (DEK) localmente (es. AES-256) e una chiave di crittografia della chiave (KEK) in Key Vault/HSM per eseguire il wrapping della DEK. A livello operativo, garantire la disponibilità della KEK e l’accesso di rete, poiché la perdita o il blocco dell’accesso possono arrestare le operazioni del servizio.

Esempio: eseguire il wrapping di una DEK con una chiave AKV

# base64-encode a 32-byte DEK; wrap using RSA-OAEP
az keyvault key wrap-key \
  --vault-name kv-prod \
  --name app-kek \
  --algorithm RSA-OAEP \
  --value $(openssl rand -base64 32)

Crittografia, opzioni per i dati a riposo e igiene dei segreti

Concetti fondamentali di crittografia

• Crittografia simmetrica: una singola chiave usata per crittografare/decrittografare (es. AES-GCM/CTR). Veloce; ideale per grandi volumi di dati.
• Crittografia asimmetrica: coppie di chiavi pubblica/privata (RSA/ECC) usate per lo scambio di chiavi e le firme. Più lenta; ideale per stabilire la fiducia e per il wrapping delle DEK.
• Hashing: digest unidirezionale (es. SHA-256). Per l’integrità; non è crittografia.
• Firma digitale: la chiave privata produce la firma; la chiave pubblica la verifica. Non ripudio e integrità.
• Crittografia a involucro (envelope encryption): combina una KEK asimmetrica con una DEK simmetrica per ottenere prestazioni e isolamento della custodia delle chiavi.

Azure Disk Encryption e crittografia dello storage

• Crittografia predefinita dei Managed Disks: crittografia lato server (SSE) con chiavi gestite dalla piattaforma (PMK). Overhead operativo minimo.
• CMK con Disk Encryption Set (DES): utilizzare un DES che fa riferimento a una chiave di Key Vault o Managed HSM per dischi, snapshot e immagini. Motivazione: controllo centralizzato del ciclo di vita e della revoca delle chiavi; soddisfa i requisiti di conformità per il controllo da parte del cliente.
• ADE (Azure Disk Encryption): BitLocker in-guest (Windows) o dm-crypt (Linux). Da usare quando è necessaria una postura di crittografia a livello di sistema operativo, protezioni delle chiavi a livello di disco legate al dominio o mandati di conformità esistenti. Compromesso operativo: maggiore complessità, gestione delle estensioni e potenziale impatto sul provisioning delle VM.
• Doppia crittografia:
  • Dischi: combinare la SSE con PMK a livello di infrastruttura con la CMK tramite DES per ottenere due livelli di crittografia indipendenti.
  • Account di storage: usare ambiti di crittografia (encryption scopes) con CMK separate per container/workload; combinarli con la crittografia dell’infrastruttura, dove disponibile, per ottenere due livelli.
• Ambiti di crittografia (Encryption scopes in Azure Storage): definire ambiti per container o per blob con CMK distinte per isolare il rischio di tenant/workload e consentire una rotazione mirata senza un impatto esteso.

Igiene dei segreti e pratiche operative

• Identità gestite: usare identità gestite assegnate dal sistema o dall’utente per le risorse Azure per ottenere token per Key Vault e altri servizi, eliminando le credenziali incorporate. Definire l’ambito di RBAC o delle policy di accesso in modo restrittivo.
• Scansione dei segreti: abilitare Microsoft Defender for DevOps, la scansione dei segreti di GitHub Advanced Security e le protezioni dei repository. Integrare con le pull request per bloccare i pattern di credenziali noti.
• Pipeline e IaC: usare le integrazioni delle attività di Key Vault in Azure Pipelines e le credenziali federate basate su OIDC di GitHub Actions per evitare segreti persistenti. Non stampare i segreti nei log; mascherare gli output. Eseguire immediatamente la rotazione di qualsiasi materiale trapelato.
• Progettazione delle applicazioni: preferire i riferimenti senza versione dove è sicuro; usare la cache in modo minimo e gestire gli errori 401/403 riacquisendo i token e recuperando nuovamente i segreti per supportare gli eventi di rotazione.

Approfondimento sulla Gestione dei Certificati

• Emissione basata su policy: Definire il soggetto, i SAN, l’utilizzo della chiave (key usage), gli EKU, il tipo/dimensione della chiave e le impostazioni di riutilizzo della chiave in una policy di certificato di Key Vault. Motivazione: mantenere una postura TLS coerente in tutti gli ambienti.
• Integrazione con l’emittente: Configurare un profilo di CA in Key Vault. Per una PKI privata, integrare con Microsoft ADCS tramite un emittente personalizzato o utilizzare il Certificate Connector di Azure Key Vault. Le CA pubbliche consentono il rinnovo automatico senza esporre le chiavi private al di fuori di AKV.
• Operazioni di rinnovo automatico: Utilizzare azioni sul ciclo di vita (es. rinnova 60 giorni prima della scadenza; notifica a 90 giorni). A livello operativo, allineare le finestre di rinnovo con i periodi di blocco delle modifiche (change freeze) e assicurarsi che i servizi dipendenti si sincronizzino automaticamente.
• Utilizzo da parte delle applicazioni: Recuperare come segreto (PFX/PEM) o collegare per riferimento nei servizi della piattaforma. Preferire i collegamenti nativi della piattaforma (App Service, Application Gateway) per un passaggio a nuove versioni senza tempi di inattività (zero-downtime). Per Kubernetes, montare tramite CSI per attivare riavvii progressivi (rolling restart) alla rotazione.

Scenario Pratico

Siemens AG deve proteggere la telemetria IoT in Azure, imporre una solida custodia delle chiavi per i dati a riposo (at rest) e automatizzare la rotazione di certificati e segreti in una flotta distribuita a livello globale.

1. Definire i vault e i confini degli HSM

• Creare Key Vault regionali di tipo Premium per i segreti/certificati delle applicazioni e un Managed HSM per le operazioni con KEK.
• Motivazione: I vault Premium abilitano chiavi supportate da HSM quando necessario; Managed HSM fornisce una garanzia di Livello 3 e una custodia indipendente delle chiavi per le operazioni di wrapping.

2. Applicare recuperabilità e misure di protezione (guardrail)

• Abilitare la protezione dall’eliminazione definitiva (purge protection) su tutti i vault e Managed HSM; impostare la conservazione per l’eliminazione temporanea (soft-delete) a 90 giorni. Applicare Azure Policy per verificare/negare i vault senza protezione dall’eliminazione definitiva.
• Motivazione: Previene la perdita catastrofica di dati dovuta a eliminazioni definitive; la policy assicura che non possano verificarsi deviazioni (drift).

3. Centralizzare l’autorizzazione tramite RBAC

• Impostare i vault sul modello di autorizzazione Azure RBAC. Assegnare il ruolo Key Vault Administrator a un piccolo team di piattaforma tramite PIM; assegnare il ruolo Key Vault Secrets Officer ai team applicativi a livello del singolo vault; assegnare il ruolo Managed HSM Crypto Officer agli ingegneri della sicurezza.
• Motivazione: RBAC + PIM garantiscono il principio del privilegio minimo (least privilege), l’elevazione dei privilegi limitata nel tempo e un auditing coerente. La separazione dei compiti impedisce agli amministratori di utilizzare le chiavi.

4. Blindare la rete con endpoint privati

• Creare endpoint privati nelle VNet hub; disabilitare l’accesso dalla rete pubblica. Abilitare i “servizi attendibili” solo per gli account di Storage che utilizzano CMK.
• Motivazione: Gli endpoint privati eliminano l’esposizione pubblica e bloccano i percorsi di esfiltrazione dei dati, preservando al contempo i flussi necessari tra servizio e vault.

5. Implementare la strategia di crittografia e CMK

• Per Storage, definire ambiti di crittografia (encryption scope) per ogni workload con URI KEK senza versione nel vault Premium; per i Managed Disks, utilizzare Disk Encryption Set con CMK dall’HSM. Abilitare la crittografia a livello di infrastruttura per una doppia crittografia.
• Motivazione: Chiavi specifiche per workload riducono il raggio d’impatto (blast radius); gli URI senza versione consentono una rotazione trasparente; la doppia crittografia soddisfa requisiti di conformità rigorosi.

6. Automatizzare la rotazione di chiavi e segreti

• Configurare le policy di rotazione delle chiavi di AKV (es. scadenza annuale, rotazione a 9 mesi) e notifiche Event Grid che attivano processi di validazione. Utilizzare identità gestite nei servizi; rimuovere le credenziali statiche.
• Motivazione: Una rotazione prevedibile e automatizzata riduce il rischio derivante da chiavi e segreti a lunga durata; le identità gestite sostituiscono i fragili segreti condivisi.

7. Operazionalizzare i certificati

• Utilizzare le policy dei certificati di Key Vault con l’integrazione dell’emittente DigiCert; impostare il rinnovo automatico a 60 giorni prima della scadenza. Collegare i certificati per riferimento in Application Gateway e App Service.
• Motivazione: Il rinnovo automatico previene le interruzioni di servizio ed evita la gestione manuale delle chiavi; i collegamenti di piattaforma acquisiscono le nuove versioni senza richiedere nuovi deployment.

8. Validare e monitorare

• Abilitare i log di diagnostica di Key Vault e Managed HSM verso Log Analytics; impostare avvisi per tentativi non autorizzati, rifiuti del firewall ed eventi di prossima scadenza. Eseguire test di ripristino trimestrali per i backup di vault e HSM utilizzando il quorum del dominio di sicurezza.
• Motivazione: Il monitoraggio continuo rileva tempestivamente configurazioni errate o attacchi; i test di ripristino assicurano la recuperabilità in condizioni di emergenza.

← Sicurezza di dati · Tutti i domini · Gestione della postura di sicurezza e governance →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →