Analisi dei log di sicurezza in Google Cloud

Last reviewed 2023-02-06 UTC

Questa guida mostra ai professionisti della sicurezza come integrare i log di Google Cloud da utilizzare nell'analisi della sicurezza. Con l'analisi della sicurezza, aiuti la tua organizzazione a prevenire, rilevare e rispondere a minacce come malware, phishing, ransomware e asset configurati in modo errato.

Questa guida illustra come:

  • Abilita i log da analizzare.
  • Instrada i log a un'unica destinazione a seconda dello strumento di analisi della sicurezza che preferisci, ad esempio Analisi dei log, BigQuery, Chronicle 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 dati e ai carichi di lavoro utilizzando query di esempio del progetto Community Security Analytics (CSA).

Le informazioni contenute in questa guida fanno parte delle Operazioni di sicurezza autonomiche di Google Cloud, che includono la trasformazione delle pratiche di rilevamento e risposta e analisi della sicurezza basata sulla progettazione strutturata per migliorare le capacità 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, ad esempio i risultati sulla sicurezza di Security Command Center. Fornisce in Security Command Center Premium un elenco di rilevatori gestiti regolarmente aggiornati, progettati per identificare minacce, vulnerabilità e configurazioni errate all'interno dei tuoi sistemi quasi in tempo reale. Analizzando questi indicatori da 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 l'interazione tra le origini dati per la sicurezza, gli strumenti di analisi della sicurezza e le query CSA.

Strumenti e contenuti di analisi della sicurezza.

Il diagramma inizia con le seguenti origini dati di sicurezza: log di Cloud Logging, modifiche agli asset di Cloud Asset Inventory e risultati sulla sicurezza di Security Command Center. Il diagramma mostra quindi queste origini dati di sicurezza indirizzate allo strumento di analisi della sicurezza di tua scelta: Analisi dei log in Cloud Logging, BigQuery, Chronicle o un SIEM di terze parti. Infine, il diagramma mostra l'utilizzo di query CSA con il tuo strumento di analisi per analizzare i dati di sicurezza raccolti.

Flusso di lavoro per l'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 prevede i tre passaggi mostrati nel diagramma seguente e descritti nei paragrafi seguenti:

I tre passaggi per configurare l'analisi dei log di sicurezza: (1) abilita i log, (2) instradano i log e (3) analizzano i log.

  • Abilita 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 delle attività di amministrazione, sono abilitati per impostazione predefinita, mentre altri devono essere abilitati manualmente perché comportano costi di importazione aggiuntivi in Cloud Logging. Pertanto, il primo passaggio del flusso di lavoro è assegnare la priorità ai log di sicurezza più pertinenti per le tue esigenze di analisi della sicurezza e abilitare individualmente questi log specifici.

    Per aiutarti a valutare i log in termini di visibilità e copertura del rilevamento delle minacce che offrono, questa guida include uno strumento di definizione dell'ambito dei log. Questo strumento mappa ciascun log alle tattiche e alle tecniche di minaccia pertinenti in MITRE ATT&CK® Matrix for Enterprise. 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 in uso.

  • Log del percorso: dopo aver identificato e abilitato i log da analizzare, il passaggio successivo prevede il routing e l'aggregazione dei log della tua 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 comuni per il routing dei log 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 che tu scelga di utilizzare Analisi dei log o BigQuery per l'analisi.

  • Analisi dei log: dopo aver indirizzato 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. Il modo in cui analizzi i log dipende dallo strumento di analisi che usi. Se usi l'analisi dei log o BigQuery, puoi analizzare i log tramite query SQL. Se utilizzi Chronicle, analizzi i log utilizzando le regole YARA-L. Se impieghi uno strumento SIEM di terze parti, usa il linguaggio di query specificato dallo strumento.

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

Le seguenti sezioni forniscono informazioni dettagliate su come configurare e applicare 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. Registra 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 gli audit log di accesso ai dati corrispondenti, come descritto più avanti in questa sezione.

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

Per 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 relativi alla 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 nelle seguenti aree:

