要塞環境の高可用性とディザスター リカバリーの考慮事項

この記事では、Privileged Access Management (PAM) に対し Active Directory Domain Services (AD DS) と Microsoft Identity Manager 2016 (MIM) を展開する際の高可用性とディザスター リカバリーに関する考慮事項を説明します。

企業は、Windows Server、SQL Server、Active Directory でのワークロードの高可用性と障害復旧に重点を置いています。 しかし、Privileged Access Management の要塞環境における信頼性の高い可用性も重要です。 要塞環境は、ユーザーが管理者ロールを果たすためにそのコンポーネントと対話するので、組織の IT インフラストラクチャの重要な部分です。 高可用性に関する全般的な情報については、ホワイト ペーパー「Microsoft High Availability Overview (Microsoft の高可用性の概要)」をダウンロードできます。

高可用性とディザスター リカバリーのシナリオ

高可用性とディザスター リカバリーを計画する場合は、以下の質問を考慮してください。

  • どの機能が停止により影響を受ける可能性がありますか。
  • どの機能がビジネスや IT 運用に不可欠ですか。
  • これらのシステムで停止の原因となる可能性のあるリスクはどのようなものですか。

これらの考慮事項の範囲は展開と運用の総コストに影響するため、組織は特定の機能を他の機能より優先したり、また優先度の低い機能が一時停止するリスクを容認したりする場合もあります。 次の表に、組織が使用する可能性のある 1 つの優先順位の概要を示します。

要塞フォレストの機能 復旧中の相対的な優先順位 機能が使用できない場合の軽減策
信頼関係の確立 要塞環境が復元されるまで待機する
ユーザーとグループの移行 要塞環境が復元されるまで待機する
MIM 管理 要塞環境が復元されるまで待機する
特権ロールのアクティブ化 中間 専用のスマート カードを使用するアカウントで、管理グループにユーザーを手動で追加する
リソース管理 専用のスマート カードを使用するアカウントで、管理グループにユーザーを手動で追加する
既存のフォレストでのユーザーとグループの監視 要塞環境が復元されるまで待機する

それでは、これらの要塞フォレストの各機能を順に見ていきましょう。

信頼関係の確立

既存のフォレストのドメインと要塞環境のフォレスト間には、フォレストの信頼関係が必要です。 これは、要塞環境へのユーザーの認証で既存のフォレストのリソースを管理できるようにするためです。 たとえば、以前のバージョンの Windows Server 上の既存のドメインからユーザーの移行を許可するために、追加の構成が必要な場合があります。

信頼関係の確立には、既存のフォレストのドメイン コントローラーだけでなく、要塞環境の MIM コンポーネントと AD コンポーネントがオンラインであることが必要です。 信頼関係の確立中にこれらのいずれかが停止した場合は、停止が解消されると管理者は再試行できます。 既存のフォレストのドメイン コントローラーまたは要塞環境が停止の後に復旧している場合、MIM には、信頼関係が引き続き有効であることを確認するために使用できる PowerShell コマンドレット Test-PAMTrustTest-PAMDomainConfiguration が含まれます。

ユーザーとグループの移行

信頼関係が確立されると、要塞環境にシャドウ グループと、それらのグループおよび承認者のメンバーのユーザー アカウントを作成できます。 これにより、それらのユーザーが特権ロールをアクティブ化して、有効なグループ メンバーシップを再取得できるようになります。

ユーザーとグループの移行には、既存のフォレストのドメイン コントローラーだけでなく、要塞環境の MIM コンポーネントと AD コンポーネントがオンラインであることが必要です。 既存のフォレストのドメイン コントローラーが到達できない場合は、他のユーザーとグループを要塞環境に追加することはできませんが、既存のユーザーとグループには影響はありません。 移行中にコンポーネントのいずれかが停止した場合は、停止が解消されると管理者は再試行できます。

MIM 管理

ユーザーとグループを移行すると、管理者は MIM でロールの割り当てをさらに構成して、ロールへのアクティブ化の候補としてユーザーをリンクすることができます。 承認と Azure MFA のための MIM ポリシーを構成することもできます。

MIM 管理では、要塞環境の MIM コンポーネントと AD コンポーネントがオンラインである必要があります。

特権ロールのアクティブ化

ユーザーが特権ロールをアクティブ化するときは、要塞環境のドメインに対して認証し、MIM に要求を送信する必要があります。 MIM には、SOAP と REST の API に加え、PowerShell と Web ページのユーザー インターフェイスが含まれています。

