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

Last reviewed 2024-05-21 UTC

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

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

  • 分析対象のログを有効にする。
  • それらのログをセキュリティ分析ツール(ログ分析BigQueryGoogle Security Operations、サードパーティのセキュリティ情報およびイベント管理(SIEM)テクノロジーなど)の選択に応じて、1 つの宛先に転送する。
  • それらのログを分析してクラウドの利用状況を監査し、コミュニティ セキュリティ分析(CSA)プロジェクトのサンプルクエリを使用して、データやワークロードに対する潜在的な脅威を検出する。

このガイドに記載されている情報は、Google Cloud の自律型のセキュリティ運用の一部であり、エンジニアリング主導の検知・対応手法の変革や、脅威検知能力を向上させるためのセキュリティ分析が含まれています。

このガイドでは、ログを分析対象のデータソースとして説明を進めます。ただし、このガイドのコンセプトを適用して、Security Command Center のセキュリティ結果など、Google Cloud の他の補完的なセキュリティ関連データを分析できます。Security Command Center Premium には、定期的に更新される管理対象検出機能のリストが用意されており、システム内の脅威、脆弱性、構成ミスをほぼリアルタイムで特定するように設計されています。Security Command Center からこうしたシグナルを分析し、本ガイドで説明するようにセキュリティ分析ツールに取り込まれたログと関連付けることで、潜在的なセキュリティの脅威をより広い視野で把握することが可能になります。

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

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

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

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

このセクションでは、Google Cloud でセキュリティ ログ分析を設定する手順について説明します。このワークフローは、次の図に示す 3 つのステップで構成されており、以下のパラグラフで各ステップについて説明します。

セキュリティ ログ分析を設定する 3 つのステップ: (1)ログを有効化、(2)ログを転送、(3)ログを分析

  • ログを有効化: Google Cloud では多くのセキュリティ ログを使用できます。各ログには、特定のセキュリティ保護用の質問に答える際に役に立つさまざまな情報が含まれています。管理アクティビティ監査ログなどの一部のログはデフォルトで有効になっていますが、その他のログは Cloud Logging で追加の取り込み費用が発生するため、手動で有効にする必要があります。したがって、ワークフローの最初のステップは、セキュリティ分析のニーズに最も関連性が高いセキュリティ ログを優先し、そうした特定のログを個別に有効にすることです。

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

  • ログを転送: 分析するログを特定して有効にしたら、次のステップでは、組織(含まれるフォルダ、プロジェクト、請求先アカウントを含む)からのログを転送して集計します。ログの転送方法は、使用する分析ツールによって異なります。

    このガイドでは、一般的なログの転送先について説明します。また、分析にログ分析と BigQuery のどちらを使用するかに応じて、Cloud Logging の集約シンクで組織全体のログを Cloud Logging ログバケットまたは BigQuery データセットに転送する方法についても説明します。

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

    このガイドでは、ログ分析や BigQuery でログを分析するために使用できる SQL クエリを紹介します。このガイドで提供される SQL クエリは、Community Security Analytics(CSA)プロジェクトに由来しています。CSA は基礎的なセキュリティ分析のオープンソースのセットで、Google Cloud ログの分析を開始するために再利用できる事前構築されたクエリとルールのベースラインを提供するように設計されています。

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

ログを有効化

ログを有効にするプロセスは、次の手順で構成されています。

  1. 本ガイドのログスコープ ツールを使用して、必要なログを特定します。
  2. 後でログシンクを構成するときに使用するために、ログスコープ ツールによって生成されたログフィルタを記録します。
  3. 特定されたログタイプまたは Google Cloud サービスごとにロギングを有効にします。サービスによっては、このセクションの後半で詳述するように、対応するデータアクセス監査ログを有効にしなければならない場合もあります。

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

このセクションで示されているログスコープ ツールを使用すると、セキュリティとコンプライアンスのニーズを満たすログを特定できます。このツールには、Cloud Audit Logs、アクセスの透明性ログ、ネットワーク ログ、いくつかのプラットフォーム ログなど、Google Cloud 全体の貴重なセキュリティ関連ログを一覧表示する対話型のテーブルが用意されています。このツールは、各ログタイプを次の領域にマッピングします。

ログスコープ ツールは、テーブルの直後に表示されるログフィルタも生成します。必要なログを特定したら、ツールでそのログを選択して、そのログフィルタを自動的に更新します。

以下の短い手順で、ログスコープ ツールの使用方法を説明します。

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

ログスコープ ツール

ログフィルタを記録する

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

  1. ツールに続く「自動生成されたログフィルタ」セクションで、ログフィルタのコードをコピーします。
  2. 省略可: コピーしたコードを編集してフィルタを絞り込みます。
  3. Cloud Shell で、ログフィルタを保存する変数を作成します。

    export LOG_FILTER='LOG_FILTER'
    

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

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

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

各プラットフォーム ログには、ロギングを有効にする方法について独自の手順があります。ただし、ログスコープ ツールを使用すると、各プラットフォーム ログに関連する手順をすばやく開くことができます。

