Google ID 管理の概要

Google Cloud、Google マーケティング プラットフォーム、Google 広告など、すべての Google サービスは、Google ログインを使用してユーザーを認証します。このドキュメントでは、Google ログインが認証と ID 管理に使用するドメインモデルについて説明します。ドメインモデルを使用すると、企業での Google ログインの仕組み、ID の管理方法、外部 ID プロバイダ(IdP)との統合を促進する方法を理解できます。次の図は、これらのエンティティ間の相互作用を示しています。

ドメインモデルの概要。

この図に示すように、モデルの中心は Google ID です。これは Google ログインで使用されます。Google ID は、ID の管理のコンテキスト内で関連するすべての他の多くのエンティティに関連付けられています。

  • 一般ユーザー向け Google には、Gmail などの Google サービスの一般向けの利用に関連するエンティティが含まれます。
  • 組織向け Google には、Cloud Identity または G Suite によって管理されるエンティティが含まれます。これらのエンティティは、企業 ID の管理に特に関連性があります。
  • Google Cloud には、Google Cloud に固有のエンティティが含まれています。
  • 外部には、Google を外部 IdP と統合する場合に関連するエンティティが含まれます。

図の実線の矢印は、エンティティが相互に参照している(通常のコネクタ)、または相互に含まれている(ダイヤモンド コネクタ)ことを示します。一方、点線の矢印は連携の関係を表します。

Google ID

ID 管理では、ID、ユーザー、ユーザー アカウントが重要な役割を果たします。この 3 つの用語は密接に関連しており、場合によっては同じ意味で使用されることもあります。ただし、ID 管理のコンテキストでは、次のように概念を区別することをおすすめします。

  • ID とは、Google サービスを操作する個人を一意に識別する名前です。Google は、この目的のためにメールアドレスを使用します。個人のメールアドレスは、その個人の Google ID と見なされます。

    個人と ID の関連付けを検証するプロセスは認証またはログインと呼ばれ、これが実際に本人の ID であることを証明するものです。

    1 人で複数のメールアドレスを持っている場合もあります。Google サービスではメールアドレスを ID として使用するため、そのような場合は複数の ID を持っていると見なされます。

  • ユーザー アカウントは、特定の ID が Google サービスとやり取りするたびに適用される属性、アクティビティ、構成を追跡するデータ構造です。ユーザー アカウントはその場ですぐには作成されませんが、最初のログイン前にプロビジョニングする必要があります。

    ユーザー アカウントは、外部に公開されていない ID で識別されます。そのため、ユーザー インターフェースまたは API では、alice@gmail.com などの関連付けられた ID によってユーザー アカウントを間接的に参照する必要があります。この間接的な方法でも、データや構成の詳細は ID ではなくユーザー アカウントに関連付けられます。

ほとんどの場合、ユーザーアカウントと ID は 1 対 1 の関係にあるため、簡単に統合できます。ただし、次のエッジケースに示すように、これは常に当てはまるわけではありません。

  • ユーザー アカウントと ID の関係は固定されていません。ユーザー アカウントのメインのメールアドレスを変更して、ユーザーに異なる ID を関連付けることができます。

    Cloud Identity 管理者や G Suite 管理者は、2 人のユーザーのメインのメールアドレスを入れ替えることもできます。たとえば、アリス(alice@example.com)とボブ(bob@example.com)のメインのメールアドレスを入れ替えた場合、アリスはボブの以前のユーザー アカウントを使用し、ボブはアリスの以前のユーザー アカウントを使用します。データと構成は ID ではなくユーザー アカウントに関連付けられているため、アリスはボブの既存の構成とデータを使用する(同様にボブはアリスの構成とデータを使用する)ようになります。次の図は、この関係を示しています。

    ボブとアリスの ID の関係。

    連携以外の設定では、アリスとボブがユーザー アカウントを入れ替えるためにパスワードをリセットする必要もあります。アリスとボブが外部 IdP を使用して認証する連携設定では、パスワードをリセットする必要はありません。

  • ID とユーザーの関係は 1 対 1 でない場合があります。一般ユーザー向けアカウントは、次の図のように意図的に複数の ID に関連付けることができます

    1 つの ID で 2 つの異なるユーザー アカウントを参照することもできます。このような状況は避けることをおすすめしますが、ユーザー アカウントの競合が生じた場合に発生することもあります。その場合は、認証中に選択画面が表示され、ユーザーは使用するユーザー アカウントを選択します。

    アリス: ユーザーと ID が常に 1 対 1 であるとは限りません。