Lo strumento di definizione dell'ambito dei log genera anche un filtro di log che viene visualizzato subito dopo la tabella. Man mano che identifichi i log necessari, selezionali nello 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 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 ciascun 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 di log generato automaticamente dallo strumento di definizione dell'ambito dei log contiene tutti i log selezionati nello strumento. Puoi usare il filtro così com'è o perfezionarlo ulteriormente a seconda delle tue esigenze. Ad esempio, puoi includere (o escludere) risorse solo in uno o più progetti specifici. Una volta ottenuto un filtro di log che soddisfa i 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 nel seguente modo:

  1. Nella sezione "Filtro log generato automaticamente" che segue lo strumento, copia il codice del filtro di log.
  2. (Facoltativo) Modifica il codice copiato per perfezionare il filtro.
  3. In Cloud Shell, crea una variabile per salvare 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 i servizi

Per ciascuno dei log della piattaforma selezionati nello strumento di definizione dell'ambito dei log, devono essere abilitati (in genere a livello di risorsa) in base al 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 nella subnet, mentre 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 ogni log della piattaforma.

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

  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 Abilita corrispondente al log. Il link rimanda a istruzioni dettagliate su come abilitare il logging per il 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 forniscono un'ampia copertura per il rilevamento delle minacce. Tuttavia, il loro volume può essere piuttosto elevato. L'abilitazione di questi audit log di accesso ai dati potrebbe quindi comportare costi aggiuntivi relativi all'importazione, all'archiviazione, all'esportazione e all'elaborazione di questi log. Questa sezione spiega come abilitare questi log e presenta alcune best practice per aiutarti a trovare il compromesso tra valore e costo.

Gli audit log di accesso ai dati, ad eccezione di BigQuery, sono disattivati per impostazione predefinita. Per configurare gli audit log di accesso ai dati per servizi Google Cloud diversi da BigQuery, devi abilitarli esplicitamente utilizzando la console Google Cloud o utilizzando Google Cloud CLI per modificare gli oggetti dei criteri IAM (Identity and Access Management). Quando abiliti 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 dagli utenti.
  • DATA_WRITE: registra le operazioni che scrivono i dati forniti dagli utenti.

Tieni presente che non puoi configurare la registrazione delle operazioni ADMIN_WRITE, ovvero operazioni 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 disabilitate.

Gestire il volume degli audit log di accesso ai dati

