Protezione delle applicazioni SaaS tramite controlli a livello di browser

Il Suo CASB impedisce a un collaboratore esterno di scaricare un elenco di clienti da Salesforce su un computer portatile non gestito. Cinque secondi dopo, lo stesso collaboratore seleziona l’intera tabella, la copia negli appunti, la incolla nella finestra di composizione di un account Gmail personale e fa clic su “Invia”. Il CASB non se ne accorge affatto. Il browser, invece, sì — e, con i controlli adeguati, avrebbe potuto impedirlo. La presente guida illustra agli amministratori della sicurezza SaaS e agli operatori CASB un approccio graduale per colmare tale lacuna, implementando controlli a più livelli a livello di browser — remote browser isolation (RBI), politiche secure web gateway SWG), DLP e azioni di sessione — in aggiunta alle implementazioni CASB esistenti.

Prerequisiti: cosa occorre predisporre prima di iniziare

Prima di abilitare i controlli a livello di browser, si assicuri che il Suo ambiente soddisfi quattro condizioni fondamentali. Trascurarle comporta conflitti tra le politiche, frustrazione da parte degli utenti e una copertura incompleta.

1. CASB con modalità proxy forward e reverse già implementate. È necessaria l’ispezione del traffico in linea per le applicazioni SaaS autorizzate (proxy reverse) e la visibilità sullo shadow IT (proxy forward) come base di riferimento per l’applicazione delle politiche. Se la vostra implementazione CASB è basata esclusivamente su API, vi manca il percorso in linea garantito dai controlli del browser.

2. Motore unificato delle politiche DLP. I controlli a livello di browser devono fare riferimento alle stesse classificazioni dei dati — PII, PHI, documenti finanziari, codice sorgente, proprietà intellettuale — utilizzate dalle vostre politiche CASB e DLP per la posta elettronica. Se le vostre definizioni DLP risiedono in silos separati, iniziate a consolidarle. Una classificazione incoerente porta a situazioni in cui un canale blocca ciò che un altro consente. Una piattaforma DLP centralizzata evita questa frammentazione.

3. Integrazione con il provider di identità (IdP) e valutazione dello stato del dispositivo. I controlli del browser diventano molto più efficaci quando si adattano in base all’identità dell’utente e al dispositivo che sta utilizzando. Un collaboratore esterno del reparto marketing che utilizza un MacBook personale dovrebbe essere soggetto a controlli più rigorosi rispetto a un analista finanziario a tempo pieno che utilizza un endpoint Windows gestito. Ciò richiede una federazione SAML/OIDC con il proprio IdP e verifiche dello stato del dispositivo (gestito o non gestito, livello di patch del sistema operativo, stato della crittografia del disco).

4. Inventario delle applicazioni SaaS con classificazione in base alla sensibilità dei dati. Non è possibile definire l’ambito delle politiche relative ai browser senza sapere quali applicazioni SaaS contengano dati sensibili. Classifichino le loro prime 20 o 50 applicazioni SaaS in base al livello di sensibilità dei dati (critico, alto, medio, basso). Le “Best Practices per la governance del SaaS” della CSA raccomandano di valutare i rischi durante tutte le fasi del ciclo di vita del SaaS: valutazione, adozione, utilizzo e cessazione. Questo inventario costituisce il dato di riferimento per la definizione dell’ambito delle politiche.

Fase 1: Colmare le lacune relative agli appunti e ai download negli scenari ad alto rischio

Iniziate da dove il rischio è maggiore e la popolazione di utenti è più ridotta: i dispositivi non gestiti che accedono ad applicazioni SaaS sensibili.

