In che modo Remote Browser Isolation l’architettura Zero Trust

Remote browser isolation RBI) rappresenta una delle espressioni tecniche più dirette del principio fondamentale dello Zero Trust: non concedere mai fiducia implicita a nessun contenuto, sessione o dispositivo. Per gli architetti della sicurezza che allineano i controlli ai principi della norma NIST SP 800-207 e al Modello di maturità Zero Trust della CISA, l’RBI colma una lacuna che il filtraggio degli URL tramite SWG e il rilevamento degli endpoint, da soli, non sono in grado di colmare: le minacce provenienti dal browser che si attivano prima che venga emesso un verdetto. Il presente articolo illustra in modo dettagliato in che modo l’RBI si allinea ai principi dello Zero Trust — verifica esplicita, privilegio minimo e ipotesi di violazione — e quale sia il suo ruolo accanto a ZTNA, SWG, CASB e DLP all’interno di un moderno stack SSE.

Che cos’è Remote Browser Isolation?

Remote browser isolation una tecnologia di sicurezza che esegue le sessioni di navigazione web all'interno di un container ospitato nel cloud, separando fisicamente tutto il codice web dall'endpoint dell'utente. Il dispositivo locale non elabora mai direttamente il codice web attivo, ma riceve esclusivamente un flusso di pixel o un DOM ripulito e ricostruito.

Immaginate un analista degli acquisti presso un’azienda manifatturiera di medie dimensioni che riceve un link da un nuovo fornitore. Il dominio è stato registrato la settimana scorsa, non ha alcuna reputazione a livello di URL e si trova nella zona grigia “non classificata”, dove un SWG tradizionale lo bloccherebbe (causando frustrazione all’analista) oppure lo consentirebbe (riponendo fiducia nell’ignoto). Con RBI, la pagina viene caricata all’interno di un container cloud monouso. L’analista visualizza una pagina completamente interattiva — compila un modulo, scarica un PDF — ma nessun JavaScript, nessun ActiveX e nessun exploit incorporato entra mai in contatto con il suo laptop. Se la pagina contenesse un exploit zero-day, questo verrebbe attivato in modo innocuo all’interno di un container che viene cancellato nel momento stesso in cui lei chiude la scheda.

Questo modello è più importante che mai. Il Google Threat Intelligence Group (GTIG) ha individuato 75 vulnerabilità zero-day sfruttate in ambiente reale nel 2024, e il 44% di tali attacchi era rivolto alle tecnologie aziendali (GTIG, aprile 2025). Le catene di attacco basate sui browser rimangono un vettore persistente, e RBI garantisce una difesa a più livelli, indipendentemente dal fatto che la minaccia sia nota o meno.

Perché l’RBI è fondamentale per l’approccio Zero Trust

Lo Zero Trust non è un prodotto che si acquista, bensì un insieme di principi di progettazione. Lo standard NIST SP 800 207 (2020) afferma che lo Zero Trust presuppone che non vi sia alcuna fiducia implicita concessa alle risorse o agli account utente basata esclusivamente sulla loro ubicazione fisica o di rete, né sulla titolarità delle risorse. Il browser, tuttavia, ha tradizionalmente operato sulla base della fiducia implicita: se un URL supera il filtro dell’elenco di autorizzazioni dello SWG o se un dominio dispone di un certificato valido, l’endpoint carica ed esegue tutto il codice fornito dal server. Si tratta di un modello di fiducia perimetrale applicato a un’interazione a livello di sessione.