特権ロールのアクティブ化では、要塞環境の MIM コンポーネントと AD コンポーネントがオンラインである必要があります。 また、MIM を選択したロールのアクティブ化に Azure MFA を使用するように構成する場合は、Azure MFA サービスへの接続にインターネット アクセスが必要です。

リソースの管理

ユーザーが正常にロールにアクティブ化されると、ドメイン コントローラーは既存のドメインのドメイン コントローラーで使用できる Kerberos チケットを生成でき、ユーザーの新しい一時的なグループ メンバーシップを認識します。

リソース管理では、リソース ドメインのドメイン コントローラーと要塞環境のドメイン コントローラーがオンラインであることが必要です。 ユーザーがアクティブ化されると、Kerberos チケットを発行するために、MIM または SQL が要塞環境でオンラインである必要はありません。 (要塞環境の機能レベルとして Windows Server 2012 R2 を使用すると、一時的なグループ メンバーシップを終了するために MIM がオンラインである必要がありますのでご注意ください。)

既存のフォレストでのユーザーとグループの監視

MIM には、既存のドメインのユーザーとグループを定期的に確認し、それに応じて MIM データベースと AD を更新する PAM 監視サービスも含まれています。 このサービスは、ロールのアクティブ化のため、またはリソース管理中にオンラインにする必要はありません。

監視では、既存のフォレストのドメイン コントローラーだけでなく、要塞環境の MIM コンポーネントと AD コンポーネントがオンラインであることが必要です。

展開オプション

環境の概要では、高可用性を対象としていないテクノロジの学習に適した基本的なトポロジを例示しています。 このセクションでは、1 つのサイトを持つ組織だけでなく、複数の既存のサイトを持つ組織向けに、高可用性を提供するためにそのトポロジ上で拡張する方法について説明します。

ネットワーク

要塞環境内のコンピューター間のネットワーク トラフィックは、別の物理ネットワークまたは仮想ネットワークを使用するなどにより、既存のネットワークから分離する必要があります。 要塞環境のリスクによっては、コンピューター間で独立して物理的な相互接続を行うことが必要な場合もあります。 特定のフェールオーバー クラスター テクノロジでは、ネットワーク インターフェイスに関して追加の要件があります。

要塞環境にある Active Directory Domain Services をホストしているコンピューターと MIM サービスをホストしているコンピューターには、次に対する既存のフォレスト内のリソースへの双方向接続が必要です。

  • PRIV フォレストのドメイン コントローラーによって認証されるユーザー
  • アクティブ化を要求するユーザー
  • 既存のフォレスト内のリソースで消耗可能な Kerberos チケットを持つユーザー
  • 既存のフォレストのドメインを監視する MIM
  • 既存のフォレストにあるメール サーバー経由で電子メールを送信する MIM

最小の高可用性トポロジ

組織は、次の制約に応じて、高可用性が必要な要塞環境内の機能を選択できます。

  • 要塞環境で提供されるすべての機能に対する高可用性には、少なくとも 2 台のドメイン コントローラーが必要です。
  • アクティブ化要求の高可用性には、MIM サービスをホストする少なくとも 2 台のコンピューターが必要です。また SQL Server に対する高可用性も必要です。
  • フェールオーバー クラスターを備えた SQL Server の高可用性には、SQL Server を提供する少なくとも 2 台のサーバーが必要であり、これらのサーバーはドメイン コントローラーと同じものにすることはできません。
  • 各サーバーに対する攻撃の可能性を最小化するため、MIM サービスはドメイン コントローラー上にインストールしないでください。

要塞環境のすべての機能に対する最小の高可用性トポロジは、少なくとも 4 台のサーバーと共有記憶域から構成されます。 2 台のサーバーは、ドメイン コントローラーとして構成し、Active Directory Domain Services を提供する必要があります。 他の 2 つのサーバーは、フェールオーバー クラスターとして構成して、SQL ServerサービスをMIMできます。

さらに、要塞環境の典型的な展開には、これらのサーバーの管理用の特権管理ワークステーションと監視コンポーネントも含まれます。

次の図は、考えられる 1 つのアーキテクチャを示しています。

要塞トポロジ - 図

負荷状態下でパフォーマンスを向上させるため、または以下に示すような地理的な冗長性のために、追加のサーバーをこれらの各機能に対して構成することができます。

複数のサイトをサポートする展開

