Ti trovi di fronte a un Network Policy Server che nessuno vuole aggiornare, un controller wireless che punta a una singola macchina RADIUS in una sala server e una coda dell'helpdesk piena di reimpostazioni della password. L'identità si è spostata su Microsoft Entra ID o Okta, eppure l'autenticazione WiFi dipende ancora da un'infrastruttura locale creata per Active Directory on-premise. Questa discrepanza è il motivo per cui le organizzazioni iniziano a valutare un cloud radius server, non perché spostare un server sia entusiasmante, ma perché il vecchio modello non si adatta più al modo in cui lavorano utenti, dispositivi e sedi.
Che cos'è un server Cloud RADIUS
Immaginate il RADIUS come una guardia di sicurezza all'ingresso di un edificio. Arriva una persona, mostra un tesserino e la guardia verifica il tesserino rispetto a un elenco approvato prima di aprire la porta. Se il tesserino è valido, la guardia decide anche quali piani quella persona può raggiungere. In caso contrario, la porta rimane chiusa.
Un cloud radius server sposta quel controllo da una postazione locale a un servizio gestito centralmente. La verifica avviene comunque all'ingresso, che in termini di WiFi è l'access point o lo switch. La decisione, tuttavia, proviene da un servizio ospitato configurato tramite policy anziché da server da aggiornare, eseguire il backup e raggruppare in cluster autonomamente.
Come funziona il flusso di autenticazione
Un laptop o uno smartphone si connette a un SSID WPA-Enterprise protetto da 802.1X. L'access point non prende decisioni in autonomia. Inoltra la richiesta di autenticazione al cloud RADIUS server, che convalida le credenziali, il certificato o l'identità del dispositivo confrontandoli con la directory o l'autorità di certificazione.
Il server restituisce un esito di accettazione o rifiuto, spesso accompagnato da attributi quali una VLAN, un ruolo o un limite di sessione. L'access point applica tale decisione a livello locale. Questa separazione è fondamentale, perché il RADIUS è il punto decisionale, non l'intera rete e neppure l'identity provider stesso.
- Supplicant: Il laptop, lo smartphone o il dispositivo che richiede l'accesso e presenta una credenziale o un certificato.
- Autenticatore: L'access point, il controller o lo switch che inoltra la richiesta e applica il risultato.
- Fonte di identità: Entra ID, Okta, Google Workspace, Active Directory o un'autorità di certificazione che detiene il registro autorevole.
Perché l'approccio ibrido è il punto di partenza naturale
Le organizzazioni del Regno Unito non hanno trasferito tutto sul cloud in un solo passaggio. Cloud Industry Forum ha riportato che l'84% delle organizzazioni del Regno Unito aveva adottato formalmente almeno un servizio cloud nella sua ricerca del 2016, rispetto al 48% del 2010, il che aiuta a spiegare perché il cloud RADIUS venga solitamente distribuito come parte di un'architettura ibrida piuttosto che come sostituzione immediata di ogni componente locale, come illustrato nella ricerca sull'adozione del cloud nel Regno Unito del 2016 di Cloud Industry Forum.
In pratica, i tuoi switch, access point, stampanti e sistemi legacy rimangono in sede. Ciò che cambia è il luogo in cui viene presa la decisione di autenticazione e la coerenza con cui puoi applicarla tra le varie sedi. Questa è una definizione più circoscritta e utile rispetto al definirlo un semplice cambio di server ospitato.
Cloud RADIUS vs RADIUS On-Premises
Il confronto onesto non è tra cloud buono e on-premises cattivo. Riguarda chi sostiene il carico operativo, quanto controllo vi serve e cosa si interrompe quando qualcosa si guasta. Una coppia on-premises ben gestita può funzionare per anni. Una trascurata diventa un singolo punto di vulnerabilità che nessuno osa toccare.
Anche gli ambienti aziendali del Regno Unito rimangono misti. Un'analisi del governo del Regno Unito del 2025 ha rilevato che circa il 55% delle organizzazioni del governo centrale ha riferito di avere oltre il 60% del proprio parco tecnologico nel cloud, mentre circa il 28% dei parchi tecnologici del governo centrale rimaneva legacy, secondo lo State of Digital Government Review. Questa combinazione è esattamente il motivo per cui è ancora necessario collegare l'identità cloud agli edifici e alle reti wireless che rimangono on-premise.
Confronto diretto tra costi e manutenzione
| Criterio | RADIUS in cloud | RADIUS on-premises |
|---|---|---|
| Costo in conto capitale | Basso, basato su abbonamento | Costi iniziali piu elevati per hardware e licenze |
| Manutenzione | Il fornitore aggiorna e gestisce il servizio | Il tuo team applica le patch a SO, RADIUS e certificati |
| Scalabilita | Aggiunta di sedi tramite configurazione | Aggiunta di server, clustering e bilanciamento del carico |
| Controllo | Controllo delle policy, minore controllo sull'infrastruttura | Controllo totale, responsabilita totale |
| Resilienza | Endpoint ridondanti forniti dal provider | Progettazione e test del failover a tuo carico |
FreeRADIUS sembra gratuito finché non si calcola il tempo degli ingegneri, i rinnovi dei certificati, il monitoraggio e la risoluzione dei problemi fuori dall'orario di lavoro. Microsoft NPS sembra incluso finché non si ha bisogno di un'integrazione nativa con una directory cloud per cui non è stato progettato. Cisco ISE offre funzionalità di policy avanzate, ma comporta licenze e competenze specialistiche che molti team non possono giustificare solo per il WiFi.
L'equivoco sulla sicurezza
La posizione del server non rende l'autenticazione sicura. La configurazione, l'integrazione con le identità, il trasporto crittografato e il monitoraggio lo fanno.
Il cloud sposta il rischio anziché eliminarlo. Si ottengono patch coerenti e policy multi-sito, ma si dipende dalla connettività Internet, dal piano di controllo del provider e dall'identity provider. La soluzione on-premise mantiene il traffico locale, ma un singolo server non aggiornato con secret condivisi ovunque non è più sicuro solo perché si trova all'interno del vostro edificio.
Scegli il cloud quando non disponi del personale necessario per gestire correttamente una coppia ad alta disponibilità, gestisci molte sedi o hai già trasferito l'identità nel cloud. Rimani on-premises quando le normative, la latenza o una sede disconnessa richiedono effettivamente decisioni locali. Molte migrazioni HR e IT seguono la stessa logica ibrida, motivo per cui questa guida per i team HR di Microsoft 365 è una lettura parallela utile su come spostare i sistemi principali senza pretendere che i sistemi legacy scompaiano dall'oggi al domani.
Integrazione con Microsoft Entra ID, Okta e certificati
Un cloud RADIUS server dimostra il suo valore nei punti di integrazione. Se non riesce a comunicare in modo pulito con la directory, l'autorità di certificazione e i flussi ospiti, avete acquistato un collo di bottiglia hosted. Stabilite i corretti modelli di integrazione e l'accesso alla rete comincerà a seguire la stessa logica di gestione degli accessi degli utenti del resto dell'IT.
RADIUS non gestisce nativamente la moderna federazione web. Se il tuo team sta cercando di chiarire dove finisce l'autenticazione di rete e dove inizia il single sign-on delle applicazioni, questa panoramica sull'autenticazione SAML e OIDC aiuta a separare questi livelli. RADIUS gestisce l'ammissione alla rete, mentre SAML e OIDC gestiscono di norma l'accesso alle applicazioni dopo che l'utente è già connesso.
Autenticazione basata su directory per il personale
Con Microsoft Entra ID o Okta, il servizio RADIUS verifica l'utente o il dispositivo rispetto ai gruppi e agli attributi presente nella directory. Un utente dell'area finanziaria può ottenere un ruolo diverso rispetto a un fornitore di servizi di manutenzione, anche sullo stesso SSID. Quando le risorse umane disabilitano un account, tale modifica dovrebbe riflettersi sull'accesso alla rete senza dover aprire un ticket separato al team di rete.
Nello specifico per Microsoft Entra ID, convalida il modo in cui gruppi, oggetti dispositivo e segnali condizionali si mappano nei criteri RADIUS prima del rilascio su larga scala, come illustrato in questa guida all'integrazione di Entra ID e RADIUS-as-a-Service. Durante la fase pilota, testa la gestione di un dipendente uscente, un cambio di ruolo e un dispositivo disabilitato. Questi tre casi di prova rivelano molto di più rispetto a cento accessi riuscite.
Certificati per i dispositivi gestiti
L'EAP-TLS utilizza certificati su entrambi i lati, quindi non c'è alcuna password da sottrarre tramite phishing, condividere o attaccare con forza bruta. È il modello più solido per i laptop gestiti, a condizione che sia possibile emettere, rinnovare e revocare i certificati tramite MDM o SCEP senza interventi manuali. Se la provisioning dei certificati è instabile, gli utenti vi spingeranno a tornare alle password, e avranno la meglio.
- Emissione dell'identità: Distribuisci un certificato utente o dispositivo tramite Intune, Jamf o il tuo MDM con un proprietario chiaro e una data di scadenza.
- Convalida dell'affidabilità: Configura il servizio RADIUS in modo da ritenere attendibile la CA emittente e verificare lo stato di revoca.
- Associazione ai criteri: Mappa i campi del certificato e i gruppi di directory su VLAN o ruoli presso l'Access Point.
- Revoca rapida: Rimuovi contemporaneamente il certificato e l'accesso alla directory quando un dispositivo viene smarrito o una persona lascia l'azienda.
Ospiti e dispositivi che non supportano 802.1X
Gli ospiti non dovrebbero aver bisogno di un account aziendale per ottenere un accesso sicuro. Passpoint e OpenRoaming consentono a un dispositivo di autenticarsi una sola volta e di riconnettersi con accesso crittografato nelle visite successive, l'ideale per hotel, hub di trasporto e strutture con più sedi. Per stampanti, terminali di pagamento e dispositivi IoT datati che non possono presentare certificati, utilizza il MAC authentication bypass o chiavi precondivise individuali con una rigida segmentazione, trattando tali dispositivi come non affidabili per impostazione predefinita.
Considerazioni sulla sicurezza e sul modello Zero-Trust
Considerate un cloud RADIUS server come un confine di sicurezza, non come una semplice utility. Decide chi accede alla rete, comunica con la directory e la sua console di amministrazione può modificare le policy per tutte le sedi contemporaneamente. Questa concentrazione di potere è utile, ed è esattamente il motivo per cui i controlli che la circondano richiedono la massima attenzione.
L'NCSC raccomanda che le interfacce dei servizi cloud consentano l'accesso solo a identita autenticate e autorizzate, utilizzando un'autenticazione contestuale con asserzioni crittografiche o scambio di chiavi sicuro, come descritto nel Principio 10 dell'NCSC su identita e autenticazione. Per il RADIUS in cloud, cio significa trattare il servizio e le sue interfacce amministrative come perimetri di fiducia distinti, con identita di servizio uniche, permessi strettamente limitati ed eventi di autenticazione tracciabili anziche credenziali amministrative condivise.
Smettere di fidarsi della posizione di rete
Il modello Zero Trust cambia la domanda da "questo dispositivo si trova sulla nostra VLAN?" a "chi è questo utente, cos'è questo dispositivo e cosa dovrebbe raggiungere in questo momento?". La presenza su una VLAN aziendale o ospiti non è una prova di autorizzazione. L'accesso deve rimanere vincolato all'identità autenticata e alla policy per quella specifica sessione, tenant e sede.
Questo principio ha conseguenze pratiche per la progettazione della rete WiFi. Il laptop di un fornitore e quello dell'ufficio amministrativo possono condividere lo stesso SSID, ma non dovrebbero condividere la raggiungibilità di rete. Il tuo insieme di controlli più ampio dovrebbe allinearsi a una guida alla sicurezza WiFi enterprise per l'accesso di rete zero trust, in modo che le decisioni di autenticazione siano collegate a segmentazione, monitoraggio e minimo privilegio, anziché alla semplice connessione.
Controlli da richiedere a un fornitore
- Trasporto crittografato: RadSec o protezione equivalente per il traffico RADIUS, oltre a TLS moderno per le API e l'accesso amministrativo.
- Rotazione e revoca: Rotazione documentata di certificati e segreti, e revoca rapida quando gli account o i dispositivi vengono disabilitati.
- Amministrazione basata sui ruoli: Ruoli distinti per lettore, operatore e amministratore, senza credenziali condivise per le modifiche alle policy.
- Registrazione utile: Eventi di autenticazione, modifiche alle policy e azioni amministrative esportati nel SIEM con periodi di conservazione chiari.
Regola pratica: Se la compromissione di una singola sede o di un account di integrazione concede a un utente malintenzionato l'autorità su altri tenant o sul piano di controllo, la progettazione ha fallito.
Poni domande difficili fin da subito. Chi può visualizzare i log di autenticazione, dove vengono archiviati e in che modo l'accesso di gestione del provider è separato dal tuo piano dati. Se un fornitore non sa rispondere in modo chiaro, questo è già un fattore indicativo.
Modelli di configurazione per WiFi enterprise e multi-tenant
Un hotel al momento del check-in, un reparto con dispositivi medici e un centro commerciale di sabato non condividono lo stesso profilo di rischio. Possono condividere un cloud RADIUS server, a condizione che ciascun gruppo di utenti ottenga la propria policy e che la rete imponga la separazione dopo l'autenticazione. L'errore consiste nel presumere che un login riuscito equivalga a una rete segmentata.
I dati dei sondaggi governativi indicano che l'85% delle grandi aziende del Regno Unito manteneva reti WiFi separate per personale e visitatori, in calo rispetto al 93% precedente, nel capitolo sui controlli di sicurezza di rete del Cyber Security Breaches Survey 2025. La separazione non è un problema risolto, nemmeno per le grandi organizzazioni. Il cloud RADIUS deve quindi essere combinato con VLAN dinamiche o con l'applicazione di policy per offrire una reale segmentazione, e non solo un'autenticazione migliore.
Cosa richiedono effettivamente le diverse sedi
Nel settore dell'ospitalità, gli ospiti si autenticano all'arrivo, i dispositivi del personale vengono verificati rispetto alla directory e i terminali di pagamento risiedono in un segmento limitato che non può vedere nessuno dei due. In ambito sanitario, personale clinico, addetti al trasporto, pazienti e apparecchiature mediche coesistono, e alcune di queste apparecchiature non supporteranno mai i certificati. La policy deve riflettere questa realtà invece di forzare ogni dispositivo in un unico modello.
Le catene retail affrontano un problema di scala piuttosto che di complessità nei singoli punti vendita. La sede centrale desidera un accesso uniforme per il personale e la separazione degli ospiti in ogni filiale senza dover spedire server in ciascun sito. Gli hub di trasporto aggiungono il roaming, dove un pendolare si aspetta che la connessione registrata in una stazione funzioni anche in quella successiva. Un servizio centralizzato risponde a entrambe le esigenze poiché le regole seguono l'identità.
Gli edifici multi-tenant richiedono isolamento nativo
I residenti nelle strutture build-to-rent o negli alloggi studenteschi si aspettano un WiFi di tipo domestico, ma i dispositivi di ciascun nucleo familiare devono rimanere invisibili ai vicini. Ciò richiede criteri per singolo tenant, chiavi individuali per i dispositivi legacy e un accesso per il personale che non vada a sovrapporsi alle reti dei residenti. Vale la pena consultare una guida al WiFi multi-tenant per reti residenti isolate insieme alla progettazione del sistema RADIUS, perché l'autenticazione è utile solo se la separazione dei tenant alla base è solida.
Prima del rilascio, mappa ogni classe di dispositivi in tuo possesso, non solo l'elenco ordinato presente nel registro degli asset. Dipendenti, ospiti, fornitori, IoT, casse, scanner e la vecchia stampante nell'ufficio amministrazione necessitano tutti di un percorso definito. I dispositivi non pianificati diventano l'eccezione che compromette la policy.
Best practice per l'implementazione e la gestione
La maggior parte dei problemi del cloud RADIUS non sono problemi di protocollo. Sono imprevisti operativi che nessuno ha testato, come un account revocato che continua a funzionare, una sede che perde l'accesso a internet o un accesso di emergenza che non lascia alcuna traccia di audit. Pianificate questi casi prima che la prima sede diventi operativa, non durante il primo disservizio.
La Cyber Security Breaches Survey 2025 del governo britannico ha rilevato che il 43% delle aziende ha segnalato una violazione o un attacco nei 12 mesi precedenti, ma solo il 31% ha condotto valutazioni formali dei rischi informatici, come riportato nei risultati della Cyber Security Breaches Survey da 2025 a 2026. Tale divario è il motivo per cui sono necessarie risposte esplicite per l'interruzione del fornitore, l'inattività dell'Identity Provider e la perdita di connettività, oltre ad accessi di emergenza sottoposti ad audit.
Definire il comportamento in caso di errore per SSID
Stabilite per iscritto dove l'autenticazione fallisce in modalità protetta (fail closed) e dove è accettabile un ripiego limitato. Gli SSID del personale con privilegi e i segmenti sensibili dovrebbero fallire in modalità protetta, poiché l'accesso aperto durante un'interruzione vanifica lo scopo dell'802.1X. I servizi operativamente critici possono giustificare un ripiego ben circoscritto e limitato nel tempo, ma questo deve essere segnalato, registrato e riesaminato.
- Fai un progetto pilota su una sede e un SSID: Verifica l'autenticazione, l'assegnazione della VLAN e la registrazione dei log con dispositivi reali, compreso l'hardware supportato piu datato.
- Simula i guasti intenzionalmente: Disabilita un account di test, revoca un certificato e simula la perdita dell'endpoint primario, quindi misura l'impatto sull'esperienza degli utenti.
- Misura la velocita di revoca: Cronometra quanto tempo un account Microsoft Entra ID o Okta disabilitato mantiene l'accesso alla rete e registra il risultato nel manuale operativo.
- Testa la strategia di uscita: Conferma di poter esportare la configurazione e i log e di poter reindirizzare gli access point verso un altro servizio senza dover ricostruire le policy da zero.
Gestire il servizio come un'infrastruttura critica
Monitora i tassi di successo e fallimento dell'autenticazione, lo stato degli endpoint e i picchi anomali per ciascuna sede. Esamina i log per individuare errori ripetuti da un singolo dispositivo, poiché spesso indicano una configurazione errata, un certificato scaduto o un tentativo di scansione della rete. Definisci la conservazione dei log, i requisiti di residenza dei dati nel Regno Unito e i tempi di risposta del supporto direttamente nel contratto, non durante una trattativa commerciale.
Non misurare il successo in base all'attivazione del protocollo 802.1X. Misura se l'isolamento funziona, se la revoca è rapida e se una sede degrada le sue prestazioni in modo prevedibile quando cade la connettività.
Verifica il rischio dei fornitori su base annuale, inclusi i sub-responsabili del trattamento e la provenienza dell'accesso al supporto. Mantieni un breve manuale operativo che un tecnico di turno possa seguire di notte senza il team di progetto. Se quel manuale non esiste, non disponi ancora di un modello operativo.
Punti chiave e prossimi passaggi
Un cloud radius server ha senso quando l'identità risiede già nel cloud, si gestiscono più sedi o il team non è in grado di gestire una coppia locale resiliente con uno standard elevato. Elimina la manutenzione del server e centralizza le policy. Non elimina tuttavia la responsabilità dell'utente per quanto riguarda segmentazione, revoca, registrazione dei log o pianificazione delle interruzioni di servizio.
Inoltre non costituisce una segmentazione di per sé. L'autenticazione stabilisce chi un dispositivo dichiara di essere. Le VLAN dinamiche, le policy basate sui ruoli e le regole del minimo privilegio stabiliscono cosa quel dispositivo può raggiungere - ed è necessario che entrambi gli elementi lavorino insieme.
Una breve checklist di valutazione
- Idoneita dell'identita: Integrazione nativa con la tua directory e gestione verificata dei processi di inserimento, cambio ruolo e uscita dei dipendenti.
- Gestione dei certificati: Emissione, rinnovo e revoca gestiti compatibili con il tuo parco dispositivi.
- Comportamento in caso di guasto: Blocco degli accessi (fail closed) per gli SSID sensibili, con qualsiasi soluzione di riserva limitata, registrata e circoscritta nel tempo.
- Conformita e tracciabilita: Log esportabili, residenza dei dati chiara, amministrazione basata sui ruoli e separazione tra tenant.
- Uscita: Esportazione di configurazioni e log, in modo che il cambio di provider sia un semplice progetto anziche una ricostruzione totale.
Inizia con un progetto pilota su una singola sede o SSID, misura il successo dell'autenticazione e la latenza di revoca, e interrompi l'integrazione di proposito prima che gli utenti ne dipendano. Scala solo quando i risultati diventano prevedibili. La prevedibilità è l'aspetto di una buona autenticazione in ambiente di produzione.
Purple fornisce RADIUS-as-a-Service per il WiFi ospiti, personale e multi-tenant, integrandosi con Entra ID, Google Workspace e Okta, consentendo di dismettere i server RADIUS on-premises e applicare un accesso coerente basato sull'identità in ogni sede. Se stai pianificando un progetto pilota o sostituendo una configurazione fragile NPS o FreeRADIUS, visita Purple per scoprire come il RADIUS gestito in cloud, Passpoint e l'isolamento per tenant funzionano con la tua infrastruttura Meraki, Aruba, Ruckus, Mist o UniFi esistente.
