WebSphere Application Server - Express for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

Secure Sockets Layer を使用したセキュア通信

Secure Sockets Layer (SSL) プロトコルは、WebSphere Application Server を使用するサーバーと クライアント間のセキュア接続のために、認証性、データ署名、およびデータの暗号化を含む トランスポート層セキュリティーを提供します。SSL の基礎技術は、公開鍵暗号方式 です。これは、あるエンテ ィティーが秘密鍵を使用してデータを暗号化した場合、これに対応する公開鍵を持つエンティティーのみがそのデータの 暗号化解除をできることを保証するものです。

WebSphere Application Server では、セキュア接続の SSL 実装として、Java Secure Sockets Extension (JSSE) を使用しています。 JSSE は Java 2 Standard Edition (J2SE) 仕様の一部であり、Java Runtime Extension (JRE) の IBM 実装に含ま れます。JSSE は、SSL によって提供さ れるハンドシェーク・ネゴシエーションと保護機能を処理し、ほとんどのプロトコル全体でセキュアな接続が存在するよ うにします。 JSSE では、セキュア接続の保護とデータ暗号化の一部について、X.509 証明書ベースの非対称の鍵ペアを信頼します。 鍵ペアは、より大きなデータ・ブロックを暗号化するセッション・ベースの秘密鍵を、効果的に暗号化します。 SSL 実装は X.509 証明書を管理します。

X.509 証明書の管理

WebSphere Application Server のセキュアな通信には、デジタル署名 を使用した X.509 証明書が必要です。 識別名や有効期限などの X.509 証明書の内容は、証明局 (CA) により署名されるか、または自己署名です。トラステッド CA が X.509 証明書に署名する場合は、 WebSphere Application Server 証明書を識別し、これを自由に配布します。 この証明書は、不特定多数のユーザーに対してあるエンティティーの身元を示すため、CA により署名される必要があります。 不特定多数の人間からの接続を受け入れるサーバー・サイドのポートは、CA が署名した証明書を使用する必要があり ます。ほとんどのクライアントやブラウザーは、すでに X.509 証明書を検証できる署名者証明書を持っているので、正常な接続のための署名者交換は必要ありません。

自己署名の X.509 証明書の ID は、内部ネットワーク通信などの制御された環境でピアが署名者証明書を受け入れる場合にのみ、信頼できます。 トラステッド・ハンドシェークを完了するには、まずエンティティーの証明書を、そのエンティティーに接続する各ピアに送信する必要があります。 自己署名証明書は、セキュア接続のための署名者交換が必要ないため、CA 署名の証明書よりもコストがかかりません。

CA 署名および自己署名の X.509 証明書は、Java 鍵ストア にあります。 JSSE によって、証明書がある鍵ストアへの参照が提供されます。 Java Cryptographic Extension (JCE) ベースの 鍵ストアやハードウェア・ベースの鍵ストアなど、 多くのタイプの鍵ストアからの選択が可能です。 通常、各 JSSE 構成には、 鍵ストアとトラストストア の 2 つの Java 鍵ストア参照があります。 鍵ストア参照は、 個人証明書を保持する Java 鍵ストア・オブジェクトを表します。 トラストストア参照は、 署名者証明書を保持する Java 鍵ストア・オブジェクトを表します。

秘密鍵がない個人証明書は、ハンドシェーク中に、証明書を所有するエンティティーを表す X.509 証明 書です。 個人証明書には公開鍵と秘密鍵の両方が含まれています。 署名者証明書は、ピア・エンティティーまたはピアそのものを表す X.509 証明書です。 署名者証明書には公開鍵しか含まれておらず、ピアツーピアのハンドシェーク中に受信する ID の署名を検証します。

詳しくは、個人証明書からの署名者証明書の抽出 を参照してください。

鍵ストアについて詳しくは、 鍵ストア構成 を参照してください。

署名者交換

SSL 接続を構成する場合、特定のエンティティーの個人証明書 で信頼を確立するために署名者を交換することができます。 署名者交換により、 ピアの鍵ストアから X.509 証明書を抽出し、 それを別のエンティティーのトラストストアに追加して、2 つの ピア・エンティティーを接続させることが可能です。 署名者証明書は、ルート署名者証明書または中間署名者証明書として CA から発信することもできます。 また、署名者証明書自己署名証明書 から直接抽出することもできます。これは、公開鍵が存在す る X.509 証明書です。

