Google Workspace のドメイン全体の委任機能における重大リスクの調査

  • 522
    people reacted
  • 0
  • 4 min. read

By

Category: Cloud

Tags: , , , ,

A pictorial representation of a vulnerability such as that found in Google Workspace. A stylized cloud with a lock hanging from it surrounded by technical tools. The Palo Alto Networks and Unit 42 logos.

This post is also available in: English (英語)

概要

Unit 42 のリサーチャーは、Google Workspace (旧 G Suite) のドメイン全体の委任機能にセキュリティ リスクがあることを発見しました。私たちは、Google Cloud Platform (GCP) から Google Workspace ドメイン データにアクセスする、予期せぬ方法を明らかにしました。

必要な権限を持つ GCP の ID があれば、委任されたユーザーに対するアクセス トークンを生成できることがわかりました。クレデンシャル (認証情報) を盗んだ悪意のある内部関係者や外部にいる攻撃者は、このアクセス トークンを使って Google Workspace ユーザーになりすまし、これらのユーザーのデータに対する不正アクセスを許可したり、これらのユーザーに代わって操作を実行できます。

本稿では、Google Workspace のドメイン全体の委任機能のリスクに焦点を当てます。そのなかで私たちは、悪意のある者が潜在的にこれをどのような悪用をしうるかを探り、Google Workspace データのセキュリティへの影響を調査します。

Google Workspace や Google Cloud Platform GCP のようなクラウドベースサービスに依存する組織はますます増えていることから、それらのセキュリティ機能と脆弱性の細部を掘り下げることが重要になっています。私たちは GCP と Google Workspace 間のリンクについて説明し、GCP の権限モデルが Google Workspace のセキュリティにどのような影響を与えるかを検討します。

パロアルトネットワークスのお客様は、Cortex XDR と Prisma Cloud を通じて、本稿で解説した問題からの保護を受けています。

関連する Unit 42 のトピック API, Cloud

目次

ドメイン全体の委任悪用の概要
シミュレーション
Google Workspace
サービス アカウントとは
ドメイン全体の委任とは
ドメイン全体の委任はどのように機能するか
ドメイン全体の委任機能のリスクと影響を理解する
GCP と Google Workspace の両側から監査ログを使って潜在的悪用を特定する
緩和策
結論
開示のタイムライン

ドメイン全体の委任悪用の概要

シミュレーション

図 1 に示したのは可能性のある攻撃シナリオの 1 つです。ここでは、悪意のある内部関係者 (たとえば、ある GCP プロジェクト内で編集者権限をもつ開発者) が自身のアクセスを悪用しています。Google Workspace でドメイン全体の委任権限が付与されているサービス アカウントを悪用すれば、これを実行可能です。この内部関係者は、同じ GCP プロジェクト内のサービス アカウントに対し、アクセス トークンを生成する権限を持っています。

画像 1 は、攻撃シナリオを表す図です。青い四角形内のオブジェクトは組織を表しています。World Wide Web から見ると、Google Workspace クラウド内にはコンピューターのデフォルト サービス アカウントとサービス アカウントがあります。赤い矢印は、Gmail、Calendar、Google Drive を含む Google Workspace を指しています。特権管理者 (Super Admin) は、Admins、R&D、Finance を表す灰色の四角形にアクセスできます。黄色の矢印は、特権管理者からサービス アカウントを指し返しています。
図 1. 攻撃シナリオの 1 つ

ドメイン全体の委任権限を有効にすると、悪意のある内部関係者が Google Workspace ドメイン内のユーザーになりすまし、アクセス トークンを使って API リクエストを認証できます。適切なスコープと API アクセスを活用すれば、内部関係者は Google Workspace の機微データへのアクセスとその取得ができるため、ドメイン内に保存されているメールや文書、その他の機密情報に危険がおよびかねません。こうした行為は、ドメイン全体の委任機能の脅威を浮き彫りにするものです。