複数のサイト間で展開されているリソースに対する適切な展開トポロジの選択は、次の 3 つの要因によって異なります。

  • 高可用性とディザスター リカバリーの目的とリスク
  • 要塞環境をホストするためのハードウェアの機能
  • 各サイトの管理作業モデル。

最も簡単なアプローチの 1 つは、特定のサイトで要塞環境をホストすることです。 通常の状況下では、ユーザーはそのサイトの要塞環境と要求のアクティブ化の MIM 展開に接続し、アクティブ化は各サイトのリソース全体で反映されます。 ネットワーク リンクが壊れているか、要塞環境をホストしているサイトが使用できない場合は、ネットワークが再接続されるまで一時的な管理を実行するために、オフラインでの資格情報に別のサイトでアクセスできます。 この方法は、ブランチ オフィスなどの特定のサイトのローカル管理がほとんど行われず、そのサイトの再接続を組織のネットワークの残りの部分に制限することが予測される状況に適している場合があります。

複数のサイト トポロジでの単一の要塞 - 図

サイト全体の高可用性とディザスター リカバリーでは、各サイトで要塞環境のコンポーネントを展開して、共通の PRIV ディレクトリと共通の SQL データベースを共有することもできます。 このトポロジでは、ネットワーク リンクが損傷した場合、各サイトのユーザーは独立して操作を続行できます。

複数のサイト トポロジでの複数の要塞 - 図

この展開アプローチでの制約の 1 つは、SQL Server に両方のサイトにまたがるクラスターが必要であり、これにより展開が複雑になる可能性があることです。 そのような状況では、要塞環境の Active Directory (PRIV フォレスト) をレプリケートすることのみを代替方法として検討します。 サイト間でネットワークの中断が発生した場合は、自身の特権ロールを既にアクティブ化しているサイト B のユーザーは、サイト B のリソースを管理する操作を続行できます。

複数のサイト トポロジでのレプリケートされた要塞 - 図

各サイトが個別の管理上の境界を表している場合は、複数の独立した要塞環境を展開することもできます。 各要塞環境には同じソフトウェアが用意されていますが、ドメイン名はそれぞれ異なります。また各要塞環境のディレクトリとデータベース間には共通点はありません。 特定のサイトのリソースを管理する必要のあるユーザーは、そのサイトの要塞環境でユーザー アカウントをアクティブにします。

複数のサイト トポロジでの独立した要塞 - 図

最後に、複数の要塞環境を独立して構成し、特定のドメインのリソースを管理する場合のために、より複雑な展開を行うこともできます。

複数のサイト トポロジでの複雑な要塞 - 図

ホストされている要塞環境

一部の組織では、組織の既存のサイトから独立した要塞環境を確立することも検討されています。 要塞環境ソフトウェアは、組織のネットワーク内または外部のホスティング プロバイダーのいずれかの仮想化プラットフォームでホストすることができます。 このアプローチを評価するときには、次の点に注意してください。

  • 既存のドメインからの攻撃を防止するために、要塞環境の管理は、既存のドメインの管理アカウントから分離する必要があります。
  • 要塞環境には、既存のドメインのドメイン コントローラーへの TCP/IP 接続が必要です。 ポートの一覧は、「ドメインと信頼関係に関してファイアウォールを構成する方法」をご参照ください。
  • Active Directory ドメイン サービスの仮想化された展開には、「仮想化ドメイン コントローラーの展開と構成」で説明されているように、仮想化プラットフォームの特定の機能が必要です。
  • MIM サービス用の SQL Server の高可用性の展開には、以下の「SQL Server データベース記憶域」セクションに記載されている特殊な記憶域の構成が必要です。 一部のホスティング プロバイダーでは、現在、SQL Server フェールオーバー クラスターに適したディスク構成を持つ Windows Server ホスティングを提供していない場合があります。

展開準備と復旧手順

要塞環境の高可用性とディザスター リカバリーに対応した展開の準備では、Windows Server Active Directory、SQL Server と共有記憶域上のそのデータベース、および MIM サービスとその PAM コンポーネントをインストールする方法を検討する必要があります。

Windows Server

Windows Server には、高可用性のための組み込み機能が用意されており、複数のコンピューターがフェールオーバー クラスターとして連携することができます。 クラスター化されたサーバーは、物理ケーブルとソフトウェアによって接続されます。 クラスター ノードに障害が発生した場合、他のノードがサービスの提供を開始します。このプロセスを "フェールオーバー" といいます。 詳細については、「フェールオーバー クラスタリングの概要」をご参照ください。

