Come valutare le soluzioni di sicurezza per i browser aziendali

La sicurezza dei browser è diventata, quasi inosservatamente, la scelta più cruciale nella vostra roadmap SSE. Entro il 2028, Gartner prevede che il 25% delle organizzazioni potenzierà gli attuali strumenti di accesso remoto sicuro e di sicurezza degli endpoint implementando almeno una tecnologia di browser aziendale sicuro; tuttavia, la maggior parte di esse non ne ha ancora adottata alcuna. Questo divario tra intenzione e adozione indica che la maggior parte dei team di sicurezza si trova in una fase intermedia: consapevole della necessità di proteggere il browser, incerta su quale approccio adottare e sotto pressione per scegliere prima che la prossima violazione renda la questione ineludibile.

La presente guida pratica offre un quadro di valutazione strutturato che copre l’intera gamma degli approcci alla sicurezza dei browser aziendali: browser sostitutivi proprietari, estensioni per browser, remote browser isolation (RBI) e controlli integrati SSE — affinché possiate condurre un processo di selezione ben fondato, anziché un ciclo di dimostrazioni guidato dai fornitori.

Prerequisiti: cosa occorre predisporre prima di procedere alla valutazione

Effettuare una valutazione della sicurezza del browser senza aver verificato i prerequisiti è come acquistare un firewall senza conoscere la topologia della propria rete. Prima di selezionare anche un solo fornitore, completi questi quattro passaggi.

1. Effettuate un inventario dei browser in uso. Verificate quali browser utilizzano effettivamente i dipendenti, non quali vengono distribuiti dal reparto IT. Secondo Gartner (2025), i browser basati su Chromium rappresentano circa il 75% della quota di mercato totale dei browser; pertanto, la vostra soluzione deve funzionare su Chrome, Edge e, probabilmente, anche sulle varianti Brave o Arc. Se la vostra forza lavoro comprende reparti in cui si utilizza prevalentemente Mac con Safari, si tratta di un requisito di compatibilità imprescindibile, non di un semplice optional.

2. Effettuate una mappatura del vostro portafoglio di applicazioni SaaS e private. Identificate quali applicazioni funzionano esclusivamente nel browser e quali prevedono componenti “thick client”. Un membro del team di marketing che accede a Salesforce, carica elenchi di clienti su una piattaforma per campagne e, occasionalmente, incolla segmenti in uno strumento di scrittura basato su GenAI, presenta un profilo di rischio sostanzialmente diverso rispetto a uno sviluppatore che accede a repository di codice interni tramite ZTNA.

3. Effettuate un inventario del vostro stack di sicurezza esistente. Documentate i vostri attuali strumenti SWG, CASB, DLP, ZTNA e di rilevamento degli endpoint. Il quadro di valutazione SSE di Forrester (primo trimestre 2024) identifica tre tecnologie di sicurezza primarie — ZTNA, CASB e SWG — e diverse tecnologie secondarie, tra cui RBI e DLP. La vostra soluzione di sicurezza per il browser deve integrarsi con questi controlli, senza duplicarli.

4. Identifichi l’esposizione derivante dai dispositivi non gestiti. I collaboratori esterni che utilizzano computer portatili personali per accedere alla Sua istanza di Workday o i revisori di terze parti che accedono a SharePoint dai centri business degli hotel rappresentano il rischio più grave legato all’utilizzo del browser. Quantifichi il numero di utenti che rientrano nelle categorie di dispositivi gestiti, parzialmente gestiti e completamente non gestiti: ciò determina direttamente quali approcci siano fattibili.

Fase 1: Definire i criteri di valutazione e gli scenari di minaccia

Una valutazione che parte dalle dimostrazioni dei fornitori si conclude con la vittoria del venditore più insistente. Iniziate invece con scenari di minaccia che riflettano il vostro rischio effettivo.

Creare una libreria di scenari

Elabori da cinque a otto scenari che rappresentino i rischi legati all’utilizzo dei browser più frequenti e con maggiore impatto. Esempi pratici:

Accesso SaaS da parte di un collaboratore esterno: un consulente esterno accede al vostro CRM da un dispositivo non gestito, visualizza le informazioni personali identificative (PII) dei clienti e tenta di scaricare un elenco di contatti su un'unità di archiviazione personale.

