Analisi dei log di sicurezza in Google Cloud

Last reviewed 2024-05-21 UTC

Questa guida mostra agli esperti di sicurezza come eseguire l'onboarding dei log di Google Cloud da utilizzare nell'analisi della sicurezza. Eseguendo analisi di sicurezza, aiuterai la tua organizzazione a prevenire, rilevare e rispondere a minacce come malware, phishing, ransomware e asset configurati in modo errato.

Questa guida illustra come:

• Consenti l'analisi dei log.
• Inoltra questi log a una singola destinazione a seconda dello strumento di analisi della sicurezza scelto, ad esempio Log Analytics, BigQuery, Google Security Operations o una tecnologia SIEM (Security Information and Event Management) di terze parti.
• Analizza questi log per controllare l'utilizzo del cloud e rilevare potenziali minacce ai tuoi dati e carichi di lavoro utilizzando query di esempio del progetto Community Security Analytics (CSA).

Le informazioni contenute in questa guida fanno parte di Autonomic Security Operations di Google Cloud, che include la trasformazione delle pratiche di rilevamento e risposta e dell'analisi della sicurezza guidata dall'ingegneria per migliorare le funzionalità di rilevamento delle minacce.

In questa guida, i log forniscono l'origine dati da analizzare. Tuttavia, puoi applicare i concetti di questa guida all'analisi di altri dati complementari relativi alla sicurezza di Google Cloud, come i risultati di sicurezza di Security Command Center. Security Command Center Premium fornisce un elenco di rilevatori gestiti aggiornati regolarmente progettati per identificare minacce, vulnerabilità e configurazioni errate all'interno dei sistemi quasi in tempo reale. Analizzando questi indicatori di Security Command Center e correlandoli con i log importati nello strumento di analisi della sicurezza, come descritto in questa guida, puoi ottenere una prospettiva più ampia delle potenziali minacce alla sicurezza.

Il seguente diagramma mostra come interagiscono le origini dati di sicurezza, gli strumenti di analisi della sicurezza e le query CSA.

Il diagramma inizia con le seguenti origini dati di sicurezza: log di Cloud Logging, modifiche delle risorse di Cloud Asset Inventory e risultati di sicurezza di Security Command Center. Il diagramma mostra poi queste origini dati di sicurezza inoltrate allo strumento di analisi della sicurezza di tua scelta: Log Analytics in Cloud Logging, BigQuery, Google Security Operations o un SIEM di terze parti. Infine, il diagramma mostra l'utilizzo delle query CSA con lo strumento di analisi per analizzare i dati di sicurezza raccolti.

Flusso di lavoro di analisi dei log di sicurezza

Questa sezione descrive i passaggi per configurare l'analisi dei log di sicurezza in Google Cloud. Il flusso di lavoro è costituito dai tre passaggi mostrati nel seguente diagramma e descritti nei paragrafi che seguono:

• Attiva i log:in Google Cloud sono disponibili molti log di sicurezza. Ogni log contiene informazioni diverse che possono essere utili per rispondere a domande di sicurezza specifiche. Alcuni log, come gli audit log per le attività di amministrazione, sono abilitati per impostazione predefinita; altri devono essere abilitati manualmente perché comportano costi di importazione aggiuntivi in Cloud Logging. Pertanto, il primo passaggio del flusso di lavoro consiste nell'assegnare la priorità ai log di sicurezza più pertinenti per le tue esigenze di analisi della sicurezza e nell'abilitare singolarmente questi log specifici.

  Per aiutarti a valutare i log in termini di visibilità e copertura del rilevamento delle minacce, questa guida include uno strumento di definizione dell'ambito dei log. Questo strumento mappa ogni log alle tattiche e alle tecniche di minaccia pertinenti nella matrice MITRE ATT&CK® per le aziende. Lo strumento mappa inoltre le regole di Event Threat Detection in Security Command Center ai log su cui si basano. Puoi utilizzare lo strumento di definizione dell'ambito dei log per valutare i log indipendentemente dallo strumento di analisi che utilizzi.

• Indirizza i log: dopo aver identificato e attivato i log da analizzare, il passaggio successivo consiste nell'indirizzare e aggregare i log della tua organizzazione, incluse eventuali cartelle, progetti e account di fatturazione contenuti. La modalità di inoltro dei log dipende dallo strumento di analisi che utilizzi.

  Questa guida descrive le destinazioni di inoltro dei log comuni e mostra come utilizzare un sink aggregato di Cloud Logging per inoltrare i log a livello di organizzazione in un bucket dei log di Cloud Logging o in un set di dati BigQuery, a seconda che tu scelga di utilizzare Log Analytics o BigQuery per l'analisi.

• Esegui l'analisi dei log:dopo aver inoltrato i log a uno strumento di analisi, il passaggio successivo consiste nell'eseguire un'analisi di questi log per identificare eventuali potenziali minacce alla sicurezza. La modalità di analisi dei log dipende dallo strumento di analisi che utilizzi. Se utilizzi Log Analytics o BigQuery, puoi analizzare i log utilizzando query SQL. Se utilizzi Google Security Operations, analizza i log utilizzando le regole YARA-L. Se utilizzi uno strumento SIEM di terze parti, utilizza il linguaggio di query specificato dallo strumento.

  In questa guida troverai le query SQL che puoi utilizzare per analizzare i log in Log Analytics o BigQuery. Le query SQL fornite in questa guida provengono dal progetto Community Security Analytics (CSA). CSA è un insieme open source di analisi della sicurezza di base progettato per fornirti una linea di base di query e regole predefinite che puoi riutilizzare per iniziare ad analizzare i log di Google Cloud.

Le sezioni seguenti forniscono informazioni dettagliate su come configurare e applicare ogni passaggio del flusso di lavoro di analisi dei log di sicurezza.

Attiva log

La procedura di attivazione dei log prevede i seguenti passaggi:

1. Identifica i log di cui hai bisogno utilizzando lo strumento di definizione dell'ambito dei log in questa guida.
2. Registra il filtro dei log generato dallo strumento di definizione dell'ambito dei log per utilizzarlo in un secondo momento prilikom konfiguriranja sink di log.
3. Attiva il logging per ogni tipo di log o servizio Google Cloud identificato. A seconda del servizio, potrebbe essere necessario attivare anche i log di controllo dell'accesso ai dati corrispondenti, come descritto più avanti in questa sezione.

Identificare i log utilizzando lo strumento di definizione dell'ambito dei log

Per aiutarti a identificare i log che soddisfano le tue esigenze di sicurezza e conformità, puoi utilizzare lo strumento di definizione dell'ambito dei log mostrato in questa sezione. Questo strumento fornisce una tabella interattiva che elenca log importanti per la sicurezza in Google Cloud, tra cui Cloud Audit Logs, i log di Access Transparency, i log di rete e diversi log della piattaforma. Questo strumento mappa ogni tipo di log alle seguenti aree:

• Le tattiche e le tecniche di minaccia MITRE ATT&CK che possono essere monitorate con quel log.
• Violazioni della conformità della piattaforma di calcolo Google Cloud CIS che possono essere rilevate in questo log.
• Regole di Event Threat Detection che si basano su quel log.

Lo strumento di definizione dell'ambito dei log genera anche un filtro dei log visualizzato immediatamente dopo la tabella. Man mano che identifichi i log di cui hai bisogno, selezionali nello strumento per aggiornare automaticamente il filtro dei log.

Le seguenti brevi procedure spiegano come utilizzare lo strumento di definizione dell'ambito dei log:

• Per selezionare o rimuovere un log nello strumento di definizione dell'ambito dei log, fai clic sul pulsante di attivazione/disattivazione accanto al nome del log.
• Per selezionare o rimuovere tutti i log, fai clic sul pulsante di attivazione/disattivazione accanto all'intestazione Tipo di log.
• Per vedere quali tecniche MITRE ATT&CK possono essere monitorate da ogni tipo di log, fai clic su accanto all'intestazione Tattiche e tecniche MITRE ATT&CK.

Strumento di definizione dell'ambito dei log

Registra il filtro di log

Il filtro dei log generato automaticamente dallo strumento di definizione dell'ambito dei log contiene tutti i log selezionati nello strumento. Puoi utilizzare il filtro così com'è o perfezionarlo ulteriormente in base alle tue esigenze. Ad esempio, puoi includere (o escludere) le risorse solo in uno o più progetti specifici. Dopo aver creato un filtro dei log che soddisfa i tuoi requisiti di logging, devi salvarlo per utilizzarlo durante il routing dei log. Ad esempio, puoi salvare il filtro in un editor di testo o in una variabile di ambiente come segue:

1. Nella sezione "Filtro log generato automaticamente" che segue lo strumento, copia il codice per il filtro log.
2. (Facoltativo) Modifica il codice copiato per perfezionare il filtro.

3. In Cloud Shell, crea una variabile per memorizzare il filtro dei log:

   export LOG_FILTER='LOG_FILTER'
   

   Sostituisci LOG_FILTER con il codice del filtro di log.

Attivare i log della piattaforma specifici del servizio

Per ogni log della piattaforma selezionato nello strumento di definizione dell'ambito dei log, questi log devono essere attivati (in genere a livello di risorsa) su base servizio. Ad esempio, i log di Cloud DNS sono abilitati a livello di rete VPC. Analogamente, i log di flusso VPC sono abilitati a livello di subnet per tutte le VM al suo interno e i log del logging delle regole firewall sono abilitati a livello di singola regola firewall.

Ogni log della piattaforma ha le proprie istruzioni su come attivare la registrazione. Tuttavia, puoi utilizzare lo strumento di definizione dell'ambito dei log per aprire rapidamente le istruzioni pertinenti per ogni log della piattaforma.

Per scoprire come attivare il logging per un log della piattaforma specifico:

1. Nello strumento di definizione dell'ambito dei log, individua il log della piattaforma da attivare.
2. Nella colonna Attivato per impostazione predefinita, fai clic sul link Attiva corrispondente al log. Il link ti reindirizza a istruzioni dettagliate su come attivare la registrazione per quel servizio.

Abilita gli audit log di accesso ai dati

