このドキュメントでは、企業 ID を管理するためのリファレンスとして使用できる一般的なアーキテクチャについて説明します。企業 ID の管理における重要な 2 つの原則は次のとおりです。
ID の信頼できるソースは、従業員の ID を作成、管理、削除する際に使用する唯一のシステムです。信頼できるソースシステムで管理されている ID が他のシステムに伝播される場合があります。
一元的な ID プロバイダ（IdP）は、認証用の唯一のシステムであり、複数のアプリケーションを対象に従業員がシングル サインオンの操作を行うことができるようにします。
Google Cloud またはその他の Google サービスを使用する場合は、ID プロバイダとして使用するシステムと、信頼できるソースとして使用するシステムを決定する必要があります。
IdP として Google を使用する
Cloud Identity Premium または Google Workspace を使用すると、Google をプライマリ IdP として設定できます。Google では、一般的なサードパーティ アプリケーション向けに事前構成済みの統合に関する多数の選択肢を用意しており、SAML、OAuth、OpenID Connect などの標準プロトコルを使用してカスタム アプリケーションを統合できます。
IdP および信頼できるソースとしての Google
次の図に示すように、Cloud Identity Premium または Google Workspace は、IdP および信頼できるソースの両方として使用できます。
- Cloud Identity Premium または Google Workspace を使用してユーザーとグループを管理します。
- すべての Google サービスで Cloud Identity Premium または Google Workspace が IdP として使用されます。
- Google を IdP として使用するように、企業アプリケーションやその他の SaaS サービスを構成します。
ユーザー エクスペリエンス
この構成では、従業員はサインオンする際にユーザーとして次のように操作します。
- 保護されたリソースまたは企業アプリケーションへのアクセスを要求すると、従業員は Google のログイン画面にリダイレクトされ、その画面でメールアドレスとパスワードの入力を求められます。
- 2 段階認証プロセスが有効になっている場合、従業員は USB キーやコードなどの 2 つ目の要素を入力するよう求められます。
- 認証されると、従業員は保護されたリソースに再びリダイレクトされます。
メリット
Google を IdP および信頼できるソースとして使用すると、次のようなメリットがあります。
- Google の多要素認証とモバイル デバイス管理機能を最大限に活用できます。
- 追加の IdP を必要としません。これにより、コストを削減できます。
このアーキテクチャを使用する場面
次のシナリオでは、Google を IdP および信頼できるソースとして使用することを検討してください。
- コラボレーションと生産性のソリューションとしてすでに Google Workspace を使用している。
- 統合を必要とする既存のオンプレミス インフラストラクチャまたは IdP が存在しない、あるいは Google（Google Cloud、Google 広告など）上のすべてのリソースから分離した状態で保持する必要がある。
- ID の管理を目的として人事情報システム（HRIS）と統合することを必要としない。
IdP としての Google と信頼できるソースとしての HRIS
人事情報システム（HRIS）を使用して従業員のオンボーディングとオフボーディングのプロセスを管理する場合でも、Google を IdP として使用できます。次の図に示すように、Cloud Identity と Google Workspace には、HRIS やその他のシステムがユーザーとグループの管理を制御できるようにする API が用意されています。
- 既存の HRIS を使用してユーザーと、必要に応じてグループを管理します。HRIS は引き続き ID 管理のための唯一の認証ソースとして機能し、Cloud Identity または Google Workspace のユーザーを自動的にプロビジョニングします。
- すべての Google サービスで Cloud Identity Premium または Google Workspace が IdP として使用されます。
- Google を IdP として使用するように、企業アプリケーションやその他の SaaS サービスを構成します。
ユーザー エクスペリエンス
サインオンする際にユーザーとして従業員が行う操作は、Google を IdP および信頼できるソースとして使用する場合と同じです。
メリット
Google を IdP および信頼できるソースとして使用すると、次のようなメリットがあります。
- 既存の HRIS ワークフローを再利用することで、管理オーバーヘッドを最小限に抑えることができます。
- Google の多要素認証とモバイル デバイス管理機能を最大限に活用できます。
- 追加の IdP を必要としません。これにより、コストを削減できます。
このアーキテクチャを使用する場面
次のシナリオでは、Google を IdP として、HRIS を信頼できるソースとして使用することを検討してください。
- ID の信頼できるソースとして機能する既存の HRIS またはその他のシステムがある。
- コラボレーションと生産性のソリューションとしてすでに Google Workspace を使用している。
- 統合を必要とする、または Google の資産とは切り離して保持することを必要とする既存のオンプレミス インフラストラクチャあるいは IdP が存在しない。
外部 IdP を使用する
組織ですでに Active Directory、Azure AD、ForgeRock、Okta、Ping Identity などの IdP を使用している場合は、連携を使用して Google Cloud をこの外部 IdP と統合できます。
外部 IdP と Cloud Identity または Google Workspace アカウントを連携することにより、従業員は既存の ID と認証情報を使用して Google Cloud、Google マーケティング プラットフォーム、Google 広告などの Google サービスにログインできるようになります。
IdP および信頼できるソースとしての外部 IDaaS
ForgeRock、Okta、Ping Identity などの Identity as a Service（IDaaS）プロバイダを使用する場合は、次の図に示すように連携を設定できます。
- Cloud Identity や Google Workspace は、IDaaS をシングル サインオンを行う際の IdP として使用します。
- IDaaS は、Cloud Identity または Google Workspace のユーザーとグループを自動的にプロビジョニングします。
- 既存の企業アプリケーションやその他の SaaS サービスは、引き続き IdP として IDaaS に移行できます。
Cloud Identity や Google Workspace と Okta の連携の詳細については、Okta のユーザー プロビジョニングとシングル サインオンをご覧ください。
ユーザー エクスペリエンス
サインオン時に従業員は、ユーザーとして次のような操作を行います。
- 保護されたリソースを要求すると、従業員は Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
- Google ログインにより、IDaaS のログインページにリダイレクトされます。
- IDaaS で認証します。IDaaS によっては、コードなどの 2 つ目の要素を入力するよう求められます。
- 認証されると、保護されたリソースに再びリダイレクトされます。
メリット
外部 IDaaS を IdP および信頼できるソースとして使用すると、次のようなメリットがあります。
- IDaaS に統合された Google サービスやその他のアプリケーションのすべてを対象に、従業員がシングル サインオンの操作を行えるようにできます。
- 多要素認証を要求するように IDaaS を構成した場合は、その構成が自動的に Google Cloud に適用されます。
- パスワードなどの認証情報を Google と同期する必要がありません。
- Cloud Identity の無料版を使用できます。
このアーキテクチャを使用する場面
次のシナリオでは、外部 IDaaS を IdP および信頼できるソースとして使用することを検討してください。
- すでに IdP として ForgeRock、Okta、Ping Identity などの IDaaS プロバイダを使用している場合。
ベスト プラクティス
Google Cloud と外部 ID プロバイダの連携に関するおすすめの方法をご覧ください。
IdP および信頼できるソースとしての Active Directory
Active Directory を ID 管理の認証ソースとして使用する場合は、次の図に示すように連携を設定できます。
- Google Cloud Directory Sync（GCDS） は、Active Directory から Cloud Identity や Google Workspace のユーザーとグループを自動的にプロビジョニングするために使用します。Google Cloud Directory Sync は、Google が無料で提供している、同期プロセスを実装するツールであり、Google Cloud またはオンプレミス環境で実行できます。同期は一方向で行われるため、Active Directory は引き続き認証ソースとして機能します。
- Cloud Identity や Google Workspace では、Active Directory フェデレーション サービス（AD FS）を使用してシングル サインオンします。
- 既存の企業アプリケーションやその他の SaaS サービスでは、引き続き AD FS を IdP として使用できます。
このパターンから派生するものとして、Active Directory Lightweight Directory Services（AD LDS）、AD FS または他の SAML を遵守する IdP を使用している別の LDAP ディレクトリを使用することもできます。
この方法の詳細については、Google Cloud と Active Directory の連携をご覧ください。
ユーザー エクスペリエンス
- 保護されたリソースを要求すると、従業員は Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
- Google ログインにより、従業員は AD FS のログインページにリダイレクトされます。
- AD FS の構成によって、Active Directory のユーザー名とパスワードの入力を求めるログイン画面が表示される場合と、AD FS が Windows ログインに基づいて自動的に従業員のログイン処理を試みる場合があります。
- AD FS による認証が行われると、従業員は保護されたリソースに再びリダイレクトされます。
メリット
Active Directory を IdP および信頼できるソースとして使用すると、次のようなメリットがあります。
- Google サービスとオンプレミス環境のすべてにおいて、従業員がシングル サインオンの操作を行えるようにできます。
- 多要素認証を要求するように AD FS を構成した場合は、その構成が自動的に Google Cloud に適用されます。
- パスワードなどの認証情報を Google に同期する必要がありません。
- Cloud Identity の無料版を使用できます。
- GCDS が使用する API は一般公開されているため、オンプレミス ネットワークと Google Cloud の間にハイブリッド接続を設定する必要がありません。
このアーキテクチャを使用する場面
次のシナリオでは、Active Directory を IdP および信頼できるソースとして使用することを検討してください。
- 既存の Active Directory インフラストラクチャがある。
- Windows ユーザーがシームレスなログイン操作を行えるようにすることを考えている。
ベスト プラクティス
次のベスト プラクティスを検討してください。
- Active Directory と Cloud Identity の論理構造は異なります。必ず違いを理解し、ドメイン、ID、グループのマッピング方法に関して、どれが最もご自身の状況に適しているかを評価してください。詳細については、Google Cloud と Active Directory の連携に関するガイドをご覧ください。
- ユーザーだけでなく、グループも同期してください。このアプローチでは、Google Cloud のリソースに対するアクセス権を割り当てるユーザーを制御するために、Active Directory のグループ メンバーシップを使用できるよう、Cloud IAM を設定できます。
- AD FS を企業ユーザーがアクセスできるようにデプロイ、公開しますが、公開対象は必要な範囲にとどめてください。企業ユーザーは AD FS にアクセスできる必要がありますが、Cloud Identity、Google Workspace、または Google Cloud にデプロイされたアプリケーションから AD FS にアクセスできるようにする必要はありません。
- AD FS で統合 Windows 認証（IWA）を有効にして、ユーザーが自分の Windows ログインに基づいて自動的にログインできるようにすることを検討してください。
- AD FS が使用できなくなると、ユーザーは Google Cloud コンソールや Google を IdP として使用するその他のリソースを使用できなくなる可能性があります。そのため、AD FS と AD FS が依存するドメイン コントローラのデプロイとサイジングが、可用性目標を満たしていることを確認してください。
Google Cloud を使用してビジネスの継続性を確保している場合、オンプレミスの AD FS に依存すると、Google Cloud をデプロイの独立したコピーとして使用するという意図が損なわれる可能性があります。この場合は、次のいずれかの方法で、関連するすべてのシステムのレプリカを Google Cloud にデプロイすることを検討してください。
- Google Cloud に既存の Active Directory ドメインを拡張し、Google Cloud で実行するために GCDS をデプロイします。
- 専用の AD FS サーバーを Google Cloud で実行します。これらのサーバーは、Google Cloud で実行されている Active Directory ドメイン コントローラを使用します。
- シングル サインオン用に Google Cloud にデプロイした AD FS サーバーを使用するように Cloud Identity を構成します。
詳細については、Google Cloud と外部 ID プロバイダの連携に関するおすすめの方法をご覧ください。
IdP としての Azure AD と信頼できるソースとしての Active Directory
Microsoft Office 365 または Azure のお客様である場合は、オンプレミスの Active Directory を Azure AD に接続している可能性があります。Google Cloud へのアクセスを必要とする可能性があるすべてのユーザー アカウントが、すでに Azure AD に同期されている場合は、次の図に示すように Cloud Identity を Azure AD と連携することにより、この統合を再利用できます。
- Azure AD を使用して、Cloud Identity または Google Workspace にユーザーとグループを自動的にプロビジョニングします。Azure AD 自体をオンプレミスの Active Directory と統合することもできます。
- Cloud Identity または Google Workspace では、シングル サインオンに Azure AD を使用します。
- 既存の企業アプリケーションやその他の SaaS サービスでは、引き続き Azure AD を IdP として使用できます。
この方法の詳細については、Google Cloud と Azure Active Directory の連携をご覧ください。
ユーザー エクスペリエンス
- 保護されたリソースを要求すると、従業員は Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
- Google ログインにより、AD FS のログインページにリダイレクトされます。
- Azure AD に対するオンプレミスの Active Directory の接続方法に応じて、Azure AD がユーザー名とパスワードの入力を求める場合と、オンプレミス AD FS にリダイレクトする場合があります。
- Azure AD で認証されると、従業員は保護されたリソースに再びリダイレクトされます。
メリット
Azure AD を IdP として使用し、Active Directory を信頼できるソースとして使用すると、次のようなメリットがあります。
- Google サービス、Azure、オンプレミス環境のすべてにおいて、従業員がシングル サインオンの操作を行えるようにできます。
- 多要素認証を要求するように Azure AD を構成した場合は、その構成が自動的に Google Cloud に適用されます。
- オンプレミスで追加のソフトウェアをインストールする必要がありません。
- オンプレミスの Active Directory が複数のドメインまたはフォレストを使用しており、この構造を Azure AD テナントにマッピングするようにカスタム Azure AD Connect 構成を設定している場合は、この統合作業の恩恵を生かすことができます。
- パスワードなどの認証情報を Google に同期する必要がありません。
- Cloud Identity の無料版を使用できます。
- Google Cloud コンソールを、Office 365 ポータルのタイルとして表示できます。
- Azure AD が使用する API は一般公開されているため、Azure と Google Cloud の間にハイブリッド接続を設定する必要がありません。
このアーキテクチャを使用する場面
次のシナリオでは、Azure AD を IdP として使用し、Active Directory を信頼できるソースとして使用することを検討してください。
- すでに Azure AD を使用しており、既存の Active Directory インフラストラクチャと統合している。
- Azure と Google Cloud 全体でユーザーがシームレスなログイン操作を行えるようにしたいと考えている。
ベスト プラクティス
次のベスト プラクティスを行ってください。
- Azure AD と Cloud Identity では使用する論理構造が異なるため、その違いを理解してください。ドメイン、ID、グループのマッピング方法に関して、どれが最もご自身の状況に適しているかを評価してください。詳細については、Google Cloud と Azure AD の連携をご覧ください。
- ユーザーだけでなく、グループも同期してください。この方法では、IAM を設定することにより、Azure AD のグループ メンバーシップを使用して Google Cloud のリソースに対するアクセス権を付与するユーザーを制御できます。
- Google Cloud を使用してビジネスの継続性を確保している場合は、認証を Azure AD に依存すると、Google Cloud をデプロイの独立したコピーとして使用するという意図が損なわれる可能性があります。
詳細については、Google Cloud と外部 ID プロバイダの連携に関するおすすめの方法をご覧ください。
次のステップ
- Active Directory との連携について詳細を確認する。
- Azure AD との連携を設定する方法を確認する。
- アカウントと組織の計画に関するおすすめの方法、Google Cloud と外部 ID プロバイダの連携について確認する。