Quando qualcuno chiede “chi ha condiviso quel file fuori dominio”, la risposta non sta in un’unica pagina. Google Workspace separa tre momenti: guardare indietro nei log, guardare il quadro generale nel security center, e farsi avvisare senza doverli guardare. Sapere quale strumento risponde a quale domanda è metà del lavoro.

Dove vivono i log, chi può leggerli e quanto sono freschi

Il punto di ingresso è Reporting > Audit and investigation, dove si sceglie prima di tutto la sorgente: Admin log events per le azioni degli amministratori, User log events per accessi e cambi di password, e poi Drive, Gmail, Chat, Meet, Groups, Devices, OAuth token, SAML, Vault, Rules e molte altre, oltre quaranta in tutto.

Chi vede che cosa dipende dai privilegi. Il privilegio Audit and investigation si articola su tre livelli: View permette di eseguire ricerche e leggere i risultati, View sensitive content aggiunge la visione dei contenuti veri e propri, come il corpo di un messaggio o l’allegato che ha fatto scattare una regola DLP, e Manage abilita le azioni correttive sui risultati. Un super administrator li ha tutti; a un analista di sicurezza si costruisce un ruolo personalizzato con solo quelli che gli servono, perché “vedere il contenuto” è una scelta di riservatezza, non un dettaglio tecnico.

Il terzo elemento è il tempo. La maggior parte delle sorgenti conserva gli eventi per circa sei mesi, mentre i log di Vault restano a tempo indeterminato. Anche il ritardo di indicizzazione varia: Admin, User, Drive, Gmail, Chat, Meet e Devices arrivano quasi in tempo reale, nell’ordine dei minuti; i Groups log events possono richiedere decine di minuti e a volte qualche ora; gli eventi dei token OAuth un paio d’ore. È la spiegazione più frequente di una ricerca che non trova nulla su un fatto appena accaduto: non è sparito, non è ancora arrivato.

Costruire una ricerca che risponda a una domanda precisa

Una ricerca utile parte dalla sorgente giusta e restringe con filtri sugli attributi di quella sorgente — l’attore, l’evento, l’indirizzo IP, il tipo di dispositivo, il documento coinvolto. Nelle edizioni che includono la versione avanzata, cioè l’investigation tool, si passa al condition builder e si combinano più condizioni con operatori AND e OR, si annidano le query, si raggruppano i risultati e si aggiungono colonne. I risultati si scaricano fino a 100.000 righe, quantità che suggerisce da sola quale sia la disciplina corretta: filtrare in console e portare fuori solo ciò che serve davvero.

La differenza fra le edizioni è netta e viene chiesta. Tutti gli amministratori hanno l’audit tool, che cerca e filtra. L’investigation tool — disponibile in Frontline Standard e Plus, Enterprise Standard e Plus, Education Standard e Plus, Enterprise Essentials Plus e Cloud Identity Premium — aggiunge le indagini salvate e condivisibili, le query annidate, i grafici, le activity rule e soprattutto la possibilità di agire sui risultati invece di limitarsi a leggerli, per esempio intervenendo sulle condivisioni di un file o su un messaggio. In quelle edizioni lo stesso strumento è raggiungibile anche da Security > Security center > Investigation tool.

Il security center: dashboard, report e security health

Il security center è la vista aggregata. Da Menu > Security > Security center > Dashboard si leggono pannelli che riassumono l’esposizione del tenant, ciascuno con un report di dettaglio: da qui si apre, per esempio, l’authentication report, che mostra quanta della posta in ingresso soddisfa gli standard di autenticazione e come si distribuisce fra SPF, DKIM e DMARC, con i domini e gli indirizzi IP che scrivono di più all’organizzazione. È il tipico strumento per accorgersi che un dominio partner sta inviando messaggi non autenticati prima che sia un incidente.

Accanto alla dashboard, la pagina security health guarda dalla parte opposta: non gli eventi, ma la configurazione. Elenca le impostazioni di sicurezza del tenant accanto alla raccomandazione di Google e segnala quelle che se ne discostano, permettendo di saltare direttamente alla pagina dove correggerle. Quando la domanda d’esame parla di lacune nella configurazione — condivisione esterna troppo aperta, 2SV non imposta su un’unità organizzativa — la risposta è security health, non l’audit tool: l’audit tool racconta che cosa è successo, security health dice come sei messo adesso.

Regole di attività e avvisi

L’ultimo passo è smettere di guardare. Da Home > Rules > Create rule > Activity si crea una regola che parte da una sorgente di log, applica una condizione sugli attributi — attore, evento, tipo di dispositivo — e produce un’azione quando la condizione si verifica.

Le azioni disponibili sono l’avviso nell’alert center, con gravità High, Medium o Low, e la notifica via email ai super administrator o a un elenco di amministratori scelti; le due si possono combinare. Anche qui l’edizione cambia le possibilità: le reporting rule, disponibili largamente, ammettono un solo valore per attributo e non accettano condizioni unite dall’operatore OR, mentre le activity rule dell’investigation tool — fino a cento — permettono condizioni composte e azioni correttive automatiche. Il flusso da tenere a mente è circolare: una ricerca ben costruita nell’audit tool diventa una regola, la regola genera un avviso nell’alert center, e l’avviso riporta all’indagine.