Windows Server 2025 / Funzioni di AD CS e progettazione di una PKI interna

Active Directory Certificate Services (AD CS), i servizi certificati di Active Directory, emette e gestisce certificati per un’organizzazione. Prima dell’installazione occorre stabilire di chi fidarsi, chi può richiedere e approvare certificati e chi gestirà revoca, rinnovo e ripristino.

Stabilire se serve una CA interna

AD CS permette di gestire un’autorità di certificazione (Certification Authority, CA) in un’infrastruttura a chiave pubblica (Public Key Infrastructure, PKI). La CA firma certificati che associano identità a chiavi pubbliche; la PKI comprende anche criteri, protezione delle chiavi, distribuzione della fiducia e procedure operative. Il client deve fidarsi dell’emittente e verificare nome, finalità, validità e altre condizioni applicabili. La sola presenza di un file di certificato non è sufficiente.

Rinnovi ricorrenti dei servizi interni o autenticazione di dispositivi gestiti possono giustificare una PKI aziendale. Una CA interna, però, non è automaticamente attendibile per qualsiasi browser o dispositivo esterno. Per un servizio pubblico utilizzato da client non gestiti può essere più adatto un certificato pubblicamente attendibile per un nome controllato. Confronta queste esigenze con le risorse operative: un certificato autofirmato di laboratorio non costituisce una PKI di produzione.

La panoramica di AD CS ne descrive le funzioni. Prima di creare un’altra CA, censisci PKI esistenti, responsabili e servizi di emissione approvati. Per trasformare, ad esempio, la prova HTTPS di WEB1 in un servizio interno, annota nome DNS, client utilizzatori, proprietario, scadenza del rinnovo ed emittente esistente utilizzabile. Un singolo sito non giustifica automaticamente una nuova CA.

Definire gerarchia e confini di fiducia

Una CA radice offline e una CA emittente online sono una possibile architettura, non una ricetta universale. La radice rappresenta il riferimento superiore di fiducia; una CA subordinata emette i certificati previsti. Mantenere la radice offline riduce l’esposizione quotidiana ma richiede attivazione controllata, pubblicazione, rinnovo e ripristino. Livelli aggiuntivi aumentano anche dipendenze e lavoro. Valutali rispetto a scala, minacce e capacità concreta di mantenerli.

Le considerazioni sulla progettazione PKI aiutano a definire nomi di CA e server, provider crittografici compatibili, protezione delle chiavi, durate e indirizzi di pubblicazione prima dell’installazione. Nome del server e nome della CA sono concetti distinti; rinominare un server CA già installato non è una modifica ordinaria. Esamina i confini amministrativi e di protezione delle chiavi prima di combinare CA e controller di dominio: l’accorpamento unisce anche ambiti di privilegio e ripristino.

Limitare modelli e autorizzazioni di registrazione

I modelli definiscono finalità, criteri delle chiavi, validità e condizioni di registrazione. Extended Key Usage (EKU), l’utilizzo esteso della chiave, identifica scopi quali autenticazione server o client. Secondo la gestione dei modelli AD CS, le CA aziendali utilizzano modelli memorizzati in Active Directory Domain Services (AD DS), i servizi di dominio Active Directory; le CA autonome non li utilizzano. Creare un modello, pubblicarlo su una CA per l’emissione e autorizzare la registrazione sono decisioni separate. Un’emissione troppo ampia di certificati di autenticazione può consentire la sostituzione di identità.

• Separa i richiedenti da chi approva ed emette. Definisci gruppi specifici e responsabili delle modifiche ai criteri; evita un account condiviso per tutte le funzioni.
• Decidi se il richiedente può indicare nomi e chi verifica il suo diritto a utilizzarli. Per un certificato web il nome autorizzato deve corrispondere al servizio previsto, non a qualsiasi identità inserita liberamente.
• Limita l’uso delle chiavi private e giustifica l’eventuale esportabilità. Distingui chiavi server, chiavi CA e materiale di ripristino; documenta destinatari e custodia prima di consentire l’esportazione.
• Limita la registrazione automatica a gruppi e finalità approvati. Prevedi un progetto pilota con richiedenti autorizzati e non autorizzati, registrando errori, certificati emessi e avvisi prima di ampliare l’ambito.

Valuta il rischio prima di assegnare autorizzazioni estese ad Authenticated Users o ad altri gruppi numerosi. Documenta richiedenti, amministratori dei modelli, amministratori CA, gestori che approvano o revocano e revisori, separando i compiti in base al rischio. La guida a sicurezza, delega e controllo della CA distingue questi controlli. Leggere le prove non richiede amministrazione completa. Stabilisci operazioni da consentire e rifiutare nel collaudo e quali modifiche o emissioni debbano produrre avvisi verificabili.

