test

Sun Java System Application Server 9.1 管理ガイド

第 9 章 セキュリティーの設定

セキュリティーとはデータの保護に関することであり、ストレージ内または伝送中のデータへの不正アクセスやそうしたデータの破損をどのようにして防止するか、ということです。Application Server には、Java EE 標準に基づく動的で拡張可能なセキュリティーアーキテクチャーがあります。標準実装されているセキュリティー機能には、暗号化、認証と承認、および公開鍵インフラストラクチャーがあります。Application Server は Java セキュリティーモデルをベースに構築され、アプリケーションが安全に動作できるサンドボックスを使用するため、システムやユーザーにリスクが及ぶ可能性がありません。この章では、次の内容について説明します。

アプリケーションおよびシステムセキュリティーについて

概して、2 種類のアプリケーションセキュリティーがあります。

アプリケーションによるセキュリティーのほかに、Application Server システムのアプリケーション全体に影響するシステムセキュリティーもあります。

プログラムによるセキュリティーはアプリケーション開発者により制御されるため、このマニュアルでは説明していません。宣言によるセキュリティーについては、このマニュアルである程度説明しています。このマニュアルは、主にシステム管理者を対象としているため、システムセキュリティーを中心に説明しています。

セキュリティー管理用ツール

Application Server には次のセキュリティー管理用ツールがあります。

Java 2 プラットフォーム、J2SE (Java 2 Standard Edition) には、次の 2 つのセキュリティー管理用ツールがあります。

keytool、policytool、およびその他の Java セキュリティーツールの使用方法の詳細については、http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#security の「Java 2 SDK Tools and Utilities」を参照してください。

エンタープライズプロファイルでは、NSS (Network Security Services) を実装した 2 つのセキュリティー管理ツールも利用可能です。NSS の詳細については、http://www.mozilla.org/projects/security/pki/nss/ を参照してください。それらのセキュリティー管理ツールは次のとおりです。

certutil、pk12util、およびその他の NSS セキュリティーツールの使用方法の詳細については、http://www.mozilla.org/projects/security/pki/nss/tools の「NSS Security Tools」を参照してください。

パスワードのセキュリティー管理

Application Server では、特定のドメインの仕様が収められるファイル domain.xml 内に、Sun Java System Message Queue ブローカのパスワードが、あらかじめ平文で格納されています。このパスワードを収めた domain.xml ファイルの要素は、jms-host 要素の admin-password 属性です。このパスワードはインストール時には変更不可能なので、セキュリティーに重大な影響は与えません。

ただし、管理コンソールを使用してユーザーやリソースを追加し、そのユーザーやリソースにパスワードを割り当てた場合、パスワードの中には、たとえばデータベースにアクセスするためのパスワードなど、平文で domain.xml ファイルに記述されるものもあります。このようなパスワードを平文で domain.xml ファイルに保持すると、セキュリティー上の危険を引き起こす可能性があります。admin-password 属性やデータベースパスワードを含む domain.xml のすべてのパスワードを暗号化できます。セキュリティーパスワードを管理する手順は、次のトピックを参照してください。

domain.xml ファイル内のパスワードの暗号化

domain.xml ファイル内のパスワードを暗号化するには、次の手順を実行します。

  1. domain.xml ファイルが格納されているディレクトリ (デフォルトでは domain-dir/config) から、次の asadmin コマンドを実行します。


    asadmin create-password-alias --user admin alias-name

    次に例を示します。


    asadmin create-password-alias --user admin jms-password

    パスワードプロンプトが表示されます。この場合は admin です。詳細については、create-password-alias、list-password-aliases、delete-password-alias コマンドのマニュアルページを参照してください。

  2. domain.xml のパスワードの削除および置き換えを行います。これは、asadmin set コマンドを使用して行います。このような目的での set コマンドの使用例は、次のとおりです。


    asadmin set --user admin server.jms-service.jms-host.
default_JMS_host.admin-password='${ALIAS=jms-password}'
    注 –

    エイリアスのパスワードは、例に示すように単一引用符で囲みます。

  3. 該当するドメインの Application Server を再起動します。

エンコード化されたパスワードを含むファイルの保護

ファイルの中にはエンコード化されたパスワードを含むものがあり、ファイルシステムのアクセス権を使用しての保護が必要になります。これらのファイルには次のものが含まれます。

マスターパスワードの変更

マスターパスワード (MP) とは、全体で共有するパスワードです。これを認証に使用したり、ネットワークを介して送信したりすることは決してありません。このパスワードはセキュリティー全体の要なので、ユーザーが必要に応じて手動で入力したり、またはファイルに隠蔽したりすることができます。これは、システムで最高の機密データです。ユーザーは、このファイルを削除することで、強制的にマスターパスワードの入力を要求できます。マスターパスワードが変更されると、Java JCEKS タイプのキーストアであるマスターパスワードキーストアに再保存されます。

マスターパスワードの変更手順は次のとおりです。

  1. ドメインの Application Server を停止します。新旧のパスワードの入力を促す asadmin change-master-password コマンドを使用して、依存するすべての項目を再暗号化してください。次に例を示します。


    #asadmin change-master-password domain-name
マスターパスワードを入力してください>
新しいマスターパスワードを入力してください>
新しいマスターパスワードをもう一度入力してください>

  2. Application Server を再起動します。

    注意 – 注意 –

    この時点で、実行中のサーバーインスタンスを再起動してはいけません。対応するノードエージェントの SMP が変更されるまでは、決して実行中のサーバーインスタンスを再起動しないでください。SMP が変更される前にサーバーインスタンスを再起動すると、起動に失敗します。

  3. 各ノードエージェントおよび関連するサーバーを １ つずつ停止します。asadmin change-master-password コマンドをもう一度実行してから、ノードエージェントおよび関連するサーバーを再起動してください。

  4. すべてのノードエージェントで対応が終了するまで、次のノードエージェントで同様の作業を継続します。このようにして、継続的な変更作業が完了します。

マスターパスワードとキーストアの操作