特定のプラットフォーム ログのロギングを有効にする方法を確認するには、以下のようにします。

  1. ログスコープ ツールで、有効にするプラットフォーム ログを探します。
  2. [Enabled by default] 列で、そのログに対応する [Enable] リンクをクリックします。リンクをクリックすると、そのサービスのロギングを有効にするための詳細な手順が表示されます。

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

ログスコープ ツールで確認できるように、Cloud Audit Logs のデータアクセス監査ログを使用することで、脅威を広い範囲で検出できます。ただし、ログのボリュームが極めて大きくなる可能性があります。したがって、このデータアクセス監査ログを有効にすると、こうしたログの取り込み、保存、エクスポート、処理に関連して追加料金が発生する場合があります。このセクションでは、こうしたログを有効にする方法と、価値とコストのトレードオフの判断に役立つベスト プラクティスの両方について説明します。

データアクセス監査ログは、BigQuery を除き、デフォルトで無効になっています。BigQuery 以外の Google Cloud サービスのデータアクセス監査ログを構成するには、Google Cloud コンソールを使用するか、Google 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_READDATA_READDATA_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") 
  • 最も機密性が高いワークロードやデータをホストするリソースなど、関連性の高いリソースを優先的に処理します。処理するデータの価値と、外部からアクセス可能かどうかなどのセキュリティ リスクに基づいて、リソースを分類できます。データアクセス監査ログはサービスごとに有効になりますが、ログフィルタによって特定のリソースやリソースタイプを除外できます。

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

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

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

階層 サービス データアクセス監査ログのタイプ MITRE ATT&CK の戦術
認証と承認サービス IAM
Identity-Aware Proxy(IAP)1
Cloud KMS
Secret Manager
Resource Manager
ADMIN_READ
DATA_READ
発見
ID 情報へのアクセス
特権の昇格
ストレージ サービス BigQuery(デフォルトで有効)
Cloud Storage1、2
DATA_READ
DATA_WRITE
コレクション
浸透
インフラストラクチャ サービス Compute Engine
組織のポリシー
ADMIN_READ 発見

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

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

構成例では、基になるデータ、メタデータ、または構成に基づいて、サービスがどのように機密性の階層にグループ化されるかに注目します。これらの階層では、次の粒度のデータアクセス監査ロギングをおすすめします。

  • 認証と承認サービス: この階層のサービスでは、すべてのデータアクセス オペレーションを監査することをおすすめします。このレベルの監査は、機密鍵、シークレット、IAM ポリシーへのアクセスのモニタリングに役立ちます。このアクセスをモニタリングすると、発見ID 情報へのアクセス特権の昇格などの MITRE ATT&CK の戦術を検出できる場合があります。
  • ストレージ サービス: この階層のサービスでは、ユーザー提供データに関連するデータアクセス オペレーションを監査することをおすすめします。このレベルの監査は、貴重なデータやセンシティブ データへのアクセスをモニタリングするのに役立ちます。このアクセスをモニタリングすると、コレクション浸透などの MITRE ATT&CK の戦術を検出できる場合があります。
  • インフラストラクチャ サービス: この階層のサービスでは、メタデータや構成情報を含むデータアクセス オペレーションを監査することをおすすめします。このレベルの監査は、インフラストラクチャ構成のスキャンをモニタリングするのに役立ちます。このアクセスをモニタリングすると、ワークロードに対する発見などの MITRE ATT&CK の戦術を検出できる場合があります。

ログを転送する

ログを特定して有効にしたら、その次のステップでは、ログを単一の宛先に転送します。転送先、パス、複雑さは、次の図に示すように、使用する分析ツールによって異なります。

ログの転送方法: BigQuery とログ分析への転送にはログシンクを使用し、サードパーティの SIEM への転送にはログシンクと Pub/Sub を使用します。また、Google Security Operations への転送には直接取り込みを使用します。

この図では、次の転送オプションが示されています。

  • ログ分析を使用する場合は、Google Cloud 組織全体のログを単一の Cloud Logging バケットに集約するための集約シンクが必要です。

  • BigQuery を使用する場合は、Google Cloud 組織全体のログを単一の BigQuery データセットに集約するための集約シンクが必要です。

  • Google Security Operations を使用し、この事前定義されたログのサブセットがセキュリティ分析のニーズを満たす場合は、組み込みの Google Security Operations の取り込み機能を使用して、これらのログを Google Security Operations アカウントに自動的に集約できます。この事前定義されたログセットは、ログスコープ ツールの [Exportable directly to Google Security Operations] 列を確認して表示することもできます。これらの事前定義されたログのエクスポートの詳細については、Google Cloud ログを Google Security Operations に取り込むをご覧ください。

  • BigQuery またはサードパーティの SIEM を使用している場合、または拡張されたログセットを Google Security Operations にエクスポートする場合は、図で示すとおり、ログの有効化と分析の間にステップを追加する必要があります。この追加のステップでは、選択したログを適切に転送する集約シンクを構成します。BigQuery を使用している場合、このシンクはログを BigQuery に転送するためだけに必要となります。サードパーティの SIEM を使用している場合は、分析ツールに pull する前に、シンクで選択したログを Pub/Sub または Cloud Storage に集約させる必要があります。