このドキュメントは、従業員ユーザーがハイブリッド コンピューティング環境で認証を行い、サービスを利用できるように、ID 管理ソリューションを Google Cloud に拡張する方法を説明するシリーズの第 2 部です。
このシリーズは、次のドキュメントで構成されています。
- ハイブリッド環境で従業員ユーザーを認証する
- ハイブリッド環境で従業員ユーザーを認証するパターン（このドキュメント）
はじめに
ハイブリッド戦略の一環として IT ランドスケープを Google Cloud に拡張する場合は、環境間で ID を管理するための一貫したアプローチを採用することをおすすめします。これらの制約や要件を満たすようにアーキテクチャを設計、調整するにあたって適用できるパターンは、いくつかの一般的なパターンに整理できます。これらのパターンは 2 つのカテゴリに分類されます。
- 外部 ID プロバイダ（IdP）とGoogle Cloudを連携するパターン。これらのパターンの目的は、Google を自社の従業員ユーザーの IdP とすることにより、Google Identity の管理を自動化し、自社の IdP が引き続き信頼できる情報源となるようにすることです。
- IdP を Google Cloudに拡張するパターン。これらのパターンでは、 Google Cloud にデプロイされたアプリケーションが IdP に直接接続するか、 Google Cloudで IdP のレプリカを維持することで、IdP を再利用できます。
外部 IdP と Google Cloudを連携するパターン
従業員ユーザーが、 Google Cloud コンソール、Google Cloud CLI、または IdP として Google を使用するその他のリソースにアクセスするには、Google Identity が必要です。従業員ごとに Google Identity を管理するには手間がかかります。全従業員のアカウントがすでに IdP に登録されていれば、自社の IdP と Google Cloudとの間でユーザー ID を連携させることで、Google アカウントの管理を自動化できます。さらに、Google アカウントのライフサイクルを既存のアカウントに関連付けることもできます。連携によって、次の処理が確実に行われます。
- IdP は引き続き ID 管理のための信頼できる唯一の情報源として機能します。
- お客様の IdP が管理するすべてのユーザー アカウント、またはそこから選択した一部のアカウントに対して、自動的に Google アカウントが作成されます。
- お客様の IdP でアカウントが無効化または削除された場合、対応する Google アカウントが停止または削除されます。
- パスワードなどの認証情報がコピーされないように、ユーザー認証の動作をお客様の IdP に委譲します。
Google Cloud Directory Sync と AD FS を使用して Active Directory と Cloud Identity を連携する
Active Directory を IdP として使用する場合、Google Cloud Directory Sync（GCDS）と Active Directory フェデレーション サービス（AD FS）を使用することで、Active Directory と Cloud Identity を連携させることができます。
- GCDS は、Google が無料で提供している、同期プロセスを実装するツールです。GCDS は、セキュア ソケット レイヤ（SSL）を介して Identity Platform と通信します。通常、このツールは既存のコンピューティング環境内で稼働します。
- AD FS: Microsoft が Windows Server の一部として提供しているコンポーネントです。AD FS の利用により、Active Directory を使用した連携認証が可能になります。通常、AD FS は既存のコンピューティング環境内で稼働します。
この方法の詳細については、 Google Cloud と Active Directory の連携をご覧ください。
このパターンから派生するものとして、Active Directory Lightweight Directory Services（AD LDS）、AD FS または他の SAML 準拠の IdP を使用している別の LDAP ディレクトリを使用することもできます。
ユーザー エクスペリエンス
- 保護されたリソースを要求すると、Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
- メールアドレスが Active Directory から同期されたアカウントに関連付けられている場合は、AD FS にリダイレクトされます。
- AD FS の構成によって、Active Directory のユーザー名とパスワードの入力を求めるログイン画面が表示される場合と、AD FS が Windows ログイン（IWA）に基づいて自動的にログインを試みる場合とがあります。
- AD FS によってユーザーが認証されると、保護されたリソースにリダイレクトされます。
利点
- このアプローチにより、オンプレミス アプリケーションと Google Cloudのリソース全体でシングル サインオン エクスペリエンスが実現します。
- 多要素認証を要求するように AD FS を構成した場合、その構成は Google Cloudに自動的に適用されます。
- パスワードなどの認証情報を Google に同期する必要がありません。
- Cloud Identity API は一般に公開されているため、オンプレミス ネットワークと Google Cloudの間にハイブリッド接続を構成する必要はありません。
ベスト プラクティス
- Active Directory と Cloud Identity の論理構造は異なります。必ず違いを理解し、ドメイン、ID、グループのマッピング方法に関して、どれが最もご自身の状況に適しているかを評価してください。詳細については、 Google Cloud と Active Directory の連携に関するガイドをご覧ください。
- ユーザーだけでなく、グループも同期してください。この方法では、IAM を設定することにより、Active Directory のグループ メンバーシップを使用して Google Cloudのリソースにアクセスできるユーザーを制御できます。
- AD FS を従業員ユーザーがアクセスできるようにデプロイ、公開しますが、公開対象は必要な範囲にとどめてください。従業員ユーザーは AD FS にアクセスできる必要があります。ただし、Google や Google Cloudにデプロイされたアプリケーションからアクセスできる必要はありません。
- AD FS で統合 Windows 認証（IWA）を有効にして、ユーザーが自分の Windows ログインに基づいて自動的にログインできるようにすることを検討してください。
- AD FS が利用できなくなると、Google Cloud コンソールや Google を IdP として使用するその他のリソースをユーザーが使用できなくなる可能性があります。そのため、AD FS と AD FS が依存するドメイン コントローラのデプロイとサイジングが、可用性目標を満たしていることを確認してください。
- Google Cloud を使用してビジネスの継続性を確保している場合、オンプレミスの AD FS に依存すると、Google Cloud をデプロイの独立したコピーとして使用するという意図が損なわれる可能性があります。この場合、 Google Cloudにすべての関連システムのレプリカをデプロイすることを検討してください。
- Active Directory を Google Cloudにレプリケートし、 Google Cloudで動作するように GCDS をデプロイします。
- 専用の AD FS サーバーを Google Cloudで実行します。これらのサーバーは、 Google Cloudで実行されている Active Directory ドメイン コントローラを使用します。
- Cloud Identity をシングル サインオン用に Google Cloud にデプロイした AD FS サーバーを使うように構成します。
Entra ID を Cloud Identity と連携させる
Microsoft Office 365 または Azure のお客様の場合、オンプレミスの Active Directory を Microsoft Entra ID（旧 Azure AD）に接続している可能性があります。 Google Cloud へのアクセスを必要とする可能性があるすべてのユーザー アカウントがすでに Entra ID と同期されている場合は、次の図に示すように、Cloud Identity と Entra ID を連携することでこの統合を再利用できます。
この方法の詳細については、 Google Cloud と Microsoft Entra ID の連携をご覧ください。
ユーザー エクスペリエンス
- 保護されたリソースを要求すると、Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
- メールアドレスが Entra ID から同期されたアカウントに関連付けられている場合は、Entra ID にリダイレクトされます。
- オンプレミスの Active Directory が Entra ID に接続されている方法によっては、Entra ID でユーザー名とパスワードの入力を求められることがあります。オンプレミスの AD FS にリダイレクトされる場合があります。
- Entra ID での認証に成功すると、保護されたリソースにリダイレクトされます。
利点
- オンプレミスで追加のソフトウェアをインストールする必要がありません。
- このアプローチにより、Office 365、Azure、 Google Cloudのリソース全体でシングル サインオン エクスペリエンスが実現します。
- 多要素認証（MFA）を要求するように Entra ID を構成した場合、MFA は Google Cloudに自動的に適用されます。
- オンプレミスの Active Directory で複数のドメインまたはフォレストを使用し、この構造を Entra ID テナントにマッピングするカスタム Entra ID Connect 構成を設定している場合は、この統合作業を活用できます。
- パスワードなどの認証情報を Google に同期する必要がありません。
- Cloud Identity API は一般に公開されているため、オンプレミス ネットワークと Google Cloud の間や、Azure とGoogle Cloudの間にハイブリッド接続を構成する必要はありません。
- Google Cloud コンソールを、Office 365 ポータルのタイルとして表示できます。
ベスト プラクティス
- Entra ID と Cloud Identity では論理構造が異なるため、違いを理解しておく必要があります。また、ドメイン、ID、グループのマッピング方法に関して、どれが最もご自身の状況に適しているかを評価してください。詳細については、 Google Cloud と Entra ID の連携をご覧ください。
- ユーザーだけでなく、グループも同期してください。この方法では、IAM を設定することにより、Entra ID のグループ メンバーシップを使用して Google Cloudのリソースに対するアクセス権を付与するユーザーを制御できます。
- Google Cloud を使用してビジネスの継続性を確保している場合、認証を Entra ID に依存すると、Google Cloud をデプロイの独立したコピーとして使用するという意図が損なわれる可能性があります。
外部 IdP を Google Cloudに拡張するパターン
Google Cloud にデプロイする予定のアプリケーションの中には、Cloud Identity で提供されていない認証プロトコルを使用する必要が生じる場合があります。このようなワークロードをサポートするには、これらのアプリケーションが Google Cloud内から IdP を使用できるようにする必要があります。
次のセクションでは、IdP を Google Cloudにデプロイされたワークロードで使用できるようにするための一般的なパターンについて説明します。
オンプレミスの AD FS を Google Cloudに公開する
アプリケーションが WS-Trust または WS-Federation の使用を必要とする場合、または OpenID Connect の使用時に AD FS 固有の機能またはクレームに依存している場合は、アプリケーションが認証に AD FS を直接使用することを許可できます。
AD FS を使用することで、アプリケーションはユーザーを認証できます。ただし、認証は Google Identity に基づいていないため、アプリケーションはユーザー認証情報を使用して認証された API 呼び出しを実行できません。代わりに、 Google Cloud APIs への呼び出しはサービス アカウントを使用して認証する必要があります。
ユーザー エクスペリエンス
- 保護されたリソースを要求すると、ADFS のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。AD FS がインターネットに公開されていない場合、AD FS にアクセスするには、お客様のネットワークまたは企業の VPN に接続している必要があります。
- AD FS の構成によって、Active Directory のユーザー名とパスワードの入力を求めるログイン画面が表示される場合と、AD FS が Windows ログインに基づいて自動的にログインを試みる場合とがあります。
- AD FS によってユーザーが認証されると、保護されたリソースにリダイレクトされます。
メリット
- WS-Trust や WS-Federation など、Cloud Identity でサポートされていない認証プロトコルを使用できます。
- アプリケーションが AD FS に対して開発、テストされている場合、Cloud Identity を使用するようにアプリケーションを切り替えることで生じるリスクを回避できます。
- オンプレミス ネットワークと Google Cloudの間にハイブリッド接続を設定する必要はありません。
ベスト プラクティス
- AD FS を従業員ユーザーがアクセスできるようにデプロイ、公開しますが、公開対象は必要な範囲にとどめてください。従業員ユーザーは AD FS にアクセスできる必要があります。ただし、Google や Google Cloudにデプロイされたアプリケーションからアクセスできる必要はありません。
- AD FS を使用できなくなった場合、ユーザーはこのアプリケーションを使用できなくなります。AD FS と AD FS が依存するドメイン コントローラのデプロイとサイジングが、可用性目標を満たしていることを確認してください。
- WS-Trust と WS-Federation に依存するアプリケーションを、SAML または OpenID Connect を使用するように変更することを検討してください。
- アプリケーションが、AD FS によって発行された
IdTokensでクレームとして公開されているグループ情報に依存している場合は、Directory API などの別のソースからグループ情報を取得することを検討してください。Directory API へのクエリは、Google Workspace ドメイン全体の委任に対して有効になっているサービス アカウントを使用する必要がある特権オペレーションです。
オンプレミスの LDAP ディレクトリを Google Cloudに公開する
アプリケーションの中には、ユーザーに対して、ユーザー名とパスワードを入力し、この資格情報を使用して LDAP バインド操作を試すように求めるものがあります。SAML などの他の手段で認証を行うようにこうしたアプリケーションを変更できない場合は、オンプレミスの LDAP ディレクトリへのアクセスを許可します。
利点
- アプリケーションを変更する必要がありません。
ベスト プラクティス
- インターネットに LDAP ディレクトリを公開する必要がないように、Cloud VPN または Cloud Interconnect を使用して、 Google Cloud とオンプレミス ネットワークの間にハイブリッド接続を確立してください。
- オンプレミスの LDAP ディレクトリへのクエリによるレイテンシが、ユーザー エクスペリエンスに悪影響を及ぼさないことを確認してください。
- アプリケーションと LDAP ディレクトリとの間の通信を必ず暗号化してください。この暗号化は、Cloud VPN を使用するか、Cloud Interconnect を LDAP/S とともに使用することにより実現できます。
- LDAP ディレクトリ、またはGoogle Cloud とオンプレミス ネットワークとの間のプライベート接続が使用できなくなった場合、LDAP ベースのアプリケーションを使用できなくなります。したがって、それぞれのサーバーが可用性目標を満たすようにデプロイされ、サイズ設定されていることを確認し、冗長な VPN トンネルまたは相互接続の使用を検討してください。
- Google Cloud を使用してビジネスの継続性を確保している場合、オンプレミスの LDAP に依存すると、Google Cloud を既存のデプロイの独立したコピーとして使用するという意図が損なわれる可能性があります。この場合は、代わりに Google Cloud に LDAP ディレクトリをレプリケートすることを検討してください。
- Active Directory を使用している場合、特にGoogle Cloud で実行されている Windows マシンを Active Directory にドメイン参加させる場合は、代わりに Google Cloud でレプリカを実行することを検討してください。
オンプレミスの LDAP ディレクトリを Google Cloudにレプリケートする
オンプレミスの LDAP ディレクトリを Google Cloud にレプリケートすることは、オンプレミスの LDAP ディレクトリを Google Cloudに公開することに似ています。LDAP を使用してユーザー名とパスワードを検証するアプリケーションの場合、このアプローチの目的は、それらのアプリケーションを Google Cloudで実行できるようにすることです。そのようなアプリケーションがオンプレミスの LDAP ディレクトリにクエリできるようにする代わりに、 Google Cloudでオンプレミスのディレクトリのレプリカを保持します。
利点
- アプリケーションを変更する必要がありません。
- Google Cloudで実行されている LDAP ベースのアプリケーションの可用性は、オンプレミス ディレクトリの可用性やオンプレミス ネットワークへの接続性に依存しません。このパターンは、ビジネス継続性ハイブリッド シナリオに適しています。
ベスト プラクティス
- インターネットに LDAP ディレクトリを公開する必要がないように、Cloud VPN または Cloud Interconnect を使用して、 Google Cloud とオンプレミス ネットワークの間にハイブリッド接続を確立してください。
- オンプレミスの LDAP ディレクトリ間のレプリケーションが安全なチャネルを介して行われるようにしてください。
- 可用性目標を達成するために、複数のゾーンまたはリージョンにまたがって複数の LDAP ディレクトリのレプリカをデプロイしてください。内部ロードバランサは、同じリージョンにデプロイされている複数のレプリカ間で LDAP 接続を分散するために使用できます。
- 別の Google Cloud プロジェクトと共有 VPC を使用して LDAP のレプリカをデプロイし、最小権限でこのプロジェクトへのアクセス権を付与してください。
オンプレミスの Active Directory を Google Cloudに拡張する
Google Cloud にデプロイする予定のワークロードの中には、Active Directory Domain Services に依存するものがあります。次に例を示します。
- ドメイン参加する必要がある Windows マシン
- 認証に Kerberos または NTLM を使用するアプリケーション
- ユーザー名とパスワードを確認するために、LDAP ディレクトリとして Active Directory を使用するアプリケーション
このようなワークロードをサポートするには、次の図のように、オンプレミスの Active Directory フォレストを Google Cloudに拡張します。たとえば、リソース フォレストをGoogle Cloud にデプロイし、それをオンプレミスの Active Directory フォレストに接続します。
この方法の詳細と Active Directory をハイブリッド環境にデプロイするその他の方法の詳細については、ハイブリッド環境での Active Directory の使用パターンをご覧ください。
利点
- Windows マシンを Active Directory ドメインに参加させる機能などの Active Directory の利点をワークロードで最大限に生かすことができます。
- Google Cloud で実行されている Active Directory ベースのアプリケーションの可用性は、オンプレミス リソースの可用性やオンプレミス ネットワークへの接続性に依存しません。このパターンは、ビジネス継続性ハイブリッド シナリオに最適です。
ベスト プラクティス
- Cloud VPN または Cloud Interconnect を使用して、 Google Cloud とオンプレミス ネットワークの間にハイブリッド接続を確立してください。
- Google Cloud とオンプレミス ネットワークとの間の通信を最小限に抑えるには、 Google Cloudのデプロイ用に Active Directory サイトを別に作成してください。共有 VPC ごとに 1 つのサイトを使用するか、リージョン間の通信を最小限に抑えるために共有 VPC とリージョンごとに 1 つのサイトを使用します。
- Google Cloud にデプロイされたリソース専用の Active Directory ドメインを別に作成し、既存のフォレストに追加してください。別のドメインを使用することにより、レプリケーションのオーバーヘッドとパーティション サイズを削減できます。
- 可用性を高めるには、少なくとも 2 つのドメイン コントローラをデプロイし、複数のゾーンに分散します1。複数のリージョンを使用している場合は、各リージョンにドメイン コントローラをデプロイすることを検討してください。
- 別の Google Cloud プロジェクトと共有 VPC を使用して、ドメイン コントローラをデプロイし、最小権限でこのプロジェクトへのアクセス権を付与してください。パスワードを生成するか、ドメイン コントローラ インスタンスのシリアル コンソールにアクセスすることで、不正なプロジェクト メンバーによってドメインが危険にさらされることを防ぎます。
- AD FS サーバー ファームと GCDS を Google Cloudにデプロイすることを検討してください。この方法を使用すると、リソースの可用性やオンプレミス ネットワークへの接続性に依存せずに、Active Directory と Cloud Identity を連携させることができます。
次のステップ
- Google Cloud と Active Directory の連携の詳細を確認する。
- ハイブリッド環境での Active Directory の使用パターンを学習する。
- Cloud Identity を Entra ID と連携させる方法を詳しく見る。
- Google Cloud ランディング ゾーンのリソース階層を設計する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。