GCPの根深い課題:管理外ユーザー

では、最初のシナリオを最初から思い浮かべてみましょう。自社のメールはオンプレミスのExchangeサーバー、Microsoft 365、あるいはGoDaddyのメールサービスで運用されています。しかしここで、すべてのGoogleアカウントを一元管理し、ガバナンスと可視性を高めたいというニーズが出てきます。

あるいは、Google AnalyticsやYouTubeを会社アカウントで使いたい、SSOを導入して自社システムからユーザーを無効化・削除したらGoogle側でも同期して削除したい、といった要件もあるでしょう。そこで、自社ドメインを法人向けまたは管理対象のGoogleサービス、たとえばGoogle Workspace(旧G-Suite)やCloudIdentityに登録します。

ドメイン所有権を確認し、サブスクリプションを使い始めます。[email protected]を作成しようとしますが、システムは「このメールアドレスはすでに使用されています」と返してきます。最初のルールを思い出してください。メールアドレスは1つしか存在し得ないのです。

こうして、重複\ 競合する管理外アカウント問題が発生します。

では今度は、あなたが完全管理されたGoogle Workspaceアカウントの特権管理者だとしましょう。別の管理者が、Google WorkspaceサブスクリプションのGoogle管理コンソールで、[email protected](プライベートのメールアドレス)宛のメールをルーティングするデフォルトのルーティングルールや受信者アドレスマップを設定したとします。

その同じ管理者が、管理外アカウントの登録リンクにアクセスし、このメールアドレスで登録します。確認メールは会社の受信トレイに届くので、そこで認証できてしまいます。

こうして、理論上はGoogle Analyticsに登録したり、自社ドメインのYouTubeチャンネルを作成したり、GCPに不正アクセスしたりできる管理外のGoogleアカウントが生まれます。さらに厄介なのは、管理者であるあなたがこのユーザーの存在を把握できず、パスワードのリセットなどもできない点です。

現状、Googleは登録済みドメインのサフィックスを使った個人用・コンシューマー向けアカウントの作成を拒否していません。また、これを防止する管理コンソール機能も提供されていません。法人向けG-SuiteやGoogle Workspaceでこのオプションを無効にしたいとGoogleサポートに明示的に依頼しても、対応してもらえませんし、対応する予定もありません。

解決策

Google Workspace(G-Suite)アカウントをお持ちであれば、こちらのリンクからキャッチオールアドレスを作成できます。

キャッチオールアドレスは、誤ったメールアドレス宛に送られたメッセージを組織内の誰かが必ず受け取れるようにする仕組みで、受信者が内容を確認して対応を判断できます。これを使えば、管理外Googleアカウントの有効化を試みているユーザーを特定するのに役立ちます。ただし、管理者が「受信者アドレスマップ」などでルーティングルールを設定しているケースでは、キャッチオールでは対処できません。

そこで、どんなメールシステムを使っていても有効な回避策となるのが、確認プロセスとユーザーの間の通信を遮断してしまうことです。以下の条件すべて(ORではなくAND)を満たすコンテンツコンプライアンスルールを作成します。

受信方向 AND 本文が正規表現 `^[0–9]{6}$` に一致 AND 本文に「Verify this email is yours」を含む AND 件名に「Verify your email address」を含む AND 送信者ヘッダーに「[email protected]」を含む。

Googleがこのメタデータを変更しない限り、この方法で対処できます。なお、確認メールを完全に拒否するのはおすすめしません。キャッチオールアドレスと同じく宛先を管理者に変更し、内容を監視できるようにするか、条件には合致するもののこのシナリオに該当しないメールを誤って拒否しないようにしてください。

必要に応じて、さらに保護を強化することもできます。GCPでは、ドメインによる共有制限ポリシーを設定可能です。詳しくはこちらをご覧ください。

これにより、組織配下のプロジェクトで、ドメイン外のユーザーがIAMに追加できなくなります。ただし遡及的には適用されず、gmail.comユーザーをプロジェクトに追加することもできなくなる点には注意が必要です。Google WorkspaceまたはCloudIdentityアカウント内の管理対象ユーザーのみが、IAM権限を割り当てられるようになります。

管理外アカウントへの対処

まず、以下の操作を行うには、Google WorkspaceまたはCloudIdentityサブスクリプションで「特権管理者」ロールが必要です。管理コンソールにログインすると、「管理外ユーザー用の移行ツール」を開けるようになります。

または「ユーザー」セクションから「その他」をクリックしても開けます。

移行ツールを開くと、重複・競合している管理外ユーザーアカウントの一覧が表示されることがあります。それぞれのアカウントについて、管理外アカウントを自社へ移行するための招待を送信できます。招待を送った後、それを承諾するか拒否するかは、招待が実際に届いた本人の判断に委ねられます。

承諾されると、そのユーザー名が法人アカウントに割り当てられ、ユーザー一覧に表示されます。ユーザーは従来どおり認証して使い続けられますが、アカウントは自社のポリシー(2FA、利用可能なサービス、セッションタイムアウトなど)の対象になります。このユーザーがGCPプロジェクトへのアクセス権を持っていた場合、その権限は引き続き有効です。

応答がない、あるいは拒否された場合は、対応策を講じることができます。たとえば、これらのユーザー宛のメッセージを管理者のメールボックスに転送するルーティングルールを作成し、招待を再送して、ユーザーに代わって承諾する(あなたはドメインの所有者であり、MXレコードも会社のアカウントを指しています)といった方法です。

ただし、これは慎重に進め、対象の従業員を追跡することをおすすめします。アカウントの閉鎖を忘れていた、あるいはこの作業を知らなかった元従業員の可能性もあります。もちろん、そのままユーザーを作成してしまう方法もあります。

管理コンソールでユーザーを作成しようとすると、「移行招待」を送るか、それともそのまま作成するかを尋ねる画面が表示されます。そのまま作成を選ぶと、法人アカウントのサブスクリプション内に新しい管理対象アイデンティティが作成され、元のユーザー名は「username%[email protected]」のような形に変更されます。

ユーザーが自分のアカウントでGoogleサービスにアクセスしようとすると、「仕事用アカウント」(あなたが作成したアカウント)か「個人用アカウント」(「username%[email protected]」)のどちらを使うかを選ぶ画面が表示されます。

ユーザーのデータは元のアカウントに残り、Google AnalyticsやYouTubeチャンネルなどの関連データも個人アカウント側に残ります。新しく作成したユーザー名からこれらのデータにアクセスすることはできません。

注意したいのは、オンプレミスのMS-ADからGoogleへのGCDS(Google Cloud Directory Sync)、MS-AAD(Microsoft Azure Active Directory)からの自動プロビジョニング、Oktaなどのサードパーティーソリューションを利用する際にAPIが使われる点です。このAPIは個人用・コンシューマー向け・管理外アカウントの存在を考慮しません。ユーザーをただ自動的に作成するだけで、個人の管理外ユーザーは管理者に移行の確認を取ることなく、そのまま名前変更されてしまいます。