Onboarding BYOD: Come configurare l'accesso di dipendenti e ospiti

Un nuovo dipendente arriva con uno smartphone personale, un consulente esterno si presenta con un laptop più datato e un ospite ha bisogno del WiFi WiFi prima che inizi una riunione. Se tutti e tre ricevono la stessa password condivisa, l'accesso è facile da distribuire ma difficile da controllare in seguito. L'onboarding BYOD funziona meglio quando si sceglie un percorso per ciascun tipo di dispositivo, pianificando poi cosa accade quando qualcuno non può o non vuole registrarlo.

La chiave consiste nel considerare l'onboarding come un ciclo di vita. Una pagina di accesso può registrare chi si è connesso, ma non stabilisce se un dispositivo sia sicuro, non decide cosa possa raggiungere e non garantisce che il suo accesso possa essere revocato.

Sommario

• Scelta di un metodo di onboarding BYOD
  • Scegliere l'opzione predefinita prima dell'eccezione
• Configurare il portale captive e l'accesso SSO
  • Creare e testare il flusso di accesso
• Emettere certificati EAP-TLS tramite MDM
  • Rendere la trust del dispositivo parte dell'associazione
• Onboarding senza MDM e chiavi per singolo dispositivo per dispositivi condivisi
  • Utilizzare un pass o una chiave con un proprietario definito
• Percorsi di fallback per dispositivi non supportati e parzialmente gestiti
  • Mantenere l'eccezione circoscritta e documentata
• Regole sul consenso, sulla privacy e sull'offboarding
• Confermare l'ordine dei percorsi ed effettuare prima un pilot
  • Definire le metriche del pilot prima del lancio

Scelta di un metodo di onboarding BYOD

Metodo	Gestione dispositivi necessaria	Credenziale emessa	Ideale per	Limitazione principale
Portale captive con SSO, Google, Apple, Facebook o SMS	Nessuna	Sessione browser con consenso registrato	Ospiti e visitatori occasionali	L'accesso al portale non dimostra la conformità del dispositivo
Certificato EAP-TLS emesso da MDM tramite SCEP	MDM iscritto come Intune o Jamf Pro	Certificato per dispositivo	Telefoni e laptop aziendali gestiti	I dispositivi personali non iscritti non possono accedere
Pass WiFi installato tramite app senza MDM	App di installazione, nessun MDM	Pass per utente o per dispositivo	Addetti alle pulizie, personale interinale, telefoni personali	Minore visibilità sulla conformità del dispositivo
Chiave xPSK per dispositivo	Nessuna sul dispositivo	Chiave precondivisa univoca per dispositivo	Casse condivise, IoT, residenti	Richiede la gestione delle chiavi e una procedura di revoca
Profilo Passpoint o OpenRoaming	Profilo installato sul dispositivo	Identità basata su certificato	Ospiti abituali in più sedi	Solo dispositivi che supportano Passpoint

Questi percorsi si adattano a diversi livelli di affidabilità e a differenti aspettative degli utenti. Un portale via browser mantiene semplice l'accesso degli ospiti, ma non può verificare lo stato di sicurezza di uno smartphone. Un certificato fornisce a un dispositivo gestito un'identità più solida al momento della connessione, ma richiede la registrazione. Per i dispositivi che non possono accettare un profilo MDM, un pass o una chiave univoca offrono un'alternativa a una password condivisa nell'intera sede.

Il BYOD è diventato un requisito per il controllo degli accessi quando i dispositivi personali sono entrati nel lavoro quotidiano. In un'indagine IBSG del 2012 firmata Cisco condotta su 600 leader IT e aziendali statunitensi, il 95% ha dichiarato che la propria organizzazione consentiva in qualche forma i dispositivi di proprietà dei dipendenti, e l'84% consentiva i dispositivi personali fornendo al contempo almeno un minimo di supporto (studio BYOD 2012 di Cisco). Tale distinzione è importante: consentire a un dispositivo l'accesso al WiFi non equivale a supportarlo, ad assegnargli un accesso appropriato o a prepararsi a rimuoverne le credenziali.

