Molti direttori IT ereditano la stessa storia di rete. Un hotel ha un circuito in fibra solido e regole di firewall sensate. La struttura successiva si basa su un provider diverso, uno standard di router diverso e una VPN che nessuno vuole toccare prima di un fine settimana festivo. Nel retail, spesso è peggio. Nuovi negozi aprono rapidamente, le app cloud si moltiplicano e la rete finisce per essere ricucita insieme da MPLS, banda larga, soluzioni locali e troppe eccezioni.
Questo modello si rompe quando il WiFi per gli ospiti, l'accesso del personale, le app cloud e le policy di sicurezza devono funzionare in modo coerente in ogni sede. La WAN come servizio (WAN-as-a-Service) rappresenta il passaggio dal gestire ogni filiale come un piccolo progetto di networking al fruire della connettività geografica come servizio gestito ed erogato via cloud. Per le organizzazioni distribuite, si tratta meno di una moda passeggera e più di una necessità operativa.
Superare i problemi delle reti legacy
Un gruppo alberghiero in crescita di solito non fallisce perché manca l'accesso a internet. Fatica perché ogni sito si comporta in modo diverso.
Una struttura ha una connettività affidabile ma una scarsa segmentazione tra il traffico degli ospiti e quello del personale. Un'altra ha un buon WiFi per gli ospiti ma un accesso lento al PMS cloud o agli strumenti di collaborazione. Una terza sede ha bisogno di modifiche urgenti per supportare una ristrutturazione o un evento temporaneo, ma la rete dipende da apparecchiature locali, tempi di consegna dei carrier e da qualcuno che si ricordi come l'ultimo fornitore ha configurato la VPN.
Questo è il punto dolente principale. Non la larghezza di banda in sé. L'incoerenza.
Per le catene di negozi, il modello è simile. I sistemi POS, l'inventario, la segnaletica digitale, i dispositivi del personale e l'accesso degli ospiti competono tutti su una rete di filiale che non è mai stata progettata per essere gestita centralmente su scala. I team IT spendono troppo tempo a risolvere problemi locali e troppo poco a migliorare l'intera infrastruttura.
Perché il modello sta cambiando
Il mercato si è evoluto perché le aziende desiderano che il networking si comporti più come un'infrastruttura cloud. Il mercato globale NaaS è stato valutato a 11,5 miliardi di USD nel 2022, è cresciuto a 14,6 miliardi di USD nel 2023 e si prevede che raggiungerà i 115,5 miliardi di USD entro il 2032, secondo le statistiche sul mercato del network as a service di Market.us .
Questa crescita è importante perché riflette una decisione più ampia presa dai team IT delle imprese. Non vogliono gestire ogni filiale come una serie di apparati, circuiti ed eccezioni. Desiderano una policy centrale, un roll-out più pulito e un'erogazione del servizio prevedibile.
Regola pratica: se l'aggiunta di una nuova sede significa ancora ricostruire la sicurezza, il routing e le policy di accesso sito per sito, il vostro modello WAN sta frenando il business.
Cosa migliora per primo
Quando le organizzazioni si allontanano dal networking di filiale legacy, i primi vantaggi sono solitamente operativi:
- Standardizzazione del sito più rapida perché la policy risiede in una piattaforma centrale, non nelle particolarità dei dispositivi locali.
- Risoluzione dei problemi più pulita poiché i team possono vedere i percorsi del traffico e lo stato del servizio in tutte le sedi.
- Migliore esperienza utente sia per il personale che per gli ospiti, perché la connettività smette di dipendere da come ogni sito è stato costruito anni fa.
Il punto chiave non è che la WANaaS faccia sparire il networking. Non è così. Cambia il luogo in cui risiede la complessità e chi deve gestirla.
Declassificare la WAN as a Service
Se desideri la spiegazione più semplice, la WAN as a Service applica il modello di consumo cloud alla WAN. È lo stesso cambiamento di mentalità che molti team hanno già accettato con l'e-mail, l'identità e l'infrastruttura. Smetti di possedere ogni parte mobile in ogni sito e inizi a consumare un servizio che gestisce il trasporto, la logica di instradamento, la visibilità e spesso la sicurezza da un piano di controllo centrale.
Il cambiamento architetturale fondamentale
Il design tradizionale della WAN lega strettamente le prestazioni e la policy all'hardware della filiale. La WANaaS cambia questo aspetto utilizzando un modello definito dal software. Le piattaforme WANaaS utilizzano il software-defined networking per separare i piani di controllo e dei dati, consentendo l'instradamento dinamico del traffico attraverso MPLS, banda larga e 5G in base alle condizioni di rete in tempo reale, come descritto nella panoramica di Red River sulla WAN as a Service .
In termini pratici, ciò significa che la filiale non deve più prendere ogni decisione in modo isolato. La policy viene definita centralmente e quindi applicata in modo coerente. Il servizio può indirizzare il traffico in base alle esigenze dell'applicazione, alla qualità del percorso, ai requisiti di resilienza o alle regole aziendali.
Per un direttore IT, la domanda utile non è se l'architettura sia elegante. È se il traffico giusto riceve il trattamento giusto senza ottimizzazioni manuali in ogni sede.
Cosa fanno effettivamente le parti in movimento
Tre componenti sono fondamentali:
L'underlay di accesso
Questa è la connettività fisica che già conosci. Fibra, banda larga, backup mobile o un mix. La WANaaS non elimina la necessità di circuiti. Li rende più facili da usare insieme.L'overlay definito dal software
Qui risiedono la selezione del percorso, l'indirizzamento del traffico, la segmentazione e la logica di resilienza. È ciò che consente a un sito di utilizzare più di un tipo di connessione senza creare confusione.Lo strato di gestione in cloud
Questa è la parte che molti team apprezzano di più. Offre visibilità centrale, policy centralizzate e un modello di servizio che scala in modo più lineare rispetto alla gestione per singola filiale.
Una prospettiva esterna utile su questo modello operativo è Optimising business networks with WaaS , che inquadra il passaggio da una progettazione WAN rigida e incentrata sul sito a una gestione basata sul servizio. Per una panoramica più ampia sul modello di networking fornito via cloud, vale la pena leggere anche la guida di Purple al networking as a service .
Considera il WANaaS come un modello operativo, non come la semplice sostituzione di un circuito. Se ti limiti a cambiare il trasporto mantenendo gli stessi processi manuali, non otterrai il vantaggio principale.
Cosa funziona e cosa no
Ciò che funziona è l'utilizzo di WANaaS per semplificare il controllo su molteplici sedi. Un gruppo alberghiero può dare la priorità al traffico PMS, ai pagamenti, alla voce e alla collaborazione del personale in modo centralizzato, mantenendo isolato l'accesso degli ospiti. Un rivenditore può implementare la stessa policy di filiale ovunque, senza dover ricostruire il design della rete punto vendita per punto vendita.
Ciò che non funziona è aspettarsi che il WANaaS risolva da solo una progettazione scadente delle applicazioni, controlli di identità deboli o standard LAN non coerenti. Migliora la WAN, ma non cancella ogni problema a monte o a valle.
Confronto tra WANaaS, MPLS e SD-WAN
Un gruppo alberghiero che apre tre strutture ristrutturate in un trimestre non ha bisogno di un altro progetto di design per le filiali. Ha bisogno che ogni sito sia online rapidamente, con pagamenti, PMS, app per lo staff e WiFi per gli ospiti che funzionino allo stesso modo fin dal primo giorno. Questo è il contesto per confrontare il WANaaS con MPLS e SD-WAN.
La maggior parte dei team IT non sceglie partendo da un foglio bianco. Solitamente lavorano con un mix di MPLS, SD-WAN autogestita, collegamenti internet tradizionali e appliance di sicurezza per filiali aggiunte nel corso di diversi anni.
Anche i modelli di traffico sono cambiati. Oggi le aziende inviano molto più traffico direttamente al cloud e alle piattaforme SaaS rispetto a quando il design WAN hub-and-spoke era lo standard. Come evidenziato nel report sullo stato della WAN aziendale , questo cambiamento è andato di pari passo con una più ampia adozione di SASE. Una volta che il traffico delle filiali si dirige direttamente verso Microsoft 365, piattaforme PMS in cloud, strumenti di collaborazione e servizi di identità, diventa più difficile giustificare il reindirizzamento di tutto attraverso un punto centrale.
Confronto delle architetture di rete
| Criterio | MPLS | SD-WAN Fai-da-te | WAN as a Service |
|---|---|---|---|
| Allineamento al cloud | Spesso costruito attorno a un trasporto centrale | Migliore adattamento al cloud se progettato bene | Progettato attorno a policy fornite via cloud e consumo di servizi |
| Proprietà operativa | Forte dipendenza dal provider e dal contratto, oltre alla complessità delle filiali locali | Elevata responsabilità interna per progettazione, hardware e ciclo di vita | Maggiore responsabilità in capo al fornitore di servizi e al piano di gestione cloud |
| Agilità per nuovi siti | In genere più lenta e meno flessibile | Più flessibile di MPLS, ma la qualità del rollout dipende dal tuo team e dai tuoi strumenti | Forte idoneità per rollout standardizzati di filiali in sedi distribuite |
| Modello di sicurezza | Storicamente separato dal trasporto | Può essere forte, ma spesso richiede integrazioni multiple | Comunemente costruito con controlli di sicurezza integrati e policy centralizzata |
| Onere hardware | Significativa dipendenza da filiali ed edge | Ancora sostanziale in molte distribuzioni | Minore complessità on-prem nei modelli cloud-native |
| Migliore idoneità | Infrastrutture stabili con traffico prevedibile e lunghi cicli di pianificazione | Team che desiderano il controllo e possono assorbire i costi operativi generali | Organizzazioni che desiderano agilità gestita, policy centralizzata e una scalabilità più snella |
Dove MPLS ha ancora un ruolo
MPLS è ancora adatto ad alcuni ambienti. Se un'azienda dispone di siti altamente stabili, lunghi cicli di pianificazione, solide relazioni con i vettori e un set limitato di applicazioni prevedibili, può rimanere utile.
Il problema non è che MPLS abbia smesso di funzionare. Il problema è che molte realtà dell'ospitalità e del retail sono cambiate intorno ad esso. I nuovi siti aprono più rapidamente. Un numero maggiore di servizi è ospitato in cloud. Le aspettative degli ospiti per la qualità del WiFi sono più elevate. Il personale si autentica sempre più tramite piattaforme di identità cloud e queste decisioni di identità richiedono che la rete della filiale risponda in modo rapido e coerente.
Dove l'SD-WAN fai-da-te aiuta e dove penalizza
L'SD-WAN fai-da-te ha colmato un divario reale. Ha offerto ai team di rete la selezione del percorso, la flessibilità di trasporto e un migliore utilizzo dei circuiti a banda larga e internet. Per le organizzazioni con una forte progettazione interna, può valere ancora la pena di mantenere tale controllo.
Il compromesso, tuttavia, è il peso operativo. Il tuo team deve comunque scegliere i vendor, mantenere l'hardware edge, aggiornare il software, integrare firewall e gateway web sicuri, risolvere le eccezioni delle filiali e mantenere gli standard coerenti in ogni sede. In una catena di negozi o in un gruppo alberghiero, il numero di filiali cresce solitamente più velocemente del team di rete.
Se stai valutando se questo controllo extra valga l'onere del supporto, la guida di Purple sui vantaggi di SD-WAN per le aziende distribuite rappresenta un utile punto di riferimento.
L'MPLS sacrifica la flessibilità a favore della prevedibilità. L'SD-WAN fai-da-te sacrifica la flessibilità a favore dell'impegno ingegneristico. Il WANaaS è progettato per le organizzazioni che desiderano una policy centrale e un'attivazione più rapida senza dover gestire direttamente ogni componente dello stack.
Scegliere il modello ideale per il proprio team
La decisione fondamentale non riguarda tanto l'elenco delle funzionalità, quanto piuttosto il modello operativo.
Un team di ingegneria di rete competente potrebbe preferire progettare la propria SD-WAN, lo stack di sicurezza e le integrazioni cloud. Questa scelta può funzionare se l'azienda accetta l'onere del ciclo di vita del sistema. Molti gruppi alberghieri, retailer e gestori di spazi polifunzionali desiderano un risultato diverso. Vogliono una segmentazione coerente, un'attivazione più rapida delle sedi e un minor numero di eccezioni specifiche per ogni filiale.
Questo aspetto diventa ancora più cruciale quando l'accesso WiFi è legato all'identità. Se l'accesso degli ospiti utilizza OpenRoaming e l'accesso del personale si affida a credenziali rilasciate da Microsoft Entra ID o Okta, la WAN non può essere trattata come un livello infrastrutturale separato. La policy deve estendersi dalla WAN fino all'edge della sede, in modo che il traffico degli ospiti rimanga isolato, i dispositivi del personale ereditino l'accesso corretto e i controlli di sicurezza cloud visualizzino il contesto utente e dispositivo necessario. Il WANaaS si adatta a questo modello molto meglio rispetto a un mosaico di circuiti e appliance locali, perché offre un modo più lineare per applicare le policy a tutte le sedi, estendendole poi all'esperienza WiFi utilizzata da ospiti e personale.
Integrare la sicurezza nel fabric WAN
Il vecchio modello per le filiali considerava la sicurezza come un livello da aggiungere dopo aver stabilito la connettività. Questo approccio crea disallineamenti. Una sede riceve una policy firewall leggermente diversa. Un'altra ritarda l'aggiornamento dell'hardware. Una terza presenta eccezioni che nessuno documenta correttamente. Con il tempo, la WAN risulta connessa, ma non protetta in modo coerente.
Il moderno WANaaS cambia questo scenario integrando la sicurezza direttamente nel fabric del servizio.
Secondo il whitepaper di Cloudflare sulla WAN as a Service, il moderno WANaaS opera come una soluzione cloud-native che integra firewall, mitigazione DDoS e protocolli zero-trust a ogni livello, eliminando gran parte dell'onere del ciclo di vita dell'hardware e fornendo una postura di sicurezza unificata da un'unica dashboard.
Perché questo è importante negli ambienti multi-sede
Un hotel, un centro commerciale o una struttura sanitaria non hanno solo bisogno di un "internet sicuro". Hanno bisogno che i diversi tipi di traffico siano trattati in modo differente.
Il traffico degli ospiti deve rimanere isolato dai sistemi operativi. I dispositivi del personale devono ereditare le policy in base all'identità e al ruolo. I sistemi di pagamento, gli strumenti di amministrazione, l'IoT e i servizi dei tenant terzi hanno spesso bisogno di canali dedicati. Se tale segmentazione dipende dalla configurazione manuale dei firewall delle singole filiali, la coerenza non durerà a lungo.
Il WANaaS migliora questo aspetto in due modi:
- La policy è centralizzata, in modo che ogni sede non diventi un'isola di sicurezza a sé stante.
- I servizi di sicurezza sono integrati anziché essere aggiunti successivamente attraverso una catena di prodotti separati e passaggi manuali.
Come si presenta una buona progettazione della sicurezza
In pratica, una solida sicurezza WANaaS include solitamente:
- Decisioni di accesso basate sull'identità, in modo che gli utenti e i dispositivi non ottengano un accesso esteso solo perché si trovano sulla subnet corretta.
- Segmentazione del traffico che tiene separati ospiti, personale, sistemi operativi e tenant.
- Ispezione e monitoraggio centralizzati, in modo che i team possano applicare la policy in modo uniforme e indagare sui problemi senza dover accedere singolarmente a ogni filiale.
Questa architettura è particolarmente utile nelle sedi con un mix di utenti attendibili e non attendibili. Gli hotel e i centri commerciali sono esempi ovvi, ma gli alloggi per studenti, le cliniche e gli edifici residenziali affrontano lo stesso problema. Un unico sito fisico può contenere diverse zone di attendibilità.
La filiale non dovrebbe decidere la sicurezza solo in base alla posizione. Dovrebbe applicare la policy in base a identità, ruolo e tipo di traffico.
Il compromesso da monitorare
C'è un compromesso. Quando si sposta un maggiore controllo sulla piattaforma cloud di un provider, il modello di visibilità e risoluzione dei problemi cambia. Il tuo team deve comprendere gli strumenti, i log e il flusso di lavoro delle policy del provider. È uno scambio equo se il piano di gestione è maturo e i tuoi processi si adattano ad esso. È un cattivo scambio se si acquista il WANaaS e si insiste ancora a gestire ogni sito come un vecchio parco firewall di filiale.
Collegare il WANaaS con l'Accesso WiFi Basato sull'Identità
Un ospite entra in un hotel, si connette al WiFi tramite OpenRoaming, apre un'app fedeltà e si aspetta che funzioni immediatamente. Allo stesso tempo, un dipendente della reception accede su un dispositivo dello staff utilizzando un certificato collegato a Entra ID o Okta. Se entrambe le sessioni atterrano sulla stessa rete locale con solo un'etichetta VLAN a separarle, la WAN ha pochissimo contesto. Vede il traffico. Non vede l'intenzione.
Questo divario è importante nelle sedi distribuite. Hotel, complessi commerciali, cliniche e proprietà a uso misto spesso investono in una migliore policy WAN, per poi lasciare le decisioni di accesso WiFi isolate nella filiale. Il risultato è noto. Gli ospiti ottengono un flusso di onboarding decente, il personale ottiene un metodo di autenticazione separato e l'IT centrale deve comunque mantenere ampie zone di rete perché l'identità viene persa prima che il traffico raggiunga il motore delle policy WAN.
Il design migliore consiste nel trasportare l'identità dal momento in cui un dispositivo si connette al WiFi all'interno del modello di policy utilizzato nell'intera rete WAN e nello stack di sicurezza cloud. Purple si adatta perfettamente a questo modello perché supporta l'accesso guest senza password tramite OpenRoaming e Passpoint , oltre all'accesso del personale basato su certificati collegato a Entra ID, Okta e Google Workspace. La piattaforma WiFi classifica prima l'utente. La WANaaS utilizza quindi tale classificazione per applicare il percorso, l'ispezione e i controlli di accesso corretti.
Come estendere l'identità al perimetro WAN
In pratica, il flusso di lavoro dovrebbe essere il seguente:
Autenticare l'utente su WiFi
- Gli utenti guest accedono tramite OpenRoaming o Passpoint.
- I membri del personale si autenticano con un certificato o un metodo basato su directory collegato a Entra ID o Okta.
Assegnare un ruolo a livello di accesso
- Guest
- Dipendente
- Collaboratore esterno
- IoT o dispositivo condiviso
Passare tale ruolo nella policy di rete
- Mappare il ruolo autenticato a una VLAN, SGT, segmento VXLAN o tag di policy equivalente, a seconda dello stack WLAN e WANaaS.
- Mantenere la mappatura coerente in ogni sede.
Applicare la policy WANaaS in base all'identità, non solo per SSID
- Il traffico guest viene instradato verso il breakout internet locale con filtraggio web e policy sulla larghezza di banda.
- Il traffico del personale viene indirizzato ad applicazioni private, controlli SaaS e punti di ispezione definiti per l'accesso dei dipendenti.
- I dispositivi operativi seguono un percorso separato con restrizioni est-ovest più stringenti.
Registrare centralmente l'identità e le decisioni sulle policy
- Il service desk deve essere in grado di rispondere rapidamente a tre domande: Chi si è connesso? Quale ruolo è stato assegnato? Quale policy WAN è stata attivata?
Questo è l'anello mancante in molti progetti WANaaS.
Un esempio pratico di policy
Un guest OpenRoaming non dovrebbe semplicemente atterrare sulla rete "WiFi guest". Questa etichetta è troppo vaga per le operazioni moderne. La sessione dovrebbe essere mappata su un oggetto di policy definito nella struttura WAN, come ad esempio:
- Origine identità: Autenticazione Purple OpenRoaming
- Ruolo: Guest
- Segmento di rete: Solo internet guest
- Policy WAN: Breakout locale, filtraggio DNS, limite di larghezza di banda, blocco dell'accesso agli intervalli privati RFC1918, nessun movimento laterale verso i sistemi della sede
- Registrazione: Inizio sessione, sede, classe di dispositivo, policy applicata
Un membro del personale su un tablet gestito dovrebbe seguire un percorso diverso:
- Origine identità: Autenticazione basata su certificato Entra ID o Okta tramite Purple
- Ruolo: Personale
- Segmento di rete: Accesso sicuro per i dipendenti
- WAN policy: Instradare verso le app aziendali, consentire i SaaS approvati, ispezionare il traffico secondo la policy aziendale, bloccare l'accesso ai segmenti guest e IoT
- Logging: Identità dell'utente, comportamento del dispositivo se disponibile, eventi di accesso alle applicazioni, modifiche alle policy
Questo è il modo in cui la segmentazione a livello WAN raggiunge l'edge WiFi in modo utilizzabile. La WLAN decide chi è l'utente. La piattaforma WANaaS decide cosa quell'identità è autorizzata a fare tra i vari siti, servizi cloud e breakout internet.
Cosa i team IT devono standardizzare
La parte difficile raramente è l'autenticazione in sé. La parte difficile è la coerenza delle policy.
Se un hotel mappa il personale sulla VLAN 20, un altro sulla VLAN 40 e un terzo si affida a un oggetto firewall locale che nessuno ha documentato, il provider WANaaS non può imporre un modello pulito basato sull'identità in tutta la struttura. Le definizioni standard dei ruoli contano più di una perfetta uniformità dei circuiti. Una catena di vendita al dettaglio con 300 negozi è solitamente servita meglio da quattro o cinque classi di identità ben gestite che da dozzine di eccezioni specifiche per sito.
I team che valutano l'architettura delle filiali spesso arrivano a questo punto quando confrontano la policy SD-WAN locale con i controlli WAN gestiti in cloud. Questi SD-WAN use cases for distributed venues sono un utile riferimento per capire come le policy applicative e di accesso si sviluppano a livello di sito.
Il compromesso da pianificare
L'applicazione delle policy basata sull'identità migliora il controllo, ma alza anche l'asticella della qualità per l'integrazione. WLAN, identity provider, NAC o policy engine e WANaaS devono concordare sui nomi dei ruoli, sui tag delle policy e sulla gestione degli errori. Se Entra ID non è disponibile, cosa succede al provisioning del personale? Se OpenRoaming ha successo ma il tag della policy non riesce a sincronizzarsi, l'utente cade in una policy di attesa limitata o ottiene per errore un ampio accesso a Internet?
I buoni progetti rispondono a queste domande fin dall'inizio. Definiscono una policy di fallback, mantengono semplice la mappatura dei ruoli e testano il provisioning dal punto di vista dell'utente, non solo dalla console di amministrazione.
Se Purple identifica l'utente e la piattaforma WANaaS non può consumare tale identità in modo coerente, avrai un onboarding WiFi migliore ma non un controllo di rete migliore.
Ecco perché l'accesso WiFi basato sull'identità dovrebbe essere progettato come parte dell'architettura WAN, non aggiunto in un secondo momento come funzionalità di filiale.
WANaaS in azione nei tuoi spazi aziendali
L'architettura è importante per ciò che risolve sul campo. Diversi settori affrontano problemi diversi, ma il modello è coerente. Le sedi distribuite hanno bisogno di un controllo centrale senza appiattire ogni requisito locale.
Hospitality
Un gruppo alberghiero spesso desidera tre cose contemporaneamente. Un onboarding degli ospiti fluido, un accesso sicuro per il personale e prestazioni costanti delle applicazioni in tutte le strutture.
Con la WANaaS, il gruppo può applicare un unico modello di routing e segmentazione in tutti gli hotel, adattandosi al contempo alla disponibilità dei circuiti locali. Il traffico degli ospiti si scollega in modo pulito, il traffico del personale raggiunge i sistemi aziendali in modo sicuro e l'IT centrale non deve sintonizzare ogni sito separatamente. Se state valutando dove i modelli SD-WAN e WAN gestiti dal cloud si adattano a livello operativo, questi casi d'uso SD-WAN per sedi distribuite forniscono un contesto utile.
Retail
I negozi di vendita al dettaglio puniscono rapidamente le reti deboli. Il traffico dei pagamenti non può aspettare che la navigazione degli ospiti si calmi. Segnaletica digitale, app di fidelizzazione, dispositivi palmari e strumenti di inventario in cloud richiedono tutti un trattamento prevedibile.
Ciò che funziona in questo caso è una policy attenta alle applicazioni combinata con una segmentazione rigorosa. La WANaaS può dare priorità al traffico critico per l'azienda, preservando al contempo un'esperienza ospite utilizzabile. Ciò che non funziona è dare a ogni negozio un ampio accesso a Internet sperando che il kit locale mantenga le cose in ordine.
Sanità
Le cliniche e i siti ambulatoriali hanno bisogno di qualcosa di più della semplice raggiungibilità di Internet. Hanno bisogno di un accesso affidabile alle applicazioni principali, di una netta separazione tra traffico clinico e non clinico e di una supervisione operativa più semplice.
Un modello WANaaS è utile quando le strutture sanitarie sono distribuite su molti siti più piccoli con una presenza IT locale limitata. I team centrali possono standardizzare le policy, ridurre la complessità delle filiali ed evitare di trasformare ogni clinica in un progetto unico.
Residenziale e multi-tenant
Le proprietà build-to-rent, gli alloggi per studenti e gli immobili a uso misto sono difficili per la mentalità tradizionale delle filiali, perché un singolo edificio può comportarsi come molte reti separate. I residenti desiderano un'esperienza simile a quella di casa. Il personale ha bisogno di un accesso gestito. I sistemi condivisi e i dispositivi legacy richiedono comunque un controllo.
Un buon design WANaaS supporta l'isolamento per tenant, confini di accesso chiari e un'amministrazione centrale. La lezione importante è che questi ambienti non sono "solo progetti WiFi". Hanno bisogno che WAN, identità e segmentazione lavorino insieme.
Le reti per sedi più forti non si limitano a connettere i siti. Preservano un modello di fiducia coerente da una proprietà all'altra.
Pianificare la migrazione a WANaaS
Le migliori migrazioni WANaaS iniziano con l'analisi dei problemi aziendali, non con le demo dei prodotti. Se iniziate con la scheda delle funzionalità del fornitore, vi sfuggiranno i problemi operativi che contano davvero per la vostra infrastruttura.
Iniziare con l'infrastruttura già esistente
Controllate i siti in base alla criticità aziendale, al tipo di utente, al metodo di accesso e all'onere di supporto. Un hotel di punta, una piccola filiale retail e una clinica sanitaria possono trovarsi tutti sulla stessa WAN oggi, ma non avranno la stessa tolleranza per interruzioni, latenza o errori di policy.
Mappate ciò che accade realmente in ogni sede:
- Comportamento del traffico tra utenti ospiti, personale, operativo e di terze parti
- Percorsi di autenticazione per utenti, dispositivi e apparecchiature legacy
- Dipendenze delle filiali come firewall locali, VPN o passaggi gestiti dal provider
Definire il successo in termini operativi
Mantenete l'obiettivo pratico. I migliori piani di migrazione di solito definiscono il successo come un minor numero di eccezioni locali, un onboarding più semplice per le nuove sedi, una segmentazione più forte e un isolamento dei guasti più rapido.
Ponete domande dirette. Una nuova proprietà può ereditare il design di rete standard senza un progetto personalizzato? Le modifiche all'identità del personale possono confluire in modo pulito nella policy di accesso? Il traffico degli ospiti e quello operativo possono rimanere isolati senza la proliferazione di regole locali?
Scegliere il modello di servizio con attenzione
I provider WANaaS variano molto. Alcuni sono forti sulla flessibilità di trasporto ma deboli sull'integrazione dell'identità. Altri hanno solide strutture di sicurezza ma strumenti operativi complessi.
Prima di impegnarvi, verificate:
- Modello di policy. Può esprimere le zone di attendibilità e i tipi di utenti che gestite?
- Visibilità. Il vostro team riceverà dati di monitoraggio e risoluzione dei problemi utilizzabili?
- Integrazione. Può allinearsi in modo pulito con il vostro WLAN, gli identity provider e le applicazioni cloud?
- Metodo di implementazione. Il provider supporta un'adozione graduale senza forzare un passaggio rischioso?
Un breve progetto pilota su alcune sedi rappresentative di solito vi dice più di un workshop di vendita raffinato. Scegliete siti con diversi tipi di circuiti, diversi mix di utenti e almeno una complessa dipendenza legacy. Se il modello funziona lì, ha buone probabilità di scalare bene.
Se state esaminando come dovrebbero integrarsi tra loro il WiFi per gli ospiti, l'identità del personale e le policy WAN in hotel, negozi al dettaglio, strutture sanitarie o proprietà multi-tenant, Purple è un buon punto di partenza. Si concentra sull'accesso degli ospiti senza password, sulla connettività del personale basata sull'identità e sul controllo centrale delle policy, il che lo rende rilevante quando cercate di collegare le decisioni di accesso WiFi con un design WANaaS e zero-trust più ampio.
