test

Sun Management Center 3.6 インストールと構成ガイド

第 3 章 構成上の考慮事項

この章では、Sun Management Center のインストールまたはアップグレードに悪影響を及ぼす可能性のある事項について説明します。この章では次の項目について説明します。

セキュリティ上の推奨事項

この節では、Sun Management Center のアクセス、サーバーコンポーネント、エージェントコンポーネント、セキュリティキーなどに関連してセキュリティ上の推奨事項について説明します。

ユーザー、グループ、および役割の概要

Sun Management Center のユーザーとユーザーグループを設定する前に、予想される管理作業の種類について理解する必要があります。これは、それらの作業を適切なユーザークラスに割り当てるためです。ユーザーグループと役割を念入りに計画することで、構成を適切に管理するとともに、管理情報やシステムリソースのデータ整合性とセキュリティを実現しやすくなります。

あらかじめマスターアクセスファイル /var/opt/SUNWsymon/cfg/esusers で明示的に識別されていないかぎり、どのユーザーも Sun Management Center にアクセスすることはできません。Sun Management Center に対するアクセス権を付与するには、そのユーザーの UNIX ユーザー名を /var/opt/SUNWsymon/cfg/esusers に追加します。追加されたユーザーは、標準の UNIX ユーザー名とパスワードを使用して Sun Management Center にログインできます。

ユーザーがログインすると、次に示す機能上の役割に応じてSun Management Center がアクセスを制御し、ユーザー権限を決定します。

大規模組織では、Sun Management Center セキュリティの役割が既存のシステム管理機能やサポート機能に直接割り当てられます。中小の組織では、企業職分と製品の役割の区分がさほど明瞭ではないためにプロセスが入り組んだものとなることがあります。場合によっては、1 人のユーザーにすべての論理の役割を割り当てるという方法が認められることもあります。

注 –

権限の指定は柔軟に行え、Sun Management Center の 4 つのセキュリティの役割に限定する必要はありません。

Sun Management Center 権限は、ドメイン、トポロジコンテナ、エージェント、およびモジュールの各レベルで明示的に指定できます。権限指定では、任意の UNIX ユーザーまたは UNIX グループを基準とし、上記のグループを慣例的に使用するだけに留めることができます。つまり、機能の役割を割り当てる際に Sun Management Center 権限グループに対して既存のアカウント構成を使用できます。権限を割り当てる場合に明示的なユーザーを指定することはお勧めできませんが、UNIX グループがすでに確立されている環境では UNIX グループを使用すると便利な場合があります。

セキュリティの役割、グループ、ユーザーの詳細は、「ユーザーの設定」 および『Sun Management Center 3.6 ユーザーガイド』の第 18 章「Sun Management Center のセキュリティ」を参照してください。

Sun Management Center の内部セキュリティ

ここでは、Sun Management Center コンポーネント間で使用されるセキュリティプロセスについて説明します。

サーバーとエージェント間のセキュリティ

Sun Management Center サーバーとその管理対象ノード間の通信は、主に業界標準の SNMP (Simple Network Management Protocol) バージョン 2 を使用し、User Security モデル SNMP v2usec を採用して行われます。SNMPv2 メカニズムは、サーバーレイヤーからエージェント側のオペレーションに対してユーザー証明 (user credential) を割り当てるのに最適です。SNMPv2 は、アクセス制御ポリシーの回避を不可能にするための主要なメカニズムです。

Sun Management Center は、コミュニティベースのセキュリティを使用した SNMP v1 と SNMP v2 もサポートします。セキュリティの観点からはそれほど堅固ではありませんが、ほかのデバイスやほかの管理プラットフォームとの統合のためには SNMP v1 と v2 のサポートが重要な意味を持ちます。これらのメカニズムの使用が望ましくない環境では、アクセス制御指定メカニズムによって SNMP v1/v2 プロトコルを使用したプロセスへのアクセスを制限または 禁止できます。Sun Management Center エージェントはまた、Sun 以外のアプリケーションからの SNMPv3 照会を認識して、応答することもできます。

