Microsoft AZ-801: Crittografia, Certificati e PKI — Guida allo studio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fa parte della Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La crittografia e l’infrastruttura a chiave pubblica (PKI) costituiscono le fondamenta della fiducia in un ambiente ibrido incentrato su Windows Server. Gli amministratori devono essere in grado di proteggere i dati “at rest” con BitLocker ed EFS, stabilire e gestire una PKI aziendale con AD CS e un Online Responder, automatizzare il ciclo di vita dei certificati tramite modelli e registrazione automatica (autoenrollment) e integrare la gestione dei certificati cloud-native tramite Azure Key Vault. Le sezioni seguenti descrivono in dettaglio l’architettura, i prerequisiti, i modelli di implementazione e i controlli operativi che si riscontrano costantemente negli ambienti ibridi reali basati su Windows Server.

BitLocker ed EFS su Windows Server

Crittografia unità BitLocker protegge i volumi utilizzando una combinazione del TPM e di “key protector” (protezioni della chiave). TPM 2.0 è la raccomandazione di base attuale; TPM 1.2 rimane supportato, ma TPM 2.0 con UEFI e Secure Boot fornisce un collegamento più forte della catena di avvio ai Platform Configuration Registers (PCR) del TPM. Per i server, è necessario richiedere TPM+PIN sui volumi del sistema operativo per aggiungere un fattore online, mitigando gli attacchi “cold-boot” e offline. Configurare questa opzione tramite Criteri di gruppo (Group Policy) in Crittografia unità BitLocker (Richiedi autenticazione aggiuntiva all’avvio; Consenti PIN avanzati per l’avvio). Dove non esiste un TPM, è possibile utilizzare una chiave di avvio USB, ma questa soluzione è inferiore dal punto di vista operativo e meno sicura.

La governance delle chiavi di ripristino è obbligatoria. Negli ambienti AD DS, depositare le informazioni di ripristino negli oggetti computer (msFVE-RecoveryInformation) tramite Criteri di gruppo (Scegliere le modalità di ripristino delle unità del sistema operativo protette con BitLocker; Eseguire il backup in AD DS delle password di ripristino e dei pacchetti di chiavi). Negli scenari di dispositivi aggiunti ad Azure AD (Azure AD–joined), le chiavi di ripristino vengono depositate nell’oggetto dispositivo di Azure AD e sono individuabili dagli amministratori autorizzati nel pannello Dispositivi; le policy di Intune possono richiedere il deposito in Azure AD. Convalidare il deposito prima di abilitare la crittografia su larga scala.

Lo Sblocco tramite rete (Network Unlock) elimina l’inserimento manuale del PIN per i server aggiunti a un dominio in subnet sicure del datacenter durante i riavvii non presidiati. I prerequisiti includono volumi del sistema operativo protetti da TPM, firmware UEFI, connettività cablata senza autenticazione 802.1X in fase di pre-avvio, raggiungibilità del broadcast DHCP e un server Windows Deployment Services con la funzionalità Sblocco tramite rete e un certificato di autenticazione server emesso da una CA aziendale utilizzando il modello Sblocco tramite rete. Configurare le GPO di BitLocker per abilitare lo Sblocco tramite rete e assicurarsi che gli endpoint OCSP/CRL della CA siano raggiungibili dal server WDS. Lo Sblocco tramite rete non si applica a host mobili o wireless.

Il pre-provisioning accelera le implementazioni su larga scala crittografando lo spazio utilizzato già in fase di Windows PE durante l’imaging. Nelle sequenze di attività di MDT/Configuration Manager, utilizzare il passaggio “Pre-provision BitLocker” (

undefined

) per avviare la crittografia prima dell’implementazione completa del sistema operativo; passare alla protezione completa dopo l’aggiunta al dominio e l’applicazione dei criteri.

Gestire BitLocker centralmente con Microsoft Endpoint Manager. Intune (MDM) impone la crittografia silenziosa con protezioni solo TPM per i dispositivi aggiunti ad Azure AD e deposita le chiavi in Azure AD; la richiesta di un PIN di avvio impedisce la crittografia silenziosa e richiede l’interazione dell’utente. Per i server aggiunti a un dominio e gli ambienti misti, utilizzare Configuration Manager BitLocker Management (il successore di MBAM) per la reportistica di conformità, il deposito delle chiavi, i portali e la rotazione delle chiavi. Progettare sempre per un deposito verificabile e una mappatura del proprietario.

