監査ログを利用したGCPにおける疑わしい活動の検出

By 清水 孝郎 - MARCH 30, 2021

SHARE:

本文の内容は、2021年3月30日にAlejandro Villanuevaが投稿したブログ(https://sysdig.com/blog/suspicious-activity-gcp-audit-logs/)を元に日本語に翻訳・再構成した内容となっております。

GCPの監査ログは、クラウドインフラストラクチャーで発生しているすべてのことを追跡する強力なツールです。それらを分析することで、脅威を検知し、対応することができます。

最新のクラウドアプリケーションは、仮想マシン、コンテナ、バイナリー、データだけではありません。クラウドに移行したことで、アプリケーションの開発が加速し、運用効率が向上しました。しかし、クラウドではセキュリティを必要とする新しい資産も使い始めています。

クラウドプロバイダーの責任共有モデルでは、これらのクラウド資産はプロバイダーによって安全に管理されていますが、その責任の一部はクラウドの顧客であるあなたにもあります。お客様のクラウドアカウントは、すべての情報サービスへのメインドアとなっています。それは、セキュリティを確保する上で最も重要なものであり、サイバーセキュリティにおける攻撃対象として最も魅力があるものです。

GCP監査ログの仕組みと、クラウド脅威検知を実装するための効率的な処理方法をご紹介します。

クラウド脅威検知は安全なインフラの鍵

クラウドプロバイダーは監査ログを提供しています。これは、クラウドアカウントで発生しているすべての出来事を詳細に示す連続したイベントの流れです。これらのログには、クラウドアカウントで実行されたコマンドごとに1つのイベントが含まれています。

これには、アセットの作成、変更、削除を行う管理コマンドだけでなく、アセットのメタデータやデータアクセスイベントの読み取りコマンドも含まれます。

これらの監査ログを利用し、セキュリティポリシーに照らし合わせて検証することで、クラウドの脅威を検知することができます。このようにして、設定ミスや脆弱性、個人情報の漏洩などをいち早く検知し、情報を提供することができます。

検知したい脅威の種類

攻撃者がお客様のインフラにアクセスした場合、どのような手順を踏むかを考えてみてください。

データアクセスログを無効にしたり、監視アラートを削除したりして、バレないようにするでしょう。また、サービスアカウントに追加のキーを作成し、アクセスを継続させることも考えられます。また、インフラを調査する際には、普段使われていない領域でコマンドを実行することもあるでしょう。

これらの手順はすべて、監査ログに認識可能な痕跡を残します。

悪意のあるアクターがクラウド上で安全なポジションを確保すると、被害を及ぼし始める可能性があります。例えば、彼らはストレージバケットのACLやIAMポリシーを変更することができます。これにより、お客様のファイルが一般にアクセス可能となり、データの流出につながります。

しかし、悪意のあるアクターだけに気を配るべきではありません。

開発者の一人が、ランタイムのバージョンが古いCGP Cloud Functionを作成してしまうことがあります。このランタイムには、既知の脆弱性が含まれている可能性がありますが、最新のバージョンではすでに修正されています。これらの脆弱性は、攻撃者が侵入口として悪用し、横方向への移動に利用することができます。

クラウド環境では、このような設定ミスにフラグを立てるための継続的なチェックが必要です。

クラウド脅威検知とCWPPおよびCSPMの比較

クラウド脅威検知がグローバルなクラウドインフラを対象としているのに対し、CWPP（Compute Workload Protection Platform）カテゴリは、コンピュート・ワークロードで発生するランタイムの脅威を対象としています。どちらもイベントを分析して脅威を検出しますが、そのレベルは異なります。

一方、CSPM（Cloud Security Posture Management）は、まったく異なるアプローチです。CSPMカテゴリーは、”私のクラウドアカウントは今どのくらい安全か？”という質問に答えるものです。そのために、定期的にクラウドアカウントの現在の状態を分析することに重点を置いています。このため、CSPMはコンプライアンスに関連しており、通常、CIS（Center for Internet Security）やクラウドプロバイダー、その他のセキュリティ基準が公表しているような、さまざまなタイプのベンチマークに依存しています。

CSPMのように静的な構成全体を分析すると、クラウドアカウントの全体像を把握できるというメリットがありますが、継続的に実行するにはコストがかかります。一方、クラウド脅威検知では、資産が未承認の状態に変化したことを容易に検知することができます。

このようなことを考えると、どれを導入すべきでしょうか？

いや、全部です。

CSPMは、クラウドインフラのセキュリティ強化が必要なポイントを明らかにし、CWPPは、アプリケーションで起きている怪しい動きにフラグを立てます。そして、クラウド脅威検知によってクラウドインフラでの疑わしい動きに対応することができます。

GCPにおける脅威検知の実装：クラウド監査ログ

クラウド脅威検知を実現するGoogle Cloud Platform（GCP）内のサービスが「Cloud Audit Logs」です。

4つの監査ログ

Cloud Audit Logsの中には、4種類のログがあります。

  • リソースの構成やメタデータを変更する行為は、Admin Activity監査ログに痕跡を残します。
  • Googleがリソースの構成を変更するアクションは、システムイベント監査ログにトレースを残します。
  • リソースの構成やメタデータを読み取るアクションや、データを作成、変更、または読み取るアクションは、データアクセス監査ログに痕跡を残します。
  • セキュリティポリシー違反の結果、Google Cloud Service によって拒否されたアクションは、Policy Denied 監査ログに痕跡を残します。

IAM（Identity and Access Management）ポリシーが allAuthenticatedUsers または allUsers であるパブリックリソースは、プライバシーの観点からこれらのログにイベントを残さないことに注意してください。

Admin Activity監査ログとSystem Event監査ログは常に有効です。ただし、データアクセス監査ログは、非常に速く成長する可能性があるため、デフォルトでは無効になっています。Policy Denied監査ログは、デフォルトでは有効ですが、無効にすることもできます。

監査イベントのイメージ

これら4つの監査ログはすべてJSON形式で保存され、いくつかの重要な構造を共有しています。すべての監査ログには、以下のフィールドで構成されるprotoPayloadキーが含まれています。

  • authenticationInfo
  • authorizationInfo
  • serviceName
  • methodName
  • resourceName
  • request
  • requestMetadata
  • response
  • @type

ペイロードの外側には、エントリーのタイムスタンプ、影響を受けたリソース、イベントの深刻度など、いくつかのフィールドがあります。

いずれの場合も、@type には type.googleapis.com/google.cloud.audit.AuditLog という文字列が含まれます。

以下は、Admin Activity 監査ログのエントリーの例です。

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "status": {},
    "authenticationInfo": {
      "principalEmail": "[email protected]",
      "principalSubject": "user:[email protected]"
    },
    "requestMetadata": {},
    "serviceName": "iam.googleapis.com",
    "methodName": "google.iam.admin.v1.CreateServiceAccountKey",
    "authorizationInfo": [
      {
        "granted": true,
        "resource": "projects/-/serviceAccounts/123456789012345678901",
        "permission": "iam.serviceAccountKeys.create",
        "resourceAttributes": {}
      }
    ],
    "resourceName": "projects/-/serviceAccounts/123456789012345678901",
    "request": {
      "@type": "type.googleapis.com/google.iam.admin.v1.CreateServiceAccountKeyRequest",
      "name": "projects/-/serviceAccounts/[email protected]",
      "private_key_type": 2
    },
    "response": {},
  "insertId": "m8ab679xmpg5",
  "resource": {
    "type": "service_account",
    "labels": {}
  },
  "timestamp": "2021-03-17T17:33:44.852270Z",
  "severity": "NOTICE",
  "logName": "projects/sample-project/logs/cloudaudit.googleapis.com%2Factivity",
  "receiveTimestamp": "2021-03-17T17:33:49.462759141Z"
}