Scegliere la regola predefinita prima dell'eccezione

Iniziare assegnando un percorso predefinito a ciascuna classe di dispositivi. I dispositivi gestiti del personale dovrebbero utilizzare i certificati; gli ospiti dovrebbero utilizzare un portale; i dispositivi privi di MDM dovrebbero ottenere un pass installato tramite app o una chiave univoca, non una password condivisa. Per gli ospiti abituali potrebbero essere adatti i profili Passpoint o OpenRoaming, qualora i loro dispositivi li supportino.

Verificare quindi se l'opzione predefinita scelta richiede qualcosa che un utente non fornirà, come l'autorizzazione a gestire uno smartphone personale. Inviare ai percorsi di fallback solo tali eccezioni, piuttosto che indebolire l'opzione predefinita per tutti. Una WiFi panoramica sul controllo degli accessi può aiutare i team a mappare l'autenticazione sulla politica di accesso, ma le classi di dispositivi e le autorizzazioni di rete dovrebbero guidare la scelta finale.

Configurare il portale captive e l'accesso SSO

Un portale captive è una scelta predefinita pratica per gli ospiti, poiché consente di accedere senza installare un profilo di gestione. È utile anche quando occorre registrare il consenso o consentire ai visitatori di autenticarsi utilizzando un account già in loro possesso. La decisione di progettazione fondamentale riguarda la destinazione a cui il portale reindirizza ciascun utente dopo l'accesso: l'autenticazione deve condurre alla rete corretta, non concedere un accesso ampio per impostazione predefinita.

Creare e testare il flusso di accesso

1. Mappare la rete e scegliere un sito pilota. Durante una sessione di progettazione, mappare punti di accesso, SSID, gruppi di directory e classi di dispositivi su reti aperte, sicure e xPSK. Un ingegnere di rete deve fornire al team un piano e un sito pilota, in modo che la configurazione rifletta la struttura fisica piuttosto che un diagramma idealizzato.

2. Registrare un'applicazione di identità. Configurare un'applicazione in Entra ID, Google Workspace o Okta e concedere l'accesso alla directory richiesto per l'accesso. Utilizzare prima una registrazione pilota, in modo da poter verificare le autorizzazioni e l'esperienza di accesso prima di estendere il deployment.

3. Aggiungere i dettagli del portale e della soluzione RADIUS al controller. Configurare il server RADIUS e l'URL della splash page. Una volta creata la registrazione dell'app, la configurazione lato cliente richiede meno di 15 minuti, incluse le modifiche al controller.

4. Scegliere i metodi di accesso per ciascun pubblico. Utilizzare SSO per il personale che necessita di un'identità aziendale, Google o Apple per gli account personali e Facebook dove i visitatori se lo aspettano. I passcode monouso tramite SMS offrono un'ulteriore opzione ai visitatori privi di un account idoneo.

5. Personalizzare il portale con il proprio brand e rendere chiaro il consenso. Redigere il testo del consenso in un linguaggio semplice e registrare una voce per ogni accesso. Inserire l'informativa dove l'utente possa leggerla prima di accettare, non al di sotto del pulsante da premere.

6. Testare dispositivi reali sulla rete ospiti. Connettere un iPhone personale, uno smartphone Android e un laptop Windows. Confermare che ciascun utente atterri sulla rete ospiti VLAN e che l'isolamento dei client impedisca ai dispositivi ospiti di raggiungersi tra loro.

I soliti errori nelle fasi pilota sono una splash URL che punta al controller errato, il testo del consenso nascosto sotto il pulsante di accesso ed effettuare i test solo con dispositivi aziendali. Ciascuno di questi fattori può far sembrare un portale riuscito in un test ristretto, ma fallimentare per le persone che ne hanno bisogno. I team che utilizzano Okta possono anche consultare questa guida all'autenticazione Okta WiFi durante la pianificazione della connessione di identità.