EFS è una crittografia per singolo file legata ai certificati EFS dell’utente. Una chiave di crittografia del file (FEK) viene generata per ogni file e crittografata con la chiave pubblica EFS dell’utente. In assenza di una CA aziendale, Windows emette un certificato EFS autofirmato, il che ostacola il ripristino e il controllo centralizzato. Nelle implementazioni aziendali, emettere certificati EFS da AD CS utilizzando il modello “Basic EFS” e designare Agenti di recupero dati (DRA) tramite GPO (Criteri di chiave pubblica, Encrypting File System) per garantire la recuperabilità dei file crittografati dagli utenti. Lo strumento a riga di comando cipher rimane essenziale:

undefined

e

undefined

crittografano o decrittografano;

undefined

genera coppie di chiavi DRA;

undefined

aggiorna i file crittografati per utilizzare il certificato EFS corrente. Utilizzare BitLocker per la protezione a livello di volume ed EFS solo quando è richiesta una separazione per utente o per file, tenendo presente che EFS richiede l’accesso dell’utente e la disponibilità del certificato.

Gerarchia di AD CS e Online Responder

Una PKI aziendale resiliente utilizza una gerarchia di CA a più livelli. La CA radice (root CA) offline è l’ancora di fiducia (trust anchor) e deve essere isolata fisicamente e logicamente, accesa solo per firmare le richieste delle CA subordinate e pubblicare le CRL. Utilizzare una validità lunga (ad esempio, 10-20 anni), chiavi RSA di grandi dimensioni (almeno 4096 ove possibile) e pubblicare CDP/AIA su URL ad alta disponibilità e con percorsi coerenti. Non emettere mai certificati di entità finale (end-entity) dalla CA radice.

Le CA subordinate (di emissione) sono unite al dominio, online e hanno una vita breve (ad esempio, 3-5 anni) con utilizzo della chiave (key usage) ed EKU vincolati. Emettono certificati per computer, utenti e servizi e pubblicano CRL frequenti con sovrapposizione per evitare interruzioni durante i ritardi di pubblicazione. Preferire chiavi private supportate da HSM sulle CA di emissione per ridurre il rischio di esfiltrazione delle chiavi. Configurare restrizioni basate su registro o policy sui modelli (template) e sull’emissione per applicare il principio del privilegio minimo (least privilege).

La verifica della revoca deve essere rapida e affidabile. Un Online Responder (OCSP) riduce la latenza del client rispondendo a query di stato per singolo certificato invece di scaricare le CRL complete. Installare il servizio di ruolo Online Responder, registrare i responder per un certificato OCSP Response Signing tramite un modello v3 dedicato e configurare una Revocation Configuration che punti alla CA di emissione e alle sue CRL utilizzando il Microsoft CRL-based Revocation Provider. Assicurarsi che la CA includa un URL OCSP nell’estensione Authority Information Access in modo che i client sappiano dove inviare le query.

Per garantire scalabilità e resilienza, implementare un array OCSP. Designare un controller dell’array per replicare le configurazioni di revoca ai responder membri. Bilanciare il carico dell’array utilizzando Windows NLB o un bilanciatore di carico esterno con un health probe che confermi la reattività di OCSP e la freschezza dei certificati di firma. Impostare durate brevi per i certificati di firma OCSP e il rinnovo tramite registrazione automatica (autoenroll) per minimizzare l’esposizione al rischio. Monitorare la freschezza delle CRL e la durata della cache OCSP per prevenire risposte obsolete (stale).

Modelli, Registrazione automatica, Archiviazione chiavi e Credential Roaming

I modelli di certificato (certificate template) regolano i vincoli delle richieste, il nome del soggetto, gli utilizzi della chiave e i requisiti di emissione. I modelli di versione 2 (introdotti con Windows Server 2003 Enterprise) consentono la personalizzazione e supportano la registrazione automatica con chiavi basate su CSP. I modelli di versione 3 (Windows Server 2008 e successivi) aggiungono il supporto per CNG, ECC e gli algoritmi Suite B. Scegliere la v3 quando si necessita di CNG/ECC; scegliere la v2 per la massima compatibilità con i sistemi legacy. Associare i modelli a un singolo set di CA di emissione per contenere il raggio d’impatto (blast radius).

La registrazione automatica (autoenrollment) trasforma il ciclo di vita dei certificati in un meccanismo guidato da policy. Configurare la Criteri di gruppo (Group Policy) in Configurazione computer o Configurazione utente, Impostazioni di Windows, Impostazioni di sicurezza, Criteri chiave pubblica, Client Servizi certificati – Registrazione automatica. Abilitarla con le opzioni per rinnovare i certificati scaduti, aggiornare i certificati che utilizzano modelli di certificato e rimuovere i certificati revocati/scaduti. La registrazione automatica richiede autorizzazioni sul modello: le entità di sicurezza (principal) devono disporre delle autorizzazioni Lettura e Registrazione automatica; l’autorizzazione Registrazione è sufficiente solo per la registrazione manuale. Delimitare l’ambito tramite gruppi di sicurezza per evitare l’emissione imprevista di certificati e controllarne il volume.

