Google Cloud でのセキュリティ ログ分析

Last reviewed 2022-12-14 UTC

このガイドでは、セキュリティ担当者は、セキュリティ分析で使用する Google Cloud ログをオンボーディングする方法について説明します。セキュリティ分析を実施することで、マルウェア、フィッシング、ランサムウェア、適切に構成されていないアセットなどの脅威を防止、検出、対処できます。

このガイドでは、次の方法について説明します。

  • ログの分析を有効にします。
  • これらのログを、BigQuery、Chronicle、サードパーティのセキュリティ情報やイベント管理（SIEM）テクノロジーなどの任意の分析ツールにエクスポートします。
  • コミュニティ セキュリティ分析（CSA）のプロジェクトでサンプルクエリを使用して、ログを分析してクラウドの使用状況を監査し、データとワークロードに対する潜在的な脅威を検出します。

このガイドの情報は、Google Cloud の自律性セキュリティ オペレーションの一部です。これには、脅威検出機能を向上させるために、検出と対応のプラクティスとエンジニアリング分析のエンジニアリング主導の変換が含まれます。

このガイドでは、分析するデータソースをログで提供します。ただし、このガイドのコンセプトを適用して、Security Command Center のセキュリティ結果など、Google Cloud の他のセキュリティ関連データを分析できます。Security Command Center Premium には、定期的に更新されるマネージド検出器のリストがあります。これらは、システム内の脅威、脆弱性、構成ミスをほぼリアルタイムで識別するように設計されています。これらのコマンドを Security Command Center から分析し、このガイドで説明するセキュリティ分析ツールに取り込んだログと関連付けることで、潜在的なセキュリティ上の脅威をより広範囲に把握できます。

次の図は、セキュリティ データソース、セキュリティ分析ツール、CSA クエリがどのように連携するかを示しています。

セキュリティ分析のツールとコンテンツ。

この図は、Cloud Logging からのログ、Cloud Asset Inventory からのアセットの変更、Security Command Center からのセキュリティの検出結果から始まります。この図は、選択したセキュリティ データソース（BigQuery、Chronicle、サードパーティの SIEM）にエクスポートされているセキュリティ データソースを示しています。最後に、この図では、分析ツールで CSA クエリを使用して、エクスポートされたセキュリティ データソースを分析しています。

セキュリティ ログ分析のワークフロー

このセクションでは、Google Cloud でセキュリティ ログ分析を設定する手順について説明します。セキュリティ ログ分析を設定する最初のステップは、分析するログを有効にすることです。次に、ログをエクスポートする必要があります。最後に、ログを分析する必要があります。次の図は、この 3 つのステップを図示しています。

セキュリティ ログ分析を設定する 3 つのステップ:（1）ログを有効にする、（2）ログをエクスポートする、（3）ログを分析する。

プロセスの各ステップは、次のリストで説明するように、さまざまなコンポーネントで構成されています。

  • ログを有効にする: Google Cloud では多くのセキュリティ ログを利用できます。各ログには、特定のセキュリティ上の疑問の解決に役立つさまざまな情報があります。Cloud Audit Logs などの一部のログはデフォルトで有効になります。その他は、Cloud Logging で追加の取り込みコストが発生するため、手動で有効にする必要があります。したがって、ワークフローの最初のステップは、セキュリティ分析のニーズに最も関連性の高いセキュリティ ログに優先順位を付けて、それらの特定のログを個別に有効にすることです。

    可視性と脅威検出のカバレッジの観点からログを評価できるように、このガイドにはログスコープ ツールが含まれています。このツールは、MITRE ATT&CK® Matrix for Enterprise で関連するログを戦術と技術にマッピングします。このツールは、Security Command Center の Event Threat Detection ルールを、依存するログにマッピングします。ログスコープ ツールを使用すると、使用する分析ツールに関係なくログを評価できます。

  • ログをエクスポートする: 分析するログを特定して有効にしたら、BigQuery、Chronicle、サードパーティの SIEM テクノロジーなどの分析ツールにログをエクスポートします。

    ログをエクスポートする方法は、使用する分析ツールによって異なります。このガイドでは、さまざまなエクスポート オプションについて簡単に説明し、ログシンクを使用して BigQuery にログをエクスポートする方法を示します。

  • ログを分析する: ログを分析ツールにエクスポートしたら、次のステップでは、エクスポートされたログを分析して、潜在的なセキュリティ上の脅威を特定します。エクスポートされたログをどのように分析するかは、使用する分析ツールによって異なります。BigQuery データセットを使用する場合は、SQL クエリを使用してログを分析できます。Chronicle を使用している場合は、YARA-L ルールを使用してログを分析します。サードパーティの SIEM ツールを使用している場合は、そのツールで指定されたクエリ言語を使用します。

    このガイドでは、BigQuery データセットまたはサードパーティ製 SIEM ツールのログを分析するために使用できる SQL クエリについて説明します。このガイドの SQL クエリは、コミュニティ セキュリティ分析（CSA）プロジェクトから提供されています。CSA は、Google Cloud ログの分析を開始するために再利用できる事前構築済みのクエリとルールのベースラインを提供するように設計されたオープンソースのセキュリティ分析のオープンソース セットです。

