Autenticazione WiFi basata su certificati: guida a EAP-TLS
Published
Un dipendente sta lasciando l'azienda e il team sta valutando se modificare nuovamente la password della rete WiFi del personaleWiFi. Modificarla significa riconnettere laptop, telefoni, tablet della reception e dispositivi che nessuno ricorda di aver configurato. Non modificarla significa accettare che qualcuno all'esterno dell'organizzazione sappia ancora come connettersi.
L'autenticazione basata su certificato WiFi offre un modo migliore per identificare i dispositivi attendibili. Tuttavia, modifica anche il lavoro che il team deve svolgere: invece di distribuire password, gestirà catene di attendibilità, rinnovo dei certificati, revoca e dispositivi che scompaiono in magazzino per mesi. Il miglioramento della sicurezza è reale. Per un funzionamento affidabile non basta selezionare EAP-TLS in un profilo wireless.
Sommario
- Significato dell'autenticazione basata su certificatoWiFi
- Come funziona l'handshake EAP-TLS passo dopo passo
- Confronto tra certificati, password condivise e PEAP
- Creazione della CA e provisioning dei certificati tramite MDM
- Gestione del ciclo di vita dei certificati dall'emissione al rinnovo
- Revoca dell'accesso in caso di smarrimento dei dispositivi o uscita del personale
- Elegibilità dei dispositivi e pianificazione delle eccezioni
- Confermare il piano di certificazione prima del rilascio
Significato dell'autenticazione WiFi basata su certificato
L'autenticazione basata su certificato WiFi sostituisce una password WiFi condivisa con un singolo certificato digitale, che la rete verifica prima di concedere l'accesso. Si pensi al codice di una porta d'ufficio condivisa rispetto al badge di un dipendente. Con il codice, tutti dimostrano di conoscere lo stesso segreto. Con il badge, il servizio di sicurezza può identificare una specifica credenziale e revocarla in modo indipendente.
Supponiamo che un laptop gestito debba accedere alla rete del personale. Il suo certificato identifica il dispositivo o l'utente assegnato, e la sua chiave privata protetta gli consente di dimostrare il possesso di tale credenziale. Il certificato in sé non è una password segreta e la sola copia del certificato pubblico non fornisce la chiave privata corrispondente.
Il diagramma mostra come le singole credenziali sostituiscono la password comune.
Come si collocano i componenti
L'infrastruttura sottostante è IEEE 802.1X, originariamente sviluppata per l'Ethernet via cavo e adattata per le LAN wireless. La panoramica di Microsoft sull'autenticazione IEEE 802.1X) descrive l'infrastruttura e il ruolo dell'autenticazione centrale tramite RADIUS.
L'access point controlla l'accesso, mentre il servizio RADIUS valuta la richiesta di autenticazione. Il protocollo EAP-TLS è il metodo di autenticazione basato su certificati gestito tramite tale configurazione. Il dispositivo e il server di autenticazione si convalidano a vicenda prima di stabilire il materiale di chiavi per la connessione.
Mantenere distinti questi componenti:
- Certificato del dispositivo: identifica l'endpoint o l'utente e funziona con una chiave privata conservata dal dispositivo.
- Certificato del server di autenticazione: consente al dispositivo di verificare che stia comunicando con un servizio di autenticazione approvato.
- Autorità di certificazione: emette certificati che ciascuna parte può convalidare tramite una catena di certificati esplicitamente attendibile.
Il dispositivo e il server non necessitano necessariamente di certificati provenienti dalla stessa autorità di emissione. Ciò che importa è che ciascuna parte si fidi dell'emittente appropriato e applichi la corretta politica di convalida.
Regola pratica: Gestisca i certificati come un sistema di identità di rete, non come password complesse.
Tale distinzione modifica la modalità di gestione di un laptop smarrito. È possibile revocare le sue credenziali senza dover sostituire quelle sui dispositivi di tutti gli altri. Tuttavia, il possesso di un certificato valido stabilisce l'identità, non un'autorizzazione illimitata. La politica di accesso deve comunque stabilire a quali risorse tale identità possa accedere.
Funzionamento dell'handshake EAP-TLS passo dopo passo
Una connessione coinvolge il supplicant del dispositivo, l'access point che funge da autenticatore e il server di autenticazione. Il supplicant è il componente del sistema operativo che gestisce l'autenticazione di rete enterprise.
Questo flusso semplificato illustra i passaggi principali, anziché ogni singolo messaggio di protocollo.
Seguire lo scambio e i relativi punti di errore
L'autenticazione reciproca e la derivazione della chiave alla base di questo scambio sono definite nella specifica EAP-TLS, RFC 5216.
Il dispositivo si associa all'access point. Avvia lo scambio di autenticazione enterprise e fornisce un'identità. L'associazione da sola non concede il normale accesso alla rete. Un'impostazione di sicurezza wireless errata può impedire del tutto al dispositivo di raggiungere l'autenticazione tramite certificato.
L'access point inoltra i messaggi EAP a RADIUS. Trasmette lo scambio tra l'endpoint e il servizio di autenticazione anziché emettere esso stesso il certificato del dispositivo. Un problema di connettività con RADIUS o un access point registrato in modo errato possono interrompere lo scambio a questo livello.
Il server presenta il proprio certificato. Il dispositivo verifica la catena di certificati, la validità e l'identità prevista del server. Un emittente non attendibile, una catena incompleta o un nome server inatteso dovrebbero indurre il dispositivo a rifiutare la connessione.
Il dispositivo presenta il proprio certificato client. Il server convalida le credenziali, verifica le informazioni sulla revoca applicabili e valuta l'identità. Un certificato mancante o una chiave privata inaccessibile possono apparire all'utente come un errore di connessione generico, anche quando i log del server mostrano una causa specifica.
Lo scambio TLS stabilisce il materiale per la chiave condivisa. L'endpoint deve dimostrare il possesso della propria chiave privata, non semplicemente presentare un file di certificato. Impostazioni crittografiche incompatibili possono impedire il completamento anche se entrambi i certificati sono altrimenti validi.
RADIUS restituisce il risultato dell'autenticazione e gli attributi dei criteri. Un'accettazione può includere l'assegnazione di una VLAN o altri attributi di autorizzazione supportati. Un'autenticazione riuscita seguita da una connessione inutilizzabile può indicare un problema relativo a una VLAN o ai criteri a valle anziché un problema di certificato.
Configurare il client per verificare il server
Nel profilo del supplicant, selezionare esplicitamente EAP-TLS, configurare la CA attendibile e specificare i nomi dei server RADIUS previsti. Mantenere abilitata la convalida del certificato del server. Non consentire agli utenti di ignorare un avviso solo per connettersi online.
Utilizzi questo video insieme al flusso del protocollo durante la discussione dello scambio con il Suo team.
Ogni connessione dipende dalla presenza, dall'accessibilità e dall'accettabilità delle credenziali al momento dell'autenticazione. La risoluzione dei problemi richiede quindi evidenze sia dal supplicant che da RADIUS, non solo una dashboard dell'access point che mostri il mancato accesso di un client.
Confronto tra certificati, password condivise e PEAP
WiFi metodi di autenticazione in base agli stessi criteri
| Metodo | Credenziale sul dispositivo | Ambito di revoca | Imputabilità | Impegno di configurazione |
|---|---|---|---|---|
| Passphrase condivisa WPA2 o WPA3-Personal | Un'unica passphrase nota a tutti gli utenti | Modifica la chiave per tutti | Nessuna dalla credenziale condivisa stessa | Basso |
| WPA2-Enterprise con PEAP-MSCHAPv2 | Nome utente e password per ciascun utente | Disabilita un singolo account | Per utente | Medio |
| EAP-TLS su WPA2 o WPA3-Enterprise | Certificato client e chiave privata univoci per dispositivo | Revoca un singolo certificato | Per dispositivo e utente quando mappati | Elevato, richiede PKI e provisioning gestito |
| WPA3-Enterprise 192 bit con EAP-TLS | Certificato conforme ai requisiti crittografici del profilo | Revoca un singolo certificato | Per dispositivo e utente quando mappati | Elevato, oltre a verifiche di compatibilità dei cifrari |
EAP-TLS non è sinonimo di WPA3. Il registro di certificazione Wi-Fi Alliance identifica EAP-TLS tra i metodi di autenticazione Enterprise supportati. L'autenticazione tramite certificato è una scelta di autenticazione Enterprise, mentre il profilo WPA determina anche i requisiti di sicurezza wireless.
Confrontare le credenziali, non solo l'etichetta
Una passphrase condivisa dimostra la conoscenza di un segreto comune. Non stabilisce quale dipendente l'abbia fornita, sebbene le apparecchiature di rete possano comunque registrare i dettagli della connessione. Le uscite del personale diventano problematiche poiché la sostituzione della credenziale comporta l'aggiornamento di ciascun dispositivo che la utilizza.
PEAP-MSCHAPv2 passa a nomi utente e password individuali. Utilizza un tunnel TLS autenticato dal server per proteggere lo scambio di autenticazione interno, per cui una corretta convalida del server rimane fondamentale. Può fornire registri utili per ciascun utente, ma le modifiche delle password e i problemi relativi agli account continuano a fare parte dell'assistenza alla rete wireless.
Con EAP-TLS, l'endpoint utilizza il proprio certificato e la chiave privata anziché la password di un account durante l'autenticazione. Ciò fornisce agli amministratori una credenziale specifica per il dispositivo da gestire, a condizione che l'inventario associ correttamente i certificati agli endpoint e ai relativi proprietari.
Scegliere il metodo il cui ciclo di vita delle credenziali possa essere effettivamente gestito dal proprio team, e non semplicemente l'opzione più avanzata nel menu del controller.
Adattare il metodo alla popolazione target
Le passphrase condivise costituiscono una scelta predefinita inadeguata per l'accesso gestito del personale, laddove la revoca individuale e la responsabilità sono fondamentali. Anche per gli ospiti e i dispositivi a basso rischio, una password comune richiede una politica deliberata di distribuzione e sostituzione.
I certificati si adattano ai laptop e ai telefoni gestiti in quanto è possibile fornirli tramite un sistema di gestione esistente. Il profilo Enterprise a garanzia elevata aggiunge lavoro di compatibilità; non rimuove alcuna responsabilità relativa al ciclo di vita. PEAP può rimanere un'opzione di migrazione nei casi in cui esistono singoli account ma la fornitura dei certificati non è pronta, piuttosto che un motivo per rinviare a tempo indeterminato una progettazione dell'accesso basata sull'identità.
Creazione della CA e provisioning dei certificati tramite MDM
Una distribuzione gestibile parte da un'infrastruttura a chiave pubblica (public key infrastructure o PKI) la cui titolarità sia chiara. Una gerarchia comune mantiene un'autorità di certificazione radice (root CA) offline e utilizza una CA emittente per l'emissione di routine dei certificati. Un servizio PKI gestito può svolgere tali ruoli senza che il team debba gestire ogni componente a livello locale.
La CA emittente firma i certificati del dispositivo e del server. RADIUS deve ritenere attendibile la catena dei certificati client, mentre gli endpoint devono ritenere attendibile la catena del server appropriata. Non presupponga che l'installazione di un certificato root configuri automaticamente il resto della politica wireless.
Scegliere i profili prima di emettere i certificati
Un modello di dispositivo necessita dell'uso per l'autenticazione del client (client authentication usage), di un'identità di dispositivo o utente che la politica aziendale sia in grado di risolvere e di un periodo di validità regolato dalla struttura di rinnovo e ripristino definita.
Profili di certificato in base al livello di sicurezza
| Profilo | Chiave e algoritmo | Validità tipica | Dove si applica |
|---|---|---|---|
| Laptop o telefono gestito standard | Algoritmo approvato dall'organizzazione e supportato nell'intero parco dispositivi | Definita dalla politica di rinnovo e ripristino | Parchi dispositivi misti su WPA2-Enterprise |
| Dispositivo gestito con restrizioni più severe | Template più solido approvato dopo i test sugli endpoint | Definita dalla politica e dalla capacità di rinnovo | Parchi dispositivi moderni con firmware aggiornato |
| WPA3-Enterprise a 192 bit | ECDSA P-384 o RSA 3072 o superiore | Definita dalla politica e dalla capacità di rinnovo | Siti a garanzia più elevata dopo i test di compatibilità |
| Dispositivo headless o legacy | Spesso non supportato | Ciclo di vita supportato dal fornitore o scadenza dell'eccezione | Percorso di eccezione |
La guida all'implementazione di WiFi Alliance specifica che la modalità WPA3-Enterprise a 192 bit limita l'autenticazione a EAP-TLS e utilizza suite AES-256-GCM con parametri a curva ellittica P-384 o dimensioni del modulo RSA/DH di almeno 3072 bit. Il profilo a garanzia più elevata della tabella deve quindi essere verificato rispetto all'intera suite selezionata, non solo all'etichetta della chiave del certificato.
I modelli di certificato, il software RADIUS, i supplicant e i provider crittografici devono essere concordi. Un endpoint che supporta il normale EAP-TLS potrebbe comunque non funzionare con questo profilo più rigido.
Fornire attendibilità, credenziali e configurazione contemporaneamente
Con lo SCEP, il profilo di gestione indica al dispositivo di generare una coppia di chiavi e richiedere un certificato. La CA firma la richiesta; il dispositivo conserva la propria chiave privata in uno spazio di archiviazione protetto. Non distribuisca lo stesso certificato client e la stessa chiave privata a più macchine.
Implementare le dipendenze in un ordine controllato:
- Prima la fiducia: installare i certificati CA attendibili richiesti.
- Poi le credenziali: inviare la configurazione SCEP e confermare l'avvenuta emissione.
- Infine il profilo wireless: fare riferimento alle credenziali client previste e alle impostazioni di convalida del server.
Mantenere coerente la destinazione dei gruppi tra i profili dipendenti. Utilizzare il confronto dei profili di certificato MDM WiFi per esaminare le differenze tra le piattaforme prima di standardizzare il rollout. Fornire inoltre una connessione di registrazione che non dipenda dal certificato che il dispositivo sta ancora cercando di ottenere.
Gestione del ciclo di vita dei certificati dall'emissione al rinnovo
Un laptop che si connette con successo oggi può riscontrare un errore dopo essere rimasto in un armadio per tutto il periodo di rinnovo. L'access point potrebbe essere funzionante, la password non è cambiata e l'utente non ha commesso alcun errore. L'endpoint semplicemente non dispone più di una credenziale accettabile.
La guida di orientamento ai requisiti EAP del NIST descrive la necessità che i certificati vengano sottoposti a provisioning prima dell'autenticazione, siano disponibili durante lo scambio e siano verificabili, incluso lo stato di revoca. Tali requisiti rendono le dipendenze del ciclo di vita parte integrante della disponibilità della rete.
Questa tempistica è utile per assegnare la responsabilità oltre la distribuzione iniziale.
Assegnare a ciascuna fase un controllo operativo
| Fase | Controllo | Errore che previene |
|---|---|---|
| Registrazione | Monitorare la registrazione MDM e la destinazione dei profili | Il dispositivo non riceve mai un'istruzione di registrazione |
| Emissione | Convalidare le autorizzazioni dei modelli e i risultati delle richieste | La CA rifiuta le richieste o emette certificati inutilizzabili |
| Distribuzione | Verificare l'installazione e l'accesso protetto alla chiave privata | Il certificato esiste ma il richiedente non può utilizzarlo |
| Rinnovo | Avviare in anticipo, monitorare il completamento e consentire la sovrapposizione testata | I dispositivi raggiungono la scadenza senza una sostituzione |
| Scadenza | Avvisare i proprietari e fornire un percorso di ripristino limitato | I dispositivi scaduti non hanno modo di effettuare il ripristino |
| Dismissione | Revocare le credenziali e rimuovere le voci dell'inventario obsolete | L'hardware dismesso conserva un'identità accettata |
Il rinnovo richiede una prova di completamento, non solo un'impostazione di automazione abilitata. Verificare che un certificato sostitutivo sia stato emesso, installato e utilizzato con successo. Durante la sovrapposizione, confermare che il supplicant selezioni una credenziale appropriata anziché sceglierne ripetutamente una obsoleta.
Pianificare la gestione per i dispositivi che non sono online
Imposti la finestra di rinnovo in base al comportamento effettivo del dispositivo. Le apparecchiature utilizzate stagionalmente o tenute come scorta potrebbero richiedere un processo di ripristino diverso rispetto a un laptop che effettua il check-in giornaliero. Non presupponga che un endpoint offline possa effettuare il rinnovo solo perché il suo vecchio certificato risulta ancora presente nell'MDM.
Mantenere un inventario che colleghi il numero seriale del certificato, l'identificatore dell'endpoint, il proprietario, l'emittente, la scadenza e lo stato di rinnovo. Includere i certificati della CA emittente e del server di autenticazione, poiché la loro sostituzione può interessare un numero di utenti molto più ampio.
Un lavoro di rinnovo eseguito correttamente non equivale a un dispositivo in grado di autenticarsi con il relativo certificato sostitutivo.
Testare gli errori dell'orologio di sistema, le ricreazioni del sistema operativo e le modifiche alla catena della CA. Una ricreazione può rimuovere la chiave privata; un errore dell'orologio può far apparire non ancora valido un certificato valido; una modifica alla catena può lasciare gli endpoint privi dell'attendibilità richiesta.
Assegnare responsabili nominativi per i guasti che coinvolgono MDM, PKI e servizi di rete. In caso contrario, ciascun team potrebbe segnalare che il proprio sistema funziona correttamente mentre l'endpoint rimane disconnesso. Il protocollo EAP-TLS trasforma il rischio di disservizio in un problema di inventario, automazione e gestione delle dipendenze. Non elimina tale rischio.
Revoca dell'accesso in caso di smarrimento dei dispositivi o di uscita delle persone dall'azienda
L'account di directory di un ex dipendente viene disabilitato, ma il suo laptop contiene ancora un certificato non scaduto. La possibilità di riconnettersi dipende dalle integrazioni di autorizzazione e dai controlli di revoca in uso. Disabilitare un account e revocare un certificato sono azioni distinte, a meno che il flusso di lavoro configurato non le colleghi esplicitamente.
Definire il risultato dell'offboarding in termini operativi: le nuove autenticazioni devono fallire, l'iscrizione non deve rilasciare credenziali sostitutive e le sessioni esistenti devono terminare tramite un meccanismo supportato. Un ticket HR completato non dimostra alcuno di questi risultati.
Comprendere i controlli dello stato
Una elenco di revoca dei certificati, o CRL, pubblica i certificati che un emittente ha revocato. Il protocollo Online Certificate Status Protocol, o OCSP, consente a un verificatore di richiedere lo stato del certificato a un responder.
Il componente che convalida il certificato applica la relativa politica di controllo dello stato. Per i certificati client, di norma si tratta del servizio di autenticazione e non dell'access point. Se le informazioni sullo stato non sono disponibili, una politica "fail-closed" può bloccare dispositivi altrimenti validi, mentre una politica "fail-open" può accettare una credenziale la cui revoca non può essere confermata.
Rendere tale scelta esplicita. Includere nei test le informazioni sullo stato salvate in cache, i ritardi di pubblicazione e la disponibilità del responder, anziché presupporre che fare clic su "revoca" modifichi immediatamente ogni decisione di autenticazione.
Utilizzare una procedura completa per i dispositivi smarriti
In caso di smarrimento di un laptop, coordinare le azioni anziché trattare ciascuna di esse come il passaggio finale di un team separato:
- Identificare e revocare le credenziali. Associare l'endpoint al numero seriale del relativo certificato effettivo e revocare le credenziali pertinenti.
- Impedire l'emissione di sostituti. Disabilitare l'idoneità all'iscrizione del dispositivo e applicare il processo di rimozione o dismissione MDM appropriato.
- Interrompere l'accesso attivo. Utilizzare i controlli di disconnessione della sessione supportati, inclusa la Change of Authorization (CoA) RADIUS ove l'infrastruttura lo supporti.
- Verificare il risultato. Confermare che la sessione sia terminata e che un nuovo tentativo di autenticazione venga rifiutato.
La sola revoca non termina necessariamente una sessione wireless stabilita. Sulle apparecchiature prive di un meccanismo di disconnessione supportato, la sessione potrebbe continuare fino alla riconnessione, alla riautenticazione o a un altro limite di sessione imposto. Registri tale limitazione nella procedura di gestione degli incidenti.
Il registro di controllo deve includere:
- Identità delle credenziali: identificatore del dispositivo, numero seriale del certificato e relativo proprietario.
- Prove della decisione: motivo della revoca, operatore e ora dell'azione.
- Prove dell'applicazione: ora di cessazione della sessione e successivo risultato di rifiuto.
- Esposizione residua: qualsiasi sessione che non è stato possibile terminare forzatamente e l'azione di contenimento intrapresa.
Pianificare esercitazioni di revoca. Eseguirle dopo le modifiche alle politiche di autenticazione e durante i test operativi di routine, in modo che un effettivo incidente di smarrimento del dispositivo non sia il primo tentativo di verificare l'intero percorso.
Pianificazione dell'idoneità dei dispositivi e delle eccezioni
Classi di dispositivi e idoneità con EAP-TLS
| Classe di dispositivi | Idoneità di EAP-TLS | Alternativa tipica | Domanda chiave da porsi |
|---|---|---|---|
| Laptop e telefoni gestiti | Elevata | Nessuna necessaria, registrazione MDM | La registrazione MDM è affidabile? |
| Tablet e chioschi aziendali | Buona se gestiti tramite MDM | Chiave specifica per il chiosco da sola SSID | La chiave privata può risiedere in un archivio sicuro? |
| Sensori IoT headless | Scarsa senza un firmware adeguato | Chiave per dispositivo su un VLAN isolato | Il firmware supporta 802.1X? |
| Sistemi per sale, AV e videoconferenza | Supporto specifico del fornitore | SSID dedicato con chiave per dispositivo | Il fornitore può installare e rinnovare i certificati? |
| Dispositivi medici | Spesso limitata | Rete segmentata con metodo approvato dal fornitore | Il dispositivo è certificato per questo metodo? |
| Endpoint con sistemi operativi legacy | Non supportati in assenza delle funzionalità richieste | VLAN di quarantena con eccezione a tempo | Quando viene riesaminata l'eccezione? |
Il vincolo fondamentale è che ogni singoloEAP-TLS client necessita di un proprio certificato, e non solo della fiducia nel server. La guida del NIST sulle reti wireless distingue questo requisito del certificato client dall'autenticazione tramite certificato basata solo sul server.
Un dispositivo necessita quindi di un supplicant funzionante, di una protezione adeguata della chiave privata e di una modalità supportata per ricevere e sostituire la propria credenziale. Una scheda tecnica che riporta "WiFi enterprise supportato" non è sufficiente per stabilire tali funzionalità.
Testare l'intero ciclo di vita dei dispositivi
Per un sistema da sala riunioni, richiedere al fornitore di dimostrare l'installazione, il rinnovo e il ripristino del certificato dopo un ripristino delle impostazioni di fabbrica. Un'interfaccia web che accetta il caricamento di un certificato può risolvere l'onboarding senza però risolvere la manutenzione.
Per le apparecchiature mediche e operative, mantenere i requisiti di supporto del fornitore. Non modificare il metodo di autenticazione di un dispositivo di produzione solo perché un altro prodotto dello stesso produttore lo supporta.
I dispositivi personali richiedono una decisione di idoneità separata. La struttura del processo di onboarding BYOD deve stabilire quale gestione o installazione del profilo sia accettabile prima di richiedere agli utenti di registrarsi.
Rendere le eccezioni circoscritte e tracciabili
Un dispositivo che non può utilizzare i certificati non dovrebbe ereditare i permessi di accesso del laptop di un dipendente gestito. Assegnare alla sua credenziale alternativa un proprietario definito e limitare la rete alle sue destinazioni necessarie.
Registrare quanto segue per ogni eccezione:
- Motivo tecnico: la funzionalità mancante o la restrizione del fornitore, supportata da una verifica della configurazione.
- Controlli compensativi: la segmentazione, i servizi consentiti e l'alternativa revocabile singolarmente.
- Data di revisione: una decisione pianificata per rinnovare, modificare o rimuovere l'eccezione.
- Piano di sostituzione: l'aggiornamento del firmware, il metodo di onboarding supportato o la sostituzione dell'hardware che vi porrebbe fine.
Evitare di trasformare una rete di quarantena temporanea in una collocazione permanente per le apparecchiature non identificate. Un'eccezione priva di proprietario o di condizione di uscita diventa una politica di accesso non documentata. L'approccio difendibile non consiste nell'adottare certificati a tutti i costi, bensì in una solida autenticazione dei dispositivi gestiti affiancata da alternative deliberatamente limitate.
Confermare il piano di certificazione prima dell'implementazione
Una dimostrazione riuscita mostra che un laptop integro è in grado di connettersi. Un progetto pilota utile mostra cosa accade quando l'iscrizione fallisce, una credenziale scade, un dispositivo viene ritirato e una dipendenza diventa non disponibile. Approvi il modello operativo, non solo il primo handshake riuscito.
Scegliere un sito pilota e identificare le classi di dispositivi interessate prima di modificare l'accesso di produzione. Censire le funzionalità degli access point, il comportamento dei supplicant e le versioni del firmware. Qualora sia richiesto un profilo di garanzia più elevato, convalidare il modello di certificato selezionato, i controlli della catena di certificazione e l'utilizzo avanzato della chiave rispetto ad endpoint rappresentativi.
Rendere concreta la verifica dello stato di preparazione di questa settimana
Utilizzi questa checklist per individuare i responsabili mancanti e le ipotesi non verificate.
- Confermare il supporto dei dispositivi: Verificare che ciascun dispositivo rientrante nell'ambito possa archiviare e utilizzare una chiave privata protetta, anziché importare semplicemente un certificato.
- Confermare la catena di fiducia e il rinnovo: Assegnare i responsabili per la catena della CA, il servizio di registrazione, il monitoraggio del rinnovo e il percorso di ripristino.
- Testare l'applicazione: Dimostrare l'accettazione, il rifiuto, la revoca e la terminazione della sessione attiva supportate.
- Approvare le eccezioni: Assegnare a ciascuna classe non supportata un'alternativa limitata, un responsabile referente e una data di revisione.
- Impostare avvisi operativi: Inoltrare gli eventi di scadenza imminente e di mancato rinnovo a una persona in grado di risolverli.
Utilizzi una RADIUS procedura di test dell'autenticazione ripetibile, in modo che gli ingegneri raccolgano prove comparabili. Registri la condizione del client, il risultato previsto, il risultato effettivo e il relativo codice di errore.
Valutare il progetto pilota in base alla sostenibilità
Eseguire il percorso del certificato accanto alla rete esistente con una procedura di ripristino definita. Includere la registrazione remota, un endpoint ricreato, una parte di ricambio offline e i sistemi operativi supportati dal proprio helpdesk. Non scegliere solo laptop predisposti di recente.
Esaminare i ticket dell'helpdesk insieme ai log di autenticazione. Separare i problemi relativi ai certificati da quelli di copertura wireless, assegnazione degli indirizzi e problemi di VLAN, in modo che il team non debba riprogettare la PKI per risolvere un guasto non correlato.
L'accettazione del progetto pilota dovrebbe indicare che i dispositivi gestiti si connettono di norma senza l'intervento dell'utente, i guasti hanno cause identificate e la revoca dell'accesso può essere dimostrata. Conservi le prove dei tentativi riusciti e di quelli rifiutati, con un contesto di identità sufficiente a spiegare la decisione presa.
Impostare la data di revisione del progetto pilota prima del suo inizio. Confermare il sito, le classi di dispositivi, i proprietari e i criteri di accettazione entro questa settimana, quindi procedere all'ampliamento solo dopo che il team avrà risolto i problemi e dimostrato il ripristino. Un ripristino su scala più ridotta con rinnovo e revoca affidabili costituisce una base migliore rispetto a una distribuzione ampia che nessuno è in grado di ripristinare con sicurezza.
Purple Access offre la modalità WiFi del personale WiFi basata su certificati tramite EAP-TLS fornito da MDM, oltre all'accesso per gli ospiti e per singolo dispositivo sugli access point già in Suo possesso. Visiti Purple Access per pianificare un progetto pilota in una sede, convalidare il certificato e i percorsi di eccezione e valutare il risultato nei ticket di supporto e negli elementi di prova di audit prima di estendere il rollout.
