Google Cloud Platform と Active Directory の連携: 概要

この記事は、Active Directory ベースの既存の ID 管理ソリューションを Google Cloud Platform(GCP)に拡張する方法について説明する、複数のパートからなるシリーズの第 1 部です。この記事では、ハイブリッド コンピューティング環境内で一貫した認証および承認メカニズムを確立する方法を説明します。この記事では Cloud Identity を使用した方法に焦点を当てますが、説明の一部は G Suite にも適用されます。

このシリーズは次のパートで構成されています。

多くの場合、企業の IT 部門はユーザー アカントを管理する際もアプリケーションやコンピューティング リソースへのアクセスを制御する際も、Active Directory に依存しています。この依存性により、Active Directory は IT 環境とオンプレミス インフラストラクチャの基盤となっています。

ハイブリッド戦略の一環として既存の IT 環境を GCP に拡張する場合は、ID を管理する場所を 1 か所に維持することをおすすめします。ID 管理ソリューションが 1 つに統一されていれば、管理作業が最小限になるだけでなく、ハイブリッド環境全体でユーザーとアプリケーションの安全な認証を確実に実施できます。

この記事では Active Directory と GCP の論理構造を比較し、これら 2 つの連携を実装するために Active Directory アカウントを GCP のユーザー アカウントとグループ アカウントにマッピングするさまざまな方法を説明します。実際のシナリオに最適な Active Directory と GCP のマッピング方法を判断できるよう、記事の最後にフローチャートを記載します。

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

連携を実装する

GCP での認証とアクセス管理には Google の ID が使用されます。従業員に Google の ID がなければ、その従業員は GCP のリソースにアクセスできません。しかしながら各従業員の Google ID を手動で管理するとなると手間がかかります。全従業員のアカウントがすでに Active Directory に登録されているのであれば、Active Directory と GCP の間でユーザー ID を連携させるという方法で、Google アカウントの保守を自動化できます。さらに、Google アカウントのライフサイクルを Active Directory 内のアカウントに関連付けることもできます。連携によって、次の処理が確実に行われます。

  • Active Directory が、ID 管理の唯一の情報源として維持されること。
  • Active Directory 内のすべてのユーザー アカウント、または選択したサブセットに対して、Google ユーザー アカウントが自動的に作成されること。
  • Active Directory 内でアカウントが無効化または削除された場合、対応する Google アカウントも停止または削除されること。それとは対照的に、Google アカウントが停止または削除されても Active Directory には影響しません。次の同期の際に、Google アカウントが自動的に再作成されるためです。
  • ユーザー認証が Active Directory によって処理されること。したがって、パスワードを GCP に同期する必要はありません。

Google 側では、Cloud Identity を使用してユーザー アカウントの非公開ディレクトリを設定し、そのディレクトリ内で Google アカウントを作成して管理できます。Cloud Identity を使用した Active Directory の連携には、次の 2 つのプロセスが伴ないます。

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

  • アカウントの同期: 関連するユーザー アカウントとグループが定期的に Active Directory から Cloud Identity に同期されます。このプロセスにより、Active Directory で新しいアカウントを作成すると、そのアカウントに関連付けられているユーザーが初めてログインする前であっても GCP でそのアカウントを参照できます。また、アカウントの削除も確実に伝播されます。

    同期は一方向で行われます。つまり、Active Directory 内の変更は Cloud Identity にレプリケートされますが、その逆は行われません。また、パスワードは同期されません。連携の設定では、Active Directory が認証情報を管理する唯一のシステムとして維持されます。

  • シングル サインオン: GCP でユーザーが認証を必要とするときは常に、Cloud Identity が Security Assertion Markup Language(SAML)プロトコルを使用して Active Directory に認証を委任します。この委任により、Active Directory のみがユーザー認証情報を管理すること、そして該当するポリシーまたは多要素認証(MFA)メカニズムが適用されることが確実になります。ただし、ログインが成功するには、該当するアカウントがあらかじめ同期されている必要があります。

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

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

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

Active Directory の論理構造

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

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

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

GCP の論理構造

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

Active Directory はユーザー アカウントをリソースとして扱うため、ユーザー アカウントの管理と認証はドメインに関連付けられます。それとは対照的に、GCP はサービス アカウントを除き、組織内でユーザー アカウントを管理しません。代わりに、GCP は Cloud Identity または G Suite に依存してユーザー アカウントを管理します。

Cloud Identity を使用すると、ユーザー アカウントやグループ用の限定公開ディレクトリを作成して管理できます。こうしたディレクトリはそれぞれ独立して管理されるため、たとえば使用可能な認証方法や適用するパスワード ポリシーをディレクトリによって変えることができます。Cloud Identity では、ディレクトリは「Cloud Identity アカウント」と呼ばれ、ドメイン名で識別されます。