Fuga di dati da strumenti di intelligenza artificiale: un product manager copia un documento di analisi della concorrenza da SharePoint, lo incolla in uno strumento GenAI non autorizzato e la risposta fornita dallo strumento include dati riservati relativi al fatturato.

Phishing durante una sessione del browser: un analista finanziario fa clic su un link contenuto in un messaggio di Teams che apre una pagina volta a sottrarre credenziali, progettata per imitare il vostro fornitore di SSO, all’interno di una sessione attiva e autenticata.

Esfiltrazione tramite copia/incolla: un dipendente in procinto di lasciare l’azienda apre Salesforce in una scheda e una bozza personale di Gmail in un’altra, quindi copia i dati relativi alla pipeline da una scheda all’altra.

Questi scenari costituiranno i vostri script di test POC. Qualsiasi fornitore che non sia in grado di dimostrare un controllo efficace rispetto ai vostri cinque scenari principali verrà eliminato, indipendentemente dalla sua posizione nel quadrante degli analisti.

Allineatevi alla vostra architettura Zero Trust

Il Modello di maturità Zero Trust v2.0 della CISA (2023) articola l’approccio Zero Trust in cinque pilastri — Identità, Dispositivi, Reti, Applicazioni e carichi di lavoro, e Dati — fornendo alle organizzazioni una tabella di marcia per la modernizzazione continua. La valutazione della sicurezza del browser dovrebbe riferirsi direttamente ad almeno tre di questi pilastri: Dispositivi (la sessione del browser riconosce il dispositivo?), Applicazioni (è possibile applicare criteri specifici per ogni applicazione a livello di browser?) e Dati (la soluzione è in grado di ispezionare e controllare i dati in transito all’interno del browser?).

Fase 2: Valutazione dei quattro approcci alla sicurezza dei browser

Non tutte le organizzazioni necessitano dello stesso approccio. Il mercato offre attualmente quattro modelli architetturali distinti, ciascuno con compromessi significativi.

Browser sostitutivi proprietari

Un browser personalizzato full-stack sostituisce Chrome, Edge o Firefox con un fork di Chromium controllato dal fornitore che integra funzionalità DLP, di gestione delle identità e di applicazione delle politiche a livello del motore di rendering. Gartner definisce un browser aziendale sicuro come una soluzione che attua le politiche e i controlli di sicurezza aziendali tramite un’estensione del browser gestita centralmente e, facoltativamente, un browser web personalizzato full-stack, garantendo sicurezza e applicazione delle politiche per applicazioni web, SaaS e private.

Il livello di sicurezza è elevato: l’utente controlla l’intera pipeline di rendering. Tuttavia, le difficoltà di implementazione sono altrettanto elevate. Si sta chiedendo a migliaia di utenti di abbandonare il browser che utilizzano da anni, di rieducare la propria memoria motoria e di accettare che i propri segnalibri, le estensioni e le password salvate potrebbero non essere trasferiti correttamente. Il team addetto agli acquisti si rende conto che ciò comporta che il reparto IT debba assumersi la responsabilità di un nuovo ciclo di vita del software — patch del browser, test di compatibilità, gestione delle versioni — che in precedenza era di competenza di Google o Microsoft.

Estensioni del browser

Un agente leggero si installa nel browser già in uso dall’utente, monitorando l’attività delle pagine, controllando le operazioni sugli appunti e applicando le politiche DLP senza sostituire il browser stesso. Le estensioni mantengono l’interfaccia familiare all’utente ed evitano l’onere di migrazione associato alla sostituzione del browser. Tuttavia, la sicurezza basata sulle estensioni dipende dalle API dei fornitori dei browser, che possono subire modifiche con ogni aggiornamento del browser; inoltre, alcune operazioni critiche (come l’ispezione approfondita del motore JavaScript) potrebbero essere limitate a livello di architettura.

Remote browser isolation RBI)

