Analisi dei log di sicurezza in Google Cloud

Last reviewed 2024-05-21 UTC

Questa guida mostra ai professionisti della sicurezza come eseguire l'onboarding di Google Cloud log da usare nell'analisi della sicurezza. Eseguendo analisi di sicurezza, aiutano la tua azienda a prevenire, rilevare e rispondere a minacce come malware, phishing, ransomware e asset non configurati correttamente.

Questa guida illustra come:

• Abilita i log da analizzare.
• Esegui il routing dei log verso un'unica destinazione a seconda della tua scelta di analisi della sicurezza, come Analisi dei log BigQuery Google Security Operations oppure una tecnologia SIEM (Security Information and Event Management) di terze parti.
• Analizza questi log per verificare l'utilizzo del cloud e rilevare il potenziale ai dati e ai carichi di lavoro, utilizzando query di esempio Analisi della sicurezza della community (CSA, Community Security Analytics) progetto.

Le informazioni in questa guida fanno parte delle Operazioni di sicurezza autonomiche di Google Cloud, che include la trasformazione di rilevamento e risposta guidata dall'ingegneria pratiche e analisi della sicurezza per migliorare le capacità di rilevamento delle minacce.

In questa guida, i log forniscono l'origine dati da analizzare. Tuttavia, puoi applica i concetti di questa guida all'analisi di altri relativi alla sicurezza di Google Cloud, ad esempio i risultati relativi alla sicurezza da Security Command Center. In Security Command Center Premium è disponibile un elenco di istanze gestite rilevatori progettati per identificare minacce, vulnerabilità e gli errori di configurazione nei tuoi sistemi quasi in tempo reale. Tramite l'analisi di questi da Security Command Center e mettendoli in relazione con i log importati strumento di analisi della sicurezza, come descritto in questa guida, le potenziali minacce alla sicurezza.

Il seguente diagramma mostra come le origini dati, gli strumenti di analisi della sicurezza e le query di annunci associati alla ricerca personalizzata.

Il diagramma inizia con le seguenti origini dati di sicurezza: log da Cloud Logging, modifiche agli asset da Cloud Asset Inventory e risultati sulla sicurezza da Security Command Center. Il diagramma quindi mostra che queste origini dati di sicurezza instradato allo strumento di analisi della sicurezza di tua scelta: Analisi dei log in Cloud Logging, BigQuery, Google Security Operations o una piattaforma SIEM di terze parti. Infine, Diagramma mostra l'utilizzo di query di annunci associati alla ricerca personalizzata con lo strumento di analisi per analizzare le query dati sulla sicurezza.

Flusso di lavoro di analisi dei log di sicurezza

Questa sezione descrive i passaggi per configurare l'analisi del log di sicurezza in in Google Cloud. Il flusso di lavoro è costituito dai tre passaggi mostrati nello diagramma seguente e descritto nei seguenti paragrafi:

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

  Per aiutarti a valutare i log in termini di visibilità e rilevamento delle minacce copertura fornita, questa guida include uno strumento di definizione dell'ambito dei log. Questo strumento mappa ogni log tattiche e tecniche di minacce nel MITRE ATT&CK® Matrix for Enterprise. Lo strumento mappa anche Rilevamento delle minacce di eventi 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.

• Log di routing: dopo aver identificato e abilitato i log analizzati, il passaggio successivo consiste nell'instradare e aggregare i log dal tuo organizzazione, inclusi eventuali cartelle, progetti e account di fatturazione contenuti. La modalità di routing dei log dipende dallo strumento di analisi utilizzato.

  Questa guida descrive le destinazioni di routing dei log più comuni e mostra come utilizzare un sink aggregato di Cloud Logging per instradare i log a livello di organizzazione in un bucket di log di Cloud Logging o in un set di dati BigQuery, a seconda se scegli di usare Analisi dei log o BigQuery per l'analisi.

• Analizza i log:dopo aver eseguito il routing dei log a uno strumento di analisi, viene è eseguire un'analisi di questi log per identificare e potenziali minacce alla sicurezza. Il modo in cui analizzi i log dipende di analisi che usi. Se usi Analisi dei log o BigQuery, puoi analizzare i log usando query SQL. Se usi Google Security Operations, devi analizzare i log utilizzando le regole YARA-L. Se utilizzi uno strumento SIEM di terze parti, utilizzerai il linguaggio di query specificate dallo strumento.

  In questa guida troverai le query SQL che puoi utilizzare per analizzare in Analisi dei log o BigQuery. Le query SQL In questa guida provengono dal sito web Community Security Analytics (CSA) progetto. CSA è un set open source di analisi di sicurezza di base progettata per fornirti una 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 presentare domanda in ogni passaggio del flusso di lavoro di analisi dei log di sicurezza.

Attiva log

Il processo di abilitazione dei log prevede i seguenti passaggi:

1. Identifica i log necessari utilizzando lo strumento di definizione dell'ambito dei log di questa guida.
2. Registrare il filtro di log generato dallo strumento di definizione dell'ambito dei log per utilizzarlo in un secondo momento. durante la configurazione del sink di log.
3. Abilita il logging per ogni tipo di log o servizio Google Cloud identificato. A seconda del servizio, potrebbe essere necessario abilitare anche Audit log degli accessi ai dati, come descritto più avanti in questa sezione.