Emettere certificati EAP-TLS tramite l'MDM

Per i dispositivi aziendali gestiti dal personale, un accesso basato su certificato vincola l'accesso alla rete a un dispositivo registrato invece di basarsi su una password WiFi condivisa. Il dispositivo dimostra la propria identità durante la connessione e l'identità dell'utente può determinare quali autorizzazioni di rete applicare. Il NIST descrive un certificato fornito come un modo per identificare e autenticare un dispositivo mobile al punto di connessione e rileva che la combinazione con le credenziali dell'utente può fornire un'autenticazione a due fattori (linee guida del NIST sulla sicurezza dei dispositivi mobili).

La scalabilità rappresenta raramente un problema in questo contesto. L'invio dei certificati tramite SCEP richiede da cinque a dieci minuti una sola volta per l'intera organizzazione, consentendo così ai laptop e agli smartphone gestiti di ricevere il certificato dall'MDM e di connettersi automaticamente la notte del passaggio finale. La parte più complessa consiste nel decidere quali controlli un dispositivo debba superare affinché tale certificato sia ritenuto affidabile.

Rendere l'affidabilità dei dispositivi parte integrante dell'accesso

1. Autenticare l'utente. Iniziare con SSO o con un altro fattore approvato, in modo che la rete possa associare un dispositivo a una persona o a un account noto.

2. Verificare l'iscrizione e la posture. Confermare che il dispositivo sia iscritto e soddisfi i requisiti minimi del sistema operativo e di sicurezza dell'organizzazione. Trattare un dispositivo di proprietà personale come potenzialmente non attendibile finché non supera tali controlli.

3. Emettere un certificato vincolato al dispositivo. Utilizzare l'MDM per distribuire il certificato tramite SCEP. Una credenziale vincolata al dispositivo è più gestibile rispetto a un segreto condiviso, poiché può essere collegata a un singolo endpoint iscritto e revocata senza modificare altri elementi.

4. Connettersi utilizzando EAP-TLS. Configurare il client e la rete per convalidare i certificati pertinenti. Le credenziali dell'utente e il certificato del dispositivo forniscono quindi controlli di identità distinti al momento della connessione.

5. Assegnare l'accesso in base al gruppo. Mappare i gruppi di directory alle VLAN con privilegio minimo, in modo che il ruolo del membro dello staff determini le risorse raggiungibili dalla sessione. Un'autenticazione riuscita non deve comportare automaticamente l'accesso a ogni servizio interno.

6. Ricontrollare continuamente la conformità. Non limitare la valutazione delle policy all'iscrizione iniziale. Riconvalidare la posture del dispositivo e rimuovere l'accesso quando un dispositivo non soddisfa più i requisiti o quando l'account associato viene disabilitato.

Tra le cause più comuni di intervento dell'help desk figurano versioni del sistema operativo non supportate, certificati scaduti, ora di sistema errata, certificati della catena di fiducia mancanti, casualizzazione dell'indirizzo MAC privato e utenti che rifiutano le autorizzazioni di gestione. È opportuno tracciare i problemi per modello di dispositivo e versione del SO, poiché un tasso di registrazione complessivamente soddisfacente può nascondere malfunzionamenti ripetuti su una singola piattaforma.

• Sistema operativo non supportato: Offrire un percorso di aggiornamento approvato o instradare il dispositivo verso un accesso limitato.
• Certificato scaduto: Automatizzare il rinnovo con un anticipo sufficiente a evitare un'interruzione del servizio alla scadenza di una credenziale.
• Ora errata o catena di fiducia mancante: Verificare l'orologio del dispositivo e l'installazione del certificato prima di modificare la politica di rete.
• Randomizzazione MAC privata: Confermare se la politica della rete dipende da un indirizzo del dispositivo stabile e fornire istruzioni di configurazione specifiche per la piattaforma.
• Autorizzazioni di gestione rifiutate: Spiegare cosa può visualizzare la gestione e offrire un percorso di fallback anziché concedere un accesso ampio.