GCP監査ログの処理

クラウド脅威検知の最初の部分は、これらすべての監査イベントを生成することです。第2の部分は、それらをセキュリティポリシーに照らし合わせて検証することです。

セキュリティツールのような他のサービスは、Pub/Subトピックを介してこれらのイベントを消費できます。

まず、監査ログをフィルタリングして、選択したイベントをPub/Subトピックに転送するシンクに送ります。このシンクは、イベントをPub/Subトピックに転送します。セキュリティツールのエンドポイントがイベントを処理できるように、このトピックをサブスクライブする必要があります。

これらのシンクは、GCPがログを生成した後、ログが改ざんされないように、ログを暗号化し、検証します。

Sysdig Secure for cloudによるGCPのランタイム検知機能の実装方法

Sysdig Secure for cloudは、Google Cloud Platformの監査ログを取り込み、Falcoルールで定義されたセキュリティポリシーに照らして監査イベントを処理します。

専用のインジェスターがクラウドの監査ログをフィードし、GCPイベントをエバリュエーターに転送します。

豊富なカスタムFalcoルールが用意されたエバリュエーターは、Sysdig Secureインターフェース、GCP Trace、またはGCP Security Command Centerでレビューできるセキュリティイベントを生成します。

すぐに使えるFalcoルールをコンプライアンス管理にマッピング

