セキュリティに関する注意事項
適用対象: System Center 2012 R2 Operations Manager,Data Protection Manager for System Center 2012,System Center 2012 - Operations Manager,System Center 2012 SP1 - Operations Manager
System Center 2012 – Operations Manager をインストールする前の準備作業のほとんどは、セキュリティに関連する作業です。 ここでは、これらの作業を大まかに説明します。 詳細については、「Index to Security-related Information for Operations Manager (Operations Manager のセキュリティ関連情報の索引)」を参照してください。
セキュリティ関連タスクを準備する際は次のようなものが関わってきます。
信頼境界を超えた監視を理解、計画、準備。
UNIX または Linux コンピューターの監視を理解、計画、準備。
必要となるサービス アカウント、ユーザー アカウント、セキュリティ グループを計画、準備。
ユーザー設計上の必要に応じてネットワーク ポートを理解、準備。
信頼境界
Active Directory ドメインは、Operations Manager から見た場合に Kerberos 信頼境界の基本単位になります。 この境界は同じ名前空間 (同じ Active Directory ツリー) の他のドメインまで自動的に拡張されたり、Active Directory ツリーが異なっても、推移的な信頼関係を通じて Active Directory フォレストが同じになっているドメイン間で自動的に拡張されたりします。 信頼境界はフォレスト間の信頼関係を利用することで、さらに Active Directory フォレストが異なるドメイン間で拡張することができます。
Kerberos
Kerberos 認証プロトコルは Windows 2000 ドメイン コントローラー以上でサポートされていて、信頼境界内でのみ生じます。 Kerberos 認証は、Operations Manager エージェント/サーバーの相互認証を行うための認証方式です。 エージェントとサーバー間の通信で行われるエージェント/サーバーの相互認証は、すべて Operations Manager シェル で管理されます。
Operations Manager の管理グループは、所属先の Kerberos 信頼境界の外側で検出と監視を実行することができます。 ただし、Active Directory ドメインに属していない Windows ベース コンピューターの場合は、既定の認証プロトコルが NTLM となっているため、相互認証をサポートするためには別のメカニズムを使用する必要があります。 これは、エージェントとサーバー間の証明書交換を通じて行われます。
証明書
監視対象サーバーが、監視を行っている管理グループ以外の信頼されていない Active Directory ドメインに存在する場合など、Operations Manager が信頼境界外で通信を行う必要がある場合は、相互認証に証明書を使用することもできます。 取得した証明書を手動で構成して、コンピューターやそのコンピューターで実行している Operations Manager サービスに関連付けることができます。 別のコンピューター上のサービスと通信する必要があるサービスが開始し、認証を行おうとすると、証明書が交換され、相互認証が完了します。
.jpeg "System_CAPS_important") 重要 |
|---|
この目的に使用される証明書は、同じルート証明機関 (CA) と絶対的な信頼関係にある必要があります。 |
相互認証用の証明書の取得方法と使用方法については、「ゲートウェイ サーバーの展開」を参照してください。
証明機関
必要な証明書を取得するには、証明機関 (CA) へのアクセス許可が必要になります。 これは Microsoft 証明書サービスか、VeriSign などのサードパーティ証明書サービスのどちらかになります。
Microsoft 証明書サービス
Microsoft CA には次の 4 つのタイプがあります。
エンタープライズ ルート
エンタープライズ 下位
スタンドアロン ルート
スタンドアロン 下位
エンタープライズ タイプの CA にはどちらも、Active Directory ドメイン サービスが必要になりますが、スタンドアロン CA には必要ありません。 どちらのタイプの CA も、信頼境界を越えたエージェント/サーバー相互認証に必要な証明書を発行することができます。
通常、CA インフラストラクチャは独自の証明書に署名して自己証明を行うルート CA と、ルートから証明を受ける 1 つ以上の下位 CAで構成されています。 サービス証明書が要求するのは下位 CA サーバーで、ルートは保管用にオフラインになり保留状態になります。 証明書の設計方法については、「Infrastructure Planning and Design (インフラストラクチャの計画と設計)」と「Windows コンピューターの認証とデータ暗号化」を参照してください。
UNIX および Linux コンピューターを監視する
System Center 2012 – Operations Manager では、UNIX コンピューターや Linux コンピューターを監視できます。 UNIX および Linux コンピューターは管理グループが所属する Active Directory ドメインに参加していないため、上記のとおり、さまざまな相互認証の証明方法が使われています。
UNIX および Linux コンピューターと相互認証を確立する
UNIX および Linux コンピューターを検索して、管理オブジェクトとして管理グループに追加するには、検出ウィザードを使用します。Operations Manager は検出ウィザードのプロセス中に、管理サーバーとの相互認証に使用する自己署名した証明書を、検出したUNIX コンピューターや Linux コンピューターに作成させます。 SSH 検出が有効になっている場合は、このような証明書の作成、署名、交換のプロセスが行われます。
管理サーバーでの検出ウィザード プロセスが、検出したUNIX または Linux コンピューターに、自己署名した証明書を作成させます。
検出を行う管理サーバーが UNIX または Linux コンピューターに対して証明書取得要求を出します。
UNIX または Linux コンピューターが管理サーバーに証明書を返します。
検出を行う管理サーバーがキーのペアと自己署名した独自の証明書を作成します。 管理サーバーは、最初に UNIX または Linux コンピューターを検出したときにのみ、キーのペアと自己署名証明書を生成します。 それから管理サーバーは独自の証明書を信頼された証明書ストアにインポートします。 その後、検出を行う管理サーバーが秘密キーで UNIX または Linux 証明書に署名します。 それ以降の UNIX または Linux コンピューター証明書の署名では、最初の署名時に生成された管理サーバーの秘密キーが再利用されます。
その後、検出を行う管理サーバーは、署名した証明書を証明書の生成元である UNIX または Linux コンピューターに戻すための、証明書保存要求を出します。 すると UNIX または Linux コンピューターでは、WSMAN 通信層が再開され、UNIX または Linux コンピューターの新しく生成された証明書がアクティブになります。
これで、管理サーバーが UNIX または Linux コンピューターに対して自己認証を要求すると、UNIX または Linux コンピューターが管理サーバーに信頼された証明書を提示し、管理サーバーが提示された証明書の署名を読み取り、この署名が信頼できることを確認し (この署名は、独自の信頼された証明書ストアに保管されている、独自の秘密キーであるため)、UNIX または Linux コンピューターの身元が確認されたという証拠としてこの証明書を受け入れるようになります。
検出を行う管理サーバーが、適切な実行プロファイルで構成された UNIX または Linux 資格情報を使用して、UNIX または Linux コンピューターとの認証を行います。 詳細については、「UNIX または Linux 実行プロファイルを計画する」セクションを参照してください。
| 重要 |
|---|
上記の操作順序は、低セキュリティ バージョンの UNIX または Linux 検出用です。 |
UNIX または Linux 実行プロファイルを計画する
UNIX または Linux コンピューターが検出を行う管理サーバーで管理されている状態になったら、管理パックの検出とワークフローの実行が開始されます。 これらのワークフローが完了するには、資格情報を使用する必要があります。 これらの資格情報、その適用先となるオブジェクト、クラスまたはグループ、その分散先となるコンピューターは、実行プロファイルに含まれています。 UNIX 管理パックを管理グループにインポートするときに、次の 2 つの実行プロファイルがインポートされます。
UNIX アクション アカウント プロファイル - この実行プロファイルとそれに関連付けられている UNIX または Linux 資格情報は、指定した UNIX または Linux コンピューター上での低レベルのセキュリティ活動に使用されます。
UNIX 特権を持つアカウント プロファイル - この実行プロファイルとそれに関連付けられている UNIX または Linux 資格情報は、より高レベルのセキュリティで保護された活動に使用されます。そのため、UNIX または Linux コンピューターでより高い特権を持つアカウントが必要になります。 ルート アカウントがこれに当たりますが、ルート アカウントでなければならないことはありません。
これらのプロファイルが正しく機能するには、適切な UNIX または Linux コンピューター資格情報を使用して、プロファイルを使用する管理パックのワークフロー用に構成する必要があります。
アカウントとグループ
Operations Manager の展開プロセスでは、多数のアカウントとセキュリティ グループが必要になる場合があります。Operations Manager のセットアップ中に必要となるのは 4 つのみです。 ロール ベースのセキュリティ割り当て、通知、プロセス実行用の別の資格情報を考え出す上で、追加アカウントについて検討する必要があります。 ロールに基づいてセキュリティを割り当てる場合の計画方法については、「System Center 2012 - Operations Manager の展開計画」を参照してください。
ロール ベースのセキュリティ アカウントとセキュリティ グループ
Operations Manager では、ロールにユーザー アカウントを割り当てることで、監視対象のグループ、タスク、ビュー、管理機能へのアクセス許可を管理します。Operations Manager でのロールは、プロファイルの種類 (オペレーター、高度なオペレーター、管理者) とスコープ (ロールがアクセス許可を持つデータ) の組み合わせとなります。 通常、Active Directory セキュリティ グループがロールに割り当てられてから、個々のアカウントがそれらのグループに割り当てられます。 これらのロールやカスタム作成のロールに追加することができる Active Directory セキュリティ グループを展開する前に計画し、その後に個々のユーザー アカウントをセキュリティ グループに追加できるようにします。
Operations Manager には、既定で次のロールが定義されています。
ロール名 |
プロファイルの種類 |
プロファイルの説明 |
ロールのスコープ |
|---|---|---|---|
Operations Manager 管理者:セットアップで作成され、削除できず、1 つ以上のグローバル グループを含んでいる必要がある。 |
管理者 |
Operations Manager でのすべての特権を持つ。管理者プロファイルのスコープは定義できない。 |
Operations Manager のすべてのデータ、サービス、管理、作成ツールへのフル アクセス権を持つ。 |
Operations Manager 高度なオペレーター:セットアップで作成され、スコープがグローバルに定義され、削除できない。 |
高度なオペレーター |
Operations Manager の一部の構成の変更許可を持つ。ルールの上書きを作成でき、構成されたスコープ内でターゲットやターゲットのグループを監視する。 |
既存または今後インポートされるグループ、表示、タスクすべてへのアクセス |
Operations Manager 作成者:セットアップで作成され、スコープがグローバルに定義され、削除できない。 |
作成者 |
構成されたスコープ内でタスク、ルール、モニター、ビューを作成、編集、削除することができる |
既存または今後インポートされるグループ、表示、タスクすべてへのアクセス |
Operations Manager オペレーター:セットアップで作成され、スコープがグローバルに定義され、削除できない。 |
演算子 |
構成されたスコープに応じて、アラートとの対話、タスクの実行、および表示へのアクセスを行うことができる |
既存または今後インポートされるグループ、表示、タスクすべてへのアクセス |
Operations Manager 読み取り専用オペレーター:セットアップで作成され、スコープがグローバルに定義され、削除できない。 |
読み取り専用オペレーター |
構成されたスコープに応じて、アラートの表示や表示へのアクセスを行うことができる |
既存または今後インポートされるグループ、表示すべてへのアクセス |
Operations Manager レポートのオペレーター:セットアップで作成され、スコープがグローバルに定義されている |
レポート オペレーター |
構成されたスコープに応じて、レポートの表示を行うことができる |
スコープがグローバルに定義されている |
Operations Manager レポートのセキュリティ管理者:SQL Server Reporting Services セキュリティと Operations Manager ユーザー ロール を統合したもの。Operations Manager 管理者に、レポートへのアクセスを制御する権限を付与できる。スコープの定義はできない。 |
レポート セキュリティ管理者 |
SQL Server Reporting Services セキュリティと Operations Manager ロールを統合できる。 |
スコープはない |
これらの定義済みロールのいずれかに、Active Directory セキュリティ グループまたは個々のアカウントを追加することができます。 追加する場合、これらの個人はスコープ内のオブジェクト全体において、与えられたロール特権を行使することができます。
[!メモ]
定義済みのロールはスコープがグローバルに定義されており、すべてのグループ、ビュー、タスクへのアクセス許可が付与されます (レポート セキュリティ管理者を除く)。
また、Operations Manager では、オペレーター、読み取り専用オペレーター、作成者、高度なオペレーターの各プロファイルに基づいてカスタムのロールを作成できます。 ロールを作成する時に、ロールからアクセスできるグループ、タスク、および表示のスコープをさらに絞ることができます。 たとえば、"Exchange オペレーター" というロールを作成し、スコープを Exchange 関連のグループ、ビュー、タスクに絞ることができます。 このロールに割り当てられたユーザー アカウントでは、Exchange 関連のオブジェクトでオペレーター レベルの操作を行うことができます。
通知アカウントとグループ
Exchange オペレーター ロールに割り当てられている Exchange 管理者など、Operations Manager を定期的に使用する社員は、新しいアラートを監視する必要があります。 そのためには、オペレーション コンソールで新しいアラートを監視するか、Operations Manager でサポートされている通信チャネルを介してアラートが生成されるように設定します。Operations Manager は、電子メール、インスタント メッセージ、ショート メッセージ サービス、ポケットベルによる通知をサポートします。 ロールに知らせる必要がある情報は、Operations Manager で指定した受信者に通知されます。Operations Manager での受信者は、電子メール通知用の SMTP アドレスなど、通知を受け取るための有効なアドレスを持つオブジェクトにすぎません。
このため、ロールの割り当てと共に、電子メール対応セキュリティ グループを通じた通知グループ メンバーシップを併用することが賢明です。 たとえば、Exchange 管理者セキュリティ グループを作成し、Exchange で修正を行う知識と権限を持つユーザーをグループに設定します。 このセキュリティ グループをカスタム作成の Exchange 管理者ロールに割り当てて、データへのアクセス許可を持ち、電子メールで対応されるようにします。 次に、電子メール対応セキュリティ グループの SMTP アドレスを使用して、受信者を作成します。
サービス アカウント
展開時には次のサービス アカウントが整っている必要があります。 ドメイン アカウントを使用しており、ドメインのグループ ポリシー オブジェクト (GPO) に既定のパスワード有効期限ポリシーが必要に応じて設定されている場合、スケジュールに応じてサービス アカウントのパスワードを変更するか、低メンテナンスのシステム アカウントを使用するか、またはパスワードの期限が切れないようアカウントを構成する必要があります。
アカウント名 |
要求される時 |
使用目的 |
低メンテナンス |
高セキュリティ |
|---|---|---|---|---|
管理サーバー アクション アカウント |
管理サーバー セットアップ |
プロバイダーからのデータ収集、応答の実行 |
ローカル システム |
低特権ドメイン アカウント |
データ アクセス サービスおよび構成サービスのアカウント |
管理サーバー セットアップ |
オペレーション データベースへの書き込み、サービスの実行 |
ローカル システム |
低特権ドメイン アカウント |
ターゲット デバイスのローカル管理者アカウント |
検出とエージェントのプッシュ インストール |
エージェントのインストール |
ドメイン アカウントまたはローカル管理者アカウント |
ドメイン アカウントまたはローカル管理者アカウント |
エージェント アクション アカウント |
検出とエージェントのプッシュ インストール |
管理されたコンピューターでの情報の収集と応答の実行 |
ローカル システム |
低特権ドメイン アカウント |
データ ウェアハウス書き込みアクション アカウント |
レポート サーバーのセットアップ |
レポート データ ウェアハウスへの書き込み |
低特権ドメイン アカウント |
低特権ドメイン アカウント |
データ リーダー アカウント |
レポート サーバーのセットアップ |
SQL Reporting Services データベースの照会 |
低特権ドメイン アカウント |
低特権ドメイン アカウント |
サービス プリンシパル名
Operations Manager を展開するときに、構成によっては、サービス プリンシパル名 (SPN) の登録が必要になる場合があります。 SPN は、クライアントがサーバーと相互に認証するための Kerberos 認証で使用されます。 詳細については、「What Are Service Publication and Service Principal Names? (サービス パブリケーションとサービス プリンシパル名とは?)」を参照してください。
Operations Manager をインストールするときは、[System Center 構成サービスと System Center データ アクセス サービス] のアカウントを選択します。 詳細については、「System Center 2012 - Operations Manager の展開」をご覧ください。
.jpeg "System_CAPS_caution") 注意 |
|---|
既定の Active Directory のアクセス許可を変更して、独自の SPN を制限なしで変更できるようにアカウントを設定しないでください。 |
ローカル システムを System Center データ アクセス サービスのアカウントとして選択する場合は、そのアカウントで適切な SPN を作成できます。 これ以上の構成は必要ありません。
ドメイン アカウントを使用する場合は、各管理サーバーの SPN を登録する必要があります。 これには、SETSPN コマンド ライン ツールを使用します。 このツールの実行方法については、「Setspn Overview (Setspn の概要)」を参照してください。
管理サーバーの NetBIOS 名と完全修飾ドメイン名の両方を登録するには、次の構文を使用します。
setspn –a MSOMSdkSvc/<netbios name> <DAS account domain>\<DAS account name>
setspn –a MSOMSdkSvc/<fqdn> <DAS account domain>\<DAS account name>
.jpeg "System_CAPS_tip") ヒント |
|---|
次の構文を使用すると、ユーザー アカウントまたはコンピューターの登録済み SPN を一覧表示できます。 setspn –l <DAS account name> setspn –l <fqdn> |
ネットワーク負荷分散またはハードウェア ロード バランサーを使用している場合は、System Center データ アクセス サービスをドメイン アカウントで実行する必要があります。 前述のセットアップに加え、ロード バランサー名も登録する必要があります。そのためには、次の構文を使用します。
setspn –a MSOMSdkSvc/<load balanced name> <DAS account domain>\<DAS account name>
[!メモ]
このロード バランサーの内側で実行している System Center データ アクセス サービスはすべて、同じドメイン アカウントで実行する必要があります。
実行アカウント
監視するコンピューターのエージェントは、タスク、モジュール、およびモニターを定義済みの条件に合わせて実行するだけでなく、オンデマンドでも行うことができます。 既定では、エージェント アクションのアカウント資格情報を使用してすべてのタスクを実行します。 エージェント アクション アカウントには、コンピューターで特定のアクションを実行する権限や特権がない場合があります。Operations Manager では、実行アカウントと呼ばれる別の資格情報セットに基づいて、エージェントのタスクを実行することができます。 実行アカウントは受信者同様、Operations Manager で作成されるオブジェクトで、Active Directory ユーザー アカウントにマッピングされます。 その時に使用する実行プロファイルは、実行アカウントを指定のコンピューターにマッピングします。 管理パックの開発時に、実行プロファイルに関連付けられたルール、タスクまたはモニターをターゲット コンピューターで実行する必要がある場合は、指定された実行アカウントを使用して実行します。
Operations Manager には既定の実行アカウントと実行プロファイルが多数組み込まれていますが、必要に応じて独自のアカウントやプロファイルを作成して追加できます。 また、実行アカウントに関連付けられた Active Directory 資格情報を変更することもできます。 これには、追加の Active Directory 資格情報を計画、作成、維持する必要があります。 パスワードの期限、Active Directory ドメイン サービス、場所、およびセキュリティに関しては、これらのアカウントをサービス アカウントとして扱う必要があります。
実行アカウントに対する要求を作成するのは管理パックの作成者であることから、この作成者と協力する必要があります。 詳細については、「Index to Security-related Information for Operations Manager (Operations Manager のセキュリティ関連情報の索引)」を参照してください。