L’archiviazione delle chiavi (key archival) protegge i dati in caso di perdita di una chiave privata. Abilitare l’opzione per archiviare la chiave privata di crittografia del soggetto sul modello per i certificati di sola crittografia (ad esempio, EFS, S/MIME). Designare Agenti recupero chiavi (Key Recovery Agent - KRA) emettendo per loro certificati KRA dal modello Agente recupero chiavi e configurare la CA per l’archiviazione delle chiavi. Il recupero è limitato ai tipi di chiave archiviabili; tradizionalmente, è supportato RSA Key Exchange (CSP legacy), mentre l’archiviazione di chiavi private CNG/ECC non è supportata dall’archiviazione chiavi di AD CS. Non abilitare l’archiviazione per i modelli di sola firma.

Il Credential Roaming sincronizza i certificati utente, le chiavi private e le chiavi master DPAPI tra i dispositivi aggiunti al dominio, memorizzandoli in AD. Abilitarlo tramite Criteri di gruppo in Configurazione utente, Modelli amministrativi, Sistema, Credential Roaming e limitarne l’ambito agli utenti attendibili. Ciò migliora l’esperienza utente per i certificati EFS, S/MIME e di autenticazione client su più macchine senza profili mobili (roaming profile). Verificare il supporto dello schema di directory e pianificare l’interazione con Windows Hello for Business e gestori di credenziali di terze parti per evitare conflitti o duplicazioni.

Ciclo di vita TLS/SSL e integrazione con Azure Key Vault

Il TLS moderno dipende dalla corretta semantica dei certificati. Includere sempre l’EKU di autenticazione server e preferire firme SHA-256 o superiori con chiavi RSA di almeno 2048 bit o curve ECC appropriate. Il campo Subject Alternative Name (SAN) deve elencare ogni hostname utilizzato dai client; il solo Subject CN, ormai obsoleto, non è sufficiente per i client moderni. I certificati wildcard (*.contoso.com) semplificano le implementazioni multi-host in una singola zona DNS, ma non coprono nomi a più livelli (app.dev.contoso.com) o zone diverse; è necessario valutare attentamente la concentrazione del rischio quando le chiavi private wildcard vengono distribuite su larga scala. Per esigenze multi-zona, è preferibile utilizzare certificati SAN o più certificati specifici.

Standardizzare le CSR con certreq o IIS, mantenere policy di custodia delle chiavi e automatizzare il rinnovo con largo anticipo rispetto alla data NotAfter per consentire implementazioni graduali (staged rollout) e la propagazione di OCSP/CRL. Sui server web aggiunti a un dominio, la registrazione automatica (autoenrollment) con un modello Web Server v3 può automatizzare l’emissione e il rinnovo; utilizzare l’opzione per fornire il nome del soggetto nella richiesta, con le approvazioni appropriate. Applicare configurazioni server che accettino solo TLS 1.2/1.3, abilitare le suite di cifratura ECDHE per la forward secrecy e rimuovere gli algoritmi SHA-1 obsoleti e i cifrari di livello export.

Azure Key Vault estende il ciclo di vita dei certificati al cloud. È possibile importare certificati PFX/PEM esistenti, generarne di nuovi con una certificate authority integrata in Key Vault (ad esempio, DigiCert) utilizzando una policy di certificato, e impostare la rotazione automatica in modo che Key Vault richieda il rinnovo e mantenga la versione più recente. L’oggetto certificato incapsula una chiave e un segreto di Key Vault, abilitando flussi di lavoro con PFX esportabili o chiavi non esportabili supportate da HSM, a seconda della policy. Applicazioni e servizi recuperano le versioni correnti tramite RBAC o policy di accesso e identità gestite. I riferimenti a Key Vault consentono a servizi come Azure App Service e Azure Functions di recuperare certificati e segreti tramite riferimento, senza incorporarli nella configurazione. Per i workload Windows Server in Azure o in ambienti ibridi, utilizzare l’estensione VM di Azure Key Vault o un’automazione personalizzata con identità gestite per recuperare e installare i certificati aggiornati nell’archivio certificati di Windows e attivare il riavvio dei servizi, garantendo rinnovi zero-touch su server web, reverse proxy e application gateway.