マスターパスワードは、セキュリティー保護されたキーストアのパスワードです。新しいアプリケーションサーバードメインが作成されると、新しい自己署名付き証明書が生成されて、関連キーストアに格納されます。このキーストアは、マスターパスワードでロックされます。マスターパスワードがデフォルトではない場合、start-domain コマンドにより、マスターパスワードが要求されます。正しいマスターパスワードが入力されると、ドメインが起動します。

ドメインに関連付けられたノードエージェントが作成されると、ノードエージェントはデータをドメインと同期化させます。その間に、キーストアも同期化されます。このノードエージェントによって制御されるサーバーインスタンスは、キーストアを開く必要があります。このストアは、ドメイン作成処理で作成されたストアと基本的に同一であるため、同一のマスターパスワードでのみ開くことができます。マスターパスワード自体は、同期化されることはなく、同期中にノードエージェントには転送されません。しかし、ローカルでノードエージェントが利用できるようにする必要があります。このため、ノードエージェントの作成または起動、あるいはその両方の場合に、マスターパスワードが要求され、かつドメインの作成や起動のときに入力したパスワードと同じものを入力する必要があるのです。マスターパスワードがドメインで変更された場合は、ドメインと関連付けられている各ノードエージェントでも同じ手順で変更する必要があります。

管理パスワードの変更

管理パスワードの暗号化については、「パスワードのセキュリティー管理」を参照してください。管理パスワードの暗号化は強く推奨されています。管理パスワードを暗号化する前に変更する場合は、asadmin set コマンドを使用してください。このような目的での set コマンドの使用例は、次のとおりです。


asadmin set --user admin server.jms-service.jms-host.default_JMS_host.admin-password=new_pwd

管理コンソールを使用して管理パスワードを変更する手順については、管理コンソールのオンラインヘルプを参照してください。

認証と承認について

認証と承認は、アプリケーションサーバーセキュリティーの中心的な概念です。ここでは、認証と承認に関連する次の項目について説明します。

エンティティーの認証

「認証」とは、あるエンティティー (ユーザー、アプリケーション、またはコンポーネント) が別のエンティティーが主張している本人であることを確認する方法です。エンティティーは、「セキュリティー資格」を使用して自らを認証します。資格には、ユーザー名、パスワード、デジタル証明書などが含まれます。

通常、認証はユーザー名とパスワードでユーザーがアプリケーションにログインすることを意味していますが、アプリケーションがサーバーのリソースを要求するとき、セキュリティー資格を提供する EJB を指す場合もあります。普通、サーバーやアプリケーションはクライアントに認証を要求しますが、さらにクライアントもサーバーに自らの認証を要求できます。双方向で認証する場合、これを相互認証と呼びます。

エンティティーが保護対象リソースにアクセスを試行する場合、Application Server はそのリソースに対して設定されている認証メカニズムを使用してアクセスを認可するかどうかを決定します。たとえば、ユーザーが Web ブラウザでユーザー名およびパスワードを入力でき、アプリケーションがその資格を確認する場合、そのユーザーは認証されます。それ以降のセッションで、ユーザーはこの認証済みのセキュリティー ID に関連付けられます。

Application Server は、4 種類の認証をサポートします。アプリケーションは、配備記述子で使用する認証タイプを指定します。

表 9–1 Application Server の認証方法

認証方法

通信プロトコル

説明

ユーザー資格の暗号化

BASIC 

HTTP (オプションで SSL) 

サーバーのビルトインポップアップログインダイアログボックスを使用します。 

SSL を使用しないかぎりありません。 

FORM 

HTTP (オプションで SSL) 

アプリケーションが独自仕様のカスタムログインおよびエラーページを提供します。 

SSL を使用しないかぎりありません。 

CLIENT-CERT 

HTTPS (HTTP over SSL) 

サーバーは公開鍵証明書を使用してクライアントを認証します。 

SSL 

シングルサインオンの確認

シングルサインオンとは、1 つの仮想サーバーインスタンスの複数のアプリケーションがユーザー認証状態を共有することを可能にするものです。シングルサインオンによって、1 つのアプリケーションにログインしたユーザーは、同じ認証情報が必要なほかのアプリケーションに暗黙的にログインするようになります。

シングルサインオンはグループに基づいています。配備記述子が同じ「グループ」を定義し、かつ同じ認証方法 (BASIC、FORM、CLIENT-CERT) を使用するすべての Web アプリケーションはシングルサインオンを共有します。

デフォルトでシングルサインオンは、Application Server に定義された仮想サーバーで有効です。

ユーザーの承認

いったんユーザーが認証されると、「承認」のレベルによってどのような操作が可能かが決まります。ユーザーの承認は、ユーザーの「ロール」に基づいています。たとえば、人事管理アプリケーションでは、管理者には社員全員の個人情報を見ることを承認し、社員には自身の個人情報だけを見ることを承認します。ロールの詳細については、「ユーザー、グループ、ロール、およびレルムについて」を参照してください。

JACC プロバイダの指定

JACC (Java Authorization Contract for Containers) は Java EE 仕様の一部で、プラグイン可能な承認プロバイダ用のインタフェースを定義しています。これによって、管理者は認証を行うためにサードパーティー製のプラグインモジュールを設定できます。

デフォルトで、Application Server は JACC 仕様に準拠する単純なファイルベースの承認エンジンを提供します。その他のサードパーティー製の JACC プロバイダを指定することもできます。

JACC プロバイダは JAAS (Java Authentication and Authorization Service) の API を使用します。JAAS によって、サービスが認証およびユーザーに対するアクセス制御を行うことが可能になります。これは、標準 PAM (Pluggable Authentication Module) フレームワークの Java テクノロジバージョンを実装しています。

認証および承認の決定の監査

Application Server は、「監査モジュール」によってすべての認証および承認の決定の監査トレールを提供します。Application Server は、デフォルトの監査モジュールのほか、監査モジュールのカスタマイズ機能も提供します。

メッセージセキュリティーの設定

