Google Cloud と Azure Active Directory の連携

この記事では、既存の Microsoft Azure Active Directory ベースの ID 管理ソリューションを Google Cloud に拡張して、ハイブリッド コンピューティング環境で一貫した認証と認可のメカニズムを確立する方法について説明します。

はじめに

ユーザー アカウントを管理して、アプリケーションとコンピューティング リソースへのアクセスを制御することは、企業の IT 部門にとって重要な責務です。これまで多くの場合に、企業は専らオンプレミスの Active Directory(AD)に依存していました。この経緯から、AD は IT 環境とオンプレミス インフラストラクチャの基盤となっています。

最近では、オンプレミスの Active Directory と Azure Active Directory(Azure AD)を併用して認証と認可を管理する企業が多くなっています。オンプレミスの Active Directory はオンプレミス リソースの管理に使用されるだけでなく、ユーザー アカウントとグループを管理する記録システムとしてみなされてもいますが、クラウドベースのデプロイで認証と認可を管理するには、通常は Azure AD が使用されます。

この記事では、Cloud Identity を使用して既存の Active Directory と Azure AD ベースの ID 管理ソリューションを Google Cloud に拡張する方法について説明します。ただし、ここで説明する内容は G Suite にも該当します。

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

Active Directory、Azure AD、Google Cloud の連携

Google Cloud では、認証とアクセス管理に Google ID が使用されます。Google Cloud のリソースにアクセスするには、従業員に Google ID が割り当てられている必要があります。すべての従業員がすでに Active Directory または Azure AD のアカウントを割り当てられている場合、各従業員の Google ID を手動で管理するのは煩雑であることが予想されます。Cloud Identity と ID 管理システムの間でユーザー ID を連携させることで、Google アカウントのメンテナンスを自動化し、Google アカウントのライフサイクルを既存のアカウントに関連付けることができます。

すでに Active Directory と Azure AD を使用している場合は、次の 2 つの方法で Google Cloud を統合できます。

  1. Google Cloud Directory Sync と Active Directory フェデレーション サービス(AD FS)を利用して、Active Directory と Cloud Identity を直接連携させます。

    Google Cloud Directory Sync

    このアプローチでは、Active Directory と Cloud Identity 間での同期の方法と対象をきめ細かく管理できますが、Azure AD を活用できていません。またこのアプローチを使用する場合は、コンピューティング環境で Google Cloud Directory Sync と AD FS を実行する必要があります。

    このアプローチの詳細については、別のガイドをご覧ください。

  2. Cloud Identity と Azure AD を連携させます。Azure AD 自体を 1 つ以上のオンプレミスの Active Directory フォレストと連携させることもできます。

    Cloud Identity と Azure AD を連携させる

    このアプローチの利点の 1 つは、オンプレミス環境に追加のソフトウェアをインストールする必要がないことです。Azure AD でサポートされている認証メカニズム(パススルー認証パスワード ハッシュ同期など)は、Google Cloud でも使用できます。

この記事の残りの部分では、2 番目のアプローチに焦点を当てます。

Azure AD を Cloud Identity と連携させると、次のことが確実になります。

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

Azure AD と Cloud Identity 間の連携の設定には、次の 2 つのプロセスが伴います。

  • アカウントのプロビジョニング: 該当するユーザー アカウントとグループが定期的に Azure AD から Cloud Identity に同期されます。このプロセスにより、Azure AD でアカウントを作成する、または Active Directory から Azure AD に新しいアカウントを同期すると、Google Cloud でも利用可能になります。その結果、関連付けられたユーザーが初回ログインする前であっても、Google Cloud で参照できるようになります。また、このプロセスによってアカウントの削除も確実に伝播されます。

    プロビジョニングは一方向で行われます。つまり、Azure AD での変更は Cloud Identity にレプリケートされますが、その逆は行われません。また、プロビジョニングにはパスワードは含まれません。

  • シングル サインオン: ユーザーが Google Cloud で認証を必要とする場合は常に、Cloud Identity が Security Assertion Markup Language(SAML)プロトコルを使用して Azure AD に認証を委任します。Azure AD の構成に応じて、Azure AD は次のいずれかを行います。

    • 認証自体を実行する。
    • パススルー認証またはパスワード ハッシュ同期を使用する。
    • オンプレミスの AD FS サーバーに認証を委任する。