Scenario pratico

Adobe Inc. deve standardizzare la crittografia e la PKI tra due datacenter on-premise e i workload Windows Server ospitati su Azure. Richiedono riavvii dei server non presidiati nei datacenter, rinnovi automatici dei certificati web, ripristino della crittografia per singolo file e minimo attrito per l’utente.

1. Costruire una PKI a due livelli con una CA radice (root) offline e due CA di emissione (issuing) online

• Perché: Una CA radice offline crea un trust anchor ad alta affidabilità, mentre le CA di emissione di breve durata limitano l’esposizione e supportano l’alta disponibilità. La gerarchia consente la separazione dei compiti, uno scoping scalabile dei modelli e la pubblicazione sicura di CRL/AIA.

2. Implementare un array di OCSP Online Responder dietro un load balancer

• Perché: OCSP fornisce risposte di revoca a bassa latenza per server web e applicativi su larga scala. Un array con bilanciamento del carico e health check previene i single point of failure e garantisce che i client ottengano uno stato aggiornato senza dover scaricare CRL di grandi dimensioni.

3. Creare modelli di certificato v3 per Web Server, Firma di Risposta OCSP e Autenticazione Computer; modelli v2 per EFS e S/MIME con archiviazione delle chiavi

• Perché: La v3 abilita CNG/ECC per il TLS moderno e la firma delle risposte OCSP; la v2 massimizza la compatibilità dei client per EFS/S/MIME e supporta l’archiviazione delle chiavi di crittografia. Lo scoping dei modelli applica il principio del privilegio minimo per l’emissione.

4. Abilitare la registrazione automatica (autoenrollment) tramite Group Policy e assegnare i permessi di Lettura/Registrazione automatica sui modelli a gruppi di sicurezza con ambito definito

• Perché: La registrazione automatica elimina i passaggi manuali, gestisce i rinnovi prima della scadenza e rimuove i certificati revocati/scaduti. Lo scoping tramite gruppi di sicurezza evita l’emissione eccessiva e aderisce al principio del privilegio minimo.

5. Implementare BitLocker su tutti i server con TPM+PIN per i volumi del sistema operativo; depositare le chiavi di ripristino in AD DS

• Perché: TPM+PIN aumenta la resistenza agli attacchi offline; il deposito in AD DS garantisce la recuperabilità. I server raggiungono gli obiettivi di uptime garantendo al contempo una verificabilità della custodia delle chiavi di livello compliance.

6. Configurare Network Unlock utilizzando WDS con la funzionalità Network Unlock nelle subnet del datacenter

• Perché: Vengono abilitati i riavvii non presidiati dopo l’applicazione di patch senza accesso alla console locale, mantenendo i controlli di sicurezza TPM+PIN al di fuori del datacenter. UEFI+TPM e DHCP cablato soddisfano i prerequisiti tecnici.

7. Gestire la postura di BitLocker con BitLocker Management di Configuration Manager e la relativa reportistica

• Perché: Configuration Manager offre una copertura consolidata per i server, dashboard di conformità e flussi di lavoro self-service/ripristino, riducendo l’onere operativo in un ambiente misto on-premise e Azure.

8. Emettere certificati EFS da AD CS e configurare i DRA tramite GPO; richiedere agli utenti di eseguire il backup dei loro certificati EFS

• Perché: L’emissione centralizzata unita ai DRA garantisce la continuità operativa per la crittografia a livello di file. Le chiavi dei DRA sono strettamente controllate per prevenire abusi, pur mantenendo le opzioni di ripristino.

9. Centralizzare i certificati TLS per i workload esposti su Internet in Azure Key Vault con integrazione di CA gestita e rotazione automatica; distribuirli a Windows Server tramite automazione con identità gestita

• Perché: Key Vault delega il rinnovo, centralizza i segreti, supporta il versioning e abilita una distribuzione sicura e automatizzata sui server. La rotazione automatica elimina le scadenze e si allinea con le operazioni zero-touch.

10. Abilitare Credential Roaming per un gruppo definito di utenti che necessitano di EFS e S/MIME su più dispositivi

• Perché: Credential Roaming sincronizza i certificati e le chiavi DPAPI, garantendo che gli utenti possano decifrare e firmare su diverse workstation senza esportazione/importazione manuale, migliorando la produttività e riducendo i ticket di supporto.

← Azure Arc e Gestione di Server Ibridi · Tutti i domini · Aggiornamento e Gestione delle Patch di Windows Server →

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

Sfoglia Microsoft →