Quando si abilitano gli audit log di accesso ai dati, l'obiettivo è massimizzarne il valore in termini di visibilità sulla sicurezza e limitare al contempo i costi e i costi generali di gestione. Per raggiungere questo obiettivo, ti consigliamo di applicare i seguenti passaggi per filtrare i log di basso valore e volumi elevati:

  • 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 voler dare la priorità rispetto ad altri, consulta Esempio di configurazione degli audit log di accesso ai dati.
  • Dai priorità ai progetti pertinenti, ad esempio quelli che ospitano carichi di lavoro di produzione, anziché a quelli che ospitano gli ambienti di sviluppo e gestione temporanea. Per filtrare tutti i log di un determinato progetto, aggiungi la seguente espressione al filtro di log per il sink. Sostituisci PROJECT_ID con l'ID del progetto da cui vuoi filtrare tutti i log:

    Progetto Espressione di filtro log
    Escludi tutti i log da 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 insieme minimo di operazioni registrate. Ad esempio, alcuni servizi come Cloud DNS scrivono tutti e tre i tipi di operazioni, ma puoi abilitare il logging solo per le operazioni ADMIN_READ. Dopo aver configurato uno o più di questi tre tipi di operazioni di accesso ai dati, ti consigliamo di escludere operazioni specifiche dai volumi particolarmente elevati. Puoi escludere queste operazioni con volumi elevati modificando il filtro di log del sink. Ad esempio, decidi di abilitare l'audit logging completo degli accessi ai dati, che include le operazioni DATA_READ su alcuni servizi di archiviazione critici. Per escludere operazioni specifiche di lettura dei dati a traffico elevato in questa situazione, puoi aggiungere le seguenti espressioni di filtro di log consigliate al filtro di log del sink:

    Servizio Espressione di filtro log
    Escludi log ad alto volume da Cloud Storage
    
    NOT (resource.type="gcs_bucket" AND
        (protoPayload.methodName="storage.buckets.get" OR
        protoPayload.methodName="storage.buckets.list")) 
    Escludi log di volumi elevati da Cloud SQL
    
    NOT (resource.type="cloudsql_database" AND
        protoPayload.request.cmd="select") 
  • Dai priorità alle risorse pertinenti, ad esempio quelle che ospitano i dati e i carichi di lavoro più sensibili. Puoi classificare le risorse in base al valore dei dati elaborati e al relativo rischio per la sicurezza, ad esempio in base al fatto che siano accessibili o meno all'esterno. Anche se gli audit log di accesso ai dati sono abilitati per servizio, puoi filtrare risorse o tipi di risorse specifici tramite il filtro di log.

  • Escludere entità specifiche dalla registrazione degli accessi ai dati. Ad esempio, puoi escludere la registrazione delle operazioni degli account di test interni. Per scoprire di più, consulta Impostare le esenzioni nella documentazione degli audit log di accesso ai dati.

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 di log, ottenendo al contempo una preziosa visibilità sulla sicurezza:

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
Rilevamento
Accesso alle credenziali
Escalation dei privilegi
Servizi di archiviazione BigQuery (attivato per impostazione predefinita)
Cloud Storage1, 2
DATA_READ
DATA_WRITE
Raccolta
Esfiltrazione
Servizi di infrastruttura Criterio dell'organizzazione
di Compute Engine
ADMIN_READ Scoperta

1 L'abilitazione degli audit log di accesso ai dati per IAP o Cloud Storage può generare volumi di log elevati in caso di traffico elevato verso risorse web protette da IAP o oggetti Cloud Storage.

2 L'abilitazione degli audit log di accesso ai dati per Cloud Storage potrebbe interrompere l'utilizzo dei download autenticati del browser per 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, nota 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 l'audit logging di Accesso ai dati:

  • Servizi di autenticazione e autorizzazione: per questo livello di servizi, consigliamo di controllare tutte le operazioni di accesso ai dati. Questo livello di controllo consente di monitorare l'accesso a chiavi, secret e criteri IAM sensibili. Il monitoraggio di questo accesso potrebbe aiutarti a rilevare le tattiche MITRE ATT&CK come Discovery, Accesso alle credenziali e Riassegnazione privilegi.
  • Servizi di archiviazione: per questo livello di servizi, consigliamo di controllare le operazioni di accesso ai dati che coinvolgono i dati forniti dall'utente. Questo livello di controllo ti consente di 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 sui tuoi dati.
  • Servizi di infrastruttura: per questo livello di servizi, consigliamo di verificare le operazioni di accesso ai dati che riguardano metadati o informazioni di configurazione. Questo livello di controllo consente di monitorare la scansione della configurazione dell'infrastruttura. Il monitoraggio di questo accesso potrebbe aiutarti a rilevare tattiche MITRE ATT&CK come Discovery sui carichi di lavoro.

Log di route

Dopo aver identificato e abilitato i log, il passaggio successivo consiste nell'instradare i log a una singola destinazione. La destinazione, il percorso e la complessità del routing variano a seconda degli strumenti di analisi utilizzati, come mostrato nel diagramma seguente.

Metodi per il routing dei log: a BigQuery e Analisi dei log tramite un sink di log, a una piattaforma SIEM di terze parti mediante un sink di log e Pub/Sub e a Chronicle mediante l'importazione diretta.

