リファレンス アーキテクチャ

Last reviewed 2024-07-11 UTC

このドキュメントでは、企業 ID を管理するためのリファレンスとして使用できる一般的なアーキテクチャについて説明します。企業 ID の管理における重要な 2 つの原則は次のとおりです。

  • ID の信頼できるソースは、従業員の ID を作成、管理、削除する際に使用する唯一のシステムです。信頼できるソースシステムで管理されている ID が他のシステムに伝播される場合があります。

  • 一元的な ID プロバイダ（IdP） は、認証用の唯一のシステムであり、複数のアプリケーションを対象に従業員がシングル サインオンの操作を行うことができるようにします。

またはその他の Google サービスを使用する場合は、ID プロバイダとして使用する システムと、信頼できる ソースとして使用するシステムを決定する必要があります。 Google Cloud

IdP として Google を使用する

Cloud Identity Premium または Google Workspace を使用すると、Google をプライマリ IdP として設定できます。Google では、一般的なサードパーティ アプリケーション向けに事前構成済みの統合に関する多数の選択肢を用意しており、SAML、OAuth、OpenID Connect などの標準プロトコルを使用してカスタム アプリケーションを統合できます。

IdP および信頼できるソースとしての Google

次の図に示すように、Cloud Identity Premium または Google Workspace は、IdP および信頼できるソースの両方として使用できます。

IdP および信頼できるソースとしての Google。

  • Cloud Identity Premium または Google Workspace を使用してユーザーとグループを管理します。
  • すべての Google サービスで Cloud Identity Premium または Google Workspace が IdP として使用されます。
  • Google を IdP として使用するように、企業アプリケーションやその他の SaaS サービスを構成します。

ユーザー エクスペリエンス

この構成では、従業員はサインオンする際にユーザーとして次のように操作します。

  1. 保護されたリソースまたは企業アプリケーションへのアクセスを要求すると、従業員は Google のログイン画面にリダイレクトされ、その画面でメールアドレスとパスワードの入力を求められます。
  2. 2 段階認証プロセスが有効になっている場合、従業員は USB キーやコードなどの 2 つ目の要素を入力するよう求められます。
  3. 認証されると、従業員は保護されたリソースに再びリダイレクトされます。

メリット

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 が用意されています。

IdP としての Google と信頼できるソースとしての HRIS。

  • 既存の 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、Microsoft Entra ID（旧 Azure AD）、ForgeRock、Okta、Ping Identity などの IdP を使用している場合は、連携を使用して をこの外部 IdP と統合できます。 Google Cloud

外部 IdP と Cloud Identity または Google Workspace アカウントを連携することにより、従業員は既存の ID と認証情報を使用して 、Google マーケティング プラットフォーム、Google 広告などの Google サービスにログインできるようになります。 Google Cloud

IdP および信頼できるソースとしての外部 IDaaS

ForgeRock、Okta、Ping Identity などの Identity as a Service（IDaaS）プロバイダを使用する場合は、次の図に示すように連携を設定できます。

IdP および信頼できるソースとしての外部 IDaaS

  • Cloud Identity や Google Workspace は、IDaaS をシングル サインオンを行う際の IdP として使用します。
  • IDaaS は、Cloud Identity または Google Workspace のユーザーとグループを自動的にプロビジョニングします。
  • 既存の企業アプリケーションやその他の SaaS サービスは、引き続き IdP として IDaaS に移行できます。

Cloud Identity や Google Workspace と Okta の連携の詳細については、Okta のユーザー プロビジョニングとシングル サインオンをご覧ください。

ユーザー エクスペリエンス

サインオン時に従業員は、ユーザーとして次のような操作を行います。

  1. 保護されたリソースを要求すると、従業員は Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
  2. Google ログインにより、IDaaS のログインページにリダイレクトされます。
  3. IDaaS で認証します。IDaaS によっては、コードなどの 2 つ目の要素を入力するよう求められます。
  4. 認証されると、保護されたリソースに再びリダイレクトされます。

メリット

外部 IDaaS を IdP および信頼できるソースとして使用すると、次のようなメリットがあります。

  • IDaaS に統合された Google サービスやその他のアプリケーションのすべてを対象に、従業員がシングル サインオンの操作を行えるようにできます。
  • 多要素認証を要求するように IDaaS を構成した場合は、 その構成が自動的に Google Cloudに適用されます。
  • パスワードなどの認証情報を Google と同期する必要がありません。
  • Cloud Identity の無料版を使用できます。

このアーキテクチャを使用する場面

次のシナリオでは、外部 IDaaS を IdP および信頼できるソースとして使用することを検討してください。

  • すでに IdP として ForgeRock、Okta、Ping Identity などの IDaaS プロバイダを使用している場合。

おすすめの方法

と外部 ID プロバイダの連携に関する おすすめの方法 Google Cloud をご覧ください。

IdP および信頼できるソースとしての Active Directory

Active Directory を ID 管理の認証ソースとして使用する場合は、次の図に示すように連携を設定できます。

IdP および信頼できるソースとしての Active Directory。

このパターンから派生するものとして、Active Directory Lightweight Directory Services（AD LDS）、AD FS または他の SAML を遵守する IdP を使用している別の LDAP ディレクトリを使用することもできます。

この方法の詳細については、 と Active Directory の連携をご覧ください。 Google Cloud

