Fondamenti di PKI per amministratori WiFi: certificati, CA e catene di attendibilità
Questa guida di riferimento tecnica spiega i concetti fondamentali della Public Key Infrastructure (PKI) per gli amministratori WiFi aziendali, coprendo le autorità di certificazione, le catene di attendibilità e i certificati X.509. Descrive dettagliatamente come la PKI supporti l'autenticazione reciproca EAP-TLS e fornisce linee guida pratiche per l'implementazione per i team IT nei settori dell'ospitalità, del retail e della pubblica amministrazione. La comprensione della PKI è un prerequisito obbligatorio per l'implementazione dell'autenticazione WiFi del personale basata su certificati con Purple.
Ascolta questa guida
Visualizza trascrizione del podcast
Sintesi Esecutiva
Per gli IT manager, i network architect e i direttori delle operazioni delle sedi fisiche, la sicurezza delle reti WiFi aziendali e del personale è un requisito operativo e di conformità fondamentale. I metodi di autenticazione legacy come le chiavi precondivise (PSK) o il filtraggio degli indirizzi MAC sono insufficienti per i moderni ambienti aziendali, lasciando le reti vulnerabili al furto di credenziali e allo spoofing dei dispositivi. Per ottenere una sicurezza solida e verificabile, le organizzazioni devono passare all'autenticazione basata su certificati, nello specifico EAP-TLS (Extensible Authentication Protocol-Transport Layer Security).
L'implementazione di EAP-TLS richiede una solida comprensione della Public Key Infrastructure (PKI). Questa guida spiega in modo semplice la PKI per gli amministratori WiFi, illustrando i ruoli delle Autorità di Certificazione (CA), i meccanismi della catena di attendibilità e le differenze pratiche tra i certificati server e client. Padroneggiando questi concetti fondamentali, i team IT possono progettare e implementare con sicurezza soluzioni di accesso alla rete sicure e scalabili nei settori dell' Ospitalità , del Retail e delle sedi del settore pubblico, garantendo la conformità a standard come PCI DSS e GDPR e offrendo al contempo una connettività fluida e senza password per i dispositivi gestiti. Comprendere la PKI è inoltre il prerequisito fondamentale per implementare l'autenticazione basata su certificati del WiFi del personale con Purple.
Approfondimento Tecnico
L'Architettura della Fiducia: Cos'è la Public Key Infrastructure?
La Public Key Infrastructure (PKI) è un framework crittografico che consente comunicazioni sicure e mutua autenticazione su una rete non attendibile. Nel contesto del WiFi aziendale, la PKI funge da sistema di passaporti digitali, verificando l'identità sia del dispositivo client (il supplicant) sia del server di autenticazione di rete (il server RADIUS) prima che avvenga qualsiasi scambio di dati.
Questo sistema si basa sui certificati X.509, che associano una chiave pubblica a un'identità verificata (come l'hostname di un server o l'indirizzo email di un utente) e sono firmati digitalmente da una terza parte fidata nota come Autorità di Certificazione (CA). La firma della CA è la garanzia crittografica che la rivendicazione di identità è legittima.
La Gerarchia dei Certificati e la Catena di Attendibilità
La forza della PKI risiede nella sua struttura gerarchica, nota come catena di attendibilità. Questa gerarchia garantisce che qualsiasi certificato presentato da un dispositivo o server possa essere tracciato crittograficamente a ritroso fino a una fonte universalmente attendibile. I tre livelli sono i seguenti.
Root Certificate Authority (Root CA): La Root CA è l'ancora crittografica di tutto l'ecosistema PKI. Rilascia un certificato autofirmato ed è intrinsecamente considerata affidabile dai dispositivi client e dai server. In un'implementazione aziendale sicura, la Root CA viene mantenuta offline e isolata fisicamente (air-gapped) per proteggere la sua chiave privata da compromissioni di rete. Il suo unico scopo operativo è firmare i certificati delle Intermediate CA.
Intermediate Certificate Authority (Intermediate CA): La Intermediate CA funge da cuscinetto tra la Root CA, altamente protetta, e l'ambiente operativo. È online e gestisce il rilascio quotidiano e la revoca dei certificati foglia (leaf certificates). Questa separazione è una strategia di mitigazione del rischio fondamentale: se una Intermediate CA viene compromessa, può essere revocata dalla Root CA senza invalidare l'intera infrastruttura PKI o richiedere la riconfigurazione di ogni dispositivo client.
Leaf Certificates (Certificati foglia o End-Entity): Questi sono i certificati installati sui singoli server e dispositivi client. Si trovano alla base della catena di attendibilità e non possono a loro volta firmare altri certificati. Esistono due tipi principali rilevanti per l'implementazione del WiFi. Il Certificato Server è installato sul server RADIUS, consentendo ai dispositivi client di verificare che si stiano connettendo alla rete aziendale legittima. Il Certificato Client è installato sui laptop del personale, sui dispositivi mobili o sui terminali point-of-sale, consentendo al server RADIUS di verificare l'identità di ogni specifico dispositivo o utente.
Come la PKI supporta l'autenticazione EAP-TLS
L'EAP-TLS rappresenta lo standard di riferimento per l'autenticazione WiFi sicura perché impone un'autenticazione reciproca basata su certificati. Ciò significa che sia il dispositivo client sia il server RADIUS devono dimostrare la propria identità l'uno all'altro utilizzando certificati convalidati rispetto alla catena di attendibilità PKI, eliminando i rischi intrinseci degli approcci basati su password.
Durante l'handshake EAP-TLS, che opera all'interno del framework IEEE 802.1X, il server RADIUS presenta prima il proprio Certificato Server al dispositivo client. Il dispositivo convalida la firma del certificato rispetto al proprio archivio delle Root CA attendibili. Se valido, il dispositivo ha la prova crittografica che si sta connettendo alla rete aziendale legittima e non a un access point canaglia o a un evil twin. Il dispositivo client presenta quindi il proprio Certificato Client al server RADIUS, che lo convalida rispetto alla CA. Una volta autenticate entrambe le parti, viene stabilito un tunnel TLS sicuro e viene concesso l'accesso alla rete. Non viene trasmessa alcuna password e non esistono segreti condivisi che possano essere rubati.
Questa architettura è anche alla base di WPA3-Enterprise, che impone la modalità di sicurezza a 192 bit e si affida alle stesse fondamenta PKI e 802.1X. Per le organizzazioni che distribuiscono Wireless Access Points in ambienti ad alta sicurezza, WPA3-Enterprise con EAP-TLS rappresenta l'attuale best practice.
CA Pubblica vs. CA Privata: La Decisione di Distribuzione
Una delle decisioni architetturali più consequenziali nella distribuzione di una PKI è la scelta tra una CA Pubblica e una CA Privata. La tabella seguente riassume i compromessi.
| Criterio | CA Pubblica | CA Privata |
|---|---|---|
| Costo | Tariffa per certificato (sostenibile per un numero ridotto di server) | Costo dell'infrastruttura, ma nessuna tariffa per certificato su larga scala |
| Fiducia del Dispositivo | Considerata affidabile per impostazione predefinita sulla maggior parte dei sistemi operativi e dispositivi | Richiede che la Root CA sia distribuita su tutti i dispositivi tramite MDM |
| Controllo | Limitato; la CA controlla le policy di emissione | Controllo totale su emissione, revoca e ciclo di vita |
| Miglior Caso d'Uso | Certificato Server RADIUS | Certificati Client per dispositivi aziendali gestiti |
| Conformità | Controllabile tramite i log pubblici di CT | Richiede processi di audit interni |
L'approccio consigliato per la maggior parte delle distribuzioni WiFi aziendali è un modello ibrido: utilizzare una CA Pubblica per il Certificato Server RADIUS per garantire un'ampia compatibilità, e implementare una CA Privata (come Microsoft Active Directory Certificate Services o un provider PKI basato su cloud) per l'emissione di Certificati Client ai dispositivi gestiti su scala.
Guida all'Implementazione
Passaggio 1: Progettare l'Architettura della CA
Inizia mappando i requisiti dei certificati. Identifica il numero di dispositivi gestiti, i sistemi operativi in uso e la piattaforma MDM disponibile. Determina se una gerarchia a due livelli (Root CA + Intermediate CA) o a tre livelli è appropriata per le dimensioni e il profilo di rischio della tua organizzazione.
Passaggio 2: Distribuire e Proteggere le CA Root e Intermediate
Stabilisci la Root CA offline su una macchina dedicata e isolata dalla rete (air-gapped). Utilizza la Root CA per firmare il certificato della Intermediate CA. Assicurati che la Intermediate CA sia distribuita in modo sicuro nel tuo data center o ambiente cloud e integrata con il tuo identity provider (IdP) o soluzione MDM. Conserva la chiave privata della Root CA in un Hardware Security Module (HSM) laddove il budget lo consenta.
Passaggio 3: Configurare il Server RADIUS
Installa il Certificato Server sul tuo server RADIUS. Configura il server per richiedere EAP-TLS per l'SSID aziendale sicuro. Assicurati che il server RADIUS consideri attendibile la Intermediate CA che ha emesso i Certificati Client e configuralo per eseguire il controllo di revoca tramite OCSP.
Passaggio 4: Distribuire i Certificati tramite MDM
Non tentare mai l'installazione manuale dei certificati su larga scala. Utilizza una piattaforma MDM come Microsoft Intune o Jamf per distribuire il certificato della Root CA, il certificato della Intermediate CA e i Certificati Client univoci a tutti i dispositivi gestiti tramite policy automatizzate. Ciò garantisce una distribuzione coerente e consente il rinnovo automatico.
Step 5: Implement and Test Revocation Mechanisms
Configure Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP). Test the revocation workflow end-to-end by revoking a test certificate and confirming the RADIUS server denies access within the expected timeframe. For environments requiring near-instant revocation — such as Retail POS networks — OCSP is mandatory.
Step 6: Monitor and Automate Lifecycle Management
Implement automated monitoring for certificate expiry across all tiers of the hierarchy. Configure alerts at 90, 60, and 30 days before expiry. Automate renewal at 60 days. This is the single most impactful operational step to prevent network outages.
Best Practices
Enforce Mutual Authentication Without Exception: Ensure client devices are configured to strictly validate the RADIUS server's certificate. Disabling server certificate validation — a common shortcut during initial deployment — leaves devices vulnerable to man-in-the-middle attacks and credential harvesting, and violates PCI DSS requirements.
Segregate Networks by Authentication Method: Use EAP-TLS for corporate and staff devices on a dedicated SSID. For public visitor access, deploy a robust Captive Portal solution like Guest WiFi on a fully segregated network. Do not attempt to deploy PKI to unmanaged guest devices.
Audit the PKI Infrastructure Regularly: Conduct quarterly audits of CA access controls, revocation lists, and certificate issuance logs. In Healthcare and Retail environments, this is a compliance requirement under HIPAA and PCI DSS respectively.
Integrate with Network Analytics: Once secure authentication is in place, layer on WiFi Analytics to gain visibility into device behaviour, connection patterns, and potential anomalies. A secure network is the foundation for trusted data.
Consider SD-WAN Integration: For multi-site deployments across hotel chains or retail estates, PKI integrates naturally with SD-WAN architectures. For context on how these technologies complement each other, see The Core SD-WAN Benefits for Modern Businesses .
Troubleshooting & Risk Mitigation
The table below maps common failure modes to their root causes and recommended mitigations.
| Symptom | Root Cause | Mitigation |
|---|---|---|
| Devices cannot connect; RADIUS logs show 'Unknown CA' | Client device does not trust the CA that issued the RADIUS server certificate | Push the Root CA to all devices via MDM |
| Sudden network-wide outage for all corporate devices | RADIUS Server Certificate or Intermediate CA certificate has expired | Implement automated monitoring and renewal; alert at 90/60/30 days |
| Stolen laptop can still access the network | CRL is stale or OCSP is not configured | Switch to OCSP for real-time revocation checking |
| I nuovi dispositivi non riescono a connettersi dopo l'arruolamento MDM | Certificato client non ancora distribuito dalla policy MDM | Verificare l'assegnazione della policy MDM e forzare una sincronizzazione del dispositivo |
| Errori di autenticazione intermittenti | Discrepanza dell'orologio tra client e server RADIUS | Assicurarsi che tutti i dispositivi utilizzino la sincronizzazione oraria NTP |
Per una comprensione più approfondita della configurazione e della risoluzione dei problemi di 802.1X, la guida 802.1X Authentication: Securing Network Access on Modern Devices fornisce linee guida dettagliate sulla configurazione indipendenti dal fornitore.
ROI e Impatto Aziendale
La transizione a un'architettura EAP-TLS supportata da PKI offre un valore aziendale misurabile per i gestori di location su molteplici dimensioni.
Mitigazione del Rischio e Compliance: L'eliminazione dell'autenticazione basata su password rimuove il vettore di attacco più comune per la compromissione della rete. Ciò riduce direttamente la probabilità di costose violazioni dei dati e semplifica la conformità con PCI DSS (richiesto per l'elaborazione dei pagamenti), GDPR (per la protezione dei dati) e le normative specifiche di settore. Per le location che distribuiscono Sensors IoT o sistemi di Wayfinding basati sulla posizione, una rete crittograficamente sicura è un prerequisito per l'integrità dei dati attendibili.
Efficienza Operativa: L'automazione della distribuzione dei certificati tramite MDM elimina il sovraccarico operativo della gestione delle password, riducendo i ticket di assistenza IT relativi alla connettività WiFi. Nei contesti ad alta rotazione come hotel e retail, dove l'onboarding e l'offboarding del personale sono frequenti, il rilascio e la revoca automatizzati dei certificati offrono un risparmio di tempo significativo rispetto alla gestione delle credenziali condivise.
Fondamenta per Servizi Avanzati: Una rete aziendale sicura e autenticata è la base affidabile su cui vengono costruiti servizi operativi avanzati. Sia che si distribuiscano WiFi Analytics per l'analisi dei flussi di visitatori, Sensors per i dati di occupazione in tempo reale, o il Wayfinding per grandi location, ognuna di queste funzionalità beneficia delle garanzie di integrità fornite dalla PKI.
Per gli operatori dell'ambito Hospitality nello specifico, la combinazione di una rete aziendale sicura per il personale e di un portale per gli ospiti ben progettato — come esplorato in Modern Hospitality WiFi Solutions Your Guests Deserve — rappresenta l'architettura WiFi aziendale completa. Per i nodi di Transport e le grandi location pubbliche, si applicano gli stessi principi su scala.
Definizioni chiave
Public Key Infrastructure (PKI)
Un framework di ruoli, criteri, hardware, software e procedure necessari per creare, gestire, distribuire, utilizzare, memorizzare e revocare certificati digitali e gestire la crittografia a chiave pubblica.
L'architettura fondamentale che deve essere implementata prima che un team IT possa distribuire un'autenticazione WiFi sicura basata su certificati utilizzando EAP-TLS.
Certificate Authority (CA)
Un'entità fidata che emette certificati digitali, verificando l'identità del soggetto del certificato e associando tale identità a una chiave pubblica con una firma crittografica.
L'autorità centrale nella rete che funge da fonte di verità per tutte le identità di dispositivi e server. Senza una CA fidata, non è possibile alcuna autenticazione basata su certificato.
X.509 Certificate
Il formato standard per i certificati a chiave pubblica, definito in RFC 5280. Contiene l'identità del soggetto, la chiave pubblica, l'identità dell'emittente, il periodo di validità e la firma digitale della CA.
Il passaporto digitale effettivo installato su un laptop o server che ne prova l'identità durante l'handshake EAP-TLS.
EAP-TLS (Extensible Authentication Protocol-Transport Layer Security)
Un metodo di autenticazione 802.1X che richiede un'autenticazione reciproca basata su certificati tra il dispositivo client (supplicant) e il server di autenticazione (RADIUS). Definito in RFC 5216.
Il metodo più sicuro per autenticare i dispositivi aziendali a una rete WiFi. Elimina la necessità di password e fornisce una prova crittografica dell'identità per entrambe le parti.
Trust Chain
Una sequenza gerarchica di certificati utilizzata per autenticare un'entità, partendo dal certificato foglia e risalendo attraverso la CA intermedia fino alla Root CA.
Il meccanismo attraverso il quale un laptop verifica che il certificato di un server RADIUS sia legittimo. Ogni anello della catena viene convalidato fino a raggiungere una Root CA fidata.
Certificate Revocation List (CRL)
Un elenco pubblicato periodicamente di certificati digitali che sono stati revocati dalla CA emittente prima della data di scadenza prevista e che non devono più essere considerati attendibili.
Un meccanismo per bloccare l'accesso da dispositivi smarriti o rubati. Le CRL vengono memorizzate nella cache e aggiornate periodicamente, il che significa che la revoca potrebbe non essere immediata — una limitazione risolta da OCSP.
Online Certificate Status Protocol (OCSP)
Un protocollo internet (RFC 6960) utilizzato per ottenere lo stato di revoca in tempo reale di un certificato digitale X.509 interrogando il responder OCSP della CA.
Il meccanismo di revoca preferito per gli ambienti ad alta sicurezza. Consente al server RADIUS di verificare la validità del certificato in tempo reale durante ogni tentativo di autenticazione, garantendo un'applicazione della revoca quasi istantanea.
RADIUS (Remote Authentication Dial-In User Service)
Un protocollo di rete che fornisce una gestione centralizzata di autenticazione, autorizzazione e tracciamento (AAA) per utenti e dispositivi che si connettono a una rete.
Il server centrale in una distribuzione WiFi aziendale che convalida i certificati e prende la decisione finale sul controllo degli accessi. Il server RADIUS è il nucleo operativo di una distribuzione EAP-TLS.
IEEE 802.1X
Uno standard IEEE per il controllo dell'accesso alla rete basato su porta (PNAC) che fornisce un meccanismo di autenticazione per i dispositivi che desiderano connettersi a una LAN o WLAN.
Il framework globale all'interno del quale opera EAP-TLS. La comprensione di 802.1X è essenziale per configurare gli access point e gli switch in modo da applicare l'autenticazione basata su certificati.
Mobile Device Management (MDM)
Una piattaforma software utilizzata dagli amministratori IT per gestire, configurare e proteggere da remoto i dispositivi mobili e i laptop all'interno di un'organizzazione.
Lo strumento operativo essenziale per distribuire certificati su larga scala. Le piattaforme MDM come Microsoft Intune e Jamf automatizzano la distribuzione dei certificati Root CA, dei certificati Intermediate CA e dei Client Certificates a tutti i dispositivi gestiti.
Esempi pratici
Un hotel di lusso da 500 camere a Londra deve mettere in sicurezza la propria rete WiFi del personale per i tablet del servizio di pulizia e i terminali POS (Point-of-Sale). Attualmente utilizzano una singola chiave precondivisa (PSK) che non è stata ruotata negli ultimi tre anni ed è nota a tutto il personale dipendente e interinale. Il Direttore IT ha ricevuto il compito di passare a un'architettura basata su certificati prima del prossimo audit PCI DSS. Come si dovrebbe procedere?
Fase 1 — Progettazione dell'Architettura: Implementare una Private PKI basata su cloud (ad esempio, Microsoft NDES tramite Intune o un provider PKI cloud dedicato) integrata con la piattaforma MDM dell'hotel. Ottenere un certificato server RADIUS da una CA pubblica come DigiCert.
Fase 2 — Distribuzione dell'Infrastruttura: Configurare il server RADIUS con il nuovo certificato server e abilitare EAP-TLS su un nuovo SSID nascosto dedicato al personale. Configurare OCSP per il controllo della revoca in tempo reale.
Fase 3 — Registrazione dei Dispositivi: Utilizzare la piattaforma MDM per distribuire la CA radice privata, la CA intermedia e i certificati client univoci a tutti i tablet del servizio di pulizia e ai terminali POS. Verificare l'installazione riuscita del certificato su un gruppo pilota di 20 dispositivi prima del roll-out completo.
Fase 4 — Migrazione e Dismissione: Migrare tutti i dispositivi sul nuovo SSID EAP-TLS tramite criteri MDM. Confermare la connettività su tutti i tipi di dispositivi. Dopo un periodo di funzionamento parallelo di due settimane, dismettere la rete PSK legacy.
Fase 5 — Passaggio Operativo: Documentare il ciclo di vita dei certificati, le procedure di revoca e i criteri MDM. Configurare avvisi di scadenza automatici e pianificare audit PKI trimestrali.
Una catena di vendita al dettaglio nazionale sta implementando EAP-TLS in 200 negozi. Durante i test pilota in cinque negozi, il team IT scopre che quando il laptop di un direttore di negozio viene segnalato come rubato e il certificato viene revocato nel sistema PKI, il dispositivo riesce comunque ad autenticarsi correttamente al WiFi aziendale fino a 18 ore dopo la revoca. Il team di sicurezza ritiene che questo sia un rischio inaccettabile, dato che il dispositivo potrebbe avere accesso ai sistemi di gestione dell'inventario. Come si dovrebbe risolvere il problema?
Il ritardo di 18 ore è causato dal server RADIUS che si affida a una Certificate Revocation List (CRL) memorizzata nella cache e scaricata raramente. Le CRL vengono in genere pubblicate secondo una pianificazione (ad esempio, ogni 24 ore) e memorizzate nella cache dal server RADIUS, il che significa che la revoca non si riflette in tempo reale.
La soluzione consiste nel riconfigurare il server RADIUS per utilizzare l'Online Certificate Status Protocol (OCSP) come meccanismo principale di controllo delle revoche. L'OCSP consente al server RADIUS di interrogare il risponditore OCSP della CA in tempo reale durante ogni handshake EAP-TLS, ricevendo una risposta immediata di "buono", "revocato" o "sconosciuto" per lo specifico certificato presentato.
Passaggi di configurazione: (1) Assicurarsi che la CA privata sia configurata con un endpoint di risposta OCSP. (2) Aggiornare la configurazione del server RADIUS per interrogare l'endpoint OCSP per ogni tentativo di autenticazione. (3) Configurare l'OCSP stapling dove supportato per ridurre la latenza. (4) Testare revocando un certificato e confermando che il server RADIUS neghi l'accesso entro 60 secondi.
Domande di esercitazione
Q1. La tua organizzazione sta migrando da PEAP-MSCHAPv2 (nome utente e password) a EAP-TLS per il WiFi aziendale. Il team di rete propone di utilizzare l'infrastruttura esistente di Active Directory Certificate Services (AD CS) per rilasciare certificati sia ai server RADIUS sia a tutti i laptop aziendali. Un membro del team fa notare che l'organizzazione ha anche 50 laptop di contrattisti esterni che non sono aggiunti al dominio. Qual è il principale rischio di compatibilità e come dovrebbe essere affrontato?
Suggerimento: Considera come i dispositivi non aggiunti al dominio convalideranno l'identità del server RADIUS quando questo presenta un certificato firmato dalla tua Private AD CS Root CA.
Visualizza risposta modello
Il rischio principale è che i 50 laptop dei contrattisti esterni non aggiunti al dominio non avranno la CA Root privata di AD CS nel proprio archivio dei certificati attendibili. Quando il server RADIUS presenterà il suo certificato server durante l'handshake EAP-TLS, questi dispositivi riceveranno un errore di 'Certificato non attendibile' e non riusciranno a connettersi. La soluzione raccomandata consiste nell'ottenere il certificato del server RADIUS da una CA pubblica (come DigiCert o Sectigo) anziché da AD CS privato. Le Root CA pubbliche sono preinstallate negli archivi di attendibilità di tutti i principali sistemi operativi, garantendo la compatibilità sia con i dispositivi aggiunti al dominio che con quelli non aggiunti. L'AD CS privato dovrebbe essere mantenuto esclusivamente per il rilascio di certificati client a dispositivi gestiti e aggiunti al dominio.
Q2. Durante un audit di conformità per un grande trust ospedaliero del NHS, l'auditor rileva che la Root CA è in esecuzione come macchina virtuale nel data center primario ed è permanentemente connessa alla rete interna dell'ospedale. L'auditor segnala questo elemento come rilievo critico. Quale modifica architetturale deve essere implementata e perché la configurazione attuale rappresenta un rischio significativo?
Suggerimento: Considera cosa accadrebbe a tutti i certificati dell'organizzazione se la chiave privata della Root CA venisse compromessa da un attacco ransomware o da una minaccia interna.
Visualizza risposta modello
La Root CA deve essere immediatamente portata offline e isolata fisicamente (air-gapped). La configurazione attuale rappresenta un rischio critico perché la chiave privata della Root CA è esposta ad attacchi basati sulla rete, inclusi ransomware, movimenti laterali da un account di dominio compromesso o minacce interne. Se la chiave privata della Root CA venisse rubata o utilizzata per firmare certificati dannosi, l'intera infrastruttura PKI — e di conseguenza ogni sistema autenticato tramite certificato nel trust — verrebbe compromessa. Il ripristino richiederebbe la revoca della Root CA e il nuovo rilascio di ogni singolo certificato nell'organizzazione, un evento operativo catastrofico. L'architettura corretta richiede che la Root CA venga accesa solo per la firma o la revoca di un certificato di una CA intermedia, lasciando che tutte le attività quotidiane di rilascio vengano gestite da una CA intermedia online. La chiave privata della Root CA deve essere memorizzata in un modulo di sicurezza hardware (HSM).
Q3. Un grande operatore di centri congressi desidera implementare l'autenticazione basata su certificati sia per il proprio personale IT permanente sia per le migliaia di espositori e visitatori che partecipano agli eventi. Ti viene chiesto di progettare un'unica infrastruttura PKI per servire entrambi i gruppi. Qual è la tua raccomandazione e perché?
Suggerimento: Considera la fattibilità operativa della distribuzione di certificati a migliaia di visitatori temporanei e non gestiti che potrebbero partecipare a un evento per un solo giorno.
Visualizza risposta modello
Si consiglia vivamente di non utilizzare la PKI e l'EAP-TLS per i visitatori pubblici e gli espositori. L'autenticazione basata su certificati richiede l'installazione di un certificato client e spesso di un profilo Root CA sul dispositivo dell'utente finale, il che è operativamente impossibile per dispositivi temporanei non gestiti e crea un'esperienza utente estremamente complessa. L'EAP-TLS dovrebbe essere rigorosamente riservato al personale IT permanente che utilizza dispositivi aziendali gestiti registrati nella piattaforma MDM dell'organizzazione. Per gli espositori e i visitatori, dovrebbe essere implementata una soluzione Captive Portal su un SSID completamente separato e segregato. Questa architettura a due reti — EAP-TLS sicuro per lo staff, Captive Portal per gli ospiti — rappresenta lo standard del settore per i gestori di grandi spazi ed è il modello supportato dalla piattaforma di Purple.
Q4. Un responsabile IT presso una catena di negozi ha distribuito con successo EAP-TLS in tutti i 150 punti vendita. Sei mesi dopo, il server RADIUS di 12 negozi smette simultaneamente di accettare connessioni client. Le indagini rivelano che non si è verificata alcuna revoca di certificati. Qual è la causa più probabile e quale lacuna di processo ha permesso che ciò accadesse?
Suggerimento: Considera cosa potrebbero avere in comune, dal punto di vista dei certificati, tutti e 12 i negozi interessati e quale evento potrebbe causare guasti simultanei.
Visualizza risposta modello
La causa più probabile è che il certificato della CA intermedia — o il certificato del server RADIUS — sia scaduto. Se tutti i 12 negozi fossero stati configurati utilizzando la stessa CA intermedia o lo stesso lotto di certificati del server RADIUS emessi nello stesso momento, sarebbero scaduti tutti simultaneamente. Si tratta di un fallimento nella gestione del ciclo di vita: l'organizzazione non ha implementato il monitoraggio e l'avviso automatizzato per la scadenza dei certificati. La risoluzione richiede il rinnovo dei certificati scaduti e l'immediata implementazione di un monitoraggio automatizzato con avvisi a 90, 60 e 30 giorni prima della scadenza per tutti i certificati della gerarchia, inclusi la CA intermedia, il certificato del server RADIUS e la Root CA.
Continua a leggere questa serie
Come configurare SCEP per la registrazione automatica dei certificati WiFi aziendali
Questa guida spiega come configurare SCEP (Simple Certificate Enrollment Protocol) per la registrazione automatica dei certificati WiFi aziendali, coprendo l'intera architettura, da PKI e NDES fino alla distribuzione dei profili MDM e alla convalida RADIUS. Si rivolge a responsabili IT, architetti di rete e CTO di hotel, catene di vendita al dettaglio, stadi, centri congressi e organizzazioni del settore pubblico che hanno l'esigenza di superare le chiavi precondivise e implementare un'autenticazione 802.1X EAP-TLS scalabile e basata sull'identità. La piattaforma cloud overlay di Purple, indipendente dall'hardware, si integra direttamente con questa architettura, fornendo il livello WiFi per ospiti e BYOD che si affianca alla rete del personale autenticata tramite certificato.
La guida enterprise a SCEP: implementare il Simple Certificate Enrollment Protocol per la sicurezza automatizzata del WiFi nei campus
Questa guida di riferimento tecnico fornisce un modello architetturale definitivo e una strategia di implementazione passo-passo per la distribuzione dei certificati WiFi aziendali tramite SCEP. Copre le differenze cruciali tra SCEP e PKCS, l'esatta sequenza di implementazione necessaria per il successo e le strategie reali di mitigazione del rischio per i leader IT.
Come implementare SCEP per l'assegnazione automatizzata dei certificati WiFi
Questa guida spiega come implementare SCEP (Simple Certificate Enrollment Protocol) per l'assegnazione automatizzata dei certificati WiFi nelle sedi aziendali. Copre l'intero schema architetturale - dalla progettazione PKI e integrazione MDM alla sequenza obbligatoria di implementazione in tre passaggi - e mostra ai manager IT e agli architetti di rete come eliminare le credenziali condivise, automatizzare la gestione del ciclo di vita dei certificati e soddisfare i requisiti PCI DSS e GDPR su scala globale.