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

Sintesi esecutiva

Per le imprese moderne che hanno investito in ecosistemi di identità cloud, collegare le directory cloud con le 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). Man mano che le organizzazioni migrano a Microsoft Entra ID e Google Workspace, lo stack di autenticazione on-premise diventa un fattore di rischio: costoso da mantenere, difficile da scalare e incompatibile con i modelli di sicurezza zero-trust.

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

Questa guida illustra la decisione 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 retail, stadi e strutture 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 della sicurezza WiFi aziendale è 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, server di autenticazione - è la pietra angolare della sicurezza wireless aziendale ed è definito nello standard IEEE 802.1X. Non ha subito modifiche sostanziali dalla sua introduzione. Ciò che è cambiato è la collocazione del server RADIUS e il modo in cui comunica con la tua directory.

Architettura RADIUS cloud-native

Un'architettura RADIUS nativa del cloud 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, o con Google Workspace tramite Google Secure LDAP o SAML/OAuth. L'autenticazione avviene interamente nel cloud. Questo si allinea con i principi di accesso alla rete zero-trust e riduce significativamente i costi operativi.

La tabella seguente confronta i due principali approcci architetturali:

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

La scelta del metodo EAP è la singola 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 non autorizzato 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 silenziosamente 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 su Cloud Identity Premium e sulle edizioni Google Workspace Enterprise, fornisce un'interfaccia LDAP tradizionale per la tua directory cloud. Il tuo server Cloud RADIUS si connette a ldap.google.com sulla porta 636 utilizzando certificati client che Google genera per te. Da quel momento, il server RADIUS interroga la directory di Google per convalidare le credenziali o l'appartenenza ai gruppi, proprio 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 di identità, gestione dei dispositivi e infrastruttura di rete. Il seguente approccio in cinque fasi si applica sia agli ambienti Microsoft Entra ID che a quelli Google Workspace.

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

Per Microsoft Entra ID: verifica che il tuo tenant disponga della licenza Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5. Questo include Microsoft Intune e Conditional Access. Senza Intune, la distribuzione automatizzata dei certificati non è possibile.

Per Google Workspace: conferma di avere Cloud Identity Premium o Google Workspace Enterprise per accedere a Google Secure LDAP. Se hai intenzione di utilizzare EAP-TLS sui Chromebook gestiti, assicurati che la Google Admin Console sia configurata per gestire i certificati dei dispositivi.