次のセクションでは、セキュリティ ログ分析ワークフローの各ステップを設定して適用する方法について詳しく説明します。

ログを有効化

ログを有効にするプロセス全体は次のとおりです。

  • このガイドのログスコープ ツールを使用して、エクスポートするログを特定する。
  • ログスコープ ツールによって生成されたログフィルタを記録し、後でログシンクを構成するときに使用する。
  • 選択した各ログまたはサービスに対してロギングを有効にする。

ロギングは、すべてのサービスではデフォルトで有効になりません。ログスコープ ツールでログを選択しても、それらが自動的に有効になることはありません。関心のある特定のサービスに対して、適切なレベルのロギングが有効になっていることを確認する必要があります。サービスによっては、このセクションで後述するように、Cloud Audit Logs の対応するデータアクセス監査ログとプラットフォーム ログの両方を有効にする必要があります。

ログスコープ ツールを使用してログを特定する

ログスコープ ツールは、次のインタラクティブなテーブルとログフィルタで構成されます。このツールは、Cloud Audit Logs、アクセスの透明性ログ、ネットワーク ログ、複数のプラットフォーム ログなど、Google Cloud 全体のセキュリティ関連の重要なログを一覧表示します。このツールを使用するには、まずセキュリティとコンプライアンスのニーズに基づいて、エクスポートして分析するログを選択します。選択したログが、ツールによって生成されるログフィルタに追加されます。

選択するログを評価するために、このツールによって各ログタイプが次の領域にマッピングされます。

ログ範囲の設定ツール

このセクションのインタラクティブ テーブルは、ログスコーピング ツールとして機能します。ツールが生成したログフィルタは、表に続く [自動生成ログフィルタ] セクションに表示されます。このツールを使用して、エクスポートするログを特定して選択します。

  • ログスコープ ツールでログを選択または削除するには、ログ名の横にある切り替えボタンをクリックします。
  • すべてのログを選択または削除するには、[ログタイプ] 見出しの横にある切り替えボタンをクリックします。
  • 各ログタイプでモニタリングできる MITRE ATT&CK 手法を確認するには、[MITRE ATT&CK 戦術と手法] の横にある をクリックします。


ログフィルタを記録する

ログスコープ ツールによって自動的に生成されるログフィルタには、ツールで選択したすべてのログが含まれます。フィルタをそのまま使用することも、要件に合わせてログフィルタをさらに絞り込むこともできます。たとえば、1 つ以上の特定のプロジェクトにあるリソースのみをフィルタリング（または除外）できます。ロギング要件を満たすログフィルタを作成したら、ログのエクスポート時に使用するためにフィルタを保存する必要があります。たとえば、次のように、テキスト エディタでフィルタを保存したり、環境変数に保存できます。

  1. ログ スコープ ツールを使用して、エクスポートするログを選択します。
  2. ツールに続く [自動生成ログフィルタ] セクションで、ログフィルタのコードをコピーします。
  3. 省略可: フィルタを絞り込むために、コピーしたコードを編集します。

  4. Cloud Shell で、ログフィルタを保存する変数を作成します。

    export LOG_FILTER='LOG_FILTER'

    LOG_FILTER は、ログフィルタのコードに置き換えます。

サービス固有のプラットフォーム ログを有効にする

ログスコープ ツールで選択した各プラットフォーム ログに、サービスごとに（通常はリソースレベルで）これらのログを有効にする必要があります。たとえば、Cloud DNS ログは VPC ネットワーク レベルで有効になります。同様に、VPC フローログはサブネット内のすべての VM に対してサブネット レベルで有効になり、ファイアウォール ルールロギングのログは個々のファイアウォール ルールレベルで有効になります。

プラットフォーム ログごとに、ロギングを有効にする手順が異なります。ただし、ログスコープ ツールを使用すると、各プラットフォーム ログに関連する手順をすばやく開くことができます。

特定のプラットフォーム ログのロギングを有効にする手順は次のとおりです。

  1. ログスコープ ツールで、有効にするプラットフォーム ログを見つけます。
  2. [デフォルトで有効] 列で、そのログに対応する [有効にする] リンクをクリックします。リンクをクリックすると、そのサービスのロギングを有効にする方法の詳細が表示されます。

データアクセス監査ログを有効にする