Gestire pubblicazione della revoca e rinnovo

Pianifica la revoca in caso di chiavi compromesse, uscita di utenti o dismissione di server. Una Certificate Revocation List (CRL), lista di revoca dei certificati, pubblica i certificati revocati. Authority Information Access (AIA), accesso alle informazioni dell’autorità, aiuta a individuare informazioni dell’emittente come il certificato della CA; i CRL Distribution Points (CDP) indicano dove reperire le liste di revoca. Catena e stato di revoca sono verifiche distinte. Specifica percorsi effettivi, responsabili della pubblicazione, frequenza, scadenza delle liste e client che devono raggiungerle.

DNS o pubblicazioni LDAP solo interni potrebbero non essere accessibili a client esterni o non aggiunti al dominio. Verifica l’accesso dai dispositivi e contesti reali, inclusi proxy e limitazioni di rete. Arrestare la CA non revoca subito tutti i certificati emessi, ma interrompe funzioni diverse come emissione, rinnovo o aggiornamento delle informazioni di revoca. Validità delle CRL, cache e criteri applicativi condizionano il risultato: certificati non ancora scaduti non garantiscono continuità. Cambiare un URL di pubblicazione riguarda i certificati nuovi; quelli già emessi possono continuare a richiedere il vecchio indirizzo.

Coordina il rinnovo della radice, delle CA emittenti e dei certificati di servizio. Richiedere una durata lunga non supera la validità residua dell’emittente o i criteri applicabili. Registra dipendenze, proprietari, date di intervento e verifica della nuova catena. Dopo il rinnovo di un servizio, controlla il certificato effettivamente presentato e la relativa associazione, non soltanto il nuovo oggetto nell’archivio. Se cambiano chiave o catena della CA, pianifica distribuzione e compatibilità dei client prima di ritirare i componenti precedenti.

Documentare protezione delle chiavi e ripristino

La compromissione della chiave privata di una CA interessa tutto il relativo ambito di fiducia. Valuta un Hardware Security Module (HSM), dispositivo dedicato alla protezione e alle operazioni sulle chiavi, insieme ad accessi amministrativi limitati e responsabilità separate. L’HSM non sostituisce procedure e backup recuperabili. La guida a backup e migrazione della CA comprende database, chiavi private, configurazione del Registro, CAPolicy.inf se utilizzato ed elenco dei modelli assegnati a una CA aziendale. Modelli e associazioni in AD DS non sono coperti dal solo backup del database CA. Progetta backup protetti, custodia delle password e ripristino isolato; per chiavi HSM segui anche il metodo supportato dal produttore. Una copia del certificato pubblico non salva la chiave privata.

1. Censisci utilizzatori, finalità e domanda prevista. Per ogni servizio annota nomi, dispositivi e utenti client, emittente attuale, responsabile, dipendenze di rete e necessità di continuità.
2. Assegna un proprietario e confronta riutilizzo della PKI o emissione approvata esistente con una nuova struttura. Documenta motivazione, risorse operative e punti aperti, non soltanto una scelta nell’installazione guidata.
3. Progetta radice, emittenti, protezione delle chiavi, modelli ove applicabili, autorizzazioni e distribuzione della fiducia. Includi chi può richiedere, approvare, modificare e controllare e come ritirare la fiducia a fine servizio.
4. Definisci pubblicazione CRL/AIA, responsabili dei rinnovi, avvisi, backup e ripristino isolato. Specifica posizioni e prove da verificare, compreso il mantenimento degli URL precedenti e il recupero del materiale protetto.
5. Convalida in un ambiente separato richieste autorizzate e rifiutate, nomi ammessi e respinti, rinnovo, revoca secondo l’applicazione e ripristino dai backup. Documenta risultato previsto, osservato e azione correttiva; un’emissione riuscita non verifica tutte le altre condizioni.

Il risultato di questa esercitazione è un progetto verificabile, non una CA installata. Non installare AD CS su DC1 e non distribuire una radice di prova a dispositivi reali. Prima di decidere la distribuzione devono essere definiti responsabili, procedure sostenibili, prove di accettazione e piano per ritirare la fiducia o trasferire il servizio. Se non è ancora chiaro chi pubblicherà le CRL, recupererà le chiavi o gestirà un rinnovo fallito, registra la decisione aperta prima di autorizzare l’installazione.