Google では、一般ユーザー向けユーザー アカウントと管理対象ユーザー アカウントの 2 種類のユーザー アカウントを区別しています。以下のセクションでは、両方のタイプのユーザー アカウントとその関連エンティティについて詳しく説明します。

一般ユーザー向け Google

alice@gmail.com のような Gmail のメールアドレスをお持ちの場合、Gmail アカウントは一般ユーザー向けアカウントです。同様に、Google ログインページの [アカウントを作成] リンクを使用し、登録時に alice@example.com などの独自のメールアドレスを指定すると、作成されるアカウントは一般ユーザー向けアカウントになります。

一般ユーザー向けアカウント

一般ユーザー向けアカウントはセルフサービスで作成され、主に個人的な目的で使用されます。一般ユーザー向けアカウントを作成した個人は、アカウントとそのアカウントを使用して作成されたデータを完全に管理できます。その個人が登録時に使用したメールアドレスは、一般ユーザー向けアカウントのメインのメールアドレスになり、アカウントの ID として使用されます。その個人は、一般ユーザー向けアカウントにメールアドレスを追加できます。これらのメールアドレスは追加の ID として使用され、ログインにも使用できます。

一般ユーザー向けアカウントで使用するメインのメールアドレスが、Cloud Identity または G Suite アカウントのプライマリ ドメインまたはセカンダリ ドメインに対応する場合、一般ユーザー向けアカウントは管理対象外のユーザー アカウントとも呼ばれます。gmail.com を Cloud Identity または G Suite アカウントにドメインとして追加することはできないため、管理対象外ユーザー アカウントにできるのは Gmail 以外の一般ユーザー向けアカウントのみです。

一般ユーザー向けアカウントは、任意の数のグループのメンバーにすることが可能です。

組織向け Google

組織で Google サービスを使用している場合は、管理対象ユーザー アカウントを使用することをおすすめします。これらのアカウントは、組織がライフサイクルと構成を完全に管理できるため、管理対象と呼ばれます。

管理対象ユーザー アカウントは、Cloud Identity と G Suite の機能です。

Cloud Identity または G Suite アカウント

Cloud Identity アカウントまたは G Suite アカウントは、ユーザー、グループ、構成、データの最上位のコンテナです。Cloud Identity または G Suite アカウントは、企業が Cloud Identity または G Suite に登録するときに作成され、テナントの概念に該当します。

Cloud Identity と G Suite は共通の技術プラットフォームです。どちらのサービスも同じ API と管理ツールを使用し、ユーザーとグループのコンテナとしてアカウントの概念を共有します。コンテナはドメイン名で識別されます。ユーザー、グループ、認証を管理する目的では、2 つのサービスはほぼ同等と見なされます。

アカウントにはグループと 1 つ以上の組織部門が含まれます。

組織部門

組織部門(OU)は、Cloud Identity または G Suite アカウントで定義されたユーザー アカウントを管理しやすいように分割できるユーザー アカウント用のサブコンテナです。

組織部門は階層で整理されます。各 Cloud Identity アカウントまたは G Suite アカウントにはルート組織部門があり、その下に必要に応じて追加の組織部門を作成できます。組織部門をネストすることもできます。