Falcoルール言語は、クラウドにおける不審な活動を定義するための仕組みとしてデファクトスタンダードとなっており、その柔軟性により、お客様の運用ニーズに合わせてきめ細かくカスタマイズすることができます。

Sysdig Secure for cloudにあらかじめ同梱されているFalcoルールを使えば、すぐに使い始めることができますが、カスタマイズしたり、このライブラリに新しいルールを追加して、クラウド上のあらゆるアクティビティを検出することができます。

同梱されているGCPクラウド監査ログのルールは、MITRE ATT&CKにあるようなコンプライアンス・コントロールにマッピングされており、以下のようなイベントを検出することができます。

Sysdig Secure for Cloudには、MITRE ATT&CK®に加え、NIST 800-53、PCI DSS、SOC 2、CIS AWS、AWS Foundational Security Best Practicesなどのセキュリティ標準やベンチマークに対応した、豊富なFalcoルールがバンドルされています。

クラウド監査ログによる設定変更の検知

Cloud Audit LogsとSysdig Secure for cloudを使って、GCPの脅威を検知した例を見てみましょう。

前に紹介したAdmin Activityの監査ログイベントを見てみましょう。

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "status": {},
    "authenticationInfo": {
      "principalEmail": "[email protected]",
      "principalSubject": "user:[email protected]"
    },
    "requestMetadata": {},
    "serviceName": "iam.googleapis.com",
    "methodName": "google.iam.admin.v1.CreateServiceAccountKey",
    "authorizationInfo": [
      {
        "granted": true,
        "resource": "projects/-/serviceAccounts/123456789012345678901",
        "permission": "iam.serviceAccountKeys.create",
        "resourceAttributes": {}
      }
    ],
    "resourceName": "projects/-/serviceAccounts/123456789012345678901",
    "request": {
      "@type": "type.googleapis.com/google.iam.admin.v1.CreateServiceAccountKeyRequest",
      "name": "projects/-/serviceAccounts/[email protected]",
      "private_key_type": 2
    },
    "response": {},
  "insertId": "m8ab679xmpg5",
  "resource": {
    "type": "service_account",
    "labels": {}
  },
  "timestamp": "2021-03-17T17:33:44.852270Z",
  "severity": "NOTICE",
  "logName": "projects/sample-project/logs/cloudaudit.googleapis.com%2Factivity",
  "receiveTimestamp": "2021-03-17T17:33:49.462759141Z"
}

このイベントは、セキュリティ上の脅威となる可能性のあるサービスアカウントキーの作成を捕捉します。

このイベントのキーフィールドは以下の通りです：

  • serviceName: イベントを発生させたサービス（iam.googleapis.com）を含みます。
  • methodName: google.iam.admin.v1.CreateServiceAccountKey.という実際に呼び出されたメソッド。
  • principalEmail: イベントを起動したユーザーです。[email protected].
  • resourceName: 変更されるリソースは、projects/serviceAccounts/123456789012345678901です。 
  • status: リクエストのステータスを反映します。