Il divario in termini di maturità è ancora evidente. Nel sondaggio di Gartner del 2024 sull’adozione dello zero-trust, il 63% delle organizzazioni ha dichiarato di aver implementato, in tutto o in parte, una strategia zero-trust; tuttavia, Gartner ha osservato che, per la maggior parte delle organizzazioni, lo zero-trust copre ancora la metà o meno dell’ambiente e mitiga un quarto o meno del rischio aziendale complessivo. Uno dei divari più significativi che permangono riguarda la sessione del browser: secondo Gartner, i browser rappresentano il principale metodo di accesso per la maggior parte delle moderne applicazioni aziendali, eppure meno del 10% delle organizzazioni ha adottato oggi un browser aziendale sicuro, anche se Gartner prevede che tale percentuale salirà al 25% entro il 2028. Il browser è il luogo in cui i dipendenti interagiscono quotidianamente con applicazioni SaaS, strumenti di intelligenza artificiale e siti esterni, ma molte organizzazioni continuano a gestirlo con un semplice modello di autorizzazione/blocco, anziché applicare controlli granulari in materia di visibilità, politiche e protezione dei dati.

Si consideri il caso di un responsabile della conformità nel settore dei servizi finanziari che accede a un portale normativo ospitato da un fornitore terzo. Lo SWG classifica il dominio come «governativo» e ne autorizza l’accesso. Tuttavia, il portale del fornitore utilizza un plugin vulnerabile e un malintenzionato ha iniettato un iframe dannoso. Senza RBI, l’endpoint del responsabile diventa ora la superficie di attacco. Con RBI, l’iframe viene caricato all’interno di un contenitore isolato, il payload dannoso non raggiunge mai l’endpoint e il responsabile porta a termine la propria attività senza rendersi conto dell’esistenza della minaccia.

In che modo l’RBI si allinea ai tre principi dello Zero Trust

Verificare in modo esplicito

La norma NIST SP 800-207 stabilisce che nessuna risorsa sia intrinsecamente affidabile: l’azienda deve valutare lo stato di sicurezza della risorsa ogni volta che esamina una richiesta di accesso. RBI attua questo principio a livello di sessione web. Anziché prendere una decisione binaria in merito all’affidabilità basata sulla reputazione dell’URL, RBI esegue ogni sessione idonea in modo isolato e valuta il contenuto in base al suo comportamento all’interno del contenitore. Ciò sposta la verifica da un controllo una tantum (verifica dell’URL) a un modello di contenimento continuo in cui nemmeno ai domini “affidabili” vengono concessi privilegi di esecuzione del codice grezzo sugli endpoint.

Quando un addetto alla gestione delle richieste di rimborso sanitario apre un portale partner e accede a una pagina che innesca un “drive-by download”, i tradizionali controlli di verifica esplicita — autenticazione a più fattori (MFA), conformità del dispositivo, reputazione dell’URL — sono già stati superati. L’utente è autenticato, il dispositivo è gestito e l’URL è classificato come sicuro. RBI aggiunge un ulteriore livello di verifica: anche dopo che tutti i controlli precedenti sono stati superati, il contenuto web stesso non è considerato affidabile per l’esecuzione sull’endpoint.

Principio del privilegio minimo

La norma NIST SP 800 207 specifica che i principi del privilegio minimo devono essere applicati per limitare sia la visibilità che l’accessibilità. RBI applica il principio del privilegio minimo alla distribuzione dei contenuti web. Gli utenti ricevono solo ciò di cui hanno bisogno per svolgere il proprio lavoro: una rappresentazione visiva renderizzata della pagina. Non ricevono codice JavaScript grezzo, CSS né oggetti eseguibili. I controlli DLP integrati con RBI possono limitare ulteriormente le operazioni relative agli appunti, la stampa, il caricamento e il download di file in base al livello di sensibilità della sessione.

Un esempio concreto: un fornitore di servizi gestiti concede ai collaboratori esterni l’accesso al sistema di gestione dei ticket aziendale tramite ZTNA. I collaboratori esterni effettuano l’autenticazione, superano i controlli di conformità dei dispositivi e accedono all’applicazione. Tuttavia, l’architetto della sicurezza applica anche una politica RBI: le sessioni dei collaboratori vengono eseguite in isolamento, con la funzione copia/incolla disabilitata e i download limitati a file PDF semplificati. I collaboratori possono leggere e aggiornare i ticket, ma non possono estrarre dati grezzi. Si tratta dell’applicazione del principio del privilegio minimo non solo all’accesso alla rete, ma anche alle azioni che gli utenti possono compiere all’interno della sessione.

