この章では、アプリケーションサーバーの主なセキュリティー概念について説明したあと、Application Server のセキュリティーの設定方法について説明します。この章では、次の項目について説明します。
セキュリティーとはデータの保護に関することであり、ストレージ内または伝送中のデータへの不正アクセスやそうしたデータの破損をどのようにして防止するか、ということです。Application Server には、J2EE 標準に基づく動的で拡張可能なセキュリティーアーキテクチャーがあります。標準実装されているセキュリティー機能には、暗号化、認証と承認、および公開鍵インフラストラクチャーがあります。Application Server は Java セキュリティーモデルをベースに構築され、アプリケーションが安全に動作できるサンドボックスを使用するため、システムやユーザーにリスクが及ぶ可能性がありません。説明する項目は次のとおりです。
概して、2 種類のアプリケーションセキュリティーがあります。
「プログラムによるセキュリティー」。開発者が記述したアプリケーションコードがセキュリティー動作を処理します。管理者が、このメカニズムを操作する必要はまったくありません。一般的に、プログラムによるセキュリティーは、J2EE コンテナで管理するのではなく、アプリケーションのセキュリティー設定をハードコード化するのでお勧めできません。
「宣言によるセキュリティー」。Application Server のコンテナがアプリケーションの配備記述子によりセキュリティーを処理します。宣言によるセキュリティーは、配備記述子を直接または deploytool などのツールで編集することによって操作できます。配備記述子はアプリケーションの開発後に変更可能なので、宣言によるセキュリティーの方が柔軟性に富んでいます。
アプリケーションによるセキュリティーのほかに、Application Server システムのアプリケーション全体に影響するシステムセキュリティーもあります。
プログラムによるセキュリティーはアプリケーション開発者により制御されるため、このマニュアルでは説明していません。宣言によるセキュリティーについては、このマニュアルである程度説明しています。このマニュアルは、主にシステム管理者を対象としているため、システムセキュリティーを中心に説明しています。
Application Server には次のセキュリティー管理用ツールがあります。
管理コンソール。サーバー全体のセキュリティー設定、ユーザー、グループ、レルムの管理、およびほかのシステム全体のセキュリティータスクの実行に使用するブラウザベースのツール。管理コンソールの概要については、「管理用ツール」を参照してください。管理コンソールで実行可能なセキュリティータスクの概要については、「管理コンソールによるセキュリティーの管理」を参照してください。
asadmin。管理コンソールと同じタスクの多くを行うコマンド行ツール。管理コンソールからできない操作でも、asadmin を使用して操作できる場合があります。コマンドプロンプトまたはスクリプトのいずれかから asadmin コマンドを実行して、繰り返しのタスクを自動化します。asadminの概要については、「管理用ツール」を参照してください。
deploytool。個別のアプリケーションセキュリティーを制御するために、アプリケーション配備記述子を編集するグラフィカルパッケージ化ツールおよび配備ツール。deploytool はアプリケーション開発者を対象にしているため、このマニュアルでは使用方法の詳細な説明はしていません。deploytool の使用手順については、このツールのオンラインヘルプおよび http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html の『J2EE 1.4 Tutorial』を参照してください。
Java 2 プラットフォーム、J2SE (Java 2 Standard Edition) には、次の 2 つのセキュリティー管理用ツールがあります。
keytool。デジタル証明書および鍵のペアの管理に使用するコマンド行ユーティリティー。keytool は、certificate レルムのユーザー管理に使用します。
policytool。システム全体の Java セキュリティーポリシー管理に使用するグラフィカルユーティリティー。管理者が policytool を使用することはほとんどありません。
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。証明書または鍵データベースと PKCS12 形式のファイル間における鍵と証明書のインポートおよびエクスポートに使用されるコマンド行ユーティリティー。
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-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 コマンドのマニュアルページを参照してください。
domain.xml のパスワードの削除および置き換えを行います。これは、asadmin set コマンドを使用して行います。このような目的での set コマンドの使用例は、次のとおりです。
asadmin set --user admin server.jms-service.jms-host. default_JMS_host.admin-password=${ALIAS=jms-password} |
該当するドメインの Application Server を再起動します。
ファイルの中にはエンコード化されたパスワードを含むものがあり、ファイルシステムのアクセス権を使用しての保護が必要になります。これらのファイルには次のものが含まれます。
domain-dir/master-password
このファイルにはエンコード化されたマスターパスワードが含まれているので、ファイルシステムのアクセス権 600 で保護する必要があります。
asadmin への --passwordfile 引数を使用して、引数として渡すために作成されたすべてのパスワードファイル。これらは、ファイルシステムのアクセス権 600 で保護する必要があります。
マスターパスワード (MP) とは、全体で共有するパスワードです。これを認証に使用したり、ネットワークを介して送信したりすることは決してありません。このパスワードはセキュリティー全体の要なので、ユーザーが必要に応じて手動で入力したり、またはファイルに隠蔽したりすることができます。これは、システムで最高の機密データです。ユーザーは、このファイルを削除することで、強制的に MP の入力を要求できます。マスターパスワードが変更されると、マスターパスワードキーストアに再保存されます。
ドメインの 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> |
Application Server を再起動します。
この時点で、実行中のサーバーインスタンスを開始してはいけません。対応するノードエージェントの SMP が変更されるまでは、決して実行中のサーバーインスタンスを再起動しないでください。SMP が変更される前にサーバーインスタンスを再起動すると、起動に失敗します。
各ノードエージェントおよび関連するサーバーを 1 つずつ停止します。asadmin change-master-password コマンドをもう一度実行してから、ノードエージェントおよび関連するサーバーを再起動してください。
すべてのノードエージェントで対応が終了するまで、次のノードエージェントで同様の作業を継続します。このようにして、継続的な変更作業が完了します。
管理パスワードの暗号化については、「パスワードのセキュリティー管理」を参照してください。管理パスワードの暗号化は強く推奨されています。管理パスワードを暗号化する前に変更する場合は、asadmin set コマンドを使用してください。このような目的での set コマンドの使用例は、次のとおりです。
asadmin set --user admin server.jms-service.jms-host.default_JMS_host.admin-password=new_pwd |
管理コンソールを使って管理パスワードを変更することもできます。その手順を次に示します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「レルム」ノードを展開します。
admin-realm ノードを選択します。
「レルムを編集」ページで、「ユーザーを管理」ボタンをクリックします。
admin という名前のユーザーを選択します。
新しいパスワードを入力し、そのパスワードをもう一度入力します。
「保存」をクリックして保存するか、「閉じる」をクリックして保存しないで閉じます。
セキュリティーの責任は次のように割り当てます。
アプリケーション開発者は次の責任を負います。
アプリケーションコンポーネントに対するロールおよびロールベースのアクセス制限の指定。
アプリケーションの認証メソッドの定義およびセキュリティー保護が行われるアプリケーションの各部の指定。
アプリケーション開発者は、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) を参照してください。
システム管理者は次の責任を負います。
セキュリティーレルムの設定。
ユーザーアカウントおよびグループの管理。
監査ログの管理。
サーバー証明書の管理およびサーバーの SSL (Secure Sockets Layer) の使用の設定。
コネクタ接続プールのセキュリティーマップ、その他の JACC プロバイダなど、その他のシステム全体のセキュリティー機能の管理。
システム管理者は、管理コンソールを使ってサーバーのセキュリティー設定を管理し、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 (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 レイヤーのメッセージセキュリティープロバイダを使用して、メッセージセキュリティーを実装します。メッセージセキュリティープロバイダは、要求メッセージおよび応答メッセージに必要な認証のタイプなどの情報を提供します。サポートされている認証には次のタイプが含まれます。
ユーザー名とパスワード認証を含む送信者認証。
XML デジタル署名を含むコンテンツ認証。
このリリースには、2 つのメッセージセキュリティープロバイダが付属しています。メッセージセキュリティープロバイダは、SOAP レイヤーの認証用に設定されます。設定可能なプロバイダには、ClientProvider と ServerProvider があります。
メッセージレイヤーセキュリティーのサポートは、プラグイン可能な認証モジュールの形式で Application Server とそのクライアントコンテナに統合されています。Application Server では、メッセージレイヤーセキュリティーはデフォルトで無効になっています。
メッセージレベルのセキュリティーは、Application Server 全体または特定のアプリケーションあるいはメソッドに対して設定できます。Application Server レベルのメッセージセキュリティーの設定については、第 10 章「メッセージセキュリティーの設定」を参照してください。アプリケーションレベルのメッセージセキュリティーの設定については、『Developer’s Guide』の「Securing Applications」の章で説明されています。
Application Server は次のエンティティーに対して認証および承認ポリシーを実施します。
「ユーザー」: 「Application Server で定義される」個別の ID。一般に、ユーザーとは、人物、エンタープライズ Bean などのソフトウェアコンポーネント、またはサービスを意味します。認証されたユーザーを「主体」と呼ぶ場合もあります。また、ユーザーが「被認証者」と呼ばれる場合もあります。
「グループ」: 「Application Server で定義される」一連のユーザー。共通の特性に基づいて分類されます。
「ロール」: アプリケーションによって定義される名前付きの承認レベル。ロールは錠を開ける鍵にたとえられます。多くの人が鍵のコピーを所持している場合があります。錠は、だれがアクセスを求めるかに関わらず、適切な鍵が使用される場合だけ対応します。
「レルム」: ユーザーとグループの情報、および関連するセキュリティー資格を含むリポジトリ。レルムは、「セキュリティーポリシードメイン」とも呼ばれます。
ユーザーおよびグループは Application Server 全体で指定されますが、各アプリケーションは独自のロールを定義します。アプリケーションがパッケージ化されて配備される場合、次の図に例示されているように、アプリケーションはユーザーまたはグループとロールとの間のマッピングを指定します。
「ユーザー」とは、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 のドキュメントを参照してください。
カスタムレルムとは、リレーショナルデータベースやサードパーティー製のコンポーネントなどその他のユーザー資格のリポジトリです。詳細については、「カスタムレルムの作成」を参照してください。
この節では、次の項目について説明します。
「デジタル証明書」(または単に証明書) とは、インターネット上の人物やリソースを一意に識別する電子ファイルです。さらに証明書は 2 つのエンティティー間の安全で機密保護された通信を可能にします。
個人により使用される個人証明書や SSL (Secure Sockets Layer) テクノロジでサーバーとクライアント間の安全なセッションを確立するために使用されるサーバー証明書など、さまざまな種類の証明書があります。SSL の詳細については、「SSL (Secure Sockets Layer) について」を参照してください。
証明書は「公開鍵暗号化」に基づき、意図した受信者だけが解読できるようデジタルの「鍵」 (非常に長い数値) のペアを使用して「暗号化」、または符号化します。そして受信者は、情報を「復号化」して解読します。
鍵のペアには公開鍵と非公開鍵が含まれます。所有者は公開鍵を配布して、だれでも利用できるようにします。しかし、所有者は非公開鍵を決して配布せず、常時秘密にしておきます。鍵は数学的に関連しているので、1 つの鍵で暗号化されたデータは、そのペアのもう 1 つの鍵でだけ復号化ができます。
証明書とはパスポートのようなものです。所有者を識別し、その他の重要な情報を提供します。証明書は、「証明書発行局」(CA) と呼ばれる、信頼できるサードパーティーが発行します。CA はパスポートセンターに似ています。CA は、証明書の所有者の身元を確認したあと、偽造や改ざんができないように証明書に署名します。いったん CA が証明書に署名すると、所有者は ID の証明としてこれを提出することで、暗号化され、機密保護された通信を確立できます。
最も重要な点は、証明書によって所有者の公開鍵が所有者の ID と結び付けられることです。パスポートが写真とその所有者についての個人情報を結び付けるように、証明書は公開鍵とその所有者についての情報を結び付けます。
公開鍵のほかに、通常、証明書には次のような情報が含まれています。
所有者の名前、および証明書を使用する Web サーバーの URL や個人のメールアドレスなどその他の識別情報。
証明書が発行された CA の名前。
有効期限の日付。
デジタル証明書は、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) とは、インターネットの通信およびトランザクションのセキュリティー保護で最も普及している標準仕様です。Web アプリケーションは HTTPS (HTTP over SSL) を使用します。HTTPS は、サーバーとクライアント間のセキュアで機密保護された通信を確保するため、デジタル証明書を使用します。SSL 接続では、クライアントとサーバーの両方が送信前にデータを暗号化し、受信するとそれを復号化します。
クライアントの Web ブラウザがセキュアなサイトに接続する場合、次のように「SSL ハンドシェーク」が行われます。
ブラウザはネットワークを介してセキュアなセッションを要求するメッセージを送信します。通常は、http ではなく https で始まる URL を要求します。
サーバーは、公開鍵を含む証明書を送信することで応答します。
ブラウザは、サーバーの証明書が有効であること、またサーバーの証明書が証明書をブラウザのデータベースに持つ信頼されている CA によって署名されていることを検証します。さらに、CA の証明書の有効期限が切れていないことも検証します。
証明書が有効な場合、ブラウザは 1 回限りの一意の「セッション鍵」を生成し、サーバーの公開鍵でそれを暗号化します。そして、ブラウザは暗号化されたセッション鍵をサーバーに送信し、両方でコピーを持てるようにします。
サーバーは、非公開鍵を使用してメッセージを復号化し、セッション鍵を復元します。
ハンドシェークの後、クライアントは 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 プロバイダの削除または変更
これらのタスクの詳細については、「JACC プロバイダに関する管理コンソールタスク」を参照してください。
監査モジュールについては、「認証および承認の決定の監査」で紹介しています。監査は、エラーやセキュリティー違反などの重大なイベントが発生した場合に、それを後から調べることができるようにイベントを記録するメソッドです。Application Server のログにすべての認証イベントが記録されます。完全なアクセスログには、Application Server で行われるすべてのアクセスイベントが連続して記録されます。
管理コンソールでは、次のタスクを実行します。
新しい監査モジュールの追加
既存の監査モジュールの削除または変更
これらのタスクの詳細については、「監査モジュールに関する管理コンソールタスク」を参照してください。
メッセージセキュリティーの概念については、「メッセージセキュリティーの設定」で紹介しています。管理コンソールでは、次のタスクを実行します。
メッセージセキュリティーの有効化
メッセージセキュリティープロバイダの設定
既存のメッセージセキュリティー設定またはプロバイダの削除または設定
これらのタスクの詳細については、第 10 章「メッセージセキュリティーの設定」を参照してください。
HTTP サービスの各仮想サーバーは、1 つまたは複数の「HTTP リスナー」を介してネットワーク接続を提供します。HTTP サービスおよび HTTP リスナーについての一般情報については、「HTTP サービスとは」を参照してください。
Application Server は、CORBA (Common Object Request Broker Architecture) オブジェクトをサポートしており、これはネットワークを介しての通信をするために IIOP (Internet Inter-Orb Protocol) を使用します。「IIOP リスナー」は、EJB コンポーネントのリモートクライアントおよびほかの CORBA ベースのクライアントから受信する接続を受け付けます。IIOP リスナーについての一般情報については、「IIOP リスナー」を参照してください。
管理コンソールでは、次のタスクを実行します。
新しい HTTP または IIOP リスナーの作成と、それを使用するセキュリティーの指定
既存のHTTP または IIOP リスナーのセキュリティー設定の変更
これらのタスクの詳細については、「リスナーと JMX コネクタに関する管理コンソールタスク」を参照してください。
管理サービスは、サーバーインスタンスが通常のインスタンスか、ドメイン管理サーバー (DAS) か、あるいは組み合わせかを決定します。管理サービスを使用して、JSR-160 準拠のリモート JMX コネクタを設定してください。これは、ドメイン管理サーバーとノードエージェントとの間の通信を処理し、ノードエージェントは、リモートサーバーインスタンスの代わりに、ホストマシンのサーバーインスタンスを管理します。
管理コンソールでは、次のタスクを実行します。
管理サービスの管理
JMX コネクタの編集
JMX コネクタのセキュリティー設定の変更
これらのタスクの詳細については、「管理サービスの JMX コネクタのセキュリティーを設定する」を参照してください。
コネクタ接続プールのセキュリティーマップの概念については、「セキュリティーマップについて」で紹介しています。管理コンソールでは、次のタスクを実行します。
既存のコネクタ接続プールへのセキュリティーマップの追加
既存のセキュリティーマップの削除または設定
これらのタスクの詳細については、「コネクタ接続プールに関する管理コンソールタスク」を参照してください。
管理コンソールの「セキュリティー」ページでは、システム全体のセキュリティー設定をさまざまに設定できます。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを選択します。
「セキュリティー」ページが表示されます。
必要に応じて値を変更します。
次の表では、一般的なセキュリティーオプションについて説明しています。
設定 |
説明 |
---|---|
監査ログ |
選択すると監査ログが有効になります。有効な場合、サーバーは「監査モジュール」設定で指定されたすべての監査モジュールのロードおよび実行を行います。無効な場合、サーバーは監査モジュールにアクセスしません。デフォルトは無効です。 |
デフォルトレルム |
サーバーが認証用に使用する有効な (デフォルト) レルム。アプリケーションは、配備記述子で異なるレルムを指定しないかぎり、このレルムを使用します。設定されているすべてのレルムがこのリストに表示されます。デフォルトの初期レルムは、file レルムです。 |
匿名ロール |
デフォルトまたは匿名ロールの名前。匿名ロールはすべてのユーザーに割り当てられます。アプリケーションは、配備記述子でこのロールを使用して任意の人に承認を付与することができます。 |
デフォルト主体 |
デフォルトのユーザー名を指定します。サーバーは、主体が指定されない場合にこれを使用します。このフィールドに値を入力する場合は、「デフォルト主体のパスワード」フィールドに対応する値を入力します。 この属性は通常のサーバー動作には不要です。 |
デフォルト主体のパスワード |
「デフォルト主体」フィールドで指定したデフォルト主体のパスワード。 この属性は通常のサーバー動作には不要です。 |
JACC |
設定されている JACC プロバイダのクラス名。「JACC プロバイダを作成する」を参照してください |
監査モジュール |
コンマで区切られている、監査モジュールプロバイダのクラスのリスト。ここで表示されるモジュールは事前に設定しておく必要があります。監査ログが有効な場合、この設定で監査モジュールが表示される必要があります。デフォルトで、サーバーは default という名前の監査モジュールを使用します。新しい監査モジュールの作成方法については、「監査モジュールを作成する」を参照してください。 |
「追加プロパティー」セクションに、JVM (Java Virtual Machine) に渡すための追加プロパティーを入力します。
有効なプロパティーは、「デフォルトレルム」フィールドで選択したレルムのタイプによって異なります。有効なプロパティーは、次の項目で説明されています。
「保存」を選択して変更を保存するか、または「デフォルトを読込み」を選択してデフォルト値を復元します。
asadmin グループのユーザーだけが、管理コンソールおよび asadmin コマンド行ユーティリティーにアクセスできます。
この管理ツールへのアクセスをユーザーに許可するには、ユーザーを admin-realm レルムの asadmin グループに追加してください。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「レルム」ノードを展開します。
admin-realm ノードを選択します。
「レルムを編集」ページで、「ユーザーを管理」ボタンをクリックします。
インストール後当初は、インストールの際に入力した管理者ユーザー名およびパスワードが admin-keyfile という名前のファイルに表示されます。このユーザーは、デフォルトで Application Server を変更する権限を付与される asadmin グループに属します。ユーザーに Application Server の管理者権限を付与する場合にかぎり、ユーザーをこのグループに割り当てます。
ユーザーを admin-realm レルムに追加しても、ユーザーに割り当てるグループが asadmin 以外の場合、ユーザーの情報は admin-keyfile という名前のファイルに記述されますが、そのユーザーには file レルムの管理ツールまたはアプリケーションへのアクセス権はありません。
「新規」をクリックして、新しいユーザーを admin-realm レルムに追加します。
正確な情報を「ユーザー ID」、「パスワード」、および「グループ」フィールドに入力します。
Application Server に変更を加えるユーザーを承認するには、「グループリスト」に asadmin グループを含めます。
「了解」をクリックして、このユーザーを admin-realm レルムに追加するか、または「取消し」をクリックして保存せずに終了します。
Application Server では、3 つのレルムが事前に設定されています。file、certificate、および admin-realm です。さらに、ldap レルム、solaris レルム、またはカスタムレルムも作成できます。一般に、1 つのサーバー上には各タイプのレルムが 1 つずつ存在しますが、Application Server 上には file レルムが 2つ存在します。file と admin-realm です。これらは、異なる 2 つの目的に使用される同じタイプの 2 つのレルムです。また、システムの各仮想サーバーで異なる証明書データベースを持つこともできます。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「レルム」ノードを選択します。
「レルム」ページで、「新規」をクリックします。
「レルムを作成」ページが表示されます。
「名前」フィールドにレルムの名前を入力します。
作成するレルムのクラス名を指定します。
有効な選択肢を次の表に示します。
レルム名 |
クラス名 |
---|---|
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 |
ログインレルムクラスの名前 |
レルムに必要なプロパティーおよび希望するオプションのプロパティーを追加します。
「プロパティーを追加」をクリックします。
「名前」フィールドに、プロパティーの名前を入力します。
file レルムのプロパティーについては、「file および admin-realm レルムの編集」を参照してください。
certificate レルムのプロパティーについては、「certificate レルムの編集」を参照してください。
ldap レルムのプロパティーについては、「ldap レルムの作成」を参照してください。
solaris レルムのプロパティーについては、「solaris レルムの作成」を参照してください。
カスタムレルムのプロパティーについては、「カスタムレルムの作成」を参照してください。
「値」フィールドに、プロパティーの値を入力します。
「了解」をクリックします。
create-auth-realm
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「レルム」ノードを展開します。
既存のレルムの名前を選択します。
「レルムを編集」ページが表示されます。
必要に応じて既存のプロパティーとその値を編集します。
さらにプロパティーを追加するには、「プロパティーを追加」ボタンをクリックします。
ページに新しい行が表示されます。有効なプロパティー名およびプロパティー値を入力します。
file レルムのプロパティーについては、「file および admin-realm レルムの編集」を参照してください。
certificate レルムのプロパティーについては、「certificate レルムの編集」を参照してください。
ldap レルムのプロパティーについては、「ldap レルムの作成」を参照してください。
solaris レルムのプロパティーについては、「solaris レルムの作成」を参照してください。
カスタムレルムのプロパティーについては、「カスタムレルムの作成」を参照してください。
「保存」をクリックして変更を保存します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「レルム」ノードを選択します。
削除するレルムの横にあるボックスをクリックします。
「削除」をクリックします。
delete-auth-realm
「デフォルトレルム」とは、アプリケーションの配備記述子がレルムを指定しない場合に、Application Server が認証と承認に使用するレルムです。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを選択します。
「セキュリティー」ページが表示されます。
「デフォルトレルム」フィールドで、ドロップダウンリストから必要なレルムを選択します。
「保存」をクリックして変更を保存するか、または「デフォルトを読込み」をクリックして変更を削除し、Application Server のデフォルト値を復元します。
コンソールに「再起動が必要です」と表示される場合は、サーバーを再起動します。
この節では、次の項目について説明します。
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 レルムは、認証のための基礎となる 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 と呼ばれるクラスによって実装されていることです。
「レルムを作成する」で概説した手順に従い、カスタムレルムの名前と LoginModule クラスの名前を入力します。
myCustomRealm などの一意で任意の名前が、カスタムレルムに使用できます。
次の表に示すカスタムレルムのプロパティーを追加します。
プロパティー名 |
プロパティー値 |
---|---|
jaas-context |
LoginModule クラス名。例: simpleCustomRealm |
auth-type |
レルムの説明。例: 「カスタムレルムの分かりやすい例」。 |
「了解」をクリックします。
ドメインのログイン設定ファイル domain-dir/config/login.conf を編集し、このファイルの最後に JAAS LoginModule の完全修飾クラス名を次のように追加します。
realmName { fully-qualified-LoginModule-classname required; }; |
次に例を示します。
myCustomRealm { com.foo.bar.security.customrealm.simpleCustomLoginModule required; }; |
LoginModule クラスと依存するすべてのクラスを、ディレクトリ domain-dir/lib/classes にコピーします。
コンソールに「再起動が必要です」と表示される場合は、サーバーを再起動します。
レルムが正常にロードされたことを確認します。
domain-dir/logs/server.logを開き、サーバーがレルムを読み込んだことを確認します。サーバーは、レルムの init() メソッドを呼び出す必要があります。
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 レルムの 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 ツールを使用する権限があります。このグループには、サーバーの管理権限のあるユーザーだけを追加してください。
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 を参照してください。
NSS (Network Security Services) については、http://www.mozilla.org/projects/security/pki/nss/
NSS セキュリティーツールについては、http://www.mozilla.org/projects/security/pki/nss/tools/
NSS の概要については、http://www.mozilla.org/projects/security/pki/nss/overview.html
file レルムユーザーは管理コンソールで管理します。file レルムのユーザーおよびグループは keyfile で表示され、その場所は file プロパティーで指定されます。
この手順を使用して、admin-realm を含む任意の file レルムにユーザーを追加することもできます。この節で言及されている file レルムの代わりに、ターゲットレルムの名前を代入するだけです。
file レルムの各ユーザーは、特定の「J2EE グループ」に所属できます。J2EE グループは、共通の特性に基づいて分類されるユーザーのカテゴリです。たとえば、E コマースアプリケーションの顧客は CUSTOMER グループに属しますが、お得意様は PREFERRED グループに属します。ユーザーをグループに分類すると、ユーザーからの大量のアクセスを制御することが容易になります。
Application Server のインストール後の当初は、ユーザーはインストールの際に入力した管理者だけです。デフォルトで、このユーザーは Application Server を変更する権限を付与する admin-realm レルムの asadmin グループに属します。このグループに割り当てられるすべてのユーザーは、管理者権限が付与されます。つまり、asadmin ツールおよび管理コンソールへのアクセス権があります。
file レルムのユーザーを管理するには、次の各タスクを実行します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「レルム」ノードを展開します。
file ノードを選択します。
「レルムを編集」ページで、「ユーザーを管理」ボタンをクリックします。
「ファイルユーザー」ページが表示されます。このページで、次のタスクを実行します。
「新規」をクリックして、新しいユーザーを file レルムに追加します。
「ファイルユーザー」ページで次の情報を入力します。
ユーザー ID (必須) - ユーザーの名前。
パスワード (必須) - ユーザーのパスワード。
パスワードの再入力 (必須) - ユーザーのパスワードの確認用再入力。
グループリスト (オプション) - ユーザーが属するグループのコンマで区切られたリスト。これらのグループをほかの場所で定義する必要はありません。
「了解」をクリックして、このユーザーを file レルムのユーザーのリストに追加します。「取消し」をクリックすると保存せずに終了します。
create-file-user
「ユーザー ID」列で、変更するユーザーの名前をクリックします。
「ファイルレルムユーザーの編集」ページが表示されます。
「パスワード」および「パスワードの確認」フィールドに新しいパスワードを入力して、ユーザーのパスワードを変更します。
「グループ リスト」フィールドのグループを追加または削除して、ユーザーが属するグループを変更します。
グループ名をコンマで区切ってください。グループを事前に定義する必要はありません。
「保存」をクリックして、このユーザーを file レルムのユーザーのリストに保存します。
「閉じる」をクリックすると保存せずに終了します。
delete-file-user
相互認証では、サーバーとクライアント側の両方で認証が有効です。相互認証をテストするには、有効な証明書を持つクライアントが存在している必要があります。相互認証の詳細については、『J2EE 1.4 Tutorial』(http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) の「Security」の章を参照してください。
特定のアプリケーションで相互認証を有効にするには、deploytool を使用して認証のメソッドを Client-Certificate に設定してください。deploytool の使用方法の詳細については、『J2EE 1.4 Tutorial』(http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html) の「Security」の章を参照してください。
Application Server は、HTTPS 認証に certificate レルムを使用します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「レルム」ノードを展開します。
certificate レルムを選択します。
「プロパティーを追加」ボタンをクリックします。
「保存」をクリックします。
コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。
サーバーの再起動の後、certificate レルムを使用するすべてのアプリケーションでクライアント認証が必要になります。
JACC (Java Authorization Contract for Containers) は J2EE 1.4 仕様の一部で、プラグイン可能な承認プロバイダ用のインタフェースを定義しています。これによって、管理者は認証を行うためにサードパーティー製の「プラグイン」モジュールを設定できます。デフォルトで、Application Server は JACC に準拠する単純なファイルベースの承認エンジンを提供します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「JACC プロバイダ」ノードを選択します。
「JACC プロバイダ」ページで、「新規」をクリックします。
「JACC プロバイダを作成」ページで、次を入力します。
名前 – このプロバイダの識別に使用する名前。
ポリシーの設定 – ポリシー設定ファクトリを実装するクラスの名前。デフォルトプロバイダは、com.sun.enterprise.security.provider.PolicyConfigurationFactoryImpl を使用します。
ポリシープロバイダ – ポリシーファクトリを実装するクラスの名前。デフォルトプロバイダは、com.sun.enterprise.security.provider.PolicyWrapper を使用します。
「プロパティーを追加」ボタンをクリックして、プロバイダにプロパティーを追加します。有効なプロパティーは次のとおりです。
repository – ポリシーファイルを含むディレクトリ。デフォルトプロバイダの場合、この値は ${com.sun.aas.instanceRoot}/generated/policy になります。
「了解」をクリックしてこの設定を保存するか、「取消し」をクリックして保存しないで終了します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「JACC プロバイダ」ノードを展開します。
編集する JACC プロバイダのノードを選択します。
「JACC プロバイダを編集」ページで、必要なプロバイダ情報の変更を行います。
ポリシーの設定 – ポリシー設定ファクトリを実装するクラスの名前。
ポリシープロバイダ – ポリシーファクトリを実装するクラスの名前。
プロパティーを追加するには、「追加」ボタンをクリックします。プロパティーの名前および値を入力します。有効なエントリは次のとおりです。
repository – ポリシーファイルを含むディレクトリ。デフォルトプロバイダの場合、この値は ${com.sun.aas.instanceRoot}/generated/policy になります。
既存のプロパティーを削除するには、プロパティーの左側のチェックボックスをクリックして、「プロパティーを削除」をクリックします。
「保存」をクリックして保存するか、ブラウザの「戻る」ボタンをクリックして保存しないで取り消します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「JACC プロバイダ」ノードを選択します。
削除する JACC プロバイダの左側のチェックボックスをクリックします。
「削除」をクリックします。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを選択します。
「セキュリティー」ページが表示されます。
「JACC」フィールドに、サーバーが使用する JACC プロバイダの名前を入力します。
使用可能な JACC プロバイダが分からない場合は、ツリーの「JACC プロバイダ」コンポーネントを展開して、設定されたすべての JACC プロバイダを表示します。
「保存」を選択して変更を保存するか、または「デフォルトを読込み」を選択してデフォルト値を復元します。
コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。
Application Server は単純なデフォルト監査モジュールを提供します。詳細については、「デフォルト監査モジュールを使用する」を参照してください。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「監査モジュール」ノードを選択します。
「監査モジュール」ページで、「新規」をクリックします。
「監査モジュールを作成」ページで、次の情報を入力します。
名前 – この監査モジュールの識別に使用する名前。
クラス名 – このモジュールを実装するクラスの完全修飾名。デフォルトの監査モジュールのクラス名は、com.sun.enterprise.security.Audit です。
このモジュールに JVM プロパティーを追加するには、「プロパティーを追加」をクリックします。各プロパティーの名前および値を指定します。有効なプロパティーは次のとおりです。
auditOn - この実装クラスを有効にするかどうかを指定します。有効な値は true および false です。
「了解」をクリックしてエントリを保存するか、「取消し」をクリックして保存しないで終了します。
監査モジュールはデフォルトではオンになりません。監査モジュールを有効にする方法の詳細については、「監査ログを有効または無効にする」を参照してください。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「監査モジュール」ノードを展開します。
編集する「監査モジュール」ノードをクリックします。
「監査モジュールを編集」ページで、必要に応じてクラス名を変更します。
「追加」ボタンを選択して、プロパティーの名前と値を入力し、モジュールの任意のプロパティーをさらに入力します。有効なプロパティーは次のとおりです。
auditOn - この監査モジュールを使用するかどうかを指定します。有効な値は true および false です。
変更する名前または値を選択して、変更を直接テキストフィールドに入力し、任意の既存のプロパティーを変更します。
プロパティーの左側のチェックボックスを選択して、「プロパティーを削除」をクリックし、プロパティーを削除します。
「保存」をクリックして保存するか、ブラウザの「戻る」ボタンをクリックして保存しないで取り消します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「監査モジュール」ノードを選択します。
削除する監査モジュールの左側のチェックボックスをクリックします。
「削除」をクリックします。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを選択します。
「セキュリティー」ページが表示されます。
ログを有効にするには、「監査ログ」チェックボックスを選択します。ログを無効にするには、選択を解除してください。
このオプションを選択すると、監査モジュールが読み込まれ、Application Server の監査ライブラリによって監査モジュールが監査ポイントで確実に呼び出されます。
監査ログを有効にする場合には、「有効な監査モジュールを設定する」の説明に従ってデフォルトの監査モジュールを指定します。
「保存」を選択して変更を保存します。
コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。
サーバーが使用する監査モジュールを指定するには、まず、「監査ログを有効または無効にする」の説明に従って監査ログを有効にします。
「監査モジュール」フィールドに、サーバーが使用する監査モジュールの名前を入力します。
事前に設定された監査モジュールは default と呼ばれます。この監査モジュールの auditOn が true に設定されていることを確認してください。その方法は、「デフォルト監査モジュールを使用する」で説明しています。
「保存」を選択して変更を保存するか、「デフォルトを読込み」を選択して取り消します。
コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。
default 監査モジュールは、認証および承認の要求をサーバーログファイルに記録します。ログファイルの場所を変更する方法については、「ログの一般設定を設定する」を参照してください。
認証ログエントリには、次の情報が含まれています。
認証を試みたユーザーの名前。
アクセス要求を処理したレルム。
要求された Web モジュール URI または EJB コンポーネント。
要求の成功または失敗。
監査ログが有効かどうかにかかわらず、Application Server はすべての拒否認証イベントを記録します。
承認ログエントリには、次の情報が含まれています。
承認されたユーザーの名前 (ある場合)。
要求された Web URI または EJB コンポーネント。
要求の成功または失敗。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「セキュリティー」ノードを展開します。
「監査モジュール」ノードを展開します。
default ノードをクリックします。
auditOn プロパティーの値を true に設定します。
「保存」を選択して変更を保存します。
コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。
HTTP サービスの各仮想サーバーは、1 つまたは複数の「HTTP リスナー」を介してネットワーク接続を提供します。管理コンソールで、新しい HTTP リスナーを作成し、既存の HTTP リスナーのセキュリティー設定を編集します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「HTTP サービス」ノードを展開します。
「HTTP リスナー」ノードを選択します。
特定の HTTP リスナーを選択してその既存リスナーを編集するか、「新規」をクリックし、「HTTP リスナーを作成する」の手順に従って新しいリスナーを作成します。
「リスナーのセキュリティープロパティーを設定する」の手順に従ってセキュリティープロパティーを設定します。
「保存」をクリックして変更を保存するか、ブラウザの「戻る」ボタンをクリックして保存しないで取り消します。
create-http-listener
Application Server は、CORBA (Common Object Request Broker Architecture) オブジェクトをサポートしており、これはネットワークを介しての通信をするために IIOP (Internet Inter-Orb Protocol) を使用します。「IIOP リスナー」は、EJB コンポーネントのリモートクライアントおよびほかの CORBA ベースのクライアントから受信する接続を受け付けます。管理コンソールで、新しい IIOP リスナーを作成し、既存の IIOP リスナーの設定を編集します。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「ORB」ノードを展開します。
「IIOP リスナー」ノードを選択します。
特定の IIOP リスナーを選択してそのリスナーを編集するか、「新規」をクリックし、「IIOP リスナーを作成する」の手順に従って新しいリスナーを作成します。
「リスナーのセキュリティープロパティーを設定する」の手順に従ってセキュリティープロパティーを設定します。
「保存」をクリックして変更を保存するか、または「デフォルトを読込み」をクリックしてプロパティーのデフォルト値を復元します。
新しいリスナーが作成されると、「IIOP リスナー」ページの「現在のリスナー」テーブルに、そのリスナーが表示されます。
create-iiop-listener
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「管理サービス」ノードを展開します。
変更する管理サービスを選択します。
「リスナーのセキュリティープロパティーを設定する」の手順に従ってセキュリティープロパティーを設定します。
「保存」をクリックして変更を保存するか、または「デフォルトを読込み」をクリックしてプロパティーのデフォルト値を復元します。
この手順は、HTTP リスナー、IIOP リスナー、および JMX コネクタのセキュリティープロパティーに適用されます。
「HTTP リスナーを編集」、「IIOP リスナーを編集」、または「JMX コネクタを編集」ページで、「SSL」というセクションに進みます。
「セキュリティー」フィールドの「有効」ボックスにチェックマークを付けて、このリスナーのセキュリティーを有効にします。このオプションを選択すると、有効にするセキュリティーのタイプを指定するため SSL3 または TLS を選択して、証明書のニックネームを入力する必要があります。
このリスナーを使用する際、Application Server への認証を個々のクライアントに任せる場合は、「クライアント認証」フィールドの「有効」ボックスにチェックマークを付けます。
「有効」ボックスにチェックマークが付いている場合は、「証明書のニックネーム」フィールドにキーストアエイリアスを入力します。キーストアエイリアスは、既存のサーバーのキーペアと証明書を識別する単一の値です。デフォルトキーストアの証明書のニックネームは、s1as です。
「証明書のニックネーム」を検索するには、「NSS (Network Security Services) ツールの使用」の説明に従って certutil ユーティリティーを使用します。
「有効」ボックスにチェックマークが付いている場合は、SSL3 および TLS またはそのいずれかを選択します。デフォルトでは、SSL3 と TLS のどちらも有効です。
必要に応じて、個別の暗号化方式群を有効にします。デフォルトでは、サポートされるすべての暗号化方式群が有効です。暗号化方式については、「暗号化方式について」を参照してください。
「保存」を選択して変更を保存するか、「デフォルトを読込み」を選択して取り消します。
シングルサインオンによって、複数のアプリケーションがユーザーのサインオン情報を共有できるため、ユーザーはアプリケーションごとにサインオンする必要がなくなります。シングルサインオンを使用するアプリケーションでは、一度ユーザーを認証すると、その認証情報はその他のすべての関連アプリケーションに伝達されます。
シングルサインオンは、同じレルムおよび仮想サーバーに設定された Web アプリケーションに適用されます。
シングルサインオンは、HTTP Cookie を使用して、各要求を保存されたユーザー ID に関連付けるトークンを送信するので、ブラウザクライアントが Cookie をサポートしている場合にのみ使用できます。
シングルサインオンは、次の規則に従って動作します。
ユーザーが Web アプリケーションの保護対象リソースにアクセスする場合、サーバーはユーザーに、Web アプリケーションで定義されているメソッドを使用してユーザー自身を認証するよう要求します。
一度認証されると、Application Server は仮想サーバーの Web アプリケーション全体の承認決定用のユーザーに関連付けられたロールを使用するので、ユーザーを個別のアプリケーションごとに認証する必要はありません。
ユーザーが 1 つの Web アプリケーションから明示的に、またはセッションの有効期限が切れたためにログアウトすると、すべての Web アプリケーションで、そのユーザーのセッションが無効になります。その後ユーザーが任意のアプリケーションの保護対象リソースにアクセスするには、ログインする必要があります。
管理コンソールのツリーコンポーネントで、「設定」ノードを展開します。
設定するインスタンスを選択します。
「HTTP サービス」ノードを展開します。
「仮想サーバー」ノードを展開し、シングルサインオンのサポートのために設定が必要な仮想サーバーを選択します。
「プロパティーを追加」をクリックします。
空白のプロパティーエントリがリストの下部に追加されます。
「名前」フィールドに、sso-enable を入力します。
「値」フィールドに false を入力すると SSO が無効になり、true を入力すると SSO が有効になります。
デフォルトで、SSO は有効です。
「プロパティーを追加」をクリックし、該当する任意の SSO プロパティーを設定することで、その他のシングルサインオンのプロパティーの追加または変更を行います。
次の表では、仮想サーバーの有効な SSO プロパティーについて説明します。
プロパティー名 |
説明 |
値 |
---|---|---|
sso-max-inactive-seconds |
クライアントが活動を停止後、ユーザーのシングルサインオンの記録を削除可能にするまでの秒数。仮想サーバーの任意のアプリケーションへアクセスすることで、シングルサインオンの記録は有効なまま保持されます。 |
デフォルトは 300 秒 (5 分) です。値を大きくすると、ユーザーの持続時間も長くなりますが、サーバー上のメモリーの消費量も増大します。 |
sso-reap-interval-seconds |
有効期限が切れたシングルサインオンの記録の削除を行う間隔 (秒単位)。 |
デフォルトは 60 です。 |
「保存」をクリックします。
コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。
「コネクタモジュール」は、リソースアダプタとも呼ばれ、J2EE アプリケーションが EIS (Enterprise Information System) と対話することを可能にします。「コネクタリソース」はアプリケーションに EIS への接続を提供します。「コネクタ接続プール」とは、特定の EIS のための再利用可能な接続のグループです。
「セキュリティーマップ」は、J2EE ユーザーおよびグループと EIS ユーザーおよびグループ間のマッピングの作成を可能にします。管理コンソールを使用して、コネクタ接続プールのセキュリティーマップの作成、更新、一覧表示、および削除を行ってください。
このコンテキストでは、ユーザーは主体と呼ばれます。EIS (Enterprise Information System) は情報を保持する任意のシステムです。これは、メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションのいずれかになります。
セキュリティーマップを使用して、コンテナ管理トランザクションベースのシナリオで、アプリケーション (主体またはユーザーグループ) の呼び出し側 ID を適切な EIS 主体に割り当ててください。アプリケーション主体が EIS に要求を開始すると、アプリケーションサーバーは最初に、マッピングされたバックエンドのEIS 主体を特定す るために、コネクタ接続プールに定義されたセキュリティーマップを使用して正確な主体を確認します。完全に一致するものがない場合、アプリケーションサーバーは、ワイルドカード文字の指定があればそれを使用して、マッピングされたバックエンドの EIS 主体を特定します。セキュリティーマップは、アプリケーションユーザーが、EIS の特定の ID として実行することを要求される EIS 動作を実行する必要がある場合に使用されます。
セキュリティーマップを管理するには、管理コンソールで次の各手順を実行してください。
コネクタ接続プールのセキュリティーマップは、アプリケーションユーザーおよびグループ (主体) を EIS 主体に割り当てます。アプリケーションユーザーが EIS の特定の ID を必要とする EIS 動作の実行を必要とする場合は、セキュリティーマップを使用してください。
「リソース」ノードを展開します。
「コネクタ」ノードを展開します。
「コネクタ接続プール」ノードを選択します。
特定のコネクタ接続プールを選択するために現在のプールのリストからその名前を選択するか、新しいコネクタ接続プールを作成するために現在のプールのリストから「新規」を選択し、「JDBC 接続プールを作成する」の手順に従います。
「セキュリティーマップ」ページを選択します。
「新規」をクリックして、新しいセキュリティーマップを作成します。
「セキュリティーマップ」ページで、次のプロパティーを入力します。
名前 – この特定のセキュリティーマップの参照に使用する名前を入力します。
ユーザーグループ – 適切な EIS 主体にマッピングされるアプリケーションの呼び出し側 ID。アプリケーション固有のユーザーグループのコンマで区切られたリストを入力するか、またはすべてのユーザーやすべてのユーザーグループを指定するワイルドカードアスタリスク (*) を入力します。「主体」オプションまたは「ユーザーグループ」オプションを指定しますが、両方は指定しません。
主体 – 適切な EIS 主体にマッピングされるアプリケーションの呼び出し側 ID。アプリケーション固有の主体のコンマで区切られたリストを入力するか、またはすべての主体を指定するワイルドカードアスタリスク (*) を入力します。「主体」オプションまたは「ユーザーグループ」オプションを指定しますが、両方は指定しません。
「バックエンド主体」セクションで、次のプロパティーを入力します。
ユーザー名 – EIS のユーザー名を入力します。EIS (Enterprise Information System) は情報を保持する任意のシステムです。これは、メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションである可能性があります。
パスワード – EIS ユーザーのパスワードを入力します。
「了解」をクリックしてセキュリティーマップを作成するか、「取消し」をクリックして保存しないで取り消します。
create-connector-security-map
「リソース」ノードを展開します。
「コネクタ」ノードを展開します。
「コネクタ接続プール」ノードを選択します。
現在のプールのリストから名前を選択することで、「コネクタ接続プール」を選択します。
「セキュリティーマップ」ページを選択します。
「セキュリティーマップ」ページで、現在のセキュリティーマップのリストからセキュリティーマップを選択します。
「セキュリティーマップを編集」ページで、必要に応じて次のプロパティーを変更します。
ユーザーグループ – 適切な EIS 主体にマッピングされるアプリケーションの呼び出し側 ID。アプリケーション固有のユーザーグループのコンマで区切られたリストを入力するか、またはすべてのグループやすべてのユーザーグループを指定するワイルドカードアスタリスク (*) を入力します。「主体」オプションまたは「ユーザーグループ」オプションを指定しますが、両方は指定しません。
主体 – 適切な EIS 主体にマッピングされるアプリケーションの呼び出し側 ID。アプリケーション固有の主体のコンマで区切られたリストを入力するか、またはすべての主体を指定するワイルドカードアスタリスク (*) を入力します。「主体」オプションまたは「ユーザーグループ」オプションを指定しますが、両方は指定しません。
「バックエンド主体」セクションで、次のプロパティーを入力します。
ユーザー名 – EIS のユーザー名を入力します。EIS (Enterprise Information System) は情報を保持する任意のシステムです。これは、メインフレーム、メッセージングシステム、データベースシステム、またはアプリケーションである可能性があります。
パスワード – EIS ユーザーのパスワードを入力します。
「保存」をクリックして、セキュリティーマップの変更を保存します。
list-connector-security-maps および update-connector-security-maps
「リソース」ノードを展開します。
「コネクタ」ノードを展開します。
「コネクタ接続プール」ノードを選択します。
現在のプールのリストから名前を選択することで、「コネクタ接続プール」を選択します。
「セキュリティーマップ」ページを選択します。
「セキュリティーマップ」ページで、削除するセキュリティーマップの名前の左側にあるチェックボックスをクリックします。
「削除」をクリックします。
delete-connector-security-map
Application Server をインストールすると、内部テストに適した NSS (Network Security Services) 形式のデジタル証明書が生成されます。デフォルトでは、Application Server は domain-dir/config ディレクトリの 証明書データベースに、証明書情報を格納します。
キーストアファイル。key3.db には、非公開鍵を含む Application Server の証明 書が格納されます。キーストアファイルはパスワードで保護されます。パスワードを変更するには、asadmin change-master-password コマンドを使用します。certutil の詳細については、「certutil ユーティリティーの使用」を参照してください。
各キーストアエントリには一意のエイリアスがあります。インストール後の Application Server キーストア内には、エイリアス s1as を持つ単一のエントリが含まれています。
トラストストアファイル。cert8.db には、ほかのエンティティーの公開鍵を含 む Application Server の信頼できる証明書が格納されます。信頼できる証明書では、サーバーは証明書の公開鍵が証明書の所有者に属していることを確認しています。信頼できる証明書には、通常、証明書発行局 (CA) の証明書も含まれています。
Platform Edition では、サーバー側で、Application Server は keytool を使用して証明書とキーストアを管理する JSSE 形式を使用します。Enterprise Edition では、サーバー側で、Application Server は certutil を使用して非公開鍵と証明書を格納する NSS データベースを管理する NSS を使用します。これらの両方の Edition で、クライアントサイド (アプリケーションクライアントまたはスタンドアロン) では、JSSE 形式を使用します。
デフォルトで、Application Server は、サンプルアプリケーションで開発目的のために動作するキーストアおよびトラストストアを使用して設定されています。本稼動環境のために、証明書エイリアスを変更し、トラストストアにほかの証明書を追加し、キーストアおよびトラストストアファイルの名前と場所を変更する必要が生ずる可能性があります。
開発用として提供されているキーストアファイルとトラストストアファイルは、domain-dir/config ディレクトリに格納されています。
管理コンソール ツリーコンポーネントで、「設定」ノードを展開します。
「server-config (管理設定)」ノードを展開します。
「JVM 設定」 ノードを選択します。
「JVM オプション」タブをクリックします。
「JVM オプション」ページで、「値」フィールドの次の値を追加または変更して、証明書ファイルの新しい場所を反映させます。
-Dcom.sun.appserv.nss.db=${com.sun.aas.instanceRoot}/NSS-database-directory |
ここで、NSS-database-directory は NSS データベースの場所です。
「保存」をクリックします。
コンソールに「再起動が必要です」と表示される場合は、Application Server を再起動します。
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) を参照してください。
次の例は、JSSE ツールによる証明書処理に関する使用方法を示したものです。
RSA 鍵アルゴリズムを使ってタイプ JKS のキーストア内に自己署名付き証明書を作成する。RSA は RSA Data Security, Inc. が開発した公開鍵暗号化技術です。この略語は、この技術の開発者である Rivest、Shamir、および Adelman を表しています。
keytool -genkey -noprompt -trustcacerts -keyalg RSA -alias ${cert.alias} -dname ${dn.name} -keypass ${key.pass} -keystore ${keystore.file} -storepass ${keystore.pass} |
証明書を作成する別の例については、「keytool ユーティリティーを使って証明書を生成する」を参照してください。
デフォルトの鍵アルゴリズムを使ってタイプ JKS のキーストア内に自己署名付き証明書を作成する。
keytool -genkey -noprompt -trustcacerts -alias ${cert.alias} -dname ${dn.name} -keypass ${key.pass} -keystore ${keystore.file} -storepass ${keystore.pass} |
証明書に署名する例については、「keytool ユーティリティーを使ってデジタル証明書に署名する」を参照してください。
タイプ JKS のキーストアで利用可能な証明書を表示する。
keytool -list -v -keystore ${keystore.file} -storepass ${keystore.pass} |
タイプ JKS のキーストア内の証明書情報を表示する。
keytool -list -v -alias ${cert.alias} -keystore ${keystore.file} -storepass ${keystore.pass} |
RFC/テキスト形式の証明書を JKS ストア内にインポートする。証明書は、バイナリエンコーディングではなく、Internet RFC (Request for Comments) 1421 標準によって定義された印刷可能なエンコーディング形式を使って格納されることがしばしばあります。Base 64 エンコーディングとしても知られるこの証明書形式を使用すれば、電子メールなどの機構を使って証明書をほかのアプリケーションにエクスポートしやすくなります。
keytool -import -noprompt -trustcacerts -alias ${cert.alias} -file ${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass} |
タイプ JKS のキーストア内の証明書を PKCS7 形式でエクスポートする。「Public Key Cryptography Standards #7, Cryptographic Message Syntax Standard」によって定義された応答形式には、発行される証明書に加え、それをサポートする証明書チェーンも含まれます。
keytool -export -noprompt -alias ${cert.alias} -file ${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass} |
タイプ JKS のキーストア内の証明書を RFC/テキスト形式でエクスポートする。
keytool -export -noprompt -rfc -alias ${cert.alias} -file ${cert.file} -keystore ${keystore.file} -storepass ${keystore.pass} |
タイプ JKS のキーストアから証明書を削除する。
keytool -delete -noprompt -alias ${cert.alias} -keystore ${keystore.file} -storepass ${keystore.pass} |
キーストアから証明書を削除する別の例については、「keytool ユーティリティーを使って証明書を削除する」を参照してください。
keytool を使用して証明書の生成、インポート、およびエクスポートを行います。デフォルトでは、keytool は実行元のディレクトリにキーストアファイルを作成します。
証明書を実行すべきディレクトリに移動します。
証明書の生成は常に、キーストアファイルとトラストストアファイルが格納されたディレクトリ (デフォルトでは domain-dir/config) 内で行います。これらのファイルの場所を変更する方法については、「証明書ファイルの場所を変更する」を参照してください。
次の keytool コマンドを入力することで、キーストアファイル keystore.jks 内に証明書を生成します。
keytool -genkey -alias keyAlias-keyalg RSA -keypass changeit -storepass changeit -keystore keystore.jks |
keyAlias には任意の一意名を指定します。キーストアまたは非公開鍵のパスワードをデフォルト以外の値に変更した場合には、前述のコマンドの changeit をその新しいパスワードで置き換えてください。
プロンプトが表示され、keytool が証明書の生成に使用するユーザーの名前、組織、およびその他の情報の入力を求められます。
次の keytool コマンドを入力することで、生成された証明書をファイル server.cer (または client.cer でもよい) にエクスポートします。
keytool -export -alias keyAlias-storepass changeit -file server.cer -keystore keystore.jks |
認証局によって署名された証明書が必要な場合は、「keytool ユーティリティーを使ってデジタル証明書に署名する」を参照してください。
トラストストアファイル cacerts.jks を作成し、そのトラストストアに証明書を追加するには、次の keytool コマンドを入力します。
keytool -import -v -trustcacerts -alias keyAlias -file server.cer -keystore cacerts.jks -keypass changeit |
キーストアまたは非公開鍵のパスワードをデフォルト以外の値に変更した場合には、前述のコマンドの changeit をその新しいパスワードで置き換えてください。
このツールは、証明書に関する情報を表示し、その証明書を信頼するかどうかをユーザーに尋ねます。
yes と入力し、続いて Enter キーを押します。
すると、keytool から次のようなメッセージが表示されます。
Certificate was added to keystore [Saving cacerts.jks] |
Application Server を再起動します。
デジタル証明書の作成後、所有者はそれに署名して偽造を防止する必要があります。E コマースのサイト、または ID の認証が重要であるサイトは、既知の証明書発行局 (CA) から証明書を購入できます。認証に心配がない場合、たとえば、非公開のセキュアな通信だけが必要な場合などは、CA 証明書の取得に必要な時間と費用を節約して、自己署名付き証明書を使用してください。
証明書の鍵のペアを生成するため、CA の Web サイトの指示に従います。
生成された証明書の鍵のペアをダウンロードします。
キーストアファイルとトラストストアファイルが格納されたディレクトリ (デフォルトでは domain-dir/config ディレクトリ) 内に、証明書を保存します。「証明書ファイルの場所を変更する」を参照してください。
使用しているシェルで、証明書を含むディレクトリに変更します。
keytool を使用して、証明書をローカルのキーストア、および必要に応じてローカルのトラストストアにインポートします。
keytool -import -v -trustcacerts -alias keyAlias -file server.cer -keystore cacerts.jks -keypass changeit -storepass changeit |
キーストアまたは非公開鍵のパスワードがデフォルト以外の値である場合には、前述のコマンドの changeit をその新しいパスワードで置き換えてください。
Application Server を再起動します。
既存の証明書を削除するには、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 ドキュメントを参照してください。
Enterprise Edition の場合、サーバー側では、NSS (Network Security Services) デジタル証明書を使って非公開鍵と証明書を格納するデータベースを管理します。クライアント側 (アプリケーションクライアントまたはスタンドアロン) では、「JSSE (Java Secure Socket Extension) ツールの使用」で説明した JSSE 形式を使用します。
NSS (Network Security Services) を使ってセキュリティーを管理するためのツールは、次のとおりです。
certutil。証明書および鍵データベースの管理に使用されるコマンド行ユーティリティー。certutil ユーティリティーの使用例については、「certutil ユーティリティーの使用」を参照してください。
pk12util。証明書または鍵データベースと PKCS12 形式のファイル間における鍵と証明書のインポートおよびエクスポートに使用されるコマンド行ユーティリティー。pk12util ユーティリティーの使用例については、「pk12util ユーティリティーによる証明書のインポートとエクスポート」を参照してください。
modutil。secmod.db ファイル内またはハードウェアトークン内の PKCS #11 モジュール情報を管理するためのコマンド行ユーティリティー。modutil ユーティリティーの使用例については、「modutil による PKCS11 モジュールの追加と削除」を参照してください。
これらのツールは install-dir/lib/ ディレクトリに格納されています。NSS セキュリティーツールの場所を指し示すために、次の各環境変数が使用されます。
LD_LIBRARY_PATH =${install-dir}/lib
${os.nss.path}
例に含まれる証明書の共通名 (CN) は、クライアントまたはサーバーの名前です。また、この CN は、SSL ハンドシェーク中に証明書の名前とその証明書の生成元であるホスト名とを比較する目的でも使用されます。SSL ハンドシェーク中に証明書名とホスト名が一致しなかった場合、警告または例外が生成されます。いくつかの例では便宜上、証明書の共通名 CN=localhost が使用されていますが、これは、すべてのユーザーが、実際のホスト名に基づいて新しい証明書を作成することなしにその証明書を使用できるようにするためです。
次の各節の例は、NSS ツールによる証明書処理に関する使用方法を示したものです。
証明書データベースツールの 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 セキュリティーツールを使って証明書の作成または管理、あるいはその両方を行う例を示したものです。
自己署名付きのサーバー証明書およびクライアント証明書を生成する。この例では、CN は hostname.domain.[com|org|net|...] の形式でなければなりません。
この例では、domain-dir/config です。serverseed.txt ファイルと clientseed.txt ファイルには、任意のランダムテキストを含めることができます。このランダムテキストは、鍵ペア生成時に使用されます。
certutil -S -n $SERVER_CERT_NAME -x -t "u,u,u" -s "CN=$HOSTNAME.$HOSTDOMAIN, OU=Java Software, O=Sun Microsystems Inc., L=Santa Clara, ST=CA, C=US" -m 25001 -o $CERT_DB_DIR/Server.crt -d $CERT_DB_DIR -f passfile <$CERT_UTIL_DIR/serverseed.txt |
クライアント証明書を生成する。この証明書も自己署名付き証明書です。
certutil -S -n $CLIENT_CERT_NAME -x -t "u,u,u" -s "CN=MyClient, OU=Java Software, O=Sun Microsystems Inc., L=Santa Clara, ST=CA, C=US" -m 25002 -o $CERT_DB_DIR/Client.crt -d $CERT_DB_DIR -f passfile <$CERT_UTIL_DIR/clientseed.txt |
前述の項目で生成された証明書を検証する。
certutil -V -u V -n $SERVER_CERT_NAME -d $CERT_DB_DIR certutil -V -u C -n $CLIENT_CERT_NAME -d $CERT_DB_DIR |
利用可能な証明書を表示する。
certutil -L -d $CERT_DB_DIR |
RFC テキスト形式の証明書を NSS 証明書データベースにインポートする。
certutil -A -a -n ${cert.nickname} -t ${cert.trust.options} -f ${pass.file} -i ${cert.rfc.file} -d ${admin.domain.dir}/${admin.domain}/config |
NSS 証明書データベース内の証明書を RFC 形式でエクスポートする。
certutil -L -a -n ${cert.nickname} -f ${pass.file} -d ${admin.domain.dir}/${admin.domain}/config > cert.rfc |
NSS 証明書データベースから証明書を削除する。
certutil -D -n ${cert.nickname} -f ${pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
証明書を NSS データベースから JKS 形式に移動する。
certutil -L -a -n ${cert.nickname} -d ${admin.domain.dir}/${admin.domain}/config > cert.rfc keytool -import -noprompt -trustcacerts -keystore ${keystore.file} -storepass ${keystore.pass} -alias ${cert.alias} -file cert.rfc |
証明書または鍵データベースと 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 を参照してください。
PKCS12 形式の証明書を NSS 証明書データベースにインポートする。
pk12util -i ${cert.pkcs12.file} -k ${certdb.pass.file} -w ${cert.pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
PKCS12 形式の証明書を NSS 証明書データベーストークンモジュールにインポートする。
pk12util -i ${cert.pkcs12.file} -h ${token.name} -k ${certdb.pass.file} -w ${cert.pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
NSS 証明書データベース内の証明書を PKCS12 形式でエクスポートする。
pk12util -o -n ${cert.nickname} -k ${pass.file} -w${cert.pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
NSS 証明書データベーストークンモジュール内の証明書を PKCS12 形式でエクスポートする (ハードウェアアクセラレータ構成で有用)。
pk12util -o -n ${cert.nickname} -h ${token.name} -k ${pass.file} -w ${cert.pass.file} -d ${admin.domain.dir}/${admin.domain}/config |
PKCS12 証明書を JKS 形式に変換する (Java ソースが必要)。
<target name="convert-pkcs12-to-jks" depends="init-common"> <delete file="${jks.file}" failonerror="false"/> <java classname="com.sun.enterprise.security.KeyTool"> <arg line="-pkcs12"/> <arg line="-pkcsFile ${pkcs12.file}"/> <arg line="-pkcsKeyStorePass ${pkcs12.pass}"/> <arg line="-pkcsKeyPass ${pkcs12.pass}"/> <arg line="-jksFile ${jks.file}"/> <arg line="-jksKeyStorePass ${jks.pass}"/> <classpath> <pathelement path="${s1as.classpath}"/> <pathelement path="${env.JAVA_HOME}/jre/lib/jsse.jar"/> </classpath> </java> </target>
「セキュリティーモジュールデータベースツール」である 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 を参照してください。
新しい PKCS11 モジュールまたはトークンを追加する。
modutil -add ${token.module.name} -nocertdb -force -mechanisms RSA:DSA:RC4:DES -libfile ${SCA.lib.path} -dbdir ${admin.domain.dir}/${admin.domain}/config |
NSS ストアから PKCS11 モジュールを削除する。
modutil -delete ${token.module.name} -nocertdb -force -mechanisms RSA:DSA:RC4:DES -libfile ${SCA.lib.path} -dbdir ${admin.domain.dir}/${admin.domain}/config |
NSS ストア内で利用可能なトークンモジュールを一覧表示する。
modutil -list -dbdir ${admin.domain.dir}/${admin.domain}/config |
Java 2 Standard Edition のセキュリティーについては、http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html を参照してください。
『J2EE 1.4 Tutorial』の「Security」の章については、http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html を参照してください。
『管理ガイド』の第 10 章「メッセージセキュリティーの設定」。
『Developer’s Guide』の「Securing Applications」の章。