test

Sun GlassFish Communications Server 2.0 管理ガイド

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

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

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

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

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

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

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

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

Java Platform, Standard Edition (Java SE) には、次の 2 つのセキュリティー管理用ツールがあります。

keytool、policytool、およびその他の Java セキュリティーツールの使用方法は、http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security の『JDK Tools and Utilities 』を参照してください。

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

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

Communications Server では、特定のドメインの仕様を収めるファイル domain.xml 内に、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. 該当するドメインの Communications Server を再起動します。

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

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

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

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

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

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


    asadmin change-master-password>
Please enter the master password>
Please enter the new master password>
Please enter the the new master password again>

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

    注意 – 注意 –

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

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

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

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

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

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

管理パスワードの変更

管理パスワードの暗号化については、「パスワードのセキュリティー管理」を参照してください。管理パスワードの暗号化は強く推奨されています。管理パスワードを暗号化する前に変更する場合は、change-admin-password コマンドを使用してください。

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

認証と承認について

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

エンティティーの認証

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

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

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

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

表 9–1 Communications Server の認証方法

認証方法

通信プロトコル

説明

ユーザー資格の暗号化

BASIC 

HTTP (オプションで SSL) 

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

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

FORM 

HTTP (オプションで SSL) 

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

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

CLIENT-CERT 

HTTPS (HTTP over SSL) 

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

SSL 

DIGEST 

HTTP および SIP 

サーバーは暗号化された応答に基づいてクライアントを認証します。 

SSL および TLS 

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

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

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

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

ユーザーの承認

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

JACC プロバイダの指定

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

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

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

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

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

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

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

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

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

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

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

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

注 –

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

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

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

ユーザー

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

グループ

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

ロール

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

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

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

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

レルム

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

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

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

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

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

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

JDBC レルムでは、サーバーはデータベースからユーザー資格を取得します。Communications Server は、データベース情報および設定ファイル内の有効化された JDBC レルムオプションを使用します。ダイジェスト認証では、jdbcDigestRealm を使用して JDBC レルムを JAAS コンテキストとして作成します。

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

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

ProcedureWeb、EJB、または SIP アプリケーションに対して JDBC レルムを設定する

Communications 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 ファイルを変更します。

    • SIP アプリケーションの場合は、sun-sip.xml ファイルを変更します。

      詳細は、TBDlink を参照してください。

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

    レルムの指定方法については、『Sun GlassFish Communications Server 2.0 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>

信頼設定およびエンティティー

ドメインとホストの間に信頼関係を構成するように設定を作成できます。信頼のタイプ、信頼されるホストまたはドメイン、およびメッセージの送受信に対して信頼関係を作成するかどうかを指定できます。

信頼設定およびエンティティーの作成

管理コンソールまたは CLI を使用して、アイデンティティーアサーションの信頼を作成できます。

管理コンソールで、「設定」ノードを展開し、設定を選択します。「セキュリティー」ノードを展開して、「トラスト設定」をクリックし、「新規」をクリックします。

または、asadmin create-trusted-entity および asadmin create-trust-config コマンドを使用することもできます。このコマンドの詳細は、TBDlink を参照してください。

信頼できるエンティティー (信頼できるホストまたはドメイン) を信頼設定に関連付けたり、Trust Handler を選択してカスタム実装で信頼を決定することができます。

信頼設定およびエンティティーの編集

信頼設定のプロパティーを編集するには、管理コンソールを使用するか、list、get、および set コマンドを次のように使用します。

ターゲットの信頼設定を一覧表示するには、list config-name.security-service.identity-assertion-trust.* コマンドを使用します。

信頼設定の属性を取得するには、get config-name.security-service.identity-assertion-trust. trust-config-name.* コマンドを使用します。

信頼設定のすべての属性については、TBDlink を参照してください。

設定中の信頼できるエンティティーを一覧表示するには、list config-name.security-service.identity-assertion-trust. trust-config-name.* コマンドを使用します。

信頼できるエンティティーのプロパティーを編集するには、管理コンソールを使用するか、list、get、および set コマンドを次のように使用します。

信頼できるエンティティーの属性を取得するには、get config-name.security-service.identity-assertion-trust. trust-config-name.trusted-entity.trusted-entity-name.* コマンドを使用します。

信頼できるエンティティーの属性を設定するには、set config-name.security-service.identity-assertion-trust. trust-config-name.trusted-entity.trusted-entity-name.ip-address=121.x.x.x コマンドを使用します。

信頼できるエンティティーのすべての属性については、TBDlink を参照してください。

証明書および 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) と呼ばれています。Communications Server は、SSL (Secure Sockets Layer) 3.0 および TLS (Transport Layer Security) 1.0 暗号化プロトコルをサポートしています。

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

暗号化方式について

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

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

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

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

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

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

「ファイアウォール」は、2 つ以上のネットワーク間のデータフローを制御し、ネットワーク間のリンクを管理します。ファイアウォールは、ハードウェア要素およびソフトウェア要素で構成できます。この節では、一般的ないくつかのファイアウォールアーキテクチャーとその設定について説明します。ここでの情報は、主に Communications 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 トランザクションを受け付けるように外部ファイアウォールを設定する必要があります。また、ファイアウォールの背後の Communications Server と通信する HTTP サーバープラグインを受け付けるように内部ファイアウォールを設定する必要があります。

証明書ファイルについて

Communications Server をインストールすると、内部テストに適した JSSE (Java Secure Socket Extension) または NSS (Network Security Services) 形式のデジタル証明書が生成されます。デフォルトでは、Communications 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) デジタル証明書を設定および操作します。開発者プロファイルの場合、Communications 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. Communications 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. Communications Server を再起動します。

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

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

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