Cloud Identity で認証を Azure AD に委任すると、パスワードを Google Cloud に同期する必要がなくなるだけでなく、Azure AD または AD FS で構成した適用可能なポリシーまたは多要素認証(MFA)メカニズムが確実に適用されるようになります。

Azure AD の論理構造

Azure を使用する場合、1 つ以上の Azure AD テナント(「ディレクトリ」とも呼ばれます)を使用します。Azure AD テナントは最上位の構造です。テナントは管理上の境界とみなされ、ユーザー、グループ、リソース、リソース グループのコンテナとしての役割を果たします。

Azure AD テナントごとに、1 つ以上の DNS ドメインが関連付けられます。この DNS ドメインは、ユーザー名(ユーザー プリンシパル名または UPN)に反映されます。ユーザー名は、[name]@[domain] という形式をとります。ここで、[domain] は、それぞれのテナントに関連付けられた DNS ドメインのうちの 1 つです。

Azure AD の論理構造

企業が複数の Azure AD テナントを維持している場合もあります。組織のさまざまな部分を区別する、本番環境のリソースを開発やテスト用のリソースから分離する、または個別のテナントを使用してオンプレミスの Active Directory の複数のフォレストを統合することなどが、複数のテナントを使用する一般的な理由として挙げられます。

Google Cloud の論理構造

Google Cloud ではすべてのリソースで、組織がコンテナとしての機能を果たします。組織内のリソースは、さらにフォルダとプロジェクトを使用してセグメント化できます。ただし、サービス アカウントを除き、組織を使用してユーザー アカウントとグループを管理することはできません。この点が、組織と Azure AD テナントの違いです。

ユーザーとグループを管理する際に、Google Cloud は Cloud Identity アカウント(またはこのドキュメントの範囲外の G Suite アカウント)を使用します。

GCP の論理構造

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

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

Azure AD と Google Cloud の統合

Azure AD と Google Cloud の論理構造には一定の類似点がありますが、この 2 つの構造間にすべてのシナリオで同等に十分機能するマッピングは存在しません。2 つのシステムを統合して構造をマッピングする際の正しいアプローチは、次の複数の要素によって異なります。

  • Azure AD テナントを Cloud Identity アカウントにマッピングする方法
  • DNS ドメインをマッピングする方法
  • ユーザー アカウントをマッピングする方法
  • グループをマッピングする方法

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

Google Cloud は Azure AD とのみ連携します。オンプレミスの Active Directory とは連携しません。このため、オンプレミスの Active Directory のフォレストとドメインが Azure AD にどのようにマッピングされているかは、ほとんど問題になりません。

Azure AD テナントのマッピング

単一のテナント

単一の Azure AD テナントを使用する場合は、そのテナントを 1 つの Cloud Identity アカウントにマッピングして、Azure AD と Cloud Identity 間の連携を設定できます。この Cloud Identity アカウントは、すべての Google Cloud リソースの管理に使用できる単一の Google Cloud 組織の基盤となります。

テナントを単一の Cloud Identity アカウントにマッピングする

複数のテナント

大規模な組織で複数の Azure AD テナントを使用することは珍しくありません。テスト環境と本番環境を区別したり、組織のさまざまな部分を区別したりする場合には、複数のテナントが使用されます。

複数の Azure AD テナントに属するユーザーとグループを 1 つの Cloud Identity アカウントにプロビジョニングすることは可能ですが、現在のところ、ユーザーのシングル サインオンが複数の Azure AD テナントにわたって機能するように設定することはできません。複数の Azure AD テナントを使用する場合は、テナントごとに個別の Cloud Identity アカウントを作成し、それぞれのペア間で連携を設定する必要があります。

Google Cloud では、Cloud Identity アカウントごとに個別の組織が作成されます。Google Cloud では、1 つの組織内でプロジェクトフォルダを使用してリソースを整理できるため、多くの場合、複数の組織を作成するのは現実的ではありません。ただし、組織のいずれか 1 つを選択して別の Cloud Identity アカウントに関連付けることで、実質的に複数の Active Directory フォレストと連携する組織を作成できます。選択した以外の組織は未使用のままになります。

