Leggere in inglese

Condividi tramite

Configurazione di punti di accesso wireless protetti

  • Articolo
In questa pagina

Introduzione
Definizione
Sfide
Soluzioni
Riepilogo

Introduzione

Questo documento è contenuto nella raccolta di indicazioni per la protezione delle aziende di medie dimensioni. pubblicate da Microsoft con l'intento di fornire informazioni utili alla creazione di un ambiente informatico più protetto e produttivo.

Nel mondo aziendale, le reti wireless locali (WLAN, Wireless Local Area Network) sono un argomento piuttosto controverso. La maggior parte delle aziende utilizza già una WLAN di qualche tipo o ha già valutato i pro e i contro della tecnologia wireless. Le aziende che hanno già distribuito le reti wireless manifestano in genere varie preoccupazioni in merito alla sicurezza della loro soluzione mentre quelle che hanno preferito rinunciare alla tecnologia wireless si domandano se hanno fatto la scelta giusta, considerati gli evidenti risparmi in termini di produttività e infrastrutture che questa tecnologia è in grado di offrire.

Nel passato, molti responsabili delle decisioni tecnologiche nutrivano giustamente perplessità sulle garanzie di sicurezza offerte dalla tecnologia wireless e ancora oggi la fama di tecnologia poco sicura non è del tutto scomparsa a causa dell'ampia pubblicità data ai difetti dei protocolli di protezione WLAN IEEE 802.11 di prima generazione. Nel corso degli anni sono state sviluppate numerose soluzioni alternative, ma in genere le soluzioni volte alla riduzione dei problemi di protezione delle reti wireless sono risultate troppo costose o caratterizzate da difetti intrinseci.

Dai tempi delle prime reti wireless si sono verificati enormi progressi. Oggi la tecnologia wireless consente di raggiungere velocità più elevate e una maggiore affidabilità e gli standard di protezione delle trasmissioni wireless si sono anch'essi evoluti. Gli ultimi protocolli di protezione delle reti wireless, WPA e WPA2, entrambi basati sullo standard IEEE 802.11i, assicurano una solida protezione del traffico wireless, anche negli ambienti che adottano i requisiti di protezione più rigorosi. Se configurati correttamente, gli standard attuali sono notevolmente più sicuri e in grado di assicurare alle medie aziende un elevato livello di affidabilità.

Panoramica

Questa guida è strutturata in quattro sezioni principali che illustrano i vari aspetti della progettazione e implementazione di una soluzione di protezione efficace per le reti wireless delle medie aziende. Le sezioni della guida sono:

  • Introduzione. Questa prima parte include una presentazione dei contenuti e una panoramica della struttura del documento, nonché informazioni sui destinatari della guida.

  • Definizione. Questa sezione include informazioni dettagliate e definizioni utili per comprendere la terminologia utilizzata nel documento.

  • Sfide. Questa sezione descrive alcuni dei problemi che le medie aziende spesso affrontano in sede di valutazione delle reti wireless e descrive il contesto delle soluzioni proposte.

  • Soluzioni. Questa sezione descrive nel dettaglio le specifiche fasi dell'attività di pianificazione, sviluppo, distribuzione e supporto di un'infrastruttura wireless protetta. Di conseguenza, la sezione dedicata alle soluzioni è ulteriormente suddivisa in tre sezioni principali:

    • Valutazione della protezione WLAN. In questa sezione vengono fornite informazioni sui requisiti preliminari e le opzioni disponibili per creare una solida base da cui partire per sviluppare il piano della soluzione.

    • Sviluppo di una soluzione WLAN protetta. In questa sezione, le informazioni apprese durante la fase di valutazione vengono utilizzate per prendere decisioni, creare un piano e sviluppare la base di partenza della soluzione.

    • Distribuzione e gestione. In questa sezione vengono presentate nel dettaglio le fasi della soluzione e vengono fornite informazioni utili per la gestione e la convalida della rete wireless protetta descritta in questo documento.

Destinatari della guida

Questa guida è rivolta al personale tecnico, al personale addetto all'implementazione delle tecnologie e ai responsabili tecnici delle medie aziende che stanno valutando una soluzione Wi-Fi Protected Access (WPA) o Wi-Fi Protected Access 2 (WPA2) per proteggere la loro infrastruttura wireless. Questa guida presuppone conoscenze tecniche generali sui dispositivi wireless, i concetti di base delle reti, Microsoft® Windows Server™ 2003, Servizio di Autenticazione Internet (IAS), Servizi certificati, Active Directory® e la configurazione e applicazione dei Criteri di gruppo.

Inizio pagina

Definizione

Questa guida presuppone la piena comprensione e conoscenza dei seguenti termini e concetti.

AES. L'AES (Advanced Encryption Standard) si basa su una tecnica di crittografia dei dati a blocchi simmetrici e fa parte di WPA2.

EAP. Il protocollo EAP (Extensible Authentication Protocol) si basa sullo standard 802.1X e consente agli sviluppatori di far passare i dati di autenticazione tra server RADIUS e punti di accesso wireless. Esistono diverse varianti del protocollo EAP, tra cui: EAP MD5, EAP-TLS, EAP-TTLS, LEAP e PEAP.

EAP-TLS. Il protocollo EAP-TLS (EAP Transport Layer Security) è stato sviluppato da Microsoft in base allo standard 802.1X per consentire l'utilizzo dei certificati digitali a scopo di autenticazione e a tutt'oggi rimane lo standard di settore per l'autenticazione 802.11i.

IEEE 802.1X. Lo standard IEEE 802.1X regola il processo di incapsulamento che si verifica tra supplicant (client), autenticatori (punti di accesso wireless) e server di autenticazione (RADIUS).

IEEE 802.11. Lo standard IEEE 802.11 regola le comunicazioni di rete tramite onde radio e include numerose specifiche, dallo standard 802.11g, relativo al traffico 20+ Mbps su banda a 2,4 GHz, allo standard 802.11i, che regola la crittografia e l'autenticazione WPA2.

IEEE 802.11i. Lo standard IEEE 802.11i modifica lo standard 802.11 specificando i metodi di protezione (WPA2) che utilizzano la cifratura a blocchi AES per proteggere i processi di autenticazione dell'origine (EAP) e risolve alcune delle carenze degli standard e specifiche di protezione wireless precedenti.

MS-CHAP v2. Il protocollo MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol versione 2) è un protocollo di autenticazione reciproca Challenge/Response basato su password che utilizza la crittografia MD4 e DES. Viene utilizzato insieme al protocollo PEAP (PEAP-MS-CHAP v2) per proteggere le comunicazioni wireless.

PEAP. Il protocollo PEAP (Protected Extensible Authentication Protocol) è un tipo di comunicazione EAP che risolve i problemi di protezione delle trasmissioni di testo non crittografato EAP grazie alla creazione di un canale crittografato e protetto tramite TLS.

SSID. L'identificatore del set di servizi (SSID, Service Set Identifier) indica il nome assegnato a una rete WLAN e utilizzato dal client per identificare le impostazioni e credenziali corrette necessarie per l'accesso alla rete wireless.

TKIP. Il protocollo TKIP (Temporal Key Integrity Protocol) è parte dello standard di crittografia WPA per le reti wireless. TKIP è il WEP di prossima generazione che, grazie all'utilizzo di chiavi miste per i singoli pacchetti, risolve i difetti rilevati nello standard WEP.

WEP. WEP (Wired Equivalent Privacy) è parte dello standard IEEE 802.11 e utilizza la crittografia RC4 a 64 o 128 bit. Nel 2001 sono stati scoperti alcuni gravi difetti nello standard WEP, principalmente dovuti alla lunghezza del vettore di inizializzazione della crittografia a flussi RC4, che consentivano la decodifica passiva della chiave RC4.

WLAN. Wireless Local Area Network (rete locale wireless).

WPA. Wi-Fi Protected Access (WPA) è un sottoinsieme di specifiche di protezione wireless interoperative dello standard IEEE 802.11 introdotto nel 2003 per risolvere i difetti rilevati nello standard WEP. Questo standard fornisce funzionalità di autenticazione e utilizza la crittografia dei dati TKIP.

WPA2. WPA2, definito nel settembre 2004 dalla Wi-Fi Alliance, è la versione interoperativa certificata dello standard IEEE 802.11i completo ratificato nel giugno 2004. Come lo standard che lo ha preceduto, WPA2 supporta l'autenticazione IEEE 802.1X/EAP o la tecnologia PSK, ma include inoltre un nuovo meccanismo di crittografia avanzato che utilizza l'algoritmo CCMP (Counter-Mode/CBC-MAC Protocol) detto Advanced Encryption Standard (AES).

Inizio pagina

Sfide

Diverse organizzazioni riconoscono i vantaggi offerti dalla tecnologia wireless in termini di produttività e collaborazione, eppure esitano all'idea di implementare questa tecnologia perché comprensibilmente preoccupate in merito alla vulnerabilità apparente delle reti wireless aziendali. Un altro motivo di perplessità è dato dall'ampia varietà di metodi consigliati per la protezione delle comunicazioni wireless e dalle opinioni contrastanti in merito all'efficacia di tali scelte.

La tecnologia wireless pone numerose sfide alle aziende di medie dimensioni, non solo in merito alla protezione dell'infrastruttura, ma anche all'opportunità o meno dell'adozione delle reti wireless. Di seguito vengono elencati alcuni dei dubbi più diffusi in materia di reti wireless che verranno affrontati in questa guida.

  • Decidere se implementare una rete WLAN

  • Comprendere i rischi e le misure di attenuazione dei rischi delle reti wireless

  • Decidere le modalità di protezione di un ambiente WLAN

  • Scegliere le opzioni di protezione della rete WLAN più adatte

  • Convalidare il livello di protezione dell'implementazione di una rete wireless

  • Integrare beni e risorse esistenti nella soluzione di protezione wireless

  • Rilevare e prevenire le connessioni di dispositivi wireless non autorizzati

Inizio pagina

Soluzioni

Questa sezione descrive come progettare, sviluppare, implementare e supportare le soluzioni wireless protette che è possibile distribuire nelle aziende di medie dimensioni. Come affermato in precedenza, i dubbi in merito all'adozione o meno della tecnologia wireless sono numerosi. In questa guida verranno affrontati tutti questi dubbi in modo da consentire alle aziende di sfruttare i vantaggi offerti dalle reti wireless nel modo più efficiente e protetto possibile.

Valutazione della protezione WLAN

Sebbene attualmente la tecnologia wireless sia in una fase di maturità tale da consentirne la distribuzione veloce e protetta all'interno di qualsiasi azienda di medie dimensioni, è necessario valutare con attenzione i numerosi aspetti e i vari metodi di protezione delle reti wireless disponibili. Questa sezione illustra numerosi metodi comuni di protezione delle reti wireless e offre indicazioni utili a determinare quale sia la soluzione ottimale per un determinato ambiente, includendo le diverse argomentazioni a favore o contro ogni approccio esaminato.

Vantaggi delle reti wireless

I vantaggi che è possibile ottenere dall'implementazione della tecnologia WLAN si possono suddividere in due categorie distinte: vantaggi aziendali e vantaggi operativi. I vantaggi operativi includono costi di gestione e le spese in conto capitale ridotti, mentre i vantaggi aziendali comprendono la maggiore produttività, il miglioramento dell'efficienza dei processi aziendali e il maggiore potenziale di creazione di nuove funzioni aziendali.

Vantaggi per l'azienda

La maggior parte dei vantaggi fondamentali per l'azienda derivanti dall'adozione della tecnologia WLAN sono dovuti all'aumento della flessibilità e mobilità del personale. Con le reti wireless il personale non è più obbligato a svolgere il proprio lavoro seduto dietro la propria scrivania ed è libero di spostarsi nell'ambiente di lavoro con relativa facilità. La libertà resa possibile dalle reti wireless può determinare i seguenti vantaggi:

  • La forza lavoro mobile dell'azienda, ad esempio i venditori, può spostarsi senza difficoltà tra i diversi uffici o rientrare dalle visite presso i clienti e connettersi alla rete aziendale in modo trasparente. La connettività è quasi istantanea e avviene senza necessità di ricercare la porta di rete o districare cavi, con un conseguente risparmio di tempo e la riduzione delle complicazioni associate alla riconnessione alla rete cablata.

  • Il personale IT può rimanere costantemente in contatto con i sistemi gestiti, indipendentemente dal luogo in cui si trova all'interno dell'edificio, anche mentre è in riunione o lontano dalla propria scrivania. Il personale IT può rispondere istantaneamente alle richieste utilizzando dispositivi portatili, come computer portatili, Tablet PC o palmari.

  • Le informazioni sono sempre a portata di mano. Le riunioni non iniziano più in ritardo per aspettare qualcuno che sta facendo delle fotocopie o ha dimenticato un documento importante sulla scrivania. Le presentazioni vengono visualizzate direttamente sul computer anziché tramite un proiettore di cui è necessario regolare impostazioni e messa a fuoco. Le tecnologie interattive permettono di estendere la partecipazione alle riunioni anche al personale degli uffici remoti e ai telelavoratori.

  • La semplicità e la rapidità di implementazione delle modifiche strutturali migliorano enormemente la flessibilità organizzativa: è persino possibile riorganizzare e ristrutturare interi uffici senza doversi più preoccupare dei cavi di rete.

  • La tecnologia wireless introduce nuovi tipi di applicazioni e soluzioni tecnologiche nell'ambiente di lavoro. Dispositivi come i PDA e i Tablet PC possono oggi integrarsi perfettamente nell'ambiente di rete. Il personale e le funzioni aziendali precedentemente "isolati" possono beneficiare anch'essi della connettività di rete: sale mensa, aree di ritrovo, stanze d'ospedale, negozi, ristoranti e persino i reparti produzione delle fabbriche possono raggiungere nuovi livelli di produttività grazie alla semplicità di accesso alle soluzioni tecnologiche.

Vantaggi operativi

La tecnologia wireless produce diversi vantaggi operativi, che variano a seconda del settore in cui opera l'azienda e delle strutture in uso, tra cui:

  • I costi di manutenzione della rete fisica si riducono notevolmente come conseguenza della minore dipendenza dalle infrastrutture di rete cablate. Le aree in precedenza non raggiunte dalla rete, ad esempio le aree esterne o gli uffici distribuiti, diventano accessibili a costi ridotti grazie alla tecnologia WLAN.

  • La scalabilità della rete risponde in modo più efficiente alle variazioni nei livelli della domanda perché è molto più semplice distribuire o spostare i punti di accesso wireless in luoghi diversi per risolvere le congestioni piuttosto che aumentare il numero di porte di rete.

  • L'entità del capitale immobilizzato nei beni infrastrutturali si riduce poiché le apparecchiature delle reti wireless non sono permanenti come i componenti delle reti cablate. Ciò consente di affrontare le espansioni o qualsiasi esigenza di spostamento di uffici con maggiore flessibilità. Le reti wireless ad alta velocità (802.11a/g/n) sono un'alternativa efficace ed economicamente conveniente ai vecchi cablaggi Ethernet o Token Ring a bassa velocità.

Vulnerabilità delle reti wireless

Al fine di comprendere il livello di sicurezza offerto dalle diverse soluzioni di protezione delle reti wireless disponibili è importante conoscere le minacce più comuni a cui sono soggette le reti wireless. Le vulnerabilità e i profili degli attacchi associati alle reti tradizionali sono ampiamente noti. Le reti wireless sono invece soggette a minacce diverse da questi rischi tradizionali.

Tabella 1. Tipici rischi di protezione delle reti WLAN