GCP の ID のインフラストラクチャ

Active Directory ではフォレストとフォレスト ルートドメインが必ず一緒に作成されるのと同様に、Cloud Identity アカウントは必ず GCP 組織とあわせて作成されます。また、フォレスト ルートドメインとフォレストは同じ名前を共有し、互いを切り離すことができないのと同じく、Cloud Identity アカウントと GCP 組織は同じ名前を共有し、互いに関連付けられます。ただし、GCP 組織は他の Cloud Identity アカウントに属するユーザーやグループを参照できます。

Active Directory と GCP の統合

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

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

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

フォレストのマッピング

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

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

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

フォレストにドメインが 1 つしか含まれていなければ、Active Directory フォレスト全体を単一の Cloud Identity アカウントにマッピングできます。このアカウントを 1 つの GCP 組織の管理単位として使用して、GCP リソースを管理できます。

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

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

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

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

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

グループのマッピングに予定している方法によっては、マルチドメイン フォレストを GCP と連携させるためには、1 つ以上の Cloud Directory Sync インスタンスを実行する一方、シングル サインオンについては単一の AD FS インスタンスまたはフリートで処理しなければならない場合があります。

フォレスト間の信頼がある複数のフォレスト

フォレスト間の信頼がある複数のフォレスト

大規模な組織では、合併や買収の結果、複数の Active Directory フォレストが存在することは珍しくありません。こうした複数のフォレストを結合するには、双方向でのフォレスト間の信頼を使用します。これにより、ユーザーが各フォレストの境界を超えてリソースを共有したり、リソースにアクセスしたりできます。

すべてのフォレストが他のフォレストと双方向での信頼関係を持っていれば、その環境全体を単一の Cloud Identity アカウントにマッピングできます。このアカウントを 1 つの GCP 組織の管理単位として使用して、GCP リソースを管理できます。

グローバル カタログ サーバーは複数のドメイン内のデータへのアクセスを提供しますが、そのスコープは単一のフォレストに制限されます。したがってマルチフォレスト環境では、たとえばユーザー アカウントの完全なリストを取得するには複数のドメイン コントローラまたは複数のグローバル カタログ サーバーに対してクエリを行う必要があります。この制限により、マルチフォレスト環境を GCP と連携させるには、フォレストごとに少なくとも 1 つの Cloud Directory Sync インスタンスが必要になります。フォレスト間の信頼を使用すれば、フォレストの境界を超えてユーザー認証が機能するため、シングル サインオンを処理するには単一の AD FS インスタンスまたはフリートがあれば十分です。

フォレスト間の信頼がない複数のフォレストにまたがる環境でも、GCP との連携に関連するすべての Active Directory ドメインが外部の信頼を介して接続されている場合は、上記と同じ考慮事項が適用されます。

フォレスト間の信頼がない複数のフォレスト

フォレスト間の信頼がない複数のフォレスト

上の図に示されている環境では、フォレストの境界を超えて認証を行ったりリソースにアクセスすることは不可能です。また、単一の AD FS インスタンスまたはフリートですべてのフォレストからのユーザー シングル サインオン リクエストを処理することもできません。

したがって、フォレスト間の信頼がない複数のフォレストを単一の Cloud Identity アカウントにマッピングすることはできません。代わりに、各フォレストを別個の Cloud Identity アカウントにマッピングする必要があります。それには、フォレストごとに少なくとも 1 つの Cloud Directory Sync インスタンスと少なくとも 1 つの AD FS サーバーまたはフリートを実行しなければなりません。

GCP では、Cloud Identity アカウントごとに別個の組織が作成されます。ほとんどの場合、ユーザーが複数の異なる組織を保守する必要はありません。組織のいずれかを選択して、別の Cloud Identity アカウントにその組織を関連付けると、実質的に複数の Active Directory フォレストと連携する組織が作成されます。選択した以外の組織は未使用のままになります。

DNS ドメインのマッピング

DNS は Active Directory 内でも Cloud Identity においても重要な役割を果たします。Active Directory と GCP の連携を計画する際に考慮すべき 2 番目の要素は、Active Directory と GCP の間で DNS ドメインをマッピングする方法です。

Active Directory での DNS ドメインの使用法