鍵ストアとトラストストアの仮定の構成を、図 1 に示します。 SSL 構成は、どのエンティティーが別のエンティティーと接続できるか、および SSL ハンドシェークにより信頼されるピア接続を決定します。 必要な署名者証明書がない場合は、ピアを信頼できないため、ハンドシェークは失敗します。
図 1. 署名者交換

この例では、エンティティー A のトラストストアには 3 人の署名者がいます。 エンティティー A は、3 人の署名者のうち 1 人が個人証明書を検証する限り、どのピアにも接続できます。 例えば、エンティティー A はエンティティー B またはエンティティー C に接続できます。これは、署名者が両方の署名された個人証明書を信頼できるからです。 エンティティー B のトラストストアには、1 人の署名者がいます。 エンティティー B はエンティティー C にしか接続できず、しかも、ピアのエンドポイントが証明書 Entity-C Cert 1 を ID として使用している場合にのみ接続できます。 エンティティー C の他の個人証明書を使用するポートは、 エンティティー B には信頼されません。 エンティティー C は、エンティティー A にのみ接続できます。

例では、自己署名構成が署名者と証明書との間の 1 対 1 関係を表しているように見えます。 しかし、CA が証明書に署名する場合、通常は一度に多くの証明書に署名します。 単一の CA 署名者を使用することの利点は、ピアが使用するために CA が生成する個人証明書を、検証できる点です。 ただし、署名者がパブリック CA の場合は、目的とするエンティティー以外の別の企業用に、署名済み証明書が生成さ れた可能性があることを認識しておく必要があります。 内部通信用には、プライベート CA と自己署名証明書の方がパブリック CA より好ましい形式です。プライベート CA と自己署名証明書では、ユーザーは必要な接続を分離し、不要な接続を回避できるからです。

SSL 構成

SSL 構成は、WebSphere Application Server トポロジー内の単一のエンドポイント または一連のエンドポイントと関連付けることのできる、一連の構成属性から成り立っています。 SSL 構成により、SSLContext オブジェクトを作成できます。このオブジェクトは、サーバーが SSL ソケット・ファクトリーを取得するために使用する基本的な JSSE オブジェクトです。 次の構成属性を管理できます。 各 SSL 構成属性の詳細を理解するには、Secure Sockets Layer 構成 を参照してください。

SSL 構成の選択

WebSphere Application Server の以前のリリースでは、ユーザーは SSL 構成エイリアスを直接選択することによってのみ、SSL 構成を参照することができます。 各セキュア・エンドポイントは、SSL 構成のレパートリー内の有効な SSL 接続を参照する別名属性で示されていました。 以前は、構成の変更を一度でも行うと、 さまざまなプロセス全体で、 多くの別名参照を再構成しなくてはいけませんでした。 現行リリースではまだ直接選択をサポートしていますが、この方式はもう推奨されていません。

