Che cos'è un browser aziendale e perché la navigazione sicura è importante per le aziende moderne

Il browser web è diventato, quasi inosservatamente, l’applicazione più rilevante – e più poco protetta – all’interno dell’azienda. Ogni accesso a un servizio SaaS, ogni richiesta all’intelligenza artificiale, ogni caricamento e download di file, ogni collaboratore esterno che accede a un portale interno: tutto ciò avviene all’interno di una scheda del browser. Gartner sottolinea che i browser aziendali sicuri «integrano i controlli di sicurezza aziendali nell’esperienza di navigazione web nativa utilizzando un browser personalizzato o un’estensione per i browser esistenti, anziché aggiungere controlli esterni a livello di endpoint o di rete». Eppure la maggior parte delle organizzazioni continua a considerare il browser come un prodotto di largo consumo, affidandosi a versioni di Chrome o Edge destinate al pubblico consumer, senza alcuna applicazione delle politiche a livello di sessione. Questa lacuna rappresenta oggi il principale punto cieco nell’architettura di sicurezza aziendale.

Che cos'è un browser aziendale?

Un browser aziendale è un controllo di sicurezza a livello di browser progettato per garantire il rispetto delle politiche aziendali —data loss prevention, controlli di accesso, analisi delle minacce e gestione delle sessioni — nel momento in cui gli utenti interagiscono con applicazioni web, piattaforme SaaS e Internet.

Gartner definisce un SEB come una soluzione che implementa le politiche e i controlli di sicurezza aziendali tramite un’estensione del browser gestita centralmente e, facoltativamente, un browser web personalizzato full-stack. Le SEB garantiscono la sicurezza e l’applicazione delle politiche per applicazioni web, SaaS e private, oltre a un rafforzamento della sicurezza del browser attuato direttamente all’interno del browser stesso, anziché a livello di sistema operativo dell’endpoint o di rete. Consentono inoltre la visibilità, il controllo e la verificabilità dei dati delle applicazioni web a cui gli utenti finali accedono da dispositivi gestiti, parzialmente gestiti o non gestiti, senza la necessità di una decrittografia in linea del traffico web.

In pratica, la categoria dei browser aziendali comprende due approcci fondamentalmente diversi:

Sostituzione completa del browser: un’applicazione basata su Chromium che sostituisce interamente Chrome o Edge; tra gli esempi figurano Island Enterprise Browser e Prisma Access Browser di Palo Alto Networks. Queste soluzioni integrano direttamente nel browser proprietario funzionalità di DLP, integrazione delle identità e controlli delle sessioni.

Rafforzare l'approccio basato sul browser esistente: estensioni del browser, remote browser isolation, l’ispezione SWG e le politiche CASB applicate ai browser già utilizzati dai dipendenti. Questo approccio consente di evitare la sostituzione di Chrome, garantendo al contempo l’applicazione dei controlli sui dati, il blocco dei contenuti dannosi e l’isolamento delle sessioni a rischio.

Si consideri un esempio concreto: un perito assicurativo presso una compagnia assicurativa utilizza Chrome per accedere a Salesforce, a un portale interno dedicato alla sottoscrizione delle polizze e, occasionalmente, a un assistente basato sull’intelligenza artificiale generativa per sintetizzare le note relative ai casi. In un modello di sostituzione, il reparto IT chiederebbe al perito di passare a un browser proprietario, di reimpara i segnalibri e le estensioni e di accettare che alcune applicazioni web interne possano essere visualizzate in modo diverso. In un modello di protezione del browser esistente, il reparto IT applica RBI agli URL rischiosi o non classificati, impiega il DLP per impedire che le informazioni personali identificative (PII) vengano incollate nello strumento di IA e utilizza uno SWG per bloccare i download dannosi — il tutto senza modificare il flusso di lavoro quotidiano del perito.

Perché la navigazione sicura è importante oggi