リクエストのstatusフィールドが空でない場合は、エラーのために処理できなかったことを意味します。例えば、要求者がアクションを実行する権限を持っていなかった場合などです。我々は、このようなイベントには興味がないかもしれません。

先ほどの例に戻ってみましょう。このイベントは、projects/-serviceAccounts/123456789012345678901というリソースに関連するgoogle.iam.admin.v1.CreateServiceAccountKeyというサービスアカウントのキーが作成されたことを知らせています。

このセキュリティイベントを検出するためのFalcoのルールは次のようになります：

- rule: GCP Create Service Account Key
  desc: Detect creating an access key for a service account.
  condition:
    jevt.value[/serviceName]="iam.googleapis.com" and
    jevt.value[/methodName]="google.iam.admin.v1.CreateServiceAccountKey" and
    jevt.value[/status]=""
  output:
    An access key has been created for a service account
    (requesting user=%jevt.value[/authenticationInfo/principalEmail],
     service account=%jevt.value[/resourceName])
  priority: CRITICAL
  tags:
    - cloud
    - gcp
    - gcp_iam
    - cis_controls_16
    - mitre_T1550-use-alternate-authentication-material
  source: gcp_auditlog

これは、Sysdig Secure for cloudに含まれている、すぐに使えるルールの1つであることに着目してください。

jevt.valueとjsonpath形式のクエリーを使って、監査イベントの一部を参照することができます。

これをルールの条件部分で使用します：

condition:
    jevt.value[/serviceName]="iam.googleapis.com" and
    jevt.value[/methodName]="google.iam.admin.v1.CreateServiceAccountKey" and
    jevt.value[/status]=""

この条件は、IAM サービスに関連し、サービス アカウント キーを作成し、ステータスが空であるイベントをフィルタリングします。

同じことが、ルールの出力部分で使用する %jevt.value にも当てはまります：

output:
    An access key has been created for a service account
    (requesting user=%jevt.value[/authenticationInfo/principalEmail],
     service account=%jevt.value[/resourceName])

この出力は、このルールがセキュリティ・イベントを生成することになった場合に、コンテキスト情報を提供するために使用されます。その場合、この出力は、有効になっているすべての通知チャネルを通じて送信されます。たとえば、Sysdig Secureアカウントでセキュリティイベントを作成することができます。

クラウドイベント用のFalcoルールを作成する際の最後の注意点があります。

これは通常のFalcoルールであり、通常のFalco構文に従います。GCP Cloud Event Logsとの互換性は、そのイベントをJSONオブジェクトとして扱い、JSONPathを使ってイベント情報を参照することで実現しています。これにより、セキュリティエンジニアがすでに慣れ親しんでいるかもしれない2つの標準を混ぜ合わせ、カスタマイズして独自のルールを作ることが容易になります。

まとめ

クラウド脅威検知は、クラウドのセキュリティを確保するために非常に重要であり、CWPPやCSPMを補完するものです。

Google Cloud Platformに関して言えば、GCP Cloud Audit Logsは、インフラを監視し、セキュリティ上の問題が発生したときにそれを検知することができる素晴らしいツールです。

Sysdig Secure for cloudは、GCPアカウントで起きていることをすべて見ることができるので、真実の情報源として最適です。Sysdig Secureのすぐに使えるFalcoルールの包括的なセットは、セキュリティイベントの調査に必要なセットアップの労力、応答時間、およびリソースを最小限に抑えます。

Sysdig Secure for Cloudでは、悪者が侵入する前にクラウドの設定ミスに継続的にフラグを立てたり、流出した認証情報からの異常なログインなどの不審なアクティビティを検出することができます。これらはすべて1つのコンソールで実行されるため、クラウドのセキュリティ態勢を簡単に検証することができます。しかも、わずか数分で始められます。

Sysdig Free Tierでは、無料でクラウドのセキュリティを確保できます。

 

Sysdig Secure DevOps Platformは、コンテナ、Kubernetes、クラウドを自信を持って実行するために必要な可視性を提供します。オープンソース・スタック上に構築され、SaaS型で提供されており、根本的にシンプルな運用と拡張性を実現しています。

今すぐ無料トライアルをお申し込みください！