Condividi tramite

Considerazioni sulla progettazione dell'infrastruttura a chiave pubblica (PKI) con Servizi certificati Active Directory

Quando si pianifica la distribuzione di un'infrastruttura a chiave pubblica (PKI) con Servizi certificati Active Directory, è necessario prendere in considerazione alcuni aspetti. Questo articolo illustra ciò che è necessario pianificare per l'installazione e la configurazione corrette dell'ambiente PKI.

A livello generale, è necessario:

  • Pianificare un'Infrastruttura a chiave pubblica (PKI) appropriata per l'organizzazione.
  • Installare e configurare un modulo di protezione hardware conformemente alle istruzioni del fornitore del modulo, se si prevede di usarne uno.
  • Creare un file CAPolicy.inf appropriato per modificare le impostazioni di installazione predefinite, se necessario.
  • Scegliere le opzioni di crittografia
  • Determinare il nome della CA
  • Determinare il periodo di validità
  • Selezionare il database della 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 (PKI)

Per assicurarsi che l'organizzazione possa usufruire di tutti i vantaggi offerti dall'installazione di Servizi certificati Active Directory, è necessario pianificare la distribuzione dell'Infrastruttura a chiave pubblica (PKI) nel modo appropriato. È necessario stabilire di quante CA si ha bisogno e con quale configurazione, prima di procedere all'installazione di 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 progettazione di un'infrastruttura a chiave pubblica (PKI) può richiedere tempo, ma è importante per garantirne il funzionamento corretto.

Usare un modulo di protezione hardware

Un modulo di protezione hardware è un dispositivo hardware dedicato che è gestito separatamente dal sistema operativo. Questi moduli offrono un archivio hardware sicuro per le chiavi CA oltre a un processore di crittografia dedicato che consente di accelerare le operazioni di firma e di crittografia. Il sistema operativo usa il modulo di protezione hardware tramite le interfacce CryptoAPI e il modulo di protezione hardware funzione come dispositivo del provider del servizio di crittografia (CSP).

I moduli di protezione hardware sono in genere costituiti da adapter PCI ma sono anche disponibili come dispositivi di rete, dispositivi seriali e dispositivi USB. Se un'organizzazione prevede di implementare due o più CA, è possibile installare un singolo modulo di protezione hardware di rete e condividerlo tra più CA.

Per configurare una CA tramite un modulo di protezione hardware, il modulo deve essere installato e configurato prima di configurare le CA con chiavi da archiviare nel modulo di protezione stesso.

Usare un file CAPolicy.inf

Il file CAPolicy.inf non è obbligatorio per l'installazione di Servizi certificati Active Directory, ma può essere usato per personalizzare le impostazioni della CA. Il file CAPolicy.inf contiene varie impostazioni che vengono usate durante l'installazione di una CA o durante il rinnovo del certificato della CA. Per poterlo usare, è necessario creare e archiviare il file CAPolicy.inf nella directory %systemroot%, in genere C:\Windows.

Le impostazioni incluse nel file CAPolicy.inf dipendono in gran parte dal tipo di distribuzione che si vuole creare. Una CA radice, ad esempio, potrebbe avere un file CAPolicy.inf con un aspetto 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ò determinare un impatto significativo sulla sicurezza, sulle prestazioni e sulla compatibilità per la CA in questione. Sebbene le opzioni di crittografia predefinite siano adatte per la maggior parte delle CA, la possibilità di implementare opzioni personalizzate può risultare utile per gli amministratori e gli sviluppatori di applicazioni che hanno conoscenze più avanzate della crittografia ed esigenze specifiche in termini di flessibilità. È possibile implementare le opzioni di crittografia tramite i provider del servizio di crittografia (CSP) o i provider di servizi chiave (KSP).

I provider del servizio di crittografia sono componenti hardware e software inclusi nei sistemi operativi Windows che forniscono funzioni di crittografia generiche. È possibile scrivere provider del servizio di crittografia per fornire svariati algoritmi di crittografia e di firma.

Quando si seleziona il provider, l'algoritmo hash e la lunghezza della chiave, è necessario valutare attentamente quali sono le opzioni di crittografia supportate dalle applicazioni e dai dispositivi che si intente usare. Anche se la procedura consigliata consiste nel selezionare le opzioni di sicurezza più avanzate, non tutte le applicazioni e i dispositivi possono supportarle.

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

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

Provider di crittografia Lunghezze chiave Hash algorithm
Microsoft Base Cryptographic Provider v1.0 - 512
- 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
Microsoft Base DSS Cryptographic Provider - 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
Microsoft Strong Cryptographic Provider - 512
- 1024
- 2048
- 4096		 - SHA1
- MD2
- MD4
- MD5
RSA#Provider di archiviazione chiavi del software Microsoft - 512
- 1024
- 2048
- 4096		 - SHA1
- SHA256
- SHA384
- SHA512
- MD2
- MD4
- MD5
DSA#Provider di archiviazione chiavi del software Microsoft - 512
- 1024
- 2048		 SHA1
ECDSA_P256#Provider di archiviazione chiavi del software Microsoft 256 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P384#Provider di archiviazione chiavi del software Microsoft 384 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P521#Provider di archiviazione chiavi del software Microsoft 521 - SHA1
- SHA256
- SHA384
- SHA512
RSA#Provider di archiviazione chiavi per smart card Microsoft - 1024
- 2048
- 4096		 - SHA1
- SHA256
- SHA384
- SHA512
- MD2
- MD4
- MD5
ECDSA_P256#Provider di archiviazione chiavi per smart card Microsoft 256 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P384#Provider di archiviazione chiavi per smart card Microsoft 384 - SHA1
- SHA256
- SHA384
- SHA512
ECDSA_P521#Provider di archiviazione chiavi per smart card Microsoft 521 - SHA1
- SHA256
- SHA384
- SHA512