RBI esegue i contenuti web in un container basato su cloud e trasmette in streaming solo output visivi sicuri al browser locale dell’utente. La Guida al potenziamento delle capacità (2023) della CISA raccomanda l’isolamento del browser in combinazione con il filtraggio dei contenuti web, il DLP e i gateway sicuri come difesa a più livelli. Il modello di sicurezza è solido dal punto di vista architettonico: nessun codice web viene eseguito sull’endpoint. Quando integrato con una piattaforma SSE, RBI opera secondo una risposta graduale basata su criteri: le destinazioni note come sicure vengono autorizzate, quelle note come dannose vengono bloccate e i siti a rischio o non classificati vengono isolati.

Controlli del browser integrati in SSE

Anziché considerare la sicurezza del browser come un prodotto a sé stante, questo approccio integra il filtraggio degli URL tramite SWG, le politiche in linea del CASB, l’ispezione dei contenuti DLP e l’RBI selettivo attraverso un secure web gateway unificato. Il browser stesso non subisce alcuna modifica: la sicurezza viene applicata a livello di rete e di proxy, con un’escalation basata su politiche che prevede l’isolamento qualora il rischio lo richieda. Questo è l’approccio che più si avvicina al modo in cui funzionano già gli stack di sicurezza aziendali.

Fase 3: Valutazione dei fornitori in base a otto criteri ponderati

Utilizzi il seguente quadro di valutazione per assegnare un punteggio a ciascuna soluzione selezionata. Assegni un peso a ciascun criterio in base alle priorità della Sua organizzazione: un’organizzazione con un ampio numero di collaboratori esterni attribuirà un peso diverso al supporto per i dispositivi non gestiti rispetto a un’organizzazione in cui prevalgono gli endpoint gestiti.

Quadro di valutazione dei fornitori

Assegnate a ciascun criterio un punteggio su una scala da 1 a 5 (1 = non soddisfa il requisito, 5 = supera il requisito). Moltiplicate il punteggio per il peso assegnato per ottenere un punteggio ponderato. Qualsiasi soluzione che ottenga un punteggio pari a 1 nei criteri “Profondità di sicurezza” o “Integrazione SSE” dovrà essere eliminata, indipendentemente dal punteggio totale.

Fase 4: Eseguire una prova di concetto che dimostri effettivamente qualcosa

La maggior parte dei POC fallisce perché verifica gli aspetti sbagliati. Una demo di 30 minuti offerta da un fornitore su una macchina virtuale vuota con due utenti di prova non fornisce alcuna indicazione su come la soluzione si comporti quando centinaia di utenti reali la utilizzano un lunedì mattina.

Principi di progettazione POC

Si ricorra a utenti reali, non al team di sicurezza. Selezionate 50–100 utenti provenienti da almeno tre reparti: finanza, ingegneria e un’unità aziendale che fa ampio uso di soluzioni SaaS. Gli utenti che non hanno scelto lo strumento metteranno in luce gli ostacoli che i sostenitori del fornitore potrebbero trascurare.

Mettete alla prova il vostro attuale stack SaaS. Eseguite il POC sulla vostra istanza Salesforce di produzione, sul vostro ambiente Workday e sulle vostre applicazioni interne. Il rapporto M-Trends 2025 di Mandiant ha rilevato che gli exploit rappresentavano il 33% delle infezioni iniziali, mentre le credenziali rubate sono salite al 16% — il secondo vettore più comune — il che significa che la sicurezza del vostro browser deve far fronte a scenari di furto di credenziali e di dirottamento di sessione, non solo al download di malware.

Valutate sia la sicurezza che l’usabilità. Monitorate tre categorie di indicatori:

Indicatori di sicurezza: tentativi di phishing bloccati, attivazioni delle politiche DLP, sessioni isolate, malware sventato

Indicatori di usabilità: variazione media dei tempi di caricamento delle pagine (rispetto al valore di riferimento), tempo necessario per il completamento di cinque flussi di lavoro standard, volume dei ticket dell’help desk

Indicatori di adozione: utenti attivi rispetto a utenti registrati, tentativi di aggirare il sistema, punteggio di soddisfazione degli utenti (sondaggio semplice su una scala da 1 a 5)

Una soluzione che blocchi ogni minaccia ma che allunghi di tre secondi il tempo di caricamento di ogni pagina provocherà una rivolta da parte degli utenti che la renderà inutilizzabile dal punto di vista operativo. Al contrario, una soluzione priva di ostacoli che non rilevi l’esfiltrazione di dati tramite copia/incolla non è altro che una messinscena di sicurezza.