I requisiti di conformità di base devono rimanere semplici. I dispositivi dovrebbero ricevere gli aggiornamenti di sicurezza tempestivamente e con cadenza regolare, utilizzare il blocco dello schermo, installare applicazioni solo da fonti autorizzate e non essere ammessi alla rete se è stato effettuato il root o il jailbreak. Un dispositivo che non supera tali controlli di stato deve essere isolato in una rete segregata con privilegi minimi, e non nella rete aziendale.

La sequenza è più facile da comprendere quando si può visualizzare il flusso del certificato nel contesto. Il video sottostante fornisce una guida visiva alle fasi di onboarding.

Onboarding senza MDM e chiavi per singolo dispositivo per dispositivi condivisi

Alcuni dispositivi non possono completare la registrazione MDM. Tra questi rientrano uno smartphone personale il cui proprietario non autorizza la gestione, una cassa o un chiosco condiviso e un sensore IoT privo di un'interfaccia di registrazione adeguata. La soluzione non consiste nell'inserire tutti questi dispositivi nella rete del personale. Utilizzare un percorso limitato che fornisca a ciascun dispositivo una credenziale identificabile e un proprietario chiaro.

Utilizzare un pass o una chiave con un proprietario definito

1. Confermare che il dispositivo sia non gestito o non supportato. Verificare che non possa utilizzare il percorso dei certificati e che il relativo proprietario accetti l'eventuale app di installazione. In questo modo si evita che un'eccezione diventi la norma solo perché l'iscrizione è poco agevole.

2. Fornire ai telefoni personali un pass installato tramite app WiFi. L'utente effettua l'accesso e installa il pass senza iscrivere l'intero telefono al sistema MDM. Per un'implementazione gestita, i telefoni personali possono installare un pass WiFi dall'app Purple in due tocchi la notte del passaggio finale.

3. Assegnare a ciascun terminale condiviso una chiave xPSK propria. Inserire la cassa o il chiosco nella propria VLAN, con un limite di banda adeguato al lavoro da svolgere. Una chiave univoca impedisce la diffusione di una singola password su tutte le casse.

4. Adattare la durata della chiave all'uso. Impostarla in modo che corrisponda alla prenotazione, al contratto o ai turni di lavoro. Le credenziali temporanee non devono rimanere valide dopo che la persona o il dispositivo non necessitano più dell'accesso.

5. Registrare chi possiede ciascuna chiave. Mantenere il proprietario del dispositivo o dell'utente associato alle credenziali, in modo che il personale di supporto possa identificare quale accesso revocare in caso di smarrimento del dispositivo o di uscita di un dipendente.

6. Revocare la chiave e testare il risultato. Rimuovere l'accesso al momento della partenza e confermare che il dispositivo si disconnetta dalla rete. La revoca fa parte della progettazione dell'onboarding, non è un'attività da inventare dopo il verificarsi di un problema.

Questi percorsi offrono meno visibilità sullo stato del dispositivo rispetto a un certificato, pertanto è preferibile mantenerli su reti limitate anziché sulla rete VLAN del personale. Il compromesso operativo è semplice: una chiave per singolo dispositivo richiede maggiore attenzione nell'emissione e nel tracciamento, ma limita la portata di una credenziale compromessa.

Percorsi di fallback per dispositivi non supportati e parzialmente gestiti

Il supporto non è sufficientemente omogeneo da rendere la politica "registrati o perdi l'accesso" fattibile per tutti i dipendenti. Un rapporto sulla sicurezza mobile di Verizon del 2025 ha rilevato che il 15% delle organizzazioni intervistate forniva pieno supporto per tutti i tipi di dispositivi mobili, mentre il 32% offriva supporto ad hoc, il 27% supportava solo modelli designati e il 23% non forniva alcun supporto. Questo divario incide su chi utilizza dispositivi più datati, sui fornitori esterni, sul personale in prima linea e sui dipendenti che non acconsentono a un monitoraggio esteso del proprio telefono personale.

