このガイドでは、Google Cloud で Active Directory を実行するためのベスト プラクティスを紹介します。このガイドでは、Google Cloud に固有なプラクティスのアプローチ、または Google Cloud に Active Directory をデプロイするときに重要となる事項に焦点を当てて説明します。このガイドは、Microsoft によって公開された Active Directory を保護するための一般的なベスト プラクティスを補完するものです。
アーキテクチャ
以降のセクションでは、アーキテクチャに関連するベスト プラクティスについて詳しく説明します。
要件に最適なアーキテクチャ パターンを使用する
Google Cloud に Active Directory をデプロイするには、まず使用するドメインとフォレストのアーキテクチャを決定する必要があります。Active Directory をすでに使用している場合は、2 つの環境を統合するかどうか、および統合する方法も決定する必要があります。
状況に最も適した設計は、オンプレミス ネットワークの設計、オンプレミスと Google Cloud リソースがどのように相互作用するか、可用性と管理の自律性の要件など、いくつかの要因によって異なります。ハイブリッド環境で Active Directory を使用するためのパターンを参照して、これらの要因が設計をどのように決定するかを確認してください。
Google Cloud とオンプレミス環境の間の信頼境界を維持する場合は、リソース フォレスト パターンの実装を検討してください。このパターンでは、別のフォレストを Google Cloud にデプロイし、一方向のフォレスト信頼を使用して、Google Cloud フォレストを既存のオンプレミスの Active Directory フォレストに統合します。
テスト環境と本番環境を分離する
Active Directory の使用状況によっては、アプリケーションの開発およびテスト中に Active Directory で頻繁な変更を行う必要がある場合があります。開発者は、Active Directory アカウントの作成および変更、グループ メンバーシップの変更（アプリケーションが承認を処理するためにグループを使用する場合）、コンピュータの参加または削除ができる必要があります。
開発およびテスト作業が本番のワークロードに影響を与えることを避けるため、また、デプロイメントのセキュリティを妨げないようにするため、開発およびテスト用にそれぞれ個別の Active Directory ドメインまたはフォレストをデプロイすることを検討してください。
個別の開発およびテスト ドメインまたはフォレストを使用すると、管理上の変更を本番環境に適用する前に確認することもできます。このような変更の例には、グループ ポリシーの実験、自動化スクリプトのテスト、またはフォレストの機能レベルを上げるなどの潜在的に危険なアクションが含まれます。
Google Cloud に Active Directory をデプロイし、Cloud Identity フェデレーションを設定する
Google Cloud に Active Directory をデプロイすると、Google Cloud 上の Windows VM を管理でき、既存のユーザー アカウントを使用して Windows VM にログインできるようになり、Kerberos、NTLM、または LDAP に認証を依存するアプリケーションをサポートできます。
ただし、Google Cloud コンソール、gcloud コマンドライン ツール、その他の Google および Google Cloud ツールを使用するには、Google ID で認証する必要があります。Active Directory を主要な管理システムとして使用する予定の場合、Google Cloud に Active Directory をデプロイすることは、既存の Active Directory と Google Cloud の連携に代わるものではありません。
たとえば、Google Cloud に別のフォレストをデプロイする場合、次の図に示すように、オンプレミスの Active Directory に対してフェデレーションを設定できます。オンプレミスの Active Directory にアカウントを持っていれば、認証に Active Directory を使用するアプリケーションだけでなく、Google ID を必要とするツールを使用できます。
既存のフォレストまたはドメインを Google Cloud に拡張する場合は、Google Cloud でデプロイされたドメイン コントローラと AD FS サーバーを使用して連携を設定することもできます。
フェデレーションを使用すると、Google アカウントと Active Directory アカウントに共通のライフサイクルを適用できるため、オンプレミスの Active Directory でユーザー アカウントを無効にすると、対応する Google ユーザーも停止されます。
ネットワーキング
次のセクションでは、ネットワークに関連するベスト プラクティスについて詳しく説明します。
Active Directory を共有 VPC ネットワークにデプロイする
Active Directory を複数のプロジェクトで使用できるようにするには、ドメイン コントローラーを共有 VPC ネットワークにデプロイします。共有 VPC ネットワークを使用すると、いくつか利点があります。
Active Directory アクセスを必要とする可能性のある各アプリケーションを、個別のプロジェクトにデプロイできることがあります。個別のプロジェクトを使用すると、リソースを分離し、アクセスを個別に管理できます。
Active Directory ドメイン コントローラに専用プロジェクトを使用すると、関連 Google Cloud リソースにアクセスできるユーザーを詳細に制御できます。
共有 VPC ネットワークを使用すると、IP アドレス管理とファイアウォール構成を一元化できます。これにより、複数のプロジェクト間での一貫性を確保できます。
VPC はグローバル リソースであるため、複数のリージョンで同じ共有 VPC ネットワークを使用できます。
ドメイン コントローラーを外部に公開しない
Active Directory の攻撃対象領域を減らすには、ドメイン コントローラに外部 IP アドレスを割り当てないようにします。
外部 IP アドレスのない VM インスタンスはデフォルトでインターネットにアクセスできないため、追加の手順を実施して、ドメイン コントローラーで Windows のアクティベーションと Windows の更新が損なわれないようにする必要があります。
Windows のアクティベーションをサポートするには、ドメイン コントローラーをデプロイする予定のサブネットで限定公開の Google アクセスを有効にし、VM インスタンスが kms.windows.googlecloud.com にアクセスできることを確認します。これにより、インターネットに直接アクセスせずにアクティベーションを行うことができます。
Windows の更新をサポートするいくつかのオプションがあります。
オンプレミスの WSUS サーバーがある場合は、ハイブリッド接続を構成し、ドメイン コントローラーが更新のソースとして WSUS サーバーを使用するように構成できます。
Cloud NAT をデプロイすることで、NAT ゲートウェイ経由のインターネット アクセスを有効にできます。
ハイブリッド接続を設定している場合は、オンプレミス NAT ゲートウェイまたはプロキシ サーバーを介して送信トラフィックをルーティングすることもできます。
ドメイン コントローラの静的 IP アドレスを事前に予約する
ドメイン コントローラは DNS サーバーとして機能するため、変更されない IP アドレスを割り当てる必要があります。そのためには、ドメイン コントローラ VM に静的内部 IP アドレスを構成します。
IP アドレスを予約すると、未使用のアドレスが自動的にデフォルトで選択されます。ドメイン コントローラの IP アドレスを簡単に記憶できるようにするには、内部静的 IP アドレスを予約します。
ドメイン コントローラーで、ネットワーク アダプターの IP アドレスを同じアドレスに設定します。この手順は省略できますが、マシンの IP アドレスがまだ動的に割り当てられている可能性があることを示す警告メッセージを Active Directory が出力しないようにします。
複数のゾーンにドメイン コントローラーをデプロイする
可用性を高めるには、少なくとも 2 つのドメイン コントローラをデプロイし、それらを複数のゾーンに分散します。サブネットと IP アドレスはゾーンに関連付けられていないため、すべてのドメイン コントローラーを単一のサブネットに展開できます。
複数のリージョンにワークロードをデプロイする場合は、関連する各リージョンにドメイン コントローラーをデプロイすることを検討してください。サブネットはリージョン リソースであるため、追加のリージョンにデプロイするには、追加のサブネットが必要になります。
リージョンごとに 1 つのサイトを作成する
クライアントがドメイン コントローラを探す際に、クライアントはまず、クライアントの IP アドレスに対応する Active Directory サイトでドメイン コントローラを探します。このサイトで利用可能なドメイン コントローラーがない場合、クライアントは続いて別のサイトでドメイン コントローラーを探します。
ドメイン コントローラまたはドメイン クライアントをデプロイするリージョンごとに個別のサイトを作成することで、この動作を利用できます。これにより、クライアントは同じリージョン内にあるドメイン コントローラの使用を自動的に優先するようになります。これにより、レイテンシとリージョン間の送信データ転送コストを削減できます。
ドメイン コントローラのないリージョンにクライアントがある場合は、サイトリンクのコストを調整してリージョンの地理的な近さを反映し、[Try Next Closest Site] 設定を有効にすることで、これらのクライアントが選択するドメイン コントローラに影響を与えることができます。
複数のサイトを使用すると、ドメイン コントローラー間のレプリケーション動作に影響します。複数のサイトを使用することの欠点の 1 つは、サイト間のレプリケーションがサイト内レプリケーションよりも発生頻度が少なくなることです。
マネージド Microsoft AD は Active Directory サイトとサービスの機能をサポートしていないため、マネージド Microsoft AD で Active Directory サイトを作成することはできません。
Cloud DNS 限定公開転送ゾーンを使用する
Compute Engine で新しい VM インスタンスを作成すると、内部 DNS とパブリック DNS へのアクセスを提供するデフォルトの DNS サーバーを使用するようにオペレーティング システムが事前構成されます。
マシンを Active Directory ドメインに参加させる前に、Active Directory によって管理されている DNS レコードをマシンが解決できることを確認する必要があります。Compute Engine が VM インスタンス用に構成するデフォルトの DNS サーバーは、内部 DNS とパブリック DNS へのアクセスを提供しますが、Active Directory が管理する DNS 名を解決することはできません。
Cloud DNS に限定公開 DNS 転送ゾーンを作成して、クライアントが Active Directory で管理されている DNS レコードを解決できるようにします。Active Directory ドメインに一致するクエリをドメイン コントローラーに転送するようにゾーンを構成します。
限定公開 DNS 転送ゾーンを使用すると、Active Directory ドメイン コントローラを DNS サーバーとして直接使用するようにクライアントを構成することに比べて、いくつかの利点があります。
VM インスタンスのネットワーク構成を調整する必要はありません。これにより、新しい VM の作成プロセスが簡略化されます。
ドメイン コントローラを昇格または降格するときは、限定公開 DNS 転送ゾーンの構成を更新するだけでよく、クライアント設定を変更する必要はありません。
VM インスタンスは引き続き内部 DNS にアクセスできます。
Active Directory ドメインと一致しない DNS レコードは Cloud DNS によって処理されるため、ドメイン コントローラーの負荷が軽減されます。
複数のドメインを使用する場合は、Active Directory ドメインごとに個別の限定公開 DNS 転送ゾーンを作成します。
Cloud DNS 限定公開転送ゾーンは、単一の VPC にスコープが設定されています。ピアリングを使用して接続された複数の VPC を使用する場合、DNS ピアリングを構成することで、限定公開転送ゾーンを他の VPC に公開できます。
ドメイン コントローラーで DNS 設定を手動で構成する必要があることは変りません。プライマリ DNS サーバーとして 127.0.0.1 を使用し、必要に応じてセカンダリ DNS サーバーとして別のドメイン コントローラーの IP アドレスを使用します。詳しくは、推奨される DNS 設定と代替オプションをご覧ください。
ハイブリッド接続
次のセクションでは、ハイブリッド接続に関連するベスト プラクティスについて詳しく説明します。
DNS 受信転送を使用して、オンプレミスから Google Cloud DNS 名を解決する
オンプレミス ネットワークのクライアントは、Google Cloud にデプロイされたリソースの DNS 名を解決できる必要がある場合があります。Google Cloud にフォレストを拡張するかリソース フォレストをデプロイする場合、DNS 受信転送を使用して、 Google Cloud にデプロイされたリソースの DNS レコードを、実行オンプレミス クライアントが認識できるようにします。受信転送を使用するには、DNS サーバー ポリシーを作成して、受信フォワーダーの IP アドレスを割り当て、このアドレスをオンプレミス ネットワークからアクセスできるようにします。
Google Cloud で使用される DNS ドメイン（例: cloud.example.com）が、オンプレミスで使用される DNS ドメインのサブドメイン（example.com など）の場合は、DNS 委任を設定します。 受信フォワーダーの IP アドレスを指すオンプレミス ドメインに NS レコードを作成します。NS レコードにより、クライアントは、Google Cloud がホストするドメインで DNS 名を検索しようとし、受信フォワーダー IP アドレスにリダイレクトされます。
Google Cloud とオンプレミスの Active Directory で使用されている DNS ドメインが異なる場合（たとえば、cloud.example.com と corp.example.com）、オンプレミスのドメインで条件付き DNS 転送を構成し、受信フォワーダーの IP アドレスをターゲットとして使用します。Google Cloud がホストするドメインの DNS 名を解決するように要求されると、オンプレミス ドメイン コントローラーはリクエストを受信フォワーダーの IP アドレスに転送します。
受信 DNS 転送を使用する場合は、ファイアウォールが適切に構成されていることを確認してください。
Active Directory に既存のドメインを拡張する場合、DNS 受信転送は必要ありません。このシナリオでは、ドメインのすべての DNS レコードが Google Cloud とオンプレミス環境全体に自動的に複製され、両方の環境で検索できるようになります。
DNS 送信転送を使用して、Google Cloud からのオンプレミス DNS 名を解決する
Google Cloud で実行されているクライアントは、オンプレミスにデプロイされたリソースの名前を解決できる必要がある場合があります。Google Cloud にフォレストを拡張するか、リソース フォレストをデプロイする場合は、Cloud DNS に限定公開転送ゾーンを作成して、オンプレミス ドメインの DNS クエリをオンプレミス DNS サーバーに転送します。
送信 DNS 転送を使用する場合は、ファイアウォールが適切に構成されていることを確認してください。
Active Directory に既存のドメインを拡張する場合、DNS 送信転送は必要ありません。このシナリオでは、ドメインのすべての DNS レコードが Google Cloud とオンプレミス環境全体に自動的に複製され、両方の環境で検索できるようになります。
VPN トンネルを使用して LDAP トラフィックを保護する
Active Directory では、LDAP プロトコルを広範囲に使用できます。Active Directory で使用される他のほとんどのプロトコルとは異なり、LDAP はデフォルトでは暗号化されていません。
Google Cloud は仮想マシン間のトラフィックを確実に暗号化するため、VPC 内で暗号化されていない LDAP を使用しても問題ありません。VPC をオンプレミス ネットワークに接続する場合は、LDAP トラフィックが信頼できるチャネルでのみ交換されるようにします。
Cloud VPN を使用して Google Cloud とオンプレミス ネットワークを接続する場合、Google Cloud とオンプレミス VPN エンドポイント間のトラフィックは IPSec を使用して自動的に暗号化されます。
Cloud Interconnect と Partner Interconnect は、暗号化を提供しません。セキュアな通信を確保するには、Google Cloud Marketplace の VPN アプライアンスを使用して、Interconnect 接続上に VPN トンネルを確立します。
フォレストの信頼に選択的認証と AES を使用する
Active Directory フォレスト間に信頼関係を作成する場合は、外部の信頼よりもフォレストの信頼を優先し、次の機能を利用してセキュリティを強化します。
リソース フォレストの送信信頼で選択的認証を有効にします。選択的認証により、明示的に権限を付与しない限り、組織フォレストのユーザーはリソース フォレストのリソースにアクセスできなくなります。
組織フォレストの受信信頼で Kerberos 完全委任のフォレスト境界の適用を有効にします。この機能は、リソース フォレスト内のリソースが組織フォレスト内のユーザーにチケットを付与するチケット（TGT）の要求を禁止するため、権限昇格攻撃の防止に効果的です。
信頼を作成するときに [The other domain supports Kerberos AES encryption] オプションを有効にします。このオプションにより、フォレスト間の認証に使用されるチケットが安全性の低い RC4 アルゴリズムではなく AES を使用して暗号化されます。
セキュリティ
次のセクションでは、セキュリティに関連するベスト プラクティスについて詳しく説明します。
Google Cloud のセキュリティが Active Directory のセキュリティを妨げないようにします
Active Directory を使用すると、どのユーザーがどのリソースにアクセスできるかをきめ細かく制御できます。マシンが Compute Engine の VM インスタンスとしてデプロイされ、ユーザーが基盤となる Google Cloud プロジェクトにアクセスできる場合、ユーザーがマシンにアクセスできるようにする追加のパスを考慮する必要があります。
Google Cloud プロジェクトで Compute インスタンス管理者の役割が割り当てられているプロジェクト メンバーは、パスワード再設定機能を使用してローカル管理者アカウントを作成できます。ローカル管理者アカウントを使用すると、グループ ポリシーを弱体化することや、ログオンしている他のユーザーのドメイン認証情報をキャプチャする可能性がある悪意のあるソフトウェアをインストールすることができるため、Active Directory ドメインのセキュリティにとっては脅威となります。
起動スクリプトを追加することで、権限のあるプロジェクト メンバーは、次回マシンを再起動したときに
nt authority\systemとして実行される VM に悪意のあるコードを挿入できます。シリアル コンソールを使用することで、特権のあるプロジェクト メンバーは Windows Special Administration Console（SAC）にもアクセスできます。Windows は、SAC 経由のログオンをローカル ログオンと見なします。したがって、SAC は、RDP を介したログオンを拒否するポリシーを回避するために悪用される可能性がありますが、ローカル ログオンを拒否するポリシーを回避することはできません。
特権のあるプロジェクト メンバーは SAC を使用して
crashdumpコマンドを発行できます。これにより、メモリダンプがディスクに書き込まれる可能性があります。このようなメモリダンプには、機密情報と認証情報が含まれる場合があります。永続ディスクを別の VM にマウントするか、スナップショットを使用すると、通常はログオンする権限のないマシンから、特権のあるプロジェクト メンバーがディスクの内容にアクセスできる可能性があります。ディスクにはメモリダンプが含まれていることも考えられます。
マネージド Microsoft AD を使用すると、デフォルトでこれらの追加のアクセスパスから保護されます。このサービスでは、プロジェクトの特権ユーザーによるドメイン管理者のパスワードのリセット、起動スクリプトの実行、AD ドメイン コントローラー VM のシリアル コンソールへのアクセスはできません。
これらのリスクをさらに軽減するには、ドメインに参加している VM インスタンスを含むプロジェクトの IAM アクセス許可が最小権限ベースで管理されていることを確認してください。組織のポリシー、グループ ポリシー、および Shielded VM のユーザーによるリスクをさらに減らすことができます。
組織のポリシーを使用して、シリアルポート アクセスを無効にします。
アカウント マネージャーを無効にして、ローカル管理者アカウントの作成を防ぐグループ ポリシーを適用します。グループ ポリシーで [ini ファイル] 設定を定義し（[コンピュータの構成] > [基本設定] > [Windows の設定] > [ini ファイル]）、次の設定を適用します。
- アクション: 更新
- ファイルパス:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - セクション名:
accountManager - プロパティ名:
disable - プロパティ値:
true
VM インスタンスからローカル管理者アカウントをすべて削除するグループ ポリシーを適用します。ローカル ユーザーとグループ機能（[コンピュータの構成] > [基本設定] > [コントロール パネルの設定] > [ローカル ユーザーとグループ]）を使用して、管理者グループとその他の機密グループからグループ メンバーシップを削除します。
Shielded VM を BitLocker ディスク暗号化と組み合わせて使用し、権限のないユーザーが永続ディスクまたはスナップショットを読み取れないようにすることを検討してください。
Active Directory のセキュリティが Google Cloud のセキュリティに干渉しないようにする
Active Directory ドメインでは、ドメイン コントローラがマシンの認証と承認を処理します。グループ ポリシー、マシンのローカル セキュリティ ポリシー、または選択的認証で制限されていない限り、ドメイン コントローラーの 1 つで ID を正常に証明できると、ドメイン内の任意のマシンにログオンできます。
Active Directory ユーザーが任意のマシンにログオンできることにより、攻撃者がドメイン内で横方向の移動を実行できる危険性があります。一部の VM インスタンスがファイアウォール制限から除外されているか、Google Cloud サービス アカウントを使用している場合、このような横方向の移動は特権の昇格につながる可能性があります。サービス アカウントの認証情報には、VM インスタンスのすべてのプロセスとユーザーがアクセスできます。したがって、Active Directory を使用してマシンにログオンできるすべてのユーザーは、これらのサービス アカウントの認証情報にアクセスして、サービス アカウントがアクセスを許可されているすべての Google Cloud リソースにアクセスできます。
マネージド Microsoft AD をセットアップするときに、サービスはグループを作成して、特定のユーザーがドメインに参加している VM に RDP でアクセスきるようにします。
横方向の動きのリスクを減らすために、ユーザーを管理層に編成し、[ネットワーク経由でコンピューターへアクセスを拒否する] および [リモート デスクトップ サービス経由でのログオンを拒否する] グループ ポリシーを使用して、階層レベルに基づいて VM へのアクセスを制限します。
リソース フォレスト トポロジで、選択的認証をさらに活用して、VM へのログオンが許可されている他のフォレストからのユーザーのセットをさらに制限します。Google Cloud と Active Directory のリソース構造を調整することで、選択的認証権限の管理を簡素化できます。Active Directory の組織単位が Google Cloud プロジェクトにマッピングされている場合、Google Cloud プロジェクトと一致するレベルで認証する権限をユーザーに付与できます。
選択的認証もグループ ポリシーも適用されない場合は、個別のサービス アカウントを作成し、サービス アカウント キーをエクスポートします。VM インスタンスのローカル ディスクまたはファイル共有に保存し、NTFS ACL を使用して保護します。これにより、承認された Active Directory ユーザーのみがキーを読み取って使用できるようになります。
ドメイン コントローラーの専用プロジェクトを使用する
ドメイン コントローラーは、Active Directory ドメインのセキュリティにおいて重要な役割を果たし、単一のドメイン コントローラーが侵害されると、Active Directory フォレスト全体が侵害される可能性があります。
不正アクセスのリスクを抑えるには、別の Google Cloud プロジェクトを使用してドメイン コントローラーをデプロイし、このプロジェクトへのアクセスを最小限の権限で付与します。プロジェクトを作成するときは、一部の権限が親フォルダから継承される場合があるので注意してください。誤って継承によるアクセスを許可しないようにするには、通常のフォルダ階層外にプロジェクトを作成することを検討してください。
プロジェクトの IAM ポリシーを構成するときは、VM インスタンス、ntds.dit データベースを含む永続ディスク、およびバックアップを含む可能性のあるストレージの場所へのアクセスを制限することに特に注意してください。
IAM ポリシーを使用してプロジェクトへのアクセスを制限することに加えて、プロジェクトを誤って削除しないように保護する必要があります。
Active Directory の管理に個別の VM とプロジェクトを使用する
Active Directory を管理するには、[Active Directory ユーザーとコンピューター] や [Active Directory 管理センター] などのツールを使用できる必要があります。これらのツールを使うと、特権ドメイン アカウントを使用してログオンする必要があります。そのため、これらのツールを実行するマシンは、認証情報の窃取またはキーロギングの恰好のターゲットになります。
攻撃者による特権ドメイン認証情報の窃取のリスクを最小限に抑えるには、ドメイン管理に専用の VM インスタンスを使用し、特権アクセス ワークステーションなどの管理 VM を処理します。
グループ ポリシーを使用して、選択したユーザーのサブセットのみが管理 VM にログオンする権利を持つようにします。階層型管理を実装した場合、このユーザーのグループは階層 0 に対応します。
ドメイン コントローラーと同様に、管理 VM は、プロジェクト メンバーによるローカル管理者アカウントの作成、シリアル コンソールを介したログオン、永続ディスクの改ざんにより危険にさらされる可能性があります。不正アクセスのリスクを制限するには、管理 VM 用に別の Google Cloud プロジェクトを使用し、このプロジェクトへのアクセスを最小特権ベースで付与します。
ハイブリッド接続を使用してオンプレミス ネットワークから管理 VM にアクセスする場合は、管理 VM を専用 VPC サブネットにデプロイします。管理 VM 専用のサブネットを使用すると、オンプレミス ファイアウォールを構成するときに、管理 VM と他の VM を区別しやすくなります。共有 VPC を使用する場合は、サブネットレベルの権限を使用して、特権管理者のみが VM インスタンスを管理サブネットにデプロイできるようにします。これにより、オンプレミス ファイアウォールが他の VM とは異なる管理 VM のルールを適用する場合、非管理 VM を管理サブネットに配置してもファイアウォール ルールを回避できなくなります。
さらに、管理 VM のログオン制限を管理するグループ ポリシーを管理サブネットに制限することを検討してください。これにより、ログオン制限（グループ ポリシーに基づく）とファイアウォール ルール（サブネット / IP アドレスに基づく）の整合が取られます。
IAM ポリシーを使用してプロジェクトへのアクセスを制限することに加えて、プロジェクトを誤って削除しないように保護する必要があります。
ファイアウォール ルールを使用してドメイン コントローラーとサーバーを保護する
ドメイン コントローラーは、LDAP、DNS、Kerberos、RPC などのいくつかのサービスを公開します。ユースケースによっては、Google Cloud にデプロイされた VM とオンプレミスで実行されているマシンは、Active Directory を利用するために、これらのサービスのさまざまなサブセットにアクセスする必要がある場合があります。
マネージド Microsoft AD を使用する場合、AD ドメイン コントローラーは専用のテナント プロジェクトにデプロイされます。AD ドメイン コントローラーをホストするネットワークは、強化された AD 固有のファイアウォール ルールで自動的に保護されます。
ドメイン コントローラと VM の攻撃対象を減らすには、ファイアウォールを使用して、必須ではないネットワーク通信を禁止します。VPC 内またはオンプレミス ネットワークから Active Directory にアクセスするために必要なファイアウォール構成の詳細については、ファイアウォールを介して Active Directory を使用するに関するガイドを参照してください。
Active Directory リソースとユーザーを管理層に編成する
Active Directory フォレスト内の一部のマシンには、Active Directory の全体的なセキュリティにとって他のマシンよりも重要なものがあります。ドメイン コントローラと管理 VM は特に重要であり、そのために潜在的な攻撃の影響を受けやすいマシンの代表例です。
各マシンの重要度を特定するには、階層の分類法を使用します。階層の数は特定のセットアップに依存しますが、まずは 3 つの階層に分けることができます。
階層 0（非常に重要）: この階層には、Active Directory フォレストのセキュリティにとって重要なすべてのマシンが含まれます。単一の階層 0 マシンが危険にさらされたら、フォレスト全体が危険にさらされることを想定する必要があります。
階層 1（重要）: この階層には、アプリケーション サーバーやデータベース サーバーなど、環境内のサーバーの大部分が含まれます。階層 1 サーバーが侵害されるとビジネスに大きな影響を与える可能性がありますが、フォレスト全体に直接的な脅威をもたらすことはありません。
階層 2（標準）: この階層には、ワークステーションまたはその他の汎用マシンが含まれます。階層 2 マシンが侵害された場合のビジネスと全体的なセキュリティへの影響は、限定的であると予想されます。
階層 2 マシンの侵害による直接的な影響は限られているように見えるかもしれませんが、ノックオン効果のリスクがあります。階層 0 または階層 1 マシンへの管理者アクセスを持つユーザーが侵害された階層 2 マシンにログオンした場合、キーロガーやその他の形式での認証情報の窃取の被害が発生する可能性があります。次に、取得した認証情報を使用して上位階層のマシンを攻撃し、全体的な影響がエスカレートする可能性があります。
このようなノックオン効果を回避するには、マシンだけでなくユーザー アカウントも分類し、これらのユーザーがアクセスできるマシンのセットを制限してください。
階層 0（非常に重要）: 階層 0 マシンにアクセスできるユーザー。
階層 1（重要）: 階層 1 マシンにアクセスできるユーザー。
階層 2（標準）: 階層 2 マシンにアクセスできるユーザー。
次の表を、ユーザーがどのリソースにアクセスする必要があるかについてのガイドラインとして使用してください。
| グループ | ティア | ドメイン アクセス | 階層 0 コンピュータ アクセス | 階層 1 コンピュータ アクセス | 階層 2 コンピュータ アクセス |
|---|---|---|---|---|---|
| Active Directory 管理者 | 0 | 管理者 | 制限ユーザー | ブロック | ブロック |
| 管理サーバー管理者 | 0 | 制限ユーザー | 管理者 | ブロック | ブロック |
| サーバー管理者 | 1 | 制限ユーザー | ブロック | 管理者 | ブロック |
| VDI ワークステーション管理者 | 2 | 制限ユーザー | ブロック | ブロック | 管理者 |
| VDI ワークステーション ユーザー | 2 | 制限ユーザー | ブロック | ブロック | 制限ユーザー |
Active Directory に管理層モデルを実装するための詳細とベスト プラクティスについては、Microsoft のドキュメントをご覧ください。
Active Directory フォレストで管理層モデルを使用する場合は、その整合性がフォレストの信頼関係によって損なわれないようにしてください。信頼できるフォレストが階層化管理モデルも適用する場合は、選択的認証を使用して、信頼できるフォレストのユーザーが同じ階層内のリソースにのみアクセスできるようにします。
信頼できるフォレストが階層化管理を実装していない場合は、信頼できるフォレストを特定の階層にマッピングし、選択的認証を使用して、信頼できるフォレストのユーザーがその特定の階層のリソースにのみアクセスできるようにします。
オンプレミス ホストに VPC Service Controls と限定公開の Google アクセスを使用する
マネージド Microsoft AD API を使用すると、管理者パスワードのリセットや他の機密性の高い操作を実行できます。重要な本番環境のデプロイでは、オンプレミス ホストで VPC Service Controls を有効にし、限定公開の Google アクセスを使用してセキュリティを強化することをおすすめします。
管理
次のセクションでは、Active Directory の管理に関するベスト プラクティスについて詳しく説明します。
Google Cloud と Active Directory のリソース構造を合わせる
Google Cloud に新しい Active Directory ドメインまたはフォレストをデプロイするときは、組織単位（OU）構造を定義して、Active Directory ドメインでリソースを編成する必要があります。まったく新しい構造を設計するのではなく、また、オンプレミス環境で使用する構造を適用するのでもなく、Google Cloud リソース階層と合った OU 構造を作成します。
階層化管理モデルを使用する場合、最上位の OU は管理階層を反映する必要があります。
階層ごとに、ユーザーとグループの OU を作成します。多数のユーザーとグループを管理する予定の場合は、必要に応じてサブ OU を作成します。
各階層で
ProjectsOU を作成し、Active Directory リソースを含む各 Google Cloud プロジェクトのサブ OU を作成します。プロジェクト固有のサブ OU を使用して、各プロジェクトの Google Cloud リソースに対応するコンピュータ アカウント、サービス アカウント、またはその他の Active Directory リソースを管理します。OU とプロジェクトの間に 1 対 1 のマッピングがあることを確認してください。
次の図は、これらの原則に従う階層の例を示しています。
Active Directory リソースを含むプロジェクトの数が中程度の場合は、Projects OU の下にフラットな OU 構造を作成できます。多数のプロジェクトを管理する予定で、複数レベルのフォルダを使用するように Google Cloud リソース階層を設計している場合は、Projects OU の下にこのフォルダ構造を反映することを検討してください。
Active Directory OU 構造と Google Cloud リソース階層を整合させることには、いくつかの利点があります。
IAM ポリシーを使用して Google Cloud プロジェクトに管理者権限を委任する場合、プロジェクト ユーザーに Active Directory の特定の権限を付与する必要が生じることもあります。たとえば、Compute Engine 管理者は、特定の OU のドメインにマシンを参加させる必要がある場合があります。OU と Google Cloud プロジェクトを連携させることで、Google Cloud と同じレベルの粒度で Active Directory にそのような権限を付与できます。
グループ ポリシー オブジェクト（GPO）を使用してコンピュータを管理する場合、Google Cloud リソース階層を反映する OU 構造は、GPO が特定のプロジェクトまたはフォルダのすべての VM に一貫して適用されることを保証します。
条件付き認証でフォレスト間の信頼を使用する場合は、Google Cloud プロジェクトに対応する組織部門を使用して、プロジェクトごとに認証を許可する権限を付与できます。
Google Cloud でプロジェクトを削除すると、関連する OU を削除するだけで、ディレクトリに古いリソースが残るリスクを軽減できます。
OU 構造がプロジェクト構造から逸脱する必要があると思われる場合は、プロジェクト構造が細かすぎるか、または粗すぎることを示している可能性があります。
Google タイムサーバーを使用する
Kerberos 認証は、プロトコルの一部としてタイムスタンプに依存します。認証が成功するには、クライアントとサーバーマシンのクロックが一定のマージン内で同期している必要があります。デフォルトでは、Active Directory が許容する誤差は 5 分以内です。
オンプレミスの Active Directory 環境での時刻の同期に関するデフォルト構成は次のとおりです。
- ドメインに参加しているマシンは、ドメイン コントローラと時刻を同期させます。
- ドメイン コントローラは、ドメインの PDC エミュレータと時刻を同期させます。
- すべてのドメインの PDC エミュレータは、時刻をフォレスト ルートドメインの PDC エミュレータと同期させます。
この構成では、フォレスト ルートドメインの PDC エミュレーターが Active Directory の最終的な時間ソースであるため、このマシンは、外部 NTP サーバーを時間ソースとして使用するように構成するのが一般的です。
Compute Engine 上にある Windows VM のデフォルト構成では、メタデータ サーバー（metadata.google.internal）が NTP サーバーとして使用され、Google の NTP サーバーを使用して正しい時刻を取得します。VM が Active Directory ドメインに参加しても、このデフォルト構成は変わりません。
フォレスト ルートドメインの PDC エミュレータが Google Cloud の外部にデプロイされていない限り、Compute Engine のデフォルト構成が維持されます。
PDC エミュレータが Google Cloud の外部にデプロイされている場合は、NTP ソースとして time.google.com を使用するように構成します。または、DOMHIER NTP ソースを使用するように Compute Engine VM の構成を再度行い、ドメイン コントローラへのインバウンド NTP トラフィック（UDP/123）を許可するようにファイアウォール ルールを構成することで、PDC エミュレータと時刻を同期する Active Directory のデフォルト動作を復元できます。
監査ログを統合および監視する
Google Cloud に Active Directory をデプロイすると、Active Directory フォレストと Google Cloud プロジェクトのセキュリティはそれぞれに関連付けられます。Google Cloud での不審なアクティビティが Active Directory を危険にさらすのと同じように、Active Directory と Windows での不審なアクティビティは、他のリソースのセキュリティを危険にさらします。
一貫性のある監査ログは、脅威や構成ミスを早期に特定し、過去のアクティビティを再構築および調査できるようにするための重要なツールです。Cloud Audit Logging を使用すると、管理アクティビティ ログとデータアクセス ログをキャプチャして分析できます。同様に、ファイアウォール ルール ロギングと VPC フローログを使用して、ネットワーク トラフィックを分析できます。ただし、これらのプラットフォーム サービスは、Active Directory で発生するセキュリティ関連のイベントを認識しません。プラットフォーム関連の監査イベントと Active Directory 関連の監査イベントの両方を対象とする一貫した監査証跡を確立するには、ドメイン コントローラとドメインに参加しているマシンに Cloud Logging エージェントをインストールして、Windows セキュリティ イベント ログを Cloud Logging にエクスポートします。
デフォルトでは、Windows セキュリティ イベント ログは、監査目的で必要なすべてのイベントをキャプチャしない場合があります。関連するすべての監査イベントを確実にキャプチャするには、監査ポリシーの構成と Active Directory の侵害の兆候を監視するに記載された Microsoft の推奨事項をご覧ください。
大量のイベントを処理する場合、重要なイベントを見逃してしまうことは珍しくありません。重要なイベントを見逃さないようにするには、特に重要または疑わしいイベントのログベースの指標を作成し、イベントの割合が変化した場合、または許容可能なしきい値を超えた場合に通知するようにアラートを構成することを検討してください。
次のステップ
Google Cloud のその他の機能を試す。チュートリアルをご覧ください。