4 セキュリティの構成

この章では、Business Transaction Managementのセキュリティ構成の方法を説明します。この章の内容は必ずよく読むようにしてください。また、セキュリティを構成する場合は、Business Transaction Managementコンポーネントをインストールする前に、関連する実行環境のセキュリティ構成を行う必要があります。

Business Transaction Managementのセキュリティは、次のメカニズムを使用して構成することができます。

HTTPSで通信を行うようにアプリケーション・サーバーを構成するネットワーク・レベルのセキュリティ。

HTTPSを使用して通信する管理コンポーネントでは、このセキュリティ・メカニズムによって、一方向または双方向の認証、メッセージの整合性および通信経路上のメッセージ・データの暗号化が実現されています。詳細は、第4.2項「ネットワーク・レベルのセキュリティ設定」を参照してください。
Business Transaction Managementコンポーネント間でHTTP(S)通信を行うためのBusiness Transaction Managementのビルトイン・セキュリティ。

このセキュリティ・メカニズムによって、HTTP(S)を使用して通信する管理コンポーネント間に信頼関係ができ、機密の通信データ要素をシリアライズする前(すなわち、回線に送信されたりディスクに格納される前)に暗号化できるようになります。詳細は、第4.3項「アサーション秘密および暗号化鍵の構成」を参照してください。
Observation Protocol Secure (OPS)を使用してオブザーバからモニターへ監視メッセージを送信するためのBusiness Transaction Managementのビルトイン・セキュリティ。OPSとは、オラクル社が独占的な権利を有するセキュア・ソケット(SSL)によるObservation Protocol (OP)です。

このセキュリティ・メカニズムによって、オブザーバとモニター間の認証、メッセージの整合性および通信経路上の監視メッセージの暗号化が実現されています。サーバー認証(オブザーバに対するモニターの認証)は、SSLによって提供されます。クライアント認証(モニターに対するオブザーバの認証)はOPSによって提供されます。詳細は、第4.4項「監視メッセージ用のセキュア・ソケット(SSL)の設定」を参照してください。

4.1 通信プロトコルおよびデプロイメント・シナリオ

Business Transaction Managementは分散環境での使用を前提に設計されています。そのため、遠隔データ・センター、DMZまたは集中データベースにアクセスできないネットワークにデプロイされるコンポーネントが存在する可能性もあります。次の表では、様々なBusiness Transaction Managementコンポーネント間や、それらのコンポーネントとビジネス・サービス間で必要になるアクセスのタイプについて説明しています。

表4-1 Business Transaction Management通信プロトコル

通信元コンポーネント	必要なプロトコル	通信先コンポーネント	説明	図での表示
各セントラル・サーバー(メイン、トランザクションおよびパフォーマンス・サーバー)	HTTPまたはHTTPS	他のセントラル・サーバー	セントラル・サーバーは相互に通信できる必要があります。通常のデプロイメント・トポロジでは、各セントラル・サーバーは同じネットワーク・ゾーンに配置されます。	A
各セントラル・サーバー	HTTPまたはHTTPS	すべてのモニター	各セントラル・サーバーはすべてのモニターと通信できる必要があります。セントラル・ネットワーク・ゾーンの外側にデプロイされているモニターも同様です。	B
メイン・サーバー	TCP、HTTPまたはHTTPS	すべての監視対象ビジネス・サービス	「稼働中」であるか(動作しているか停止しているか)を判断するために、メイン・サーバーは監視対象のビジネス・サービスと通信できる必要があります。なお、稼働ステータスを判断するために使用する厳密なプロトコルは、サービスごとに構成できます。(このプロトコルの構成の詳細は、My Oracle Supportでサービス・リクエストを入力してください。)	C
各モニター	HTTPまたはHTTPS	すべてのセントラル・サーバー	モニターは各セントラル・サーバーと通信できる必要があります。	D
各モニター	JDBC	メッセージ・ログ・データベース(messageLogDB)	各モニターは、JDBCを使用してメッセージ・ログ・データベースの書込みおよび読込みができる必要があります。メッセージ・ログ・データベースは、すべてのモニターが使用する信頼できるネットワーク内の単一データベースでも構いません。または、モニターがDMZや集中データベースにアクセスできないネットワークにある場合は、リモート・モニター用に1つ以上のデータベースをデプロイすることもできます。	E
各オブザーバ	TCPおよびHTTPまたはHTTPS	関連付けられたモニター	各オブザーバには、関連付けられたモニターへのコネクションが2つ必要です。オブザーバは、モニターから構成をダウンロードするためにHTTP(S)コネクションを使用します。監視メッセージをモニターに送信するために、オブザーバはTCPによるObservation Protocol (OP)またはセキュア・ソケットによるObservation Protocol Secure (OPS)を使用して接続します。モニター・グループに対しては、これらのコネクションはモニター・グループの前にあるロード・バランサに対して作成されます。ソケット・ポート番号は、オブザーバ通信ポリシーで構成します。	F
トランザクション・サーバー	JDBC	すべてのメッセージ・ログ・データベース	省略可。トランザクション・サーバーは、メッセージ・ログ・データベースに直接アクセスできる必要はありません。ただし、このようなアクセスを可能にすることによって、メッセージ・ログ問合せのパフォーマンスを改善できます。可能な場合は常にこの通信チャネルを有効にしてください。	G
メイン・サーバー	JDBC	スフィア・データベース(sphereDB)	メイン・サーバーは、JDBCを使用してスフィア・データベースに書き込みできる必要があります。	H
パフォーマンス	JDBC	測定データベース(measurementDB)	パフォーマンス・サーバーは、JDBCを使用して測定データベースに書き込みできる必要があります。	I
トランザクション	JDBC	トランザクション・データベース(transactionDB)	トランザクション・サーバーは、JDBCを使用してトランザクション・データベースに書き込みできる必要があります。	J
(モニター・グループ内の)モニター	JDBC	モニター・グループ・データベース	特定のモニター・グループ内の各モニターは、JDBCを使用して同じモニター・グループ・データベースに書き込みができる必要があります。	K