Active Directory フォレストでは、次のようにさまざまなところで DNS ドメインが使用されます。

  • Active Directory DNS ドメイン: 各 Active Directory ドメインが 1 つの DNS ドメインに相当します。このドメインは、おそらくはグローバル ドメイン(corp.example.com など)ですが、ローカル ドメイン名(corp.localcorp.internal など)である場合もあります。
  • メール交換(MX)ドメイン: メールアドレスで DNS ドメインが使用されます。このドメインは Active Directory DNS ドメインと同じであることもありますが、通常は異なり、多くの場合は短縮されたドメイン(example.com など)が使用されます。理想的には、Active Directory 内のユーザー アカウントにはオプションの mail 属性を関連付けたメールアドレスが割り当てられます。
  • UPN サフィックス ドメイン: これらのドメインはユーザー プリンシパル名(UPN)に使用されます。デフォルトでは、アカウントのドメインの Active Directory DNS ドメインを使用して UPN が作成されます。たとえば corp.example.com ドメイン内のユーザー john の UPN はデフォルトで john@corp.example.com となります。ただし、Active Directory DNS ドメインにも MX ドメインにも相当しない別の DNS ドメインを UPN サフィックスとして使用するようにフォレストを構成することもできます。UPN はオプションであり、ユーザー アカウントの userPrincipalName フィールドに格納されます。
  • エンドポイント ドメイン: 通常、AD FS サーバーなどの一般公開されるサーバーには DNS 名(login.external.example.com など)が割り当てられます。こうした目的で使用されるドメインは、MX、UPN サフィックス、または Active Directory DNS ドメインと重複する場合も、まったく異なるドメインである場合もあります。

GCP での DNS ドメインの使用法

GCP が認証の際に依存する Google Identity Platform では、メールアドレスを使用してユーザーを識別します。メールアドレスを使用すると、それぞれがグローバルに一意であることが保証されるだけでなく、GCP が該当するメールアドレスに通知メッセージを送信することもできます。

Google Identity Platform ではメールアドレスの @ の後に続くドメインの部分に基づいて、ユーザーの認証に使用する ID プロバイダを決定します。たとえば、gmail.com ドメインを使用するメールアドレスの場合、Google Identity Platform は Gmail ユーザー アカウントのディレクトリを使用して認証を行います。

GCP での DNS ドメインの使用法

G Suite または Cloud Identity にアカウントを登録すると、実際のところ限定公開ディレクトリを作成することになります。Google Identity Platform ではこの限定公開ディレクトリを認証の際に使用できます。Gmail ディレクトリが gmail.com ドメインに関連付けられるのと同じように、G Suite アカウントや Cloud Identity アカウントにはカスタム ドメインを関連付ける必要があります。それには次の 3 種類のドメインが使用されます。

  • プライマリ ドメイン: このドメインは Cloud Identity ディレクトリを識別します。これはまた、GCP 内での組織の名前としても使用されます。Cloud Identity に登録する際は、このドメイン名を指定する必要があります。
  • セカンダリ ドメイン: プライマリ ドメインとあわせて、追加のセカンダリ ドメインを Cloud Identity ディレクトリに関連付けることができます。ディレクトリ内の各アカウントには、プライマリ ドメインか、セカンダリ ドメインのうちのいずれかが関連付けられます。したがって、ディレクトリのプライマリ ドメインが example.com で、セカンダリ ドメインが secondary.example.com の場合、johndoe@example.comjohndoe@secondary.example.com という 2 つのアカウントはそれぞれ別のアカウントとみなされます。
  • エイリアス ドメイン: エイリアス ドメインは、プライマリ ドメインの代替ドメインです。つまり、alias.example.com がエイリアス ドメインとして設定されている場合、johndoe@example.comjohndoe@alias.example.com は同じアカウントを指します。エイリアス ドメインで代替名を指定できるのはプライマリ ドメインに対してのみです。セカンダリ ドメインのエイリアス ドメインを追加することはできません。

すべてのドメインは、次の要件を満たす必要があります。

  • 有効なグローバル DNS ドメイン名でなければなりません。Active Directory で一般的に使用されている corp.localcorp.internal などのローカル ドメイン名は許可されません。ドメイン設定時には、ドメイン所有権を確認するために、該当する DNS ゾーンに対する管理アクセス権限が必要になる場合があります。
  • example.com などのドメインで参照できるディレクトリは 1 つだけです。ただし、subdomain.example.com などのさまざまなサブドメインを使用して異なるディレクトリを参照できます。
  • プライマリ ドメインとセカンダリ ドメインには有効な MX レコードが必要です。これにより、該当するドメイン名を使用して生成されたメールアドレスへの送信メッセージを適切に配信できます。

ディレクトリ間の同期を可能にするには、Active Directory ドメインと、Cloud Identity が使用するディレクトリとの間になんらかのマッピングが必要です。正しいマッピングは、Active Directory をどのように使用しているかによって異なります。また、正しいマッピングを判断するには、Active Directory フォレスト内でのユーザー アカウントの識別方法と、それらのユーザー アカウントを Cloud Identity にどのようにマッピングできるかを詳しく調べる必要があります。