複数の Active Directory フォレストと連携する組織

外部ユーザー

Azure AD B2B を使用すると、外部ユーザーを Azure AD テナントのゲストとして招待できます。ゲストごとに新しいユーザーが作成され、Azure AD によってゲストユーザーに UPN が自動的に割り当てられます。Azure AD が生成する UPN では、招待者のメールアドレスから取得した接頭辞と、テナントの初期ドメイン([prefix]#EXT#@[tenant].onmicrosoft.com)が組み合わされて使用されます。

Azure AD から Cloud Identity にゲストユーザーをプロビジョニングする際には、特定の制限が課されます。

  • onmicrosoft.com は Cloud Identity では追加と確認ができないドメインのため、ゲストユーザーの UPN を Cloud Identity のメールアドレスにマッピングすることはできません。そのため、UPN 以外の属性を使用してユーザー アカウントをマッピングする必要があります。
  • ゲストユーザーがホームのテナントで停止された場合でも、Cloud Identity の対応するユーザーは有効なままとなり、Google Cloud リソースへのアクセスが正しく取り消されない場合があります。

別の Azure AD テナントからのゲストユーザーに対応するためのより適切な方法は、前のセクションで説明したように、複数の Cloud Identity アカウントを作成し、それぞれを別の Azure AD テナントと連携させることです。

外部ユーザーに特定の Google Cloud リソースへのアクセス権を付与する際に、対象ユーザーが Cloud Identity のアカウントを持っていることは前提条件ではありません。ポリシーによって制限されていない限り、外部ユーザーが Google アカウントを持っていれば、該当するプロジェクト、フォルダ、組織のメンバーとして外部ユーザーを直接追加できます。

DNS ドメインのマッピング

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

Google Cloud での DNS ドメインの使用法

Google Cloud が認証目的のために使用する Google ログインでは、メールアドレスを使用してユーザーを識別します。メールアドレスを使用すると、各ユーザーをグローバルに一意のユーザーとして識別できるだけでなく、Google Cloud が該当するメールアドレスに通知メッセージを送信することもできます。

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

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

G SuiteCloud Identity にアカウントを登録すると、基本的に限定公開ディレクトリを作成することになります。Google Identity Platform ではこの限定公開ディレクトリを認証の際に使用できます。Gmail ディレクトリを gmail.com ドメインに関連付けたのと同じ方法で、G Suite アカウントと Cloud Identity アカウントをカスタム ドメインに関連付ける必要があります。これらの目的のために、異なる 3 種類のドメインを使用します。

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

いずれのドメインも、次の要件を満たす必要があります。

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

Azure AD での DNS ドメインの使用法

Cloud Identity での DNS の使用法と同じように、Azure AD でも DNS に依存して Azure AD テナントを区別し、ユーザー名をテナントに関連付けます。ただし、2 つの注意すべき相違点があります。

  1. 初期ドメイン: Azure AD テナントを作成すると、そのテナントは onmicrosoft.com のサブドメインである初期ドメインに関連付けられます。このドメインは、ユーザーがドメインを所有していないという点と、そのユーザーには該当する DNS ゾーンへの管理者権限が付与されていないという点で、ユーザーが登録するカスタム ドメイン名とは異なります。

    Cloud Identity には初期ドメインに相当するものはありません。ユーザーが Cloud Identity アカウントに関連付けるすべてのドメインは、ユーザーが所有するものでなければなりません。この要件は、onmicrosoft.com サブドメインを Cloud Identity ドメインとして登録できないことを意味します。

  2. ユーザー ID で使用されるドメイン: Azure AD はメールアドレスの MOERA(Microsoft Online Email Routing Addresse)と UPN を区別します。どちらも RFC 822 形式(user@domain)に従いますが、異なる目的を果たします。UPN はユーザーの識別とログイン フォームで使用され、メールの配信には MOERA のみが使用されます。

    UPN で使用するドメイン サフィックスは Azure AD テナントの登録ドメインのいずれかと一致しなければなりません。この要件は、メールアドレスには適用されません。

    Cloud Identity は UPN の概念に依存しません。代わりに、ユーザーのメールアドレスを ID として使用します。したがって、メールアドレスで使用するドメインは、Cloud Identity アカウントの登録ドメインのいずれかと一致しなければなりません。

Azure AD と Cloud Identity は同じ DNS ドメインを使用できます。上記の 2 つの違いを踏まえ、Azure AD と Cloud Identity 間でのユーザー アカウントのマッピング方法は、ドメインのマッピングに基づくものとします。

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

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

Azure AD アカウントを Cloud Identity アカウントに正常にマッピングするには、各アカウントに関する 2 つの情報が必要です。

  1. 同期の際にどの Azure AD アカウントがどの Cloud Identity アカウントに対応しているかを追跡するために使用できる、変わることのない一意の ID。
  2. ドメインの部分が Cloud Identity のプライマリ ドメイン、セカンダリ ドメイン、またはエイリアス ドメインに相当するメールアドレス。このメールアドレスは Google Cloud 全体で使用されるため、アドレスは人が読んで理解できる必要があります。

内部的には、Azure AD は ObjectId によってユーザーを識別します。ObjectId は、ランダムに生成される、グローバルに一意の ID です。この ID は安定しているため、最初の要件を満たしていますが、人間には理解できず、メールアドレスの形式にも従っていません。ユーザーをマッピングするのに唯一実用的なオプションは、UPN またはメールアドレスでマッピングすることです。

メールアドレスによるユーザー アカウントのマッピング

ユーザーが入力したメールアドレスが、Azure AD によるシングル サインオンを使用するように構成されている Cloud Identity アカウントに属する場合、ユーザーは Azure AD のログイン画面にリダイレクトされます。

Azure AD ではユーザーを識別するためにメールアドレスではなく UPN を使用します。したがって、Azure AD ログイン画面では UPN を入力するよう求められます。

UPN の入力を求めるログイン画面

Azure AD テナントが AD FS を使用してログインするように構成されている場合、ユーザーはさらに AD FS ログイン画面にリダイレクトされます。AD FS は、Active Directory UPN または Windows 2000 より前のログオン名(domain\user)でユーザーを識別できます。

AD FS のログイン画面

Cloud Identity で使用するメールアドレス、Azure AD で使用する UPN、Active Directory で使用する UPN がすべて異なる場合、一連のログイン画面によりエンドユーザーが混乱することが容易に想定されます。一方、サンプルのスクリーンショット(johndoe@example.com)のように、3 つの ID すべてが同じである場合、ユーザーは UPN とメールアドレスの技術的な相違に気づかないため、ユーザーが混乱する可能性を最小限に抑えることができます。

UPN によるマッピング

ユーザー エクスペリエンスの観点から最善のオプションと考えられるのは、Azure AD の UPN を Cloud Identity のメールアドレスにマッピングすることです。また、UPN を使用するもう 1 つの利点は、Azure AD が一意性を保証するため、名前の競合リスクを回避できることです。

ただし、Azure AD の UPN を Cloud Identity のメールアドレスにマッピングするには、次の要件を満たす必要があります。

  • Google Cloud から送信される通知メールがユーザーのメールボックスに正しく配信されるように、Azure AD UPN を有効なメールアドレスにする必要があります。有効なメールアドレスでない場合は、Google Cloud から送信されるメールをユーザーが受信できるよう、エイリアスのメールアドレスを構成します。
  • Azure AD 内のすべての関連ユーザーの UPN では、サフィックス([user]@[custom-domain])としてカスタム ドメインを使用する必要があります。Azure AD の初期ドメイン([user]@[tenant].onmicrosoft.com)を使用する UPN は、Cloud Identity のメールアドレスにはマッピングできません。これは、初期ドメインは管理者自身が所有しているのではなく、Microsoft が所有しているためです。
  • Azure AD で UPN に使用するすべてのカスタム ドメインは、Cloud Identity にも登録されている必要があります。この要件は、ドメイン検証を行うために、該当する DNS ゾーンへのアクセス権が必要であることを意味します。Azure AD でドメイン所有権を確認するために作成した既存の TXT DNS レコードをオーバーライドするのを回避するには、Cloud Identity で CNAME レコードを使用してドメイン所有権を確認します。

Cloud Identity では、Active Directory の UPN と Azure AD の UPN が同一かどうかは問題になりません。ただし、AD FS を使用する際は、Active Directory の UPN と Azure AD の UPN が同一である場合、よりよいユーザー エクスペリエンスを得ることができます。

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

Azure AD の UPN を Cloud Identity のメールアドレスにマッピングする選択ができない場合、メールアドレスによってアカウントをマッピングできます。

Active Directory でメールアドレスを指定すると、そのアドレスが各 user オブジェクトの mail 属性に保存され、Azure AD Connect によって値が Azure AD の Mail 属性に同期されます。Azure AD では、ユーザーのプロビジョニングにもこの属性を使用可能にすることで、Cloud Identity のメールアドレスにマッピングできるようにします。

重要な点として、Azure AD の Mail 属性は現在 Azure ポータルには表示されず、API または PowerShell でのみ表示および編集できることに留意してください。ユーザー インターフェースではメールアドレスと予備のメールアドレスを指定できますが、いずれの値も Mail 属性に格納されないため、Cloud Identity へのプロビジョニングには使用できません。このことから、メールアドレスでユーザーをマッピングする方法が実用的であるのは、ユーザーの作成と編集の作業の大部分を Azure AD ではなく Active Directory で行う場合に限られます。

メールアドレスでユーザーをマッピングするには、さらに次の要件も満たす必要があります。

  • メールアドレスの割り当てが完了していること。同期の対象となるすべてのユーザー アカウントにメールアドレスが割り当てられる必要があります。特に、ユーザーがオンプレミスの Active Directory から同期されている場合は、mail は Active Directory ではオプションのユーザー属性であるため、このケースに該当しない可能性があります。Azure AD で Mail 属性にメールアドレスがないユーザーは同期中、暗黙的に無視されます。
  • メールアドレスが Azure AD テナント全体で一意であること。Active Directory はアカウントの作成時に一意性を確認しませんが、Azure AD Connect はデフォルトで競合を検出します。この場合、該当するユーザー アカウントの同期は失敗します。
  • メールアドレスで使用されているドメインが Azure AD に登録されている必要はありませんが、Cloud Identity に登録されている必要があります。この要件は、ドメインの検証を行うために各 DNS ゾーンに対するアクセス権を割り当てられている必要があり、所有していないドメイン(gmail.com など)でメールアドレスを使用できないことを意味します。

グループのマッピング

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

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

Azure AD と Google Cloud 間のグループのマッピングはオプションです。ユーザー アカウントが連携するようになったら、Cloud Identity 内で直接グループを作成して管理できます。つまり、Active Directory または Azure AD は ID 管理に関しては中央システムであり続けますが、Google Cloud のアクセス管理に関してはそうではなくなるということです。

Active Directory または Azure AD を ID 管理とアクセス管理の中央システムとして維持するには、グループを Cloud Identity で管理するのではなく、Azure AD から同期することをおすすめします。このアプローチでは、Google Cloud のリソースに対するアクセス権を割り当てるユーザーを制御するために、Active Directory または Azure AD のグループ メンバーシップを使用できるよう、Cloud IAM を設定できます。

Cloud Identity でのグループ

Cloud Identity には 1 種類のグループだけ存在します。Cloud Identity でのグループは、グループが定義されている Cloud Identity アカウントのスコープに制限されません。これらのグループは他の Cloud Identity アカウントに属するユーザー アカウントを含み、他の Cloud Identity アカウント内での参照とネストをサポートします。また任意の Google Cloud 組織間での使用も可能です。

ユーザー アカウントの場合と同じく、Cloud Identity はメールアドレスでグループを識別します。メールアドレスが実際のメールボックスに対応している必要はありません。ただし、メールアドレスには、該当する Cloud Identity アカウントに登録されているドメインのうちの 1 つが使用されている必要があります。

Cloud IAM でグループを操作する際に、名前ではなくメールアドレスでグループを指定する必要がある場合が多いです。したがって、グループには意味のある名前を付けるだけでなく、意味のある、かつ認識しやすいメールアドレスを割り当てることをおすすめします。

Azure AD でのグループ

Azure AD では異なるユースケースに応じた複数の種類のグループをサポートしています。グループは単一のテナントにスコープ設定され、オブジェクト ID によって識別されます。オブジェクト ID は、ランダムに生成される、グローバルに一意の ID です。グループはネストすることができ、同じテナントのユーザー、または Azure B2B を使用して他のテナントから招待されたユーザーのいずれかを含めることができます。Azure AD では、クエリに基づいてメンバーが自動的に決定される動的グループもサポートされます。

Azure AD を Cloud Identity に統合するというコンテキストで特に重要となるグループのプロパティは、グループにおいて、メールが有効であるかどうかと、セキュリティが有効であるかどうかの 2 つです。

  • セキュリティが有効なグループは、Azure AD のリソースへのアクセス管理に使用できます。したがって、セキュリティが有効なグループはいずれも、Google Cloud との関連では重要になる可能性があります。
  • メールが有効なグループには、メールアドレスがあります。Cloud Identity ではグループをメールアドレスで識別することを要件とするため、このプロパティは重要です。

Azure AD では、セキュリティ タイプのグループと Office 365 タイプのグループ(統合グループとも呼ばれます)を作成できます。オンプレミスの Active Directory からグループを同期する場合、または Office 365 タイプを使用する場合は、配布リストタイプのグループも作成できます。

次の表に、メールが有効であるかという点、セキュリティが有効であるかという点でグループの種類をまとめています。また、Azure AD Connect のデフォルト構成を前提として、Active Directory のグループの種類にどのように対応するかを記載しています。

ソース Active Directory のグループの種類 Azure AD のグループの種類 メールが有効 セキュリティが有効
Azure AD - Office 365 グループ 既定 任意
Azure AD - セキュリティ グループ 任意 既定
オンプレミス セキュリティ グループ(メールあり) セキュリティ グループ
オンプレミス セキュリティ グループ(メールなし) セキュリティ グループ ×
オンプレミス 配布リスト(メールあり) 配布リスト ×
オンプレミス 配布リスト(メールなし) (Azure AD Connect によって無視される)

ユーザーの場合とは異なり、Azure AD はグループに割り当てるメールアドレスに、Azure AD でカスタム ドメインとして登録されているドメインの使用を要件としています。この要件により、デフォルトの動作は次のようになります。

  • Active Directory 内のグループで、Azure AD に登録済みのドメインを使用するメールアドレスを使用している場合、そのメールアドレスは Azure AD との同期中に適切に維持されます。
  • Active Directory 内のグループで、Azure AD に未登録のメールアドレスを使用している場合、Azure AD は同期中に新しいメールアドレスを自動生成します。このメールアドレスには、テナントのデフォルト ドメインが使用されます。テナントがデフォルト ドメインとして初期ドメインを使用している場合、生成されるメールアドレスは [name]@[tenant].onmicrosoft.com の形式になります。
  • Azure AD で Office 365 グループを作成する場合も、Azure AD はテナントのデフォルト ドメインを使用したメールアドレスを自動生成します。

グループ ID のマッピング

Azure AD のグループを Cloud Identity のグループに正常にマッピングするには、共通の ID が必要です。Cloud Identity では、この共通 ID はメールアドレスでなければなりません。Azure AD 側では、この要件に 2 つの選択肢があります。

  • Azure AD 内のグループのメールアドレスを使用して、そのグループを Cloud Identity のメールアドレスにマッピングします。
  • Azure AD 内のグループ名からメールアドレスを取得し、そのアドレスを Cloud Identity のメールアドレスにマッピングします。

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

メールアドレスによるグループ マッピングが最も明白な選択ですが、それでもまだ、求められる要件がいくつかあります。

  • 同期の対象とするすべてのグループにメールアドレスが割り当てられていること。これは実際のところ、メールが有効なグループのみ同期が可能であることを意味します。メールアドレスがないグループはプロビジョニング時に無視されます。
  • メールアドレスがそのテナント全体で一意であること。Azure AD では一意性を強制しないため、カスタム チェックまたはポリシーを実装しなければならない場合があります。
  • メールアドレスで使用されているドメインが Azure AD と Cloud Identity の両方に登録されていること。[tenant].onmicrosoft.com ドメインを含め、Cloud Identity に登録されていないドメインを使用するメールアドレスを持つグループは、同期に失敗します。

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

名前によるマッピング

メールアドレスでグループをマッピングするために必要な条件を満たすことが難しい場合があります。これは特に、Cloud Identity にプロビジョニングする多くのセキュリティ グループが、メールが有効でないグループの場合です。その場合は、グループの表示名からメールアドレスを自動的に取得することをおすすめします。

メールアドレスの取得には、2 つの問題が伴います。

  1. グループの名前から取得したメールアドレスは、ユーザーのメールアドレスと競合する可能性があります。
  2. Azure AD ではグループ名に一意性を強制しません。Azure AD テナント内の複数のグループが同じ名前を共有している場合、この名前から取得されたメールアドレスが競合し、1 つのグループしか正常に同期されません。

最初の問題を解決するには、生成されたメールアドレスに、ユーザーが使用しているドメインとは異なるドメインを使用します。たとえば、すべてのユーザーがドメインとして example.com のメールアドレスを使用している場合は、すべてのグループに groups.example.com を使用できます。Cloud Identity にサブドメインを登録する場合、ドメインの確認は必要ないため、DNS ゾーン groups.example.com は存在する必要さえありません。

2 番目の問題を解決するには、グループ名を複製します。技術的には、オブジェクト ID からグループのメールアドレスを取得するだけで複製できます。しかし、このようにして生成されるグループ名は不可解で扱いにくいものです。したがって、Cloud Identity へのプロビジョニングを設定する前に、Azure AD で重複するグループ名を識別し、変更することをおすすめします。

ユーザー アカウントのライフサイクルを管理する

テナント、ドメイン、ユーザー、グループの間での適切なマッピングを特定すると、Cloud Identity でのユーザー アカウントとグループの管理を自動化できます。しかし、どのユーザー アカウントとグループをプロビジョニングしてシングル サインオンを有効にすべきでしょうか。

オンボーディング

Google Cloud の使用に関する計画内容によっては、Azure AD にアカウントを持つすべてのユーザー、または新しいアカウントを作成する対象ユーザーにも Google Cloud への権限を付与することになります。より可能性が高いシナリオとして、一部のユーザーのみが Google Cloud にアクセスできることを必要とする場合が考えられます。そのため、Azure AD で 4 つに分けられるユーザー アカウントの相違を明確にすることが重要です。

  • Azure AD のアカウントは、Azure AD のアカウントの総数を意味します。
  • Cloud Identity にプロビジョニングされたアカウントは、Azure AD のアカウントのうち、Cloud Identity へのプロビジョニングの対象として割り当てられたアカウントを意味します。
  • SSO が有効にされたアカウントは、Azure AD のアカウントのうち、シングル サインオンの対象として割り当てられたアカウントを意味します。
  • Cloud IAM でアクセス権を付与されたアカウントは、Azure AD のアカウントのうち、Google Cloud 内の任意のリソースへのアクセス権が付与された Cloud Identity にプロビジョニングされたアカウントを意味します。

Google Cloud のリソースを使用できるようになるには、Cloud Identity にアカウントをプロビジョニングし、SSO を有効にして、Cloud IAM でアクセス権を付与する必要があります。

Cloud Identity にプロビジョニングされ SSO が有効にされているものの、Cloud IAM でアクセス権を付与されていないアカウントは、Google Cloud を使用できませんが、データポータルなどの他の Google ツールは使用できる場合があります。

Cloud Identity にプロビジョニングされているものの SSO が有効にされていないアカウントは、ログインに使用できないため、ユーザーにとってほとんど価値がありません。ただし、Cloud Identity にアカウントが存在すると、会社のメールアドレスを使用して YouTube、Google 検索、他の Google サイトに一般ユーザー向けアカウントを登録するユーザーをブロックします。従業員にビジネス目的での一般ユーザー向けアカウントの使用を許可することには、企業でそれらのアカウントとアカウントのライフサイクルおよびセキュリティを制御できないことから、リスクを伴う可能性があります。したがって、会社のメールアドレスでの登録をブロックすることが最善策として考えられます。

アカウントで SSO を有効にしつつ、Cloud Identity へのプロビジョニングは行わないという手法は、既存の一般ユーザー向けアカウントを Cloud Identity に移行する場合に有用です。移行を除けば、Cloud Identity にプロビジョニングされないアカウントで SSO を有効にする理由はほとんどありません。

すべてのアカウントをプロビジョニングして SSO を有効にする

以上の 4 種類のユーザーの相互作用を踏まえると、Azure AD のすべてのアカウントを Cloud Identity にプロビジョニングし、すべてのアカウントに対して SSO を有効にする一方、該当する一部のユーザーにのみリソースへのアクセス権を付与することが最も端的なアプローチとなります。

すべてのアカウントをプロビジョニングして SSO を有効にする

大規模な組織では、個人ではなくグループ単位で権限を付与することをおすすめします。Cloud Identity で作成されたグループ、または Azure AD からプロビジョニングされたグループのいずれも、この目的で使用できます。

Google Cloud リソースへのアクセスを制御するために Cloud Identity を使用してグループを作成、管理するアプローチを選択する場合、このアプローチにはグループへのアクセス権を付与するユーザー数を増やす決定を行った際に、Cloud Identity ですべてのユーザー アカウントを直ちに利用できるというメリットがあります。それ以外の場合に、Google Cloud へのアクセス権をユーザーに付与するには、まず Azure AD で変更を行い、ユーザー アカウントが同期されるまで待機してから、Cloud Identity でその他の操作を行うことが必要な場合があります。

最小限のアカウントのセットをプロビジョニングして SSO を有効にする

すべての Azure AD アカウントを Cloud Identity にプロビジョニングして SSO を有効にすると、すべてのユーザーがデータポータルなどの Google Cloud 以外のツールにアクセスできますが、このようにする必要性はあまりありません。代替アプローチは、考えられる最小限のアカウントのセットのみを Cloud Identity にプロビジョニングすることです。このセットに含めるアカウントは、Cloud IAM でもアクセス権を付与されているもののみにすることが理想的です。

最小限のアカウントのセットをプロビジョニングして SSO を有効にする

グループを使用してアクセスを管理するものの、それらのグループの管理を Cloud Identity ではなく Azure AD で行う手法を選択する場合は、関連するアカウントのみがプロビジョニングされるよう、同じグループを使用して該当するエンタープライズ アプリへの割り当てを制御できます。代替手法として、Azure AD で動的グループを作成することで、Google Cloud へのアクセスを必要とする可能性があるアカウントのセットについて概算することも考えられます。

上記のアプローチの欠点は、アカウントがプロビジョニングされていないユーザーでも、会社のメールアドレスを使用して一般ユーザー向けアカウントを登録できることです。

すべてのユーザーをプロビジョニングし、最小限のアカウントのセットに対して SSO を有効にする

すべてのアカウントを Cloud Identity にプロビジョニングしつつ、Cloud IAM でアクセス権を付与する予定のユーザーのみを対象に SSO を有効にすることで、前述のアプローチに伴う問題を解消できます。

すべてのユーザーをプロビジョニングし、最小限のアカウントのセットに対して SSO を有効にする

このアプローチでは、一般ユーザー向けアカウントの作成を防止するだけでなく、必要以上のユーザーが Google サービスにログインできるようになる状態も回避できます。

退会

ユーザーが退職した、またはロールに変更が生じた場合に該当のアクセス権を取り消すことは、必要に応じてユーザーに Google Cloud へのアクセス権を付与することと同じく重要です。Azure AD でユーザーが削除されると、以降は、そのユーザーのシングル サインオンの試行が失敗します。また、Cloud Identity で対応するユーザー アカウントも停止されます。

同様に、Cloud Identity に同期されているグループからユーザーを削除すると、そのメンバーシップの削除が Cloud Identity に反映されます。これにより、そのユーザーはグループで関連付けられているすべての権限を失います。

次のステップ