データストリーミングを要する場合があるカスタマイズされた処理の場合は、プローブメカニズムも採用されます。プローブメカニズムは、SNMP オペレーションによって開始されます。開始されたプローブオペレーションは、ストリーミング TCP 接続を使用して管理対象ノード上で双方向性の対話型サービス (ログファイルの表示など) を実施します。プローブメカニズムは SNMP 通信を行うため、パケットペイロードの暗号化は実施されません。

サーバーコンテキスト間のセキュリティ

Sun Management Center がローカルサーバーコンテキスト外の管理対象ノードと通信を行う場合は、一般的な espublic SNMPv2 usec ユーザーとして処理が実行されるようにセキュリティモデルによって対策が講じられます。espublic を使用すると、権限が大幅に限定され、ユーザーの権限は管理データを読むだけに制限されます。

クライアントとサーバー間のセキュリティ

Sun Management Center サーバーレイヤーとクライアント (コンソールやコマンド行インタフェースなど) 間の通信は、Java 技術の RMI（遠隔メソッド呼び出し）と製品固有の包括的なセキュリティモデルとの組み合わせで行われます。このセキュリティモデルにより低度、中度、または高度のセキュリティモードのいずれかによるクライアント処理が可能となり、実行されるメッセージ認証のレベルが決定されます。これらのレベルを次に示します。

セキュリティレベルが高いとパフォーマンスに影響が出る可能性があるため、メッセージ認証ニーズを慎重に検討することをお勧めします。

モジュールのセキュリティ

Sun Management Center は、サービス管理機能 (SMF)、Module Configuration Propagation (MCP)、および Solaris Container Manager モジュールに対するモジュールレベルのセキュリティを提供します。ユーザーは誰でも、Sun Management Center エージェントで任意のモジュールを読み込むことができます。しかしながら、モジュールでの処理や値の設定や変更を行うには、事前にアクセス権を取得している必要があります。モジュールセキュリティは、RBAC (Role Based Access Control) およびローカルファイルアクセスの 2 通りの方法で提供されます。

RBAC はプロファイルに基づいています。必要なプロファイルを持つユーザーは、そのプロファイル固有の作業を行うことができます。RBAC は、Solaris システムの管理コマンドを使用して実現できます。

ローカルファイルアクセスは、OS からは独立したセキュリティ機能です。ユーザーは、ローカルアクセスファイルに、必要なアクセス権を追加してもらう必要があります。ローカルファイルアクセスによるセキュリティは、es-config コマンドを使用して実現できます。詳細は、「es-config の使用」を参照してください。

セキュリティキーと SNMP コミュニティ文字列

1 台のマシンに Sun Management Center エージェントをインストールして、その設定に進むと、そのエージェントのセキュリティキーを生成するためのパスワードを求めるメッセージが表示されます。このパスワードは、Sun Management Center サーバーの設定で指定したパスワードと同じである必要があります。それぞれのセキュリティキーが異なると、サーバーとエージェントは互いに通信できません。セキュリティキーの再生成方法については、「セキュリティキーの再生成」を参照してください。

設定時には、デフォルトの SNMP コミュニティ文字列 (public) を受け入れるか、あるいは非公開のコミュニティ文字列を指定するように求めるメッセージも表示されます。本来 SNMP コミュニティ文字列は特権化された内部的なアカウントのパスワードとして使用されるものであり、この文字列を一般的な SNMPv2 usec ツールと併用することでサーバーレイヤーを模倣できます。このため、デフォルトのコミュニティ文字列は使用せず、サーバーコンテキストごとに個別の非公開コミュニティ文字列を指定してください。

セキュリティパスワードと SNMP コミュニティ文字列の扱いには、スーパーユーザーパスワードと同様の注意を払ってください。

管理対策

この節では、Sun Management Center の管理手法について概要を述べます。管理対象となるシステムとそれらの実装について理解すれば、Sun Management Center の導入と利用を順調に行えます。

サーバーコンテキスト

管理情報をとりまとめる上での最高レベルの構築ブロックは、サーバーコンテキストです。各 Sun Management Center サーバーは、サーバーコンテキストを 1 つしか提供しません。各サーバーコンテキストは、サーバーコンテキストに対して報告を行う 1 つ以上のシステムを管理します。管理対象となる各システムは、1 つのサーバーコンテキストにのみ報告を行います。