Caso dispositivo	Percorso di onboarding	Accesso alla rete	Verifica prima della concessione
OS completamente gestito e supportato	Certificato MDM tramite EAP-TLS	Rete sicura per gruppo di directory	Stato di conformità e scadenza del certificato
Smartphone personale, nessuna autorizzazione di gestione	Portale captive o pass WiFi via app	Rete VLAN ospiti con isolamento dei client	Consenso registrato, nessuna rete VLAN aziendale
Versione OS non supportata	Accesso da solo browser alle app designate	Rete segregata a bassi privilegi	Data di aggiornamento ed elenco app approvate
Cassa condivisa o chiosco	Chiave xPSK per dispositivo	Rete VLAN propria con limite di larghezza di banda	Proprietario della chiave e percorso di revoca
Contrattista o lavoratore temporaneo	Accesso ospiti a tempo limitato o dispositivo in prestito	Rete VLAN ospiti, in scadenza al termine del contratto	Data fine contratto e referente responsabile
Accessibilità o richiesta per dispositivi datati	Revisione manuale con dispositivo in prestito	Limitato alle app approvate	Data di revisione e responsabile designato

Mantenere l'eccezione circoscritta e documentata

Garantire a ciascun dispositivo il livello minimo di accesso necessario all'attività. Uno smartphone personale che necessita solo dell'accesso tramite browser a un servizio specifico non richiede un reindirizzamento verso le applicazioni interne o la rete VLAN aziendale. Un cassa condivisa necessita dei soli servizi assegnati, e le sue credenziali richiedono un proprietario identificato e un percorso di revoca.

Pubblichi una matrice di compatibilità dei dispositivi affinché il personale possa verificare se il proprio SO e dispositivo possono essere registrati prima dell'arrivo in sede. Mantenga un inventario dei sistemi operativi e delle applicazioni non supportati e registri il percorso alternativo applicabile a ciascuno. Per consulenti esterni e visitatori, un percorso di rete a tempo limitato aiuta a rendere esplicite la scadenza e la sponsorizzazione.

Una regola rigida può peggiorare la sicurezza se spinge i dipendenti verso hotspot personali, password condivise o altre soluzioni alternative non gestite. Un percorso limitato e documentato è spesso più sicuro che negare l'accesso senza offrire un'alternativa.

Regole di consenso, privacy e offboarding

“Posso rifiutare il BYOD e che cosa potrà visualizzare o cancellare esattamente il mio datore di lavoro?” È necessario inserire la risposta nell'informativa di registrazione, prima che al collaboratore venga chiesto di accettare un profilo o di installare un'applicazione. L'autenticazione tecnica non dimostra che l'utente abbia compreso i termini o si sia sentito libero di scegliere.