「メッセージセキュリティー」によって、サーバーは、メッセージレイヤーで Web サービスの呼び出しおよび応答をエンドツーエンドで認証できます。Application Server は、SOAP レイヤーのメッセージセキュリティープロバイダを使用して、メッセージセキュリティーを実装します。メッセージセキュリティープロバイダは、要求メッセージおよび応答メッセージに必要な認証のタイプなどの情報を提供します。サポートされている認証には次のタイプが含まれます。

このリリースには、2 つのメッセージセキュリティープロバイダが付属しています。メッセージセキュリティープロバイダは、SOAP レイヤーの認証用に設定されます。設定可能なプロバイダには、ClientProvider と ServerProvider があります。

メッセージレイヤーセキュリティーのサポートは、プラグイン可能な認証モジュールの形式で Application Server とそのクライアントコンテナに統合されています。Application Server では、メッセージレイヤーセキュリティーはデフォルトで無効になっています。

メッセージレベルのセキュリティーは、Application Server 全体または特定のアプリケーションあるいはメソッドに対して設定できます。Application Server レベルのメッセージセキュリティーの設定については、第 10 章「メッセージセキュリティーの設定」を参照してください。アプリケーションレベルのメッセージセキュリティーの設定については、『Developer's Guide』を参照してください。

ユーザー、グループ、ロール、およびレルムについて

Application Server は次のエンティティーに対して認証および承認ポリシーを実施します。

注 –

ユーザーおよびグループは Application Server 全体で指定されますが、各アプリケーションは独自のロールを定義します。アプリケーションがパッケージ化されて配備される場合、次の図に例示されているように、アプリケーションはユーザーまたはグループとロールとの間のマッピングを指定します。

図 9–1 ロールマッピング

図は、ユーザーをグループに割り当てる方法、ユーザーやグループをロールに割り当てる方法、およびアプリケーションがグループやロールを使用する方法を示しています。

ユーザー

「ユーザー」とは、Application Server によって定義された個人またはアプリケーションプログラムの ID です。ユーザーは 1 つのグループと関連付けできます。Application Server の認証サービスは、複数のレルムでユーザーを管理できます。

グループ

「J2EE グループ」(または単にグループ) は、肩書きや顧客のプロファイルなど、共通の特性で分類されたユーザーのカテゴリです。たとえば、E コマースアプリケーションのユーザーは CUSTOMER グループに属しますが、お得意様は PREFERRED グループに属します。ユーザーをグループに分類すると、大量のユーザーによるアクセスを容易に制御できます。

ロール

「ロール」は、ユーザーが、どのアプリケーションのどの部分にアクセスできるかと、何を実行できるかを定義します。つまり、ロールによってユーザーの承認レベルが決まります。

たとえば、人事アプリケーションの場合、電話番号とメールアドレスにはすべての社員がアクセスできますが、給与情報にアクセスできるのは管理職だけです。このアプリケーションでは少なくとも 2 つのロールが定義されます。employee と manager です。そして、manager ロールのユーザーだけに給与情報の表示が許可されます。

ロールはアプリケーション内での役割を定義するのに対し、グループはある方法で関連付けられているユーザーの集まりに過ぎません。この点で、ロールとユーザーグループは異なります。たとえば、人事アプリケーションには、full-time、part-time、および on-leave などのグループがありますが、これらすべてのグループのユーザーは employee ロールに所属します。

ロールはアプリケーション配備記述子で定義されます。反対に、グループはサーバーおよびレルム全体に対して定義されます。アプリケーション開発者または配備担当者は、配備記述子により各アプリケーション内で、ロールを 1 つまたは複数のグループに割り当てます。

レルム

「セキュリティーポリシードメイン」または「セキュリティードメイン」とも呼ばれている「レルム」とは、サーバーによって共通のセキュリティーポリシーが定義および適用される範囲のことです。実際には、レルムとはサーバーがユーザーおよびグループの情報を格納するリポジトリです。

Application Server には、次の 3 つのレルムが事前に設定されています。file (初期のデフォルトレルム)、certificate、および admin-realm です。さらに、ldap レルム、 JDBC レルム、solaris レルム、またはカスタムレルムも設定できます。アプリケーションは、その配備記述子でレルムを指定して使用できます。レルムを指定しない場合、Application Server はデフォルトレルムを使用します。

file レルムでは、サーバーはユーザー資格を keyfile という名前のファイルにローカルで格納します。管理コンソールを使用して file レルムのユーザーを管理できます。

certificate レルムでは、サーバーはユーザー資格を証明書データベースに格納します。certificate レルムを使用する際、サーバーは HTTP プロトコルを使う証明書を使用して Web クライアントを認証します。証明書の詳細については、「証明書および SSL の概要」を参照してください。

admin-realm は FileRealm でもあり、管理者ユーザーの資格を admin-keyfile という名前のファイルにローカルで格納します。file レルムでユーザーを管理するのと同じ方法で、管理コンソールを使用してこのレルムのユーザーを管理してください。

ldap レルムでは、サーバーは Sun Java System Directory Server などの LDAP (Lightweight Directory Access Protocol) サーバーからユーザー資格を取得します。LDAP とは、一般のインターネットまたは会社のイントラネットのどちらであっても、ネットワークでの組織、個人、およびファイルやデバイスなどその他のリソースの検出をだれにでもできるようにするプロトコルです。ldap レルムのユーザーおよびグループの管理については、LDAP サーバーのドキュメントを参照してください。

JDBC レルムでは、サーバーはデータベースからユーザー資格を取得します。Application Server は、データベース情報および設定ファイル内の有効化された JDBC レルムオプションを使用します。

solaris レルムでは、サーバーは Solaris オペレーティングシステムからユーザー資格を取得します。このレルムは Solaris 9 OS 以降でサポートされています。solaris レルムのユーザーおよびグループの管理については、Solaris のドキュメントを参照してください。

カスタムレルムとは、リレーショナルデータベースやサードパーティー製のコンポーネントなどその他のユーザー資格のリポジトリです。詳細については、管理コンソールのオンラインヘルプを参照してください。