Identifica 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 tabella interattiva che elenca log importanti per la sicurezza Google Cloud, inclusi Cloud Audit Logs, log di Access Transparency, log di rete, e diversi log della piattaforma. Questo strumento mappa ogni tipo di log alle seguenti aree:

• ATTACCA ATTACCO tattiche e tecniche di minaccia che possono essere monitorate con quel registro.
• Piattaforma di computing Google Cloud CIS violazioni della conformità rilevate nel log.
• Rilevamento delle minacce di eventi regole basate sul log.

Lo strumento di definizione dell'ambito dei log genera anche un filtro di log che viene visualizzato subito dopo nella tabella. Quando identifichi i log necessari, selezionali lo strumento per aggiornare automaticamente il filtro di 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 Avanti al nome del log.
• Per selezionare o rimuovere tutti i log, fai clic sul pulsante di attivazione/disattivazione accanto a Log del tipo.
• Per vedere quali tecniche MITRE ATT&CK possono essere monitorate da ogni log tipo, 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 di log generato automaticamente dallo strumento di definizione dell'ambito dei log contiene a tutti i log che hai selezionato nello strumento. Puoi utilizzare il filtro così com'è oppure perfezionare ulteriormente il filtro dei log a seconda dei requisiti. Per Ad esempio, puoi includere (o escludere) le risorse solo in una o più risorse in modo programmatico a gestire i progetti. Dopo aver impostato un filtro di log che soddisfa i requisiti di log, salvare il filtro per usarlo durante il routing dei log. Ad esempio, puoi salva il filtro in un editor di testo o in una variabile di ambiente come che segue:

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

3. In Cloud Shell, crea una variabile salva il filtro di log:

   export LOG_FILTER='LOG_FILTER'
   

   Sostituisci LOG_FILTER con il codice del filtro di log.

Abilita i log della piattaforma specifici per il servizio

Per ogni log della piattaforma selezionato nello strumento di definizione dell'ambito dei log, i log devono essere abilitati (in genere a livello di risorsa) base. Ad esempio, i log di Cloud DNS sono abilitati a livello di rete VPC. Allo stesso modo, i log di flusso VPC sono abilitati a livello di subnet per tutte le VM 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 abilitare il logging. Tuttavia, puoi utilizzare lo strumento di definizione dell'ambito dei log per aprire rapidamente le istruzioni pertinenti per di ciascun log della piattaforma.

Per scoprire come abilitare il logging per un log della piattaforma specifico, segui questi passaggi:

1. Nello strumento di definizione dell'ambito dei log, individua il log della piattaforma che vuoi abilitare.
2. Nella colonna Abilitata per impostazione predefinita, fai clic sul link Abilita che corrisponde a quel log. Il link rimanda a istruzioni dettagliate su come abilitare il logging 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 Cloud Audit Logs fornisce un'ampia copertura di rilevamento delle minacce. Tuttavia, può essere molto grande. L'abilitazione di questi audit log di accesso ai dati potrebbe quindi comportano costi aggiuntivi per l'importazione, l'archiviazione, l'esportazione nell'elaborazione di questi log. In questa sezione viene spiegato come abilitare questi log e presenta alcune best practice per aiutarti a trovare un compromesso tra valore e costi aggiuntivi.

Nota: i log di controllo di accesso ai dati potrebbero contenere informazioni che consentono l'identificazione personale (PII) come identità del chiamante e indirizzi IP. Devi applicare le misure del caso le impostazioni di controllo dell'accesso e conservazione disponibili nello strumento di analisi per proteggere i dati di log, conservarli solo per il tempo necessario e poi eliminarli i tuoi dati in tutta sicurezza.

Gli audit log per l'accesso ai dati, tranne quelli di BigQuery, sono disabilitati per impostazione predefinita. A configurare gli audit log di accesso ai dati per servizi Google Cloud diversi da BigQuery, devi abilitarli esplicitamente utilizzando la console Google Cloud oppure utilizzando Google Cloud CLI per modificare Oggetti dei criteri IAM (Identity and Access Management). Quando si abilita l'accesso ai dati gli audit log, 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 la configurazione informazioni.
• 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 di ADMIN_WRITE, che sono operazioni che scrivono metadati o informazioni di configurazione. ADMIN_WRITE le operazioni sono incluse negli audit log delle attività di amministrazione di Cloud Audit Logs e pertanto non può essere disattivato.

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

Gestire il volume degli audit log di accesso ai dati

Quando abiliti gli audit log di accesso ai dati, l'obiettivo è massimizzare il loro valore della sicurezza, limitandone al contempo i costi e la gestione overhead. Per raggiungere questo obiettivo, ti consigliamo di eseguire le seguenti operazioni: per filtrare i log di scarso valore e con volumi elevati:

• Dai la priorità ai servizi pertinenti, ad esempio i servizi che ospitano dati sensibili carichi di lavoro, chiavi e dati. Per esempi specifici di servizi che potresti se vuoi dare la priorità ad altri, consulta Esempio di configurazione degli audit log di accesso ai dati.

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

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