Determinare il nome della CA

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

È possibile creare un nome usando qualsiasi carattere Unicode, ma ai fini dell'interoperabilità è preferibile usare il set di caratteri ANSI. Certi tipi di router, ad esempio, 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 latino, ad esempio i caratteri cirillici, arabi o cinesi, il nome della CA potrà contenere un massimo di 64 caratteri. Se si usano solo caratteri non latini, il nome della CA potrà contenere un massimo di 37 caratteri.

In Active Directory Domain Services, il nome specificato quando si configura un server come CA diventa il nome comune della CA. Tale nome viene riflesso in ogni certificato rilasciato dalla CA. Per questo motivo, è importante non usare il nome di dominio completo (FQDN) per il nome comune della CA. In questo modo, gli utenti malintenzionati che ottengono una copia del certificato non possono completare l'identificazione e usare il nome di dominio completo della CA per creare una potenziale vulnerabilità di protezione.

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

Per modificare il nome del server dopo avere installato 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 affinché sui le chiavi e il database della CA esistenti. Non è necessario reinstallare una CA dopo la ridenominazione di un dominio, anche se sarà necessario riconfigurarla CA per il supporto della modifica del nome.

Determinare il periodo di validità

La crittografia basata su certificati si avvale della crittografia a chiave pubblica per proteggere e firmare i dati. Con il passare del tempo, gli autori di attacchi potrebbero ottenere i dati protetti tramite la chiave pubblica e tentare di derivare da essa la chiave privata. Con il tempo e le risorse necessari, la chiave privata potrebbe essere compromessa annullando così la protezione di tutti i dati protetti. In alcuni casi, potrebbe essere necessario modificare anche i nomi garantiti da un certificato. Dato che un certificato è un'associazione tra un nome e una chiave pubblica, quando uno di questi elementi cambia, il certificato deve essere rinnovato.

Ogni certificato ha un periodo di validità. Al termine del periodo di validità, il certificato non è più considerato una credenziale accettabile o utilizzabile.

Le CA non possono emettere certificati con una validità che supera il proprio periodo di validità. È quindi consigliabile rinnovare il certificato della CA alla scadenza della metà del relativo periodo di validità. Durante l'installazione della CA, pianificare questa data e verificare che venga registrata come attività futura.

Selezionare il database della CA

Il database dell'autorità di certificazione è costituito da un file ospitato nel disco rigido. Oltre a questo file, altri file fungono da log delle transazioni e ricevono tutte le modifiche apportate al database prima che tali modifiche vengano implementate. Poiché in genere si accede a questi file di frequente e contemporaneamente, può essere utile mantenere il database e i log delle transazioni in volumi separati.

Il percorso dei file di database e di log dei certificati vengono mantenuti nei percorsi del Registro di sistema seguenti:

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 Accesso alle informazioni dell'autorità (AIA) e Punto di distribuzione CRL (CDP) prima che la CA rilasci i certificati. L'estensione AIA specifica il percorso in cui si trovano i certificati aggiornati per la CA. L'estensione CDP specifica il percorso in cui si trovano gli elenchi di revoche di certificati (CRL) aggiornati firmati dalla CA. Queste estensioni si applicano a tutti i certificati rilasciati dalla CA in questione.

La configurazione di queste estensioni garantisce che queste informazioni siano incluse in ogni certificato rilasciato dalla CA in modo che siano disponibili per tutti i client. L'uso delle estensioni risulta in un numero minore di errori derivanti da catene di certificati non verificate o revoche di certificati, che possono determinare connessioni VPN non riuscite, accessi tramite smart card non riusciti o firme di posta elettronica non verificate.

Gli amministratori delle 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 certificati appena rilasciati. I certificati rilasciati in precedenza continueranno a fare riferimento al percorso originale. Per questo motivo è necessario definire i percorsi prima che la CA distribuisca i certificati.

Durante la configurazione degli URL per l'estensione CDP, tenere conto delle indicazioni seguenti:

  • Evitare di pubblicare delta CRL sulle CA radice offline. Poiché in genere non si revocano molti certificati su una CA radice offline, è probabile che un delta CRL non sia necessario.
  • Modificare i percorsi degli URL LDAP:// e https:// predefiniti nella scheda Estensioni della scheda Estensione proprietà dell'autorità di certificazione in base alle esigenze.
  • Pubblicare un CRL in un percorso HTTP Internet o Extranet in modo che gli utenti e le applicazioni esterni all'organizzazione possano eseguire la convalida dei certificati. È possibile pubblicare gli URL LADP e HTTP per i percorsi CDP per consentire ai client di recuperare i dati CRL tramite HTTP e LDAP.
  • 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.

Passaggi successivi

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