最悪のシナリオは、攻撃者が、ある Compute Engine のインスタンスにアタッチされた GCP のサービス アカウント トークンを取得した場合に発生します。 たとえば、デフォルトで編集者権限を持つ Compute Engine のデフォルト サービス アカウントなどです。そこから、攻撃者はドメイン全体の委任機能を悪用し、より大きな影響を与える可能性があります。同じプロジェクト内にドメイン全体の委任を持つサービス アカウントが存在する場合、攻撃者が委任されたサービス アカウントになりすまし、GCP からのラテラル ムーブにより、Google Workspace 環境へのアクセスを取得する可能性があります。

Google Workspace

Google Workspace と GCP 内で最近表面化したセキュリティ リスクの細部を掘り下げる前に、これらの強力なクラウドベース サービスについて基礎をしっかりおさえておくことが重要でしょう。

Google Workspace アプリは、クラウドベースのコラボレーション ツール コレクションです。さまざまな組織がこの Google Workspace を使い、以下にあげるようなツールで自社の生産性とコミュニケーションを強化しています。

  • 電子メール
  • カレンダー
  • ファイル ストレージと共有
  • チーム間のコミュニケーション
  • ワークフローの自動化
  • セキュリティ
  • 管理

Google Workspace では、ロールベースのアクセス制御 (role-based access control: RBAC) 機能を提供し、管理者がユーザーに特定のロールを割り当て、その責任とニーズに基づいて、事前定義された一連の権限を付与できるようにしています。これらのロールには次の内容が含まれます。

  • 特権管理者 (Super Admin)
  • グループ管理者 (Groups admin)
  • ユーザー管理者 (User Management Admin)

各ロールは特定の権限を持ち、組織の Google Workspace 環境のさまざまな側面を制御します。Google Workspace の特権管理者は、サービス アカウントにドメイン全体の委任権限を付与する機能など、上位の権限と広範なドメイン管理責任を持っています。これについては後ほど詳しく説明します。

Google Workspace 管理者は、アプリケーション固有の権限を定義し、共有と公開設定を制限することもできます。たとえば、ある管理者は、ユーザーがファイルを公に共有することを禁止したり、共有オプションを制限したりするポリシーを適用し、ファイルが許可された境界内に留まるようにできます。

GCP と Google Workspace 間のリンクの一般的使用例は、GCP でホストされているアプリケーションが Google Workspace サービスの 1 つとやり取りせねばならない場合です。こうしたサービスには以下のものが含まれます。

  • Gmail
  • Calendar
  • Drive
  • Docs

この統合により、アプリケーションは特定ユーザーのデータにアクセスして操作したり、ユーザーに代わってアクションを実行したり、Google Workspace のコラボレーション機能や生産性機能を活用したりできるようになります。

Google サービスとやり取りしたり、Google API にアクセスしたり、ユーザーのデータを処理したり、ユーザーに代わってアクションを実行したりするアプリケーションを作成するには、委任された GCP サービス アカウントが必要です。

サービス アカウントとは

サービス アカウントとは GCP の特別な種類のアカウントで、アプリケーションや仮想マシンなど、人間以外のエンティティを表します。これを使うことで Google API の認証や操作が可能になります。サービス アカウントは、個々のエンド ユーザーではなく、アプリケーションそのものに紐づけられています。

ユーザー アカウントとちがって、サービス アカウントは Google Workspace ドメインのメンバーではありません。サービス アカウントは Google Workspace 管理者が設定するドメイン ポリシーの対象ではなく、ドメイン全体の委任が許可されている場合にのみ、ユーザー データにアクセスできます。

ドメイン全体の委任とは

ドメイン全体の委任は Google Workspace の機能のひとつです。この機能により、GCP のサービス アカウントは、Google Workspace ユーザーのデータにアクセスし、特定ドメイン内でユーザーに代わって行動できるようになります。

ドメイン全体の委任機能を使うと、アプリケーションは、個々のユーザーに当該アプリケーションの認証・認可を要求しなくても、Google Workspace ドメイン内のユーザーに代わって行動できるようになりまます。

サービス アカウントとして機能するアプリケーションが、ドメイン内のユーザーに代わってデータにアクセスすることを許可できるのは、Google Workspace の特権管理者のみです。この許可は、サービス アカウントへの「ドメイン全体の権限の委任」と呼ばれます。

ドメイン全体の委任はどのように機能するか

