test

Sun Java System Application Server Enterprise Edition 8.1 2005Q2 管理ガイド

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

この章では、アプリケーションサーバーの主なセキュリティー概念について説明したあと、Application Server のセキュリティーの設定方法について説明します。この章では、次の項目について説明します。

Application Server のセキュリティーについて

セキュリティーの概要

セキュリティーとはデータの保護に関することであり、ストレージ内または伝送中のデータへの不正アクセスやそうしたデータの破損をどのようにして防止するか、ということです。Application Server には、J2EE 標準に基づく動的で拡張可能なセキュリティーアーキテクチャーがあります。標準実装されているセキュリティー機能には、暗号化、認証と承認、および公開鍵インフラストラクチャーがあります。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」を参照してください。

Enterprise Edition では、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 のすべてのパスワードを暗号化できます。

Proceduredomain.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 を再起動します。

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

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

Procedureマスターパスワードを変更する

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

手順

  1. ドメインの Application 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. Application Server を再起動します。

    注意 – 注意 –

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

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

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

Procedure管理パスワードを変更する

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


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

管理コンソールを使って管理パスワードを変更することもできます。その手順を次に示します。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「レルム」ノードを展開します。

  5. admin-realm ノードを選択します。

  6. 「レルムを編集」ページで、「ユーザーを管理」ボタンをクリックします。

  7. admin という名前のユーザーを選択します。

  8. 新しいパスワードを入力し、そのパスワードをもう一度入力します。

  9. 「保存」をクリックして保存するか、「閉じる」をクリックして保存しないで閉じます。

セキュリティーの責任の割り当て

セキュリティーの責任は次のように割り当てます。

アプリケーション開発者

アプリケーション開発者は次の責任を負います。

アプリケーション開発者は、deploytool などのツールを使用してアプリケーション配備記述子を編集できます。これらのセキュリティータスクの詳細については、『J2EE 1.4 Tutorial』の「Security」の章 (http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) を参照してください。

アプリケーション配備担当者

アプリケーション配備担当者は次の責任を負います。

アプリケーション配備担当者は、deploytool などのツールを使用してアプリケーション配備記述子を編集できます。これらのセキュリティータスクの詳細については、『J2EE 1.4 Tutorial』の「Security」の章 (http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) を参照してください。

システム管理者

システム管理者は次の責任を負います。

システム管理者は、管理コンソールを使ってサーバーのセキュリティー設定を管理し、certutil を使って証明書を管理します。このマニュアルは主にシステム管理者を対象にしています。

認証と承認について

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

エンティティーの認証

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

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

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

「エンティティーの認証」で説明しているように、Application Server は 4 種類の認証をサポートします。アプリケーションは、配備記述子で使用する認証タイプを指定します。deploytool を使ってアプリケーションの認証メソッドを設定する方法の詳細については、http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html の『J2EE 1.4 Tutorial』を参照してください。

表 9–1 Application Server の認証メソッド

認証メソッド 

通信プロトコル 

説明 

ユーザー資格の暗号化 

基本 

HTTP (オプションで SSL) 

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

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

フォームベース 

HTTP (オプションで SSL) 

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

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

クライアント証明書 

HTTPS (HTTP over SSL) 

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

SSL 

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

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

シングルサインオンはグループに基づいています。配備記述子が同じ「グループ」を定義し、かつ同じ認証メソッド (基本、フォーム、ダイジェスト、証明書) を使用するすべての Web アプリケーションはシングルサインオンを共有します。

デフォルトでシングルサインオンは、Application Server に定義された仮想サーバーで有効です。シングルサインオンを無効にする方法については、「シングルサインオン (SSO) を設定する」を参照してください。

ユーザーの承認

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

JACC プロバイダの指定

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

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

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

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

Application Server は、「監査モジュール」によってすべての認証および承認の決定の監査トレールを提供します。Application Server は、デフォルトの監査モジュールのほか、監査モジュールのカスタマイズ機能も提供します。カスタム監査モジュールの開発の情報については、『Application Server Developer's Guide』を参照してください。

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

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

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

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

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

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

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 レルム、solaris レルム、またはカスタムレルムも設定できます。アプリケーションは、その配備記述子でレルムを指定して使用できます。レルムを指定しない場合、Application Server はデフォルトレルムを使用します。

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

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

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

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

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

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

証明書および 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 サーバープラグインを受け付けるように内部ファイアウォールを設定する必要があります。

管理コンソールによるセキュリティーの管理

管理コンソールは、セキュリティーの次の側面を管理する手段を提供します。

サーバーセキュリティー設定

「セキュリティー設定」ページでは、デフォルトレルム、匿名ロール、およびデフォルトの主体ユーザー名とパスワードの指定を含む、サーバー全体のプロパティーを設定します。詳細については、「セキュリティー設定を設定する」を参照してください。

レルムおよび file レルムユーザー

レルムの概念については、「ユーザー、グループ、ロール、およびレルムについて」で紹介しています。

これらのタスクの詳細については、「レルムに関する管理コンソールタスク」を参照してください。

JACC プロバイダ

JACC プロバイダについては、「JACC プロバイダの指定」で紹介しています。管理コンソールでは、次のタスクを実行します。

これらのタスクの詳細については、「JACC プロバイダに関する管理コンソールタスク」を参照してください。

監査モジュール

監査モジュールについては、「認証および承認の決定の監査」で紹介しています。監査は、エラーやセキュリティー違反などの重大なイベントが発生した場合に、それを後から調べることができるようにイベントを記録するメソッドです。Application Server のログにすべての認証イベントが記録されます。完全なアクセスログには、Application Server で行われるすべてのアクセスイベントが連続して記録されます。

管理コンソールでは、次のタスクを実行します。

これらのタスクの詳細については、「監査モジュールに関する管理コンソールタスク」を参照してください。

メッセージセキュリティー

メッセージセキュリティーの概念については、「メッセージセキュリティーの設定」で紹介しています。管理コンソールでは、次のタスクを実行します。

これらのタスクの詳細については、第 10 章「メッセージセキュリティーの設定」を参照してください。

HTTP および IIOP リスナーのセキュリティー

HTTP サービスの各仮想サーバーは、1 つまたは複数の「HTTP リスナー」を介してネットワーク接続を提供します。HTTP サービスおよび HTTP リスナーについての一般情報については、「HTTP サービスとは」を参照してください。