ログスコーピング ツールでわかるように、Cloud Audit Logs のデータアクセス監査ログは広範な脅威検出を提供します。ただし、ボリュームは非常に大きくなる可能性があります。このため、データアクセス監査ログを有効にすると、これらのログの取り込み、保存、エクスポート、処理に関連する追加料金が発生する可能性があります。これらの追加料金は、分析プロセス全体で Cloud Logging に関連する料金から、セキュリティ分析ツールに関連する料金まで発生します。このセクションでは、これらのログを有効にする方法と、価値とコストのトレードオフに役立つベスト プラクティスについて説明します。

データアクセス監査ログは、BigQuery を除き、デフォルトで無効になっています。BigQuery 以外の Google Cloud サービスのデータアクセス監査ログを構成するには、Google Cloud コンソールを使用するか、Cloud CLI を使用 して、Identity and Access Management（IAM）ポリシー オブジェクトを編集します。データアクセス監査ログを有効にする場合は、記録されるオペレーションのタイプを構成することもできます。データアクセス監査ログには次の 3 つのタイプがあります。

  • ADMIN_READ: メタデータまたは構成情報を読み取るオペレーションを記録します。
  • DATA_READ: ユーザー提供データを読み取るオペレーションを記録します。
  • DATA_WRITE: ユーザー提供データを書き込むオペレーションを記録します。

メタデータまたは構成情報を書き込むオペレーションである ADMIN_WRITE オペレーションの記録は構成できません。ADMIN_WRITE オペレーションは、Cloud Audit Logs の管理アクティビティ監査ログに含まれるため、無効にすることはできません。

データアクセス監査ログの量を管理する

データアクセス監査ログを有効にする場合は、セキュリティの可視性の観点から価値を最大化し、費用と管理オーバーヘッドを制限することが目標です。この目標を達成するため、次のようにして価値の低い大量のログを除外することをおすすめします。

  • 機密性の高いワークロード、キー、データをホストするサービスなど、関連サービスを優先します。他のサービスよりも優先できるサービスの例については、データアクセス監査ログの構成の例をご覧ください。

  • デベロッパーやステージング環境をホストするプロジェクトではなく、本番環境ワークロードをホストするプロジェクトなど、関連するプロジェクトを優先します。特定のプロジェクトのすべてのログを除外するには、シンクのログフィルタに次の式を追加します。PROJECT_ID は、すべてのログを除外するプロジェクトの ID に置き換えます。

    プロジェクト ログフィルタの式
    特定のプロジェクトのすべてのログを除外する 
    NOT logName =~ "^projects/PROJECT_ID"

  • 記録するオペレーションを最小限に抑えるために、ADMIN_READ、DATA_READ、DATA_WRITE などのデータアクセス オペレーションのサブセットを優先します。たとえば、Cloud DNS などの一部のサービスは 3 種類のオペレーションをすべて書き込みますが、ロギングを有効にできるのは ADMIN_READ オペレーションのみです。この 3 種類のデータアクセス オペレーションのいずれか 1 つを構成した後で、特にトラフィックが多い特定のオペレーションを除外できます。このような大量のオペレーションを除外するには、シンクのログフィルタを変更します。たとえば、一部の重要なストレージ サービスに対する DATA_READ オペレーションを含む、完全なデータアクセス監査ログを有効にします。このような特定のトラフィックの多いデータ読み取りオペレーションを除外するには、次の推奨ログフィルタ式をシンクのログフィルタに追加できます。

    サービス ログフィルタの式
    Cloud Storage から大量のログを除外する 
    NOT (resource.type="gcs_bucket" AND
    (protoPayload.methodName="storage.buckets.get" OR
    protoPayload.methodName="storage.buckets.list"))
    Cloud SQL から大量のログを除外する 
    NOT (resource.type="cloudsql_database" AND
    protoPayload.request.cmd="select")

  • 関連するリソースを優先する。特に機密性の高いワークロードとデータをホストするリソースを優先する。リソースは、処理するデータの値と、リソースが外部にアクセスできるかどうかなどのセキュリティ リスクに基づいて分類できます。データアクセス監査ログはサービスごとに有効になりますが、ログフィルタを通じて特定のリソースやリソースタイプを除外できます。

  • 特定のプリンシパルをデータアクセスから除外します。たとえば、内部テスト アカウントを除外し、そのアカウントがオペレーションを記録しないようにします。詳しくは、データアクセス監査ログのドキュメントで除外の設定をご覧ください。

データアクセス監査ログの構成例

次の表に、Cloud プロジェクトでログのボリュームを制限しつつ、セキュリティの可視性を高めるベースライン データアクセス監査ログ構成を示します。

ティア サービス データアクセス監査ログのタイプ MITRE ATT&CK の戦術
認証と認可サービス IAM
Identity-Aware Proxy (IAP)1
Cloud KMS
Secret Manager
Resource Manager 		ADMIN_READ
DATA_READ		 調査
認証情報アクセス
権限昇格
ストレージ サービス BigQuery（デフォルトで有効）
Cloud Storage1、2 		DATA_READ
DATA_WRITE		 コレクション
引き出し
インフラストラクチャ サービス Compute Engine
組織のポリシー 		ADMIN_READ Discovery