Durata e ambito del POC

Eseguite il POC per un periodo minimo di tre settimane. La prima settimana è dedicata alla risoluzione delle difficoltà iniziali legate all’implementazione e all’onboarding degli utenti. La seconda settimana mette in luce le prestazioni a regime. La terza settimana consente di individuare i casi limite: il ciclo di rendicontazione trimestrale che genera volumi di dati insoliti, l’appaltatore che necessita di un accesso temporaneo a un’applicazione con restrizioni, l’utente che tenta di incollare dati riservati in uno strumento di intelligenza artificiale generativa (GenAI).

Fase 5: Valutazione dell’integrazione dell’SSE e dell’armonizzazione delle politiche

È proprio qui che la maggior parte delle valutazioni sulla sicurezza dei browser fallisce. I team valutano la sicurezza dei browser in modo isolato, per poi scoprire, in fase di implementazione, che ciò crea un universo di politiche parallelo, scollegato dai propri controlli SWG, CASB e DLP.

Una prova pratica: configuri una politica DLP che impedisca il caricamento dei numeri di previdenza sociale su servizi di archiviazione cloud non autorizzati. Verifichi quindi che la stessa politica si attivi quando un utente digita tali numeri in un prompt di GenAI all’interno di una sessione browser isolata, li copia tra le schede del browser e tenta di stampare una pagina che li contenga. Se ciascuna di queste azioni richiede una politica distinta in una console separata, la sicurezza del browser sta generando un debito operativo, anziché ridurlo.

La valutazione SSE di Forrester (primo trimestre 2024) ha evidenziato che la residenza dei dati rimane una questione cruciale, soprattutto al di fuori degli Stati Uniti, e che alcuni fornitori sono in grado, rispetto ad altri, di mantenere i dati in un determinato Paese. Nel corso della vostra valutazione, verificate dove vengono elaborate le sessioni di isolamento del browser, dove vengono archiviati i registri di ispezione e se è possibile controllare l’instradamento delle sessioni verso regioni specifiche, in particolare se la vostra attività è soggetta al GDPR, al CCPA o a requisiti di sovranità dei dati specifici del settore.

Il panorama delle minacce richiede questo livello di integrazione. Il rapporto CSA “State of SaaS Security Report” (2025) ha rilevato che il 56% delle organizzazioni afferma che i propri dipendenti caricano dati sensibili su applicazioni SaaS non autorizzate. Una soluzione di sicurezza del browser che non condivida il contesto con il CASB e il DLP non è in grado di affrontare questi rischi in tempo reale. La piattaforma SSE Skyhigh Security, ad esempio, unifica le politiche SWG, CASB, DLP e RBI all’interno di un’unica console, eliminando il problema della doppia politica che affligge i prodotti di sicurezza del browser autonomi.

Errori comuni che compromettono le valutazioni sulla sicurezza dei browser

Errore n. 1: valutare il livello di sicurezza senza testare l’esperienza utente. Un CISO seleziona un browser sostitutivo sulla base di una lista di controllo delle funzionalità di sicurezza, lo distribuisce a migliaia di utenti e scopre che tre applicazioni SaaS critiche non vengono visualizzate correttamente. Nel giro di due settimane, proliferano le soluzioni alternative di “shadow IT”: gli utenti passano ai browser personali, accedono alle applicazioni aziendali dai dispositivi personali e il livello di sicurezza subisce di fatto un peggioramento.

Errore n. 2: considerare la sicurezza del browser come un acquisto a sé stante. Un team addetto agli acquisti acquista una soluzione di sicurezza per i browser da un fornitore esterno al proprio stack SSE, per poi impiegare sei mesi nel tentativo di integrarla con le politiche SWG e CASB esistenti. Il risultato sono due console di gestione delle politiche, regole DLP duplicate con logiche leggermente diverse e un sovraccarico di avvisi dovuto a dati telemetrici contrastanti. Le linee guida di valutazione di Gartner (ottobre 2025) raccomandano esplicitamente di verificare in che modo le soluzioni si integrano con il proprio stack SIEM, SOAR, SSE ed EDR, e non se siano teoricamente in grado di farlo.