Il diagramma mostra le seguenti opzioni di routing:

  • Se utilizzi Analisi dei log, è necessario un sink aggregato per aggregare i log dell'organizzazione Google Cloud in un singolo bucket Cloud Logging.

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

  • Se utilizzi Chronicle e questo sottoinsieme di log predefinito soddisfa le tue esigenze di analisi della sicurezza, puoi aggregare automaticamente questi log nel tuo account Chronicle utilizzando l'importazione Chronicle integrata. Puoi inoltre visualizzare questo set predefinito di log nella colonna Esportabile direttamente in Chronicle nello strumento di definizione dell'ambito dei log. Per maggiori informazioni sull'esportazione di questi log predefiniti, consulta Importare i log di Google Cloud in Chronicle.

  • Se utilizzi BigQuery o un SIEM di terze parti o vuoi esportare un set espanso di log in Chronicle, il diagramma mostra che è necessario un passaggio aggiuntivo tra l'abilitazione dei log e l'analisi. Questo passaggio aggiuntivo consiste nella configurazione di un sink aggregato che indirizzi i log selezionati in modo appropriato. Se usi BigQuery, questo sink è tutto ciò che ti serve per instradare i log a BigQuery. Se usi un SIEM di terze parti, devi far sì che il sink aggrega i log selezionati in Pub/Sub o Cloud Storage prima che i log possano essere estratti nello strumento di analisi.

Le opzioni di routing per Chronicle e SIEM di terze parti non sono trattate in questa guida. Tuttavia, le seguenti sezioni forniscono i passaggi dettagliati per eseguire il routing dei log ad Analisi dei log o a BigQuery:

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

Configura una destinazione singola

Analisi dei log

  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 questo 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 bucket di Logging.
    • BUCKET_LOCATION: la posizione geografica del nuovo bucket Logging. Le località 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 di queste regioni.

  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. L'esempio seguente estende a 365 giorni la conservazione dei log archiviati nel bucket:

    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 in cui vuoi aggregare i log.

    Vai alla console Google Cloud

  2. In un terminale Cloud Shell, esegui questo 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 set di dati BigQuery.
    • DATASET_LOCATION: la posizione geografica del set di dati. Una volta creato un set di dati, la località non può essere modificata.

    • PARTITION_EXPIRATION: la durata predefinita (in secondi) per le partizioni nelle tabelle partizionate create dal sink di log. Configura il sink di log nella sezione successiva. Il sink di log che configuri 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.

Crea un sink di log aggregato

Puoi instradare 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, devi configurare il sink con il filtro di log generato dallo strumento di definizione dell'ambito dei log.

Analisi dei log

  1. In un terminale Cloud Shell, esegui il comando gcloud seguente per creare un sink aggregato 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 del sink che indirizza i log.
    • PROJECT_ID: l'ID del progetto Google Cloud in cui verranno archiviati i log aggregati.
    • BUCKET_LOCATION: la località del bucket Logging che hai creato per l'archiviazione dei log.
    • BUCKET_NAME: il nome del bucket Logging che hai creato per l'archiviazione dei log.
    • LOG_FILTER: il filtro di 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 maggiori informazioni, consulta Raccogliere e instradare i log a livello di organizzazione alle destinazioni supportate.

  2. Verifica che il sink sia stato creato:

    gcloud logging sinks list --organization=ORGANIZATION_ID
    
  3. Ottieni il nome dell'account di servizio associato al sink appena creato:

    gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
    

    L'output è simile al seguente:

    writerIdentity: serviceAccount:p1234567890-12345@logging-o1234567890.iam.gserviceaccount.com`
    
  4. Copia l'intera stringa per writerIdentity iniziando con serviceAccount:. Questo identificatore è l'account di servizio del sink. Finché non concedi 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. Concedi l'accesso in scrittura all'identità di autore del sink nella sezione successiva.

BigQuery

  1. In un terminale Cloud Shell, esegui questo 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 indirizza 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 di 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 maggiori informazioni, consulta Raccogliere e instradare i log a livello di organizzazione alle destinazioni supportate.

    Il flag --use-partitioned-tables è importante per partizionare i dati in base al giorno in base al campo timestamp della voce di log. Ciò semplifica l'esecuzione di query sui dati e aiuta a ridurre i costi delle query riducendo la quantità di dati scansionati dalle query. Un altro vantaggio delle tabelle partizionate è che puoi impostare una scadenza predefinita per la partizione 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, fornendo controlli granulari della 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. Ottieni il nome dell'account di servizio associato al sink appena creato:

    gcloud logging sinks describe SINK_NAME --organization=ORGANIZATION_ID
    

    L'output è simile al seguente:

    writerIdentity: serviceAccount:p1234567890-12345@logging-o1234567890.iam.gserviceaccount.com`
    
  4. Copia l'intera stringa per writerIdentity iniziando con serviceAccount:. Questo identificatore è l'account di servizio del sink. Finché non concedi 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. Concederai l'accesso in scrittura all'identità dell'autore del sink nella sezione successiva.