1 IAP または Cloud Storage のデータアクセス監査ログを有効にすると、IAP で保護されたウェブリソースまたは Cloud Storage オブジェクトへのトラフィックが多い場合に、大量のログが生成されることがあります。

2 Cloud Storage のデータアクセス監査ログを有効にすると、非公開オブジェクトで認証によるブラウザでのダウンロードが使用できなくなる場合があります。この問題の詳細と回避策については、Cloud Storage のトラブルシューティング ガイドをご覧ください。

この構成例では、基になるデータ、メタデータ、または構成に基づいて、サービスが機密層でグループ化されています。これらの階層では、データアクセス監査ログの次の推奨粒度が示されています。

  • 認証と認可サービス: この種類のサービスでは、すべてのデータアクセス オペレーションを監査することをおすすめします。このレベルの監査は、機密性の高いキー、シークレット、IAM ポリシーへのアクセスをモニタリングする際に役立ちます。このアクセスをモニタリングすると、検出、認証情報アクセス、権限昇格などの MITRE ATT&CK 戦術を検出できます。
  • ストレージ サービス: この種類のサービスでは、ユーザーが提供したデータに関連するデータアクセス オペレーションを監査することをおすすめします。このレベルの監査は、重要な機密データへのアクセスをモニタリングするのに役立ちます。このアクセスをモニタリングすると、データに対するコレクションやデータの引き出しなどの MITRE ATT&CK 戦術を検出できる可能性があります。
  • インフラストラクチャ サービス: この種類のサービスでは、メタデータまたは構成情報を含むデータアクセス オペレーションを監査することをおすすめします。このレベルの監査は、インフラストラクチャ構成のスキャンに役立ちます。このアクセスをモニタリングすると、ワークロードに対して Discovery などの MITRE ATT&CK 戦術を検出できる可能性があります。

ログをエクスポートする

ログを特定して有効にしたら、次のステップでログを分析ツールにエクスポートします。エクスポート プロセスは、次の図に示すように、使用する分析ツールによって異なります。

ログシンクによる方法: ログシンクを使用して BigQuery に、ログシンクと Pub/Sub を使用してサードパーティの SIEM に、直接取り込みを使用して Chronicle にエクスポートする。

この図は、次のエクスポート プロセスを示しています。

  • Chronicle を使用し、この事前定義されたログセットがセキュリティ分析のニーズを満たす場合は、図に示すように、Chronicle のビルドインを使用して、Chronicle にログを直接エクスポートできます。この事前定義ログのセットは、ログ スコープ ツールの [Chronicle に直接エクスポートできる] 列を確認して表示することもできます。これらの事前定義されたログのエクスポートの詳細については、Chronicle への Google Cloud ログの取り込みをご覧ください。

  • BigQuery またはサードパーティの SIEM を使用している場合、または拡張したログセットを Chronicle にエクスポートする場合は、この図を有効にしてログを分析する必要があります。この追加のステップは、選択したログを適切にルーティングするログシンクを構成することです。BigQuery を使用している場合、ログを BigQuery にルーティングするのに必要なのはログシンクのみです。サードパーティの SIEM を使用している場合は、ログが分析ツールに取り込まれるまで、ログシンクで Pub/Sub または Cloud Storage 内の選択したログを集計する必要があります。

Chronicle とサードパーティの SIEM へのエクスポート プロセスについては、このガイドでは説明しません。以降のセクションでは、BigQuery にログをエクスポートするために必要な手順の概要と詳細を説明します。

  1. BigQuery でログ エクスポート データセットを設定します。

  2. BigQuery のログシンクを構成します。

    このセクションでは、BigQuery のログシンクの構成方法を説明します。ただし、この例に示すログシンクのコンセプトをサードパーティの SIEM ツールにエクスポートしたり、展開された一連のログを Chronicle にエクスポートしたりできます。主な違いは、ログシンクのエクスポート先です。宛先は BigQuery ではなく、下流分析ツールがログを取得する Cloud Storage バケットまたは Pub/Sub トピックのいずれかです（図を参照）。

  3. BigQuery データセットの IAM ポリシー権限を設定します。

  4. ログが BigQuery にエクスポートされていることを確認します。

BigQuery データセットのデータセットを設定する

エクスポートしたログをホストするデータセットを設定するための手順を行います。集約ログを使用している場合は、組織内のいずれかの Google Cloud プロジェクトに BigQuery データセットを作成する必要があります。単一のプロジェクトにログ エクスポートを使用している場合、同じプロジェクトに BigQuery データセットを作成する必要があります。

BigQuery のログシンクを構成する