ドメイン全体の委任機能を使うには、以下 (図 2 参照) の手順を踏む必要があります。

  1. ドメイン全体の委任の有効化: Google Workspace の特権管理者は、サービス アカウントに対するドメイン全体の委任と、そのアクセスに許可される一連の OAuth スコープを許可します。これらのスコープが、そのサービス アカウントがアクセスできる特定のサービスやアクションを詳細に示します。たとえば、スコープとして /auth/gmail.readonly だけが付与された場合、そのサービス アカウントはユーザーに代わって Gmail メッセージを読み取るアクセス権を持ちますが、Drive 内のファイルへのアクセスなど、べつの Workspace データにはアクセスできません。
  2. Google Workspace アクセス トークンのリクエスト: アプリケーションが適切なクレデンシャルを使い、リクエストを Google Workspace のトークン エンドポイントに送信します。このリクエストには、サービス アカウントのクライアント ID、クライアント シークレット、ユーザー データへのアクセスに必要なスコープを含めておきます。このリクエストが有効で、必要なドメイン全体の委任権限がそのサービス アカウントに付与されていれば、そのトークン エンドポイントはアクセス トークンで応答します。アプリケーションはこのアクセス トークンを使い、要求されたスコープの制限内でドメイン全体のユーザー データにアクセスできます。
  3. API アクセス: アプリケーションは API リクエストに認可ヘッダーとしてアクセス トークンを含めます。この認可ヘッダーが、サービス アカウントに代わる認証・認可の証拠として機能します。
画像 2 はドメイン全体の委任フロー図です。クラウド内には、Google Workspace、Cloud IAM、サービス アカウント、ユーザーがあります。手順 1. 黄色の矢印は、Google Workspace からサービス アカウントを指しています。ドメイン全体の委任を有効にしています。手順 2. 赤い矢印がサービス アカウントから特権管理者を指しています。Google Workspace のアクセス トークンをリクエストしています。手順 3. 黄色の矢印が特権管理者からサービス アカウントを指しています。API アクセスが付与されています。
図 2. ドメイン全体の委任フロー

ドメイン全体の委任が付与されると、Google Workspace のサービス アカウントはユーザー データにアクセスし、ユーザーに代わって行動し、Google API へのリクエストを認証できます。具体的に何ができるかや、どのデータにアクセスできるかは定義されたスコープしだいです。

ドメイン全体の委任機能のリスクと影響を理解する

ドメイン全体の委任が GCP サービス アカウントに付与されると、必要な権限を持つ GCP ID は、同じプロジェクト内にある委任されたサービス アカウントに対し、アクセス トークンを生成できるようになります。悪意のある内部関係者は、このアクセス トークンを使って Google Workspace ユーザーになりすまし、ユーザー データへの不正アクセスを許可したり、ユーザーに代わって操作を実行したりできるようになります。

このシナリオでは、ドメイン全体で委任される権限の感度と GCP プラットフォームで管理される権限モデルとの間に不一致が生じます。

Google Workspace の管理者ヘルプには、ドメイン全体の委任機能に関する注意事項が含まれており、この機能のもつ重大な能力についての概要を説明しています。Google は、「このため、ドメイン全体の委任を管理できるのは特権管理者のみであり、特権管理者はアプリによるアクセスが可能な各 API スコープを指定する必要があります。」と述べています。

Google は「(デフォルトの) サービス アカウントへの自動的なロール付与を使用しない」ことを勧める記事を提供しています。前述のケースの場合、この記事通りにしておけばデフォルトの Google Compute Engine サービス アカウントを作成できなかったでしょう。過剰な権限を減らすため、Google は GCP のロールの推奨事項に関するベスト プラクティスというドキュメントを用意し、そのなかで「Recommender API 」ツールについても言及しています。

GCP と Google Workspace の両側から監査ログを使って潜在的悪用を特定する

アクティビティの全体像を理解し、ドメイン全体の委任機能の潜在的な悪用を特定するには、GCP と Google Workspace の両プラットフォームの監査ログ分析が欠かせません。サービス アカウント キーの生成ログは GCP のログに記録され、Google キーの生成と API 呼び出しの実行ログは Google Workspace のログに記録されます。