要塞環境内のオペレーティング システムとアプリケーションが、セキュリティの問題に関する更新プログラムを受信することを確認してください。 これらの更新プログラムの一部では、サーバーの再起動が必要になる場合があるため、サーバー全体で更新プログラムが適用される時間を調整して、長時間停止するのを回避します。 1 つの方法は、Windows Server フェールオーバー クラスター内のサーバーに対してクラスター対応更新を使用する方法です。

要塞環境内のサーバーは、ドメインに参加して、ドメイン サービスに依存します。 これらのサーバーが、誤って DNS などのサービス用の特定のドメイン コントローラーに依存して構成されないようにしてください。

要塞環境の Active Directory

Windows Server Active Directory Domain Services には、ネイティブで高可用性とディザスター リカバリーのサポートが含まれています。

準備

特権アクセス管理の典型的な運用環境では、要塞環境に少なくとも 2 台のドメイン コントローラーが含まれています。 要塞環境での最初のドメイン コントローラーを設定するための手順は、展開の記事の手順 2「PRIV ドメイン コントローラーを準備する」に記載されています。

追加のドメイン コントローラーを追加する手順は、「Windows Server 2012 のレプリカ ドメイン コントローラーを既存のドメインにインストールする (レベル 200)」をご参照ください。

注意

ドメイン コントローラーが Hyper-V などの仮想化プラットフォーム上でホストされる場合は、「仮想化ドメイン コントローラーの展開と構成」の注意事項をご確認ください。

復元

停止後、他のサーバーを再起動する前に、少なくとも 1 台のドメイン コントローラーが要塞環境で使用できるようにしておきます。

操作マスターのしくみ」で説明しているように、Active Directory はドメイン内で、フレキシブル シングル マスター操作 (FSMO) のロールをドメイン コントローラー全体に分散します。 ドメイン コントローラーに障害が発生した場合、そのドメイン コントローラーに割り当てられていた 1 つまたは複数のドメイン コントローラーのロールを転送することが必要な場合があります。

ドメイン コントローラーが運用環境に戻らないと判断した後、すべてのロールがそのドメイン コントローラーに割り当てられていたかどうかを必ず確認し、必要に応じてそれらを再割り当てしてください。 手順については、「現在の操作マスターのロール所有者を表示する」とその関連記事をご参照ください。

また、要塞環境に参加しているコンピューターの DNS 設定、およびそのドメイン コントローラーと信頼関係のある CORP ドメイン内のドメイン コントローラーを確認して、そのドメイン コントローラー コンピューターの IP アドレスに依存してハード コーディングされていないことを確認することもお勧めします。

SQL Server データベース記憶域

高可用性の展開では SQL Server フェールオーバー クラスターが必要であり、SQL Server フェールオーバー クラスター インスタンスはデータベースとログの記憶のために、すべてのノード間の共有記憶域に依存しています。 共有記憶域は、Windows Server フェールオーバー クラスタリングのクラスター ディスク、記憶域ネットワーク (SAN) 上のディスク、または SMB サーバー上のファイル共有の形式にすることができます。 なお、これらは要塞環境専用にしてください。要塞環境の保全性が脅かされる可能性があるため、要塞環境以外の他のワークロードと記憶域を共有することは推奨されません。

SQL Server

MIM サービスには、要塞環境での SQL Server の展開が必要です。 高可用性のために、フェールオーバー クラスター インスタンス (FCI) を使用して SQL を展開できます。 スタンドアロン インスタンスでの場合と異なり、FCI では、SQL Server の高可用性は FCI 内に冗長ノードがあることによって保護されます。 障害が発生した場合や予定されていたアップグレードを行う場合は、リソース グループの所有権は別の Windows Server フェールオーバー クラスター ノードに移動します。

高可用性ではなくディザスター リカバリーのサポートのみが必要な場合は、フェールオーバー クラスタリングの代わりに、ログ配布、トランザクション レプリケーション、スナップショット レプリケーション、またはデータベース ミラーリングを使用できます。

準備

要塞環境に SQL Server をインストールするときは、CORP フォレストにあるすべての既存の SQL Server から独立している必要があります。 さらに、SQL Server は、ドメイン コントローラーのサーバーとは異なる、専用サーバーに展開することをお勧めします。 詳細については、SQL Server ガイドの「AlwaysOn フェールオーバー クラスター インスタンス」をご参照ください。

