Considerazioni sulla progettazione PKI con Servizi certificati Active Directory

Quando si pianifica la distribuzione di un'infrastruttura a chiave pubblica con Servizi certificati Active Directory, è necessario prendere in considerazione alcuni aspetti. Qui è possibile trovare gli elementi necessari per pianificare correttamente l'installazione e la configurazione dell'ambiente PKI.

A livello generale, è consigliabile:

• Pianificare un'infrastruttura a chiave pubblica (PKI) appropriata per l'organizzazione.
• Installare e configurare un modulo di protezione hardware (HSM) in base alle istruzioni del fornitore del modulo di protezione hardware, se si prevede di usarne uno.
• Creare un oggetto appropriato CAPolicy.infse si desidera modificare le impostazioni di installazione predefinite.
• Scegliere le opzioni di crittografia
• Determinare il nome della CA
• Determinare il periodo di validità
• Selezionare il database CA
• Impostazioni dell'accesso alle informazioni dell'autorità e del punto di distribuzione dell'elenco di revoche di certificati

Pianificare l'infrastruttura a chiave pubblica

Per assicurarsi che l'organizzazione possa sfruttare appieno l'installazione di Servizi certificati Active Directory, è necessario pianificare la distribuzione PKI in modo appropriato. È necessario determinare il numero di ca necessarie e in quale configurazione è necessario prima di installare qualsiasi CA. Ad esempio, è necessaria una CA radice aziendale o una CA radice autonoma? Come verranno gestite le richieste di approvazione del certificato? Come si gestirà la revoca dei certificati? La creazione di una progettazione PKI appropriata può richiedere molto tempo, ma è importante per il successo dell'infrastruttura a chiave pubblica.

Usare un modulo di protezione hardware

Un modulo di protezione hardware è un dispositivo hardware dedicato gestito separatamente dal sistema operativo. Questi moduli forniscono un archivio hardware sicuro per le chiavi CA, oltre a un processore di crittografia dedicato per accelerare le operazioni di firma e crittografia. Il sistema operativo usa il modulo di protezione hardware tramite le interfacce CryptoAPI e il modulo di protezione hardware funge da dispositivo CSP (Cryptographic Service Provider).

I moduli di protezione hardware sono generalmente adattatori PCI, ma sono disponibili anche come appliance di rete, dispositivi seriali e dispositivi USB. Se un'organizzazione prevede di implementare due o più ca, è possibile installare un unico modulo di protezione hardware basato sulla rete e condividerlo tra più ca.

Per configurare una CA usando un modulo di protezione hardware, è necessario installare e configurare il modulo di protezione hardware prima di configurare le ca con chiavi che devono essere archiviate nel modulo di protezione hardware.

Prendere in considerazione un file CAPolicy.inf

Il CAPolicy.inf file non è necessario per installare Servizi certificati Active Directory, ma può essere usato per personalizzare le impostazioni della CA. Il CAPolicy.inf file contiene varie impostazioni usate durante l'installazione di una CA o quando si rinnova il certificato della CA. Il CAPolicy.inf file deve essere creato e memorizzato nella directory %systemroot% (in genere C:\Windows) per poterlo usare.

Le impostazioni incluse nel CAPolicy.inf file dipendono in gran parte dal tipo di distribuzione che si vuole creare. Ad esempio, una CA radice potrebbe avere un CAPolicy.inf file simile al seguente:

[Version]
Signature= "$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=20
LoadDefaultTemplates=0

Selezionare le opzioni di crittografia

La selezione delle opzioni di crittografia per un'autorità di certificazione (CA) può avere implicazioni significative per la sicurezza, le prestazioni e la compatibilità per tale CA. Anche se le opzioni di crittografia predefinite possono essere adatte per la maggior parte delle ca. La possibilità di implementare opzioni personalizzate può essere utile agli amministratori e agli sviluppatori di applicazioni con una conoscenza più avanzata della crittografia e la necessità di questa flessibilità. Le opzioni di crittografia possono essere implementate usando provider di servizi di crittografia (CSP) o provider di archiviazione chiavi (KSP).

I CSP sono componenti hardware e software nei sistemi operativi Windows che forniscono funzioni di crittografia generiche. I CSP possono essere scritti per fornire vari algoritmi di crittografia e firma.

Quando si seleziona il provider, l'algoritmo hash e la lunghezza della chiave, valutare attentamente le opzioni di crittografia che possono essere supportate dalle applicazioni e dai dispositivi che si intende usare. Sebbene sia consigliabile selezionare le opzioni di sicurezza più avanzate, non tutte le applicazioni e i dispositivi possono supportarli.

