Operations Manager での認証とデータ暗号化

System Center Operations Manager は、管理サーバー、ゲートウェイ サーバー、レポート サーバー、オペレーション データベース、レポート データ ウェアハウス、エージェント、Web コンソール、オペレーション コンソールなどの機能で構成されます。 この記事では、認証の実行方法について説明し、データが暗号化される接続チャネルを識別します。

証明書ベースの認証

Operations Manager エージェントと管理サーバーが信頼されていないフォレストまたはワークグループの境界で分離されている場合は、証明書ベースの認証を実装する必要があります。 次のセクションでは、こうした状況と Windows ベースの証明機関から証明書を取得しインストールするための特定の手順について説明します。

同一の信頼境界内におけるエージェントと管理サーバー間の通信の設定

管理サーバーがエージェントからデータを受け入れる前に、エージェントと管理サーバーは Windows 認証を使用して相互認証を行います。 Kerberos バージョン 5 プロトコルが認証提供の既定の方法です。 Kerberos ベースの相互認証を機能させるためには、エージェントと管理サーバーが Active Directory ドメインにインストールされている必要があります。 エージェントと管理サーバーが別々のドメインにある場合は、それらのドメインの間に完全な信頼が存在する必要があります。 このシナリオでは、相互認証が行われてから、エージェントと管理サーバー間のデータ チャネルが暗号化されます。 認証と暗号化実行のためにユーザー操作は必要ありません。

信頼境界を超えるエージェントと管理サーバー間の通信の設定

エージェント (単数または複数) が管理サーバー (ドメイン A) とは別のドメイン (ドメイン B) に展開され、ドメイン間に双方向の信頼関係がない場合があります。 2 つのドメイン間に信頼がないため、1 つのドメイン内のエージェントは、Kerberos プロトコルを使用して他のドメインの管理サーバーで認証できません。 各ドメイン内の Operations Manager 機能間の相互認証は引き続き行われます。

この状況を解決するには、エージェントが存在するドメインにゲートウェイ サーバーをインストールしてから、ゲートウェイ サーバーと管理サーバーに証明書をインストールして、相互認証とデータ暗号化を実現します。 ゲートウェイ サーバーを使用すると、次の図で示されるように、ドメイン B で証明書が 1 つ、ファイアウォール間でポートが 1 つのみ必要になります。

ドメイン間の通信の設定 - ワークグループの境界

環境によっては、ファイアウォールの中でワークグループに対して 1 つまたは 2 つのエージェントが展開されている場合があります。 ワークグループ内のエージェントは、Kerberos プロトコルを使用してドメイン内の管理サーバーで認証できません。 この状況は、次の図が示すように、エージェントをホストするコンピューターとエージェントが接続している管理サーバーの両方に証明書をインストールすることによって解決できます。

エージェントをホストするコンピューター、および同一の証明機関を使用する管理サーバーの両方で次の手順を実行します。

1. CA に証明書を要求します。
2. CA で証明書の要求を承認します。
3. コンピューターの証明書ストアで承認済みの証明書をインストールします。
4. MOMCertImport ツールを使用して Operations Manager を構成します。

ゲートウェイ承認ツールをインストールまたは実行しない場合を除き、これらはゲートウェイ サーバーに証明書をインストールする場合と同じ手順です

証明書のインストールの確認

証明書が正しくインストールされている場合は、Operations Manager イベント ログに次のイベントが書き込まれます。

証明書の設定中は、MOMCertImport ツールを実行します。 MOMCertImport ツールが終了すると、インポートした証明書のシリアル番号が次のサブキーにあるレジストリに書き込まれます。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Machine Settings

管理サーバー、ゲートウェイ サーバー、エージェント間の認証とデータ暗号化

これらの Operations Manager 機能間の通信は、相互認証から始まります。 両方の通信チャネルに証明書が存在する場合は、相互認証にそれらの証明書が使用されます。それ以外の場合は、Kerberos version 5 プロトコルが使用されます。 2 つのコンポーネントが信頼されていないドメイン内で分離されている場合は、証明書を使用して相互認証を実行する必要があります。 イベント、アラート、管理パックの展開などの通常の通信は、このチャネルを経由して発生します。 前述の図は、管理サーバーにルーティングされたエージェントのうちの 1 つで生成されるアラートの例です。 これはゲートウェイ サーバーとエージェントが同一のドメインにあるため、エージェントからゲートウェイ サーバーまでデータの暗号化には Kerberos セキュリティ パッケージが使用されます。 アラートはゲートウェイ サーバーによって解読され、管理サーバーの証明書を使用して再暗号化されます。 ゲートウェイ サーバーによって、暗号化されたメッセージが管理サーバーに送信され、管理サーバーがアラートを暗号化解除します。 管理サーバーとエージェントの間の通信には、構成データやタスクなどの資格情報が含まれている場合があります。 エージェントと管理サーバーの間のデータ チャネルは、通常のチャネルの暗号化に加えて、さらに別の暗号化の層を追加します。 ユーザー操作は必要ありません。

管理サーバーとオペレーション コンソール、Web コンソール サーバー、およびレポート サーバー

管理サーバーとオペレーション コンソール、Web コンソール サーバー、またはレポート サーバーの間の認証とデータ暗号化は、Windows Communication Foundation (WCF) テクノロジを使用して実現されます。 認証における最初の試行は、ユーザーの資格情報を用いて行われます。 Kerberos プロトコルが最初に試行されます。 Kerberos プロトコルが機能しない場合は、NTLM を使用して別の試行が行われます。 それでも認証が失敗する場合は、ユーザーは資格情報の提供を求められます。 認証が行われた後、データ ストリームは Kerberos プロトコルまたは NTLM を使用する場合は SSL のいずれかの関数として暗号化されます。