Tre fattori hanno contribuito a rendere la sicurezza dei browser una necessità operativa piuttosto che un semplice elemento auspicabile.

1. Il browser è il nuovo perimetro. L’Innovation Insight di Gartner dell’aprile 2025 sottolinea che i browser web rappresentano il principale metodo di accesso per la maggior parte delle moderne applicazioni aziendali e forniscono un punto di controllo della sicurezza aziendale indipendente dall’endpoint. Quando un rappresentante commerciale in trasferta accede al CRM da una rete Wi-Fi di un hotel, il browser è l’unico ostacolo tra quella sessione e un proxy che raccoglie le credenziali. I firewall tradizionali e i concentratori VPN non rilevano affatto la sessione.

2. Gli attacchi basati sui browser sono in forte aumento. Il rapporto «2025 State of Browser Security» di Menlo Security ha rilevato che gli attacchi di phishing «zero hour» sono aumentati del 130% rispetto all’anno precedente. Nel 2024, un attacco su cinque basato sul browser ha utilizzato tecniche evasive progettate per aggirare i tradizionali controlli di sicurezza basati sulla rete e sugli endpoint. Non si tratta di semplici problemi di blocco degli URL. Gli autori degli attacchi utilizzano domini SaaS legittimi, sovrapposizioni «browser nel browser» ed esche di phishing generate dall’intelligenza artificiale che i gateway web tradizionali faticano a individuare.

3. Il furto delle credenziali ha inizio nel browser. Il rapporto DBIR 2025 di Verizon riporta che l’88% degli attacchi alle applicazioni web di base ha coinvolto credenziali rubate. Una responsabile marketing salva la propria password di Salesforce nella funzione di compilazione automatica di Chrome. Un programma di furto di informazioni presente su un dispositivo personale che utilizza anche per lavoro copia tutte le credenziali salvate e le mette in vendita su un marketplace del dark web. Sei settimane dopo, un malintenzionato accede al CRM con un token di sessione valido. Nessun allarme scatta finché l’esfiltrazione dei dati non è già stata completata.

Il rapporto IBM “Cost of a Data Breach Report 2024” ha rilevato che le violazioni legate al furto di credenziali hanno richiesto in media 292 giorni per essere individuate e contenute: il periodo più lungo tra tutti i vettori di attacco. Quasi dieci mesi di permanenza del malintenzionato nel sistema. I controlli a livello di browser che rilevano comportamenti anomali durante le sessioni, impongono un’autenticazione resistente al phishing e impediscono la memorizzazione delle credenziali nei dispositivi non gestiti riducono tale lasso di tempo da mesi a minuti.

Come funziona la sicurezza dei browser aziendali

La sicurezza dei browser aziendali si articola su quattro livelli funzionali. Comprendere tali livelli vi aiuta a valutare gli approcci dei fornitori e a individuare le affermazioni di marketing prive di fondamento.

Livello 1: Isolamento e analisi delle minacce

Remote browser isolation i contenuti web in una sandbox nel cloud e trasmette in streaming all’endpoint dell’utente solo pixel sicuri (o elementi DOM bonificati). Un analista finanziario fa clic su un link contenuto in un’e-mail che rimanda a un dominio mai visto prima. Grazie all’RBI, la pagina viene eseguita in un contenitore isolato. Anche se dovesse contenere un exploit drive-by o un programma di raccolta delle credenziali, il codice dannoso non entrerà mai in contatto con il computer dell’analista. L’utente visualizza una pagina dall’aspetto normale; il sistema di sicurezza rileva una minaccia contenuta.

Un secure web gateway è posizionato a monte, ispeziona il traffico decrittografato tramite TLS, applica le politiche relative alle categorie di URL e blocca le destinazioni note come dannose prima ancora che il browser richieda la pagina. Insieme, RBI e SWG colmano sia le lacune relative alle minacce note sia quelle relative alle minacce «zero hour».