図 3 は、GCP の監査ログ内でサービス アカウント キーの作成を検索している Cortex Web インターフェースの XQL クエリーです。

画像 3 は、サービス アカウント キー作成を検索しているようすを示したスクリーンショットです。コードは 3 行あります。dataset、filter、fields が含まれています。
図 3. サービス アカウント キーの作成を検索
画像 4 は、1 行のコードのスクリーンショットです。これは、Prisma Cloud での同等のクエリーです。緑色のチェックマークがクエリーの前に表示されています。
図 4. 同じクエリーを Prisma Cloud の RQL 構文で表したもの

図 5 は、サービス アカウントの許可ログを検索する XQL クエリーを示したものです。

画像 5 は、アクセス トークン リクエストを検索しているところを示したスクリーンショットです。コードは 3 行あります。dataset、filter、fields が含まれています。
図 5. Google Workspace のアクセス トークン リクエストを検索
画像 6 は、 1 行のコードのスクリーンショットです。これは、図 5 に示したクエリーと同等の内容を Prisma Cloud の RQL 構文で表したものです。緑色のチェックマークがクエリーの前に表示されています。
図 6. 同じクエリーを Prisma Cloud の RQL 構文で表したもの

図 7 は、このサービス アカウントにドメイン全体の委任アクセス許可を与えたユーザーと、それがいつ行われたかを確認しているところです。

画像 7 は、サービス アカウントのアクセス許可の付与について確認できるログを検索するようすを示したスクリーンショットです。dataset、filter、fieldsの 3 行のコードが含まれています。
図 7. あるサービス アカウントに対しドメイン全体の委任アクセスの許可が付与されたことを示すログを検索
画像 8 は、1 行のコードのスクリーンショットです。これは、図 7 に示したクエリーと同等の内容を Prisma Cloud の RQL 構文で表したものです。緑色のチェックマークがクエリーの前に表示されています。
図 8. 同じクエリーを Prisma Cloud の RQL 構文で表したもの

図 9 は、「ある Google Workspace 管理者が GCP サービス アカウントに対するドメイン全体の委任を有効にして機微なスコープへのアクセスを許可した (A Google Workspace admin has enabled domain-wide delegation to a GCP service account and granted him access to a sensitive scope)」というアラートが Cortex Web インターフェースでトリガーされたようすを示したものです。

画像 9 は、Cortex XDR のアラートのスクリーンショットです。この情報には、timestamp、user name、severity、alert source、action、category、alert name、description (タイムスタンプ、ユーザー名、深刻度、アラート ソース、アクション、カテゴリー、アラート名、説明) が含まれています。情報の一部は割愛してあります。
図 9. Cortex Web インターフェイスでドメイン全体の委任アラートを表示したところ

緩和策

私たちが特定したセキュリティ リスクは、「悪意のある内部関係者がドメイン全体の委任機能を悪用するために必要とする初期の権限」と「その権限が及ぼしうる影響」との間の不一致からくるものです。

ドメイン委任権限を持つサービス アカウントに対する最適なセキュリティ プラクティスは、それらのサービス アカウントを GCP 階層内でより上位のフォルダー内に配置することです。GCP の階層モデルでは、アクセス制御が階層的に行われます。

上位レベル (組織やフォルダーなど) に設定されたアクセス許可やポリシーは、下位レベルのフォルダーやプロジェクトに対し、自動的にはアクセスを許可しません。アクセス制御は下位の階層には継承されません。これはつまり、下位レベルのフォルダーやプロジェクトは、上位レベルのフォルダーまたはプロジェクトに対し、自動的なアクセスは持たないということです。

画像 10 は GCP の階層ツリーです。Organization (組織) の行の一番上にあるのは Company (会社) です。次の行の Folders (フォルダー) には、Dept (部門) と Shared Infrastructure (共有インフラ) が含まれています。これらのフォルダーが、Team (チーム)、 Product (製品) のフォルダーにつながっていきます。3 行目は Projects (プロジェクト)です。最後の行は Resources (リソース) です。
図 10. GCP リソースの階層ツリー

