Integrazione di RADIUS as a Service con directory cloud (Azure AD e Google Workspace)

Executive summary

Per le aziende moderne che investono in ecosistemi di identità cloud, collegare le directory cloud alle reti wireless fisiche è un imperativo di sicurezza fondamentale. Storicamente, l'autenticazione WiFi si basava su Active Directory Domain Services on-premise e Windows Network Policy Server (NPS). Con la migrazione delle organizzazioni a Microsoft Entra ID e Google Workspace, lo stack di autenticazione on-premise diventa un punto debole: costoso da mantenere, difficile da scalare e incompatibile con i modelli di sicurezza zero-trust.

RADIUS as a Service (RADIUSaaS) cambia le regole del gioco. Un server RADIUS ospitato nel cloud si integra direttamente con la directory cloud, convalida le richieste di autenticazione in tempo reale e restituisce le decisioni di accesso ai punti di accesso, senza server on-premise, senza cicli di patch e senza singoli punti di vulnerabilità. Combinata con l'autenticazione basata su certificati EAP-TLS, questa architettura elimina il furto di credenziali, supporta la conformità PCI DSS e GDPR e offre un'esperienza fluida per il personale in ogni sede.

Questa guida illustra la scelta architetturale tra NPS on-premise e RADIUS cloud-native, l'implementazione di EAP-TLS tramite Microsoft Intune e Google Admin Console, e le migliori pratiche operative per proteggere l'accesso wireless in hotel, punti vendita, stadi e spazi del settore pubblico. Per un'introduzione più ampia al controllo dell'accesso alla rete, consulta A Guide to Your Network Access Control System .

Approfondimento tecnico: architettura e standard

Il ruolo di RADIUS e IEEE 802.1X

La base di una rete WiFi aziendale sicura è lo standard IEEE 802.1X, che fornisce il controllo dell'accesso alla rete basato su porte. Quando un dispositivo client (il supplicant) tenta di connettersi a una rete WPA2-Enterprise o WPA3-Enterprise, l'Access Point wireless (l'authenticator) blocca tutto il traffico tranne i pacchetti EAP (Extensible Authentication Protocol). L'AP inoltra questi pacchetti a un server RADIUS. Il server RADIUS convalida l'identità rispetto a un servizio di directory e restituisce un messaggio di Access-Accept o Access-Reject. Solo a quel punto l'AP concede l'accesso alla rete.

Questo modello a tre parti - supplicant, authenticator, authentication server - è il pilastro della sicurezza wireless aziendale ed è definito nello standard IEEE 802.1X. Non è cambiato fondamentalmente dalla sua introduzione. Ciò che è cambiato è dove risiede il server RADIUS e come comunica con la directory.

Architettura RADIUS cloud-native

Un'architettura RADIUS cloud-native elimina la necessità di server NPS o FreeRADIUS on-premise. Un provider Cloud RADIUS di terze parti si integra direttamente con Microsoft Entra ID tramite Microsoft Graph API, oppure con Google Workspace tramite Google Secure LDAP o SAML/OAuth. L'autenticazione avviene interamente nel cloud. Questo si allinea con i principi di zero-trust network access e riduce significativamente i costi operativi.

La tabella seguente confronta i due principali approcci architetturali:

EAP-TLS vs. PEAP-MSCHAPv2: la scelta cruciale

La scelta del metodo EAP è la decisione di sicurezza più importante in questa implementazione. PEAP-MSCHAPv2 si basa sull'inserimento delle credenziali di dominio da parte degli utenti. Questo metodo è vulnerabile al furto di credenziali e agli attacchi man-in-the-middle. Se un dispositivo client non convalida rigorosamente il certificato del server RADIUS (e molti non lo fanno per impostazione predefinita), un utente malintenzionato può distribuire un access point fittizio con il tuo SSID, intercettare l'handshake EAP e catturare le credenziali. Questo è un attacco Evil Twin ed è ampiamente documentato.

EAP-TLS (Transport Layer Security) utilizza certificati digitali installati sul dispositivo client per l'autenticazione reciproca. Sia il client che il server dimostrano la propria identità in modo crittografico. Non ci sono password da digitare o rubare. In un ambiente Microsoft, i certificati vengono distribuiti in modo invisibile tramite Microsoft Intune utilizzando profili SCEP (Simple Certificate Enrollment Protocol) o PKCS. Questo è il percorso consigliato per tutte le nuove implementazioni ed è essenziale per la conformità a PCI DSS v4.0 (Requisito 8.3 sull'autenticazione forte) e agli obblighi di protezione dei dati del GDPR.

Google Workspace: la differenza architetturale