Application Server は、CORBA (Common Object Request Broker Architecture) オブジェクトをサポートしており、これはネットワークを介しての通信をするために IIOP (Internet Inter-Orb Protocol) を使用します。「IIOP リスナー」は、EJB コンポーネントのリモートクライアントおよびほかの CORBA ベースのクライアントから受信する接続を受け付けます。IIOP リスナーについての一般情報については、「IIOP リスナー」を参照してください。

管理コンソールでは、次のタスクを実行します。

これらのタスクの詳細については、「リスナーと JMX コネクタに関する管理コンソールタスク」を参照してください。

管理サービスのセキュリティー

管理サービスは、サーバーインスタンスが通常のインスタンスか、ドメイン管理サーバー (DAS) か、あるいは組み合わせかを決定します。管理サービスを使用して、JSR-160 準拠のリモート JMX コネクタを設定してください。これは、ドメイン管理サーバーとノードエージェントとの間の通信を処理し、ノードエージェントは、リモートサーバーインスタンスの代わりに、ホストマシンのサーバーインスタンスを管理します。

管理コンソールでは、次のタスクを実行します。

これらのタスクの詳細については、「管理サービスの JMX コネクタのセキュリティーを設定する」を参照してください。

セキュリティーマップ

コネクタ接続プールのセキュリティーマップの概念については、「セキュリティーマップについて」で紹介しています。管理コンソールでは、次のタスクを実行します。

これらのタスクの詳細については、「コネクタ接続プールに関する管理コンソールタスク」を参照してください。

セキュリティーに関する管理コンソールタスク

Procedureセキュリティー設定を設定する

管理コンソールの「セキュリティー」ページでは、システム全体のセキュリティー設定をさまざまに設定できます。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを選択します。

    「セキュリティー」ページが表示されます。

  4. 必要に応じて値を変更します。

    次の表では、一般的なセキュリティーオプションについて説明しています。

    設定 

    説明 

    監査ログ 

    選択すると監査ログが有効になります。有効な場合、サーバーは「監査モジュール」設定で指定されたすべての監査モジュールのロードおよび実行を行います。無効な場合、サーバーは監査モジュールにアクセスしません。デフォルトは無効です。 

    デフォルトレルム 

    サーバーが認証用に使用する有効な (デフォルト) レルム。アプリケーションは、配備記述子で異なるレルムを指定しないかぎり、このレルムを使用します。設定されているすべてのレルムがこのリストに表示されます。デフォルトの初期レルムは、file レルムです。

    匿名ロール 

    デフォルトまたは匿名ロールの名前。匿名ロールはすべてのユーザーに割り当てられます。アプリケーションは、配備記述子でこのロールを使用して任意の人に承認を付与することができます。 

    デフォルト主体 

    デフォルトのユーザー名を指定します。サーバーは、主体が指定されない場合にこれを使用します。このフィールドに値を入力する場合は、「デフォルト主体のパスワード」フィールドに対応する値を入力します。 

    この属性は通常のサーバー動作には不要です。 

    デフォルト主体のパスワード 

    「デフォルト主体」フィールドで指定したデフォルト主体のパスワード。 

    この属性は通常のサーバー動作には不要です。 

    JACC 

    設定されている JACC プロバイダのクラス名。「JACC プロバイダを作成する」を参照してください

    監査モジュール 

    コンマで区切られている、監査モジュールプロバイダのクラスのリスト。ここで表示されるモジュールは事前に設定しておく必要があります。監査ログが有効な場合、この設定で監査モジュールが表示される必要があります。デフォルトで、サーバーは default という名前の監査モジュールを使用します。新しい監査モジュールの作成方法については、「監査モジュールを作成する」を参照してください。

  5. 「追加プロパティー」セクションに、JVM (Java Virtual Machine) に渡すための追加プロパティーを入力します。

    有効なプロパティーは、「デフォルトレルム」フィールドで選択したレルムのタイプによって異なります。有効なプロパティーは、次の項目で説明されています。

  6. 「保存」を選択して変更を保存するか、または「デフォルトを読込み」を選択してデフォルト値を復元します。

Procedure管理ツールへのアクセスを許可する

asadmin グループのユーザーだけが、管理コンソールおよび asadmin コマンド行ユーティリティーにアクセスできます。

この管理ツールへのアクセスをユーザーに許可するには、ユーザーを admin-realm レルムの asadmin グループに追加してください。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「レルム」ノードを展開します。

  5. admin-realm ノードを選択します。

  6. 「レルムを編集」ページで、「ユーザーを管理」ボタンをクリックします。

    インストール後当初は、インストールの際に入力した管理者ユーザー名およびパスワードが admin-keyfile という名前のファイルに表示されます。このユーザーは、デフォルトで Application Server を変更する権限を付与される asadmin グループに属します。ユーザーに Application Server の管理者権限を付与する場合にかぎり、ユーザーをこのグループに割り当てます。

    ユーザーを admin-realm レルムに追加しても、ユーザーに割り当てるグループが asadmin 以外の場合、ユーザーの情報は admin-keyfile という名前のファイルに記述されますが、そのユーザーには file レルムの管理ツールまたはアプリケーションへのアクセス権はありません。

  7. 「新規」をクリックして、新しいユーザーを admin-realm レルムに追加します。

  8. 正確な情報を「ユーザー ID」、「パスワード」、および「グループ」フィールドに入力します。

    Application Server に変更を加えるユーザーを承認するには、「グループリスト」に asadmin グループを含めます。

  9. 「了解」をクリックして、このユーザーを admin-realm レルムに追加するか、または「取消し」をクリックして保存せずに終了します。

レルムに関する管理コンソールタスク

Procedureレルムを作成する

