Che cos'è Remote Browser Isolation come funziona l'RBI

Remote browser isolation RBI) esegue i contenuti web in un container cloud monouso anziché sull’endpoint dell’utente, garantendo che il codice dannoso proveniente da pagine di phishing, exploit zero-day e download automatici non raggiunga mai il dispositivo o la rete aziendale. Per gli architetti della sicurezza che valutano la tecnologia di isolamento del browser nell’ambito di una strategia zero trust, l’RBI offre un modello di sicurezza fondamentalmente diverso: anziché cercare di rilevare ogni minaccia nel traffico web, parte dal presupposto che tutti i contenuti web siano inaffidabili e separa fisicamente l’esecuzione dall’endpoint. Questo approccio sta assumendo un’importanza sempre maggiore man mano che il browser diventa lo spazio di lavoro principale — e la principale superficie di attacco — in ogni azienda.

Che cos’è Remote Browser Isolation

Remote browser isolation una tecnologia di sicurezza informatica che separa fisicamente l’attività di navigazione web di un utente dal suo dispositivo locale e dalla rete aziendale. Quando un utente accede a un sito web, la pagina viene caricata ed eseguita all’interno di un contenitore cloud sicuro ed effimero, anziché all’interno del browser installato sul proprio laptop o sulla propria workstation. L’utente visualizza e interagisce con una rappresentazione visiva sicura della pagina; tutto il codice sottostante — HTML, CSS, JavaScript, oggetti incorporati — rimane confinato all’ambiente remoto. Al termine della sessione, il contenitore viene distrutto insieme a eventuali payload dannosi che possa aver incontrato. Quando viene fornita come servizio ospitato nel cloud, questa tecnologia è nota come remote browser isolation.

Ecco come funziona il processo nella pratica: una direttrice marketing riceve un’e-mail contenente un link a un presunto rapporto di settore. Lei clicca sul link. Anziché aprirsi direttamente in Chrome sul suo portatile, il traffico viene instradato attraverso il secure web gatewaydell’organizzazione, che indirizza l’URL non classificato in una sessione RBI. Viene avviato un container cloud monouso, che carica la pagina e la visualizza. La direttrice marketing vede una versione completamente interattiva della pagina — può scorrere, cliccare e leggere — ma nessun codice HTML, JavaScript o contenuto eseguibile raggiunge mai il suo computer. Se il link conduce a una pagina di phishing contenente un exploit zero-day, il codice dannoso viene eseguito all’interno del container, che viene distrutto al termine della sessione. Il suo endpoint rimane pulito. Non si verifica alcuna esfiltrazione di dati. Il SOC potrebbe non dover mai valutare un incidente, poiché l’attacco è stato contenuto prima ancora che avesse inizio.

Questo modello si discosta radicalmente dalla sicurezza tradizionale basata sul rilevamento. A differenza dei motori antivirus o dei filtri di reputazione degli URL, che si basano su modelli e firme di minacce noti, l’isolamento del browser adotta un approccio “zero trust”, trattando tutti i contenuti web come potenzialmente ostili, indipendentemente dalla loro reputazione. Tale distinzione è fondamentale poiché gli strumenti tradizionali sono strutturalmente incapaci di rilevare gli attacchi “zero hour”, ovvero quelle minacce che non dispongono ancora di una firma.

Perché Remote Browser Isolation oggi

Il browser non è più solo una finestra su Internet. È l’ambiente di lavoro aziendale in cui convergono posta elettronica, applicazioni SaaS, sistemi CRM, piattaforme finanziarie e strumenti di intelligenza artificiale. Tale concentrazione di attività sensibili rende il browser un bersaglio estremamente allettante.

Quasi la metà degli incidenti di sicurezza oggetto di indagine nel 2024 (44%) ha riguardato attività dannose avviate o facilitate tramite i browser dei dipendenti, tra cui attacchi di phishing, abuso di reindirizzamenti URL e download di malware (Rapporto globale sulla risposta agli incidenti 2025 di Unit 42). Nel contempo, il rapporto «2025 State of Browser Security Report» di Menlo Security rivela un aumento del 140% degli attacchi di phishing mirati ai browser nell’ultimo anno, con gli incidenti di phishing «zero hour» — attacchi troppo recenti per essere rilevati da qualsiasi database di firme — in crescita del 130%.

