BeyondCorp Enterpriseで外部パートナーのOAuth制御を設計する

Google Workspace（GWS）では、外部パートナーへの OAuth アクセス管理をどこまで情シスが制御できるかが、内部ユーザーと大きく異なる。この記事では、BeyondCorp Enterprise（現 Chrome Enterprise Premium）のゼロトラスト原則を外部パートナー管理に当てはめたとき、何を設計判断として持ち帰れるかを整理する。

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

• 業務委託・SIer・コンサルなど外部パートナーが GWS リソースに OAuth 経由でアクセスしている
• 契約終了後にアクセストークンが残存するリスクへの対処を後回しにしている
• 内部ユーザー向けの BeyondCorp/CAA（Context-Aware Access）設計は検討済みだが、外部パートナーの扱いが未定義
• 100 名規模の企業で情シスを担当しており、外部パートナーの権限棚卸しを体系化したい

外部パートナーのOAuth管理が内部ユーザーと根本的に違う点

内部ユーザーの場合、情シスは次の手段でアクセスを即座に制御できる。

• アカウントの停止・削除
• パスワードリセット（GWS の公式仕様では、パスワード変更時に特定製品向けの OAuth 2.0 トークンが自動失効する）
• MDM（モバイルデバイス管理）によるデバイス管理
• CAA による動的アクセス評価

外部パートナーに GWS ドメインのアカウントがない場合、これらの手段は機能しない。パートナーが個人または自社の Google アカウントを使って共有ドライブや OAuth 連携アプリ経由でアクセスしているとき、管理コンソールからそのアクセス状況を直接追跡することはできない。

退場後もトークンが生き続けるリスクが静かに積み上がるのは、この管理の非対称性が原因だ。100 名規模の企業では複数の外部パートナーが同時並行で関与するケースも多く、棚卸しの漏れが起きやすい。

BeyondCorp Enterprise の設計原則を外部パートナー管理に活かす

BeyondCorp Enterprise は 2024 年 4 月の Google Cloud Next で Chrome Enterprise Premium として統合・再編された。「VPN を廃止してゼロトラストで社内アプリにアクセスする」文脈で紹介されることが多いが、そのコアにある「ユーザーのコンテキストを常に評価し、アクセスを動的に判断する」という原則は外部パートナー管理にも応用できる。

BeyondCorp アクセスレベルの設計判断を外部パートナーに当てはめると、次の問いになる。

• 外部パートナーを自社のアイデンティティ境界（GWS ドメイン）の内側に取り込むか、外側に置いたまま制御するか
• GWS アカウントを付与して管理可能な状態にするか、OAuth 連携のみに留めるか

この判断は「利便性」だけで決めるのではなく、退場時の制御容易性を設計段階から折り込む必要がある。

内部ユーザーと外部パートナーの設計判断フロー

アクセス制御の観点から、外部パートナーを 2 パターンに分類して設計判断を整理する。

観点	内部ユーザー	外部パートナー（GWSアカウントあり）	外部パートナー（GWSアカウントなし）
アカウント停止・削除	◎ 即制御	◎ ゲストアカウントを停止	× 不可
パスワードリセット	◎ 特定製品向けOAuthトークン自動失効	◎ 同様に機能	× 不可（相手側が管理）
CAA 適用	◎ OU（組織単位）・グループ単位で適用可	○ Google グループ経由で適用可（対応エディション要）	× 基本的に不可
OAuth トークン棚卸し	◎ 管理コンソールで確認・取り消し可	◎ アカウント単位で確認・取り消し可	× 管理コンソールで追跡不可
退場時の無効化	◎ アカウント削除で概ね処理可	○ アカウント停止 + トークン手動取り消しで対応	△ 共有解除 + アプリ側での対応が必要

この表から得られる設計判断は明確だ。高機密プロジェクトに関わる外部パートナーには GWS ゲストアカウントを付与して「アカウントあり」の制御レーンに入れる。スポット業務だけの関係者は共有範囲を最小化しつつ、退場時の手順を事前に合意しておく。

なお、CAA（Context-Aware Access）を外部パートナーの Google グループに適用するには、Enterprise Standard 以上または Cloud Identity Premium などの対応エディションが必要になる。CAA の適用対象は GWS コアアプリ（Drive、Gmail、Calendar 等）および SAML/OIDC 認証を使うアプリであり、マーケットプレイスの個別アプリに直接 CAA を当てる UI は提供されていない点も設計上の前提として把握しておく。

GWS OAuth スコープの外部制御：棚卸しチェックリスト

外部パートナーに GWS アカウントを付与している場合、管理コンソールのセキュリティ設定から API の制御機能を使ってスコープを定期的に確認できる。以下を定期棚卸しの基準として活用する。

GWS 公式仕様では、アプリへのアクセス制御を Trusted（すべてのサービスへのアクセスを許可）、Limited（制限されていないサービスのみ）、Specific Google data（指定スコープのみ）、Blocked（アクセス不可）の 4 段階で管理できる。

