Osservatorio sulla sicurezzaDistribuzione di una PKI attendibile globale

John Morello

Le informazioni nel presente articolo sono relative a versioni non definitive dei prodotti e sono soggette a modifica.

Un'infrastruttura a chiave pubblica o PKI (Public Key Infrastructure) è un elemento fondamentale nella creazione di una relazione di trust tra più applicazioni, sistemi operativi e aree di autenticazione delle identità. L'infrastruttura si basa su un modello di trust gerarchico, in cui le entità finali considerano attendibile una chiave comune al livello più alto dell'Autorità di certificazione radice e pertanto qualsiasi altra chiave firmata da tale autorità è considerata implicitamente attendibile.

Grazie a questa struttura, un'infrastruttura PKI progettata in modo corretto garantisce elevate caratteristiche di scalabilità verticale, mediante l'aggiunta di ulteriori Autorità di certificazione (CA) senza apportare modifiche alle entità finali.

Le infrastrutture PKI vengono in genere implementate in uno dei due modi illustrati di seguito. L'approccio più comune consiste nell'acquistare i certificati necessari da una delle Autorità di certificazione radice globali implicitamente attendibili, quale Cybertrust o VeriSign. I certificati acquistati vengono in genere utilizzati per garantire la protezione del traffico sui siti Web, ma possono anche essere impiegati per la crittografia di reti private virtuali (VPN), la firma dei messaggi di posta elettronica e l'esecuzione di attività simili. Poiché le Autorità di certificazione radice globali sono incorporate in qualsiasi browser Web e sistema operativo recente, questo metodo consente di estendere con facilità una relazione di trust all'esterno dei confini dell'organizzazione. Tuttavia, dal momento che i certificati vengono acquistati in base alle necessità, l'implementazione su vasta scala di questo approccio all'interno di un'organizzazione di grandi dimensioni può rivelarsi piuttosto costosa.

Il modello PKI interno è l'approccio adottato attualmente nella maggior parte degli ambienti di lavoro. Come suggerisce il nome, un'infrastruttura PKI interna viene considerata attendibile solo all'interno della rete di un'organizzazione. Questo modello costituisce per le organizzazioni un metodo più economico per il provisioning di ogni utente e computer sulla rete mediante l'uso di certificati. Viene in genere utilizzato questo approccio per semplificare tecnologie specifiche, come accesso con smart card, Crittografia file system (EFS) e connessioni di rete wireless protette. Lo svantaggio è rappresentato dal fatto che i certificati non sono considerati globalmente attendibili e non sono adatti ad applicazioni che interagiscono con l'esterno. La maggior parte delle organizzazioni che ha distribuito infrastrutture PKI interne adotta in genere un approccio ibrido che prevede l'acquisto di certificati per applicazioni pubbliche da una delle Autorità di certificazione radice globalmente attendibili.

L'ideale sarebbe poter sfruttare le potenzialità di entrambi gli approcci, con la possibilità per un'organizzazione di eseguire un'infrastruttura PKI personalizzata, realizzando notevoli risparmi sui costi grazie all'emissione di certificati interni, e nello stesso tempo di effettuare il provisioning di certificati pubblicamente attendibili, direttamente dal sistema locale. Una soluzione di questo tipo offrirebbe i vantaggi di un'infrastruttura PKI interna (come l'integrazione in Active Directory®, la registrazione automatica e il supporto IT per i diversi paesi) e nel contempo garantirebbe il vantaggio principale di un'Autorità di certificazione radice globalmente attendibile. La Louisiana State University (LSU) dispone esattamente di un sistema di questo tipo. In questa numero di Osservatorio sulla sicurezza viene esaminata in dettaglio la soluzione implementata presso la LSU e, in particolare, vengono illustrati gli aspetti della progettazione tecnica e delle procedure consigliate da utilizzare durante la distribuzione di un sistema simile. È opportuno tenere sempre presente che la soluzione descritta nell'articolo è in grado di soddisfare esigenze specifiche nel contesto dell'ambiente, delle risorse e dei requisiti aziendali presi in esame. Per determinare il tipo di soluzione più adatto alle proprie esigenze, è consigliabile valutare prima tutti questi aspetti in relazione alla propria azienda.