Cloud Identity と G Suite では、ライセンスの割り当て2 段階認証プロセスなど、特定の構成を組織部門ごとに適用できます。これらの設定は、組織部門内のすべてのユーザーに自動的に適用され、子組織部門にも継承されます。したがって、組織部門は Cloud Identity と G Suite の構成を管理するうえで重要な役割を果たします。

1 つのユーザー アカウントは複数の組織部門に属することができない点で、組織部門はグループとは異なります。組織部門はユーザー アカウントに構成を適用するのに便利ですが、アクセス管理での使用を意図したものではありません。アクセスを管理するには、グループの使用をおすすめします。

組織部門は Google Cloud フォルダに似ていますが、この 2 つのエンティティの目的は異なり、互いに無関係です。

管理対象ユーザー アカウント

管理対象ユーザー アカウントは一般ユーザー向けアカウントと同様に機能しますが、Cloud Identity または G Suite アカウントの管理者が完全に管理できます。

管理対象ユーザー アカウントの ID は、メインのメールアドレスによって定義されます。メインのメールアドレスには、Cloud Identity または G Suite アカウントに追加されたプライマリ、セカンダリ、エイリアス ドメインのいずれかに対応するドメインを使用する必要があります。管理対象ユーザー アカウントには、追加のエイリアス メールアドレス再設定用のメールアドレスを設定できますが、ID とはみなされないためログインには使用できません。たとえば、アリスが alice@example.com をメインのメールアドレスとして使用し、エイリアスのメールアドレスとして ally@example.com を、再設定用のメールアドレスとして alice@gmail.com を構成している場合、アリスがログイン時に使用できるのは alice@example.com のみとなります。

管理対象ユーザー アカウントは組織部門に含まれ、任意の数のグループのメンバーにすることが可能です。

管理対象ユーザー アカウントは、マシンユーザーではなく人間のユーザーが使用することを目的としています。マシンのユーザー アカウントは、個人ではなく、アプリケーションまたは仮想マシン(VM)インスタンスで使用される特別なアカウントです。マシンユーザー向けに、Google Cloud はサービス アカウントを提供しています(サービス アカウントについては、このドキュメントの後半で詳しく説明します)。

グループ

グループを使用すると、複数のユーザーをまとめることができます。グループを使用して、メーリング リストを管理することや、複数のユーザーに共通のアクセス制御や構成を適用することもできます。

Cloud Identity と G Suite は、メールアドレス(billing-admins@example.com など)でグループを識別します。ユーザーのメインのメールアドレスと同様に、グループのメールアドレスには Cloud Identity または G Suite アカウントのプライマリ ドメイン、セカンダリ ドメイン、エイリアス ドメインのいずれかを使用する必要があります。グループがメーリング リストとして使用されていない限り、メールアドレスはメールボックスに対応している必要はありません。認証は引き続きグループのメールではなくユーザーのメールを使用して行われるため、ユーザーはグループのメールアドレスを使用してログインできません。

グループには、次のエンティティをメンバーとして含めることができます。

  • ユーザー(管理対象ユーザーまたは一般ユーザー向けアカウント)
  • 他のグループ
  • サービス アカウント

組織部門とは異なり、グループはコンテナとしては機能しません。

  • ユーザーまたはグループは、1 つだけでなく、任意の数のグループのメンバーにすることが可能です。
  • グループを削除しても、メンバーのユーザーやグループは削除されません。

グループには、任意の Cloud Identity または G Suite アカウントのユーザーと、一般ユーザー向けアカウントを含めることができます。[disallow members outside your organization] 設定を使用して、メンバーを同じ Cloud Identity または G Suite アカウントのユーザー アカウントに制限できます。

外部 ID

Cloud Identity アカウントまたは G Suite アカウントを外部 IdP と連携させることで、従業員が既存の ID と認証情報を使用して Google サービスにログインできるようなります。