In un'indagine condotta nel settore dell'assistenza, il 50% dei fornitori utilizzava il BYOD, ma solo la metà di essi disponeva di una politica BYOD; solo il 40% del personale che utilizzava dispositivi personali ricordava di aver firmato politiche o linee guida. Un'altra indagine del 2025 ha rilevato che il 70% del personale preferiva dispositivi forniti dall'organizzazione (il rapporto BYOD 2025 per l'assistenza sociale agli adulti). Tali risultati mettono in discussione l'ipotesi che l'accesso da dispositivi personali sia automaticamente più economico o più pratico per i lavoratori.

L'informativa deve indicare, in un linguaggio chiaro:

• Quali telemetrie di sicurezza vengono raccolte e quali contenuti personali l'organizzazione non può visualizzare.
• Cosa può essere rimosso, inclusa la conferma che la rimozione di un profilo di lavoro non cancellerà i contenuti personali.
• Chi paga per i dati mobili di lavoro e l'usura del dispositivo, con le regole di rimborso per il paese di riferimento.
• Qual è l'alternativa se il lavoratore rifiuta la gestione del dispositivo personale.

Una casella di controllo non costituisce un consenso valido se la partecipazione è di fatto obbligatoria. Offrire un dispositivo in prestito o un altro percorso di accesso e richiedere nuovamente il consenso in caso di modifiche al monitoraggio o all'utilizzo dei dati. Per i processi di registrazione degli ospiti, i team possono anche utilizzare le linee guida per verificare gli ID degli ospiti prima della registrazione come spunto per valutare quali informazioni identificative siano necessarie e come debbano essere gestite.

L'offboarding deve rimuovere il certificato, il profilo di gestione, i token in cache e qualsiasi chiave xPSK associata al dispositivo. Una dimostrazione di Purple Access può mostrare a un tecnico come emettere e revocare una chiave su una rete attiva, utilizzando i dispositivi di un appartamento: una serratura, un termostato, il laptop di un ospite e lo smartphone del personale di un cliente.

1. Emettere una chiave su un dispositivo attivo.
2. Revocarla.
3. Misurare il tempo necessario per l'interruzione dell'accesso.
4. Registrare il risultato come criterio di superamento della revoca del pilota.

Confermare l'ordine del percorso e testarlo prima con un progetto pilota

Implementare i percorsi in un ordine che eviti che le eccezioni definiscano l'intera rete. Ciascuna classe di dispositivi riceve un'impostazione predefinita, mentre il progetto pilota conferma che il percorso funzioni con le identità, i controller e i dispositivi in un sito reale.

1. Iniziare dai dispositivi gestiti del personale su EAP-TLS. Utilizzare il percorso con certificato per i laptop e i telefoni registrati, con accesso collegato ai gruppi di directory e un percorso di revoca testato.

2. Aggiungere il portale ospiti. Rendere chiara l'esperienza di accesso e registrare il consenso per ogni sessione utente ospite.

3. Spostare i telefoni personali e non gestiti del personale a un pass WiFi. Ciò offre agli utenti un percorso che non richiede la registrazione completa del dispositivo.

4. Assegnare chiavi xPSK univoche a casse condivise, chioschi e dispositivi IoT. Assegnare ogni dispositivo alla propria politica di accesso e registrare chi possiede le relative credenziali.

5. Applicare percorsi di fallback solo alle eccezioni. Utilizzare l'accesso solo tramite browser, una rete per ospiti o fornitori, un dispositivo in prestito o una verifica manuale laddove il percorso predefinito non sia possibile.

Stabilire le metriche del pilota prima del lancio

Scelga una sede pilota e definisca i punteggi di superamento prima che chiunque inizi la registrazione. Misuri il completamento della registrazione, la prima autenticazione riuscita, i contatti all'help-desk per 100 registrazioni e il tempo di revoca dell'accesso. Se si impostano le soglie dopo il pilota, è troppo facile definire accettabile un risultato debole per il solo fatto che la sede è già attiva.

Prenoti una sessione di progettazione e prepari il Suo elenco di SSID, il fornitore di access point, la directory e l'MDM. Un ingegnere di rete potrà mappare tali dettagli sulle reti aperte, sicure e xPSK, oltre a convalidare il piano rispetto alla sede pilota prima del rollout. La richiesta di demo rileva l'organizzazione e i dati di contatto, oltre a ciò che attualmente è in esecuzione sul WiFi del cliente, inclusi SSID, fornitore di access point, directory e MDM.

---

Purple Access supporta l'accesso e il consenso tramite captive portal, i certificati EAP-TLS tramite MDM e chiavi individuali per dispositivo per le apparecchiature non gestite. Visitare Purple Access per organizzare una dimostrazione e includere i dettagli dei propri dispositivi e della propria rete nella sessione di progettazione.