L'infrastruttura PKI secondo la LSU

La LSU è una importante università di ricerca con un totale di oltre 40.000 entità tra studenti, facoltà e personale e dispone di numerosi siti Web pubblici, molti dei quali richiedono l'utilizzo del servizio TLS (Transport Layer Security), il termine corretto per i certificati SSL (Secure Sockets Layer). La LSU investiva ogni anno migliaia di dollari per l'acquisto di certificati da Autorità di certificazione radice globalmente attendibili.

Nel frattempo, mirava al conseguimento di altri obiettivi in termini di protezione IT, che potessero trarre vantaggio da un'infrastruttura PKI interna progettata in modo corretto. Considerati i requisiti e gli obiettivi della LSU, si immagina l'adozione di un modello ibrido. Si è optato invece per un approccio più innovativo.

È stato avviato un rapporto di collaborazione con una delle Autorità di certificazione radice globalmente attendibile, Cybertrust, per distribuire una CA all'interno della LSU che fosse subordinata a una CA radice Cybertrust (vedere la Figura 1). Cybertrust offre questo servizio nel programma OmniRoot. In questo scenario la LSU crea e utilizza una CA che viene eseguita a livello locale su apparecchiature di proprietà della LSU. Tuttavia, a differenza del modello interno illustrato in precedenza, la CA della LSU non è autofirmata e la rispettiva chiave (insieme a tutte le chiavi che firma) è considerata implicitamente attendibile su quasi tutti i sistemi operativi e browser attuali. Dal punto di vista tecnico, questo modello è un'estensione logica dell'apertura degli standard x.509. Poiché un'infrastruttura PKI è basata su tali standard, è possibile inserire sistemi creati da fornitori diversi nella stessa gerarchia globale. Considerate le premesse, la particolarità più interessante della soluzione OmniRoot sono i termini di utilizzo del servizio.