現行リリースでは、SSL 構成の管理機能が改善され、SSL 構成をより柔軟に選択できるようになりました。 このリリースでは、次の方法から選択できます。
プログラマチック選択
アウトバウンド接続の前に、実行スレッド上で SSL 構成を設定できます。 WebSphere Application Server では、Internet Inter-ORB Protocol (IIOP)、Java Message Service (JMS)、Hyper Text Transfer Protocol (HTTP)、および Lightweight Directory Access Protocol (LDAP) などのほとんどのシステム・プロトコルが、構成を受け入れることを保証しています。例: JSSEHelper API を使用した、アウトバウンド SSL 構成のプログラマチックな指定 を参照してください。
動的選択
定義済みの選択基準を使用して、SSL 構成を、特定のターゲット・ホスト、ポート、またはアウトバウンド・プロトコルと動的に関連付けることができます。 接続を確立するときに、WebSphere Application Server は、ターゲット・ホストおよびポートが、ホストのドメイン 部分を含む定義済みの基準に一致するかどうかを検査します。 さらに、特定のアウトバウンド SSL 構成用のプロトコルと証明書の別名の選択を、事前に定義することができます。 詳しくは、Secure Sockets Layer 構成の動的アウトバウンド選択 を参照してください。
直接選択
過去のリリースと同じように、特定の別名を使用して SSL 構成を選択できます。 多くのアプリケーションとプロセスは別名参照を基にしているため、この選択方法は後方互換性のために維持されています。
有効範囲の選択
ある SSL 構成と、 その SSL 構成に関連付けられた鍵ストアにある証明書の別名を、WebSphere Application Server の 管理有効範囲と関連付けることができます。 SSL 構 成を中央で管理するには、この方法をお勧めします。 エンドポイントは、セルの 1 つのトポロジー表示にあるので、より効率的にエンドポイントを管理できます。 有効範囲間の継承関係により、設定しなければならない SSL 構成の割り当ての数が減ります。
SSL 構成をセル有効範囲と関連付けるたびに、そのセル内のノード有効範囲は自動的に構成プロパティーを継承します。 ただし、SSL 構成をノードに割り当てると、そのノード構成は、ノードがセルから継承する構成をオーバーライドしま す。 同様に、ノードのすべてのアプリケーション・サーバーは、これらの割り当てをオーバーライドしない限り、その ノードの SSL 構成を自動的に継承します。 特定の構成をオーバーライドしない限り、トポロジーは各アプリケーション・サーバーに対して、セル・レベルからエ ンドポイント・レベルまでの継承の規則に従います。
トポロジー表示は、インバウンド・ツリーとアウトバウンド・ツリーを表示します。サーバーのアウトバウンドの接続先、およびイ ンバウンドの接続先に基づき、SSL 接続の両側に対して異なる SSL 構成を選択することができます。 詳しくは、Secure Sockets Layer 構成の中央管理 を参照してください。
SSL 構成を選択するには多くの方法があるため、ランタイムは、選択する SSL 構成を決定する際に 、優先順位を使用します。 構成方法を選択する場合は、次の優先順位を検討してください。
  1. プログラマチック選択。アプリケーションが、com.ibm.websphere.ssl.JSSEHelper アプリケーション・プログラミング・イ ンターフェース (API) を使用して、実行スレッド上の SSL 構成を設定する場合、その SSL 構成の優先順位は最も高く なります。
  2. アウトバウンド・ホストおよびポート、またはプロトコルの動的選択基準。
  3. 直接選択。
  4. 有効範囲の選択。有効範囲の継承により、選択するエンドポイントが SSL 構成と関連付けられ、この選択をオーバーライ ドしない、その有効範囲より下の各有効範囲により継承されることが保証されます。

デフォルトの自己署名証明書の構成

デフォルトで、WebSphere Application Server は、ノードごとに、 固有の自己署名証明書を作成します。 WebSphere Application Server は、製品に同梱されるデフォルトの証明書もダミーの証明書も信頼しなくなりました 。 デフォルトの鍵ストア key.p12 および トラストストア trust.p12 は、 ノード・ディレクトリー内の構成リポジトリーに保管されます。

この共通トラストストア (trust.p12) に、 すべてのノードの署名者証明書が置かれます。 さらに、ノードを統合した後で、 共通トラストストア (セル・ディレクトリーにあります) を 指すように、デフォルトの SSL 構成が自動的に変更されます。 これで、ノードはセル内のすべての他のサーバーと通信できるようになりました。

すべてのデフォルトの SSL 構成には、 名前のサフィックスが DefaultKeyStore となっている鍵ストアと、 名前のサフィックスが DefaultTrustStore となっているトラストストアが含まれています。 これらのデフォルトのサフィックスは、WebSphere Application Server ランタイムに対して、 個人証明書の署名者を共通トラストストアに追加するよう指示します。 鍵ストア名が DefaultKeyStore で終わっていない場合、 その鍵ストアの署名者証明書は、 サーバーを統合する際に、 共通トラストストアに追加されません。 デフォルトの SSL 構成を変更することはできますが、正しい信頼が、特に管理接続で確立されることを確認する必要があります。

詳しくは、 デフォルトの自己署名証明書の構成 およびWeb サーバー・プラグインのデフォルト構成 を参照してください。

証明書有効期限のモニター

証明書モニターにより、各ノードの自己署名証明書の有効期限が切れないこ とが保証されます。 証明書の有効期限モニター機能は、証明書と署名者の有効期限が切れる前に、警告を出します。 WebSphere Application Server 構成により管理される鍵ストアにある、 証明書と署名者をモニターできます。 自己署名証明書を、最初に作成した自己署名証明書に使用したものと同じデータに基づく、新しい自己署名証明書と自 動的に置き換えるように、有効期限モニターを構成することができます。 このモニターを使うと、 WebSphere Application Server が管理する鍵ストアにある、 新しい自己署名証明書の署名者によって、 古い署名者を自動的に置き換えることもできます。 統合中にランタイムにより発生した既存の署名者交換、および管理により発生した既存の署名者交換は、保存されます。 詳しくは、証明書有効期限のモニター を参照してください。

WebSphere Application Server クライアント: 署名者交換の要件