潜在的な悪意のある内部関係者の持つ権限が、図 10 に示した GCP 階層内の下位レベルのフォルダーやプロジェクトに対してのみであれば、この戦略をとることでセキュリティ侵害の対象領域を縮小できます。下位レベルの領域にあるエンティティにサービス アカウントのアクセス トークンを取得させないようにするには、委任されたサービス アカウントへのアクセス トークンを生成できるエンティティを、同一または上位レベルのフォルダーやプロジェクト内に限定します。これにより、ドメイン全体の委任での権限悪用と Google Workspace データへのアクセスを防げます。

結論

この問題について私たちは 2023 年 6 月からさまざまな窓口を通じて Google と協議してきました。この問題については Team Axon も特定しており、彼らも Google への報告を行っていました。

ドメイン全体の委任機能にはリスクと影響があります。アクセス許可の構成にあたってセキュリティ防御担当者はこのことを念頭に置かねばなりません。ドメイン全体の委任により付与されたスコープしだいでは、攻撃者はこの機能を使って Google Workspace ユーザーになりすまし、ユーザーに代わってアクションを実行し、データへの不正アクセスを取得する可能性があります。

攻撃者がこの機能を悪用するのに必要な初期権限と、そこから生じうる影響との間の不一致に着目することが重要です。最悪の場合、攻撃者や悪意のある内部関係者によって、ドメイン内に格納されている電子メール、ドキュメント、その他の機密情報など、Google Workspace の機微データが漏えいする可能性があります。

パロアルトネットワークスのお客様は、Cortex XDR と Prisma Cloud の両製品を通じ、本稿で解説した問題からの保護を受けています。

Cortex XDRの機能は、ドメイン全体の委任権限の付与や GCP サービス アカウント キーの作成など、さまざまな異常のあるアクティビティを識別・警告できます。Cortex XDR は、GCP や Google Workspace のエンティティの振る舞いを学習し、異常な振る舞いを検出できます。

Prisma Cloud CIEM は、以下を提供することで、リスクの高いアクセスや、過剰な特権を付与されたアクセスを緩和できます。

  • リスクの高い権限を可視化し、アラートを発報し、自動修復する
  • 最小特権のアクセス修復により未使用の権限を自動検出する

Prisma Cloud の Threat Detection 機能は、クラウドの内外からクレデンシャルが異常な使われかたをした場合など、さまざまな ID 関連の異常アクティビティに対してアラートを発報できます。

Prisma Cloud はまた、ランタイム オペレーションの監視を実行し、クラウド環境に関連付けられたコンポーネントにガバナンス、リスク、コンプライアンス (GRC) 要件を提供することもできます。

侵害の懸念があり弊社にインシデントレスポンスに関するご相談をなさりたい場合は、こちらのフォームからご連絡いただくか、下記の電話番号までお問い合わせください (ご相談は弊社製品のお客様には限定されません)。

  • 北米フリーダイヤル: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • 日本: (+81) 50-1790-0200

パロアルトネットワークスは、これらの調査結果を Cyber Threat Alliance (CTA: サイバー脅威アライアンス) のメンバーと共有しました。CTA のメンバーはこのインテリジェンスを使って、お客様に保護を迅速に提供し、悪意のあるサイバー攻撃者を体系的に阻害できます。詳細は Cyber Threat Alliance にてご確認ください｡

開示のタイムライン

  • 2023 年 6 月 27 日: パロアルトネットワークスがドメイン全体の委任のセキュリティ リスクに関する報告書を Google Workspace プロダクト チームに提出
  • 2023 年 7 月 10 日: Google Workspace 製品チームとパロアルトネットワークスのクラウド リサーチ グループとの間でセキュリティに関するディスカッションを実施
  • 2023 年 7 月 18 日: パロアルトネットワークスが本問題に関する報告書を Google Vulnerability Reward Program に提出
  • 2023 年 8 月 2 日: パロアルトネットワークスが Google Workspace 製品チームに不具合を報告し、必要があれば修正を実装するとの回答を得る
  • 2023 年 8 月: パロアルトネットワークスが Google にセキュリティ リスクについての公開意向を通知し修正または意見の機会を提供
  • 2023 年 11 月 8 日: パロアルトネットワークスがドメイン全体の委任のセキュリティ リスクに関する弊社記事について Google の意見を求める