このドキュメントでは、連携を一貫性をもって安全に設定するためのベスト プラクティスとガイダンスについて説明します。このガイダンスは、Google Cloud で Cloud Identity または Google Workspace を使用する場合のベスト プラクティスを基にしています。
Google Cloud、Google マーケティング プラットフォーム、Google 広告など、すべての Google サービスは、Google ログインを使用してユーザーを認証します。Cloud Identity または Google Workspace で、各従業員のユーザー アカウントを手動で作成して管理するのではなく、Active Directory や Azure Active Directory などの外部 ID プロバイダ（IdP）と Cloud Identity や Google Workspace を連携させることができます。連携の通常の設定では、次の手順を行います。
- 関連するユーザー アカウントを外部の信頼できるソースから Cloud Identity または Google Workspace に自動的にプロビジョニングする。
- ユーザーが外部 IdP を使用して、Google サービスに対して認証できるようにする。
ID のマッピング
Cloud Identity または Google Workspace で管理されるユーザー アカウントの ID は、メインのメールアドレスで定義されます。メインのメールアドレスは、Google アカウントのページに [Google アカウントのメールアドレス] として表示されます。メインのメールアドレスが有効とみなされるためには、Cloud Identity または Google Workspace アカウントに追加したいずれかのドメインを使用する必要があります。
メインのメールアドレスは次の目的にも使用されます。
- メインのメールアドレスは、ユーザーがログインするときに入力する必要があるユーザー名です。ユーザーは予備のメールアドレスやエイリアスを自分の Google ユーザー アカウントに追加できますが、これらのアドレスは ID とはみなされず、ログインには使用できません。
- 管理者がユーザーに通知を送信する必要がある場合（潜在的なセキュリティ リスクを通知する場合など）、その通知はメインのメールアドレスにのみ送信されます。
Google と外部 IdP 間のシングル サインオンと自動ユーザー プロビジョニングを設定するには、外部 IdP の ID を Cloud Identity または Google Workspace の対応する ID にマッピングする必要があります。以下のセクションでは、このマッピングを確立するためのベスト プラクティスについて説明します。
すべてのフェデレーション システムで同じ ID を使用する
マッピングを確立するために必要なことは、IdP が Google に提供する SAML アサーションが、既存の Cloud Identity または Google Workspace のメインのメールアドレスと一致する値の NameID 要求を含んでいることを確認することです。IdP は、既存のユーザーに適した NameID 要求を生成するために適用可能なマッピングまたはロジックを自由に使用できます。
多くの IdP は、ユーザーを識別するためにメールアドレス（より一般的には RFC 822 遵守の名前）を使用します。以下に例を示します。
- Active Directory の
userPrincipalName属性は、ユーザーを一意に識別する RFC 822 遵守の名前であり、Windows または Active Directory フェデレーション サービス（AD FS）へのログインに使用できます。 - Azure Active Directory は
UserPrincipalName属性を使用して、ユーザーを識別し、ログインを許可します。
外部 IdP が管理するユーザーがすでにメールアドレスを ID として使用している場合は、Cloud Identity または Google Workspace でのメインのメールアドレスと同じ ID を使用できます。フェデレーション システム間で同じユーザー ID を使用することには、いくつかのメリットがあります。
ユーザーが Google Cloud コンソール などの Google ツールにログインすると、まず Cloud Identity または Google Workspace ユーザーのメインのメールアドレスを入力するよう求められた後、外部 IdP にリダイレクトされます。IdP によっては、ユーザー名とパスワードの入力を求める別のログイン画面が、続いて表示される場合があります。
これらの手順において異なるメールアドレスを使用すると、一連のログイン画面でエンドユーザーが混乱する場合があります。一方、ユーザーがすべての手順で共通の ID を使用できる場合は、IdP 間での技術上の相違点は表面化せず、混乱を最小限に抑えることができます。
ユーザー ID をマッピングする必要がない場合は、より簡単に、Google Cloud の監査ログとオンプレミス システムのログとを関連付けることができます。
同様に、オンプレミスと Google Cloud にデプロイされたアプリケーションがユーザー ID を含むデータを交換する必要がある場合は、ユーザー ID をあえてマッピングする必要はありません。
Active Directory ユーザーや Azure AD ユーザーを Cloud Identity または Google Workspace にマッピングする方法については、Active Directory または Azure AD ガイドをご覧ください。
ID でルーティング可能なメールアドレスを使用する
Google Cloud では、ユーザーのメインのメールアドレスを使用して通知メールを配信します。これらの通知の例を次に示します。
予算アラート: 予算アラートを構成している場合、予算のしきい値を超えると、Google Cloud から課金管理者と課金ユーザーに通知が送信されます。
お支払いに関する通知: お支払い関連の通知やアラートは、該当する請求先アカウントに構成されているお支払いサービスのユーザーのメールアドレスに送信されます。
プロジェクトへの招待: プロジェクトの組織が関連付けられているアカウントとは異なる Cloud Identity または Google Workspace アカウントに属するユーザーにプロジェクト管理者のロールを割り当てる場合、そのユーザーに招待メールが送信されます。新しく付与したロールを有効にするには、ユーザーがメール メッセージ内のリンクをクリックして招待を承諾する必要があります。
サポートケースへの返信およびサポートからのその他の通知。
Google Workspace を使用しており、必要な DNS MX レコードを適切に構成している場合、メインのメールアドレスに送信されるすべての通知メールが、対応するユーザーの Gmail の受信トレイに配信されます。
Cloud Identity ユーザーの場合、Google Cloud は通知メールの配信も試みますが、メールは既存のメールシステムで処理される必要があります。Cloud Identity ユーザーが通知を見逃さないように、Cloud Identity ユーザーの既存のメールシステムで、メインのメールアドレスに送信されたメールが受け入れられ、正しいメールボックスにルーティングされるようにします。手順は次のとおりです。
Cloud Identity に追加されているすべてのドメインに、既存のメールシステムを指す DNS MX レコードがあることを確認します。
Cloud Identity ユーザーのメインのメールアドレスが、メールシステムの既存のメールボックスと一致することを確認します。Cloud Identity で使用されるメインのメールアドレスとユーザーのメールアドレスが一致しない場合は、既存のメールシステムでエイリアスを構成し、各メインのメールアドレスに送信されるメールが正しいメールボックスにルーティングされるようにします。
こうしたソリューションが現実的でない場合は、既存の Cloud Identity アカウントに Google Workspace を追加し、請求やサポートを担当していて通知を受け取る可能性が最も高い主要なユーザーに、Google Workspace ライセンスを割り当てます。
既存の一般ユーザー向けアカウントの移行オプションを評価する
組織として Cloud Identity や Google Workspace に登録する前に、Google アド マネージャー、Google AdSense、Google アナリティクスなどの Google サービスを使用していたユーザーが組織にいる場合、これらのサービスへのアクセスに、一般ユーザー向けアカウントを使用している可能性があります。
一般ユーザー向けアカウントのビジネス目的での使用を従業員に許可することはリスクが伴います。これらのリスクの詳細と、既存の一般ユーザー向けアカウントを表示する方法については、既存の Google アカウントの評価をご覧ください。
既存の一般ユーザー向けアカウントについては、次のように対処できます。
- 一般ユーザー向けのアカウントを維持して、潜在的なリスクを受け入れる。
- 転送を開始することで、アカウントを Cloud Identity または Google Workspace に移行する。
- 管理対象外のユーザー アカウントの所有者に、メールアドレスを変更して別のドメインを使用するように強制する。
既存の一般ユーザー向けアカウントを統合する方法の詳細については、ID 統合オプションの評価をご覧ください。
一般ユーザー向けアカウントにどのように対処するかが、連携を設定する方法と順序に影響します。Cloud Identity または Google Workspace でユーザー アカウントの作成や、シングル サインオンの設定は、ユーザーが使用している既存の一般ユーザー アカウントを評価した後に開始します。
ID セットをマッピングする
外部 IdP と Cloud Identity または Google Workspace との間で個々の ID をマッピングする方法を定義したら、続いて Google サービスへのアクセスを有効にする ID のセットを決める必要があります。
Google サービスに対して認証できる有効な ID のセットは、次の 2 つのセットの交差です。
- Cloud Identity または Google Workspace の ID にマッピングされている外部 ID。
外部 IdP により Cloud Identity または Google Workspace へのシングル サインオンが許可される外部 ID。
シングル サインオンの使用を許可するユーザーを制御するプロセスは、使用する IdP によって異なります。たとえば、Azure AD は割り当てに依存しますが、AD FS はアクセス制御ポリシーを使用します。
Google サービスに対して認証できる ID のセットを制限する
Google Cloud、Google Workspace、その他の Google ツールをどのように使用する予定かに応じて、組織の全従業員または一部の従業員のみを Google サービスに対して認証できるようにする必要があります。
組織の従業員の一部にのみ Google サービスへのアクセスを許可する場合は、この一部のユーザーにのみ認証を許可することをおすすめします。認証できるユーザーの数を制限することで、誤って緩すぎるアクセス制御ルールを構成した場合に備えて、防御を強化できます。
Google に対して認証できるユーザー グループを制限する方法は、次のとおりです。
- Cloud Identity または Google Workspace のユーザー アカウント数を最小限に抑える。ユーザー アカウントがマッピングされていない場合、シングル サインオンを使用した Cloud Identity または Google Workspace へのログインを IdP が許可していても、認証は失敗します。
- IdP でシングル サインオンを構成して、Cloud Identity または Google Workspace にログインできるユーザーの数を最小限に抑える。
状況に最適なアプローチは、移行が必要な一般ユーザー向けアカウントの有無によって異なります。
一般ユーザー向けアカウントを移行する必要がある場合は、プロビジョニングする ID のセットを制限する
一般ユーザー向けアカウントを Cloud Identity または Google Workspace に移行できるのは、Cloud Identity または Google Workspace で同じ ID のユーザー アカウントを作成していない場合のみです。
移行を予定している既存の一般ユーザー向けアカウントがある場合は、競合するユーザー アカウントを誤って作成しないように注意してください。次のガイドラインに従って操作してください。
- 既存の一般ユーザー向けアカウントを持たず、新しいアカウントを必要とするユーザーにのみ、新しい Cloud Identity または Google Workspace のユーザー アカウントを作成して、認証を制限します。
- Cloud Identity や Google Workspace でユーザー アカウントを作成するユーザーだけでなく、まだ移行されていないすべての一般ユーザー向けユーザー アカウントにシングル サインオンを許可することで、移行対象アカウントを誤ってロックアウトすることを回避します。
次の図は、さまざまなタイプの ID がどのように重複して相互に関連しているかを示しています。
この図では、Cloud Identity または Google Workspace のユーザー アカウントを持つ ID が、最も小さい楕円（黄色）で示されています。この楕円は、認証可能な ID を含む 2 つ目の楕円（青色）に囲まれています。3 つ目の最も大きい楕円（グレー）は IdP にユーザー アカウントを持つ ID を表し、他の楕円を包括しています。Active Directory、Azure AD、Okta の構成方法については、それぞれのベスト プラクティス ガイドをご覧ください。
新しい一般ユーザー向けアカウントの登録を禁止する
example.com などのドメインを Cloud Identity アカウントや Google Workspace アカウントに追加しても、従業員が同じドメインを使用して新しい一般ユーザー向けアカウントを登録することは禁止できません。これらの新しい一般ユーザー向けアカウントは、Cloud Identity または Google Workspace アカウントで管理対象外のユーザーとして表示されますが、シングル サインオンや、Cloud Identity または Google Workspace アカウントで適用した他の構成を使用することは許可されません。
新しい一般ユーザー向けアカウントの作成をブロックする方法の 1 つは、Cloud Identity または Google Workspace で同じメールアドレスを使用してユーザー アカウントを作成することです。たとえば、Cloud Identity または Google Workspace アカウントでユーザー alice@example.com を作成した場合、従業員が同じ ID で新しい一般ユーザー向けアカウントに登録しようとすると失敗します。ただし、Cloud Identity または Google Workspace に対応するユーザーがまだ存在しない場合は、新しい一般ユーザー向けアカウントの登録は成功します。
Cloud Identity に移行できる一般ユーザー向けアカウントがない場合、次の構成を適用することで新しい一般ユーザー向けアカウントの登録を禁止できます。
関連するユーザーのみが Cloud Identity または Google Workspace にシングル サインオンできるようにして、認証を制限します。
全従業員の Cloud Identity または Google Workspace のユーザーをプロビジョニングします。ユーザー アカウントで従業員の企業メールをメインのメールアドレスまたはエイリアスとして使用して、同じメールアドレスを使用して新しい一般ユーザー向けアカウントを作成できないようにします。可能であれば、シングル サインオンが有効になっていないユーザー アカウントを停止状態に保ちます。
以下の図に、この構成を示します。
一般ユーザー向けアカウントの移行作業がまだ進行中の場合は、登録プロセス中に送信された確認メールをキャプチャすることで、新しい一般ユーザー向けアカウントの登録を一時的にモニタリングできます。確認メールでは、*@idverification.bounces.google.com に一致するエンベロープ送信者アドレスが使用されます。メールシステムに、このエンベロープ送信者アドレスでメールを識別するフィルタを設定し、これらのメールを内部審査のため保留します。
Cloud Identity または Google Workspace ID を外部 IdP の ID のサブセットにする
Cloud Identity アカウントや Google Workspace アカウントには、外部 IdP のどのユーザーにもマッピングされていないユーザー アカウントが含まれている可能性があります。これらのユーザー アカウントには、次の 2 つの一般的なシナリオがあります。
- Cloud Identity または Google Workspace で新しいユーザー アカウントを作成し、外部 IdP のどのユーザーにもマッピングされていないメインのメールアドレスを使用する。
- Cloud Identity または Google Workspace のユーザー アカウントを外部 IdP の ID にマッピングした後、その外部 IdP の ID を削除する。たとえば、従業員が退職した場合に ID を削除します。
Cloud Identity または Google Workspace でシングル サインオンを有効にすると、すべてのユーザー（特権管理者を除く）はシングル サインオンを使用せざるを得なくなります。外部 IdP の ID にマッピングされていない Cloud Identity または Google Workspace のユーザー アカウントでは、シングル サインオンを使用しようとすると失敗します。このように、対応する ID がないユーザー アカウントは実質的には機能しませんが、次のような状況ではリスクが生じる可能性があります。
ある時点でシングル サインオンが一時的または完全に無効になった場合、ユーザー アカウントが再び使用できるようになります。これにより、元従業員がログインして企業リソースにアクセスできるようになる可能性があります。
削除されたユーザー アカウントの名前が再利用される可能性があります。たとえば、入社した従業員が、数か月前または数年前に退職した別の従業員と同じ名前だったとします。退職した従業員のユーザー アカウントが削除されている場合は、新しい従業員に前の従業員が使用していたユーザー名を割り当てることができます。
新しい従業員のユーザー アカウントの内部 ID は、前の従業員のものとは異なる場合があります。ただし、連携においては、2 つのユーザー アカウントが Cloud Identity または Google Workspace の同じメインのメールアドレスにマッピングされている場合、同じものであると見なされます。そのため、新しい従業員が Google にログインすると、前の従業員の既存のデータ、設定、権限が「継承」される可能性があります。
Cloud Identity と Google Workspace の特権管理者ユーザーは、シングル サインオンを使用する必要はありませんが、IdP によるログインが開始されても、シングル サインオンを使用できます。IdP で開始されたシングル サインオンを使用できる機能により、外部 IdP に対応するユーザーがない特権管理者ユーザーは、ユーザー名の不正占拠に対して注意を払う必要があります。
次の例について考えてみます。A さんは Cloud Identity または Google Workspace の特権管理者ユーザー alice-admin@example.com を持ち、2 段階認証プロセスを使用していません。A さんのパスワードを知らない B さんは、alice-admin@example.com にマッピングされる外部 IdP で新しいユーザーを作成する方法を見つけます。この新しく作成されたユーザー アカウントには特別な権限はなく、A さんのユーザー アカウントとは無関係ですが、A さんの特権管理者アカウントと ID を共有しているために、B さんは IdP で開始されたシングル サインオンを使用し、alice-admin@example.com として認証できることになります。
このようなユーザー名の不正占拠のリスクを軽減するには、Cloud Identity または Google Workspace の ID が外部 IdP の ID のサブセットであるようにします。そのための最適な方法は、外部 IdP によって実装されているように、Cloud Identity や Google Workspace のユーザー アカウントのライフサイクルに、ユーザー アカウントのライフサイクル全体をマッピングすることです。
専用の特権管理者ユーザーを使用する
Google Workspace と Cloud Identity の特権管理者アカウントには、Cloud Identity または Google Workspace アカウントだけでなく、関連する Google Cloud 組織にも適用される強力な権限があります。特権管理者権限が必要なアクティビティはごく小数であるため、特権管理者権限を持つ管理者の数を可能な限り制限し、アカウントや Google Cloud 組織の日常的な管理には、より権限の少ないユーザー アカウントを使用することをおすすめします。
特権管理者権限が必要な管理者を特定した場合、専用の特権管理者ユーザー アカウントを作成します。次に例を示します。
- ID
alice@example.comでユーザー アカウントを作成し、通常の権限を割り当てます。このアカウントは、日常業務に使用します。 ID が
alice-admin@example.comの 2 つ目のユーザー アカウントを作成し、スーパー ユーザー権限を割り当てます。ベスト プラクティスとして、特権管理者権限が必要な場合にのみこのアカウントを使用することをおすすめします。ユーザーのメールボックスでこのメールアドレスに送信された通知メールを受信するために、Google Workspace または既存のメールシステムを構成して、メールアドレス
alice-admin@example.comがエイリアスになるか、alice@example.comに転送されるようにします。
両方の ID を外部 IdP で認識させ、Cloud Identity または Google Workspace の ID のセットが引き続き外部 IdP の ID のサブセットになるようにします。
これらの専用の特権管理者アカウントの命名規則に従って、どこでどのように使用されているかを監査ログで追跡できるようにすることをおすすめします。たとえば、前の例のように、ユーザー名に -admin を追加します。
Google Workspace と Cloud Identity のサービス ユーザー数を制限する
外部 IdP には、従業員のユーザー アカウントだけでなく、マシンユーザー用（アプリケーション、ツール、バックグラウンド ジョブなど）のユーザー アカウントが含まれる場合があります。
対照的に、Google Cloud でアプリケーションが Google API に認証してアクセスするためのおすすめの方法は、次のいずれかの方法を実装することです。
エンドユーザーの代わりに Google API またはサービスにアクセスする必要があるウェブ アプリケーションまたはツールは、OAuth 2.0 または OpenID Connect を使用します。これらのプロトコルのいずれかを使用することで、アプリケーションはまずエンドユーザーにユーザーのデータへのアクセスについて同意を求め、同意を得た後に、エンドユーザーに代わってアクセスできるようになります。
API やサービスへのアクセスをエンドユーザーのためではなく、アプリケーション自体に対して行う場合は、Google Cloud サービス アカウントを使用して認証し、IAM を使用してリソースへのサービス アカウント アクセスを付与するのがおすすめの方法です。
Google Cloud サービス アカウントに IAM の適切なロールが付与されている場合、そのアカウントを使用して Cloud API を認証し使用できます。Google Cloud 以外の API （Directory API や Drive API など）へのアクセス権サービス アカウントに付与する必要がある場合は、Google Workspace ドメイン全体の委任を使用します。
Google Workspace ドメイン全体の委任では、サービス アカウントが Cloud Identity または Google Workspace ユーザーに代わって操作できるようにします。委任は強力な権限であるため、OAuth を使用する方法が現実的でない場合にのみ、Google Workspace ドメイン全体の委任を使用することをおすすめします。
Google Workspace ドメイン全体の委任が有効になっているすべての Google Cloud サービス アカウントに、専用の Cloud Identity または Google Workspace ユーザーを使用します。このユーザーを外部 IdP で作成し、Cloud Identity または Google Workspace にプロビジョニングして、Cloud Identity または Google Workspace のユーザーのセットが引き続き外部 IdP のユーザーのサブセットになるようにします。
Google Workspace ドメイン全体の委任に使用しないサービス ユーザーを、Cloud Identity と Google Workspace 内に作成しないでください。
ユーザー アカウントのライフサイクルをマッピングする
外部 IdP のユーザー アカウントは特定のライフサイクルをたどります。通常、このライフサイクルは従業員と会社の間の雇用関係を反映します。
- 組織に加わる従業員の新しいユーザー アカウントが作成されます。
- 従業員が長期休暇をとった場合などは、ユーザー アカウントが一時的に停止され、後で再び有効になることがあります。
- ユーザーが退職した場合、ユーザー アカウントは削除されるか、最終的に削除される前に停止状態で一定期間維持されます。
次の図は、このライフサイクルを示しています。
このセクションでは、Cloud Identity または Google Workspace のユーザー アカウントのライフサイクルが、外部 IdP の対応するユーザー アカウントのライフサイクルに沿うようにするためのベスト プラクティスを示します。
外部の IdP を信頼できる情報源として指定する
多くの HR 情報システム（HRIS）、IdP、アダプタは、一方向のユーザー プロビジョニングのみをサポートしています。つまり、HRIS または IdP で行われた変更は Cloud Identity または Google Workspace に反映されますが、Cloud Identity または Google Workspace で行われた変更が反映されることはありません。
一方向のプロビジョニングによる不整合を防ぐには、外部 IdP を信頼できる情報源として指定します。外部 IdP（または HRIS）のみを使用してユーザーを作成、変更、削除し、自動プロビジョニングを使用して変更を Google Workspace と Cloud Identity に反映させます。外部 IdP を信頼できる情報源として指定することで、不整合のリスクや手動変更が IdP によりオーバーライドされるリスクを制限できます。
Cloud Identity または Google Workspace へのユーザー プロビジョニングを自動化する
従業員がシングル サインオンを使用して Google に認証できるようにするには、まず Cloud Identity または Google Workspace で従業員のユーザー アカウントを作成する必要があります。外部 IdP との整合性を保つため、Cloud Identity または Google Workspace でこれらのユーザー アカウントをプロビジョニングするプロセスは、自動化することをおすすめします。
- プロビジョニングを自動化することで、Cloud Identity または Google Workspace の ID が、常に外部 IdP の ID のサブセットになります。
- Cloud Identity または Google Workspace の ID と外部 IdP の対応する ID が、誤って不一致となるリスクを最小限に抑えることができます。メールアドレスのスペルミスなどの不一致があると、従業員がログインできないことがあります。
- 手動での管理作業を最小限に抑えます。
オンボーディング プロセスの管理に HRIS を使用する場合、ユーザー プロビジョニングを自動化する方法の 1 つは、次の図のように、HRIS を構成して、外部 IdP と Cloud Identity または Google Workspace の両方にユーザー アカウントをプロビジョニングすることです。
この設定を正常に機能させるには、適切に相互にマッピングするように、HRIS がユーザー アカウントをプロビジョニングする必要があります。また、HRIS は、Cloud Identity または Google Workspace にプロビジョニングするユーザー アカウントを判断する必要があります。
ユーザー プロビジョニングの自動化で、HRIS とは独立して機能するもう 1 つの方法は、Cloud Identity または Google Workspace でのユーザー プロビジョニングの信頼できるソースとして外部 IdP を使用することです。この設定では、ユーザー アカウントのマッピングとユーザー アカウント セットの構成は、次の図で示すように、IdP またはアダプタによって管理されます。
Active Directory を IdP として使用する場合は、Google Cloud Directory Sync を使用してこの設定を複製できます。Azure AD、Okta などの他の IdP には、Google Workspace にユーザーをプロビジョニングするための組み込みアダプタがあります。Google Workspace と Cloud Identity は同じプラットフォームを基にしており、同じ API を使用しているため、これらのアダプタは Cloud Identity にも使用できます。
Cloud Identity または Google Workspace に停止イベントを伝える
従業員が一時的に休職した場合または退職した場合、Google サービスへのアクセス権を取り消すことをおすすめします。外部 IdP で従業員のユーザー アカウントを停止することにより、従業員はシングル サインオンを使用して Google に認証できなくなりますが、すべての Google サービスへのアクセスが完全には取り消されない可能性があります。次のような場合が考えられます。
- Cloud Identity または Google Workspace のユーザーがアクティブなブラウザ セッションを使用している場合、そのセッションは動作し続けます。すでに取得されている OAuth トークンも引き続き有効です。
- ユーザーに特権管理者権限がある場合や、ネットワーク マスクを構成している場合でも、従業員はパスワードを使用してログインできる場合があります。
- 予算アラートを含む Google Cloud からの通知が、依然として送信される場合があります。
- ユーザーに Google Workspace ライセンスが割り当てられている場合、メールは引き続きユーザーのメールボックスに配信され、ユーザーはアドレス帳や Google カレンダーに表示される場合があります。
- ユーザーに安全性の低いアプリの使用を許可している場合でも、ユーザーはアプリ パスワードを使用して Gmail や Google カレンダーなどのデータにアクセスできる場合があります。
Google サービスへのアクセスを完全に取り消すには、次の方法で停止イベントを Cloud Identity または Google Workspace に伝えます。
外部 IdP でユーザー アカウントが一時停止された場合には、Cloud Identity または Google Workspace の対応するユーザー アカウントも停止されるようにします。Cloud Identity または Google Workspace でユーザーを一時停止すると、アクティブなブラウザ セッションが終了し、トークンが無効になり、他のすべてのアクセスが取り消されます。
同様に、外部 IdP でユーザー アカウントを再度有効にする場合は、Cloud Identity または Google Workspace でも対応するユーザー アカウントを必ず有効にしてください。
Cloud Identity または Google Workspace でのユーザー アカウントの一時停止は非破壊的な操作です。ユーザー アカウントが一時停止されている間、ユーザーのデータは保持され、Google Workspace ライセンスは関連付けられたままとなり、Google Cloud 内の割り当てられたロールは変更されずに残ります。
Cloud Identity または Google Workspace に削除イベントを伝える
従業員が完全に退職した場合、その従業員のユーザー アカウントを外部 IdP で停止するだけでなく、削除することもできます。
外部 IdP のユーザー アカウントのみを削除し、対応する Cloud Identity または Google Workspace のユーザーを削除しない場合、以降、Cloud Identity と Google Workspace のユーザーのセットは、外部 IdP のユーザーのサブセットではなくなります。これは、退職した従業員と同じ名前の新しい従業員が組織に参加した場合に、問題に発展する可能性があります。IdP で新しい従業員のユーザー アカウントを作成すると、前の従業員のユーザー名を再利用する場合があり、Cloud Identity または Google Workspace の古いユーザー アカウントに新しいユーザー アカウントがマッピングされることになります。その結果、新しい従業員は前の従業員のデータと設定にアクセスできるようになります。
孤立した Cloud Identity または Google Workspace のユーザー アカウントに関連するリスクを回避するには、IdP で対応するユーザー アカウントが削除されたらすぐに Cloud Identity または Google Workspace のユーザーを削除します。
Cloud Identity または Google Workspace のユーザーを削除することは破壊的な操作となり、元に戻せる期間は限られています。ユーザーが使用している Google サービスによっては、ユーザーを削除すると関連データが完全に削除され、コンプライアンス要件を満たさなくなる場合があります。
ユーザーの設定とデータを完全に削除する前に一定期間保持するには、次のいずれかの方法を使用します。
一定の保持期間の間ユーザーを一時停止状態にして、外部 IdP でのユーザー アカウントの削除を先延ばしにします。保持期間が経過したら、IdP と Cloud Identity または Google Workspace の両方でユーザーを削除します。
外部 IdP のユーザー アカウントを削除する場合は、対応する Cloud Identity または Google Workspace ユーザーを一時停止し、メインのメールアドレスを競合が発生しない名前に変更します。たとえば、
alice@example.comの名前をobsolete-yyyymmdd-alice@example.comに変更します。yyyymmddは、外部 IdP での削除日を表します。名前を変更したユーザー アカウントを保持期間中停止状態にし、保持期間が経過したら削除します。
一時停止中のユーザーの Google Workspace データを保持するには、ユーザーに割り当てられた Google Workspace ライセンスを保持するか、アーカイブ ユーザー ライセンスに切り替えて、Google Workspace Vault の保持ルールが引き続き適用され、ユーザーのデータが保持されるようにします。
シングル サインオン
Google Cloud、Google 広告、YouTube などのすべての Google サービスでは、Google ログインを使用してユーザーを認証します。サービスがユーザーを accounts.google.com にリダイレクトして認証プロセスを開始します。ユーザーは、Google ログイン画面でメールアドレスの入力を求められます。指定されたメールアドレスのドメインに応じて、Gmail、一般ユーザー向けアカウントのディレクトリ内でユーザー アカウントが検索されます。または、ドメインがプライマリ ドメイン、セカンダリ ドメイン、またはエイリアス ドメインと一致する場合は、Cloud Identity アカウントまたは Google Workspace アカウント内で検索されます。
次の図は、この認証プロセスを示しています。
Cloud Identity または Google Workspace アカウントを構成して、シングル サインオンを使用すると、ユーザーは認証のため、外部 IdP にリダイレクトされます。外部 IdP が認証を完了すると、SAML アサーションによって結果が Google ログインに戻されます。この SAML アサーションは、認証が成功したことを証明します。アサーションにはユーザーのメールアドレスが含まれ、外部の IdP の証明書によって署名されるため、Google ログインで認証を確認できます。
このプロセスは、サービス プロバイダが開始するシングル サインオンと呼ばれ、特権管理者を除くすべてのユーザーに適用されます。特権管理者が外部 IdP にリダイレクトされることはなく、代わりにパスワードの入力を求められます。
一部の IdP では、IdP で開始されるシングル サインオンもサポートされています。このモデルでは、ユーザーは外部 IdP で認証を行い、Google Cloud や Google 広告などの Google サービスを指すリンクをたどります。Cloud Identity または Google Workspace アカウントでシングル サインオンが有効になっている場合、特権管理者を含むそのアカウントの全ユーザーは、IdP が開始するシングル サインオンを使用できます。
SAML アサーションで渡される属性セットを最小化する
ユーザーが外部 IdP で認証された後、Cloud Identity または Google Workspace は、外部 IdP から渡された SAML アサーションを使用してセッションを確立します。このプロセスでは、信頼性の検証に加えて、SAML アサーションの NameID 値に対応する Cloud Identity または Google Workspace ユーザー アカウントを特定します。
NameID の値には、認証するユーザー アカウントのメインのメールアドレスが含まれている必要があります。メールアドレスでは大文字と小文字が区別されます。エイリアスと予備のメールアドレスは考慮されません。
スペルミスや大文字と小文字の不一致を避けるため、ユーザー アカウントを自動的にプロビジョニングすることをおすすめします。
SAML アサーションには追加の属性を含めることができますが、認証においては考慮されません。ユーザーの名前、姓、グループ メンバーシップなどの情報を含む属性は、Cloud Identity または Google Workspace のユーザー アカウントがこのユーザー情報の唯一のソースと見なされるため、無視されます。
SAML アサーションのサイズを最小限に抑えるには、Google ログインで必要とされない属性を含めないように IdP を構成します。
発行者として google.com を使用する
Google ログイン セッションは、1 つのツールやドメインに限定されません。セッションが確立されると、ユーザーにアクセス権が付与されているすべての Google サービスでセッションが有効になります。これらのサービスには、Google Cloud や Google 広告などのサービスのほか、Google 検索や YouTube などのサービスも含まれます。
セッションのグローバルな性質は SAML プロトコル交換に反映されます。デフォルトでは、Google は SAML リクエストで google.com を発行元（SAML リクエスト内の Issuer 要素）として使用し、SAML アサーションがオーディエンス（SAML レスポンス内の Audience 要素）として google.com を指定すると想定します。
このデフォルトを変更するには、Cloud Identity または Google Workspace でシングル サインオンを構成するときに [ドメイン固有の発行元を使用] オプションを有効にします。ドメイン固有の発行元オプションは、複数の Cloud Identity アカウントまたは Google Workspace アカウント（および複数のドメイン）がある場合と、Cloud Identity アカウントまたは Google Workspace アカウントによって開始されたサインオンとその他のアカウントによって開始されたサインオンを IdP が区別する必要がある場合にのみ有効にしてください。このオプションを有効にした場合、SAML リクエストは google.com/a/DOMAIN を発行元として使用し、オーディエンスとして google.com/a/DOMAIN を想定します。ここで、DOMAIN は Cloud Identity または Google Workspace アカウントのプライマリ ドメインです。
それ以外の場合は、デフォルト設定のままで、google.com を発行元として使用し、外部 IdP を構成して google.com を SAML アサーションのオーディエンスとして指定します。この設定は、IdP によっては、発行者、証明書利用者信頼 ID、エンティティ ID とも呼ばれます。
Google セッションと IdP セッションの長さを調整する
ユーザーがシングル サインオン プロセスを完了し、セッションが確立されると、Google ログイン セッションは一定期間アクティブなままになります。この期間が経過するか、ユーザーがログアウトすると、ユーザーはシングル サインオン プロセスを繰り返して再認証を求められます。
Google サービスのセッション継続時間はデフォルトで 14 日間です。Cloud Identity Premium または Google Workspace Business のライセンスをお持ちの場合は、異なる期間（8 時間など）にデフォルトのセッションの長さを変更できます。
Google Cloud で使用されるセッションの長さを制御できます。Google Cloud セッションは、Google Cloud コンソール、Google Cloud CLI、その他の API クライアントに適用されます。Cloud Identity と Google Workspace のすべてのアカウント タイプで、Google Cloud セッションの長さを設定できます。
また、ほとんどの外部 IdP で、認証済みユーザーのセッションも維持されます。IdP セッションの長さが Google セッションの長さより長い場合は、再認証が自動的に行われることがあります。つまり、ユーザーは IdP にリダイレクトされますが、認証情報を再度入力する必要はありません。サイレント再認証は、Google セッションの長さを短縮する意図を損なう可能性があります。
Google セッションの有効期限が切れた後にユーザーにより認証情報の再入力が必要となるようにするには、IdP セッションが Google セッションよりも短くなるように構成します。
特権管理者ユーザーのシングル サインオンを無効にする
特権管理者ユーザーの場合、SSO は省略可能です。IdP によってサインオンが開始されたときに SSO を使用できますが、ユーザー名とパスワードを使用してログインすることもできます。
特権管理者ユーザーに IdP が開始するシングル サインオンを使用する予定がない場合は、次の手順でリスクを軽減できます。
- 特権管理者に専用の組織部門を追加します。
- シングル サインオンを無効にする組織部門に SSO プロファイルを割り当てる。
IdP で開始されたシングル サインオンを使用する予定がある場合は、特権管理者ユーザーに SSO 後の検証を適用してください。
多要素認証
Cloud Identity または Google Workspace と外部 IdP 間のシングル サインオンを有効にすると、従業員のユーザー エクスペリエンスが向上します。ユーザーは頻繁に認証する必要がなくなり、各種 Google サービスにアクセスするために異なる認証情報を覚える必要がなくなります。
しかし、ユーザーが複数のサービスや環境でシームレスに認証できるようにすると、ユーザー認証情報が不正使用された場合の影響も大きくなります。ユーザーのユーザー名とパスワードが紛失または盗まれた場合、攻撃者はこれらの認証情報を使用して、既存の環境だけでなく、1 つまたは複数の Google サービスのリソースにアクセスする可能性があります。
認証情報の盗難のリスクを軽減するには、すべてのユーザー アカウントで多要素認証を使用することをおすすめします。
ユーザーに多要素認証を適用する
Cloud Identity アカウントまたは Google Workspace アカウントにシングル サインオンを構成した場合、特権管理者権限のないユーザーは認証に外部 IdP を使用する必要があります。
IdP を構成して、2 つ目の要素（1 回限りのコードや USB キー）の使用を求め、Google へのシングル サインオンのたびに、多要素認証を適用します。
外部 IdP が多要素認証をサポートしていない場合は、SSO 後の検証を有効にして、ユーザーが外部 IdP での認証から戻った後に Google による追加検証を実行することを検討してください。
ネットワーク マスクは使用しないでください。ユーザーの多要素認証を回避する方法として悪用される可能性があります。
特権管理者ユーザーに Google の 2 段階認証プロセスを適用する
特権管理者ユーザーは、Google Cloud コンソールや他の Google サイトにログインしようとしても、外部 IdP にリダイレクトされません。特権管理者はユーザー名とパスワードで認証を行う必要があります。
特権管理者ユーザーはユーザー名とパスワードで認証できるため、IdP によって適用される可能性のある多要素認証ポリシーの適用対象とはなりません。特権管理者ユーザーを保護するために、すべての特権管理者ユーザーに Google の 2 段階認証を適用します。
特権管理者ユーザーは通常、次の 2 つのうちの 1 つのカテゴリに分類されます。
パーソナライズされた特権管理者ユーザー: パーソナライズされ、1 人の管理者が使用するユーザーです。すべてのパーソナライズされた特権管理者ユーザーに、2 段階認証プロセスを適用することをおすすめします。
マシン特権管理者ユーザー: このユーザー アカウントの使用は避けることをおすすめしますが、Cloud Identity や Google Workspace のユーザーやグループを管理するため、Cloud Directory Sync や Azure AD ギャラリー アプリなどのツールを有効にする必要が生じる場合があります。
マシン特権管理者ユーザーの数を制限し、可能な限り 2 段階認証プロセスを有効にしてください。
シングル サインオンを使用しないユーザーの場合は、アカウント全体、組織部門、またはグループごとに 2 段階認証プロセスを適用できます。
2 段階認証プロセスを使用できないマシン特権管理者ユーザーがいない場合は、すべてのユーザーに対する適用を有効にすることをおすすめします。すべてのユーザーに 2 段階認証プロセスを適用することで、ユーザーが適用対象から漏れるリスクを回避できます。
2 段階認証プロセスを使用できないマシン特権管理者ユーザーがいる場合は、専用のグループを使用して 2 段階認証プロセスを管理します。新しいグループを作成し、グループへの適用を有効にして、関連するすべてのスーパー ユーザーを追加します。
2 段階認証プロセスを使用して特権管理者ユーザーを保護する方法について詳しくは、管理者アカウントのセキュリティに関するベスト プラクティスをご覧ください。
特権管理者ユーザーに対して SSO 後の検証を適用する
特権管理者ユーザーはシングル サインオンを使用する必要はありませんが、IdP によって開始された場合には、シングル サインオンを使用できます。特権管理者ユーザーが IdP によって開始されたログインによって認証されていても、常に 2 段階認証プロセスが適用されるようにするには、すべての特権管理者ユーザーに対して追加の SSO 検証と 2 段階認証プロセスを有効にします。
IdP がすでに多要素認証を適用している場合、追加の SSO の確認は冗長であるように見える場合がありますが、この設定は IdP が不正使用された場合に特権管理者ユーザーを保護できます。
ネットワーク マスクによるシングル サインオンを制限しない
Cloud Identity または Google Workspace でシングル サインオンを構成する場合は、必要に応じてネットワーク マスクを指定できます。マスクを指定すると、マスクに一致する IP アドレスを持つユーザーのみがシングル サインオンの対象となります。他のユーザーはログイン時にパスワードの入力を求められます。
ネットワーク マスクを使用する場合は、外部 IdP によって適用される多要素認証を阻害する可能性があります。たとえば、ロケーションの変更や、VPN の使用により、ユーザーはネットワーク マスクを適用するかどうかを制御できます。外部 IdP で多要素認証を適用すると、ユーザーまたは攻撃者が、外部 IdP で構成された多要素認証ポリシーを回避できる可能性があります。
ユーザーのロケーションや IP アドレスに関係なく、多要素認証が一貫して適用されるようにするには、ネットワーク マスクによるシングル サインオン制限を避けるようにします。
リソースへのアクセスを IP アドレスで制限するには、外部 IdP で適切な IP 許可リストを構成するか、Google Cloud のコンテキストアウェア アクセスと Google Workspace を使用します。
次のステップ
- その他のベスト プラクティスを確認する。
- 外部 IdP と Google Cloud の連携のパターンを比較する。