Livello 2: Data loss prevention livello di sessione

Il DLP a livello di browser intercetta le operazioni di copia/incolla, caricamento e download di file, nonché le azioni di stampa all’interno della sessione del browser stessa. Immaginate un reclutatore a contratto che abbia accesso al vostro sistema HRIS tramite una sessione browser gestita. Il reclutatore può visualizzare i profili dei candidati, ma non può scaricare un file CSV, incollare i numeri di previdenza sociale in una scheda della propria posta elettronica personale né effettuare uno screenshot della pagina, poiché le politiche DLP vengono applicate a livello di rendering, non solo all’uscita dalla rete.

Livello 3: Controlli relativi all’identità e all’accesso

La sicurezza del browser si integra con i provider di identità (Okta, Entra ID) e con le politiche CASB per garantire l’accesso condizionato. Un collaboratore esterno effettua l’accesso da un computer portatile personale non gestito. Anziché concedere l’accesso completo al SaaS o bloccare del tutto la sessione, il motore delle politiche instrada la sessione attraverso RBI con restrizioni di upload/download, blocco degli appunti e inserimento di filigrane. Il collaboratore esterno può svolgere il proprio lavoro. L’organizzazione mantiene il controllo dei propri dati.

Livello 4: Visibilità e analisi

I dati di telemetria delle sessioni — quali utenti hanno effettuato l’accesso a quali applicazioni, da quale stato del dispositivo e quali azioni hanno tentato di compiere — vengono integrati nel flusso di lavoro delle operazioni di sicurezza. È proprio questo il livello che trasforma il browser da un punto cieco a un sensore.

Il ruolo della sicurezza del browser nell'architettura aziendale

La sicurezza del browser non opera in modo isolato. Si integra — o entra in conflitto — con ogni livello della vostra infrastruttura di sicurezza esistente. La questione architettonica non è: «Abbiamo bisogno della sicurezza del browser?», bensì: «Dove si colloca la sicurezza del browser rispetto a SSE, CASB, DLP, endpoint e identità?».

Il documento NIST SP 800-46 Rev. 2 fornisce indicazioni fondamentali sulle considerazioni di sicurezza relative alle soluzioni di accesso remoto, raccomandando alle organizzazioni di proteggere tutti i componenti delle tecnologie di telelavoro e di elaborare politiche che disciplinino i tipi di dispositivi, i livelli di accesso e i controlli relativi al BYOD. Il browser è ormai la tecnologia dominante nel campo del telelavoro, eppure le architetture di accesso remoto di molte organizzazioni continuano a considerarlo come un canale trasparente e non controllato.

Un servizio di sicurezza ben integrato security service edge (SSE) ben integrata unifica SWG, CASB, DLP, ZTNA e RBI sotto un unico motore di policy. Quando un utente apre un’applicazione SaaS, la piattaforma SSE valuta l’identità, lo stato del dispositivo, la posizione e la sensibilità dei dati per determinare se consentire direttamente la sessione, instradarla tramite RBI, applicare restrizioni DLP o bloccare completamente l’accesso. Il browser è il punto di applicazione; la piattaforma SSE è il cervello delle policy.

Si considerino gli ostacoli concreti dell’alternativa. Un’organizzazione sanitaria implementa un browser aziendale autonomo per 500 infermieri che accedono a un sistema di cartelle cliniche elettroniche (EHR). Funziona bene per quel caso d’uso. Tuttavia, gli stessi infermieri utilizzano anche Chrome per un’applicazione SaaS di pianificazione degli appuntamenti dei pazienti, Edge per un portale statale di Medicaid e Safari sui propri telefoni personali per la pianificazione dei turni. Ora il reparto IT si trova a gestire quattro contesti di navigazione con livelli di sicurezza diversi. Il browser aziendale autonomo ha risolto un problema, ma ha frammentato l’architettura di sicurezza.