ユーザー エクスペリエンス

  1. 保護されたリソースを要求すると、従業員は Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
  2. Google ログインにより、従業員は AD FS のログインページにリダイレクトされます。
  3. AD FS の構成によって、Active Directory のユーザー名とパスワードの入力を求めるログイン画面が表示される場合と、AD FS が Windows ログインに基づいて自動的に従業員のログイン処理を試みる場合があります。
  4. AD FS による認証が行われると、従業員は保護されたリソースに再びリダイレクトされます。

メリット

Active Directory を IdP および信頼できるソースとして使用すると、次のようなメリットがあります。

  • Google サービスとオンプレミス環境のすべてにおいて、従業員がシングル サインオンの操作を行えるようにできます。
  • 多要素認証を要求するように AD FS を構成した場合は、その 構成が自動的に Google Cloudに適用されます。
  • パスワードなどの認証情報を Google に同期する必要がありません。
  • Cloud Identity の無料版を使用できます。
  • GCDS が使用する API は一般公開されているため、オンプレミス ネットワークと の間に ハイブリッド接続 を設定する必要がありません Google Cloud。

このアーキテクチャを使用する場面

次のシナリオでは、Active Directory を IdP および信頼できるソースとして使用することを検討してください。

  • 既存の Active Directory インフラストラクチャがある。
  • Windows ユーザーがシームレスなログイン操作を行えるようにすることを考えている。

ベスト プラクティス

次のベスト プラクティスを検討してください。

詳細については、 と外部 ID プロバイダの連携に関するおすすめの方法 Google Cloud をご覧ください。

IdP としての Entra ID と信頼できるソースとしての Active Directory

Microsoft 365 または Azure のお客様である場合は、オンプレミスの Active Directory を Entra ID に接続している可能性があります。へのアクセスを必要とする可能性があるすべてのユーザー アカウントがすでに Entra ID と同期されている場合は、Cloud Identity と Entra ID を連携することでこの統合を再利用できます。 Google Cloud

IdP としての Entra ID と信頼できるソースとしての Active Directory。

  • Entra ID を使用して、Cloud Identity または Google Workspace にユーザーとグループを自動的にプロビジョニングします。Entra ID 自体をオンプレミスの Active Directory と統合することもできます。
  • Cloud Identity または Google Workspace では、シングル サインオンに Entra ID を使用します。
  • 既存の企業アプリケーションやその他の SaaS サービスでは、引き続き Entra ID を IdP として使用できます。

この方法の詳細については、 と Microsoft Entra ID の連携をご覧ください。 Google Cloud

ユーザー エクスペリエンス

  1. 保護されたリソースを要求すると、従業員は Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
  2. Google ログインにより、AD FS のログインページにリダイレクトされます。
  3. Entra ID に対するオンプレミスの Active Directory の接続方法に応じて、Entra ID がユーザー名とパスワードの入力を求める場合と、オンプレミス AD FS にリダイレクトする場合があります。
  4. Entra ID で認証されると、従業員は保護されたリソースに再びリダイレクトされます。

メリット

Entra ID を IdP として使用し、Active Directory を信頼できるソースとして使用すると、次のようなメリットがあります。

  • Google サービス、Entra、オンプレミス環境のすべてにおいて、従業員がシングル サインオンの操作を行えるようにできます。
  • 多要素認証を要求するように Entra ID を構成した場合は、その 構成が自動的に に適用されます Google Cloud.
  • オンプレミスで追加のソフトウェアをインストールする必要がありません。
  • オンプレミスの Active Directory が複数のドメインまたはフォレストを使用しており、この構造を Entra ID テナントにマッピングするようにカスタム Entra ID Connect 構成を設定している場合は、この統合作業の恩恵を生かすことができます。
  • パスワードなどの認証情報を Google に同期する必要がありません。
  • Cloud Identity の無料版を使用できます。
  • コンソールを、Office 365 ポータルのタイルとして表示できます。 Google Cloud
  • Entra ID が使用する API は一般公開されているため、Entra と の間に ハイブリッド接続 を設定する必要がありません Google Cloud。

このアーキテクチャを使用する場面

次のシナリオでは、Entra ID を IdP として使用し、Active Directory を信頼できるソースとして使用することを検討してください。

  • すでに Entra ID を使用しており、既存の Active Directory インフラストラクチャと統合している。
  • Entra と Google Cloud全体でユーザーがシームレスなログイン操作を行えるようにしたいと考えている。

おすすめの方法

次のベスト プラクティスに従ってください。

  • Entra ID と Cloud Identity では使用する論理構造が異なるため、その違いを理解してください。ドメイン、ID、グループのマッピング方法に関して、どれが最もご自身の状況に適しているかを評価してください。詳細については、 と Microsoft Entra ID との連携をご覧ください。 Google Cloud
  • ユーザーだけでなく、グループも同期してください。この方法では、IAM を設定することにより、Entra ID のグループ メンバーシップを使用して のリソースに対するアクセス権を付与するユーザーを制御できます。 Google Cloud
  • Google Cloud を使用してビジネスの継続性を確保している場合、 認証を Entra ID に依存すると、 Google Cloud をデプロイの独立したコピーとして使用するという意図が損なわれる可能性があります。

詳細については、 と外部 ID プロバイダの連携に関するおすすめの方法 Google Cloud をご覧ください。

次のステップ