L’impatto finanziario è grave. Secondo il rapporto di IBM “Cost of a Data Breach Report”, nel 2024 il costo medio globale di una violazione dei dati ha raggiunto i 4,88 milioni di dollari. Gli attacchi basati su credenziali compromesse hanno richiesto in media 292 giorni per essere identificati e contenuti. Molte di queste catene di furto di credenziali hanno inizio nel browser: un utente accede a una pagina di phishing convincente, inserisce le proprie credenziali e l’autore dell’attacco rimane all’interno dell’ambiente per quasi dieci mesi prima che la violazione venga contenuta.

Si consideri uno scenario concreto: un analista finanziario presso una banca di medie dimensioni riceve una notifica nel browser che sembra provenire dal sistema di gestione dei documenti della banca. Il link reindirizza a un clone identico, pixel per pixel, della pagina di accesso, ospitato su una piattaforma cloud legittima per eludere i filtri di reputazione degli URL. In assenza di isolamento del browser, l’analista inserisce le credenziali e l’autore dell’attacco ottiene l’accesso ai sistemi interni. Con l’RBI attivo, la pagina di phishing viene caricata all’interno di un container cloud; anche se l’analista tentasse di inserire le credenziali, la sessione può essere configurata in modo da bloccare l’inserimento delle credenziali su domini non classificati o da eliminare completamente l’invio dei moduli. La catena di attacco si interrompe già al primo link.

Il documento NIST SP 800 46 Rev. 2 sottolinea il modello di minaccia che rende indispensabile l’RBI: il documento ipotizza che i dispositivi client utilizzati per il telelavoro possano essere infettati da malware e raccomanda controlli a più livelli, tra cui soluzioni di accesso alla rete che verifichino lo stato di sicurezza del client prima di concedere l’accesso. L’RBI rende operativa questa ipotesi, non fidandosi mai, in primo luogo, della capacità dell’endpoint di elaborare in modo sicuro i contenuti web.

Come Remote Browser Isolation : tre approcci di rendering

Tutte le soluzioni RBI condividono la stessa architettura di base: i contenuti web vengono recuperati ed eseguiti in un ambiente remoto e isolato (in genere un container cloud effimero) e al browser locale dell’utente viene fornita solo una rappresentazione sicura della pagina. La differenza fondamentale risiede nel modo in cui tale rappresentazione sicura viene generata e trasmessa. Esistono tre approcci principali.

Elaborazione dei pixel (streaming dei pixel)

Questo approccio rende i contenuti web su un server remoto e invia una rappresentazione visiva della pagina web al dispositivo dell’utente sotto forma di immagine interattiva o flusso video. Si può pensare a questo processo come a una trasmissione video in diretta di una sessione del browser in esecuzione sul computer di qualcun altro: il dispositivo dell’utente funge da client di visualizzazione leggero.

Vantaggio in termini di sicurezza: isolamento massimo. Nessun codice web o script originale raggiunge mai l’endpoint. Tutti i potenziali vettori di attacco incorporati nel codice del sito rimangono isolati sul server remoto.

Compromesso: la codifica e la trasmissione continue di flussi video richiedono un’elevata larghezza di banda e risultano costose su larga scala. Anche in caso di ottimizzazione avanzata, la latenza inevitabile comporta un’esperienza utente sensibilmente diversa. Sui display ad alta risoluzione (DPI), il testo può apparire sfocato; gli utenti mobili con connessioni instabili riscontrano un deterioramento della qualità.

Ambiti di applicazione ideali: ambienti ad alta sicurezza in cui la riservatezza prevale sull’esperienza utente — ricerca OSINT, accesso amministrativo privilegiato a sistemi critici o navigazione in ambienti riservati.

Riflessione del DOM (ricostruzione del DOM)

Con la ricostruzione del DOM, le pagine web vengono caricate in un ambiente isolato, analizzate a livello di Document Object Model e riscritte per rimuovere potenziali minacce. Una volta che il contenuto è stato depurato, una versione pulita viene inviata al dispositivo dell’utente, dove il browser dell’endpoint la visualizza utilizzando il proprio motore.

Vantaggio in termini di sicurezza: leggerezza e velocità. L’endpoint offre un’esperienza di navigazione quasi nativa, che mantiene l’accelerazione GPU e il comportamento standard di scorrimento.

Compromesso: le tecnologie sottostanti — HTML, CSS, font web — costituiscono esse stesse vettori di attacco. Il tentativo di rimuovere i contenuti dannosi tramite la sanificazione è intrinsecamente imperfetto; nuove tecniche di sfruttamento potrebbero sfuggire al controllo. Le pagine dinamiche complesse potrebbero non funzionare correttamente o essere visualizzate in modo errato.