Application Server では、3 つのレルムが事前に設定されています。file、certificate、および admin-realm です。さらに、ldap レルム、solaris レルム、またはカスタムレルムも作成できます。一般に、1 つのサーバー上には各タイプのレルムが 1 つずつ存在しますが、Application Server 上には file レルムが 2つ存在します。file と admin-realm です。これらは、異なる 2 つの目的に使用される同じタイプの 2 つのレルムです。また、システムの各仮想サーバーで異なる証明書データベースを持つこともできます。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「レルム」ノードを選択します。

  5. 「レルム」ページで、「新規」をクリックします。

    「レルムを作成」ページが表示されます。

  6. 「名前」フィールドにレルムの名前を入力します。

  7. 作成するレルムのクラス名を指定します。

    有効な選択肢を次の表に示します。

    レルム名 

    クラス名 

    file

    com.sun.enterprise.security.auth.realm.file.FileRealm

    certificate

    com.sun.enterprise.security.auth.realm.certificate.CertificateRealm

    ldap

    com.sun.enterprise.security.auth.realm.ldap.LDAPRealm

    solaris

    com.sun.enterprise.security.auth.realm.solaris.SolarisRealm

    custom

    ログインレルムクラスの名前 

  8. レルムに必要なプロパティーおよび希望するオプションのプロパティーを追加します。

    1. 「プロパティーを追加」をクリックします。

    2. 「名前」フィールドに、プロパティーの名前を入力します。

    3. 「値」フィールドに、プロパティーの値を入力します。

  9. 「了解」をクリックします。

同機能を持つ asadmin コマンド

create-auth-realm

Procedureレルムを編集する

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「レルム」ノードを展開します。

  5. 既存のレルムの名前を選択します。

    「レルムを編集」ページが表示されます。

  6. 必要に応じて既存のプロパティーとその値を編集します。

  7. さらにプロパティーを追加するには、「プロパティーを追加」ボタンをクリックします。

    ページに新しい行が表示されます。有効なプロパティー名およびプロパティー値を入力します。

  8. 「保存」をクリックして変更を保存します。

Procedureレルムを削除する

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「レルム」ノードを選択します。

  5. 削除するレルムの横にあるボックスをクリックします。

  6. 「削除」をクリックします。

同機能を持つ asadmin コマンド

delete-auth-realm

Procedureデフォルトレルムを設定する

「デフォルトレルム」とは、アプリケーションの配備記述子がレルムを指定しない場合に、Application Server が認証と承認に使用するレルムです。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを選択します。

    「セキュリティー」ページが表示されます。

  4. 「デフォルトレルム」フィールドで、ドロップダウンリストから必要なレルムを選択します。

  5. 「保存」をクリックして変更を保存するか、または「デフォルトを読込み」をクリックして変更を削除し、Application Server のデフォルト値を復元します。

  6. コンソールに「再起動が必要です」と表示される場合は、サーバーを再起動します。

特定のレルムに関する追加情報

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

ldap レルムの作成

ldap レルムは、LDAP サーバーからの情報を使用して認証を行います。ユーザー情報には、ユーザー名、パスワード、およびユーザーが属するグループが含まれます。LDAP レルムを使用するには、ユーザーおよびグループを LDAP ディレクトリで事前に定義しておいてください。

LDAP レルムを作成するには、「レルムを作成する」の手順に従って新しいレルムを追加したあと、次の表に示したプロパティーを追加します。

表 9–2 ldap レルムに必要なプロパティー

プロパティー名 

説明 

値 

directory 

ディレクトリサーバーの LDAP URL。 

ldap://hostname:port という形式の LDAP URL。例: ldap://myldap.foo.com:389。

base-dn 

ユーザーデータの場所のベース DN (Distinguished Name)。ツリー範囲検索が実行されるため、ユーザーデータのレベルより上に置かれます。検索ツリーが小さければ小さいほど、パフォーマンスが向上します。 

検索用のドメイン。例: dc=siliconvalley, dc=BayArea, dc=sun, dc=com。

jaas-context 

このレルムに使用するログインモジュールのタイプ。 

ldapRealm が必須です。

ldap レルムのオプションのプロパティーを、次の表に示します。

表 9–3 ldap レルムのオプションのプロパティー

プロパティー名 

説明 

デフォルト 

search-filter 

ユーザー検索に使用される検索フィルタ。 

uid=%s (%s はサブジェクト名に展開される)。

group-base-dn 

グループデータの場所のベース DN。 

base-dn と同じですが、必要に応じて変更可能です。

group-search-filter 

ユーザーのグループメンバーシップ検索に使用する検索フィルタ。 

uniquemember=%d (%d はユーザー要素 DN に展開される)。

group-target 

グループ名エントリを含む LDAP の属性名。 

CN 

search-bind-dn 

search-filter 検索を実行するディレクトリの認証に使用するオプション DN。匿名検索を実行できないディレクトリにのみ必要になります。 

 

search-bind-password 

search-bind-dn で指定した DN の LDAP パスワード。

 

例

たとえば、次のように LDAP ユーザー、Joe Java が LDAP ディレクトリで定義されているとします。

uid=jjava,ou=People,dc=acme,dc=com
uid=jjava
givenName=joe
objectClass=top
objectClass=person
objectClass=organizationalPerson
objectClass=inetorgperson
sn=java
cn=Joe Java

ldap レルムの作成または編集をする際には、例示したコードを使用して、次の表で示す値を入力できます。

表 9–4 ldap レルムの値の例

プロパティー名 

プロパティー値 

directory

サーバーへの LDAP URL。例: ldap://ldap.acme.com:389

base-dn

ou=People,dc=acme,dc=com.

より上位に置くことも可能です (例: dc=acme、dc=com)。ただし、トラバースするツリーの範囲が広ければ、それだけパフォーマンスが低下します。

jaas-context

ldapRealm

solaris レルムの作成

solaris レルムは、システム設定で指定されているとおり、基礎となる Solaris ユーザーデータベースからユーザーおよびグループの情報を取得します。solaris レルムは、認証のための基礎となる PAM インフラストラクチャーを呼び出します。設定されている PAM モジュールに root 権限が必要な場合、ドメインはこのレルムを使用するため root として実行される必要があります。詳細については、セキュリティーサービスに関する Solaris ドキュメントを参照してください。

solaris には、1 つの必須プロパティー jaas-context があり、これは使用するログインモジュールのタイプを指定します。プロパティー値は solarisRealm である必要があります。

注 –

solaris レルムは Solaris 9 以降でのみサポートされています。

カスタムレルムの作成