復元

SQL Server がログ配布を使用してディザスター リカバリー用に構成されていた場合は、復旧中に SQL Server を更新するアクションを実行する必要があります。 さらに、各 MIM サービス インスタンスを再起動する必要があります。

SQL Server が失敗したか、または SQL Server と MIM サービス間の接続が失われた場合は、SQL Server を復元した後、各 MIM サービスを再起動することをお勧めします。 これにより、MIM サービスが SQL Server への接続を確実に再確立します。

MIM サービス

アクティブ化要求の処理には、MIM サービスが必要です。 アクティブ化要求の受信中に、MIM サービスをホストしているコンピューターをメンテナンスのために休止させるために、複数の MIM サービス コンピューターを展開できます。 ユーザーがグループに追加されると、MIM サービスは Kerberos 操作に含まれなくなるのでご注意ください。

準備

MIM サービスは PRIV ドメインに参加している複数のサーバー上に展開することをお勧めします。 高可用性については、Windows Server のドキュメントで「フェールオーバー クラスタリングのハードウェア要件と記憶域オプション」および「Windows Server 2012 フェールオーバー クラスターの作成」をご参照ください。

複数のサーバーにまたがって運用環境を展開する場合は、ネットワーク負荷分散 (NLB) を使用して処理負荷を分散することができます。 1 つの共通名がユーザーに公開されるように、単一のエイリアス (たとえば、A または CNAME レコード) も必要です。

重要

Windows Server 2012 R2 で NLB 機能以外の負荷分散テクノロジを使用する場合は、ソリューションが 1 つのセッションをランダム サーバーではなく、同じサーバーにリダイレクトすることを確認してください。

マルチ サーバーの MIM 展開では、各 MIM サービスに外部ホスト名、サービス名、サービス パーティション名があります。 サービス名の既定値はコンピューターの名前であり、外部ホスト名とサービス パーティション名の既定値は、MIM サービスのインストール中に MIM サービス サーバーのアドレスの入力を求める画面上で構成されます。 これら 3 つの名前は、resourceManagementService 構成ノードの属性 externalHostNameserviceName、および servicePartitionName として %ProgramFiles%\Microsoft Forefront Identity Manager\Service\Microsoft.ResourceManagementService.exe.config ファイルに保存されます。

MIM サービスが要求を受信すると、サービス パーティション名はその要求の属性として保存されます。 その後は、同じサービス パーティション名を持つ他の MIM サービス インストールのみが、その要求と対話することを許可されます。 このため、PAM シナリオに手動の承認または長く続く他の要求処理が含まれている場合は、各 MIM サービスにその構成ファイル内の同じ servicePartitionName 属性があることを確認してください。

復元

停止後、MIM サービスを再起動する前に、少なくとも 1 つの Active Directory ドメイン コントローラーと SQL Server が要塞環境で使用できるようにしておきます。

ワークフロー インスタンスは、ワークフロー インスタンスを開始した MIM サービス サーバーと同じサービス パーティション名とサービス名を持つ MIM サービス サーバーでのみ完了できます。 要求を処理中の MIM サービスをホストしているときに、特定のコンピューターが失敗し、そのコンピューターがサービスに戻れない場合は、MIM サービスを新しいコンピューターにインストールする必要があります。 インストール後に新しい MIM サービスで、resourcemanagementservice.exe.configファイルを編集し、新しい MIM 展開の 属性と 属性を、失敗したコンピューターのホスト名とサービス パーティション名と同じに設定します。 servicePartitionName

MIM PAM コンポーネント

MIM サービスおよびポータルのインストーラーには、PowerShell モジュールと 2 つのサービスを含む、追加の PAM コンポーネントも組み込まれています。

準備

Privileged Access Management コンポーネントは、MIM サービスがインストールされている要塞環境内の各コンピューターにインストールする必要があります。 これらは、後で追加することはできません。

復元

停止から復旧した後、MIM サービスが少なくとも 1 つのサーバー上で実行されていることを確認します。 次に net start "PAM Monitoring service" を使用して、MIM PAM 監視サービスもそのサーバーで実行されていることを確認してします。

要塞環境フォレストの機能レベルが Windows Server 2012 R2 の場合は、コマンド net start "PAM Component service" を使用して、MIM PAM コンポーネント サービスもそのサーバーで実行されていることを確認します。