月次で確認する項目

• [ ] 外部パートナー名義のアカウントに付与されているサードパーティアプリの一覧を確認する
• [ ] 各アプリのスコープ（読み取り専用・書き込み・管理者権限）が業務内容と整合しているか確認する
• [ ] Trusted（信頼済み）に設定されているアプリに外部パートナー用のものが含まれていないか確認する（Trusted はすべての GWS サービスへのアクセスを許可するため、外部パートナー向けアプリへの適用はリスクが高い）
• [ ] ドメイン全体の委任（Domain-wide delegation）が外部パートナー向けアプリに不必要に付与されていないか確認する

四半期ごとに確認する項目

• [ ] 退場済みパートナー担当者のアカウントが残っていないか名簿と突合する
• [ ] 前四半期以降にアクセス実績がゼロのアプリを特定し、Blocked 設定を検討する
• [ ] CAA ポリシーが外部パートナーのグループに適切に適用されているか確認する

GWS アカウントを持たない外部パートナーのトークン管理は、OAuth 連携先のアプリ側で行う必要がある。利用しているアプリのベンダーと「退場時にトークンを失効させる手順とその確認方法、および失効完了の通知をいつ・どのように受け取るか」を事前に取り決めておくことを勧める。

外部ユーザー GWS 権限棚卸し：退場時の無効化フロー

外部パートナーの退場手続きを標準化しておかないと、「おそらく大丈夫だろう」で終わるリスクが残る。以下の 5 ステップを退場フローとして組み込む。

Step 1：アカウント有無の確認

退場する担当者が GWS アカウント（ゲストアカウント含む）を持つかどうかを確認する。アカウントがあれば Step 2 へ進む。なければ Step 4 へスキップする。

Step 2：OAuth トークンの個別取り消し

管理コンソールのセキュリティ設定から、対象ユーザーに付与されているアプリのトークンを個別に取り消す。パスワードリセットで特定製品向けトークンは自動失効するが、すべてのトークンが対象とは限らないため、個別取り消しも併せて実施する。なお GWS 公式仕様では、トークン付与または取り消しから最大 48 時間後にアクセスアプリリストへ反映されるとされている。

Step 3：アカウントの停止・削除

トークン取り消し後、アカウントを停止または削除する。監査ログへのアクセスを一定期間保持する必要がある場合は、即時削除ではなく「停止」を経由するフローを設計する。

Step 4：共有設定・グループメンバーシップの解除

GWS アカウントを持たない外部パートナーについては、共有ドライブ・ファイル・Google グループから該当者を取り除く。プロジェクト管理者への依頼フローになることが多いため、情シス側から依頼の起点となる仕組みを設ける。

Step 5：退場ログの記録

処理内容・処理日・実施者を記録する。管理コンソールの監査ログ（OAuth log events）でトークン取り消しイベントを確認し、そのクエリ結果をエビデンスとして退場記録に添付する。

BeyondCorpの考え方を外部パートナー制御に落とし込む3つの判断軸

BeyondCorp の「常に検証、決して信頼しない」原則を外部パートナー制御に具体化すると、次の 3 点になる。

1. アイデンティティ境界を設計段階で決める

外部パートナーに GWS アカウントを付与することで、情シスが制御できるアイデンティティ境界の内側に入れられる。付与の基準（関与するプロジェクトの機密度・関与期間の長さ・アクセスするデータの範囲等）を明文化しておく。

2. 最小スコープの原則を OAuth 連携アプリに適用する

OAuth アプリに付与するスコープは「読み取り専用で十分なのに書き込み権限がある」ケースが実務では珍しくない。アプリのスコープ要求を確認し、過剰な権限を要求するアプリは Blocked にするか、Limited 設定で制限する。

3. 退場設計をオンボーディング時に合意する

アクセス権を付与するタイミングで、退場手順も同時に合意しておく。「誰が・いつ・どのアカウントとトークンを無効化するか」を業務引継ぎ書または契約書に含めておく。退場後に慌てて棚卸しをするより、退場フローを最初から設計しておくほうが情シスの対応負荷は低くなる。

まとめ

外部パートナーの OAuth 制御を「相手がいるから仕方ない」と先送りすると、契約終了後のアクセス残存リスクが静かに積み上がっていく。

BeyondCorp Enterprise / Chrome Enterprise Premium が示すゼロトラストの考え方は、外部パートナー管理では「GWS アカウントの付与有無という設計判断」と「OAuthスコープの月次棚卸し・退場フローの標準化」という形で実践できる。

技術的に完璧なゼロトラスト環境を構築することより、退場時に確実にアクセスを切れる仕組みを持つことが、100 名規模の情シスにとって現実的な第一歩だ。アカウント付与基準・スコープ棚卸しの頻度・退場フローの明文化、この 3 点を整備することから始めると、複数の外部パートナーが同時並行する環境でも制御を維持できる体制が整う。

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

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