|
|
この節では、WebLogic Operations Control (WLOC) の保護に関する情報を示します。この節は、以下のトピックで構成されています。
WLOC へのアクセスを保護するために、WLOC ではロールベースのアクセス制御を使用します。これにより、さまざまなレベルの特権をユーザまたはグループに割り当てることができます。WLOC では、セキュリティ ロールを提供し、それらのアクセス特権を指定します。多数のユーザの管理を簡単に行うために、WLOC には、1 つまたは複数の WLOC ロールに属するようにコンフィグレーション可能な一連のグループも用意されています。WLOC Administration Console を使用すると、ユーザを作成してグループに割り当てたり、直接セキュリティ ロールに割り当てたりすることができます。WLOC Administration Console を使用してユーザ、グループ、およびセキュリティ ロールを管理する方法の詳細については、『WLOC Administration Console オンライン ヘルプ』のユーザとグループの管理を参照してください。
匿名ユーザは WLOC Administration Console にアクセスできません。
WLOC Configuration Wizard を実行してコントローラを作成する場合は、起動ユーザのユーザ名とパスワードの入力をウィザードから求められます。このアカウントは、WLOC Administration Console へのログインに使用されます。デフォルトのユーザ名とパスワードはそれぞれ WLOCBootUser および changeit です。
| 注意 : | システムのセキュリティを保護するために、Oracle ではこのパスワードを (特にプロダクション環境では) 変更することをお勧めします。そのためには、『WLOC Administration Console オンライン ヘルプ』の「ユーザの変更」を参照してください。 |
| 警告 : | 起動ユーザは削除しないでください。削除すると、WLOC Administration Console にログインする場合に、コントローラの再作成が必要になります。 |
ユーザは認証可能なエンティティです。WLOC で使用されるのはパスワード認証のみです。グループは、一般に何らかの共通点 (例 : 社内の同じ部署に所属している) を持つユーザの集まりです。セキュリティ管理を効率的に行うために、Oracle では、セキュリティ ロールに直接ユーザを追加するのではなく、グループにユーザを追加してからセキュリティ ロールに割り当てることをお勧めします。
表 7-1 は、WLOC セキュリティ グループおよびそのグループについてあらかじめ用意されているセキュリティ ロールの割り当てを示しています。追加のグループは作成可能ですが、追加のセキュリティ ロールを作成することはできません。サービスを作成することにより、スコープ指定されたサービスの Admin ロールを間接的に作成することができます。新しいサービスを作成すると、そのサービスを管理するセキュリティ ロールが作成されます。また、WLOC では、作成するサービスごとに ServiceAdministrators_Service-Name というグループを作成します。Service-Name はサービスの名前です。ユーザがすべてのサービスを管理できるようにするには、ServiceAdministrators グループにユーザを追加する必要があります。ユーザが 1 つの Service-Name サービスだけを管理できるようにするには、ServiceAdministrators_Service-Name グループにユーザを追加する必要があります。サービスを削除すると、ServiceAdministrators_Service-Name グループは削除されます。
また、WLOC では、作成するサービスごとに ServiceAdmin_Service-Name というロールが提供されます。Service-Name はサービスの名前です。
表 7-2 は、WLOC セキュリティ ロールのアクセス特権を示しています。追加のセキュリティ ロールを作成したり、ロールのアクセス特権を変更したりすることはできません。ServiceAdmin_Service-Name ロールにユーザを追加することはできません。その代わりに、ServiceAdministrators_Service-Name グループにユーザを追加する必要があります。
WLOC、管理対象エンドポイント、およびエンドポイントをホストするインフラストラクチャの間の通信を保護するために、WLOC では一方向 SSL または双方向 SSL を使用します。この場合、境界セキュリティ対策 (ファイアウォールなど) がコンフィグレーションされており、ホストやそのファイル システムへのアクセスが信頼性のあるユーザに制限されていることを前提としています。
図 7-2 は、WLOC の通信におけるセキュリティの概要を示します。
Oracle では、コントローラとすべてのエージェントを、可能な限り同じファイアウォールの内側に配置することをお勧めします (図 7-2 を参照)。セキュアな通信が有効な場合、コントローラとエージェントは HTTPS のみを使用して通信します。この通信では、コントローラは常に要求を送信することによって通信を開始し、エージェントは応答を返します。コントローラがエージェントとの接続を開始し、エージェントがそれに応答すると、エージェントとコントローラのどちらかが HTTPS 接続を開始できます。
コントローラとエージェントを別個のファイアウォールの内側に配置する場合は、少なくとも 1 つの HTTPS 通信チャネルを開くようにファイアウォールをコンフィグレーションする必要があります。また、ファイアウォールの内側の各エージェントについてポート転送をコンフィグレーションする必要があります。このような環境では、コントローラはファイアウォールに要求を送信し、ファイアウォールはそれぞれの要求を適切なエージェントに転送します。図 7-3 を参照してください。
同様に、エージェントでは、一方向プロトコル (HTTPS または IIOPS) を使用してハイパーバイザ ソフトウェアおよび管理対象プロセスと通信します。ファイアウォールを使用してエージェントをハイパーバイザ ソフトウェアや管理対象プロセスから分離する場合は、エージェントからハイパーバイザ ソフトウェアや管理対象プロセスに要求を転送するようにファイアウォールをコンフィグレーションする必要があります。
Web ブラウザと WLOC Administration Console との通信は一方向 SSL を使用して保護されます。この通信における考慮事項は以下のとおりです。
controller で格納) がキーストアに追加されます。「キーストア」を参照してください。
Administration Console とコントローラとのセキュアな通信を有効にするには、コントローラの [Console Security Mode] を SECURE または BOTH に設定します。この設定は Configuration Wizard の実行中に行うことができます。また、Administration Console の [Networking] タブを使用するか、loc-controller-config.xml の <console-mode> 要素を変更する方法もあります。
コントローラでは、個別の SSL 接続を確立し、双方向 SSL を使用して HTTPS 経由で各エージェントと通信します。この通信では、コントローラは SSL クライアントであり、各エージェントは SSL サーバです。
コントローラとエージェントとの接続でセキュアな接続を有効にするには、以下の点に注意する必要があります。
| 注意 : | コントローラとそのエージェントのセキュリティ モードの設定は同じにする必要があります。 |
双方向 SSL を使用すると、攻撃者が通信を覗き見ることを防げますが、エージェントの Web サービス インタフェースでは認可が必要とされません。エージェントでは、SSL 接続が確立されると、呼び出し側は信頼性できると想定します。WLOC エージェントを不正使用されないようにするには、すべてのエージェントをファイアウォールの内側に配置して、コントローラとエージェントとのセキュアな通信を有効にしてください。
テスト環境や暗号化が不要なその他の環境では、非セキュアな接続を使用できます。ただし、この場合、すべてのエージェントとコントロールの機能に攻撃者が制約なしに直接アクセス可能である点に注意が必要です。
エージェントの内部信頼キーストアへのコントローラの ID 証明書のインポートは、JDK bin ディレクトリ (例 : BEA_HOME\jrockit_xxx_xx\bin) にある Keytool ユーティリティを使用して行われます。インポートを実行するには、次の手順に従います。
keytool -import -noprompt -alias controllerinternal -file BEA_HOME/user_projects/controller/ssl/internal/controllerinternalidentity.pem -keystore BEA_HOME/user_projects/agent1/ssl/internal/internaltrust.jks -storepass jks_password
controllerinternal は作成するエリアスです。jks_password は、エージェントの内部信頼キーストアの現在のパスワードです (デフォルト値は changeit です)。
keytool -list -v -keystore BEA_HOME/user_projects/agent1/ssl/internal/internaltrust.jks -storepass jks_password
コントローラの内部信頼キーストアへのエージェントの ID 証明書のインポートは、JDK bin ディレクトリ (例 : BEA_HOME\jrockit_xxx_xx\bin) にある Keytool ユーティリティを使用して行われます。インポートを実行するには、次の手順に従います。
keytool -import -noprompt -alias agentinternal -file BEA_HOME/user_projects/agent1/ssl/internal/agentinternalidentity.pem -keystore BEA_HOME/user_projects/controller/ssl/internal/internaltrust.jks -storepass jks_password
agentinternal は作成するエリアスです。インポートされるエージェント ID ごとに異なるエリアスを指定する必要があります。
jks_password は、コントローラの内部信頼キーストアのパスワードです (デフォルト値は changeit です)。
keytool -list -v -keystore BEA_HOME/user_projects/controller/ssl/internal/internaltrust.jks -storepass jks_password
エージェントと Virtual Center とのすべての通信は一方向 SSL を使用して保護されます。この通信では、エージェントは SSL クライアントであり、Virtual Center は SSL サーバです。SSL を有効にするには、Virtual Center の証明書をエージェントの内部信頼キーストアにインポートする必要があります。
エージェントと Virtual Center とのセキュアな接続をコンフィグレーションするには、Virtual Center の ID 証明書をエージェントの信頼キーストアにインポートする必要があります。この処理は、Configuration Wizard でエージェント インスタンスを作成するときに [Connect to the Virtual Center to retrieve SSL certificate] オプションを選択すると、自動的に行われます。
また、GrabCert ユーティリティを使用して Virtual Center に接続し、証明書を取得してからトラストストアに配置することにより、Virtual Center ID をインポートすることもできます。次に、Keytool ユーティリティを使用して、インポートが成功したかどうかを確認できます。GrabCert ユーティリティは、WLOC_HOME\common\bin ディレクトリにあります。Keytool ユーティリティは、JDK bin ディレクトリ (例 : BEA_HOME\jrockit_xxx_xx\bin) にあります。
BEA_HOME/user_projects/ESXAgent/ssl/internal にコピーします。 java -jar ./wloc_10.3/common/bin/GrabCert.jarhost[:port] [-alias=alias] [truststorepath[truststorepassword]]
host:port は、リモート サイトの証明書を要求するために SSL を使用して接続するホストとポートです。
-alias は、リモート証明書をローカルのトラストストアに保存する場合に使用する証明書エリアスです。
truststorepath は、リモート証明書を保存するローカルのトラストストアの場所です。既存のトラストストアがない場合は、新しく作成されます。
truststorepassword は、ローカルのトラストストアのパスワードです。
port: 443
alias:hostname
truststorepath:internaltrust.jks
truststorepassword:changeit
keytool -list -v -keystore BEA_HOME/user_projects/ESXAgent/ssl/internal/internaltrust.jks -storepass jks_password
エージェントは、IIOPS を使用して一方向 SSL 接続経由で MBean サーバと通信します。この通信では、エージェントは SSL クライアントであり、MBean サーバは SSL サーバです。管理対象プロセスでは、管理する側のエージェントの内部信頼キーストアにインポートする証明書を提供します。
また、通常、MBean サーバはユーザ名とパスワードを資格として使用して認証を行うようにコンフィグレーションされます (WebLogic Server MBean サーバでは、常に認証と認可が必要です)。
セキュアな通信のために、WLOC では、環境全体に配布される Java キーストアを使用します。WLOC Configuration Wizard では、すべての WLOC キーストアを作成し、ID キーストアにプライベート キーと自己署名証明書を格納します。自己署名証明書は、ID キーストア外では pem ファイルとして使用することもできるため、対応する信頼キーストアにインポート可能です。
ユーザは、信頼キーストアへの情報の格納を行います。管理対象プロセスとハイパーバイザ ソフトウェアは独自の ID キーストアを提供します。WLOC では、管理対象プロセスとハイパーバイザ ソフトウェア用のキーストアを作成しません。図 7-4 を参照してください。
Web ブラウザと WLOC Administration Console との間の一方向 SSL をサポートするために、コントローラではコンソール ID キーストアを使用します。コントローラと各エージェントとの間の双方向 SSL をサポートするために、コントローラではコントローラの内部 ID キーストアとコントローラの内部信頼キーストアを使用します。
コンソール ID キーストアには、Web ブラウザと WLOC Administration Console アプリケーションとの一方向 SSL 通信をサポートするプライベート キーと自己署名証明書が格納されます。WLOC Administration Console アプリケーションを使用したセッションをユーザが開始すると、Web ブラウザから、コントローラの証明書を信頼するように求められます。
controlleridentity.jks であり、CONTROLLER_DIR\ssl にあります。ここで、CONTROLLER_DIR は、コントローラをインストールするディレクトリ (例 : BEA_HOME\user_projects\controller\ssl\controlleridentity.jks) です。 controller というエリアスで保存されます。また、この証明書にはコントローラがインストールされるホストの名前が格納されます。証明書のキー サイズは 1024 で、プライベート キーの種類は RSA です。また、署名アルゴリズムとして MD5withRSA を使用します。有効期限は 10958 日 (30 年) です。controller というエリアスを使用する必要があります。
キーストアの名前は internalidentity.jks であり、CONTROLLER_DIR\ssl\internal にあります。ここで、CONTROLLER_DIR は、コントローラをインストールするディレクトリ (例 : BEA_HOME\user_projects\controller\ssl\internal\internalidentity.jks) です。
このキーストア内の証明書は controllerinternal というエリアスで保存されます。また、この証明書にはコントローラがインストールされるホストの名前が格納されます。証明書のキー サイズは 1024 で、プライベート キーの種類は RSA です。また、署名アルゴリズムとして MD5withRSA を使用します。有効期限は 10958 日 (30 年) です。
JDK キーストア ツールを使用したキーストアへのアクセスは、パスワードで保護されます。パスワードは、Configuration Wizard の実行時にユーザが指定します。また、このパスワードは、コントローラのコンフィグレーション ドキュメントに、暗号化された文字列として格納されます。このキーストアの変更は想定されていませんが、JDK キーストア ツールを使用して証明書の値を読み込むことができます。
コントローラの内部信頼キーストアには、各エージェントの自己署名証明書のコピーが格納されます (WLOC では、内部信頼キーストアの CA 証明書の使用がサポートされません)。これらの証明書は、コントローラとエージェントとの双方向 SSL 通信をサポートするために必要です。
WLOC Configuration Wizard では、このキーストアを作成しますが、キーストアへのエージェント ID の格納は行いません。この処理は、「コントローラの信頼キーストアへのエージェント ID のインポート」の手順に従って行われます。
キーストアの名前は internaltrust.jks であり、CONTROLLER_DIR\ssl\internal にあります。ここで、CONTROLLER_DIR は、コントローラをインストールするディレクトリ (例 : BEA_HOME\user_projects\controller\ssl\internal\internaltrust.jks) です。
エージェントとコントローラとの間の双方向 SSL、エージェントと管理対象プロセスとの間の一方向 SSL、およびエージェントと VMware Virtual Center との間の一方向 SSL をサポートするために、エージェントではエージェント ID キーストアとエージェントの内部信頼キーストアを使用します。
エージェントの ID キーストアには、エージェントとコントローラとの双方向 SSL 通信をサポートするプライベート キーと自己署名証明書が格納されます。
WLOC Configuration Wizard では、このキーストアおよびプライベート キーと自己署名証明書を作成します。このキーストアのキーや証明書の置き換えまたは変更はできません。
キーストアの名前は internalidentity.jks であり、AGENT_DIR\ssl\internal にあります。ここで、AGENT_DIR は、エージェントをインストールするディレクトリ (例 : BEA_HOME\user_projects\agent1\ssl\internal\internalidentity.jks) です。
このキーストア内の証明書は agentinternal というエリアスで保存されます。また、この証明書にはエージェントがインストールされるホストの名前が格納されます。証明書のキー サイズは 1024 で、プライベート キーの種類は RSA です。また、署名アルゴリズムとして MD5withRSA を使用します。有効期限は 10958 日 (30 年) です。
JDK キーストア ツールを使用したキーストアへのアクセスは、パスワードで保護されます。パスワードは、エージェントのコンフィグレーション時にユーザが指定します。また、このパスワードは、エージェントのコンフィグレーション XML ドキュメントに、暗号化された文字列として格納されます。
このキーストアの変更は想定されていませんが、JDK キーストア ツールを使用して証明書の値を読み込むことができます。
エージェントの内部信頼キーストアには、コントローラの自己署名証明書のコピーおよびエージェントが管理するプロセスの CA 証明書のコピーが格納されます。また、ハイパーバイザ エージェントには、VMware Virtual Center CA 証明書のコピーが格納されます。これらの証明書は、エージェントとコントローラとの双方向 SSL 通信、エージェントと管理対象プロセスとの間の一方向 SSL、およびエージェントと VMware Virtual Center との間の一方向 SSL をサポートするために必要です。
WLOC Configuration Wizard では、エージェントのコンフィグレーション時にこのキーストアを作成します。キーストアの名前は internaltrust.jks であり、AGENT_DIR\ssl\internal にあります。ここで、AGENT_DIR は、エージェントをインストールするディレクトリ (例 : BEA_HOME\user_projects\agent1\ssl\internal\internaltrust.jks) です。
コントローラの ID をキーストアにインポートする場合は、「エージェントの信頼キーストアへのコントローラ ID のインポート」を参照してください。Virtual Center の ID を ESX Agent のキーストアにインポートする場合は、「エージェントの信頼キーストアへの Virtual Center ID のインポート」を参照してください。
WLOC のインストール時、Configuration Wizard の実行時、または WLOC Administration Console の使用時に入力するパスワードは、XML コンフィグレーション ファイルに格納される前に暗号化されます。
| 警告 : | コンフィグレーション XML ファイルを直接編集してパスワードを入力または変更する場合、(通常は、Administration Console を使用してコンフィグレーションを変更した結果として) 新しいコンフィグレーション ファイルが生成されるまで、そのパスワードはクリア テキストのままになります。新しいコンフィグレーション ファイルが生成されると、クリア テキストのすべてのパスワードが暗号化されます。コントローラやエージェントを停止または再起動した場合、クリア テキスト パスワードは暗号化されません。 |
お使いの環境におけるファイル システムのセキュリティによって、WLOC 以外のユーザによる WLOC のファイルとディレクトリへのアクセスが完全に制限される必要があります。これには、パスワードがクリア テキストで格納される可能性のある開発環境やテスト環境が含まれます。
WLOC インストールの保護の詳細については、『プロダクション環境の保護』を参照してください。
  
|