GWS CAA自動遮断：Admin SDKで脅威応答を設計する

Google WorkspaceのContext-Aware Access (CAA) は、ユーザーの状況に応じてアクセスを制御できる強力なセキュリティ機能です。しかし、脅威が検知された際にCAAポリシーを動的に変更してアクセスを即座に遮断する仕組みは、標準機能では提供されていません。

この記事を読んだほうが良い人

Google Workspace環境でContext-Aware Access (CAA) を設定済みの情シス担当者
セキュリティアラートを受けてもCAAポリシーの変更が手動になり、タイムラグが生じることに課題を感じている方
インシデント発生時の「検知後の自動応答」フローを整備したいと考えている方
Google Workspace Admin SDKとGoogle Apps Script (GAS) を活用したセキュリティ自動化に興味がある方

Google Workspaceにおける脅威対応の現状と課題

Google Workspaceのセキュリティ機能は年々強化されており、アラートセンターやセキュリティ調査ツールなどで脅威の「検知 (Detection)」能力は向上しています。また、Context-Aware Access (CAA) を導入することで、ユーザーのデバイス状況やIPアドレス、地域などに基づいてアクセスを許可・拒否する「予防 (Prevention)」も可能です。

しかし、一度設定したCAAポリシーは静的であり、新しい脅威が検知された際に動的にポリシーを変更してアクセスを「即座に遮断する (Response)」仕組みは、標準では提供されていません。例えば、以下のような課題が考えられます。

手動対応のタイムラグ: ユーザーアカウントの侵害や不審なアクティビティがアラートセンターで検知されても、それを受けてCAAポリシーを更新したり、ユーザーを特定のグループから外したりする作業は手動になりがちです。この手動介入の間に、攻撃者に猶予を与えてしまうリスクがあります。
インシデント対応の遅延: 深夜や休日など、担当者がすぐに反応できない時間帯にインシデントが発生した場合、対応が翌営業日まで遅れることもあり得ます。

既存のCAA記事がポリシーの設定方法や設計パターン、あるいは監査ログとSIEM連携による「検知」に焦点を当てているのに対し、本記事では「検知後の自動応答」に焦点を当て、このタイムラグを解消する設計パターンを提案します。

手動対応と自動応答のタイムライン比較

脅威が検知されてからアクセスが遮断されるまでのタイムラインを比較してみましょう。

手動対応のタイムライン 1. 脅威検知: Google Workspaceアラートセンターや外部SIEMで不審なアクティビティを検知。 2. アラート通知: 担当者にメールやチャットで通知。 3. 担当者確認: 担当者がアラート内容を確認し、インシデントと判断。 4. 対応策検討: アクセス遮断が必要と判断し、CAAポリシー変更やグループメンバーシップ変更を検討。 5. 手動操作: 管理コンソールでCAAポリシーを更新するか、ユーザーをアクセス拒否対象グループから手動で削除。 6. アクセス遮断: 変更が適用され、対象ユーザーのアクセスが遮断される。

このプロセスでは、担当者の認知から操作までの時間がボトルネックとなり、数十分から数時間のタイムラグが発生する可能性があります。

自動応答のタイムライン 1. 脅威検知: Google Workspaceアラートセンターや外部SIEMで不審なアクティビティを検知。 2. 自動通知/トリガー: 検知システムがWebHookなどを通じてGoogle Apps Script (GAS) を自動実行。 3. GAS実行: GASがGoogle Workspace Admin SDKのDirectory APIを呼び出し、対象ユーザーをグループから削除。 4. アクセス遮断: グループメンバーシップ変更がCAAポリシーに反映され、対象ユーザーのアクセスが遮断される。

自動応答では、担当者の手動介入が不要になるため、検知から遮断までの時間を大幅に短縮できます。これにより、攻撃者に与える猶予を最小限に抑え、被害拡大のリスクを低減することが可能です。

Admin SDKを活用したCAA自動遮断のアーキテクチャ設計

Google WorkspaceのContext-Aware Access (CAA) は、アクセスを許可する条件として「ユーザーが特定のセキュリティグループに所属していること」を設定できます。この特性を利用し、脅威を検知した際にGoogle Apps Script (GAS) とAdmin SDK (Directory API) を用いて、対象ユーザーをこのセキュリティグループから自動的に削除することで、CAAによるアクセスを動的に遮断するアーキテクチャを設計できます。

