Migrazione multi-sito di RADIUS: sequenziamento dei siti, dei punti di accesso e delle policy

È possibile migrare una struttura multi-sito a RADIUS in cloud in quattro fasi senza un giorno d'interruzione, affiancando i vecchi e i nuovi server. Ogni SSID elenca entrambi e ogni dispositivo riconosce il nuovo certificato server. Il passaggio definitivo di ciascun sito avviene sotto IEEE 802.1X con un test di uscita formale. Con Purple, il passaggio finale è di solito un'operazione completabile nel fine settimana.

Cosa cambia e cosa resta invariato in una migrazione RADIUS multi-sito?

Lo stato finale prevede un'unica policy RADIUS in cloud al servizio di ogni sito, in cui l'identità definisce la VLAN. RADIUS, definito in RFC 2865, è il protocollo utilizzato dai punti di accesso per chiedere a un server se un dispositivo può accedere. Il server accetta o rifiuta il dispositivo. Può anche restituire attributi come la VLAN, ovvero il segmento di rete su cui atterra il dispositivo.

Su una rete sicura, tale scambio avviene all'interno di IEEE 802.1X, lo standard per il controllo dell'accesso alla rete basato su porte. 802.1X veicola EAP (Extensible Authentication Protocol) tra il dispositivo, il punto di accesso e il server. EAP-TLS, definito in RFC 5216, autentica entrambe le parti mediante certificati. PEAP racchiude uno scambio di password all'interno di un tunnel TLS.

I cambiamenti riguardano quattro aspetti:

• Ogni punto di accesso o controller punta a un nuovo indirizzo server e a un nuovo segreto condiviso. RADIUS definisce tale dispositivo NAS (network access server).
• I dispositivi rilevano un nuovo certificato server durante l'handshake EAP.
• La policy legge i gruppi da Microsoft Entra ID, Okta o Google Workspace anziché da una directory locale.
• I log vengono trasferiti su una nuova console.

Gli elementi che rimangono invariati sono ancora più importanti. Si mantengono i punti di accesso, i nomi SSID, gli ID VLAN, i trunk degli switch e le zone firewall esistenti. Nessun utente deve modificare la password o accedere a una nuova rete.

Lo stesso approccio si applica a tutte e tre le tipologie di rete su Purple Access. Sulle reti aperte, molti Captive Portal autorizzano i dispositivi tramite RADIUS. Le reti sicure utilizzano EAP-TLS o PEAP. Sulle reti xPSK, RADIUS assegna a ciascun dispositivo o residente una propria chiave pre-condivisa. Questa guida prende in esame la rete sicura, poiché presenta il livello di rischio più elevato.

{"tone":"warning","title":"Il rischio principale: la trust del certificato server","text":"I dispositivi che utilizzano EAP-TLS o PEAP verificano il certificato del server RADIUS e molti riconoscono solo la CA del vecchio server. Distribuisci la nuova CA a ogni profilo dispositivo prima di migrare il primo sito, altrimenti i dispositivi non riusciranno a connettersi e continueranno a riprovare."}

Una volta risolta la questione della trust del certificato, il resto della migrazione consiste in attività di configurazione e periodi di osservazione.

Quali requisiti devono essere soddisfatti prima della fase 1?

Prima di creare qualsiasi policy devono essere verificate cinque condizioni. L'assenza di anche solo una di esse causerà problemi in una fase successiva.

Un inventario NAS completo

Elenchi ogni dispositivo che invia richieste al vecchio server. Ciò include access point, controller wireless, switch che eseguono 802.1X cablato e gateway VPN. Compili l'elenco a partire dall'elenco client RADIUS del vecchio server, non dal diagramma di rete. Se un NAS manca dall'inventario, non sarà possibile spegnere il vecchio server nella fase 4.

Una mappa delle policy, riga per riga