ProcedureJava EE アプリケーションの JDBC レルムを設定する

Application Server では、接続プールの代わりに JDBC レルムにユーザーの資格を指定できます。接続プールの代わりに JDBC レルムを使用すると、ほかのアプリケーションがユーザー資格のデータベース表を参照するのを防止できます。ユーザーの資格とは、ユーザーの名前とパスワードです。

注 –

JDBC レルムでは、デフォルトでは平文によるパスワードの保存はサポートされません。通常の状況では、パスワードを平文で保存しないでください。

  1. レルムのユーザー資格を格納するデータベース表を作成します。

    データベース表の作成方法は、使用しているデータベースによって異なります。

  2. 手順 1 で作成したデータベース表にユーザーの資格を追加します。

    データベース表にユーザーの資格を追加する方法は、使用しているデータベースによって異なります。

  3. JDBC レルムを作成します。

    この作業には管理コンソール GUI を使用します。JDBC レルムの作成手順については、管理コンソール GUI のオンラインヘルプを参照してください。

  4. 手順 3 で作成したレルムをアプリケーションのレルムとして指定します。

    レルムを指定するには、アプリケーションの該当する配備記述子を変更します。

    • Enterprise Archive (EAR) ファイルのエンタープライズアプリケーションの場合は、sun-application.xml ファイルを変更します。

    • Web Application Archive (WAR) ファイルの Web アプリケーションの場合は、web.xml ファイルを変更します。

    • EJB JAR ファイルのエンタープライズ Bean の場合は、sun-ejb-jar.xml ファイルを変更します。

    レルムの指定方法の詳細については、『Sun Java System Application Server 9.1 Developer’s Guide』の「How to Set a Realm for an Application or Module」を参照してください。

  5. レルム内のユーザーにセキュリティーロールを割り当てます。

    ユーザーにセキュリティーロールを割り当てるには、手順 4 で変更した配備記述子に security-role-mapping 要素を追加します。

    次の例は、ユーザー Calvin にセキュリティーロール Employee を割り当てる security-role-mapping 要素を示しています。

    <security-role-mapping>
    <role-name>Employee</role-name>
    <principal-name>Calvin</principal-name>
  </security-role-mapping>

証明書および SSL の概要

この節では、次の項目について説明します。

デジタル証明書について

「デジタル証明書」(または単に証明書) とは、インターネット上の人物やリソースを一意に識別する電子ファイルです。さらに証明書は 2 つのエンティティー間の安全で機密保護された通信を可能にします。

個人により使用される個人証明書や SSL (Secure Sockets Layer) テクノロジでサーバーとクライアント間の安全なセッションを確立するために使用されるサーバー証明書など、さまざまな種類の証明書があります。SSL の詳細については、「SSL (Secure Sockets Layer) について」を参照してください。

証明書は「公開鍵暗号化」に基づき、意図した受信者だけが解読できるようデジタルの「鍵」 (非常に長い数値) のペアを使用して「暗号化」、または符号化します。そして受信者は、情報を「復号化」して解読します。

鍵のペアには公開鍵と非公開鍵が含まれます。所有者は公開鍵を配布して、だれでも利用できるようにします。しかし、所有者は非公開鍵を決して配布せず、常時秘密にしておきます。鍵は数学的に関連しているので、1 つの鍵で暗号化されたデータは、そのペアのもう 1 つの鍵でだけ復号化ができます。

証明書とはパスポートのようなものです。所有者を識別し、その他の重要な情報を提供します。証明書は、「証明書発行局」(CA) と呼ばれる、信頼できるサードパーティーが発行します。CA はパスポートセンターに似ています。CA は、証明書の所有者の身元を確認したあと、偽造や改ざんができないように証明書に署名します。いったん CA が証明書に署名すると、所有者は ID の証明としてこれを提出することで、暗号化され、機密保護された通信を確立できます。

もっとも重要な点は、証明書によって所有者の公開鍵が所有者の ID と結び付けられることです。パスポートが写真とその所有者についての個人情報を結び付けるように、証明書は公開鍵とその所有者についての情報を結び付けます。

公開鍵のほかに、通常、証明書には次のような情報が含まれています。

デジタル証明書は、X.509 形式の技術仕様で管理されます。certificate レルムのユーザー ID を検証するために、 certificate 認証サービスは X.509 証明書の共通名フィールドを主体名として使用して、X.509 証明書を検証します。

証明書チェーンについて

Web ブラウザは、ブラウザが自動的に信頼する一連の「ルート」CA 証明書で事前に設定されます。別の場所で発行されたすべての証明書は、有効性を検証するために「証明書チェーン」を備えている必要があります。証明書チェーンとは、最後が ルート CA 証明書で終わる、継続的な CA によって発行される一連の証明書です。

証明書が最初に生成される場合、それは「自己署名付き」証明書です。自己署名付き証明書とは、発行者 (署名者) が被認証者 (公開鍵が証明書で認証されているエンティティー) と同じものです。所有者は、証明書の署名要求 (CSR) を CA に送信するとき、その応答をインポートし、自己署名付き証明書が証明書のチェーンによって置き換えられます。チェーンの元の部分には、被認証者の公開鍵を認証する CA によって発行された証明書 (応答) があります。このチェーンの次の証明書は、CA の公開鍵を認証するものです。通常、これは自己署名付き証明書 (つまり、自らの公開鍵を認証する CA からの証明書) およびチェーンの最後の証明書です。

CA が証明書のチェーンに戻ることができる場合もあります。この場合、チェーンの元の証明書は同じ (キーエントリの公開鍵を認証する、CA によって署名された証明書) ですが、チェーン 2 番目の証明書が、CSR の送信先の CA の公開鍵を認証する、異なる CA によって署名された証明書です。そして、チェーンのその次の証明書は 2 番目の鍵を認証する証明書というように、自己署名付き「ルート」証明書に到達するまで続きます。こうして、チェーンの最初以降の各証明書は、チェーンの前にある証明書の署名者の公開鍵を認証します。