Lo scenario che giustifica la Fase 1: un revisore esterno accede alla vostra istanza di Workday da un computer portatile personale utilizzando l’SSO. Il proxy inverso CASB autentica la sessione e blocca il download dei file in base alla politica aziendale. Tuttavia, il revisore apre un report sulla retribuzione dei dipendenti, seleziona trenta righe di dati salariali, le copia, apre una nuova scheda con un foglio di lavoro Google personale e incolla i dati. Il CASB ha rilevato una sessione Workday autenticata e una sessione di Google Sheets: due eventi distinti, entrambi consentiti singolarmente. Non ha mai rilevato il trasferimento di dati tra le due sessioni, poiché l’operazione relativa agli appunti è avvenuta interamente all’interno del contesto di rendering del browser.

Cosa implementare: Abilitare remote browser isolation tutte le sessioni dei dispositivi non gestiti che accedono alle applicazioni SaaS di Livello 1 (critico) e Livello 2 (alto). L’RBI esegue il rendering dell’applicazione SaaS in un container ospitato nel cloud e trasmette in streaming solo i pixel al browser dell’utente. Questa architettura offre un controllo granulare sulle azioni della sessione:

Restrizione relativa al copia/incolla: bloccare le operazioni di scrittura e lettura negli appunti dalla sessione isolata, oppure consentire l’incollaggio ma bloccare la copia in uscita, al fine di impedire che i dati escano dal contesto dell’applicazione SaaS.

Blocco dei download: impedite completamente il download di file dalla sessione visualizzata oppure limitate i download a tipi di file specifici.

Blocco della stampa: disattivare i comandi di stampa e di salvataggio in formato PDF.

Filigrana sugli screenshot: inserire nel flusso di dati visualizzato una filigrana visibile o forense contenente l'indirizzo e-mail dell'utente e la data e l'ora, al fine di scoraggiare la cattura dello schermo.

La norma NIST SP 800-53 SC 7 impone l’isolamento dei componenti di sistema mediante meccanismi di protezione perimetrale, al fine di controllare i flussi di informazioni e limitare i potenziali danni derivanti da attacchi ostili ed errori. RBI crea proprio questo confine tra i dati dell’applicazione SaaS e il dispositivo locale dell’utente, applicando controlli sui flussi di informazioni che un proxy di rete non è in grado di garantire.

Limitazione dell’ambito di applicazione: applicare tali controlli esclusivamente ai dispositivi non gestiti e al personale di appalto nella Fase 1. Gli endpoint gestiti su cui è stato installato un agente e il cui stato di sicurezza è stato verificato possono essere soggetti a controlli meno restrittivi (come l’inserimento di filigrane senza il blocco degli appunti) al fine di preservare la produttività.

Fase 2: Estensione del DLP del browser agli endpoint gestiti e a una copertura SaaS più ampia

Una volta che la Fase 1 si sarà stabilizzata — in genere dopo 4-6 settimane di raccolta dei dati telemetrici e di messa a punto delle politiche — estendere la copertura ai dispositivi gestiti e a una gamma più ampia di applicazioni SaaS.

Lo scenario che giustifica la Fase 2: un rappresentante commerciale a tempo pieno, che utilizza un laptop gestito dall’azienda, accede a Salesforce tramite Chrome. Apre la scheda di un cliente, copia il nome, l’azienda e il numero di telefono del contatto, quindi li incolla in ChatGPT per generare un’e-mail di contatto personalizzata. Non è stato scaricato alcun file. Non è stata violata alcuna regola di condivisione di Salesforce. Tuttavia, le informazioni personali identificative (PII) del cliente hanno appena lasciato il vostro ambiente SaaS controllato ed sono entrate in uno strumento di intelligenza artificiale di terze parti tramite gli appunti del browser.

Secondo il rapporto “State of SaaS Security Report (2025)” di CSA, il 63% delle organizzazioni segnala una condivisione eccessiva di dati verso l’esterno, mentre il 56% afferma che i dipendenti caricano dati sensibili su applicazioni SaaS non autorizzate — spesso proprio attraverso questi percorsi relativi agli appunti e al caricamento che sfuggono ai controlli tradizionali. Il DLP a livello di browser è il meccanismo di controllo che intercetta tali azioni prima che i dati raggiungano la destinazione non autorizzata.