Consentire l'interazione dell'amministratore quando si accede alla chiave privata dalla CA è un'opzione che viene in genere usata con i moduli di protezione hardware. Questa opzione consente al provider di crittografia di richiedere all'utente l'autenticazione aggiuntiva quando si accede alla chiave privata della CA. Ad esempio, richiedere all'amministratore di immettere una password prima di ogni operazione di crittografia.

I provider di crittografia predefiniti supportano lunghezze di chiave e algoritmi hash specifici, come descritto nella tabella seguente.

Cryptographic provider	Key lengths	Hash algorithm
Microsoft Base Cryptographic Provider v1.0	- 512 - 1024 - 2048 - 4096	- SHA1 - MD2 - MD4 - MD5
Provider di crittografia DSS Di base Microsoft	- 512 - 1024	SHA1
Microsoft Base Smart Card Crypto Provider	- 1024 - 2048 - 4096	- SHA1 - MD2 - MD4 - MD5
Microsoft Enhanced Cryptographic Provider v1.0	- 512 - 1024 - 2048 - 4096	- SHA1 - MD2 - MD4 - MD5
Provider di crittografia avanzata Microsoft	- 512 - 1024 - 2048 - 4096	- SHA1 - MD2 - MD4 - MD5
RSA#Provider di archiviazione chiavi software Microsoft	- 512 - 1024 - 2048 - 4096	- SHA1 - SHA256 - SHA384 - SHA512 - MD2 - MD4 - MD5
DSA#Provider di archiviazione delle chiavi software Microsoft	- 512 - 1024 - 2048	SHA1
ECDSA_P256#Provider di archiviazione chiavi software Microsoft	256	- SHA1 - SHA256 - SHA384 - SHA512
ECDSA_P384#Provider di archiviazione chiavi software Microsoft	384	- SHA1 - SHA256 - SHA384 - SHA512
ECDSA_P521#Provider di archiviazione chiavi software Microsoft	521	- SHA1 - SHA256 - SHA384 - SHA512
RSA#Provider di archiviazione delle chiavi della smart card Microsoft	- 1024 - 2048 - 4096	- SHA1 - SHA256 - SHA384 - SHA512 - MD2 - MD4 - MD5
ECDSA_P256#Provider di archiviazione chiavi smart card Microsoft	256	- SHA1 - SHA256 - SHA384 - SHA512
ECDSA_P384#Provider di archiviazione chiavi smart card Microsoft	384	- SHA1 - SHA256 - SHA384 - SHA512
ECDSA_P521#Provider di archiviazione delle chiavi della smart card di Microsoft	521	- SHA1 - SHA256 - SHA384 - SHA512

Determinare il nome della CA

Prima di configurare le autorità di certificazione nell'organizzazione, è necessario stabilire una convenzione di denominazione della CA.

È possibile creare un nome usando qualsiasi carattere Unicode, ma è possibile usare il set di caratteri ANSI se l'interoperabilità è un problema. Ad esempio, alcuni tipi di router non sono in grado di usare il servizio Registrazione dispositivi di rete per registrare i certificati se il nome della CA contiene caratteri speciali, ad esempio un carattere di sottolineatura.

Se si usano caratteri non latini (ad esempio caratteri cirillico, arabo o cinese), il nome della CA deve contenere meno di 64 caratteri. Se si usano solo caratteri non latini, il nome della CA non può contenere più di 37 caratteri.

In Servizi di dominio Active Directory il nome specificato quando si configura un server come CA diventa il nome comune della CA. Il nome comune si riflette in ogni certificato che rilascia la CA. È per questo motivo che è importante non utilizzare il nome di dominio completo come denominazione comune della CA. In questo modo, gli utenti malintenzionati che ottengono una copia di un certificato non possono identificare e usare il nome di dominio completo della CA per creare una potenziale vulnerabilità di sicurezza.

Il nome della CA non deve essere identico al nome del computer (NetBIOS o nome DNS). Inoltre, non è possibile modificare il nome di un server dopo l'installazione di Servizi certificati Active Directory senza invalidare tutti i certificati rilasciati dalla CA.

Per modificare il nome del server dopo l'installazione di Servizi certificati Active Directory, è necessario disinstallare la CA, modificare il nome del server, reinstallare la CA usando le stesse chiavi e modificare il Registro di sistema per usare le chiavi e il database CA esistenti. Non è necessario reinstallare una CA se si rinomina un dominio; Tuttavia, è necessario riconfigurare la CA per supportare la modifica del nome.