ユーザー アカウントのマッピング

Active Directory と GCP の連携を計画する際に考慮すべき 3 番目の要素は、Active Directory と GCP の間でユーザー アカウントをマッピングする方法です。

Active Directory 内でのユーザー アカウントの識別

Active Directory では、ユーザー アカウントを一意に識別するために内部で 2 つの識別子が使用されます。

  • objectGUID: これはユーザーの作成時に生成される、グローバルに一意の ID です。この ID が変更されることはありません。
  • objectSID: この SID(セキュリティ識別子)は、すべてのアクセス チェックで使用されます。この ID はドメイン内で一意であり、変わることはありません。ただし、アカウントがフォレスト内の別のドメインに移動された場合は、そのアカウントに新しい SID が割り当てられる可能性があります。

ユーザーにとっては、上記の ID はいずれも意味を持ちません。そのため、Active Directory では人間がユーザー アカウントを識別しやすいように 2 つの識別手段を用意しています。

  • UPN(userPrincipalName): ユーザー アカウントを識別するのに推奨される手段は UPN です。UPN は RFC 822 形式のメールアドレスの準拠しており、ユーザー名と UPN サフィックス ドメインを結合して作成されます(例: johndoe@corp.example.com)。UPN はユーザー アカウントを識別するのに推奨される手段ではありますが、これはオプションであるため、Active Directory フォレスト内のユーザー アカウントによっては UPN がない可能性もあります。

    UPN を有効なメールアドレスにすることがおすすめ方法とみなされていますが、Active Directory ではこの手法を強制していません。

  • Windows 2000 以前のログオン名(sAMAccountName): このログオン名は、NetBIOS ドメイン名とユーザー名を domain\user の形式で結合したものです(例: corp\johndoe)。これらの名前はレガシーとみなされますが、今でも一般的に使用されていて、ユーザー アカウントに唯一必須の識別子となっています。

注意する点として、Active Directory ではユーザーの識別にユーザーのメールアドレス(mail)を使用しません。したがって、このフィールドは必須でもなければ、フォレスト内で一意にする必要もありません。

これらの識別子はいずれも随時、変更できます。

アカウント ID のマッピング

Active Directory アカウントを Cloud Identity アカウントにマッピングするには、各ユーザー アカウントに関する 2 つの情報が必要です。

  • 同期の際にどの Active Directory アカウントがどの Cloud Identity アカウントに対応しているかを追跡するために使用できる、変わることのない一意の ID。AD 側でこの目的を果たすのに最適な ID は、objectGUID です。
  • ドメインの部分が Cloud Identity のプライマリ ドメイン、セカンダリ ドメイン、またはエイリアス ドメインに相当するメールアドレス。このメールアドレスは GCP 全体で使用されるため、意味のあるアドレスであることを確認してください。objectGUID からアドレスを派生させるという方法は実際的ではありません。他の方法で自動的に生成されるメールアドレスにしても同じことです。

Active Directory ユーザー アカウントのフィールドのうち、Cloud Identity メールアドレスを提供する候補となるのは userPrincipalNamemail の 2 つです。

ユーザー プリンシパル名によるマッピング

userPrincipalName フィールドを使用する場合、同期の対象となるすべてのアカウントが次の 2 つの条件を満たす必要があります。

  • UPN が有効なメールアドレスであること。また、UPN サフィックス ドメインとして使用されているすべてのドメインが MX ドメインであり、かつ、ユーザーの UPN に送信されるメールがそのユーザーのメール受信トレイに配信されるように設定されていることも必要です。
  • UPN 割り当てが完了していること。同期の対象となるすべてのユーザー アカウントに UPN が割り当てられている必要があります。UPN が割り当てられていないアカウントを調べるには、次の PowerShell コマンドが役立ちます。

    Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

以上の 2 つの条件が満たされていれば、UPN を問題なく Cloud Identity メールアドレスにマッピングできます。UPN サフィックス ドメインのいずれかを Cloud Identity 内のプライマリ ドメインとして使用し、他の UPN サフィックス ドメインをセカンダリ ドメインとして追加できます。

いずれかの条件が満たされていなくても UPN を Cloud Identity メールアドレスにマッピングできますが、その場合は、次の点に注意してください。

  • UPN が有効なメールアドレスでなければ、ユーザーは GCP から送信される通知メールを受け取れません。それによって、ユーザーが重要な情報を見逃す可能性があります。
  • UPN が割り当てられていないアカウントは、同期の際に無視されます。
  • UPN サフィックス ドメインを別のドメインに置き換えるように同期を構成できます。ただし、フォレスト内で複数の UPN サフィックス ドメインを使用している場合、この方法を採ると、すべての UPN サフィックス ドメインが単一のドメインで置き換えられるため、重複が生じる可能性があります。アカウントが重複している場合、そのうち 1 つのアカウントしか同期されません。

