Ci sono due modi diversi di impedire che un dato esca dall’organizzazione, e conviene non confonderli. Le regole di protezione dei dati guardano dentro il contenuto: cercano un numero di carta di credito, un codice fiscale, una parola chiave. Le trust rules di Drive non guardano il contenuto ma la relazione: chi sta condividendo, con quale dominio, in quale direzione. Molti scenari d’esame si risolvono scegliendo lo strumento giusto prima ancora di configurarlo.

Quali servizi copre il DLP e con quali azioni

La protezione dei dati non è identica ovunque. Su Drive analizza i file posseduti dagli utenti, sia in Il mio Drive sia nei Drive condivisi, e agisce sulla condivisione. Su Gmail analizza corpo del messaggio e allegati. Su Chat lavora su due trigger distinti, l’invio di un messaggio e il caricamento di un file, e copre conversazioni uno a uno, chat di gruppo e spazi, compresi quelli di proprietà esterna e quelli con accesso guest. Sono coperti anche Calendar e Gemini, mentre l’integrazione con il browser richiede Chrome Enterprise Premium.

Anche le azioni cambiano per servizio, ed è la differenza che l’esame chiede più spesso. Ovunque esistono «Block», «Warn users» e «Audit only». Gmail aggiunge la quarantena, che trattiene il messaggio per la revisione di un amministratore, e l’applicazione di etichette di classificazione. Su Gmail vale inoltre una simmetria mancante: la regola può scattare sia sui messaggi inviati sia su quelli ricevuti, ma sui messaggi in ingresso le azioni disponibili sono molto più ridotte, perché non ha senso bloccare un invio già avvenuto altrove. La funzione richiede edizioni specifiche: Frontline Standard e Plus, Enterprise Standard e Plus, Enterprise Essentials Plus e le edizioni Education.

Costruire una regola di protezione dei dati

Il percorso nella Admin console è Menu, poi Rules, poi Create rule, poi Data protection, e servono i privilegi di visualizzazione e gestione delle regole DLP. La regola si costruisce in quattro passi.

Prima l’ambito: tutta l’organizzazione oppure unità organizzative e gruppi selezionati, con l’avvertenza che in caso di conflitto il gruppo ha la precedenza sull’unità organizzativa. Poi il trigger, cioè il servizio e l’evento che avviano la scansione. Poi le condizioni sul contenuto. Infine le azioni, che si scelgono per applicazione e possono essere diverse nella stessa regola.

Restano due impostazioni che si dimenticano facilmente. La gravità, fra Low, Medium e High, alimenta la dashboard degli incidenti e permette di distinguere il rumore dai casi veri. Le notifiche all’Alert center recapitano l’evento agli amministratori designati: senza questo passo una regola in sola verifica produce dati che nessuno legge. E per le azioni di blocco, avviso e quarantena si può scrivere un messaggio personalizzato: è la differenza fra un utente che apre un ticket e un utente che capisce da solo perché quel file non si condivide.

Rilevatori predefiniti, espressioni regolari e falsi positivi

I rilevatori predefiniti coprono le categorie più comuni senza doverle descrivere: numeri di carta di credito, IBAN e codici SWIFT, codici fiscali e documenti d’identità di molti paesi, identificativi sanitari, credenziali e chiavi di API. Sono il punto di partenza corretto quando lo scenario nomina un tipo di dato riconoscibile.

L’espressione regolare serve invece per i formati interni all’azienda, quelli che nessun rilevatore può conoscere: la matricola dipendente, il codice commessa, il numero di contratto. Il prezzo da pagare sono i falsi positivi, perché un formato numerico generico intercetta anche ciò che non c’entra. Il correttivo previsto è la corrispondenza di prossimità, che convalida il riscontro solo se accanto compare una parola chiave attesa.

Vale la pena conoscere anche i limiti dichiarati: i rilevatori non garantiscono di trovare tutto, la scansione di un messaggio ha un tempo massimo e i rilevatori più complessi possono non arrivare in fondo, e i file CSV vengono trattati come testo semplice. Per questo una regola nuova si mette prima in sola verifica e si guarda che cosa avrebbe bloccato, poi si passa a bloccare davvero.

Le trust rules per la condivisione su Drive

Le trust rules rispondono a una domanda diversa: non «che cosa c’è nel file», ma «chi può darlo a chi». Definiscono un ambito interno per unità organizzative, gruppi o singoli utenti, una controparte che può essere l’intera organizzazione, un dominio di fiducia o un insieme di destinatari, e una direzione, perché una regola può governare la condivisione in uscita dai file posseduti dalle persone in ambito oppure la ricezione di file da parte loro. Le azioni sono tre: consentire, consentire con un avviso all’utente, bloccare.

Attivarle cambia il resto della configurazione: quando le trust rules sono in uso, le impostazioni classiche di condivisione esterna di Drive diventano inattive, e questo spiega perché una modifica fatta lì può non produrre alcun effetto. In caso di sovrapposizione l’ordine è netto, il blocco vince sul consenso e il consenso vince sull’avviso: basta una regola di blocco su un dominio per fermare quello che una regola generale permetteva.

Sui destinatari senza account Google la logica è asimmetrica. La condivisione è consentita per impostazione predefinita solo verso account Google gestiti, e per raggiungere visitatori e account guest occorre selezionare esplicitamente l’opzione relativa. Le regole di blocco, invece, si applicano ai visitatori in ogni caso. Restano i vincoli operativi da non ignorare quando si pianifica un cambiamento: fino a 200 regole attive e 2.000 complessive, e una propagazione che arriva a 24 ore, o a 48 quando l’ambito include unità organizzative.