Errore n. 3: ignorare il caso d’uso dei dispositivi non gestiti. I team valutano la sicurezza del browser sui laptop aziendali gestiti, per poi rendersi conto, dopo l’implementazione, che una quota significativa del rischio legato al browser proviene da collaboratori esterni e utenti BYOD che non possono installare un agente o un profilo MDM. Le soluzioni che richiedono il controllo degli endpoint — come alcuni browser alternativi che necessitano dell’installazione da parte di un amministratore locale — falliscono silenziosamente proprio per gli utenti che hanno maggiormente bisogno di protezione.

Errore n. 4: Tralasciare l’analisi del modello di costo. I costi del sistema RBI variano in base al volume di utilizzo: isolare ogni singola sessione web per ciascun utente è costoso. L’isolamento selettivo (solo per siti rischiosi e non classificati) riduce drasticamente i costi, mantenendo al contempo il livello di sicurezza. Valutate se la politica dei prezzi del fornitore favorisca o penalizzi l’isolamento mirato.

Errore n. 5: Condurre un POC della durata di due giorni con cinque membri del team di sicurezza. Ciò dimostra che il prodotto funziona per gli utenti tecnici in un ambiente controllato. Non fornisce però alcuna indicazione su come reagirà un’addetta alla contabilità fornitori dell’ufficio di Houston quando la sua sessione del browser si interromperà durante l’isolamento o quando la sua estensione preferita di Chrome smetterà di funzionare. Conducete un POC reale con utenti reali per almeno tre settimane.

Indicatori e criteri di successo per la vostra decisione finale

Al termine del POC, utilizzi questi parametri di riferimento per formulare una raccomandazione motivata alla dirigenza:

La variazione nei tempi di caricamento delle pagine rientra in un intervallo accettabile. Se i tempi medi di caricamento delle pagine aumentano in modo sostanziale rispetto al valore di riferimento (misurato sulle vostre prime 20 applicazioni), è prevedibile che si verifichino reclami da parte degli utenti che potrebbero compromettere l’adozione del sistema. Monitorate con precisione la variazione in millisecondi per ciascuna applicazione.

Copertura delle politiche DLP pari o superiore a quella attuale. La soluzione di sicurezza per il browser dovrebbe rilevare le violazioni DLP individuate dal vostro attuale sistema DLP in linea, oltre ad aggiungere una copertura per i vettori specifici del browser (appunti, stampa, cattura dello schermo).

Soddisfazione degli utenti pari o superiore a 3,5 su una scala di 5 punti. Al di sotto di tale soglia, sono da prevedersi escalation, tentativi di aggirare le misure di sicurezza ed eccezioni concesse dai responsabili, che compromettono il valore della sicurezza.

Il volume dei ticket dell'help desk rientra in un intervallo gestibile. Un picco repentino indica difficoltà di implementazione che non si risolveranno spontaneamente. Si prega di monitorare il numero di ticket per 100 utenti registrati a settimana.

Il tempo medio necessario per la modifica delle politiche è inferiore a quattro ore. Se l'aggiornamento di una regola DLP specifica per il browser richiede più tempo rispetto all'aggiornamento della regola SWG, l'integrazione è insufficiente.

Nessun malfunzionamento critico delle applicazioni. Qualsiasi applicazione tra le prime 20 che non venga visualizzata correttamente o che non superi i test funzionali costituisce un ostacolo alla distribuzione, non un “problema noto”.

Il rapporto “M-Trends 2026” di Mandiant ha rilevato che il tempo mediano che intercorre tra la compromissione iniziale e il passaggio di consegne a un secondo gruppo di attacco si è ridotto a soli 22 secondi nel 2025, rispetto alle oltre otto ore registrate nel 2022. La sicurezza del browser deve operare alla velocità della connessione, rilevando e bloccando le minacce durante la sessione del browser prima che un aggressore possa sfruttare le credenziali compromesse per effettuare un movimento laterale.

Comprendere il ruolo dell’isolamento del browser all’interno della vostra architettura di sicurezza più ampia aiuta a contestualizzare tali metriche. L’isolamento non è una difesa a sé stante, bensì un’escalation guidata da criteri all’interno di un modello di sicurezza a più livelli.