Cosa implementare:

SWG ha applicato il controllo DLP sugli endpoint gestiti. secure web gateway intercetta il traffico del browser e applica la classificazione DLP ai dati in transito — inclusi l’invio dei dati inseriti nei campi dei moduli, gli eventi di incollaggio dagli appunti nelle applicazioni web e il caricamento di file tramite browser. In questo modo viene intercettato lo scenario sopra descritto, che prevede l’invio di dati da Salesforce a ChatGPT.

RBI selettivo per le categorie sensibili. Anziché isolare tutte le attività di navigazione, si indirizzino le sessioni verso le applicazioni SaaS di Livello 1 e Livello 2 tramite RBI quando il comportamento dell’utente fa scattare un segnale di rischio (ad esempio, l’accesso a un oggetto contenente dati dei clienti, l’apertura di una vista di esportazione, l’accesso a uno strumento di intelligenza artificiale utilizzando credenziali aziendali).

Inserimento di filigrane a scopo deterrente nella registrazione delle sessioni. Applicare filigrane visibili alle sessioni in cui vengono visualizzati dati sensibili, in modo che, qualora un utente fotografasse lo schermo, la filigrana consenta di ricondurre l’immagine a un utente specifico, a una sessione e a un timestamp.

Principio di progettazione delle politiche tratto dalla norma NIST SP 800-53 AC 4: È possibile impiegare meccanismi di applicazione delle politiche a livello di applicazione e di servizio per garantire una maggiore sicurezza delle informazioni e controllare i flussi di informazioni oltre quanto consentito dai controlli a livello di rete. Le soluzioni DLP e RBI a livello di browser operano proprio a questo livello di applicazione e di servizio, aggiungendo un livello di applicazione che i proxy CASB a livello di rete non sono in grado di garantire.

Fase 3: Integrazione dei controlli del browser nella struttura delle politiche SSE

L’implementazione dei controlli sul browser come livello autonomo comporta un sovraccarico operativo: politiche separate, console separate, code di incidenti separate. La Fase 3 unifica l’applicazione delle politiche a livello di browser con il vostro più ampio Security Service Edge (SSE), in modo che un unico motore di policy regoli le decisioni relative a CASB, SWG, DLP, RBI e ZTNA.

Lo scenario che giustifica la Fase 3: il vostro SOC riceve tre avvisi: un avviso CASB che segnala che un utente ha effettuato l’accesso a un’applicazione SaaS “ombra”, un avviso SWG che indica che la sessione del browser dello stesso utente ha attivato una corrispondenza con un modello DLP e un avviso RBI che segnala che è stata bloccata una copia negli appunti. Tre console, tre analisti, tre ticket — per un solo utente che esegue una sequenza di azioni. La politica SSE unificata raggruppa tutto ciò in un unico evento correlato con un unico flusso di lavoro di risposta.

Cosa implementare:

Regole di policy unificate che fanno riferimento all’identità dell’utente, allo stato di sicurezza del dispositivo, al livello di sensibilità delle applicazioni SaaS, alla classificazione dei dati e al tipo di azione del browser (download, appunti, stampa, caricamento) in un’unica istruzione condizionale.

Isolamento adattivo che eleva automaticamente una sessione al livello RBI completo quando la piattaforma SSE rileva una combinazione di segnali — ad esempio, un dispositivo non gestito che accede a un’applicazione di livello 1 mentre il sistema DLP rileva contenuti sensibili nella pagina.

Invio dei dati di telemetria delle sessioni al sistema SIEM/SOAR, in modo che gli eventi a livello di browser (blocco degli appunti, inserimento di filigrane, blocco dei download) siano visibili insieme agli eventi CASB, SWG e ZTNA ai fini della correlazione e dell’analisi.