4 つのビルトインレルムに加えて、ユーザーデータを、リレーショナルデータベースなどのほかの何らかの方法で格納するカスタムレルムも作成できます。カスタムレルムの作成は、このマニュアルの対象外です。詳細については、Application Server の『Developer's Guide』の「Securing Applications」の章を参照してください。

管理者として知っておく必要のある主な事柄は、カスタムレルムが、JAAS (Java Authentication and Authorization Service) パッケージから派生した LoginModule と呼ばれるクラスによって実装されていることです。

Procedureカスタムレルムを作成する

手順

  1. 「レルムを作成する」で概説した手順に従い、カスタムレルムの名前と LoginModule クラスの名前を入力します。

    myCustomRealm などの一意で任意の名前が、カスタムレルムに使用できます。

  2. 次の表に示すカスタムレルムのプロパティーを追加します。

    プロパティー名 

    プロパティー値 

    jaas-context 

    LoginModule クラス名。例: simpleCustomRealm

    auth-type 

    レルムの説明。例: 「カスタムレルムの分かりやすい例」。 

  3. 「了解」をクリックします。

  4. ドメインのログイン設定ファイル domain-dir/config/login.conf を編集し、このファイルの最後に JAAS LoginModule の完全修飾クラス名を次のように追加します。


    realmName {
    fully-qualified-LoginModule-classname required;
};

    次に例を示します。


    myCustomRealm {
    com.foo.bar.security.customrealm.simpleCustomLoginModule required;
};

  5. LoginModule クラスと依存するすべてのクラスを、ディレクトリ domain-dir/lib/classes にコピーします。

  6. コンソールに「再起動が必要です」と表示される場合は、サーバーを再起動します。

  7. レルムが正常にロードされたことを確認します。

    domain-dir/logs/server.logを開き、サーバーがレルムを読み込んだことを確認します。サーバーは、レルムの init() メソッドを呼び出す必要があります。

certificate レルムの編集

certificate レルムは、SSL 認証をサポートしています。このレルムは、Application Server のセキュリティーコンテキスト内にユーザー ID を設定したあと、トラストストアファイルとキーストアファイル内の暗号的に検証されたクライアント証明書からユーザーデータを取得し、それをそのユーザー ID に格納します ( 「証明書ファイルについて」を参照)。これらのファイルにユーザーを追加するには、certutil を使用します。

J2EE コンテナは、certificate レルムを使用して、証明書からの各ユーザーの DN (Distinguished Name) に基づいた承認処理を行います。DN とは、その公開鍵を証明書が識別するエンティティーの名前です。この名前には、X.500 標準が使用され、インターネット全体で一意であるように意図されています。キーストアおよびトラストストアの詳細については、 certutil のドキュメント (「NSS (Network Security Services) ツールの使用」)を参照してください。

次の表は、certificate レルムのオプションのプロパティーの一覧です。

表 9–5 certificate レルムのオプションのプロパティー

プロパティー 

説明 

assign-groups 

グループ名のコンマで区切られたリスト。有効な証明書を提出するすべてのクライアントがこのグループに割り当てられます。たとえば、employee,manager など。この場合、これらはユーザーグループの名前です。

jaas-context 

このレルムに使用するログインモジュールのタイプ。certificate レルムでは、この値は必ず certificateRealm にする必要があります。

file および admin-realm レルムの編集

サーバーは、file レルムの keyfile および admin-realm レルムの admin-keyfile という名前のファイルに、すべてのユーザー、グループ、およびパスワードの情報を保持します。どちらの場合も、file プロパティーを使って keyfile の場所を指定します。次の表に、file レルムに必要なプロパティーを示します。

表 9–6 file レルムに必要なプロパティー

プロパティー名 

説明 

デフォルト値 

file 

keyfile のフルパスおよび名前。 

domain-dir/config/keyfile

jaas-context 

このレルムに使用するログインモジュールのタイプ。 

fileRealm だけが有効な値です。

keyfile は最初は空のため、file レルムを使用する前にユーザーを追加する必要があります。手順については、「file レルムユーザーの管理」を参照してください。

admin-keyfile には最初、管理ユーザー名、暗号形式の管理パスワード、およびデフォルトで asadmin であるこのユーザーが属するグループが収められています。admin-realm にユーザーを追加する方法の詳細については、「管理ツールへのアクセスを許可する」を参照してください。

注 –

admin-realm のグループ asadmin のユーザーには、管理コンソールおよび asadmin ツールを使用する権限があります。このグループには、サーバーの管理権限のあるユーザーだけを追加してください。

NSS (Network Security Services) によるユーザーの管理

Enterprise Edition の場合にのみ、「file レルムユーザーの管理」で説明したように管理コンソールを使ってユーザーを管理することもできますし、NSS ツールを使ってユーザーを管理することもできます。NSS (Network Security Services) とは、セキュリティーが有効なクライアントおよびサーバーアプリケーションのクロスプラットフォーム開発をサポートするよう設計された一連のライブラリです。NSS で構築されたアプリケーションは、SSL v2 および v3、TLS、PKCS #5、PKCS #7、PKCS #11、PKCS #12、S/MIME、X.509 v3 証明書およびその他のセキュリティー標準をサポートできます。詳細については、次の URL を参照してください。

file レルムユーザーの管理

file レルムユーザーは管理コンソールで管理します。file レルムのユーザーおよびグループは keyfile で表示され、その場所は file プロパティーで指定されます。

注 –

この手順を使用して、admin-realm を含む任意の file レルムにユーザーを追加することもできます。この節で言及されている file レルムの代わりに、ターゲットレルムの名前を代入するだけです。

file レルムの各ユーザーは、特定の「J2EE グループ」に所属できます。J2EE グループは、共通の特性に基づいて分類されるユーザーのカテゴリです。たとえば、E コマースアプリケーションの顧客は CUSTOMER グループに属しますが、お得意様は PREFERRED グループに属します。ユーザーをグループに分類すると、ユーザーからの大量のアクセスを制御することが容易になります。

Application Server のインストール後の当初は、ユーザーはインストールの際に入力した管理者だけです。デフォルトで、このユーザーは Application Server を変更する権限を付与する admin-realm レルムの asadmin グループに属します。このグループに割り当てられるすべてのユーザーは、管理者権限が付与されます。つまり、asadmin ツールおよび管理コンソールへのアクセス権があります。