Rischio Descrizione
Divulgazione di dati tramite l'intercettazione Gli attacchi basati sull'intercettazione del traffico wireless non protetto possono determinare la divulgazione di dati riservati, l'individuazione delle credenziali utente e persino il furto di identità. Gli utenti malintenzionati più esperti sono in grado di utilizzare le informazioni raccolte tramite l'intercettazione per predisporre attacchi ai danni di sistemi altrimenti perfettamente sicuri.
Intercettazione e modifica dei dati trasmessi Un utente malintenzionato che riesca ad accedere alle risorse di rete può anche infiltrare nella rete computer non autorizzati in grado di intercettare e modificare i dati in transito tra due computer autorizzati.
Spoofing L'accesso a una rete interna offre all'autore di un attacco l'opportunità di costruire dati all'apparenza identici al traffico autorizzato. Tali attacchi possono includere la falsificazione di messaggi di posta elettronica che gli utenti interni sono portati a ritenere attendibili con maggiore facilità rispetto ai messaggi provenienti dall'esterno e pertanto utilizzabili come veicoli di social engineering e per la diffusione di Trojan.
Denial of Service (DoS) Indipendentemente dalla soluzione di protezione adottata, le WLAN presentano una particolare predisposizione agli attacchi DoS, sia intenzionali che accidentali. Tali interruzioni del servizio possono essere provocate da un semplice forno a microonde o dispositivo impostato per inondare una rete di traffico indiscriminato.
"Free-loading"
(furto di risorse)		 Alcuni intrusi possono essere semplicemente in cerca di un accesso gratuito alla rete Internet. Anche se questo tipo di attacco non provoca di per sé alcun danno, può comportare un rallentamento della connettività di rete ai danni degli utenti autorizzati o rappresentare un canale di diffusione di malware all'interno della rete.
Minacce casuali e connessioni non gestite Negli ambienti WLAN non protetti, chiunque può riuscire ad accedere alla rete dall'esterno semplicemente utilizzando un dispositivo in grado di connettersi alle reti wireless. Tali dispositivi non gestiti potrebbero essere già compromessi o fornire a un utente malintenzionato una piattaforma di attacco alla rete aziendale.
Punti di accesso WLAN non autorizzati Anche se un'azienda non dispone di una rete wireless può comunque presentare vulnerabilità ai rischi di protezione derivanti da reti wireless non gestite. Poiché l'acquisto di hardware wireless è relativamente economico, qualsiasi dipendente aziendale potrebbe essere in grado di configurare una rete non gestita e non protetta all'interno dell'ambiente aziendale.
Anche se molti dei rischi di protezione associati alla trasmissione dei dati via radio risulterebbero piuttosto evidenti negli attuali ambienti di rete configurati per garantire un grado elevato di protezione, la situazione era ben diversa ai tempi dell'introduzione delle tecnologie di protezione wireless di prima generazione. Quando fu sviluppato lo standard WEP per proteggere le trasmissioni di dati wireless, non vi era una forte esigenza di compensare le carenze di sicurezza intrinseche del wireless rispetto alle trasmissioni dei dati su cavo perché la tecnologia era talmente innovativa che in pochi avevano valutato i possibili rischi ai danni delle nuove reti wireless. Con l'evoluzione dei metodi di attacco divenne però evidente che i dati trasmessi tramite le onde radio attraversavano ambienti potenzialmente ostili per cui era necessario garantire alle reti wireless la stessa protezione riservata alle comunicazioni delle reti locali cablate. Quando i difetti di protezione dello standard WEP iniziarono a essere ampiamente pubblicizzati, l'ambiente di protezione delle reti stava cambiando rapidamente. I media davano ampio risalto alle imprese dei "wardriver" e i governi iniziavano ad approvare le prime normative volte a regolamentare la gestione dei dati e la protezione delle identità da parte delle aziende. A seguito di questi sviluppi, molte aziende decisero che la tecnologia wireless era impraticabile e poco sicura oppure svilupparono complesse soluzioni alternative per affrontare i difetti intrinseci dello standard WEP. Alcune di queste soluzioni alternative sono ancora in uso e persino in commercio. Tuttavia, come illustrato chiaramente nelle sezioni seguenti, oggi non è più necessario adottare queste complicate soluzioni per proteggere le reti wireless dalle minacce in quanto la tecnologia wireless si è evoluta di pari passo con il panorama della protezione. ##### Scelta della soluzione di protezione WLAN più adatta Fin dall'identificazione delle carenze tecnologiche delle WLAN di prima generazione è stato dedicato molto impegno all'eliminazione delle vulnerabilità delle reti wireless. Il settore wireless, Microsoft e altri produttori si sono concentrati sul miglioramento degli standard wireless, mentre numerosi analisti, fornitori di prodotti per la protezione delle reti e altri esperti del settore si sono dedicati alla ricerca di soluzioni alternative per risolvere i difetti degli standard esistenti. Ciò ha portato a un'ampia varietà di approcci alla gestione dei problemi di protezione delle reti wireless. A parte l'approccio più diffuso, ovvero la decisione di non adottare la tecnologia WLAN, nella tabella seguente vengono confrontate le principali alternative disponibili. **Tabella 2. Confronto degli approcci alla protezione WLAN**
Funzionalità WPA e WPA2 WEP statico VPN IPsec
Autenticazione avanzata (vedere la nota) Sì No Sì, solo quando non si utilizza
l'autenticazione con chiave condivisa		 Sì, se si utilizza l'autenticazione basata su certificati o su Kerberos
Crittografia avanzata dati Sì No Sì Sì
Connessione e riconnessione trasparente Sì Sì No Sì
Autenticazione utente (vedere la nota) Sì No Sì No
Autenticazione computer (vedere la nota) Sì Sì No Sì
Protezione del traffico broadcast e multicast Sì Sì Sì No
Dispositivi di rete aggiuntivi richiesti Sì, server RADIUS No Sì, server VPN e RADIUS No
Accesso protetto alla WLAN anziché solo ai pacchetti Sì Sì No No
**Nota**   Per quanto riguarda l'autenticazione avanzata, molte implementazioni di reti private virtuali (VPN, Virtual Private Network) che impiegano la modalità tunnel IPsec utilizzano un tipo di autenticazione con chiave condivisa non avanzata chiamata XAuth. Le attuali versioni del sistema operativo Windows non supportano l'autenticazione utente delle associazioni IPsec. Questa funzionalità sarà tuttavia disponibile in Windows Vista e Longhorn. Con l'autenticazione computer, il computer rimane connesso alla WLAN e alla LAN anche se nessun utente è connesso al computer. Ciò consente il corretto funzionamento di alcune funzionalità basate sul dominio, ad esempio i profili comuni. Come illustrato in questa tabella, durante l'analisi delle varie possibilità di protezione delle reti wireless è necessario tenere in considerazione diversi fattori. Tale valutazione dovrà soffermarsi su ogni aspetto della soluzione, dai costi associati all'implementazione e alla gestione alla sicurezza generale della soluzione. Ogni approccio presenta pro e contro ed è pertanto necessario esaminare nel dettaglio ogni soluzione al fine di giungere a una decisione adeguata e informata. Per favorire la comprensione delle varie opzioni di protezione di un'implementazione WLAN, verranno esaminati nel dettaglio i seguenti argomenti, suddivisi in base al grado di protezione offerto. - Nessuna tecnologia WLAN - Utilizzo di WPA con EAP-TLS - Utilizzo di WPA con PEAP-MS-CHAP v2 - Utilizzo di WPA con PEAP-MS-CHAP v2 e Servizi certificati - Utilizzo di una VPN - Utilizzo di IPsec - Utilizzo di WEP - Nessuna protezione WLAN ###### Nessuna tecnologia WLAN Tra i professionisti della sicurezza circola un detto: "Il sistema più protetto è il sistema che è sempre spento” ovvero il metodo più sicuro di distribuzione di una tecnologia, incluse le reti wireless, consiste nel non distribuire quella tecnologia. Naturalmente, una scelta del genere comporta che l'azienda non potrà mai avvalersi della tecnologia non utilizzata, con la conseguente perdita di competitività nell'attuale contesto di mercato dove ogni vantaggio, in particolare di tipo tecnologico, può essere determinante. Come affermato in precedenza, ogni azienda dovrà valutare le proprie esigenze specifiche, il proprio grado di tolleranza ai rischi e la quantità di rischio derivante da ogni tecnologia di cui si valuta l'adozione e la tecnologia wireless non è diversa. Le reti wireless sono in grado di assicurare numerosi vantaggi, ma questi vantaggi possono essere sottovalutati oppure non risultare utili nel caso di un'organizzazione specifica. Nel momento in cui si prendono in esame le varie soluzioni di protezione wireless, è bene valutare tutte le opzioni, inclusa quella di non implementare una soluzione wireless. Tuttavia, se un'organizzazione stabilisce che non è pronta per l'adozione di una WLAN, questa decisione dovrebbe rientrare nell'ambito di una politica aziendale attiva volta alla prevenzione della distribuzione di reti WLAN non autorizzate da parte degli utenti finali che potrebbero compromettere la protezione della rete. ###### Utilizzo di WPA con EAP-TLS WPA o WPA2 con EAP-TLS (Extensible Authentication Protocol-Transport Level Security) ed entrambi i certificati utente e computer è il metodo di autenticazione 802.1X più avanzato supportato dalle attuali versioni dei client wireless basati su Windows. EAP-TLS utilizza i certificati digitali per fornire l'autenticazione reciproca, in cui il client wireless si autentica su un server di autenticazione e viceversa. L'autenticazione EAP-TLS richiede un'infrastruttura a chiave pubblica (PKI, Public Key Infrastructure) per emettere i certificati e mantenerli aggiornati. Per ottenere il massimo livello di protezione, è necessario configurare la PKI per l'emissione di certificati sia utente che computer per l'accesso wireless. In ragione dei costi di implementazione e amministrativi associati alle PKI, nel passato questa soluzione a elevata protezione veniva utilizzata solo presso le medie e grandi aziende, ma oggi, grazie all'introduzione di Microsoft Small Business Server, che fornisce i servizi certificati necessari per l'implementazione di EAP-TLS, è accessibile anche alle piccole aziende. **Nota**   Attualmente, nessun oggetto Criteri di gruppo è in grado di supportare lo standard WPA2 e ciò può influire sull'efficacia di implementazione dello standard negli ambienti di grandi dimensioni. Tuttavia, gli aggiornamenti per Windows Server 2003 e Windows XP in corso di sviluppo prevedono l'integrazione del supporto di oggetti Criteri di gruppo per WPA2. Le prossime generazioni di Windows, Vista e Longhorn, includeranno il supporto nativo dello standard WPA2. ###### Utilizzo di WPA con PEAP-MS-CHAP v2 WPA o WPA2 con PEAP (Protected Extensible Authentication Protocol) e MS-CHAP v2 (Microsoft Challenge Handshake Authentication Protocol versione 2) con requisiti di password complesse è l'implementazione al secondo posto in ordine di efficacia della protezione supportata dalle versioni attuali dei client basati su Windows. Se la distribuzione di un'infrastruttura a chiave pubblica non risulta fattibile, PEAP-MS-CHAP v2 è un'opzione praticabile e sicura per la distribuzione di una rete wireless affidabile. PEAP è uno schema di autenticazione monodirezionale che utilizza TLS per creare un canale crittografato dal server di autenticazione su cui il client si autentica utilizzando un altro protocollo. Originariamente sviluppato per gli accessi remoti tramite connessione remota e VPN, MS-CHAP v2 supporta l'autenticazione di client wireless basata su password complesse unicamente se nella rete vengono utilizzati criteri per password utente complesse. ###### Utilizzo di WPA con PEAP-MS-CHAP v2 e Servizi certificati Le aziende che richiedono una soluzione con elementi di entrambi gli approcci possono utilizzare Servizi certificati in combinazione con una soluzione PEAP-MS-CHAP v2 basata su password. Tuttavia, alla data della redazione del presente documento, non risulta che l'aggiunta di PEAP-MS-CHAP v2 produca miglioramenti della protezione evidenti rispetto al ragionevole livello di protezione offerto dalla soluzione EAP-TLS. Anzi, la combinazione di PEAP-MS-CHAP v2 con EAP-TLS provoca un rallentamento del processo di autenticazione dovuto alla creazione di due canali TLS, uno all'interno dell'altro. Questa doppia crittografia non produce alcun vantaggio. ###### Utilizzo di una VPN Quando furono scoperti i difetti di protezione dello standard WEP, una delle prime soluzioni proposte da numerosi esperti di sicurezza e leader del settore fu l'utilizzo delle reti private virtuali per proteggere le reti wireless. La tecnologia VPN rappresenta un metodo sicuro e testato per proteggere le comunicazioni di rete che attraversano reti ostili come Internet e questa soluzione al problema dei difetti dello standard WEP è ancora in uso in molti ambienti. Sebbene all'apparenza si tratti di una soluzione vantaggiosa dal punto di vista della protezione, in realtà presenta alcuni difetti evidenti che la rendono poco interessante al confronto con la flessibilità offerta da altre soluzioni basate sul protocollo WPA, sviluppato appositamente per affrontare i rischi delle reti wireless. Anche se è possibile implementare soluzioni WPA in combinazione con la tecnologia VPN per contribuire a proteggere una rete wireless, tale soluzione non presenta alcun vantaggio rispetto a una soluzione WPA pura e semplice, in particolare tenuto conto dell'ulteriore complessità della rete wireless introdotta dalla soluzione VPN. La semplicità di utilizzo è un altro fattore da considerare quando si valuta se aggiungere o meno una VPN alla soluzione di protezione WLAN. Sebbene nel momento in cui si collegano alla rete aziendale tramite Internet gli utenti si aspettino ulteriori requisiti di autenticazione e limiti di timeout associati all'utilizzo delle reti private virtuali, queste procedure aggiuntive possono risultare onerose per gli utenti abituati a connettersi con immediatezza alle risorse dall'interno di una rete locale. Alcune aziende possono optare per questa soluzione semplicemente perché dispongono già di una soluzione VPN per gli utenti remoti e desiderano incrementare l'utilizzo di questo sistema per giustificarne i costi. In tal caso, prima di scegliere questa opzione è necessario considerare una serie di problemi aggiuntivi, tra i quali: - Poiché prima che vengano consentite le comunicazioni tramite il tunnel è necessario stabilire una connessione VPN, i Criteri di gruppo del computer non vengono applicati se l'utente si collega alla rete privata virtuale dopo aver eseguito l'accesso al computer locale. Se l'utente seleziona l'opzione **Accesso con connessione remota** durante l'accesso al computer, prima viene completata la connessione VPN e poi vengono applicati i Criteri di gruppo. - La maggior parte dei server VPN sono progettati per proteggere le connessioni più lente, come le connessioni remote o il traffico su banda larga, e possono diventare colli di bottiglia quando vengono stabilite numerose connessioni ad alta velocità all'interno della rete. - A seconda della configurazione VPN, gli utenti possono avere problemi quando eseguono il roaming tra punti di accesso wireless in quanto le reti private virtuali interrompono spesso le connessioni, anche dopo una brevissima disconnessione, e richiedono una nuova autenticazione manuale ogni volta che l'utente passa da un punto di accesso a un altro. Lo stesso avviene quando il computer dell'utente entra in modalità standby. ###### Utilizzo di IPsec L'utilizzo di IPsec come metodo di protezione delle reti wireless ha avuto origine dalla stessa esigenza che ha portato all'utilizzo delle reti private virtuali per proteggere le reti WLAN ovvero come soluzione per ovviare ai difetti dello standard WEP. Naturalmente, IPsec è un metodo di protezione affidabile per numerose tipologie di traffico di rete e il suo utilizzo nelle WLAN offre alcuni vantaggi, tra i quali la trasparenza, l'indipendenza dalle limitazioni hardware delle WLAN e spese generali contenute in quanto il suo funzionamento non richiede server o software aggiuntivi. Tuttavia, l'utilizzo di IPsec come metodo di protezione delle reti wireless comporta alcuni problemi, tra i quali: - IPsec non è in grado di proteggere il traffico broadcast o multicast in quanto si limita a governare le comunicazioni tra due parti che si sono autenticate reciprocamente e scambiate le rispettive chiavi. - IPsec non protegge la rete, ma solo i pacchetti che transitano nella rete. - Seppur trasparente agli utenti, IPsec non è totalmente trasparente ai dispositivi di rete poiché opera al livello di rete anziché al livello MAC e pertanto comporta ulteriori requisiti per le regole del firewall. - Qualsiasi dispositivo che non può utilizzare IPsec sarà vulnerabile ai tentativi di probe o attacco da parte di chiunque sia in grado di monitorare il traffico della rete WLAN. - La gestione dei criteri IPsec negli ambienti di grandi dimensioni può risultare complessa se si utilizza IPsec per fornire protezione end-to-end ad altre applicazioni oltre al traffico della rete wireless. ###### Utilizzo di WEP Il WEP statico è la forma di protezione più elementare basata sullo standard 802.11 e prevede il controllo di accesso tramite una chiave condivisa utilizzata anche per crittografare il traffico wireless. L'aspetto più interessante di questo metodo è la semplicità; tuttavia, anche se offre una protezione leggermente superiore rispetto a una configurazione di rete wireless non protetta, comporta gravi problemi di gestione e sicurezza, ovvero può richiedere da alcuni minuti ad alcune ore per il rilevamento della chiave condivisa e del SSID (in assenza di broadcast) su una WLAN WEP e pertanto per consentire l'accesso alla rete utilizzando un normale computer portatile e semplici strumenti disponibili su Internet. Una soluzione che consente di migliorare le prestazioni del WEP statico è la configurazione dei punti di accesso in modo da limitare l'accesso alla rete a un gruppo di client predefiniti tramite il filtraggio MAC. Tuttavia, questo approccio rende la rete WLAN vulnerabile agli attacchi effettuati tramite strumenti di rilevamento e spoofing degli indirizzi MAC dei computer collegati. È possibile combinare le tecnologie di protezione e WEP per migliorare in parte la sicurezza degli ambienti che non supportano WPA o WPA2, ma anche queste configurazioni non sono consigliate, tranne nei periodi di transizione tra l'implementazione di una rete WLAN non protetta e la configurazione protetta basata su WPA. Questi metodi, ordinati dal più al meno efficace, sono: - WEP con autenticazione 802.1X e EAP-TLS con certificati sia utente che computer e riautenticazione periodica imposta. - WEP con autenticazione 802.1X e PEAP-MS-CHAP v2 con criteri per password utente complesse e riautenticazione periodica imposta. ###### Nessuna protezione WLAN Anche se l'implementazione di una rete wireless non protetta non è mai consigliata per l'ambiente informatico di una media azienda, in alcuni casi eccezionali una configurazione di rete wireless non protetta può rappresentare la soluzione migliore. Ad esempio, molte città e comuni hanno preso in considerazione o già implementato aree wireless a libero accesso e in tali situazioni si può preferire l'utilizzo di punti di accesso wireless non protetti che forniscono unicamente la connessione diretta a Internet. Tuttavia è bene sottolineare che, nella pratica, le reti wireless non protette sono estremamente vulnerabili a un'ampia varietà di attacchi. ##### WPA o WPA2 Entrambi i protocolli WAP (Wi-Fi Protected Access) e WPA2 (Wi-Fi Protected Access 2) sono stati sviluppati specificamente per affrontare i rischi a cui sono esposte le reti wireless basate sul protocollo IEEE 802.11. Tuttavia, esistono alcune differenze tra i due protocolli. Il protocollo WPA è stato introdotto nel 2003 a seguito del rilevamento dei difetti nello standard WEP, che risolve piuttosto efficacemente tramite l'implementazione del supporto dell'autenticazione reciproca, la crittografia dei dati basata sul protocollo TKIP e l'inserimento di un controllo di integrità nei messaggi firmati per contrastare i tentativi di spoofing e gli attacchi di tipo replay. Il protocollo WPA2 migliora ulteriormente il livello di protezione utilizzando la crittografia AES anziché TKIP per proteggere il traffico di rete e pertanto va sempre preferito allo standard WPA. Sia WPA che WPA2 assicurano una protezione notevolmente superiore rispetto alla standard WEP e, se si adottano le misure di protezione appropriate, non presentano difetti di protezione attualmente noti. Tuttavia, WPA2 è ampiamente riconosciuto come più sicuro e pertanto deve essere preferito al protocollo WPA in tutti i casi in cui l'infrastruttura aziendale sia in grado di supportarlo e si possano sostenere o ridurre i costi di gestione più elevati. La maggior parte dei dispositivi di accesso wireless prodotti oggi, così come le ultime versioni di Windows, in particolare Windows XP con Service Pack 2 (SP2) e Windows Server 2003 con SP1, sono certificati WPA2. Se alcuni punti di accesso o client wireless presenti nell'ambiente non supportano WPA2, i dispositivi e i client wireless che supportano WPA2 sono compatibili con lo standard WPA precedente. **Nota**   Affinché i client basati su Windows XP SP2 siano in grado di supportare la certificazione WPA2, è necessario installare un pacchetto di aggiornamento aggiuntivo, l'[aggiornamento per Wi-Fi Protected Access 2 (WPA2)/Elementi informativi di Wireless Provisioning Services (WPS IE)](http://support.microsoft.com/default.aspx?scid=kb;it-it;893357). Per ulteriori informazioni su questo aggiornamento, vedere http://support.microsoft.com/default.aspx?scid=kb;en-us;893357 (in inglese, articolo in italiano tradotto da un sistema di traduzione automatica all'indirizzo http://support.microsoft.com/default.aspx?scid=kb;it-it;893357). Inoltre, le attuali versioni di Windows non prevedono il supporto di oggetti Criteri di gruppo per WPA2 e ciò costituisce un notevole svantaggio dal punto di vista gestionale poiché rende l'implementazione di WPA2 molto più complessa di quella di WPA. Ciò può rappresentare un fattore di scelta determinante in quanto entrambi gli standard assicurano un grado di protezione relativamente elevato. #### Sviluppo di una soluzione WLAN protetta Nella sezione precedente è stato illustrato il contesto storico in cui hanno avuto origine le diverse opzioni di protezione delle reti WLAN disponibili, è stata fornita una descrizione delle principali vulnerabilità delle reti wireless e sono stati presentati i diversi modi in cui i singoli approcci proteggono o meno contro tali rischi. Le informazioni fornite consentono di adottare decisioni informate in merito alle modalità di applicazione delle singole opzioni in uno specifico ambiente aziendale. Gli ultimi miglioramenti introdotti dagli standard per le reti wireless in materia di protezione, con l'implementazione dei protocolli WPA e WPA2, hanno affrontato i gravi difetti dello standard WEP riducendo significativamente la necessità di adottare soluzioni alternative quali IPsec o le reti private virtuali per proteggere le connessioni wireless. L'implementazione del WEP statico o dinamico non è mai consigliata e l'assenza di funzionalità di protezione è utile solo in alcune situazioni molto specifiche. Alla luce di questi presupposti, rimangono poche opzioni valide da valutare durante l'elaborazione di una soluzione di protezione globale ed efficiente per un'implementazione WLAN. Questa sezione guida i responsabili delle decisioni all'esame dei rimanenti approcci consigliati per la protezione delle reti wireless. Le soluzioni consigliate da Microsoft in questa guida sono ampiamente riconosciute dagli analisti di settore, dagli esperti di sicurezza e dai principali produttori come i metodi migliori per implementare una rete wireless protetta ed efficiente. Anche se l'argomento centrale di questa guida è il metodo ottimale per le aziende di medie dimensioni, è importante prendere in esame tutte le opzioni e percorrere le diverse fasi del processo decisionale in quanto esistono sempre eccezioni alla regola. ##### Il processo decisionale Microsoft per una soluzione WLAN protetta Per la protezione di una rete WLAN, esistono due processi consigliati oltre a un terzo approccio combinato. Le due soluzioni principali, in ordine di efficacia, sono: - WPA2 con EAP-TLS e l'utilizzo di Servizi certificati - WPA2 con PEAP-MS-CHAPv2 A parte il livello di protezione offerto dalle singole soluzioni, il fattore determinante per la scelta è rappresentato dalle risorse richieste per l'implementazione e il supporto della soluzione. WPA o WPA2 con PEAP-MS-CHAPv2 necessita di una minore quantità di conoscenze tecniche e apparecchiature poiché non richiede un'infrastruttura di certificazione sottostante. Tutti i dispositivi attualmente in commercio sono certificati WPA2 e non hanno costi particolarmente proibitivi; pertanto, è più logico scegliere i prodotti che supportano WPA2, anche se si decide di utilizzare WPA in ragione dei vantaggi amministrativi attualmente offerti. Il metodo di crittografia AES di WPA2, da più parti ritenuto più sicuro rispetto al metodo TKIP utilizzato invece dal protocollo WPA, e il supporto di oggetti Criteri di gruppo per WPA2 previsto per il prossimo futuro sono ulteriori motivi a favore della creazione delle basi per un'implementazione di WPA2 futura. WPA o WPA2 con EAP-TLS è l'opzione che assicura la massima protezione delle reti WLAN, ma comporta anche costi di implementazione e gestione più elevati perché richiede un'infrastruttura di certificazione sottostante. Tuttavia, molte medie aziende dispongono già di sistemi conformi ai requisiti di WPA2 con EAP-TLS e pertanto questa soluzione potrebbe risultare preferibile. Molte aziende che invece non dispongono ancora della tecnologia necessaria hanno comunque l'esigenza di dotarsi di alcuni dei componenti tecnologici della soluzione, i certificati e RADIUS; pertanto l'implementazione di questa soluzione ha senso sia dal punto di vista tecnico che commerciale. [![](/security-updates/images/Cc875845.SWCG1(it-it,TechNet.10).gif "Figura 1. Struttura decisionale WLAN Microsoft")](https://technet.microsoft.com/it-it/cc875845.swcg1_big(it-it,technet.10).gif) **Figura 1. Struttura decisionale WLAN Microsoft** Il diagramma di flusso nella figura 1 è già stato utilizzato in precedenza per altra documentazione Microsoft volta ad assistere le organizzazioni nella scelta dell'approccio alle reti WLAN protette più adatto all'ambiente esistente e si basa su determinati criteri di definizione di una grande azienda. Quando si utilizza questo diagramma di flusso, è quindi necessario tener presente che per grande azienda si intende un'azienda con 500 o più dipendenti e un reparto IT composto da almeno cinque persone. Come spiegato in precedenza, la struttura decisionale qui proposta non è stata appositamente sviluppata per le medie aziende a cui è rivolta questa guida, tuttavia molte medie aziende possiedono le risorse e capacità necessarie per implementare senza problemi WPA2 con EAP-TLS e Servizi certificati in quanto dispongono di almeno cinque professionisti IT e sono in grado di dotarsi delle infrastrutture richieste per un'implementazione di EAP-TLS di base (quattro server aggiuntivi, uno dei quali non connesso alla rete). Tenuto conto di ciò, risulta immediatamente chiaro che la soluzione ottimale per la maggior parte delle medie aziende è rappresentata da WPA2 con EAP-TLS e Servizi certificati e questa guida sarà pertanto incentrata su questa soluzione. Possono tuttavia esistere valide eccezioni alla regola per cui, se è richiesto un approccio diverso, sarà comunque possibile consultare le numerose guide esistenti in materia. In particolare, se la soluzione ideale è rappresentata da WPA con PEAP-MS-CHAP v2, sarà possibile trovare ulteriori informazioni nel documento [Protezione delle reti LAN wireless con PEAP e password](http://technet.microsoft.com/it-it/library/dd162271.aspx) all'indirizzo http://technet.microsoft.com/it-it/library/dd162271.aspx ###### Requisiti dei server EAP-TLS Come affermato in precedenza, EAP-TLS richiede almeno quattro server (o un numero superiore, se richiesto per ambienti distribuiti o di dimensioni elevate), due dei quali verranno utilizzati come server ridondanti per Servizio di Autenticazione Internet (IAS), che rappresenta l'implementazione Microsoft di RADIUS (Remote Authentication Dial-in User Service), e due come parte dell'infrastruttura di certificazione a chiave pubblica (PKI) di base. Dei due server di certificazione, quello che funge da autorità di certificazione (CA) principale sarà stand-alone e dovrà rimanere disconnesso dalla rete per proteggere il certificato principale. **Tabella 3. Requisiti hardware consigliati per il server CA principale**
Componente Requisiti
CPU Singola da 733 MHz o superiore
Memoria 256 MB di RAM
Interfaccia di rete Nessuna (o disattivata)
Archiviazione su disco Controller IDE o RAID SCSI. 2 dischi rigidi da 18 GB configurati come unico volume RAID 1 (unità C). Archivio locale rimovibile per il trasferimento dei dati (certificato principale).