• Dai la priorità a un sottoinsieme di operazioni di accesso ai dati, ad esempio ADMIN_READ, DATA_READ o DATA_WRITE per un numero minimo di operazioni registrate. Per Ad esempio, alcuni servizi come Cloud DNS scrivono tutti e tre i tipi di operazioni, ma puoi abilitare il logging solo per le operazioni di ADMIN_READ. Dopo aver ottenuto configurato uno di questi tre tipi di operazioni di accesso ai dati, potresti voler escludere operazioni specifiche che generano un volume particolarmente elevato. Puoi escludere queste operazioni ad alto volume modificando il log del sink filtro. Ad esempio, decidi di abilitare l'audit logging di accesso ai dati completo, incluse le operazioni DATA_READ su alcuni servizi di archiviazione critici. Per escludere operazioni di lettura di dati a traffico elevato in questa situazione, puoi aggiungere seguenti espressioni di filtro log consigliate per il filtro di log del sink:

  Servizio	Espressione di filtro di log
  Escludi i log di volumi elevati da Cloud Storage	NOT (resource.type="gcs_bucket" AND (protoPayload.methodName="storage.buckets.get" OR protoPayload.methodName="storage.buckets.list"))
  Escludi i log di volumi elevati 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 dati sensibili. Puoi classificare le risorse in base valore dei dati elaborati e dei rischi per la sicurezza, ad esempio se sono accessibili o meno dall'esterno. Anche se gli audit log di accesso ai dati abilitati per servizio, puoi filtrare risorse o tipi di risorse specifici attraverso il filtro di log.

• Escludi entità specifiche dalla registrazione degli accessi ai dati. Ad esempio, puoi escludere i tuoi account di test interni operazioni registrate. Per saperne di più, consulta Impostare le esenzioni in Accesso ai dati documentazione degli audit log.

Nota: oltre a utilizzare il filtro di log del sink per filtrare gli altri come descritto in questa sezione, ti consigliamo di escluderli importati in Cloud Logging per motivi di costo. Per evitare che questi log l'importazione, puoi applicare le espressioni di filtro dei log elencate in come filtri di esclusione sul sink _Default predefinito che instrada i log (incluso l'accesso ai dati) di audit log) al bucket di log _Default. I filtri di esclusione hanno l'effetto opposto di un filtro di log, che è un filtro. Di conseguenza, quando configuri queste espressioni come filtri di esclusione, devi per rimuovere l'operatore booleano NOT precedente dalle espressioni di filtro che vengono mostrati in questa sezione.

Esempio di configurazione degli audit log di accesso ai dati

La tabella seguente fornisce una configurazione di base degli audit log di accesso ai dati che puoi utilizzare per i progetti Google Cloud per limitare i volumi dei log mentre per avere una preziosa visibilità sulla sicurezza:

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

¹ Abilitazione degli audit log di accesso ai dati per IAP Cloud Storage può generare grandi volumi di log in caso di traffico elevato. alle risorse web protette da IAP o a Cloud Storage di oggetti strutturati.

² L'abilitazione degli audit log di accesso ai dati per Cloud Storage potrebbe interrompere l'uso dei download da browser autenticati per contenuti di oggetti strutturati. Per ulteriori dettagli e soluzioni alternative suggerite a questo problema, consulta Risoluzione dei problemi di Cloud Storage .

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

• Autenticazione e di autorizzazione: per questo livello di servizi, consigliamo di controllare tutte le operazioni di accesso ai dati. Questo livello di controllo consente puoi monitorare l'accesso a chiavi, secret e IAM criteri. Il monitoraggio di questo accesso potrebbe aiutarti a rilevare le tattiche MITRE ATT&CK ad esempio Discovery, Accesso alle credenziali e Escalation dei privilegi.
• Servizi di archiviazione: per questo livello di servizi, consigliamo di controllare i dati le operazioni di accesso che coinvolgono i dati forniti dall'utente. Questo livello di controllo ti aiuta a monitorare l'accesso ai tuoi dati importanti e sensibili. Monitoraggio di potrebbe aiutarti a rilevare tattiche MITRE ATT&CK come Raccolta ed Esfiltrazione sui tuoi dati.
• Servizi di infrastruttura: per questo livello di servizi, consigliamo di controllare i dati operazioni di accesso che coinvolgono metadati o informazioni di configurazione. Questo di controllo consente di monitorare la scansione dell'infrastruttura configurazione. Il monitoraggio di questo accesso potrebbe aiutarti a rilevare MITRE ATT&CK come Discovery per i tuoi carichi di lavoro.

Log di route

Dopo aver identificato e abilitato i log, il passaggio successivo consiste nell'instradarli a una singola destinazione. La destinazione, il percorso e la complessità del routing variano a seconda sugli strumenti di analisi che utilizzi, come illustrato nel seguente diagramma.

Il diagramma mostra le seguenti opzioni di routing:

• Se utilizzi Analisi dei log, ti serve un sink aggregato per aggregare i log della tua organizzazione Google Cloud in un unico bucket Cloud Logging.

• Se utilizzi BigQuery, hai bisogno di un sink aggregato per aggregare i log della tua organizzazione Google Cloud in un unico set di dati BigQuery.

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

• Se utilizzi BigQuery o una piattaforma SIEM di terze parti o vuoi esportare un di log ampliato in Google Security Operations, il diagramma mostra che è necessario un passaggio aggiuntivo tra l'abilitazione dei log e l'analisi. Questo il passaggio aggiuntivo consiste nella configurazione di un sink aggregato che instrada i log selezionati in modo appropriato. Se utilizzi BigQuery, questo sink è tutto quello di cui hai bisogno per instradare i log a BigQuery. Se utilizzi un SIEM di terze parti, devi fare in modo che il sink aggrega i log selezionati in Pub/Sub o Cloud Storage prima di poter eseguire il pull dei log il tuo strumento di analisi.

