Google Cloud と Active Directory の連携

Last reviewed 2023-02-27 UTC

この記事では、Active Directory を IdP および信頼できるソースとして使用するように Cloud Identity または Google Workspace を構成する方法について説明します。

この記事では、Active Directory の論理構造と Cloud Identity と Google Workspace で使用される構造を比較し、Active Directory のフォレスト、ドメイン、ユーザー、グループをマッピングする方法について説明します。この記事では、シナリオに最適なマッピング方法を決定する際に役立つフローチャートも紹介します。

この記事では、読者が Active Directory について十分に理解していることを前提としています。

連携を実装する

Google Cloud では、認証とアクセス管理に Google ID が使用されます。すべての従業員がすでに Active Directory にアカウントを持っている場合、各従業員の Google ID を手動で管理すると、不要な管理オーバーヘッドが発生する場合があります。Google Cloud と既存の ID 管理システムの間でユーザー ID を連携させることで、Google ID のメンテナンスを自動化できます。さらに、Google ID のライフサイクルを Active Directory の既存ユーザーに結び付けることができます。

Cloud Identity を使用した Active Directory の連携。

Active Directory と Cloud Identity または Google Workspace との間の連携を設定するには、次の 2 つの手順が必要です。

  • ユーザーのプロビジョニング: 関連するユーザーとグループが Active Directory から Cloud Identity または Google Workspace に定期的に同期されます。このプロセスにより、Active Directory で新しいユーザーを作成するときに、関連付けられたユーザーが初回ログインする前でも、Google Cloud で参照できるようになります。このプロセスにより、ユーザーの削除も確実に反映されます。

    プロビジョニングは一方向に機能します。つまり、Active Directory の変更は Google Cloud に複製されますが、その逆は行われません。また、プロビジョニングにはパスワードは含まれません。連携の設定では、Active Directory が認証情報を管理する唯一のシステムとして維持されます。

  • シングル サインオン: ユーザーの認証が必要な場合は常に、Google Cloud が SAML(Security Assertion Markup Language)プロトコルを使用して Active Directory に認証を委任します。この委任により、Active Directory のみがユーザー認証情報を管理すること、そして該当するポリシーまたは多要素認証(MFA)メカニズムが適用されることが確実になります。ただし、ログインが成功するには、それぞれのユーザーが事前にプロビジョニングされている必要があります。

連携を実装するには、以下のツールを使用できます。

  • Google Cloud Directory Sync: Google が無料で提供している、同期プロセスを実装するツールです。Google Cloud Directory Sync はセキュア ソケットレイヤ(SSL)を使用して Google Cloud と通信します。通常、このツールは既存のコンピューティング環境内で稼働します。
  • Active Directory フェデレーション サービス(AD FS): Microsoft が Windows Server の一部として提供しているコンポーネントです。AD FS の利用により、Active Directory を使用した連携認証が可能になります。通常、AD FS は既存のコンピューティング環境内で稼働します。

Google Cloud 用の API は一般公開されていること、さらに SAML はオープン標準であることから、さまざまなツールを使用して連携を実装できます。この記事では Google Cloud Directory Sync と AD FS を使用する場合の方法に焦点を当てます。

Active Directory の論理構造

Active Directory インフラストラクチャの最上位コンポーネントはフォレストです。フォレストは 1 つ以上のドメインを含むコンテナとして機能します。フォレストには、フォレスト ルートドメインにちなんだ名前が付けられます。Active Directory フォレスト内のドメインは互いを信頼し、いずれかのドメインで認証されたユーザーにはフォレスト内の別のドメインにあるリソースへのアクセスを許可します。一方、フォレストについては、フォレスト間の信頼を使用して接続されるのでない限り、個々のフォレストはデフォルトで互いを信頼しません。したがって、あるフォレストで認証されたユーザーでも、別のフォレスト内のリソースにはアクセスできません。

Active Directory のインフラストラクチャ

Active Directory のドメインはリソースを管理するためのコンテナであり、管理上の境界とみなされます。管理の簡素化や他の構造の適用を行うには 1 つのフォレストに複数のドメインを含めるという方法がありますが、フォレスト内のドメインがセキュリティ境界を表すことはありません。