ログ エクスポートを構成するには、以前に生成して保存したログフィルタを使用してログシンクを作成します。データの管理とクエリを簡素化するには、ログエントリの timestamp フィールドに基づいて日別にデータを分割するパーティション分割テーブルにデータをエクスポートするようにログシンクを構成します。 パーティション分割テーブルの使用により、クエリの一部としてスキャンされるデータ量を減らして、クエリのコストを削減できます。パーティション分割テーブルのもう 1 つの利点は、個別のテーブルまたはデータセット全体のパーティションの有効期限を設定できることです。これにより、役立つと思われる期間、ロギングデータを維持できます。たとえば、監査ロギングデータを 3 年間保持すると、古いデータはパーティションの有効期限が切れて自動的に削除されます。

gcloud CLI から gcloud logging sinks create コマンドまたは organizations.sinks.create API 呼び出しを使用して、適切なロギング フィルタが設定されたシンクを作成します。次の例では、gcloud コマンドを使用して、組織用に gcp_logging_sink_bq というシンクを作成します。シンクにはすべての子プロジェクトが含まれ、使用するログフィルタを指定します。

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

以下を置き換えます。

  • PROJECT_ID: BigQuery データセットが配置されているプロジェクトの ID。
  • DATASET_ID: BigQuery データセットの ID。
  • LOG_FILTER: ログスコープ ツールから保存したログフィルタ。
  • ORGANIZATION_ID: 組織の ID。

gcloud logging sinks create コマンドは、次のようなレスポンスを返します。

Created [https://logging.googleapis.com/v2/organizations/324989855333/sinks/gcp_logging_sink_bq].
Please remember to grant `serviceAccount:gcp-logging-sink-bq@logging-o324989855333.iam.gserviceaccount.com` the WRITER role on the dataset..
More information about sinks can be found at /logging/docs/export/configure_export

レスポンスの出力で、serviceAccount フィールドに表示される値をコピーして保存し、次のセクションで使用します。たとえば、前の出力例で示した serviceAccount 値は gcp-logging-sink-bq@logging-o324989855333.iam.gserviceaccount.com です。

serviceAccount フィールドに表示される値は、作成したシンクに関連付けられているサービス アカウントの ID です。この識別子は、シンクの書き込み ID です。この ID に BigQuery データセットへの書き込みアクセス権を付与するまで、このシンクからのログエントリのエクスポートは失敗します。 次のセクションで、シンクの書き込み ID への書き込みアクセス権を付与します。

BigQuery データセットの IAM ポリシー権限を設定する

ログシンクがエクスポートしたログを BigQuery に書き込むには、シンクの書き込み ID を BigQuery データセットに追加し、その ID に編集者権限を付与する必要があります。それ以外の場合、書き込みオペレーションは失敗します。

サービス アカウントに権限を付与するには、次の操作を行います。

  1. Google Cloud コンソールで [BigQuery] に移動します。

    BigQuery に移動

  2. エクスポートされたログ用に作成した BigQuery データセットを開きます。

  3. データセットの情報タブで、[共有] プルダウン メニューをクリックし、[権限] をクリックします。

  4. [データセットの権限] サイドパネルで、[プリンシパルを追加] をクリックします。

  5. [新しいプリンシパル] フィールドに、シンクの書き込み ID を入力します。この ID は、ログシンクの作成後に生成されたレスポンスで提供される serviceAccount フィールドの値であることを思い出してください。

  6. [役割] プルダウン メニューで、[BigQuery データ編集者] を選択します。

    IAM ポリシー権限 - 編集者。

このフィルタを使用してログ エクスポートを作成すると、構成されたプロジェクトの BigQuery データセットへの入力が、ログファイルによって開始されます。

BigQuery にログがエクスポートされていることを確認する

BigQuery データセットにログをエクスポートすると、次のスクリーンショットに示すように、Cloud Logging はエクスポートされたログエントリを保持する BigQuery テーブルを作成します。

BigQuery エクスプローラで cloudaudit_googleapis_com_data_access テーブルが選択されている。

このスクリーンショットは、ログエントリが属するログの名前に基づいて、Cloud Logging が各 BigQuery テーブルに名前を付ける方法を示しています。たとえば、スクリーンショットで選択された cloudaudit_googleapis_com_data_access テーブルには、ログ ID が cloudaudit.googleapis.com%2Fdata_access のデータアクセス監査ログが含まれています。各テーブルは、対応するログエントリに基づいて名前が付けられるだけでなく、各ログエントリのタイムスタンプに基づいても分割されます。

管理アクティビティ ログとデータアクセス ログの両方が BigQuery に読み込まれ、BigQuery の protoPayload ログエントリ フィールドの名前が protoPayload_auditlog に変更されます。BigQuery に書き込む前に Cloud Logging によって行われるスキーマの変換の詳細については、エクスポートされた監査ログのフィールドをご覧ください。

ログを分析する

監査ログとプラットフォーム ログに対して、さまざまなクエリを実行できます。次のリストは、質問のタイプごとにグループ化されたセキュリティ問題のサンプルを示しています。このリスト内の各質問について、関連する CSA クエリもこのガイドに記載されています。各質問に関連付けられた CSA クエリを使用するには、MY_DATASET_ID をこのドキュメントの前半で作成した BigQuery データセットに置き換え、MY_PROJECT_ID をデータセットが配置されている Google Cloud プロジェクト IDに置き換えます。

ログインとアクセスに関する質問

これらのサンプルクエリでは、分析を実行して、不審なログイン試行や Google Cloud 環境への最初のアクセス試行を検出します。

Google Workspace によって不審なログイン試行が報告されましたか？

次のクエリでは、Google Workspace ログイン監査の一部である Cloud Identity ログを検索し、Google Workspace から報告された不審なログイン試行を検出します。ログインは、Google Cloud コンソール、Google Workspace 管理コンソール、gcloud CLI のいずれかから行うことができます。

backends/bigquery/sql/1_02_suspicious_login_attempt.sql

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"

任意のユーザー ID からの過剰なログインエラーが発生していますか？

次のクエリでは、Google Workspace ログイン監査の一部である Cloud Identity ログを検索し、過去 24 時間以内にログインが連続して 3 回以上失敗したユーザーを検出します。

backends/bigquery/sql/1_03_excessive_login_failures.sql

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

VPC Service Controls に違反するアクセス試行は見られますか？

Cloud Audit Logs のポリシー拒否監査ログを分析すると、次のクエリは VPC Service Controls によってブロックされたアクセス試行を検出します。クエリ結果は、盗難された認証情報を使用した不正なネットワークからのアクセス試行など悪意のあるアクティビティを示している可能性があります。

backends/bigquery/sql/1_10_access_attempts_blocked_by_VPC_SC.sql

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

IAP アクセス制御に違反しているアクセス試行はありますか？

次のクエリは、HTTP(S) 負荷分散ログを分析することで、IAP によってブロックされたアクセス試行を検出します。クエリ結果は、初期アクセス試行または脆弱性攻撃の試みを示す場合があります。

backends/bigquery/sql/1_20_access_attempts_blocked_by_IAP.sql

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

権限変更に関する質問

これらのサンプルクエリは、IAM ポリシー、グループとグループ メンバーシップ、サービス アカウント、関連する鍵の変更など、権限を変更する管理者のアクティビティを分析します。このような権限の変更により、機密性の高いデータや環境に対して高レベルのアクセスが発生する可能性があります。

高度な権限が付与されたグループにユーザーが追加されていますか？

次のクエリでは、Google Workspace 管理監査ログを分析することにより、クエリにリストされた権限の高いグループのいずれかに追加されたユーザーを検出します。クエリで正規表現を使用して、モニタリング対象のグループ（admin@example.com や prod@example.com など）を定義します。クエリ結果は、悪意のある、または偶発的な権限昇格を示している可能性があります。

backends/bigquery/sql/2_02_user_added_to_privileged_group.sql

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
  )