Ipotesi di violazione

Lo standard NIST SP 800 207 parte dal presupposto che la rete sia sempre ostile e che le minacce esterne e interne siano sempre presenti. RBI incarna questo principio fin dalla sua progettazione: parte dal presupposto che ogni pagina web possa essere compromessa e crea un “air gap” tra i contenuti web e l’endpoint. Come sottolinea la Cloud Security Alliance, RBI esegue le sessioni web ad alto rischio all’interno di container cloud isolati ed effimeri, in cui l’endpoint locale dell’utente non interagisce mai direttamente con il codice web attivo (CSA, gennaio 2026).

Se un rappresentante commerciale visita la pagina di marketing di un fornitore SaaS compromesso che distribuisce un payload di malware senza file tramite una libreria JavaScript compromessa, il payload viene eseguito all’interno del container e viene distrutto al termine della sessione. Non vi è alcun meccanismo di persistenza, nessuna possibilità di movimento laterale e nessuna traccia sull’endpoint. L’approccio basato sull’ipotesi di violazione viene mantenuto anche se la minaccia ha aggirato ogni altro controllo presente nello stack.

Come si inserisce l’RBI nel modello di maturità Zero Trust della CISA

Il Modello di maturità Zero Trust della CISA v2.0 (2023) articola l’approccio Zero Trust in cinque pilastri — Identità, Dispositivi, Reti, Applicazioni e carichi di lavoro, e Dati — con tre capacità trasversali: Visibilità e analisi, Automazione e orchestrazione, e Governance. La RBI contribuisce contemporaneamente a più pilastri:

Pilastro CISA ZTMM: contributo della RBI e andamento della scadenza

Il documento NIST SP 800 207 definisce la triade architettonica composta da motore delle politiche (PE), amministratore delle politiche (PA) e punto di applicazione delle politiche (PEP). All’interno di questo modello, RBI funge da PEP a livello di sessione del browser. Il PE valuta il contesto della richiesta — identità dell’utente, stato di sicurezza del dispositivo, rischio associato all’URL, sensibilità dei dati — e il PA ordina al servizio RBI di isolare la sessione e applicare i controlli appropriati sui dati. Ciò è in linea con i requisiti di verifica per ogni singola richiesta stabiliti dalla CISA, come descritto dalla Cloud Security Alliance (CSA, gennaio 2026).

RBI all’interno dello stack SSE: integrazione con ZTNA, SWG, CASB e DLP

La tecnologia RBI, se considerata isolatamente, è utile ma presenta dei limiti. Il suo pieno valore in un contesto “zero trust” emerge quando opera come componente integrato all’interno di una piattaforma Security Service Edge SSE) che include SWG, CASB, ZTNA e DLP.

Si consideri il flusso di lavoro che si verifica quando un dipendente, utilizzando un dispositivo gestito, accede a uno strumento di IA generativa tramite un browser. Lo SWG esamina la richiesta, classifica la destinazione e determina il livello di rischio associato all’URL. Il CASB identifica l’applicazione di IA e verifica se sia autorizzata. Il motore DLP analizza il testo del prompt alla ricerca di dati sensibili. Infine, la sessione RBI — attivata dalla policy dello SWG poiché lo strumento di IA è classificato come «monitor» — garantisce che il dipendente possa utilizzare lo strumento, ma non possa incollare informazioni personali identificative (PII) dei clienti, scaricare risposte contenenti contenuti sensibili né caricare file con dati soggetti a regolamentazione. Tutto ciò avviene all’interno di un unico motore di policy, non attraverso quattro prodotti distinti con console separate.

Questo modello di integrazione è il motivo per cui Gartner stima che il mercato SASE crescerà a un tasso di crescita annuale composto (CAGR) del 26%, raggiungendo i 28,5 miliardi di dollari entro il 2028 (Gartner, febbraio 2025). Le aziende stanno convergendo l’accesso, la protezione dalle minacce e la sicurezza dei dati in piattaforme unificate poiché l’alternativa — ovvero l’integrazione di prodotti RBI, SWG, CASB e DLP autonomi — crea lacune nelle politiche, un’applicazione incoerente delle stesse e un sovraccarico operativo che compromette il modello zero trust.

