Comprendere Cisco SUDI: Identità del Dispositivo Basata su Hardware nel Controllo dell'Accesso alla Rete

Comprendere Cisco SUDI: Identità del Dispositivo Basata su Hardware nel Controllo dell'Accesso alla Rete Un briefing tecnico di Purple - Testo completo del podcast (circa 10 minuti) --- SEGMENTO 1: INTRODUZIONE E CONTESTO (circa 1 minuto) Ciao e benvenuti a un briefing tecnico di Purple. Nei prossimi dieci minuti vi guiderò attraverso Cisco SUDI - Secure Unique Device Identifier - spiegando cos'è in realtà, come si inserisce nella vostra architettura di controllo dell'accesso alla rete e cosa dovete fare al riguardo se gestite un'infrastruttura Cisco su larga scala. Questo briefing è rivolto ad architetti di rete, responsabili IT e CTO di grandi strutture - hotel, catene di vendita al dettaglio, stadi, centri congressi - ovunque si gestisca una rete WiFi aziendale e si abbia la necessità di essere certi che l'hardware sulla rete sia esattamente quello che dichiara di essere. Iniziamo con il problema risolto da SUDI. In qualsiasi rete di grandi dimensioni, ci sono decine o centinaia di access point, switch e controller. La domanda da cui dipende la vostra sicurezza è: come fate a sapere che ognuno di questi dispositivi è un prodotto Cisco originale e non modificato, e non un contraffatto, un'unità compromessa o un dispositivo manomesso durante il transito? Questo è il divario che SUDI va a colmare. --- SEGMENTO 2: APPROFONDIMENTO TECNICO (circa 5 minuti) SUDI sta per Secure Unique Device Identifier. Si tratta di un certificato X.509 versione 3, lo stesso formato di certificato utilizzato in HTTPS e TLS, ma anziché essere emesso per una persona o un server, viene emesso per uno specifico componente hardware durante la produzione. Contiene l'identificatore del prodotto e il numero di serie del dispositivo, ed è radicato nella Public Key Infrastructure di Cisco. Ecco cosa differenzia SUDI da un certificato software installato autonomamente. Il certificato SUDI, insieme alla coppia di chiavi associata, risiede all'interno di un chip resistente alle manomissioni chiamato Trust Anchor module, o TAm. La chiave privata viene generata all'interno di quel chip e non lo lascia mai. Non è possibile esportarla. Non è possibile clonarla. Se qualcuno manomette fisicamente il chip, la chiave viene distrutta. Questa è la root of trust hardware. SUDI è l'implementazione di Cisco dello standard IEEE 802.1AR, lo standard di settore per i Secure Device Identifier, o DevID. Secondo lo standard 802.1AR, la credenziale installata dal produttore è chiamata Initial Device Identifier, o IDevID. Il SUDI di Cisco è esattamente questo: un IDevID che Cisco installa in fabbrica. È possibile integrarlo con un Locally Significant Device Identifier, o LDevID, emesso dalla propria PKI per le policy di autorizzazione locali. Ora, come si collega tutto questo al controllo dell'accesso alla rete? Il punto di integrazione più comune è lo standard IEEE 802.1X, lo standard per il controllo dell'accesso alla rete basato su porta. Quando un access point o uno switch Cisco si connette, può presentare il proprio certificato SUDI a un server RADIUS (in genere Cisco ISE, Identity Services Engine) utilizzando EAP-TLS, ovvero Extensible Authentication Protocol con Transport Layer Security. Il server RADIUS convalida il certificato rispetto alla CA pubblica di Cisco, conferma che il dispositivo è originale e quindi applica la policy di rete appropriata. Questo approccio è notevolmente più sicuro rispetto al MAC Address Bypass, che è il meccanismo di fallback utilizzato dalla maggior parte delle reti per i dispositivi infrastrutturali. Gli indirizzi MAC possono essere contraffatti in meno di un minuto. Un certificato vincolato all'hardware in un chip resistente alle manomissioni non può essere contraffatto senza distruggere fisicamente il dispositivo. Nel contesto di una grande struttura, questo è importante per tre motivi. In primo luogo, elimina il rischio che access point non autorizzati accedano alla rete. Un dispositivo contraffatto o non autorizzato semplicemente non può presentare un SUDI valido. In secondo luogo, consente il Zero Touch Provisioning automatizzato: un nuovo dispositivo viene spedito alla struttura, si accende, presenta il proprio SUDI e il sistema di gestione lo verifica rispetto all'inventario prima di inviare la configurazione. Nessun intervento manuale. In terzo luogo, offre un audit trail verificabile crittograficamente. Ogni dispositivo che si è autenticato sulla rete lo ha fatto con un certificato che dimostra che si tratta di uno specifico prodotto Cisco registrato. Vorrei parlare del Trust Anchor module in modo un po' più dettagliato, perché è la base su cui poggia tutto il resto. Il TAm è un chip proprietario di Cisco che fornisce tre elementi: storage sicuro non volatile per il SUDI e le chiavi, servizi crittografici inclusa la generazione di numeri casuali e il fingerprinting hardware. Quest'ultimo aspetto merita attenzione: Cisco registra un'impronta digitale crittografica dei componenti hardware critici di un dispositivo al momento della produzione e memorizza tale impronta nel TAm. All'avvio, il firmware UEFI calcola una nuova impronta dell'hardware rilevato e la confronta con quella master memorizzata nel TAm. Se le impronte non corrispondono, il dispositivo arresta il processo di avvio. Questo meccanismo rileva la manomissione dell'hardware in transito, una preoccupazione reale per le installazioni in grandi strutture in cui l'hardware può passare attraverso diverse mani prima dell'installazione. Un aspetto operativo di cui essere consapevoli: i certificati SUDI emessi prima di maggio 2019 scadono dieci anni dopo la data di produzione o il 14 maggio 2029, a seconda di quale evento si verifichi per primo. Cisco ha affrontato questo problema con una nuova generazione di certificati chiamata SUDI-2099, validi fino a dicembre 2099. Se utilizzate hardware della serie Catalyst 9000 prodotto prima del 2019, dovete verificare subito le date di scadenza dei SUDI. Il comando su IOS-XE è show crypto pki certificate. Cercate il trustpoint CISCO_IDEVID_SUDI e verificate la data di scadenza. Se utilizzate Catalyst 9200, aggiornate a IOS-XE 17.12.2 o versioni successive per assicurarvi di utilizzare il certificato 2099 corretto. --- SEGMENTO 3: RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI (circa 2 minuti) Lasciate che vi illustri il quadro pratico dell'implementazione. Se state distribuendo l'autenticazione basata su SUDI in un ambiente di grandi dimensioni, ecco la sequenza consigliata. Iniziate con la vostra infrastruttura RADIUS. Cisco ISE è la scelta naturale se fate già parte dell'ecosistema Cisco, ma qualsiasi server RADIUS che supporti EAP-TLS e possa effettuare la convalida rispetto a una CA esterna funzionerà. È necessario importare la root CA di Cisco e i certificati ACT2 SUDI CA nell'archivio di attendibilità del server RADIUS. Questi certificati sono disponibili pubblicamente sul portale PKI di Cisco. Successivamente, configurate la policy 802.1X per richiedere l'autenticazione basata su certificato per i dispositivi infrastrutturali. Separate questa policy da quella di autenticazione degli utenti finali: i flussi di autenticazione del personale e degli ospiti sono diversi e dovrebbero risiedere su set di policy distinti in ISE. Per le nuove distribuzioni, abilitate il Zero Touch Provisioning. Il vostro sistema di gestione della rete (Cisco DNA Center o Catalyst Center) può utilizzare SUDI to verificare l'identità del dispositivo prima di inviare la configurazione. Questo elimina il processo di staging manuale e riduce i tempi di provisioning da ore a pochi minuti per dispositivo. Ora, passiamo alle trappole comuni. La più frequente consiste nel combinare l'autenticazione SUDI con il MAC Address Bypass sulla stessa porta. Se ricorrete al MAB in caso di errore di SUDI, compromettete l'intero modello di sicurezza. Definite una policy chiara: i dispositivi compatibili con SUDI devono autenticarsi tramite SUDI, senza eccezioni. I dispositivi non compatibili con SUDI vengono indirizzati a una VLAN di quarantena in attesa di verifica manuale. La seconda trappola è la scadenza dei certificati. Configurate subito il monitoraggio delle date di scadenza dei SUDI in tutta la vostra infrastruttura. Non aspettate un'interruzione del servizio per scoprire che i vostri access point non riescono più ad autenticarsi. La piattaforma di Purple si integra con Cisco Meraki e altri fornitori di hardware per mostrare i segnali di stato dei dispositivi, incluso lo stato di autenticazione, in un'unica dashboard, rendendo pratico questo tipo di monitoraggio proattivo su larga scala. La terza trappola è l'estensione impropria dell'ambito di applicazione. SUDI autentica il dispositivo hardware. Non autentica l'utente che si connette tramite quel dispositivo. È comunque necessario un livello di identità separato per ospiti, personale e residenti. È qui che si colloca una piattaforma come Purple: noi gestiamo il livello dell'identità umana, l'acquisizione del consenso, l'assegnazione delle VLAN per il traffico degli ospiti e la reportistica, mentre SUDI gestisce il livello infrastrutturale sottostante. --- SEGMENTO 4: DOMANDE E RISPOSTE RAPIDE (circa 1 minuto) Passiamo a tre domande che mi vengono poste regolarmente. SUDI sostituisce la mia PKI esistente? No. SUDI è un IDevID installato dal produttore. Prova che il dispositivo è hardware Cisco originale. La vostra PKI aziendale emette LDevID e certificati utente per tutto il resto. Funzionano in parallelo. Posso usare SUDI su hardware non Cisco? No. SUDI è specifico di Cisco. HPE Aruba ha un equivalente chiamato certificati di provisioning IAP. Ruckus e Juniper Mist hanno i propri meccanismi di identità dei dispositivi. Lo standard sottostante, IEEE 802.1AR, è neutrale rispetto ai fornitori, ma ogni produttore lo implementa in modo diverso. Cosa succede quando un certificato SUDI scade? I servizi che si affidano a SUDI per l'autenticazione (HTTPS, SSH con autenticazione tramite certificato, Zero Touch Provisioning) smetteranno di funzionare. Il dispositivo in sé continua a funzionare, ma non può più dimostrare la propria identità crittograficamente. Ecco perché la migrazione a SUDI-2099 è importante. --- SEGMENTO 5: RIEPILOGO E PROSSIMI PASSI (circa 1 minuto) Per concludere: Cisco SUDI offre un'identità del dispositivo ancorata all'hardware che non può essere contraffatta, clonata o esportata. È la base di un livello infrastrutturale affidabile. Combinato con lo standard IEEE 802.1X e una policy RADIUS ben configurata, elimina il rischio di dispositivi non autorizzati e consente il provisioning automatizzato su larga scala. Le vostre tre azioni immediate: uno, verificate la scadenza dei SUDI nella vostra infrastruttura Cisco utilizzando il comando show crypto pki certificate. Due, importate la root CA di Cisco nell'archivio di attendibilità del server RADIUS e configurate le policy EAP-TLS per i dispositivi infrastrutturali. Tre, separate la policy di autenticazione dell'infrastruttura da quella degli utenti finali: servono a scopi diversi e devono essere gestite in modo indipendente. Se desiderate approfondire come Purple si integra con Cisco Meraki e altri fornitori di hardware per offrire una segmentazione della rete basata sull'identità per ospiti, personale e residenti, visitate purple.ai o leggete le guide correlate collegate sotto questo episodio. Grazie per l'ascolto. Ci vediamo al prossimo briefing. --- FINE DEL TESTO