サービス アカウントに付与された権限はありますか？

次のクエリでは、Cloud Audit Logs の管理アクティビティ監査ログを分析することで、サービス アカウントに対するプリンシパルに付与されている権限が検出されます。付与される権限の例としては、そのサービス アカウントに成り代わる権限やサービス アカウント キーを作成する権限があります。クエリの結果は、権限昇格のインスタンスや認証情報漏洩のリスクを示している可能性があります。

backends/bigquery/sql/2_20_permissions_granted_over_SA.sql

SELECT
 timestamp,
 logName,
 protopayload_auditlog.authenticationInfo.principalEmail,
 protopayload_auditlog.methodName,
 protopayload_auditlog.resourceName,
 bindingDelta
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 400 DAY)
  AND resource.type="service_account"
  AND protopayload_auditlog.methodName LIKE "google.iam.admin.%.SetIAMPolicy"
  AND bindingDelta.action = 'ADD'

未承認の ID によって作成されたサービス アカウントまたはキーはありますか？

次のクエリは、管理アクティビティ監査ログを分析することで、ユーザーが手動で作成したサービス アカウントまたはキーを検出します。たとえば、自動化されたワークフローの一部として、承認されたサービス アカウントによってのみサービス アカウントの作成を許可するには、ベスト プラクティスに従います。したがって、そのワークフロー以外のサービス アカウントを作成した場合、準拠していないとみなされ、悪意のある可能性もあります。

backends/bigquery/sql/2_30_service_accounts_or_keys_created_by_non_approved_identity.sql

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"

機密性の高い IAM ポリシーに追加された（または削除された）ユーザーは存在しますか？

