Chrome PDF: Salva in Google Drive apre un buco DLP, come bloccarlo

Il nuovo pulsante Salva in Google Drive integrato nel visualizzatore PDF di Chrome riduce a un solo clic il passaggio tra documento e cloud, ma in molte aziende introduce un vettore di esfiltrazione più “silenzioso” rispetto al classico download locale, perché il file può essere trasferito direttamente in un Drive personale senza mai transitare dalla cartella Download o dai controlli più banali impostati a livello di singolo endpoint.

A gennaio 2026 Chrome pesava circa il 71,4% della quota browser globale, quindi un cambiamento nel suo comportamento operativo tende a propagarsi rapidamente anche nei contesti aziendali e professionali.

Per anni il rischio principale, quando un utente apriva un PDF da un archivio interno dell’impresa era legato alla persistenza locale: download su disco, indicizzazione, copia su supporti rimovibili, sincronizzazione automatica verso storage personali. Oggi, il nuovo pulsante Salva in Google Drive crea un canale di comunicazione diretto da cloud a cloud.

Che cosa fa davvero Salva in Google Drive nel visualizzatore PDF di Chrome

Google descrive la funzione come un meccanismo di salvataggio diretto dei PDF in Drive, con organizzazione automatica in una cartella dedicata (“Contenuti salvati da Chrome”). Lato utente vi è la possibilità di selezionare l’account Google su cui memorizzare il documento PDF.

Nella pratica, l’utente apre un PDF nel visualizzatore interno di Chrome e avvia il trasferimento senza passare dal salvataggio locale; l’interazione è nativa nel visualizzatore, non richiede estensioni e può proporre l’uso di un account diverso da quello eventualmente già presente.

Dal punto di vista del rischio, il punto chiave è che la catena apertura documento seguita dal trasferimento su cloud personale può avvenire senza generare segnali tipici come creazione di un file in Download o un’azione di upload su un sito Web.

È importante notare che la possibilità di portare contenuti in Drive dal browser non nasce oggi: esistono da tempo alternative come la stampa con destinazione Drive e l’estensione “Save to Google Drive”. La novità è l’abbassamento drastico dell’attrito e la collocazione dell’azione nel posto dove l’utente già sta lavorando: il visualizzazione PDF.

Perché il trasferimento può sfuggire al monitoraggio: introduzione di un punto cieco

Molti programmi di Data Loss Prevention (DLP) usati in ufficio e in azienda sono eccellenti quando il dato è un file locale: possono bloccare la scrittura su percorsi specifici, impedire copie verso directory sincronizzate, marcare e tracciare movimenti, applicare policy basate su etichette.

Se però il documento resta in memoria nel visualizzatore e l’azione di “salvataggio” diventa una chiamata applicativa verso servizi Google, non è detto che esista un evento file system equivalente da intercettare. Il risultato è un disallineamento: la policy “non far finire PDF sensibili in cloud personali” resta valida, ma il sensore che l’organizzazione aveva scelto per applicarla non vede più il passaggio critico.

La mitigazione più rapida: policy Chrome e aggiornamento dei template amministrativi

La soluzione più efficace applicabile in azienda passa dall’aggiornamento dei template amministrativi e dall’attivazione di una policy specifica. Su Windows, ciò significa allineare i file ADMX di Chrome a una versione che includa la nuova impostazione (pulsante Download ADM/ADMX templates), quindi applicare la regola che limita gli account utilizzabili per il trasferimento su Drive a partire dal visualizzatore PDF.

La policy adatta è RestrictPdfSaveToGoogleDriveAccountsToPattern, applicabile via GPO o tramite strumenti come Intune. La logica è basata su pattern: si definisce quali account Google possono essere usati per la funzione, tipicamente consentendo solo il dominio aziendale (per esempio un’espressione che vincoli a account terminanti con @azienda.tld).

In ambienti non gestiti o dove la policy è assente, il comportamento è “aperto”: permette cioè la selezione di account personali nel visualizzatore PDF di Chrome.

È possibile anche impostare la restrizione agendo direttamente sulla configurazione del registro di sistema. Esempio dalla finestra del terminale di Windows:

reg add HKLM\Software\Policies\Google\Chrome /v RestrictPdfSaveToGoogleDriveAccountsToPattern /d "*@azienda.tld" /f

Per bloccare completamente la funzione, si può usare un'”astuzia” che consiste nell’autorizzare soltanto l’uso di un account inesistente come none@none.none:

reg add HKLM\Software\Policies\Google\Chrome /v RestrictPdfSaveToGoogleDriveAccountsToPattern /d "none@none.none" /f

Limiti pratici e scenari residuali: cosa resta possibile anche dopo il blocco

Bloccare il bottone o limitarne gli account non chiude ogni via di uscita. Un utente può ancora trasferire contenuti con metodi alternativi: stampa verso destinazioni cloud, uso di estensioni, condivisione tramite applicazioni di terze parti, copia/incolla del contenuto (quando il PDF lo consente), screenshot e reinserimento in documenti, oppure caricamenti manuali su portali Web se l’accesso ai servizi consumer resta permesso.

L’effetto concreto della policy presentata al paragrafo precedente è riportare l’operazione sotto un controllo amministrativo e, soprattutto, ripristinare una separazione tra account aziendali e personali nel punto in cui il browser propone l’azione.

Da qui discende una scelta architetturale: se l’impresa consente l’uso di account personali su macchine di lavoro, ogni funzionalità che semplifica il passaggio verso cloud consumer amplifica il rischio, anche quando non nasce con intento malevolo. Se invece l’organizzazione impone identità gestite, browser controllato e restrizioni lato rete, Salva in Google Drive può diventare una caratteristica di produttività all’interno di un perimetro controllato.