Ambito di applicazione ideale: navigazione aziendale generica, in cui le prestazioni e l’esperienza utente sono fondamentali e in cui l’organizzazione accetta un livello di isolamento leggermente inferiore a vantaggio della produttività.

Rendering vettoriale di rete (NVR)

NVR intercetta i comandi di disegno provenienti dal motore grafico utilizzato in Chromium e Firefox, li crittografa e li trasmette in streaming al browser locale. Poiché NVR trasmette in streaming comandi di disegno vettoriali anziché il codice effettivo del sito web, garantisce un consumo di larghezza di banda inferiore rispetto alla trasmissione dei pixel, mantenendo al contempo un solido confine di isolamento.

Vantaggio in termini di sicurezza: nessun codice del sito web raggiunge l’endpoint, analogamente alla trasmissione di pixel; tuttavia, il consumo di larghezza di banda è notevolmente inferiore poiché i comandi di disegno vettoriale sono molto più compatti rispetto ai fotogrammi video costituiti da pixel.

Compromesso: l’adozione della tecnologia NVR è più limitata e può dipendere dal supporto specifico del motore del browser. In termini sia di sicurezza che di prestazioni, si colloca a metà strada tra il “pixel pushing” e il “DOM mirroring”.

Ideale per: organizzazioni che necessitano di una sicurezza quasi perfetta senza sovraccarico di banda — personale distribuito su connessioni di rete variabili.

Isolamento totale contro isolamento selettivo: la scelta del modello di politica adeguato

La maggior parte delle organizzazioni non ha bisogno — né desidera — isolare ogni singola sessione di navigazione. Il sovraccarico in termini di prestazioni e i costi di elaborazione legati all’isolamento completo sono difficili da giustificare quando la maggior parte del traffico è diretta verso applicazioni SaaS ben note e classificate. È proprio in questi casi che l’isolamento selettivo diventa una strategia praticabile.

L'isolamento completo instrada tutto il traffico web attraverso RBI. Ogni pagina, ogni sessione, ogni utente. Questo approccio è indicato per i segmenti che richiedono un elevato livello di sicurezza: un'agenzia governativa che gestisce informazioni riservate, una sala di negoziazione finanziaria o un laboratorio di ricerca sanitaria che accede a fonti di dati esterne. La garanzia di sicurezza è assoluta, ma lo sono anche i costi e l'impatto sulla latenza.

L'isolamento selettivo applica l'RBI solo al traffico che supera una soglia di rischio definita. Tra i fattori scatenanti tipici figurano:

Domini non classificati o appena registrati. Un collaboratore clicca su un link che rimanda a un dominio registrato 48 ore fa. Lo SWG lo contrassegna come non classificato; l’RBI isola automaticamente la sessione.

Categorie di URL a rischio. I siti classificati come piattaforme di condivisione file, posta elettronica personale o reti pubblicitarie vengono isolati, mentre il traffico SaaS aziendale viene instradato direttamente.

Link contenuti nelle e-mail. Ogni URL presente nelle e-mail in entrata — indipendentemente dalla reputazione — viene aperto tramite RBI, neutralizzando così il principale meccanismo di diffusione del phishing.

Segmenti di utenti sensibili. I dirigenti, gli addetti alla finanza e alle risorse umane che gestiscono dati soggetti a normative navigano in modalità isolata per impostazione predefinita; il personale non specializzato utilizza tale modalità solo per destinazioni a rischio.

Il punto chiave dell’integrazione è il secure web gateway(SWG), che classifica e instrada il traffico in tempo reale. La politica dello SWG determina quali sessioni entrano nell’RBI e quali vengono sottoposte a ispezione standard. Quando lo SWG fa parte di una piattaforma SSE più ampia, le decisioni relative all’isolamento possono tenere conto dei punteggi di rischio CASB, della classificazione DLP, dell’identità dell’utente, dello stato di sicurezza del dispositivo e delle informazioni sulle minacce in tempo reale, creando così una politica sensibile al contesto che concilia sicurezza e produttività.

Il ruolo di RBI nell’architettura Zero Trust e SSE

L'isolamento del browser non opera in modo isolato. Se implementato in modo autonomo, contrasta il malware basato sul web e il phishing, ma presenta delle lacune in materia di esfiltrazione dei dati, “shadow IT” SaaS e attacchi basati sull’identità. Il vero valore emerge quando l’RBI viene integrato in un’architettura zero trust insieme a controlli complementari.

