Il consiglio più comune nel dibattito tra single tenant vs multi tenant è anche il meno utile: il single tenant è sicuro, il multi tenant è economico, e la decisione si riduce a una scheda di valutazione degli acquisti. Questa impostazione fallisce negli edifici in cui la progettazione della rete ha il maggiore impatto commerciale.
In un hotel, uno studentato, un complesso residenziale in affitto (BTR), un campus ospedaliero o uno spazio di lavoro flessibile, la domanda decisiva è chi controlla il confine della rete. Una piattaforma dedicata può comunque subire perdite di traffico a causa di policy inadeguate. Un'infrastruttura fisica condivisa può proteggere ogni tenant quando l'identità, l'autenticazione, il routing e la revoca sono progettati correttamente. Il numero di tenant è solo l'etichetta. Il controllo dei confini è l'architettura.
I dati sul settore abitativo nel Regno Unito rendono difficile ignorare questa distinzione. Un'analisi governativa ha identificato 459.262 complessi residenziali che sono o potrebbero essere a regime misto, contenenti 3,33 milioni di alloggi sociali, pari al 79% dei 4,21 milioni di alloggi sociali identificati nelle statistiche ufficiali sull'edilizia residenziale. Tuttavia, il rapporto medio di inquilini sociali era dell'80%, mentre la mediana era del 97%, dimostrando che i complessi residenziali possono contenere diversi regimi di occupazione pur rimanendo fortemente concentrati in un solo tipo. Gli appartamenti appositamente costruiti rappresentavano il 54% dei complessi multi-abitativi identificati, con un rapporto mediano di inquilini sociali del 91%, rispetto al 50% per gli appartamenti convertiti. La tipologia di immobile modifica il problema dei confini operativi, non solo il contratto di locazione. (Analisi del governo britannico sul regime misto negli alloggi sociali inglesi)
Perché la questione Single Tenant vs Multi Tenant va ben oltre il SaaS
I team aziendali spesso ereditano questa discussione dal procurement SaaS. Confrontano istanze dedicate con infrastrutture applicative condivise, presumendo poi che la stessa conclusione si applichi a un edificio fisico. Non è così. Nelle proprietà condivise, la questione più importante è se l'operatore sia in grado di mantenere un residente, un ospite, un dipartimento o un fornitore all'interno del corretto confine di accesso e di policy.
Un deployment single-tenant di solito offre ai tecnici una separazione fisica più netta. Ciò è utile per l'ambito di audit, il controllo delle modifiche e il contenimento dei guasti. Tuttavia, non elimina i rischi operativi. Un controller con patch non aggiornate, credenziali amministratore deboli, una regola del firewall configurata male o un servizio di autenticazione con un raggio d'azione errato possono compromettere un ambiente dedicato con la stessa efficacia di uno condiviso.
Il networking multi-tenant comporta una responsabilità diversa. L'operatore condivide access point, switch, controller, uplink e spesso il piano di gestione, per poi utilizzare controlli logici per separare gli utenti. Tali controlli devono funzionare a livello di wireless, autenticazione, routing, DNS, monitoraggio e supporto. Un tenant non è isolato semplicemente perché ha un SSID o una splash page differenti.
Il confine pratico non è l'SSID. È la catena completa dall'identità all'autorizzazione, all'inoltro del traffico, alla telemetria e alla revoca.
Tre confini da testare
Considera l'architettura attraverso tre domande distinte:
- Confine fisico: Quali radio, switch, controller, circuiti e appliance sono condivisi?
- Confine di identità: In che modo la rete riconosce quale persona, dispositivo, stanza, dipartimento o azienda si sta connettendo?
- Confine di gestione: Chi può creare credenziali, modificare le policy, ispezionare la telemetria, approvare l'accesso e revocarlo?
Questo approccio è fondamentale nelle reti residenziali e del settore ricettivo perché agli utenti non interessa se il fornitore definisce il design cloud-native, condiviso o dedicato. Si aspettano che i loro dispositivi si connettano facilmente e che i dispositivi dei vicini rimangano separati. Il personale si aspetta che l'accesso venga revocato quando il proprio account di directory viene disattivato. Gli operatori si aspettano un unico flusso di lavoro di supporto anziché un'infrastruttura separata per ogni stanza o occupante.
Le politiche di sicurezza antincendio del Regno Unito offrono un utile parallelo. Il Fire Safety Act 2021 ha chiarito che il Fire Safety Order si applica alla struttura, alle pareti esterne, ai balconi e alle porte d'ingresso degli appartamenti negli edifici residenziali multi-occupati con due o più unità abitative. I relativi regolamenti sono entrati in vigore il 23 gennaio 2023, mentre i controlli storici sugli HMO si sono sviluppati a seguito di gravi incendi e hanno formalizzato una categoria di rischio distinta per gli edifici multi-occupati. (Ricerca del governo britannico sugli alloggi a regime misto e contesto sulla sicurezza antincendio)
La lezione per gli architetti di rete è diretta. L'occupazione condivisa merita controlli espliciti, ma la risposta non è automaticamente l'hardware dedicato. Si tratta di un confine dimostrabile che corrisponde al rischio dell'edificio, al modello commerciale e alla capacità operativa.
Spiegazione delle architetture Single Tenant e Multi Tenant
Nel networking, single tenant significa che una singola organizzazione o utente riceve uno stack infrastrutturale dedicato o un'istanza operativa dedicata. Ciò può includere access point, controller, VLAN, domini di autenticazione, monitoraggio e permessi di gestione separati. Questo design limita le dipendenze condivise, rendendo l'ambiente più facile da gestire quando l'organizzazione possiede ogni endpoint e decisione di policy.
Un ente ospedaliero, un sito della difesa o un campus aziendale possono scegliere questo modello per il traffico principale perché i loro processi interni di identità, conformità e risposta agli incidenti richiedono un ambiente strettamente controllato. L'infrastruttura dedicata può anche supportare una pianificazione radio personalizzata, requisiti di dispositivi insoliti e finestre di modifica che sarebbero difficili da coordinare tra inquilini non correlati.
Il networking multi tenant utilizza una struttura fisica comune applicando al contempo controlli logici per organizzazione, nucleo familiare, stanza, reparto o servizio. VLAN, VRF, attributi RADIUS, chiavi pre-condivise private basate sull'identità, policy del firewall e motori di policy possono creare contesti di accesso separati senza duplicare ogni appliance.
La rete fisica è condivisa. Il contesto di sicurezza e l'esperienza utente non dovrebbero esserlo. Una catena alberghiera potrebbe gestire un'unica piattaforma centralizzata tra le varie proprietà, mentre un fornitore di alloggi per studenti potrebbe mappare ciascun residente o unità a un contesto di policy e credenziali separato.
Panoramica sul networking single tenant vs multi tenant
| Dimensione | Single Tenant | Multi Tenant |
|---|---|---|
| Isolamento fisico | Infrastruttura dedicata o istanza operativa | Switch, access point, controller o circuiti condivisi |
| Isolamento logico | Di solito più semplice perché meno tenant condividono l'ambiente | Essenziale, applicato tramite identità, VLAN, VRF, regole firewall e policy |
| Piano di gestione | Dedicato o strettamente limitato a un'unica organizzazione | Centralizzato, con amministrazione basata sui tenant e autorizzazioni delegate |
| Scalabilità dei costi | Ripete l'infrastruttura e il lavoro operativo per ciascun tenant | Condivide l'infrastruttura e concentra la gestione |
| Contesto tipico | Aziende regolamentate, difesa, sanità di base, patrimonio aziendale dedicato | Ospitalità, alloggi per studenti, BTR, servizi gestiti, spazi di lavoro condivisi |
| Principale modalità di guasto | Le strutture duplicate si differenziano nel tempo o non vengono sottoposte a sufficiente manutenzione | Un errore di policy o di identità può influire su più tenant |
I team che confrontano i modelli di implementazione possono utilizzare questa guida all'architettura WiFi multi-tenant come riferimento pratico, ma il design deve comunque essere testato rispetto all'edificio reale e al modello operativo.
La scelta non è tra sicuro e insicuro. È tra la separazione fisica con maggiore duplicazione e la separazione logica con maggiori requisiti di progettazione e governance.
Confronto diretto basato sui criteri fondamentali
La decisione sull'architettura appartiene al modello di edificio e operativo, non all'etichetta SaaS. Una rete sanitaria, una residenza per studenti, una proprietà BTR e un hotel possono tutti fornire il WiFi come un servizio di pubblica utilità, eppure i loro confini di tolleranza ai guasti, le responsabilità di supporto e i modelli di traffico differiscono.
Scegli il single tenant quando un guasto deve rimanere confinato all'interno del patrimonio fisico di una sola organizzazione. Gli ingegneri possono modificare un controller, un firewall o un servizio di autenticazione senza dover coordinare una finestra di manutenzione condivisa. Questo vantaggio dura solo se ogni ambiente dedicato riceve un'adeguata applicazione di patch, monitoraggio, documentazione e test di ripristino. L'infrastruttura dedicata offre controllo, non resilienza automatica.
Scegli il multi tenant quando un unico operatore deve fornire un servizio ripetibile a molti occupanti o proprietà. Un fabric condiviso supporta policy standard, monitoraggio centralizzato e un onboarding coerente. L'operatore si assume quindi un carico di governance maggiore: credenziali, traffico, telemetria e accesso amministrativo devono rimanere correttamente delimitati per ogni tenant.
Cinque criteri che determinano il design
| Criterio | Single Tenant | Multi Tenant | Punto di Ancoraggio |
|---|---|---|---|
| Isolamento | La separazione fisica limita il raggio d'impatto condiviso | La separazione logica deve essere mantenuta in ogni livello di controllo | La forza dell'isolamento aumenta con il grado di separazione, dallo schema condiviso al database per tenant |
| Sicurezza | Meno dipendenze condivise creano un confine di audit più chiaro | I controlli centralizzati migliorano la coerenza, ma un singolo errore di policy può influire su più tenant | La sicurezza dipende dalla verifica dell'identità, dalla configurazione, dal patching e dal monitoraggio, non dall'etichetta dell'architettura |
| Costo | Hardware, licenze, canali di supporto e manutenzione si ripetono per ogni tenant | L'infrastruttura condivisa migliora l'utilizzo e riduce il lavoro ripetitivo | Il costo per tenant aumenta all'aumentare dell'isolamento. Il confronto dettagliato dei costi appare nella sezione successiva (UK SaaS architecture comparison) |
| Prestazioni | La capacità dedicata evita la contesa tra i tenant | La capacità condivisa richiede il controllo degli accessi, QoS e monitoraggio attivo | L'operatore ha bisogno di controlli espliciti per i vicini rumorosi e i dispositivi ad alta domanda |
| Operazioni | Ogni ambiente può essere più semplice, ma la gestione complessiva diventa ripetitiva | Una sola piattaforma può funzionare in modo efficiente, a condizione che l'automazione dell'identità e delle policy sia matura | Il single tenant concentra il lavoro operativo per singolo ambiente. Il multi tenant lo concentra nella governance e nel piano di controllo |
L'isolamento è una proprietà del design
Verifica l'isolamento attraverso i flussi di traffico, non con i diagrammi. Un residente può rilevare il dispositivo di un altro residente? Un ospite può raggiungere i servizi del personale? Un amministratore di supporto può visualizzare i dati di sessione di un altro tenant? Un'identità revocata perde l'accesso immediatamente, anche dai dispositivi precedentemente autorizzati?
Gli stessi test si applicano a entrambi i modelli. Un controller dedicato non risponde ad essi automaticamente, e un controller condiviso non li rende impossibili. La questione decisiva è dove avviene l'applicazione, come vengono definiti gli amministratori e quanta infrastruttura comune si trova sotto ogni tenant.
Negli alloggi per studenti e nel settore BTR, i residenti si aspettano un accesso privato anche se l'edificio condivide switching, wireless e connettività a monte. Gli hotel affrontano lo stesso confine tra servizi per ospiti, personale e servizi operativi. Il settore sanitario aggiunge apparecchiature cliniche gestite e sistemi legacy, pertanto il modello di policy deve proteggere tali dipendenze senza rendere impraticabile il supporto ordinario.
Le prestazioni seguono i modelli di domanda
Gli hotel registrano picchi di domanda concentrati intorno al check-in, agli eventi e all'uso serale. Gli alloggi per studenti combinano un'alta densità di dispositivi con un turnover frequente. Il settore sanitario mescola apparecchiature gestite, dispositivi personali e sistemi specialistici. Il single tenant può riservare la capacità, mentre il multi tenant può soddisfare la stessa domanda quando l'operatore misura il tempo di trasmissione (airtime), applica il QoS e separa il traffico critico dall'uso ricreativo.
Il WiFi è ormai un servizio essenziale in queste proprietà. Un'interruzione del servizio influisce sull'esperienza dei residenti, sulle attività degli ospiti e sui risultati commerciali, non solo su una dashboard tecnica.
Il test pratico è semplice: l'operatore può osservare la congestione prima che gli utenti la segnalino, identificare il tenant o il servizio responsabile e modificare la policy senza ricostruire la rete? In caso contrario, il modello di isolamento selezionato è incompleto.
Costi, scalabilità e costi operativi nascosti dell'isolamento
L'infrastruttura dedicata sembra semplice in un piano di progetto. Ogni tenant riceve i propri controller, switch, access point, licenze, integrazioni di monitoraggio, archivi di identità, pianificazione del firmware e processo di supporto. Il conto include il tempo di progettazione necessario per distribuire, documentare, testare, patchare e ripristinare ogni singola copia.
Il design single-tenant duplica anche il lavoro operativo. Gli ingegneri gestiscono modelli separati, esaminano avvisi simili in console differenti, ripetono la convalida del firmware e mantengono procedure di ripristino indipendenti. Questa separazione giustifica il suo costo quando un inquilino necessita di un confine di conformità distinto o di controlli tecnici insoliti. Diventa invece un'erosione del margine quando ogni inquilino riceve lo stesso servizio e nessuna policy richiede una separazione fisica.
Il confronto dei costi precedentemente menzionato rimane valido, ma gli operatori di rete devono tenere conto di spese che le tabelle SaaS non mostrano. Una licenza controller separata può comportare un proprio ambito contrattuale. Ogni piattaforma aggiuntiva può richiedere un accordo di supporto, una finestra di manutenzione e la convalida del firmware prima dell'implementazione. Gli ingegneri dedicano inoltre tempo a testare l'autenticazione, il monitoraggio, il failover e il passaggio di consegne agli inquilini in ambienti multipli. In un portafoglio affollato di alloggi per studenti nel Regno Unito, BTR o strutture ricettive, queste ore influiscono sul margine di servizio tanto direttamente quanto l'hardware.
Analisi dettagliata dei costi per singolo tenant
| Voce di costo | Single Tenant, per tenant | Multi Tenant, per tenant | Note |
|---|---|---|---|
| Infrastruttura fisica | Stack dedicato o riservato | Allocazione su fabric condiviso | Il single tenant comporta la ripetizione di apparecchiature e lavori in loco |
| Licenze per controller e piattaforma | Istanza separata o ambito di licenza dedicato | Piattaforma condivisa, licenze basate sul tenant | Le condizioni contrattuali possono modificare il risultato |
| Identità e autenticazione | Realm separato o integrazione dedicata | Servizio condiviso con policy mirate | Il multi tenant richiede una mappatura forte dei tenant |
| Monitoraggio | Dashboard e percorsi di avviso separati | Dashboard centrale con filtri per tenant | Un filtraggio inadeguato può creare un rischio per il controllo degli accessi |
| Supporto e gestione del cambiamento | Finestre e runbook specifici per tenant | Workflow standardizzati con eccezioni | La standardizzazione migliora la scalabilità solo quando la policy è matura |
| Ripristino e test | Piani di ripristino separati | Ripristino della piattaforma condivisa più convalida del tenant | L'operatore deve dimostrare il ripristino a livello di tenant |
Una piattaforma condivisa riduce la duplicazione solo quando l'operatore può applicare i confini del tenant in modo coerente. Richiede modelli di policy, distribuzione a fasi, convalida della configurazione, log limitati al tenant e rollback testati. Senza questi controlli, un'unica console condivisa può trasformare un problema di isolamento in un problema di controllo degli accessi.
La progettazione della rete deve essere testata prima delle modifiche in produzione. I team possono utilizzare uno strumento di progettazione di subnet iPSK per modellare la segmentazione basata sull'identità, verificare l'allocazione delle subnet ed esporre in anticipo i conflitti di indirizzi o di policy.
Paga per l'isolamento fisico quando l'attività richiede un confine fisico. Non pagare solo perché il team di progettazione non ne ha creato uno logico e affidabile.
La risposta corretta è spesso ibrida. Mantieni il traffico clinico, di pagamento, di gestione dell'edificio o aziendale su un percorso dedicato strettamente controllato. Utilizza una rete condivisa e consapevole dei tenant per ospiti, residenti, appaltatori e altre popolazioni variabili. Questa allocazione colloca l'isolamento dove un guasto comporta conseguenze commerciali, normative o di sicurezza, mentre l'infrastruttura condivisa gestisce la domanda che trae vantaggio dalla scalabilità.
Scenari reali per IT aziendale e operatori di rete
La decisione sull'architettura diventa più chiara quando vengono definiti il proprietario, l'utente e l'impatto dei guasti. Una rete per un'unica organizzazione non è automaticamente un problema single-tenant, e una rete al servizio di molte persone non è automaticamente un problema multi-tenant.
Scenario uno: un campus aziendale da 5.000 posti
Un grande campus aziendale con rigidi requisiti di residenza dei dati dovrebbe optare per impostazione predefinita per il single-tenant per i servizi principali. Il fattore decisivo non è il numero di dipendenti. È la necessità di allineare i confini fisici, amministrativi e di audit.
Controller dedicati, servizi di autenticazione, accesso di gestione e percorsi di traffico rendono più semplice dimostrare la proprietà. I team di sicurezza possono limitare l'accesso amministratore al personale dell'organizzazione, definire un singolo processo di modifica e indagare sugli incidenti senza filtrare l'attività non correlata dei tenant.
L'accesso ospiti può comunque utilizzare un servizio logico separato. La rete aziendale principale dei dipendenti non deve dipendere dallo stesso percorso di policy di visitatori temporanei, collaboratori esterni o partecipanti a eventi.
Scenario due: un gruppo alberghiero multi-sito
Un gruppo alberghiero che gestisce proprietà sotto un unico marchio dovrebbe generalmente scegliere il modello multi tenant. Un centro operativo di rete centrale ha bisogno di onboarding coerente, policy del Captive Portal, reportistica e gestione degli incidenti in hotel, ristoranti e location. Duplicare l'intero patrimonio di gestione in ogni proprietà renderebbe la standardizzazione più difficile, non più sicura.
Il confine deve comunque esistere a livello di proprietà, ospite, personale e servizio. I dispositivi degli ospiti non devono raggiungere i sistemi dei punti vendita. Le identità del personale non devono ereditare i permessi degli ospiti. Il team di una proprietà deve vedere le informazioni necessarie per il proprio lavoro senza ricevere un accesso illimitato a ogni sito.
Il compromesso è chiaro. Il controllo centralizzato vince, a condizione che l'operatore possa applicare un'amministrazione e una policy di traffico consapevoli dei tenant.
Scenario tre: BTR nel Regno Unito e alloggi per studenti
Nel build-to-rent e negli alloggi per studenti appositamente realizzati, un modello multi-tenant ibrido di solito si rivela vincente. I residenti si aspettano una privacy a livello di appartamento o di stanza, ma l'operatore beneficia di un'unica rete fisica a livello di proprietà, di un unico modello di supporto e di una gestione centralizzata dei servizi.
I dati relativi agli alloggi per studenti nel Regno Unito mostrano che il 93% dei locatori intervistati in Scozia utilizza un unico contratto di locazione, mentre il 7% utilizza contratti di locazione multipli. Ciò suggerisce che la semplicità amministrativa influenza ancora i modelli operativi. (UK student housing evidence)
In questi edifici la connettività è sempre più un servizio fornito dall'operatore anziché un contratto sottoscritto da ciascun residente. Nella National Student Accommodation Survey 2026 di Save the Student, l'80% degli studenti ha dichiarato che l'affitto copriva almeno un servizio aggiuntivo e il 48% che la banda larga era inclusa, dietro solo ad acqua (63%), elettricità (61%) e gas (54%). Erogarla in modo affidabile è la parte più difficile: l'indagine Jisc 2024/25 su 15.398 studenti dell'istruzione superiore britannica ha rilevato che il 60% ha segnalato problemi di connettività WiFi dentro o fuori dal campus. (Save the Student, National Student Accommodation Survey 2026; Jisc Digital Experience Insights 2024/25)
La rete deve quindi offrire un'esperienza privata senza trasformare ogni residente in un progetto infrastrutturale a sé stante. L'accesso basato sull'identità, la policy per unità, la fatturazione semplice e la revoca immediata contano più dell'etichetta dell'architettura.
Garantire l'isolamento dei tenant senza duplicare la rete
Il networking moderno basato sull'identità offre una terza opzione tra un singolo stack fisico per tenant e una rete condivisa non controllata. L'operatore condivide l'infrastruttura, quindi associa l'accesso all'identità di un singolo, di un'unità, di una stanza, di un reparto o di un dispositivo.
La tecnologia iPSK è un punto di partenza pratico per ambienti residenziali e con dispositivi misti. Invece di rilasciare un'unica password condivisa a un intero edificio, l'operatore assegna chiavi private distinte e le mappa su un contesto di policy. Una chiave può identificare un appartamento, una stanza, un residente, un gruppo di dispositivi o una classe di servizio, a seconda dei requisiti operativi.
Costruire il control plane a livelli
- Mappare l'identità all'accesso. Utilizza gli attributi RADIUS, i gruppi di directory o un servizio di identità gestito per associare un utente o un dispositivo alla policy tenant corretta.
- Applicare controlli basati sui ruoli. Il personale, i residenti, gli ospiti, i collaboratori esterni e i sistemi dell'edificio devono ricevere autorizzazioni diverse. I team che valutano questo livello possono consultare il software di controllo degli accessi basato sui ruoli per una spiegazione più ampia della policy per ruolo.
- Separare il traffico. Utilizza VLAN, VRF, regole di firewall e policy di servizio per bloccare i movimenti laterali tra i tenant e proteggere i sistemi operativi.
- Automatizzare gli eventi del ciclo di vita. Fornisci l'accesso quando un residente o un dipendente viene approvato e revocalo quando i record della directory o del sistema di gestione della proprietà cambiano.
- Delimitare la telemetria. Il monitoraggio centrale deve fornire agli operatori dati utili sullo stato di salute senza esporre le informazioni sull'identità o sulla sessione di un tenant a un altro tenant.
L'SSO tramite Microsoft Entra ID o Okta può vincolare l'accesso aziendale alla governance delle identità stabilita. Funziona bene per il personale e gli utenti gestiti. L'iPSK rimane utile per residenti, visitatori, dispositivi legacy e apparecchiature che non possono completare un moderno flusso di autenticazione enterprise.
La piattaforma di rete basata sull'identità di Purple è un esempio di approccio basato sul piano di controllo che supporta l'accesso specifico per l'inquilino su un'infrastruttura condivisa, inclusi iPSK e integrazioni con provider di identità aziendali. Il suo valore in questa architettura non risiede nella presenza di un altro SSID, bensì nella capacità di collegare identità, policy, onboarding e revoca senza richiedere una rete fisica separata per ogni occupante.
Il design ha comunque bisogno di essere testato. Verificate che una credenziale non possa superare la policy prevista, che l'onboarding dei dispositivi non aggiri la segmentazione, che gli amministratori abbiano autorizzazioni limitate al tenant e che la revoca raggiunga le sessioni attive. Una rete fisica condivisa può offrire un'esperienza di tenant privato, ma solo se l'operatore tratta l'identità e le policy come infrastruttura di produzione.
Quale architettura scegliere e quando
Utilizza il single tenant quando l'organizzazione ha bisogno di un confine fisico dedicato, e non semplicemente di un login separato. Il settore sanitario regolamentato, gli ambienti di pagamento, la difesa e i carichi di lavoro aziendali ad alta sensibilità dovrebbero partire da qui per i servizi principali. L'architettura semplifica la raccolta delle prove e riduce le dipendenze condivise, anche se richiede comunque una gestione rigorosa di patch, monitoraggio e identità.
Scegliete il multi-tenant quando l'operatore serve molti clienti, occupanti, stanze, dipartimenti o proprietà e il servizio dipende da una distribuzione ripetibile. Il settore alberghiero, gli alloggi per studenti, il build-to-rent (BTR), i servizi gestiti e gli spazi di lavoro condivisi traggono solitamente maggiori vantaggi da operazioni centralizzate piuttosto che dalla duplicazione dell'hardware. La condizione essenziale è una rigorosa policy orientata al tenant, non uno standard di sicurezza approssimativo.
Utilizza l'approccio ibrido quando una singola sede ospita sia servizi interni ad alta sensibilità sia grandi volumi di utenti temporanei o residenziali.
Matrice di raccomandazione dell'architettura
| Scenario | Modello consigliato | Perché |
|---|---|---|
| Core aziendale regolamentato, sistemi clinici sanitari o traffico di pagamento | Single tenant | Il limite fisico e di audit deve corrispondere al limite di controllo dell'organizzazione |
| Fornitore SaaS o operatore di servizi gestiti che serve molti clienti | Multi tenant | L'infrastruttura condivisa supporta policy ripetibili, operazioni centralizzate ed espansione efficiente |
| Gruppo alberghiero con servizi per gli ospiti centralizzati | Multi tenant | Un unico modello operativo supporta un'identità coerente, il supporto e l'erogazione dei servizi in tutte le proprietà |
| BTR, alloggi per studenti o spazi di lavoro flessibili | Ibrido multi tenant | L'infrastruttura condivisa funziona con identità, policy, fatturazione e revoca per singolo occupante |
| Sito aziendale con reti dipendenti e ospiti | Ibrido | Mantiene il traffico aziendale sensibile strettamente controllato applicando al contempo un accesso ospiti basato sul tenant |
| Ambiente con ripetuti incidenti di noisy-neighbour o rilievi di audit | Rivalutare, quindi isolare i servizi interessati | Il limite attuale sta fallendo, indipendentemente dall'etichetta dell'architettura |
Le decisioni di migrazione dovrebbero seguire la stessa logica. Create un inventario delle classi di traffico, delle identità, dei tipi di dispositivi, dei ruoli di gestione e dei domini di errore prima di selezionare una piattaforma. I segnali di allarme includono una visibilità cross-tenant non spiegata, policy incoerenti tra i siti, revoca lenta degli accessi, team di supporto con un raggio d'azione amministrativo eccessivo e abbandono dei tenant causato da controlli mancanti o ritardi nelle funzionalità.
Poni una domanda prima di firmare il progetto: chi possiede il confine di rete e ha bisogno di hardware dedicato o di una policy dedicata?
La sintesi del documento di indirizzo è semplice:
- Scegli il single tenant quando l'isolamento fisico è un requisito aziendale o di conformità.
- Scegli il multi tenant quando la scalabilità dipende da un'infrastruttura condivisa e da controlli di identità maturi.
- Scegli l'ibrido quando coesistono traffico core sensibile e accesso condiviso ad alto volume.
Purple fornisce networking basato sull'identità per edifici condivisi, inclusi controlli di accesso a livello di tenant e separazione basata su iPSK su infrastruttura comune. Visita Purple per valutare se il suo approccio si adatta al tuo studentato, BTR, settore alberghiero, sanitario o al design della rete WiFi per ospiti aziendali, quindi testa i confini con le tue policy di identità, revoca e traffico.