Annoti ogni regola applicata dal vecchio server, con la relativa condizione, il risultato e gli attributi restituiti. Le righe tipiche sono simili a questa: dal gruppo del personale alla VLAN del personale, dai fornitori a una VLAN con restrizioni, dai laptop aziendali tramite certificato alla VLAN aziendale. Prenda nota di quali attributi contengono la VLAN. La specifica RFC 3580 definisce il set standard: Tunnel-Type, Tunnel-Medium-Type e Tunnel-Private-Group-ID. Alcuni ambienti utilizzano invece attributi specifici del fornitore, che devono essere replicati esattamente.

Un piano per i certificati

Decida quale autorità di certificazione (CA) emetterà il nuovo certificato del server. Sui dispositivi gestiti, distribuisca tale CA tramite Microsoft Intune, Jamf o la sua piattaforma di gestione dei dispositivi mobili (MDM) prima di spostare qualsiasi sede. Per EAP-TLS, il nuovo server deve anche considerare attendibile la CA che ha emesso i certificati dei dispositivi.

Una fonte di identità leggibile dal nuovo server

Connetta il suo provider di identità e confermi che ogni gruppo presente nella mappa delle policy esista anche lì. Se un gruppo esiste solo sul vecchio server, lo ricrei prima nel provider di identità.

Raggiungibilità, responsabili e finestre di modifica

Ogni sede necessita di un percorso di rete verso il server cloud, utilizzando gli indirizzi e le porte specificati nella documentazione di onboarding di Purple. Designi un responsabile per ciascuna sede e concordi le finestre di modifica con i responsabili di sede. Annoti il criterio di attivazione del rollback prima di effettuare qualsiasi spostamento.