Come è illustrato in tabella, i requisiti, sulla base dei requisiti generici per Windows Server 2003 Standard Edition, per la CA principale sono minimi ed è possibile utilizzare una piattaforma esistente designata per il ritiro o, eventualmente, creare una macchina virtuale. Molti clienti potrebbero preferire l'utilizzo di un computer portatile in quanto è possibile chiuderlo al sicuro in qualsiasi stanza chiusa a chiave. Indipendentemente dall'approccio scelto per la creazione della CA principale, è importante verificare che, all'occorrenza, il computer in questione possa essere avviato o ripristinato in modo affidabile.

I requisiti hardware per l'autorità di certificazione di emissione sono simili, ma prevedono un maggiore spazio di archiviazione; inoltre sarà necessario collegare il server alla rete. Poiché questo server deve archiviare tutti i certificati emessi, si consiglia di prevedere almeno 2 GB di spazio su disco per ogni 1000 utenti.

I requisiti dei server RADIUS sono più importanti perché questi server sono fondamentali per mantenere la funzionalità WLAN e devono inoltre gestire numerosi tentativi di autenticazione in periodi di tempo molto brevi. Pertanto, negli ambienti che includono migliaia di client wireless può essere necessaria una piattaforma hardware più robusta. Inoltre, anche se le autorità di certificazione utilizzano solo Windows Server 2003 Standard Edition, i server IAS possono richiedere la Enterprise Edition perché la Standard Edition è in grado di supportare solo 50 client RADIUS.

Per questi motivi, in genere si consiglia di installare IAS nei controller di dominio perché ciò consente di ridurre la necessità di utilizzare altro hardware per i server sfruttando invece le robuste piattaforme server esistenti richieste dai controller di dominio. Inoltre, l'utilizzo di IAS sui controller di dominio incrementa le prestazioni di IAS grazie alla riduzione del traffico di rete tra i controller di dominio e IAS per l'autenticazione utente.

Quando si determinano i requisiti per i server RADIUS, è necessario fare altre considerazioni in merito al failover, alla ridondanza e alle sedi remote. Sebbene i requisiti minimi consigliati prevedano due server IAS, le aziende con numerosi uffici remoti potrebbero richiedere la presenza di server IAS in alcune di queste sedi. Alcune aziende potrebbero prevedere requisiti più elevati di ridondanza server o bilanciamento del carico.

Anche se non esistono specifiche controindicazioni all'utilizzo di server multifunzione come server RADIUS, è importante valutare l'eventuale incremento del carico su tali server e la natura di tali esigenze. Un server RADIUS deve essere scalabile al fine di gestire efficacemente anche le situazioni in cui tutti i client wireless tentino una connessione durante un periodo di tempo ridotto.

Certificati

Indipendentemente dall'approccio WPA scelto per proteggere la rete WLAN, la soluzione richiederà comunque l'utilizzo di certificati. Poiché PEAP richiede i certificati solo sul server di autenticazione, è possibile utilizzare un servizio certificati di terze parti per ottenere i certificati necessari, il che significa che non si dovrà implementare un'infrastruttura a chiave pubblica. Questo è il motivo principale per cui PEAP rappresenta l'approccio consigliato per le organizzazioni di dimensioni più piccole, che potrebbero non disporre delle conoscenze o delle risorse necessarie per implementare e supportare un'infrastruttura di certificazione.

L'implementazione di EAP-TLS con Servizi certificati supportata da Windows non richiede necessariamente una PKI sottostante a supporto del rilascio di certificati, ma poiché ogni client deve disporre di un certificato che consenta l'autenticazione con il server RADIUS, l'utilizzo di certificati di terze parti può comportare costi eccessivi per le aziende più piccole. Le stesse considerazioni valgono per l'approccio combinato PEAP con Servizi certificati.

Se un'organizzazione dispone già di un'infrastruttura a chiave pubblica, il processo decisionale è in parte più semplice perché sarà possibile utilizzare i componenti esistenti per implementare l'opzione di protezione della rete WLAN che garantisce la massima sicurezza. Le medie aziende che non dispongono di un'infrastruttura a chiave pubblica potranno comunque ritenere saggio investire in un'infrastruttura di certificazione che potrà venire utilizzata anche per altre applicazioni, ad esempio:

  • Firma del codice

  • Protezione della posta elettronica

  • Protezione dei contenuti Web

  • Protezione VPN

  • Servizi file crittografati

Considerati i diversi fattori, la scelta di utilizzare Servizi certificati con EAP-TLS o PEAP rappresenta l'approccio ottimale per le medie aziende e questa guida sarà pertanto incentrata su questa soluzione.

Creazione di una dichiarazione sulle procedure di certificazione (CPS, Certificate Practices Statement)

La pianificazione iniziale di una PKI dovrebbe includere la documentazione delle modalità di utilizzo dei certificati nell'ambiente aziendale. Anche se queste decisioni sono modificabili nel corso del tempo, è importante includerle all'interno di una dichiarazione formale sui criteri di certificazione.

I criteri di certificazione sono un insieme di regole che definiscono il funzionamento della PKI e registrano informazioni sull'applicabilità dei certificati a specifici gruppi organizzativi o applicazioni con requisiti di protezione comuni. Una dichiarazione sulle procedure di certificazione (CPS) illustra le procedure adottate dall'azienda per la gestione dei certificati emessi e descrive come verranno interpretati i criteri di certificazione nel contesto dell'infrastruttura aziendale e dei criteri procedurali. Anche se i criteri di certificazione sono documenti validi a livello di intera organizzazione, la dichiarazione sulle procedure di certificazione è riferita alle singole CA, sebbene diverse CA possano condividere una stessa dichiarazione sulle procedure di certificazione nel caso in cui eseguano le stesse attività.

In alcune aziende, questi documenti hanno valore legale e la loro redazione è richiesta da specifiche normative che regolano il settore di appartenenza e richiede il coinvolgimento di esperti in materia legale. Tuttavia, la creazione di questi documenti è consigliata anche alle aziende che non sono obbligate a farlo.

Gerarchia delle autorità di certificazione

Questa guida presuppone un modello di trust gerarchico con un'unica autorità di certificazione principale interna. Poiché questo approccio comporta una serie di vantaggi e svantaggi, potrebbe essere necessario approfondire ulteriormente l'argomento al fine di determinare se questo specifico approccio è valido per l'azienda. Per ulteriori informazioni su questo argomento, vedere il capitolo Designing a Public Key Infrastructure del Windows Server 2003 Deployment Kit all'indirizzo http://technet2.microsoft.com/WindowsServer/en/library/b1ee9920-d7ef-4ce5-b63c-3661c72e0f0b1033.mspx (in inglese).

Figura 2. Gerarchia delle autorità di certificazione

Protezione dell'autorità di certificazione principale

L'implementazione Microsoft di EAP-TLS funzionerà solo se la CA principale viene protetta “off the wire” (scollegata dalla rete). Esistono validi motivi di sicurezza per cui in genere si consiglia l'approccio all'implementazione della PKI che prevede una CA principale stand-alone come questa anziché una CA principale a livello aziendale.

Questo approccio può sembrare uno spreco di risorse, ma va comunque considerato che sarà possibile ridistribuire almeno parte dell'hardware utilizzato per creare la CA principale che non verrà mai collegata alla rete. Questi metodi includono:

  • Dopo la creazione e la distribuzione del certificato principale a una CA di emissione, rimuovere i dischi rigidi dalla CA principale e conservarli in un luogo sicuro finché non saranno di nuovo necessari. Ciò presenta lo svantaggio che, nel caso dovesse servire la CA principale, si dovrà rimettere in funzione l'hardware corrispondente.

  • Dopo la creazione e la distribuzione del certificato principale a una CA di emissione, creare un'immagine del server tramite backup e salvarla su nastri o supporti non in linea per consentire il riutilizzo dell'hardware del server. Anche in questo caso, lo svantaggio è che, se l'hardware dovesse servire nuovamente, dovrà essere recuperato.

  • L'utilizzo di un server virtuale, un PC virtuale o altro software che simuli un computer virtuale per creare la CA principale consente di creare e distribuire il certificato principale e quindi salvare in un archivio non in linea l'immagine della macchina virtuale per l'eventuale utilizzo futuro. Se per questo approccio si sceglie di utilizzare una piattaforma generica (ad esempio un computer desktop standard in uso presso l'organizzazione, purché dotato dei requisiti hardware richiesti) sarà più facile recuperare l'hardware in caso la CA principale sia nuovamente necessaria.

  • Creare la CA principale non in linea su un portatile inutilizzato che verrà conservato al sicuro in una stanza chiusa a chiave per sfruttare così una risorsa hardware che altrimenti potrebbe rimanere inutilizzato.

Autenticazione Internet

Servizio di Autenticazione Internet (IAS) è l'implementazione Microsoft di un server RADIUS e proxy. IAS può eseguire operazioni centralizzate di autenticazione, autorizzazione e accounting per diverse connessioni di rete. IAS può venire utilizzato insieme ad altri server RADIUS per l'inoltro di autenticazioni, autorizzazioni e accounting, insieme ad altri server VPN come server di routing e accesso remoto o in combinazione con altre infrastrutture di rete, ad esempio i punti di accesso wireless.

Durante l'elaborazione di un piano di sviluppo per un'infrastruttura IAS, è importante sfruttare al meglio il valore della combinazione RADIUS-IAS in quanto la finalità di questa infrastruttura non è quella di fornire accesso a una singola rete isolata. Pertanto, durante la pianificazione e distribuzione di un'infrastruttura IAS è opportuno decidere se utilizzare o meno un servizio centralizzato per la gestione dell'accesso alla rete, incluso l'utilizzo di un database di account centralizzato come Active Directory, e verificare che tutti i requisiti attuali e futuri dell'organizzazione siano soddisfatti. In altri termini, la distribuzione di un'infrastruttura IAS deve essere strategica, non tattica.

Questa guida tratterà unicamente la pianificazione e distribuzione di IAS in relazione a un'infrastruttura wireless protetta. Per altre possibilità e aspetti relativi alla pianificazione e distribuzione di IAS, vedere la sezione Deployment Resources sul sito di Servizio di Autenticazione Internet all'indirizzo www.microsoft.com/technet/itsolutions/network/ias/default.mspx (in inglese).

Implementazioni RADIUS preesistenti

Anche se è possibile integrare questa soluzione con le implementazioni RADIUS preesistenti, la presente guida non include informazioni su questo processo. Nella maggior parte dei casi, l'utilizzo di IAS per le funzionalità descritte in questa guida risulta vantaggioso. A tale scopo, è possibile aggiornare le piattaforme precedenti a Windows 2003 Server per utilizzarle come server RADIUS centrali oppure modificare i server RADIUS esistenti per l'inoltro del traffico RADIUS a nuovi server RADIUS basati su Windows Server 2003.

Per una guida dettagliata alla pianificazione della migrazione dell'infrastruttura RADIUS esistente a Windows Server 2003, vedere la pagina IAS Technical Reference all'indirizzo http://technet2.microsoft.com/WindowsServer/en/Library/8f5c89d5-fdaf-430c-9ef4-318f8c15baf11033.mspx (in inglese) oppure contattare un Account Representative Microsoft o il professionista Microsoft Consulting Services appropriato.

Failover e bilanciamento del carico dei server RADIUS

RADIUS è un componente fondamentale di qualsiasi soluzione di protezione di reti wireless 802.1X e pertanto la disponibilità della rete wireless dipenderà dalla disponibilità dei server RADIUS. Una soluzione RADIUS che supporti le reti wireless dovrà quindi garantire affidabilità, reattività e ridondanza per consentire livelli di disponibilità e prestazioni equivalenti a quelli di una rete cablata e per questo in genere si consiglia di installare IAS sui controller di dominio esistenti.

Prima di scegliere una strategia di bilanciamento del carico, è importante tenere presente che lo standard 802.1X prevede l'implementazione di EAP all'interno di RADIUS (EAP-RADIUS) tra i punti di accesso wireless e il server RADIUS. Anche se la soluzione RADIUS utilizza UDP, EAP è un protocollo orientato alla sessione con tunnel all'interno di RADIUS. Ciò significa che i diversi pacchetti EAP-RADIUS che compongono un'unica operazione di autenticazione devono ritornare allo stesso server RADIUS altrimenti si verificherà un tentativo di autenticazione non riuscito.

Sono disponibili due approcci di bilanciamento del carico e failover sui server IAS per le reti wireless. Il primo prevede l'utilizzo di server proxy IAS con gruppi di server RADIUS, il secondo la configurazione dei server RADIUS primario e secondario tramite le impostazioni dell'hardware dei punti di accesso wireless. Nella tabella seguente vengono elencati i vantaggi e gli svantaggi di ogni approccio.

Tabella 4. Failover e bilanciamento del carico RADIUS per EAP

Metodo Vantaggi Svantaggi
Proxy IAS con gruppi di server RADIUS
  • Rilevamento degli errori del servizio RADIUS con failover e failback
  • Distribuzione del carico sulla base delle proprietà del traffico
  • Mantenimento dello stato della sessione EAP durante il bilanciamento del carico
  • Distribuzione delle richieste configurabile sulla base delle impostazioni di priorità e peso
  • Richiede ulteriori server IAS
  • Richiede la configurazione degli indirizzi dei server proxy RADIUS primario e secondario
Impostazioni dei server RADIUS primario e secondario sui punti di accesso wireless
  • Configurazione più semplice per gli ambienti più piccoli
  • Il punto di accesso wireless rileva gli errori del traffico ed esegue il failover
  • Utilizza le funzionalità native dei punti di accesso wireless
  • Richiede maggiore pianificazione e monitoraggio dell'overhead per la distribuzione del traffico sui server RADIUS primario e secondario
  • Alcuni punti di accesso wireless non supportano la funzionalità di failback e ciò può determinare una cattiva distribuzione dei carichi di traffico

Alle aziende di maggiori dimensioni si consiglia di valutare l'utilizzo di proxy RADIUS configurati in gruppi di server RADIUS per la distribuzione dei carichi sui server RADIUS. Ciò assicura una certa flessibilità poiché consente di distribuire il traffico sulla base di diversi elementi configurabili, inclusi il tipo di traffico RADIUS e gli attributi RADIUS, oltre ai valori ponderati e in ordine di priorità. Questo tipo di architettura assicura inoltre la massima flessibilità e scalabilità di gestione delle richieste di autenticazione ed è al contempo meno impegnativo dal punto di vista amministrativo.

La più semplice funzionalità di failover dei server RADIUS integrata nei punti di accesso wireless è in grado di fornire una capacità di recupero sufficiente alla maggior parte delle organizzazioni, ma non è certo una soluzione sofisticata come l'utilizzo di gruppi di server proxy. Tuttavia, il percorso di migrazione da questa architettura alla soluzione di failover e bilanciamento del carico basata su server proxy RADIUS è relativamente semplice per cui questa architettura potrà evolversi nel tempo. Per le aziende che stanno valutando una copertura wireless ridotta o limitata, questa soluzione è efficace e semplice da implementare; tuttavia, l'impegno in termini di gestione e implementazione aumenta parallelamente alle dimensioni e alla complessità della rete wireless poiché ogni dispositivo richiede un monitoraggio e una pianificazione accurati al fine di mantenere un bilanciamento del carico ottimale tra tutti i server.

Figura 3. Metodi di failover e bilanciamento del carico RADIUS per reti WLAN

Il bilanciamento del carico con la funzionalità integrata dei punti di accesso wireless comporta la configurazione di circa la metà dei punti di accesso di ogni sede perché utilizzino il server RADIUS primario con un altro set come secondario mentre l'altra metà dei punti di accesso wireless dovrà utilizzare assegnazioni invertite per i campi primari e secondari, come illustrato nella figura 3. L'elevato overhead risulta evidente poiché il carico può gravare maggiormente su alcuni punti di accesso rispetto ad altri ed è pertanto necessario un intenso monitoraggio per raggiungere e mantenere un livello di bilanciamento del carico efficace.

Requisiti di registrazione RADIUS

I server IAS possono registrare due tipi di eventi opzionali:

  • Tentativi di autenticazione riusciti e non riusciti

  • Informazioni di autenticazione e accounting RADIUS

Gli eventi di autenticazione vengono generati da dispositivi e utenti nel momento in cui tentano di accedere alla WLAN e vengono registrati da IAS nel registro eventi di sistema di Windows Server 2003. Questi eventi sono utili sia per la risoluzione dei problemi che nell'ambito del sistema di controllo della protezione e rilevamento delle intrusioni e pertanto devono essere inizialmente attivati sia per i tentativi riusciti che non riusciti, ma in seguito filtrati per impedire l'overflow del registro eventi di sistema. L'attivazione della registrazione delle richieste di autenticazione RADIUS può rendere superfluo l'utilizzo di questi eventi per scopi di protezione.