Google Cloud の論理構造

Google Cloud ではすべてのリソースで、組織がコンテナとしての機能を果たします。組織内のリソースは、フォルダやプロジェクトを使用してセグメント化できます。したがって、組織、フォルダ、プロジェクトが Active Directory のドメインと同様の目的を果たします。

Active Directory はユーザーをリソースとして扱うため、ユーザーの管理と認証はドメインに関連付けられます。一方、Google Cloud はサービス アカウントを除き、組織内のユーザーを管理しません。代わりに、Google Cloud では Cloud Identity または Google Workspace を使用してユーザーを管理します。

Cloud Identity アカウントまたは Google Workspace アカウントは、ユーザーとグループのプライベート ディレクトリとして機能します。ユーザーはアカウント管理者として、ユーザーとグループのライフサイクルと設定を制御し、認証の実行方法を定義できます。

Google Cloud の論理構造。

Cloud Identity アカウントまたは Google Workspace アカウントを作成すると、Google Cloud 組織が自動的に作成されます。Cloud Identity アカウントまたは Google Workspace アカウントとそれに関連付けられている Google Cloud 組織は、同じ名前を共有し、互いに関連付けられます。ただし、Google Cloud 組織は、他の Cloud Identity アカウントまたは Google Workspace アカウントのユーザーとグループを参照できます。

Active Directory と Google Cloud の統合

Active Directory と Google Cloud の論理構造には特定の類似点があるとは言え、これら 2 つの構造をマッピングするのにすべてのシナリオで共通して適用できる最良の方法というものはありません。2 つのシステムを統合して構造をマッピングする際の正しいアプローチは、次の複数の要素によって左右されます。

  • ドメインとフォレストを Cloud Identity アカウントまたは Google Workspace アカウントにマッピングする方法
  • DNS ドメインをマッピングする方法
  • ユーザーをマッピングする方法
  • グループをマッピングする方法

以降のセクションで、上記のそれぞれの要素について説明します。

フォレストのマッピング

特に大規模な組織では、企業全体の ID とアクセスを管理するために、複数の Active Directory ドメインを使用する場合がよくあります。Active Directory と Google Cloud の連携を計画する際に最初に考慮すべき要素は、Active Directory インフラストラクチャのトポロジです。

単一フォレスト、単一ドメイン

単一フォレスト、単一ドメイン。

フォレストに含まれるドメインが 1 つだけの場合、Active Directory フォレスト全体を 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにマッピングできます。このアカウントを 1 つの Google Cloud 組織の管理単位として使用して、Google Cloud リソースを管理できます。

単一ドメイン環境では、ドメイン コントローラとグローバル カタログ サーバーの両方が、Active Directory 内で管理されているすべてのオプジェクトへのアクセスを提供します。ほとんどの場合、ユーザー アカントとグループを Google Cloud に同期するにも、シングル サインオンを処理する単一の AD FS インスタンスまたはフリートを保守するにも、1 つの Google Cloud Directory Sync インスタンスを実行するだけで対処できます。

単一フォレスト、複数ドメイン

単一フォレスト、複数ドメイン。

フォレストに複数の Active Directory ドメインが含まれている場合、それらのドメインを 1 つ以上のドメインツリーで編成できます。どちらの場合も、フォレスト全体を 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにマッピングできます。このアカウントを 1 つの Google Cloud 組織の管理単位として使用して、Google Cloud リソースを管理できます。

マルチドメイン環境では、ドメイン コントローラから取得できる情報と、グローバル カタログ サーバーに対するクエリによって取得できる情報には違いがあります。ドメイン コントローラから取得できるのは、そのドメイン コントローラが処理するローカル ドメイン内のデータだけです。一方、グローバル カタログ サーバーはフォレストに含まれるすべてのドメイン内の情報へのアクセスを提供します。重要な点として、グローバル カタログ サーバーから提供されるデータは部分的なものであり、特定の LDAP 属性が欠落しています。この制限は、グループを同期するように Google Cloud Directory Sync を構成する方法に影響を与える場合があります。

グループのマッピングに予定している方法によっては、マルチドメイン フォレストを Google Cloud と連携させるためには、1 つ以上