サーバーコンテキスト間の通信は一般に禁止され、サーバー間で管理イベントが転送されることはありません。サーバーコンテキストは、Sun Management Center を採用した組織内のグループ構造に対応して使用する必要があります。また、システム管理に関して、サーバーコンテキストとそれらのグループの責務を対応付ける必要もあります。サーバーを所有する管理グループは、サーバー内に管理データも所有することになります。このグループは、Sun Management Center サーバーによって管理されるすべてのシステムとネットワークリソースに対するあらゆるアクセスを制御します。

ドメインの対策

ドメインはサーバーコンテキストにおける最高レベルの構成要素であり、独自のトポロジ構成を確立できる独立した環境を提供します。ドメインはいたって一般的なものです。管理者は、ユーザー、環境、その他の任意の論理的部署などに固有の情報を提示するためにドメインを作成できます。管理対象となるシステムは 1 つ以上のドメインに出現できるため、重複したドメインが存在してもかまいません。したがって、同一の管理情報とシステムリソースをいくつもの異なる構成で提示できます。

一般にドメインには、一連の管理対象システム、Sun Management Center 管理モジュール、または管理対象オブジェクトの取りまとめに利用できる階層的な Sun Management Center グループがいくつも存在します。この階層は、ユーザーインタフェースにおける情報の視覚的な分類を決定します。この階層は、管理ステータスをまとめる規則や、このステータスをハイレベルサマリー (全体要約) に渡す規則などの定義も行います。ドメイン (およびドメインに含まれるコンテナ) にはこのような機能性と柔軟性があるため、個々の環境の論理的な管理モデルを構築する上で強力なツールとなります。

編成面からの対策

Sun Management Center には、ローカル環境を定期的に自動チェックして管理対象ノードを確認できる強力な Discovery Manager が付属しています。Discovery Manager は、Sun Management Center の構成に役立つだけでなく、ネットワークベースの物理的なラインに沿って管理情報の体系化も行います。

環境の特性によっては、Discovery Manager を使用することが管理情報の表示やステータス情報の収集に最適な方法とは言えない場合もあります。しかし、Sun Management Center 環境の編成に先立って管理対象となるシステムをすべて特定するのには Discovery Manager が非常に役立ちます。Discovery Manager の詳細は、『Sun Management Center 3.6 ユーザーガイド』の第 4 章「検出マネージャによるトポロジデータベースへのオブジェクト追加」を参照してください。

Sun Management Center 環境を編成する方法としては、ほかに次のようなものがあり ます。

各 Sun Management Center 環境では、完全性を重視する必要があります。たとえば、対応範囲は、システム障害を事前に、あるいは少なくともただちに発見できるぐらいの範囲でなければなりません。環境にとってきわめて重要でありながら Sun Management Center による監視が行われていないデバイス、ホスト、サービス、プロセスなどで障害が発生すると、この対応にギャップが生じ、実装の全体的な有効性に影響を与えかねません。このためには、Sun Management Center 管理環境を構築する際に、カスタマイズされたモジュールやプロキシソリューションを考慮するとともに、ほかのサーバーコンテキストからの情報も考慮する必要があります。

物理面からの編成

管理対象となるシステムの物理的な位置が、そのシステムが存在するネットワークに対応していないという場合があります。このような場合には、その Sun Management Center グループを物理的なライン上に構成できる新しいドメインを作成することをお勧めします。都市、サイト、ビル、フロア、サーバールームのほか、機器を設置するラックまでも簡単に表現できます。これらの場所のシステムは、Discovery Manager を使用して検出作業が行われたドメインからコピーしてペーストできます。

物理的なラインに沿って Sun Management Center 環境を構成するには、システムが実際に配置されている場所を知る必要があります。この編成は、簡単に利用できる貴重なリファレンスとなります。物理面からの編成では、ステータスの収集パスも決定されます。このため、障害は物理的なライン上で分離され、共通モード故障 (CMF) の検出が容易に行われます。たとえば、特定の場所で発生した停電は複数のネットワーク上に渡って存在するシステムに影響を与える可能性がありますが、物理的な場所ということでは 1個所にしか現れません。

注意 – 注意 –