SSL (Secure Sockets Layer) について

「SSL」(Secure Sockets Layer) とは、インターネットの通信およびトランザクションのセキュリティー保護でもっとも普及している標準仕様です。Web アプリケーションは HTTPS (HTTP over SSL) を使用します。HTTPS は、サーバーとクライアント間のセキュアで機密保護された通信を確保するため、デジタル証明書を使用します。SSL 接続では、クライアントとサーバーの両方が送信前にデータを暗号化し、受信するとそれを復号化します。

クライアントの Web ブラウザがセキュアなサイトに接続する場合、次のように「SSL ハンドシェーク」が行われます。

ハンドシェークの後、クライアントは Web サイトの ID を検証し、クライアントと Web サーバーだけがセッション鍵のコピーを持ちます。これ以降、クライアントとサーバーはセッション鍵を使用して互いにすべての通信を暗号化します。こうすると、通信は確実にセキュアになります。

SSL 標準の最新バージョンは TLS (Transport Layer Security) と呼ばれています。Application Server は、SSL (Secure Sockets Layer) 3.0 および TLS (Transport Layer Security) 1.0 暗号化プロトコルをサポートしています。

SSL を使用するには、セキュアな接続を受け付ける各外部インタフェースまたは IP アドレスの証明書を、Application Server が所持しておく必要があります。ほとんどの Web サーバーの HTTPS サービスは、デジタル証明書がインストールされるまで実行されません。「keytool ユーティリティーを使って証明書を生成する」の手順に従って、Web サーバーが SSL 用に使用できるデジタル証明書を設定してください。

暗号化方式について

「暗号化方式」とは、暗号化と復号化に使用される暗号化アルゴリズムです。SSL および TLS プロトコルは、サーバーとクライアントでお互いを認証するために使用される多くの暗号化方式のサポート、証明書の送信、およびセッション鍵の確立を行います。

安全度は、暗号化方式によって異なります。クライアントとサーバーは異なる暗号化方式群をサポートできます。SSL および TLS プロトコルから暗号化方式を選択してください。クライアントとサーバーは安全な接続のために、双方で通信に使用可能であるもっとも強力な暗号化方式を使用します。そのため、通常は、すべての暗号化方式を有効にすれば十分です。

名前ベースの仮想ホストの使用

セキュアなアプリケーションに名前ベースの仮想ホストを使用すると、問題が発生する場合があります。これは、SSL プロトコル自体の設計上の制約です。クライアントブラウザがサーバーの証明書を受け付ける SSL ハンドシェークは、HTTP 要求がアクセスされる前に行われる必要があります。その結果、認証より前に仮想ホスト名を含む要求情報を特定できないので、複数の証明書を単一の IP アドレスに割り当てできません。

単一の IP すべての仮想ホストが同じ証明書に対して認証を必要とする場合、複数の仮想ホストを追加しても、サーバーの通常の SSL 動作を妨害する可能性はありません。ただし、証明書 (主に正式な CA の署名済みの証明書が該当) に表示されているドメイン名がある場合、ほとんどのブラウザがサーバーのドメイン名をこのドメイン名と比較することに注意してください。ドメイン名が一致しない場合、これらのブラウザは警告を表示します。一般的には、アドレスベースの仮想ホストだけが本稼働環境の SSL で広く使用されています。

ファイアウォールについて

「ファイアウォール」は、2 つ以上のネットワーク間のデータフローを制御し、ネットワーク間のリンクを管理します。ファイアウォールは、ハードウェア要素およびソフトウェア要素で構成できます。この節では、一般的ないくつかのファイアウォールアーキテクチャーとその設定について説明します。ここでの情報は、主に Application Server に関係するものです。特定のファイアウォールテクノロジの詳細については、使用しているファイアウォールのベンダーのドキュメントを参照してください。

一般的には、クライアントが必要な TCP/IP ポートにアクセスできるようにファイアウォールを設定します。たとえば、HTTP リスナーがポート 8080 で動作している場合は、HTTP 要求をポート 8080 だけで受け付けるようにファイアウォールを設定します。同様に、HTTPS 要求が ポート 8181 に設定されている場合は、HTTPS 要求をポート 8181 で受け付けるようにファイアウォールを設定する必要があります。

インターネットから EJB モジュールへ直接の RMI-IIOP (Remote Method Invocations over Internet Inter-ORB Protocol) アクセスが必要な場合は、同様に RMI-IIOP リスナーポートを開きますが、これにはセキュリティー上のリスクが伴うので、使用しないことを強くお勧めします。

二重のファイアウォールのアーキテクチャーでは、HTTP および HTTPS トランザクションを受け付けるように外部ファイアウォールを設定する必要があります。また、ファイアウォールの背後の Application Server と通信する HTTP サーバープラグインを受け付けるように内部ファイアウォールを設定する必要があります。

証明書ファイルについて

Application Server をインストールすると、内部テストに適した JSSE (Java Secure Socket Extension) または NSS (Network Security Services) 形式のデジタル証明書が生成されます。デフォルトでは、Application Server は domain-dir/config ディレクトリの証明書データベースに、証明書情報を格納します。

証明書ファイルの場所の変更

開発用として提供されているキーストアファイルとトラストストアファイルは、domain-dir/config ディレクトリに格納されています。

証明書ファイルの新しい場所の値フィールドを追加または変更するには、管理コンソールを使用します。


-Dcom.sun.appserv.nss.db=${com.sun.aas.instanceRoot}/NSS-database-directory

ここで、NSS-database-directory は NSS データベースの場所です。

JSSE (Java Secure Socket Extension) ツールの使用

keytool を使用して、JSSE (Java Secure Socket Extension) デジタル証明書を設定および操作します。開発者プロファイルの場合、Application Server はサーバー側で、JSSE 形式を使って証明書とキーストアを管理します。すべてのプロファイルで、クライアント側 (アプリケーションクライアントまたはスタンドアロン) では、JSSE 形式を使用します。