Il modello di maturità Zero Trust v2.0 (2023) della CISA consente di abbandonare gli approcci tradizionali incentrati sul perimetro, permettendo alle organizzazioni di isolare gli host, applicare la crittografia, segmentare le attività e implementare controlli di sicurezza più vicini alle applicazioni e ai dati. RBI si allinea direttamente a questi principi: isola l’ambiente di navigazione, applica la crittografia tra il container e l’endpoint e segmenta le attività web a rischio dalla rete aziendale.

Il piano tecnico del 2026 della Cloud Security Alliance sulla sicurezza dei browser va oltre, riposizionando il browser come un punto di applicazione delle politiche (Policy Enforcement Point, PEP) di primo livello all’interno di un’architettura Zero Trust completa che unifica i controlli di accesso con privilegi minimi, l’autenticazione multifattoriale resistente al phishing, la convalida dello stato dei dispositivi, la governance adattiva delle sessioni e remote browser isolation. La CSA raccomanda in particolare di implementare remote browser isolation le sessioni privilegiate o a rischio elevato, al fine di neutralizzare sia la compromissione degli endpoint sia le minacce web dannose.

Nelle architetture SSE concrete, l'RBI opera in combinazione con:

SWG per il filtraggio degli URL, le informazioni sulle minacce e le decisioni relative all’instradamento del traffico.

CASB per garantire la visibilità sull’utilizzo autorizzato e non autorizzato dei servizi SaaS, con la possibilità di isolare le sessioni relative ai servizi IT non autorizzati, bloccando al contempo le operazioni di upload e download.

Il DLP ispeziona i contenuti che transitano attraverso sessioni isolate e impedisce che i dati sensibili vengano incollati, caricati o stampati durante la navigazione a rischio.

ZTNA / Private Access isolare le sessioni provenienti da dispositivi non gestiti che accedono alle applicazioni interne: un collaboratore esterno, utilizzando il proprio computer portatile personale, accede alla rete intranet aziendale tramite una sessione isolata in cui le funzioni di copia, incolla e download sono disabilitate.

Secondo il Magic Quadrant di Gartner del 2024 Magic Quadrant SSE, entro il 2026 l’85% delle organizzazioni che intendono proteggere le proprie applicazioni web, SaaS e private otterrà le funzionalità di sicurezza da un’offerta SSE. L’RBI figura tra le funzionalità previste per una piattaforma SSE matura, a conferma del fatto che l’isolamento non è più un’opzione facoltativa per le organizzazioni che prendono sul serio la sicurezza dei browser aziendali.

Valutazione delle soluzioni RBI: quali aspetti dovrebbero essere prioritari per gli architetti della sicurezza

Non tutte le implementazioni di RBI sono uguali. Nel valutare le soluzioni, è opportuno concentrarsi sui criteri che incidono direttamente sul livello di sicurezza, sulla complessità operativa e sull’accettazione da parte degli utenti.

1. Metodo di rendering e isolamento del ceiling. Verifichi se la soluzione utilizza il “pixel pushing”, il “DOM mirroring”, l’NVR o un approccio ibrido. Chieda al fornitore quali contenuti — se ve ne sono — vengano eseguiti sul browser dell’endpoint. Una soluzione di “DOM mirroring” che invia codice JavaScript sanificato all’endpoint presenta una superficie di attacco diversa rispetto a una soluzione di “pixel pushing” che invia solo fotogrammi di immagini.

2. Esperienza utente e latenza. Richiedete una prova di fattibilità nel vostro ambiente di rete effettivo. Chiedete agli utenti di caricare le dieci applicazioni SaaS che utilizzano più spesso tramite la sessione isolata e misurate il tempo di caricamento delle pagine, la fluidità dello scorrimento, il comportamento delle operazioni di copia e incolla e i flussi di lavoro relativi al caricamento e al download dei file. Se l’esperienza risulta sensibilmente compromessa, l’adozione da parte degli utenti fallirà e questi ultimi troveranno soluzioni alternative che aggirino completamente l’isolamento.

3. Livello di integrazione di SSE. Il motore di isolamento dovrebbe condividere le politiche, il contesto delle identità, le regole DLP e le informazioni sulle minacce con i componenti SWG, CASB e ZTNA. Se dovete gestire le politiche RBI in una console separata con un linguaggio di regole distinto, state acquistando un prodotto puntuale, non una funzionalità di piattaforma. La piattaforma SSE Skyhigh Security integra RBI con SWG, CASB, DLP e ZTNA all’interno di un unico motore di policy: un esempio dell’approccio unificato che gli architetti della sicurezza dovrebbero richiedere.