Come puoi vedere nello strumento di definizione dell'ambito dei log, gli audit log di accesso ai dati di Cloud Audit Logs offrono una copertura ampia per il rilevamento delle minacce. Tuttavia, il loro volume può essere piuttosto elevato. L'attivazione di questi log di controllo dell'accesso ai dati potrebbe quindi comportare costi aggiuntivi per l'importazione, l'archiviazione, l'esportazione e l'elaborazione di questi log. Questa sezione spiega come attivare questi log e presenta alcune best practice per aiutarti a trovare il giusto equilibrio tra valore e costo.

Nota: i log di controllo dell'accesso ai dati potrebbero contenere informazioni che consentono l'identificazione personale (PII), come le identità degli utenti che chiamano e gli indirizzi IP. Devi applicare le impostazioni di controllo dell'accesso dell'accesso e di conservazione appropriate disponibili nello strumento di analisi per proteggere i dati dei log, conservarli solo per il tempo necessario e poi smaltirli in modo sicuro.

Gli audit log per l'accesso ai dati, tranne quelli di BigQuery, sono disabilitati per impostazione predefinita. Per configurare gli audit log per l'accesso ai dati per servizi Google Cloud diversi da BigQuery, devi abilitarli esplicitamente utilizzando la console Google Cloud o utilizzando l'interfaccia a riga di comando Google Cloud per modificare gli oggetti dei criteri Identity and Access Management (IAM). Quando attivi gli audit log di accesso ai dati, puoi anche configurare i tipi di operazioni che vengono registrati. Esistono tre tipi di audit log di accesso ai dati:

• ADMIN_READ: registra le operazioni che leggono i metadati o le informazioni di configurazione.
• DATA_READ: registra le operazioni che leggono i dati forniti dall'utente.
• DATA_WRITE: registra le operazioni che scrivono i dati forniti dall'utente.

Tieni presente che non puoi configurare la registrazione delle operazioni ADMIN_WRITE, ovvero quelle che scrivono metadati o informazioni di configurazione. Le operazioni ADMIN_WRITE sono incluse negli audit log delle attività di amministrazione di Cloud Audit Logs e pertanto non possono essere disattivate.

Best practice: attiva gli audit log di accesso ai dati a livello di cartella o organizzazione per garantire la conformità in tutti i progetti secondari di quella cartella o organizzazione. Quando attivi gli audit log a livello di cartella o organizzazione, il criterio di controllo si applica a tutti i progetti nuovi ed esistenti nella cartella o nell'organizzazione. Questo criterio di controllo non può essere disattivato a livello di progetto.

Gestire il volume degli audit log di accesso ai dati

Quando attivi gli audit log di accesso ai dati, l'obiettivo è massimizzare il loro valore in termini di visibilità della sicurezza, limitando al contempo il loro costo e il loro overhead di gestione. Per aiutarti a raggiungere questo obiettivo, ti consigliamo di procedere come segue per filtrare i log di basso valore e ad alto volume:

• Assegna la priorità ai servizi pertinenti, ad esempio quelli che ospitano carichi di lavoro, chiavi e dati sensibili. Per esempi specifici di servizi a cui potresti assegnare la priorità rispetto ad altri, consulta Configurazione di esempio degli audit log di accesso ai dati.

• Dai la priorità ai progetti pertinenti, ad esempio quelli che ospitano carichi di lavoro di produzione, rispetto a quelli che ospitano ambienti di sviluppo e di gestione temporanea. Per filtrare tutti i log di un determinato progetto, aggiungi la seguente espressione al filtro dei log per l'emissario. Sostituisci PROJECT_ID con l'ID del progetto da cui vuoi filtrare tutti i log:

  Progetto	Espressione di filtro log
  Escludere tutti i log da un determinato progetto	NOT logName =~ "^projects/PROJECT_ID"

• Assegna la priorità a un sottoinsieme di operazioni di accesso ai dati, ad esempio ADMIN_READ, DATA_READ o DATA_WRITE, per un insieme minimo di operazioni registrate. Ad esempio, alcuni servizi come Cloud DNS scrivono tutti e tre i tipi di operazioni, ma puoi attivare il logging solo per le operazioni ADMIN_READ. Dopo aver configurato uno o più di questi tre tipi di operazioni di accesso ai dati, potresti voler escludere operazioni specifiche con volumi particolarmente elevati. Puoi escludere queste operazioni a volume elevato modificando il filtro log della destinazione. Ad esempio, decidi di attivare la registrazione completa degli audit log di accesso ai dati, incluse le operazioni DATA_READ su alcuni servizi di archiviazione critici. Per escludere operazioni di lettura di dati ad alto traffico specifiche in questa situazione, puoi aggiungere le seguenti espressioni di filtro dei log consigliate al filtro dei log del tuo sink:

  Servizio	Espressione di filtro log
  Escludere i log ad alto volume da Cloud Storage	NOT (resource.type="gcs_bucket" AND (protoPayload.methodName="storage.buckets.get" OR protoPayload.methodName="storage.buckets.list"))
  Escludere i log ad alto volume da Cloud SQL	NOT (resource.type="cloudsql_database" AND protoPayload.request.cmd="select")

• Dai la priorità alle risorse pertinenti, ad esempio quelle che ospitano i tuoi carichi di lavoro e i tuoi dati più sensibili. Puoi classificare le risorse in base al valore dei dati che elaborano e al rischio per la sicurezza, ad esempio se sono o meno accessibili dall'esterno. Sebbene gli audit log di accesso ai dati siano attivati per servizio, puoi escludere risorse o tipi di risorse specifici tramite il filtro dei log.

• Escludi entità specifiche dal fatto che i loro accessi ai dati vengano registrati. Ad esempio, puoi esentare i tuoi account di test interno dalla registrazione delle operazioni. Per scoprire di più, consulta la sezione Impostare le esenzioni nella documentazione relativa ai log di audit di accesso ai dati.