Il modello di maturità Zero Trust della CISA invita le organizzazioni a gestire e proteggere le applicazioni implementate mediante controlli di accesso granulari e protezioni integrate contro le minacce, puntando a raggiungere una maturità ottimale nei pilastri “Applicazioni e carichi di lavoro” e “Dati”. L’integrazione dei controlli a livello di browser nella politica SSE rappresenta il modo in cui è possibile rendere operativa tale linea guida per le applicazioni SaaS a cui si accede tramite il browser.

Punti di integrazione: dove i controlli del browser si integrano con il vostro stack esistente

I controlli a livello di browser non sostituiscono gli strumenti di sicurezza esistenti, ma colmano il divario di applicazione tra di essi. È opportuno definire chiaramente i punti di integrazione per evitare duplicazioni e garantire una copertura completa.

Si consideri una sequenza di integrazione nel mondo reale: un’organizzazione sanitaria utilizza la modalità API CASB per analizzare le informazioni sanitarie protette (PHI) inattive su Box e applicare le politiche di condivisione. Tuttavia, quando un infermiere specializzato, utilizzando un tablet personale, apre un documento relativo a un paziente tramite il browser, l’analisi tramite API è già stata eseguita e non impedirà quindi la copia della diagnosi del paziente dagli appunti in un’applicazione di messaggistica. Una sessione RBI con restrizioni sugli appunti e l’inserimento di filigrane colma tale lacuna senza richiedere la presenza di un agente endpoint sul tablet personale. L’approccio Skyhigh Security alla protezione delle applicazioni cloud da dispositivi non gestiti affronta esattamente questo caso d’uso combinando proxy inverso, RBI e DLP in una politica integrata.

Indicatori e criteri di successo

I controlli a livello di browser generano dati di telemetria che le precedenti implementazioni basate esclusivamente su CASB non erano in grado di produrre. Definisca le metriche prima dell’implementazione, in modo da poter dimostrare il valore aggiunto e ottimizzare le politiche.

Indicatori operativi (da monitorare settimanalmente):

Blocchi degli eventi relativi agli appunti per utente/app/tipo di dispositivo. Un picco nei blocchi degli appunti per un determinato utente potrebbe indicare un tentativo di esfiltrazione o segnalare una politica troppo restrittiva per un flusso di lavoro legittimo. Indagare sui valori anomali.

Eventi di blocco dei download. Monitoraggio per app SaaS e ruolo utente. Un elevato numero di download bloccati provenienti da una determinata app potrebbe indicare che gli utenti necessitano di un’alternativa sicura (ad esempio, un visualizzatore in sola lettura o un flusso di lavoro di esportazione controllato).

La filigrana ha dato avvio a delle indagini. Si calcoli quante volte uno screenshot o un documento stampato contrassegnato da filigrana è stato ricondotto a un utente nel corso di un’indagine. Anche un numero esiguo ne dimostra il valore deterrente.

Richieste di deroga alle politiche. Monitorare il numero di utenti che richiedono deroghe ai controlli del browser e i motivi addotti. Un elevato volume di deroghe per un’applicazione specifica indica che la politica necessita di un adeguamento.

Indicatori di riduzione del rischio (da monitorare trimestralmente):

Riduzione degli incidenti relativi a dati sensibili che coinvolgono gli appunti o i percorsi di caricamento delle applicazioni SaaS. Si prega di confrontare il volume degli incidenti prima e dopo l’implementazione dei controlli sul browser per le stesse applicazioni SaaS e le stesse fasce di utenti.

Copertura del controllo delle sessioni sui dispositivi non gestiti. Misurare la percentuale di sessioni SaaS sui dispositivi non gestiti che transitano attraverso RBI rispetto a quelle che lo aggirano. Obiettivo: copertura pari o superiore al 95% per le applicazioni di livello 1.