Nota: se utilizzi Analisi dei log (o BigQuery) e hai già configurato un sink aggregato per archiviare i log in un bucket Logging centrale (o un set di dati BigQuery centrale), puoi saltare questa sezione della guida e aggiorna semplicemente il sink con il filtro di 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 routing verso Google Security Operations e una piattaforma SIEM di terze parti non sono trattate in questa guida. Tuttavia, le sezioni seguenti forniscono i passaggi dettagliati per eseguire il routing dei log ad Analisi dei log o BigQuery:

1. Configura un'unica 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 siano instradati alla destinazione.

Configura un'unica destinazione

Analisi dei log

Nota: puoi saltare questo passaggio se utilizzi un bucket Cloud Logging che già esiste nel progetto Google Cloud in cui vuoi aggregare i log. Tu puoi usare il bucket _Default, ma ti consigliamo di creare un'istanza per questo caso d'uso.

1. Apri la console Google Cloud nel progetto Google Cloud che vuoi e aggregare i log.

   Vai alla console Google Cloud

2. In un terminale Cloud Shell, esegui 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 archiviati i log aggregati.
   • BUCKET_NAME: il nome del nuovo Logging di sincronizzare la directory di una VM con un bucket.

   • BUCKET_LOCATION: la posizione geografica del nel nuovo bucket Logging. Le località supportate sono global, us o eu. Per saperne di più su queste regioni di archiviazione, consulta Regioni supportate. Se non specifichi una località, viene utilizzata la regione global, che significa che i log possono 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. La nell'esempio seguente estende la conservazione dei log archiviati nel bucket 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 questi passaggi.

BigQuery

1. Apri la console Google Cloud nel progetto Google Cloud che vuoi e aggregare i log.

   Vai alla console Google Cloud

2. In un terminale Cloud Shell, esegui 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 in cui verranno archiviati i log aggregati.
   • DATASET_ID: l'ID del nuovo BigQuery del set di dati.

   • DATASET_LOCATION: la posizione geografica del set di dati. Dopo aver creato un set di dati, la località non può essere modificata.

     Nota: se scegli UE o una regione UE per la località del set di dati, il tuo I Dati dei clienti BigQuery si trovano nell'UE. Nucleo I dati dei clienti BigQuery sono definiti Servizio Termini specifici.

   • PARTITION_EXPIRATION: la durata predefinita (in secondi) per le partizioni nelle tabelle partizionate create dal sink di log. Configurerai il sink di log nella sezione successiva. Il sink di log La configurazione utilizza tabelle partizionate partizionate per giorno in base il timestamp della voce di log. Partizioni (incluse le voci di log associate) vengono eliminati PARTITION_EXPIRATION secondi dopo della partizione.

     Best practice: imposta la proprietà scadenza predefinita della partizione di il set di dati in base ai requisiti di conservazione dei log, in modo che i log meno recenti scadono e scadere. 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 il dimensione totale dell'archiviazione dei log e 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 il parametro il sink di log ha avviato il routing dei log e ha creato i relativi partizionate. Ad esempio, potresti dover mantenere 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 sì non imposti una scadenza predefinita per le partizioni a livello di set di dati e non ne imposti una quando viene creata la tabella. Le partizioni non scadono mai

Crea un sink di log aggregato

Instrada i log dell'organizzazione alla destinazione creando un insieme aggregato a livello di organizzazione. Per includere tutti i log selezionati nello strumento di definizione dell'ambito dei log, devi configurare il sink con il filtro di log generato dallo strumento di definizione dell'ambito dei log.

Nota: l'indirizzamento dei log a questa nuova destinazione non significa che i tuoi log vengono reindirizzati al sito. I log sono invece archiviati due volte: una volta nel dal progetto Google Cloud padre e poi di nuovo nella nuova destinazione. Da evitare spazio di archiviazione duplicato dei tuoi log, aggiungi un filtro di esclusione nel sink _Default di ogni progetto Google Cloud figlio nella tua organizzazione. Per impedire l'importazione dei log nei sink _Default del futuro Progetti Google Cloud nella tua organizzazione, disattiva il sink _Default nelle impostazioni predefinite della tua organizzazione.

Analisi dei log

1. In un terminale Cloud Shell, esegui questo comando gcloud per creare un sink aggregato nell'organizzazione livello:

   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 del sink che instrada i log.
   • PROJECT_ID: l'ID del progetto Google Cloud in cui verranno archiviati i log aggregati.
   • BUCKET_LOCATION: la posizione del logging del bucket che hai creato per l'archiviazione dei log.
   • BUCKET_NAME: il nome del logging del bucket che hai creato per l'archiviazione dei log.
   • LOG_FILTER: il filtro log che hai salvato dalla di valutazione dell'ambito dei log.
   • ORGANIZATION_ID: l'ID risorsa della tua organizzazione.

   Il flag --include-children è importante affinché i log di tutti Sono inclusi anche i progetti Google Cloud all'interno della tua organizzazione. Per maggiori informazioni le informazioni, vedi Facolta e instrada 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 al sink 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 iniziando con serviceAccount:. Questo identificatore è l'account di servizio del sink. Finché non concedi l'autorizzazione accesso in scrittura dell'account di servizio al bucket di log, routing dei log da questo sink non riuscirà. Concedi l'accesso in scrittura all'identità writer del sink nella sezione successiva.