次の図に、様々なデプロイメント・シナリオでBusiness Transaction Managementコンポーネントに必要となるアクセスのタイプを示します。なお、図中の丸印のついた文字は、表4-1「Business Transaction Management通信プロトコル」との相互参照用です。

図4-1「デプロイされたBusiness Transaction Managementコンポーネントおよびビジネス・サービス」
図4-2「セントラル・サーバー内およびセントラル・サーバーとモニター間の通信コネクション」
図4-3「Business Transaction Managementコンポーネントとデータベース間のコネクション」
図4-4「モニターとオブザーバ間の通信コネクション」
図4-5「メイン・サーバーとビジネス・サービス間の通信コネクション」

図4-1 デプロイされたBusiness Transaction Managementコンポーネントおよびビジネス・サービス

「図4-1 デプロイされたBusiness Transaction Managementコンポーネントおよびビジネス・サービス」の説明

図4-2 セントラル・サーバー内およびセントラル・サーバーとモニター間の通信コネクション

「図4-2 セントラル・サーバー内およびセントラル・サーバーとモニター間の通信コネクション」の説明

図4-3 Business Transaction Managementコンポーネントとデータベース間のコネクション

「図4-3 Business Transaction Managementコンポーネントとデータベース間のコネクション」の説明

図4-4 モニターとオブザーバ間の通信コネクション

「図4-4 モニターとオブザーバ間の通信コネクション」の説明

図4-5 メイン・サーバーとビジネス・サービス間の通信コネクション

「図4-5 メイン・サーバーとビジネス・サービス間の通信コネクション」の説明

4.2 ネットワーク・レベルのセキュリティ設定

Business Transaction Managementコンポーネントに対してネットワーク・レベルのセキュリティを有効にしたい場合、コンポーネントがデプロイされているアプリケーション・サーバーが提供するSSL/TLSを使用して実現することができます。SSLによってあるサーバーから別のサーバーへと流れる管理トラフィックが暗号化され、分散管理コンポーネント間の通信におけるメッセージの整合性および機密保持が実現されています。クライアント証明書とともに構成すると、SSLによる管理コンポーネント間の相互認証も実現できます。Business Transaction ManagementはSSLの特殊なサポートは行わないため、標準のSSL構成の妨げにはなりません。そのため、Business Transaction Managementのトラフィックの安全性を高めるために、アプリケーション・サーバーでサポートされているすべての構成を使用することができます。Business Transaction Managementコンポーネントをインストールする前に、まずアプリケーション・サーバーがSSL用に適切に構成されていることを確認することを強くお薦めします。

Business Transaction Managementをデプロイするアプリケーション・サーバーでSSLを構成し、テストした後、Business Transaction Managementをインストールし、その後にブラウザ・ベースの初期構成ウィザードを使用してBusiness Transaction Managementを構成します。初期構成の際には、必要なSSLアドレスおよびポート番号を指定します。Business Transaction Managementコンポーネントは自動的に安全な転送方法で通信します。

注意:

オブザーバおよびモニターは、監視メッセージの送信に使用するソケット接続および管理系のメッセージに使用するHTTP/HTTPS接続という2つの個別のチャネルで相互に通信します。ソケット接続用のSSLの設定は、第4.4項「監視メッセージ用のセキュア・ソケット(SSL)の設定」で説明しています。HTTPS接続の設定はこれとは無関係の別のタスクで、アプリケーション・サーバーのセキュリティ機能を使用して行います。

4.2.1 HTTPSの構成

この項は、コマンドライン・インタフェース(CLI)を含むすべてのBusiness Transaction Managementコンポーネントに関係しています。

セントラル・サーバーをHTTPSのみの環境(すなわち、コンポーネント間にHTTPトラフィックが発生しない環境)にインストールする場合、次のいずれかを実行する必要があります。

セントラル・サーバーをホストしているアプリケーション・サーバーが、HTTPSポートのみをリスニングしていることを確認します。

または

HTTPSアクセスのみを許可していることを指定するために、各セントラル・サーバーのWARファイルにパッケージ化されている各web.xmlファイルを変更します。これは、前述のファイルで提供されている次の<security-constraint>要素のコメントを解除することのみで実現できます。