Figura 1** Certificato radice globale Cybertrust **(Fare clic sull'immagine per ingrandirla)

Il servizio OmniRoot è stato progettato in modo specifico per il tipo di distribuzione PKI implementata all'interno della LSU. Nel programma OmniRoot le organizzazioni pagano a Cybertrust una tariffa annuale fissa per la partecipazione al programma e una tariffa per singolo certificato, solo per i certificati creati per l'utilizzo pubblico. In altre parole la LSU può emettere un qualsiasi numero di certificati per l'utilizzo interno, senza problemi di aumento dei costi a causa delle tariffe per singolo certificato. Al contempo, il costo attuale dei certificati pubblici è notevolmente ridotto rispetto alla tariffa pagata quando l'università acquistava i certificati in base alle necessità.

È bene chiarire che dal punto di vista tecnico i certificati interni e i certificati pubblici sono identici, poiché vengono emessi dalla stessa catena di CA, utilizzano lo stesso livello di crittografia e ne viene effettuato il provisioning tramite lo stesso sistema di autorità di registrazione. L'unica differenza tra i due tipi di certificati è rappresentata dai termini del Contratto di licenza.

È stato infine possibile espandere e migliorare la piattaforma di protezione IT della LSU a un costo inferiore. Questo ha consentito di predisporre un eccezionale business case per questo tipo di soluzione PKI presso la LSU. Ora è possibile esaminare i dettagli più tecnici della distribuzione.

Gerarchia PKI

La gerarchia PKI della LSU si basa su una struttura a due livelli, in cui il livello radice è gestito da Cybertrust e una CA emittente in linea risiede presso la LSU (vedere la Figura 2). Il livello radice rappresenta il punto di ancoraggio per la relazione di trust all'interno della gerarchia. In altri termini la relazione di trust di tutti i certificati emessi da una CA nella gerarchia appartiene alla CA radice (vedere la Figura 3). Pertanto, la CA radice costituisce il collegamento comune tra tutte le CA, i certificati e le entità finali all'interno della gerarchia. Poiché l'Autorità di certificazione radice globale Cybertrust è già incorporata in Windows® e in ogni altro sistema di elaborazione attuale, il collegamento comune si estende automaticamente oltre la rete della LSU.

Figure 2 Gerarchia PKI a due livelli

Figura 3** Certificato emesso dalla CA emittente della LSU **(Fare clic sull'immagine per ingrandirla)

Cybertrust gestisce la CA radice in una delle proprie strutture di hosting protette. La struttura di hosting prevede l'utilizzo di controlli di protezione fisici, tra cui barriere, blocchi biometrici e un archivio completamente ricoperto da una camicia di rame. Cybertrust rilascia certificati solo alle CA emittenti delle organizzazioni in grado di garantire la conformità ai propri criteri di protezione e certificazione.

La CA emittente della LSU è un sistema che interagisce con le entità finali, responsabile del rilascio di certificati agli utenti e ai computer della LSU. Il certificato dell'emittente è firmato dalla CA Cybertrust, posta al livello superiore della gerarchia, e i certificati emessi creano una catena fino alla CA radice Cybertrust (vedere la Figura 3).

Sistema operativo e hardware di emissione

La LSU utilizza Windows Server® 2003 Enterprise Edition con Service Pack 1 per la CA emittente. Il servizio Autorità di certificazione di Windows Server 2003 offre numerose nuove funzionalità, tra cui archiviazione di chiavi, elenchi di revoche di certificati (CLR) delta e modelli "versione 2". L'istanza di Windows utilizzata come CA emittente viene creata in base ai criteri standard relativi alla creazione di Windows Server della LSU. In tale istanza vengono implementati tutti gli aggiornamenti di protezione pertinenti e l'istanza viene gestita mediante le procedure di gestione delle modifiche della LSU standard e gli strumenti per l'aggiornamento e l'inventario software. In breve, sebbene la gestione del servizio CA sia caratterizzata da alcuni aspetti univoci, l'integrazione del sistema operativo e dell'hardware del server di base nelle operazioni IT esistenti dell'organizzazione risulta piuttosto semplice.

Oltre a seguire le procedure consigliate della LSU standard per l'installazione dei server, si sono sfruttati i vantaggi offerti dalla Configurazione guidata impostazioni di sicurezza (SCW), disponibile in Windows Server 2003 Service Pack 1. Lo strumento SCW utilizza un database con le matrici delle dipendenze dei diversi carichi di lavoro che è possibile eseguire su Windows Server e il tipo di impostazione di protezione richiesto dai carichi di lavoro. Nel database sono inclusi i due ruoli principali forniti dalla CA: lo stesso servizio CA e IIS (per il sito Web self-service PKI).

L'utilizzo della Configurazione guidata impostazioni di sicurezza ha consentito di creare con facilità un modello di protezione, che ha determinato la disattivazione di tutti i servizi non necessari per l'esecuzione dei carichi di lavoro e ha garantito la protezione avanzata dello stack di rete del server. Si è utilizzato quindi il file scwcmd.exe per convertire questo modello in oggetto Criteri di gruppo, in modo da poterlo applicare al server a livello di unità organizzativa. Grazie a questo approccio è stato possibile semplificare la scalabilità verticale e il ripristino di emergenza, poiché la configurazione della protezione basata sui ruoli per una CA della LSU viene ora archiviata in Active Directory, invece di essere specifica del computer.

La CA emittente della LSU è integrata in un server IBM xSeries 346 con doppio processore Intel Xeon da 3,2 GHz, 4 GB di RAM e cinque dischi rigidi SCSI da 146 GB. Considerati gli elevati livelli di prestazioni necessari per il servizio CA e il fatto che la LSU utilizza un modulo di protezione hardware, questa piattaforma dovrebbe garantire una lunga durata e nuove opportunità di espansione.

In conformità con le procedure consigliate standard per la separazione dei database e dei file di registro su unità fisiche distinte, sono stati creati due array RAID 1. Il quinto disco rigido viene gestito come unità di riserva a caldo ed è disponibile per entrambi gli array. Il primo array è stato montato come volume di sistema in cui viene conservato il database della CA. Il secondo array viene utilizzato per i file di registro e altri file di dati, come gli elenchi di revoche dei certificati. Il database della CA si basa sulla stessa tecnologia Jet utilizzata per altri componenti di Windows, come Active Directory, e pertanto sono applicabili le stesse procedure consigliate per la manutenzione e la configurazione dei dischi impiegate per le altre soluzioni di archiviazione basate su Jet.

Un modulo di protezione hardware (HSM) è un dispositivo hardware dedicato, gestito separatamente dal sistema operativo. I moduli HSM vengono in genere forniti come schede PCI, ma sono anche disponibili come apparecchiature in rete. Questi moduli costituiscono un archivio hardware protetto per le chiavi della CA e un processore di crittografia dedicato per rendere più rapide le operazioni di firma e crittografia. In Windows il modulo HSM viene utilizzato tramite le interfacce CryptoAPI: il modulo HSM viene considerato come un dispositivo del provider del servizio di crittografia (CSP). Il programma OmniRoot richiede che ogni CA utilizzi almeno un modulo HSM certificato FIPS 140-2 di livello 3 (i dispositivi di livello 4 sono piuttosto rari) per la generazione e l'archiviazione delle chiavi. Un modulo HSM è un dispositivo unico, con una protezione molto elevata, e richiede investimenti finanziari significativi; i prezzi di listino per i moduli HSM basati su PCI sono in genere compresi nella gamma tra gli 8.000 e i 12.000 Euro.

Nel progetto della LSU viene utilizzato come modulo HSM un modello 500 TPS (500 transazioni al secondo) nCipher nShield con collegamento diretto. Per "collegamento diretto" si intende che il modulo è interno al server e può essere utilizzato solo dal server specifico, al contrario di un modulo HSM in rete che può essere condiviso tra più host. HSM è un dispositivo FIPS 140-2 di livello 3 che garantisce la protezione di K di N dei materiali di definizione chiavi. Il modulo HSM garantisce un elevato livello di protezione contro i tentativi di compromissione delle chiavi private: un intruso, per accedere alla chiave, dovrà possedere sia il dispositivo di archiviazione HSM che un numero definito di token di accesso con i codici PIN corrispondenti.

È importante tenere presente che i moduli HSM sono progettati per impedire la manomissione del contenuto da parte di utenti non autorizzati. Per i moduli HSM viene dunque imposto un limite per i tentativi di accesso consecutivi non riusciti. Nel progetto della LSU il contenuto del dispositivo di archiviazione viene cancellato in modo irreversibile dopo 10 tentativi di accesso consecutivi non riusciti.

La configurazione della LSU prevede una singola CA e, pertanto, il prezzo per un modulo HSM in rete non è giustificato. Se, tuttavia, un'organizzazione prevede di implementare due o più CA, sarà molto meno costoso acquistare un singolo modulo HSM in rete e condividerlo tra le CA. Questo approccio consente inoltre di semplificare la gestione dei token, poiché è possibile proteggere tutti i dispositivi di archiviazione chiavi con lo stesso set di token.

Active Directory e registrazione

Uno dei principali vantaggi di una soluzione PKI basata su Windows è rappresentato dal fatto che il provisioning dei certificati viene effettuato senza installare software aggiuntivo sulle entità che fanno parte dell'infrastruttura PKI. Grazie a una combinazione di registrazione automatica e criteri di gruppo, gran parte del processo di provisioning dei certificati può essere gestito in modo autonomo e invisibile all'utente finale. La LSU utilizza questa tecnologia per la distribuzione automatica dei certificati di computer ai computer membri di Active Directory. Per fornire funzionalità di richiesta di certificati self-service per gli host non Windows, si è utilizzato un sito Web personalizzato.

Come affermato in precedenza, il programma OmniRoot opera una distinzione tra i certificati per uso pubblico e i certificati per uso interno. I certificati sono considerati pubblici se vengono utilizzati da sistemi e utenti che non fanno parte dell'organizzazione LSU, ad esempio quando un potenziale studente invia una domanda di ammissione mediante un sito Web protetto tramite SSL. I certificati utilizzati all'interno dell'organizzazione LSU, ad esempio quelli utilizzati per la crittografia dei dati sui server della LSU, sono considerati interni.

Poiché il costo del programma OmniRoot è basato sul numero di certificati pubblici, è necessario tenere traccia del numero di certificati pubblici emessi e degli utenti a cui vengono rilasciati. Quindi per qualsiasi certificato progettato per uso pubblico, il nome distinto del modello inizia con "PublicCertificate" e il nome visualizzato inizia con "Public Certificate". Il modello di certificato TLS della LSU destinato all'utilizzo pubblico è, ad esempio, basato sul modello del server Web Windows predefinito e viene definito Server Web LSU per certificati pubblici. Per i server Web utilizzati internamente viene impiegato un altro modello definito Server Web LSU per certificati interni. Dal punto di vista tecnico, i due modelli sono identici; le differenze di denominazione hanno il solo scopo di semplificare l'accounting.

Per soddisfare le esigenze di registrazione di massa, come la registrazione di interi reparti per i certificati da utilizzare con IPSec, viene utilizzata la funzionalità di registrazione automatica. Si tratta di uno strumento semplice e molto efficace, integrato in Windows. Dal punto di vista di un amministratore PKI, l'unica azione necessaria consiste nella modifica dell'elenco di controllo di accesso nel modello, con la concessione del diritto a eseguire la registrazione automatica a qualsiasi gruppo di utenti o computer che necessitano di certificati. Queste entità in seguito eseguiranno il controllo automatico di Active Directory, eseguiranno l'enumerazione dei modelli per i quali dispongono dell'autorizzazione alla registrazione automatica, individueranno le CA con tali modelli ed effettueranno la registrazione automatica dei certificati. La funzionalità di registrazione automatica garantisce inoltre che i certificati vengano sostituiti quando un modello viene sostituito e automaticamente rinnovato prima della scadenza.

Per attività diverse dalle operazioni di massa, come il provisioning di certificati per i server Web, si utilizza un sito Web self-service che consente agli utenti di richiedere certificati tramite un browser Web. Il sito è una versione personalizzata delle pagine di registrazione Web fornite con Windows Server 2003 (la directory virtuale /certsrv); l'implementazione comprende la personalizzazione Web standard della LSU e determina la precompilazione delle voci predefinite corrette nella pagina di richiesta. Per inviare automaticamente un avviso tramite posta elettronica al team di amministrazione di PKI quando una richiesta inviata tramite il sito necessita di approvazione, viene utilizzato il modulo di uscita predefinito del servizio CA di Windows.

Modello di revoca

Ciascun certificato prevede un periodo di validità. Accade talvolta che la LSU abbia l'esigenza di invalidare specifici certificati prima della fine del periodo di validità, ad esempio quando viene rilasciato un certificato il cui periodo di validità scade nel maggio 2007 a un dipendente che lascia la LSU nel gennaio del 2007. Questo tipo di revoca viene eseguito tramite gli elenchi di revoche di certificati, ovvero file che contengono un elenco di numeri di serie di certificati firmati da una CA. I numeri di serie contenuti in un elenco di revoche di certificati si riferiscono ai certificati il cui periodo di validità non è scaduto, ma che non vengono più considerati attendibili dalla LSU. I clienti possono quindi scaricare l'elenco di revoche di certificati e determinare la validità dei certificati in base a tale elenco.

Qualsiasi certificato x.509 v3 (eccetto il certificato della CA radice) deve specificare un puntatore a un elenco di revoche di certificati valido. Il puntatore viene definito punto di distribuzione CRL o CDP. Il punto di distribuzione CRL è incluso nel certificato stesso (vedere la Figura 4) e non può essere modificato dopo l'emissione di un certificato. L'elenco di revoche di certificati è un componente fondamentale per la garanzia della validità dei certificati emessi da una CA. Viene quindi verificato che gli elenchi di revoche di certificati della LSU siano fisicamente ridondanti, garantiscano elevata disponibilità e siano accessibili da entità esterne.

Figura 4** Punto di distribuzione CRL di LSU **(Fare clic sull'immagine per ingrandirla)

Una CA basata su Windows Server integrata in Active Directory (come la CA della LSU) pubblica automaticamente il relativo elenco di revoche di certificati in Active Directory, rendendolo accessibile tramite il protocollo LDAP. La posizione di pubblicazione predefinita corrisponde al contenitore CDP (vedere la Figura 5) all'interno del contenitore Servizi chiave pubblica della foresta. Questa posizione di pubblicazione rappresenta un'opzione straordinaria, perché offre funzionalità di replica automatica, tolleranza di errore e un percorso per le ricerche CDP.

Figura 5** Contenitore CDP **(Fare clic sull'immagine per ingrandirla)

Il progetto della LSU, tuttavia, prevede numerosi computer non Windows e non Active Directory che utilizzano l'infrastruttura PKI. Sebbene la LSU sia un'organizzazione di grandi dimensioni, la maggior parte degli utenti risiede sulla rete dello stesso campus, con un'area backbone da 10 Gbps, riducendo al minimo i vantaggi offerti dalla pubblicazione CDP basata su Active Directory.

L'elenco di revoche di certificati viene quindi pubblicato solo su un percorso HTTP, semplificando la creazione di una piattaforma host ridondante (il sito Web principale è già in mirroring). Si eliminano così le potenziali complessità associate all'attivazione di ricerche LDAP client. L'elenco di revoche di certificati viene pubblicato ogni giorno e gli elenchi di revoche di certificati delta ogni ora.

Sviluppi futuri

Microsoft prevede di apportare miglioramenti alle funzionalità della soluzione di protezione avanzata basata sull'infrastruttura PKI corrente per la comunità delle università. In Windows Vista™ e nella prossima versione di Windows Server (nome in codice "Longhorn") saranno disponibili numerose nuove funzionalità di gestione delle chiavi, che verranno debitamente analizzate. Microsoft è particolarmente interessata alle funzionalità pianificate del risponditore e del client Protocollo di stato del certificato in linea (OCSP), al supporto per gli algoritmi di crittografia a curva ellittica e SHA-256 e a un'interfaccia di registrazione automatica notevolmente migliorata. Si prevede inoltre di includere in Windows XP Service Pack 3 una funzionalità nota come credenziali mobili, che garantirà la protezione del roaming di coppie di chiavi, eliminando il significativo overhead associato ai profili mobili. È prevista infine l'analisi dell'utilizzo del Certificate Lifecycle Manager (attualmente disponibile in versione beta) per migliorare le funzionalità di gestione e reporting.

In conclusione l'infrastruttura PKI della LSU fornisce all'università un servizio di protezione di base utilizzato per la maggior parte delle funzioni IT di importanza critica. L'utilizzo del servizio OmniRoot di Cybertrust consente di eseguire un'infrastruttura PKI perfettamente integrata negli altri sistemi IT della LSU, con un'attendibilità che si estende a livello globale. Inoltre, la creazione della soluzione in base al servizio CA di Windows garantisce funzionalità di gestione e provisioning dei certificati efficienti, nonché una perfetta integrazione con il sistema di gestione delle identità e delle directory esistente. In breve la strategia globale alla base dell'infrastruttura PKI mirata a garantire protezione avanzata e relazioni di trust trasparenti sta già diventando realtà presso la LSU.

John Morello si è laureato con lode presso la Louisiana State University e ha lavorato per sei anni in qualità di Senior Consultant per Microsoft Consulting Services. Con MCS, ha progettato le infrastrutture PKI per clienti strategici come Deloitte, GE e diverse organizzazioni federali. Attualmente svolge la funzione di Deputy CISO presso la LSU.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.