UPN を使用してユーザーをマッピングする主な利点として、UPN はフォレスト全体で一意であることが保証されています。また、UPN はキュレートされたドメインのセットを使用するため、潜在的な同期の問題を回避するのに役立ちます。

メールアドレスによるマッピング

mail フィールドを使用する場合、同期の対象となるすべてのアカウントが次の条件を満たす必要があります。

  • メールの割り当てが完了していること。同期の対象となるすべてのユーザー アカウントの mail フィールドに値が入力されている必要があります。このフィールドに値が入力されていないアカウントを調べるには、次の PowerShell コマンドが役立ちます。

    Get-ADUser -LDAPFilter "(!mail=*)"
  • キュレートされたドメインのセットをメールアドレスで使用していて、それらのドメインのすべてを自分が所有していること。アカウントの中にパートナー会社や消費者向けメール プロバイダを参照するメールアドレスを使用しているものがある場合、それらのメールアドレスは使用できません。

  • すべてのメールアドレスがフォレスト全体で一意であること。Active Directory では一意性を強制しないため、カスタム チェックまたはポリシーを実装しなければならない場合があります。

関連するアカウントのすべてが上記の条件を満たしている場合、これらのメールアドレスで使用されているドメインのすべてを識別して、それらのドメインを Cloud Identity 内のプライマリ ドメインやセカンダリ ドメインとして使用できます。

いずれかの条件が満たされていなくても UPN を Cloud Identity メールアドレスにマッピングすることはできますが、その場合は、次の点に注意してください。

  • 同期の際に、メールアドレスがないアカウントは無視されます。また、メールアドレスがあるアカウントでも、そのメールアドレスで Cloud Identity ディレクトリに関連付けられていないドメインが使用されている場合は無視されます。
  • 2 つのアカウントが同じメールアドレスを共有している場合、いずれか 1 つのアカウントだけが同期されます。
  • メールアドレスのドメインを別のドメインに置き換えるように同期を構成できます。ただし、このプロセスによって重複が生じる可能性があります。その場合、重複するアカウントのうち、いずれか 1 つだけが同期されます。

グループのマッピング

Active Directory と GCP の連携を計画する際に考慮すべき 4 番目の要素は、Active Directory と GCP の間でグループを同期するかどうか、同期する場合はどのようにグループをマッピングするかです。

GCP では、複数のプロジェクトで効率的にアクセスを管理する一般的な手段としてグループが使用されます。各プロジェクトで個々のユーザーを Cloud Identity and Access Management(Cloud IAM)の役割に割り当てるのではなく、組織での一般的な役割をモデル化した一連のグループを定義し、それらのグループを一連の Cloud IAM 役割に割り当てます。この場合、グループのメンバーシップを変更するだけで、一連のすべてのリソースに対するユーザーのアクセス権限を制御できます。

Active Directory では、配信グループとセキュリティ グループという 2 種類のグループを区別しています。配信グループは、メールリストを管理するために使用されます。Microsoft Exchange から G Suite に移行する場合、Cloud Directory Sync が通常の配信グループと動的配信グループの両方を処理できるよう、配信グループを同期する必要があります。ただし、GCP の ID およびアクセス管理では、配信グループは重要ではありません。したがって、ここではセキュリティ グループについてのみ説明します。

Active Directory と GCP の間でのセキュリティ グループのマッピングはオプションです。ユーザー アカウントが連携するようになったら、Cloud Identity 内で直接グループを作成して管理できます。つまり、Active Directory は ID 管理に関しては中央システムであり続けますが、アクセス管理に関してはそうではなくなるということです。Active Directory を ID 管理とアクセス管理の中央システムとして維持するには、セキュリティ グループを Cloud Identity で管理するのではなく、Active Directory から同期することをおすすめします。このアプローチを使用すれば、Active Directory 内のグループ メンバーシップを使用して GCP 内の特定のリソースへのアクセスを許可するユーザーを制御できるように Cloud IAM を設定できます。

Active Directory 内のセキュリティ グループ

セキュリティ グループは、Windows セキュリティと Active Directory アクセス管理の基礎としての役割を果たします。この役割を補完するために、Active Directory にはドメイン ローカル グループ、グローバル グループ、ユニバーサル グループという 3 種類のグループがあります。

AD でのセキュリティ グループ