file レルムのユーザーを管理するには、次の各タスクを実行します。

Procedure「ファイルユーザー」ページにアクセスする

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「レルム」ノードを展開します。

  5. file ノードを選択します。

  6. 「レルムを編集」ページで、「ユーザーを管理」ボタンをクリックします。

    「ファイルユーザー」ページが表示されます。このページで、次のタスクを実行します。

Procedureユーザーを追加する

手順

  1. 「新規」をクリックして、新しいユーザーを file レルムに追加します。

  2. 「ファイルユーザー」ページで次の情報を入力します。

    • ユーザー ID (必須) - ユーザーの名前。

    • パスワード (必須) - ユーザーのパスワード。

    • パスワードの再入力 (必須) - ユーザーのパスワードの確認用再入力。

    • グループリスト (オプション) - ユーザーが属するグループのコンマで区切られたリスト。これらのグループをほかの場所で定義する必要はありません。

  3. 「了解」をクリックして、このユーザーを file レルムのユーザーのリストに追加します。「取消し」をクリックすると保存せずに終了します。

同機能を持つ asadmin コマンド

create-file-user

Procedureユーザー情報を編集する

手順

  1. 「ユーザー ID」列で、変更するユーザーの名前をクリックします。

    「ファイルレルムユーザーの編集」ページが表示されます。

  2. 「パスワード」および「パスワードの確認」フィールドに新しいパスワードを入力して、ユーザーのパスワードを変更します。

  3. 「グループ リスト」フィールドのグループを追加または削除して、ユーザーが属するグループを変更します。

    グループ名をコンマで区切ってください。グループを事前に定義する必要はありません。

  4. 「保存」をクリックして、このユーザーを file レルムのユーザーのリストに保存します。

    「閉じる」をクリックすると保存せずに終了します。

Procedureユーザーを削除する

手順

  1. 削除するユーザーの名前の左側にあるチェックボックスを選択します。

  2. 「削除」をクリックします。

  3. 「閉じる」をクリックすると「レルムを編集」ページに戻ります。

同機能を持つ asadmin コマンド

delete-file-user

相互認証の設定

相互認証では、サーバーとクライアント側の両方で認証が有効です。相互認証をテストするには、有効な証明書を持つクライアントが存在している必要があります。相互認証の詳細については、『J2EE 1.4 Tutorial』(http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) の「Security」の章を参照してください。

アプリケーションの相互 SSL 認証の有効化

特定のアプリケーションで相互認証を有効にするには、deploytool を使用して認証のメソッドを Client-Certificate に設定してください。deploytool の使用方法の詳細については、『J2EE 1.4 Tutorial』(http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) の「Security」の章を参照してください。

Procedureすべてのアプリケーションの相互認証を有効にする

Application Server は、HTTPS 認証に certificate レルムを使用します。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「レルム」ノードを展開します。

  5. certificate レルムを選択します。

  6. 「プロパティーを追加」ボタンをクリックします。

    1. 「名前」フィールドに、clientAuth を入力します。

    2. 「値」フィールドに、true を入力します。

  7. 「保存」をクリックします。

  8. コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。

    サーバーの再起動の後、certificate レルムを使用するすべてのアプリケーションでクライアント認証が必要になります。

JACC プロバイダに関する管理コンソールタスク

ProcedureJACC プロバイダを作成する

JACC (Java Authorization Contract for Containers) は J2EE 1.4 仕様の一部で、プラグイン可能な承認プロバイダ用のインタフェースを定義しています。これによって、管理者は認証を行うためにサードパーティー製の「プラグイン」モジュールを設定できます。デフォルトで、Application Server は JACC に準拠する単純なファイルベースの承認エンジンを提供します。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「JACC プロバイダ」ノードを選択します。

  5. 「JACC プロバイダ」ページで、「新規」をクリックします。

  6. 「JACC プロバイダを作成」ページで、次を入力します。

    • 名前 – このプロバイダの識別に使用する名前。

    • ポリシーの設定 – ポリシー設定ファクトリを実装するクラスの名前。デフォルトプロバイダは、com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl を使用します。

    • ポリシープロバイダ – ポリシーファクトリを実装するクラスの名前。デフォルトプロバイダは、com.sun.enterprise.security.provider.PolicyWrapper を使用します。

  7. 「プロパティーを追加」ボタンをクリックして、プロバイダにプロパティーを追加します。有効なプロパティーは次のとおりです。

    • repository – ポリシーファイルを含むディレクトリ。デフォルトプロバイダの場合、この値は ${com.sun.aas.instanceRoot}/generated/policy になります。

  8. 「了解」をクリックしてこの設定を保存するか、「取消し」をクリックして保存しないで終了します。

ProcedureJACC プロバイダを編集する

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「JACC プロバイダ」ノードを展開します。

  5. 編集する JACC プロバイダのノードを選択します。

  6. 「JACC プロバイダを編集」ページで、必要なプロバイダ情報の変更を行います。

    • ポリシーの設定 – ポリシー設定ファクトリを実装するクラスの名前。

    • ポリシープロバイダ – ポリシーファクトリを実装するクラスの名前。

  7. プロパティーを追加するには、「追加」ボタンをクリックします。プロパティーの名前および値を入力します。有効なエントリは次のとおりです。

    • repository – ポリシーファイルを含むディレクトリ。デフォルトプロバイダの場合、この値は ${com.sun.aas.instanceRoot}/generated/policy になります。

  8. 既存のプロパティーを削除するには、プロパティーの左側のチェックボックスをクリックして、「プロパティーを削除」をクリックします。

  9. 「保存」をクリックして保存するか、ブラウザの「戻る」ボタンをクリックして保存しないで取り消します。

ProcedureJACC プロバイダを削除する

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「JACC プロバイダ」ノードを選択します。

  5. 削除する JACC プロバイダの左側のチェックボックスをクリックします。

  6. 「削除」をクリックします。

Procedure有効な JACC プロバイダを設定する

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを選択します。

    「セキュリティー」ページが表示されます。

  4. 「JACC」フィールドに、サーバーが使用する JACC プロバイダの名前を入力します。

    使用可能な JACC プロバイダが分からない場合は、ツリーの「JACC プロバイダ」コンポーネントを展開して、設定されたすべての JACC プロバイダを表示します。

  5. 「保存」を選択して変更を保存するか、または「デフォルトを読込み」を選択してデフォルト値を復元します。

  6. コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。