Server IAS centralizzati e distribuiti

Per la maggior parte delle medie aziende è inizialmente consigliabile valutare l'adozione di un'architettura dei server IAS centralizzata in quanto molte aziende di queste dimensioni dispongono di connessioni WAN con le sedi remote ad alta velocità e con capacità di recupero. Inoltre, il traffico RADIUS non occupa molta larghezza di banda poiché è progettato per funzionare con i collegamenti WAN e le connessioni remote. Un'architettura centralizzata è anche più conveniente, a condizione che esista già di un'infrastruttura WAN sottostante ad alta velocità e ridondante.

È tuttavia opportuno analizzare l'attuale capacità dei collegamenti WAN esistenti per determinare se si tratta dell'opzione ottimale in quanto, se la rete è congestionata, è possibile che durante l'attesa del completamento dei tentativi di autenticazione 802.1X si verifichi il timeout di altri tipi di comunicazioni, ad esempio il traffico DHCP. La connettività client non è l'unico aspetto da considerare durante la valutazione di un'architettura IAS centralizzata perché la comunicazione tra i server IAS e i controller di dominio richiede solide connessioni di rete per evitare i timeout durante la determinazione dei diritti di accesso alla rete e l'appartenenza ai gruppi.

Alcune aziende dovranno rinunciare ai vantaggi di un'architettura centralizzata a causa dei costi associati alle connessioni WAN ridondanti a larghezza di banda elevata e alle sofisticate apparecchiature di rete richieste. Queste aziende possono optare per un'architettura IAS distribuita, in particolare se dispongono già di un'infrastruttura server decentralizzata.

Un terzo approccio è una combinazione delle due architetture precedenti e consente di collocare strategicamente i server IAS presso i siti che supportano l'infrastruttura, consentendo a questi server di fornire l'autenticazione alle filiali sprovviste di una base di server sottostante, come illustrato nella figura seguente.

Figura 4. Infrastruttura WLAN IAS mista

Questa guida tiene conto di tutti e tre i modelli proposti fornendo indicazioni utili per la configurazione di uffici hub di grandi dimensioni con due server RADIUS in grado di gestire sia le richieste locali che remote, oltre a indicazioni su come configurare uffici principali di grandi dimensioni con filiali opzionali a server singolo.

Nota   Anche in questo caso, l'accesso alla rete WLAN presso gli uffici remoti senza un'infrastruttura server dipende dalla disponibilità della WLAN.

Posizionamento dei server IAS e considerazioni relative al posizionamento congiunto

Per mantenere l'accessibilità ai servizi WLAN è necessario che esistano almeno due server RADIUS per ogni foresta indipendente di Active Directory. Oltre a questo requisito di base esistono numerosi fattori che determinano quanti server sono necessari e se sarà possibile posizionarli insieme ad altre funzionalità.

In generale, il posizionamento dei server IAS dipende dalla posizione occupata dai controller di dominio. Ciò significa che se un ufficio dipende già da un collegamento WAN ad alta velocità a un altro ufficio per i servizi di dominio, è probabile che sia necessario utilizzare anche un server RADIUS remoto. Gli uffici più grandi già dotati di controller di dominio dedicati probabilmente richiederanno almeno un server RADIUS con eventuale failover posizionato altrove a seconda del collegamento WAN disponibile. È necessario valutare con attenzione la capacità del collegamento WAN durante la pianificazione del posizionamento dei server RADIUS sia per l'affidabilità dell'autenticazione degli utenti locali sia per il posizionamento dei controller di dominio utilizzati per l'autenticazione a causa del traffico aggiuntivo generato. Inoltre, al fine di migliorare le prestazioni, è opportuno posizionare i server RADIUS nel dominio principale di una foresta in modo da ottimizzare le operazioni Kerberos.

Un'altra valutazione riguarda la fattibilità del posizionamento di ulteriori server presso le sedi remote laddove ciò risulti necessario perché gli uffici di dimensioni più piccole non dispongono di spazi o infrastrutture sufficienti a supportare server aggiuntivi. Per risolvere questi problemi è possibile posizionare un server IAS insieme a un controller di dominio Active Directory. Nella tabella seguente vengono illustrati alcuni vantaggi e svantaggi di questo approccio.

Tabella 5. Considerazioni sul posizionamento congiunto IAS e controller di domini

Posizione IAS Vantaggi Svantaggi
Sul controller di dominio
  • Migliora le prestazioni di autenticazione utente e computer nonché di autorizzazione.
  • Riduce la necessità di utilizzare ulteriore hardware di server.
  • Nessuna separazione tra i gruppi amministrativi IAS e gli amministratori di dominio.
  • Nessuna separazione intrinseca di errori o problemi di prestazioni associati ai servizi della posizione congiunta.
Server IAS indipendenti
  • Separazione tra i gruppi amministrativi IAS e gli amministratori di dominio.
  • Il carico e il comportamento di IAS non influisce sul controller di dominio.
  • È necessario ulteriore hardware per i server.

Come mostrato in tabella, molte organizzazioni adottano criteri di isolamento delle funzionalità dei controller di dominio su server separati perché ciò riveste un'importanza critica per l'ambiente di rete. Il posizionamento dei servizi IAS su un controller di dominio può suscitare preoccupazioni legate alla sicurezza quando esiste una separazione delle attività tra i due gruppi amministrativi poiché non esiste una separazione intrinseca dell'amministrazione IAS dalle funzioni del gruppo degli amministratori locali di Windows. Questi problemi devono essere valutati prima di decidere se utilizzare il posizionamento congiunto dei servizi IAS, ma a parte ciò la scelta comporta vantaggi di prestazioni oltre che di costi, in particolare per le sedi remote.

Per contenere i costi dell'acquisto di ulteriore hardware di server presso gli uffici remoti, è possibile utilizzare i controller di dominio eventualmente già in uso presso le sedi remote come server IAS, direttamente o integrando una macchina virtuale ai controller di dominio esistenti.

Stima dei requisiti di carico e hardware dei server

La valutazione e la pianificazione dei carichi potenziali per i server deve sempre tenere conto del peggiore dei casi possibile. Nello specifico ci si dovrà quindi chiedere: cosa accadrebbe se tutti i potenziali utenti della rete WLAN eseguissero l'autenticazione in un periodo di tempo molto limitato durante un failover? Naturalmente, in una situazione ottimale si dovrebbe avere il numero minimo di server richiesti per assicurare la capacità di recupero e lasciare al tempo stesso spazio per la crescita futura.

In sede di pianificazione dei carichi e dei requisiti dei server IAS è necessario considerare quanto segue:

  • Numero di utenti e dispositivi che richiedono l'autenticazione e l'accounting.

  • Opzioni di autenticazione, ad esempio il tipo EAP e la frequenza di riautenticazione.

  • Opzioni RADIUS, ad esempio il livello di dettaglio delle registrazioni e l'analisi del software IAS.

Per questa soluzione, che prevede l'utilizzo di WPA o WPA2 con i servizi certificati EAP-TLS, è importante osservare che, a differenza di WEP, WPA e WPA2 evitano le riautenticazioni imposte per aggiornare le chiavi di sessione e pertanto richiedono meno overhead in tale contesto. È inoltre importante osservare che EAP-TLS richiede operazioni di chiave pubblica a intenso utilizzo di CPU a ogni autenticazione iniziale, ma in seguito utilizza le credenziali memorizzate nella cache per consentire riconnessioni rapide a ogni successivo accesso, fino alla scadenza delle credenziali nella cache, ovvero ogni 8 ore per impostazione predefinita. Vale anche la pena di osservare che la riautenticazione si verifica anche quando un client effettua il roaming da un punto di accesso wireless che esegue l'autenticazione in un server RADIUS a un punto di accesso wireless che esegue l'autenticazione in un altro server di autenticazione. Questo processo avviene solo una volta per ogni server di autenticazione ed è trasparente all'utente.

Quando si valuta la capacità del server IAS è utile stimare i carichi potenziali sulla base del numero di autenticazioni al secondo. La tabella seguente mostra la capacità di autenticazioni al secondo stimata di un server IAS con Active Directory su una piattaforma Intel Pentium 4 con CPU a 2 GHz.

Tabella 6. Autenticazioni al secondo

Tipo di autenticazione Autenticazioni al secondo
Nuove autenticazioni EAP-TLS 36
Nuove autenticazioni EAP-TLS con supporto offload 50
Autenticazioni con riconnessione rapida 166
**Nota**   I dati contenuti in questa tabella sono stimati e vengono forniti unicamente come linee guida indicative per scopi di pianificazione della capacità. La tabella mostra che un server con queste caratteristiche può essere in grado di elaborare 36 nuove autenticazioni al secondo in caso di failover o in periodi di picco, pertanto l'autenticazione di 100 utenti richiederebbe circa 3 secondi. Un altro fattore da considerare è l'effetto delle registrazioni su disco dei tempi di autenticazione. Un sottosistema del disco lento può avere un impatto negativo sui tempi di autenticazione se si utilizza la registrazione dettagliata per le attività di autenticazione. Verificare che il sottosistema del disco assicuri la velocità necessaria a garantire tempi di risposta adeguati su ciascun server IAS. ##### Autenticazione WPA 802.11 Dopo aver parlato dell'utilizzo di un'infrastruttura di certificazione e RADIUS per proteggere le comunicazioni wireless tramite l'autenticazione degli utenti e dei dispositivi, è il momento di approfondire le modalità di protezione dal probe e da altri rischi dei dati trasmessi tra dispositivi wireless. Le trasmissioni via radio sono da sempre considerate meno sicure delle comunicazioni via cavo poiché è molto più semplice intercettare i dati che viaggiano nell'etere piuttosto che collegarsi a un cavo o a un patch panel, in particolare se le porte sono protette. Per ovviare alla natura intrinsecamente meno sicura delle comunicazioni wireless è necessario ricorrere alla crittografia dei dati che evita la raccolta di informazioni leggibili da parte di eventuali intercettatori. Le prime specifiche WEP per la crittografia wireless si sono presto dimostrate inadeguate e, di conseguenza, si è tentato di porre rimedio con la creazione dello standard WPA, un sottoinsieme dello standard 802.11i, all'epoca in attesa di approvazione. Infine, si è giunti allo standard WPA2 che costituisce l'implementazione completa dello standard 802.11i ora ratificato ufficialmente. La principale differenza tra WPA e WPA2 è il metodo di crittografia utilizzato: WPA utilizza TKIP e WPA2 il più sicuro AES-CCMP. Sebbene la soluzione descritta in questa guida consenta di utilizzare sia WEP che WPA, in tutti i casi ove sia fattibile da un punto di vista gestionale, si consiglia di adottare WPA2 in quanto costituisce la forma di protezione più elevata e affidabile oggi disponibile per le comunicazioni wireless. In alternativa, la combinazione di WPA e della soluzione proposta in questa guida assicura anch'essa un livello di protezione adeguato. ###### Requisiti dei client La soluzione presentata in questa guida è stata progettata per i computer client che supportano le reti wireless ed eseguono Windows XP Professional con SP2 o Windows XP Tablet Edition. Queste versioni di Windows integrano il supporto dello standard 802.1X e delle reti WLAN. Inoltre, i client basati su Windows XP prevedono la registrazione automatica e la funzionalità di rinnovo dei certificati, il che rende la soluzione basata sui certificati qui presentata particolarmente conveniente in termini di costi, se collegata a un'infrastruttura di certificazione. Anche se Windows XP SP2 prevede il supporto integrato di WPA, per attivare il supporto di WPA2 IEEE 802.11i sui client basati su Windows XP SP2 è necessario installare uno specifico aggiornamento. Per ulteriori informazioni su questo aggiornamento e le istruzioni per il download, vedere l'articolo [Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Service Information Element (WPS IE) update for Windows XP with Service Pack 2 is available](http://support.microsoft.com/default.aspx?scid=kb;it-it;893357) all'indirizzo http://support.microsoft.com/default.aspx?scid=kb;en-us;893357 (in inglese, articolo in italiano tradotto da un sistema di traduzione automatica all'indirizzo http://support.microsoft.com/kb/893357/it). ###### Requisiti dell'infrastruttura server Come descritto in precedenza, questa soluzione richiede l'utilizzo dei componenti di Windows Server 2003 Servizi certificati e IAS. L'implementazione di Servizi certificati e IAS di Windows Server 2003 prevede alcune funzionalità integrate specifiche per le reti WLAN 802.1X. Anche se è possibile distribuire IAS e Servizi certificati sulle versioni precedenti di Windows, questa guida si riferisce specificamente all'ambiente Active Directory di Windows Server 2003. ###### Requisiti dei punti di accesso wireless Questa guida è incentrata sugli aspetti di una soluzione WLAN correlati alla protezione e pertanto non include istruzioni sulla distribuzione, il posizionamento o la scelta dei canali per l'hardware dei punti di accesso wireless. Per ulteriori informazioni su specifici problemi, configurazioni o esigenze di posizionamento dell'hardware dei punti di accesso wireless, consultare i manuali o il sito Web del produttore. La soluzione qui descritta assicura i massimi livelli di protezione in combinazione con hardware per punti di accesso wireless certificato WPA2 IEEE 802.11i e dotato di funzionalità integrate di failover/failback. Questa soluzione può essere implementata anche utilizzando apparecchiature certificate WPA senza eccessive modifiche rispetto alle indicazioni fornite in questa guida e mantenendo un livello molto elevato di protezione. Tuttavia, anche se è possibile implementare la soluzione utilizzando lo standard WEP, questa opzione non è consigliata né supportata da questa guida. #### Distribuzione e gestione Questa sezione include istruzioni dettagliate riguardanti l'installazione e la configurazione dei server e dei servizi richiesti per la soluzione, tuttavia non descrive i singoli passaggi di installazione e configurazione richiesti per sistemi operativi quali Windows Server 2003 e Windows XP Professional. Si presuppone che la maggior parte delle aziende utilizzi processi di creazione e linee guida per la protezione avanzata consolidati. ##### Certificati Questa sezione include indicazioni precise sull'installazione di una PKI, tuttavia non include i dettagli della creazione e protezione avanzata di server in quanto si presuppone che tali procedure avvengano già in base a un processo standardizzato. Si presuppone inoltre che i server CA siano già stati oggetto di configurazione con un'immagine di base e protezione avanzata utilizzando il processo standard aziendale prima dell'inizio di questa fase della soluzione. **Nota**   È bene ricordare che la CA principale non deve mai essere collegata alla rete e pertanto ogni fase della creazione e protezione avanzata dei server dell'organizzazione che richieda la connessione alla rete dovrà essere modificata al fine di rispettare questa eccezione. ###### Informazioni di configurazione definite dall'utente: requisiti preliminari Prima di iniziare la distribuzione della soluzione descritta in questa guida è necessario avere a disposizione o definire i parametri dipendenti dall'organizzazione elencati nella tabella seguente. I segnaposto utilizzati all'interno della guida descrivono le impostazioni in un formato simile al nome dell'impostazione stessa. Ad esempio, il nome DNS del dominio principale di una foresta di Active Directory può apparire come *NomeDominio*.com. I valori elencati in corsivo devono essere sostituiti con le informazioni relative alla propria organizzazione raccolte durante il processo. **Tabella 7. Informazioni di configurazione definite dall'utente**
Elemento di configurazione Riferimenti Impostazione
Nome DNS della foresta di Active Directory    
Nome distinto della directory principale della foresta Pkiparams.vbs  
Nome di dominio NetBIOS    
Nome NetBIOS del gruppo di lavoro della CA principale    
Nome server della CA principale    
Nome server della CA di emissione    
Nome comune X.500 della CA principale    
Nome comune X.500 della CA di emissione    
Nome host completo del server Web utilizzato per pubblicare i certificati CA Pkiparams.vbs  
###### Elementi di configurazione prescritti dalla soluzione: requisiti preliminari Non è necessario modificare le impostazioni elencate in questa tabella, a meno che non sia richiesto specificatamente l'utilizzo di un'impostazione diversa da quella prevista dalla soluzione. Prima di modificare i parametri riportati, assicurarsi di aver compreso pienamente le implicazioni della modifica e le dipendenze dell'impostazione modificata. **Tabella 8. Elementi di configurazione prescritti dalla soluzione**
Elemento di configurazione Riferimenti Impostazione
Gruppi di protezione del ruolo amministrativo    
Amministratori del contenitore di configurazione Servizi chiave pubblica ca_setup.wsf Enterprise PKI Admins
Gruppo autorizzato a pubblicare elenchi CRL e certificati CA nei contenitori della configurazione dell'organizzazione ca_setup.wsf Enterprise PKI Publishers
Gruppo amministrativo che configura e aggiorna le CA; controlla inoltre la capacità di assegnare tutti gli altri ruoli della CA e di rinnovare il certificato CA ca_setup.wsf CA Admins
Gruppo amministrativo che approva le richieste di registrazione e revoca dei certificati (ruolo di Responsabile della CA) ca_setup.wsf Certificate Managers
Gruppo amministrativo che gestisce i registri di controllo e protezione della CA ca_setup.wsf CA Auditors
Gruppo amministrativo che gestisce i backup della CA ca_setup.wsf CA Backup Operators
Configurazione IIS    
Nome della directory virtuale IIS utilizzata per pubblicare il certificato CA e i CRL Pkiparams.vbs pki
Percorso fisico nella CA di emissione mappato alla directory virtuale IIS C:\CAWWWPub Pkiparams.vbs
Parametri comuni della CA    
Unità e percorso di memorizzazione dei file di richiesta di Servizi certificati C:\CAConfig Pkiparams.vbs
Unità e percorso di memorizzazione dei registri del database di Servizi certificati   %windir%\System32\CertLog
Configurazione della CA principale    
Lunghezza della chiave della CA principale (vedere la nota che segue questa tabella) 4096  
Periodo di validità del certificato della CA principale (anni) Pkiparams.vbs 16
Periodo massimo di validità dei certificati rilasciati dalla CA principale (anni) Pkiparams.vbs 8
Intervallo di pubblicazione dei CRL della CA principale (mesi) Pkiparams.vbs 6
Periodo di sovrapposizione dei CRL (giorni) Pkiparams.vbs 10
Periodo di pubblicazione dei Delta CRL della CA principale (ore, 0=disattivato) Pkiparams.vbs 0
Parametri della CA di emissione    
Unità e percorso di memorizzazione del database di Servizi certificati   D:\CertLog
Lunghezza della chiave della CA di emissione   2048
Periodo di validità del certificato della CA di emissione (anni) Pkiparams.vbs 8
Periodo massimo di validità dei certificati rilasciati dalla CA di emissione (anni) Pkiparams.vbs 4
Intervallo di pubblicazione dei CRL della CA di emissione (giorni) Pkiparams.vbs 7
Periodo di sovrapposizione dei CRL (giorni) Pkiparams.vbs 4
Periodo di pubblicazione dei Delta CRL per la CA di emissione (ore, 0=disattivato) Pkiparams.vbs 1
Periodo di sovrapposizione dei Delta CRL (giorni) Pkiparams.vbs 1
Altro    
Percorso degli script di installazione   C:\MSSScripts
**Nota**   L'utilizzo di una chiave della lunghezza di 4096 bit potrebbe causare problemi di compatibilità, se i certificati devono essere utilizzati da alcuni dispositivi o versioni precedenti di software di alcuni fornitori. È necessario testare le applicazioni utilizzando certificati con una chiave del certificato della CA principale di queste dimensioni. La lunghezza della chiave della CA principale può essere ridotta a 2048 bit in caso di problemi di compatibilità dovuti alla lunghezza della chiave. ###### Installazione degli script di configurazione nei server CA Per semplificare alcuni aspetti della configurazione di questa soluzione, nelle sezioni seguenti vengono forniti diversi script di supporto. Questi script devono essere installati in ciascun server CA, senza eliminarli dopo l'utilizzo, in quanto servono per il funzionamento dei server. Per installare gli script, creare una cartella denominata C:\\MSSScripts e copiare gli script all'interno di questa directory. ###### Installazione e configurazione di IIS nel server della CA di emissione Internet Information Services (IIS) funge da punto di download dei certificati CA e dei CRL per i client non Windows. Non è necessario che la CA principale fornisca questo servizio, soprattutto perché non deve essere collegata alla rete, tuttavia la CA di emissione deve poter accedere al servizio. IIS può inoltre essere utilizzato per ospitare le pagine di registrazione Web di Servizi certificati, anche se ciò non è previsto da questa soluzione. Se le pagine di registrazione Web sono installate in un sistema diverso dalla CA di emissione, il server deve essere contrassegnato come trusted per delega impostando la relativa proprietà sull'oggetto computer in Active Directory. IIS viene installato tramite Gestione componenti facoltativi di Windows (accessibile dal Pannello di controllo, Installazione componenti di Windows). Nella tabella seguente sono elencati i componenti da installare: - Server delle applicazioni - Abilita l'accesso COM+ alla rete - Internet Information Services - File comuni - Gestione di Internet Information Services - Servizio World Wide Web **Per installare IIS** 1. Al prompt dei comandi, eseguire 
```

Sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIIS.txt

```