BigQuery

1. In un terminale Cloud Shell, esegui seguente comando gcloud per creare un sink aggregato 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 del sink che instrada i log.
   • PROJECT_ID: l'ID del progetto Google Cloud che in cui aggregare i log.
   • DATASET_ID: l'ID del set di dati BigQuery che hai creato.
   • LOG_FILTER: il filtro log che hai salvato dalla di valutazione dell'ambito dei log.
   • ORGANIZATION_ID: l'ID risorsa della tua organizzazione.

   Il flag --include-children è importante affinché i log di tutti Sono inclusi anche i progetti Google Cloud all'interno della tua organizzazione. Per maggiori informazioni le informazioni, vedi Facolta e instrada i log a livello di organizzazione verso le destinazioni supportate.

   Il flag --use-partitioned-tables è importante per eseguire il partizionamento dei dati al giorno, in base al campo timestamp della voce di log. Ciò semplifica l'esecuzione di query dei dati e aiuta a ridurre i costi delle query diminuendo la quantità di dati analizzati dalle query. Un altro vantaggio delle tabelle partizionate è che imposta una scadenza predefinita per la partizione a livello del set di dati in modo da rispettare i log requisiti di conservazione. Hai già impostato una scadenza predefinita per la partizione quando hai creato la destinazione del set di dati nella sezione precedente. Potresti scegli anche di impostare la scadenza della partizione a livello di singola tabella, consentendoti una conservazione dei dati granulare i controlli 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 al sink 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 iniziando con serviceAccount:. Questo identificatore è l'account di servizio del sink. Finché non concedi l'autorizzazione l'accesso in scrittura dell'account di servizio al set di dati BigQuery il routing dei log da questo sink non riuscirà. Concedi l'accesso in scrittura al sink sull'identità autore nella sezione successiva.

Concedi l'accesso al sink

Dopo aver creato il sink di log, devi concedere al sink l'accesso in scrittura al relativo sink sia il bucket Logging che BigQuery del set di dati.

Nota: per eseguire il routing dei log a una risorsa protetta da un perimetro di servizio, devi anche aggiungere l'account di servizio per quel sink a un livello di accesso, quindi e assegnarlo al perimetro di servizio di destinazione. Questa operazione non è necessaria per e i sink non aggregati. Per maggiori dettagli, vedi Controlli di servizio VPC: Cloud Logging.

Analisi dei log

Per aggiungere le autorizzazioni all'account di servizio del sink, segui questi passaggi:

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 Logging che hai creato per l'archiviazione centrale dei log.

3. Fai clic su Concedi l'accesso.

4. Nel campo Nuove entità, inserisci l'account di servizio del sink senza il prefisso serviceAccount:. Ricorda che questa identità proviene il campo writerIdentity recuperato nella sezione precedente dopo ha creato il sink.

5. Nel menu a discesa Seleziona un ruolo, scegli Writer bucket di log.

6. Fai clic su Aggiungi condizione IAM per limitare le account di servizio solo al bucket di 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 località 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 del sink, segui questi passaggi:

1. Nella console Google Cloud, vai a BigQuery:

   Vai a BigQuery

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

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

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

5. Nel campo Nuove entità, inserisci l'account di servizio del sink senza il prefisso serviceAccount:. Ricorda che questa identità proviene il campo writerIdentity recuperato nella sezione precedente dopo ha creato il sink.

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

7. Fai clic su Salva.

Dopo aver concesso l'accesso al sink, le voci di log iniziano a completare il sink di destinazione: il bucket 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 puoi cercare in tutti questi log. Utilizza IAM le autorizzazioni necessarie per gestire le autorizzazioni e concedere l'accesso, se necessario.

Analisi dei log

Per concedere l'accesso per visualizzare ed eseguire query sui log nel nuovo bucket di log, segui questi passaggi.

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

   Vai alla pagina IAM

   Assicurati di aver selezionato il progetto Google Cloud che stai utilizzando 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 viste log.

   Questo ruolo fornisce all'entità appena aggiunta l'accesso in lettura a tutte le viste per qualsiasi bucket nel 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 località e il nome del bucket, e la visualizzazione di log predefinita _AllLogs, come segue:

      locations/BUCKET_LOCATION/buckets/BUCKET_NAME/views/_AllLogs
      

      Nota: Cloud Logging crea automaticamente la vista _AllLogs per in ogni bucket, con la visualizzazione di tutti i log nel bucket. Per dati più granulari su quali log è possibile visualizzare ed eseguire query all'interno del bucket di log, puoi creare e utilizzare una visualizzazione personalizzata del log 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 per visualizzare ed eseguire query sui log nel tuo set di dati BigQuery, segui i passaggi nella sezione Concedere l'accesso a un set di dati del documentazione di BigQuery.

Verifica che i log siano instradati alla destinazione

Analisi dei log

Quando esegui il routing dei log a un bucket di log di cui è stato eseguito l'upgrade ad Analisi dei log, puoi visualizza ed esegui query su tutte le voci di log tramite un'unica visualizzazione di log con uno schema unificato per tutti i tipi di log. Segui questi passaggi per verificare che i log siano instradati correttamente.