L'approccio integrato di SSE garantisce l'applicazione coerente delle politiche in tutti e quattro i contesti browser, senza richiedere la sostituzione del browser. Le politiche DLP seguono i dati indipendentemente dal browser utilizzato per aprire la sessione. I controlli di sicurezza web e cloud vengono applicati in modo uniforme.

Il problema delle resistenze all’adozione: sostituire il browser o renderlo più sicuro

Gartner sottolinea che gli SEB consentono un accesso segmentato da dispositivi degli utenti finali non gestiti o gestiti in misura limitata e da ambienti BYOD, in cui l’implementazione di agenti sugli endpoint risulterebbe inappropriata per motivi di privacy o di manutenzione. Si tratta di un caso d’uso convincente. La questione strategica è come garantire tali controlli.

Il modello sostitutivo richiede ai dipendenti di abbandonare il proprio browser predefinito e di utilizzare un'applicazione proprietaria. Il fornitore controlla il motore di rendering, l'ecosistema delle estensioni e il ciclo di aggiornamento. I team di sicurezza ottengono un controllo approfondito a livello di sessione.

Il costo è rappresentato dalle resistenze all’adozione. Chrome detiene oltre il 65% della quota di mercato globale dei browser per desktop. I dipendenti hanno alle spalle anni di abitudine, password salvate, segnalibri sincronizzati e flussi di lavoro basati sulle estensioni, tutti costruiti attorno a questo browser. Chiedere loro di cambiare comporta la creazione di ticket per l’assistenza tecnica, soluzioni alternative non autorizzate (i dipendenti che aprono comunque Chrome per “le cose che non funzionano”) e test di compatibilità continui per ogni applicazione web interna.

Per un confronto più approfondito tra questi due modelli, l’analisi Skyhigh Securitysui browser aziendali rispetto a RBI esamina i pro, i contro e l’idoneità per le aziende.

Il modello di browser sicuro mantiene Chrome, Edge o Safari al loro posto e garantisce la sicurezza della sessione tramite controlli RBI, SWG, DLP, CASB e ZTNA forniti attraverso una piattaforma SSE. L’esperienza utente rimane familiare. L’applicazione delle politiche rimane invisibile finché un utente non tenta un’azione rischiosa, come incollare dati personali identificativi (PII) in uno strumento di intelligenza artificiale, scaricare un file da un’applicazione SaaS non autorizzata o accedere a una pagina di phishing.

Il compromesso: l’approccio SSE richiede l’ispezione TLS (il che comporta considerazioni specifiche in materia di gestione dei certificati e privacy) e non è in grado di applicare controlli a livello di DOM con la stessa profondità di un browser proprietario. Per la maggior parte dei casi d’uso aziendali — protezione dell’accesso ai servizi SaaS, applicazione delle politiche DLP, isolamento della navigazione a rischio, protezione dell’accesso dei collaboratori esterni — il modello integrato SSE offre una protezione equivalente senza i costi di adozione.

Criteri di valutazione: la scelta di una strategia di sicurezza per i browser

Nel valutare la sicurezza dei browser aziendali, si raccomanda di porsi le seguenti domande prima di rivolgersi a qualsiasi fornitore:

Sicurezza del browser sostitutivo rispetto a quella del browser integrato in SSE

Il ruolo dello Zero Trust nella sicurezza dei browser

La sicurezza del browser e l’approccio “zero trust” non sono iniziative distinte: si tratta della stessa iniziativa vista da prospettive diverse.

Il Modello di maturità Zero Trust v2.0 della CISA fornisce un approccio alla modernizzazione continua in ambito Zero Trust in un panorama tecnologico in rapida evoluzione, guidando le agenzie nella progettazione e nell’attuazione di piani di transizione in conformità con l’Ordine Esecutivo 14028. Il modello è strutturato attorno a cinque pilastri — Identità, Dispositivi, Reti, Applicazioni e carichi di lavoro, e Dati — oltre a tre capacità trasversali: Visibilità e analisi, Automazione e orchestrazione, e Governance.