ドメイン ローカル グループ
これらのグループが関連するのは単一ドメインのスコープ内のみです。したがって、他のドメインで参照できません。ドメイン ローカル グループのメンバーリストをフォレスト全体でレプリケートする必要はないため、グループに含めることができるメンバーのタイプという点では、最も柔軟性のあるグループです。
グローバル グループ
これらのグループは他のドメインに対して表面化されるため、他のドメインでも参照できます。ただし、メンバーリストはレプリケートされません。この制限により、これらのグループには限られたタイプのメンバーしか含めることができません。これらのグループに含めることができるのは、同じドメイン内のユーザー アカウントと他のグローバル グループのみです。
ユニバーサル グループ
これらのグループは、そのメンバーリストとあわせてフォレスト全体でレプリケートされます。したがって、他のドメインで参照できるだけでなく、これらのグループにはユーザー アカウントと他のユニバーサル グループに加え、すべてのドメインのグローバル グループを含めることもできます。

Active Directory フォレストに 1 つのドメインしか含まれていなければ、Cloud Directory Sync を使用して上記の 3 種類すべてのセキュリティ グループを同期できます。Active Directory フォレストで複数のドメインを使用している場合、グループを Cloud Identity に同期できるかどうか、同期できる場合はどのように同期するかは、グループのタイプによって決まります。

ドメイン ローカル グループとグローバル グループはフォレスト全体で完全にはレプリケートされないため、グローバル カタログ サーバーに格納されるこれらのグループに関する情報は不完全です。この制限は意図的なものであり、ディレクトリのレプリケーションを高速化するのに役立ちますが、こうしたグループを Cloud Identity に同期させる場合はその妨げとなります。具体的には、グローバル カタログ サーバーをソースとして使用するように Cloud Directory Sync を構成すると、このツールはフォレスト全体ですべてのドメインからグループを検出できます。ただし、メンバーリストが含まれていてレプリケーションに適切なグループは、グローバル カタログ サーバーと同じドメイン内にあるグループだけです。マルチドメイン フォレスト内のドメイン ローカル グループやグローバル グループを同期させるには、ドメインごとに個別の Cloud Directory Sync インスタンスを実行する必要があります。

ユニバーサル グループはフォレスト全体で完全にレプリケートされるため、こうした制限はありません。1 つの Cloud Directory Sync インスタンスで複数のドメイン内にあるユニバーサル グループを同期できます。

複数の Active Directory ドメインを Cloud Identity に同期させるためには複数の Cloud Directory Sync インスタンスが必要であると結論付ける前に、すべてのグループを同期しなければならないわけではない場合もあるので注意してください。このことから、Active Directory フォレスト全体で各種のセキュリティ グループが一般にどのように使用されているかを調べる価値はあります。

Active Directory でのセキュリティ グループの使用法

リソース グループ

Windows ではアクセス制御リスト(ACL)ベースのアクセスモデルを使用しています。ファイルや LDAP オブジェクトなどのリソースごとに、そのリソースにアクセスできるユーザーを制御する ACL が関連付けられます。リソースと ACL はかなり細分化されることから、ACL はかなりの数に上ります。したがって、ACL の保守を簡素化するために、「リソース グループ」を作成して使用頻度やアクセス頻度が高いリソースをまとめるのが一般的です。リソース グループを関連する ACL に追加した後は、ACL を変更するのではなく、リソース グループのメンバーシップを変更するだけでアクセスを管理できます。

このようにまとめられるリソースは、一般に単一のドメイン内にあります。このことから、リソース グループは 1 つのドメイン内のみで ACL または他のリソース グループで参照される傾向があります。ほとんどのリソース グループはローカルであるため、通常は Active Directory 内でドメイン ローカル グループを使用して実装されます。

役割グループと組織グループ

リソース グループはアクセス管理を簡素化するのに役立ちますが、大規模な環境では多数のリソース グループに新しいユーザーを追加しなければならない場合があります。このことから、リソース グループは一般に「役割グループ」または「組織グループ」によって補完されます

役割グループは、組織内での特定の役割に必要な権限を集約したものです。たとえば、エンジニアリング ドキュメント閲覧者という名前の役割グループは、すべてのエンジニアリング ドキュメントに対する読み取り専用アクセス権限をメンバーに付与します。実際には、役割グループを作成し、その役割グループを各種のドキュメントへのアクセス制御に使用するすべてのリソース グループのメンバーにすることでこれを実現します。

同様に、組織グループは組織内の部門に必要な権限を集約したものです。たとえば、エンジニアリングという名前の組織グループは、エンジニアリング部門のメンバーが共通して必要とするすべてのリソースへのアクセス権限を付与します。

