PPSK usm kubang kerian: confronto tra funzionalità e modelli di deployment

Benvenuto al Technical Briefing di Purple. Oggi parleremo di PPSK presso USM Kubang Kerian - che cos'è, come si confronta con le alternative e come si presenta un'implementazione pratica su un grande campus di scienze della salute. Iniziamo con il contesto. L'Health Campus della Universiti Sains Malaysia a Kubang Kerian, Kelantan, è uno degli ambienti WiFi più complessi che si possano incontrare nel Sud-Est asiatico. Troviamo un ospedale universitario da 747 posti letto, diverse scuole di medicina e scienze della salute, alloggi per studenti, laboratori di ricerca e strutture cliniche - tutto in un unico campus, che condivide la stessa infrastruttura di rete fisica. La popolazione di utenti spazia tra studenti di medicina, personale clinico, team amministrativi, ricercatori in visita, pazienti e le loro famiglie. Il parco dispositivi è ancora più vario: laptop gestiti, telefoni personali, apparecchiature mediche, sensori IoT, sistemi di videosorveglianza e centraline per edifici intelligenti. La domanda che ogni direttore IT in un campus come questo finisce per porsi è: come offrire a ciascuno di questi gruppi di utenti un'esperienza di rete sicura e isolata senza implementare un SSID separato per ogni segmento? Perché se lo si fa - se si trasmettono otto o dieci SSID in un campus di queste dimensioni - si degradano le prestazioni WiFi di tutti. Ogni SSID consuma tempo di trasmissione per i beacon frame. In un ambiente denso, la proliferazione di SSID è letale per le prestazioni. La risposta, sempre più spesso, è PPSK. Private Pre-Shared Key. Ed è proprio questo che andremo ad analizzare oggi. Quindi, cos'è esattamente il PPSK? È un modello di autenticazione WiFi in cui ogni utente, ogni gruppo di dispositivi o ogni dipartimento riceve la propria chiave pre-condivisa unica. Tutti si connettono allo stesso SSID - lo stesso nome di rete - ma ogni chiave si mappa su una VLAN separata. L'access point gestisce automaticamente la mappatura chiave-VLAN. La terminologia varia a seconda del fornitore, e questo genera una reale confusione sul mercato. HPE Aruba lo chiama PPSK - Private Pre-Shared Key. Cisco Meraki lo chiama iPSK - Identity PSK. Juniper Mist utilizza ePSK. Ruckus lo chiama DPSK - Dynamic PSK. Extreme Networks, che ha sviluppato il concetto sotto il marchio Aerohive, lo chiama Private PSK. Ubiquiti UniFi lo chiama semplicemente PPSK. Il meccanismo di base è identico: un SSID, più chiavi uniche, ciascuna chiave legata a una VLAN o a un gruppo di criteri. Ora, confrontiamo il PPSK con le due alternative su cui più comunemente vi verranno poste domande. La prima è il PSK standard - una password condivisa per l'intera rete. Questo è ciò che la maggior parte delle implementazioni legacy dei campus utilizza ancora. È semplice da implementare, ma rappresenta un singolo punto di vulnerabilità. Una sola password compromessa significa che l'intera rete è esposta. Non è possibile revocare l'accesso a un singolo utente senza cambiare la password per tutti. In un campus con migliaia di utenti, questo non è semplicemente gestibile. La seconda alternativa è 802.1X Enterprise - lo standard di riferimento per l'autenticazione dei dispositivi aziendali. 802.1X utilizza un server RADIUS, un identity provider come Microsoft Entra ID, Okta o Google Workspace, e un supplicant su ogni dispositivo. Quel supplicant è il componente software che gestisce lo scambio di autenticazione EAP. Ogni laptop gestito ne ha uno. Il frigorifero intelligente del tuo studente no. Il tuo sensore IoT clinico no. Il controller di gestione del tuo edificio no. 802.1X è la risposta giusta per le reti del personale e i parchi dispositivi gestiti. È la risposta sbagliata per i dispositivi IoT, i dispositivi personali e il tipo di ambiente a uso misto che si trova in un campus di scienze della salute. PPSK si colloca nel mezzo. Offre isolamento per utente e assegnazione della VLAN senza richiedere un'infrastruttura di certificati o un supplicant su ogni dispositivo. Funziona con qualsiasi dispositivo dotato di WiFi, comprese le apparecchiature mediche legacy che non possono supportare WPA Enterprise. Questo è il suo vantaggio chiave in un ambiente sanitario e didattico. Esaminiamo il flusso di autenticazione tecnica. Quando un dispositivo si connette all'SSID, presenta la sua chiave precondivisa durante l'handshake a quattro vie WPA2. L'access point - o il cloud controller alle sue spalle - cerca quella chiave nell'archivio PPSK, identifica a quale VLAN è mappata e contrassegna il traffico del dispositivo di conseguenza da quel momento in poi. Il dispositivo vede una normale connessione WiFi. Non ha idea di essere stato inserito in un segmento isolato. Le sue applicazioni funzionano. I suoi servizi si associano. Tutto si comporta come previsto. In una distribuzione basata su RADIUS - che è ciò che Purple consiglia per qualsiasi campus con oltre 200 utenti simultanei - il controller interroga un server RADIUS esterno per ogni nuova connessione. Il server RADIUS restituisce una risposta Access-Accept contenente sia la convalida della chiave che l'assegnazione della VLAN. Questo offre registrazione centralizzata, percorsi di controllo e la possibilità di revocare l'accesso istantaneamente rimuovendo la chiave dall'archivio RADIUS. Il dispositivo viene disconnesso alla successiva riautenticazione. Non è richiesto alcun intervento manuale a livello di access point. Ora parliamo dei modelli di distribuzione, perché oggi ci sono tre approcci distinti in produzione e la scelta giusta dipende dalle dimensioni del tuo campus, dalle tue risorse IT e dall'hardware esistente. Il primo è il PPSK locale del controller. Le chiavi univoche sono memorizzate direttamente sul controller wireless, senza necessità di un server RADIUS esterno. Questo funziona per distribuzioni più piccole - fino a circa 200 utenti simultanei - ed è il più semplice da gestire. Ubiquiti UniFi lo supporta nativamente. Il limite è la scalabilità. La maggior parte dei controller si limita a poche centinaia di voci PPSK locali e si perde la gestione centralizzata del ciclo di vita che rende il PPSK operativamente praticabile su scala. Per un campus delle dimensioni di USM Kubang Kerian, questo modello non è appropriato. Il secondo modello è il PPSK supportato da RADIUS. Le chiavi sono memorizzate in un server RADIUS esterno e il controller interroga il server RADIUS per ogni nuova connessione. Questo modello è scalabile fino a migliaia di utenti. Ruckus SmartZone, HPE Aruba ClearPass e Cisco ISE supportano tutti questo modello. I costi di gestione operativa sono più elevati, ma la scalabilità e le capacità di gestione del ciclo di vita sono significativamente migliori. Questo è il modello giusto per un'implementazione in un grande campus. Il terzo modello - e quello consigliato da Purple per gli istituti che non dispongono di un'infrastruttura RADIUS dedicata - è il cloud RADIUS-as-a-Service. L'infrastruttura RADIUS è ospitata e gestita esternamente e i punti di accesso vengono collegati ad essa tramite un overlay cloud. La piattaforma di Purple si integra con l'hardware esistente - che si tratti di Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks o Fortinet - e fornisce il livello di orchestrazione per il provisioning delle chiavi, la gestione del ciclo di vita e l'onboarding degli utenti. Il ciclo di vita delle chiavi è completamente automatizzato. Uno studente si iscrive e la sua chiave viene fornita tramite l'integrazione con il sistema di gestione degli studenti. Si laurea o si ritira, e la sua chiave viene revocata all'istante. Nessun intervento manuale, nessuna lacuna di sicurezza. Specificamente per l'USM Kubang Kerian, l'architettura consigliata è un modello ibrido: PPSK per studenti, residenti e dispositivi IoT, con 802.1X per il personale clinico e i team amministrativi che utilizzano dispositivi gestiti. Tre modelli di autenticazione distinti, tre segmenti VLAN distinti, un'unica infrastruttura fisica. Studenti sulla VLAN 10 attraverso qualsiasi dimensione richiesta dal gruppo. Personale clinico su 802.1X rispetto all'identity provider dell'università. Sistemi IoT e di gestione degli edifici su una VLAN IoT dedicata con filtraggio in uscita. WiFi per gli ospiti nelle aree pubbliche tramite un Captive Portal su una VLAN separata. Un vincolo critico da segnalare prima di specificare l'hardware: l'implementazione PPSK di Ubiquiti UniFi è attualmente solo WPA2. Se si distribuiscono punti di accesso WiFi 6E e si desidera utilizzare la banda a 6 gigahertz per i client PPSK, è necessaria una piattaforma che supporti WPA3-SAE con PPSK - Aruba, Ruckus e Meraki supportano tutti questa funzionalità. La banda a 6 gigahertz è un'esclusiva di WPA3, pertanto qualsiasi implementazione PPSK su 6 gigahertz richiede la compatibilità con WPA3-SAE. Tenetelo presente nelle specifiche dell'hardware prima di scegliere un fornitore. Permettetemi di esaminare le insidie dell'implementazione, perché questi sono i tipi di errore che vedo ripetutamente nelle distribuzioni di produzione. Il primo è la proliferazione di SSID. Ogni SSID trasmesso consuma tempo di trasmissione per i beacon frame. In un ambiente di campus denso, se si trasmettono sei o otto SSID per punto di accesso, si degradano le prestazioni per tutti. Limitatevi a un massimo di quattro SSID per radio. Utilizzate il PPSK per servire più segmenti di utenti da un singolo SSID anziché creare un SSID separato per reparto o per piano. Il secondo errore comune è un'insufficiente configurazione delle porte trunk. Si progetta uno schema VLAN pulito, si distribuiscono gli access point e poi il traffico cade silenziosamente perché qualcuno ha dimenticato di consentire le VLAN pertinenti su un collegamento trunk tra lo switch di distribuzione e il livello di accesso. Convalidate ogni porta trunk durante la messa in servizio. Documentatelo. Testatelo con un dispositivo su ciascuna VLAN prima che gli utenti entrino in attività. Il terzo errore comune è la randomizzazione degli indirizzi MAC. A partire da iOS 14, Android 10 e Windows 11, i dispositivi utilizzano per impostazione predefinita indirizzi MAC randomizzati per motivi di privacy. Se il vostro server RADIUS esegue un controllo MAC e il dispositivo presenta un indirizzo randomizzato, il controllo fallisce e il dispositivo non può connettersi. La soluzione consiste nel configurare l'SSID per richiedere che i client utilizzino il loro indirizzo MAC hardware permanente, oppure nell'implementare un flusso di lavoro di pre-registrazione in cui gli utenti registrano il proprio dispositivo prima di connettersi. La piattaforma di Purple gestisce questo aspetto automaticamente come parte del flusso di onboarding degli utenti. Il quarto errore comune è la distribuzione delle chiavi. Generare le chiavi è semplice. Distribuirle agli utenti in modo sicuro e operativamente gestibile è più difficile. Un codice QR nel pacchetto di benvenuto funziona bene per il giorno del trasferimento. Un portale self-service in cui gli utenti possono recuperare la propria chiave e aggiungere nuovi dispositivi è preferibile per le operazioni quotidiane. Create il flusso di lavoro di distribuzione delle chiavi prima di procedere alla distribuzione, non dopo. Esaminiamo ora due scenari reali che sono direttamente rilevanti per un campus come USM Kubang Kerian. Scenario uno: un blocco di alloggi per studenti appositamente costruito da 400 posti letto. La sfida è il turnover annuale degli studenti. Ogni anno accademico, centinaia di studenti lasciano gli alloggi e centinaia di nuovi studenti vi entrano, spesso nella stessa settimana. Con un modello PSK condiviso, ciò significa una rotazione della password a livello di intero edificio che interessa tutti i residenti che ritornano. Con PPSK, significa revocare le chiavi del gruppo uscente e fornirne di nuove per quello in entrata - tutto automatizzato tramite l'integrazione con il sistema di gestione degli studenti. Un operatore che utilizza questo modello ha riferito una riduzione del 70% dei ticket di assistenza relativi al WiFi nel primo trimestre, principalmente perché i problemi di associazione dei dispositivi che avevano tormentato la precedente implementazione PSK condivisa sono stati completamente eliminati. Scenario due: una struttura di ricerca clinica con tipi di dispositivi misti. La sfida in questo caso è supportare sia le workstation cliniche gestite su 802.1X sia le apparecchiature mediche legacy che non possono supportare WPA Enterprise. Il modello ibrido - 802.1X per i dispositivi gestiti, PPSK per le apparecchiature legacy e IoT - risolve questo problema senza richiedere un'infrastruttura fisica separata. Le workstation cliniche si autenticano tramite EAP-TLS con l'identity provider dell'università. Le apparecchiature legacy ricevono una chiave PPSK dedicata mappata su una VLAN limitata con filtraggio in uscita verso i sistemi clinici che devono raggiungere, e nient'altro. La postura di sicurezza viene mantenuta. La complessità operativa è gestibile. Permettetemi di fornirvi tre regole pratiche prima di passare alle domande a risposta rapida. Regola uno: se il campus o l'edificio ha più di 200 utenti simultanei, utilizza PPSK basato su RADIUS, non PPSK locale sul controller. Il limite di scalabilità del PPSK locale sul controller causerà problemi entro 12 mesi dall'avvio. Regola due: pianifica la randomizzazione degli indirizzi MAC fin dal primo giorno. Integra un flusso di lavoro di preregistrazione nel processo di onboarding degli utenti. Non dare per scontato che i dispositivi presentino il loro indirizzo MAC permanente per impostazione predefinita. Non lo faranno. Regola tre: automatizza il ciclo di vita delle chiavi. Il valore operativo di PPSK rispetto a una PSK condivisa dipende interamente dal provisioning e dalla revoca automatica delle chiavi. La gestione manuale delle chiavi su larga scala non è praticabile. Integra il sistema con il sistema di gestione degli studenti o delle risorse umane fin dall'inizio. Bene. Domande a raffica. Queste sono quelle che emergono più spesso. PPSK funziona con WPA3? Sì, sulla maggior parte delle piattaforme enterprise. WPA3-SAE offre una protezione più forte contro gli attacchi con dizionario offline rispetto a WPA2-PSK, quindi distribuire PPSK su WPA3 dove i dispositivi client lo supportano è l'approccio corretto. L'eccezione è Ubiquiti UniFi, che attualmente supporta solo WPA2 per PPSK. Quante chiavi PPSK può supportare un singolo SSID? Con un server RADIUS esterno, il limite pratico è la capacità del database RADIUS. Cisco Meraki supporta fino a 5.000 voci iPSK per rete. Il servizio cloud RADIUS di Purple scala fino a decine di migliaia di chiavi simultanee. PPSK sostituisce 802.1X? No. Per flotte di dispositivi aziendali completamente gestite in cui contano la responsabilità individuale e l'autenticazione basata su certificati, 802.1X rimane la risposta corretta. PPSK è la risposta corretta per i dispositivi IoT, i dispositivi personali e gli ambienti a uso misto in cui 802.1X non è pratico. Posso integrare PPSK con il mio sistema di gestione degli studenti? Sì, tramite l'API del fornitore. Aruba Central, Meraki, Ruckus e Mist espongono tutti API REST per la gestione delle chiavi PPSK. La piattaforma di Purple fornisce integrazioni predefinite che automatizzano il provisioning e la revoca in base allo stato di iscrizione. Per riassumere. PPSK è il modello di autenticazione corretto per un campus complesso e a uso misto come USM Kubang Kerian. Offre isolamento per utente e assegnazione delle VLAN senza richiedere un'infrastruttura di certificati su ogni dispositivo. Il modello ibrido - PPSK per studenti e IoT, 802.1X per il personale - è l'architettura che offre sia sicurezza che semplicità operativa su larga scala. Automatizza il ciclo di vita delle chiavi fin dal primo giorno. Pianifica la randomizzazione del MAC. Mantieni il numero di SSID inferiore a quattro per radio. E se stai implementando su larga scala, utilizza un servizio cloud RADIUS invece di gestire l'infrastruttura da solo. Questo è il Purple Technical Briefing su PPSK per USM Kubang Kerian. Se desideri approfondire uno di questi argomenti, la guida scritta completa è disponibile su purple.ai. Grazie per l'ascolto.