このドキュメントでは、Google Cloud の ID プロビジョニング オプションと、ユーザーを Cloud Identity または Google Workspace にオンボーディングする際に決定する必要がある事項について説明します。また、このドキュメントには、各オプションをデプロイする方法に関する詳細情報も記載されています。
このドキュメントは、ランディング ゾーンに関するシリーズの一部であり、組織と Google Cloud のデプロイの ID の管理に携わるアーキテクトや技術者を対象としています。
概要
組織のユーザーが Google Cloud リソースにアクセスできるようにするには、ユーザーが自身の認証を行うための方法を提供する必要があります。Google Cloud は Google ログインを使用してユーザーを認証します。これは、Gmail や Google 広告などの他の Google サービスが使用する ID プロバイダ（IdP）です。
組織内の一部のユーザーはすでに限定公開の Google ユーザー アカウントを持っている場合がありますが、Google Cloud にアクセスするときは、プライベート アカウントを使用することを強くおすすめします。代わりに、Cloud Identity または Google Workspace にユーザーをオンボーディングして、ユーザー アカウントのライフサイクルとセキュリティを制御できます。
Google Cloud での ID のプロビジョニングは複雑なトピックです。正確な戦略では、この決定ガイドの範囲よりも詳細な情報が必要になる場合があります。より詳しいベスト プラクティス、計画、デプロイの情報については、Identity and Access Management の概要をご覧ください。
ID オンボーディングの決定ポイント
組織に最適な ID プロビジョニングの設計を選択するには、次のことを決定する必要があります。
ID アーキテクチャを決定する
ユーザー アカウントのライフサイクルとセキュリティを管理することは、Google Cloud のデプロイを保護する上で重要な役割を果たします。あなたがしなければならない重要な決定は、既存の ID 管理システムとアプリケーションに対して Google Cloud が果たす役割です。以下のオプションがあります。
- Google をメインの ID プロバイダ（IdP）として使用する。
- 外部 ID プロバイダとの連携を使用する。
次のセクションで、各オプションに関する詳細を説明します。
オプション 1: Google を ID の主なソースとして使用する（連携なし）
Cloud Identity または Google Workspace で直接ユーザー アカウントを作成する場合、Google を ID のソースとプライマリ IdP にできます。ユーザーはこれらの ID と認証情報を使用して Google Cloud やその他の Google サービスにログインします。
Cloud Identity と Google Workspace には、一般的なサードパーティ アプリケーション向けのさまざまなすぐに使用できる統合機能が用意されています。また、SAML、OAuth、OpenID Connect などの標準プロトコルを使用して、カスタム アプリケーションを Cloud Identity または Google Workspace と統合することもできます。
この戦略は、次の条件に当てはまる場合に使用します。
- Google Workspace で、組織にユーザー ID がすでにプロビジョニングされている。
- 組織に既存の IdP がない。
- 組織に既存の IdP があるが、少数のユーザーですぐに開始してから、後で ID の連携を行いたい。
ID の信頼できるソースとして使用する既存の IdP がある場合は、この戦略は使用しないでください。
詳しくは以下をご覧ください。
オプション 2: 外部 ID プロバイダとの連携を使用する
連携を使用して、Google Cloud を既存の外部 IdP と統合できます。ID 連携は、2 つ以上の IdP 間の信頼を確立し、ユーザーが異なる ID 管理システムで持つ可能性のある複数の ID をリンクできるようにします。
外部 IdP と Cloud Identity または Google Workspace アカウントを連携することにより、ユーザーは既存の ID と認証情報を使用して Google Cloud やその他の Google サービスにログインできるようになります。
この戦略は、次の条件に当てはまる場合に使用します。
- Active Directory、Azure AD、ForgeRock、Okta、Ping Identity などの既存の IdP がある。
- 従業員が、既存の ID と認証情報を使用して、Google Cloud やその他の Google サービス（Google 広告や Google マーケティング プラットフォームなど）にログインする。
組織に既存の IdP がない場合は、この戦略は使用しないでください。
詳しくは以下をご覧ください。
- 外部 ID - Google ID 管理の概要
- リファレンス アーキテクチャ: 外部 IdP の使用
- Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティス
- Google Cloud と Active Directory の連携
- Google Cloud と Azure AD の連携
既存のユーザー アカウントを統合する方法を決定する
Cloud Identity や Google Workspace を使用していない場合は、組織の従業員が一般ユーザー向けアカウントを使用して Google サービスにアクセスしている可能性があります。一般ユーザー向けアカウントは、作成者が完全に所有、管理するアカウントです。これらのアカウントは組織の管理対象外であり、個人データと企業データの両方が含まれている可能性があるため、これらのアカウントを他の企業アカウントと統合する方法を決定する必要があります。
一般ユーザー向けアカウントの詳細、その特定方法、組織に対するリスクについては、既存のユーザー アカウントの評価をご覧ください。
アカウントを統合するためのオプションは次のとおりです。
- 一般ユーザー向けアカウントの関連するサブセットを統合する。
- 移行ですべてのアカウントを統合する。
- 新しいアカウントを作成する前に、アカウントを移行せずに、エビクションですべてのアカウントを統合する。
次のセクションで、各オプションに関する詳細を説明します。
オプション 1: 一般ユーザー向けアカウントの関連する一部を統合する
一般ユーザー向けアカウントを保持し、会社のポリシーでそれらのデータを管理する場合は、Cloud Identity または Google Workspace に移行する必要があります。ただし、一般ユーザー向けアカウントを統合するプロセスには時間がかかる場合があります。そのため、まず計画した Google Cloud デプロイに関連するユーザーのサブセットを評価してから、それらのユーザー アカウントだけを統合することをおすすめします。
この戦略は、次の条件に当てはまる場合に使用します。
- 管理対象に含まれないユーザー用の移行ツールに、ドメイン内の多くの一般ユーザー向けアカウントが表示されるが、Google Cloud を使用するのは一部のユーザーである場合。
- 統合プロセスの時間を節約したいと考えている。
以下に当てはまる場合、この戦略は避けてください。
- ドメイン内に一般ユーザー向けのユーザー アカウントがない。
- Google Cloud の使用を開始する前に、ドメイン内のすべての一般ユーザー向けアカウントから取得したすべてのデータを管理対象アカウントに統合する必要があります。
詳細については、アカウントの統合の概要をご覧ください。
オプション 2: 移行によってすべてのアカウントを統合する
ドメイン内のすべてのユーザー アカウントを管理する場合は、すべての一般ユーザー向けアカウントを管理対象アカウントに移行することで統合できます。
この戦略は、次の条件に当てはまる場合に使用します。
- 管理対象に含まれないユーザー用の移行ツールには、ドメイン内の小数の一般ユーザー向けアカウントのみが表示される場合。
- 組織での一般ユーザー向けアカウントの使用を制限する場合。
統合プロセスの時間を節約したい場合は、この戦略は使用しないでください。
詳しくは、一般ユーザー向けアカウントの移行をご覧ください。
オプション 3: エビクションによってすべてのアカウントを統合する
次のような場合は、一般ユーザー向けアカウントを削除できます。
- 一般ユーザー向けアカウントを作成したユーザーが、アカウントとデータを完全に管理できるようにする場合。
- 組織により管理されるデータを転送しない場合。
一般ユーザー向けアカウントを削除するには、最初にユーザー アカウントを移行せずに、同じ名前のマネージド ユーザー ID を作成します。
この戦略は、次の条件に当てはまる場合に使用します。
- 一般ユーザー向けアカウントに存在するデータを転送せずに、ユーザーの新しい管理対象アカウントを作成する場合。
- 組織で利用できる Google サービスを制限する場合。また、ユーザーがデータを保持し、作成した一般ユーザー向けアカウントに引き続きこれらのサービスを使用できるようにする場合。
一般ユーザー向けアカウントが企業で使用されていて、企業データにアクセスできる可能性がある場合は、この戦略は使用しないでください。
詳しくは、一般ユーザー向けアカウントの削除をご覧ください。
ID のオンボーディングのベスト プラクティス
ID アーキテクチャと既存の一般ユーザー向けアカウントを統合する方法を選択したら、次の ID のベスト プラクティスを検討してください。
組織に適したオンボーディング プランを選択する
組織の ID を Cloud Identity または Google Workspace にオンボーディングさせるための大まかな計画を選択します。実績のあるオンボーディング プランの選択と、ニーズに最適なプランの選択方法については、オンボーディング プランの評価をご覧ください。
外部 IdP を使用する予定で、移行が必要なユーザー アカウントを特定している場合は、追加の要件が発生する可能性があります。詳しくは、ユーザー アカウントの統合による連携への影響の評価をご覧ください。
ユーザー アカウントの保護
Cloud Identity または Google Workspace にユーザーをオンボーディングしたら、アカウントを不正行為から保護するための対策を講じる必要があります。詳しくは以下をご覧ください。
- Cloud Identity 管理者アカウントのセキュリティのベスト プラクティスを実装する。
- 均一な多要素認証ルール を適用し、連携 ID と組み合わせた場合のベスト プラクティスに従う。
- データ共有を有効にすることで、Google Workspace または Cloud Identity の監査ログを Cloud Logging にエクスポートする。
次のステップ
- リソース階層を決定する（このシリーズの次のドキュメント）。
- ユーザー、Cloud Identity アカウント、Google Cloud 組織の関係について詳細を確認する。
- アカウントと組織の計画に関する推奨されるベスト プラクティスを確認する。
- Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスを確認する。