Nota: oltre a utilizzare il filtro log del sink per filtrare i log aggiuntivi come descritto in questa sezione, ti consigliamo di escludere l'importazione di questi log in Cloud Logging per motivi di costo. Per impedire l'importazione di questi log, puoi applicare le espressioni di filtro dei log elencate in questa sezione come filtri di esclusione al sink _Default predefinito che inoltra i log (inclusi i log di controllo dell'accesso ai dati) al bucket dei log _Default. I filtri di esclusione hanno l'effetto opposto di un filtro dei log, che è un filtro di inclusione. Pertanto, quando configuri queste espressioni come filtri di esclusione, devi rimuovere l'operatore booleano NOT precedente dalle espressioni di filtro mostrate in questa sezione.

Esempio di configurazione degli audit log di accesso ai dati

La tabella seguente fornisce una configurazione di base del log di controllo di accesso ai dati che puoi utilizzare per i progetti Google Cloud per limitare i volumi dei log e allo stesso tempo ottenere una visibilità sulla sicurezza preziosa:

Livello	Servizi	Tipi di audit log di accesso ai dati	Tattiche MITRE ATT&CK
Servizi di autenticazione e autorizzazione	IAM Identity-Aware Proxy (IAP)^1 Cloud KMS Secret Manager Resource Manager	ADMIN_READ DATA_READ	Accesso alle credenziali Escalation dei privilegi di Discovery
Servizi di archiviazione	BigQuery (attivato per impostazione predefinita) Cloud Storage^1, 2	DATA_READ DATA_WRITE	Esfiltrazione della raccolta
Servizi di infrastruttura	Criteri dell'organizzazione di Compute Engine	ADMIN_READ	Discovery

¹ L'attivazione degli audit log di accesso ai dati per IAP o Cloud Storage può generare grandi volumi di log quando il traffico verso le risorse web protette da IAP o verso gli oggetti Cloud Storage è elevato.

² L'attivazione degli audit log di accesso ai dati per Cloud Storage potrebbe interrompere l'utilizzo dei download del browser autenticati per gli oggetti non pubblici. Per ulteriori dettagli e soluzioni alternative suggerite per questo problema, consulta la guida alla risoluzione dei problemi di Cloud Storage.

Nella configurazione di esempio, noterai come i servizi sono raggruppati in livelli di sensibilità in base ai dati, ai metadati o alla configurazione sottostanti. Questi livelli mostrano la seguente granularità consigliata per il logging di controllo dell'accesso ai dati:

• Servizi di autenticazione e autorizzazione: per questo livello di servizi, consigliamo di eseguire il controllo di tutte le operazioni di accesso ai dati. Questo livello di controllo ti consente di monitorare l'accesso alle chiavi, ai secret e ai criteri IAM sensibili. Il monitoraggio di questo accesso potrebbe aiutarti a rilevare le tattiche MITRE ATT&CK come Discovery, Accesso alle credenziali e Escalation dei privilegi.
• Servizi di archiviazione: per questo livello di servizi, consigliamo di eseguire il controllo delle operazioni di accesso ai dati che coinvolgono i dati forniti dagli utenti. Questo livello di controllo ti aiuta a monitorare l'accesso ai tuoi dati importanti e sensibili. Il monitoraggio di questo accesso potrebbe aiutarti a rilevare tattiche MITRE ATT&CK come Raccolta ed Esfiltrazione nei confronti dei tuoi dati.
• Servizi di infrastruttura: per questo livello di servizi, consigliamo di eseguire l'audit delle operazioni di accesso ai dati che coinvolgono metadati o informazioni di configurazione. Questo livello di controllo ti consente di monitorare la scansione della configurazione dell'infrastruttura. Il monitoraggio di questo accesso potrebbe aiutarti a rilevare tattiche MITRE ATT&CK come la scoperta nei confronti dei tuoi carichi di lavoro.

Log delle route

Dopo aver identificato e attivato i log, il passaggio successivo consiste nel indirizzarli a una singola destinazione. La destinazione, il percorso e la complessità del routing variano in base agli strumenti di analisi utilizzati, come mostrato nel seguente diagramma.

Il diagramma mostra le seguenti opzioni di routing:

• Se utilizzi Log Analytics, devi avere un destinazione aggregata per aggregare i log di tutta la tua organizzazione Google Cloud in un unico bucket Cloud Logging.

• Se utilizzi BigQuery, devi avere un'area di destinazione aggregata per aggregare i log di tutta la tua organizzazione Google Cloud in un unico set di dati BigQuery.

• Se utilizzi Google Security Operations e questo sottoinsieme predefinito di log soddisfa le tue esigenze di analisi della sicurezza, puoi aggregare automaticamente questi log nel tuo account Google Security Operations utilizzando l'importazione integrata di Google Security Operations. Puoi anche visualizzare questo insieme predefinito di log consultando la colonna Esportabile direttamente in Google Security Operations dello strumento di definizione dell'ambito dei log. Per ulteriori informazioni sull'esportazione di questi log predefiniti, consulta Importare i log di Google Cloud in Google Security Operations.

• Se utilizzi BigQuery o un SIEM di terze parti o vuoi esportare un insieme espanso di log in Google Security Operations, il diagramma mostra che è necessario un passaggio aggiuntivo tra l'attivazione dei log e la loro analisi. Questo passaggio aggiuntivo consiste nel configurare un sink aggregato che inoltra i log selezionati in modo appropriato. Se utilizzi BigQuery, questo sink è tutto ciò che ti serve per instradare i log a BigQuery. Se utilizzi un sistema SIEM di terze parti, devi fare in modo che l'obiettivo aggreghi i log selezionati in Pub/Sub o Cloud Storage prima che possano essere estratti nel tuo strumento di analisi.

Nota: se utilizzi Log Analytics (o BigQuery) e hai già configurato un destinazione aggregata per archiviare i log in un bucket di Log Analytics centralizzato (o in un set di dati BigQuery centralizzato), puoi saltare questa sezione della guida e aggiornare la destinazione con il filtro dei log della sezione precedente. Nel caso di Analisi dei log, assicurati di eseguire l'upgrade del bucket di log esistente per utilizzare Analisi dei log.

Le opzioni di instradamento a Google Security Operations e a un SIEM di terze parti non sono coperte in questa guida. Tuttavia, le sezioni seguenti forniscono i passaggi dettagliati per instradare i log a Log Analytics o BigQuery:

1. Configurare una singola destinazione
2. Crea un sink di log aggregato.
3. Concedi l'accesso al sink.
4. Configura l'accesso in lettura alla destinazione.
5. Verifica che i log vengano instradati alla destinazione.

Configurare una singola destinazione

Analisi dei log

Nota: puoi saltare questo passaggio se utilizzi un bucket Cloud Logging già esistente nel progetto Google Cloud in cui vuoi aggregare i log. Puoi utilizzare il bucket _Default, ma ti consigliamo di crearne uno distinto per questo caso d'uso.

1. Apri la console Google Cloud nel progetto Google Cloud in cui vuoi aggregare i log.

   Vai alla console Google Cloud

2. In un terminale Cloud Shell, esegui il seguente comando gcloud per creare un bucket di log:

   gcloud logging buckets create BUCKET_NAME \
     --location=BUCKET_LOCATION \
     --project=PROJECT_ID
   

   Sostituisci quanto segue:

   • PROJECT_ID: l'ID del progetto Google Cloud in cui verranno memorizzati i log aggregati.
   • BUCKET_NAME: il nome del nuovo bucket logging.

   • BUCKET_LOCATION: la posizione geografica del nuovo bucket di logging. Le posizioni supportate sono global, us o eu. Per scoprire di più su queste regioni di archiviazione, consulta Regioni supportate. Se non specifichi una località, viene utilizzata la regione global, il che significa che i log potrebbero trovarsi fisicamente in una qualsiasi delle regioni.

     Nota: dopo aver creato il bucket, non puoi modificare la regione del bucket.

3. Verifica che il bucket sia stato creato:

   gcloud logging buckets list --project=PROJECT_ID
   

4. (Facoltativo) Imposta il periodo di conservazione dei log nel bucket. Il seguente esempio estende la conservazione dei log archiviati nel bucket a 365 giorni:

   gcloud logging buckets update BUCKET_NAME \
     --location=BUCKET_LOCATION \
     --project=PROJECT_ID \
     --retention-days=365
   

5. Esegui l'upgrade del nuovo bucket per utilizzare Analisi dei log seguendo questa procedura.

BigQuery

1. Apri la console Google Cloud nel progetto Google Cloud in cui vuoi aggregare i log.

   Vai alla console Google Cloud

2. In un terminale Cloud Shell, esegui il seguente comando bq mk per creare un set di dati:

   bq --location=DATASET_LOCATION mk \
       --dataset \
       --default_partition_expiration=PARTITION_EXPIRATION \
       PROJECT_ID:DATASET_ID
   

   Sostituisci quanto segue:

   • PROJECT_ID: l'ID del progetto Google Cloud dove verranno archiviati i log aggregati.
   • DATASET_ID: l'ID del nuovo set di dati BigQuery.

   • DATASET_LOCATION: la posizione geografica del set di dati. Una volta creato un set di dati, la posizione non può essere modificata.

     Nota: se scegli UE o una regione basata sull'UE per la posizione del set di dati, i dati dei clienti di BigQuery Core si trovano nell'UE. I dati dei clienti BigQuery di base sono definiti nei Termini specifici del servizio.

   • PARTITION_EXPIRATION: la durata predefinita (in secondi) per le partizioni nelle tabelle partizionate create dallsink di log. Configura la sink di log nella sezione successiva. L'sink di log configurato utilizza tabelle partizionate per giorno in base al timestamp della voce di log. Le partizioni (incluse le voci di log associate) vengono eliminate PARTITION_EXPIRATION secondi dopo la data della partizione.

     Best practice: imposta la proprietà scadenza della partizione predefinita del set di dati in base ai requisiti di conservazione dei log in modo che i log meno recenti scadano. Puoi farlo durante o dopo la creazione del set di dati. In questo modo puoi conservare i log per tutto il tempo necessario, limitando al contempo le dimensioni totali dello spazio di archiviazione dei log e il costo associato. Se hai requisiti di conservazione più granulari in base al tipo di log, puoi eseguire l'override di questa proprietà a livello di tabella dopo che l'sink di log ha iniziato a instradare i log e ha creato le relative tabelle partizionate. Ad esempio, potresti dover conservare i dati di Cloud Audit Logs per tre anni, ma i log di flusso VPC e i log delle regole firewall devono essere conservati solo per 90 giorni. Se non imposta una scadenza predefinita per le partizioni a livello di set di dati e non imposta una scadenza per le partizioni quando viene creata la tabella, le partizioni non scadono mai.

Creare un sink di log aggregato

Indirizzi i log della tua organizzazione alla destinazione creando un sink aggregato a livello di organizzazione. Per includere tutti i log selezionati nello strumento di definizione dell'ambito dei log, configura il sink con il filtro dei log generato dallo strumento.

Nota: l'inoltro dei log a questa nuova destinazione non significa che i log vengono reindirizzati. I log vengono invece archiviati due volte: una volta nel progetto Google Cloud principale e poi di nuovo nella nuova destinazione. Per evitare questo doppio archiviazione dei log, aggiungi un filtro di esclusione al sink _Default di ogni progetto Google Cloud secondario nella tua organizzazione. Per interrompere l'importazione dei log nei sink _Default dei futuri progetti Google Cloud della tua organizzazione, disattiva il sink _Default nelle impostazioni predefinite della tua organizzazione.

Analisi dei log

1. In un terminale Cloud Shell, esegui il seguente comando gcloud per creare un'area di destinazione aggregata a livello di organizzazione:

   gcloud logging sinks create SINK_NAME \
     logging.googleapis.com/projects/PROJECT_ID/locations/BUCKET_LOCATION/buckets/BUCKET_NAME \
     --log-filter="LOG_FILTER" \
     --organization=ORGANIZATION_ID \
     --include-children
   

   Sostituisci quanto segue:

   • SINK_NAME: il nome della destinazione che instrada i log.
   • PROJECT_ID: l'ID del progetto Google Cloud dove verranno archiviati i log aggregati.
   • BUCKET_LOCATION: la posizione del bucket di logging che hai creato per lo spazio di archiviazione dei log.
   • BUCKET_NAME: il nome del bucket logging che hai creato per lo stoccaggio dei log.
   • LOG_FILTER: il filtro dei log salvato dallo strumento di definizione dell'ambito dei log.
   • ORGANIZATION_ID: l'ID risorsa della tua organizzazione.

   Il flag --include-children è importante per includere anche i log di tutti i progetti Google Cloud all'interno della tua organizzazione. Per ulteriori informazioni, consulta la pagina Raccogliere e instradare i log a livello di organizzazione verso le destinazioni supportate.

2. Verifica che il sink sia stato creato:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. Recupera il nome dell'account di servizio associato all'emissario che hai appena creato:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   L'output è simile al seguente:

   writerIdentity: serviceAccount:[e-mail]`
   

4. Copia l'intera stringa per writerIdentity che inizia con serviceAccount:. Questo identificatore è l'account di servizio del sink. Finché non concederai a questo account di servizio l'accesso in scrittura al bucket di log, il routing dei log da questo sink non andrà a buon fine. Nella sezione successiva concedi l'accesso in scrittura all'identità autore del sink.

BigQuery

1. In un terminale Cloud Shell, esegui il seguente comando gcloud per creare un'area di destinazione aggregata a livello di organizzazione:

   gcloud logging sinks create SINK_NAME \
     bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET_ID \
     --log-filter="LOG_FILTER" \
     --organization=ORGANIZATION_ID \
     --use-partitioned-tables \
     --include-children
   

   Sostituisci quanto segue:

   • SINK_NAME: il nome della destinazione che instrada i log.
   • PROJECT_ID: l'ID del progetto Google Cloud in cui vuoi aggregare i log.
   • DATASET_ID: l'ID del set di dati BigQuery che hai creato.
   • LOG_FILTER: il filtro dei log salvato dallo strumento di definizione dell'ambito dei log.
   • ORGANIZATION_ID: l'ID risorsa della tua organizzazione.

   Il flag --include-children è importante per includere anche i log di tutti i progetti Google Cloud all'interno della tua organizzazione. Per ulteriori informazioni, consulta la pagina Raccogliere e instradare i log a livello di organizzazione verso le destinazioni supportate.

   Il flag --use-partitioned-tables è importante per suddividere i dati per giorno in base al campo timestamp della voce di log. In questo modo, le query sui dati vengono semplificate e i relativi costi ridotti, poiché viene ridotta la quantità di dati scansionati dalle query. Un altro vantaggio delle tabelle partizionate è che puoi impostare una scadenza predefinita per le partizioni a livello di set di dati per soddisfare i requisiti di conservazione dei log. Hai già impostato una scadenza predefinita per la partizione quando hai creato la destinazione del set di dati nella sezione precedente. Puoi anche scegliere di impostare una scadenza della partizione a livello di singola tabella, in modo da disporre di controlli granulari per la conservazione dei dati in base al tipo di log.

2. Verifica che il sink sia stato creato:

   gcloud logging sinks list --organization=ORGANIZATION_ID
   

3. Recupera il nome dell'account di servizio associato all'emissario che hai appena creato:

   gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
   

   L'output è simile al seguente:

   writerIdentity: serviceAccount:[e-mail]`
   

4. Copia l'intera stringa per writerIdentity che inizia con serviceAccount:. Questo identificatore è l'account di servizio del sink. Finché non concederai a questo account di servizio l'accesso in scrittura al set di dati BigQuery, il routing dei log da questo sink non andrà a buon fine. Nella sezione successiva concederai l'accesso in scrittura all'identità dello scrittore della destinazione.

Concedi l'accesso al canale

Dopo aver creato il sink di log, devi concedere al sink l'accesso in scrittura alla destinazione, che si tratti del bucket Logging o del set di dati BigQuery.

Nota: per instradare i log a una risorsa protetta da un perimetro di servizio, devi anche aggiungere l'account di servizio per la destinazione a un livello di accesso e poi assegnatelo al perimetro di servizio di destinazione. Questo non è necessario per i canali non aggregati. Per maggiori dettagli, consulta Controlli di servizio VPC: registrazione in Cloud.

Analisi dei log

Per aggiungere le autorizzazioni all'account di servizio della destinazione:

1. Nella console Google Cloud, vai alla pagina IAM:

   Vai alla pagina IAM

2. Assicurati di aver selezionato il progetto Google Cloud di destinazione che contiene il bucket di logging che hai creato per lo stoccaggio centralizzato dei log.

3. Fai clic su Concedi accesso.

4. Nel campo Nuove entità, inserisci l'account di servizio dell'eseguiamo senza il prefisso serviceAccount:. Ricorda che questa identità proviene dal campo writerIdentity recuperato nella sezione precedente dopo aver creato l'eseguitore di importazione.

5. Nel menu a discesa Seleziona un ruolo, seleziona Autore del bucket dei log.

6. Fai clic su Aggiungi condizione IAM per limitare l'accesso dell'account di servizio solo al bucket dei log che hai creato.

7. Inserisci un Titolo e una Descrizione per la condizione.

8. Nel menu a discesa Tipo di condizione, seleziona Risorsa > Nome.

9. Nel menu a discesa Operatore, seleziona Termina con.

10. Nel campo Valore, inserisci la posizione e il nome del bucket come segue:

    locations/BUCKET_LOCATION/buckets/BUCKET_NAME
    

11. Fai clic su Salva per aggiungere la condizione.

12. Fai clic su Salva per impostare le autorizzazioni.

BigQuery

Per aggiungere le autorizzazioni all'account di servizio della destinazione:

1. Nella console Google Cloud, vai a BigQuery:

   Vai a BigQuery

2. Apri il set di dati BigQuery che hai creato per l'archiviazione centralizzata dei log.

3. Nella scheda Informazioni set di dati, fai clic sul menu a discesa Condivisione e poi su Autorizzazioni.

4. Nel riquadro laterale Autorizzazioni set di dati, fai clic su Aggiungi entità.

5. Nel campo Nuove entità, inserisci l'account di servizio dell'eseguiamo senza il prefisso serviceAccount:. Ricorda che questa identità proviene dal campo writerIdentity recuperato nella sezione precedente dopo aver creato l'eseguitore.

6. Nel menu a discesa Ruolo, seleziona BigQuery Data Editor.

7. Fai clic su Salva.

Dopo aver concesso l'accesso al sink, le voci di log iniziano a compilare la destinazione del sink: il bucket di logging o il set di dati BigQuery.

Configura l'accesso in lettura alla destinazione

Ora che il sink di log instrada i log dell'intera organizzazione in un'unica destinazione, puoi eseguire ricerche in tutti questi log. Utilizza le autorizzazioni IAM per gestire le autorizzazioni e concedere l'accesso in base alle esigenze.

Analisi dei log

Per concedere l'accesso per visualizzare ed eseguire query sui log nel nuovo bucket di log:

1. Nella console Google Cloud, vai alla pagina IAM:

   Vai alla pagina IAM

   Assicurati di aver selezionato il progetto Google Cloud che utilizzi per aggregare i log.

2. Fai clic su Aggiungi.

3. Nel campo Nuova entità, aggiungi il tuo account email.

4. Nel menu a discesa Seleziona un ruolo, seleziona Accesso alle visualizzazioni dei log.

   Questo ruolo fornisce all'entità appena aggiunta l'accesso in lettura a tutte le visualizzazioni per tutti i bucket del progetto Google Cloud. Per limitare l'accesso di un utente, aggiungi una condizione che consenta all'utente di leggere solo dal nuovo bucket.

   1. Fai clic su Aggiungi condizione.

   2. Inserisci un Titolo e una Descrizione per la condizione.

   3. Nel menu a discesa Tipo di condizione, seleziona Risorsa > Nome.

   4. Nel menu a discesa Operatore, seleziona Termina con.

   5. Nel campo Valore, inserisci la posizione e il nome del bucket, nonché la visualizzazione dei log predefinita _AllLogs come segue:

      locations/BUCKET_LOCATION/buckets/BUCKET_NAME/views/_AllLogs
      

      Nota: Cloud Logging crea automaticamente la visualizzazione _AllLogs per ogni bucket, che mostra tutti i log al suo interno. Per un controllo più granulare sui log che possono essere visualizzati e sottoposti a query all'interno del bucket dei log, puoi creare e utilizzare una visualizzazione dei log personalizzata anziché _AllLogs.

   6. Fai clic su Salva per aggiungere la condizione.

5. Fai clic su Salva per impostare le autorizzazioni.

BigQuery

Per concedere l'accesso in visualizzazione e per eseguire query sui log nel set di dati BigQuery, segui i passaggi descritti nella sezione Concedere l'accesso a un set di dati della documentazione di BigQuery.

Verifica che i log vengano instradati alla destinazione

Analisi dei log

Quando indirizzi i log a un bucket di log di cui è stato eseguito l'upgrade a Log Analytics, puoi visualizzare ed eseguire query su tutte le voci di log tramite un'unica visualizzazione dei log con uno schema unificato per tutti i tipi di log. Segui questi passaggi per verificare che i log vengano indirizzati correttamente.

1. Nella console Google Cloud, vai alla pagina Log Analytics:

   Vai ad Analisi dei log

   Assicurati di aver selezionato il progetto Google Cloud che utilizzi per aggregare i log.

2. Fai clic sulla scheda Visualizzazioni log.

3. Espandi le visualizzazioni log nel bucket dei log che hai creato (BUCKET_NAME), se non è già espanso.

4. Seleziona la visualizzazione dei log predefinita _AllLogs. Ora puoi esaminare l'intero schema del log nel riquadro a destra, come mostrato nello screenshot seguente:

   

5. Accanto a _AllLogs, fai clic su Query . In questo modo, l'editor Query viene compilato con una query SQL di esempio per recuperare le voci di log di recente instradamento.

6. Fai clic su Esegui query per visualizzare le voci di log di recente instradate.

A seconda del livello di attività nei progetti Google Cloud della tua organizzazione, potrebbe essere necessario attendere alcuni minuti prima che alcuni log vengano generati e poi indirizzati al tuo bucket dei log.

BigQuery

Quando inoltri i log a un set di dati BigQuery, Cloud Logging crea tabelle BigQuery per contenere le voci di log, come mostrato nella seguente schermata:

Lo screenshot mostra in che modo Cloud Logging nomina ogni tabella BigQuery in base al nome del log a cui appartiene una voce di log. Ad esempio, la tabella cloudaudit_googleapis_com_data_access selezionata nello screenshot contiene gli audit log di accesso ai dati il cui ID log è cloudaudit.googleapis.com%2Fdata_access. Oltre a essere denominata in base alla voce di log corrispondente, ogni tabella viene anche suddivisa in base ai timestamp di ogni voce di log.

A seconda del livello di attività nei progetti Google Cloud della tua organizzazione, potrebbe essere necessario attendere alcuni minuti prima che alcuni log vengano generati e poi indirizzati al tuo set di dati BigQuery.

Nota: sia i log delle attività di amministrazione sia i log degli accessi ai dati vengono caricati in BigQuery con il campo voce di log protoPayload rinominato in protoPayload_auditlog in BigQuery. Per ulteriori informazioni sulle conversioni dello schema eseguite da Cloud Logging prima della scrittura in BigQuery, consulta Campi nei log di controllo esportati.

Analisi dei log

Puoi eseguire una vasta gamma di query sui log di controllo e della piattaforma. L'elenco seguente fornisce un insieme di domande di sicurezza di esempio che potresti porre ai tuoi log. Per ogni domanda in questo elenco, esistono due versioni della query CSA corrispondente: una da utilizzare con Log Analytics e una con BigQuery. Utilizza la versione della query corrispondente alla destinazione del canale che hai configurato in precedenza.

Analisi dei log

Prima di utilizzare una delle query SQL riportate di seguito, sostituisci MY_PROJECT_ID con l'ID del progetto Google Cloud in cui hai creato il bucket di log (ovvero PROJECT_ID)) e MY_DATASET_ID con la regione e il nome del bucket di log (ovvero BUCKET_LOCATION.BUCKET_NAME).

Vai ad Analisi dei log

BigQuery

Prima di utilizzare una delle query SQL riportate di seguito, sostituisci MY_PROJECT_ID con l'ID del progetto Google Cloud in cui hai creato il set di dati BigQuery (ovvero PROJECT_ID)) e MY_DATASET_ID con il nome del set di dati (ovvero DATASET_ID).

Vai a BigQuery

1. Domande su accesso e accesso
   • Ci sono tentativi di accesso sospetti segnalati da Google Workspace?
   • Ci sono stati errori di accesso eccessivi da parte di qualsiasi identità utente?
   • Ci sono stati tentativi di accesso che violano i Controlli di servizio VPC?
   • Ci sono stati tentativi di accesso che violano i controlli di accesso di Identity-Aware Proxy?
2. Domande sulle modifiche alle autorizzazioni
   • Qualche utente è stato aggiunto a gruppi con privilegi elevati?
   • Sono state concesse autorizzazioni a un account di servizio?
   • Esistono account di servizio o chiavi creati da un'identità non approvata?
   • Qualche utente è stato aggiunto (o rimosso) dal criterio IAM sensibile?
3. Domande sulle attività di provisioning
   • Sono state apportate modifiche alle impostazioni di registrazione?
   • Ci sono log di flusso VPC disabilitati?
   • È stato modificato un numero insolito di regole firewall la scorsa settimana?
   • Sono state eliminate VM nell'ultima settimana?
4. Domande sull'utilizzo dei carichi di lavoro
   • È stato registrato un utilizzo anomalo dell'API da parte di un'identità utente nell'ultima settimana?
   • Qual è l'utilizzo dell'autoscaling al giorno nell'ultimo mese?
5. Domande sull'accesso ai dati
   • Quali utenti hanno avuto accesso più di frequente ai dati nell'ultima settimana?
   • Quali utenti hanno avuto accesso ai dati nella tabella "accounts" il mese scorso?
   • A quali tabelle viene eseguito l'accesso più di frequente e da chi?
   • Quali sono le 10 query più eseguite su BigQuery nell'ultima settimana?
   • Quali sono le azioni più comuni registrate nel log di accesso ai dati nell'ultimo mese?
6. Domande sulla sicurezza della rete
   • Esistono connessioni da un nuovo indirizzo IP a una subnet specifica?
   • Esistono connessioni bloccate da Google Cloud Armor?
   • Sono stati rilevati virus o malware di alta gravità da Cloud IDS?
   • Quali sono i principali domini sottoposti a query da Cloud DNS dalla tua rete VPC?

Domande su accesso e accesso

Queste query di esempio eseguono un'analisi per rilevare tentativi di accesso o tentativi di accesso iniziali sospetti al tuo ambiente Google Cloud.

Nota: le attività di accesso vengono acquisite nei log di Cloud Identity inclusi nell'audit degli accessi di Google Workspace. Per analizzare l'attività di accesso e utilizzare alcune delle query in questa sezione, devi attivare la condivisione dei dati di Google Workspace con Google Cloud. Per scoprire di più sulla condivisione degli audit log di Google Workspace con Google Cloud, consulta Visualizzare e gestire gli audit log di Google Workspace.

Ci sono stati tentativi di accesso sospetti segnalati da Google Workspace?

Se esegui una ricerca nei log di Cloud Identity che fanno parte del controllo degli accessi di Google Workspace, la seguente query rileva i tentativi di accesso sospetti segnalati da Google Workspace. Questi tentativi di accesso potrebbero provenire dalla console Google Cloud, dalla Console di amministrazione o dalla gcloud CLI.

Analisi dei log

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.method_name, parameter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS parameter
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND proto_payload.audit_log IS NOT NULL
  AND proto_payload.audit_log.service_name = "login.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.login.LoginService.loginSuccess"
  AND JSON_VALUE(parameter.name) = "is_suspicious"
  AND JSON_VALUE(parameter.boolValue) = "true"

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`,
  UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS parameter
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND protopayload_auditlog.metadataJson IS NOT NULL
  AND protopayload_auditlog.serviceName = "login.googleapis.com"
  AND protopayload_auditlog.methodName = "google.login.LoginService.loginSuccess"
  AND JSON_VALUE(parameter, '$.name') = "is_suspicious"
  AND JSON_VALUE(parameter, '$.boolValue') = "true"

Ci sono stati tentativi di accesso eccessivi da parte di qualsiasi identità utente?

Se esegui una ricerca nei log di Cloud Identity che fanno parte di Google Workspace Login Audit, la seguente query rileva gli utenti che hanno avuto tre o più accessi consecutivi insuccessi nelle ultime 24 ore.

Analisi dei log

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  MIN(timestamp) AS earliest,
  MAX(timestamp) AS latest,
  count(*) AS attempts
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND proto_payload.audit_log.service_name = "login.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.login.LoginService.loginFailure"
GROUP BY
  1
HAVING
  attempts >= 3

BigQuery

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  MIN(timestamp) AS earliest,
  MAX(timestamp) AS latest,
  count(*) AS attempts
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
  AND protopayload_auditlog.serviceName="login.googleapis.com"
  AND protopayload_auditlog.methodName="google.login.LoginService.loginFailure"
GROUP BY
  1
HAVING
  attempts >= 3

Ci sono stati tentativi di accesso che violano i Controlli di servizio VPC?

Analizzando gli audit log sugli accessi negati in base ai criteri di Cloud Audit Logs, la seguente query rileva i tentativi di accesso bloccati da Controlli di servizio VPC. Eventuali risultati della query potrebbero indicare potenziali attività dannose, come tentativi di accesso da reti non autorizzate che utilizzano credenziali rubate.

Analisi dei log

SELECT
  timestamp,
  log_name,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  JSON_VALUE(proto_payload.audit_log.metadata.violationReason) as violationReason, 
  IF(JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations) IS NULL, 'ingress', 'egress') AS violationType,
  COALESCE(
    JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations[0].targetResource),
    JSON_VALUE(proto_payload.audit_log.metadata.egressViolations[0].targetResource)
  ) AS  targetResource,
  COALESCE(
    JSON_VALUE(proto_payload.audit_log.metadata.ingressViolations[0].servicePerimeter),
    JSON_VALUE(proto_payload.audit_log.metadata.egressViolations[0].servicePerimeter)
  ) AS  servicePerimeter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND proto_payload.audit_log IS NOT NULL
  AND JSON_VALUE(proto_payload.audit_log.metadata, '$."@type"') = 'type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata'
ORDER BY
  timestamp DESC
LIMIT 1000

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  JSON_VALUE(protopayload_auditlog.metadataJson, '$.violationReason') as violationReason, 
  IF(JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations') IS NULL, 'ingress', 'egress') AS violationType,
  COALESCE(
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations[0].targetResource'),
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.egressViolations[0].targetResource')
  ) AS  targetResource,
  COALESCE(
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.ingressViolations[0].servicePerimeter'),
    JSON_VALUE(protopayload_auditlog.metadataJson, '$.egressViolations[0].servicePerimeter')
  ) AS  servicePerimeter
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_policy`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND JSON_VALUE(protopayload_auditlog.metadataJson, '$."@type"') = 'type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata'
ORDER BY
  timestamp DESC
LIMIT 1000

Ci sono stati tentativi di accesso che violano i controlli di accesso IAP?

Analizzando i log dell'Application Load Balancer esterno, la seguente query rileva i tentativi di accesso bloccati dall'IAP. Eventuali risultati della query potrebbero indicare un tentativo di accesso iniziale o di sfruttamento di una vulnerabilità.

Analisi dei log

SELECT
  timestamp,
  http_request.remote_ip,
  http_request.request_method,
  http_request.status,
  JSON_VALUE(resource.labels.backend_service_name) AS backend_service_name,
  http_request.request_url
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND JSON_VALUE(json_payload.statusDetails) = "handled_by_identity_aware_proxy"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  httpRequest.remoteIp,
  httpRequest.requestMethod,
  httpRequest.status,
  resource.labels.backend_service_name,
  httpRequest.requestUrl,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].requests`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND jsonpayload_type_loadbalancerlogentry.statusdetails = "handled_by_identity_aware_proxy"
ORDER BY
  timestamp DESC

Domande sulle modifiche alle autorizzazioni

Queste query di esempio eseguono un'analisi delle attività di amministratore che modificano le autorizzazioni, incluse le modifiche ai criteri IAM, ai gruppi e alle iscrizioni ai gruppi, agli account di servizio e a eventuali chiavi associate. Queste modifiche alle autorizzazioni potrebbero fornire un elevato livello di accesso a dati o ambienti sensibili.

Nota: le modifiche ai gruppi vengono acquisite in Controllo dell'amministratore di Google Workspace. Per analizzare l'attività di modifica dei gruppi e utilizzare alcune delle query in questa sezione, devi attivare la condivisione dei dati di Google Workspace con Google Cloud. Per scoprire di più sulla condivisione degli audit log di Google Workspace con Google Cloud, consulta Visualizzare e gestire gli audit log di Google Workspace.

Qualche utente è stato aggiunto a gruppi con privilegi elevati?

Analizzando gli audit log di Google Workspace Admin Audit, la seguente query rileva gli utenti che sono stati aggiunti a uno dei gruppi con privilegi elevati elencati nella query. L'espressione regolare nella query viene utilizzata per definire i gruppi (ad esempio [e-mail] o [e-mail]) da monitorare. Eventuali risultati della query potrebbero indicare un'escalation di privilegi malevola o accidentale.

Analisi dei log

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.resource_name,
  (SELECT JSON_VALUE(x.value)
   FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
   WHERE JSON_VALUE(x.name) = "USER_EMAIL") AS user_email,
  (SELECT JSON_VALUE(x.value)
   FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
   WHERE JSON_VALUE(x.name) = "GROUP_EMAIL") AS group_email,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 120 DAY)
  AND proto_payload.audit_log.service_name = "admin.googleapis.com"
  AND proto_payload.audit_log.method_name = "google.admin.AdminService.addGroupMember"
  AND EXISTS(
    SELECT * FROM UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.metadata.event[0].parameter)) AS x
    WHERE
      JSON_VALUE(x.name) = "GROUP_EMAIL"
      AND REGEXP_CONTAINS(JSON_VALUE(x.value), r'(admin|prod).*') -- Update regexp with other sensitive groups if applicable
  )

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.methodName,
  protopayload_auditlog.resourceName,
  (SELECT JSON_VALUE(x, '$.value')
   FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
   WHERE JSON_VALUE(x, '$.name') = "USER_EMAIL") AS userEmail,
  (SELECT JSON_VALUE(x, '$.value')
   FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
   WHERE JSON_VALUE(x, '$.name') = "GROUP_EMAIL") AS groupEmail,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 120 DAY)
  AND protopayload_auditlog.serviceName = "admin.googleapis.com"
  AND protopayload_auditlog.methodName = "google.admin.AdminService.addGroupMember"
  AND EXISTS(
    SELECT * FROM UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.metadataJson, '$.event[0].parameter')) AS x
    WHERE
      JSON_VALUE(x, '$.name') = 'GROUP_EMAIL'
      AND REGEXP_CONTAINS(JSON_VALUE(x, '$.value'), r'(admin|prod).*') -- Update regexp with other sensitive groups if applicable
  )

Sono state concesse autorizzazioni a un account di servizio?

Analizzando gli audit log delle attività amministrative di Cloud Audit Logs, la seguente query rileva eventuali autorizzazioni concesse a qualsiasi entità su un account di servizio. Alcuni esempi di autorizzazioni che potrebbero essere concesse sono la possibilità di assumere il ruolo dell'account di servizio o di creare chiavi dell'account di servizio. Qualsiasi risultato della query potrebbe indicare un'istanza di escalation dei privilegi o un rischio di compromissione delle credenziali.

Analisi dei log

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email as grantor,
  JSON_VALUE(bindingDelta.member) as grantee,
  JSON_VALUE(bindingDelta.role) as role,
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.service_data.policyDelta.bindingDeltas)) AS bindingDelta
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  -- AND log_id = "cloudaudit.googleapis.com/activity"
  AND (
    (resource.type = "service_account"
    AND proto_payload.audit_log.method_name LIKE "google.iam.admin.%.SetIAMPolicy")
    OR
    (resource.type IN ("project", "folder", "organization")
    AND proto_payload.audit_log.method_name = "SetIamPolicy"
    AND JSON_VALUE(bindingDelta.role) LIKE "roles/iam.serviceAccount%")
  )
  AND JSON_VALUE(bindingDelta.action) = "ADD"
  -- Principal (grantee) exclusions
  AND JSON_VALUE(bindingDelta.member) NOT LIKE "[e-mail]"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail as grantor,
  bindingDelta.member as grantee,
  bindingDelta.role,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName,
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`,
  UNNEST(protopayload_auditlog.servicedata_v1_iam.policyDelta.bindingDeltas) AS bindingDelta
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY)
  AND (
    (resource.type = "service_account"
    AND protopayload_auditlog.methodName LIKE "google.iam.admin.%.SetIAMPolicy")
    OR
    (resource.type IN ("project", "folder", "organization")
    AND protopayload_auditlog.methodName = "SetIamPolicy"
    AND bindingDelta.role LIKE "roles/iam.serviceAccount%")
  )
  AND bindingDelta.action = 'ADD'
  -- Principal (grantee) exclusions
  AND bindingDelta.member NOT LIKE "[e-mail]"