1. Nella console Google Cloud, vai alla pagina Analisi dei log:

   Vai ad Analisi dei log

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

2. Fai clic sulla scheda Visualizzazioni log.

3. Espandi le visualizzazioni dei log sotto il bucket di log che hai creato, BUCKET_NAME) se non è espansa .

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

   

5. Accanto a _AllLogs, fai clic su Query . Compila l'editor di query con una query SQL di esempio per recuperare le voci di log con routing recenti.

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

A seconda del livello di attività nei progetti Google Cloud della tua organizzazione, potresti dover attendere qualche minuto prima che vengano generati dei log, quindi instradato al bucket di log.

BigQuery

Quando esegui il routing dei log su un set di dati BigQuery, Cloud Logging crea tabelle BigQuery per contenere le voci di log come mostrato nello screenshot seguente:

Lo screenshot mostra come Cloud Logging assegna un nome a ogni BigQuery basata sul nome del log a cui appartiene una voce di log. Ad esempio: la tabella cloudaudit_googleapis_com_data_access selezionata nell'area screenshot contiene gli audit log di accesso ai dati il cui ID log è cloudaudit.googleapis.com%2Fdata_access. Oltre che sul nome basato su la voce di log corrispondente, ogni tabella è partizionata anche in base per ogni voce di log.

A seconda del livello di attività nei progetti Google Cloud della tua organizzazione, potresti dover attendere qualche minuto prima che vengano generati dei log, quindi instradato al set di dati BigQuery.

Nota: i log relativi all'attività di amministrazione e all'accesso ai dati vengono caricati in BigQuery con il campo della voce di log protoPayload rinominato in protoPayload_auditlog in BigQuery. Per ulteriori informazioni sulle conversioni dello schema eseguite da Cloud Logging prima di scrivere in BigQuery, consulta Campi negli audit log esportati.

Analisi dei log

Puoi eseguire una vasta gamma di query sui log di controllo e della piattaforma. La l'elenco seguente fornisce una serie di domande di sicurezza di esempio a cui potresti chiedere informazioni sui tuoi log. Per ogni domanda dell'elenco, esistono due versioni di la query CSA corrispondente: una per l'uso con Analisi dei log e l'altra per l'uso con BigQuery. Utilizza la versione della query corrispondente alla destinazione del sink configurato in precedenza.

Analisi dei log

Prima di utilizzare una delle query SQL seguenti, sostituisci MY_PROJECT_ID con l'ID del progetto Google Cloud in cui hai creato il bucket di log (ossia 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 seguenti, sostituisci MY_PROJECT_ID con l'ID del progetto Google Cloud in cui hai creato il set di dati BigQuery (PROJECT_ID), mentre MY_DATASET_ID con il nome del set di dati, ovvero DATASET_ID.

Vai a BigQuery

1. Domande relative all'accesso e all'accesso
   .
   • Google Workspace ha segnalato qualche tentativo di accesso sospetto?
   • Sono presenti eccessivi errori di accesso da parte di qualsiasi identità utente?
   • Ci sono tentativi di accesso che violano i Controlli di servizio VPC?
   • Ci sono tentativi di accesso che violano i controlli dell'accesso di Identity-Aware Proxy?
2. Domande sulle modifiche alle autorizzazioni
   .
   • Sono presenti utenti aggiunti a gruppi con privilegi elevati?
   • Ci sono autorizzazioni concesse per un account di servizio?
   • Ci sono account di servizio o chiavi creati da identità non approvate?
   • Qualsiasi utente aggiunto (o rimosso da) al criterio IAM sensibile?
3. Domande sull'attività di provisioning
   .
   • Sono state apportate modifiche alle impostazioni di logging?
   • Eventuali log di flusso VPC disabilitati?
   • È stato modificato un numero insolito di regole firewall la scorsa settimana?
   • Sono state eliminate le VM nell'ultima settimana?
4. Domande sull'utilizzo del carico di lavoro
   .
   • Utilizzo insolitamente elevato dell'API da parte di qualsiasi identità utente nell'ultima settimana?
   • Qual è l'utilizzo della scalabilità automatica al giorno nell'ultimo mese?
5. Domande sull'accesso ai dati
   .
   • Quali utenti hanno avuto accesso più spesso ai dati nell'ultima settimana?
   • Gli utenti che hanno eseguito l'accesso ai dati negli "account" tabella lo scorso mese?
   • Quali tabelle vengono consultate più di frequente e da chi?
   • Quali sono le prime 10 query rispetto a BigQuery la scorsa settimana?
   • Quali sono le azioni più comuni registrate nel log di accesso ai dati lo scorso mese?
6. Domande sulla sicurezza di rete
   .
   • Sono presenti connessioni da un nuovo indirizzo IP a una subnet specifica?
   • Ci sono connessioni bloccate da Google Cloud Armor?
   • Sono presenti virus o malware ad alta gravità rilevati da Cloud IDS?
   • Quali sono i principali domini per le query Cloud DNS della tua rete VPC?

Domande relative ad accesso e accesso

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

Nota: l'attività di accesso viene acquisita nei log di Cloud Identity inclusi in Controllo degli accessi di Google Workspace. Per analizzare l'attività di accesso e utilizzare alcune delle query di questa sezione, è necessario per attivare la condivisione dei dati di Google Workspace con Google Cloud. Per scoprire di più su condividi i log di controllo di Google Workspace con Google Cloud, vedi Visualizzare e gestire i log di controllo per Google Workspace.