最も基本的なレベルでは、SAML を使用してシングル サインオンを設定し、Cloud Identity または G Suite の ID を外部 IdP が管理する ID にリンクさせます。alice@example.com などの ID をリンクして Google へのシングル サインオンを有効にするには、次の 2 つの前提条件を満たす必要があります。

  • 外部 IdP が ID alice@example.com を認識し、シングル サインオンでの使用を許可している。
  • Cloud Identity アカウントまたは G Suite アカウントに、alice@example.com を ID として使用するユーザー アカウントが含まれている。このユーザー アカウントは、最初のシングル サインオンを試行する前に存在している必要があります。

Cloud Identity または G Suite でユーザー アカウントを手動で作成して管理する代わりに、SAML ベースのシングル サインオンと自動ユーザー プロビジョニングを組み合わせて処理を自動化できます。自動ユーザー プロビジョニングでは、ユーザーとグループのすべてまたはサブセットを、外部の信頼できるソースから Cloud Identity または G Suite に同期します。

IdP の選択によっては、SAML ベースのシングル サインオンと自動ユーザー プロビジョニングが同じソフトウェア コンポーネントで処理されるか、個別のコンポーネントが必要になる場合があります。したがって、ドメインモデルは SAML ID プロバイダと外部の信頼できるソースを区別します。

外部 SAML ID プロバイダ

外部 IdP は認証用の唯一のシステムであり、アプリケーションにまたがるシングル サインオン エクスペリエンスを従業員に提供します。これは Google の外部にあるため、外部 ID プロバイダと呼ばれます。

シングル サインオンを有効にすると、Cloud Identity または G Suite は認証の決定を SAML IdP に伝えます。SAML 側では、Cloud Identity または G Suite はサービス プロバイダとして機能し、SAML IdP を信頼してユーザーの ID を検証します。

各 Cloud Identity または G Suite アカウントは、最大で 1 つの外部 IdP を参照できます。複数の Cloud Identity または G Suite アカウントは異なる SAML IdP を参照できますが、1 つの Cloud Identity または G Suite アカウントで複数の SAML IdP を使用することはできません。

よく使用される外部 IdP には、Active Directory フェデレーション サービス(AD FS)、Azure AD、Okta、Ping Identity などがあります。

外部の信頼できるソース

ID の信頼できるソースは、従業員の ID を作成、管理、削除するための唯一のシステムです。Google の外部にあるため、外部の信頼できるソースと呼ばれます。

外部の信頼できるソースから、ユーザー アカウントとグループを Cloud Identity または G Suite に自動的にプロビジョニングできます。プロビジョニングは、信頼できるソース自体で処理される場合やプロビジョニング ミドルウェアによって処理される場合があります。

自動ユーザー プロビジョニングを有効にするには、SAML IdP で認識される ID をユーザーにプロビジョニングする必要があります。ID をマッピングする場合(たとえば、Cloud Identity または G Suite の ID alice@example.com を SAML IdP の u12345@corp.example.com にマッピングする場合)、SAML IdP とプロビジョニング ミドルウェアはどちらも同じマッピングを実行する必要があります。

外部ユーザー アカウント

外部 ID プロバイダには、名前、属性、構成を追跡するユーザー アカウントというコンセプトがあると想定されます。

信頼できるソース(またはプロビジョニング ミドルウェア)は、ログイン エクスペリエンスを容易にするために、すべて(またはサブセット)の外部ユーザー アカウントを Cloud Identity または G Suite にプロビジョニングすることが想定されます。多くの場合、ユーザーの属性のサブセット(メールアドレス、姓、名など)のみを Cloud Identity や G Suite に伝えれば十分です。データの冗長性を制限できます。

外部のグループ

外部 IdP がグループの概念をサポートしている場合、必要に応じてこれらのグループを Cloud Identity または G Suite のグループにマッピングできます。

グループのマッピングと自動プロビジョニングは任意であり、シングル サインオンに必要ではありませんが、両方のステップは既存のグループを再利用して G Suite または Google Cloud でアクセスを制御する場合に役立つこともあります。

Google Cloud

他の Google サービスと同様に、Google Cloud はユーザーの認証に Google ログインを使用します。Google Cloud は G Suite および Cloud Identity と密接に統合されているため、リソースを効率的に管理できます。