Skyhigh Private Access la tecnologia ZTNA con la scansione DLP e la funzionalità RBI senza soluzione di continuità, in modo che le sessioni delle applicazioni private vengano isolate quando le politiche lo richiedono, senza dover instradare il traffico attraverso un prodotto separato.

Quando il browser diventa l'area di lavoro

Il browser costituisce l’ambiente di lavoro principale per l’accesso ai servizi SaaS, l’utilizzo di strumenti di intelligenza artificiale, il download di file, l’inserimento delle credenziali e la collaborazione con terze parti. Un architetto della sicurezza che implementi la ZTNA per proteggere le applicazioni private, ma che ignori la sessione del browser in cui i dipendenti interagiscono con tali applicazioni, presenta una lacuna nell’applicazione delle misure di sicurezza. RBI colma tale lacuna, non sostituendo il browser che gli utenti già conoscono (Chrome, Edge, Firefox, Safari), ma avvolgendo la sessione in un livello di isolamento basato sul cloud controllato dalla politica SSE.

Un collaboratore esterno non gestito accede all’applicazione CRM dell’azienda tramite un CASB con proxy inverso. Il CASB autentica il collaboratore, applica i controlli di sessione e attiva una politica RBI poiché il dispositivo non è gestito. Il collaboratore visualizza e utilizza il CRM normalmente, ma, dietro le quinte, la sessione viene eseguita in modo isolato con restrizioni sugli appunti e il blocco dei download. L’azienda garantisce la sicurezza dei dati senza costringere il collaboratore a installare un agente, registrare un dispositivo o utilizzare un browser proprietario.

Criteri di valutazione: quali aspetti considerare in un RBI basato sul modello Zero Trust

Non tutte le implementazioni di RBI offrono lo stesso valore in termini di “zero trust”. Gli architetti della sicurezza che valutano l’isolamento del browser dovrebbero prendere in considerazione i seguenti criteri:

1. Integrazione nativa con SSE. L’RBI deve far parte dello stesso motore di policy di SWG, CASB, ZTNA e DLP. Se l’RBI richiede una console separata, policy separate o un instradamento del traffico separato, si creano lacune operative e incongruenze nelle policy.

2. Controlli granulari dei dati all’interno delle sessioni di isolamento. Il modello “zero trust” richiede l’applicazione del principio del privilegio minimo a livello di sessione. RBI dovrebbe consentire di disabilitare gli appunti, la stampa, il caricamento, il download e la cattura dello schermo in modo indipendente per ogni politica, gruppo di utenti e categoria di applicazioni.

3. Supporto dei dispositivi non gestiti. Una soluzione che richieda un agente endpoint per abilitare l’isolamento è in contrasto con uno dei principali casi d’uso di RBI: proteggere l’accesso da dispositivi che l’azienda non controlla.

4. Prestazioni ed esperienza utente. Se l’RBI introduce una latenza percepibile, gli utenti troveranno il modo di aggirarlo: aprendo i link sui propri dispositivi personali, utilizzando hotspot mobili o semplicemente lamentandosi finché il reparto IT non creerà delle eccezioni. Il livello di isolamento deve visualizzare le pagine a una velocità quasi pari a quella nativa.

5. Fedeltà di rendering. Le moderne applicazioni SaaS sono applicazioni a pagina singola complesse e con un uso intensivo di JavaScript. RBI deve gestirle senza comprometterne la funzionalità, senza tralasciare elementi interattivi e senza peggiorare l’esperienza utente.

6. Attivazione scalabile basata su criteri. L’approccio Zero Trust non richiede l’isolamento di ogni singola sessione. Le migliori implementazioni consentono ai team di sicurezza di definire criteri di attivazione basati sul rischio: isolare gli URL non classificati, isolare tutte le sessioni degli utenti ad alto rischio, isolare specifiche categorie di servizi SaaS oppure isolare tutto il traffico proveniente da dispositivi non gestiti.

