Progettazione di un'architettura WiFi multi-tenant per MDU

Progettare un'architettura WiFi multi-tenant per MDU - Un briefing tecnico Purple. Benvenuti alla serie di briefing tecnici Purple. Oggi approfondiremo l'architettura alla base di alcune delle distribuzioni WiFi più complesse che si possano incontrare negli ambienti aziendali - il WiFi multi-tenant per edifici residenziali (MDU) e ad uso misto. Sia che siate responsabili di un hotel da 300 camere dove ospiti, personale e sistemi di gestione dell'edificio condividono tutti la stessa infrastruttura fisica, di un complesso misto di uffici e spazi commerciali, o di uno studentato con centinaia di inquilini indipendenti, la sfida è fondamentalmente la stessa: come fornire una connettività affidabile, sicura e isolata a più parti indipendenti su un'unica rete fisica condivisa? Questo non è un esercizio teorico. Le decisioni prese in fase di progettazione dell'architettura determineranno direttamente il vostro livello di sicurezza, l'esposizione alla conformità ai sensi del GDPR e del PCI-DSS e, francamente, se il vostro help desk verrà inondato di reclami a sei mesi dal lancio. Quindi, entriamo nel vivo della questione. La base di qualsiasi architettura WiFi multi-tenant è la segmentazione della rete - e il meccanismo principale per ottenere tale segmentazione è il tagging VLAN, definito dallo standard IEEE 802.1Q. Il concetto è semplice: si assegna ogni tenant, o ogni classe di traffico, a una LAN virtuale distinta. Il traffico sulla VLAN 10 non può raggiungere il traffico sulla VLAN 20 a meno che non lo si consenta esplicitamente tramite una policy di routing o di firewall. Questo isolamento logico è la vostra prima linea di difesa. Ma è qui che i progettisti spesso commettono il primo errore: confondono la segmentazione VLAN con la sicurezza. Le VLAN forniscono isolamento, non sicurezza. Sono comunque necessarie policy di firewall tra le VLAN, sono necessarie liste di controllo degli accessi e bisogna riflettere attentamente su quale routing inter-VLAN consentire. Una porta trunk configurata in modo errato può far crollare l'intero modello di segmentazione in pochi secondi. Ora parliamo del livello fisico. In un ambiente MDU, in genere si dispone di un'infrastruttura fisica condivisa - cablaggio, switch e access point - al servizio di più tenant. Gli stessi access point trasmettono più SSID, ciascuno mappato su una VLAN diversa. In questo modo il Tenant A si connette al proprio SSID, il suo traffico viene taggato con la VLAN 10 a livello di AP, attraversa lo switch condiviso su una porta trunk e arriva al livello di distribuzione dove viene instradato nella subnet isolata del Tenant A. Il traffico del Tenant B segue lo stesso percorso fisico ma è completamente isolato a livello 2. È qui che la scelta della piattaforma degli access point è estremamente importante. Sono necessari AP che supportino mappature SSID-VLAN multiple, che siano in grado di gestire le frequenze radio tra decine di unità potenzialmente vicine e che si integrino con un controller centralizzato o una piattaforma di gestione cloud. Il controller è fondamentale - è ciò che vi offre la possibilità di applicare modifiche alle policy, monitorare il throughput per singolo tenant e rispondere agli imprevisti senza dover intervenire sui singoli AP.Sul fronte dell'autenticazione, lo standard attuale per le implementazioni multi-tenant di livello enterprise è lo standard IEEE 802.1X con autenticazione RADIUS. Ciascun tenant esegue l'autenticazione tramite il proprio server RADIUS o una infrastruttura RADIUS condivisa con l'applicazione di policy specifiche per tenant. Lo standard WPA3-Enterprise è oggi lo standard di crittografia raccomandato - fornisce una modalità di sicurezza a 192 bit per ambienti ad alta sensibilità ed elimina le vulnerabilità associate all'handshake a quattro vie di WPA2. Per i segmenti WiFi per gli ospiti - e in un contesto MDU, ne avrai quasi sempre almeno uno - la scelta ricade tipicamente su un modello con Captive Portal. L'ospite si connette a un SSID aperto o WPA2-Personal, viene reindirizzato a una splash page per l'autenticazione o l'accettazione dei termini e ottiene quindi l'accesso alla sola rete internet su una VLAN isolata. Aspetto fondamentale, tale VLAN ospiti non deve avere alcun instradamento verso nessuna VLAN dei tenant. Zero. Questo è non negoziabile sia dal punto di vista della sicurezza sia da quello del GDPR. Parliamo per un momento dell'ambiente a radiofrequenza, perché è qui che le implementazioni MDU diventano davvero complesse. Quando ci sono più tenant in unità adiacenti - si pensi al corridoio di un hotel con camere su entrambi i lati, o a un centro commerciale con negozi che condividono le pareti - ci si trova in un ambiente RF ad alta densità. L'interferenza co-canale è il tuo nemico. È necessaria una corretta pianificazione RF prima dell'installazione: un site survey che mappi la propagazione del segnale, identifichi le fonti di interferenza e guidi la strategia di allocazione dei canali. La banda a 2.4 GHz offre tre canali non sovrapposti nella maggior parte dei domini normativi - i canali 1, 6 e 11. La banda a 5 GHz ne offre un numero significativamente maggiore, ed è per questo che le installazioni moderne spingono i client verso i 5 GHz ove possibile. Il Wi-Fi 6 e il Wi-Fi 6E estendono ulteriormente questo aspetto nella banda a 6 GHz, offrendo uno spettro pulito e ampiamente privo di interferenze causate da dispositivi legacy. Per le nuove installazioni MDU nel 2025 e oltre, specificare AP abilitati per il Wi-Fi 6E è la scelta giusta - lo spazio di spettro aggiuntivo ripaga ampiamente negli ambienti densi. Un modello di architettura che sta guadagnando una notevole popolarità nelle grandi installazioni MDU è l'uso di un overlay Software-Defined Networking - nello specifico approcci SD-WAN o SD-LAN in cui le policy dei tenant sono definite a livello centrale e distribuite verso l'edge. Questo scollega il livello delle policy dall'infrastruttura fisica, il che significa che è possibile attivare un nuovo tenant, modificare la sua allocazione di banda o revocare il suo accesso senza dover toccare una singola riga di comando dello switch. Per i gestori di strutture che amministrano decine o centinaia di tenant, tale efficienza operativa è rivoluzionaria. L'IoT è l'altra dimensione che non si può ignorare. In un moderno MDU - che si tratti di un hotel, di un complesso commerciale o di un blocco residenziale - sono presenti sistemi di gestione dell'edificio, controller HVAC, illuminazione intelligente, controllo degli accessi, TVCC e una gamma crescente di altri dispositivi connessi. Questi devono risiedere su una propria VLAN isolata, completamente separata sia dal traffico degli inquilini che da quello degli ospiti. I dispositivi IoT sono notoriamente difficili da aggiornare e rappresentano una superficie di attacco significativa. Segmentateli, monitorateli e applicate un filtraggio rigoroso del traffico in uscita in modo che possano comunicare solo con le piattaforme di gestione designate. Bene, passiamo alla pratica. Ecco come affronterei l'implementazione di un nuovo MDU. Iniziate con la progettazione logica prima di toccare un singolo componente hardware. Definite il numero di inquilini, le classi di traffico - gestione, aziendale, ospiti, IoT, pagamenti - e assegnate le VLAN di conseguenza. Documentate lo schema di indirizzamento IP. Definite la policy di routing inter-VLAN: cosa può comunicare con cosa e cosa è assolutamente vietato. Quindi, eseguite la pianificazione RF. Richiedete un sopralluogo adeguato del sito. Non affidatevi alle mappe di copertura dei fornitori, che nel migliore dei casi sono ottimistiche. Sono necessarie misurazioni reali del segnale nello spazio fisico, tenendo conto dei materiali delle pareti, della struttura dei solai e dell'ambiente RF degli edifici circostanti. Quando specificate l'hardware, date la priorità alle piattaforme che supportano la gestione cloud centralizzata. I costi operativi per la gestione di un parco AP distribuito senza un controller sono insostenibili su larga scala. Cercate piattaforme che offrano policy di larghezza di banda per SSID, reportistica per inquilino e integrazione con la vostra infrastruttura RADIUS. Sulle insidie: l'errore più comune che riscontro è l'insufficiente configurazione delle porte trunk. I progettisti creano uno splendido schema VLAN e poi dimenticano di consentire esplicitamente le VLAN pertinenti su ogni collegamento trunk lungo il percorso. Il traffico cade silenziosamente, gli inquilini si lamentano e il team di supporto passa giorni a rintracciare il problema. Documentate meticolosamente le configurazioni dei trunk e convalidatele in fase di messa in servizio. La seconda insidia è la proliferazione degli SSID. Ogni SSID trasmesso consuma tempo di trasmissione per i frame di beacon. In un ambiente denso, trasmettere otto o dieci SSID per AP riduce le prestazioni per tutti. Mantenete il numero di SSID al minimo necessario, in genere non più di quattro per radio. Utilizzate l'assegnazione dinamica delle VLAN tramite gli attributi RADIUS anziché creare SSID separati per servire più inquilini da un unico SSID. La terza insidia è trascurare il piano di gestione. La VLAN di gestione - quella su cui comunicano i vostri AP, switch e controller - deve essere completamente isolata da tutte le VLAN degli inquilini e degli ospiti. Se un inquilino può raggiungere il vostro piano di gestione, avete una vulnerabilità di sicurezza critica. Utilizzate la gestione out-of-band dove possibile e applicate ACL rigorose al traffico di gestione. Ora vorrei passare in rassegna alcune domande che emergono costantemente in queste implementazioni. Quanti tenant può supportare un singolo AP? Dal punto di vista pratico, la maggior parte degli AP enterprise può gestire da 20 a 30 client attivi contemporaneamente per radio prima che le prestazioni degradino. In un MDU ad alta densità, pianifica un AP ogni 15-20 dispositivi attivi, non per unità fisica. Ho bisogno di un AP separato per ogni tenant? No - questo è proprio lo scopo della multi-tenancy basata su VLAN. Più tenant condividono lo stesso AP, con l'isolamento del traffico applicato a livello di rete. Qual è la corretta allocazione della larghezza di banda per tenant? Non esiste una risposta universale, ma un punto di partenza comune è da 10 a 25 megabit al secondo garantiti con capacità di burst fino alla capacità di uplink disponibile. Utilizza policy QoS per imporre questo limite ed evitare che un singolo tenant saturi l'uplink condiviso. Come gestisco un tenant che ha bisogno del proprio firewall? Fornisci loro una VLAN dedicata e un punto di consegna instradato. Collegheranno il proprio CPE o firewall a quel punto di consegna, e tutto ciò che si trova dietro di esso sarà di loro responsabilità. Per riassumere: un'architettura WiFi multi-tenant ben progettata per un MDU si basa su quattro pilastri. Primo, una rigorosa segmentazione VLAN con policy di firewall applicate tra i segmenti. Secondo, una gestione centralizzata basata su controller che offre visibilità operativa e controllo delle policy su scala. Terzo, una corretta pianificazione RF che tenga conto dell'ambiente fisico e della densità del deployment. E quarto, un modello di sicurezza che affronti l'autenticazione, la crittografia, l'isolamento IoT e i requisiti di conformità fin dal primo giorno. Le organizzazioni che ottengono questo risultato vedono risultati misurabili: riduzione dei costi di supporto, onboarding dei tenant più rapido, una postura di conformità dimostrabile per gli audit e la possibilità di monetizzare la connettività come servizio anziché trattarla come un centro di costo. Se stai pianificando un deployment MDU e desideri esplorare come la piattaforma di Purple possa fornire analisi, gestione del guest WiFi e un livello di reportistica a livello di tenant sopra la tua infrastruttura di rete, le risorse collegate nella guida sono un buon punto di partenza. Grazie per l'ascolto. Alla prossima.