各ノードについて、最初の始動中に、新規自己署名証明書が生成されます。 信頼を保証するには、クライアントにこれらの生成された署名者を提供して、接続を確立する必要があります。 現行リリースのいくつかの拡張機能では、このプロセスが簡単になっています。 次のオプションのいずれかを使用して、クライアントが接続する必要のあるさまざまなノードの署名者証明書にアクセスすることができます (詳しくは、クライアント署名者を取り出すためのセキュア・インストール を参照してください)。

動的 SSL 構成の変更

WebSphere Application Server の SSL ランタイムは、ほとんどの SSL 接続 のリスナーを維持します。 SSL 構成を変更すると、インバウンド接続リスナーが新規 SSLContext オブジェクトを作成します。既存の接続では、現行の SSLContext オブジェクトが引き 続き使 用されます。アウトバウンド接続は、接続試行時に、新規構成プロパティーを自動的に使用します。

オフピーク時に SSL 構成に動的変更を行うことで、タイミング関連の問題が発生する可能性を少なくし、サーバーが 再始動しないようにします。 動的変更を受け入れるためにランタイムを使用可能にする場合は、SSL 構成を変更して security.xml ファ イルを保管します。変更は、新規 security.xml ファイルが各ノードに到達したときに、有効になります。

注: 構成の変更により、SSL ハンドシェークが失敗する場合は、管理接続に障害が発生す る可能性もあり、停止につながることがあります。 この場合は、SSL 接続を再構成してから、 手動でノードの同期を実行し、 問題を訂正する必要があります。 動的変更は、注意して行う必要があります。 実動システムの SSL 構成に変更を行う前に、同じ変更をテスト環境で実行することを強く推奨します。 詳しくは、動的構成の更新 を参照してください。

組み込み証明書管理

iKeyMan 機能に匹敵する証明書管理が、 管理コンソールの鍵ストア管理パネルに統合されました。 組み込み証明書管理を使用して、 鍵ストアにある個人証明書、証明書要求、および署名者証明書を管理します。 さらに、鍵ストアをリモートで管理することができます。 例えば、任意のノード上の構成リポジトリーの外側に存在する、 ファイル・ベースの鍵ストアを、 デプロイメント・マネージャーから管理することができます。 また、デプロイメント・マネージャーから、 ハードウェア暗号鍵ストアをリモートで管理することもできます。

組み込み証明書管理の場合、 多数のトラストストアに散在する すべての署名者証明書とともに、 自己署名証明書を置き換え、 リモートの SSL ホストとポートに接続して、 ハンドシェーク中に署名者をインターセプトすることにより、 リモート・ポートから署名者を取り出すことができます。 証明書はまず、証明書 SHA ダイジェストに従って検証されます。 次に、管理者は、検証済みの証明書を受け入れてから、 トラストストアに入れる必要があります。

証明書要求を行う場合は、証明書を認証局 (CA) へ送信できます。証明書が戻されると、それを管理コンソール内で受け入れることがで きます。 詳しくは、証明書管理 を参照してください。
ヒント: iKeyMan 機能は、 これまでどおり WebSphere Application Server に同梱されていますが、 鍵ストアの構成は、 組み込みの証明書管理機能を使用して、管理コンソールから行ってください。 管理コンソールを使用するのが便利ではない場合は、iKeyMan を依然として選択することができます。 詳しくは、iKeyman を使用した証明書管理 を参照してください。

AdminTask 構成管理

管理コンソールの SSL 構成管理パネルは、基本的に管理タスクに基づいて います。管理タスクは、管理コンソールの機能をサポートするために維持および拡張されます。 Java コンソール・プロンプトから wsadmin コマンドを使用して、 鍵ストア、SSL 構成、証明書などの管理を自動化することができます。



サブトピック
Secure Sockets Layer 構成
鍵ストア構成
Secure Sockets Layer 構成の動的アウトバウンド選択
Secure Sockets Layer 構成の中央管理
Secure Sockets Layer ノード、アプリケーション・サーバー、およびクラスターの分離
デフォルトの自己署名証明書の構成
動的構成の更新
iKeyman を使用した証明書管理
証明書管理
retrieveSigners コマンドを使用したサーバー・トラストへのサーバーの使用可能化
関連概念
トラスト・マネージャーによる X.509 証明書の信頼についての決定の制御
X.509 証明書 ID の鍵マネージャー制御
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 7:05:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.express.iseries.doc/info/iseriesexp/ae/csec_sslsecurecom.html