技術的には、役割グループとリソース グループの間に違いはなく、一般的にこの 2 つは同時に使用されます。ただし、役割グループと組織グループはリソース グループとは異なり、ドメインの境界を超えた関連性を持つことができます。役割グループや組織グループを他のドメイン内のリソース グループで参照できるようにするために、これらのグループは通常、グローバル グループを使用して実装されます。このように実装されるグループのメンバーは 1 つのドメインのメンバーに制約されます。場合によっては、別のドメインからのメンバーを許容できるよう、ユニバーサル グループで補完されることもあります。

次の図は、マルチドメイン Active Directory 環境で一般的に使用されるネストパターンを示しています。

マルチドメイン AD 環境で使用されるネストパターン

Cloud Identity でのグループ

Cloud Identity には 1 種類のグループしかありません。このグループは Active Directory でのユニバーサル グループと同じように動作します。つまり、グループはそれが定義されている Cloud Identity アカウントのスコープに制限されず、他の Cloud Identity アカウントに属するユーザー アカウントを含めることもできます。これらのグループは他の Cloud Identity アカウント内で参照したりネストしたりできるため、任意の GCP 組織で使用できます。

Active Directory でのグループとは異なり、Cloud Identity でのグループのメンバーには、同じグループの他のメンバーを一覧表示する権限が暗黙的に付与されません。グループ メンバーシップのクエリを行うには、通常、明示的な承認が必要となります。

GCP でのグループの使用法

GCP では ACL ベースのアクセスモデルではなく役割ベースのアクセスモデルを使用しています。役割は、特定のスコープ内にある特定の種類のすべてのリソースに適用されます。たとえば、Kubernetes Engine デベロッパーの役割には、特定のプロジェクトのすべてのクラスタに含まれる Kubernetes API オブジェクトに対するフルアクセスが許可されます。役割の性質上、GCP 上でリソース グループを保守する必要はほとんどありません。さらに、リソース グループを GCP に同期する必要もめったにありません。

役割グループと組織グループは多数のユーザーのアクセスを管理しやすくするためのものであることから、GCP でも Active Directory での場合と同じ関連性があります。役割グループと組織グループを同期すると、Active Directory を主要なアクセス管理システムとして維持するのに役立ちます。

役割グループと組織グループの同期

リソース グループをドメイン ローカル グループとして、役割グループと組織グループをグローバル グループまたはユニバーサル グループとして一貫して実装すると、グループタイプに基づいて役割グループと組織グループだけを確実に同期できます。

マルチドメイン フォレストごとに 1 つの Cloud Directory Sync インスタンスを実行するだけで十分なのか、あるいは複数の Cloud Directory Sync インスタンスが必要になるのかという質問は、グローバル グループを使用するかどうかという質問になります。ユニバーサル グループを使用して役割グループと組織グループのすべてを実装する場合は、1 つの Cloud Directory Sync インスタンスで十分です。そうでなければ、ドメインごとに Cloud Directory Sync インスタンスが必要になります。

グループ ID のマッピング

Active Directory のセキュリティ グループを Cloud Identity のグループにマッピングするには、共通識別子が必要です。Cloud Identity ではこの識別子として、ドメインの部分が Cloud Identity のプライマリ ドメイン、セカンダリ ドメイン、またはエイリアス ドメインに相当するメールアドレスを使用する必要があります。このメールアドレスは GCP 全体で使用されるため、人間が読んで理解できるアドレスでなければなりません。メールアドレスがメールボックスに対応している必要はありません。

Active Directory では、グループを識別するためにグループの共通名(cn)または Windows 2000 以前のログオン名(sAMAccountName)が使用されます。ユーザー アカウントと同様にグループにもメールアドレス(mail)を割り当てることはできますが、グループのメールアドレスはオプションの属性であり、Active Directory は一意性を検証しません。

Active Directory と Cloud Identity の間でグループ ID をマッピングするには、2 つのオプションがあります。

共通名によるマッピング

共通名(cn)を使用する利点としては、共有名は可用性が保証されていること、そして少なくとも組織部門内では一意であることが挙げられます。ただし、共有名はメールアドレスではないため、サフィックス(@[DOMAIN])を付加してメールアドレスに変換する必要があります。

Cloud Directory Sync は、グループ名へのサフィックスの付加を自動的に処理するように構成できます。Active Directory ではグループ名とユーザー アカウント名が競合しないようなっているため、このようにして生成されたメールアドレスでも競合が発生する可能性はほぼありません。