Stabilisci la tua Public Key Infrastructure (PKI). Per le nuove distribuzioni, si raccomanda caldamente una PKI cloud-native fornita dal tuo fornitore Cloud RADIUS. Le alternative includono Microsoft Cloud PKI (disponibile con 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: nel centro amministrativo di Intune, crea un profilo di configurazione Trusted Certificate. Carica il certificato della Root CA e distribuiscilo ai gruppi di dispositivi target. Questo assicura che i dispositivi client considerino attendibile il certificato presentato dal server RADIUS durante l'handshake TLS. Successivamente, crea un profilo SCEP Certificate. Per l'autenticazione basata su utente, imposta il Subject Name su CN={{UserPrincipalName}}. Per l'autenticazione basata su dispositivo, usa CN={{DeviceName}}. Imposta il Subject Alternative Name per includere l'User Principal Name o l'ID del dispositivo.

Percorso Google Admin Console: naviga su Dispositivi, poi Reti, quindi Certificati. Carica la tua Root CA. Configura 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 verso una Certificate Authority Microsoft on-premise. Distribuisci la Root CA e i profili dei certificati client alle Unità Organizzative appropriate.

Fase 3: configurare l'integrazione Cloud RADIUS

Assegna al tuo provider Cloud RADIUS le autorizzazioni API necessarie nel tuo tenant di directory. Per Microsoft Entra ID, ciò 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 LDAP sicuro, scarica il certificato client e la chiave dalla Google Admin Console e installali sul servizio RADIUS.

Definisci i tuoi criteri di autenticazione all'interno del portale di gestione del Cloud RADIUS. Un criterio ben strutturato per un ambiente aziendale: "Consenti l'accesso se il certificato è emesso da [CA attendibile] E l'utente è un membro del gruppo [Corporate-WiFi-Users] E il dispositivo è contrassegnato come Conforme in Intune." Questo impone contemporaneamente 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 server primari e secondari per la ridondanza. Imposta il timeout RADIUS a un minimo di cinque secondi per accogliere la latenza di andata e ritorno del cloud.

Crea un nuovo SSID configurato per WPA2-Enterprise o WPA3-Enterprise. Per le installazioni in ambito Hospitality, assicurati che l'SSID aziendale si trovi su una VLAN separata da qualsiasi rete Guest WiFi. Per gli ambienti Retail, considera di distribuire l'SSID aziendale solo nelle aree del retrobottega.

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 dell'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 in modo silenzioso il certificato e la configurazione WiFi durante la successiva sincronizzazione di Intune.

Google Admin Console: vai su Dispositivi, poi su Reti, quindi su WiFi. 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 installazioni. 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.

Applica una validazione rigorosa dei certificati 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 un'implementazione sicura e una vulnerabile.

Segmenta la tua rete con l'assegnazione dinamica delle VLAN. Utilizza il tuo server RADIUS per esaminare l'appartenenza ai gruppi dell'utente in Entra ID o Google Workspace e assegnarli in modo dinamico 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 compromissione 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. Il 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 dell'implementazione iniziale. L'autenticazione RADIUS richiede la porta UDP 1812 in uscita dall'infrastruttura wireless al servizio Cloud RADIUS. L'accounting RADIUS richiede la porta UDP 1813. Verifica che queste siano aperte prima di qualsiasi altra risoluzione dei problemi.

I fallimenti di 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 tra il dispositivo client e il server RADIUS (EAP-TLS si affida a una misurazione precisa del tempo); e se il certificato della CA radice è stato distribuito correttamente al 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. La mancata assegnazione della VLAN indica in genere una discrepanza 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'autenticazione 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 nel centro di amministrazione 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 un sistema RADIUS cloud offre risparmi operativi misurabili. Un server RADIUS on-premise richiede come minimo due server per garantire l'alta affidabilità, l'applicazione continua di patch del sistema operativo, la gestione dei certificati e il tempo di un tecnico specializzato. Il tempo impiegato da un singolo tecnico per la manutenzione di un RADIUS nel corso di un anno supera in genere il costo annuale di un abbonamento a un RADIUS cloud.

I vantaggi commerciali 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 WiFi. Questo supporta direttamente gli obblighi previsti dal GDPR relativi ai diritti di accesso ai dati.

Analisi più approfondite. Piattaforme come WiFi Analytics di Purple forniscono dati più dettagliati sull'utilizzo degli spazi e sui percorsi dei visitatori quando l'accesso alla rete è associato a identità autenticate. Si passa da indirizzi MAC anonimi a utenti autenticati e identificati, trasformando la qualità dei dati a disposizione dei team di marketing e operations.

Prove di conformità. L'autenticazione EAP-TLS genera log di accesso dettagliati - chi si è connesso, da quale dispositivo, in quale luogo e a che ora. Questa traccia di audit supporta il requisito 10 del PCI-DSS (registrazione e monitoraggio) e gli obblighi di accountability previsti dal GDPR.

Coerenza tra più sedi. Un unico servizio RADIUS cloud autentica tutte le sedi con policy coerenti, gestite da un'unica dashboard. Aggiungere un nuovo hotel, negozio o spazio per eventi significa semplicemente aggiungere i suoi access point alla configurazione RADIUS, senza dover 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 per le strutture sanitarie del settore Healthcare, dove l'uptime della rete è fondamentale dal punto di vista operativo, i provider RADIUS cloud 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.