4. Supporto dei dispositivi non gestiti. Uno dei casi d’uso di maggior valore per RBI consiste nel consentire l’accesso sicuro da dispositivi che l’organizzazione non controlla: computer portatili di collaboratori esterni, dispositivi di partner, tablet personali. La soluzione dovrebbe supportare un’implementazione senza client (senza agenti), in cui gli utenti si connettono tramite un browser standard senza installare agenti o software proprietario.

5. Granularità del controllo dei dati. La soluzione consente di disabilitare le operazioni di copia e incolla, la stampa, la creazione di screenshot e il download di file in base alle singole politiche? Per una sessione isolata in cui un collaboratore esterno accede a Salesforce, è auspicabile un accesso in sola lettura con il blocco delle operazioni di copia e incolla e senza memorizzazione dei file nella cache locale.

6. Scalabilità e impronta nel cloud. Ogni sessione isolata consuma risorse di calcolo. Si informi in merito all’infrastruttura cloud del fornitore, alla sua presenza geografica, ai limiti di concorrenza delle sessioni e a come i costi variano all’aumentare del numero di utenti o della percentuale di traffico isolato.

7. Compatibilità con i browser esistenti. Il percorso di adozione più efficace consiste nel mantenere i browser già in uso dagli utenti — Chrome, Edge, Firefox, Safari — anziché imporre la sostituzione con un browser proprietario. Come illustrato nel confronto tra browser aziendali e RBI, le soluzioni SSE integrate di RBI consentono di proteggere i browser già utilizzati dai dipendenti senza imporre una migrazione che comporti interruzioni dell’attività.

Errori comuni nelle implementazioni di RBI

Isolare tutto fin dal primo giorno. L’isolamento totale di tutto il traffico può sembrare una soluzione sicura nelle presentazioni, ma genera reclami relativi alle prestazioni che minano la fiducia degli utenti. Un approccio migliore consiste nell’iniziare dalle categorie ad alto rischio: domini non classificati, URL incorporati nelle e-mail e sessioni su dispositivi non gestiti. Ampliate la copertura dell’isolamento man mano che valutate l’impatto sugli utenti e rafforzate la fiducia.

Implementazione di RBI come prodotto autonomo. RBI senza integrazione con SWG non è in grado di prendere decisioni di instradamento intelligenti. RBI senza DLP non può impedire a un utente di inserire dati sensibili in un modulo web durante una sessione isolata. RBI senza CASB non è in grado di verificare se la destinazione sia un servizio di archiviazione cloud autorizzato o un account personale di condivisione file. L’isolamento risolve un problema — impedire che contenuti dannosi raggiungano l’endpoint — ma la sicurezza dei dati richiede l’intero stack SSE.

Ignorare il caso d’uso dei dispositivi non gestiti. Molte organizzazioni acquistano la soluzione RBI per gli endpoint gestiti, ma trascurano i collaboratori esterni e gli utenti di terze parti che utilizzano dispositivi BYOD. Questi utenti rappresentano alcune delle sessioni a più alto rischio. La norma NIST SP 800-46 Rev. 2 avverte esplicitamente che tutti i componenti delle tecnologie di telelavoro, compresi i dispositivi client BYOD, devono essere protetti dalle minacce previste, identificate attraverso modelli di minaccia. La soluzione RBI rappresenta uno dei modi più pratici per farlo senza richiedere la registrazione nella gestione dei dispositivi.

Mancata integrazione dell’isolamento con l’identità. Una politica di isolamento generica che tratti tutti gli utenti allo stesso modo comporta uno spreco di risorse e crea frustrazione negli utenti a basso rischio. È necessario collegare le politiche di isolamento ai gruppi di identità, ai controlli di accesso basati sui ruoli e alla valutazione adattiva del rischio. Un dirigente che naviga dalla rete aziendale tramite un dispositivo gestito potrebbe non necessitare di isolamento; lo stesso dirigente che naviga dalla rete Wi-Fi di un hotel su un tablet personale dovrebbe invece essere isolato automaticamente. Il rapporto «Unit 42 2025 Global Incident Response Report» ha rilevato che il 70% degli incidenti ha coinvolto tre o più vettori di attacco: le politiche sensibili al contesto che tengono conto dell’identità, del dispositivo e della destinazione sono essenziali per spezzare le catene di attacchi multivettoriali.