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

- Previous: 第 8 章 J2EE コンテナ
- Next: セキュリティーに関する管理コンソールタスク

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

- 「セキュリティーの概要」

- 「認証と承認について」

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

- 「証明書および SSL の概要」

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

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

## セキュリティーの概要

セキュリティーとはデータの保護に関することであり、ストレージ内または伝送中のデータへの不正アクセスやそうしたデータの破損をどのようにして防止するか、ということです。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 内のパスワードを暗号化する

##### 手順

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

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

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

- domain-dir`/master-password`

  このファイルにはエンコード化されたマスターパスワードが含まれているので、ファイルシステムのアクセス権 600 で保護する必要があります。

- `asadmin` への `--passwordfile` 引数を使用して、引数として渡すために作成されたすべてのパスワードファイル。これらは、ファイルシステムのアクセス権 600 で保護する必要があります。

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

マスターパスワード (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. すべてのノードエージェントで対応が終了するまで、次のノードエージェントで同様の作業を継続します。このようにして、継続的な変更作業が完了します。

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

管理パスワードの暗号化については、「パスワードのセキュリティー管理」を参照してください。管理パスワードの暗号化は強く推奨されています。管理パスワードを暗号化する前に変更する場合は、`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`) を参照してください。

#### システム管理者

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

- セキュリティーレルムの設定。

- ユーザーアカウントおよびグループの管理。

- 監査ログの管理。

- サーバー証明書の管理およびサーバーの SSL (Secure Sockets Layer) の使用の設定。

- コネクタ接続プールのセキュリティーマップ、その他の JACC プロバイダなど、その他のシステム全体のセキュリティー機能の管理。

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

## 認証と承認について

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

- 「エンティティーの認証」

- 「ユーザーの承認」

- 「JACC プロバイダの指定」

- 「認証および承認の決定の監査」

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

### エンティティーの認証

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

通常、認証はユーザー名とパスワードでユーザーがアプリケーションにログインすることを意味していますが、アプリケーションがサーバーのリソースを要求するとき、セキュリティー資格を提供する 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 レイヤーのメッセージセキュリティープロバイダを使用して、メッセージセキュリティーを実装します。メッセージセキュリティープロバイダは、要求メッセージおよび応答メッセージに必要な認証のタイプなどの情報を提供します。サポートされている認証には次のタイプが含まれます。

- ユーザー名とパスワード認証を含む送信者認証。

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

##### 図 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 の概要

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

- 「デジタル証明書について」

- 「SSL (Secure Sockets Layer) について」

### デジタル証明書について

「デジタル証明書」(または単に証明書) とは、インターネット上の人物やリソースを一意に識別する電子ファイルです。さらに証明書は 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) について

「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 プロバイダ」

- 「監査モジュール」

- 「メッセージセキュリティー」

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

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

- 「セキュリティーマップ」

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

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

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

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

- 新しいレルムの作成

- 既存のレルムの削除

- 既存のレルムの設定変更

- `file` レルムのユーザーの追加、変更、および削除

- デフォルトレルムの設定

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

### JACC プロバイダ

JACC プロバイダについては、「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 リスナー」を参照してください。

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

- 新しい HTTP または IIOP リスナーの作成と、それを使用するセキュリティーの指定

- 既存のHTTP または IIOP リスナーのセキュリティー設定の変更

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

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

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

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

- 管理サービスの管理

- JMX コネクタの編集

- JMX コネクタのセキュリティー設定の変更

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

### セキュリティーマップ

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

- 既存のコネクタ接続プールへのセキュリティーマップの追加

- 既存のセキュリティーマップの削除または設定

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

- Previous: 第 8 章 J2EE コンテナ
- Next: セキュリティーに関する管理コンソールタスク

- © 2010, Oracle Corporation and/or its affiliates