情報は管理者自身で最新の状態に保つ必要があります。検出が実施される際にこの情報が自動的に更新されることはありません。検出プロセスは物理的に再配置が行われた資産の自動追跡は行いません。

環境面からの編成

組織によっては、場所とリソースが重複していながら論理的な機能はそれぞれ独立しているという複数の論理環境を抱えている場合もあるでしょう。論理環境には、職務グループ (営業や技術など)、機能グループ (小売や大口など)、論理的なソフトウェア環境 (ユーザー承認や製造など) があります。

この 3 つのケースとも、各グループの要素を分離させる個別の Sun Management Center トポロジを生成することを検討してください。トポロジグループを分離させると、1 つのグループで問題が発生してもほかのグループで警告が出されるということがありません。この分離は、マルチドメインサーバーを抱えるシステムで Sun Management Center 環境を構成する場合にとりわけ重要となります。ドメインが異なると、それぞれまったく異なるグループまたは環境を対象として機能している可能性があります。単一のトポロジグループに複数のドメインを含めると、紛らわしい情報やアラーム通知が生成される可能性があります。

アプリケーション面からの編成

システム管理においてアプリケーションは複雑な存在です。アプリケーションがどのような要素から構成されているかを管理的な視点から確認するのは容易ではありません。特に、適切な稼働を目的としてアプリケーションが分散され、多数の外部サービスに依存している場合はとりわけ困難でしょう。このため、アプリケーションを編成してから Sun Management Center のインストールをする必要があります。問題が実際に発生するまで因果関係の検討を先延ばしにすることがあってはなりません。初期分析を実施することで効率向上の一助となり、アプリケーションレベルの問題の解決策につながります。

アプリケーションを重視した Sun Management Center 環境を構成する場合は、一般にトポロジコンテナにホスト、モジュール、および特定のオブジェクトを混在させます。この場合、一部のホストを完全にそのアプリケーション専用とし、ほかのホストはそのアプリケーションを正常に稼動させるために部分的に使用するだけにとどめるという方法を採ることができます。たとえば、コーポレートディレクトリサービスを使用するアプリケーションの場合、アプリケーションの処理上、そのディレクトリサービスが健全に機能していることが重要視されますが、サーバー上のほかのサービスの健全性はアプリケーションにとって重要ではなく必須要件ではありません。

サービス担当面からの編成

状況によっては、1 つのグループまたは 1 人の管理者が特定のサービスを担当し、使用中のリソースは担当しないという場合があります。たとえば、データベースサービスの可用性とデータの整合性を担当するデータベース管理者の場合、ハードウェアやオペレーティングシステムは担当していないことが考えられます。この場合、データベース管理者はそのデータベースサービス用に作成された Sun Management Center ドメインの支援によって必要な作業を進めることができます。また、一般的なシステムやネットワークステータスのアクセスには、一般ユーザー の役割の権限を使用できます。

大規模エンタープライズの管理

Sun Management Center には、大規模エンタープライズの管理を簡易化する機能がいくつか用意されています。その 1 つ Reference Domains を利用すると、いくつものサーバーコンテキストにわたって複数のグループで管理情報を共有できます。大々的に分散された管理オペレーションの実施に役立つ Grouping Operations システムという機能もあります。

グルーピングシステムは、データプロパティ値の設定やデータプロパティ属性の変更に利用できます。また、Sun Management Center サーバー環境へのモジュールの読み込みおよび読み込み解除、有効化および 無効化なども行えます。これらの処理はすべて、管理対象システムと管理対象ノードから成る大規模のグループに適用できます。これらのグループは、既存のトポロジ構造または柔軟な検出タイプのフィルタを使用して定義できます。グループ化の作業は保存と実行を何度も繰り返すことができ、スケジューラを使用して自動化することも可能です。グループ化の作業には、参照ノードの全構成をサーバーにプールし、続いてすべての類似ノードにプッシュすることによってこの構成を複製する Module Configuration Propagation (MCP) という機能もあります。

参照ドメインの詳細は、『Sun Management Center 3.6 ユーザーガイド』の「遠隔管理ドメインの監視」を参照してください。グループ処理の詳細は、『Sun Management Center 3.6 ユーザーガイド』の第 13 章「グループ関連ジョブの管理」を参照してください。