Spostare il proprio server RADIUS nel cloud non costituisce, di per sé, una strategia di sicurezza WiFi. Il consiglio diffuso di sostituire FreeRADIUS o Windows NPS con un endpoint in hosting sorvola sulle questioni più complesse: di chi è l'identità che controlla l'accesso, come la perde chi lascia l'azienda e cosa succede quando la sede non riesce a raggiungere il servizio.
Il RADIUS as a service è principalmente utile come controllo della governance delle identità, non solo come semplice sostituzione di un server. Per le strutture e le aziende nel Regno Unito, la progettazione ideale combina spesso l'autenticazione del personale collegata alla directory con chiavi univoche per i dispositivi che non possono utilizzare la moderna autenticazione enterprise. Una migrazione basata unicamente sui certificati non è automaticamente l'opzione più solida.
Cosa cambia con il RADIUS as a Service per il WiFi
Il RADIUS as a service è un piano di controllo gestito in hosting per autenticazione, autorizzazione e accounting. Il tuo access point o controller WLAN rimane il punto di applicazione delle norme (enforcement point). Il servizio in hosting decide se ammettere un utente o un dispositivo e restituisce la policy di rete da applicare.
Confronto tra RADIUS on-premise, cloud e federato
| Modello | Chi gestisce AAA | Origine dell'identità | Failover e crescita | Soluzione ideale |
|---|---|---|---|---|
| FreeRADIUS o Windows NPS on-premise | Il tuo team applica le patch e monitora il servizio | Directory locale o un identity provider raggiunto tramite il tuo server | Applichi le patch, crei cluster e monitori ogni istanza, quindi configuri i siti aggiuntivi | Un singolo sito con competenze RADIUS interne |
| Cloud RADIUS as a service | Il provider applica le patch e monitora il servizio in hosting | Entra ID, Okta, Google Workspace o un altro identity provider supportato | Endpoint e SLA del provider, con nuovi siti aggiunti senza dover installare nuovi server di autenticazione | Strutture multi-sito senza un team dedicato a RADIUS |
| Proxy RADIUS federato | Operatori di proxy condivisi e identity provider di origine | Credenziali dell'organizzazione di origine | L'infrastruttura di proxy nazionale o condivisa collega i siti partecipanti | Utenti in roaming tra siti gestiti in modo indipendente |
Spostare il server non crea una struttura zero trust. La sicurezza si basa ancora su identità univoche, revoca tempestiva e una regola scritta che stabilisca se l'accesso fallisca in modalità aperta (fail-open) o chiusa (fail-closed) quando l'autenticazione non è disponibile.
Una passphrase WiFi condivisa non può identificare in modo affidabile una persona specifica. Né è possibile revocare le credenziali di un dipendente uscente senza dover cambiare la password a tutti gli altri. Inoltre, tenere gli ospiti lontani dai sistemi del personale richiede policy di rete, non soltanto una password diversa.
Separare il modello operativo dalla policy di accesso
L'hosting cloud cambia chi mantiene l'infrastruttura di autenticazione. In Purple gestiamo il cloud RADIUS che sostituisce FreeRADIUS o Windows NPS, eliminando i server di autenticazione on-premise che il tuo team dovrebbe altrimenti aggiornare o gestire in failover. Il tuo team mantiene comunque la piena titolarità delle regole di accesso, dei gruppi di directory e della struttura della rete locale.
La federazione risolve un problema diverso: consentire agli utenti di autenticarsi presso sedi gestite in modo indipendente. Secondo il briefing digestivo eduroam di Jisc, il servizio nel Regno Unito è stato lanciato il 2 maggio 2006, reindirizzando l'autenticazione dei visitatori al loro istituto di origine anziché richiedere ai siti visitati di gestire account ospiti locali. Si tratta di una gestione delegata delle identità, non di un semplice hosting remoto del server.
Regola pratica: Individua il modello corrispondente a chi gestisce le identità oggi, quindi decidi se tale titolarità debba cambiare.
L'autenticazione non è neanche una soluzione per una copertura radio insufficiente, la congestione o una connessione Internet debole. La guida di Madeira Remote su come migliorare il WiFi per videochiamate più fluide offre un contesto utile per separare l'ottimizzazione della qualità di connessione dalla gestione del controllo accessi. Correggere l'ammissione alla rete non risolverà il problema di un canale wireless sovraccarico.
La decisione è quindi sia operativa sia tecnica. È possibile esternalizzare la manutenzione del server mantenendo la responsabilità di stabilire esattamente chi accede a ciascuna rete.
Come Cloud RADIUS decide l'accesso
Un laptop aziendale gestito si connette a un SSID configurato per WPA2-Enterprise o WPA3-Enterprise. Anziché verificare la conoscenza di una passphrase valida per l'intero edificio, avvia uno scambio EAP (Extensible Authentication Protocol) tramite l'access point.
L'access point o il controller impacchetta lo scambio in una Access-Request RADIUS e la invia al servizio in hosting. Il protocollo EAP potrebbe richiedere diversi passaggi prima che il servizio disponga di informazioni sufficienti per prendere una decisione.
Testare separatamente le funzioni AAA
La documentazione dell'architettura FreeRADIUS del governo britannico descrive il servizio attraverso autenticazione, autorizzazione e accounting. Considera questi elementi come test di accettazione distinti, non come definizioni intercambiabili per un accesso riuscito.
- L'autenticazione stabilisce l'identità. Il servizio valuta la credenziale o il certificato utilizzando il metodo configurato. Un Access-Challenge prosegue lo scambio, un Access-Reject nega l'ammissione e un Access-Accept la autorizza.
- L'autorizzazione assegna le autorizzazioni. La risposta può includere una VLAN, un ruolo, una lista di controllo degli accessi (ACL) o un limite di sessione. Il controller deve interpretare ed applicare tali attributi.
- L'accounting registra la sessione. Raccoglie gli avvii di sessione, gli aggiornamenti intermedi e gli arresti con identificatori stabili di identità e dispositivo, marca temporale e ID di sessione.
Un messaggio di Access-Accept non dimostra che la segmentazione abbia funzionato. Ad esempio, se un consulente esterno si autentica con successo ma finisce sulla VLAN dei dipendenti perché il controller ignora l'attributo di ruolo, l'autenticazione è riuscita, ma la struttura di accesso ha fallito.
Allo stesso modo, l'esito dell'autenticazione nella dashboard di un provider non sostituisce l'accounting della sessione. Chi effettua analisi di sicurezza deve poter collegare un'identità a un dispositivo, a una struttura e a una sessione, identificando con precisione l'inizio e la fine dell'accesso.
Progettare la gestione per endpoint non raggiungibili
Configura endpoint di servizio ridondanti, monitoraggio dello stato di salute e timer di tentativi delimitati (retry timers). Tentativi infiniti possono lasciare i client in sospeso rendendo più complessa la diagnosi. Il nostro cloud RADIUS opera con failover multi-regione supportato da un SLA di disponibilità del 99,9%, ma la connettività della struttura e il comportamento del controller richiedono comunque test dedicati.
Definisci le regole di disservizio prima della messa in produzione. Il comportamento fail-open può ammettere dispositivi senza le verifiche previste, creando potenzialmente accessi privi di restrizioni. Il comportamento fail-closed nega invece i nuovi accessi, proteggendo il perimetro ma rischiando di interrompere i terminali di pagamento o altre apparecchiature operative.
Non dare per scontato che le sessioni esistenti e le nuove connessioni si comportino allo stesso modo durante un'interruzione. Testa separatamente l'autenticazione iniziale, la riautenticazione e il ripristino degli endpoint, richiedendo per iscritto gli impegni di disponibilità e la struttura del failover.
Concludi la fase pilota con prove tangibili e verificabili:
- Sessione accettata: Il client raggiunge la VLAN prevista e solo i servizi autorizzati.
- Identità disabilitata: Un nuovo tentativo di autenticazione riceve un rifiuto (reject).
- Accounting consultabile: Un amministratore può rintracciare successivamente il registro di sessione generato.
Controlli di sicurezza che un servizio in hosting deve dimostrare
Nel 2024, il 50% delle aziende del Regno Unito ha subito una violazione o un attacco informatico nei 12 mesi precedenti, con una percentuale superiore al 70% tra le medie e grandi imprese, secondo l'analisi su zero trust pubblicata da Consultancy.uk. Un servizio di login gestito in hosting non risolve da solo questa vulnerabilità.
Zero trust significa autenticare e autorizzare l'accesso anziché fidarsi di un dispositivo solo perché ha raggiunto l'SSID aziendale. Un servizio cloud può comunque applicare policy deboli se utilizza credenziali condivise, controlli dei dispositivi assenti o autorizzazioni troppo ampie.
Richiedere verifiche per ciascun perimetro
Inizia dalle credenziali, per poi analizzare il trasporto, l'amministrazione e l'applicazione delle regole. Ciascun livello presenta modalità di guasto differenti.
- Identità nominate: Utilizza account individuali o identità di dispositivo, con rimozione automatica gestita dalla directory anziché con elenchi di accesso aggiornati manualmente.
- Autenticazione avanzata del client: Prediligi l'autenticazione dei dispositivi basata su certificati per gli endpoint gestiti. Utilizza metodi resistenti al phishing ove supportati e richiedi la MFA per l'amministrazione e i flussi di onboarding pertinenti.
- Trasporto protetto: Proteggi il percorso tra controller e servizio con un trasporto crittografato adeguato, come RadSec o un tunnel sicuro. Un secret condiviso RADIUS da solo non crittografa l'intero scambio.
- Amministrazione separata: Mantieni le identità degli amministratori con privilegi separate dagli account operativi quotidiani e conserva un registro di audit (audit trail) di tutte le modifiche alle policy.
- Ruoli a privilegio minimo: Concedi al personale, ai consulenti esterni, alle apparecchiature mediche e ai sistemi di gestione dell'edificio esclusivamente l'accesso strettamente necessario.
Non dare per scontato che la richiesta MFA basata su browser di una directory cloud possa apparire all'interno di ogni scambio EAP. Il metodo EAP scelto, il software client e l'integrazione dell'identità devono supportare specificamente il flusso di autenticazione desiderato.
Verificare anche i controlli wireless e operativi
Configura la sicurezza wireless enterprise con la convalida del certificato server, l'autenticazione reciproca e i frame dati crittografati. Richiedi i Protected Management Frames (PMF) ove supportati e appropriati alla modalità WPA selezionata, anziché considerare l'etichetta enterprise come garanzia dell'attivazione di ogni protezione.
Per una progettazione più ampia delle policy, la nostra guida sulla sicurezza WiFi enterprise rappresenta un valido approfondimento. Il nostro WiFi del personale offre sicurezza di livello enterprise senza la complessità di un NAC, ma gli amministratori devono comunque definire i perimetri di accesso e monitorarne il funzionamento.
L'infrastruttura fisica rimane fondamentale anche quando l'autenticazione è gestita in hosting. Le indicazioni di ABCO Security Services Australia sul rafforzamento della sicurezza dei data center offrono un contesto complementare per la protezione delle strutture a supporto dei servizi di rete.
Una credenziale valida non dovrebbe concedere a un dispositivo l'autorizzazione ad accedere a qualsiasi risorsa all'interno dell'edificio.
Assegna un responsabile per gli avvisi di rifiuto (reject) ripetuti, le modifiche impreviste dei privilegi e le attività amministrative sospette. I log sono utili solo se c'è qualcuno in grado di interpretarli e di intervenire.
Collegare le directory senza creare un secondo archivio utenti
La directory autorevole deve rimanere l'unico punto in cui vengono gestiti lo stato occupazionale e l'appartenenza ai gruppi. Che si tratti di Entra ID, Okta o Google Workspace, l'integrazione RADIUS in hosting deve convertire l'identità in autorizzazioni di rete, senza creare un database di password isolato.
Il metodo di integrazione è fondamentale. Un connettore può sincronizzare i gruppi, convalidare le credenziali tramite un meccanismo supportato o associare certificati alle identità di directory. Non dare per scontato che tutte le directory cloud espongano la stessa interfaccia di convalida delle password.
Gestire i flussi di ingresso, cambio ruolo e uscita (joiner, mover, leaver)
Consideriamo un nuovo dipendente che entra nel team dei servizi generali (facilities). Una volta confermata l'appartenenza alla directory e registrato il dispositivo, il servizio dovrebbe assegnare direttamente il ruolo di rete corrispondente, senza che l'amministratore debba creare un account WiFi separato.
Quando il dipendente passa al reparto finanza, la modifica nella directory deve riflettersi nella VLAN o ACL appropriata alla successiva valutazione delle policy. Un'architettura efficace elimina la necessità di modificare i singoli controller, ma deve specificare chiaramente la frequenza di aggiornamento delle appartenenze in cache e delle sessioni attive.
Per un dipendente uscente, la disattivazione dell'account di directory deve impedire le autenticazioni successive entro una finestra temporale concordata. Il meccanismo di Change of Authorisation (CoA) può disconnettere o modificare una sessione attiva se il controller lo supporta e l'integrazione lo attiva. Le distribuzioni basate su certificati richiedono inoltre una procedura esplicita per la revoca dei certificati o per la verifica dello stato dell'identità.
Condizione di accettazione: Stabilisci la tempistica con cui una modifica nella directory influisce sulle nuove autenticazioni e sulle sessioni attive. Testa entrambi gli scenari, anziché accettare la dicitura “automatico” come impegno temporale.
Il principio del controllo degli accessi e dell'identità dell'NCSC raccomanda di verificare e autorizzare utenti, dispositivi e sistemi prima di concedere l'accesso. Applicato al WiFi, questo trasforma la gestione del ciclo di vita in un requisito di sicurezza, anziché in una semplice comodità di onboarding.
Verificare il perimetro dell'integrazione
Il CoA, i ruoli dinamici e le funzionalità di walled garden dipendono dal controller presente nella struttura. Nelle infrastrutture con apparati Meraki, Aruba, Ruckus, Mist e UniFi, occorre verificare il modello esatto, il firmware e le funzionalità supportate anziché basarsi unicamente sul nome del produttore.
I laptop aziendali gestiti possono utilizzare l'EAP-TLS o un altro metodo enterprise senza password supportato. Gli ospiti non dovrebbero seguire lo stesso percorso di certificato dei dispositivi gestiti. L'SSO trova la sua collocazione ideale nella console amministrativa e nei flussi di onboarding idonei del personale, ma non sostituisce l'802.1X sul collegamento wireless.
Per un'implementazione incentrata su Entra, consulta la nostra panoramica sull'integrazione con Entra ID per definire i requisiti di identità. Esegui quindi un breve test del ciclo di vita:
- Nuovo ingresso (joiner): Un nuovo utente configurato correttamente deve potersi connettere.
- Cambio ruolo (mover): Una modifica di gruppo deve generare il ruolo di rete previsto.
- Uscita (leaver): Un account disabilitato all'ora di test registrata deve negare l'accesso entro la finestra di revoca concordata.
Modelli di accesso per ospiti, personale e contesti multi-tenant
Un edificio ospita diverse tipologie di utenti con perimetri di fiducia differenti. Un ospite di un hotel, un laptop di un dipendente e il televisore di un inquilino non dovrebbero condividere la stessa policy di accesso solo perché utilizzano gli stessi access point.
Scegli il profilo utente prima di definire la relativa schermata di onboarding. Il metodo deve essere compatibile con il dispositivo, mentre la rete deve impedire l'accesso a utenti e sistemi non correlati.
Modello di accesso per tipologia di utente
| Tipologia utente | Metodo di autenticazione | Isolamento | Modalità di termine dell'accesso |
|---|---|---|---|
| Ospite/Visitatore | Email o identità monouso, con crittografia dove viene utilizzato Passpoint o modalità enterprise | Ruolo od VLAN ospite senza instradamento verso il personale | Scadenza della sessione o policy del portale |
| Personale e dispositivi gestiti | Identità di directory tramite EAP, spesso certificati o autenticazione enterprise senza password | Ruolo, VLAN o ACL derivati dal gruppo di directory | Disabilitazione nella directory, oltre a CoA se supportato dal controller |
| Consulente / Partner esterno | Gruppo di directory con scadenza temporale | Ruolo restrittivo, non la VLAN completa del personale | Scadenza del gruppo o termine della richiesta (ticket) |
| Dispositivi legacy e IoT | PSK univoca o altra credenziale a raggio d'azione limitato | Segmento dedicato senza percorsi laterali oltre ai servizi esplicitamente autorizzati | Rotazione della chiave o scollegamento dal proprietario |
| Residente multi-tenant | PSK univoca per persona o per unità abitativa | Rete privata isolata dagli altri inquilini | Revoca della chiave al momento del rilascio dell'immobile |
Mantenere separati l'onboarding semplificato e l'accesso ad ampi permessi
Gli ospiti necessitano di un onboarding immediato, spesso basato sull'inserimento dell'email. Tuttavia, una splash page non crittografa di per sé la connessione wireless. Seleziona un metodo di accesso crittografato ove supportato e non considerare il completamento della procedura sul portale come un'autorizzazione ad accedere ai sistemi interni.
Il personale necessita di un'autenticazione enterprise collegata alla directory. I consulenti esterni richiedono una data di scadenza e un ruolo più restrittivo, anche quando lavorano a fianco dei dipendenti aziendali. Assegna ai responsabili operativi l'onere di estendere l'accesso ai consulenti anziché lasciare gli account attivi a tempo indeterminato.
Gli residenti e i tenant commerciali hanno un'ulteriore esigenza: i propri dispositivi devono poter comunicare tra loro senza risultare visibili ai vicini. La nostra guida al WiFi multi-tenant approfondisce questo specifico modello di rete privata.
Utilizzare chiavi univoche per i dispositivi con vincoli tecnici
Stampanti, TV, console e scanner potrebbero non supportare il metodo EAP richiesto. Una chiave precondivisa univoca, spesso chiamata iPSK o xPSK, consente di associare l'accesso a una persona, a un'abitazione o a un dispositivo specifico senza dover ripristinare una password valida per l'intero edificio.
La chiave da sola non garantisce l'isolamento. Il controller e la rete devono mapparla sul segmento privato previsto e applicare i percorsi autorizzati. Considera la credenziale come trasferibile, registra il relativo proprietario e revocala quando la titolarità termina.
Forniamo WiFi per ospiti, sicurezza 802.1X per il WiFi del personale e Private Area Network xPSK su un'unica piattaforma cloud. Il nostro xPSK e WiFi multi-tenant offre a ciascun residente, tenant o dispositivo una chiave univoca con isolamento completo, inclusa la connettività privata per TV e console prive di browser.
Per i gestori del settore residenziale, è fondamentale coordinare l'uscita digitale dell'utente con la revoca degli accessi fisici. Il sistema di controllo accessi ai varchi per complessi residenziali di Nimbio rappresenta un esempio utile per gestire la titolarità delle credenziali dei residenti. Né l'accesso al varco né la chiave di rete di un ex residente dovrebbero rimanere attivi dopo la partenza.
Come effettuare la migrazione senza ricorrere a una password condivisa di riserva
Una migrazione deve dimostrare che ciascun gruppo di dispositivi sia in grado di connettersi in modo sicuro prima di disattivare la configurazione precedente. L'errore operativo consiste nel considerare ogni eccezione come un pretesto per mantenere una password di emergenza per l'intero edificio.
La necessità di una pianificazione accurata va oltre il WiFi: il report di Cyber Magazine su un'indagine Hiscox indica che due terzi delle aziende interpellate pianificano di implementare un'architettura zero trust entro il 2030. Si tratta di un'intenzione futura dichiarata, non della prova che le loro reti attuali soddisfino già questo modello.
Eseguire la migrazione secondo una sequenza controllata
- Classifica i client. Separa gli endpoint del personale compatibili con 802.1X, gli apparati legacy o privi di browser e gli ospiti. Record device ownership and operational criticality.
- Verifica le funzionalità del controller. Conferma il supporto all'autenticazione enterprise, alle VLAN o ai ruoli dinamici, al CoA e a eventuali walled garden richiesti. Controlla il firmware installato, non solo la famiglia di prodotti.
- Avvia un progetto pilota su un SSID limitato in un sito selezionato. Collegalo alla directory e documenta il comportamento fail-closed. Includi un dispositivo operativo rappresentativo, non solo un laptop dell'IT.
- Configura i dispositivi gestiti del personale. Utilizza certificati o un metodo enterprise senza password supportato. Il nostro WiFi del personale funziona sugli access point esistenti senza richiedere la creazione di una PKI dedicata.
- Assegna credenziali con ambito limitato ai dispositivi con vincoli tecnici. Genera PSK univoche per stampanti, apparecchiature mediche e dispositivi IoT ove opportuno. Autorizza solo le destinazioni strettamente necessarie.
- Maintieni gli ospiti su una policy separata. Verifica che i dispositivi ospiti non possano raggiungere le risorse del personale, anche se onboarding e autenticazione condividono la stessa piattaforma di gestione.
- Testa le procedure di gestione delle interruzioni. Interrompi separatamente l'accesso all'identity provider e la connettività Internet della struttura. Dimostra il ripristino senza distribuire una password generica.
- Completa il passaggio in modo progressivo. Analizza l'accounting, la segmentazione e il comportamento dei client in ciascun sito. Rimuovi la vecchia passphrase solo dopo il superamento dei test di accettazione concordati.
Sapere quando non conviene effettuare il passaggio
I siti isolati dalla rete esterna (air-gapped) non possono fare affidamento su un piano di controllo in cloud. I controller non in grado di elaborare gli attributi RADIUS richiesti potrebbero inoltre ostacolare l'architettura prevista, anche qualora l'autenticazione di base funzioni correttamente.
Eventuali requisiti interni che impongono di conservare i metadati di autenticazione nel Regno Unito devono essere gestiti verificando le sedi di elaborazione documentate e gli accordi con i subfornitori. Tale requisito non si considera soddisfatto semplicemente dal fatto che il provider possieda un ufficio nel Regno Unito. La conservazione dei registri, l'accesso amministrativo e i piani di ripristino devono far parte della procedura di approvazione degli acquisti.
Il nostro servizio opera come un overlay cloud sugli access point esistenti, senza richiedere la sostituzione dell'hardware (rip-and-replace). Il nostro xPSK e WiFi multi-tenant supporta hardware Meraki, Aruba, Ruckus e UniFi, in base alle funzionalità del controller richieste dal progetto.
Un approccio ibrido basato su autenticazione enterprise e chiavi univoche risolve la compatibilità dei client, ma non elimina necessariamente la dipendenza da eventuali interruzioni del cloud. Laddove l'autonomia locale sia fondamentale, è preferibile mantenere una struttura di autenticazione locale adeguata o rimanere su un'architettura on-premise. Non mascherare un requisito di resilienza non risolto ricorrendo a una password di eccezione.
Stabilire se Cloud RADIUS è adatto alla tua infrastruttura
Scegli il cloud RADIUS quando più siti necessitano di un accesso coerente basato sulle identità e il tuo team vuole evitare la manutenzione dei server di autenticazione. Il vantaggio principale è operativo: le modifiche nella directory devono governare l'accesso alla rete senza generare ulteriori carichi di lavoro per la gestione degli account.
Rimani on-premise se il tuo team gestisce già in modo efficiente ed elevata resilienza l'infrastruttura RADIUS, se un servizio in hosting contrasta con i requisiti di elaborazione dei dati o se il controller non è in grado di applicare la policy proposta. Una migrazione che elimina un server ma riduce la disponibilità locale non rappresenta un progresso.
Prendere decisioni basate sull'inventario dell'infrastruttura
Scegli un modello di accesso ibrido quando gli endpoint gestiti del personale supportano l'802.1X ma l'edificio ospita anche TV, stampanti, scanner o apparecchiature mediche che richiedono chiavi ad ambito limitato. L'obiettivo è garantire un livello di sicurezza adeguato per ciascun gruppo di utenti, non applicare credenziali identiche a tutti i dispositivi.
Crea un inventario dettagliato che includa:
- Infrastruttura wireless: SSID, produttore del controller, modello e versione del firmware.
- Gestione delle identità: Directory autorevole, responsabili dei gruppi e procedura di gestione degli utenti in uscita (leaver).
- Capacità dei client: Quali dispositivi supportano l'uso dei certificati e quali no.
- Dipendenze operative: Sistemi che devono rimanere operativi anche in caso di perdita di connettività.
Confrontare gli impegni scritti, non le semplici dimostrazioni
Poni le stesse domande a ciascun provider selezionato: cosa copre l'impegno di disponibilità in caso di guasti multi-sito, per quanto tempo vengono conservati i log, dove vengono elaborati i metadati di autenticazione, quali subfornitori possono accedervi e in che modo la procedura di ripristino evita il ricorso a una password condivisa di riserva?
Inserisci Purple tra i provider candidati se la tua infrastruttura risponde alle esigenze di ospiti, personale e contesti multi-tenant. Supportiamo questi ambienti dal 2012 presso catene retail, strutture sanitarie, stadi, snodi di trasporto e centri urbani. I prezzi per il nostro WiFi del personale non sono pubblicati online: contattaci per richiedere un preventivo personalizzato in base all'infrastruttura da migrare.
Il passo successivo consiste nella definizione di un piano di accettazione basato sull'inventario reale. Una dimostrazione impeccabile non può mai sostituire il superamento dei test pratici condotti sui tuoi controller, sulla tua directory e sui tuoi dispositivi più complessi.
Purple offre un servizio RADIUS in hosting per l'autenticazione del personale, integrato con WiFi per ospiti e accessi isolati multi-tenant. Visita il sito Purple disponendo dell'inventario dei tuoi controller, dei requisiti dell'identity provider e dell'elenco dei dispositivi legacy per valutare l'architettura e la quotazione più adatte alla tua infrastruttura.