Google Cloud では、組織ノード、フォルダ、プロジェクトの概念が導入されています。これらのエンティティは主にアクセスと構成の管理に使用されるため、ID 管理のコンテキストでのみ間接的に関連性があります。ただし、Google Cloud には、サービス アカウントという追加のタイプのユーザー アカウントも含まれています。サービス アカウントはプロジェクトに属し、ID 管理で重要な役割を果たします。

組織ノード

組織は、Google Cloud リソース階層のルートノードであり、プロジェクトとフォルダのコンテナです。組織を使用すると、リソースを階層的に構成できるので、リソースを一元的かつ効率的に管理するうえで非常に重要です。

各組織は 1 つの Cloud Identity または G Suite アカウントに属しています。組織の名前は、対応する Cloud Identity または G Suite アカウントのプライマリ ドメイン名から取得されます。

フォルダ

フォルダは Google Cloud リソース階層のノードであり、プロジェクト、他のフォルダ、またはその両方を含めることができます。フォルダを使用して、共通の Cloud Identity and Access Management(Cloud IAM)ポリシーまたは組織のポリシーを共有するリソースをグループ化します。これらのポリシーは、フォルダ内のすべてのプロジェクトに自動的に適用され、子フォルダにも継承されます。

フォルダは組織部門と似ていますが、無関係です。組織部門はユーザーを管理し、ユーザーに共通の構成やポリシーを適用するうえで役立ちます。一方、フォルダは Google Cloud プロジェクトを管理し、プロジェクトに共通の設定やポリシーを適用するのに役立ちます。

プロジェクト

プロジェクトはリソースのコンテナです。プロジェクトは、API の管理、課金、リソースへのアクセスの管理で重要な役割を果たします。

ID 管理のコンテキストでは、プロジェクトはサービス アカウントのコンテナであるため、関連性があります。

サービス アカウント

サービス アカウント(または Google Cloud サービス アカウント)は、アプリケーションやその他のタイプのマシンユーザーが使用するための特別なユーザー アカウントです。

各サービス アカウントは Google Cloud プロジェクトに属します管理対象ユーザーアカウントの場合と同様に、管理者はサービス アカウントのライフサイクルと構成を完全に管理できます。

サービス アカウントでもメールアドレスが ID として使用されますが、管理対象ユーザー アカウントとは異なり、必ず developer.gserviceaccount.com などの Google 所有ドメインが使用されます。

サービス アカウントは連携の対象ではなく、パスワードもありません。Google Cloud で Cloud IAM を使用して、仮想マシン(VM)や Cloud Functions の関数などのコンピューティング リソースに対するサービス アカウントの権限を管理することで、認証情報の管理が不要になります。Google Cloud の外部では、サービス アカウント キーを使用することで、サービス アカウントを使用してアプリケーションを認証できます。

Kubernetes サービス アカウント

Kubernetes サービス アカウントは Kubernetes のコンセプトであり、Google Kubernetes Engine(GKE)を使用する際に必要になります。Google Cloud サービス アカウントと同様に、Kubernetes サービス アカウントは人間ではなくアプリケーションによって使用されます。

Kubernetes サービス アカウントは、アプリケーションが Kubernetes クラスタの Kubernetes API を呼び出すときに認証に使用できますが、クラスタ外では使用できません。これらは Google API で認識されないため、Google Cloud サービス アカウントに代わるものではありません。

アプリケーションを Kubernetes Pod としてデプロイすると、Pod をサービス アカウントに関連付けることができます。この関連付けにより、アプリケーションは証明書やその他の認証情報を構成または維持することなく、Kubernetes API を使用できます。

Workload Identity を使用すると、Kubernetes サービス アカウントを Google Cloud サービス アカウントにリンクできます。このリンクにより、アプリケーションは証明書やその他の認証情報を維持することなく Google API に対しても認証を行うことができます。

次のステップ