Concedi l'accesso al sink

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.

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 dal campo writerIdentity recuperato nella sezione precedente dopo la creazione del sink.

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

  6. Fai clic su Aggiungi condizione IAM per limitare l'accesso dell'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 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 del sink senza il prefisso serviceAccount:. Ricorda che questa identità proviene dal campo writerIdentity recuperato nella sezione precedente dopo la creazione del 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 compilare la destinazione del sink: il bucket Logging o il set di dati BigQuery.

Configurare l'accesso in lettura alla destinazione

Ora che il sink di log instrada i log dall'intera organizzazione a 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, 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, scegli Accessotore di visualizzazione dei 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 log predefinita _AllLogs come segue:

      locations/BUCKET_LOCATION/buckets/BUCKET_NAME/views/_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 set di dati BigQuery, segui i passaggi descritti nella sezione Concedere l'accesso a un set di dati nella documentazione di BigQuery.

Verifica che i log siano instradati alla destinazione

Analisi dei log

Quando esegui il routing dei log su un bucket di log di cui è stato eseguito l'upgrade ad Analisi dei log, 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 il routing dei log venga eseguito 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 del log sotto il bucket di log che hai creato (ossia BUCKET_NAME) se non è già espanso.

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

    Analisi dei log con la tabella cloudaudit_googleapis_com_data_access selezionata.

  5. Accanto a _AllLogs, fai clic su Query . Questo inserisce nell'editor Query una query SQL di esempio per recuperare le voci di log con routing di recente.

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

A seconda del livello di attività dei progetti Google Cloud nella tua organizzazione, potresti dover attendere alcuni minuti prima che alcuni log vengano generati e poi indirizzati 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:

Spazio di esplorazione BigQuery con la tabella cloudaudit_googleapis_com_data_access selezionata.

Lo screenshot mostra come Cloud Logging assegna un nome a 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 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 è partizionata anche in base ai timestamp per ciascuna voce di log.

A seconda del livello di attività nei progetti Google Cloud nella tua organizzazione, potresti dover attendere alcuni minuti prima che alcuni log vengano generati e poi indirizzati al set di dati BigQuery.

Analisi dei log

Puoi eseguire un'ampia gamma di query sui log della piattaforma e di controllo. Il seguente elenco fornisce una serie di domande di sicurezza di esempio che è consigliabile porre ai tuoi log. Per ogni domanda in questo elenco sono presenti due versioni della query CSA corrispondente: una per l'utilizzo con Analisi dei log e una per l'utilizzo con BigQuery. Usa la versione della query che corrisponde alla destinazione del sink configurata in precedenza.

Analisi dei log

Prima di utilizzare una qualsiasi 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 (ossia PROJECT_ID), e MY_DATASET_ID con la regione e il nome di quel bucket di log (ovvero BUCKET_LOCATION.BUCKET_NAME).

Vai ad Analisi dei log

BigQuery

Prima di utilizzare una qualsiasi 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 (ossia PROJECT_ID), quindi MY_DATASET_ID con il nome del set di dati, ovvero DATASET_ID.

Vai a BigQuery

  1. Domande sull'accesso
  2. Domande sulle modifiche alle autorizzazioni
  3. Domande sull'attività di provisioning
  4. Domande sull'utilizzo del carico di lavoro
  5. Domande sull'accesso ai dati
  6. Domande sulla sicurezza della rete