監査モジュールに関する管理コンソールタスク

Procedure監査モジュールを作成する

Application Server は単純なデフォルト監査モジュールを提供します。詳細については、「デフォルト監査モジュールを使用する」を参照してください。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「監査モジュール」ノードを選択します。

  5. 「監査モジュール」ページで、「新規」をクリックします。

  6. 「監査モジュールを作成」ページで、次の情報を入力します。

    • 名前 – この監査モジュールの識別に使用する名前。

    • クラス名 – このモジュールを実装するクラスの完全修飾名。デフォルトの監査モジュールのクラス名は、com.sun.enterprise.security.Audit です。

  7. このモジュールに JVM プロパティーを追加するには、「プロパティーを追加」をクリックします。各プロパティーの名前および値を指定します。有効なプロパティーは次のとおりです。

    • auditOn - この実装クラスを有効にするかどうかを指定します。有効な値は true および false です。

  8. 「了解」をクリックしてエントリを保存するか、「取消し」をクリックして保存しないで終了します。

Procedure監査モジュールを編集する

監査モジュールはデフォルトではオンになりません。監査モジュールを有効にする方法の詳細については、「監査ログを有効または無効にする」を参照してください。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「監査モジュール」ノードを展開します。

  5. 編集する「監査モジュール」ノードをクリックします。

  6. 「監査モジュールを編集」ページで、必要に応じてクラス名を変更します。

  7. 「追加」ボタンを選択して、プロパティーの名前と値を入力し、モジュールの任意のプロパティーをさらに入力します。有効なプロパティーは次のとおりです。

    • auditOn - この監査モジュールを使用するかどうかを指定します。有効な値は true および false です。

  8. 変更する名前または値を選択して、変更を直接テキストフィールドに入力し、任意の既存のプロパティーを変更します。

  9. プロパティーの左側のチェックボックスを選択して、「プロパティーを削除」をクリックし、プロパティーを削除します。

  10. 「保存」をクリックして保存するか、ブラウザの「戻る」ボタンをクリックして保存しないで取り消します。

Procedure監査モジュールを削除する

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「監査モジュール」ノードを選択します。

  5. 削除する監査モジュールの左側のチェックボックスをクリックします。

  6. 「削除」をクリックします。

Procedure監査ログを有効または無効にする

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを選択します。

    「セキュリティー」ページが表示されます。

  4. ログを有効にするには、「監査ログ」チェックボックスを選択します。ログを無効にするには、選択を解除してください。

    このオプションを選択すると、監査モジュールが読み込まれ、Application Server の監査ライブラリによって監査モジュールが監査ポイントで確実に呼び出されます。

  5. 監査ログを有効にする場合には、「有効な監査モジュールを設定する」の説明に従ってデフォルトの監査モジュールを指定します。

  6. 「保存」を選択して変更を保存します。

  7. コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。

Procedure有効な監査モジュールを設定する

始める前に

サーバーが使用する監査モジュールを指定するには、まず、「監査ログを有効または無効にする」の説明に従って監査ログを有効にします。

手順

  1. 「監査モジュール」フィールドに、サーバーが使用する監査モジュールの名前を入力します。

    事前に設定された監査モジュールは default と呼ばれます。この監査モジュールの auditOn が true に設定されていることを確認してください。その方法は、「デフォルト監査モジュールを使用する」で説明しています。

  2. 「保存」を選択して変更を保存するか、「デフォルトを読込み」を選択して取り消します。

  3. コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。

Procedureデフォルト監査モジュールを使用する

default 監査モジュールは、認証および承認の要求をサーバーログファイルに記録します。ログファイルの場所を変更する方法については、「ログの一般設定を設定する」を参照してください。

認証ログエントリには、次の情報が含まれています。

監査ログが有効かどうかにかかわらず、Application Server はすべての拒否認証イベントを記録します。

承認ログエントリには、次の情報が含まれています。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「セキュリティー」ノードを展開します。

  4. 「監査モジュール」ノードを展開します。

  5. default ノードをクリックします。

  6. auditOn プロパティーの値を true に設定します。

  7. 「保存」を選択して変更を保存します。

  8. コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。

リスナーと JMX コネクタに関する管理コンソールタスク

ProcedureHTTP リスナーのセキュリティーを設定する

HTTP サービスの各仮想サーバーは、1 つまたは複数の「HTTP リスナー」を介してネットワーク接続を提供します。管理コンソールで、新しい HTTP リスナーを作成し、既存の HTTP リスナーのセキュリティー設定を編集します。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「HTTP サービス」ノードを展開します。

  4. 「HTTP リスナー」ノードを選択します。

  5. 特定の HTTP リスナーを選択してその既存リスナーを編集するか、「新規」をクリックし、「HTTP リスナーを作成する」の手順に従って新しいリスナーを作成します。

  6. 「リスナーのセキュリティープロパティーを設定する」の手順に従ってセキュリティープロパティーを設定します。

  7. 「保存」をクリックして変更を保存するか、ブラウザの「戻る」ボタンをクリックして保存しないで取り消します。

同機能を持つ asadmin コマンド

create-http-listener

ProcedureIIOP リスナーのセキュリティーを設定する

Application Server は、CORBA (Common Object Request Broker Architecture) オブジェクトをサポートしており、これはネットワークを介しての通信をするために IIOP (Internet Inter-Orb Protocol) を使用します。「IIOP リスナー」は、EJB コンポーネントのリモートクライアントおよびほかの CORBA ベースのクライアントから受信する接続を受け付けます。管理コンソールで、新しい IIOP リスナーを作成し、既存の IIOP リスナーの設定を編集します。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「ORB」ノードを展開します。

  4. 「IIOP リスナー」ノードを選択します。

  5. 特定の IIOP リスナーを選択してそのリスナーを編集するか、「新規」をクリックし、「IIOP リスナーを作成する」の手順に従って新しいリスナーを作成します。

  6. 「リスナーのセキュリティープロパティーを設定する」の手順に従ってセキュリティープロパティーを設定します。

  7. 「保存」をクリックして変更を保存するか、または「デフォルトを読込み」をクリックしてプロパティーのデフォルト値を復元します。

    新しいリスナーが作成されると、「IIOP リスナー」ページの「現在のリスナー」テーブルに、そのリスナーが表示されます。