Ciascuno di questi pilastri converge nel browser:

Identità: i token di autenticazione e di sessione risiedono nel browser. Gli attacchi di tipo “man-in-the-middle” consentono agli aggressori di sottrarre i cookie di sessione tramite il browser.

Dispositivi: il browser è la prima applicazione a interagire con un endpoint potenzialmente compromesso. I controlli sullo stato di sicurezza del dispositivo regolano l’accesso tramite browser.

Reti: l’ispezione TLS presso lo SWG intercetta il traffico del browser prima che raggiunga l’applicazione SaaS.

Applicazioni e carichi di lavoro: le applicazioni SaaS vengono utilizzate tramite il browser. Le politiche CASB garantiscono il controllo tra l’accesso alle applicazioni autorizzate e quelle non autorizzate.

Dati: i dati sensibili vengono visualizzati, copiati, scaricati e caricati tramite il browser. Il DLP a livello di browser rappresenta l’ultima linea di difesa prima che i dati escano dall’organizzazione.

Uno scenario pratico: un funzionario addetto ai prestiti di una banca regionale accede a un’applicazione interna per la concessione di prestiti tramite ZTNA / Private Access si trova in un bar. La piattaforma Skyhigh SSE verifica l’identità del funzionario (Okta MFA), controlla lo stato del dispositivo (laptop gestito, disco crittografato, livello aggiornato delle patch del sistema operativo), instrada la sessione attraverso lo SWG per l’ispezione delle minacce, applica le regole DLP che impediscono il download di documenti relativi ai prestiti contenenti informazioni personali identificative (PII) dei clienti e registra ogni azione a fini di audit. Nessuna VPN. Nessun browser proprietario. Solo un accesso regolato da policy tramite il browser che il funzionario utilizza già.

Cosa succede quando si trascura la sicurezza del browser

Il rapporto DBIR 2025 di Verizon ha rilevato che il coinvolgimento di soggetti terzi nelle violazioni è raddoppiato rispetto all’anno precedente, rappresentando ora il 30% di tutte le violazioni. Molte di queste compromissioni da parte di soggetti terzi hanno avuto origine dall’accesso da parte di appaltatori o partner ad applicazioni SaaS tramite browser non gestiti, privi di DLP, di governance delle sessioni e di isolamento.

Immagini la seguente sequenza: un analista di una società di consulenza accede alla vostra istanza di Workday tramite un laptop personale non gestito. Il profilo Chrome dell’analista sincronizza le credenziali con un account Google personale. Un membro della famiglia scarica una mod di un gioco contenente un infostealer sullo stesso laptop. L’infostealer raccoglie tutte le password salvate nel browser, comprese le vostre credenziali di Workday. Sei settimane dopo, un malintenzionato utilizza tali credenziali per accedere al vostro ambiente Workday ed esportare i dati W-2 relativi a 8.000 dipendenti.

Non si tratta di uno scenario teorico: rispecchia infatti il modello documentato dal DBIR di Verizon nel cluster relativo alla violazione di Snowflake, in cui le credenziali compromesse provenienti da dispositivi infettati da infostealer hanno consentito l’accesso ad ambienti cloud in cui non era in vigore l’autenticazione a più fattori (MFA).

Il documento NIST SP 800-46 Rev. 2 sottolinea l’importanza di proteggere le informazioni sensibili archiviate sui dispositivi utilizzati per il telelavoro e trasmesse tramite accesso remoto attraverso reti esterne. Il browser è ormai il principale dispositivo utilizzato per il telelavoro. Esso memorizza credenziali, token di sessione, dati memorizzati nella cache e il contenuto degli appunti. Lasciarlo senza alcuna gestione equivale a lasciare un tunnel VPN permanentemente aperto senza alcuna autenticazione.