レポート サーバーと管理サーバーの場合、認証が行われた後、管理サーバーと SQL Server Reporting Server の間にデータ接続が確立されます。 この接続には Kerberos プロトコルのみが使用されるため、管理サーバーとレポート サーバーは信頼されているドメイン内になければなりません。 WCF の詳細については、MSDN の記事の「 Windows Communication Foundation とは」を参照してください。

管理サーバーとレポート データ ウェアハウス

管理サーバーとレポート データ ウェアハウス間には、2 つの通信チャネルが存在します。

• 管理サーバーのヘルス サービス (System Center 管理サービス) によって生成されるホスト監視プロセス
• 管理サーバーの System Center データ アクセス サービス

監視ホスト プロセスとレポート データ ウェアハウス

既定では、データ ウェアハウスに収集されたイベントおよびパフォーマンス カウンターの書き込みを行うヘルス サービスによって生成される監視ホスト プロセスは、レポート セットアップ時に指定したデータ ライター アカウントとして実行することで Windows 統合認証を行います。 アカウントの資格情報は、データ ウェアハウス アクション アカウントと呼ばれる実行アカウント内に安全に格納されています。 この実行アカウントは、(実際の収集ルールに関連付けられている) データ ウェアハウス アカウントと呼ばれる実行プロファイルのメンバーの 1 つです。

レポート データ ウェアハウスと管理サーバーが信頼境界で区切られている場合 (たとえば、それぞれが信頼されていない異なるドメインに存在する場合)、Windows 統合認証は機能しません。 この状況に対応するには、SQL サーバー認証を使用して監視ホスト プロセスをレポート データ ウェアハウスに接続することができます。 これは、SQL アカウントの資格情報使用して実行アカウント (簡易アカウントの種類) を作成し、管理サーバーをターゲット コンピューターとするこのアカウントをデータ ウェアハウス SQL サーバー認証アカウントと呼ばれる実行プロファイルのメンバーにすることで実行できます。

次に、Windows 統合認証と SQL サーバー認証両方におけるさまざまなアカウント資格情報、実行アカウント、および実行プロファイルの関係の概要を示します。

既定:Windows 統合認証

1. 実行プロファイル:データ ウェアハウス アカウント

   • 実行アカウント: Data Warehouse アクション
   • アカウント資格情報: Data Writer アカウント (セットアップ時に指定)

2. 実行プロファイル:データ ウェアハウス SQL サーバー認証アカウント

   • 実行アカウント: Data Warehouse SQL Server 認証
   • アカウント資格情報: Operations Manager によって作成された特別なアカウント (変更しない)

オプション: SQL サーバー認証

1. 実行プロファイル: Data Warehouse SQL Server 認証アカウント
   • 実行アカウント: セットアップ時に指定した実行アカウント。
   • アカウント資格情報: セットアップ時に指定したアカウント。

System Center Data Access サービスとレポート データ ウェアハウス

既定では、レポート データ ウェアハウスからデータを読み取り、レポート パラメーター領域で使用できるようにする System Center Data Access サービスは、Operations Manager のセットアップ時に定義されたデータ アクセス サービスおよび構成サービス アカウントとして実行することで、Windows 統合認証を実現します。

レポート データ ウェアハウスと管理サーバーが信頼境界で区切られている場合 (たとえば、それぞれが信頼されていない異なるドメインに存在する場合)、Windows 統合認証は機能しません。 この問題に対処するには、SQL Server 認証を使用して System Center データ アクセス サービスをレポート データ ウェアハウスに接続します。 これは、SQL アカウントの資格情報を使って実行アカウント (簡易アカウントの種類) を作成し、管理サーバーをターゲット コンピューターとして使用しながら、そのアカウントをレポート SDK SQL サーバー認証アカウントと呼ばれる実行プロファイルのメンバーにすることで実行できます。

次に、Windows 統合認証と SQL サーバー認証両方におけるさまざまなアカウント資格情報、実行アカウント、および実行プロファイルの関係の概要を示します。

既定:Windows 統合認証

1. データベース アクセス サービスおよび Config サービス アカウント (Operations Manager のセットアップ時に定義)

   • 実行プロファイル:SDK SQL サーバー認証レポート アカウント
   • 実行アカウント:SDK SQL サーバー認証レポート アカウント
   • アカウント資格情報: Operations Manager によって作成された特別なアカウント (変更しない)

2. オプション: SQL サーバー認証

   • 実行プロファイル:データ ウェアハウス SQL サーバー認証アカウント
   • 実行アカウント: セットアップ時に指定した実行アカウント。
   • アカウント資格情報: セットアップ時に指定したアカウント。

オペレーション コンソールとレポート サーバー

オペレーション コンソールは、HTTP を使用してポート 80 のレポート サーバーに接続します。 認証は Windows 認証を使用して実行されます。 データは、SSL チャネルを使用して暗号化できます。

レポート サーバーとレポート データ ウェアハウス

レポート サーバーとレポート データ ウェアハウスの間の認証は、Windows 認証を使用して実行されます。 レポートのセットアップ時にデータ リーダー アカウントとして指定されたアカウントが、レポート サーバーの実行アカウントになります。 アカウントのパスワードを変更する必要がある場合は、SQL Server の Reporting Services 構成マネージャーを使用して同じパスワードを変更する必要があります。 レポート サーバーとレポート データ ウェアハウスの間のデータは暗号化されません。