<security-constraint>
  <display-name>Require SSL communication</display-name>
  <web-resource-collection>
    <web-resource-name>All AmberPoint system services</web-resource-name>
    <url-pattern>/*</url-pattern>
  </web-resource-collection>
  <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
  </user-data-constraint>
</security-constraint>

4.2.2 WebLogic ServerのJSEEプロパティ設定

WebLogicサーバーでHTTPS通信を行うための構成の一部として、サーバーで多くのJavaシステム・プロパティを設定する必要があります。これらのプロパティは、WebLogicサーバーがセキュリティ・ストアにアクセスするために必要な情報を指定するものです。プロパティ内で指定する情報は、次のとおりです。

注意:

次のリストにおいて、双方向SSLとは、相互認証を必要とするSSL接続を指しています。一方向SSLとは、サーバー認証のみを必要とするSSL接続を指しています。

クライアントのトラスト・ストアの場所(一方向または双方向SSLに必要)
トラスト・ストアのタイプ(一方向または双方向SSLに必要)
トラスト・ストアにアクセスするためのパスワード(一方向または双方向SSLに必要)
サーバーのキー・ストアの場所(双方向SSLに必要)
キー・ストアのタイプ(双方向SSLに必要)
キー・ストアにアクセスするためのパスワード(双方向SSLに必要)

WebLogicサーバーでは、javax.net.ssl.* (JSEE)プロパティまたはweblogic.security.* プロパティのどちらかによって、この情報を指定できます。WebLogicサーバーは、どちらのタイプのプロパティからでもこの情報を読み込むことができます。一方、Business Transaction Managementも同じ情報へのアクセスが必要ですが、JSEEプロパティ以外からは読み込むことができません。このため、JSEEプロパティのみ、またはweblogic.security.*およびJSEEプロパティの両方を設定して、必要な情報を提供できます。JSEEプロパティが設定されていない場合、Business Transaction Managementコンポーネントの起動は失敗します。

注意:

WebLogic管理コンソールの「環境」→「サーバー」→「サーバー名」→「構成」→「SSL」→「詳細」タブで「JSSE SSLの使用」チェック・ボックスの選択を解除している場合でも、JSEEプロパティを設定する必要があります。

WebLogic管理コンソールまたはWebLogicサーバー起動スクリプトによって、JavaオプションとしてJSEEプロパティを設定します。次の例は、双方向SSL設定のためのオプションです。

-Djavax.net.ssl.trustStore=path_to_my_trustStore

-Djavax.net.ssl.trustStoreType=type_of_my_trustStore

-Djavax.net.ssl.trustStorePassword=my_trustStore_password

-Djavax.net.ssl.keyStore=path_to_my_keyStore

-Djavax.net.ssl.keyStoreType=type_of_my_keyStore 

-Djavax.net.ssl.keyStorePassword=my_keyStore_password

次の例は、WindowsのWebLogicサーバー起動スクリプトでWebLogic Demoセキュリティ・ストアを使用して双方向SSL用のJSEEプロパティを設定する方法を示しています。

set JAVA_OPTIONS=-Djavax.net.ssl.trustStore=C:\Oracle\Middleware\wlserver_10.3\server\lib\DemoTrust.jks -Djavax.net.ssl.trustStoreType=JKS -Djavax.net.ssl.trustStorePassword=MyTrustStorePassword -Djavax.net.ssl.keyStore=C:\Oracle\Middleware\wlserver_10.3\server\lib\DemoIdentity.jks -Djavax.net.ssl.keyStoreType=JKS -Djavax.net.ssl.keyStorePassword=MyKeyStorePassword %JAVA_OPTIONS%

これらのプロパティをWebLogicサーバー起動スクリプトで設定する場合、必ず次の行の前に前述の行を挿入してください。そうしないと、JAVA_OPTIONSの値が上書きされる可能性があります(最初の例はWindows用で、次の例はUNIX系オペレーティング・システム用です)。

set SAVE_JAVA_OPTIONS=%JAVA_OPTIONS%

SAVE_JAVA_OPTIONS="${JAVA_OPTIONS}"

注意:

HTTPS環境でWebLogic Scripting Tool (WLST)を使用するには、weblogic.security.*プロパティが必要です。

4.2.3 コマンドライン・インタフェース用のJSEEプロパティ設定

HTTPS環境でBusiness Transaction Managementコマンドライン・インタフェース(CLI)を使用している場合は、第4.2.2項でWebLogicサーバーに設定したものと同じJSSEプロパティを設定する必要があります。次の例は、CLIのビルトイン変数であるAP_OPTSを使用したJSSEプロパティの設定方法を示しています。この例は、WebLogic Demoセキュリティ・ストアを使用しています。

set AP_OPTS=-Djavax.net.ssl.trustStore=C:\Oracle\Middleware\wlserver_10.3\server\lib\DemoTrust.jks -Djavax.net.ssl.trustStoreType=JKS -Djavax.net.ssl.trustStorePassword=MyTrustStorePassword -Djavax.net.ssl.keyStore=C:\Oracle\Middleware\wlserver_10.3\server\lib\DemoIdentity.jks -Djavax.net.ssl.keyStoreType=JKS -Djavax.net.ssl.keyStorePassword=MyKeyStorePassword

4.2.4 ファイアウォールの構成

この項は、セントラル・サーバー、モニターおよびオブザーバに関係しています。

ファイアウォールを使用している場合、Business Transaction Managementコンポーネントが通信を受け取る各ポートにアクセスできるように構成する必要があります。対象となるポートには、次のものがあります。

ホストとなるアプリケーション・サーバーがリスニングしているポート
モニターがオブザーバからの監視メッセージを受信するソケット
Business Transaction ManagementデータベースへのJDBC接続に使用されるポート。このデータベースについては、第5.4項「Business Transaction Managementデータベースの設定」を参照

4.3 アサーション秘密および暗号化鍵の構成

注意:

この項で説明されている構成を選択する場合、Business Transaction Managementセントラル・サーバー、モニターまたはオブザーバをホストしているすべてのアプリケーション・サーバーでこの構成を選択する必要があります。Business Transaction Managementコマンドライン・インタフェース(CLI)を使用する実行環境でも、この構成を行う必要があります。

Business Transaction Managementコンポーネント間の通信は、信頼できるアサーションによって安全なものとなります。つまり、Business Transaction Managementコンポーネントが相互に通信し、インストールされたBusiness Transaction Managementが正しく機能するためには、すべてのBusiness Transaction Managementコンポーネントが同じ値のアサーション秘密で構成されている必要があります。

Business Transaction Managementは、コンポーネント間の通信に含まれる機密データの暗号化も行います。データの暗号化は、通信経路上およびBusiness Transaction Managementデータベースの記憶域の両方で行われます。

このようなセキュリティ・メカニズムはデフォルトで有効で、すべてのBusiness Transaction Managementコンポーネントはデフォルトのアサーション秘密および暗号化鍵であらかじめ構成されています。このデフォルトのセキュリティ構成によって、セキュリティ・メカニズムが完全に有効化されているとともにBusiness Transaction Managementのインストールが簡単になっています。

一方、すべてのインストールされたBusiness Transaction Managementは同じデフォルト値を持っているため、デフォルト値を使用することは潜在的なセキュリティの脅威となります。デモ用、または開発環境では、デフォルト値で十分かもしれません。ただし、本番環境では、一意の値を指定してセキュリティを強固にする必要があります。また、Business Transaction Managementを本番環境にデプロイする前に使用するテスト環境でも独自の値を使用する必要があります。アサーション秘密および暗号化鍵に独自の値を指定する場合は、コンポーネントをデプロイする前にBusiness Transaction Managementコンポーネントをホストしている各アプリケーション・サーバーで構成を行う必要があります。

WebLogicサーバーにデプロイするコンポーネントでは、これらのセキュリティ設定を構成し格納するために使用する方法を、Oracle Wallet (第4.3.1項を参照)またはBusiness Transaction Management拡張プロパティ(第4.3.2項を参照)のどちらかから選択することができます。(Oracle Walletは、Oracle資格証明ストア・フレームワークすなわちOCSFの実装で、Javaプラットフォーム・セキュリティすなわちJPSのコンポーネントです。)その他のJavaアプリケーション・サーバーおよびOracle Enterprise Gatewayでは、Business Transaction Management拡張プロパティを使用します。必要に応じて、これらのセキュリティ構成方法を混在させることも可能です。たとえば、あるアプリケーション・サーバーではOracle Walletを使用し、別のアプリケーション・サーバーではBusiness Transaction Management拡張プロパティを使用することも可能です。

4.3.1 Oracle Walletによるセキュリティ構成

この項は、WebLogicアプリケーション・サーバーにデプロイするセントラル・サーバー、モニターおよびオブザーバに関係しています。ここでは、Oracle Walletを使用したBusiness Transaction Managementコンポーネント用のアサーション秘密および暗号化鍵の構成方法について説明します。この手順は、Oracle Walletを使用してアサーション秘密および暗号化鍵を構成する各セントラル・サーバー、モニターおよびオブザーバで繰り返す必要があります。

Business Transaction ManagementコンポーネントをインストールするWebLogicドメインに、Java Required Files (JRF)テンプレートが含まれていることを確認します。

ドメインが存在しない場合は、ドメインを作成する際に必ずJRFテンプレートを追加するようにします。ドメインがすでに存在し、JRFテンプレートが含まれていない場合は、ドメインを拡張してテンプレートを追加します。

JRFテンプレートには、後の手順で参照するJPS JARファイルが含まれています。(JPSはOracle Platform Security Servicesのコンポーネントです。)
アサーション秘密および暗号化鍵を格納する資格証明の名前を決定します。

名前は自由に選択できますが、それぞれの2つの資格証明は別の名前とする必要があります。また、すべてのBusiness Transaction Managementコンポーネントで同じ2つの資格証明の名前を使用する必要があります。
発行者名および発行者のアサーション秘密の値を決定します。

この文字列の値は自由に選択できますが、すべてのBusiness Transaction Managementコンポーネントで同じ値を使用する必要があります。
Business Transaction Managementセントラル・サーバー用の配布アーカイブを探し、セキュリティを構成するセントラル・サーバー、モニターまたはオブザーバをホストしているマシン上のディレクトリ(以降、このディレクトリをBTM_Central_Expandedと表記します)に展開します。

配布アーカイブはBTM_Servers*.zipという名前です。「*」はバージョン番号です。
以下の手順に従い、setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを構成します。

setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを構成することによって、アプリケーション・サーバーのクラスパスへのJPS JARファイルの追加、デフォルトの資格証明ストアのオーバーライド、共通秘密鍵および暗号化鍵が格納されている資格証明の名前の指定(なお、資格証明は後の手順で作成します)が実現できます。
1. BTM_Central_Expanded/security_add_onsの中から、setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを探します。
  
  Windowsシステムでは、setBtmOverriderEnv_via_CredStore.cmdを使用します。UNIX系システムでは、setBtmOverriderEnv_via_CredStore.shを使用します。
2. スクリプト・ファイルをWebLogicサーバーにコピーします。
  
  すべてのドメインでセキュリティを構成する場合は、スクリプト・ファイルをWebLogicサーバーのホーム・ディレクトリにコピーします。ホーム・ディレクトリとは、WebLogicのインストール・ディレクトリにあるweblogic92またはwlserver_10.3ディレクトリで、たとえばC:\bea\wlserver_10.3です。
  
  特定のドメインに対してセキュリティを構成する場合は、スクリプト・ファイルをドメインのディレクトリのトップ・レベルにコピーします。
3. テキスト・エディタでスクリプト・ファイルを開きます。
4. 文字列>>> YOUR_ISSUER_SECRET_CREDENTIAL_NAME_HERE <<<をアサーション秘密の資格証明の名前で置換して、BTM_TIS_CRED_NAME変数にアサーション秘密が格納されている資格証明の名前を設定します。
5. 文字列>>> YOUR_ENCRYPT_KEY_CREDENTIAL_NAME_HERE <<<を暗号化鍵の資格証明の名前で置換して、BTM_ENCKEY_CRED_NAME変数に暗号化鍵が格納されている資格証明の名前を設定します。
6. スクリプト・ファイルを保存して閉じます。

次の手順に従い、setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを呼び出すように、WebLogicのドメイン起動スクリプトを構成します。

注意:

この手順では、startWebLogicスクリプトを変更していないことを仮定しています。スクリプトを変更している場合は、それに応じたインストール手順の変更が必要な場合があります。

セキュリティを構成するWebLogicドメインの1つでbinディレクトリに移動し、テキスト・エディタで起動スクリプトを開きます(Windowsシステムではbin\startWebLogic.cmdを、UNIX系システムではbin/startWebLogic.shを開きます。ドメイン・ディレクトリの直下にある起動スクリプトは編集しないでください)。
次の行を探します(最初の行はWindowsの場合、次の行はUNIX系システムの場合)。
```
call "%DOMAIN_HOME%\bin\setDomainEnv.cmd"

. ${DOMAIN_HOME}/bin/setDomainEnv.sh
```
この行の直後に、setBtmOverriderEnv_via_CredStoreスクリプト・ファイルを呼び出す行を追加します。

Windowsシステムですべてのドメインのセキュリティを構成する場合は、次の行を追加します。
```
call "%WL_HOME%\setBtmOverriderEnv_via_CredStore.cmd"
```
UNIX系システムですべてのドメインのセキュリティを構成する場合は、次の行を追加します(最初のピリオドと空白に注意してください)。
```
. ${WL_HOME}/setBtmOverriderEnv_via_CredStore.sh   
```
Windowsシステムで特定のドメインのセキュリティを構成する場合は、次の行を追加します。
```
call "%DOMAIN_HOME%\setBtmOverriderEnv_via_CredStore.cmd"
```
UNIX系システムで特定のドメインのセキュリティを構成する場合は、次の行を追加します(最初のピリオドと空白に注意してください)。
```
. ${DOMAIN_HOME}/setBtmOverriderEnv_via_CredStore.sh
```
セキュリティを構成する各ドメインで、この手順を繰り返します。

次の手順に従い、ポリシー・ストアにBusiness Transaction Managementコンポーネント用の権限付与を追加します。
1. セキュリティを構成するWebLogicドメインの1つでconfig\fmwconfigディレクトリに移動します。
  
  このディレクトリは、JRFテンプレートを含めるようにドメインを拡張した際に作成されたもので、oracle.security.jps.configプロパティが検索するデフォルトの場所となっています。
2. テキスト・エディタでsystem-jazn-data.xmlファイルを開きます。
3. セキュリティを構成するドメイン内の各デプロイメントで、次の例のように文字列Your Deployment Name Hereをデプロイメント名で置換し、<jazn-data>/<jazn-policy>要素の子要素として<grant>要素を追加します。
```
<jazn-data>
 <jazn-policy>
 (... other <grant> elements, etc. ...)
 
  
  <grant>
   <grantee>
    <codesource>
     <url>file:${domain.home}/servers/${weblogic.Name}/tmp/_WL_user/Your Deployment Name Here/-</url>
    </codesource>
   </grantee>
   <permissions>
    <permission>
     <class>
      oracle.security.jps.service.credstore.CredentialAccessPermission
     </class>
     <name>context=SYSTEM,mapName=BTM,keyName=*</name>
     <actions>read,write</actions>
    </permission>
   </permissions>
  </grant>
  
 
 (... other <grant> elements, etc. ...)
 </jazn-policy>
</jazn-data>
```
  表1-1は、セントラル・サーバーおよびモニターのデプロイメント名の一覧です。オブザーバには、監視するビジネス・アプリケーションを含むデプロイメント名を使用します。
4. ファイルを保存して閉じます。
5. セキュリティを構成する各ドメインで、この手順を繰り返します。

次の手順に従い、Business Transaction Managementコマンドライン・インタフェース(CLI)を使用してアサーション秘密を含む「信頼できる発行者と秘密」の資格証明を作成し、先ほど構成したポリシー・ストアに関連付けられたOracle Wallet資格証明ストアに追加します。

次の手順では、最初にCLI用の環境を設定し、次にCLIをOracle Wallet資格証明ストアに向け、最後にCLIを使用してアサーション秘密用の資格証明を作成し、ストアに追加しています。

コマンド・シェルまたはコマンド・ウィンドウを開き、JAVA_HOMEおよびJPS_11_HOME環境変数が正しく設定されていることを確認します。

これらの変数は、システムまたはシェルおよびウインドウ・レベルで設定されます。JAVA_HOME変数は、バージョン6以上のJDKを指している必要があります。JPS_11_HOME変数は、次の例のようにoracle.jpsファイルを指している必要があります。
```
oracle\Middleware\oracle_common\modules\oracle.jps_11.1.1
```
テキスト・エディタでBTM_Central_Expanded/security_add_ons/jps_config_dir/jps-config.xmlファイルを開き、次の行を探します。
```
<serviceInstance name="credstore" provider="credstoressp" location="./">
```
次の例のように、location属性の値を./からWebLogicドメイン・ディレクトリ内の/config/fmwconfig/ディレクトリに変更します。
```
<serviceInstance name="credstore" provider="credstoressp" location="C:/Oracle/Middleware/user_projects/domains/my_domain/config/fmwconfig/">
```
location属性の値は、手順7でドメイン用にポリシー・ストアを構成した%DOMAIN_HOME%\config\fmwconfigディレクトリの場所と一致している必要があります。
コマンド・シェルまたはウィンドウでBTM_Central_Expanded/toolsディレクトリに移動し、次のコマンドを実行します(my_credential_nameは、手順5 dで選択したこの資格証明の名前で置換します)。
```
btmcli credStoreTool -createCred my_credential_name -credType is
```
CLIから、「信頼できるアサーション発行者」および「信頼できるアサーション秘密」が求められます。後者は、入力した文字がアスタリスクで表示されます。

「信頼できるアサーション発行者」および「信頼できるアサーション秘密」の値を入力します(次の手順のために、コマンド・シェルまたはウィンドウは開いたままにします)。

手順3で選択した値を使用します。

注意:

対話モードを使用したくない場合は、コマンドラインに-credValue my_issuer:my_secretを追加することによって発行者名およびアサーション秘密を指定することも可能です。ただし、対話モードを使用する方が、マスキングされるため安全です。

この時点で、アサーション秘密の資格証明は作成され、Oracle Wallet資格証明ストアに追加されています。

同じコマンド・シェルまたはウィンドウで、CLIを使用して次のコマンドを実行し、暗号化鍵用の資格証明を作成します(my_credential_nameは、手順5 eで選択したこの資格証明の名前で置換します)。
```
btmcli credStoreTool -createCred my_credential_name -credType bin -genKey AES:128
```
このコマンドによって、指定された名前の資格証明が作成され、AES 128ビット乱数暗号化鍵が生成され、Oracle Wallet資格証明ストアに追加されます。
次のコマンドを実行して、システム内の他のマシンの構成に使用するために暗号化鍵を検索します(my_credential_nameは、資格証明の名前で置換します)。
```
btmcli credStoreTool -getCred my_credential_name -credType bin -showSecret
```
このコマンドは、暗号化鍵の文字列値を返します。この文字列は、システム内の他のマシンを構成する際にコピーする必要があります。
Oracle Walletを使用してアサーション秘密および暗号化鍵を構成する各セントラル・サーバー、モニターおよびオブザーバで、必要な手順を繰り返します。ただし、繰り返す際には次の点を変更します。
- 手順2および3はスキップします(最初のマシンで使用したものと同じ資格証明の名前、発行者名および発行者アサーション秘密の値を使用します)。
- 手順9および10のコマンドのかわりに、次のCLIコマンドを実行します(my_credential_nameは資格証明の名前で、my_encryption_key_stringは手順10で取得した文字列で置換します)。
```
btmcli credStoreTool -createCred my_credential_name -credType bin -credValue my_encryption_key_string
```
  このコマンドによって、指定された名前および暗号化鍵の資格証明が作成され、Oracle Wallet資格証明ストアに追加されます。

4.3.2 拡張プロパティによるセキュリティ構成

この項は、セントラル・サーバー、モニターおよびオブザーバに関係しています。ここでは、Business Transaction Management拡張プロパティを使用したアサーション秘密および暗号化鍵の構成方法について説明します。この手順は、拡張プロパティを使用してアサーション秘密および暗号化鍵を構成する各セントラル・サーバー、モニターおよびオブザーバで繰り返す必要があります。

このセキュリティ・メカニズムには、次の2つの基本的な部分があります。

このメカニズムの最初の部分は、拡張プロパティを宣言し、値を設定する一連のファイルです。

アサーション秘密および暗号化鍵のそれぞれに拡張プロパティ・ファイルが必要です。両方を設定する場合、2つの拡張プロパティ・ファイルが必要になります。両方の拡張プロパティ・ファイルを同じディレクトリに配置し、オペレーティング・システムのファイル・セキュリティ・メカニズムでファイルを保護します。Business Transaction Managementコンポーネントが実行されるアプリケーション・サーバーは、拡張プロパティ・ファイルを読み込むためのアクセス権を持っている必要があります。詳細は、第4.3.2.1項「拡張プロパティ・ファイルの設定」を参照してください。
このメカニズムの2つ目の部分は、拡張プロパティ・ファイルを含むディレクトリを指すJavaシステム・プロパティ(.NET環境のオブザーバでは、Windows環境変数)です。詳細は、第4.3.2.2項「ポインタの設定」を参照してください。

4.3.2.1 拡張プロパティ・ファイルの設定

拡張プロパティ・ファイルを格納するディレクトリを作成します。

ディレクトリには、任意の名前が使用できます。(以降の手順では、ディレクトリの名前をext_propsと仮定します。)
アサーション秘密を構成する場合は、次の手順を実行します。
1. ext_propsディレクトリ内に、com.amberpoint.SimpleIdentityAssertion.propertiesという名前のファイルを作成します。
2. 次の行をファイルに追加します。
```
TrustedIssuerOverriderClassName=com.amberpoint.wsclient.TrustedIssuerOverriderByExtProp
```
3. さらに、次の行をファイルに追加します。
```
TrustedIssuerSecretOverride=MySecret
```
  MySecretは秘密の文字列です。
4. デフォルトでは、セキュリティ・アサーションの発行者名はAmberPointです。デフォルトの発行者名をオーバーライドする場合、ファイルの3行目に次の行を追加します。
```
TrustedIssuerNameOverride=MyIssuerName
```
  MyIssuerNameはセキュリティ・アサーションの発行者名です。
5. ファイルを閉じます。
暗号化鍵を構成する場合は、次の手順を実行します。
1. ext_propsディレクトリ内に、com.amberpoint.security.encryption.propertiesという名前のファイルを作成します。
2. ファイルに次の2行を追加します。
```
SystemDefaultAESKeyOverriderClassName=com.amberpoint.security.util.SystemDefaultAESKeyOverriderByExtProp

aes.defaultKeySize=128
```
3. さらに、次の行をファイルに追加します。
```
aes.defaultKey=MyEncryptionKey
```
  MyEncryptionKeyはbase 64でエンコードされたAES 128ビット鍵です。
  
  base 64でエンコードされた暗号化鍵を生成した後、コピー・アンド・ペーストでこのプロパティの値を設定できます。鍵に特殊文字が含まれている場合は、次のように二重引用符で囲む必要があります。
```
aes.defaultKey="oylJKoTGXTHasOYwtjwA7g=="
```
4. ファイルを閉じます。
オペレーティング・システムのファイル・セキュリティ・メカニズムを使用して、拡張プロパティ・ファイル(com.amberpoint.SimpleIdentityAssertion.propertiesおよびcom.amberpoint.security.encryption.properties)をセキュリティ保護します。

Business Transaction Managementコンポーネントが実行されるアプリケーション・サーバーが、拡張プロパティ・ファイルを読み込むためのアクセス権を持っていることを確認します。

4.3.2.2 ポインタの設定

ポインタを拡張プロパティ・ファイルに設定するために使用する手順は、Business Transaction Managementがデプロイされるサーバーのタイプによって異なります。この項では、次の環境でのポインタの設定方法を説明します。

Javaアプリケーション・サーバー(第4.3.2.2.1項を参照)
Oracle Enterprise Gatewayサーバー(第4.3.2.2.2項を参照)
.NET環境(第4.3.2.2.3項を参照)

4.3.2.2.1 Javaアプリケーション・サーバーへのポインタ設定

テキスト・エディタでサーバーの起動スクリプトを開きます。
「com.amberpoint.util.Extension.dir」という名前のJavaシステム・プロパティを作成し、次のように値に拡張プロパティ・ディレクトリの場所を設定します。

Windowsシステムの場合は、次のようにします。
```
set JAVA_OPTIONS=-Dcom.amberpoint.util.Extension.dir=C:\btm\ext_props %JAVA_OPTIONS%
```
UNIX系システムの場合は、次のようにします。
```
JAVA_OPTIONS=-Dcom.amberpoint.util.Extension.dir="/home/btm/ext_props" "${JAVA_OPTIONS}"
```
注意:
WebLogicサーバーでは、startWebLogicスクリプトのsetDomainEnvを呼び出す部分の後に、この行を追加します。

4.3.2.2.2 Oracle Enterprise Gatewayサーバーへのポインタ設定

テキスト・エディタでOEG_HOME/system/conf/jvm.xmlファイルを開きます(OEG_HOMEは、インストールしたEnterprise Gatewayサーバーのトップ・レベル・ディレクトリです)。
「com.amberpoint.util.Extension.dir」という名前のJavaシステム・プロパティを作成し、値に拡張プロパティ・ディレクトリの場所を設定します。

<JVMSettings>要素の子要素として<SystemProperty>要素を追加し、次のようにこのプロパティを設定します。

Windowsシステムの場合は、次のようにします。
```
<SystemProperty name="com.amberpoint.util.Extension.dir" value="C:\btm\ext_props"/>
```
UNIX系システムの場合は、次のようにします。
```
<SystemProperty name="com.amberpoint.util.Extension.dir" value="/home/btm/ext_props"/>
```

4.3.2.2.3 .NET環境へのポインタ設定

「com.amberpoint.util.Extension.dir」という名前のWindows環境変数を作成し、次のように値に拡張プロパティ・ディレクトリの場所を設定します。
```
set = C:\btm\ext_props
```

4.4 監視メッセージ用のセキュア・ソケット(SSL)の設定

オブザーバは、ソケット接続によるオラクル社が独占的な権利を有するObservation Protocol (OP)を使用し、関連付けられたモニターに監視メッセージを送信します。この通信チャネルにセキュア・ソケット(SSL)を設定することによって、監視メッセージをセキュリティ保護することができます。SSLを使用するOPは、Observation Protocol Secure (OPS)と呼ばれています。

このセキュリティ・メカニズムでは、サーバーのみの認証または相互認証を選択することができ、メッセージの整合性、送信中の監視メッセージの暗号化が実現されています。サーバー認証(オブザーバに対するモニターの認証)は、SSLによって提供されます。クライアント認証(モニターに対するオブザーバの認証)はOPSによって提供されます。

サーバー認証には、モニターがアクセスできる正しく構成されたキー・ストアと、オブザーバがアクセスできる正しく構成されたトラスト・ストアが必要です。SSLを有効化するための設定を最小限にとどめるために、Business Transaction Managementはビルトインの事前構成済鍵およびトラスト・ストアを提供しています(構成済のサーバー証明書は、.NETベースのオブザーバにも提供されています)。デモ用、または開発環境には、ビルトインのセキュリティ・ストアで十分かもしれません。ただし、本番環境では、独自のセキュリティ・ストアを指定してセキュリティを強固にする必要があります。なお、これらのセキュリティ・ストアはHTTPS用のネットワーク・レベルのセキュリティ・ストアとは別であることに注意してください。

注意:

クライアント認証メカニズムは、完全にOPSに組み込まれています。いかなる環境でも、クライアント認証用にセキュリティ・ストアを提供する必要はありません。

デフォルトのオブザーバ通信ポリシーでは、監視メッセージ・チャネルがOPS/SSLを使用し、相互認証が必要となる(ビルトイン・セキュリティ・ストアがサーバー認証に使用されている)ように構成されます。独自のものでなくビルトイン・セキュリティ・ストアを使用し、Javaベースのオブザーバのみを使用する場合は、これらのデフォルト設定をそのまま使用することができます。その場合は、以降の構成を行う必要はありません。

サーバー認証に独自のセキュリティ・ストアを使用する場合は、ガイドとして次の手順を使用します。この手順では、自己署名証明書を含む独自のキー・ストアおよびトラスト・ストアの作成およびデプロイの方法を説明しています。

注意:

ビルトイン・セキュリティ・ストアを.NETベースのオブザーバとともに使用する場合は、手順4に飛び、.NETオブザーバをホストするマシンに事前構成済の証明書をデプロイします。事前構成済の証明書は、.NETベースのオブザーバを含むZIPファイルの中のnanoagent\config\ssl\server.cerにあります。

次の手順に従い、適切な証明書および秘密鍵を含むキー・ストアおよびトラスト・ストアを準備します。
1. JDKのkeytoolアプリケーションを探します。
2. 証明書-秘密鍵のペアを含むキー・ストアを生成します。
  
  たとえば、次のkeytoolコマンドによって、「mykeystore.ks」という名前のファイルに証明書-秘密鍵ペアを含むキー・ストアが生成されます。証明書-秘密鍵ペアの別名は「myks」、共通名は「MyMonitor」、アルゴリズムはRSA、証明書および秘密鍵へアクセスするパスワードは「mycertandprivkeypass」、キー・ストアにアクセスするパスワードは「mykeystorepass」です(ファイルが存在しない場合は、このコマンドによって作成されます)。
```
keytool -genkey -alias myks -dname "CN=MyMonitor" -keyalg RSA -keypass mycertandprivkeypass -storepass mykeystorepass -keystore mykeystore.ks
```
3. 証明書をキー・ストアから外部ファイルにエクスポートします。
  
  たとえば、次のkeytoolコマンドによって、上の例で作成した証明書が「mycertificate.cer」というファイルにエクスポートされます。
```
keytool -export -alias myks -storepass mykeystorepass -file mycertificate.cer -keystore mykeystore.ks
```
4. 証明書を(関連付けられた秘密鍵なしに)トラスト・ストアにインポートします。
  
  たとえば、次のkeytoolコマンドによって、上の例で作成した証明書がファイル「mytruststore.ks」に含まれるトラスト・ストアにインポートされます(トラスト・ストア・ファイルが存在していない場合は、このコマンドによって作成されます)。
```
keytool -import -v -trustcacerts -alias myks -file mycertificate.cer -keystore mytruststore.ks -keypass mycertandprivkeypass -storepass mykeystorepass
```
キー・ストアをモニターをホストするマシンにデプロイします。

キー・ストア(たとえば、mykeystore.ks)を、モニターをホストするマシンまたはモニターがHTTP GETでアクセスできる場所にコピーします。
トラスト・ストアをJavaベースのオブザーバをホストするマシンにデプロイします(Javaベースのオブザーバがない場合は、この手順は無視します)。

次の2つのいずれかの方法で実行します。
- トラスト・ストア(たとえば、mytruststore.ks)をオブザーバをホストするマシンまたはオブザーバがHTTP GETでアクセスできる場所のどちらかにコピーします。
- トラスト・ストア(たとえば、mytruststore.ks)をモニターをホストするマシンまたはモニターがHTTP GETでアクセスできる場所のどちらかにコピーします。この2つ目の方法を使用する場合、オブザーバ通信ポリシーを構成する際に(第8.5項を参照)「トラスト・ストアをJavaオブザーバへ自動ディスパッチ」フィールドを有効化することによって、モニターが自動的にトラスト・ストアをオブザーバにディスパッチするように構成できます。
証明書を.NETベースのオブザーバをホストするマシンにデプロイします(.NETベースのオブザーバがない場合は、この手順を無視します)。

Windowsの証明書インポート・ウィザードを使用して、証明書(たとえば、mycertificate.cer)を.NETベースのオブザーバをホストするマシンの証明書ストアの「Trusted Root Certification Authorities」フォルダにインポートします。

注意:

監視メッセージのSSL接続は、この項で選択したセキュリティ・ストアに対応する情報でオブザーバ通信ポリシーが構成されるまでは使用できません。オブザーバ通信ポリシーを構成する際には、この情報を参照用に準備しておく必要があります。その際に準備しておく必要がある情報の詳細は、第8.5項「オブザーバ通信ポリシーの適用」の手順4を参照してください。