同機能を持つ asadmin コマンド

create-iiop-listener

Procedure管理サービスの JMX コネクタのセキュリティーを設定する

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「管理サービス」ノードを展開します。

  4. 変更する管理サービスを選択します。

  5. 「リスナーのセキュリティープロパティーを設定する」の手順に従ってセキュリティープロパティーを設定します。

  6. 「保存」をクリックして変更を保存するか、または「デフォルトを読込み」をクリックしてプロパティーのデフォルト値を復元します。

Procedureリスナーのセキュリティープロパティーを設定する

この手順は、HTTP リスナー、IIOP リスナー、および JMX コネクタのセキュリティープロパティーに適用されます。

手順

  1. 「HTTP リスナーを編集」、「IIOP リスナーを編集」、または「JMX コネクタを編集」ページで、「SSL」というセクションに進みます。

  2. 「セキュリティー」フィールドの「有効」ボックスにチェックマークを付けて、このリスナーのセキュリティーを有効にします。このオプションを選択すると、有効にするセキュリティーのタイプを指定するため SSL3 または TLS を選択して、証明書のニックネームを入力する必要があります。

  3. このリスナーを使用する際、Application Server への認証を個々のクライアントに任せる場合は、「クライアント認証」フィールドの「有効」ボックスにチェックマークを付けます。

  4. 「有効」ボックスにチェックマークが付いている場合は、「証明書のニックネーム」フィールドにキーストアエイリアスを入力します。キーストアエイリアスは、既存のサーバーのキーペアと証明書を識別する単一の値です。デフォルトキーストアの証明書のニックネームは、s1as です。

    「証明書のニックネーム」を検索するには、「NSS (Network Security Services) ツールの使用」の説明に従って certutil ユーティリティーを使用します。

  5. 「有効」ボックスにチェックマークが付いている場合は、SSL3 および TLS またはそのいずれかを選択します。デフォルトでは、SSL3 と TLS のどちらも有効です。

  6. 必要に応じて、個別の暗号化方式群を有効にします。デフォルトでは、サポートされるすべての暗号化方式群が有効です。暗号化方式については、「暗号化方式について」を参照してください。

  7. 「保存」を選択して変更を保存するか、「デフォルトを読込み」を選択して取り消します。

仮想サーバーに関する管理コンソールセキュリティータスク

Procedureシングルサインオン (SSO) を設定する

シングルサインオンによって、複数のアプリケーションがユーザーのサインオン情報を共有できるため、ユーザーはアプリケーションごとにサインオンする必要がなくなります。シングルサインオンを使用するアプリケーションでは、一度ユーザーを認証すると、その認証情報はその他のすべての関連アプリケーションに伝達されます。

シングルサインオンは、同じレルムおよび仮想サーバーに設定された Web アプリケーションに適用されます。

注 –

シングルサインオンは、HTTP Cookie を使用して、各要求を保存されたユーザー ID に関連付けるトークンを送信するので、ブラウザクライアントが Cookie をサポートしている場合にのみ使用できます。

シングルサインオンは、次の規則に従って動作します。

手順

  1. 管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。

  2. 設定するインスタンスを選択します。

    • 特定のインスタンスを設定するには、そのインスタンスの設定ノードを展開します。たとえば、デフォルトインスタンス server の場合は、server-config ノードを展開します。

    • すべてのインスタンスのデフォルト値を設定するには、default-config ノードを展開します。

  3. 「HTTP サービス」ノードを展開します。

  4. 「仮想サーバー」ノードを展開し、シングルサインオンのサポートのために設定が必要な仮想サーバーを選択します。

  5. 「プロパティーを追加」をクリックします。

    空白のプロパティーエントリがリストの下部に追加されます。

  6. 「名前」フィールドに、sso-enable を入力します。

  7. 「値」フィールドに false を入力すると SSO が無効になり、true を入力すると SSO が有効になります。

    デフォルトで、SSO は有効です。

  8. 「プロパティーを追加」をクリックし、該当する任意の SSO プロパティーを設定することで、その他のシングルサインオンのプロパティーの追加または変更を行います。

    次の表では、仮想サーバーの有効な SSO プロパティーについて説明します。

    プロパティー名 

    説明 

    値 

    sso-max-inactive-seconds

    クライアントが活動を停止後、ユーザーのシングルサインオンの記録を削除可能にするまでの秒数。仮想サーバーの任意のアプリケーションへアクセスすることで、シングルサインオンの記録は有効なまま保持されます。 

    デフォルトは 300 秒 (5 分) です。値を大きくすると、ユーザーの持続時間も長くなりますが、サーバー上のメモリーの消費量も増大します。 

    sso-reap-interval-seconds

    有効期限が切れたシングルサインオンの記録の削除を行う間隔 (秒単位)。 

    デフォルトは 60 です。 

  9. 「保存」をクリックします。

  10. コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。

コネクタ接続プールに関する管理コンソールタスク

コネクタ接続プールについて

「コネクタモジュール」は、リソースアダプタとも呼ばれ、J2EE アプリケーションが EIS (Enterprise Information System) と対話することを可能にします。「コネクタリソース」はアプリケーションに EIS への接続を提供します。「コネクタ接続プール」とは、特定の EIS のための再利用可能な接続のグループです。

「セキュリティーマップ」は、J2EE ユーザーおよびグループと EIS ユーザーおよびグループ間のマッピングの作成を可能にします。管理コンソールを使用して、コネクタ接続プールのセキュリティーマップの作成、更新、一覧表示、および削除を行ってください。

注 –

このコンテキストでは、ユーザーは主体と呼ばれます。EIS (Enterprise Information System) は情報を保持する任意のシステムです。これは、メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションのいずれかになります。

セキュリティーマップについて