7. Visibilità e analisi. L’RBI dovrebbe integrare i dati di telemetria delle sessioni nel più ampio livello di analisi dell’SSE, contribuendo alla capacità trasversale di “Visibilità e analisi” dello ZTMM della CISA. Ciò significa sapere chi ha effettuato l’accesso a cosa, quando, da dove e utilizzando quale dispositivo, nonché se tale comportamento si discosta dalla linea di base.

Il costo del punto cieco durante la navigazione

Lasciare le sessioni del browser al di fuori dei controlli “zero trust” comporta un costo quantificabile. Secondo il rapporto IBM “Cost of a Data Breach Report 2024” (luglio 2024), il costo medio globale di una violazione dei dati ha raggiunto i 4,88 milioni di dollari nel 2024. Le credenziali compromesse hanno rappresentato il vettore di attacco più comune, costituendo il 16% di tutte le violazioni.

Il phishing basato su browser è uno dei principali meccanismi utilizzati per il furto delle credenziali. Un amministratore del libro paga riceve un link a quella che sembra essere la pagina di accesso a un portale dedicato ai benefici aziendali. Il dominio è stato registrato di recente, supera i controlli DMARC e appare legittimo. In assenza di RBI, l’amministratore inserisce le credenziali nella pagina dell’autore dell’attacco e il furto delle credenziali è completato. Con RBI che applica una politica di isolamento sui domini non classificati, la pagina di phishing viene caricata in un container, il DLP rileva lo schema di invio delle credenziali e la sessione viene interrotta prima che le credenziali escano dall’ambiente isolato.

La giustificazione finanziaria del RBI non è di natura teorica. Le organizzazioni che colmano le lacune nella sicurezza a livello di browser riducono la propria esposizione ai vettori di violazione più costosi: il furto di credenziali, la diffusione di malware tramite il web e l’esfiltrazione di dati attraverso azioni del browser non monitorate.

Errori comuni nell'implementazione dell'RBI in un modello Zero Trust

Implementazione di RBI come prodotto autonomo. Senza l’integrazione con SSE, RBI diventa un’altra soluzione puntuale con un proprio silo di policy. Un sistema sanitario che implementa RBI separatamente dal proprio SWG si ritrova con due diversi motori di categorizzazione degli URL, due console di gestione delle policy e un’inevitabile divergenza. Le policy entrano in conflitto, le eccezioni proliferano e il modello zero trust subisce un deterioramento.

Isolare tutto, sempre. L’isolamento generalizzato comporta uno spreco di risorse di calcolo e compromette le prestazioni delle sessioni a basso rischio. Un approccio basato sul rischio — che preveda l’isolamento dei domini non classificati, dei gruppi di utenti ad alto rischio e delle categorie di applicazioni sensibili — garantisce migliori risultati in termini di sicurezza con minori ostacoli.

Ignorare i dispositivi non gestiti. Alcune implementazioni richiedono che gli agenti indirizzino il traffico verso il servizio di isolamento, escludendo proprio quei casi d’uso (collaboratori esterni, BYOD, transizioni dovute a fusioni e acquisizioni) in cui RBI offre il massimo valore. Un’azienda del settore retail che integra responsabili di magazzino stagionali che utilizzano tablet personali necessita di un isolamento senza agenti, non di un reindirizzamento che dipenda dagli agenti.

Trascurare il DLP all’interno delle sessioni isolate. L’RBI, in assenza di controlli sui dati, blocca il malware ma non l’esfiltrazione dei dati. Un dipendente che non può incollare i dati dei clienti in un’e-mail personale tramite un normale browser può comunque farlo attraverso una sessione isolata, a meno che non vengano applicati controlli sugli appunti.

Considerare RBI come un’alternativa alla VDI. RBI isola le sessioni del browser, non i desktop completi. Si integra con la VDI in casi d’uso specifici (accesso al web per terze parti), ma non la sostituisce per gli utenti che necessitano di applicazioni desktop native.