Determinare il periodo di validità

La crittografia basata su certificati usa la crittografia a chiave pubblica per proteggere e firmare i dati. Nel corso del tempo, gli utenti malintenzionati potrebbero ottenere dati protetti con la chiave pubblica e tentare di derivare la chiave privata da essa. Data una quantità sufficiente di tempo e risorse, questa chiave privata potrebbe essere compromessa, rendendo effettivamente non protetti tutti i dati protetti. Anche i nomi garantiti da un certificato possono essere modificati nel tempo. Poiché un certificato è un'associazione tra un nome e una chiave pubblica, quando si modifica, il certificato deve essere rinnovato.

Ogni certificato ha un periodo di validità. Dopo la fine del periodo di validità, il certificato non viene più considerato una credenziale accettabile o utilizzabile.

Le ca non possono rilasciare certificati validi oltre il proprio periodo di validità. Una procedura consigliata consiste nel rinnovare il certificato della CA quando la metà del periodo di validità è scaduta. Quando si installa una CA, è necessario pianificare questa data e assicurarsi che venga registrata come attività futura.

Selezionare il database CA

Il database dell'autorità di certificazione è un file sul disco rigido. Oltre a questo file, gli altri file fungono da log delle transazioni e ricevono tutte le modifiche al database prima che vengano apportate le modifiche. Poiché questi file possono essere accessibili frequentemente e contemporaneamente, è possibile mantenere i log di database e transazioni in volumi separati.

Il percorso del database del certificato e dei file di log viene mantenuto nel percorso del Registro di sistema seguente:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration

Il Registro di sistema contiene i valori seguenti:

• DBDirectory
• DBLogDirectory
• DBSystemDirectory
• DBTempDirectory

Impostazioni dell'accesso alle informazioni dell'autorità e del punto di distribuzione dell'elenco di revoche di certificati

Dopo l'installazione di una CA radice o subordinata, è necessario configurare le estensioni AIA (Authority Information Access) e CRL Distribution Point (CDP) prima che la CA rilascia i certificati. L'estensione AIA specifica dove trovare i certificati datati up-toper la CA. L'estensione CDP specifica dove trovare le liste di revoca dei certificati (up-to) firmate dalla CA nella specifica data. Queste estensioni si applicano a tutti i certificati rilasciati dalla CA.

La configurazione di queste estensioni garantisce che queste informazioni siano incluse in ogni certificato che la CA rilascia in modo che sia disponibile per tutti i client. L'uso delle estensioni comporta un minor numero di errori a causa di catene di certificati non verificati o revoche di certificati, che possono causare connessioni VPN non riuscite, accessi tramite smart card non riusciti o firme di posta elettronica non verificate.

Gli amministratori della CA possono aggiungere, rimuovere o modificare i punti di distribuzione CRL e i percorsi per il rilascio di certificati CDP e AIA. La modifica dell'URL per un punto di distribuzione CRL influisce solo sui nuovi certificati rilasciati. I certificati rilasciati in precedenza continuano a fare riferimento alla posizione originale, motivo per cui è necessario stabilire queste posizioni prima che la CA distribuisca tutti i certificati.

Quando si configurano gli URL dell'estensione CDP, prendere in considerazione queste linee guida:

• Evitare di pubblicare CRL delta sulle CA radice offline. Poiché non si revocano molti certificati in una CA radice offline, probabilmente non è necessario un CRL delta.
• Modificare i percorsi predefiniti LDAP:// e http:// url nella scheda Estensioni della scheda Estensione delle proprietà dell'autorità di certificazione in base alle esigenze.
• Pubblicare un CRL in una posizione Http Internet o Extranet in modo che gli utenti e le applicazioni all'esterno dell'organizzazione possano eseguire la convalida dei certificati. È possibile pubblicare gli URL LDAP e HTTP per le posizioni CDP per consentire ai client di recuperare i dati CRL con HTTP e LDAP.
• Tenere presente che i client Windows recuperano sempre l'elenco di URL in ordine sequenziale fino a quando non viene recuperato un CRL valido.
• Usare i percorsi CDP HTTP per fornire percorsi CRL accessibili per i client che eseguono sistemi operativi non Windows.

Next steps

Per altre informazioni sulla distribuzione di Servizi certificati Active Directory, vedere Implementare e gestire Servizi certificati Active Directory.