Microsoft Entra ID e Google Workspace differiscono in un aspetto importante per l'integrazione RADIUS. Microsoft NPS si integra nativamente con Active Directory e i provider Cloud RADIUS si connettono a Entra ID tramite Microsoft Graph API. Google, tuttavia, non offre un servizio RADIUS nativo. È sempre necessario un intermediario. Google Secure LDAP è il percorso di integrazione principale. Disponibile nelle edizioni Cloud Identity Premium e Google Workspace Enterprise, fornisce un'interfaccia LDAP tradizionale alla directory cloud. Il server Cloud RADIUS si connette a ldap.google.com sulla porta 636 utilizzando i certificati client generati da Google. Da quel momento, il server RADIUS interroga la directory di Google per convalidare le credenziali o l'appartenenza ai gruppi, esattamente come farebbe con un Active Directory on-premise.

Un percorso alternativo utilizza l'integrazione basata su SAML, in cui il provider Cloud RADIUS si registra come applicazione SAML nella Google Admin Console ed esegue una ricerca OAuth al momento dell'autenticazione per verificare l'identità dell'utente e l'appartenenza ai gruppi in tempo reale.

Guida all'implementazione

L'implementazione di RADIUSaaS con EAP-TLS richiede il coordinamento dell'identità, della gestione dei dispositivi e dell'infrastruttura di rete. Il seguente approccio in cinque fasi si applica sia agli ambienti Microsoft Entra ID che Google Workspace.

Fase 1: preparare l'infrastruttura di gestione delle identità e dei dispositivi

Per Microsoft Entra ID: verificare che il tenant disponga delle licenze Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5. Questo include Microsoft Intune e l'Accesso Condizionale. Senza Intune, la distribuzione automatizzata dei certificati non è possibile.

Per Google Workspace: confermare di disporre di Cloud Identity Premium o Google Workspace Enterprise per accedere a Google Secure LDAP. Se si prevede di utilizzare EAP-TLS sui Chromebook gestiti, assicurarsi che la Google Admin Console sia configurata per gestire i certificati dei dispositivi.

Stabilire la Public Key Infrastructure (PKI). Per le nuove distribuzioni, si raccomanda vivamente una PKI cloud-native fornita dal fornitore Cloud RADIUS. Le alternative includono Microsoft Cloud PKI (disponibile con la licenza Intune Suite) o una distribuzione ADCS on-premise esistente collegata tramite il Microsoft Intune Certificate Connector.

Fase 2: configurare la distribuzione dei certificati

Percorso Microsoft Intune: nell'interfaccia di amministrazione di Intune, creare un profilo di configurazione Trusted Certificate. Caricare il certificato della Root CA e distribuirlo ai gruppi di dispositivi di destinazione. Questo garantisce che i dispositivi client considerino attendibile il certificato presentato dal server RADIUS durante l'handshake TLS. Successivamente, creare un profilo SCEP Certificate. Per l'autenticazione basata sull'utente, impostare il Subject Name su CN={{UserPrincipalName}}. Per l'autenticazione basata sul dispositivo, utilizzare CN={{DeviceName}}. Impostare il Subject Alternative Name per includere l'User Principal Name o l'ID del dispositivo.

Percorso Google Admin Console: accedere a Dispositivi, quindi Reti, infine Certificati. Caricare la Root CA. Configurare un meccanismo di emissione dei certificati: una PKI cloud che supporti l'integrazione SCEP con Google Workspace, oppure il Google Cloud Certificate Connector che funge da proxy per le richieste a una Microsoft Certificate Authority on-premise. Distribuire la Root CA e i profili dei certificati client alle Unità Organizzative appropriate.

Fase 3: configurare l'integrazione Cloud RADIUS

Concedi al tuo provider Cloud RADIUS i permessi API necessari nel tenant della tua directory. Per Entra ID, questo richiede come minimo User.Read.All e GroupMember.Read.All tramite Microsoft Graph API. Alcuni provider richiedono anche Device.Read.All per i controlli di conformità dei dispositivi. Per Google Workspace tramite Secure LDAP, scarica il certificato client e la chiave dalla Google Admin Console e installali sul servizio RADIUS.

Definisci le tue policy di autenticazione all'interno del portale di gestione Cloud RADIUS. Una policy ben strutturata per un ambiente aziendale: "Consenti l'accesso se il certificato è rilasciato da [Trusted CA] E l'utente è un membro del gruppo [Corporate-WiFi-Users] E il dispositivo è contrassegnato come Conforme in Intune". Questo impone simultaneamente l'identità, l'appartenenza al gruppo e lo stato di salute del dispositivo.