フローの概要 1. 脅威の検知: Google Workspaceのアラートセンターや、Google Security Operations（旧 Chronicle Security Operations、2024年4月に改称）のような外部のSIEM (Security Information and Event Management) ツールが、不審なユーザーアクティビティや侵害されたアカウントを検知します。 2. GASのトリガー: 検知システムは、設定された条件に基づいてGoogle Apps Script (GAS) のWebHookまたは特定の関数を呼び出します。 * アラートセンター側のネイティブ通知メカニズムは Cloud Pub/Sub のみが公式に提供されているため、Pub/Sub のメッセージを Cloud Functions などで受けて GAS の doPost を叩く構成にします。一方、SIEM 側（Google Security Operations / Splunk / Datadog 等）であれば、SIEM の outbound webhook 機能から GAS の doPost URL に直接送る構成が取れます。アラートセンターから GAS の WebHook を直接叩く UI は提供されていないため、必ず Pub/Sub を経由する必要があります。 3. Admin SDK (Directory API) の実行: GASは、Google Workspace Admin SDKのDirectory APIを利用して、アクセスを遮断したいユーザーを、CAAポリシーでアクセス許可条件として設定されているセキュリティグループから削除します。 * 例えば、「gws-allow-access@example.com」というグループに所属しているユーザーのみが特定のアプリケーションにアクセスできるCAAポリシーを設定している場合、侵害されたユーザーをこのグループから削除します。 4. CAAによるアクセス遮断: グループメンバーシップの変更が反映されると、対象ユーザーはCAAポリシーで設定されたアクセス許可条件を満たさなくなり、関連リソースへのアクセスが拒否されます。

このアーキテクチャでは、脅威検知と同時にプログラムによる自動応答が可能となり、手動介入によるタイムラグを排除できます。

実践：GASとAdmin SDKによるグループメンバーシップ制御

ここでは、Google Apps Script (GAS) を使用して、Admin SDKのDirectory API経由でユーザーをグループから削除するコード断片を紹介します。

前提条件:

Google Workspaceの管理者アカウント。
GASプロジェクトでAdmin SDK Directory APIを有効化。
1. GASプロジェクトを開く。
2. 左サイドバーの「サービス」アイコン（+ の隣）をクリック。
3. 「Admin SDK」を検索し、「Admin SDK」を選択して「追加」をクリック。
GASプロジェクトに適切なOAuthスコープが付与されていること。グループメンバーシップの読み取り・追加・削除には、最小権限の https://www.googleapis.com/auth/admin.directory.group.member スコープで十分です（グループ自体の作成・削除を扱う admin.directory.group まで広げる必要はありません）。初めて実行する際に認証プロンプトが表示されます。

/**
 * 指定されたユーザーを特定のグループから削除する関数
 * @param {string} userEmail 削除するユーザーのメールアドレス
 * @param {string} groupEmail ユーザーを削除するグループのメールアドレス
 */
function removeUserFromGroup(userEmail, groupEmail) {
  try {
    // メンバーシップIDを取得 (ユーザーがグループに存在しない場合はエラーになる)
    const member = AdminDirectory.Members.get(groupEmail, userEmail);

    // メンバーが存在すれば削除
    if (member) {
      AdminDirectory.Members.remove(groupEmail, userEmail);
      console.log(`ユーザー ${userEmail} をグループ ${groupEmail} から削除しました。`);
    } else {
      console.log(`ユーザー ${userEmail} はグループ ${groupEmail} に存在しません。`);
    }
  } catch (e) {
    if (e.message.includes("Resource Not Found")) {
      console.log(`ユーザー ${userEmail} はグループ ${groupEmail} に存在しませんでした。`);
    } else {
      console.error(`グループからのユーザー削除中にエラーが発生しました: ${e.message}`);
    }
  }
}

// 実行例:
// const targetUser = "compromised-user@example.com"; // 侵害された可能性のあるユーザー
// const securityGroup = "gws-allow-access@example.com"; // CAAポリシーで利用しているセキュリティグループ
// removeUserFromGroup(targetUser, securityGroup);

このremoveUserFromGroup関数を、脅威検知システムからのトリガー（例えば、特定のシートへのデータ書き込み、WebHook受信など）に応じて呼び出すことで、ユーザーを自動的にグループから外し、CAAによるアクセス制御を即座に適用できます。

技術的制約と考慮事項

この自動遮断アーキテクチャを導入する際には、いくつかの技術的制約と考慮事項があります。

CAAセッション評価のタイミング（アプリ種別で挙動が違う）

Context-Aware Access (CAA) のポリシー評価タイミングは、アクセス先のアプリ種別によって挙動が異なります。この差を理解せずに「グループから外せば即遮断される」と前提を置くと、想定通りに遮断できないケースが出ます。