Tramite questo comando, Gestione componenti facoltativi utilizza le configurazioni dei componenti specificate nel file di installazione automatica C:\\MSSScripts\\OC\_AddIIS.txt riportate di seguito:

```

[Components]
complusnetwork = On
iis_common = On
iis_asp = On
iis_inetmgr = On
iis_www = On

```

**Nota**    In questa configurazione vengono attivate le pagine ASP. Tuttavia, se le pagine di registrazione Web di Servizi certificati non sono richieste, è necessario disattivare ASP eliminando la riga **iis\_asp = on** prima di eseguire sysocmgr.exe. All'occorrenza, è possibile attivare questa impostazione in un secondo momento.

  1. Eseguire nuovamente Gestione componenti facoltativi e verificare che i componenti installati corrispondano a quelli elencati nella tabella precedente.

    sysocmgr /i:sysoc.inf

    Non sono richiesti altri sottocomponenti di Server applicazioni, quindi non è necessario eseguire altre selezioni.

Configurazione di IIS per la pubblicazione dell'accesso alle informazioni dell'autorità (AIA, Authority Information Access) e del punto di distribuzione CRL (CDP, CRL Distribution Point) nella CA di emissione
È necessario creare una directory virtuale su IIS da utilizzare come percorso del protocollo HTTP per i punti di pubblicazione del certificato CA e del CRL (AIA) e dei punti di distribuzione CRL (CDP).

Per creare una directory virtuale su IIS

  1. Accedere al server IIS con i privilegi di Amministratore locale.

  2. Creare la cartella C:\CAWWWPub che conterrà i certificati CA e i CRL.

  3. Impostare la protezione della cartella nel modo seguente:

Tabella 9. Autorizzazioni directory virtuale

User/Group Autorizzazione Consenti/Nega
Administrators Controllo completo Consentito
System Controllo completo Consentito
Creator Owners Controllo completo (solo sottocartelle e file) Consentito
Users Lettura e visualizzazione contenuto cartella Consentito
IIS_WPG Lettura e visualizzazione contenuto cartella Consentito
Account Internet Guest Scrittura Negato
4. Nella console di gestione di Internet Information Services, creare una nuova directory virtuale nel sito Web predefinito: - Assegnare alla directory virtuale il nome **pki** - Specificare **C:\\CAWWWPub** come percorso 5. Deselezionare l'opzione **Esecuzione script** nelle autorizzazioni di accesso alla directory virtuale. 6. Assicurarsi che l'autenticazione anonima per la directory virtuale sia attivata. **Selezione di un alias DNS per il punto di pubblicazione HTTP** È necessario creare un alias DNS generico (CNAME) che risolve il nome del server IIS in cui risiedono il CDP e AIA. L'alias DNS deve essere utilizzato quando si configurano i percorsi di CDP e AIA per le CA, come descritto nelle sezioni successive. Gli alias consentono di spostare facilmente i punti di pubblicazione della CA in altri server o posizioni della rete, senza dover nuovamente emettere i certificati CA. ###### Installazione e configurazione di componenti aggiuntivi del sistema operativo Oltre alle procedure di configurazione fin qui descritte, è consigliata l'installazione e la configurazione di altri componenti, inclusi: - Servizio Aggiorna certificati principali. È necessario disattivare il servizio Aggiorna certificati principali in quanto non è consigliabile che la trust della directory principale delle CA venga aggiornata automaticamente. Per rimuovere questo servizio, utilizzare i comandi seguenti al prompt dei comandi: 
```
sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_RemoveRootUpdate.txt

```

Il file OC\_RemoveRootUpdate.txt contiene le righe seguenti:

```

[Components]
rootautoupdate = off
```

  • Verificare che la CA principale non sia collegata alla rete e che sulla CA di emissione non vi sia connettività Internet in entrata o in uscita.

  • Verificare la disponibilità di nuovi Service Pack o aggiornamenti che potrebbero essere richiesti a seguito dell'installazione di IIS.

  • Installare Windows Server 2003 Support Tools. Sebbene non siano essenziali, gli strumenti di supporto di Windows 2003 sono utili per alcune operazioni della CA e per la risoluzione dei problemi.

  • Installare CAPICOM. CAPICOM 2.1 è richiesto nella CA principale e nella CA di emissione per molti degli script di impostazione e di gestione descritti in questa guida. Per ulteriori informazioni su CAPICOM e il relativo percorso di download, vedere www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6&DisplayLang=it.

Preparazione di Active Directory per l'infrastruttura PKI

I requisiti fondamentali per un'infrastruttura di dominio di Active Directory descritti in questa sezione sono basati su un'architettura Active Directory di Microsoft Windows Server 2003. Se è in uso un'implementazione di Active Directory di Windows 2000, i requisiti possono variare. Per informazioni su questi ulteriori requisiti per una struttura di dominio basata su Windows 2000, vedere l'articolo Aumento dei livelli funzionalità di dominio e di insieme di strutture in Windows Server 2003 all'indirizzo http://support.microsoft.com/kb/322692.

La soluzione richiede un livello funzionale minimo di dominio nella modalità nativa di Windows 2000, almeno per il dominio in cui sono installati i server dell'autorità di certificazione. Tale requisito è necessario perché la soluzione si avvale dei gruppi universali di Active Directory, disponibili appunto a partire dalla modalità nativa di Windows 2000.

Creazione dei gruppi amministrativi della PKI e delle CA
In questa soluzione vengono definiti più gruppi di protezione che corrispondono a ruoli amministrativi distinti. Ciò conferisce un ampio controllo sulle modalità di delega dell'amministrazione delle CA e principi di protezione basati su privilegi ridotti. Tuttavia, non è necessario utilizzare questi ruoli, se essi non corrispondono al modello di amministrazione desiderato.

Per creare gruppi amministrativi delle CA nel dominio

  1. Accedere a un computer membro del dominio con un account che dispone di autorizzazioni sufficienti per creare oggetti utente e gruppo nel contenitore di utenti.

  2. Per creare i gruppi di gestione CA del dominio, eseguire il comando seguente:

    Cscript //job:CertDomainGroups C:\MSSScripts\ca_setup.wsf

    Questo script crea i gruppi di protezione elencati nella tabella seguente. I gruppi sono creati come gruppi universali nel contenitore di utenti del dominio e devono quindi essere spostati a un'unità organizzativa (UO) più appropriata, a seconda dei criteri in uso all'interno dell'organizzazione.

    Tabella 10. Nomi e scopi dei gruppi

    Nome gruppo Scopo
    Enterprise PKI Admins Amministratori del contenitore di configurazione Servizi chiave pubblica
    Enterprise PKI Publishers Gruppo autorizzato a pubblicare elenchi CRL e certificati CA nei contenitori della configurazione dell'organizzazione
    CA Admins Dispone di privilegi amministrativi completi sulla CA, inclusa la determinazione dell'appartenenza di altri ruoli
    Certificate Managers Gestisce il rilascio e la revoca dei certificati
    CA Auditors Gestisce i dati di controllo per la CA
    CA Backup Operators Dispone delle autorizzazioni a eseguire il backup e il ripristino delle chiavi e dei dati della CA

Le procedure di configurazione descritte nel resto del documento richiedono l'utilizzo di account membri dei gruppi Enterprise PKI Admins, Enterprise PKI Publishers e CA Admins, pertanto è necessario popolare questi gruppi con gli account appropriati prima di continuare. Se una sola persona è responsabile di tutti i ruoli relativi alla CA, è possibile assegnare a tutti i gruppi un solo account. Tuttavia, in molte aziende esiste un certo grado di suddivisione di ruoli e compiti tra più persone, anche se il livello di specificità sarà inferiore a quello della tabella precedente. Per le aziende con una separazione semplificata delle attività, nella tabella seguente sono elencate le suddivisioni di responsabilità comuni.

Tabella 11. Modello di amministrazione semplificato

Ruolo amministrativo Appartenenza a gruppo
CA Administrator Enterprise PKI Admins, CA Admins, Certificate Managers, Administrators
CA Auditor CA Auditors, Administrators
CA Backup Operator CA Backup Operators
##### Struttura delle unità organizzative del dominio consigliata Esistono diversi tipi di gruppi e account utente associati alla gestione e al funzionamento di una PKI. Per consentire una più facile gestione dei gruppi e degli utenti, è possibile riunirli in unità organizzative (UO). La tabella seguente illustra la struttura consigliata, che potrà essere modificata in base alle esigenze della propria azienda. **Per creare la gerarchia delle unità organizzative di Servizi certificati** 1. Accedere con un account che disponga delle autorizzazioni per creare UO e delegare le autorizzazioni all'interno di queste stesse UO. 2. Creare la struttura delle UO in base alla tabella seguente: **Tabella 12. Esempio di struttura delle UO** 
<table style="border:1px solid black;">
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th style="border:1px solid black;" >Organizational Unit, Unità organizzativa</th>
<th style="border:1px solid black;" >Scopo</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="border:1px solid black;">Servizi certificati</td>
<td style="border:1px solid black;">Unità organizzativa principale</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">\-Amministrazione Servizi certificati</td>
<td style="border:1px solid black;">Contiene i gruppi amministrativi per la gestione delle CA e la configurazione della PKI dell'organizzazione.</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">\-Gestione dei modelli di certificato</td>
<td style="border:1px solid black;">Contiene i gruppi per la gestione dei singoli modelli di certificato.</td>
</tr>
<tr class="even">
<td style="border:1px solid black;">\-Registrazione dei modelli di certificato</td>
<td style="border:1px solid black;">Contiene i gruppi ai quali è stata concessa l’autorizzazione di registrazione o registrazione automatica sui modelli con lo stesso nome. Il controllo di questi gruppi può essere delegato al personale appropriato senza modificare i modelli stessi.</td>
</tr>
<tr class="odd">
<td style="border:1px solid black;">\-Utenti test di Servizi certificati</td>
<td style="border:1px solid black;">Contiene account test temporanei.</td>
</tr>
</tbody>
</table>
  1. Assegnare le autorizzazioni al gruppo Enterprise PKI Admins per creare ed eliminare gruppi nell'UO di Servizi certificati e in tutti i contenitori figli.

Concessione delle autorizzazioni al contenitore Servizi chiave pubblica

È necessario modificare la protezione sul contenitore Servizi chiave pubblica per consentire al gruppo Enterprise PKI Admins di installare le CA dell'organizzazione e configurare i modelli di certificato senza dover appartenere al gruppo Enterprise Admins e per consentire al gruppo Enterprise PKI Publishers di pubblicare elenchi di revoca certificati e certificati CA senza dover appartenere al gruppo Enterprise Admins.

Per eseguire le modifiche seguenti è necessario utilizzare un account di membro del gruppo Enterprise Admins di Active Directory.

Per assegnare le autorizzazioni al gruppo Enterprise PKI Admins

  1. Accedere come membro del gruppo di protezione Enterprise Admins.

  2. Nello snap-in di Microsoft Management Console (MMC) di Siti e servizi Active Directory, visualizzare il nodo Servizi dal menu Visualizza. Selezionare il sottocontenitore Servizi chiave pubblica e visualizzare le relative proprietà.

  3. Nella scheda Protezione aggiungere il gruppo di protezione Enterprise PKI Admins e concedergli il privilegio Controllo completo.

  4. Nella vista Avanzate, modificare le autorizzazioni del gruppo per garantire che il privilegio venga applicato all'oggetto specificato e a tutti gli oggetti figlio.

  5. Selezionare il contenitore Servizi e visualizzare le relative proprietà.

  6. Nella scheda Protezione aggiungere il gruppo di protezione Enterprise PKI Admins e concedergli il privilegio Controllo completo.

  7. Nella vista Avanzate, modificare le autorizzazioni del gruppo per garantire che il privilegio venga applicato solo all'oggetto specificato.

Per assegnare le autorizzazioni al gruppo Enterprise PKI Publishers

  1. Accedere come membro del gruppo di protezione Enterprise Admins.

  2. Nello snap-in MMC di Siti e servizi di Active Directory visualizzare il nodo Servizi e aprire le proprietà del contenitore Servizi chiave pubblica\AIA.

  3. Nella scheda Protezione aggiungere il gruppo di protezione Enterprise PKI Publishers e concedergli le seguenti autorizzazioni:

    • Lettura

    • Scrittura

    • Crea tutti gli oggetti figli

    • Elimina tutti gli oggetti figli

  4. Nella vista Avanzate, modificare le autorizzazioni del gruppo per garantire che le autorizzazioni vengano applicate all'oggetto specificato e a tutti gli oggetti figlio.

  5. Ripetere i passaggi da 2 a 4 per i contenitori seguenti:

    • Servizi chiave pubblica\CDP

    • Servizi chiave pubblica\Autorità di certificazione

Assegnazione delle autorizzazioni al gruppo Cert Publishers

Il gruppo di protezione Cert Publishers contiene gli account computer di tutte le CA dell'organizzazione nel dominio. Questo gruppo viene utilizzato per concedere autorizzazioni agli oggetti utente e computer e agli oggetti inclusi nel contenitore CDP menzionato nella procedura precedente. Quando viene installata una CA, è necessario aggiungere il relativo account computer a tale gruppo.

Per consentire ai membri di Enterprise PKI Admins di installare le CA dell'organizzazione, è necessario modificare le autorizzazioni di questo gruppo di protezione.

Per assegnare l'autorizzazione per modificare l'appartenenza al gruppo Cert Publishers

  1. Accedere come membro di Domain Admins del dominio in cui viene installata la CA di emissione.

  2. Aprire lo snap-in MMC Utenti e computer di Active Directory.

  3. Dal menu Visualizza di MMC, assicurarsi che Caratteristiche avanzate sia selezionato.

  4. Individuare il gruppo Cert Publishers (incluso per impostazione predefinita nel contenitore di utenti) e visualizzare le proprietà del gruppo.

  5. Dalla scheda Protezione, aggiungere il gruppo Enterprise PKI Admins e fare clic su Avanzate.

  6. Selezionare il gruppo Enterprise PKI Admins dall'elenco e fare clic su Modifica.

  7. Selezionare la scheda Proprietà e assicurarsi che sia selezionato Solo l'oggetto specificato nella casella Applica a.

  8. Scorrere verso il basso e fare clic sulla casella dei membri con privilegi di scritturanella colonna Consenti.

  9. Chiudere tutte le finestre di dialogo e salvare le modifiche facendo clic su OK in ogni finestra.

  10. Riavviare il server della CA di emissione prima di installare il componente Servizi certificati. In questo modo si consentirà al server di rilevare i membri del nuovo gruppo nel proprio token di accesso.

Assegnazione delle autorizzazioni di ripristino a Enterprise PKI Admins

Per installare le CA dell'organizzazione è necessario disporre dei diritti di ripristino di file e directory nel dominio in cui si sta installando Servizi certificati. Più specificamente, questo diritto è richiesto per consentire l'unione dei descrittori di protezione dei modelli e di altri oggetti della directory e, quindi, per assegnare le autorizzazioni corrette agli oggetti PKI del dominio. I gruppi di dominio incorporati Administrators, Server Operators e Backup Operators dispongono di questo diritto per impostazione predefinita.

Poiché si utilizzerà il gruppo Enterprise PKI Admins per eseguire l'installazione della CA, è necessario assegnare i diritti di ripristino di file e directory al gruppo.

Per assegnare i diritti di ripristino a Enterprise PKI Admins

  1. Accedere come membro di Domain Admins del dominio in cui viene installata la CA di emissione.

  2. Aprire lo snap-in MMC Utenti e computer di Active Directory.

  3. Selezionare l'UO dei controller di dominio e visualizzare le proprietà dell'UO.

  4. Nella scheda Criteri di gruppo, selezionare l'oggetto Criterio controller di dominio predefinito, quindi fare clic su Modifica.

  5. Passare a Configurazione computer\Impostazioni di Windows\Impostazioni protezione\Criteri locali\Assegnazione diritti utente fare doppio clic sulla voce Ripristino di file e directory.

  6. Aggiungere il gruppo Enterprise PKI Admins all'elenco visualizzato.

  7. Chiudere la finestra di dialogo e la console MMC di modifica degli oggetti Criteri di gruppo.

    Nota   Se si dispone di altri oggetti Criteri di gruppo che impostano il diritto utente Ripristino di file e directory nei controller di dominio, è necessario eseguire la procedura sopra descritta sugli oggetti Criteri di gruppo utilizzando la massima priorità anziché sul Criterio controller di dominio predefinito. Le impostazioni dei diritti utente non sono cumulative e sarà valido solo l'ultimo oggetto Criteri di gruppo per il quale sono stati impostati questi diritti.

Distribuzione di un server Autorità di certificazione principale

Come affermato in precedenza, questa guida non fornisce istruzioni dettagliate per l'installazione di Windows Server 2003 in quanto la maggior parte delle aziende dispone già di un processo di creazione server documentato. Tuttavia, a differenza degli altri tipi di server, i server CA principale non devono mai essere collegati alla rete per evitare che vengano compromessi.

È pertanto importante verificare che il server CA principale non venga mai collegato alla rete durante il processo di creazione e che le schede di rete vengano disattivate per prevenire un collegamento accidentale. È inoltre importante osservare che non essendo collegato alla rete, il server risiederà in un gruppo di lavoro il cui nome dovrà essere scelto e documentato prima dell'installazione.

Nota   Anche se la CA principale viene creata e mantenuta non in linea, è fondamentale che il nome della CA sia univoco all'interno dell'ambiente di rete.

File CAPolicy.inf

Una volta individuato l'hardware necessario per il server CA e installato il sistema operativo, si potrà procedere alla creazione del file capolicy.inf. Il file capolicy.inf è necessario per creare la CA principale in quanto specifica le caratteristiche del certificato della CA principale autofirmato, quali la lunghezza della chiave e il periodo di validità del certificato.

I dati CRL e AIA non sono richiesti per il certificato della CA principale, pertanto sarà possibile lasciare vuoti i parametri CRLDistributionPoint e AuthorityInformationAccess del file capolicy.inf.

Per creare il file CAPolicy.inf

  1. Immettere il testo seguente in un editor di testo, ad esempio Blocco note:

    
[version]
Signature=”$Windows NT$”

[Certsrv_server]
RednewalKeyLength=4096
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=16

[CRLDistributionPoint]
Empty=true

[AuthorityInformationAccess]
Empty=true

  2. Se è stata definita una dichiarazione sulle procedure di certificazione (CPS) per la CA, includere quanto segue nel file capolicy.inf, sostituendo ai valori in corsivo i valori della propria organizzazione:

    
[CAPolicy]
Policies=nome CPS dell'azienda

[company CPS name]
OID=OID. azienda
URL=”http://www.urlazienda.com/nomepaginacps.htm”

  3. Salvare il file di testo come %windir%\Capolicy.inf (sostituire a %windir% il percorso assoluto della cartella di installazione di Windows, ad esempio C:\Windows). Per completare questo passaggio è necessario essere un amministratore locale o disporre delle autorizzazioni di scrittura nella cartella di Windows.

Installazione dei componenti software di Servizi certificati

Utilizzare Aggiunta guidata componenti di Windows per installare i componenti software della CA. Per completare l'installazione è necessario disporre del supporto di installazione di Windows Server 2003.

Per installare Servizi certificati

  1. Accedere come membro del gruppo Administrators locale ed eseguire Gestione componenti facoltativi (oppure selezionare Installazione applicazioni/Componenti di Windows dal Pannello di controllo).

    