Fase 4: configurare l'infrastruttura wireless

Nel controller LAN wireless o nella dashboard di gestione cloud - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet - aggiungi gli indirizzi IP del server Cloud RADIUS e i segreti condivisi come server di autenticazione RADIUS. Configura i server primario e secondario per la ridondanza. Imposta il timeout RADIUS a un minimo di cinque secondi per gestire la latenza di andata e ritorno del cloud.

Crea un nuovo SSID configurato per WPA2-Enterprise o WPA3-Enterprise. Per le distribuzioni nel settore Hospitality , assicurati che l'SSID aziendale si trovi su una VLAN separata da qualsiasi rete Guest WiFi . Per gli ambienti Retail , valuta la possibilità di distribuire l'SSID aziendale solo nelle aree riservate al personale.

Fase 5: distribuire il profilo WiFi tramite MDM

Microsoft Intune: crea un profilo di configurazione WiFi. Imposta l'SSID in modo che corrisponda esattamente alla configurazione della tua infrastruttura. Seleziona WPA2-Enterprise o WPA3-Enterprise. Nelle impostazioni EAP, seleziona EAP-TLS. Collega il profilo del certificato SCEP come certificato client e specifica il profilo della CA radice attendibile. Assegna questo profilo WiFi agli stessi gruppi di dispositivi che hanno ricevuto i profili dei certificati. I dispositivi ricevono silenziosamente il certificato e la configurazione WiFi durante la successiva sincronizzazione con Intune.

Google Admin Console: vai su Dispositivi, poi su Reti, quindi su Wi-Fi. Crea un nuovo profilo di rete WiFi. Imposta l'SSID, seleziona WPA3-Enterprise, scegli EAP-TLS e invia il certificato della CA radice attendibile ai dispositivi. Applica questo profilo alle tue Unità Organizzative. I Chromebook si connettono in modo silenzioso e sicuro.

Best practice

Imponi EAP-TLS in tutte le nuove distribuzioni. Non distribuire nuove reti utilizzando PEAP-MSCHAPv2. I rischi per la sicurezza sono ampiamente documentati e il percorso di migrazione è semplice con i moderni strumenti MDM.

Imponi una convalida rigorosa del certificato del server. Se devi utilizzare PEAP per i dispositivi legacy, configura i dispositivi per convalidare il certificato del server RADIUS. Nel profilo WiFi di Intune e nel profilo WiFi di Google Admin Console, è presente un campo per specificare la CA attendibile per la convalida del server. Non lasciare questo campo vuoto. Questa singola decisione di configurazione fa la differenza tra una distribuzione sicura e una vulnerabile.

Segmenta la tua rete con l'assegnazione dinamica della VLAN. Utilizza il tuo server RADIUS per controllare l'appartenenza ai gruppi dell'utente in Entra ID o Google Workspace e assegnarli dinamicamente a diverse VLAN. Il server RADIUS restituisce l'attributo Tunnel-Private-Group-Id all'access point, che posiziona il client sulla VLAN corretta. Ciò limita il movimento laterale in caso di violazione e supporta i requisiti di segmentazione della rete PCI DSS.

Separa l'autenticazione aziendale da quella degli ospiti. Utilizza EAP-TLS per i dispositivi gestiti dall'azienda. Utilizza un Captive Portal con SSO per i dispositivi BYOD e degli ospiti. Cercare di configurare manualmente EAP-TLS su dispositivi non gestiti crea un sovraccarico di supporto eccessivo. La piattaforma Guest WiFi di Purple gestisce l'onboarding degli ospiti separatamente, mantenendo una netta separazione tra il traffico del personale e quello dei visitatori.

Monitora la scadenza dei certificati in modo proattivo. Imposta il monitoraggio e gli avvisi a 90 giorni, 30 giorni e sette giorni prima della scadenza del certificato. Se il certificato del tuo server RADIUS scade, tutti i dispositivi perdono la connettività contemporaneamente. Automatizza il rinnovo laddove la tua PKI lo supporti.

Verifica le impostazioni di timeout RADIUS. Cloud RADIUS introduce una latenza di rete di andata e ritorno che l'NPS on-premise non presenta. Imposta il timeout RADIUS sui tuoi access point ad almeno cinque secondi. Un timeout di due secondi, comune nelle configurazioni predefinite, causerà errori di autenticazione intermittenti.

Risoluzione dei problemi e mitigazione dei rischi

Le porte del firewall bloccate sono la causa principale del fallimento della distribuzione iniziale. L'autenticazione RADIUS richiede la porta UDP 1812 in uscita dalla tua infrastruttura wireless verso il servizio Cloud RADIUS. L'accounting RADIUS richiede la porta UDP 1813. Verifica che queste porte siano aperte prima di procedere con qualsiasi altra risoluzione dei problemi.

