Trading Partner Integration の紹介
|
 |
 |
|
ここでは、WebLogic Integration の Trading Partner Integration ソリューションのセキュリティの概念およびタスクについて説明します。内容は以下のとおりです。
WebLogic Integration の Trading Partner Integration のセキュリティの実装を始める前に、以下のドキュメントを必ずお読みください。
http://edocs.beasys.co.jp/e-docs/wli/docs81/deploy/secure.html
http://edocs.beasys.co.jp/e-docs/wls/docs81/secintro/index.html
http://edocs.beasys.co.jp/e-docs/wls/docs81/security.html
ここでは、WebLogic Integration の Trading Partner Integration のセキュリティ フレームワークについて説明します。内容は以下のとおりです。
WebLogic Integration は、WebLogic Server セキュリティ フレームワークの特定の機能を利用して、トレーディング パートナ統合のための機能を追加します。WebLogic Integration では、以下の機能を使用して、トレーディング パートナ間のセキュアなビジネス トランザクションをサポートしています。
WebLogic Integration のセキュリティは、WebLogic Server のセキュリティ フレームワーク、すなわちデフォルトのセキュリティ コンフィグレーションに基づきます。詳細については、『WebLogic Security の管理』(下記 URL) の「セキュリティ管理の概要」の「WebLogic Server のデフォルト セキュリティ コンフィグレーション」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs81/secmanage/overview.html
Trading Partner Integration の WebLogic セキュリティ モデルには、次の特長があります。
次の図は、Trading Partner Integration をサポートする WebLogic Server および WebLogic Integration のエンティティと機能を示します。
図 4-1 Trading Partner Integration の WebLogic セキュリティ モデル
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
WebLogic Platform の Configuration Wizard と WebLogic Integration テンプレートを使用して新しいドメインを作成すると、新しいドメインには、以下のようなデフォルトのセキュリティ設定が含まれます。
http://edocs.beasys.co.jp/e-docs/wls/docs81/secwlres/types.html
WebLogic Integration では、パスワード、プライベート キー、および証明書を格納するために、以下の資格ストアを用意しています。
パスワードはすべて、暗号化形式で PasswordStore に保管されます。WebLogic Integration では、クリアテキストのパスワードは不要です。PasswordStore は、JCE セキュリティ プロバイダを使用します。パスワードのコンフィグレーションは MBean API によって制御され、パスワードはパスワード エリアスを使用してアクセスされます。
PasswordStore 内のパスワードは、WebLogic Integration Administration Console で管理できます。詳細については、『WebLogic Integration ソリューションの管理』の「システム コンフィグレーション」にある、以下のトピックを参照してください。
WebLogic Integration では、すべてのプライベート キーと証明書をキーストアに格納する必要があります。キーストアは、キーおよび証明書を保持する、保護されたデータベースです。キーおよび証明書を使用して、メッセージを暗号化したり、デジタル署名や SSL を使用したりする場合は、それらのキーおよび証明書をキーストアに格納し、認証や署名の目的でキーおよび証明書を必要とするアプリケーションに対してキーストアを使用可能にしておく必要があります。
Trading Partner Integration 用に WebLogic Integration ドメインをセットアップすると、以下のキーストアがコンフィグレーションされます。
|
|
|
|
|
WebLogic Platform の Configuration Wizard と WebLogic Integration テンプレートを使用して新しいドメインを作成すると、新しいドメインには、JKS タイプのデモ キーストアが含まれます。これらのキーストアには、次の特長があります。
開発環境やテスト環境ではデモ キーストアを使用できますが、プロダクション環境の場合は、新しい ID と信頼キーストアを明示的に作成する必要があります。キーストアを作成し、Trading Partner Integration でこのキーストアを使用できるようにするには、以下の手順を実行します。
http://edocs.beasys.co.jp/e-docs/wls/docs81/secmanage/ssl.html
http://edocs.beasys.co.jp/e-docs/wls/docs81/secmanage/ssl.html
WebLogic Integration Administration Console でのキーストアのリフレッシュ方法については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「キーストアのリフレッシュ」を参照してください。
注意 : クラスタ化されたドメインでは、WebLogic サーバごとに独立したキーストアを作成およびコンフィグレーションする必要があります。
Trading Partner Integration リソース用として、次のようなセキュリティ ポリシーをコンフィグレーションできます。
bpmarchpoo と cgpool) および MBean詳細については、『WebLogic リソースのセキュリティ』(下記 URL) を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs81/secwlres/index.html
「転送レベルのセキュリティ」には、転送レベル (HTTP および HTTPS) での認証および暗号化と、エンドポイントでの認可が関与します。ここでは、Trading Partner Integration のための転送レベルのセキュリティの概念とタスクについて説明します。内容は以下のとおりです。
WebLogic Integration では、「認証」とは、システム エンティティによって宣言された ID、またはシステム エンティティに対して宣言された ID を検証するプロセスです。認証の対象は、エンティティが何者であるか、です。つまり、認証は、ID と エンティティとの関連付けです。WebLogic Integration では、TPM リポジトリに格納されているセキュリティ情報に基づいて、デジタル証明書を検証します。
Trading Partner Integration に関しては、WebLogic Integration は次の方法で認証を行います。
トレーディング パートナの認証は、トレーディング パートナ間の通信を定義するプロトコル バインディング内でコンフィグレーションされます。詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「プロトコル バインディングの定義」を参照してください。
SSL プロトコルは、ネットワーク接続を介してリンクされた 2 つのアプリケーションが相手の ID を認証できるようにすること、およびアプリケーション間で交換されるデータを暗号化することにより、セキュアな接続を実現します。SSL 接続では、まずハンドシェイクが行われます。ハンドシェイクでは、アプリケーション同士がデジタル証明書を交換し、使用する暗号化アルゴリズムについて合意し、そのセッションで使用する暗号化キーを生成します。
WebLogic Integration では、SSL プロトコルの以下のセキュリティ機能をサポートしています。
トレーディング パートナ間でビジネス メッセージを交換する際は、両方のタイプの認証を使用できます。さらに、管理者は Web ブラウザから HTTPS を使用して、WebLogic Integration Administration Console と WebLogic Server Administration Console にアクセスできます。
管理者は、Web ブラウザを使用して、WebLogic Integration Administration Console にアクセスできます。このタイプのネットワーク通信は、HTTPS (Hypertext Transfer Protocol with SSL) を使用することにより保護できます。SSL の詳細については、以下を参照してください。
WebLogic Integration は、以下のタイプの認証をサポートします。
Trading Partner Integration には、以下の 2 レベルの認証プロセスが組み込まれています。
WebLogic Integration リソースのエンドツーエンド アクセス制御 (認可) には、両方のレベルの認証が必要です。トレーディング パートナのビジネス メッセージが両方のレベルの認証に成功した後、Trading Partner Integration エンジンがそのビジネス メッセージに対して認可プロセスを実行します。Trading Partner Integration の各種リソースを保護するには、認可プロセスで少なくとも基本認証または相互認証を実行する必要があります。これらについては、「認証のタイプ」を参照してください。
デジタル証明書は、インターネットなどのネットワークを通じてプリンシパルやエンティティの一意の ID を検証するために使用される電子ドキュメントです。デジタル証明書は、ユーザまたはエンティティの ID を安全にバインドします。この安全性は、信頼性のある第三者機関 (認証局) が特定の公開鍵に対して検証します。公開鍵とプライベート キーを組み合わせることにより、デジタル証明書の所有者を一意に識別できます。
デジタル証明書は、特定の公開鍵が特定のユーザまたはエンティティに実際に帰属するという主張を裏付けることができます。デジタル証明書の受信者は、その証明書が、サブジェクトの公開鍵を含んでおり、信頼性のある認証局 (CA) によって発行および署名されたものであることを確認できます。受信者はこの確認を行うために、信頼性のある認証局の公開鍵を使用して、デジタル署名が認証局のプライベート キーで作成されていることを確認します。この確認が成功すれば、論理的なつながりとして、そのプライベート キーの所有者が、デジタル証明書で名前を指定されているサブジェクトであること、ならびに、デジタル署名がその認証局によって作成されたことが保証されます。
デジタル証明書は、ID キーストアに格納されます。詳細については、「プライベート キーと証明書のキーストア」を参照してください。
デジタル証明書には、以下のようなさまざまな情報が含まれています。
デジタル証明書のフォーマットとしては、ITU-T X.509 国際標準で定義されたものが最も広く使用されています。したがって、X.509 標準に準拠しているアプリケーションであれば、どのアプリケーションでも、デジタル証明書の読み書きが可能です。WebLogic Server の公開鍵インフラストラクチャ (PKI) は、X.509 バージョン 1 (X.509v1) またはバージョン 3 (X.509v3) に準拠するデジタル証明書を認識します。
デジタル証明書は、認証局が発行します。デジタル証明書と公開鍵を発行してその対象の身元を保証する機関または企業が認証局です。認証局は、デジタル証明書を作成するとき、プライベート キーを使用して証明書に署名します。これにより、改ざんを確実に検出できます。その後、認証局は、署名したデジタル証明書を要求元のサブジェクトに返します。
サブジェクトは、発行元の認証局の署名を、認証局の公開鍵を使用して確認できます。認証局は、自身の公開鍵を使用可能にするために、上位の認証局から発行されたデジタル証明書を提供します。この証明書は、下位の認証局の公開鍵の有効性を保証するものです。この認証局の階層は、ルート証明書と呼ばれる自己署名デジタル証明書で終端します。この様子を次の図で示します。
デジタル証明書を使用したり、デジタル署名を検証したり、ビジネス メッセージを復号化したりするためには、デジタル証明書の発行元が信頼性のある認証局であることを確認する必要があります。ビジネス メッセージを誰が暗号化したかにかかわらず、ビジネス メッセージのデジタル証明書は信頼性のあるものである必要があり、またそのことが認証局によって立証されなければなりません。
WebLogic Integration では、以下のタイプの証明書を Trading Partner Integration でサポートしています。
|
|
|
|
|
|
|
|
|
|
|
トレーディング パートナ証明書のコンフィグレーションについては、以下の一般ルールに注意してください。
デジタル証明書に関するコンフィグレーション要件は、ローカル トレーディング パートナとリモート トレーディング パートナとで異なります。
ローカル トレーディング パートナについては、サーバ証明書をコンフィグレーションしません。SSL を使用して相互認証を行う場合は、クライアント証明書、暗号化証明書、および署名証明書が必要です。これらすべての証明書は、関連付けられているプライベート キーを必要とします。証明書内でキーがこれらの機能に対応するように設定されている限り、同じ証明書とプライベート キーのペアを使用できます。
デジタル証明書のコンフィグレーションは、WebLogic Integration Administration Console で行います。デジタル証明書は、ID キーストアに格納されます。デジタル証明書をコンフィグレーションするためには、トレーディング パートナを TPM リポジトリで定義し、ID キーストアをコンフィグレーションする必要があります。詳細については、「プライベート キーと証明書のキーストア」を参照してください。
詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある、以下のトピックを参照してください。
注意 : トレーディング パートナ証明書をキーストアにロードする際、WebLogic Integration では、信頼性のある認証局に基づくトレーディング パートナ証明書の検証を行いません。
「認証レベル」での説明のとおり、トレーディング パートナの証明書が WebLogic Server によって検証された後は、Trading Partner Integration エンジンでトレーディング パートナ メッセージが認証されない限り、そのメッセージ自体がサービスを受けることはできません。トレーディング パートナ メッセージの認証処理には、ビジネス メッセージの送信者が有効なトレーディング パートナとして TPM リポジトリにリストされていることの確認が含まれます。トレーディング パートナ メッセージが認証されると、そのメッセージの処理プロセスで、そのトレーディング パートナの ID が認識され、コンフィグレーション済みポリシーに基づいて Trading Partner Integration の各種リソースへのアクセスが許可されます。
次の図は、トレーディング パートナ メッセージを認証するプロセスを表しています。
ここでは、リモート トレーディング パートナ の ID と WebLogic Server ユーザとの間の関連付けを検出するのに役立つ TPMUserNameMapper クラスの使用方法について説明します。
注意 : TPMUserNameMapper は、双方向認証にのみ適用されます。別の認証メカニズムを使用してデプロイメントを行う場合は、このセクションをスキップできます。
注意 : TPMUserNameMapper は、「リモート」トレーディング パートナにのみ適用されます。ローカル トレーディング パートナには適用されません。ローカル トレーディング パートナをコンフィグレーションする場合は、そのトレーディング パートナに WebLogic Server ユーザ名を付ける必要はありません。
TPMUserNameMapper クラスは、リモート トレーディング パートナの ID と WebLogic Server ユーザとの間の関連付けを検出するのに役立ちます。WebLogic Integration でトレーディング パートナ プロファイルをコンフィグレーションする際、そのプロファイルにバインドするトレーディング パートナ名も指定します。WebLogic Integration Administration Console で、ユーザとトレーディング パートナを関連付けるには、WebLogic Server ユーザ名であるトレーディング パートナ ユーザ名を指定します。
実行時、WebLogic Server が、そのトレーディング パートナのデジタル証明書をトレーディング パートナ ユーザにマップします。この動作を次の図に示します。
図 4-4 WebLogic Server ユーザへのトレーディング パートナ証明書のマッピング
相互認証が使用されている場合 (web.xml 内の CLIENT-CERT と SSL が WebLogic Server での相互認証向けにコンフィグレーションされている場合)、TPMUserNameMapper は、以下のように 2 つの仕組みを使用して、ユーザ マッパーに対する証明書を検索します。トレーディング パートナ メッセージがリモート トレーディング パートナから WebLogic Server に到着すると、SSL ハンドシェイクの完了直前に TPMUserNameMapper が起動します。TPMUserNameMapper はまず、TPM リポジトリで、リモート トレーディング パートナのクライアント証明書のフィンガープリントを使用して、トレーディング パートナ と WebLogic Server ユーザとの関連付けを探します。見つからない場合は、クライアント証明書の属性を WLS ユーザにマッピングしようとします。
WebService/SOAP、ebXML、RosettaNet の各プロトコルが WebLogic Integration 内で同じ UserNameMapper を使用できるようにするためには、TPMUserNameMapper を使用するよう、WebLogic Server 内で DefaultIdentityAsserter 設定をコンフィグレーションする必要があります。
TPMUserNameMapper をコンフィグレーションするには
com.bea.b2b.security.TPMUserMapper クラスは、WebLogic Server の weblogic.security.providers.authentication.UserNameMapper インタフェースを実装します。必要であればこの API の独自の実装を作成することも可能ですが、TPMUserNameMapper クラスを使用しても同様に、TPM リポジトリにアクセスすることができます。詳細については、UserNameMapper (下記 URL) を参照してください。
http://edocs.bea.com/wls/docs81/javadocs/weblogic/security/providers
/authentication/UserNameMapper.html
WebLogic Integration でトレーディング パートナのデジタル証明書を検証するには、証明書検証プロバイダ (CVP) を使用します。Trading Partner Integration セキュリティ フレームワークは、サードパーティ サービスを呼び出してトレーディング パートナ証明書を検証する SPI を実装する Java クラスを挿入できるサービス プロバイダ インタフェース (SPI) を備えています。証明書検証プロバイダと呼ばれるこのような実装は、以下のいずれかの証明書検証アプリケーションを呼び出すことができます。
証明書検証プロバイダ (CVP) を使用する場合は、これを WebLogic Integration Administration Console でコンフィグレーションする必要があります。これについては、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「証明書検証プロバイダの指定」を参照してください。
トレーディング パートナ証明書検証の目的は、トレーディング パートナのデジタル証明書を検証することです。たとえば、証明書の検証では、以下のタスクの一部またはすべてを行います。
CVP 実装をコンフィグレーションして使用することは必須ではありませんが、そうすることにより、証明書検証プロセスにおけるセキュリティのレベルを高めることができます。
WebLogic Integration では、以下の場合に CVP を使用します。
次の図は、SSL と相互認証を使用する着信メッセージに対する WebLogic Integration の証明書検証プロセスで発生するイベントのシーケンスの例です。
図 4-5 WebLogic Integration のトレーディング パートナ証明書検証
証明書検証プロバイダ (CVP) の Java クラスは、com.bea.wli.security.verification.CertificateVerificationProvider インタフェースを実装する必要があります。CVP クラスが何を呼び出せるかについては、次の 2 つの選択肢があります。
どれを選択するかにかかわらず、実際に証明書検証を実行するアプリケーションを呼び出す CVP SPI の Java 実装を作成する必要があります。この CVP アプリケーションを作成、コンパイル、コンフィグレーションする方法について、この後に説明します。
Trading Partner Integration では、CVP サービス プロバイダ インタフェース (SPI) を提供する com.bea.wli.security.verification.CertificateVerificationProvider インタフェースを使用して CVP を実装できます。ここで説明する SPI を使用して CVP を実装または使用する場合は、後でその CVP を WebLogic Integration Administration Console でコンフィグレーションして、実行時に正しく呼び出されるようにする必要があります。
com.bea.wli.security.verification.CertificateVerificationProvider インタフェースには、以下のメソッドがあります。CVP アプリケーションはこれらを実装する必要があります。
void init()このメソッドは、Trading Partner Integration エンジンによって自動的に呼び出され、このインタフェースを実装する、ユーザが作成したクラス内で、カスタム初期化プロセスを起動します。このメソッドは、WebLogic Integration の起動時に一度だけ呼び出されます。
String verify(Certificate[] certs)注意 : CVP を実装する場合は、CVP 用のデフォルトのパブリック コンストラクタを引数なしで追加する必要があります。このコンストラクタもクラス内のどのメソッドも例外を送出しません。
CVP をコンフィグレーションしない場合は、信頼性のある認証局で発行されたすべての証明書が、Trading Partner Integration エンジンによって、有効と見なされます。
CVP を実装する場合は、CVP Java クラスを作成した後に、それをコンパイルして、システム CLASSPATH に配置する必要があります。
WebLogic Integration Administration Console または Bulk Loader ユーティリティを使用して、CVP をコンフィグレーションする必要があります。CVP をコンフィグレーションした後、WebLogic Server を再起動すると、CVP が有効になります。CVP をコンフィグレーションしない場合は、信頼性のある認証局で発行されたすべての証明書が、Trading Partner Integration エンジンによって、有効と見なされます。
CVP のコンフィグレーションは、WebLogic Integration Administration Console で行います。詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「証明書検証プロバイダの指定」を参照してください。
CVP をコンフィグレーションした後、WebLogic Server を再起動すると、CVP が有効になります。
注意 : WebLogic Integration を反復型開発モードで実行しているときは、セキュリティ検証設定はアクティブになりません。開発モード中は CVP だけがアクティブになります。
認可では、以下のような Trading Partner Integration リソースに対してアクセスが許可されているかどうかが判定されます。
bpmarchpoo と cgpool) および MBeanトレーディング パートナ リソースにアクセスするためのパーミッションは、ポリシーとロールに基づいて割り当てられます。つまり、保護の必要があるリソースについては、そのセキュリティ ポリシーがロールに基づいて定義されます。したがって、個々のユーザやエンティティは、それぞれが属するロールに基づいてアクセス権を取得できます。認証は、エンティティが「誰」なのか (つまり、ID とエンティティとの関連付け) を問題にしますが、認可は、その ID が何を見て、何をすることが「できる」かを問題にします。
注意 : 認可は、基本認証、一方向基本認証、および相互認証で利用できます (必須ではありません)。
トレーディング パートナ統合については、次の 2 レベルの認可が WebLogic Integration に組み込まれています。
WebLogic Server は、トレーディング パートナの認可を実行します。トレーディング パートナのメッセージが WebLogic Server に到着し、トレーディング パートナと WebLogic Server が相互認証または基本認証 (ユーザ名とパスワード) の手続きを完了すると、Transport Servlet Filter へのアクセスの認可が WebLogic Server によって実行されます。
B2BDefaultWebApp をコンフィグレーションする場合は、WebLogic Server Administration Console で、URL へのアクセスに関して B2BDefaultWebApp に対するポリシーを設定する方法をお勧めします。手順については、『WebLogic リソースのセキュリティ』の「WebLogic リソースのタイプ」(下記 URL) の「URL (Web) リソースおよび EJB (エンタープライズ JavaBean) リソース」を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs81/secwlres/types.html
IB2BDefaultWebApp のコンフィグレーションだけでなく、同様にコンフィグレーションを必要とする他の Trading Partner Integration リソースもコンフィグレーションできます。たとえば、TPM リポジトリ、WebLogic Workshop ビジネス プロセス、JMS 送り先などへのアクセスで使用される JDBC 接続プールや MBean をコンフィグレーションできます。詳細については、「認可」を参照してください。
Trading Partner Integration エンジンがサービス認可を実行すると、サーバは、トレーディング パートナのビジネス メッセージの内容を、そのトレーディング パートナがバインドされているサービス プロファイルに基づいて検査します。つまり、トレーディング パートナは、1 つのサービス プロファイルについて、ある特定のセットのビジネス メッセージだけを送信することができます。Trading Partner Integration エンジンは、特定のサービスのサービス プロファイルで指定されている以下の情報に基づいて、ビジネス メッセージを検証します。
着信ビジネス メッセージに対するサービス認可が完了すると、WebLogic リソース ポリシーによって、B2B リソースへのアクセスが指示されます。
「メッセージレベルのセキュリティ」には、個々のビジネス メッセージのデジタル署名、暗号化、および否認防止性が含まれます。ここでは、Trading Partner Integration のためのメッセージレベルのセキュリティの概念とタスクについて説明します。内容は以下のとおりです。
デジタル署名を使用すると、ビジネス メッセージの改ざんを防ぐことができます。暗号化を行うと、メッセージのプライバシを確保できます。否認防止性を使用すると、トレーディング パートナが、以前に他のトレーディング パートナと特定のビジネス メッセージをやりとりしたことを立証または反証できます。
メッセージレベルのセキュリティは、トレーディング パートナ間の通信を定義するプロトコル バインディング内でコンフィグレーションされます。詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「プロトコル バインディングの定義」を参照してください。
「デジタル署名」は、特にビジネス メッセージがトレーディング パートナ間で送信されているときに起こりうる、何者か、または何物かによるビジネス メッセージの内容の改ざんを防ぐ手段です。WebLogic Integration は、署名を検証した後に、証明書検証プロバイダを使用します (双方向認証がコンフィグレーションされている場合)。これについては、「双方向認証でのリモート ユーザの認証」を参照してください。デジタル署名は、否認防止性に必要です。これについては、「否認防止性」を参照してください。
WebLogic Integration は、以下のタイプのデジタル署名をサポートします。
注意 : ebXML MS 1.0 を使用して WLI Business Connect から ebXML メッセージを受信しているときは、XML デジタル署名は使用できません。ebXML MS 2.0 を使用する必要があります。
デジタル署名自体は、ビジネス メッセージの末尾に付加された一組のデータであり、特定のフォーマット (たとえば、PKCS7 SignedData や XMLDSIG 署名) でパッケージ化されたデータの、暗号化された一方向ハッシュ値で構成されます。デジタル署名には、次の特長があります。
デジタル署名の作成に必要なデータは、TPM リポジトリにあるトレーディング パートナのコンフィグレーション データから取得されます。デジタル署名の作成には、以下の情報も必要です。
トレーディング パートナ間の通信を定義するプロトコル バインディングにおいて、ビジネス メッセージに署名するかどうかをコンフィグレーションできます。詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「プロトコル バインディングの定義」を参照してください。
WebLogic Integration は、署名を検証した後、証明書検証プロバイダ (CVP) を呼び出します。これについては、「証明書検証プロセス」を参照してください。
WebLogic Integration は、トレーディング パートナ間の ebXML 1.0 および ebXML 2.0 メッセージ交換のための XMLDSig をサポートしています。
WebLogic Integration は、以下の XMLDSig 機能をサポートしています。
XMLDSig の詳細については、下記 URL の W3C Web サイトの「XML-Signature Syntax and Processing」を参照してください。
http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/Overview.html
WebLogic Integration では、XMLDSig のアルゴリズムとして以下のものを使用しています。
WebLogic Integration では、RosettaNet 1.1 および 2.0 に対して、PKCS7 エンベロープ データによるデジタル署名をサポートしています。
WebLogic Integration では、RosettaNet 1.1 および 2.0 のデジタル署名用として、PKC7 エンベロープ データをサポートしています。マルチパート メッセージのデジタル署名は、以下のものに適用されます。
WebLogic Integration では、以下の PKC7 エンベロープ データ アルゴリズムをサポートしています。
「否認防止性」は、関与を否認するパーティの関与を法的に立証する機能です。この機能は、重要なビジネス メッセージの法的要件です。否認防止性は、トレーディング パートナが、以前に他のトレーディング パートナと特定のビジネス メッセージをやりとりしたことを立証または反証できる機能です。WebLogic Integration は、以下の否認防止性をサポートしています。
否認防止性は、トレーディング パートナ間の通信を定義するプロトコル バインディング内でコンフィグレーションされます。詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「プロトコル バインディングの定義」を参照してください。
トレーディング パートナ A が、トレーディング パートナ B から人工学に基づく椅子を 1000 脚購入することで、トレーディング パートナ B と合意しました。この合意の過程で、トレーディング パートナ A は椅子を指定価格で購入することに同意するビジネス メッセージをトレーディング パートナ B に送信しました。しかし、後になってトレーディング パートナ A は、最初に決めた価格に異議を唱え、その価格での支払に両者が合意したメッセージを送信したことを否認しました。
信頼性のある否認防止性システムが設置されていれば、トレーディング パートナ B は、トレーディング パートナ A が支払に同意した価格を明示している、トレーディング パートナ A からのドキュメントを出力することによって、トレーディング パートナ A の主張を反証することができます。さらに、そのオリジナルのドキュメントが、信頼性のあるサードパーティ ソースによってデジタル的に署名され、タイムスタンプを付加され、記録され、セキュリティ保護されていれば、そのドキュメントは法的に完全に有効です。
WebLogic Integration は、否認防止性をサポートするために、以下のサービスを提供します。
デジタル署名は、特にビジネス メッセージがトレーディング パートナ間で送信されているときに起こりうる、何者か、または何物かによるビジネス メッセージの内容の改ざんを防ぐ手段となるため、否認防止性には不可欠です。詳細については、「デジタル署名」を参照してください。
「セキュアな監査ログ」は、概して、各ビジネス メッセージをデジタル署名およびセキュアなタイムスタンプとともに保管します。これにより、トレーディング パートナは、他のトレーディング パートナとのビジネス メッセージの交換中に発生したメッセージや他のシステム イベントの順序を、交換したデータとともに再構成できます。したがって、セキュアな監査ログは否認防止性に不可欠です。
デフォルトの監査ログ プロバイダ (com.bea.wli.security.audit.DefaultAuditLogProvider) は、secureaudit.log というファイルにログを保存します。このファイルは、ロギング サブシステムをベースとし、基本となるオペレーティング システムのファイル パーミッション システムによってのみ保護されます。このファイルは、デジタル的に署名されたり、暗号化されたりしません。このファイルはデモ用途または開発用途にのみ使用します。プロダクション環境には使用しないでください。
監査ログの有効/無効の切り替え、および監査ログ クラスの指定は、WebLogic Integration Administration Console で行います。詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「セキュアな監査ログのコンフィグレーション」を参照してください。
ログ メッセージはすべて、各メッセージ タイプの内容を定義する DTD log-message.dtd に対応します。
すべての監査ログ メッセージに、以下の 3 つの識別子が含まれます。
次の表は、各メッセージ タイプのデータの内容についての説明です。すべてのログ メッセージに、WebLogic Integration でコンフィグレーションされているタイムスタンプ プロバイダから取得したタイムスタンプが含まれます。
以下のコードは、log-message.dtd ファイルの例です。
コード リスト 4-1 log-message.dtd ファイルの例
<!ELEMENT LOG (起点の否認防止性 | 受信の否認防止性 | アプリケーション)>
<!ATTLIST LOG タイムスタンプ CDATA #REQUIRED >
<!ATTLIST LOG 場所 CDATA #IMPLIED >
<!ATTLIST LOG プリンシパル CDATA #IMPLIED >
<!ELEMENT 起点の否認防止性 (#PCDATA)>
<!ELEMENT 受信の否認防止性 (#PCDATA)>
<!ELEMENT アプリケーション (#PCDATA)>
Trading Partner Integration エンジンが提供するサービス プロバイダ インタフェース (SPI) を使用して、信頼性のある、セキュアな監査ログのサードパーティ プロバイダをコンフィグレーションできます。信頼性のあるサードパーティ プロバイダのセキュアな監査ログ サービスを組み込むには、com.bea.wli.security.audit.AuditLogProvider インタフェースを実装するクラスを作成する必要があります。作成したクラス (たとえば、log) のメソッドで、サードパーティ監査ログ プロバイダを呼び出します。
注意 : ここで説明する SPI を使用して監査ログサービスを実装する場合は、後でそのサービスを WebLogic Integration Administration Console でコンフィグレーションして、実行時に正しく呼び出されるようにする必要があります。
com.bea.wli.security.audit.AuditLogProvider インタフェースには、以下のメソッドがあります。セキュアな監査ログ アプリケーションはこれらを実装する必要があります。
void init()void log (java.lang.String component,
java.lang.String type,
byte[] data,
java.lang.String principal)セキュアな監査インタフェースの実装には、デフォルトのパブリック コンストラクタを引数なしで含める必要があります。このコンストラクタも、AuditLogProvider インタフェースを実装するクラス内のどのメソッドも、例外を送出しません。
監査ログに書き込むアプリケーションを呼び出す com.bea.wli.security.audit.AuditLogProvider インタフェースの Java 実装を作成する代わりに、com.bea.wli.security.audit.Audit.log(byte[] data) メソッドを呼び出して監査ログに直接書き込むアプリケーションを作成できます。ビジネス プロセスでのコード例を以下に示します。この例で、太字のコードは、監査ログへの書き込みを表示するために追加された文を示します。
package orderprocessing;
import com.bea.jpd.JpdContext;
import com.bea.xml.XmlObject;
import com.bea.data.MessageAttachment;// WLI セキュリティ パッケージ インポート/**
com.bea.wli.security.audit.Audit から Audit クラスをインポートする;
* @jpd:process process::
* <process name="ServerBuyer">
* <clientRequest name="Receive order request from client" method="start"/>
* <controlSend name="Send PO to enterprise server seller"
method="sendOrder"/>
* <controlReceive name="Receive PO receipt from enterprise server seller"
method="orderService_onMessage"/>
* <clientCallback name="sendAck" method="sendAck"/>
* </process>::
*
*/
public class EnterpriseServerBuyer implements com.bea.jpd.ProcessDefinition
{
public com.bea.tutorial.b2B.order.OrderDocument pcOrder;
/**
* @jc:ebxml ebxml-service-name="SecureOrderService" from="BEA-IT-id" to="SUN-id" ebxml-action-mode="default"
* @common:control
*/
private SecureOrderServiceControl orderService;
/**
*@common:context
*/
JpdContext context;
public void start( String str )
{
//create an order
pcOrder = ...
}
public void sendOrder()
{
//#START: CODE GENERATED - PROTECTED SECTION - このメソッドのこのコメントより前であれば、安全にコードを追加できる。#//
// トランスフォームを入力する
// メソッド コール
orderService.sendOrder(pcOrder);
// トランスフォームを入力する
// 割り当てを出力する
//#END : CODE GENERATED - PROTECTED SECTION - このメソッドのこのコメントより後であれば、安全にコードを追加できる。#//
}
public void orderService_onMessage(MessageAttachment[] reply)
{
//応答で、タイプ XmlObject のオブジェクトを 1 つだけ想定する
XmlObject xo = reply[reply.length - 1].getXmlObject();
if(Audit.isEnabled()) {
Audit.log(xo.toString().getBytes());
}
}
public Callback callback;
public interface Callback {
public void onAck(String reply);
}
void sendAck() {
callback.onAck("This is an ACK from ServerBuyer.jpd.");
}
}
セキュアなタイムスタンプ サービスは、セキュアな監査ログにビジネス メッセージも記録されるときに、UTC (Coordinated Universal Time: 協定世界時) タイムスタンプをセキュアな監査ログに付加して、時刻と日付の情報の正確性を保ちます。そのため、「タイムスタンプ プロバイダ」は否認防止性に不可欠です。
たとえば、トレーディング パートナがビジネス メッセージを受信すると、受信の否認防止性 (NRR) メッセージとしてタイムスタンプが監査ログに入力されます。また、トレーディング パートナがビジネス メッセージを送信すると、起点の否認防止性 (NRO) メッセージとしてタイムスタンプが監査ログに入力されます。
タイムスタンプ プロバイダのコンフィグレーションは、WebLogic Integration Administration Console で行います。詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「セキュアな監査ログのコンフィグレーション」を参照してください。
Trading Partner Integration エンジンでは、複数のセキュアなタイムスタンプ プロバイダが WebLogic Integration に登録されることを禁止しています。この制限により、WebLogic Integration で作成されたタイムスタンプはすべて、時間の経過順に並びます。
注意 : セキュアなタイムスタンプ サービス プロバイダを WebLogic Integration にコンフィグレーションしない場合、デフォルトのログ プロバイダが使用されていれば、タイムスタンプ システム イベントおよび署名にシステム時刻が使用されます。
Trading Partner Integration に含まれるサービス プロバイダ インタフェース (SPI) を使用すると、信頼性のあるサードパーティ プロバイダのセキュアなタイムスタンプ サービスを組み込むことができます。
信頼性のあるサードパーティ プロバイダのセキュアなタイムスタンプ サービスを組み込むには、com.bea.wli.security.time.TimestampProvider インタフェースを実装する Java クラスを作成する必要があります。com.bea.wli.security.time.TimestampProvider インタフェースを実装するクラスのメソッド (たとえば、getTimestamp) 内で、サードパーティ タイムスタンプ プロバイダを呼び出します。
Trading Partner Integration では、com.bea.wli.security.time.TimestampProvider インタフェースを実装することにより、カスタマイズした、セキュアなタイムスタンプ サービスを作成できます。 ここで説明する SPI を使用してタイムスタンプを実装する場合は、後でそのサービスを WebLogic Integration Administration Console でコンフィグレーションして、実行時に正しく呼び出されるようにする必要があります。
com.bea.wli.security.time.TimestampProvider インタフェースには、以下のメソッドがあります。タイムスタンプ アプリケーションはこれらを実装する必要があります。
タイムスタンプ インタフェースの実装には、デフォルトのパブリック コンストラクタを引数なしで含める必要があります。このコンストラクタも、TimeStampProvider インタフェースを実装するクラス内のどのメソッドも、例外を送出しません。
WebLogic Integration では、暗号化を必要とするビジネス プロトコルのビジネス メッセージを暗号化できます。この WebLogic Integration リリースでは、RosettaNet 2.0 に対してのみ、メッセージ暗号化をサポートしています。
注意 : メッセージを暗号化するには、暗号化サービスを使用するための有効なライセンスが必要です。
次の図は、公開鍵とプライベート キーを使用してデータの暗号化が実行される様子を表したものです。
図 4-6 Trading Partner Integration でのメッセージ暗号化
データ暗号化は、送信者の証明書、プライベート キー、および受信者の証明書を組み合わせてビジネス メッセージをエンコードすることにより行われます。暗号化されたメッセージは、受信者が受信者のプライベート キーを使用することによってのみ復号化できます。
注意 : WebLogic Integration では、暗号化はライセンス (Encryption/Domestic または Encryption/Export) で管理されますが、ビジネス メッセージの復号化はそうではありません。Trading Partner Integration エンジンでは、有効な暗号化ライセンスがない場合、暗号化サービスは無効化されます。ただし、受信したビジネス メッセージはいつでも復号化できます。
WebLogic Integration のメッセージ暗号化サービスは、以下のアルゴリズムをサポートしています。
トレーディング パートナ間の通信を定義するプロトコル バインディングでのビジネス メッセージの暗号化の有効/無効の切り替えは、WebLogic Integration Administration Console で行います。詳細については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「プロトコル バインディングの定義」を参照してください。
ここでは、Trading Partner Integration でプロキシ サーバを使用する方法を説明します。内容は以下のとおりです。
高度なセキュリティで保護する必要のある環境で WebLogic Integration を使用する場合、WebLogic Integration をプロキシ サーバの後ろで使用すると効果的です。プロキシ サーバを使用することにより、セキュリティで妥協せずに、トレーディング パートナ同士がイントラネットやインターネットを経由して通信できます。プロキシ サーバは、以下の用途で使用されます。
ローカル ネットワーク上にプロキシ サーバを構成すると、ネットワーク トラフィックは、プロキシ サーバを経由して、あるいはプロキシ サーバに委託して外部ネットワークに出ていきます。次の図は、WebLogic Integration 環境でのプロキシ サーバの使用方法の例を示しています。
WebLogic Integration Administration Console でプロキシ サーバをコンフィグレーションする方法については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」の「プロキシ ホストのコンフィグレーション」を参照してください。
注意 : プロキシ サーバをコンフィグレーションするには、WebLogic Server の ssl.proxyHost および ssl.proxyPort システム プロパティを読み書きするパーミッションの追加も必要です。これらのシステム プロパティは、weblogic.policy ファイルに格納されます。このファイルは、WebLogic Server をインストールしたディレクトリにあります。weblogic.policy ファイルの grant セクションに以下の行を追加してください。
permission java.util.PropertyPermission "ssl.proxyHost", "read, write";
permission java.util.PropertyPermission "ssl.proxyPort", "read, write";
さらに、次の WebLogic Web Server システム プロパティを指定する必要があります。
-http.proxyHost (プロキシ サーバが SSL を経由するようにコンフィグレーションされている場合)
-http.proxyPort
-https.proxyHost -https.proxyPort (プロキシ サーバが SSL を経由するようにコンフィグレーションされている場合)
プロキシと通信するための認証情報は、weblogic.common.ProxyAuthenticator インタフェースを使用して取得されます。詳細については、Interface ProxyAuthenticator(http://edocs.bea.com/wls/docs81/javadocs/weblogic/common/ProxyAuthenticator.html) を参照してください。
リモート トレーディング パートナからのビジネス メッセージを処理するようにプログラムされた、Apache サーバなどの Web サーバで WebLogic Integration をコンフィグレーションできます。Web サーバは、以下のサービスを提供できます。
Web サーバで WebLogic プロキシ プラグインを使用して、以下のサービスが提供されるようにコンフィグレーションできます。
次の図は、Web サーバ、WebLogic プロキシ プラグイン、および WebLogic Integration を使用する環境のトポロジを表します。
図 4-8 Web サーバと WebLogic プロキシ プラグインの使用
WebLogic プロキシ プラグインを使用する場合は、以下の点に注意してください。
Web サーバーをコンフィグレーションする方法については、『WebLogic Server のコンフィグレーションと管理』の「Web Server の Web サーバ機能のコンフィグレーション」(下記 URL) を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs81/adminguide/web_server.html
次のコード例は、プロキシ プラグインのコンフィグレーションに必要な httpd.conf (Apache サーバ用) の一部です。
# LoadModule foo_module libexec/mod_foo.so
LoadModule weblogic_module libexec/mod_wl_ssl.extension
<Location /weblogic>
SetHandler weblogic-handler
PathTrim /weblogic
WebLogicHost myhost
WebLogicPort 80
</Location>
extension は、Unix でのインストールで使用されるファイルの拡張子です。
開発用途およびテスト用途では、WebLogic Platform の Configuration Wizard を使用して新しい WebLogic Integration ドメインを作成したときに生成された、デフォルトのセキュリティ コンフィグレーションを使用します。詳細については、「デフォルトのドメイン セキュリティ コンフィグレーション」を参照してください。
プロダクション環境については、デプロイメントの一環としてセキュリティをコンフィグレーションする必要があります。ここでは、実行する必要があるタスクの概要を示します。内容は以下のとおりです。
デフォルトのセキュリティ レルムで定義されているユーザ、グループ、およびロールを管理するには、WebLogic Integration Administration Console の「ユーザ管理」モジュールを使用します。WebLogic Integration Administration Console でユーザ、グループ、およびロールをコンフィグレーションする手順については、『WebLogic Integration ソリューションの管理』の「ユーザ管理」を参照してください。
ビジネス メッセージの交換相手のトレーディング パートナのプロファイルをコンフィグレーションする必要があります。トレーディング パートナ プロファイルの概要については、「トレーディング パートナ プロファイル」を参照してください。WebLogic Integration Administration Console でのトレーディング パートナ プロファイルのコンフィグレーション手順については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
証明書およびプライベート キーの ID と信頼キーストアを作成およびコンフィグレーションする必要があります。キーストアの概要については、「プライベート キーと証明書のキーストア」を参照してください。キーストアを作成およびコンフィグレーションする手順については、以下のトピックを参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs81/secmanage/ssl.html
http://edocs.beasys.co.jp/e-docs/wls/docs81/secmanage/ssl.html
トレーディング パートナにデジタル証明書を追加する必要があります。証明書の概要については、「デジタル証明書」を参照してください。WebLogic Integration Administration Console でのトレーディング パートナ プロファイルのコンフィグレーション手順については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
WebLogic Server Administration Console で、転送レベルのセキュリティについて SSL をコンフィグレーションする必要があります。概要については、「SSL プロトコル」を参照してください。コンフィグレーション手順については、『WebLogic Security の管理』の「SSL のコンフィグレーション」(下記 URL) を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs81/secmanage/ssl.html
メッセージ交換で使用する転送レベルおよびメッセージ レベルのセキュリティ オプションを決定する必要があります。次に、それらのオプションを、各トレーディング パートナのサービス プロファイルにコンフィグレーションする必要があります。たとえば、あるトレーディング パートナとは相互認証を使用し、別のトレーディング パートナとは基本認証を使用することが可能です。同様に、顧客やベンダに対しては否認防止性を実装し、自社内のトレーディング パートナに対しては実装しないようにできます。
WebLogic Integration Administration Console でのサービス プロファイルの管理手順については、『WebLogic Integration ソリューションの管理』の「トレーディング パートナ管理」にある以下のトピックを参照してください。
The WebLogic Platform ドキュメント セットには、さまざまなセキュリティ関連トピックが含まれています。これらのトピックの一覧については、『WebLogic Platform 8.1 のセキュリティ』の 「詳細情報の入手」節 (http://edocs.beasys.co.jp/e-docs/platform/docs81/secintro/info.html) に記載されている「WebLogic Platform セキュリティ ドキュメントのトピック」の表を参照してください。
セキュリティに関する最新の勧告を常に通知し、セキュリティ関連パッチが入手可能になったときにただちにアクセスできるようにするために、BEA では、次の URL で「BEA Advisories Notifications」ページを管理しています。
http://dev2dev.bea.com/advisories
WebLogic Platform 8.1 またはそのコンポーネントで発生する可能性があるセキュリティ上の問題を発見した場合は、secalert@bea.com (US) に報告をお願いします。
BEA dev2dev Web サイトには、以下を含むさまざまなセキュリティ固有のリソースへのリンクを提供する Web ページが用意されています。
dev2dev Web サイトで推奨されているセキュリティ関連トピックのリストについては、以下を参照してください。
http://dev2dev.bea.com/products/wlplatform81/security.jsp
dev2dev サイトには、BEA WebLogic Platform とその他の BEA 製品に関してよく聞かれる質問 (FAQ) に対する答えを示す Web ページも含まれています。サイトは毎月更新されます。dev2dev FAQ ページにアクセスするには、次のリンクをクリックします。
|
|
|