管理アクティビティ監査ログを検索する場合、次のクエリは、Compute Engine バックエンド サービスなどの IAP で保護されたリソースのユーザーまたはグループのアクセス変更を検出します。次のクエリは、IAM ロール roles/iap.httpsResourceAccessor を含む IAP リソースのすべての IAM ポリシー更新を検索します。このロールは、HTTPS リソースまたはバックエンド サービスにアクセスする権限を付与します。クエリ結果は、インターネットに公開されている可能性のあるバックエンド サービスの防御をバイパスしようとする可能性があります。

backends/bigquery/sql/2_40_user_access_modified_in_IAP.sql

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

プロビジョニング アクティビティに関する質問

これらのサンプルクエリは、リソースのプロビジョニングや構成など、不審な管理アクティビティや異常な管理アクティビティを検出するために分析を行います。

ログイン設定に変更が加えられていますか？

次のクエリでは、管理アクティビティ監査ログを検索すると、ロギング設定に対する変更が検出されます。ロギング設定のモニタリングは、監査ログの無効化や悪意のある無効化などの検出手法を検出するのに役立ちます。

backends/bigquery/sql/3_01_logging_settings_modified.sql

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"

アクティブに無効化されている VPC フローログはありますか？

次のアクティビティでは、管理アクティビティ監査ログを検索することで、VPC フローログがアクティブに無効化されているサブネットを検出します。VPC フローログ設定のモニタリングは、VPC フローログの偶発的または悪意的な無効化や、同様の防御回避策を検出するのに役立ちます。

backends/bigquery/sql/3_02_vpc_flows_logging_disabled.sql

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"

過去 1 週間に異常な数のファイアウォール ルールが変更されていますか？

次のクエリでは、管理アクティビティ監査ログを検索することにより、過去 1 週間に毎日大量のファイアウォール ルール変更が検出されます。外れ値があるかどうかを判定するために、クエリは 1 日あたりのファイアウォール ルールの変更数に対する統計分析を実行します。平均と標準偏差は、90 日間のルックバック ウィンドウを使用して、上記の 1 日のカウントを振り向けることにより、毎日計算されます。外れ値は、1 日の数が平均より標準偏差 2 倍を超える場合に発生します。標準偏差係数とルックバック ウィンドウを含むクエリはすべて、クラウド プロビジョニング アクティビティ プロファイルに適合し、誤検出を最小限に抑えるように構成できます。

backends/bigquery/sql/3_11_unusual_number_of_firewall_rules_modified.sql 

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

過去 1 週間に削除された VM はありますか？

次のクエリでは、管理アクティビティ監査ログを検索すると、過去 1 週間に削除された Compute Engine インスタンスが一覧表示されます。このクエリは、リソースの削除を監査して、悪意のあるアクティビティを検出するのに役立ちます。

backends/bigquery/sql/3_20_virtual_machines_deleted.sql

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

ワークロードの使用状況に関する質問

これらのサンプルクエリでは、クラウドのワークロードと API を誰が、どのように消費しているかを分析し、内部または外部の悪意のある動作を検出できます。

過去 1 週間に任意のユーザー ID による異常な量の API の使用が見られますか？

次のクエリでは、すべての Cloud Audit Logs を分析し、過去 1 週間の任意の日のユーザー ID による異常な API 使用量を検出します。このような異常に高い使用率は、潜在的な API の悪用、内部の脅威、または認証情報の漏洩を示している可能性があります。外れ値があるかどうかを判定するために、このクエリではプリンシパルごとのアクションの 1 日あたりの数に対する統計分析を実行します。平均と標準偏差は、ルックバック ウィンドウを 60 日に設定し、前述の日次数を振り返ることで、各日と各プリンシパルに対して計算されます。外れ値は、ユーザーの 1 日あたりのカウントが平均より標準偏差 3 倍を超える場合に発生します。標準偏差係数とルックバック ウィンドウを含むクエリはすべて、クラウド プロビジョニング アクティビティ プロファイルに適合し、誤検出を最小限に抑えるように構成できます。

backends/bigquery/sql/4_01_unusually_high_api_usage_by_user_identity.sql

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

過去 1 か月における 1 日あたりの自動スケーリングの使用量はどの程度ですか？

次のアクティビティでは、管理アクティビティ監査ログを分析することで、先月の自動スケーリングの使用状況を日付別に報告します。このクエリを使用して、さらなるセキュリティ調査が必要なパターンや異常を特定できます。

backends/bigquery/sql/4_11_autoscaling_usage_frequency_by_day.sql

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

データアクセスに関する質問

これらのサンプル　クエリは、Google Cloud のデータにアクセスまたは修正を行ったユーザーを把握するための分析を行います。

前週に最も頻繁にデータにアクセスしたユーザーは誰か