ORDER BY
  timestamp DESC

Esistono account di servizio o chiavi creati da un'identità non approvata?

Analizzando i log di controllo delle attività amministrative, la seguente query rileva eventuali account o chiavi di servizio creati manualmente da un utente. Ad esempio, potresti seguire una best practice per consentire la creazione di account di servizio solo da parte di un account di servizio approvato nell'ambito di un flusso di lavoro automatico. Pertanto, qualsiasi creazione di account di servizio al di fuori di questo flusso di lavoro è considerata non conforme e potenzialmente dannosa.

Analisi dei log

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.resource_name,
  JSON_VALUE(proto_payload.audit_log.response.email) as service_account_email
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="service_account"
  AND proto_payload.audit_log.method_name LIKE "%CreateServiceAccount%"
  AND proto_payload.audit_log.authentication_info.principal_email NOT LIKE "%.gserviceaccount.com"

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.methodName,
  protopayload_auditlog.resourceName,
  JSON_VALUE(protopayload_auditlog.responseJson, "$.email") as serviceAccountEmail
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY)
  AND resource.type="service_account"
  AND protopayload_auditlog.methodName LIKE "%CreateServiceAccount%"
  AND protopayload_auditlog.authenticationInfo.principalEmail NOT LIKE "%.gserviceaccount.com"