Google Workspace segnala un tentativo di accesso sospetto?

Eseguendo una ricerca nei log di Cloud Identity che fanno parte Controllo degli accessi a Google Workspace la seguente query rileva tentativi di accesso sospetti segnalati da Google Workspace. Questi tentativi di accesso possono provenire dalla console Google Cloud, dalla Console di amministrazione o 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"

Si sono verificati troppi errori di accesso da qualsiasi identità utente?

Eseguendo una ricerca nei log di Cloud Identity che fanno parte Controllo degli accessi a Google Workspace la seguente query rileva gli utenti che hanno effettuato almeno tre accessi successivi errori 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

Sono stati effettuati tentativi di accesso in violazione dei Controlli di servizio VPC?

Analizzando gli audit log dei criteri negati da Cloud Audit Logs, rileva i tentativi di accesso bloccati dai Controlli di servizio VPC. Qualsiasi risultato della query potrebbe indicare potenziali attività dannose, come i tentativi di accesso da parte di reti non autorizzate con 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

Tentativi di accesso che violano i controlli di accesso IAP?

Analizzando i log del bilanciatore del carico delle applicazioni esterno, la seguente query rileva tentativi di accesso bloccati da IAP. Qualsiasi risultato della query indicano un tentativo di accesso iniziale o un tentativo di exploit della 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

Questi esempi di query eseguono analisi sull'attività dell'amministratore che cambia autorizzazioni, incluse le modifiche a criteri, gruppi e gruppi IAM appartenenze, account di servizio ed eventuali chiavi associate. Queste modifiche alle autorizzazioni potrebbe fornire un alto livello di accesso a dati o ambienti sensibili.

Nota: le modifiche ai gruppi vengono acquisite nel controllo della Console di amministrazione di Google Workspace. Per analizzare l'attività delle modifiche al gruppo e utilizzare alcune delle query di questa sezione, è necessario per attivare la condivisione dei dati di Google Workspace con Google Cloud. Per scoprire di più su condividi i log di controllo di Google Workspace con Google Cloud, vedi Visualizzare e gestire i log di controllo per Google Workspace.

Sono stati aggiunti utenti a gruppi con privilegi elevati?

Analizzando il controllo degli amministratori di Google Workspace log di controllo, la seguente query rileva gli utenti che sono stati aggiunti a uno qualsiasi ai gruppi con privilegi elevati elencati nella query. Puoi utilizzare l'espressione regolare in la query per definire quali gruppi (ad es. [e-mail] o [e-mail]) da monitorare. I risultati delle query potrebbero indicare un privilegio dannoso o accidentale una riassegnazione.

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
  )

Qualche autorizzazione concessa su un account di servizio?

Analizzando gli audit log delle attività di amministrazione di Cloud Audit Logs, rileva le autorizzazioni concesse a qualsiasi entità su un l'account di servizio. Esempi di autorizzazioni che potrebbero essere concesse sono la possibilità per impersonare quell'account di servizio o per creare chiavi dell'account di servizio. Qualsiasi query i risultati potrebbero indicare un'istanza di escalation dei privilegi o il rischio la perdita di 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 chiavi o account di servizio creati da identità non approvate?

Analizzando gli audit log delle attività di amministrazione, la seguente query rileva la presenza di eventuali servizi account o chiavi creati manualmente da un utente. Ad esempio, potrebbe seguire una best practice per consentire solo la creazione di account di servizio approvato nell'ambito di un flusso di lavoro automatizzato. Pertanto, qualsiasi servizio la creazione di account 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"

Qualsiasi utente aggiunto (o rimosso da) al criterio IAM sensibile?

Cercando negli audit log delle attività di amministrazione, la seguente query rileva qualsiasi utente o modifica dell'accesso a un gruppo per una risorsa protetta da IAP, come di servizio di backend di Compute Engine. La seguente query cerca in tutte le istanze IAM aggiornamenti dei criteri per le risorse IAP che coinvolgono ruolo roles/iap.httpsResourceAccessor. Questo ruolo fornisce le autorizzazioni per accedere la risorsa HTTPS o il servizio di backend. I risultati delle query potrebbero indicare tenta di aggirare le difese di un servizio di backend che potrebbe essere esposto su 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 sull'attività di provisioning

Queste query di esempio eseguono l'analisi per rilevare amministratori sospetti o anomali per attività come il provisioning e la configurazione delle risorse.

Sono state apportate modifiche alle impostazioni di logging?

Eseguendo una ricerca negli audit log delle attività di amministrazione, la seguente query rileva qualsiasi modifica alle impostazioni di logging. Le impostazioni di Monitoring consentono di rilevare disattivazione accidentale o dannosa degli audit log e simili evasione della difesa tecniche.

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"

Eventuali log di flusso VPC sono disattivati attivamente?

Eseguendo una ricerca negli audit log delle attività di amministrazione, la seguente query rileva qualsiasi subnet i cui log di flusso VPC sono stati disattivati attivamente . Monitoraggio dei log di flusso VPC consentono 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 la scorsa settimana?

