BYOD e accesso dei collaboratori esterni: protezione dei dispositivi non gestiti tramite il browser

Una società di consulenza necessita di 200 collaboratori esterni che accedano alle piattaforme interne SharePoint e Salesforce per un incarico della durata di sei mesi. I loro computer portatili personali non supportano gli agenti endpoint, l’iscrizione a soluzioni MDM è fuori discussione per dispositivi che i collaboratori utilizzano anche per operazioni bancarie personali e per conservare foto di famiglia, e l’implementazione di una VDI per un gruppo temporaneo di utenti farebbe saltare il budget del progetto. Il browser, l'applicazione già aperta su ciascuno di quei laptop, rappresenta il punto di controllo più pratico a vostra disposizione. Questa guida accompagna i responsabili della sicurezza attraverso un approccio graduale alla protezione dell'accesso BYOD e dei collaboratori esterni tramite controlli basati sul browser, dai prerequisiti ai criteri di successo misurabili.

Prerequisiti: cosa occorre prima di iniziare

Prima di configurare i controlli di accesso basati su browser per gli utenti BYOD e i collaboratori esterni, si assicuri che questi presupposti siano soddisfatti. Trascurarli è la causa più comune di interruzione delle implementazioni.

L'infrastruttura di identità deve supportare gli utenti esterni. Il vostro IdP deve gestire le identità federate dei collaboratori esterni, non solo dei dipendenti. Immaginate lo scenario di una società di consulenza: il responsabile di progetto invia le istruzioni di onboarding a 200 collaboratori esterni un lunedì. Se il vostro IdP non è in grado di emettere identità con ambito limitato e a tempo determinato legate a un dominio esterno, passerete quella settimana a configurare manualmente gli account e dimenticherete di disattivarli al termine dell’incarico. La norma NIST SP 800-46 Rev. 2 affronta esplicitamente i requisiti di sicurezza per il BYOD e per i dispositivi client controllati da collaboratori esterni, partner commerciali e fornitori, sottolineando l’importanza di proteggere le informazioni sensibili memorizzate su tali dispositivi e trasmesse attraverso di essi.

