Google Cloud、Google マーケティング プラットフォーム、Google 広告など、すべての Google サービスは、Google ログインを使用してユーザーを認証します。このドキュメントでは、Google ログインが認証と ID 管理に使用するドメインモデルについて説明します。ドメインモデルを使用すると、企業での Google ログインの仕組み、ID の管理方法、外部 ID プロバイダ（IdP）との統合を促進する方法を理解できます。次の図は、これらのエンティティ間の相互作用を示しています。
この図に示すように、モデルの中心は Google ID です。これは Google ログインで使用されます。Google ID は、ID の管理のコンテキスト内で関連するすべての他の多くのエンティティに関連付けられています。
- 一般ユーザー向け Google には、Gmail などの Google サービスの一般向けの利用に関連するエンティティが含まれます。
- 組織向け Google には、Cloud Identity または Google Workspace で管理されるエンティティが含まれています。これらのエンティティは、企業 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 または Google Workspace 管理者は、2 人のユーザーのメインのメールアドレスを交換することもできます。たとえば、アリス（
alice@example.com）とボブ（bob@example.com）のメインのメールアドレスを入れ替えた場合、アリスはボブの以前のユーザー アカウントを使用し、ボブはアリスの以前のユーザー アカウントを使用します。データと構成は ID ではなくユーザー アカウントに関連付けられているため、アリスはボブの既存の構成とデータを使用する（同様にボブはアリスの構成とデータを使用する）ようになります。次の図は、この関係を示しています。
連携以外の設定では、アリスとボブがユーザー アカウントを入れ替えるためにパスワードをリセットする必要もあります。アリスとボブが外部 IdP を使用して認証する連携設定では、パスワードをリセットする必要はありません。
ID とユーザーの関係は 1 対 1 でない場合があります。一般ユーザー向けアカウントは、次の図のように意図的に複数の ID に関連付けることができます。
1 つの ID で 2 つの異なるユーザー アカウントを参照することもできます。このような状況は避けることをおすすめしますが、ユーザー アカウントの競合が生じた場合に発生することもあります。その場合は、認証中に選択画面が表示され、ユーザーは使用するユーザー アカウントを選択します。
Google では、一般ユーザー向けユーザー アカウントと管理対象ユーザー アカウントの 2 種類のユーザー アカウントを区別しています。以下のセクションでは、両方のタイプのユーザー アカウントとその関連エンティティについて詳しく説明します。
一般ユーザー向け Google
alice@gmail.com のような Gmail のメールアドレスをお持ちの場合、Gmail アカウントは一般ユーザー向けアカウントです。同様に、Google ログインページの [アカウントを作成] リンクを使用し、登録時に alice@example.com などの独自のメールアドレスを指定すると、作成されるアカウントは一般ユーザー向けアカウントになります。
一般ユーザー向けアカウント
一般ユーザー向けアカウントはセルフサービスで作成され、主に個人的な目的で使用されます。一般ユーザー向けアカウントを作成した個人は、アカウントとそのアカウントを使用して作成されたデータを完全に管理できます。その個人が登録時に使用したメールアドレスは、一般ユーザー向けアカウントのメインのメールアドレスになり、アカウントの ID として使用されます。その個人は、一般ユーザー向けアカウントにメールアドレスを追加できます。これらのメールアドレスは追加の ID として使用され、ログインにも使用できます。
一般ユーザー向けアカウントで Cloud Identity アカウントまたは Google Workspace アカウントのプライマリ ドメインまたはセカンダリ ドメインに相当するメインのメールアドレスを使用している場合、一般ユーザー向けアカウントは管理対象外のユーザー アカウントとも呼ばれます。
一般ユーザー向けアカウントは、任意の数のグループのメンバーにすることが可能です。
組織向け Google
組織で Google サービスを使用している場合は、管理対象ユーザー アカウントを使用することをおすすめします。これらのアカウントは、組織がライフサイクルと構成を完全に管理できるため、管理対象と呼ばれます。
管理対象ユーザー アカウントは、Cloud Identity と Google Workspace の機能です。
Cloud Identity または Google Workspace アカウント
Cloud Identity アカウントまたは Google Workspace アカウントは、ユーザー、グループ、構成、データの最上位コンテナです。Cloud Identity アカウントまたは Google Workspace アカウントは、企業が Cloud Identity または Google Workspace に登録するときに作成され、テナントの概念に相当します。
Cloud Identity と Google Workspace は、共通の技術プラットフォームを共有します。どちらのサービスも同じ API と管理ツールを使用し、ユーザーとグループのコンテナとしてアカウントの概念を共有します。コンテナはドメイン名で識別されます。ユーザー、グループ、認証を管理する目的では、2 つのサービスはほぼ同等と見なされます。
アカウントにはグループと 1 つ以上の組織部門が含まれます。
組織部門
組織部門（OU）は、Cloud Identity アカウントまたは Google Workspace アカウントで定義されたユーザー アカウントを管理しやすいように分割できる、ユーザー アカウント用のサブコンテナです。
組織部門は階層で整理されます。各 Cloud Identity アカウントまたは Google Workspace アカウントにはルート組織部門があり、その下に必要に応じて追加の組織部門を作成できます。組織部門をネストすることもできます。
Cloud Identity と Google Workspace を使用すると、ライセンスの割り当てや 2 段階認証プロセスなど、組織部門ごとに特定の構成を適用できます。これらの設定は、組織部門内のすべてのユーザーに自動的に適用され、子組織部門にも継承されます。したがって、組織部門は Cloud Identity と Google Workspace の構成を管理するうえで重要な役割を果たします。
1 つのユーザー アカウントは複数の組織部門に属することができない点で、組織部門はグループとは異なります。組織部門はユーザー アカウントに構成を適用するのに便利ですが、アクセス管理での使用を意図したものではありません。アクセスを管理するには、グループの使用をおすすめします。
組織部門は Google Cloud フォルダに似ていますが、この 2 つのエンティティの目的は異なり、互いに無関係です。
管理対象ユーザー アカウント
管理対象ユーザー アカウントは一般ユーザー向けのユーザー アカウントと同じように動作しますが、Cloud Identity または Google Workspace アカウントの管理者によって完全に制御されます。
管理対象ユーザー アカウントの ID は、メインのメールアドレスによって定義されます。メインのメールアドレスは、Cloud Identity アカウントまたは Google Workspace アカウントに追加されたプライマリ ドメイン、セカンダリ ドメイン、エイリアス ドメインのいずれかに対応するドメインを使用する必要があります。管理対象ユーザー アカウントには、追加のエイリアス メールアドレスと再設定用のメールアドレスを設定できますが、ID とはみなされないためログインには使用できません。たとえば、アリスが alice@example.com をメインのメールアドレスとして使用し、エイリアスのメールアドレスとして ally@example.com を、再設定用のメールアドレスとして alice@gmail.com を構成している場合、アリスがログイン時に使用できるのは alice@example.com のみとなります。
管理対象ユーザー アカウントは組織部門に含まれ、任意の数のグループのメンバーにすることが可能です。
管理対象ユーザー アカウントは、マシンユーザーではなく人間のユーザーが使用することを目的としています。マシンのユーザー アカウントは、個人ではなく、アプリケーションまたは仮想マシン（VM）インスタンスで使用される特別なアカウントです。マシンユーザー向けに、Google Cloud はサービス アカウントを提供しています（サービス アカウントについては、このドキュメントの後半で詳しく説明します）。
グループ
グループを使用すると、複数のユーザーをまとめることができます。グループを使用して、メーリング リストを管理することや、複数のユーザーに共通のアクセス制御や構成を適用することもできます。
Cloud Identity と Google Workspace は、メールアドレス（billing-admins@example.com など）でグループを識別します。ユーザーのメインのメールアドレスと同様に、グループのメールアドレスは、Cloud Identity アカウントまたは Google Workspace アカウントのプライマリ ドメイン、セカンダリ ドメイン、エイリアス ドメインのいずれかを使用する必要があります。グループがメーリング リストとして使用されていない限り、メールアドレスはメールボックスに対応している必要はありません。認証は引き続きグループのメールではなくユーザーのメールを使用して行われるため、ユーザーはグループのメールアドレスを使用してログインできません。
グループには、次のエンティティをメンバーとして含めることができます。
- ユーザー（管理対象ユーザーまたは一般ユーザー向けアカウント）
- 他のグループ
- サービス アカウント
組織部門とは異なり、グループはコンテナとしては機能しません。
- ユーザーまたはグループは、1 つだけでなく、任意の数のグループのメンバーにすることが可能です。
- グループを削除しても、メンバーのユーザーやグループは削除されません。
グループには、任意の Cloud Identity アカウントや Google Workspace アカウントのほか、一般ユーザー向けアカウントからのメンバーも含めることができます。[組織外のメンバーを許可しない] 設定を使用して、同じ Cloud Identity アカウントまたは Google Workspace アカウントのユーザー アカウントにメンバーを制限できます。
外部 ID
Cloud Identity アカウントまたは Google Workspace のアカウントを外部 IdP と連携させることで、従業員が既存の ID と認証情報を使用して Google サービスにログインできるようになります。
最も基本的なレベルでは、連携には SAML を使用してシングル サインオンを設定する必要があります。これにより、Cloud Identity または Google Workspace の ID と、外部 IdP で管理されている ID がリンクします。alice@example.com などの ID をリンクして Google へのシングル サインオンを有効にするには、次の 2 つの前提条件を満たす必要があります。
- 外部 IdP が ID
alice@example.comを認識し、シングル サインオンでの使用を許可している。 - Cloud Identity アカウントまたは Google Workspace アカウントに、ID として
alice@example.comを使用するユーザー アカウントが含まれている。このユーザー アカウントは、最初のシングル サインオンを試行する前に存在している必要があります。
Cloud Identity や Google Workspace でユーザー アカウントを手動で作成して管理する代わりに、SAML ベースのシングル サインオンと自動ユーザー プロビジョニングを組み合わせて処理を自動化できます。自動ユーザー プロビジョニングでは、ユーザーとグループの全体または一部を外部の信頼できるソースから Cloud Identity または Google Workspace に同期します。
IdP の選択によっては、SAML ベースのシングル サインオンと自動ユーザー プロビジョニングが同じソフトウェア コンポーネントで処理されるか、個別のコンポーネントが必要になる場合があります。したがって、ドメインモデルは SAML ID プロバイダと外部の信頼できるソースを区別します。
外部 SAML ID プロバイダ
外部 IdP は認証用の唯一のシステムであり、アプリケーションにまたがるシングル サインオン エクスペリエンスを従業員に提供します。これは Google の外部にあるため、外部 ID プロバイダと呼ばれます。
シングル サインオンを構成すると、Cloud Identity または Google Workspace によって認証の決定が SAML IdP にリレーされます。SAML 側では、Cloud Identity または Google Workspace はサービス プロバイダとして機能し、自身の代わりにユーザー ID を検証する SAML IdP を信頼します。
よく使用される外部 IdP には、Active Directory フェデレーション サービス（AD FS）、Entra ID、Okta、Ping Identity などがあります。
外部の信頼できるソース
ID の信頼できるソースは、従業員の ID を作成、管理、削除するための唯一のシステムです。Google の外部にあるため、外部の信頼できるソースと呼ばれます。
外部の信頼できるソースから、ユーザー アカウントとグループを Cloud Identity または Google Workspace に自動的にプロビジョニングできます。プロビジョニングは、信頼できるソース自体で処理される場合やプロビジョニング ミドルウェアによって処理される場合があります。
自動ユーザー プロビジョニングを有効にするには、SAML IdP で認識される ID をユーザーにプロビジョニングする必要があります。ID 間でマッピングする場合（たとえば、Cloud Identity または Google Workspace の ID alice@example.com を SAML IdP の u12345@corp.example.com にマッピングする場合など）、SAML IdP とプロビジョニング ミドルウェアはどちらも同じマッピングを行う必要があります。
外部ユーザー アカウント
外部 ID プロバイダには、名前、属性、構成を追跡するユーザー アカウントというコンセプトがあると想定されます。
信頼できるソース（またはプロビジョニング ミドルウェア）は、ログイン エクスペリエンスを容易にするために、すべての（または一部の）外部ユーザー アカウントを Cloud Identity または Google Workspace にプロビジョニングすることが想定されます。データの冗長性を制限できるようにするには、多くの場合、ユーザーの属性の一部（メールアドレス、名、姓など）のみを Cloud Identity または Google Workspace に伝えるだけで十分です。
外部のグループ
外部 IdP がグループの概念をサポートしている場合、必要に応じてこれらのグループを Cloud Identity または Google Workspace のグループにマッピングできます。
グループのマッピングと自動プロビジョニングは任意であり、シングル サインオンには必須ではありません。ただし、既存のグループを再利用して Google Workspace や Google Cloud でアクセスを制御する場合には、両方の手順が役立つ場合があります。
Google Cloud
他の Google サービスと同様に、Google Cloud はユーザーの認証に Google ログインを使用します。Google Cloud は Google Workspace や Cloud Identity と緊密に統合されているため、リソースを効率的に管理できます。
Google Cloud では、組織ノード、フォルダ、プロジェクトの概念が導入されています。これらのエンティティは主にアクセスと構成の管理に使用されるため、ID 管理のコンテキストでのみ間接的に関連性があります。ただし、Google Cloud には、サービス アカウントという追加のタイプのユーザー アカウントも含まれています。サービス アカウントはプロジェクトに属し、ID 管理で重要な役割を果たします。
組織ノード
組織は、Google Cloud リソース階層のルートノードであり、プロジェクトとフォルダのコンテナです。組織を使用すると、リソースを階層的に構成できるので、リソースを一元的かつ効率的に管理するうえで非常に重要です。
各組織は、1 つの Cloud Identity アカウントまたは Google Workspace アカウントに属します。組織の名前は、対応する Cloud Identity アカウントまたは Google Workspace アカウントのプライマリ ドメイン名から取得されます。
フォルダ
フォルダは Google Cloud リソース階層のノードであり、プロジェクト、他のフォルダ、またはその両方を含めることができます。フォルダを使用して、共通の Identity and Access Management（IAM）ポリシーまたは組織のポリシーを共有するリソースをグループ化します。これらのポリシーは、フォルダ内のすべてのプロジェクトに自動的に適用され、子フォルダにも継承されます。
フォルダは組織部門と似ていますが、無関係です。組織部門はユーザーを管理し、ユーザーに共通の構成やポリシーを適用するうえで役立ちます。一方、フォルダは Google Cloud プロジェクトを管理し、プロジェクトに共通の設定やポリシーを適用するのに役立ちます。
プロジェクト
プロジェクトはリソースのコンテナです。プロジェクトは、API の管理、課金、リソースへのアクセスの管理で重要な役割を果たします。
ID 管理のコンテキストでは、プロジェクトはサービス アカウントのコンテナであるため、関連性があります。
サービス アカウント
サービス アカウント（または Google Cloud サービス アカウント）は、アプリケーションやその他のタイプのマシンユーザーが使用するための特別なユーザー アカウントです。
各サービス アカウントは Google Cloud プロジェクトに属します。管理対象ユーザーアカウントの場合と同様に、管理者はサービス アカウントのライフサイクルと構成を完全に管理できます。
サービス アカウントでもメールアドレスが ID として使用されますが、管理対象ユーザー アカウントとは異なり、必ず developer.gserviceaccount.com などの Google 所有ドメインが使用されます。
サービス アカウントは連携の対象ではなく、パスワードもありません。Google Cloud では、仮想マシン（VM）や Cloud Run functions などのコンピューティング リソースに対するサービス アカウントが持つ権限を IAM を使用して管理することで、認証情報を管理する必要がなくなります。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 に対しても認証を行うことができます。
次のステップ
- ID 管理のリファレンス アーキテクチャを確認する。