I fallimenti della convalida del certificato si presentano come rifiuti di autenticazione senza una causa evidente. Controlla nell'ordine: la scadenza del certificato sia sul client che sul server RADIUS; il disallineamento dell'orologio (clock skew) tra il dispositivo client e il server RADIUS (EAP-TLS si basa su una misurazione precisa del tempo); e se il certificato della Root CA è stato distribuito correttamente sul dispositivo tramite MDM.

La mancata applicazione dell'appartenenza ai gruppi è un problema comune quando le policy RADIUS fanno riferimento ai gruppi di Entra ID o Google Workspace. Verifica che il provider Cloud RADIUS disponga delle autorizzazioni API corrette per leggere le appartenenze ai gruppi. In Entra ID, conferma che il service principal disponga di GroupMember.Read.All. In Google Workspace, conferma che il client Secure LDAP disponga dell'autorizzazione per leggere le informazioni sui gruppi.

L'assegnazione della VLAN non funziona indica in genere una mancata corrispondenza tra i valori degli attributi RADIUS e gli ID VLAN configurati sull'infrastruttura wireless. Verificare che Tunnel-Type sia impostato su VLAN (valore 13), Tunnel-Medium-Type sia impostato su 802 (valore 6) e Tunnel-Private-Group-Id corrisponda all'ID VLAN configurato sullo switch o sul controller.

I dispositivi BYOD che falliscono l'EAP-TLS indicano solitamente che il certificato client non è stato distribuito correttamente. Per i dispositivi gestiti da Intune, controllare l'archivio dei certificati del dispositivo nell'interfaccia di amministrazione di Intune. Per i Chromebook gestiti da Google, verificare che il profilo del certificato sia assegnato all'Unità Organizzativa corretta e che il dispositivo si sia sincronizzato di recente.

ROI e impatto aziendale

Il passaggio a Cloud RADIUS offre risparmi operativi misurabili. Il RADIUS on-premise richiede come minimo due server per l'alta affidabilità, l'applicazione continua di patch al sistema operativo, la gestione dei certificati e il tempo di tecnici specializzati. Il tempo dedicato da un singolo ingegnere alla manutenzione del RADIUS in un anno supera in genere il costo annuale di un abbonamento a Cloud RADIUS.

I vantaggi aziendali vanno oltre la riduzione dei costi. Collegando l'accesso alla rete a identità cloud verificate, si ottiene:

Offboarding istantaneo. La disattivazione di un utente in Entra ID o Google Workspace revoca immediatamente il suo accesso alla rete in tutte le sedi. Non ci sono ritardi, processi manuali o rischi che un ex dipendente mantenga l'accesso al WiFi. Ciò supporta direttamente gli obblighi del GDPR in materia di diritti di accesso ai dati.

Analisi più approfondite. Piattaforme come WiFi Analytics di Purple offrono dati più ricchi sull'utilizzo dello spazio e sui percorsi dei visitatori quando l'accesso alla rete è legato a identità autenticate. Si passa da indirizzi MAC anonimi a utenti nominativi e autenticati, il che trasforma la qualità delle informazioni a disposizione dei team operativi e di marketing.

Prove di conformità. L'autenticazione EAP-TLS genera registri di accesso dettagliati: chi si è connesso, da quale dispositivo, in quale luogo e a che ora. Questo percorso di audit supporta il requisito 10 del PCI DSS (registrazione e monitoraggio) e gli obblighi di responsabilità del GDPR.

Coerenza multi-sede. Un unico servizio Cloud RADIUS autentica tutte le sedi con policy coerenti, gestite da un'unica dashboard. Aggiungere un nuovo hotel, negozio o locale significa aggiungere i relativi punti di accesso alla configurazione RADIUS, non spedire e configurare un altro server. Per le organizzazioni che gestiscono grandi patrimoni immobiliari, questo rappresenta un vantaggio operativo significativo.

Per gli operatori del settore Trasporti e le strutture Sanitarie in cui il tempo di attività della rete è fondamentale dal punto di vista operativo, i provider Cloud RADIUS offrono in genere SLA di uptime del 99,999% con failover multi-regione integrato. Purple opera con un uptime del 99,999% in oltre 80.000 sedi attive, con 440 milioni di accessi elaborati nel 2024 (dati interni Purple, 2024).

Per approfondire argomenti correlati, consulta WAN Computer Definition: A Practical Guide for 2026 e World WiFi Day 2026: How Your Venue Can Help Bridge the Digital Divide .