J2SE SDK に同梱されている keytool を使用すれば、管理者は、公開鍵と非公開鍵のペアおよび関連する証明書を管理できます。さらに、ユーザーは、通信接続先の公開鍵を証明書の形式でキャッシュできます。

keytool を実行するには、J2SE の /bin ディレクトリがパスの中に設定されているか、またはツールへのフルパスがコマンド行に存在するように、シェルの環境を設定する必要があります。keytool の詳細については、keytool のドキュメント (http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html) を参照してください。

keytool ユーティリティーの使用

次の例は、JSSE ツールによる証明書処理に関する使用方法を示したものです。

keytool ユーティリティーを使って証明書を生成する

keytool を使用して証明書の生成、インポート、およびエクスポートを行います。デフォルトでは、keytool は実行元のディレクトリにキーストアファイルを作成します。

  1. 証明書を実行すべきディレクトリに移動します。

    証明書の生成は常に、キーストアファイルとトラストストアファイルが格納されたディレクトリ (デフォルトでは domain-dir/config) 内で行います。これらのファイルの場所を変更する方法については、「証明書ファイルの場所の変更」を参照してください。

  2. 次の keytool コマンドを入力することで、キーストアファイル keystore.jks 内に証明書を生成します。


    keytool -genkey -alias keyAlias-keyalg RSA
 -keypass changeit
 -storepass changeit
-keystore keystore.jks

    keyAlias には任意の一意名を指定します。キーストアまたは非公開鍵のパスワードをデフォルト以外の値に変更した場合には、前述のコマンドの changeit をその新しいパスワードで置き換えてください。デフォルトのキーパスワードエイリアスは「s1as」です。

    プロンプトが表示され、keytool が証明書の生成に使用するユーザーの名前、組織、およびその他の情報の入力を求められます。

  3. 次の keytool コマンドを入力することで、生成された証明書をファイル server.cer (または client.cer でもよい) にエクスポートします。


    keytool -export -alias keyAlias-storepass changeit
 -file server.cer
 -keystore keystore.jks

  4. 認証局によって署名された証明書が必要な場合は、「keytool ユーティリティーを使ってデジタル証明書に署名する」を参照してください。

  5. トラストストアファイル cacerts.jks を作成し、そのトラストストアに証明書を追加するには、次の keytool コマンドを入力します。


    keytool -import -v -trustcacerts
-alias keyAlias
 -file server.cer
-keystore cacerts.jks
 -keypass changeit

  6. キーストアまたは非公開鍵のパスワードをデフォルト以外の値に変更した場合には、前述のコマンドの changeit をその新しいパスワードで置き換えてください。

    このツールは、証明書に関する情報を表示し、その証明書を信頼するかどうかをユーザーに尋ねます。

  7. yes と入力し、続いて Enter キーを押します。

    すると、keytool から次のようなメッセージが表示されます。


    Certificate was added to keystore
[Saving cacerts.jks]

  8. Application Server を再起動します。

keytool ユーティリティーを使ってデジタル証明書に署名する

デジタル証明書の作成後、所有者はそれに署名して偽造を防止する必要があります。E コマースのサイト、または ID の認証が重要であるサイトは、既知の証明書発行局 (CA) から証明書を購入できます。認証に心配がない場合、たとえば、非公開のセキュアな通信だけが必要な場合などは、CA 証明書の取得に必要な時間と費用を節約して、自己署名付き証明書を使用してください。

  1. 証明書の鍵のペアを生成するため、CA の Web サイトの指示に従います。

  2. 生成された証明書の鍵のペアをダウンロードします。

    キーストアファイルとトラストストアファイルが格納されたディレクトリ (デフォルトでは domain-dir/config ディレクトリ) 内に、証明書を保存します。「証明書ファイルの場所の変更」を参照してください。

  3. 使用しているシェルで、証明書を含むディレクトリに変更します。

  4. keytool を使用して、証明書をローカルのキーストア、および必要に応じてローカルのトラストストアにインポートします。


    keytool -import -v -trustcacerts
-alias keyAlias
 -file server.cer
-keystore cacerts.jks
 -keypass changeit
-storepass changeit

    キーストアまたは非公開鍵のパスワードがデフォルト以外の値である場合には、前述のコマンドの changeit をその新しいパスワードで置き換えてください。

  5. Application Server を再起動します。

keytool ユーティリティーを使って証明書を削除する

既存の証明書を削除するには、keytool -delete コマンドを使用します。次に例を示します。

keytool -delete
 -alias keyAlias
 -keystore keystore-name
 -storepass password

NSS (Network Security Services) ツールの使用

クラスタおよびエンタープライズプロファイルの場合、サーバー側では、NSS (Network Security Services) デジタル証明書を使って非公開鍵と証明書を格納するデータベースを管理します。クライアント側 (アプリケーションクライアントまたはスタンドアロン) では、「JSSE (Java Secure Socket Extension) ツールの使用」で説明した JSSE 形式を使用します。

NSS (Network Security Services) を使ってセキュリティーを管理するためのツールは、次のとおりです。

これらのツールは as-install/lib/ ディレクトリに格納されています。NSS セキュリティーツールの場所を指し示すために、次の各環境変数が使用されます。

例に含まれる証明書の共通名 (CN) は、クライアントまたはサーバーの名前です。また、この CN は、SSL ハンドシェーク中に証明書の名前とその証明書の生成元であるホスト名とを比較する目的でも使用されます。SSL ハンドシェーク中に証明書名とホスト名が一致しなかった場合、警告または例外が生成されます。いくつかの例では便宜上、証明書の共通名 CN=localhost が使用されていますが、これは、すべてのユーザーが、実際のホスト名に基づいて新しい証明書を作成することなしにその証明書を使用できるようにするためです。

次の各節の例は、NSS ツールによる証明書処理に関する使用方法を示したものです。

certutil ユーティリティーの使用

certutil を実行する前に必ず、このユーティリティーを実行するために必要なライブラリの場所が LD_LIBRARY_PATH で指定されていることを確認してください。この場所は、asenv.conf (製品全体の設定ファイル) の AS_NSS_LIB の値から特定できます。