Active Directory フォレストに複数のドメインが含まれている場合は、次の点に注意してください。

  • 異なるドメイン内にある 2 つのグループが共通名を共有している場合、それぞれのグループに生成されるメールアドレスで競合が発生し、同期の際にいずれかのグループが無視されます。
  • 単一のフォレストに含まれるドメイン内のグループだけを同期できます。それぞれの個別の Cloud Directory Sync インスタンスを使用して複数のフォレスト内のグループを同期する場合、共通名から生成されるメールアドレスには、その共通名に対応するフォレストが反映されません。この曖昧さにより、Cloud Directory Sync インスタンスは以前に他の Cloud Directory Sync インスタンスによって別のフォレストから作成されたグループを削除します。
  • ドメイン置換を使用してユーザー アカウントをマッピングしている場合、共通名でグループをマッピングすることはできません。

メールアドレスによるマッピング

メールアドレス(mail)を使用してグループ ID をマッピングするということは、メールアドレスを使用してアカウント ID をマッピングする場合と同じく、次の条件を満たさなければならないことを意味します。

  • メールの割り当てが完了していること。配信グループには一般にメールアドレスが割り当てられますが、セキュリティ グループにこの属性が欠落している場合は珍しくありません。メールアドレスを使用して ID をマッピングするには、同期の対象となるセキュリティ グループの mail フィールドに値が入力されている必要があります。このフィールドに値が入力されていないアカウントを調べるには、次の PowerShell コマンドが役立ちます。

    Get-ADGroup -LDAPFilter "(!mail=*)"
  • キュレートされたドメインのセットをメールアドレスで使用していて、それらのドメインのすべてを自分が所有していること。アカウントの中にパートナー会社や消費者向けメール プロバイダを参照するメールアドレスを使用しているものがある場合、それらのメールアドレスは使用できません。

  • すべてのメール アカウントがフォレスト全体で一意であること。Active Directory では一意性を強制しないため、カスタム チェックまたはポリシーを実装しなければならない場合があります。

関連するグループのすべてが上記の条件を満たしている場合、これらのメールアドレスで使用されているドメインのすべてを識別して、Cloud Identity に登録されている DNS ドメインのリストで該当するドメインがすべてカバーされていることを徹底できます。

いずれかの条件が満たされていなくても UPN を Cloud Identity メールアドレスにマッピングすることはできますが、その場合は、次の点に注意してください。

  • 同期の際に、メールアドレスがないグループは無視されます。また、メールアドレスがあるグループでも、そのメールアドレスで Cloud Identity ディレクトリに関連付けられていないドメインが使用されている場合は無視されます。
  • 2 つのグループが同じメールアドレスを共有している場合、いずれか 1 つのグループだけが同期されます。

Active Directory フォレストに複数のドメインが含まれていて、ドメイン置換を使用してユーザー アカウントをマッピングしている場合、メールアドレスでグループをマッピングすることはできません。

組織部門のマッピング

ほとんどの Active Directory ドメインでは、リソースをクラスタ化して階層構造に編成する際、アクセスを制御する際、ポリシーを適用する際など、組織部門を広く利用します。

GCP ではフォルダとプロジェクトが同じような目的を果たしますが、GCP 組織内で管理されるリソースの種類は Active Directory 内で管理されるリソースとは大幅に異なります。そのため、企業に適切な GCP フォルダ階層は Active Directory での組織部門の構造とは顕著に異なる傾向があります。したがって、組織部門を自動的にフォルダとプロジェクトにマッピングするという方法はほぼ不可能であり、Cloud Directory Sync でもサポートされていません。

Cloud Identity では、フォルダとは無関係に組織部門のコンセプトをサポートしています。Active Directory の場合と同様に、組織部門はユーザー アカウントをクラスタ化して編成するために作成されます。ただし Active Directory での場合とは異なり、組織部門はグループではなくユーザー アカウントにのみ適用されます。

Cloud Directory Sync には、Active Directory の組織部門を Cloud Identity の組織部門に同期するオプションが用意されています。Active Directory の ID 管理を GCP に拡張するためだけに Cloud Identity を使用するというシナリオでは、通常、組織部門をマッピングする必要はありません。

正しいマッピングを選択する

この記事の冒頭で述べたように、Active Directory と GCP の構造をマッピングする際に、あらゆるシナリオに共通して適用できる最良の方法というものはありません。シナリオに適切なマッピングを選択できるよう、これまでのセクションで説明した条件を以下の決定グラフにまとめます。

まず、次のグラフを参照して、必要となる Cloud Identity アカウントの数、Cloud Directory Sync インスタンスの数、AD FS インスタンスまたはフリートの数を特定してください。

必要なフリートまたはインスタンスの数を判断するための決定グラフ

次に、2 番目のチャートを参照して、Cloud Identity アカウントで構成するドメインを特定します。

Cloud Identity で構成するドメインを特定するための決定グラフ

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...