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 Technical Briefing di Purple - Circa 10 Minuti --- INTRODUZIONE E CONTESTO - circa 1 minuto Benvenuti nella serie di Technical Briefing di 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 di rete 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. Rappresenta 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 roll-out di produzione. Iniziamo. --- APPROFONDIMENTO TECNICO - circa 5 minuti Per prima cosa, definiamo il problema che stiamo risolvendo. In qualsiasi rete autenticata tramite 802.1X - che è lo standard alla base delle reti WiFi aziendali, 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 tramite protocolli come SCEP. Ma i certificati hanno un ciclo di vita. Scadono, vengono compromessi e i dispositivi vengono dismessi. Quando si verifica una di queste situazioni, è necessario un meccanismo per comunicare all'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 CRL. Una Certificate Revocation List è esattamente ciò che suggerisce il nome - un elenco firmato, pubblicato dalla vostra Certificate Authority, contenente i numeri di serie di tutti i 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 confronta i numeri di serie dei certificati in entrata con questo elenco durante l'handshake EAP-TLS. Il vantaggio operativo di CRL risiede nella semplicità e nella 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 ore 9:00 e l'intervallo di aggiornamento della CRL è di 24 ore, quel dispositivo potrebbe ancora autenticarsi fino al download successivo pianificato. 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 responder OCSP - un servizio posizionato 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 strutturata. Il compromesso con OCSP è la dipendenza dalla disponibilità. Se il responder OCSP si interrompe o se il server RADIUS non riesce a raggiungerlo a causa di una partizione di rete, è necessario prendere una decisione di policy: consentire l'accesso in caso di guasto (fail open - consentendo il proseguimento dell'autenticazione) o bloccare l'accesso in caso di guasto (fail closed - negando l'accesso fino a quando il responder non sia raggiungibile)? La modalità fail open mantiene il tempo di attività ma crea una lacuna di sicurezza. La modalità fail closed mantiene il livello di sicurezza ma può bloccare gli utenti legittimi durante un incidente infrastrutturale. Esiste una terza opzione che vale la pena conoscere: 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 con timbro (stapled) anziché effettuare la propria query OCSP. Ciò riduce il carico sul responder OCSP, 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. In che modo tutto questo si inserisce in un'architettura NAC? Il motore di policy NAC - sia esso Cisco ISE, Aruba ClearPass, Juniper Mist o 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 la richiesta di Access-Request, esegue la negoziazione EAP-TLS, convalida la catena dei certificati client, verifica lo stato di revoca tramite OCSP o CRL, e infine emette un Access-Accept con l'assegnazione di una VLAN o un Access-Reject. L'automazione interviene su 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 avvia una chiamata di revoca alla CA, che aggiorna la CRL e notifica il responder OCSP. In secondo luogo, a livello di applicazione 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 alcun intervento manuale. Il punto di integrazione cruciale 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 una nuova CRL, il server RADIUS recepisce la modifica - o 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 DA EVITARE - circa 2 minuti Desidero fornirvi indicazioni pratiche per evitare che le installazioni vadano storte. In primo luogo: definite la vostra tolleranza alla latenza di revoca prima di scegliere il vostro meccanismo. Se gestite 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 adeguato. Se gestite una rete sanitaria in cui un dispositivo compromesso potrebbe accedere ai dati dei pazienti, è preferibile utilizzare OCSP con una policy di fail-closed e un cluster di responder ad alta disponibilità. In secondo luogo: non eseguite un singolo OCSP Responder in produzione. Distribuitene 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 all'infrastruttura. In terzo luogo: prestate attenzione alle 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. Prendete in considerazione le CRL delta, che contengono solo le modifiche apportate dall'ultima CRL completa, oppure passate a OCSP per gli ambienti ad alto volume. In quarto luogo: testate regolarmente la vostra pipeline di revoca. Non basta configurare OCSP e dare per scontato che funzioni. Automatizzate un test mensile: emettete un certificato, revocatelo, tentate l'autenticazione, verificate il rifiuto. Se il vostro monitoraggio non rileva un OCSP Responder non funzionante, il vostro meccanismo di revoca è solo di facciata. In quinto luogo: allineate i periodi di validità dei certificati con la vostra 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 è opportuno valutarla 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 alla CRL se il responder non è raggiungibile. Questo garantisce un controllo in tempo reale in condizioni normali e la 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 del Captive Portal, l'acquisizione dei dati e la relativa 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 quelle del personale sono in genere segmentate, con meccanismi di autenticazione differenti e adatti a ciascuna di esse. Domanda: Qual è l'aspetto legato alla conformità? Lo standard PCI-DSS 4.0 richiede che l'accesso agli ambienti con dati dei titolari di carta utilizzi un'autenticazione forte. Il GDPR impone l'adozione di 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 sia possibile dimostrare che la revoca sia tempestiva e testata. L'audit trail deve mostrare quando i certificati sono stati revocati e quando tale revoca è stata propagata all'applicazione sulla 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 CRL Distribution Point 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 si sta creando o esaminando una distribuzione NAC e si desidera comprendere come la piattaforma di guest WiFi e analytics di Purple si inserisca nella più ampia architettura di rete, i link nelle note dell'episodio rimanderanno alle guide tecniche pertinenti. Grazie per l'ascolto. Ci vediamo al prossimo briefing. --- FINE DELLO SCRIPT