セキュリティーマップを使用して、コンテナ管理トランザクションベースのシナリオで、アプリケーション (主体またはユーザーグループ) の呼び出し側 ID を適切な EIS 主体に割り当ててください。アプリケーション主体が EIS に要求を開始すると、アプリケーションサーバーは最初に、マッピングされたバックエンドのEIS 主体を特定す るために、コネクタ接続プールに定義されたセキュリティーマップを使用して正確な主体を確認します。完全に一致するものがない場合、アプリケーションサーバーは、ワイルドカード文字の指定があればそれを使用して、マッピングされたバックエンドの EIS 主体を特定します。セキュリティーマップは、アプリケーションユーザーが、EIS の特定の ID として実行することを要求される EIS 動作を実行する必要がある場合に使用されます。

セキュリティーマップを管理するには、管理コンソールで次の各手順を実行してください。

Procedureセキュリティーマップを作成する

コネクタ接続プールのセキュリティーマップは、アプリケーションユーザーおよびグループ (主体) を EIS 主体に割り当てます。アプリケーションユーザーが EIS の特定の ID を必要とする EIS 動作の実行を必要とする場合は、セキュリティーマップを使用してください。

手順

  1. 「リソース」ノードを展開します。

  2. 「コネクタ」ノードを展開します。

  3. 「コネクタ接続プール」ノードを選択します。

  4. 特定のコネクタ接続プールを選択するために現在のプールのリストからその名前を選択するか、新しいコネクタ接続プールを作成するために現在のプールのリストから「新規」を選択し、「JDBC 接続プールを作成する」の手順に従います。

  5. 「セキュリティーマップ」ページを選択します。

  6. 「新規」をクリックして、新しいセキュリティーマップを作成します。

  7. 「セキュリティーマップ」ページで、次のプロパティーを入力します。

    • 名前 – この特定のセキュリティーマップの参照に使用する名前を入力します。

    • ユーザーグループ – 適切な EIS 主体にマッピングされるアプリケーションの呼び出し側 ID。アプリケーション固有のユーザーグループのコンマで区切られたリストを入力するか、またはすべてのユーザーやすべてのユーザーグループを指定するワイルドカードアスタリスク (*) を入力します。「主体」オプションまたは「ユーザーグループ」オプションを指定しますが、両方は指定しません。

    • 主体 – 適切な EIS 主体にマッピングされるアプリケーションの呼び出し側 ID。アプリケーション固有の主体のコンマで区切られたリストを入力するか、またはすべての主体を指定するワイルドカードアスタリスク (*) を入力します。「主体」オプションまたは「ユーザーグループ」オプションを指定しますが、両方は指定しません。

  8. 「バックエンド主体」セクションで、次のプロパティーを入力します。

    • ユーザー名 – EIS のユーザー名を入力します。EIS (Enterprise Information System) は情報を保持する任意のシステムです。これは、メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションである可能性があります。

    • パスワード – EIS ユーザーのパスワードを入力します。

  9. 「了解」をクリックしてセキュリティーマップを作成するか、「取消し」をクリックして保存しないで取り消します。

同機能を持つ asadmin コマンド

create-connector-security-map

Procedureセキュリティーマップを編集する

手順

  1. 「リソース」ノードを展開します。

  2. 「コネクタ」ノードを展開します。

  3. 「コネクタ接続プール」ノードを選択します。

  4. 現在のプールのリストから名前を選択することで、「コネクタ接続プール」を選択します。

  5. 「セキュリティーマップ」ページを選択します。

  6. 「セキュリティーマップ」ページで、現在のセキュリティーマップのリストからセキュリティーマップを選択します。

  7. 「セキュリティーマップを編集」ページで、必要に応じて次のプロパティーを変更します。

    • ユーザーグループ – 適切な EIS 主体にマッピングされるアプリケーションの呼び出し側 ID。アプリケーション固有のユーザーグループのコンマで区切られたリストを入力するか、またはすべてのグループやすべてのユーザーグループを指定するワイルドカードアスタリスク (*) を入力します。「主体」オプションまたは「ユーザーグループ」オプションを指定しますが、両方は指定しません。

    • 主体 – 適切な EIS 主体にマッピングされるアプリケーションの呼び出し側 ID。アプリケーション固有の主体のコンマで区切られたリストを入力するか、またはすべての主体を指定するワイルドカードアスタリスク (*) を入力します。「主体」オプションまたは「ユーザーグループ」オプションを指定しますが、両方は指定しません。

  8. 「バックエンド主体」セクションで、次のプロパティーを入力します。

    • ユーザー名 – EIS のユーザー名を入力します。EIS (Enterprise Information System) は情報を保持する任意のシステムです。これは、メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションである可能性があります。

    • パスワード – EIS ユーザーのパスワードを入力します。

  9. 「保存」をクリックして、セキュリティーマップの変更を保存します。

有用な asadmin コマンド

list-connector-security-maps および update-connector-security-maps

Procedureセキュリティーマップを削除する

手順

  1. 「リソース」ノードを展開します。

  2. 「コネクタ」ノードを展開します。

  3. 「コネクタ接続プール」ノードを選択します。

  4. 現在のプールのリストから名前を選択することで、「コネクタ接続プール」を選択します。

  5. 「セキュリティーマップ」ページを選択します。

  6. 「セキュリティーマップ」ページで、削除するセキュリティーマップの名前の左側にあるチェックボックスをクリックします。

  7. 「削除」をクリックします。

同機能を持つ asadmin コマンド

delete-connector-security-map

証明書と SSL の操作

証明書ファイルについて

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

Procedure証明書ファイルの場所を変更する

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

手順

  1. 管理コンソール ツリーコンポーネントで、「設定」ノードを展開します。

  2. 「server-config (管理設定)」ノードを展開します。

  3. 「JVM 設定」 ノードを選択します。

  4. 「JVM オプション」タブをクリックします。

  5. 「JVM オプション」ページで、「値」フィールドの次の値を追加または変更して、証明書ファイルの新しい場所を反映させます。


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

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

  6. 「保存」をクリックします。

  7. コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。

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

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

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

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

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

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

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

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 をその新しいパスワードで置き換えてください。

    プロンプトが表示され、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

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

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

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

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


    Certificate was added to keystore
[Saving cacerts.jks]

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

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

デジタル証明書の作成後、所有者はそれに署名して偽造を防止する必要があります。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

-delete コマンドで利用可能なオプションの完全な一覧については、http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/keytool.html の keytool ドキュメントを参照してください。

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

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

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

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

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

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

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

証明書データベースツールの 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 を参照してください。

詳細情報