Qualche utente è stato aggiunto (o rimosso) dal criterio IAM sensibile?

Se esegui una ricerca nei log di controllo delle attività di amministrazione, la seguente query rileva qualsiasi modifica dell'accesso di un utente o di un gruppo per una risorsa protetta da IAP, ad esempio un servizio di backend Compute Engine. La seguente query cerca in tutti gli aggiornamenti dei criteri IAM le risorse IAP che coinvolgono il ruolo IAM roles/iap.httpsResourceAccessor. Questo ruolo fornisce le autorizzazioni per accedere alla risorsa HTTPS o al servizio di backend. Eventuali risultati della query potrebbero indicare tentativi di aggirare le difese di un servizio di backend che potrebbe essere esposto a internet.

Analisi dei log

SELECT
  timestamp,
  proto_payload.audit_log.authentication_info.principal_email,
  resource.type,
  proto_payload.audit_log.resource_name,
  JSON_VALUE(binding, '$.role') as role,
  JSON_VALUE_ARRAY(binding, '$.members') as members
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(JSON_QUERY_ARRAY(proto_payload.audit_log.response, '$.bindings')) AS binding
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  -- AND log_id = "cloudaudit.googleapis.com/activity"
  AND proto_payload.audit_log.service_name = "iap.googleapis.com"
  AND proto_payload.audit_log.method_name LIKE "%.IdentityAwareProxyAdminService.SetIamPolicy"
  AND JSON_VALUE(binding, '$.role') = "roles/iap.httpsResourceAccessor"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  protopayload_auditlog.authenticationInfo.principalEmail,
  resource.type,
  protopayload_auditlog.resourceName,
  JSON_VALUE(binding, '$.role') as role,
  JSON_VALUE_ARRAY(binding, '$.members') as members