コアサービス (Gmail / Drive / Calendar / Meet / Chat など): アクセス許可後も継続的に再評価されます (continuous evaluation)。GASでユーザーを許可グループから削除した場合、次の評価サイクルで条件不一致と判定され、比較的短時間でアクセスが遮断されます。
SAML 連携アプリ（外部 SaaS など）: 評価タイミングはサインイン時のみです。既にサインイン済みのセッションは、ユーザーが明示的にサインアウトしてサインインし直すか、Google 側のセッション期間ポリシーでセッションが切れて再認証が発生するまで、アクセスが継続します。
グループメンバーシップ伝播の遅延: Admin SDK でグループからユーザーを削除しても、メンバーシップ変更がアクセス制御層に伝播するまで最大で 24 時間程度かかる場合があると Google は案内しています（通常はもっと早く反映されます）。コアサービス側で継続評価が走っていても、メンバーシップ伝播の遅延分はラグが乗ります。

設計上の意味合いは次のとおりです。

コアサービスを守る用途であれば、本記事のアーキテクチャはおおむね期待通りに動きます。ただし「秒単位の即時遮断」ではなく「分〜時間オーダーで反映される」設計と理解する必要があります。
SAML アプリ側のセッション切断まで含めて即時遮断したい場合は、ユーザー側のセッションを強制終了する操作（管理コンソールでのサインアウト / セッションリセット）を併用する設計を検討します。グループから外すだけでは、サインアウトするまでサインイン済みセッションが活き続けます。
CAA のセッション期間ポリシーは管理コンソールから短縮設定が可能です。SAML アプリの再評価頻度を上げたい場合は、この値を業務上許容できる範囲で短く調整します。

このため、本アーキテクチャを「リアルタイム遮断」として扱うのではなく、「アプリ種別に応じた遮断の上限時間を理解した上で、手動運用よりも大幅に短いラグで遮断するためのもの」と位置づけて設計してください。

Google Workspaceネイティブでの脅威インテリジェンス連携の限界

本記事で解説した方法は、Admin SDKを活用したカスタム連携であり、Google Workspaceが外部の脅威インテリジェンスフィードと直接ネイティブ連携してCAAポリシーを動的に変更する機能ではありません。そのため、以下のような限界があります。

複雑な条件判断: 脅威の深刻度や種類に応じた複雑なCAAポリシーの動的変更は、GASスクリプト側でロジックを組む必要があります。
誤検知のリスク: 自動遮断は強力な機能であるため、誤検知が発生した場合の影響も大きくなります。誤って正規のユーザーのアクセスを遮断しないよう、検知ロジックの精度と、ロールバック（グループへの復帰）手順を確立することが重要です。

設計上の注意点

ロールバック手順の確立: 自動遮断が誤って発動した場合に備え、迅速にユーザーをグループに戻せる手動または自動のロールバック手順を準備しておく必要があります。
ログと監視: GASの実行ログやAdmin SDKの監査ログ、CAAの監査ログを適切に監視し、自動応答が意図通りに機能しているか、または異常が発生していないかを確認できる仕組みを構築します。
権限の最小化: GASプロジェクトに付与するAdmin SDKの権限は、必要最小限に限定します。本記事のユースケース（グループメンバーシップの読み取りと削除）であれば、admin.directory.group.member スコープのみで足り、グループ自体の作成・削除を含む admin.directory.group まで広げる必要はありません。スコープを絞ることで、GASプロジェクトが侵害された場合の被害範囲も狭められます。

これらの制約と考慮事項を理解した上で設計することで、より堅牢で実用的な自動応答システムを構築できます。

まとめ：脅威応答の自動化でセキュリティを強化する

Google Workspace環境におけるセキュリティインシデント対応において、脅威検知後の「自動応答」は、被害を最小限に抑える上で非常に重要です。本記事では、Context-Aware Access (CAA) のグループベースのアクセス制御と、Google Apps Script (GAS) およびAdmin SDK (Directory API) を組み合わせることで、脅威検知後にユーザーアクセスを自動的に遮断するアーキテクチャを解説しました。

この設計パターンにより、手動対応に伴うタイムラグを大幅に削減し、インシデント発生時の対応速度を向上させることが可能です。ただし、CAAのセッション評価のタイミングや、誤検知時の影響など、技術的な制約と考慮事項を十分に理解し、堅牢な運用体制を構築することが成功の鍵となります。

セキュリティ運用を強化し、より迅速な脅威応答を実現するために、この自動遮断の設計パターンをぜひ検討してください。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。

CONTACT

御社の IT 部門、ここにあります。

「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。

無料相談を予約する → サービス詳細を見る

一社ずつ、一から。