{"title":"Checklist per la migrazione RADIUS multisito","groups":[{"heading":"Prima della fase 1","items":[{"text":"Esportare l'elenco dei client RADIUS del vecchio server e riconciliarlo con l'inventario NAS","why":"Un NAS dimenticato blocca la dismissione"},{"text":"Mappare ogni regola di policy: condizione, risultato e attributi restituiti"},{"text":"Confermare che ogni gruppo di policy esista in Microsoft Entra ID, Okta o Google Workspace"},{"text":"Distribuire la CA del nuovo server ai dispositivi gestiti tramite MDM"},{"text":"Aprire i percorsi indicati nella documentazione di onboarding di Purple in ciascun sito"},{"text":"Nominare un responsabile e una finestra di modifica per sito, e concordare per iscritto il criterio di rollback"}]},{"heading":"Fase 1: creazione","items":[{"text":"Bloccare le modifiche alle policy sul vecchio server"},{"text":"Ricreare ogni riga di policy sul nuovo server"},{"text":"Testare un'identità per riga su entrambi i server e verificare che le risposte corrispondano"}]},{"heading":"Fasi 2 e 3: pilota e fasi successive","items":[{"text":"Registrare un tasso di rifiuto di riferimento per sito prima del passaggio"},{"text":"Aggiungere il nuovo server accanto a quello vecchio su ciascun SSID"},{"text":"Confermare che ogni classe di dispositivi si autentichi sul nuovo server"},{"text":"Mantenere ciascuna fase per un ciclo aziendale completo prima di passare alla successiva"}]},{"heading":"Fase 4: dismissione","items":[{"text":"Rimuovere il vecchio server da ogni SSID e NAS"},{"text":"Confermare zero richieste sul vecchio server per il periodo di inattività concordato"},{"text":"Esportare e conservare i log del vecchio server secondo la policy di conservazione"},{"text":"Disattivare i segreti condivisi usati con il vecchio server"},{"text":"Aggiornare il runbook e archiviare il verbale dei test di uscita di ciascun sito"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

Quali sono le 4 fasi, in ordine?

Il piano prevede quattro fasi. Ciascuna termina con un test di uscita superato o fallito. Nulla passa alla fase successiva finché il test non viene superato, evitando così un passaggio diretto rischioso.

{"kind":"timeline","direction":"lr","caption":"Un parco di 40 sedi a scopo illustrativo: quattro fasi, ciascuna conclusa da un test di uscita","alt":"Cronologia che mostra la preparazione, quindi la fase 1 di creazione, la fase 2 pilota, la fase 3 a scaglioni e la fase 4 di dismissione in circa 12 settimane.","nodes":[{"id":"p0","label":"Prima della fase 1","sub":"Inventario, mappa delle policy, deployment CA, fonte d'identità","tone":"neutral","when":"Settimane 1-2"},{"id":"p1","label":"Fase 1: creazione e mirroring","sub":"Policy ricostruita su RADIUS cloud, le risposte del lab corrispondono","tone":"brand","when":"Settimana 3"},{"id":"p2","label":"Fase 2: sede pilota","sub":"Una sede, vecchio server mantenuto come secondario","tone":"brand","when":"Settimane 4-5"},{"id":"p3","label":"Fase 3: scaglioni","sub":"Cinque, poi 10, quindi le restanti 24 sedi","tone":"brand","when":"Settimane 6-10"},{"id":"p4","label":"Fase 4: dismissione","sub":"Zero richieste sul vecchio server, poi spegnimento","tone":"success","when":"Settimane 11-12"}],"edges":[{"from":"p0","to":"p1","label":"prerequisiti soddisfatti"},{"from":"p1","to":"p2","label":"le risposte del lab corrispondono"},{"from":"p2","to":"p3","label":"test di uscita pilota"},{"from":"p3","to":"p4","label":"migrazione completata per tutte le sedi"}]}

{"caption":"Piano di fase per una migrazione RADIUS multi-sede","asOf":"2026-06-10","columns":[{"key":"phase","label":"Fase"},{"key":"scope","label":"Ambito"},{"key":"owner","label":"Responsabile"},{"key":"exit","label":"Test di uscita"}],"rows":[["Prima della fase 1","Inventario NAS, mappa delle policy, deployment CA, fonte d'identità, percorsi delle sedi","IT manager con il responsabile dell'identità e degli accessi","Ogni NAS elencato, ogni gruppo di policy nell'identity provider, nuova CA sui dispositivi gestiti"],["Fase 1: creazione","Policy ricostruita su RADIUS cloud, nessun traffico in produzione","Responsabile dell'identità e degli accessi","Un'identità di prova per riga riceve la stessa risposta e VLAN dal vecchio e dal nuovo server"],["Fase 2: pilota","Una sede rappresentativa, nuovo server primario, vecchio secondario","Network architect","Un ciclo aziendale senza rifiuti non spiegati e ogni classe di dispositivo rilevata sul nuovo server"],["Fase 3: scaglioni","Sedi rimanenti in scaglioni crescenti, raggruppate per modello di console","Network architect con i responsabili delle sedi","Ogni scaglione supera il test di uscita pilota prima che inizi il successivo"],["Fase 4: dismissione","Vecchio server rimosso da ogni SSID e NAS","IT manager","Zero richieste sul vecchio server per il periodo di inattività, log conservati, segreti revocati"]],"footnote":"I responsabili sono ruoli, non persone specifiche. Impostare il periodo di inattività su almeno un ciclo di riautenticazione più una settimana lavorativa.","download":{"filename":"radius-migration-phase-plan.csv"}}

Cosa succede all'interno di ciascuna fase?

Fase 1: creazione e mirroring della policy

Ricostruire la mappa delle policy sul nuovo server prima che sia raggiunta da qualsiasi richiesta in produzione. Connettere l'identity provider, quindi ricreare ciascuna riga con la relativa condizione, risultato e attributi restituiti. Mantenere identici gli ID VLAN, in modo che la configurazione di switch e firewall non cambi mai.

Testi ogni riga da un laboratorio. Utilizzi eapol_test, uno strumento del progetto wpa_supplicant. Invia un reale scambio EAP a un server RADIUS e stampa la risposta. Esegua un'identità per riga su entrambi i server e confronti le risposte. Il test finale consiste in una corrispondenza su ogni riga, con lo stesso esito di accettazione o rifiuto e lo stesso VLAN.

Fase 2: pilota in una sede

Scelga una sede rappresentativa dell'intera struttura, non quella più semplice. Dovrebbe contenere ogni classe di dispositivo utilizzata, comprese quelle più complesse. Si pensi a scanner portatili, terminali di pagamento su WiFi e laptop datati. È inoltre necessaria la presenza in loco di una persona in grado di testare un dispositivo quando richiesto.

Aggiunga il nuovo server accanto a quello vecchio, lo testi, quindi renda primario il nuovo server. Lo lasci attivo per un intero ciclo operativo. Per un hotel, questo significa una settimana di turni. Per un ufficio, significa una settimana di accessi del lunedì mattina. Il pilota si considera superato al verificarsi di due condizioni. In primo luogo, ogni classe di dispositivo si è autenticata sul nuovo server. In secondo luogo, il tasso di rifiuto non è peggiore rispetto al valore di riferimento.

Fase 3: migrazione della struttura a scaglioni

Renda ogni scaglione più ampio del precedente man mano che i primi vengono completati. Una struttura con 40 sedi potrebbe migrare una sede pilota, poi cinque, poi 10 e infine le restanti 24. Raggruppi ogni scaglione per modello di console o gruppo, in modo che una singola modifica raggiunga tutte le sedi interessate. I modelli di configurazione Meraki, i modelli WLAN Juniper Mist e i gruppi HPE Aruba Central sono tutti adatti a questo approccio.

Esegua il passaggio diretto mentre il personale della sede è presente, non alle 3 del mattino. Una modifica che nessuno testa fino al mattino è una modifica non testata. Eviti di accorpare altre modifiche di rete nella stessa finestra temporale.

Fase 4: dismissione del vecchio server

Rimuova il vecchio server da ogni SSID e da ogni NAS nell'inventario, quindi monitori i relativi log. Le richieste dovrebbero azzerarsi. Qualsiasi richiesta ancora in arrivo proviene da un NAS dimenticato. Mantenga il periodo di inattività per almeno un ciclo di riautenticazione più una settimana lavorativa. Successivamente, esporti i log in base alla propria politica di conservazione, spenga il server e ritiri i relativi segreti condivisi.

Scenario pratico: un gruppo di 40 hotel su Cisco Meraki

Si consideri un gruppo di 40 hotel che utilizza il WiFi del personale WiFi su Cisco Meraki. Utilizza PEAP verso un server RADIUS locale presso la sede centrale. Ogni richiesta attraversa la rete WAN verso un unico edificio, pertanto un'interruzione presso la sede centrale disabilita il WiFi del personale WiFi in ogni hotel.

Il gruppo distribuisce la nuova CA tramite il proprio MDM nella prima settimana. Ricostruisce cinque righe di criteri su RADIUS cloud rispetto a Microsoft Entra ID, quindi avvia il pilota presso un hotel cittadino da 120 camere. Seguono scaglioni da cinque, 10 e 24 hotel, ciascuno gestito tramite un modello di configurazione Meraki. Un hotel esegue il ripristino per un pomeriggio poiché un tablet per le pulizie riconosce solo la vecchia CA. Viene migrato nuovamente una settimana dopo.

Il risultato:

• Tutti i 40 hotel sono stati migrati in sei finestre di modifica.
• Una sede ha effettuato il ripristino una sola volta.
• La sede centrale non si trova più nel percorso di autenticazione.

Come funzionano affiancati i vecchi e i nuovi server RADIUS?

Il funzionamento in parallelo dipende dalla modalità di failover degli access point. Un NAS invia ciascuna richiesta al primo server presente nel suo elenco. Tenta di contattare il server successivo solo quando il primo non risponde entro il tempo limite.

Un messaggio di Access-Reject conta come risposta, non come errore, pertanto il NAS non riproverà la richiesta altrove. Ciò comporta due conseguenze:

• Entrambi i server devono fornire la stessa risposta. Se le risposte differiscono, l'esperienza del dispositivo dipenderà da quale server ha risposto per primo.
• Il funzionamento in parallelo è una rete di sicurezza, non un test. Verifichi le policy nella fase 1 e durante il pilot. Non le testate attendendo di vedere come reagisce il failover.

Verifichi i tempi limite prima dello spostamento della prima sede. Un server cloud è più distante rispetto a un server situato nella sua sala macchine. Confronti le impostazioni di timeout e di re-invio del NAS di ciascuna sede con il relativo tempo di andata e ritorno (round-trip time). Se le impostazioni sono troppo restrittive, le richieste passeranno al vecchio server in failover senza un motivo reale, nascondendo eventuali problemi. Sposti la contabilizzazione RADIUS sul nuovo server nello stesso momento dell'autenticazione, in modo che i record di sessione risiedano in un unico luogo.

Il passaggio definitivo in ciascuna sede consiste semplicemente nell'invertire l'ordine dei due server. Questi passaggi si applicano a ogni sede, con le differenze specifiche del fornitore mostrate all'interno del passaggio 2.

{"title":"Esegui il cutover di un sito senza un giorno di fermo totale","steps":[{"title":"Conferma che il sito sia pronto","body":"Verifica il sito rispetto alla checklist di migrazione: NAS elencato, nuova CA sui dispositivi gestiti, percorso verso Purple aperto, referente sul posto.","check":"Tutti i prerequisiti per il sito sono stati verificati."},{"title":"Aggiungi il nuovo server affiancandolo a quello vecchio","body":"Aggiungi il cloud RADIUS di Purple all'elenco dei server RADIUS dell'SSID, utilizzando il segreto condiviso fornito da Purple per il sito. Per ora lascia il vecchio server in prima posizione.","check":"La console mostra entrambi i server associati all'SSID.","variants":[{"label":"Meraki","body":"Nel Dashboard Meraki, aggiungi il server nelle impostazioni di controllo degli accessi dell'SSID, idealmente nel modello di configurazione."},{"label":"Aruba","body":"In HPE Aruba Central, aggiungi il server al gruppo di server di autenticazione utilizzato dalla WLAN."},{"label":"Ruckus","body":"Aggiungi il server al profilo del server AAA utilizzato dalla WLAN, come server secondario."},{"label":"Mist","body":"Nel portale Juniper Mist, aggiungi il server ai server di autenticazione RADIUS della WLAN, idealmente nel modello WLAN."},{"label":"UniFi","body":"Nell'applicazione UniFi Network, aggiungi il server al profilo RADIUS assegnato alla rete WiFi."}]},{"title":"Esegui i test prima dello scambio","body":"Da un host di test registrato come client RADIUS, invia un'identità per ogni riga di criterio al nuovo server.","code":{"lang":"bash","text":"eapol_test -c eap-tls.conf -a <purple-radius-address> -p 1812 -s <shared-secret>"},"check":"Ogni identità riceve Access-Accept o Access-Reject come indicato dalla mappa dei criteri, con la VLAN prevista."},{"title":"Inverti l'ordine","body":"Imposta il nuovo server come primario e mantieni il vecchio server come secondario. Questo è il cutover.","check":"I log del nuovo server mostrano richieste da ogni access point presente nel sito."},{"title":"Attendi per un ciclo aziendale completo","body":"Confronta il tasso di rifiuto con la tua baseline e conferma che ogni classe di dispositivi si sia autenticata.","check":"Nessun rifiuto inspiegabile e il sito supera il test di uscita."}]}

Come si effettua il rollback di un sito o di un gruppo?

Il rollback equivale al cutover eseguito al contrario: si riposiziona il vecchio server al primo posto. Su ciascuna delle console menzionate sopra, si tratta di una singola modifica di configurazione. Funziona solo se il vecchio server è ancora in funzione, inalterato e con i relativi segreti condivisi intatti. Ecco perché la dismissione avviene per ultima. È anche il motivo per cui si bloccano le modifiche ai criteri sul vecchio server all'inizio della fase 1.

Concorda le condizioni di attivazione prima di iniziare. Le condizioni tipiche includono:

• Una classe di dispositivi che non riesce a connettersi e non ha una soluzione applicabile in giornata.
• Assegnazioni VLAN che differiscono dalla mappa dei criteri.
• Un tasso di rifiuto superiore alla baseline che non è possibile spiegare all'interno della finestra di modifica.

{"title":"Procedere, sospendere o ripristinare un'ondata","start":"q1","nodes":[{"id":"q1","question":"Ci sono classi di dispositivi che falliscono sul nuovo server ma funzionavano sul vecchio?","help":"Confronta i rifiuti per tipo di dispositivo con il baseline registrato prima del passaggio.","options":[{"label":"Sì","to":"q2"},{"label":"No","to":"q3"}]},{"id":"q2","question":"Il problema è limitato a una singola classe di dispositivi con una soluzione nota?","help":"Una CA mancante in un profilo è una soluzione nota. Rifiuti su più classi non lo sono.","options":[{"label":"Sì","to":"o2"},{"label":"No","to":"o3"}]},{"id":"q3","question":"Ogni identità di test viene assegnata alla VLAN prevista in ogni sede dell'ondata?","options":[{"label":"Sì","to":"q4"},{"label":"No","to":"o3"}]},{"id":"q4","question":"L'ondata ha completato un intero ciclo operativo senza rifiuti non spiegati?","options":[{"label":"Sì","to":"o1"},{"label":"No","to":"o2"}]},{"id":"o1","outcome":"Procedi: avvia la prossima ondata","detail":"Registra il risultato del test d'uscita per sede e pianifica l'ondata successiva.","link":"[Una sola policy per ogni sede](guide:cloud-radius-multi-site)"},{"id":"o2","outcome":"Sospendi: correggi, poi ripeti il test","detail":"Imposta il vecchio server come primario solo sull'SSID interessato, correggi il profilo o la regola e ripeti il test d'uscita."},{"id":"o3","outcome":"Ripristina l'ondata","detail":"Imposta il vecchio server come primario su ogni SSID dell'ondata, acquisisci i log da entrambi i server e individua la causa prima di riprovare.","link":"[Quando RADIUS non è raggiungibile](guide:radius-server-down-wifi)"}]}

Dopo qualsiasi ripristino, esporta i log da entrambi i server per la finestra temporale interessata dall'errore. Individua la causa e correggila nella nuova policy. Successivamente, ripeti il test di laboratorio della fase 1 per la riga interessata prima di trasferire nuovamente la sede.

Come si capisce che la migrazione è terminata?

La migrazione è terminata quando sono le evidenze a confermarlo, non quando viene trasferita l'ultima sede. Cinque test la concludono:

1. Il vecchio server ha registrato zero richieste per il periodo di inattività concordato.
2. Ogni NAS nell'inventario compare nei log del nuovo server.
3. Un dispositivo reale ha attivato ogni riga della policy ed è stato assegnato alla VLAN prevista.
4. Il tasso di rifiuto è pari o inferiore al baseline registrato prima della fase 2.
5. Il vecchio server è spento, i suoi log sono conservati, i relativi secret sono stati revocati e il runbook è stato aggiornato.

Conserva una scheda di sintesi per ciascuna sede, indicando la data, il risultato del test d'uscita ed eventuali ripristini. Insieme ai nuovi log di autenticazione, queste schede costituiscono le evidenze necessarie per i controlli di accesso ISO 27001 e di tracciamento PCI-DSS. Servono inoltre come prova del controllo delle modifiche per il successivo ciclo di audit.

Modalità di guasto riscontrate sul campo

Dispositivi che si fidano solo del vecchio certificato

Questo è l'errore più comune. I dispositivi PEAP non gestiti potrebbero richiedere l'accettazione del nuovo certificato o rifiutarlo direttamente. Alcuni profili gestiti effettuano il pinning del nome del server oltre che della CA. Verificali entrambi prima del pilot.

Un NAS non elencato da nessuno

Controller dimenticati, switch cablati 802.1X e gateway VPN mantengono occupato il vecchio server molto tempo dopo il trasferimento del WiFi. Il periodo di inattività nella fase 4 serve proprio a individuarli.

Criteri che risiedevano sul vecchio server

I gruppi locali, gli elenchi MAC codificati nel codice e le regole basate sull'ora del giorno spesso esistono solo sul vecchio server. Se non sono presenti nella mappa dei criteri, scompaiono al momento del passaggio definitivo.

Discrepanze nei segreti condivisi e negli attributi

Un segreto digitato in modo errato genera un errore che non viene segnalato su alcune console. Una VLAN restituita per nome anziché per ID può spostare i dispositivi sulla VLAN predefinita. Entrambi i problemi dovrebbero emergere durante i test della fase 1 e dovrebbero essere verificati nuovamente durante il pilot.

Timeout ottimizzati per un server situato nello stesso edificio

Timeout troppo stretti su un NAS causano un failover spurio verso il vecchio server. Tutto sembra funzionare fino a quando il vecchio server non viene rimosso.

Scenario pratico: un rivenditore con 120 punti vendita su due console

Prendiamo il caso di un rivenditore con 120 punti vendita, dove i negozi più vecchi utilizzano HPE Aruba e quelli più recenti Juniper Mist. I palmari e i laptop del punto vendita utilizzano EAP-TLS rispetto a una coppia di server RADIUS on-premise. Il pilot e le successive fasi procedono senza intoppi, raggruppati per gruppo Aruba Central e modello WLAN Mist.

Nella fase 4, i vecchi server continuano a registrare richieste da tre indirizzi dopo che ogni SSID è stato trasferito. Due sono controller del centro di distribuzione esterni alla rete dei punti vendita. Il terzo è un gateway VPN per i laptop della sede centrale. Il team aggiunge tutti e tre all'inventario, li sposta in una finestra temporale aggiuntiva e riavvia il periodo di inattività. La dismissione si conclude con due settimane di ritardo, senza alcuna interruzione in nessuno dei punti vendita.

Il ruolo di Purple

Purple Access gestisce reti aperte, sicure e iPSK/PPSK su un'unica piattaforma, utilizzando gli access point già in tuo possesso. La rete sicura gestisce questa migrazione. Fornisce RADIUS basato su SaaS, EAP-TLS e identità da Microsoft Entra ID, Okta o Google Workspace. Supporta anche Passpoint, noto anche come Hotspot 2.0, che consente ai dispositivi di accedere automaticamente a una rete sicura tramite una credenziale. Purple è indipendente dall'hardware, quindi un unico criterio serve sedi basate su queste piattaforme:

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme Networks
• Fortinet

Ciò significa che un'infrastruttura mista può migrare basandosi su un unico piano.

Purple gestisce il più grande servizio RADIUS in cloud al mondo. Viene fornito con uno SLA di operatività RADIUS del 99,9%, su una piattaforma che funziona con un'operatività del 99,999%. Poiché l'ambiente Purple viene configurato prima dell'inizio della fase 2, il passaggio definitivo di ciascuna sede si riduce solitamente a un'operazione da svolgere nel fine settimana. La suddivisione in fasi esiste per gestire il rischio all'interno della tua infrastruttura, non sulla nostra piattaforma.

{"items":[{"value":"80,000+","label":"sedi attive","note":"Dati proprietari Purple"},{"value":"90","label":"paesi"},{"value":"99.9%","label":"SLA di operatività RADIUS","note":"Su una piattaforma operativa al 99.999%"}]}

{"tone":"proof","title":"WiFi aziendale su scala capillare","text":"JPMorgan gestisce il WiFi per il personale tramite Purple in 5.000 filiali."}

Consultare il WiFi RADIUS cloud su Purple Access per i dettagli sul prodotto e la guida alla sicurezza aziendale WiFi per l'insieme di controlli più ampio. Il marketing degli ospiti si trova in Engage e il filtraggio DNS si trova in Shield. Nessuno dei due varia durante una migrazione del RADIUS.

Domande frequenti

Quanto tempo richiede una migrazione del RADIUS multisito?

È opportuno pianificare alcune settimane per l'intero parco immobiliare e un fine settimana per ciascun sito. Su Purple, il passaggio di ogni sito è solitamente un'operazione da svolgere nel fine settimana. Il parco complessivo richiede più tempo poiché ogni fase si arresta per un ciclo aziendale prima che inizi la successiva. Ad esempio, un parco di 40 siti richiede circa 12 settimane dall'inventario alla dismissione. La maggior parte di questo tempo è dedicata alla preparazione e ai periodi di attesa, non al lavoro di modifica.

Sono necessari nuovi access point per passare al WiFi RADIUS cloud?

No. Il WiFi RADIUS cloud modifica il server interpellato dagli access point, non gli access point stessi. Purple funziona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. È sufficiente aggiungere il nuovo server all'elenco dei server RADIUS di ciascun SSID nella console già in uso. Gli SSID, gli ID VLAN e la configurazione dello switch rimangono invariati.

Come occorre modellare il costo del WiFi RADIUS cloud su più siti?

È opportuno modellarlo su due cifre: siti e identità. Occorre contare ogni sito che esegue l'autenticazione e ogni identità che si connette, compresi i dispositivi su EAP-TLS. Quindi, occorre confrontare questo valore con il costo totale del vecchio server: hardware, licenze, applicazione delle patch, elevata disponibilità e il percorso WAN verso la sede centrale. La nostra guida su come modellare il costo del WiFi RADIUS cloud per sito illustra tutti i passaggi del calcolo.

È possibile mantenere il vecchio server RADIUS come soluzione di riserva dopo il passaggio?

È bene mantenerlo durante il funzionamento in parallelo, per poi spegnerlo. Finché è elencato come secondario, copre i timeout nei siti ancora interessati dalle varie fasi. Dopo la fase 4, un server che conserva una copia bloccata della vecchia politica diventa un rischio, poiché qualsiasi risposta fornisca utilizzerà regole obsolete. Da quel momento in poi, la resilienza è garantita dall'SLA di operatività del RADIUS del 99,9% e da un piano di ripristino in caso di interruzione.

Il personale dovrà registrare nuovamente i propri dispositivi?

Non se il nuovo certificato del server viene ritenuto attendibile prima del passaggio. È sufficiente distribuire la nuova CA ai dispositivi gestiti tramite l'MDM durante la fase di creazione. I dispositivi EAP-TLS mantengono i certificati client esistenti, a condizione che il nuovo server ritenga attendibile la CA che li ha emessi. I dispositivi PEAP non gestiti rappresentano l'unica eccezione, poiché alcuni di essi richiedono un'unica conferma per accettare il nuovo certificato. Si consiglia di inviare a tale personale un breve preavviso prima che il rispettivo sito venga trasferito.

La migrazione influisce sulle nostre prove ISO 27001 o PCI DSS?

Questo cambia la provenienza delle prove di conformità, quindi pianificalo fin dall'inizio. Log di autenticazione, definizioni delle policy e registri delle modifiche passano alla nuova piattaforma. Conserva i log del vecchio server in base alla tua policy di conservazione e archivia il verbale del test di uscita di ciascun sito. Purple possiede la certificazione ISO 27001, fornendo ai revisori le prove necessarie sul lato piattaforma. I controlli interni richiedono comunque prove specifiche.

In che modo varia questo processo per un MSP che gestisce più ambienti?

Le fasi sono le stesse. Ciò che cambia è l'isolamento tra i diversi ambienti. Un MSP esegue le stesse quattro fasi per ciascun ambiente, ma ognuno necessita di policy, origini di identità e log dedicati su una piattaforma condivisa. Le fasi di migrazione di solito seguono i confini contrattuali piuttosto che i modelli della console. La nostra guida al RADIUS multi-tenant per MSP spiega come mantenere separato ogni ambiente durante e dopo la migrazione.