Inventario delle applicazioni per modalità di accesso. Si tratta di un elenco delle applicazioni di cui hanno bisogno i collaboratori esterni, che si tratti di soluzioni SaaS (accessibili tramite proxy forward o reverse), applicazioni web interne (accessibili tramite ZTNA) o applicazioni legacy con client pesante (che potrebbero ancora richiedere l'uso di VDI). La maggior parte dei carichi di lavoro dei collaboratori esterni è incentrata sulle soluzioni SaaS — SharePoint, Salesforce, ServiceNow — il che rende l'applicazione delle politiche tramite browser una soluzione praticabile per la maggior parte delle sessioni.

Classificazione dei dati per la mappatura delle politiche DLP. Se non avete ancora definito quali dati siano da considerarsi sensibili nelle applicazioni a cui i collaboratori esterni avranno accesso, le politiche DLP finiranno per bloccare troppe informazioni o, al contrario, non rileveranno nulla. Come minimo, definite i criteri di attivazione delle politiche per i dati personali, i documenti finanziari e la proprietà intellettuale.

Decisione relativa all'architettura di rete. La norma NIST SP 800-46 raccomanda alle organizzazioni di prendere in considerazione l'uso di soluzioni di controllo dell'accesso alla rete che verifichino lo stato di sicurezza di un dispositivo client prima di consentirgli l'accesso alla rete interna, nonché di valutare l'utilizzo di una rete separata per tutti i dispositivi client esterni, compresi quelli BYOD e quelli controllati da terzi. Per quanto riguarda l'accesso basato su browser, ciò si traduce nell'instradamento di tutto il traffico proveniente dai dispositivi non gestiti attraverso la piattaforma SSE, anziché concedere loro l'accesso diretto alla rete.

Fase 1: Definizione della visibilità e della politica di riferimento con CASB e SWG

Iniziate rispondendo alla domanda fondamentale: che ruolo svolgono attualmente i dispositivi non gestiti nelle vostre applicazioni SaaS?

Implementi il CASB in modalità proxy inverso per intercettare le sessioni provenienti da dispositivi non gestiti che accedono ad applicazioni SaaS autorizzate. Un proxy inverso non richiede alcun agente: il collaboratore esterno effettua semplicemente l'autenticazione tramite il vostro IdP e viene instradato in modo trasparente attraverso il punto di applicazione del CASB. Nello scenario della società di consulenza, quando un collaboratore esterno accede a Salesforce da un MacBook personale, il CASB rileva la sessione, classifica il dispositivo come non gestito in base all'assenza di un certificato client e applica la vostra politica sui dispositivi non gestiti: accesso in sola lettura ai record delle opportunità, nessuna esportazione in blocco e filigrana sulle visualizzazioni a schermo.

Contemporaneamente, convogliate il traffico web di questi utenti attraverso il vostro SWG per applicare le politiche di utilizzo accettabile, bloccare l'accesso a categorie ad alto rischio ed eseguire la scansione dei file scaricati alla ricerca di malware. Lo SWG rappresenta la vostra prima linea di difesa contro un collaboratore esterno che clicchi su un link di phishing in una scheda di posta elettronica personale mentre è connesso anche al vostro SharePoint aziendale.

Cosa misurare in questa fase:

Numero di sessioni di dispositivi non gestiti rilevate al giorno

Applicazioni SaaS a cui accedono dispositivi non gestiti (individuazione di shadow SaaS)

Violazioni delle norme bloccate (download in blocco, accesso non autorizzato alle app)

Tempo medio che intercorre tra la richiesta di inserimento di un collaboratore esterno e l'ottenimento dell'accesso operativo

Questa fase fornisce i dati di monitoraggio necessari per giustificare gli investimenti nelle fasi successive. Se il vostro CASB rileva che i collaboratori esterni scaricano ogni settimana elenchi di clienti sui propri dispositivi personali, la motivazione economica per la Fase 2 si presenta da sé.

Fase 2: Aggiunta Remote Browser Isolation le sessioni ad alta sensibilità

Una volta ottenuta la visibilità, il passo successivo consiste nell'eliminare completamente l'endpoint come vettore di minaccia per le vostre applicazioni più sensibili. È qui che entra in gioco remote browser isolation diventa il controllo più efficace a disposizione per i dispositivi non gestiti.

Si consideri uno scenario pratico: un collaboratore esterno di una società di consulenza deve esaminare i dati dei clienti in Salesforce che includono informazioni di identificazione personale (PII), quali nomi, indirizzi e valori delle transazioni. Con RBI, la sessione di Salesforce viene eseguita in un container basato su cloud. Il collaboratore visualizza e interagisce con l'applicazione normalmente nel proprio browser Chrome o Safari, ma nessun dato dell'applicazione, token di sessione o contenuto della pagina raggiunge mai il dispositivo locale. Se il laptop personale del collaboratore viene compromesso da un keylogger o da un programma di furto di informazioni, il malware non ha nulla di utile da acquisire poiché la sessione non viene mai eseguita localmente.

RBI consente inoltre di applicare controlli granulari sui dati all'interno della sessione isolata. È possibile disabilitare il copia-incolla, bloccare la stampa, impedire il download di file e applicare filigrane dinamiche che incorporano l'identità dell'utente negli screenshot. Al termine della sessione, il contenitore viene distrutto, senza lasciare alcuna traccia di dati sul dispositivo non gestito.

Questo approccio è perfettamente in linea con i principi dello Zero Trust. Il documento NIST SP 800-207 riconosce esplicitamente che i dispositivi presenti sulla rete potrebbero non essere di proprietà dell'azienda né configurabili da essa, e che i servizi in appalto potrebbero includere risorse non di proprietà dell'azienda che necessitano di accesso alla rete per svolgere la propria funzione. RBI rappresenta l'attuazione pratica di questo principio: si concede l'accesso alle applicazioni senza riporre fiducia nel dispositivo.

Quando utilizzare RBI anziché il proxy CASB standard:

Quando utilizzare il proxy RBI rispetto al proxy CASB standard

Fase 3: Estensione dello ZTNA alle applicazioni private

Le applicazioni SaaS rappresentano solo una parte del quadro. Molti incarichi affidati a collaboratori esterni richiedono l'accesso ad applicazioni web interne — portali personalizzati, wiki interni, ambienti di sviluppo — che non sono accessibili da Internet.

Una VPN tradizionale offre ai collaboratori esterni un tunnel a livello di rete verso il vostro ambiente, il che viola ogni principio del modello Zero Trust. Se uno di quei 200 collaboratori esterni ha un malware sul proprio computer portatile personale e voi gli avete concesso l'accesso tramite VPN, il malware può eseguire una scansione della vostra rete interna, tentare di muoversi lateralmente e raggiungere sistemi ben oltre l'ambito di competenza previsto per il collaboratore esterno.

ZTNA / Private Access la VPN con un accesso a livello di applicazione. Il collaboratore esterno effettua l'autenticazione; il motore delle politiche valuta la sua identità, il contesto del dispositivo e i segnali di rischio, e concede l'accesso solo alle specifiche applicazioni interne autorizzate per il suo ruolo — nient'altro. Il collaboratore esterno non vede né entra in contatto con la rete sottostante.

Le fasi di maturità del Modello di maturità Zero Trust della CISA consentono alle organizzazioni di valutare, pianificare e mantenere gli investimenti necessari per progredire verso l'approccio Zero Trust attraverso cinque pilastri: identità, dispositivi, reti, applicazioni e carichi di lavoro, nonché dati. Il passaggio dalla VPN allo ZTNA per l'accesso dei collaboratori esterni rappresenta un passo concreto dalla maturità "Tradizionale" a quella "Iniziale" sia nel pilastro dei dispositivi che in quello delle reti.

Nel caso di una società di consulenza, lo ZTNA consente alla collaboratrice Jane di accedere al portale interno di monitoraggio dei progetti dal proprio computer portatile personale a casa, ma le impedisce di eseguire scansioni della rete, di raggiungere il controller di dominio o di passare all'applicazione finanziaria. Se il suo incarico termina venerdì, il suo accesso viene revocato a livello di applicazione: non occorre cercare certificati VPN né modificare regole del firewall.

Perché le soluzioni VDI e MDM non sono all'altezza delle esigenze del BYOD e dell'accesso dei collaboratori esterni

I responsabili della sicurezza spesso valutano soluzioni VDI e MDM prima di prendere in considerazione i controlli basati su browser. Entrambe presentano casi d'uso legittimi, ma nessuna delle due è particolarmente adatta a gestire popolazioni di dispositivi temporanei, in numero elevato e non gestiti.

VDI (Virtual Desktop Infrastructure): la VDI crea un ambiente desktop centralizzato su un server, trasmettendo una sessione visiva al dispositivo dell'utente. È ideale per ambienti altamente regolamentati che richiedono applicazioni thick client. Tuttavia, per 200 collaboratori esterni che accedono ad applicazioni SaaS per sei mesi, la VDI rappresenta una soluzione eccessiva. Le soluzioni VDI ospitate su cloud hanno solitamente un costo di decine di dollari al mese per utente, mentre la VDI on-premise richiede un investimento sostanziale in server, rete e software di virtualizzazione. Per un progetto che coinvolge 200 collaboratori esterni, i soli costi totali di abbonamento alla VDI possono raggiungere decine di migliaia di dollari in sei mesi, senza contare i costi generali relativi a infrastruttura, licenze e assistenza. La VDI comporta inoltre latenza, interruzioni di sessione e lunghi tempi di onboarding che frustrano gli utenti e riducono la produttività.

MDM (Mobile Device Management): l'MDM richiede l'installazione di un profilo di gestione sul dispositivo personale del collaboratore, garantendo all'organizzazione il controllo sulle impostazioni del dispositivo, la possibilità di cancellare i dati da remoto e la visibilità sulle applicazioni installate. La maggior parte dei collaboratori si opporrà. Il dispositivo è di loro proprietà, lo utilizzano per operazioni bancarie, posta elettronica personale e foto di famiglia. Chiedere a un collaboratore di aderire all'MDM crea attriti legali, obiezioni relative alla privacy e ritarda l'inserimento nel team di giorni o settimane.

Controlli basati su browser (CASB + RBI + SWG + ZTNA): nessun agente, nessuna registrazione dei dispositivi, nessuna infrastruttura da scalare. L'appaltatore apre il proprio browser, effettua l'autenticazione tramite il vostro IdP e le politiche di sicurezza vengono applicate a livello di sessione. I tempi di onboarding si riducono da giorni a minuti. Il mercato della sicurezza BYOD riflette questo cambiamento: il mercato era valutato a 60,64 miliardi di dollari nel 2025 e si prevede che raggiunga i 120,36 miliardi di dollari entro il 2032 con un CAGR del 10,28% (GII Research, 2026).

Tabella 2: VDI, MDM e controlli basati su browser

Punti di integrazione: come integrare la sicurezza del browser con la vostra infrastruttura esistente

I controlli BYOD basati su browser non funzionano in modo isolato. Il loro valore aumenta notevolmente se integrati con la vostra infrastruttura di sicurezza esistente.

IdP e accesso condizionato: il vostro IdP (Azure AD, Okta, Ping) funge da gatekeeper. Configurate criteri di accesso condizionato in grado di rilevare i dispositivi non gestiti — in genere in base all'assenza di un certificato client o di un segnale di conformità — e di instradare automaticamente tali sessioni attraverso il proxy inverso CASB o RBI. Quando un collaboratore esterno accede a SharePoint da un dispositivo non registrato, l'IdP dovrebbe applicare automaticamente il percorso di accesso più restrittivo senza alcun intervento manuale.

Unificazione delle politiche DLP: le stesse politiche DLP che proteggono i dati sugli endpoint gestiti dovrebbero estendersi alle sessioni browser da dispositivi non gestiti. Se la vostra politica DLP blocca l'esportazione in blocco dei dati dei clienti per i dipendenti, deve bloccarla anche per i collaboratori esterni che accedono tramite RBI. Il rapporto IBM sul costo delle violazioni dei dati (2024) quantifica il rischio: il costo medio globale di una violazione dei dati ha raggiunto i 4,88 milioni di dollari nel 2024, con un aumento del 10% su base annua, il picco più elevato dall’inizio della pandemia. Un’applicazione coerente delle politiche DLP sia per gli accessi gestiti che per quelli non gestiti riduce la probabilità di diventare parte di quella statistica.

Integrazione tra SIEM e UEBA: convogliate i log delle sessioni provenienti da CASB, RBI e ZTNA nel vostro SIEM per definire linee di riferimento comportamentali relative all'attività dei collaboratori esterni. Se un collaboratore esterno che normalmente accede a 20 record di Salesforce al giorno ne esporta improvvisamente 2.000, tale anomalia dovrebbe attivare un avviso. La visibilità e l'analisi sono una delle tre funzionalità trasversali del Modello di maturità Zero Trust della CISA, e la telemetria a livello di sessione derivante dai controlli del browser ne costituisce un'implementazione pratica.

Automazione dell'offboarding: al termine del rapporto con un collaboratore esterno, disattivate la sua identità IdP. Poiché l'accesso è basato sulla sessione e viene applicato a livello di proxy o RBI, non è necessario revocare alcun certificato VPN, disinstallare alcun agente endpoint né rimuovere alcun profilo dispositivo. L'accesso cessa semplicemente di esistere.

Indicatori e criteri di successo

Misurate ciò che conta. Questi indicatori dimostrano se i vostri controlli di accesso per il BYOD e per i collaboratori esterni basati su browser funzionano e giustificano un investimento continuativo.

Indicatori operativi:

Tempo medio necessario per l'accesso dei collaboratori esterni: dal provisioning dell'identità alla prima sessione produttiva. Obiettivo: meno di 30 minuti. Se si misura questo tempo in giorni, il processo deve essere migliorato.

Volume delle sessioni dei dispositivi non gestiti: numero totale di sessioni settimanali provenienti da dispositivi classificati come non gestiti. È prevedibile un andamento al rialzo con l'aumentare dell'adozione; un andamento al ribasso a parità di organico degli appaltatori suggerisce un utilizzo non autorizzato.

Tasso di violazione delle politiche: numero di azioni bloccate (download, copia-incolla, accesso non autorizzato alle app) ogni 1.000 sessioni. Un tasso costantemente elevato può indicare che le politiche sono troppo restrittive o che la comunicazione con gli utenti è insufficiente.

Indicatori di sicurezza:

Zero incidenti relativi a residui di dati: numero di casi di esposizione dei dati riconducibili a un dispositivo non gestito. L'obiettivo è zero per le sessioni protette da RBI.

Tasso di rilevamento delle applicazioni SaaS non autorizzate: numero di applicazioni SaaS non autorizzate a cui accedono dispositivi non gestiti, come rilevato dal CASB. Questo indicatore dovrebbe diminuire nel tempo man mano che si inaspriscono le politiche SWG.

Casi di furto di credenziali da dispositivi non gestiti: gli attacchi basati sulle credenziali hanno rappresentato il 16% di tutte le violazioni e hanno richiesto il tempo più lungo per essere individuati e contenuti, con una durata di quasi 292 giorni (IBM, 2024). L'isolamento delle sessioni offerto da RBI dovrebbe ridurre quasi a zero il furto di credenziali derivante da attacchi basati sui browser.

Indicatori di costo:

Costo per accesso di un collaboratore: Confronti il costo totale delle licenze SSE per le sessioni su dispositivi non gestiti con il costo equivalente della VDI. La differenza costituisce la sua motivazione per il rinnovo.

Volume dei ticket di assistenza relativi all'accesso degli appaltatori: i controlli basati su browser dovrebbero generare un numero inferiore di ticket di assistenza rispetto alle soluzioni VDI o MDM, poiché non è necessario risolvere problemi relativi al software client.

Errori comuni

Trattare tutti i dispositivi non gestiti allo stesso modo. Un collaboratore esterno che accede a documentazione di progetto non sensibile non necessita degli stessi controlli di chi gestisce dati personali dei clienti. Applicare in modo eccessivo l'RBI a ogni sessione aumenta i costi e la latenza. Utilizzare una classificazione basata sul rischio: proxy CASB per le applicazioni a bassa sensibilità, RBI per quelle ad alta sensibilità.

Trascurare i dati in transito tra le applicazioni. Ha bloccato l'accesso a Salesforce con RBI, ma il collaboratore esterno può comunque copiare il nome di un cliente da Salesforce, incollarlo in uno strumento di IA generativa in una scheda adiacente e ottenere una risposta che include dati arricchiti. Abbini RBI alle politiche SWG che limitano l'accesso agli strumenti di IA generativa da sessioni su dispositivi non gestiti, oppure instrada l'accesso agli strumenti di IA anche attraverso l'isolamento. Skyhigh delinea ulteriori controlli per questo scenario nella sua guida sulla protezione delle app cloud dai dispositivi non gestiti.

Si trascura il flusso di lavoro relativo all'offboarding. L'assegnazione delle risorse riceve tutta l'attenzione, mentre la revoca delle autorizzazioni viene trattata con superficialità. Automatizzate i trigger di offboarding collegati alle date di scadenza dei contratti nel vostro sistema HR o di approvvigionamento. Un collaboratore esterno che mantiene l'accesso tre mesi dopo la conclusione del proprio progetto rappresenta una minaccia interna, indipendentemente dal fatto che lo intenda o meno.

Ignorare la comunicazione con gli utenti. I collaboratori esterni che si imbattono per la prima volta in RBI potrebbero segnalare che «l'applicazione sembra diversa» o che il copia-incolla non funziona. Senza una comunicazione proattiva che spieghi perché esistono questi controlli e quali comportamenti limitano, si finirà per assistere a soluzioni alternative non ufficiali: i collaboratori esterni invieranno i dati via e-mail a indirizzi personali per aggirare le restrizioni sui download.

Implementazione dei controlli sul browser senza DLP. L'isolamento del browser senza data loss prevention una porta chiusa a chiave con una finestra aperta. L'RBI impedisce ai dati di raggiungere il dispositivo, ma il DLP garantisce che i dati all'interno della sessione non possano essere sottratti attraverso canali non autorizzati, come il caricamento su un account di archiviazione cloud personale, l'invio tramite e-mail a un indirizzo non aziendale o la stampa in un file PDF locale. IBM ha rilevato che il 35% delle violazioni ha riguardato i dati ombra — informazioni archiviate in fonti di dati non gestite (IBM, 2024) — sottolineando come il movimento incontrollato dei dati generi costi e rischi.

Partire dal presupposto che un unico modello di implementazione sia adatto a tutti. Alcune categorie di utenti potrebbero trarre vantaggio da un'estensione browser leggera su dispositivi gestiti, mentre i collaboratori esterni utilizzano un sistema RBI senza agente. Adattate il controllo allo stato del dispositivo e al tipo di utente, anziché imporre un unico approccio a tutta la forza lavoro.