sysocmgr /i:sysoc.inf

  2. Selezionare il componente Servizi certificati (fare clic su Sì per eliminare il messaggio di avviso relativo alla ridenominazione).

  3. Selezionare CA principale autonoma (standalone) come tipo di CA verificando che sia selezionata la casella di controllo Utilizzare impostazioni personalizzate.

  4. Nella finestra di dialogo Coppia di chiavi pubblica e privata lasciare le impostazioni predefinite, eccetto la lunghezza della chiave, che deve essere impostata su 4096, e il Tipo CSP, che deve essere impostato su Microsoft Strong Cryptographic Provider.

  5. Immettere le informazioni di identificazione della CA raccolte nella fase relativa ai requisiti preliminari nel modo seguente:

    • Nome comune CA:

    • Suffisso nome distinto:

    • Periodo di validità: 8 anni

    A questo punto il CSP genera la coppia di chiavi che viene memorizzata nell'archivio delle chiavi del computer locale.

    Nota   Se in precedenza è già stata installata nel computer una CA, viene visualizzato un messaggio di avviso in cui si richiede di confermare se sovrascrivere la chiave privata dell'installazione precedente. Verificare se la chiave può essere eliminata prima di procedere.

  6. Non modificare i percorsi predefiniti del database dei certificati, dei registri del database e della cartella di configurazione. Gestione componenti facoltativi installa quindi i componenti di Servizi certificati. In questa fase del processo, verrà richiesto di inserire il supporto di installazione di Windows Server 2003.

  7. Fare clic su OK per eliminare l'avviso relativo a IIS e continuare l'installazione fino al termine.

Configurazione delle proprietà della CA principale

Per la procedura di configurazione della CA principale, vengono applicati una serie di parametri specifici dell'ambiente aziendale. I valori di tali parametri dovranno già essere stati rilevati, come descritto in precedenza nella sezione relativa ai requisiti preliminari.

Per configurare le proprietà della CA principale

  1. Accedere al server CA come membro del gruppo Administrators locale.

  2. Personalizzare lo script C:\MSSScripts\pkiparams.vbs nel modo seguente:

    • Modificare il valore dell'impostazione AD_ROOT_DN in modo che corrisponda al nome distinto del dominio principale della foresta di Active Directory.

    • Modificare l'impostazione HTTP_PKI_VROOT in modo che corrisponda al percorso HTTP della directory virtuale IIS impostata precedentemente.

  3. Eseguire lo script seguente:

    
Cscript //job:RootCAConfig C:\MSSScripts\ca_setup.wsf

Configurazione dei ruoli amministrativi

Per utilizzare i ruoli amministrativi nella CA, ad esempio controllori e gestori di certificati, è necessario innanzitutto mappare ad essi i gruppi di protezione creati precedentemente.

Nota   Anche se è probabile che la maggior parte delle medie aziende utilizzi il modello di delega semplificato descritto in precedenza in questa guida, in questa sezione viene illustrato un modello più flessibile e adatto a soddisfare eventuali requisiti di maggiore separazione.

Per configurare i ruoli amministrativi nella CA principale

  1. Dalla console di gestione dell'autorità di certificazione, fare clic su Proprietà.

  2. Fare clic sulla scheda Protezione e aggiungere i gruppi di protezione locali elencati nella tabella seguente. Per ciascun gruppo aggiungere l'autorizzazione elencata.

    Tabella 13. Autorizzazioni CA

    Group Autorizzazione Consenti/Nega
    CA Admins Gestione CA Consentito
    Certificate Managers Rilascio e gestione certificati Consentito

  3. Altri ruoli di protezione per questa CA sono già stati definiti tramite i criteri di protezione applicati precedentemente.

Trasferimento del certificato e del CRL della CA principale su disco

È necessario copiare dalla CA il certificato e il CRL della CA principale in modo che possano essere pubblicati in Active Directory e nel server di pubblicazione dei certificati IIS e dei CRL. Anche se in questo esempio si parla genericamente di utilizzo di un disco, sarà possibile utilizzare qualsiasi supporto portatile, incluse le unità USB.

Per copiare il certificato e il CRL della CA principale sul disco

  1. Accedere alla CA principale come membro del gruppo CA Admins locale, quindi inserire il supporto nel server.

  2. Eseguire lo script seguente per copiare il certificato CA sul disco:

    
Cscript //job:GetCACerts C:\MSSScripts\CA_Operations.wsf

  3. Eseguire lo script seguente per copiare il CRL della CA sul disco:

    
Cscript //job:GetCRLs C:\MSSScripts\CA_Operations.wsf

  4. Etichettare, datare e conservare il disco per le fasi successive della procedura.

Pubblicazione delle informazioni della CA principale

Prima di installare la CA di emissione, è necessario pubblicare il certificato della CA principale nell'archivio principale attendibile di Active Directory e il CRL della CA principale nel contenitore CDP di Active Directory. In questo modo, tutti i membri del dominio importeranno il certificato della CA principale nei propri archivi principali e li attiveranno per verificare lo stato di revoca di eventuali certificati rilasciati dalla CA principale.

Anche se è possibile utilizzare qualsiasi membro del dominio che esegua Windows Server 2003 in cui siano installati i file certutil.exe e le DLL richieste, è preferibile eseguire la procedura seguente utilizzando la CA di emissione in quanto contiene le librerie certutil.exe, certadm.dll, certcli.dll richieste.

Per pubblicare il certificato e il CRL della CA principale in Active Directory

  1. Accedere a un computer membro del dominio in possesso dei requisiti indicati in precedenza come membro del gruppo Enterprise PKI Admins e inserire il disco in cui sono stati salvati il certificato e il CRL della CA principale.

  2. Eseguire lo script seguente per pubblicare il certificato CA in Active Directory:

    Cscript //job:PublishCertstoAD C:\MSSScripts\CA_Operations.wsf

  3. Eseguire lo script seguente per pubblicare il CRL in Active Directory:

    
Cscript //job:PublishCRLstoAD C:\MSSScript\CA_Operations.wsf

Pubblicazione del certificato e del CRL della CA principale nel server Web

Questo passaggio è necessario, in quanto le versioni HTTP degli URL CDP e AIA vengono specificate nelle estensioni dei certificati emessi dalla CA. Se sono presenti tali estensioni, è necessario tenerne conto pubblicando i CRL e i certificati negli URL indicati.

Nota   Questa procedura non varia a seconda che il server Web di pubblicazione CDP e AIA si trovi nella CA di emissione o in un altro server, tuttavia si presume che la directory virtuale corrisponda a quella impostata nella procedura di configurazione IIS descritta precedentemente (C:\CAWWWPub). Se il percorso è diverso, sarà necessario aggiornare il valore WWW_LOCAL_PUB_PATH dello script PKIParams.vbs.

Per pubblicare il certificato e il CRL della CA principale in un URL Web

  1. Accedere al server Web come amministratore locale o con un account equivalente.

  2. Assicurarsi che il disco contenente i certificati e i CRL della CA sia inserito nell'unità.

  3. Eseguire lo script seguente per pubblicare il certificato CA nella cartella sul server Web:

    
Cscript //job:PublishRootCerttoIIS
C:\MSSScripts\CA_Operations.wsf

  4. Eseguire lo script seguente per pubblicare i CRL della CA nella cartella sul server Web:

    Cscript //job:PublishRootCRLstoIIS
C:\MSSScripts\CA_Operations.wsf
Distribuzione di un server Autorità di certificazione di emissione

Una volta installata la CA principale e pubblicati i relativi certificati, è possibile distribuire il server CA di emissione. L'installazione di Servizi certificati comporta una serie di complesse interazioni tra la CA di emissione, la CA principale, Active Directory e il server Web. Per semplificare la comprensione di tali interazioni è utile consultare il diagramma seguente come riferimento.

Figura 5. Processo di installazione del certificato

Le interazioni contrassegnate da numeri nel diagramma rappresentano:

  1. Pubblicazione del certificato e del CRL della CA principale in Active Directory utilizzando un supporto rimovibile.

  2. Pubblicazione del certificato e del CRL della CA principale nel server Web utilizzando un supporto rimovibile.

  3. Installazione del software Servizi certificati che genera una richiesta di certificato da trasferire alla CA principale utilizzando un supporto rimovibile. Il certificato viene rilasciato dalla CA principale.

  4. Installazione del corrispondente certificato della CA di emissione tramite un supporto rimovibile.

  5. Pubblicazione del certificato e del CRL della CA di emissione nel server Web.

    x.   Questo passaggio avviene automaticamente durante la routine di installazione della CA dell'organizzazione.

Preparazione del file CApolicy.inf per la CA di emissione

Il file CAPolicy.inf non è indispensabile per la CA di emissione, tuttavia sarà necessario se si desidera modificare le dimensioni della chiave utilizzata dalla CA. È necessario creare il file CApolicy.inf prima di impostare la CA di emissione, sebbene sia possibile aggiungerne uno e rinnovare il certificato CA in seguito.

Per creare il file CAPolicy.inf

  1. Accedere al server CA di emissione come amministratore locale o con un account equivalente.

  2. Immettere il testo seguente in un editor di testo, ad esempio Blocco note:

    
[Version]
Signature= “$Windows NT$”

[Certsrv_Server]
RenewalKeyLength=2048

  3. Se è stata definita una CPS per la CA, includere quanto segue nel file CApolicy.inf:

    [CAPolicy]
Policies=nomecriterio

[policyname]
OID=oid.azienda
URL=”http://http://urlazienda.com/NomePaginaCPS.htm/”

    Nota   I valori in corsivo devono essere sostituiti con le informazioni relative alla propria organizzazione.

  4. Salvare il file come %windir%\Capolicy.inf (sostituire a %windir% il percorso assoluto della cartella di installazione di Windows, ad esempio C:\Windows).

Installazione dei componenti software di Servizi certificati

Analogamente alla procedura di installazione dei servizi certificati nella CA principale, anche questo passaggio richiede l'utilizzo del supporto di installazione di Windows Server 2003 e di Aggiunta guidata componenti di Windows.

Per installare Servizi certificati

  1. Accedere alla CA di emissione come membro del gruppo Administrators locale ed eseguire Gestione componenti facoltativi:

    sysocmgr /i:sysoc.inf

  2. Selezionare il componente Servizi certificati e fare clic su OK per eliminare il messaggio di avviso relativo alla ridenominazione.

  3. Selezionare il tipo di CA CA subordinata dell'organizzazione verificando che sia selezionata la casella di controllo Utilizzare impostazioni personalizzate.

  4. Nella finestra di dialogo Coppia di chiavi pubblica e privata lasciare le impostazioni predefinite, eccetto le impostazioni seguenti:

    • Lunghezza della chiave: 2048 bit

    • Tipo CSP: Microsoft Strong Cryptographic Provider

  5. Immettere le seguenti informazioni di identificazione della CA:

    • Nome comune CA

    • Suffisso nome distinto

    • Periodo di validità: (determinato dalla CA padre)

  6. A questo punto il CSP genera la coppia di chiavi che viene memorizzata nell'archivio delle chiavi del computer locale.

  7. Immettere i percorsi predefiniti del database dei certificati, dei registri del database e della cartella di configurazione nel modo seguente:

    • Database dei certificati: D:\CertLog

    • Registro database dei certificati: %windir%\System32\CertLog

    • Cartella condivisa: Disabilitato

    Per garantire prestazioni e capacità di recupero, memorizzare sempre il database CA e i registri su volumi fisicamente separati. È necessario posizionare il database dei certificati e i relativi registri nelle unità NTFS locali.

  8. A questo punto viene generato un file di richiesta del certificato che dovrà essere copiato sul disco. Gestione componenti facoltativi installa quindi i componenti di Servizi certificati. In questa fase del processo, verrà richiesto di inserire il supporto di installazione di Windows Server 2003.

  9. Fare clic su OK per eliminare l'avviso relativo a IIS e continuare l'installazione fino al termine. La procedura di installazione guidata visualizzerà un avviso in cui si informa l'utente che deve ottenere il certificato dalla CA padre per continuare.

Invio della richiesta di certificato alla CA principale

È necessario inviare la richiesta di certificato della CA di emissione alla CA principale in modo che possa essere firmata e il certificato possa essere rilasciato alla CA di emissione.

Per inviare la richiesta di certificato alla CA principale

  1. Accedere alla CA principale come membro del gruppo Certificate Managers locale.

  2. Verificare che il disco su cui è stato salvato il file della richiesta di certificato sia inserito nell'unità.

  3. Dalla console di gestione dell'autorità di certificazione, nel menu Attività della CA selezionare Invia nuova richiesta quindi inviare la richiesta trasferita dalla CA di emissione.

  4. Individuare il certificato appena rilasciato nel contenitore Certificati emessi e aprirlo.

  5. Verificare che i dettagli del certificato siano corretti, quindi esportare il certificato in un file facendo clic su Copia su file e salvarlo con il nome PKCS#7 (selezionare l'opzione che consente di includere tutti i certificati possibili nella catena) su un disco.

Aggiornamento del certificato nella CA di emissione

Il certificato della CA principale è stato pubblicato precedentemente nell'archivio principale attendibile di Active Directory. È necessario ora assicurare che la CA di emissione abbia scaricato le informazioni e inserito il certificato nel proprio archivio principale.

Per aggiornare e verificare le informazioni sulla relazione di trust del certificato nella CA di emissione

  1. Accedere alla CA di emissione come amministratore locale o con un account equivalente.

  2. Al prompt dei comandi, eseguire:

    certutil –pulse

    Questo comando forzerà il download delle informazioni sul nuovo certificato principale attendibile dalla directory e inserirà il certificato nell'archivio principale attendibile locale. Anche se questo passaggio non è indispensabile, consente di verificare che la procedura di pubblicazione precedente sia stata eseguita correttamente.

  3. Eseguire mmc.exe e aggiungere lo snap-in Certificati.

  4. Selezionare Account del computer come archivio certificati da gestire.

  5. Verificare che il certificato della CA principale si trovi nella cartella Autorità di certificazione principale attendibili.

Installazione del certificato nella CA di emissione

La risposta con la firma inviata dalla CA principale è stata salvata come pacchetto di certificato PKCS#7 e può quindi venire installata nella CA di emissione. Per pubblicare il certificato CA nell'archivio NTAuth di Active Directory (che identifica la CA come CA dell'organizzazione), è necessario installare il certificato CA utilizzando un account che sia membro sia del gruppo Enterprise PKI Admins, sia del gruppo Administrators locale della CA di emissione. Il primo gruppo dispone dei diritti di pubblicare il certificato nella directory, mentre il secondo dispone dei diritti di installare il certificato nel server CA. Se si sta utilizzando il modello di amministrazione semplificato suggerito in precedenza, il ruolo CAAdmin è già membro di entrambi i gruppi.

Per installare il certificato della CA di emissione

  1. Accedere alla CA di emissione utilizzando un account membro sia del gruppo Enterprise PKI Admins, sia del gruppo Administrators locale.

  2. Inserire il disco con il certificato firmato rilasciato dalla CA principale.

  3. Dalla console di gestione dell'autorità di certificazione, nel menu Attività della CA, selezionare Installa certificato per installare il certificato della CA di emissione dal disco.

    A questo punto la CA viene avviata.

Configurazione delle proprietà della CA di emissione

Questa procedura consente di configurare i parametri specifici dell'ambiente aziendale raccolti nella fase relativa ai requisiti preliminari della CA di emissione. Prima di procedere con questo passaggio, è importante verificare che le informazioni relative alla propria organizzazione raccolte nella fase relativa ai requisiti preliminari siano state inserite nel file C:\MSSScripts\pkiparams.vbs nella CA principale e che queste modifiche siano state trasferite anche alla CA di emissione.

Per configurare le proprietà della CA di emissione

  1. Accedere al server CA di emissione come membro del gruppo Administrators locale.

  2. Verificare che le modifiche apportate al file C:\MSSScripts\pkiparams.vbs corrispondano alle impostazioni specifiche del proprio ambiente precedentemente descritte in questa sezione.

  3. Eseguire lo script seguente:

    
Cscript //job:IssCAConfig C:\MSSScripts\ca_setup.wsf

Configurazione dei ruoli amministrativi nella CA di emissione

Per utilizzare i ruoli amministrativi descritti in questa guida è necessario innanzitutto mappare ad essi i gruppi di protezione. Come affermato in precedenza, anche se l'utilizzo di ruoli semplificati può essere sufficiente per le esigenze della maggior parte delle medie aziende, il processo prevede l'implementazione di ruoli dettagliati al fine di garantire la massima flessibilità e separazione delle responsabilità.

Per configurare i ruoli amministrativi nella CA di emissione

  1. Accedere al server CA di emissione come membro del gruppo Administrators locale.

  2. Dalla console di gestione dell'autorità di certificazione, accedere alle proprietà della CA per modificarle.

  3. Fare clic sulla scheda Protezione e aggiungere i gruppi di protezione del dominio elencati nella tabella seguente. Per ciascun gruppo aggiungere l'autorizzazione indicata.

    Tabella 14. Autorizzazioni CA di emissione

    Group Autorizzazione Consenti/Nega
    CA Admins Gestione CA Consentito
    Certificate Managers Rilascio e gestione certificati Consentito

  4. È necessario aggiungere il gruppo CA Auditors al gruppo Administrators locale anche se il gruppo è già stato parzialmente definito tramite i criteri di protezione applicati precedentemente.

Pubblicazione delle informazioni della CA di emissione

I certificati e i CRL vengono pubblicati automaticamente dalla CA di emissione in Active Directory. La pubblicazione del certificato CA e dei CRL nei percorsi HTTP di CDP e AIA, tuttavia, non è automatica; per garantire la pubblicazione automatica del certificato in tali percorsi è necessario impostare un processo pianificato.

Poiché il certificato CA viene aggiornato molto raramente, è possibile pubblicarlo manualmente nel percorso AIA attenendosi alla procedura seguente.

Per pubblicare il certificato della CA di emissione

  1. Accedere alla CA di emissione utilizzando un account in possesso delle autorizzazioni di scrittura nella cartella pubblicata sul server Web.

  2. Aggiornare il parametro WWW_REMOTE_PUB_PATH in C:\MSSScripts\PKIParams.vbs in modo che corrisponda al percorso di destinazione della cartella sul server Web.

    1. Se il server Web si trova in un server remoto, assicurarsi che la relativa cartella sia condivisa e registrare il percorso UNC (Universal Naming Convention) della cartella condivisa.

    2. Se il server Web si trova nello stesso server della CA, registrare il percorso locale nella cartella (il percorso predefinito è C:\CAWWWPub).

  3. Eseguire lo script seguente per pubblicare il certificato della CA nel server Web:

    Cscript //job:PublishIssCertsToIIS 
C:\MSSScripts\CA_Operations.wsf

    Nota   Questa procedura è destinata specificamente ai server Web interni. Se i certificati sono destinati alla pubblicazione su un sito Web su Internet, è necessario svolgere ulteriori passaggi in quanto questa soluzione prevede la condivisione di file su reti Windows, che in genere viene bloccata dai firewall Internet.

La pubblicazione dei CRL è più frequente di quella dei certificati CA e pertanto richiede un metodo automatico di pubblicazione sul server Web.

Per rendere automatica la pubblicazione dei CRL

  1. Accedere alla CA di emissione con un account membro del gruppo Administrators locale.

  2. Assicurarsi che la cartella sul server Web sia accessibile da questo server.

  3. Se il server Web è remoto, assegnare alla CA di emissione l'accesso in scrittura alla cartella del file system e l'accesso in condivisione. Se il server Web è membro di una foresta, utilizzare il gruppo Cert Publishers per assegnare l'accesso; in questo modo qualsiasi CA dell'organizzazione sarà in grado di pubblicare i certificati e i CRL.

  4. Creare un processo pianificato per copiare i CRL eseguendo il comando seguente:

    Nota   Alcune parti del codice seguente sono visualizzate su più righe per migliorarne la visibilità; immettere l'intero codice su un'unica riga.

    schtasks /creat /tn “Publish CRLs” /tr “cscript.exe //job:PublishIssCRLsToIIS C:\
MSSScripts\CA_Operations.wsf” /sc Hourly /ru “System”

Rimozione dei modelli indesiderati dalla CA di emissione

Se non sono richiesti, è consigliabile rimuovere i modelli corrispondenti a tipi specifici di certificati al fine di evitarne il rilascio accidentale. In caso di necessità, i modelli potranno essere ricreati in seguito con facilità poiché rimangono sempre disponibili all'interno della directory.