FROM
  `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`,
  UNNEST(JSON_QUERY_ARRAY(protopayload_auditlog.responseJson, '$.bindings')) AS binding
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 400 DAY)
  AND protopayload_auditlog.serviceName = "iap.googleapis.com"
  AND protopayload_auditlog.methodName LIKE "%.IdentityAwareProxyAdminService.SetIamPolicy"
  AND JSON_VALUE(binding, '$.role') = "roles/iap.httpsResourceAccessor"
ORDER BY
  timestamp DESC

Domande sulle attività di provisioning

Queste query di esempio eseguono analisi per rilevare attività amministrative anomale o sospette, come il provisioning e la configurazione delle risorse.

Sono state apportate modifiche alle impostazioni di logging?

Se esegui una ricerca nei log di controllo delle attività di amministrazione, la seguente query rileva eventuali modifiche apportate alle impostazioni di registrazione. Il monitoraggio delle impostazioni di logging ti aiuta a rilevare la disattivazione accidentale o dannosa dei log di controllo e tecniche di evasione della difesa simili.

Analisi dei log

SELECT
  receive_timestamp, timestamp AS eventTimestamp,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  proto_payload.audit_log.service_name = "logging.googleapis.com"
  AND log_id = "cloudaudit.googleapis.com/activity"

BigQuery

SELECT
  receiveTimestamp, timestamp AS eventTimestamp,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.authenticationInfo.principalEmail, 
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  protopayload_auditlog.serviceName = "logging.googleapis.com"

Esistono log di flusso VPC disattivati?

Se esegui una ricerca negli audit log delle attività di amministrazione, la seguente query rileva qualsiasi subnet per la quale i log di flusso VPC sono stati disattivati attivamente . Il monitoraggio delle impostazioni dei log di flusso VPC consente di rilevare la disattivazione accidentale o dannosa dei log di flusso VPC e tecniche di evasione della difesa simili.

Analisi dei log

SELECT
  receive_timestamp, timestamp AS eventTimestamp,
  proto_payload.audit_log.request_metadata.caller_ip,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  proto_payload.audit_log.method_name = "v1.compute.subnetworks.patch" 
  AND (
    JSON_VALUE(proto_payload.audit_log.request, "$.logConfig.enable") = "false"
    OR JSON_VALUE(proto_payload.audit_log.request, "$.enableFlowLogs") = "false"
  )

BigQuery

SELECT
  receiveTimestamp, timestamp AS eventTimestamp,
  protopayload_auditlog.requestMetadata.callerIp,
  protopayload_auditlog.authenticationInfo.principalEmail, 
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
protopayload_auditlog.methodName = "v1.compute.subnetworks.patch" 
AND JSON_VALUE(protopayload_auditlog.requestJson, "$.logConfig.enable") = "false"

È stato modificato un numero insolitamente elevato di regole firewall nell'ultima settimana?

Se esegui una ricerca negli audit log per le attività di amministrazione, la seguente query rileva eventuali modifiche anomale alle regole firewall in un determinato giorno della settimana precedente. Per determinare se è presente un outlier, la query esegue un'analisi statistica sui conteggi giornalieri delle modifiche delle regole del firewall. Le medie e le deviazioni standard vengono calcolate per ogni giorno esaminando i conteggi giornalieri precedenti con una finestra temporale di 90 giorni. Viene considerato un outlier quando il conteggio giornaliero è superiore a due deviazioni standard sopra la media. La query, incluso il coefficiente di deviazione standard e le finestre temporali, può essere configurata in base al profilo della tua attività di provisioning cloud e per ridurre al minimo i falsi positivi.

Analisi dei log

SELECT
  *