Domande sull'accesso

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

Google Workspace ha segnalato un tentativo di accesso sospetto?

Analizzando i log di Cloud Identity che fanno parte del controllo degli accessi a Google Workspace, la seguente query rileva i tentativi di accesso sospetti segnalati da Google Workspace. Questi tentativi di accesso possono provenire dalla Console Google Cloud, dalla Console di amministrazione o da 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"

Eventuali errori di accesso eccessivi causati da qualsiasi identità utente?

Cercando nei log di Cloud Identity che fanno parte del controllo dell'accesso a Google Workspace, la seguente query rileva gli utenti che hanno riscontrato tre o più errori di accesso successivi 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

Si sono verificati tentativi di accesso che violano i Controlli di servizio VPC?

Analizzando gli audit log relativi ai criteri negati da Cloud Audit Logs, la query seguente rileva i tentativi di accesso bloccati dai Controlli di servizio VPC. Qualsiasi risultato di query potrebbe 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

Si sono verificati tentativi di accesso che violano i controlli dell'accesso IAP?

Analizzando i log esterni del bilanciatore del carico delle applicazioni, la query seguente rileva i tentativi di accesso bloccati da IAP. Qualsiasi risultato della query potrebbe indicare un tentativo di accesso iniziale o di exploit delle 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 analisi sull'attività dell'amministratore che modifica le autorizzazioni, tra cui modifiche a criteri IAM, gruppi e membri dei gruppi, account di servizio ed eventuali chiavi associate. Queste modifiche alle autorizzazioni potrebbero fornire un livello elevato di accesso ad ambienti o dati sensibili.

Eventuali utenti aggiunti a gruppi con privilegi elevati?

Analizzando i log di controllo dei controlli dell'amministratore di Google Workspace, la query seguente rileva gli utenti che sono stati aggiunti a uno dei gruppi con privilegi elevati elencati nella query. Puoi utilizzare l'espressione regolare nella query per definire quali gruppi (ad esempio admin@example.com o prod@example.com) monitorare. Qualsiasi risultato della query potrebbe indicare un'escalation dei privilegi dannosa 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
  )

Qualche autorizzazione concessa su un account di servizio?

Analizzando gli audit log delle attività di amministrazione da Cloud Audit Logs, la query seguente rileva eventuali autorizzazioni concesse a un'entità su un account di servizio. Esempi di autorizzazioni che possono essere concesse sono la possibilità di impersonare quell'account di servizio o di creare chiavi dell'account di servizio. Qualsiasi risultato di query potrebbe indicare un'istanza di escalation dei privilegi o un rischio di fuga 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 "%@example.com"
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 "%@example.com"
ORDER BY
  timestamp DESC

Esistono chiavi o account di servizio creati da identità non approvate?

Analizzando gli audit log dell'attività di amministrazione, la query seguente rileva eventuali account di servizio o chiavi 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 automatizzato. Di conseguenza, 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"

Sono presenti utenti aggiunti o rimossi da un criterio IAM sensibile?

Effettuando una ricerca negli audit log delle attività di amministrazione, la query seguente rileva qualsiasi modifica dell'accesso di utenti o gruppi 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. Qualsiasi risultato di query potrebbe indicare tentativi di bypassare 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 sull'attività di provisioning

Queste query di esempio eseguono analisi per rilevare attività amministrative sospette o anomale, 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 query seguente rileva eventuali modifiche apportate alle impostazioni di logging. Il monitoraggio delle impostazioni di logging consente di rilevare la disabilitazione accidentale o dannosa degli audit log e di 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"

Eventuali log di flusso VPC attivamente disabilitati?

Cercando gli audit log delle attività di amministrazione, la query seguente rileva qualsiasi subnet in cui i log di flusso VPC sono stati attivamente disabilitati . Il monitoraggio delle impostazioni dei log di flusso VPC consente di rilevare la disabilitazione accidentale o dannosa dei log di flusso VPC e di 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?