次のクエリでは、データアクセス監査ログを使用して、過去 1 週間に BigQuery テーブルに最も頻繁にアクセスしたユーザー ID を確認します。

backends/bigquery/sql/5_01_users_who_most_frequently_accessed_data.sql 

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

先月「accounts」テーブルのデータにアクセスしたユーザーは誰か

次のクエリでは、データアクセス監査ログを使用して、過去 1 か月間に特定の accounts テーブルに最も頻繁にクエリを実行したユーザー ID を検索します。次のクエリでは、BigQuery エクスポート先の MY_DATASET_ID および MY_PROJECT_ID プレースホルダのほかに、DATASET_ID と PROJECT_ID プレースホルダを使用しています。DATASET_ID プレースホルダと PROJECT_ID プレースホルダを置き換えて、アクセスを分析するターゲット テーブルを指定する必要があります（この例では accounts テーブル）。

backend/bigquery/sql/5_04_users_person_accessed_data_in_table.sql 

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

最も頻繁にアクセスされているテーブルはどれで、アクセスしたユーザーは誰か

次のクエリでは、データアクセス監査ログを使用して、過去 1 か月間に頻繁に読み取り、変更されたデータが含まれる BigQuery テーブルを検索します。関連するユーザー ID と、データの読み取り総回数に対する変更の総回数の内訳が表示されます。

backend/bigquery/sql/5_05_tables_most_mostly_accessed.sql 

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

前週の BigQuery に対するクエリのトップ 10 は何か

次のクエリでは、データアクセス監査ログを使用して、過去 1 週間で最も頻繁に実行されたクエリを確認します。また、対応するユーザーと参照されたテーブルも一覧表示されます。

backends/bigquery/sql/5_06_BQ_queries_top.sql 

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

過去 1 か月間にデータアクセス ログに記録されたもっとも多い操作は何か

次のクエリでは、Cloud Audit Logs からのすべてのログを使用して、過去 1 か月間に記録された頻度の高い 100 件のアクションを確認します。

backends/bigquery/sql/5_20_top_data_access_actions.sql 

SELECT
  ANY_VALUE(_TABLE_SUFFIX),
  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

ネットワーク セキュリティに関する質問

以下のサンプルクエリでは、Google Cloud のネットワーク アクティビティを分析します。

新しい IP アドレスから特定のサブネットワークへの接続はありますか？

次のクエリは、VPC フローログを分析することで、新しい送信元 IP アドレスから特定のサブネットへの接続を検出します。この例では、ルックバック ウィンドウが 60 日間で、過去 24 時間にソース IP アドレスが初めて検出された場合、送信元 IP アドレスは新規とみなされます。PCI などの特定のコンプライアンス要件の対象となるサブネットで、このクエリを使用して調整することをおすすめします。

backends/bigquery/sql/6_10_connection_from_new_IP.sql 

SELECT
  jsonPayload.connection.src_ip as src_ip,
  MIN(TIMESTAMP(REGEXP_REPLACE(jsonPayload.start_time, r'\.(\d{0,6})\d+(Z)?$', '.\\1\\2'))) AS firstInstance, --- TIMESTAMP supports up to 6 digits of fractional precision, so drop any more digits to avoid parse errors
  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

Google Cloud Armor でブロックされた接続はありますか？

次のクエリは、HTTP(S) 負荷分散ログを分析して、Google Cloud Armor で構成されたセキュリティ ポリシーによってブロックされた接続を検出することで、悪用の試みを検出するのに役立ちます。このクエリでは、HTTP(S) 負荷分散に Google Cloud Armor セキュリティ ポリシーが構成されていることを前提としています。また、このクエリでは、ログ スコープ ツールのEnableリンクで提供されている手順にある通り、HTTP(S) 負荷分散のロギングが有効になっていることを前提としています。

backends/bigquery/sql/6_20_connections_blocked_by_cloud_armor.sql 

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 によって検出された重大なウィルスまたはマルウェアの検出

次のクエリは、Cloud IDS Threat Logs を検索して Cloud IDS によって検出された重大度の高いウィルスまたはマルウェアを表示します。このクエリでは、Cloud IDS エンドポイントが構成されていることを前提としています。

backends/bigquery/sql/6_30_virus_or_malware_detected_by_cloud_IDS.sql 

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" OR "CRITICAL")
  AND jsonPayload.type = "virus"
ORDER BY
  timestamp DESC

VPC ネットワークからの上位の Cloud DNS クエリドメインは何か。

次のクエリは、過去 60 日間に VPC ネットワークから上位 10 の Cloud DNS クエリドメインを一覧表示します。このクエリでは、ログ スコープ ツールのEnableリンクで提供されている手順にある通り、VPC サービスで Cloud DNS ロギングが有効になっていることを前提としています。

backends/bigquery/sql/6_40_DNS_top_queried_domains.sql 

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

次のステップ