Automazione della revoca dei certificati con OCSP e CRL in un ambiente NAC

Automazione della revoca dei certificati con OCSP e CRL in un ambiente NAC Un briefing tecnico Purple — Circa 10 minuti --- INTRODUZIONE E CONTESTO — circa 1 minuto Benvenuti alla serie di briefing tecnici Purple. Sono il vostro ospite e oggi approfondiremo i meccanismi di automazione della revoca dei certificati, in particolare come funzionano OCSP e CRL all'interno di un ambiente Network Access Control e perché configurare correttamente questo aspetto sia una delle decisioni di sicurezza più trascurate nelle implementazioni WiFi aziendali. Se gestite una catena alberghiera, un patrimonio retail, uno stadio o una rete del settore pubblico con centinaia o migliaia di dispositivi connessi, la gestione del ciclo di vita dei certificati non è un optional. È la differenza tra una rete che applica le policy in tempo reale e una che ospita silenziosamente credenziali revocate di dispositivi che avrebbero dovuto essere disconnessi settimane fa. Esamineremo l'architettura tecnica, analizzeremo due scenari di implementazione reali e concluderemo con le domande che il vostro team dovrebbe porsi prima di avvicinarsi a un rollout di produzione. Iniziamo. --- APPROFONDIMENTO TECNICO — circa 5 minuti Per prima cosa, definiamo il problema che stiamo risolvendo. In qualsiasi rete autenticata tramite lo standard IEEE 802.1X — che è alla base del WiFi aziendale, del NAC cablato e della maggior parte delle moderne architetture di accesso guest — i dispositivi si autenticano utilizzando credenziali o certificati. I certificati sono preferibili perché non si basano su segreti condivisi, sono associati al dispositivo e si integrano perfettamente con le piattaforme MDM attraverso protocolli come SCEP. Ma i certificati hanno un ciclo di vita. Scadono, vengono compromessi e i dispositivi vengono dismessi. Quando si verifica uno di questi eventi, è necessario un meccanismo per comunicare alla propria infrastruttura di rete: questo certificato non è più valido, smetti di considerarlo attendibile. Questo meccanismo si presenta in due varianti: CRL, che sta per Certificate Revocation List, e OCSP, che sta per Online Certificate Status Protocol. Iniziamo con la CRL. Una Certificate Revocation List è esattamente ciò che suggerisce il nome: un elenco firmato, pubblicato dalla Certificate Authority, contenente tutti i numeri di serie dei certificati che sono stati revocati. La vostra infrastruttura NAC — in genere un server RADIUS come FreeRADIUS, Cisco ISE o Aruba ClearPass — scarica periodicamente questo elenco da un CRL Distribution Point, che è semplicemente un endpoint HTTP o LDAP. Il server RADIUS memorizza l'elenco localmente nella cache e verifica i numeri di serie dei certificati in entrata rispetto a esso durante l'handshake EAP-TLS. Il vantaggio operativo della CRL è la semplicità e la resilienza offline. Una volta scaricato l'elenco, il controllo della revoca funziona anche se la CA non è raggiungibile. Lo svantaggio è la latenza. Se si revoca un certificato alle 9:00 e l'intervallo di aggiornamento della CRL è di 24 ore, quel dispositivo potrebbe comunque autenticarsi fino al successivo download programmato. In un ambiente ad alta sicurezza — un ospedale, il back office di servizi finanziari, una rete governativa — questa finestra temporale è inaccettabile. OCSP risolve il problema della latenza. Invece di mantenere un elenco memorizzato nella cache locale, il server RADIUS invia una query in tempo reale a un OCSP Responder — un servizio che si trova davanti alla CA — per ogni certificato che deve convalidare. Il responder restituisce una delle tre risposte: Good, Revoked o Unknown. L'intero scambio avviene inline, durante l'handshake EAP-TLS, in genere in meno di 100 millisecondi su un'infrastruttura ben dimensionata. Il compromesso con OCSP è la dipendenza dalla disponibilità. Se l'OCSP Responder si interrompe o se il server RADIUS non riesce a raggiungerlo a causa di una partizione di rete, è necessario prendere una decisione di policy: si sceglie il fail open — consentendo il proseguimento dell'autenticazione — o il fail closed — negando l'accesso fino a quando il responder non è raggiungibile? Il fail open mantiene il tempo di attività ma crea una lacuna di sicurezza. Il fail closed mantiene la postura di sicurezza ma può bloccare gli utenti legittimi durante un incidente infrastrutturale. Esiste una terza opzione che vale la pena conoscere: l'OCSP Stapling. In questo modello, il titolare del certificato — il dispositivo client — recupera periodicamente una risposta OCSP firmata dal responder e la allega all'handshake TLS. Il server RADIUS convalida la risposta allegata (stapled) anziché effettuare la propria query OCSP. Ciò riduce il carico sull'OCSP Responder, elimina il problema di privacy legato all'esposizione dei seriali dei certificati a un servizio esterno e migliora la resilienza. Lo svantaggio è che non tutti i supplicant EAP supportano lo stapling, quindi è necessario verificare la compatibilità del client prima di fare affidamento su di esso. Ora, come si inserisce questo in un'architettura NAC? Il motore di policy NAC — che si tratti di Cisco ISE, Aruba ClearPass, Juniper Mist o di uno stack open source basato su FreeRADIUS e PacketFence — si colloca tra il supplicant e la rete. Quando un dispositivo tenta di connettersi, il server RADIUS riceve l'Access-Request, esegue la negoziazione EAP-TLS, convalida la catena di certificati del client, verifica lo stato di revoca tramite OCSP o CRL, quindi emette un Access-Accept con un'assegnazione VLAN o un Access-Reject. La parte di automazione interviene a due livelli. In primo luogo, a livello di emissione dei certificati: la piattaforma MDM — Jamf, Intune, Workspace ONE — utilizza SCEP per fornire automaticamente i certificati ai dispositivi gestiti. Quando un dispositivo viene rimosso dalla registrazione o dismesso, l'MDM attiva una chiamata di revoca alla CA, che aggiorna la CRL e notifica l'OCSP Responder. In secondo luogo, a livello di applicazione del NAC: il server RADIUS è configurato per interrogare l'OCSP o aggiornare la cache della CRL secondo una pianificazione definita, garantendo che le decisioni di revoca si propaghino alla policy di accesso senza interventi manuali. Il punto di integrazione critico in questo caso è la pipeline di comunicazione da CA a NAC. In una distribuzione ben progettata, la revoca è una catena completamente automatizzata: l'MDM dismette il dispositivo, attiva la revoca della CA, la CA aggiorna l'OCSP Responder e pubblica la nuova CRL, il server RADIUS recepisce la modifica — immediatamente tramite OCSP o entro la successiva finestra di aggiornamento della CRL — e al dispositivo viene negato l'accesso al successivo tentativo di autenticazione. --- RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI — circa 2 minuti Ecco alcune linee guida pratiche per evitare che la distribuzione prenda una piega sbagliata. Primo: definisci la tua tolleranza alla latenza di revoca prima di scegliere il meccanismo. Se gestisci una rete WiFi per gli ospiti di un hotel in cui il rischio principale è un dispositivo del personale dismesso, un intervallo di aggiornamento della CRL di 4 ore è probabilmente sufficiente. Se gestisci una rete sanitaria in cui un dispositivo compromesso potrebbe accedere ai dati dei pazienti, hai bisogno di OCSP con policy fail-closed e un cluster di responder ad alta disponibilità. Secondo: non eseguire un singolo OCSP Responder in produzione. Distribuiscine almeno due, dietro un bilanciatore di carico, con monitoraggio dello stato di salute. Un'interruzione dell'OCSP Responder che causa un comportamento fail-closed genererà ticket di supporto più velocemente di quasi qualsiasi altro guasto dell'infrastruttura. Terzo: tieni d'occhio le dimensioni della CRL. Nelle grandi distribuzioni — parliamo di decine di migliaia di certificati — i file CRL possono crescere fino a diversi megabyte. Un server RADIUS che scarica una CRL da 5 MB ogni ora attraverso un collegamento WAN è un problema di throughput destinato a verificarsi. Prendi in considerazione le CRL delta, che contengono solo le modifiche dall'ultima CRL completa, o passa a OCSP per ambienti ad alto volume. Quarto: testa regolarmente la tua pipeline di revoca. Non basta configurare OCSP e dare per scontato che funzioni. Automatizza un test mensile: emetti un certificato, revocalo, tenta l'autenticazione, verifica il rifiuto. Se il tuo monitoraggio non rileva un OCSP Responder non funzionante, il tuo meccanismo di revoca è solo una messinscena. Quinto: allinea i periodi di validità dei certificati con la tua strategia di revoca. I certificati a breve durata — da 24 a 72 ore — riducono la finestra di esposizione per le credenziali compromesse e possono ridurre del tutto la dipendenza dall'infrastruttura di revoca. Questa è la direzione in cui si sta muovendo il settore ed è un'opzione che vale la pena valutare per le nuove distribuzioni. --- DOMANDE E RISPOSTE RAPIDE — circa 1 minuto Domanda: Posso utilizzare contemporaneamente sia OCSP che CRL? Sì. La maggior parte delle implementazioni RADIUS supporta una catena di fallback: prova prima OCSP, poi passa a CRL se il responder non è raggiungibile. Questo garantisce un controllo in tempo reale in condizioni normali e resilienza offline durante le interruzioni. Domanda: La piattaforma guest WiFi di Purple si integra con il NAC basato su certificati? La piattaforma di Purple opera a livello di accesso guest, gestendo l'autenticazione tramite Captive Portal, l'acquisizione dei dati e l'analisi. Per le reti aziendali del personale che eseguono lo standard 802.1X con autenticazione tramite certificato, Purple si integra con l'infrastruttura di rete sottostante — access point, controller e server RADIUS — anziché sostituire lo stack di gestione dei certificati. Le reti guest e del personale sono in genere segmentate, con meccanismi di autenticazione diversi e appropriati per ciascuna. Domanda: Qual è l'aspetto legato alla conformità? Lo standard PCI DSS 4.0 richiede che l'accesso agli ambienti dei dati dei titolari di carta utilizzi un'autenticazione forte. Il GDPR richiede misure tecniche adeguate per proteggere i dati personali. Entrambi i framework sono soddisfatti dallo standard 802.1X basato su certificati con revoca automatizzata, a condizione che si possa dimostrare che la revoca è tempestiva e testata. L'audit trail deve mostrare quando i certificati sono stati revocati e quando tale revoca si è propagata all'applicazione di rete. --- RIASSUNTO E PROSSIMI PASSI — circa 1 minuto Per riassumere: l'automazione della revoca dei certificati in un ambiente NAC è un problema a tre livelli. È necessaria una CA che supporti i trigger di revoca automatizzati, un risponditore OCSP o un punto di distribuzione CRL altamente disponibile e adeguatamente dimensionato, e un server RADIUS configurato per applicare lo stato di revoca come parte della sua policy di accesso. La scelta tra OCSP e CRL non è binaria: si tratta di una decisione sulla tolleranza al rischio che dovrebbe essere presa nel contesto dei requisiti di sicurezza, della topologia di rete e della maturità operativa del proprio ambiente. Se stai creando o esaminando una distribuzione NAC e desideri capire come la piattaforma di analisi e guest WiFi di Purple si inserisce nella più ampia architettura di rete, i link nelle note dello show ti porteranno alle guide tecniche pertinenti. Grazie per l'ascolto. Ci vediamo al prossimo briefing. --- FINE DELLO SCRIPT