Eseguendo una ricerca negli audit log dell'attività di amministrazione, la query seguente rileva un numero insolitamente elevato di modifiche alle regole firewall in un determinato giorno dell'ultima settimana. Per determinare se è presente un outlier, la query esegue un'analisi statistica sul conteggio giornaliero delle modifiche alle regole firewall. Le medie e le deviazioni standard vengono calcolate per ogni giorno esaminando i conteggi giornalieri precedenti con una finestra temporale di 90 giorni. Un valore anomalia viene considerato quando il conteggio giornaliero è superiore a due deviazioni standard sopra la media. La query, compresi il fattore di deviazione standard e le finestre temporali, può essere configurata per adattarsi al tuo profilo di 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

Ci sono VM eliminate nell'ultima settimana?

Cercando gli audit log delle attività di amministrazione, la query seguente elenca tutte le istanze di 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 del carico di lavoro

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

Hai utilizzato un'API insolitamente elevata da parte di qualsiasi identità utente nell'ultima settimana?

Analizzando tutti Cloud Audit Logs, la query seguente rileva un utilizzo insolitamente elevato delle API da parte di qualsiasi identità utente in un determinato giorno dell'ultima settimana. Un utilizzo insolitamente elevato potrebbe essere un indicatore di potenziale abuso delle API, minacce interne o divulgazione di credenziali. Per determinare se esiste un outlier, questa query esegue un'analisi statistica sul conteggio giornaliero delle azioni per entità. Le medie e le deviazioni standard vengono calcolate per ogni giorno e per ogni entità 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, inclusi il fattore di deviazione standard e le finestre temporali, sono tutte configurabili per adattarsi al tuo profilo di 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 giornaliero della scalabilità automatica nell'ultimo mese?

Analizzando gli audit log delle attività di amministrazione, la seguente query segnala l'utilizzo della scalabilità automatica in base al giorno nell'ultimo mese. Questa query può essere utilizzata per identificare pattern 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

Queste query di esempio eseguono analisi per capire chi accede ai dati o li modifica in Google Cloud.

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

La seguente query utilizza gli audit log di accesso ai dati per trovare le identità utente che hanno eseguito più spesso 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 "account" il mese scorso?

La seguente query utilizza gli audit log di accesso ai dati per trovare le identità utente che hanno eseguito più spesso query 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 seguente query 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, ad esempio 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 si accede 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ù di frequente nell'ultimo mese. Mostra l'identità dell'utente associata e un'analisi del numero totale di volte in cui i dati sono stati letti e 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 prime 10 query relative a BigQuery nell'ultima settimana?

La seguente query utilizza gli audit log di accesso ai dati per trovare le query più comuni nell'ultima settimana. Elenca anche gli utenti corrispondenti e le 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 dell'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 di sicurezza della rete

Queste query di esempio eseguono analisi sulla tua attività di rete in Google Cloud.

Ci sono 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 visto per la prima volta nelle ultime 24 ore in una finestra temporale di 60 giorni. Ti consigliamo di utilizzare e ottimizzare questa query su 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

Ci sono connessioni bloccate da Google Cloud Armor?

La seguente query consente di rilevare potenziali tentativi di exploit analizzando i log esterni del bilanciatore del carico delle applicazioni 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 Google Cloud Armor sul bilanciatore del carico delle applicazioni esterno. Questa query presuppone inoltre che tu abbia abilitato il logging del bilanciatore del carico delle applicazioni esterno come descritto nelle istruzioni fornite dal link 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

Cloud IDS ha rilevato virus o malware ad alta gravità?

La seguente query mostra qualsiasi virus o malware ad alta gravità rilevato da Cloud IDS eseguendo ricerche 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 oggetto di query su Cloud DNS dalla tua rete VPC?

La seguente query elenca i primi 10 domini oggetto di query su Cloud DNS dalle tue reti VPC negli ultimi 60 giorni. Questa query presuppone che tu abbia attivato il logging di Cloud DNS per le tue reti VPC come descritto nelle istruzioni fornite dal link Abilita 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