Tempo medio necessario per rilevare i tentativi di esfiltrazione tramite browser. La telemetria del browser dovrebbe ridurre il tempo di rilevamento da giorni (quando ci si affida agli avvisi di scansione DLP a posteriori) a secondi (blocco in tempo reale degli appunti).

Il rapporto DBIR 2025 di Verizon ha rilevato che il 60% delle violazioni ha coinvolto il fattore umano: l’utente che clicca, copia, carica e incolla. I controlli a livello di browser generano dati di monitoraggio proprio su queste azioni umane, fornendo al vostro SOC visibilità su un vettore che i controlli di rete e API trascurano completamente. Nel contempo, Forrester riferisce che circa una violazione dei dati su cinque deriva da incidenti causati da personale interno (2026), e i controlli sulle sessioni del browser garantiscono un’applicazione diretta e in tempo reale delle politiche relative agli appunti e ai percorsi di caricamento che il personale interno sfrutta più frequentemente.

Errori comuni

Errore n. 1: implementare l’isolamento RBI completo per tutti gli utenti sin dal primo giorno. L’isolamento completo dello streaming dei pixel modifica l’esperienza di navigazione. La latenza aumenta leggermente, alcune estensioni del browser smettono di funzionare e le applicazioni web complesse potrebbero essere visualizzate in modo diverso. Se si applica questa misura contemporaneamente a 5.000 dipendenti, l’help desk insorgerà e la dirigenza bloccherà il progetto. Iniziate con i dispositivi non gestiti e le applicazioni ad alto rischio. Espandetevi gradualmente.

Errore 2: applicare politiche del browser identiche a dispositivi gestiti e non gestiti. Un laptop di un collaboratore esterno non gestito richiede il blocco totale degli appunti e la soppressione dei download. Un endpoint aziendale gestito, dotato di agente, crittografia del disco verificata e patch aggiornate, potrebbe necessitare solo di filigrane e restrizioni selettive all’incollaggio. Differenziate le politiche in base allo stato di sicurezza del dispositivo. Il profilo di rischio di una credenziale compromessa su un dispositivo gestito dotato di EDR è fondamentalmente diverso da quello su un dispositivo non gestito privo di visibilità: le vostre politiche relative al browser dovrebbero riflettere tale asimmetria.

Errore 3: Ignorare le destinazioni degli strumenti di IA nelle politiche DLP. Molte organizzazioni hanno configurato il DLP del browser per bloccare i caricamenti verso le tradizionali categorie di “shadow IT” — archiviazione cloud personale, webmail — ma hanno dimenticato di includere gli assistenti di IA. Gli strumenti di IA sono ormai tra le destinazioni non autorizzate più comuni per i dati incollati e caricati. Aggiornate le categorie di URL del vostro SWG e DLP per includere i servizi di IA generativa e applicate le stesse restrizioni relative agli appunti e ai caricamenti che applicate alle altre app non autorizzate.

Errore n. 4: considerare i controlli del browser come un progetto autonomo anziché come un’estensione della politica SSE. Se i controlli del browser risiedono in una console separata con politiche distinte, diventano semplicemente un ulteriore strumento che il SOC ignora. Integrateli nella vostra piattaforma SSE a partire dalla Fase 3, in modo che gli eventi del browser siano correlati agli eventi CASB, SWG e ZTNA in un unico flusso di lavoro dedicato agli incidenti.

Errore n. 5: Trascurare di classificare le applicazioni SaaS in base al livello di sensibilità prima di redigere le politiche. Senza un inventario delle applicazioni SaaS suddiviso per livelli di sensibilità, si rischia di applicare restrizioni eccessive (isolando applicazioni a basso rischio e creando frustrazione tra gli utenti) oppure insufficienti (lasciando applicazioni critiche prive di controlli). Le grandi imprese utilizzano abitualmente da decine a centinaia di offerte SaaS, e la classificazione non è facoltativa: costituisce il fondamento di una politica mirata che evita sia le lacune di sicurezza sia la rivolta degli utenti.