ハイブリッド環境で従業員ユーザーを認証するパターン

Last reviewed 2024-06-26 UTC

このドキュメントは、従業員ユーザーがハイブリッド コンピューティング環境で認証を行い、サービスを利用できるように、ID 管理ソリューションを Google Cloud に拡張する方法を説明するシリーズの第 2 部です。

このシリーズは、次のドキュメントで構成されています。

はじめに

ハイブリッド戦略の一環として IT 環境を Google Cloud に拡張する場合は、さまざまな環境で ID 管理を行うための一貫したアプローチをとることをおすすめします。これらの制約や要件を満たすようにアーキテクチャを設計、調整するにあたって適用できるパターンは、いくつかの一般的なパターンに整理できます。これらのパターンは 2 つのカテゴリに分類されます。

  • 外部 ID プロバイダ(IdP)と Google Cloud を連携するパターン。Google を自社の従業員ユーザーの IdP とすることにより、Google ID の管理を自動化し、自社の IdP が引き続き信頼できる情報源となるようにします。
  • IdP を Google Cloud に拡張するパターン。Google Cloud にデプロイされたアプリケーションで自社の IdP を再利用します。直接自社の IdP に接続するか、Google Cloud 上に自社の IdP のレプリカを保持します。

外部 IdP と Google Cloud を連携するパターン

従業員ユーザーが、Google Cloud コンソール、Google Cloud CLI、または IdP として Google を使用するその他のリソースにアクセスするには、Google ID が必要です。従業員ごとに Google ID を管理するには手間がかかります。全従業員のアカウントがすでに 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 の連携をご覧ください。

GCDS と AD FS を使用した Active Directory と Cloud Identity の連携

このパターンから派生するものとして、Active Directory Lightweight Directory Services(AD LDS)、AD FS または他の SAML 準拠の IdP を使用している別の LDAP ディレクトリを使用することもできます。

ユーザー エクスペリエンス

  1. 保護されたリソースを要求すると、Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
  2. メールアドレスが Active Directory から同期されたアカウントに関連付けられている場合は、AD FS にリダイレクトされます。
  3. AD FS の構成によって、Active Directory のユーザー名とパスワードの入力を求めるログイン画面が表示される場合と、AD FS が Windows ログイン(IWA)に基づいて自動的にログインを試みる場合とがあります。
  4. 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 サーバーを使うように構成します。

Azure AD を Cloud Identity と連携させる

Microsoft Office 365 または Azure のお客様の場合、オンプレミスの Active Directory を Azure AD に接続している可能性があります。Google Cloud へのアクセスを必要とする可能性があるすべてのユーザー アカウントがすでに Azure AD と同期されている場合は、次の図に示すように、Cloud Identity と Azure AD を連携することでこの統合を再利用できます。

Cloud Identity と Azure AD の連携

この方法の詳細については、Google Cloud と Azure Active Directory の連携をご覧ください。

ユーザー エクスペリエンス

  1. 保護されたリソースを要求すると、Google のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。
  2. メールアドレスが Azure AD から同期されたアカウントに関連付けられている場合は、Azure AD にリダイレクトされます。
  3. オンプレミスの Active Directory がどのように Azure AD に接続されているかにより、Azure AD がユーザー名とパスワードの入力を求める場合と、オンプレミスの AD FS にリダイレクトされる場合があります。
  4. Azure AD で正常に認証されると、保護されたリソースにリダイレクトされます。

メリット

  • オンプレミスで追加のソフトウェアをインストールする必要がありません。
  • この方法により、Office 365、Azure、Google Cloud のリソースの間のシングル サインオンを提供することが可能になります。
  • 多要素認証(MFA)を要求するように Azure AD を構成した場合、Google Cloud にも MFA が自動的に適用されます。
  • オンプレミスの Active Directory が複数のドメインまたはフォレストを使用しており、この構造を Azure AD テナントにマップするようにカスタム Azure AD Connect 構成を設定している場合、この統合作業の恩恵を生かすことができます。
  • パスワードなどの認証情報を Google に同期する必要がありません。
  • Cloud Identity API は一般に公開されているため、オンプレミス ネットワークと Google Cloud の間や、Azure と Google Cloud の間にハイブリッド接続を構成する必要はありません。
  • Google Cloud コンソールを、Office 365 ポータルのタイルとして表示できます。

ベスト プラクティス

  • Azure AD と Cloud Identity では使用する論理構造が異なるため、その違いを理解してください。また、ドメイン、ID、グループのマッピング方法に関して、どれが最もご自身の状況に適しているかを評価してください。詳細については、Google Cloud と Azure AD の連携をご覧ください。
  • ユーザーだけでなく、グループも同期してください。この方法では、IAM を設定することにより、Azure AD のグループ メンバーシップを使用して Google Cloud のリソースに対するアクセス権を付与するユーザーを制御できます。
  • Google Cloud を使用してビジネスの継続性を確保している場合、認証を Azure AD に依存すると、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 を直接使用するアプリケーション。

AD FS を使用することで、アプリケーションはユーザーを認証できます。ただし、認証は Google ID に基づいていないため、アプリケーションはユーザー認証情報を使用して認証された API 呼び出しを実行できません。代わりに、Google Cloud APIs への呼び出しはサービス アカウントを使用して認証する必要があります。

ユーザー エクスペリエンス

  1. 保護されたリソースを要求すると、ADFS のログイン画面にリダイレクトされ、その画面でメールアドレスの入力を求められます。AD FS がインターネットに公開されていない場合、AD FS にアクセスするには、お客様のネットワークまたは企業の VPN に接続している必要があります。
  2. AD FS の構成によって、Active Directory のユーザー名とパスワードの入力を求めるログイン画面が表示される場合と、AD FS が Windows ログインに基づいて自動的にログインを試みる場合とがあります。
  3. 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 ディレクトリへのアクセス権を付与する。

利点

  • アプリケーションを変更する必要がありません。

ベスト プラクティス

  • インターネットに 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 にオンプレミス ディレクトリのレプリカを保持する。

利点

  • アプリケーションを変更する必要がありません。
  • 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 をハイブリッド環境にデプロイするその他の方法の詳細については、ハイブリッド環境での Active Directory の使用パターンをご覧ください。

Google Cloud に追加のドメイン コントローラをデプロイして、オンプレミスの Active Directory フォレストを Google Cloud に拡張する。

利点

  • 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 つ以上のドメイン コントローラをデプロイし、複数のゾーンに分散させます。複数のリージョンを使用している場合は、各リージョンにドメイン コントローラをデプロイすることを検討してください。
  • 別の Google Cloud プロジェクトと共有 VPC を使用して、ドメイン コントローラをデプロイし、最小権限でこのプロジェクトへのアクセス権を付与してください。パスワードを生成するか、ドメイン コントローラ インスタンスのシリアル コンソールにアクセスすることで、不正なプロジェクト メンバーによってドメインが危険にさらされることを防ぎます。
  • AD FS サーバー ファームと GCDS を Google Cloud にデプロイすることを検討してください。この方法を使用すると、リソースの可用性やオンプレミス ネットワークへの接続性に依存せずに、Active Directory と Cloud Identity を連携させることができます。

次のステップ