Per rimuovere i modelli indesiderati dalla CA di emissione

  1. Accedere come membro del gruppo CA Admins.

  2. Dalla console di gestione dell'autorità di certificazione, selezionare il contenitore Modelli di certificato.

  3. Rimuovere i tipi di modello seguenti:

    • Agente recupero dati EFS

    • EFS di base

    • Server Web

    • Computer

    • Utente

    • Autorità di certificazione subordinata

    • Amministratore

Autenticazione Internet

In questa sezione vengono fornite informazioni dettagliate su come procedere all'implementazione di un'infrastruttura RADIUS a supporto della soluzione WLAN protetta descritta in questa guida. L'infrastruttura RADIUS qui illustrata è basata su Servizio di Autenticazione Internet (IAS) di Windows Server 2003.

Progettazione di un'infrastruttura RADIUS

Le tabelle seguenti possono essere utilizzate come fogli di lavoro per la raccolta delle informazioni preliminari a cui viene fatto riferimento all'interno della guida. Alcuni di questi requisiti preliminari possono essere impostati utilizzando gli script forniti in questa guida oppure manualmente come indicato nelle sezioni a cui sono applicabili.

Informazioni di configurazione definite dall'utente: requisiti preliminari

Nella tabella seguente vengono elencate le informazioni specifiche che differiscono in base alle caratteristiche delle singole organizzazioni. Prima di procedere oltre, è necessario verificare di avere a disposizione, deciso e registrato le informazioni richieste.

Tabella 15. Impostazioni definite dall'utente

Elemento di configurazione Impostazione
Nome DNS del dominio principale della foresta di Active Directory  
Nome di dominio NetBIOS  
Nome server IAS principale  
Nome server IAS secondario  
##### Informazioni di configurazione richieste indicate dalla soluzione Nella tabella seguente sono elencate le impostazioni che non è necessario modificare, tranne nel caso in cui sia richiesto l'utilizzo di un'impostazione diversa da quella offerta dalla soluzione. Prima di modificare eventuali valori qui indicati, assicurarsi di aver compreso a fondo le implicazioni della modifica che si intende apportare e le dipendenze di tale impostazione, incluse eventuali modifiche negli script forniti. **Tabella 16. Elementi di configurazione indicati dalla soluzione**
Elemento di configurazione Impostazione
Nome completo del gruppo amministrativo che controlla la configurazione di Servizio di Autenticazione Internet IAS Admins
Nome completo del gruppo che rivede i registri IAS delle richieste di accounting e autenticazione IAS Security Auditors
Percorso degli script di installazione C:\MSSScripts
File batch per l'esportazione della configurazione IAS IASExport.bat
File batch per l'importazione della configurazione IAS IASImport.bat
File batch per l'esportazione della configurazione client RADIUS IAS IASClientExport.bat
File batch per l'importazione della configurazione client RADIUS IAS IASClientImport.bat
Percorso dei file di backup della configurazione D:\IASConfig
Posizione dei file di registro di autenticazione e delle richieste di controllo IAS D:\IASLogs
Nome di condivisione dei file di registro delle richieste RADIUS IASLogs
###### Distribuzione dei server IAS La soluzione illustrata nelle sezioni seguenti include due server IAS in posizione centrale configurati come server RADIUS per il controllo di accesso alla rete WLAN. Tenuto conto di ciò, prima di continuare sarà necessario completare le attività seguenti. - Allocazione e configurazione dell'hardware per i server. - Installazione e configurazione del sistema operativo dei server in base alle procedure aziendali eventualmente esistenti. - Verifica che Active Directory sia in uso e correttamente funzionante. - Adozione delle procedure di protezione avanzata dei server dell'organizzazione e di altre applicazioni previste dai criteri esistenti. **Installazione degli script di configurazione** Per semplificare l'installazione della soluzione, vengono forniti numerosi script di supporto. Questi script dovranno essere installati in ogni server prima di continuare e non potranno venire eliminati neppure dopo aver completato l'intera procedura descritta in questa guida. **Per installare gli script di installazione** 1. Creare una cartella denominata C:\\MSSScripts 2. Copiare gli script dal supporto di distribuzione alla cartella. **Ulteriori requisiti software per i server** Oltre al sistema operativo e alle altre applicazioni eventualmente richieste da eventuali criteri di creazione server dell'organizzazione, è necessario installare il file eseguibile CAPICOM 2.1 e la DLL di supporto al fine di poter utilizzare gli script indicati in questa guida. Per ulteriori informazioni su [CAPICOM](http://www.microsoft.com/downloads/details.aspx?familyid=860ee43a-a843-462f-abb5-ff88ea5896f6&displaylang=it), il relativo percorso di download e le istruzioni per l'installazione, vedere www.microsoft.com/downloads/details.aspx?FamilyID=860ee43a-a843-462f-abb5-ff88ea5896f6&DisplayLang=it. **Configurazione dei gruppi amministrativi di IAS** Lo script seguente consente di creare i gruppi di protezione IAS Admins e IAS Security Auditors: 
    Cscript //job:CreateIASGroups C:\MSSScripts\IAS_Tools.wsf

Negli ambienti con più domini, è necessario creare questi gruppi nel dominio in cui risiedono i server IAS.

Dopo aver creato i gruppi richiesti, configurarli affinché possano eseguire le attività di configurazione IAS nel modo seguente:

  • Aggiungere il gruppo globale di dominio IAS Admins al gruppo Administrators locale in ogni server IAS.

  • Se IAS è installato nei controller di dominio, è necessario aggiungere il gruppo IAS Admins al gruppo Administrators per il dominio.

  • I gruppi IAS Admins e IAS Security Auditors devono essere popolati con gli account utente appropriati.

Configurazione delle impostazioni di protezione del sistema dei server

Come accennato in precedenza, questa guida presuppone che la maggior parte delle medie aziende adottino procedure e criteri di protezione avanzata dei server. Per questo motivo non vengono fornite istruzioni dettagliate relative al processo di protezione dei server richiesti dalla soluzione. Se l'organizzazione non utilizza procedure o criteri di protezione avanzata o richiede ulteriori informazioni sulla protezione dei server IAS, vedere la guida Windows 2003 Security Guide all'indirizzo http://go.microsoft.com/fwlink/?LinkId=14846 (in inglese).

Installazione e configurazione di IAS

Nella seguente sezione viene descritto come installare IAS nei server. È importante che ogni fase dell'installazione e della configurazione venga eseguita come descritto per ogni server IAS.

IAS viene installato selezionando la voce dei Servizi di rete corrispondente da Gestione componenti facoltativi di Windows (accessibile dal Pannello di controllo, Installazione componenti di Windows). Per semplificare il processo, è possibile utilizzare lo script seguente:

sysocmgr /i:sysoc.inf /u:C:\MSSScripts\OC_AddIAS.txt
Registrazione di IAS in Active Directory

È necessario registrare i server IAS in ogni dominio, aggiungendo l'account computer di ogni server IAS al gruppo di protezione Server RAS e IAS in ciascun dominio per il quale dovranno eseguire l'autenticazione. In tal modo si garantisce che i server IAS dispongano delle autorizzazioni adeguate per leggere le proprietà di accesso remoto di tutti gli account utente e computer dei domini.

Per registrare IAS in Active Directory

  1. Accedere a ciascun server con un account che dispone dei privilegi di amministratore di dominio per i domini in cui devono essere registrati i server IAS.

  2. Per il dominio predefinito, eseguire il comando seguente al prompt dei comandi:

netsh ras add registeredserver
  1. Per gli altri domini, eseguire il comando seguente al prompt dei comandi:
  
netsh ras add registeredserver domain = NomeDominio


**Nota**   In alternativa, è possibile aggiungere semplicemente l'oggetto computer del server IAS direttamente nel gruppo di protezione Server RAS e IAS tramite lo snap-in MMC Utenti e computer di Active Directory.

Creazione e protezione delle directory dati IAS

Per archiviare i dati di configurazione e del file di registro nei server IAS è necessario rispettare alcuni requisiti relativi alle directory. Per semplificare il processo di configurazione che consente la creazione e la protezione di tali directory, è possibile utilizzare il file batch seguente al prompt dei comandi:

C:\MSSScripts\IAS_Data.bat

Nota   Prima dell'esecuzione potrebbe essere necessario modificare e sostituire le voci %NomeDominio% per riflettere il nome di dominio NetBIOS dell'ambiente specifico del file batch in uso.

Configurazione del server IAS primario

È necessario selezionare uno dei server IAS nel proprio ambiente come server primario e configurarlo prima degli altri server IAS poiché questo server fungerà da modello per la configurazione di tutti i server.

Registrazione delle richieste di accounting e autenticazione

Per impostazione predefinita, IAS non registra le richieste di accounting e autenticazione RADIUS, ma si dovranno attivare entrambi i tipi di registri in modo che gli eventi di protezione vengano registrati per essere eventualmente analizzati in caso di necessità.

Per configurare la registrazione delle richieste di accounting e autenticazione

  1. Utilizzando lo snap-in MMC Servizio di Autenticazione Internet, selezionare Registrazione Accesso remoto, quindi visualizzare le proprietà del metodo di registrazione File locale.

  2. Selezionare le richieste di accounting e le richieste di autenticazione.

  3. Assicurarsi che la directory del file di registro sia D:\IASLogs e che sia selezionato il formato file Compatibile con database (questo formato consente l'importazione diretta dei file di registro all'interno di database quali Microsoft SQL Server™).

Autenticazione WLAN 802.1X

In questa sezione vengono descritti i passaggi del processo di protezione di una rete WLAN in base alle specifiche del protocollo 802.1X e alle piattaforme Windows Server 2003 e Windows XP SP1. Queste istruzioni includono informazioni sulla configurazione dei gruppi di Active Directory, la distribuzione dei certificati X.509, la modifica delle impostazioni dei server IAS, la distribuzione di Criteri di gruppo WLAN e alcuni suggerimenti per la configurazione dei punti di accesso wireless a supporto dell'implementazione di EAP-TLS 802.1X su cui è basata questa guida.

Preparazione dell'ambiente per una rete WLAN protetta

Una volta implementate le infrastrutture di certificazione e RADIUS sottostanti, è possibile procedere alla configurazione del protocollo 802.1X. Nelle tabelle seguenti sono elencate le impostazioni necessarie per il processo di raccolta delle informazioni preliminari all'implementazione. Alcune di queste impostazioni vengono attivate manualmente, mentre altre sono incluse all'interno degli script forniti in questa guida.

Impostazioni di configurazione definite dall'utente: requisiti preliminari

Prima di iniziare questa fase dell'implementazione di una rete WLAN protetta è necessario avere a disposizione o definire i parametri dipendenti dall'organizzazione elencati nella tabella seguente. È possibile utilizzare gli spazi forniti per registrare le impostazioni richieste per l'ambiente specifico.

Tabella 17. Impostazioni preliminari definite dall'utente

Elemento di configurazione Impostazione
Nome DNS del dominio principale della foresta di Active Directory  
Nome di dominio NetBIOS  
Nome server IAS principale  
Nome server IAS secondario  
##### Impostazioni di configurazione richieste indicate dalla soluzione Nella tabella seguente sono elencate le impostazioni che non è necessario modificare, tranne nel caso in cui sia richiesto l'utilizzo di un'impostazione diversa da quella offerta dalla soluzione. Prima di modificare eventuali valori qui indicati, assicurarsi di aver compreso a fondo le implicazioni della modifica che si intende apportare e le dipendenze di tale impostazione, incluse eventuali modifiche negli script forniti. **Tabella 18. Impostazioni di configurazione indicate dalla soluzione**
Elemento di configurazione Impostazione
Gruppo globale di Active Directory che controlla la distribuzione dei certificati di autenticazione utente 802.1X Registrazione automatica autenticazione client – Certificato utente
Gruppo globale di Active Directory che controlla la distribuzione dei certificati di autenticazione computer 802.1X Registrazione automatica autenticazione client – Certificato computer
Gruppo globale di Active Directory contenente i server IAS che richiedono certificati di autenticazione 802.1X Registrazione automatica certificato di autenticazione server RAS e IAS
Gruppo globale di Active Directory contenente gli utenti ai quali è consentito l'accesso alla rete wireless Criteri di accesso remoto – Utenti senza fili
Gruppo globale di Active Directory contenente i computer ai quali è consentito l'accesso alla rete wireless Criteri di accesso remoto – Computer senza fili
Gruppo universale di Active Directory contenente sia il gruppo di utenti wireless che il gruppo di computer wireless Criteri di accesso remoto – Accesso senza fili
Gruppo globale di Active Directory contenente i computer che richiedono la configurazione delle proprietà di rete wireless Criterio di rete senza fili – Computer
Modello di certificato utilizzato per generare certificati per l'autenticazione di utenti client Autenticazione client – Utente
Modello di certificato utilizzato per generare certificati per l'autenticazione di computer client Autenticazione client – Computer
Modello di certificato utilizzato per generare certificati di autenticazione server per IAS Autenticazione server RAS e IAS
Percorso degli script di installazione C:\MSSScripts
Percorso dei file di backup della configurazione D:\IASConfig
Percorso dei file registro di autenticazione e delle richieste di controllo IAS D:\IASLogs
Nome del criterio Consenti accesso senza fili
Nome oggetto Criteri di gruppo di Active Directory Criterio di rete senza fili
Criterio di rete wireless all'interno dell'oggetto Criteri di gruppo Configurazione computer client senza fili
##### Creazione dei gruppi di Active Directory richiesti per l'accesso alla rete WLAN È necessario eseguire il seguente script come utente che dispone dell'autorizzazione a creare gruppi di protezione di Active Directory. Questo script crea i gruppi richiesti per la registrazione di certificati di autenticazione wireless e l'implementazione di criteri di accesso remoto e Criteri di gruppo per reti senza fili: 
Cscript //job:CreateWirelessGroups C:\MSSScripts\wl_tools.wsf

Nota   Per gli ambienti con insiemi di strutture in più domini, creare i gruppi nello stesso dominio degli utenti wireless.

Verifica delle impostazioni DHCP

Per utilizzare una rete wireless, è necessario configurare i server DHCP con ambiti specifici per le tecnologie wireless e tempi di lease degli indirizzi IP più brevi rispetto a quelli per i client di reti cablate. Rivolgersi agli amministratori dei server DHCP per verificare che tali server siano stati configurati correttamente. Per ulteriori informazioni sulla pianificazione di DHCP per le LAN wireless, vedere il Windows Server 2003 Deployment Kit all'indirizzo www.microsoft.com/windowsserver2003/techinfo/reskit/deploykit.mspx (in inglese).

Configurazione di certificati di autenticazione WLAN

La soluzione di rete WLAN protetta basata su EAP-TLS descritta in questa guida richiede la creazione e distribuzione dei seguenti tipi di certificati:

  • Autenticazione client – Computer

  • Autenticazione client – Utente

  • Autenticazione server RAS e IAS

Creazione di un modello di certificato per l'autenticazione server IAS

I server IAS richiedono un certificato server per autenticare i computer ai client che eseguono l'handshake del protocollo EAP-TLS. Chiedere all'amministratore di Servizi certificati di eseguire i seguenti passaggi per creare un modello di certificato di autenticazione server per i server IAS.

Per creare un modello di certificato per l'autenticazione server

  1. Accedere alla CA di emissione con un account amministrativo della CA ed eseguire lo snap-in MMC Modelli di certificato.

  2. Creare un duplicato del modello Server RAS e IAS. Nella scheda Generale delle proprietà del nuovo modello, digitare Autenticazione server RAS e IAS nel campo Nome visualizzato modello.

  3. Nella scheda Estensioni assicurarsi che i criteri di rilascio includano solo Autenticazione server (OID 1.3.6.1.5.5.7.3.1).

  4. Sempre nella scheda Estensioni, modificare i criteri di rilascio aggiungendo il criterio Garanzia media.

  5. Nella scheda Nome soggetto, selezionare Crea in base alle informazioni di Active Directory. Assicurarsi inoltre che Formato del nome soggetto sia impostato su Nome comune e che in Includere le seguenti informazioni nel nome soggetto alternativo sia selezionato solo Nome DNS.

  6. Nella scheda Gestione richiesta, fare clic sul pulsante CSP, verificare che sia selezionato Le richieste utilizzano uno dei seguenti CSP e che sia selezionato solo Microsoft RSA SChannel Cryptographic Provider.

  7. Nella scheda Protezione, aggiungere il gruppo di protezione Registrazione automatica certificato di autenticazione server RAS e IAS con le autorizzazioni di lettura, registrazione e registrazione automatica ed eliminare eventuali altri gruppi in possesso di autorizzazioni per la registrazione o la registrazione automatica di questo modello di certificato.

    Nota   Poiché questo certificato ha un'importanza relativamente alta per la protezione, può essere utile impostarlo in modo che richieda l'approvazione di Gestione certificati. L'attivazione di questo valore evita la registrazione di un server IAS non autorizzato che richiederà invece l'approvazione manuale dopo l'emissione e l'invio automatico dei certificati da parte del server IAS.

Creazione di un modello di certificato per l'autenticazione utente

Per l'autenticazione nel server IAS durante l'handshake EAP-TLS gli utenti finali devono disporre di certificati utente. Anche in questo caso, sarà necessario eseguire la procedura seguente utilizzando un account di amministratore di Servizio certificati.

Per creare un modello di certificato per l'autenticazione utente

  1. Avviare lo snap-in MMC Modelli di certificato sul server CA di emissione.

  2. Creare un duplicato del modello Sessione autenticata e assegnare al nuovo modello un nome digitando Autenticazione client – Utente nel campo Nome visualizzato del modello nella scheda Generale.

  3. Nella scheda Gestione richiesta, fare clic sul pulsante CSP e deselezionare le caselle di controllo Microsoft Base DSS Cryptographic Provider.

  4. Nella scheda Nome soggetto, verificare che sia selezionata la voce Crea in base alle informazioni di Active Directory. In Formato del nome soggetto, selezionare Nome comune. Verificare che Nome principale utente (UPN) sia l'unica opzione selezionata in Includere le seguenti informazioni nel nome soggetto alternativo.

  5. Nella scheda Estensioni, verificare che i criteri di applicazioneincludano Autenticazione client (OID 1.3.6.1.5.5.7.3.2). Modificare inoltre i criteri di rilascio aggiungendo il criterio Garanzia bassa.

  6. Nella scheda Protezione, aggiungere il gruppo di protezione Registrazione automatica autenticazione client – Certificato utente con le autorizzazioni di lettura, registrazione e registrazione automatica ed eliminare eventuali altri gruppi in possesso di autorizzazioni per la registrazione o la registrazione automatica.

Creazione di un modello di certificato per l'autenticazione computer

Questo certificato viene utilizzato dai computer quando eseguono l'autenticazione nel server IAS con l'handshake EAP-TLS. Anche in questo caso, la procedura seguente dovrà venire eseguita dall'amministratore di Servizio certificati.

Per creare un modello di certificato per l'autenticazione computer

  1. Avviare lo snap-in MMC Modelli di certificato sul server CA di emissione.

  2. Creare un duplicato del modello Autenticazione workstation e assegnare un nome al nuovo modello digitando Autenticazione client – Computer nel campo Nome visualizzato del modello nella scheda Generale.

  3. Nella scheda Nome soggetto, verificare che sia selezionata la voce Crea in base alle informazioni di Active Directory. In Formato del nome soggetto, selezionare Nome comune. Verificare che Nome DNS sia l'unica opzione selezionata in Includere le seguenti informazioni nel nome soggetto alternativo.

  4. Nella scheda Estensioni, modificare i criteri di applicazione in modo che includano solo Autenticazione client (OID 1.3.6.1.5.5.7.3.2). Modificare inoltrei criteri di rilascio aggiungendo il criterio Garanzia bassa.

  5. Nella scheda Protezione, aggiungere il gruppo di protezione Registrazione automatica autenticazione client – Certificato computer con le autorizzazioni di lettura, registrazione e registrazione automatica ed eliminare eventuali altri gruppi in possesso di autorizzazioni.

Aggiunta dei certificati di autenticazione WLAN alla CA

Una volta configurati i modelli di certificato di autenticazione WLAN, è necessario aggiungerli alla CA per attivare la registrazione. Chiedere quindi all'amministratore di Servizi certificati di eseguire i seguenti passaggi.