FROM (
  SELECT
    *,
    AVG(counter) OVER (
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
    STDDEV(counter) OVER (
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
    COUNT(*) OVER (
      RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
  FROM (
    SELECT
      EXTRACT(DATE FROM timestamp) AS day,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.method_name IGNORE NULLS) AS actions,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.authentication_info.principal_email IGNORE NULLS) AS actors,
      COUNT(*) AS counter
    FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
    WHERE
      timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
      AND proto_payload.audit_log.method_name LIKE "v1.compute.firewalls.%"
      AND proto_payload.audit_log.method_name NOT IN ("v1.compute.firewalls.list", "v1.compute.firewalls.get")
    GROUP BY
      day
  )
)
WHERE
  counter > avg + 2 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

BigQuery

SELECT
  *,
  AVG(counter) OVER (
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
  STDDEV(counter) OVER (
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
  COUNT(*) OVER (
    RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
FROM (
  SELECT
    EXTRACT(DATE FROM timestamp) AS day,
    ARRAY_AGG(DISTINCT protopayload_auditlog.methodName IGNORE NULLS) AS actions,
    ARRAY_AGG(DISTINCT protopayload_auditlog.authenticationInfo.principalEmail IGNORE NULLS) AS actors,
    COUNT(*) AS counter
  FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
  WHERE
    timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
    AND protopayload_auditlog.methodName LIKE "v1.compute.firewalls.%"
    AND protopayload_auditlog.methodName NOT IN ("v1.compute.firewalls.list", "v1.compute.firewalls.get")
  GROUP BY
    day
)
WHERE TRUE
QUALIFY
  counter > avg + 2 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

Sono state eliminate VM nell'ultima settimana?

Se esegui una ricerca nei log di controllo delle attività di amministrazione, la seguente query elenca tutte le istanze Compute Engine eliminate nell'ultima settimana. Questa query può aiutarti a controllare le eliminazioni delle risorse e a rilevare potenziali attività dannose.

Analisi dei log

SELECT
  timestamp,
  JSON_VALUE(resource.labels.instance_id) AS instance_id,
  proto_payload.audit_log.authentication_info.principal_email, 
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.method_name
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  resource.type = "gce_instance"
  AND proto_payload.audit_log.method_name = "v1.compute.instances.delete"
  AND operation.first IS TRUE
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
  timestamp desc,
  instance_id
LIMIT
  1000

BigQuery

SELECT
  timestamp,
  resource.labels.instance_id,
  protopayload_auditlog.authenticationInfo.principalEmail,
  protopayload_auditlog.resourceName,
  protopayload_auditlog.methodName
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  resource.type = "gce_instance"
  AND protopayload_auditlog.methodName = "v1.compute.instances.delete"
  AND operation.first IS TRUE
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
ORDER BY
  timestamp desc,
  resource.labels.instance_id
LIMIT
  1000

Domande sull'utilizzo dei carichi di lavoro

Queste query di esempio eseguono analisi per capire chi e cosa utilizza i tuoi carichi di lavoro e le tue API cloud e ti aiutano a rilevare potenziali comportamenti dannosi internamente o esternamente.

È stato registrato un utilizzo anomalo dell'API da parte di un'identità utente nell'ultima settimana?

Analizzando tutti Cloud Audit Logs, la seguente query rileva un utilizzo anomalo dell'API da parte di qualsiasi identità utente in un determinato giorno della settimana passata. Un utilizzo così insolitamente elevato potrebbe essere un indicatore di potenziali abusi dell'API, minacce di tipo insider o credenziali divulgate. Per determinare se è presente un outlier, questa query esegue un'analisi statistica sul conteggio giornaliero delle azioni per amministratore. Le medie e le deviazioni standard vengono calcolate per ogni giorno e per ogni utente principale esaminando i conteggi giornalieri precedenti con una finestra temporale di 60 giorni. Un valore outlier viene considerato quando il conteggio giornaliero di un utente è superiore a tre deviazioni standard al di sopra della media. La query, incluso il fattore di deviazione standard e le finestre temporali, sono tutte configurabili in base al profilo della tua attività di provisioning cloud e per ridurre al minimo i falsi positivi.

Analisi dei log

SELECT
  *
FROM (
  SELECT
    *,
    AVG(counter) OVER (
      PARTITION BY principal_email
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
    STDDEV(counter) OVER (
      PARTITION BY principal_email
      ORDER BY day
      ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
    COUNT(*) OVER (
      PARTITION BY principal_email
      RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
  FROM (
    SELECT
      proto_payload.audit_log.authentication_info.principal_email,
      EXTRACT(DATE FROM timestamp) AS day,
      ARRAY_AGG(DISTINCT proto_payload.audit_log.method_name IGNORE NULLS) AS actions,
      COUNT(*) AS counter
    FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
    WHERE
      timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
      AND proto_payload.audit_log.authentication_info.principal_email IS NOT NULL
      AND proto_payload.audit_log.method_name NOT LIKE "storage.%.get"
      AND proto_payload.audit_log.method_name NOT LIKE "v1.compute.%.list"
      AND proto_payload.audit_log.method_name NOT LIKE "beta.compute.%.list"
    GROUP BY
      proto_payload.audit_log.authentication_info.principal_email,
      day
  )
)
WHERE
  counter > avg + 3 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

BigQuery

SELECT
  *,
  AVG(counter) OVER (
    PARTITION BY principalEmail
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS avg,
  STDDEV(counter) OVER (
    PARTITION BY principalEmail
    ORDER BY day
    ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING) AS stddev,
  COUNT(*) OVER (
    PARTITION BY principalEmail
    RANGE BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS numSamples
FROM (
  SELECT
    protopayload_auditlog.authenticationInfo.principalEmail,
    EXTRACT(DATE FROM timestamp) AS day,
    ARRAY_AGG(DISTINCT protopayload_auditlog.methodName IGNORE NULLS) AS actions,
    COUNT(*) AS counter
  FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_*`
  WHERE
    timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
    AND protopayload_auditlog.authenticationInfo.principalEmail IS NOT NULL
    AND protopayload_auditlog.methodName NOT LIKE "storage.%.get"
    AND protopayload_auditlog.methodName NOT LIKE "v1.compute.%.list"
    AND protopayload_auditlog.methodName NOT LIKE "beta.compute.%.list"
  GROUP BY
    protopayload_auditlog.authenticationInfo.principalEmail,
    day
)
WHERE TRUE
QUALIFY
  counter > avg + 3 * stddev
  AND day >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) 
ORDER BY
  counter DESC

Qual è l'utilizzo della scalabilità automatica al giorno nell'ultimo mese?

Analizzando gli audit log per le attività degli amministratori, la seguente query riporta l'utilizzo dell'autoscaling per giorno nell'ultimo mese. Questa query può essere utilizzata per identificare pattern o anomalie che richiedono ulteriori accertamenti in materia di sicurezza.

Analisi dei log

SELECT
  TIMESTAMP_TRUNC(timestamp, DAY) AS day,
  proto_payload.audit_log.method_name,
  COUNT(*) AS counter
FROM
   `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  resource.type = "gce_instance_group_manager"
  AND log_id = "cloudaudit.googleapis.com/activity"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  1, 2

BigQuery

SELECT
  TIMESTAMP_TRUNC(timestamp, DAY) AS day,
  protopayload_auditlog.methodName AS methodName,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_activity`
WHERE
  resource.type = "gce_instance_group_manager"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  1, 2

Domande sull'accesso ai dati

Queste query di esempio eseguono un'analisi per capire chi accede o modifica i dati in Google Cloud.

Quali utenti hanno eseguito l'accesso ai dati più di frequente nell'ultima settimana?

La seguente query utilizza i log di controllo dell'accesso ai dati per trovare le identità degli utenti che hanno eseguito più di frequente l'accesso ai dati delle tabelle BigQuery nell'ultima settimana.

Analisi dei log

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  COUNT(*) AS COUNTER
FROM 
   `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  (proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.Query")
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND log_id = "cloudaudit.googleapis.com/data_access"
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

BigQuery

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS COUNTER
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  (protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.Query")
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

Quali utenti hanno avuto accesso ai dati della tabella "accounts" il mese scorso?

La seguente query utilizza gli audit log di accesso ai dati per trovare le identità degli utenti che hanno eseguito query più di frequente su una determinata tabella accounts nell'ultimo mese. Oltre ai segnaposto MY_DATASET_ID e MY_PROJECT_ID per la destinazione di esportazione BigQuery, la query riportata di seguito utilizza i segnaposto DATASET_ID e PROJECT_ID. Devi sostituire i segnaposto DATASET_ID e PROJECT_ID per specificare la tabella di destinazione di cui viene analizzato l'accesso, come la tabella accounts in questo esempio.

Analisi dei log

SELECT
  proto_payload.audit_log.authentication_info.principal_email,
  COUNT(*) AS COUNTER
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`,
  UNNEST(proto_payload.audit_log.authorization_info) authorization_info
WHERE
  (proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   proto_payload.audit_log.method_name = "google.cloud.bigquery.v2.JobService.Query")
  AND authorization_info.permission = "bigquery.tables.getData"
  AND authorization_info.resource = "projects/[PROJECT_ID]/datasets/[DATASET_ID]/tables/accounts"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

BigQuery

SELECT
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNT(*) AS COUNTER
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`,
  UNNEST(protopayload_auditlog.authorizationInfo) authorizationInfo
WHERE
  (protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.InsertJob" OR
   protopayload_auditlog.methodName = "google.cloud.bigquery.v2.JobService.Query")
  AND authorizationInfo.permission = "bigquery.tables.getData"
  AND authorizationInfo.resource = "projects/[PROJECT_ID]/datasets/[DATASET_ID]/tables/accounts"
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1
ORDER BY
  2 desc, 1
LIMIT
  100

A quali tabelle viene eseguito più di frequente l'accesso e da chi?

La seguente query utilizza gli audit log dell'accesso ai dati per trovare le tabelle BigQuery con i dati letti e modificati più di frequente nell'ultimo mese. Mostra l'identità utente associata, oltre alla suddivisione del numero totale di volte in cui i dati sono stati letti rispetto a quelli modificati.

Analisi dei log

SELECT
  proto_payload.audit_log.resource_name,
  proto_payload.audit_log.authentication_info.principal_email,
  COUNTIF(JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataRead") IS NOT NULL) AS dataReadEvents,
  COUNTIF(JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataChange") IS NOT NULL) AS dataChangeEvents,
  COUNT(*) AS totalEvents
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  STARTS_WITH(resource.type, 'bigquery') IS TRUE
  AND (JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataRead") IS NOT NULL
    OR JSON_VALUE(proto_payload.audit_log.metadata, "$.tableDataChange") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  5 DESC, 1, 2
LIMIT 1000

BigQuery

SELECT
  protopayload_auditlog.resourceName,
  protopayload_auditlog.authenticationInfo.principalEmail,
  COUNTIF(JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataRead") IS NOT NULL) AS dataReadEvents,
  COUNTIF(JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataChange") IS NOT NULL) AS dataChangeEvents,
  COUNT(*) AS totalEvents
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  STARTS_WITH(resource.type, 'bigquery') IS TRUE
  AND (JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataRead") IS NOT NULL
    OR JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.tableDataChange") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  1, 2
ORDER BY
  5 DESC, 1, 2
LIMIT 1000

Quali sono le 10 query principali eseguite su BigQuery nell'ultima settimana?

La seguente query utilizza gli audit log di accesso ai dati per trovare le query più comuni dell'ultima settimana. Vengono elencati anche gli utenti corrispondenti e le tabelle a cui viene fatto riferimento.

Analisi dei log

SELECT
  COALESCE(
   JSON_VALUE(proto_payload.audit_log.metadata, "$.jobChange.job.jobConfig.queryConfig.query"),
   JSON_VALUE(proto_payload.audit_log.metadata, "$.jobInsertion.job.jobConfig.queryConfig.query")) as query,
  STRING_AGG(DISTINCT proto_payload.audit_log.authentication_info.principal_email, ',') as users,
  ANY_VALUE(COALESCE(
   JSON_EXTRACT_ARRAY(proto_payload.audit_log.metadata, "$.jobChange.job.jobStats.queryStats.referencedTables"),
   JSON_EXTRACT_ARRAY(proto_payload.audit_log.metadata, "$.jobInsertion.job.jobStats.queryStats.referencedTables"))) as tables,
  COUNT(*) AS counter
FROM 
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  (resource.type = 'bigquery_project' OR resource.type = 'bigquery_dataset')
  AND operation.last IS TRUE
  AND (JSON_VALUE(proto_payload.audit_log.metadata, "$.jobChange") IS NOT NULL
    OR JSON_VALUE(proto_payload.audit_log.metadata, "$.jobInsertion") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  query
ORDER BY
  counter DESC
LIMIT 10

BigQuery

SELECT
  COALESCE(
   JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobChange.job.jobConfig.queryConfig.query"),
   JSON_EXTRACT_SCALAR(protopayload_auditlog.metadataJson, "$.jobInsertion.job.jobConfig.queryConfig.query")) as query,
  STRING_AGG(DISTINCT protopayload_auditlog.authenticationInfo.principalEmail, ',') as users,
  ANY_VALUE(COALESCE(
   JSON_EXTRACT_ARRAY(protopayload_auditlog.metadataJson, "$.jobChange.job.jobStats.queryStats.referencedTables"),
   JSON_EXTRACT_ARRAY(protopayload_auditlog.metadataJson, "$.jobInsertion.job.jobStats.queryStats.referencedTables"))) as tables,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  (resource.type = 'bigquery_project' OR resource.type = 'bigquery_dataset')
  AND operation.last IS TRUE
  AND (JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.jobChange") IS NOT NULL
    OR JSON_EXTRACT(protopayload_auditlog.metadataJson, "$.jobInsertion") IS NOT NULL)
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY
  query
ORDER BY
  counter DESC
LIMIT 10

Quali sono le azioni più comuni registrate nel log di accesso ai dati nell'ultimo mese?

La seguente query utilizza tutti i log di Cloud Audit Logs per trovare le 100 azioni più frequenti registrate nell'ultimo mese.

Analisi dei log

SELECT
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  resource.type,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND log_id="cloudaudit.googleapis.com/data_access"
GROUP BY
  proto_payload.audit_log.method_name,
  proto_payload.audit_log.service_name,
  resource.type
ORDER BY
  counter DESC
LIMIT 100

BigQuery

SELECT
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  resource.type,
  COUNT(*) AS counter
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].cloudaudit_googleapis_com_data_access`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY
  protopayload_auditlog.methodName,
  protopayload_auditlog.serviceName,
  resource.type
ORDER BY
  counter DESC
LIMIT 100

Domande sulla sicurezza della rete

Queste query di esempio eseguono l'analisi dell'attività di rete in Google Cloud.

Esistono connessioni da un nuovo indirizzo IP a una subnet specifica?

La seguente query rileva le connessioni da qualsiasi nuovo indirizzo IP di origine a una determinata subnet analizzando i log di flusso VPC. In questo esempio, un indirizzo IP di origine viene considerato nuovo se è stato rilevato per la prima volta nelle ultime 24 ore in un periodo di 60 giorni. Ti consigliamo di utilizzare e ottimizzare questa query su una subnet inclusa nell'ambito di un determinato requisito di conformità, come PCI.

Analisi dei log

SELECT
  JSON_VALUE(json_payload.connection.src_ip) as src_ip,
  -- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  MIN(TIMESTAMP(REGEXP_REPLACE(JSON_VALUE(json_payload.start_time), r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance,
  MAX(TIMESTAMP(REGEXP_REPLACE(JSON_VALUE(json_payload.start_time), r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS lastInstance,
  ARRAY_AGG(DISTINCT JSON_VALUE(resource.labels.subnetwork_name)) as subnetNames,
  ARRAY_AGG(DISTINCT JSON_VALUE(json_payload.dest_instance.vm_name)) as vmNames,
  COUNT(*) numSamples
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND JSON_VALUE(json_payload.reporter) = 'DEST'
  AND JSON_VALUE(resource.labels.subnetwork_name) IN ('prod-customer-data')
GROUP BY
  src_ip
HAVING firstInstance >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
ORDER BY
  lastInstance DESC,
  numSamples DESC

BigQuery

SELECT
  jsonPayload.connection.src_ip as src_ip,
  -- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  MIN(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance,
  MAX(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS lastInstance,
  ARRAY_AGG(DISTINCT resource.labels.subnetwork_name) as subnetNames,
  ARRAY_AGG(DISTINCT jsonPayload.dest_instance.vm_name) as vmNames,
  COUNT(*) numSamples
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].compute_googleapis_com_vpc_flows`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND jsonPayload.reporter = 'DEST'
  AND resource.labels.subnetwork_name IN ('prod-customer-data')
GROUP BY
  src_ip
HAVING firstInstance >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY)
ORDER BY
  lastInstance DESC,
  numSamples DESC

Esistono connessioni bloccate da Google Cloud Armor?

La seguente query consente di rilevare potenziali tentativi di exploit analizzando i log di Application Load Balancer esterni per trovare eventuali connessioni bloccate dal criterio di sicurezza configurato in Google Cloud Armor. Questa query presuppone che tu abbia configurato un criterio di sicurezza di Google Cloud Armor sul bilanciatore del carico delle applicazioni esterno. Questa query presuppone inoltre che tu abbia attivato il logging del bilanciatore del carico delle applicazioni esterno come descritto nelle istruzioni fornite dal link Attiva nello strumento di definizione dell'ambito dei log.

Analisi dei log

SELECT
  timestamp,
  http_request.remote_ip,
  http_request.request_method,
  http_request.status,
  JSON_VALUE(json_payload.enforcedSecurityPolicy.name) AS security_policy_name,
  JSON_VALUE(resource.labels.backend_service_name) AS backend_service_name,
  http_request.request_url,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND JSON_VALUE(json_payload.statusDetails) = "denied_by_security_policy"
ORDER BY
  timestamp DESC

BigQuery

SELECT
  timestamp,
  httpRequest.remoteIp,
  httpRequest.requestMethod,
  httpRequest.status,
  jsonpayload_type_loadbalancerlogentry.enforcedsecuritypolicy.name,
  resource.labels.backend_service_name,
  httpRequest.requestUrl,
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].requests`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="http_load_balancer"
  AND jsonpayload_type_loadbalancerlogentry.statusdetails = "denied_by_security_policy"
ORDER BY
  timestamp DESC

Sono stati rilevati virus o malware di gravità elevata da Cloud IDS?

La seguente query mostra eventuali virus o malware con gravità elevata rilevati da Cloud IDS cercando nei log delle minacce di Cloud IDS. Questa query assume che tu abbia configurato un endpoint Cloud IDS.

Analisi dei log

SELECT
  JSON_VALUE(json_payload.alert_time) AS alert_time,
  JSON_VALUE(json_payload.name) AS name,
  JSON_VALUE(json_payload.details) AS details,
  JSON_VALUE(json_payload.application) AS application,
  JSON_VALUE(json_payload.uri_or_filename) AS uri_or_filename,
  JSON_VALUE(json_payload.ip_protocol) AS ip_protocol,
FROM `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="ids.googleapis.com/Endpoint"
  AND JSON_VALUE(json_payload.alert_severity) IN ("HIGH", "CRITICAL")
  AND JSON_VALUE(json_payload.type) = "virus"
ORDER BY 
  timestamp DESC

BigQuery

SELECT
  jsonPayload.alert_time,
  jsonPayload.name,
  jsonPayload.details,
  jsonPayload.application,
  jsonPayload.uri_or_filename,
  jsonPayload.ip_protocol
FROM `[MY_PROJECT_ID].[MY_DATASET_ID].ids_googleapis_com_threat`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
  AND resource.type="ids.googleapis.com/Endpoint"
  AND jsonPayload.alert_severity IN ("HIGH", "CRITICAL")
  AND jsonPayload.type = "virus"
ORDER BY 
  timestamp DESC

Quali sono i principali domini sottoposti a query da Cloud DNS dalla tua rete VPC?

La seguente query elenca i 10 domini principali sottoposti a query da Cloud DNS dalle tue reti VPC negli ultimi 60 giorni. Questa query presuppone che tu abbia abilitato il logging di Cloud DNS per le tue reti VPC come descritto nelle istruzioni fornite dal link Attiva nello strumento di definizione dell'ambito dei log.

Analisi dei log

SELECT
  JSON_VALUE(json_payload.queryName) AS query_name,
  COUNT(*) AS total_queries
FROM
  `[MY_PROJECT_ID].[MY_LOG_BUCKET_REGION].[MY_LOG_BUCKET_NAME]._AllLogs`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
  AND log_id="dns.googleapis.com/dns_queries"
GROUP BY
  query_name
ORDER BY
  total_queries DESC
LIMIT
  10

BigQuery

SELECT
 jsonPayload.queryname AS query_name,
 COUNT(*) AS total_queries
FROM
 `[MY_PROJECT_ID].[MY_DATASET_ID].dns_googleapis_com_dns_queries`
WHERE
  timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 60 DAY)
GROUP BY
 query_name
ORDER BY
 total_queries DESC
LIMIT
 10

Passaggi successivi

• Scopri come eseguire lo streaming dei log da Google Cloud a Splunk.

• Importazione dei log di Google Cloud in Google Security Operations.

• Esportazione dei dati sulla sicurezza di Google Cloud nel sistema SIEM.

• Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.