第15章 EJB RMI トランスポート層をセキュアにする

JBoss Application Server は EJB2 および EJB3 Bean の Remote Method Invocation (リモートメソッド呼び出し : RMI) に対してソケットベースの invoker レイヤを使用します。このネットワークトラフィックはデフォルトでは暗号化されていません。本章の手順に従って、Secure Sockets Layer (セキュアソケットレイヤ : SSL) を使用してこのネットワークトラフィックを暗号化します。
SSL を使用した EJB のトランスポートオプション

本章では暗号化したトランスポートに対する EJB3 のリモートメソッド呼び出しの 2 つの異なる設定、RMI + SSL および HTTPS による RMI の設定について説明します。HTTPS はファイアウォール設定により RMI ポートを使用できない場合の RMI のトランスポートとしてのオプションです。

SSL のキーペアの生成については 「暗号化キーと証明書の生成」 で取り上げます。
EJB3 の RMI + SSL の設定については 「EJB3 RMI + SSL 設定」 で取り上げます。
EJB3 の HTTPS による RMI の設定については 「HTTPS 設定による EJB3 RMI」 で取り上げます。
EJB2 の RMI + SLL の設定については 「EJB2 RMI + SSL 設定」 で取り上げます。

15.1. SSL 暗号化の概要

15.1.1. キーペアと証明書

Secure Sockets Layer (SSL) は 2 つのシステム間のネットワークトラフィックを暗号化します。この 2 つのシステム間のトラフィックは、双方向キーを使用して暗号化され、接続の ハンドシェイク フェーズ中に生成され、これら 2 つのシステムにのみ知られます。
双方向の暗号化キーを安全に交換するために、SSL は Public Key Infrastructure (公開鍵基盤 : PKI) という キーペア を活用する暗号化メソッドを使用します。キーペアは公開キーと秘密キーという別々ですが対応する 2 つの暗号化キーで構成されています。公開キーは他人と共有し、データの暗号化に使用します。秘密キーは秘密にされ、公開キーを使用して暗号化されたデータの復号化に使用します。
クライアントがセキュアな接続を要求する場合は、セキュアな通信が始まる前にハンドシェイクフェーズが行われます。SSL ハンドシェイクの間、サーバーはその公開キーを証明書の形でクライアントに渡します。その証明書にはサーバーのアイデンティティ (URL)、サーバーの公開キー、証明書を検証するデジタル署名が含まれています。次にクライアントは証明書を検証し、証明書が信頼できるか決定します。証明書が信頼できる場合は、クライアントは SLL 接続に対し双方向の暗号化キーを生成し、サーバーの公開キーを使用してそれを暗号化し、サーバーに戻します。サーバーはその秘密キーを使用して双方向の暗号化キーを復号化し、双方向の暗号化キーを使用してこの接続に関して 2 つのマシン間での更なる通信が暗号化されます。
サーバーでは、公開 / 秘密キーのペアはキーペアと信頼できる証明書を保存する暗号化されたファイルである キーストア に保存されます。キーストア内の各キーペアは、キーストアからキーペアを保存または要求するときに使用される一意の名前、エイリアス として識別されます。公開キーは公開キーとアイデンティティをバインドするデジタル署名である 証明書 の形でクライアントに配布されます。クライアントでは、既知の検証の証明書は 信頼ストア として知られるデフォルトのキーストアで保管されます。
CA 署名証明書と自己署名証明書

公開鍵基盤は不明のマシンの資格情報を確立するための信頼チェーンに依存しています。公開キーの使用はマシン間のトラフィックを暗号化するだけでなく、ネットワーク接続のもう一方の最後でマシンのアイデンティティを確立するための機能を果たします。「Web of Trust (信用の輪)」を使用して、サーバーのアイデンティティを検証します。あなたにとって不明なサーバーがあるかもしれませんが、その公開キーがあなたの信頼できる誰かにより署名された場合、サーバーにその信頼を広げます。Certificate Authority (認証局) はカスタマのアイデンティティを検証し、署名された証明書を発行する商用エンティティです。JDK には cacerts ファイルが含まれ、信頼できる Certificate Authority (CA) の証明書が複数付いています。これらの CA により署名されたすべてのキーは自動的に信頼されます。大規模な組織には Red Hat Certificate System を使用するなど、独自の内部の Certificate Authority があります。この場合、内部の Certificate Authority の証明書の署名は通常 Corporate Standard Build の一部としてクライアントにインストールされており、その証明書で署名されたすべての証明書は信頼できます。CA 署名証明書は稼働シナリオにとって最良事例です。

開発やテスト中、または小規模や内部のみの実稼働シナリオでは、自己署名証明書 を使用できます。この証明書は Certificate Authority では署名されていませんが、ローカルで生成された証明書で署名されています。ローカルで生成された証明書はクライアントの cacerts ファイル内にはないため、サーバーからそのキーの証明書をエクスポートし、SSL により接続するすべてのクライアントからその証明書をインポートする必要があります。
JDK にはキーペアと証明書を生成するコマンドラインツール keytool が含まれています。keytool で生成された証明書は、CA による署名のために送られるか、自己署名証明書としてクライアントに配布されます。
  • 開発使用のための自己署名証明書の生成、クライアントへのその証明書のインポートに関しては 「keytool を使用した自己署名証明書の生成」 で説明されています。
  • 証明書を生成し、実稼働使用に対して CA によりそれを署名することは、本書の範囲外です。このタスクを実行する上での詳細情報は keytool の man ページを参照してください。