Per aggiungere modelli di certificato alla CA

  • Dallo snap-in MMC Autorità di certificazione della CA di emissione, fare doppio clic sulla cartella Modelli di certificato, quindi selezionare Nuovo e Modello di certificato da emettere. Selezionare i certificati seguenti e fare clic su OK:

    • Autenticazione client – Computer

    • Autenticazione client – Utente

    • Autenticazione server RAS e IAS

Registrazione dei certificati del server IAS

La distribuzione dei certificati di autenticazione server ai server IAS è una procedura relativamente semplice e automatizzata.

Per registrare un server IAS

  1. Avviare lo snap-in MMC Utenti e computer di Active Directory per aggiungere gli account computer IAS al gruppo di protezione Registrazione automatica certificato di autenticazione server RAS e IAS.

  2. Riavviare il server IAS e accedere come membro del gruppo Administrators locale.

  3. Dal prompt dei comandi, eseguire GPUPDATE /force

  4. Aprire MMC e aggiungere lo snap-in Certificati. Quando viene richiesto, selezionare l'opzione Account del computer, quindi Computer locale.

  5. Selezionare Certificati (computer locale) dalla struttura della console, scegliere Tutte le attività dal menu Azione, quindi fare clic su Registra i certificati automaticamente.

    Nota   Se è stata selezionata l'opzione per richiedere l'approvazione di Gestione certificati, l'amministratore della CA dovrà verificare la validità della richiesta e quindi rilascerà il certificato.

Aggiunta di utenti e computer per la registrazione automatica
È necessario rilasciare agli utenti e computer che richiedono l'accesso alla rete WLAN i rispettivi certificati per consentire l'autenticazione e l'accesso alla rete tramite una connessione wireless. La procedura di emissione e rinnovo dei certificati utente e computer è trasparente all'utente finale grazie all'utilizzo dei gruppi di registrazione automatica configurati in precedenza.

Per aggiungere gli utenti e i relativi computer ai gruppi per la registrazione automatica, utilizzare lo snap-in MMC Utenti e computer di Active Directory e aggiungere gli account utente al gruppo Registrazione automatica autenticazione client – Certificato utente e i computer al gruppo Registrazione automatica autenticazione client – Certificato computer. Al termine di questa operazione, gli utenti riceveranno i certificati utente e computer dopo il riavvio dei computer e potranno accedere nuovamente alla rete.

Nota   Questa soluzione utilizza gruppi personalizzati per il controllo degli utenti e computer che possono ricevere i certificati. Se i certificati sono richiesti per tutti gli utenti e i computer dell'ambiente, è sufficiente aggiungere il gruppo Domain Users al gruppo Registrazione automatica autenticazione client – Certificato utente e il gruppo Domain Computers al gruppo Registrazione automatica autenticazione client – Certificato computer.

Configurazione dell'infrastruttura di accesso alla rete WLAN

È necessario configurare il server IAS primario con criteri di accesso remoto e impostazioni di richiesta di connessione che determinano l'autenticazione e l'autorizzazione di client wireless alla rete WLAN. Sarà quindi necessario replicare queste impostazioni agli altri server IAS e configurare ognuno di questi server in maniera univoca per accettare le connessioni da client RADIUS, come i punti di accesso wireless. Inoltre, i punti di accesso wireless devono essere configurati per utilizzare i server IAS come origine dell'autenticazione e accounting per la rete wireless 802.1X.

Creazione di un criterio di accesso remoto IAS per reti WLAN
Utilizzando lo snap-in MMC Servizio di Autenticazione Internet sul server IAS primario, configurare IAS con un criterio di accesso remoto.

Per creare un criterio di accesso remoto

  1. Fare clic con il pulsante destro del mouse sulla cartella Criteri di accesso remoto, quindi selezionarel'opzione per la creazione di un nuovo criterio di accesso remoto.

  2. Assegnare al criterio il nome Consenti accesso senza fili e nella procedura guidata impostare Procedura guidata per impostare un criterio tipico per scenari comuni.

  3. Selezionare Senza fili come metodo di accesso.

  4. Consentire l'accesso in base al gruppo e utilizzare il gruppo di protezione Criteri di accesso remoto – Accesso senza fili.

  5. Scegliere Smart card o altro certificato per il tipo di protocollo EAP (Extensible Authentication Protocol), quindi selezionare il certificato di autenticazione server installato per IAS.

  6. Completare la procedura guidata e uscire.

  7. Aprire le proprietà del criterio Consenti accesso senza fili e fare clic su Modifica profilo.

  8. Nella scheda Avanzate, aggiungere l'attributo Ignore-User-Dialin-Properties e impostarlo su True, quindi aggiungere l'attributo Termination-Action e impostarlo su RADIUS Request.

    Nota   Il criterio Consenti accesso senza fili può coesistere con altri criteri creati dall'utente o con i criteri di accesso predefiniti, tuttavia, per un corretto funzionamento, il criterio di accesso remoto predefinito deve comparire nella cartella Criteri di accesso remoto dopo il criterio Consenti accesso senza fili.

Aggiunta di client RADIUS a IAS

Prima che i client IAS e RADIUS possano utilizzare i servizi di autenticazione e accounting tramite il protocollo RADIUS è necessario aggiungere a tali client i punti di accesso wireless e i proxy RADIUS.

Per aggiungere i client RADIUS a IAS

  1. Avviare lo snap-in MMC Servizio di Autenticazione Internet.

  2. Fare clic con il pulsante destro del mouse sulla cartella Client RADIUS, quindi selezionare Nuovo client RADIUS.

  3. Immettere il nome descrittivo e l'indirizzo IP del punto di accesso wireless.

  4. Selezionare Standard RADIUS come attributo del fornitore del client e immettere il segreto condiviso per il punto di accesso wireless. Selezionare La richiesta deve contenere l'attributo autenticatore del messaggio.

    Nota   Affinché ogni server IAS disponga di un insieme univoco di client e segreti condivisi per i punti di accesso wireless, è necessario ripetere questa procedura su ogni server IAS. Al fine di agevolare il processo, in questa guida viene fornito uno script che consente di generare i segreti condivisi che sarà possibile archiviare in una posizione sicura per utilizzarli in caso sia necessario eseguire il ripristino del sistema. Per eseguire lo script, immettere quanto segue al prompt dei comandi:

  
 Cscript //job:GenPWD C:\MSSScripts\wl_tools.wsf /client:NomeClient
Distribuzione delle configurazioni a più server IAS

Dopo aver configurato gli elementi seguenti sul server IAS primario, sarà possibile esportarli in file di testo utilizzando il comando netsh. Dopo aver esportato i file di testo, importarli nei singoli server IAS che ricoprono ruoli simili all'interno dell'ambiente per garantire una configurazione comune a livello di intero ambiente.

Le impostazioni di configurazione esportabili includono:

  • Impostazioni dei server

  • Configurazione di registrazione

  • Criteri di accesso remoto

  • Client RADIUS

  • Configurazione completa

Poiché ogni server IAS dovrà contenere un elenco univoco di client RADIUS e segreti condivisi sarà necessario configurare tali impostazioni individualmente su ciascun server ed eseguire separatamente il relativo backup. Inoltre, un dump della configurazione completa contiene dati altamente riservati che dovranno ricevere la massima protezione in quanto, in caso di furto, possono consentire l'accesso alla rete wireless.

Esportazione della configurazione del server IAS primario

Esportare le impostazioni seguenti in file di testo da utilizzare per la replica sugli altri server IAS.

  • Configurazione dei server

  • Impostazioni di registrazione

  • Criteri di accesso remoto

  • Criteri di richiesta di connessione

Per semplificare la procedura, questa guida include file batch contenenti i comandi netsh che consentono di esportare i dati di configurazione comuni all'interno di file di testo nella directory D:\IASConfig tramite l'esecuzione del comando seguente al prompt dei comandi.

  
C:\MSSScripts\IASExport.bat
Importazione delle informazioni di configurazione dal server IAS primario

Come indicato in precedenza, il comando netsh consente di trasferire gli stati di configurazione tra server diversi. Questo processo migliora l'efficienza della distribuzione riducendo la possibilità di errori durante la configurazione. Dopo aver esportato le informazioni di configurazione dal server IAS primario, è possibile importare lo stato della configurazione nei server IAS secondari.

Per importare lo stato della configurazione del server IAS primario in altri server IAS

  1. Copiare tutti i file di configurazione dalla directory D:\IASConfig nel server IAS primario alla corrispondente directory D:\IASConfig negli altri server IAS.

  2. Sui server secondari, utilizzare il file batch seguente (incluso in questa guida) al prompt dei comandi per importare lo stato della configurazione:

C:\MSSScripts\IASImport.bat
Punti di accesso wireless e client

La procedura di configurazione dei punti di accesso wireless può variare significativamente a seconda delle marche e dei modelli dei dispositivi utilizzati. In genere, i produttori di punti di accesso wireless forniscono tuttavia informazioni dettagliate sulla configurazione dei dispositivi, inclusi i seguenti dati richiesti:

  • Impostazioni di rete 802.1X

  • Configurazione dell'indirizzo del server RADIUS primario

  • Configurazione dell'indirizzo del server RADIUS secondario

  • Segreto RADIUS condiviso con il server RADIUS primario

  • Segreto RADIUS condiviso con il server RADIUS secondario

Per istruzioni sulla configurazione di un dispositivo wireless di una determinata marca e modello, consultare i manuali o il sito Web del produttore.

Distribuzione di certificati di autenticazione WLAN

In questa sezione vengono descritte alcune importanti attività di configurazione richieste per l'attivazione della registrazione automatica dei certificati per i client basati su Windows XP. Anche se nelle precedenti sezioni è stato illustrato come attivare i criteri e i modelli per il supporto della registrazione automatica dei certificati nell'infrastruttura di certificazione, tenere presente che in Windows XP il supporto di questa funzionalità è disattivato per impostazione predefinita. Per attivare il supporto della registrazione automatica dei certificati è necessario configurare le impostazioni appropriate tramite Criteri di gruppo. Utilizzando i gruppi di protezione per il controllo della registrazione automatica è possibile attivare questa funzionalità per tutti gli utenti e i computer di un dominio; i gruppi di protezione consentono di determinare i destinatari dei diversi tipi di certificati.

Per attivare la registrazione automatica per tutti gli utenti e i computer di un dominio

  1. Accedere con un account che disponga delle autorizzazioni per creare oggetti Criteri di gruppo e collegare questi ultimi al dominio.

  2. In Utenti e computer di Active Directory, selezionare l'oggetto dominio facendo clic con il pulsante destro del mouse su di esso e selezionare le proprietà dell'oggetto.

  3. Nella scheda Criteri di gruppo, fare clic su Nuovo e digitare un nome per l'oggetto Criteri di gruppo (ad esempio Criteri PKI del dominio).

  4. Fare clic su Modifica quindi passare a Criteri chiave pubblica in Configurazione computer\Impostazioni di Windows\Impostazioni protezione.

  5. Nel riquadro deidettagli, fare doppio clic su Impostazioni registrazione automatica.

  6. Verificare che siano selezionati gli elementi seguenti:

    • Registra i certificati automaticamente

    • Rinnova i certificati scaduti, aggiorna quelli in sospeso e rimuovi i certificati revocati

    • Aggiorna i certificati che utilizzano modelli di certificato

  7. Ripetere i passaggi 5 e 6 per Impostazioni registrazione automatica in Configurazione utente\Impostazioni di Windows\Impostazioni protezione\Criteri chiave pubblica.

  8. Chiudere l'oggetto Criteri di gruppo

  9. Verificare che l'oggetto Criteri di gruppo abbia una priorità più elevata dell'oggetto Criterio dominio predefinito.

  10. Per gli ambienti con insiemi di strutture in più domini, ripetere la procedura per ogni dominio in cui si desidera attivare la registrazione automatica dei certificati.

    Nota   Se gli utenti non utilizzano i profili comuni e la registrazione automatica è consentita universalmente, i certificati verranno rilasciati agli utenti su ogni computer a cui eseguono l'accesso. Per impedire che ciò avvenga anche per gli utenti con privilegi di amministrazione accedono ai server, si consiglia di creare un oggetto Criteri di gruppo per i server che disattivi la registrazione automatica. Inoltre, per evitare l'attivazione della registrazione automatica per determinati utenti, sarà possibile collegare un oggetto Criteri di gruppo alle UO che contengono il sottoinsieme di utenti che non richiedono la registrazione automatica.

Attivazione dell'accesso alla rete WLAN per utenti e computer

La fase finale dell'attivazione dell'accesso alla WLAN protetta da parte di utenti e computer prevede l'esecuzione di alcune azioni sugli oggetti di Active Directory che includono la modifica delle autorizzazioni di account e di gruppo e l'implementazione delle impostazioni di Criteri di gruppo WLAN.

Aggiunta di utenti ai gruppi Criteri di accesso remoto

I criteri di accesso remoto IAS utilizzano gruppi di protezione basati su Active Directory per determinare quali utenti e computer sono autorizzati a stabilire connessioni alla rete WLAN. Questi gruppi di protezione sono stati creati nelle sezioni precedenti e includono:

  • Criteri di accesso remoto – Utenti senza fili

  • Criteri di accesso remoto – Computer senza fili

  • Criteri di accesso remoto – Accesso senza fili

Per aggiungere utenti e computer ai gruppi di accesso alla rete WLAN

  1. Aprire lo snap-in MMC Utenti e computer di Active Directory.

  2. Aggiungere i gruppi Criteri di accesso remoto – Utenti senza fili e Criteri di accesso remoto – Computer wireless al gruppo Criteri di accesso remoto – Accesso senza fili.

  3. Aggiungere gli utenti che disporranno dell'autorizzazione di accesso alla rete WLAN al gruppo Criteri di accesso remoto – Utenti senza fili.

  4. Aggiungere gli utenti che disporranno dell'autorizzazione di accesso alla rete WLAN al gruppo Criteri di accesso remoto – Computer senza fili.

    Nota   Se si decide di consentire l'accesso alla rete WLAN a tutti gli utenti e i computer per impostazione predefinita, per semplificare l'amministrazione è preferibile aggiungere i gruppi Domain Users e Domain Computers ai gruppi dei criteri corrispondenti.

Creazione di Criteri di gruppo WLAN di Active Directory

È possibile automatizzare e imporre la configurazione WLAN di computer client utilizzando lo snap-in MMC Criteri di gruppo di Windows 2003 che contiene le impostazioni di Criterio di rete senza fili basate sugli standard 802.1X e 802.11.

Per creare un criterio di rete wireless

  1. Aprire lo snap-in MMC Utenti e computer di Active Directory in un server Windows Server 2003 o una workstation in cui siano installati gli strumenti di amministrazione di Windows Server 2003.

  2. Nella scheda Criteri di gruppo, selezionare le proprietà dell'oggetto dominio, fare clic su Nuovo e assegnare all'oggetto Criteri di gruppo il nome Criterio di rete senza fili.

  3. Fare clic sul pulsante Proprietà, quindi dalla scheda Protezione assegnare al gruppo di protezione Criterio di rete senza fili – Computer le autorizzazioni di lettura e applicazione dei criteri di gruppo. Rimuovere inoltre le autorizzazioni di applicazione dei criteri di gruppo dagli utenti Authenticated Users dell'oggetto Criteri di gruppo.

  4. Nella scheda Generale, selezionare Disattiva impostazioni configurazione utente per l'oggetto Criteri di gruppo e selezionare Sì se compaiono messaggi di avviso. Applicare le modifiche e chiudere la finestra.

  5. Fare clic sul pulsante Modifica e passare a Configurazione computer\Impostazioni di Windows\Impostazioni protezione\Criteri di rete senza fili (IEEE 802.11).

  6. Selezionare l'oggetto Criteri di rete wireless (IEEE 802.11) dal riquadro di navigazione, quindi nel menu Azione fare clic su Crea criterio rete senza fili. Utilizzando la procedura guidata, assegnare al criterio il nome Configurazione computer client senza fili. Lasciare selezionata l'opzione Modifica proprietà e fare clic su Fine per chiudere la procedura guidata.

  7. Nella scheda Reti preferite del criterio Configurazione computer client senza fili, selezionare Aggiungi, quindi immettere il nome di rete o il SSID della rete wireless.

  8. Fare clic sulla scheda IEEE 802.1X e aprire le impostazioni del Tipo EAP Smart card o altro certificato. In Autorità di certificazione principale attendibili, selezionare il certificato della CA principale per la PKI che ha rilasciato i certificati del server IAS.

  9. Chiudere le proprietà del criterio Configurazione computer client senza fili ed Editor oggetti Criteri di gruppo.

    Nota   Attualmente il protocollo WPA2 non è applicabile tramite gli oggetti Criteri di gruppo. Il supporto di oggetti Criteri di gruppo per WPA2 sarà tuttavia incluso sia nelle nuove versioni di Windows, Vista e Longhorn, che in futuri aggiornamenti destinati alle versioni attuali di Windows.

Aggiunta di computer a gruppi di protezione per i Criteri di gruppo WLAN

I gruppi di protezione basati su Active Directory vengono utilizzati per determinare i computer ai quali sono applicati criteri di rete wireless e per i quali, pertanto, sono automaticamente configurate le impostazioni di rete wireless 802.1X. La distribuzione di queste impostazioni dei criteri di rete wireless 802.1X deve avvenire prima della configurazione delle impostazioni 802.1X sui punti di accesso wireless e dell'attivazione della nuova rete WLAN. In tal modo i computer client potranno scaricare e applicare il criterio di gruppo basato sul computer, anche se si connettono alla rete cablata soltanto occasionalmente.

Inoltre, le impostazioni dei Criteri di gruppo possono essere applicate al computer prima che venga installata la scheda di rete WLAN (NIC). Una volta installata, verranno automaticamente applicati a tale scheda i criteri di rete wireless.

Per aggiungere i computer ai gruppi per il criterio di reti wireless, utilizzare lo snap-in MMC Utenti e computer di Active Directory e aggiungere gli oggetti computer autorizzati al gruppo Criterio di rete senza fili – Computer.

Nota   Le impostazioni dell'oggetto Criterio di rete senza fili verranno aggiornate sui computer client durante il successivo intervallo di aggiornamento dei Criteri di gruppo. È possibile utilizzare il comando GPUPDATE /force per imporre l'aggiornamento dei criteri.

Requisiti per i client WPA2

La soluzione presentata in questa guida è stata progettata per i computer client che supportano le reti wireless ed eseguono Windows XP Professional con SP2 o Windows XP Tablet Edition. Queste versioni di Windows integrano il supporto dello standard 802.1X e delle reti WLAN. Inoltre, i client basati su Windows XP prevedono la registrazione automatica e la funzionalità di rinnovo dei certificati, il che rende la soluzione basata sui certificati qui presentata particolarmente conveniente in termini di costi, se collegata a un'infrastruttura di certificazione.

Anche se Windows XP con SP2 prevede il supporto integrato di WPA, per attivare il supporto di WPA2 IEEE 802.11i sui client basati su Windows XP con SP2 è necessario installare uno specifico aggiornamento. Per ulteriori informazioni su questo aggiornamento e le istruzioni per il download, vedere l'articolo Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Service Information Element (WPS IE) update for Windows XP with Service Pack 2 is available all'indirizzo http://support.microsoft.com/default.aspx?scid=kb;en-us;893357 (in inglese, articolo in italiano tradotto da un sistema di traduzione automatica all'indirizzo http://support.microsoft.com/kb/893357/it).

Inizio pagina

Riepilogo

Dopo aver esaminato le numerose soluzioni utilizzate per risolvere i ben noti difetti dei precedenti standard di protezione delle reti wireless e i modi in cui i nuovi standard di settore hanno reso obsolete tali soluzioni alternative, è stata descritta nel dettaglio la soluzione Microsoft per il miglioramento della protezione delle reti wireless delle medie aziende. Le indicazioni presentate in questa guida consentono pertanto alle medie aziende di implementare la tecnologia wireless ottenendo i vantaggi in termini di maggiore produttività, affidabilità e protezione dell'ambiente aziendale che una soluzione WPA o WPA2 con EAP-TLS e Servizi certificati è in grado di offrire. La procedura dettagliata e gli strumenti illustrati in questa guida consentono alle aziende di medie dimensioni di implementare una soluzione wireless più affidabile, protetta e in grado di migliorare la produttività senza che gli utenti della rete subiscano alcun disagio o interruzione.

Download

Guida Configurazione di punti di accesso wireless protetti

Inizio pagina