証明書データベースツールの certutil は、Netscape Communicator の cert8.db および key3.db データベースファイルを作成し、変更することができる NSS コマンド行ユーティリティーです。このユーティリティーは、cert8.db ファイルで、証明書の一覧表示、生成、変更、または削除を行い、key3.db ファイルで、パスワードの作成または変更、新しい公開鍵と非公開鍵のペアの生成、鍵データベースのコンテンツの表示、または鍵のペアの削除を行うこともできます。

通常、鍵と証明書の管理プロセスは鍵データベース内の鍵の作成から始まり、証明書データベース内の証明書の生成と管理に続きます。次のドキュメントでは、certutil ユーティリティーの構文を含む、NSS による証明書および鍵データベースの管理について説明しています。http://www.mozilla.org/projects/security/pki/nss/tools/certutil.html。

次の箇条書きの各項目は、NSS および JSSE セキュリティーツールを使って証明書の作成または管理、あるいはその両方を行う例を示したものです。

pk12util ユーティリティーによる証明書のインポートとエクスポート

証明書または鍵データベースと PKCS12 形式のファイル間における鍵と証明書のインポートおよびエクスポートに使用されるコマンド行ユーティリティーは、pk12util です。PKCS12 は、「Public-Key Cryptography Standards (PKCS) #12, Personal Information Exchange Syntax Standard」です。pk12util ユーティリティーの詳細については、http://www.mozilla.org/projects/security/pki/nss/tools/pk12util.html を参照してください。

modutil による PKCS11 モジュールの追加と削除

「セキュリティーモジュールデータベースツール」である modutil は、secmod.db ファイル内またはハードウェアトークン内の PKCS #11 (Cryptographic Token Interface Standard) モジュール情報を管理するためのコマンド行ユーティリティーです。このツールを使用して、PKCS #11 モジュールを追加および削除し、パスワードを変更し、デフォルトを設定し、モジュールの内容を表示し、スロットを使用可または使用不可にし、FIPS-140-1 準拠を有効または無効にし、暗号化操作にデフォルトのプロバイダを割り当てることができます。また、このツールを使用すれば、key3.db、cert7.db、および secmod.db セキュリティーデータベースファイルを作成することもできます。このツールの詳細については、http://www.mozilla.org/projects/security/pki/nss/tools/modutil.html を参照してください。

Application Server でのハードウェア暗号化アクセラレータの使用

ハードウェアアクセラレータトークンを使用すると、暗号化のパフォーマンスを向上させたり、セキュリティー保護された鍵ストレージ機能を備えたりすることができます。また、スマートカードを使用したモバイル用のセキュリティー保護された鍵ストレージを提供することもできます。

Sun Java System Application Server は、SSL 通信および TLS 通信用の PKCS#11 トークンと、鍵および PKCS#11 トークンを管理するための Network Security Services (NSS) ツールの使用をサポートします。この節では、Application Server によるサポートの提供方法と、関連設定の手順を説明します。

J2SE 5.0 PKCS#11 プロバイダは、簡単に Application Server ランタイムと統合できます。これらのプロバイダによって、ハードウェアアクセラレータなどの PKCS#11 トークンを Application Server で使用して、高速なパフォーマンスを実現したり、SSL 通信や TLS 通信での非公開鍵の継承を防いだりすることができます。

ここでは、次の内容について説明します。

ハードウェア暗号化アクセラレータの設定について

Sun Java System Application Server は、Sun Crypto Accelerator 1000 (SCA-1000) および SCA-4000 でテスト済みです。

Application Server, は、J2SE 5.0 と併用することにより、PKCS#11 トークンと通信できます。Application Server にパッケージされているのは、NSS PKCS#11 トークンライブラリ (NSS 内部 PKCS#11 モジュール用、一般に NSS ソフトトークンと呼ばれる) と、NSS コマンド行管理ツールです。詳細は、「NSS (Network Security Services) ツールの使用」を参照してください。

NSS ツールを使用して PKCS#11 トークンと J2SE PKCS#11 プロバイダに鍵と証明書を作成し、実行時にトークンの鍵と証明書にアクセスします。PKCS#11 プロバイダは、暗号化サービスプロバイダで、ネイティブ PKCS#11 ライブラリのラッパーとして動作します。一般に、PKCS#11 トークンは、ネイティブ PKCS#11 インタフェースを使用してすべてのハードウェアとソフトウェアを参照します。ハードウェアトークンは、ハードウェアアクセラレータやスマートカードなどの物理デバイスに実装された PKCS#11 トークンです。ソフトウェアトークンは、完全にソフトウェアに実装された PKCS#11 トークンです。

注 –

Application Server を J2SE 1.4.x プラットフォームで実行する場合、PKCS#11 トークンは 1 つだけ、つまり NSS ソフトトークンがサポートされます。

Microsoft Windows 環境では、NSS ライブラリの位置 AS_NSS と NSS ツールディレクトリ AS_NSS_BIN を PATH 環境変数に追加してください。簡単にするために、この節では UNIX のコマンドだけを使用して手順を説明します。必要に応じて UNIX 変数を Windows 変数に置き換えるようにしてください。

ハードウェア暗号化アクセラレータの設定は、主に次の 2 つの手順に分かれます。

PKCS#11 トークンの設定

ここでは、NSS セキュリティーツール modutil を使用して PKCS#11 トークンを設定する方法について説明します。次の手順で PKCS#11 トークンを設定します。

次のコマンドを入力します。すべて 1 行に入力してください。

modutil -dbdir AS_NSS_DB -nocertdb -force -add moduleName -libfile
 absolute_path_of_pkcs11_library -mechanisms list_of_security_mechanisms

ここで AS_NSS_DB は NSS データベースのディレクトリになり、ドメイン管理サーバー (DAS) を使用する場合には AS_DOMAIN_CONFIG と同じになります。

たとえば、ハードウェアアクセラレータトークンを設定するには、次のように入力します。すべて 1 行に入力してください。

