このドキュメントでは、Google Cloud に Active Directory をデプロイする際に検討すべき要件について説明します。この情報を参考にして、適切なアーキテクチャを選択してください。
Active Directory を Cloud Identity または Google Workspace と連携（ハイブリッド環境で Workforce ユーザーを認証するためのパターンを参照）することで、既存の Active Directory ドメインのユーザーが認証を行い Google Cloud のリソースにアクセスできるようになります。Google Cloud 上の Windows サーバーを Active Directory で管理する場合や、Google Cloud でサポートされないプロトコルに依存している場合は、Google Cloud に Active Directory をデプロイすることもできます。
Active Directory を Google Cloud にデプロイする前に、使用するドメインとフォレストのアーキテクチャ、および既存の Active Directory フォレストとの統合方法を決定する必要があります。
要件の評価
Active Directory は、さまざまなドメインとフォレストのアーキテクチャをサポートしています。ハイブリッド環境では、1 つの Active Directory ドメインを複数の環境に拡張することもできます。また、別のドメインまたはフォレストを使用して、これらを信頼関係で接続することもできます。どちらのアーキテクチャが最適かは要件によって異なります。
最適なアーキテクチャを選択するため、次の要因について検討します。
- 既存のセキュリティ ゾーンとの連携
- オンプレミスと Google Cloud リソース間のやり取り
- 管理の自律性
- 対象
以下では、これらの要因について説明します。
既存のセキュリティ ゾーンとの連携
まず、オンプレミスのネットワークの設計を確認することから始めましょう。
オンプレミス環境では、VLAN やサブネットなどでネットワークが複数のセキュリティ ゾーンに分割されている場合があります。ネットワークがセキュリティ ゾーンに分割されている場合、セキュリティ ゾーン内の通信は制限されていないか、簡易的なファイアウォールと監査ポリシーで制御されています。反対に、セキュリティ ゾーン間の通信には厳密なファイアウォール、監査、トラフィック検査のポリシーが適用されます。
セキュリティ ゾーンは、単にネットワーク通信を制限して監査するためのものではありません。セキュリティ ゾーンでは信頼境界を実装する必要があります。
信頼境界
ネットワーク内の各マシンは複数のプロセスを実行します。これらのプロセスは、プロセス間通信でローカルのプロセスと通信を行う場合もあれば、HTTP などのプロトコルを介してマシン間で通信を行う場合もあります。このような状況では、プロセス間の信頼度が常に同じになるとは限りません。たとえば、同じマシンで実行されているプロセスのほうが、他のマシンで実行されているプロセスよりも信頼度が高くなることがあります。また、一部のマシンが他のマシンよりも信頼度が高くなることもあります。
信頼境界により、通信当事者の間で信頼度を変えることができます。つまり、ある通信当事者に他の当事者よりも高い信頼度を設定できます。
信頼境界は、攻撃の影響を抑えるために不可欠な機能です。攻撃対象が単一のプロセスかマシン全体かにかかわらず、1 つのシステムへの侵入に成功しただけで、攻撃が終わることはまずありません。攻撃者は続けて他のシステムにも攻撃を仕掛けてきます。同じ信頼境界内のシステムは信頼度に違いがないため、別の境界のシステムを攻撃するよりも、攻撃が容易になります。
信頼境界内のシステムが侵害された場合、その境界内の他のシステムもすべて侵害されたとみなされます。この前提は、信頼境界を識別する際に役立ちます。また、特定のシステム境界が信頼境界かどうか検証する場合にも役立ちます。次に例を示します。
たとえば、攻撃者がターゲット A に対して最高レベルのアクセス権（マシンまたはアプリケーションに対する管理者権限または root 権限）を乗っ取ったとします。これらの特権を利用してターゲット B に対して同等の権限を取得できた場合、A と B は同じ信頼境界内に存在することになります。取得できなかった場合、信頼境界は A と B の間に存在します。
ネットワーク通信を制限することで、セキュリティ ゾーンの信頼境界を実装できます。ただし、セキュリティ ゾーンを真の信頼境界にするには、境界の両側にあるワークロードで、同じセキュリティ ゾーンからのリクエストと別のセキュリティ ゾーンからのリクエストを区別し、後者をより綿密に制御する必要があります。
ゼロトラスト モデル
Google Cloud で推奨されるネットワーキング モデルはゼロトラスト モデルです。
信頼境界内の 1 つのシステムが侵害された場合、その境界内のすべてのシステムが侵害されたと想定できます。この仮定に基づくと、信頼境界が小さいほど良いことになります。信頼境界が小さいほど、危険にさらされるシステムが少なくなりますが、境界が広がるほど、攻撃の影響を受ける範囲も広がることになります。
ゼロトラスト モデルは、この考え方を論理的に表現したものです。ネットワーク内の各マシンは、一意のセキュリティ ゾーンおよび信頼境界として扱われます。マシン間の通信にはすべて同じ調査とファイアウォールが適用されます。すべてのネットワーク リクエストは、信頼できない送信元から発信されたものとして扱われます。
ネットワーク レベルでは、ファイアウォール ルールを使用してトラフィックを制限し、VPC フローログとファイアウォール ルールログを使用してトラフィックを分析することでゼロトラスト モデルを実装できます。アプリケーション レベルでは、すべてのアプリケーションが一貫した安全な方法で認証、認可、監査を行う必要があります。
Active Directory の信頼境界
Active Directory ドメインでは、ドメイン コントローラがマシンの認証と承認を処理します。いずれかのドメイン コントローラでユーザー ID が認証されると、そのユーザーはデフォルトで同じドメイン内のすべてのパソコンにログオンできます。ユーザーがドメイン コントローラから付与されているアクセス権（特権とグループ メンバーシップ）は、ドメイン内の多くのパソコンに適用されます。
グループ ポリシーを使用すると、特定のマシンに対するアクセスを禁止できます。また、ユーザーの権限を特定のマシンに制限することもできます。ただし、マシンが侵害された場合、そのマシンにサインオンしている他のドメイン ユーザーのパスワード、パスワード ハッシュ、Kerberos トークンが盗まれる可能性があります。攻撃者は、このような認証情報を悪用して、フォレスト内の他のドメインに攻撃を展開する可能性があります。
このような点を考慮すると、フォレスト内のすべてのマシンが同じ信頼境界にあることを前提とすることをおすすめします。
ドメインの境界は、組織の別の部分に対する管理の自律性の制御を目的としていますが、フォレストの境界ではより強力な分離を行うことができます。フォレストは信頼境界として機能します。
Active Directory フォレストとセキュリティ ゾーンの調整
フォレストを信頼境界として想定すると、セキュリティ ゾーンの設計方法が変わります。フォレストが 2 つのセキュリティ ゾーンにまたがっている場合、攻撃者がこれらのセキュリティ ゾーンの境界を越えるのは簡単なことです。この 2 つのセキュリティ ゾーンは実質的に 1 つになり、1 つの信頼境界を形成することになります。
ゼロトラスト モデルでは、ネットワーク内の各マシンを別個のセキュリティ ゾーンとして考えます。しかし、前述のようなネットワークに Active Directory をデプロイすると、このコンセプトが崩れ、Active Directory フォレスト内のすべてのマシンが有効なセキュリティ境界に含まれることになります。
セキュリティ ゾーンを信頼境界として機能させるには、Active Directory フォレスト全体が 1 つのセキュリティ ゾーンになっていることを確認する必要があります。
Active Directory を Google Cloud に拡張した場合の影響
Active Directory が必要な Google Cloud へのデプロイを計画する場合は、既存のセキュリティ ゾーンに合わせてデプロイを調整する際に次の 2 つの方法から選択する必要があります。
既存のセキュリティ ゾーンを Google Cloud に拡張する。Google Cloud に共有 VPC をプロビジョニングし、それを Cloud VPN または Cloud Interconnect で既存のゾーンに接続することで、既存の 1 つ以上のセキュリティ ゾーンを Google Cloud に拡張できます。
共通のゾーンを共有するオンプレミスと Google Cloud へデプロイされたリソースが共通の Active Directory フォレストを共有できるため、Google Cloud に別のフォレストをデプロイする必要はありません。
たとえば、セキュリティ ゾーンとして開発環境の境界ネットワークと本番環境の境界ネットワークが存在し、各セキュリティ ゾーンに個別の Active Directory フォレストが存在する既存のネットワークについて考えてみましょう。セキュリティ ゾーンを Google Cloud に拡張すると、Google Cloud 上のすべてのデプロイがこれら 2 つのセキュリティ ゾーンのいずれかに属し、同じ Active Directory フォレストを使用できるようになります。
新しいセキュリティ ゾーンを導入する。セキュリティ ゾーンを拡張したくない場合や、既存のセキュリティ ゾーンのセキュリティ要件が Google Cloud 環境の要件と一致しない場合など、セキュリティ ゾーンの拡張が適切でないこともあります。この場合、Google Cloud を追加のセキュリティ ゾーンとして扱うことができます。
たとえば、境界ネットワークが存在し、開発と本番環境のワークロードを区別しないオンプレミス環境について考えてみましょう。これらのワークロードを Google Cloud で分離するには、2 つの共有 VPC を作成し、これらを新しいセキュリティ ゾーンと見なします。次に、セキュリティ ゾーンごとに 1 つずつ、2 つの追加の Active Directory フォレストを Google Cloud にデプロイします。複数のセキュリティ ゾーンで認証を行えるように、フォレスト間で信頼関係を確立することもできます。
オンプレミスと Google Cloud リソース間のやり取り
Active Directory を Google Cloud に拡張するときに考慮すべき 2 つ目の要因は、オンプレミスと Google Cloud 間でのユーザーとリソースのやり取りです。ユースケースにもよりますが、その量は少ない場合も多い場合もあります。
やり取りが少ない場合
Google Cloud で Active Directory を使用する唯一の目的が、Windows サーバー群を管理し、管理者がこれらのサーバーにログインできるようにすることであれば、環境間のやり取りは少なくなります。
- Google Cloud のリソースとやり取りする従業員は、管理スタッフに限定されます。
- Google Cloud にデプロイされたアプリケーションとオンプレミス アプリケーションとのやり取りは一切ありません。また、Kerberos や NTLM などの Windows 認証機能に依存せずにやり取りを行うことができます。
やり取りが少ないシナリオでは、次のいずれかの方法でオンプレミス環境と Google Cloud 環境を統合する場合について考えます。
2 つの別個の Active Directory フォレスト: 信頼関係を共有しない別々の Active Directory フォレストを使用して 2 つの環境を分離します。管理者が認証を行えるように、Google Cloud のフォレストで別々のユーザー アカウントを管理します。
一連のユーザー アカウントを別々に管理するため、管理作業が増えます。また、従業員が退職したときに、アカウントの無効化を忘れる危険性もあります。この場合、アカウントの自動プロビジョニングをおすすめします。
オンプレミスの Active Directory のユーザー アカウントが人事情報システム（HRIS）でプロビジョニングされている場合、Google Cloud フォレストのユーザー アカウントに対しても同様のプロビジョニングと管理を行うことができます。あるいは、Microsoft Identity Manager などのツールを使用して、環境間でユーザー アカウントの同期を行うこともできます。
2 つの Active Directory フォレストを使用し、フォレスト間で信頼関係を構築する: 2 つの Active Directory フォレストを使用してフォレスト間の信頼関係を構築することで、アカウントを別々に維持する必要がなくなります。管理者は、両方の環境で同じユーザー アカウントを使用して認証を行います。環境間の分離レベルは弱くなりますが、別々のフォレストを使用することで、オンプレミスと Google Cloud 環境の間で信頼境界を維持できます。
やり取りが適度な量の場合
実際のユースケースはもう少し複雑な場合があります。例:
- Google Cloud にデプロイされている Windows サーバーにログインする管理者が、オンプレミスでホストされているファイル共有にアクセスする必要がある。
- アプリケーションが、Kerberos または NTLM を使用して、環境の境界を越えて認証と通信を行う場合がある。
- 従業員が、統合 Windows 認証（IWA）を使用して、Google Cloud にデプロイされたウェブ アプリケーションの認証を行えるようにする。
このシナリオでは、2 つの個別の Active Directory フォレストを使用するには制限が多すぎます。たとえば、2 つのフォレスト間で Kerberos で認証を行うことはできません。また、NTLM パススルー認証を使用するには、ユーザー アカウントとパスワードを同期させる必要があります。
この場合は、フォレスト間の信頼関係を持つ 2 つの Active Directory フォレストを使用することをおすすめします。
やり取りが非常に多い場合
仮想デスクトップ インフラストラクチャ（VDI）のデプロイを含む特定のワークロードでは、オンプレミスのリソースと Google Cloud にデプロイされたリソース間のやり取りが非常に多くなる場合があります。環境間のリソースが密に結合されているときに、環境間の信頼関係を維持するのが現実的でない場合もあります。制約が多く、2 つのフォレスト間で信頼関係を確立できない場合もあります。
この場合は、単一の Active Directory フォレストを使用し、それを環境間で共有することをおすすめします。
管理の自律性
Active Directory を Google Cloud に拡張するときに考慮すべき 3 つ目の要因は管理上の自律性です。
オンプレミスと Google Cloud でワークロードを分散する場合、Google Cloud で実行するワークロードとオンプレミスのワークロードが大きく異なることがあります。2 つの環境を管理するために、別々のチームを用意しなければならないこともあります。
チーム間で責任を分担するには、それぞれのチームに、ある程度の管理の自律性が必要になります。Active Directory では、代理管理または個別のドメインを使用して、チームにリソースの管理権限を付与できます。
代理管理を使用すると、管理業務を簡単に委任し、ある程度の自律性をチームに与えることができます。単一ドメインの維持は、環境やチーム間での一貫性の維持にも役立ちます。
ただし、すべての管理機能を委任することはできません。また、単一ドメインを共有すると、チーム間の調整で余分な管理作業が増える可能性があります。このような場合は、別のドメインを使用することをおすすめします。
対象
Active Directory を Google Cloud に拡張する際に考慮すべき最後の要因は可用性です。Active Directory フォレスト内の各ドメインに対して、ドメイン コントローラはそのドメイン内のユーザーの ID プロバイダとして機能します。
認証に Kerberos を使用している場合、ユーザーは次のようなポイントで Active Directory ドメイン コントローラと通信を行う必要があります。
- 初期認証（チケットを付与するチケットの取得）
- 定期的な再認証（チケットを付与するチケットの更新）
- リソースによる認証（サービス チケットの取得）
初期認証と定期的な再認証では、ユーザーが属するドメインのドメイン コントローラとのみ通信を行います。
リソースを使用して認証を行う場合、リソースが属するドメインによっては、複数のドメイン コントローラと通信が必要になる可能性があります。
- リソースがユーザーと同じドメインにある場合、ユーザーは同じドメイン コントローラ（または同じドメインの別のドメイン コントローラ）を使用して認証プロセスを完了できます。
- リソースが別のドメインにあり、ユーザーのドメインと直接的な信頼関係がある場合、ユーザーは少なくとも 2 つのドメイン コントローラ（リソースのドメインとユーザーのドメイン）と通信を行う必要があります。
- リソースとユーザーが異なるドメインに属し、これらのドメイン間に間接的な信頼関係しかない場合、認証を成功させるには、信頼パス内のすべてのドメインのドメイン コントローラと通信を行う必要があります。
異なる Active Directory ドメインまたはフォレストにユーザーとリソースを配置すると、全体的な可用性が低下する可能性があります。認証で複数のドメインとのやり取りが必要になるため、1 つのドメインが停止すると他のドメインのリソースの可用性に影響を及ぼす可能性があります。
Active Directory トポロジが可用性に与える影響を考慮して、ハイブリッド戦略に合わせて Active Directory トポロジを調整することをおすすめします。
分散ワークロード
各コンピューティング環境が提供するユニークな機能を最大限に活用するには、ハイブリッドなマルチクラウド アプローチを採用し、コンピューティング環境ごとにワークロードを分散させます。このような環境では、Google Cloud にデプロイするワークロードは、オンプレミスで実行されている他のインフラストラクチャやアプリケーションに依存する可能性が高いため、可用性の高いハイブリッド接続が重要な要件になります。
別の Active Directory フォレストまたはドメインを Google Cloud にデプロイし、信頼関係を使用してオンプレミスの Active Directory に接続する場合は、Google Cloud とオンプレミス環境の間に別の依存関係を追加します。この依存関係により、可用性への影響を最小限に抑えることができます。
冗長なワークロード
Google Cloud を使用してビジネスの継続性を確保している場合、Google Cloud のワークロードはオンプレミス環境のワークロードの一部を反映したものになります。この設定では、障害が発生した場合に一方の環境が他の環境の役割を引き継ぎます。したがって、これらの環境間の依存関係をすべて調べる必要があります。
別の Active Directory フォレストまたはドメインを Google Cloud にデプロイし、信頼関係を使用してオンプレミスの Active Directory に接続する場合、この設定の目的を損なう依存関係を作成してしまう可能性があります。オンプレミスの Active Directory が使用できなくなると、Google Cloud にデプロイされ、ドメイン間認証またはフォレスト間認証に依存するすべてのワークロードが使用できなくなる可能性があります。
ビジネスの継続性の確保を目的としている場合は、相互に接続していない環境で別の Active Directory フォレストを使用できます。既存の Active Directory ドメインを Google Cloud に拡張することもできます。追加のドメイン コントローラを Google Cloud にデプロイし、環境間でディレクトリ コンテンツを複製することで、環境を独立して運用できます。
統合パターン
要件を評価したら、次の意思決定ツリーを使用して、適切なフォレストとドメインのアーキテクチャを特定します。
以下では、各パターンについて詳しく説明します。
同期されたフォレスト
同期されたフォレストを使用する場合は、Google Cloud に別の Active Directory フォレストをデプロイします。このフォレストを使用して、Google Cloud にデプロイされているリソースと、これらのリソースの管理に必要なユーザー アカウントを管理します。
新しいフォレストとオンプレミスの既存のフォレストの間に信頼関係を作成する代わりに、アカウントを同期します。リーディング システムとして HRIS を使用してユーザー アカウントを管理する場合は、Google Cloud にホストされている Active Directory フォレストにユーザー アカウントをプロビジョニングするように HRIS を構成できます。また、Microsoft Identity Manager などのツールを使用して、環境間でユーザー アカウントの同期を行うこともできます。
次のいずれかに該当する場合は、同期されたフォレストの使用を検討してください。
- Google Cloud の使用目的が冗長デプロイ パターンの 1 つに適しており、オンプレミス環境と Google Cloud 間でランタイムの依存関係が発生しないようにする必要がある。
- 多層防御策として、または一方の環境を他方よりも信頼していることから、オンプレミスの Active Directory 環境と Google Cloud にホストされている Active Directory 環境の間で信頼境界を維持する。
- Active Directory で管理されているオンプレミスのリソースと Google Cloud 上のリソースの間でやり取りが少ないか、やり取りがないことが想定される。
- Google Cloud でホストされている Active Directory 環境に必要なユーザー アカウントの数が少ない。
利点:
- 同期されたフォレストを使用すると、2 つの Active Directory 環境間の分離を強固に保つことができます。1 つの環境が侵害されても、そこから別の環境が攻撃される可能性は低くなります。
- Active Directory を運用するために、オンプレミス ネットワークと Google Cloud ネットワークの間にハイブリッド接続を設定する必要がありません。
- オンプレミスの Active Directory が停止しても、Google Cloud にホストされた Active Directory は影響を受けません。このパターンは、ビジネスの継続性を目的とするユースケースや、高可用性を必要とするシナリオに最適です。
- Google Cloud にホストされた Active Directory フォレストを管理するチームに、高度な管理上の自律性を与えることができます。
- このパターンは Managed Service for Microsoft Active Directory でサポートされています。
ベスト プラクティス:
- 2 つの Active Directory フォレスト間でユーザー アカウントのパスワードを同期しないようにします。同期すると、環境間の分離が損なわれます。
- パススルー認証に依存しないようにします。この認証方法では、ユーザー アカウントのパスワードを同期する必要があります。
- 従業員が退職したときに、両方の Active Directory 環境のアカウントを無効にするか、削除します。
リソース フォレスト
リソース フォレストを使用する場合は、Google Cloud に別の Active Directory フォレストをデプロイします。このフォレストを使用して、Google Cloud にデプロイされているリソースと、フォレストの管理に必要な最小限の管理ユーザー アカウントを管理します。オンプレミスの既存 Active Directory フォレストと信頼関係を確立することで、既存のフォレストのユーザーは、認証を受け Google Cloud にホストされている Active Directory フォレストで管理されているリソースにアクセスできるようになります。
このパターンを進化させ、中央に既存の Active Directory フォレストを中心としたハブ / スポーク トポロジを構成し、多くのリソース フォレストに接続することもできます。
次のいずれかに該当する場合は、リソース フォレストの使用を検討してください。
- Google Cloud の使用目的が分散デプロイ パターンの 1 つに適しており、オンプレミス環境と Google Cloud の間の依存関係を許容する。
- 多層防御策として、または一方の環境を他方よりも信頼していることから、オンプレミスの Active Directory 環境と Google Cloud にホストされている Active Directory 環境の間で信頼境界を維持する。
- Active Directory で管理されているオンプレミスのリソースと Google Cloud 上のリソースの間で適度なやり取りが発生する。
- Google Cloud にデプロイされたリソースにアクセスするユーザーが非常に多い。たとえば、認証に IWA を使用するウェブ アプリケーション。
利点:
- リソース フォレスト パターンを使用すると、2 つの Active Directory 環境間の信頼境界を維持できます。信頼関係の構成方法によっては、1 つの環境が侵害されても、そこから他の環境が攻撃される可能性は低くなります。
- このパターンは、Managed Service for Microsoft Active Directory で完全にサポートされています。
- Google Cloud にホストされた Active Directory フォレストを管理するチームに、高度な管理上の自律性を与えることができます。
ベスト プラクティス:
- Google Cloud にホストされている Active Directory が既存の Active Directory を信頼するように、一方向の信頼関係を使用して 2 つの Active Directory フォレストを接続します。
- 選択的認証を使用して、オンプレミスの Active Directory のユーザーにアクセスを許可する Google Cloud でホストされている Active Directory のリソースを制限します。
- オンプレミス ネットワークと Google Cloud 間で高可用性のネットワーク接続を維持するため、Dedicated Interconnect、Partner Interconnect、または Cloud VPN で冗長接続を確立します。
拡張ドメイン
拡張ドメインを使用する場合は、1 つ以上の既存の Active Directory ドメインを Google Cloud に拡張します。ドメインごとに 1 つ以上のドメイン コントローラを Google Cloud にデプロイします。これにより、すべてのドメインデータとグローバル カタログが複製され、Google Cloud で使用できるようになります。オンプレミスと Google Cloud のサブネットで別々の Active Directory サイトを使用することで、クライアントが最も近いドメイン コントローラと通信できるようになります。
次のいずれかに該当する場合は、拡張ドメインの使用を検討してください。
- Google Cloud の使用目的が冗長デプロイ パターンの 1 つに適しており、オンプレミス環境と Google Cloud 間でランタイムの依存関係が発生しないようにする必要がある。
- オンプレミスと Google Cloud の Active Directory で管理されているリソース間のやり取りが非常に多いことが想定される。
- 認証に LDAP を使用するアプリケーションで認証処理を高速化する必要がある。
利点:
- オンプレミスの Active Directory が停止しても、Google Cloud にホストされた Active Directory は影響を受けません。このパターンは、ビジネスの継続性を目的とするユースケースや、高可用性を必要とするシナリオに最適です。
- オンプレミス ネットワークと Google Cloud 間の通信を制限できます。これにより、帯域幅を節約し、レイテンシを改善できる可能性があります。
- グローバル カタログのすべてのコンテンツが Active Directory に複製されます。Google Cloud にホストされているリソースから効率的にアクセスできます。
ベスト プラクティス:
- すべてのドメインを複製する場合、オンプレミス ネットワークと Google Cloud ネットワーク間の通信が、ドメイン コントローラ間の Active Directory の複製に制限されます。フォレストのドメインのサブセットのみを複製する場合、Google Cloud 上で実行されるドメインに参加しているサーバーは、複製されていないドメインのドメイン コントローラと通信が必要になることがあります。オンプレミスと Google Cloud 間の通信に適用されるファイアウォール ルールですべての関連するケースを考慮する必要があります。
- サイト間の複製は一定の間隔で行われます。オンプレミス ドメイン コントローラのサーフェスで実行された更新はすぐに Google Cloud に反映されません（逆も同様）。
- Google Cloud でドメインデータの読み取り専用コピーを維持するため、読み取り専用のドメイン コントローラ（RODC）の使用を検討してください。ただし、ユーザー パスワードのキャッシュに関連するトレードオフに注意が必要です。RODC にパスワードのキャッシュ保存を許可し、パスワード キャッシュを事前に設定すると、オンプレミス ドメイン コントローラが停止しても、Google Cloud にデプロイされたリソースは影響を受けません。ただし、通常のドメイン コントローラを比べると、RODC を使用するセキュリティ上の利点は限定的です。パスワード キャッシュを無効にすれば、侵害された RODC の影響が Active Directory の残りの部分に及ぶリスクを抑えることができますが、その反面、オンプレミス ドメイン コントローラが停止した場合、Google Cloud に影響を受けることになります。
拡張フォレスト
拡張フォレストを使用する場合、Google Cloud に新しい Active Directory ドメインをデプロイしますが、このドメインを既存のフォレストに統合します。この新しいドメインで、Google Cloud にデプロイされているリソースを管理し、ドメインの管理に必要な管理ユーザー アカウントの数を最小限にします。
フォレストの他のドメインに暗黙的な信頼関係を拡張することで、他のドメインの既存ユーザーが認証を受け、Google Cloud 上の Active Directory ドメインで管理されているリソースにアクセスできるようになります。
次のいずれかに該当する場合は、拡張フォレストの使用を検討してください。
- Google Cloud の使用目的が分散デプロイ パターンの 1 つに適しており、オンプレミス環境と Google Cloud の間の依存関係を許容する。
- Google Cloud にデプロイするリソースに、既存のドメインと異なるドメイン構成または構造が必要になる。または、Google Cloud でホストされたドメインを管理するチームに高度な管理上の自律性を与える。
- オンプレミスと Google Cloud の Active Directory で管理されているリソース間のやり取りが適度な量、または非常に多いと想定される。
- Google Cloud にデプロイされたリソースにアクセスするユーザーが多い。たとえば、認証に IWA を使用するウェブ アプリケーション。
利点:
- グローバル カタログのすべてのコンテンツが Active Directory に複製されます。Google Cloud にホストされているリソースから効率的にアクセスできます。
- オンプレミス ネットワークと Google Cloud 間の複製トラフィックは、グローバル カタログの複製に限定されます。これにより、帯域幅全体の使用量を抑えることができます。
- Google Cloud にホストされた Active Directory ドメインを管理するチームに、高度な管理上の自律性を与えることができます。
ベスト プラクティス:
- オンプレミス ネットワークと Google Cloud 間で高可用性のネットワーク接続を維持するため、Dedicated Interconnect、Partner Interconnect、または Cloud VPN で冗長接続を確立します。
拡張ドメインとリソース フォレスト
拡張ドメインとリソース フォレストを使用するパターンは、リソース フォレストを拡張したパターンになります。リソース フォレストを使用すると、環境間の信頼境界を維持し、管理上の自律性を与えることができます。リソース フォレストの問題点は、オンプレミス ドメイン コントローラの可用性とオンプレミス データセンターとのネットワーク接続の信頼性によって全体的な可用性が決まる点です。
リソース フォレストと拡張ドメインを組み合わせることで、この問題を解消できます。ドメインを複製すると、Google Cloud にユーザー アカウントが配置され、オンプレミス ドメイン コントローラが使用できない場合や、ネットワーク接続が失われた場合でも、Google Cloud にホストされたリソースに対するユーザー認証を行うことができます。
次のいずれかに該当する場合は、拡張ドメインとリソース フォレストの使用を検討してください。
- メインの Active Directory フォレストとリソース フォレストの間の信頼境界を維持したい。
- オンプレミス ドメイン コントローラの停止やオンプレミス環境とのネットワークの切断が、Google Cloud でホストされたワークロードに影響を与えないようにする必要がある。
- オンプレミスと Google Cloud 上の Active Directory 管理リソース間のやり取りは適度な量であることが想定される。
- 1 つの Active Directory ドメインで、Google Cloud 上のリソースにアクセスするユーザーが多い。たとえば、認証に IWA を使用するウェブ アプリケーション。
利点:
- オンプレミスの Active Directory が停止しても、Google Cloud にホストされたリソースは影響を受けません。このパターンは、ビジネスの継続性を目的とするユースケースや、高可用性を必要とするシナリオに最適です。
- このパターンでは、2 つの Active Directory フォレスト間の信頼境界を維持できます。信頼関係の構成方法によっては、1 つの環境が侵害されても、そこから他の環境が攻撃される可能性は低くなります。
- オンプレミス ネットワークと Google Cloud ネットワーク間の通信は、ドメイン コントローラ間での Active Directory の複製に限定されます。ファイアウォール ルールを実装して他のすべての通信を禁止し、環境間の分離を強化できます
- Google Cloud にホストされた Active Directory フォレストを管理するチームに、高度な管理上の自律性を与えることができます。
- リソース フォレストには Managed Microsoft AD を使用できます。
ベスト プラクティス:
- 拡張ドメインのドメイン コントローラを個別の Google Cloud プロジェクトと VPC にデプロイし、これらのコンポーネントをリソース フォレストのコンポーネントから分離します。
- VPC ピアリングを使用して、VPC を共有 VPC またはリソース フォレストで使用する VPC に接続し、通信を Kerberos のユーザー認証とフォレストの信頼作成に制限するようにファイアウォールを構成します。
- Google Cloud にホストされている Active Directory が既存の Active Directory フォレストを信頼するように、一方向の信頼関係を使用して 2 つの Active Directory フォレストを接続しますが、その逆は行われません。
- 選択的認証を使用して、他のフォレストのユーザーにアクセスを許可するリソース フォレスト上のリソースを制限します。
- サイト間の複製は一定の間隔で行われます。オンプレミス ドメイン コントローラのサーフェスで実行された更新はすぐに Google Cloud に反映されません（逆も同様）。
- 拡張ドメインに RODC を使用することを検討します。ただし、リソース フォレストのみの場合と異なり、可用性の利点を維持するためにパスワードのキャッシュを許可します。
次のステップ
- Managed Service for Microsoft Active Directory の詳細を確認する。
- Google Cloud での Active Directory リソース フォレストのデプロイに関するベスト プラクティスを確認する。
- Google Cloud にフォールト トレラントな Active Directory 環境をデプロイする方法について学習する。
- VPC 設計のベスト プラクティスを確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。