Cercando negli audit log delle attività di amministrazione, la seguente query rileva eventuali un numero elevato di modifiche alle regole firewall in un determinato giorno nell'ultima settimana. Per determinare se è presente un outlier, la query esegue un'analisi statistica numero giornaliero di modifiche alle regole firewall. Le medie e le deviazioni standard sono calcolate per ogni giorno osservando i conteggi giornalieri precedenti con una finestra temporale di 90 giorni. Un outlier viene considerato quando il conteggio giornaliero di più di due deviazioni standard sopra la media. La query, tra cui il fattore di deviazione standard e le finestre temporali possono essere configurati il tuo profilo di attività di provisioning del 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 le VM la scorsa settimana?

Se cerchi negli audit log delle attività di amministrazione, la seguente query elenca qualsiasi Istanze di Compute Engine eliminate la settimana scorsa. Questa query può aiutarti controllare le eliminazioni delle risorse e 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 del carico di lavoro

Questi esempi di query eseguono analisi per capire chi e cosa sta consumando i carichi di lavoro e le API cloud e ti aiutano a rilevare potenziali comportamenti dannosi internamente o esternamente.

Utilizzo insolitamente elevato dell'API da parte di qualsiasi identità utente nella scorsa settimana?

Analizzando tutti Cloud Audit Logs, la seguente query rileva un numero insolitamente elevato di API Utilizzo da parte di qualsiasi identità utente in un determinato giorno della settimana precedente. Talmente insolitamente alto l'utilizzo potrebbe essere un indicatore di potenziale abuso dell'API, minaccia interna o e credenziali. Per determinare se esiste un outlier, questa query esegue l'analisi statistica sul conteggio giornaliero delle azioni per entità. Medie e le deviazioni standard vengono calcolate per ogni giorno e per ogni entità osservando ai conteggi giornalieri precedenti con una finestra temporale di 60 giorni. Un outlier viene considerato quando il conteggio giornaliero di un utente è superiore a tre deviazioni standard superiore alla loro media. La query, inclusi il fattore di deviazione standard e finestre temporali, tutte configurabili per adattarsi alla tua attività di provisioning cloud profilo e minimizzare 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 delle attività di amministrazione, la seguente query genera l'utilizzo della scalabilità automatica in base al giorno nell'ultimo mese. Questa query può essere usata per identificare modelli o anomalie che richiedono ulteriori indagini sulla 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

Questi esempi di query eseguono analisi per capire chi accede o modifica dei dati in Google Cloud.

Quali utenti hanno avuto accesso ai dati con maggiore frequenza la scorsa settimana?

La seguente query utilizza gli audit log di accesso ai dati per trovare l'utente Identità da cui si accede più frequentemente ai dati delle tabelle BigQuery dell'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 negli "account" tabella lo scorso mese?

La seguente query utilizza gli audit log di accesso ai dati per trovare l'utente identità che hanno spesso eseguito query su una determinata tabella accounts nell'ultimo mese. Oltre a MY_DATASET_ID e MY_PROJECT_ID segnaposto per BigQuery destinazione di esportazione, la seguente query utilizza DATASET_ID e PROJECT_ID. Devi sostituire con il DATASET_ID e PROJECT_ID segnaposto per specificare la tabella di destinazione di cui viene analizzato l'accesso, come la tabella accounts.

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

Quali tabelle vengono consultate più di frequente e da chi?

La seguente query utilizza gli audit log di accesso ai dati per trovare Le tabelle BigQuery con i dati letti e modificati più spesso nel corso nell'ultimo mese. Mostra l'identità utente associata con l'analisi dettagliata 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 dieci query principali rispetto a BigQuery la scorsa settimana?

La seguente query utilizza gli audit log di accesso ai dati per trovare più frequenti nell'ultima settimana. Elenca anche gli utenti corrispondenti e alle tabelle di 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 frequenti registrate il mese scorso.

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 di rete

Questi esempi di query eseguono un'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 un una data subnet analizzando i log di flusso VPC. In questo esempio, un IP di origine l'indirizzo è considerato nuovo se è stato visto per la prima volta nelle ultime 24 ore in una finestra temporale di 60 giorni. Ti consigliamo di utilizzare e ottimizzare questa query una subnet che rientra nell'ambito di un particolare 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

Sono presenti connessioni bloccate da Google Cloud Armor?

La seguente query consente di rilevare potenziali tentativi di exploit analizzando log del bilanciatore del carico delle applicazioni esterno per individuare le connessioni bloccate dal di sicurezza configurato in Google Cloud Armor. Questa query presuppone che tu abbia Criterio di sicurezza di Google Cloud Armor configurato sul bilanciatore del carico delle applicazioni esterno. Questa query presuppone anche che tu abbia abilitato il bilanciatore del carico delle applicazioni esterno come descritto nelle istruzioni fornite dallo strumento Abilita 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 ad alta gravità da Cloud IDS?

La seguente query mostra qualsiasi virus o malware ad alta gravità rilevato Cloud IDS cercando nei log delle minacce di Cloud IDS. Questa query presuppone 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 Cloud DNS dalla tua rete VPC?

La seguente query elenca i primi 10 domini per cui è stata eseguita una query Cloud DNS dal tuo VPC reti negli ultimi 60 giorni. Questa query presuppone che tu abbia abilitato Cloud DNS il logging per le reti VPC come descritto nelle istruzioni forniti 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

• Guarda gli altri scenari di esportazione:

  • Scenario: esportazione per requisiti di conformità.
  • Scenario: esportazione in Splunk.

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

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

• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.