modutil -dbdir AS_NSS_DB -nocertdb -force -add "Sun Crypto Accelerator" -libfile
 /opt/SUNWconn/crypto/lib/libpkcs11.so -mechanisms RSA:DSA:RC4:DES

この例のハードウェアアクセラレータは SCA–1000 暗号化アクセラレータです。対応する PKCS#11 ライブラリは、デフォルトでは /opt/SUNWconn/crypto/lib/libpkcs11.so にあります。

mechanisms は、トークンで利用可能な暗号化メカニズムの完全なリストにしてください。利用可能な暗号化メカニズムの一部だけを使用する方法については、「J2SE 5.0 PKCS#11 プロバイダの設定」を参照してください。サポートされるすべてのメカニズムのリストについては、NSS セキュリティーツールのサイト (http://www.mozilla.org/projects/security/pki/nss/tools) にある modutil のドキュメントを参照してください。

次の例では、トークンのインストール時に指定したトークン名がmytoken であるとします。

ハードウェアアクセラレータが正しく設定されていることを確認するには、次のコマンドを入力します。

modutil -list -dbdir AS_NSS_DB

標準出力表示は次のようになります。


Using database directory /var/opt/SUNWappserver/domains/domain1/config ...

Listing of PKCS#11 Modules
-----------------------------------------------------------
  1. NSS Internal PKCS#11 Module
         slots: 2 slots attached
        status: loaded

         slot: NSS Internal Cryptographic Services                            
        token: NSS Generic Crypto Services

         slot: NSS User Private Key and Certificate Services                  
        token: NSS Certificate DB

  2. Sun Crypto Accelerator
        library name: /opt/SUNWconn/crypto/lib/libpkcs11.so
         slots: 1 slot attached
        status: loaded

         slot: Sun Crypto Accelerator:mytoken
        token: mytoken
-----------------------------------------------------------

鍵と証明書の管理

ここでは、certutil と pk12util を使用して鍵や証明書を作成および管理する一般的な手順について説明します。certutil および pk12util の詳細については、「NSS (Network Security Services) ツールの使用」、および NSS セキュリティーツールのサイト (http://www.mozilla.org/projects/security/pki/nss/tools) を参照してください。

注 –

Java ランタイムの JAVA_HOME/jre/lib/security ディレクトリにある java.security プロパティーファイルで PKCS#11 プロバイダを設定することで、J2SE keytool ユーティリティーを使用して鍵や証明書を管理することもできます。keytool の使用の詳細は、http://java.sun.com/j2se/1.5.0/docs/guide/security/p11guide.html の『Java PKCS#11 Reference Guide』を参照してください。

ここで説明する内容は次のとおりです。

鍵や証明書の一覧表示

非公開鍵と証明書の操作

自己署名付き証明書の作成や、証明書のインポート/エクスポートには、certutil を使用します。非公開鍵をインポートまたはエクスポートするには、pk12util ユーティリティーを使用します。詳細は、「NSS (Network Security Services) ツールの使用」を参照してください。

注意 – 注意 –

Application Server では、certutil や modutil などの NSS ツールを使用して NSS パスワードを直接変更しないでください。そのようにすると、Application Server のセキュリティーデータが破損する可能性があります。

J2SE 5.0 PKCS#11 プロバイダの設定

Application Server は実行時に PKCS#11 トークン内にある鍵や証明書へのアクセスに、J2SE PKCS#11 プロバイダを使用します。デフォルトでは、Application Server では NSS ソフトトークン用に J2SE PKCS#11 プロバイダが設定されます。ここでは、J2SE PKCS#11 プロバイダのデフォルト設定をオーバーライドする方法について説明します。

Application Server では、PKCS#11 トークンごとに次のデフォルト PKCS#11 設定パラメータが生成されます。

これらの設定は、『Java PKCS#11 Reference Guide』で説明されている構文に従います。

注 –

name パラメータは、固有でなければならない場合を除き、必要ではありません。J2SE 5.0 の一部の以前のバージョンでは、英数字のみ使用できます。

デフォルトの設定パラメータをオーバーライドするには、カスタム設定ファイルを作成します。たとえば、SCA–1000 で RSA 暗号化方式と RSA 鍵ペアジェネレータを明示的に無効にすることができます。RSA 暗号化方式と RSA 鍵ペアジェネレータを無効にする詳細は、http://www.mozilla.org/projects/security/pki/nss/tools を参照してください。

カスタム設定ファイルを作成するには、次の手順に従います。

  1. 次のコードを記述した as-install/mypkcs11.cfg という設定ファイルを作成して保存します。


    name=HW1000
library=/opt/SUNWconn/crypto/lib/libpkcs11.so
slotListIndex=0
disabledMechanisms = {
&#9;CKM_RSA_PKCS
&#9;CKM_RSA_PKCS_KEY_PAIR_GEN
}
omitInitialize=true

  2. 必要に応じて NSS データベースを更新します。この場合は、RSA を無効にするために NSS データベースを更新します。

    以下のコマンドを実行します。


    modutil -undefault "Sun Crypto Accelerator" -dbdir AS_NSS_DB -mechanisms RSA

    mechanisms リストのアルゴリズム名は、デフォルト設定のアルゴリズム名とは異なります。NSS で有効な mechanisms のリストについては、NSS セキュリティーツールのサイト (http://www.mozilla.org/projects/security/pki/nss/tools) にある modutil のドキュメントを参照してください。

  3. 次のように、適切な位置にプロパティーを追加して、この変更でサーバーを更新します。


    &lt;property name="mytoken" value="&InstallDir;/mypkcs11.cfg"/>

    プロパティーの位置は、次のいずれかにします。

    • プロバイダが DAS またはサーバーインスタンス用である場合は、関連 &lt;security-service> の下にプロパティーを追加します。

    • プロバイダがノードエージェント用である場合は、domain.xml ファイルで関連 &lt;node-agent> 要素の下にプロパティーを追加します。

  4. Application Server を再起動します。

    カスタマイズされた設定が再起動後に有効になります。