- 1 -

6. セキュリティー構成 ................................................................................................................ 3

6-1 セキュリティー・アーキテクチャー......................................................................................... 3 6-1-1 セキュリティー機能を支える技術 ..................................................................................... 3 6-1-2 セキュリティー概観............................................................................................................ 4 6-1-3 グローバル・セキュリティー............................................................................................... 6 6-1-4 グローバル・セキュリティー設定方法 ............................................................................... 6 6-1-4-1 セキュリティー構成ウィザード ....................................................................................... 7 6-1-4-2 セキュリティー構成報告書 .......................................................................................... 10 6-2 複数セキュリティー・ドメイン ............................................................................................... 10 6-2-1 複数セキュリティー・ドメインの概要 ............................................................................... 10 6-2-2 セキュリティー・ドメインの内容 ....................................................................................... 11 6-2-2-1 セキュリティー・ドメイン構成ファイル .......................................................................... 11 6-2-2-2 セキュリティー・ドメインで設定できるセキュリティー属性 .......................................... 11 6-2-2-3 セキュリティー・ドメインへの有効範囲の関連付け .................................................... 12 6-2-3 設定方法 ......................................................................................................................... 12 6-2-4 考慮点 ............................................................................................................................. 15 6-2-4-1 古いサーバー・レベルのセキュリティーと新しいセキュリティー・ドメインの関係 ...... 15 6-2-4-2 セキュリティー・ドメインの使用時のクライアントおよびアプリケーション・セキュリティ

ー・プログラミング・モデル.......................................................................................................... 15 6-2-4-3 複数ドメイン構成におけるアプリケーション・デプロイメント....................................... 15 6-2-4-4 相互レルム通信........................................................................................................... 16 6-2-4-5 ノードとセキュリティー・ドメインの統合 ....................................................................... 16 6-3 認証 ..................................................................................................................................... 16 6-3-1 認証とは .......................................................................................................................... 16 6-3-2 認証モデル ...................................................................................................................... 16 6-3-3 ユーザー・レジストリー .................................................................................................... 17 6-3-4 認証メカニズム ................................................................................................................ 18 6-3-5 仮想メンバー・マネージャー（VMM:virtual member manager） .................................. 19 6-3-6 認証プロセス ................................................................................................................... 19 6-3-7 設定方法 ......................................................................................................................... 20 6-3-7-1 統合リポジトリー .......................................................................................................... 20 6-3-7-2 SSO .............................................................................................................................. 22 6-3-7-3 トラスト・アソシエーション............................................................................................. 24 6-4 認可 ..................................................................................................................................... 25 6-4-1 認可とは .......................................................................................................................... 25 6-4-2 認可モデル ...................................................................................................................... 25 6-4-3 宣言セキュリティー.......................................................................................................... 26 6-4-4 プログラマティック・セキュリティー .................................................................................. 26 6-4-5 代行モデル ...................................................................................................................... 27 6-4-6 認可プロセス ................................................................................................................... 28 6-5 SSL ...................................................................................................................................... 30 6-5-1 SSL とは........................................................................................................................... 30 6-5-2 SSL 構成.......................................................................................................................... 31 6-5-3 SSL 証明書 ...................................................................................................................... 31 6-5-4 設定方法 ......................................................................................................................... 32

- 2 -

6-5-4-1 Web ブラウザーと Web サーバー間の SSL 構成 ..................................................... 32 6-5-4-2 Web サーバーと WAS の SSL 構成........................................................................... 33 6-6 鍵と証明書 .......................................................................................................................... 36 6-6-1 Ikeyman と同等の機能を管理コンソールから使用 ....................................................... 36 6-6-2 証明書の有効期限.......................................................................................................... 36 6-7 監査 ..................................................................................................................................... 37 6-7-1 監査とは .......................................................................................................................... 37 6-7-2 監査可能なイベント・タイプ ............................................................................................. 39 6-7-3 設定方法 ......................................................................................................................... 40 6-7-4 監査リーダーの使用 ....................................................................................................... 46 6-8 管理ロール.......................................................................................................................... 48 6-8-1 管理ロール ...................................................................................................................... 48 6-8-1-1 監査員 .......................................................................................................................... 49 6-8-2 稼動ユーザー .................................................................................................................. 49 6-8-3 設定方法 ......................................................................................................................... 50 6-8-3-1 管理ロールの設定....................................................................................................... 50 6-8-3-2 非 root ユーザーでの稼動設定 .................................................................................. 52 6-9 Fine-grained 管理セキュリティー .................................................................................... 52 6-9-1 Fine-grained 管理セキュリティーとは ........................................................................... 52 6-9-2 許可グループ .................................................................................................................. 53 6-9-3 管理コンソールによる設定方法 ..................................................................................... 54 6-9-4 wsadmin による設定方法 ............................................................................................... 58 6-10 JACC................................................................................................................................. 59 6-10-1 JACC とは...................................................................................................................... 59 6-10-2 JACC プロバイダー ....................................................................................................... 59 6-10-3 設定方法 ....................................................................................................................... 60 6-10 Java 2 セキュリティー...................................................................................................... 65 6-10-1 Java 2 セキュリティーとは............................................................................................ 65 6-10-2 Java 2 セキュリティー・ポリシー・ファイル ................................................................... 65 6-10-3 静的ポリシー・ファイル.................................................................................................. 65 6-10-4 動的ポリシー・ファイル.................................................................................................. 66 6-11 JAAS ................................................................................................................................. 66 6-11-1 JAAS とは ...................................................................................................................... 66 6-11-2 JAAS の許可 ................................................................................................................. 67

- 3 -

6. セキュリティー構成

この章では、WebSphere Application Server(以下、WAS) V7.0 におけるセキュリティーの概念や仕組

み、構成について説明します。また、各項目について、管理コンソールを使用した設定方法についても

紹介します。

6-1 セキュリティー・アーキテクチャー この節では、WebSphere セキュリティー全体像を理解するために、基盤となっている技術やアーキテク

チャーについて説明します。

6-1-1 セキュリティー機能を支える技術 WebSphere セキュリティーは、図 6-1に示すような階層化セキュリティー・アーキテクチャー上に構築さ

れます。

図 6-1 階層化セキュリティー・アーキテクチャー

- 4 -

WAS リソースには、ネーミングやユーザー・レジストリー、JMX メッセージ Bean、HTML、サーブレット、

JSP、Enterprise Bean、Web サービスなどといったサービスやコンテンツが含まれます。階層構造の最も

高い位置にある WebSphere セキュリティーは、このようなさまざまなリソースへアクセスする方法として、統

一されたセキュリティー・ポリシーおよびサービスを提供しています。 WebSphere セキュリティーの下の層が Java Platform Enterprise Edition (以下、Java EE)セキュリティ

ーです。WebSphere セキュリティーは、 Java EE ベースのセキュリティー・ポリシーを実行し、Java EE セ

キュリティーの Application Programming Interface(以下、API)をサポートします。 Java EE セキュリティーの下の層が CORBA セキュリティーです。セキュアな Object Request Broker(以下、ORB)間で行われる呼び出しは、全て Common Security Interoperability Version 2(以下、CSIv2)セキュリティー・プロトコル上で行われます。このプロトコルはセキュリティー・コンテキストを生成し、セッショ

ンが確立された後、呼び出しは Enterprise Bean 層に渡されます。後方互換性のために、WAS は、以前

のリリースや他の IBM 製品で使用されていた Secure Authentication Service(以下、SAS)セキュリティー・

プロトコルもサポートします。尚、SAS がサポートされるのは、WAS V7.0 セルに統合された V6.0.x と、

それより前のバージョンの間のサーバーに限られます。 CORBA セキュリティーの下の層が Java 2 セキュリティーです。Java 2 セキュリティー・モデルは、ファ

イル・システム、システム・プロパティー、ソケット接続、スレッド化、クラス・ロードなどのシステム・リソース

に対して、きめの細かいアクセス制御を提供します。アプリケーション・コードで保護されたリソースにアク

セスするためには、必要な許可を明示的に与えなければなりません。 Java 2 セキュリティーの下の層が Java Virtual Machine(以下、JVM)セキュリティーです。JVM セキュリ

ティー・モデルは、オペレーティング・システム層の上にセキュリティーの層を提供します。例えば、JVMセキュリティーは無制限のアクセスからメモリーを保護し、スレッド内でエラーが起こった場合には例外を

スローして配列型を定義します。 更にこれらの下の層がオペレーティング・システム・セキュリティーです。基礎となるオペレーティング・

システムのセキュリティー基盤は、特定のセキュリティー・サービスを WAS に提供します。このセキュリテ

ィー・サービスには、WAS の製品インストールにおいて機密ファイルを保護するファイル・システム・セキ

ュリティーのサポートが含まれます。システム管理者は、製品を構成したら、オペレーティング・システム

のユーザー・レジストリーから認証情報を直接取得することができます。 オペレーティング・システム・セキュリティーの下の層がネットワーク・セキュリティーです。ネットワーク・

セキュリティー層は、トランスポート・レベルの認証およびメッセージの保全性と機密性を提供します。別

個のアプリケーション・サーバー間の通信は、Secure Sockets Layer(以下、SSL)を使用するように構成す

ることができます。また、更にメッセージ保護を強化するためには、IP セキュリティーや Virtual Private Network(以下、VPN)を使用することもできます。

6-1-2 セキュリティー概観 アプリケーション・サーバーは、複数層のエンタープライズ・コンピューティング・フレームワークの中核

をなすコンポーネントです。WAS は、図 6-2に示すようにオープン・アーキテクチャーを採用し、エンタ

ープライズ・ソフトウェア・コンポーネントと統合するために多数のプラグイン・ポイントを提供します。プラ

グイン・ポイントは、Java EE の標準仕様が適用できるところでは必ずこの仕様を基にしています。図 6-2で影が付いた部分は、WAS と他のエンタープライズ・ソフトウェア・コンポーネントとの境界を示します。

- 5 -

図 6-2 WebSphere セキュリティー概観

トラスト・アソシエーションにより、WAS セキュリティーとサード・パーティー製セキュリティー・サーバーと

を統合することができます。具体的には、リバース・プロキシー・サーバーがフロントエンド認証サーバー

として機能させることができる一方で、プロキシー・サーバーによって渡される信任状を WAS 製品自体

の認証ポリシーに適用することができます。トラスト・アソシエーション・インターセプターを実装する製品

には、IBM Tivoli Access Manager for e-business(以下、TAM)、Caching Proxy などがあります。 WAS は、ユーザーの認証情報やドメインなどの情報が含まれたセキュリティー属性を、構成内のサー

バー間で受け渡しすることができます。セキュリティー属性は、ユーザーのアカウント情報が格納された

ユーザー・レジストリーあるいは Java Authentication and Authorization Service(以下、JAAS)ログイン・モ

ジュールから取得することができます。 また、WAS では、Web サービス・セキュリティー仕様に基づいて Web サービスを保護することができま

す。この仕様は、Web サービス環境で交換されるメッセージの保護方法を規定しており、メッセージの保

全性と機密性を保護するための中核機構を定義し、セキュリティー関連の要求とメッセージを関連付け

るためのメカニズムを提供します。 その他にも、J2EE コネクター・アーキテクチャーによるコンテナー管理認証のサポート、Java Authorization Contract for Containers(以下、JACC)インターフェースによる外部 JACC プロバイダーのサ

ポート、CSIv2 セキュリティー・プロトコルのサポートなど、WAS はさまざまなプラグイン・ポイントを提供し

ています。

- 6 -

6-1-3 グローバル・セキュリティー グローバル・セキュリティーとは、WAS 自体や連携する他のコンポーネントも含んだシステムの一部を

保護された状態にする機能です。そして、グローバル・セキュリティーはユーザー・レジストリーや認証メ

カニズム、セキュリティー・ドメインの振る舞いを定義するその他のセキュリティー情報から構成されます。

具体的には、Java 2 セキュリティー・マネージャー、JAAS、Java 2 コネクター認証データ・エントリー、

CSIv2 認証プロトコルなどの各種属性があります。 WAS V7.0 におけるグローバル・セキュリティーは、WAS V6.1 と同様に管理セキュリティーとアプリケ

ーション・セキュリティーに分離された形で構成されています。管理セキュリティーとは、WAS の管理をセ

キュアにするための機能で、常時使用を推奨しています。管理セキュリティーを有効にすると管理コンソ

ールや wsadmin といった管理ツールにログインするユーザーに認証やアクセス制御の設定を行う事が

できます。尚、管理セキュリティーのデフォルトの認証メカニズムは LTPA となります。アプリケーション・セ

キュリティーとは、WAS 上で稼動するアプリケーションをセキュアにするための機能です。アプリケーショ

ン・セキュリティーを有効にすると、WAS 上で稼動するアプリケーションに対して認証認可などのセキュリ

ティー設定を行う事ができます。Web リソースの場合、web.xml 内のリソースに対するセキュリティー制

約が実行されます。保護リソースにアクセスすると、Web クライアントに対して、認証を求めるプロンプト

が出されます。 注意点としては、管理セキュリティーは単独で有効にすることが可能ですが、アプリケーション・セキュ

リティーは独立して有効にすることはできません。必ずアプリケーション・セキュリティーを有効にする場

合は管理セキュリティーを有効にする必要があります。 WAS V7.0 で追加された新機能により、セル内にセキュリティー・ドメインを複数定義し、グローバル・

セキュリティー構成を上書きすることが可能になりました。複数セキュリティー・ドメインの詳細については

次の節で解説します。 WAS V7.0 から追加されたジョブ・マネージャーおよび管理エージェントに対してもグローバル・セキュ

リティーを設定することが可能です。ジョブ・マネージャー、管理エージェント上でアプリケーションは稼

働しないため、正確にはこれらに対し管理セキュリティーを設定することが可能です。 認証リポジトリーも、統合リポジトリー、スタンドアロン LDAP レジストリー、ローカル・オペレーティング・シ

ステム・レジストリー、スタンドアロン・カスタム・レジストリーの 4 種類をサポートしています。考慮点として、

ジョブ・マネージャーと登録する ND 環境、シングル・サーバー(管理エージェント含む)のグローバル・セ

キュリティーの設定を同じにしておく必要があります。また、管理エージェントについても登録するシング

ル・サーバーのそれを同じ設定にしておく必要があります。

6-1-4 グローバル・セキュリティー設定方法 グローバル・セキュリティーは WAS 導入中、プロファイル作成中、または WAS 導入後に設定すること

が可能です。 まず初めに、WAS導入中、プロファイル作成中の設定方法を紹介します。WAS導入ウィザードまたは

プロファイル管理ツールには、管理セキュリティー・パネルが追加されています。WAS 導入ウィザード、

プロファイル作成ウィザードともに同様のパネルが表示されます。

- 7 -

図 6-3 プロファイル管理ツールの管理セキュリティー設定画面

管理セキュリティーを設定する場合は、このパネルの[管理セキュリティーを有効にする]のチェックボッ

クスを ON にします。続いて、任意のユーザー名とパスワードを入力します。このユーザー名はのちに１

次管理ユーザーとなり管理セキュリティーが有効となった管理ツールからログインする際に入力するユ

ーザー名とパスワードになります。このユーザーはファイル・ベースのリポジトリーに格納されます。ここで

設定したユーザー情報は<DM_Profile_Root>/config/<Cell_name> パスに保管されているファイル・レ

ジストリー（fileRegistry.xml）に保管されます。管理セキュリティーは WAS 導入後、またはプロファイル作

成後に有効となります。ただし、有効であるのは管理セキュリティーだけで、このときアプリケーション・セ

キュリティーはデフォルトで使用不可となっています。アプリケーション・セキュリティーを使用可能にする

場合は、あらためて設定する必要があります。

6-1-4-1 セキュリティー構成ウィザード 次に、プロファイル作成後にグローバル・セキュリティーを有効にする方法を説明します。

グローバル・セキュリティーを WAS 導入後またはプロファイル作成後に設定するには、セキュリティー構

成ウィザードを使用します。セキュリティー構成ウィザードは、基本的な管理とアプリケーションのセキュリ

ティーを構成するために必要なステップを提供しています。具体的には 1 次管理ユーザーの作成や、使

用するユーザー・レジストリーの選択、管理セキュリティーの有効化などになります。管理コンソールか

ら、[セキュリティー]→[グローバル・セキュリティー]を開きます。[セキュリティー構成ウィザード]ボタンをク

リックします。

- 8 -

【Step1】保護の範囲の指定

アプリケーション・セキュリティーとリソース・セキュリティーの選択ができますが、これらの選択については

任意です。必要があれば選択し、[次へ]をクリックします。管理セキュリティーはこのウィザードを使用し

て変更した場合、デフォルトで有効になりますので選択するチェックボックスはありませんのでご注意くだ

さい。 【Step2】ユーザー・リポジトリー

ユーザー・リポジトリーの選択を行います。ユーザー・リポジトリーは、認証やアクセス制御のために使

用するユーザーとグループの情報を持ちます。いずれか１つだけ選択し、[次へ]をクリックします。

- 9 -

【Step3】ユーザー・リポジトリーの構成

管理セキュリティーが有効になった管理コンソールにログインする際に必要なユーザー名とパスワー

ドを設定します。このユーザーはファイル・ベースのリポジトリーに保管されます。ファイル・ベースのリポ

ジトリーに保管されたユーザーは、管理コンソールから、[ユーザーおよびグループ]→[ユーザーの管

理]または[グループの管理]を開くとその管理画面を確認することができます。 また、WAS 導入またはプロファイル作成ウィザードの管理セキュリティー･パネルでは、[管理セキュリティ

ーを有効にする]のチェックボックスを ON にしたとき入力するユーザー名とパスワードが同様です。 【Step4】要約

- 10 -

このページでは設定した内容の確認ができます。 [管理セキュリティーを使用可能にする]が true になっていることを確認します。設定に間違いがなければ

[OK]ボタンをクリックし、保管します。 管理コンソールからログアウトし、変更を有効にするためにサーバーを再起動します。サーバーの再起

動が完了したら、管理セキュリティーが有効になった管理コンソールを立ち上げます。ログイン・ユーザ

ーを要求されますので、セキュリティー構成ウィザードの Step3 で設定した 1 次管理ユーザーを入力しま

す。無事、ログインができたら、[セキュリティー]→[管理、アプリケーション、およびインフラストラクチャー

の保護]画面を開き、[管理セキュリティーを使用可能にする]のチェックボックスが ON になっていることを

確認します。

6-1-4-2 セキュリティー構成報告書 導入またはプロファイル作成後に、管理セキュリティーの設定を管理コンソールから確認することがで

きます。 管理コンソールから、[セキュリティー]→[管理、アプリケーション、およびインフラストラクチャーの保

護]を開き、[セキュリティー構成報告書]を開きます。 [セキュリティー構成報告書]は、現在のセキュリティーに関する設定の全てを見ることができます。ただ

し、機能上の制限により、アプリケーション・レベルのセキュリティー情報は表示されません。また、Java Message Service (JMS) セキュリティー、バス・セキュリティー、 Web Services セキュリティーに関する情

報も同じく表示されません。

6-2 複数セキュリティー・ドメイン この節では、WAS V7.0 における複数セキュリティー・ドメインについて説明します。

6-2-1 複数セキュリティー・ドメインの概要 WAS V7.0 のセキュリティー新機能として追加された複数セキュリティー・ドメインは、セキュリティー・ド

メイン毎に異なるセキュリティー設定を柔軟に構成することができます。尚、複数セキュリティー・ドメイン

は、単にセキュリティー・ドメインとも呼ばれます。 WAS V7.0 におけるすべての管理アプリケーションおよびユーザー・アプリケーションは、セキュリティ

ー設定有効時において、デフォルトでグローバル・セキュリティー属性を使用します。グローバル・セキュ

リティー構成は管理セキュリティーおよびデフォルト・セキュリティー構成に適用されます。例えば管理コ

ンソール、ネーミング・リソース、MBeans などの管理アプリケーションには、グローバル・セキュリティー

属性が必要です。そして、セル内に複数セキュリティー・ドメインが定義されると、このグローバル・セキュ

リティー構成はセキュリティー・ドメインの構成に上書きされます。 これによって異なるアプリケーションに対して異なるセキュリティー属性 (例：認証リポジトリー) を構成

できます。例えば、セル環境内の管理セキュリティーでは統合リポジトリーを使用し、アプリケーション・セ

キュリティーでは LDAP レジストリーを使用する構成や、アプリケーションが使用する認証リポジトリーはク

ラスター毎に別レジストリーにする構成などを組む事ができます。 アプリケーション毎に変える必要のあるセキュリティー属性に対しては、セキュリティー・ドメインを作成

して、それらのユーザー・アプリケーションが実行されるサーバーあるいはクラスターを有効範囲として関

連付けます。また、セキュリティー・ドメインをセルに関連付けることもできます。

- 11 -

また、WAS V6.1 までのサーバー・レベルのセキュリティーを使用していた場合は、複数セキュリティー・

ドメインを使用する必要があります。サーバー・レベルのセキュリティーは、WAS V7.0 では非推奨になっ

ており、複数セキュリティー・ドメインを使用した方が構成をより柔軟に簡単に行うことができるためです。

6-2-2 セキュリティー・ドメインの内容

6-2-2-1 セキュリティー・ドメイン構成ファイル グローバル・セキュリティー構成データは security.xml ファイルに保管されます。

このファイルは <Profile_root>/config/cells/<Cell_name> ディレクトリーにあります。 セキュリティー・ドメインは、2 つの構成ファイルによって表されます。セキュリティー・ドメイン情報は、

<Profile_root>/config/waspolicies/default/securitydomains/<SecurityDomain_name> デ ィ レ ク ト リ ー に

domain-security.xml ファイルと domain-security-map.xml ファイルが保管されます。domain-security.xml ファイルには、セキュリティー・ドメイン用に構成されたセキュリティー属性のリストが含まれ、もう 1 つの domain-security-map.xml ファイルには、セキュリティー・ドメインを使用する有効範囲が含まれます。

6-2-2-2 セキュリティー・ドメインで設定できるセキュリティー属性 表 6-1 にグローバル・セキュリティー構成とセキュリティー・ドメイン構成で設定できるセキュリティー属性

の一覧を示します。下記表より、すべてのセキュリティー属性を上書きできるわけではないことがわかりま

す。 注意点として、統合リポジトリー・ユーザー・レジストリーは、グローバル・レベルでしか構成できませ

ん。WAS では、統合リポジトリーのインスタンスは 1 つしか存在することができません。すべてのセキュ

リティー・ドメインは、そのユーザー・レジストリーに対してこの構成を使用します。セキュリティー・ドメイン

は、それ自体のユーザー・レジストリーでこの構成をオーバーライドできます。ただし、統合リポジトリーの

別のインスタンスを構成することはできません。

表 6-1 セキュリティー・ドメインで構成できるセキュリティー属性

グローバル・セキュリティー構成(security.xml) セ キ ュ リ テ ィ ー ・ ド メ イ ン 構 成

(domain-security.xml) アプリケーション・セキュリティーの使用可能化 アプリケーション・セキュリティーの使用可能化 Java 2 セキュリティー Java 2 セキュリティー ユーザー・レルム（レジストリー） ユーザー・レルム（レジストリー） トラスト・アソシエーション・インターセプター(TAI) トラスト・アソシエーション・インターセプター(TAI) SPNEGO Web 認証 SPNEGO Web 認証 RMI/IIOP セキュリティー(CSIv2 プロトコル) RMI/IIOP セキュリティー(CSIv2 プロトコル) JAAS JAAS 認証メカニズム属性 認証メカニズム属性 許可プロバイダー 許可プロバイダー カスタム・プロパティー カスタム・プロパティー Web 属性(SSO) - SSL - 監査 - LTPA 認証メカニズム - Kerberos 認証メカニズム -

- 12 -

6-2-2-3 セキュリティー・ドメインへの有効範囲の関連付け WAS V7.0 では、セキュリティー・ドメインに以下の有効範囲を関連付けることができます。

セル

サーバー

クラスター

SIBus

セキュリティー・ドメインを作成して、ある有効範囲に関連付けると、その有効範囲内のユーザー・アプリ

ケーションだけが、そのセキュリティー・ドメインで定義されているセキュリティー属性を使用します。ただ

し、その有効範囲内でのネーミング操作、管理アプリケーションにおいては、グローバル・セキュリティー

構成が使用されます。グローバル・レベルにあるセキュリティー属性を変更する必要のあるセキュリティ

ー属性は、ドメイン・レベルで定義します。情報が共通の場合は、セキュリティー・ドメインにその情報を

重複して持たせる必要はありません。ドメインに欠落している属性は、グローバル構成から取得されま

す。 サーバーがクラスターの一部である場合は、セキュリティー・ドメインをそのクラスターに関連付けること

ができますが、そのクラスター内の個々のメンバーに関連付けることはできません。したがって、セキュリ

ティーの動作は、すべてのクラスター・メンバーに渡って一貫性のあるものになります。 セキュリティー・ドメインをセルに関連付ける場合は、通常、WAS 内のすべてのユーザー・アプリケーシ

ョンをセキュリティー・ドメインに関連付けたい場合です。この場合、すべての管理アプリケーションとネー

ミング操作は、グローバル・セキュリティー構成を使用するのに対し、すべてのユーザー・アプリケーショ

ンは、ドメイン・レベルの構成を使用します。管理アプリケーションおよびユーザー・アプリケーションのセ

キュリティー構成情報を分割するのであれば、有効範囲をセルレベルにしてください。

6-2-3 設定方法 1). ［セキュリティー］→［セキュリティー・ドメイン］を選択します。セキュリティー・ドメインを作成する方法

として、新規作成、既存セキュリティー・ドメインをコピー、グローバル・セキュリティーをコピー、の 3つの方法があります。ここでは新規作成します。

2). [新規作成]ボタンをクリックします。

- 13 -

3). [名前]欄にセキュリティー・ドメインの名前を入力します。[説明]欄への入力は任意です。そして[適

用]ボタンをクリックして、セキュリティー・ドメインの詳細ページに進みます。

4). セキュリティー・ドメインに割り当てる有効範囲を指定します。割り当てたい有効範囲のチェックボッ

クスにチェックを入れます。 5). 新規ドメインにセキュリティー属性を指定して、そのドメイン内のセキュリティー構成をカスタマイズし

ます。ここでは、ユーザー・レルムをスタンドアロン LDAP レジストリーにカスタマイズします。レルム・

タイプから[スタンドアロン LDAP レジストリー] を選択して、[構成]ボタンをクリックします。

- 14 -

6). 既存のレルムを指定する場合は、[レルム名の入力]をクリックしてレルム名の入力を行います。新

規にレルムを作成する場合は、[システムによるレルム名の作成を許可する]をクリックして、適宜必

要な設定を行って[OK]ボタンをクリックします。

7). [セキュリティー・ドメイン]→[セキュリティー・ドメイン名]にて[適用]ボタンをクリックします。

8). 構成変更を保管したら、サーバーを再始動して変更内容を有効にします。

- 15 -

6-2-4 考慮点 複数セキュリティー・ドメインを構成するにあたっての考慮点を以下に説明します。

6-2-4-1 古いサーバー・レベルのセキュリティーと新しいセキュリティ

ー・ドメインの関係 WAS V6.1 までは、サーバー・レベルのセキュリティー属性セットを関連付けることができました。これら

の属性は、サーバー・レベルのすべてのアプリケーションで使用されていました。セキュリティー属性の

以前の構成方法は、WAS V7.0 では非推奨になっており、将来のリリースでは削除されます。 スクリプトの互換モードが false になっている場合 (-scriptCompatibility="false")、マイグレーション・

ツールを使用すると、既存のサーバー・レベルのセキュリティー構成情報が、新しいセキュリティー・ドメ

イン構成にマイグレーションされます。スクリプトの互換モードが true に設定されている場合、サーバ

ー・レベルのセキュリティー構成は、新規のセキュリティー・ドメイン構成にマイグレーションされません。

6-2-4-2 セキュリティー・ドメインの使用時のクライアントおよびアプリ

ケーション・セキュリティー・プログラミング・モデル EJB にアクセスするクライアントとして動作する Java クライアントまたはアプリケーションは、一般に最

初にネーミング検索を実行します。ネーミング・リソースは、管理アプリケーションおよびユーザー・アプリ

ケーションの両方によって使用され、管理リソースとみなされます。ネーミング・リソースは、グローバル・

セキュリティー構成情報によって保護されます。グローバル・セキュリティーがあるレルム (ユーザー・レ

ジストリー) を使用し、ドメインがそれとは異なるレルムを使用している複数ドメイン・セットアップでは、

Java クライアントは 2 つの異なるレルムにより認証を受ける必要があります。最初の認証は、ネーミング

操作を正常に行うために、グローバル・セキュリティー構成内のレルムに対して必要で、2 つ目の認証

は、異なるレルムを使用している EJB にアクセスするために必要です。 すべてのネーミング読み取り操作は、CosNamingRead ロールによって保護されます。このロールに

は、通常 Everyone が割り当てられます。これは、すべてのユーザーが有効であるか否かには関係なく

名前空間を検索できる、ということを意味しています。複数セキュリティー・ドメインが定義されている場

合、CosNamingRead ロールが Everyone を持っていると、クライアント側のセキュリティー・ランタイム・コ

ードは、ログインを促すプロンプトを表示しません。その代わりにこのセキュリティー・ランタイム・コード

は、非認証サブジェクトを使用してネーミング操作にアクセスします。ネーミング検索操作が完了して、ク

ライアントが EJB にアクセスしようとすると、現在 EJB アプリケーションが使用しているレルム (すなわ

ち、ドメインで使用されているレルム) を示すログイン・パネルがプロンプトとしてクライアントに表示され

ます。クライアントはそのレルムに対応する適切なユーザー・クレデンシャルを提供することにより、EJB にアクセスできます。

6-2-4-3 複数ドメイン構成におけるアプリケーション・デプロイメント 複数ドメイン構成でアプリケーションをデプロイする場合は、同じセキュリティー・ドメインに属するサー

バーまたはクラスターに、アプリケーション内のすべてのモジュールをインストールする必要があります。

もしそうしなかった場合、これらのセキュリティー・ドメインに構成されているセキュリティー属性によって

は、動作の一貫性が失われる可能性があります。異なるドメインに渡ってアプリケーションがデプロイさ

れると、アプリケーションのデプロイメントはほとんどの場合で失敗します。

- 16 -

6-2-4-4 相互レルム通信 アプリケーションが異なるレルムを使用している他のアプリケーションと通信する必要がある場合は、

RMI/IIOP および LTPA トークン使用時に、インバウンド通信とアウトバウンド通信の両方に対して信頼関

係を確立する必要があります。

6-2-4-5 ノードとセキュリティー・ドメインの統合

Base サーバーをセルに統合する場合は、セキュリティー・ドメインに割り当てられたリソースを、セル有

効範囲ではなく、サーバー有効範囲にする必要があります。統合中に Base のセキュリティー・ドメインが

セル・レベルになっている場合、addNode コマンドは失敗します。統合中にセキュリティー・ドメインを組

み込まないようにするためには、-excludesecuritydomains オプションを使用できます。

6-3 認証 この節では、WAS V7.0 における基本的なセキュリティー技術の一つである認証について説明しま

す。

6-3-1 認証とは 認証とは、リソースを要求するユーザーが「誰であるか」、そして「本人であるか」を証明するプロセスで

す。最も一般的に使われる認証手法は、ユーザーID とパスワードの照合による審査です。

6-3-2 認証モデル WAS セキュリティーにおける認証は、Java EE のセキュリティー・モデルに基づいて行われます。Java

EE については、下記サイトから詳細が得られます。

Sun Developer Network (SDN) Java EE 「Do more with less work.」 http://java.sun.com/javaee/index.jsp

WAS の認証モデルは、以下の要素から構成されています。それぞれの詳細は後述します。（「6-3-3

ユーザー・レジストリー（p17）」、「6-3-4認証メカニズム(p18)」参照）

ユーザー・レジストリー

ユーザー情報を登録するレジストリー。OS レジストリーや LDAP などをサポート。

認証メカニズム

ユーザーの提示した情報を登録済みのユーザー情報と照会・確認するための方法

- 17 -

6-3-3 ユーザー・レジストリー WAS のユーザー・レジストリーは、管理セキュリティーやアプリケーション・セキュリティーなど WAS が

提供するセキュリティー機能を有効にする場合に使用されます。WAS はユーザー・レジストリーに存在

するユーザーおよびグループ情報を用いて認証をおこなったり、セキュリティー・ロールへのマッピング

などの操作を実施します。 WAS V7.0 では以下のようなさまざまなタイプのユーザー・レジストリーをサポートしています。

ローカル OS レジストリー

ローカル・マシン上のOSのユーザー情報がレジストリーとして使用され、ユーザーIDとパ

スワード情報が認証時に使用されます。アプリケーション・サーバーが複数のマシンに

分散しているセル環境では、各マシンが独自のユーザー・レジストリーを持つため、ロー

カル OS ユーザー・レジストリーを使用しないでください。ユーザー・レジストリーから取り

出した ID は、通常、固有の ID であるため、まったく同じユーザーとパスワードが各マシン

上に存在しても、マシンごとに異なります。また、UNIX システムでローカル OS ユーザー・

レジストリーを使用する場合、WAS プロセスを実行するプロセス ID は、ユーザーやグル

ープ情報取得用のローカル OS の API を呼び出すために、root 権限を持っている必要が

あります。

スタンドアロン LDAP レジストリー

LDAP は、LDAP バインディングを使用する認証が行われるユーザー・レジストリーです。

WAS セキュリティーは、ユーザーおよびグループの情報用リポジトリーとして機能する主

要な LDAP ディレクトリー・サーバーのインプリメンテーションを提供し、サポートします。

これらの LDAP サーバーは、ユーザー認証やその他のセキュリティー関連タスクの際に

呼び出されます。カスタム LDAP フィーチャーにより、適切なフィルターを使用すれば、製

品がサポートする LDAP サーバーのリストにはない、他の任意の LDAP サーバーをユー

ザー・レジストリーとして使用できます。

スタンドアロン・カスタム・レジストリー

開発者は、com.ibm.websphere.security.UserRegistryインターフェースを実装することによ

り、セキュリティーに使用するユーザー・レジストリーを自由に作りこむことができます。カ

スタム・ユーザー・レジストリーは、リレーショナル・データベース、フラット・ファイルなど、

事実上あらゆるタイプのアカウント・レポジトリーをサポートすることができます。既存の

アプケーションでユーザーID、パスワードを管理するためにデータベースを使用している

場合などは、このインターフェースを実装すればそのデータベースを WAS セキュリティー

のユーザー・リポジトリーとすることが可能です。

統合リポジトリー

統合リポジトリーは、複数のレジストリーを同時に使用しながら論理的な単一リポジトリ

ーのビューを提供します。1 つのレルム下には、次の 3 種類のユーザー・リポジトリーの

組み合わせが可能です。

ビルドインされたファイル・ベース・リポジトリー

1 つ以上の外部リポジトリー

ファイル・ベース・リポジトリーと 1 つ以上の外部リポジトリー

- 18 -

統合リポジトリーは read/write 両方をサポートします。統合リポジトリーがサポートするリ

ポジトリーのタイプはさまざまで、以下の 4 種類のリポジトリーをサポートします。ファイ

ル・ベースのリポジトリーはデフォルトで提供されます。

ファイル・ベース

LDAP（または LDAP のサブツリー）

データベース

カスタム

このうちデータベースとカスタムは管理コンソールから操作することはできません。コマ

ンドラインからのみサポートされていますのでご注意ください。なお、統合リポジトリーを

使用する場合、ユーザー名は統合リポジトリーに追加されている複数リポジトリー内で

ユニークである必要があります。

6-3-4 認証メカニズム WAS は認証メカニズムとして LTPA、Kerberos、RSA トークンの 3 種類をサポートしています。 LTPA はプロファイル作成時にセキュリティーが有効であればデフォルトで構成されます。なお、使用

可能なユーザー・レジストリーは、統合リポジトリー、ローカル OS ユーザー・レジストリー、スタンドアロン

LDAP レジストリー、スタンドアロン・カスタム・レジストリーの４種類になります。

LTPA

LTPA は、分散環境と複数アプリケーション・サーバーおよび複数マシン環境を対象として

います。LTPA は、転送可能な信任状およびシングルサインオン(SSO)（※１）をサポートし

ています。LTPA は、分散環境のセキュリティーを暗号化によりサポートしているので、認証

関連のデータを暗号化し、デジタル署名して安全に伝送し、後で署名を暗号解除して検査

することができます。複数のノードおよびセルに分散されているアプリケーション・サーバー

は、LTPA を使用することによって安全に通信を行うことができます。また、SSO・フィーチャ

ーも提供されます。SSO では、ユーザーは Domain Name System(以下、DNS)ドメインで一

度だけ認証を受けるだけで、プロンプトが出されることもなく、WAS の他のセルにあるリソー

スにアクセスすることができます。

Kerberos

WAS V7.0 から新しく Kerberos 認証がサポートされるようになりました。Kerberos 認証はオ

ープンでかつ成熟したネットワーク認証プロトコルで、認証、相互認証、メッセージの保全性

と機密性、および代行の機能を持ちます。Keroberos はクライアント、サーバー、および

Kerberos 鍵配布センター (KDC) と呼ばれる信頼のおける第三者機関という 3 つのパー

ツで構成されており、それゆえギリシャ神話の 3 つの頭をもつという地獄の番犬 Kerberos

の名前がつけられています。Kerberos 認証の利点のひとつとして、標準規格のため、.様々

な製品でサポートされており(NET や DB2 など)、他のアプリケーションとのインターオペラビ

リティーが可能になることがあげられます。WAS V7.0 では LTPA と Kerberos の同時使用も

サポートしています。

RSA トークン

RSA トークン認証も WAS V7.0 から新しく導入された認証方式です。この認証方式は

Flexible Management 環境におけるサーバー間の管理認証 (管理コネクターおよびファイ

ル転送要求) にのみ使用されます。RSA トークン認証を使用することにより、フレキシブル・

マネジメント環境での管理プロセス間のセキュリティ構成を各プロファイルのセキュリティ構

成から分離することが可能になります。

- 19 -

WAS V6.0 までサポートされていた SWAM は WAS V7.0 では推奨されていません。将来のリリースで

除去される予定です。

(※1) シングルサインオン(SSO)とは、複数台の WAS セキュリティー・サーバーが存在する場合に、一度ユ

ーザーが DNS ドメインで認証されると、他のセキュリティー・サーバーにアクセスする場合に再度認証を

行うことなく、同一のユーザーとしてリソースへのアクセスを継続できる機能です。WAS は、LTPA や

SPNEGO を用いた SSO をサポートしています。

6-3-5 仮想メンバー・マネージャー（VMM:virtual member manager）

図 6-4 VMM アーキテクチャー概要

統合リポジトリーが提供するユーザーやグループの管理、同時に複数のレジストリーをサポートする機

能は仮想メンバー・マネージャー（VMM）によって提供されています。VMM の目的は、ユーザーおよび

組織情報に対して、単一のモデルを提供することです。つまり VMM は、リポジトリーに特化しない、ユ

ーザーとグループを管理するための API とスキーマを提供します。この管理機能は、管理コンソール、コ

マンドライン・ユーティリティ、公開された API から利用できます。

6-3-6 認証プロセス 前述の認証メカニズム機構とユーザー・レジストリーによって行われる WAS V7.0 の認証プロセスは、

図 6-5のような流れとなります。 基本的に、認証が必要なのは EJB クライアントと Web クライアントが保護リソースにアクセスする場合

です。サーブレット、EJB、または純粋な EJB クライアントは、CSIv2 プロトコルを使用して、WAS に認証

アプリケーション wsadmin

Local OS

CUR VMM

LDAP

ユーザー・レジストリー

LDAP DBFile Custom

Adaptor Adaptor Adaptor Adaptor

認証 (JAAS)

管理コンソール

VMM ランタイム

APIs

VMM 構成 APIs

Administrative Command Framework

リポジトリー

Property Ext

Adaptor

DB

WASセキュリティVMM ユーザー管理 VMM構成管理

VMM = Virtual Member Manager

- 20 -

情報を送信します。Web クライアントは、HTTP や HTTPS といったプロトコルを使用して認証情報を送信

します。 認証情報は、基本認証、信任状トークン、またはクライアント証明書のいずれかです。Web 認証は

Web オーセンティケーター・モジュールにより実行され、EJB 認証は CSIv2 層にある EJB オーセンティケ

ーター・モジュールにより実行されます。 認証モジュールは、JAAS ログイン・モジュールを使用して実

装されます。Web オーセンティケーターおよび EJB オーセンティケーターは、ログイン・モジュールに認

証データを渡し、データを認証するために LTPA の認証モジュールを呼び出します。認証モジュール

は、認証にローカル OS、LDAP、カスタム・レジストリーのいずれかをユーザー・レジストリーとして使用し

ます。 認証後にログイン・モジュールによって作成される信任状は、Web オーセンティケーター・モジュール

または EJB オーセンティケーター・モジュールに返されます。そして、Web オーセンティケーター・モジュ

ールまたは EJB オーセンティケーター・モジュールは、アクセス許可の仕組みが後に参照できるよう、こ

の信任状を保管しておきます。

図 6-5 認証プロセス

6-3-7 設定方法 ここでは、管理コンソールを使用した統合リポジトリー、SSO、トラスト・アソシエーション、ユーザー・レ

ジストリーなどの設定方法を紹介します。

6-3-7-1 統合リポジトリー 統合リポジトリーの設定は 2 つのステップからなります。まず、最初に LDAP などのリポジトリーを追加

し、それを統合リポジトリーに追加するという流れになります。 管理コンソールの[セキュリティー]→[グローバル・セキュリティー]画面を開き、ユーザー・アカウント・リ

ポジトリー・フィールドの[使用可能なレルム定義]で[統合リポジトリー]を選択し、右隣の[構成]ボタンをク

リックします。デフォルトではレルム内のリポジトリーはファイル・ベースのリポジトリーのみです。

- 21 -

統合リポジトリー画面では、[ベース・エントリーをレルムに追加]ボタンをクリックします。

リポジトリー参照画面で、[リポジトリーの追加]ボタンをクリックし、追加リポジトリーへのセキュア・アクセ

スに関する構成を次画面で行います。必要な項目を入力したら[OK]ボタンを押します。

管理コンソールから、[セキュリティー]→[グローバル・セキュリティー]を開き、ユーザー・アカウント・リ

ポジトリー・フィールドの[使用可能なレルム定義]で[統合リポジトリー]を選択し、右隣の[構成]ボタンをク

リックします。関連項目の[リポジトリーの管理]をクリックすると、追加されたリポジトリーを確認することが

できます。

- 22 -

6-3-7-2 SSO SSO（シングル・サインオン）とは、複数のシステムの認証処理を 1 回のログオンで実行する認証方法

です。例えばそれぞれ認証が必要なシステム A とシステム B があります。これらのシステムが SSO を実

現していると、システム A で認証を行ったクライアントは、システム B にアクセスする際に再度認証を必要

とすることなくアクセスが可能になります。 WAS でサポートされる一般的な SSO の方式は LTPA 認証を使用する方式です。これは、WAS が

LTPA 鍵の交換をサポートしているため実現することができます。LTPA 認証方式では、クライアントは最

初に認証を受けたサーバーから LTPA トークンを受け取ります。この LTPA トークンはユーザー情報と有

効期限が含まれています。2 回目以降のアクセスでは、LTPA トークンを持ってサーバーにアクセスし、

サーバーはトークンの内容に従って認証を行います。従って、異なるシステム間で認証に使用する

LTPA トークンを共通化することで SSO を実現することが可能になります。他にもKerberos ログイントーク

ンを使用した SPNEGO（Simple and Protected GSS-API Negotiation）と呼ばれる方法も WAS でサポート

されています。

SSO におけるログインの処理の流れを表したのが、図 6-6になります。 /FormAuth/login.html がシステムのログオン画面です。この画面でユーザーID/パスワードを入力して

ログオンボタンをクリックすると、サーバーに対する認証要求が実行されます。ユーザーID とパスワード

が正しい場合には LTPA トークンが発行され、保護されたリソースに対してアクセス可能になります。この

後システム B の保護されたリソースに対してアクセスをします。この際 HTTP リクエストにはシステム A で

発行されたLTPAトークンが付加されています。システムBはシステムA の LTPAトークンの情報を元に、

クライアントからにリクエストを許可して、画面を返します。

- 23 -

図 6-6 SSO におけるログイン処理の流れ

SSO の設定は、管理コンソールから LTPA トークンを共有する範囲を指定するドメイン・ネームの設定

と、LTPA 鍵の交換を行う必要があります。LTPA を共有する範囲をの設定は、[セキュリティー]→[グロー

バル・セキュリティー]→[認証]→[Web および SIP セキュリティー]→[シングル・サインオン (SSO)]を開いて行います。ドメイン・ネームを入力します。デフォルトはサーバー名です。クライアントはここで設定

されたドメイン名に対して、同じ LTPA トークンを付加します。したがって、ドメイン名が異なるシステム間

では SSO を実現することは出来ません。

図 6-7 SSO の設定

- 24 -

LTPA の交換のため、鍵のエクスポートとインポートを行います。 特定のサーバーから LTPA 鍵をエクスポートします。インポート時に必要となるパスワードを入力しま

す。パスワードは任意の値を入力することが可能です。完全修飾鍵ファイル名は、LTPA 鍵をエクスポー

トするファイル名を完全修飾名で指定して、エクスポートボタンをクリックします。エクスポートを行う画面

は[セキュリティー]→[グローバル・セキュリティー]→[認証]→[LTPA]です。エクスポートした LTPA 鍵は

テキスト形式ですので、テキスト・エディタで内容を確認することができます。 エクスポートした LTPA 鍵を別のサーバーでインポートします。 まずエクスポートで作成したファイルのインポートを行うサーバーに移動させます。そしてエクスポート

時に指定したパスワードを入力し、完全修飾鍵ファイル名を指定してインポートボタンをクリックします。

インポートを行う画面は、エクスポートを行う画面と同じで[セキュリティー]→[グローバル・セキュリティー]→[認証]→[LTPA]です。

図 6-8 LTPA のインポートエクスポート画面

構成を保管し、アプリケーション・サーバーあるいはデプロイメント・マネージャーを再起動します。

6-3-7-3 トラスト・アソシエーション トラスト・アソシエーションにより、WASセキュリティーとサード・パーティー製セキュリティー・サーバーと

を統合することができます（「6-1-2 セキュリティー概観」参照）。トラスト・アソシエーションの設定は、管理

コンソールの[セキュリティー]→[グローバル・セキュリティー]→[認証]→[Web および SIP セキュリティ

ー]→[トラスト・アソシエーション]を開いて行います。各項目に適切な値を設定してから構成を保管し、

アプリケーション・サーバーあるいはデプロイメント・マネージャーを再起動します。

図 6-9 トラスト・アソシエーションの設定画面

トラスト・アソシエーションを使用可能にする

- 25 -

トラスト・アソシエーション機能を有効にするかどうかを指定します。トラスト・アソシエーシ

ョン機能により、WAS セキュリティーとサード・パーティー製セキュリティー・サーバーを統

合することができます。つまり、リバース・プロキシー・サーバーがフロントエンド認証サ

ーバーとして機能できるようになる一方で、プロキシー・サーバーから渡された信任状を

この製品自体の認証ポリシーに適用することができるようになります。

6-4 認可 この節では、WAS V7.0 における基本的なセキュリティー技術の一つである認可について説明しま

す。

6-4-1 認可とは 認可とは、認証されたユーザーが、要求するリソースにアクセスする権限をもっているかを判定するプ

ロセスであり、アクセス制御とも言われます。

6-4-2 認可モデル WAS セキュリティーにおける認可は、Java EE のセキュリティー・モデルに基づいて行われます。Java

EE の認可の情報については、下記サイトから詳細が得られます。

Sun Developer Network (SDN) Java EE 「Do more with less work」 http://java.sun.com/j2ee/index.jsp

個々のユーザーに対してアクセス制御を行うのではなく、セキュリティー・ロールという概念の元にアク

セス制御を行います。セキュリティー・ロールを使用することによって、ユーザー管理を WAS 環境から分

離することができます。HTML、サーブレット、JSP、EJB などといったリソースに対して、図 6-10のように

セキュリティー・ロールを設定してアクセス制御を行うことができます。例えば、Teller ロールを設定しま

す。表から Teller ロールは AccountBean method の getBalance を実行することが可能です。このロール

を持つユーザーは、Teller Group と Bob になります。よって、Bob は getBalance を実行することができ

るユーザーになります。

図 6-10 セキュリティー・ロールの設定例

- 26 -

WAS の認可モデルには、以下の二形態があります。それぞれの詳細は後述します。（「6-4-3宣言セ

キュリティー(p26)」、「6-4-4プログラマティック・セキュリティー(p26)」参照）

宣言セキュリティー（デクララティブ・セキュリティー）

デプロイメント・ディスクリプターにセキュリティー・ポリシーを記述する方法

プログラマティック・セキュリティー

API を使用してコード内でセキュリティー・タスクを実装する方法

6-4-3 宣言セキュリティー 宣言セキュリティーは、アプリケーションのアセンブリー段階で構成されるもので、セキュリティー・ポリ

シーなどの情報はデプロイメント記述子で宣言または定義されています。宣言セキュリティーは、セキュ

リティー・ランタイムによって実行されます。ここに、Servlet2.5 におけるデプロイメント記述子の一例を示

します。

<security-constraint>

<display-name>ExampleSecurityConstraint</display-name>

<web-resource-collection>

<web-resource-name>

ExampleWRCollection

</web-resource-name>

<url-pattern>/example</url-pattern>

<http-method>POST</http-method>

<http-method>GET</http-method>

</web-resource-collection>

<auth-constraint>

<role-name>exampleRole</role-name>

</auth-constraint>

<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>

例 6-1 デプロイメント記述子の一例

6-4-4 プログラマティック・セキュリティー プログラマティック・セキュリティーは、宣言セキュリティー単独ではアプリケーションのセキュリティー・

モデルを表現するのに十分でない場合に、セキュリティーを重視するアプリケーションによって使用され

ます。Servlet と EJB に対して API を提供しており、コードの中でそれらを使用してセキュリティー・タスク

を実装することができます。 プログラマティック・セキュリティーは、HttpServletRequest インターフェースの以下のメソッドから構成さ

れています。

HttpServletRequest.getRemoteUser

アクセス制限する Web リソースを設定

アクセスを許可する ロールを設定

クライアントとの 通信方法を設定

- 27 -

クライアント認証に使用したユーザー名を戻します。ユーザーが認証されていない場合

は、null を戻します。

HttpServletRequest.isUserInRole

リモート・ユーザーに指定されたセキュリティー・ロールが与えられている場合は、true を

戻します。リモート・ユーザーが、指定されたロールを与えられていない場合、またはユ

ーザーが認証されていない場合は、false を戻します。

HttpServletRequest.getUserPrincipal

リモート・ユーザー名を含む java.security.Principal オブジェクトを戻します。ユーザーが認

証されていない場合は、null を戻します。

また、javax.ejb.EJBContext インターフェースで提供される次の２つのメソッドを使用すると、EJB の呼

び出し元についてのセキュリティー情報にアクセスすることができます。

IsCallerInRole

Bean の呼び出し元に、ロール名で指定されているセキュリティー・ロールが認可されてい

る場合は、true を戻します。呼び出し元に指定のロールが認可されていない場合、また

は呼び出し元が認証されていない場合は、false を戻します。指定のロールに、全員のア

クセスが認可されている場合は、常に true を戻します。

getCallerPrincipal

Bean呼び出し元の名前を含むjava.security.Principalオブジェクトを戻します。呼び出し元

が認証されていない場合は、認証されていない名前を含むプリンシパルを戻します。

6-4-5 代行モデル 代行とは、セキュリティーID を呼び出し元から呼び出されるオブジェクトに伝搬するプロセスです。

Java EE 仕様により、サーブレットと EJB は、EJB を呼び出す際にクライアント ID を伝搬することも、ある

いはデプロイメント記述子で明示指定された別の ID を使用することもできます。WAS では、図 6-11のよ

うにクライアント ID、指定済み ID、システム ID といった 3 つのタイプの代行が可能です。

- 28 -

図 6-11 代行モデル

6-4-6 認可プロセス 前述のような認可機構によって行われる WAS V7.0 の認可プロセスは、図 6-12のような流れとなりま

す。

- 29 -

図 6-12 認可プロセス

Web クライアントからの Web リソース・アクセスは、Web コラボレーターによって処理されます。Java クラ

イアント(エンタープライズ Bean またはサーブレット)からの EJB リソースへのアクセスは、エンタープライ

ズ Bean コラボレーター（以下、EJB コラボレーター）によって処理されます。Web コラボレーターと EJB コ

ラボレーターは、ORBcurrent オブジェクトからクライアント信任状を抽出します。クライアント信任状は、

認証プロセスの際に ORBcurrent オブジェクトで受け取った信任状として設定されます。リソースと受信さ

れた信任状はアクセス・マネージャーに提示され、クライアントに対して、そのクライアントが要求している

リソースへのアクセスが許可されているかどうかがチェックされます。 アクセス・マネージャー・モジュールには、リソース許可モジュールと許可テーブル・モジュールといっ

た２つのメイン・モジュールがあります。 リソース許可モジュールは、指定のリソースに必要なロールを決定するのに役立ちます。このモジュー

ルは、セキュリティー・ランタイムがアプリケーションの始動時に作成する、リソースからロールへのマッピ

ング表を使用します。リソースからロールへのマッピング・テーブルを作成するために、セキュリティー・ラ

ンタイムは、エンタープライズ Bean または Web モジュールのデプロイメント記述子 (ejb-jar.xml ファ

イルまたは web.xml ファイル) を読み取ります。 許可テーブル・モジュールは、ユーザーまたはグループに対するロール表を調べ、クライアントに必

要なロールのいずれかが付与されているかどうかを判断します。ロールからユーザーまたはグループへ

のマッピング・テーブルは許可テーブルとも呼ばれ、アプリケーション始動時にセキュリティー・ランタイム

によって作成されます。許可テーブルを作成するために、セキュリティー・ランタイムはアプリケーション・

バインディング・ファイル(ibm-application-bnd.xmi または ibm-application-bnd.xml)を読み取ります。 呼び出し元がサービスの要求に必要な特権を持っているかどうかを判別するためには、許可情報を

使用します。許可情報は、いろいろな方法で保管できます。例えば、リソースごとにアクセス制御リストを

保管することができ、ここには、ユーザーおよびユーザー特権のリストが含まれています。もう１つの保管

方法は、リソースのリストとそれに対応する特権を各ユーザーに関連付けることです。

- 30 -

6-5 SSL この節では、WAS V7.0 における基本的なセキュリティー技術の一つである SSL について説明しま

す。

6-5-1 SSL とは SSL とは、クライアントとサーバー間のセキュア接続のための認証性、保全性、および機密性のあるト

ランスポート層セキュリティーを提供するプロトコルです。このプロトコルは、TCP/IP の上位、かつHTTP、

LDAP、ORB/IIOP などのアプリケーション・プロトコルの下位で実行され、トランスポート・データに信頼

性とプライバシーを提供します。 クライアントとサーバー双方の SSL 構成に応じて、さまざまなレベルの信頼性、データ保全性、および

プライバシーを確立することができます。適切な構成を行い、クライアントとアプリケーション両方のデー

タに必要な保護レベルを実現するためには、SSL の基本動作について理解していることが非常に重要

です。 SSL によって提供されるセキュリティー・フィーチャーの中には、データの伝送中に機密情報が漏れな

いようにするためのデータの暗号化があります。また、データの署名により、データの転送中にデータが

許可なく変更されることを防止できます。更に、クライアント認証およびサーバー認証により、適切なユー

ザーまたはマシンと通信していることが保証されます。SSL は、エンタープライズ環境の通信の保護に効

果的です。

図 6-13 SSL の仕組み

- 31 -

6-5-2 SSL 構成 WAS では、内部にある複数のコンポーネントが SSL を使用することで、データを信頼できるものにし、

プライバシーを保護します。これらのコンポーネントとは、標準装備された HTTP トランスポート、ORB、

およびセキュア LDAP クライアントです。

各コンポーネント間において使用される SSL は、以下の通りです。

HTTP トランスポート

WAS に組み込まれた HTTP トランスポートは、ブラウザーなどの Web クライアントから

SSL を介した HTTP 要求を受け入れます。

ORB

WAS で使用される ORB は、SSL を介して IIOP を実行し、メッセージを保護します。

セキュア LDAP クライアント

セキュア LDAP クライアントは、SSL を介して LDAP を使用し、LDAP ユーザー・レジストリ

ーへのセキュア接続を実現します。このクライアントは、LDAP をユーザー・レジストリー

として構成する場合にのみ存在します。

6-5-3 SSL 証明書 SSL 通信の際には SSL 証明書が必要になります。デジタル証明書、デジタル ID、単に証明書とも呼

びます。証明書には、ベリサインなどの認証局(CA)によって発行された証明書と自己署名証明書があり

ます。認証局が発行した証明書は認証局の秘密鍵を使用した署名が付いているのに対して、自己署名

証明書は自分自身の秘密鍵を使用した署名が付いています。それらの証明書が使い分けされるケース

としては、ブラウザーと Web サーバー間の SSL 構成には認証局が発行する証明書を使用し、WAS 内部

コンポーネント間の SSL 構成には自己署名証明書が使用されるケースが考えられます。 WAS V6.1 の証明書管理機能で作成される証明書はすべて自己署名証明書でした。WAS V7.0 で

は、以前のバージョンとは異なり、チェーン証明書がデフォルトで採用されています。チェーン証明書と

は、証明書に署名するために別の証明書(ルート証明書)が使用された証明書になります。自己署名証

明書は自身によって署名されているのに対して、チェーン証明書は WAS が認証局として発行したルー

ト証明書によって署名されている点が異なります。また、チェーン証明書は、証明書に別の証明書で署

名しているという点において CA 証明書と同じ構造であるといえます。そして、ルート証明書は、チェーン

証明書より有効期限が長く、WAS コンポーネント間で共有されます。 図 6-14はデフォルトで作成されるチェーン証明書になります。図の発行先と発行元に注目すると、チ

ェーン証明書(別名：default)はルート証明書が発行した（署名した）証明書であり、ルート証明書は WAS内部で発行した自己署名証明書であることがわかります。

デフォルトの有効期限は、チェーン証明書が 1 年、ルート証明書が 15 年になっています。この有効期

限は、プロファイル作成（拡張プロファイル作成）時に変更することが可能です。チェーン証明書が 1 年

～15 年（1 年単位）、ルート証明書が 15 年/20 年/25 年から選択できます。プロファイルツール画面上の

記述は、個人証明書がチェーン証明書、署名者証明書がルート証明書に該当します。

- 32 -

図 6-14 デフォルト個人証明書

6-5-4 設定方法 ここでは、Web ブラウザーと Web サーバー間および Web サーバーと WAS 間を SSL 通信させるため

の設定方法をそれぞれ紹介します。

6-5-4-1 Web ブラウザーと Web サーバー間の SSL 構成 WAS は Web ブラウザーと Web サーバー間での SSL 通信をサポートしています。SSL 通信には Web

サーバーの機能が使用され、Web サーバー側で SSL 通信を可能にするための設定を行う必要がありま

す。具体的な手順は、Web サーバーの製品ごとに異なりますので、各製品のマニュアル等を参照してく

ださい。ここでは、Web サーバーとして IHS を使用している場合の設定方法を紹介します。

Web サーバーの設定 IHS で SSL 通信の設定を行うには、IHS の構成ファイル<IHS_root>/conf/httpd.conf を編

集します。IHS の構成ファイルは、WAS の管理コンソールを介して編集することもできま

す。httpd.conf を開き、次の行をファイルの下部に追加します。

鍵ファイルのホスト名とパスは適宜変更してください。また、SSLClientAuth ディレクティブ

のコメントアウトをはずすことにより、クライアント認証をサポートすることができます。

LoadModule ibm_ssl_module modules/mod_ibm_ssl.so Listen 443 <VirtualHost <host_name>:443> ServerName <host_name> DocumentRoot <IHS_root>/htdocs SSLEnable SSLServerCert <cert_name> #SSLClientAuth required </VirtualHost>SSLDisable Keyfile <IHS_root>/serverkey.kdb

- 33 -

WAS の設定 WAS では、SSL 通信用のポートを使用して IHS と通信できるようにするには、仮想ホスト

default_host にホスト・エイリアスを追加する必要があります。管理コンソールの[環境]→[仮想ホスト]→[default_host]→[ホスト別名]を選択します。[新規作成]ボタンをクリックし

て、該当するフィールドに SSL 通信に使用するポート番号（通常は 443）を指定して、エイ

リアスを追加します。

6-5-4-2 Web サーバーと WAS の SSL 構成 Web サーバーと WAS 間で SSL 通信を行うためには、Web サーバーに組み込まれて実際にアプリケ

ーション・サーバーと通信を行っている Web サーバー・プラグインに SSL 通信用の設定を行う必要があり

ます。また、通信相手となる Web コンテナーにも設定を行う必要があります。ここでは、Web サーバーとし

て IHS を使用している場合の設定方法を紹介します。 注）

デフォルト構成では、Web ブラウザーと Web サーバー間が SSL 通信を行っている場合、Web サーバ

ーと WAS は自動的に SSL 通信用ポートを使用して SSL 通信を行います。パフォーマンスの観点から、

明示的に Web サーバーと WAS 間で SSL 通信をさせないためには、WAS で定義されている SSL 通信

用のトランスポートを削除する必要があります。この方法に関しては、本書では割愛させていただきます

ことをご了承ください。 1). Web サーバー・プラグイン用のチェーン証明書の作成

Web サーバー・プラグインはそれ自身の秘密鍵と公開鍵を保管し、Web コンテナーの鍵ファイルの公

開証明書を保管するために、鍵ストア（鍵データベース）を必要とします。今回はデフォルトで作成され

ている鍵ストア(CMSKeyStore)を使用します。Web サーバー・プラグイン用のチェーン証明書を作成する

には、以下のステップを実行します。尚、従来通り自己署名証明書を作成する事も可能です。

i). チェーン証明書を作成します。 管理コンソールから[セキュリティー]→[SSL 証明書および鍵管理]→[エンドポイント・セキ

ュリティ構成の管理 ]を選択します。 [インバウンド ]→<Node_name>→ [servers]→

<webserver_name>を選択します。CMSKeyStore を選択し、[個人証明書]→[作成]→[チェーン証明書]をクリックし、以下のように設定し、[OK]ボタンをクリックします。

- 34 -

別名：WAS7PluginCert 証明書に署名するために使用するルート証明書：root 鍵サイズ：1024 ビット（デフォルト） 共通名：マシン名 有効期間：365 日間（デフォルト）

2). Web コンテナー用のチェーン証明書の作成

ii). JKS タイプの鍵ストアを作成 管理コンソールから[セキュリティー]→[SSL 証明書と鍵管理]→[エンドポイント・セキュリ

ティ構成の管理]→インバウンド→<Cell_name>を選択します。[鍵ストアおよび証明書]→[新規作成]ボタンをクリックし、作成する鍵ストア構成の値を入力します。 名前：WebContainerKeyStore

パス：${CONFIG_ROOT}/cells/<cell_name>/WAS7WebContainerCertificates.jks パスワード：任意のパスワード タイプ：JKS

iii). チェーン証明書を作成します。 管理コンソールから[セキュリティー]→[SSL 証明書と鍵管理]→[エンドポイント・セキュリ

ティ構成の管理]→インバウンド→（セル名）を選択します。WebContainerKeyStore を選択

し、[個人証明書]→[作成]→[チェーン証明書]をクリックします。以下の値を入力して[OK]ボタンをクリックします。 別名：WAS7CustNode01Cert 証明書に署名するために使用するルート証明書：root 鍵サイズ：1024 ビット（デフォルト） 共通名：マシン名 有効期間：365 日間（デフォルト）

3). SSL 構成を作成します。 [SSL 証明書および鍵管理]→[SSL 構成]→[新規作成]を選択し、作成する SSL 構成の

値を入力します。 名前：WebContainerSSL トラスト・ストア名：WebContainerKeyStore（リストから選択） 鍵ストア名：WebContainerKeyStore（リストから選択）

証明書エイリアスを取得します。[証明書別名の取得]をクリックします。サーバーとクライア

ント証明書エイリアスを選択し、適用をクリックします。（※クライアント認証、CipherSuite、プ

ロバイダーやプロトコルの設定をするにはこの手順の後に、追加プロパティー＞QoP を選択

します。） 構成を保存します。

4). Web コンテナーが、前手順で作成した個人証明書を使用するように構成を修正します。

[サーバー]→[サーバー・タイプ]→[WebSphere Application Server]を選択しサーバ

ー名を選択します。[Web コンテナー設定]→[Web コンテナー・トランスポート・チェーン]を選択します。

- 35 -

[WCInboundDefaultSecure]をクリックし、使用可能にチェックが入っているのを確認し

ます。 [SSL インバウンド・チャネル（SSL2）]をクリックし、このエンドポイント特定を選択して、リ

ストから WebContainerSSL を選択します。[OK]を選択して構成を保存し、Web サーバー・

プラグインの再生成と伝播を行います。 5). 管理コンソールでプラグイン・プロパティを確認します。 [サーバー ]→ [Web サーバー ]→

[webserver_name]を選択します。追加プロパティーのプラグイン・プロパティを選択し、以下の

値になっているか確認します。 プラグインの鍵ストア・ファイル名 ・plugin-key.kdb

[Web サーバー鍵ストアディレクトリにコピーする]をクリックして、鍵ストア・ファイルと Stashファイルを Web サーバープラグインのリポジトリーにコピーします。

[OK]をクリックし、構成を保存します。

6). Web サーバー・プラグイン構成ファイルを編集します。 プラグイン構成ファイルが下記のような内容になっているかを確認します。

<Transport Hostname=”<Host_name>” Port=”9443” Protocol=”https”>

<Property name=”keyring”

value=”<Plugin_Install_Root>\config\<webserver_name>\plugin-key.kdb”/>

<Property name=”stashfile”

value=”<Plugin_Install_Root>\config\<webserver_name>\plugin-key.sth”/>

ポート番号に9080を使用しないよう9080のトランスポートの定義をコメントアウトします。

<!--<Transport Hostname=”[HostName]” Port=”9080”

プラグイン構成ファイルを保存し、Web サーバーを再始動します。

7). 動作確認を行います。 サンプル・アプリケーションの snoopServlet を稼動させ、SSL 通信が行えていることを確認

します。 https://[ホスト名]/snoop

図 6-15 snoop 画面

- 36 -

6-6 鍵と証明書 この節では、WAS V7.0 における鍵と証明書の管理について説明します。

6-6-1 Ikeyman と同等の機能を管理コンソールから使用 WAS V6.0 まで ikeyman で提供されていたのと同等の機能が WAS V6.1 より管理コンソールで行うこ

とができます。従来の ikeyman は WAS V7.0 でも引き続き使用することができます。ただし、個人証明書

と署名者証明書の管理は ikeyman、管理コンソールのどちらで行なっても可能ですが、証明書要求は

生成したツールを使用して受信する必要があります。これは、証明書要求を ikeyman で作成された場合

は ikeyman で受信する、管理コンソールで作成された場合は管理コンソールで受信する、という意味に

なります。また、鍵や証明書の管理は ikeyman、管理コンソールのほかに wsadmin からも AdminTask オ

ブジェクトを使用することで可能です。

6-6-2 証明書の有効期限 WAS V6.1 より証明書の有効期限を管理コンソールから管理することができます。対象は鍵ストアに格

納されている証明書と署名のみです。管理コンソールから、[セキュリティー]→[SSL 証明書および鍵管

理]→[証明書有効期限の管理]を選択します。この証明書の有効期限の管理のページでは、スケジュー

ルやしきい値に基づいてすべての証明書を検査します。また、関連項目にある[通知]では、有効期限

切れの警告をログや e-mail で知らせることができます。 有効期限のしきい値に達した場合、同じ証明書情報を使用して自動的に証明書を更新することや、

鍵ストア内にある古い証明書を新しい証明書に置き換えることも可能です。

- 37 -

図 6-16 証明書有効期限の管理と通知画面

WAS V6.1 では証明書自動更新による以下の問題がありました。 【ご注意ください】 WAS 6.1 の自己署名証明書・自動更新機能を使用する場合の考慮点 http://www-06.ibm.com/jp/domino01/mkt/websphere.nsf/doc/0033ED2E

WAS V7.0 ではデフォルトでチェーン証明書を使用しているため、この問題は発生しません。これはチ

ェーン証明書の署名を、コンポーネント間で共有されるルート証明書で行うためです。チェーン証明書

で使用するルート証明書は 15 年という長い有効期限を持っています。したがって、チェーン証明書の更

新を 1 年ごとに行ったとしても、証明書の検証失敗によって SSL 通信ができなくなるという問題は起こり

ません。 WAS V7.0 において自己署名証明書を使用する場合においては、同様の問題が発生しますので、注

意してください。自己署名証明書の場合は、トラスト・ストアに保管される署名者証明書として、自動更新

された自己署名証明書を保管する必要があり、SSL 通信を行うノード間でこの署名者証明書の交換が

正常に行えないとSSL通信に失敗して、環境によってはWASがサービス停止となってしまう可能性があ

ります。 WAS V7.0 では、wsadmin コマンドを使用して自己署名証明書をチェーン証明書に変換する事が可

能です。AdminTask オブジェクトの convertSelfSignedCertificatesToChained コマンドを使用してくださ

い。convertSelfSignedCertificatesToChained コマンドは、自己署名証明書の情報 (発行先識別名、サ

イズ、および存続期間など) を使用して、同じ情報のチェーン証明書を作成します。新しいチェーン証

明書によって自己署名証明書が置き換えられます。詳細は以下 URL を参照してください。 WAS V7.0 Information Center「AdminTask オブジェクトの SSLMigrationCommands コマンド・グル

ープ」 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.doc/inf

o/ae/ae/rxml_7sslmigration.html

6-7 監査 この説では、WAS V7.0 で追加された監査機能について説明します。

6-7-1 監査とは WAS V7.0 では、監査機能が追加され、WAS のインフラおよびアプリケーションで認証・認可やその

他のセキュリティー・イベントをモニターし、保護対象リソースに対して、「いつ」、「誰が」、「何をしたの

か」を監査ログに記録することが可能です。 この監査機能の使用目的として、主に２つの目的があります。１つは、既存システムのセキュリティー

構成の有効性と保全性を確保することです。2008 年 4 月から開始された日本版 SOX 法（金融商品取引

法）により、上場企業には「財務報告の適正性」を確保するための内部統制の整備が求められていま

す。そして内部統制の有効性の評価において、システムが出力する監査ログからいつでも必要な情報

を引き出せる必要があります。このように法令遵守を証明し、立証責任と否認防止の証拠の提示に役立

ちます。もう 1 つは、セキュリティー構成の改善が必要な領域を認識するなどの脆弱性分析に利用する

事ができます。監査ログをを分析することにより、既存のセキュリティー・メカニズムの欠陥を見つけたり、

現在のセキュリティー・インフラストラクチャーの潜在的な弱点を発見したりすることができます。

- 38 -

セキュリティー監査機能を使用可能にする場合には、ご使用の環境でグローバル・セキュリティーを有

効にする必要があります。また、セキュリティー監査機能の構成設定を表示および変更するには、ユー

ザーに監査員ロールが必要です。監査員ロールの詳細は、「6-8 管理ロール」を参照してください。 そして、セキュリティー監査機能の構成要素として以下のものがあります。

イベント・タイプ・フィルター

監査ログとして記録される監査可能なイベント・タイプをフィルタリングすることができます。

イベント・タイプ・フィルターを構成して、特定の監査可能イベント・タイプのサブセットだけを監査ログに

記録することができます。記録されるイベント・タイプをフィルタリングすると、ご使用の環境にとって重

要なレコードのみが確実に保存されるため、監査レコードの分析が容易になります。

監査イベント・ファクトリー

監査イベント・ファクトリーは、監査可能なセキュリティー・イベントに関連付けられたデータを収集し、

監査データ・オブジェクトを作成します。作成されたオブジェクトは、監査サービス・プロバイダーに送信

され、フォーマットされて、指定されたリポジトリーに記録されます。

監査サービス・プロバイダー

監査サービス・プロバイダーを使用して、監査イベント・ファクトリーによって送信された監査データ・

オブジェクトをフォーマットします。監査データは、フォーマットされた後、監査サービス・プロバイダー構

成で定義されているリポジトリーに記録されます。

監査サービス・プロバイダーは、デフォルトで組み込まれているバイナリ・ベース・エミッターとサード・

パーティー・エミッターのどちらかを選択することができます。

デフォルトの監査サービス・プロバイダーでフォーマットされた監査ログはテキスト形式で保管され、

監査ログ・ファイルの場所／サイズ／最大数／使用可能なフィルターを設定することができます。

また、監査リーダーを使用して HTML 形式の監査データにフォーマットすることが可能です。詳細は、

6-7-4 監査リーダーの使用を参照してください。

暗号化および署名

監査の実行においては、記録された監査データのデータ保全性を保護および保証することが重要で

す。許可されたユーザーだけが監査データへアクセスでき、改ざんを防止するために、監査データを暗

号化および署名することができます。

障害通知

通知を使用可能にして、セキュリティー監査機能に障害が発生したときにアラートを生成することがで

きます。通知は、システム・ログにアラートを記録したり、指定した受信者リストにアラートを E メールで

送信したりするように構成できます。

監査リーダー

監査リーダーは、デフォルトのバイナリー・エミッター実装によって生成されるバイナリー監査ログを

読み取るためのユーティリティーです。監査リーダーは、監査ログを解析して HTML レポートを生成し

ます。監査リーダーは、wsadmin コマンドを使用して呼び出します。尚、管理コンソールからアクセスす

ることはできません。

- 39 -

6-7-2 監査可能なイベント・タイプ WAS V7.0 の監査機能を使用して監査可能なイベント・タイプを表 6-2に示します。これらのイベント・タ

イプは、イベント・タイプ・フィルターで選択できます。

表 6-2 監査イベント・タイプ一覧

イベント名 監査取得対象 SECURITY_AUTHN 全ての認証 SECURITY_AUTHN_CREDS_MODIFY ユーザーID に対するクレデンシャルの変更 SECURITY_AUTHN_TERMINATE タイムアウト、ログアウト等による認証の終了 SECURITY_AUTHN_DELEGATION ID アサーションや RunAs などの委任情報関連 SECURITY_AUTHN_MAPPING 2 つのユーザーID が含まれるクレデンシャルマッピング情

報関連 SECURITY_AUTHZ システムのアクセス・コントロール・ポリシー実行時の認証 SECURITY_ENCRYPTION Web サービスの暗号化など暗号化情報 SECURITY_MGMT_AUDIT 監査の開始、停止などセキュリティー監査サブシステム操

作関連 SECURITY_MGMT_CONFIG WAS の管理・構成操作関連

SECURITY_MGMT_KEY 証明書の作成、更新など証明書に対する管理操作関連 SECURITY_MGMT_POLICY アクセス制御リストの作成等のセキュリティー・ポリシー関

連 SECURITY_MGMT_PROVISIONING ユーザーアカウントの作成やグループへの追加等のプロ

ビジョニング SECURITY_MGMT_REGISTRY 管理者等の適切な権限を持つユーザーによるユーザ

ー、グループの作成、変更など認証リポジトリー管理関連

SECURITY_MGMT_RESOURCE ファイル、Web ページなどのリソース属性の作成、削除等

のリソース管理 SECURITY_RESOURCE_ACCESS Web ページやデータベースなどリソースに対する全ての

アクセス SECURITY_RUNTIME 起動、停止など WAS ランタイムのイベント SECURITY_RUNTIME_KEY 有効期限切れなど証明書に対するランタイム操作関連 SECURITY_SIGNING Web サービスに対する SOAP メッセージを有効にするた

めなどの署名操作関連

- 40 -

6-7-3 設定方法 監査ログを取得するための設定方法について説明します。

1). セキュリティー監査サブシステムの使用可能化

管理コンソールより、[セキュリティー]→[セキュリティー監査]を選択し、[セキュリティー監査を使用可能

にする]のチェックボックスにチェックを入れます。セキュリティー監査を使用可能にするにはグローバル・

セキュリティーが有効になっている必要があります。変更を有効にするためには JVM を再起動する必要

があります。 2). 監査員ロールの割り当て

監査員ロールを持つユーザーは、セキュリティー監査サブシステムを使用可能にして構成する必要

があります。セキュリティー監査を最初に使用可能にしたときには、１次監査員ユーザーは 1 次管理者に

なっています。ご使用の環境で特権を分離する必要がある場合は、デフォルトのロール割り当てを変更

する必要があります。 また、セキュリティー監査を使用可能にした後に１次監査員ユーザーを１次管理者以外の監査ロール

が割り当てられたユーザーに変更することが可能です。尚、監査ロールが割り当てられたユーザーは事

前に作成しておく必要があります。 監査員ロールに関する詳細は、6-8-1-1監査員49）」を参照してください。

3). イベント・タイプ・フィルターの作成 管理コンソールより、[セキュリティー]→[セキュリティー監査]→[イベント・タイプ・フィルター]→[新規作

成]をクリックします。[名前]フィールドにこのイベント・タイプ・フィルター構成と関連付ける固有の名前を

入力します。このフィルターが適用されるときに記録するイベントとイベント結果を指定して[OK]ボタンを

クリックします。

- 41 -

また、作成後に使用可能フィールドを設定することができ、true/false の選択が可能です。 4). 監査サービス・プロバイダーの構成 管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査サービス・プロバイダー]→[新規

作成]をクリックします。作成する監査サービス・プロバイダーのタイプを選択します。今回はデフォルトの

[バイナリー・ファイル・ベース・エミッター]を選択します。

- 42 -

以下のフィールドに値を設定して、[OK]ボタンをクリックします。 名前 ：任意 監査ログファイルの場所 ：任意 監査ログ・ファイル・サイズ ：10 （デフォルト） 監査ログ・ファイルの最大数 ：100 （デフォルト） 使用可能なフィルター ：この監査サービス・プロバイダーで使用するフィルターを選択可能

なフィルターから選択。

- 43 -

5). イベント・ファクトリーの構成 管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査イベント・ファクトリー]→[新規作

成]をクリックします。 以下のフィールドに値を設定して、[OK]ボタンをクリックします。 名前 ：任意 監査サービス・プロバイダー ：構成済み監査サービス・プロバイダーを選択。 使用可能なフィルター ：この監査サービス・プロバイダーで使用するフィルターを選択可能

なフィルターから選択。 6). 監査データの暗号化（オプション） このステップはオプションとなります。

i). 監査データの暗号化に使用する鍵ストアと証明書を作成します。 管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査暗号化鍵ストアおよび証明書]を選

択して新規作成をクリックします。以下のフィールドに値を設定して[OK]をクリックします。

名前 ：任意

パス ：任意

パスワード ：任意

確認パスワード ：任意

タイプ ：PKCS12（デフォルト）

- 44 -

作成した鍵ストアを選択して、追加プロパティーの[個人証明書]を選択して[自己署名証明書の作

成．．．]をクリックします。必要なフィールドを設定して[OK]をクリックします。

別名 ：任意

鍵サイズ ：1024 ビット（デフォルト）

共通名 ：任意

有効期間 ：365 日間（デフォルト）

- 45 -

ii). 監査レコード暗号化構成を行います。

管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査レコード暗号化構成]を選択しま

す。[暗号化を使用可能にする]にチェックを入れ、[暗号化証明書が入った監査鍵ストア]に作成した鍵

ストアが選択され、[鍵ストア内の証明書]の[証明書別名]に作成した証明書が選択されている事を確認

します。[OK]をクリックして、構成を保存します。 7). 監査データの署名（オプション）

管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査レコード署名構成]を選択しま

す。[署名を使用可能にする]にチェックを入れ、[署名証明書が入った管理対象鍵ストア]で作成済みの

鍵ストアを選択します。証明書は[鍵ストア内の証明書]あるいは[選択した鍵ストア・ファイルに新規証明

書を作成する]のどちらかを選択できます。ここでは、前者を選択しています。 [OK]をクリックして構成を保存します。変更を有効にするにはサーバーの再始動が必要です。

- 46 -

6-7-4 監査リーダーの使用 監査リーダー(Audit Reader)は、デフォルトのバイナリー・エミッター実装によって生成されるバイナリ

ー監査ログを解析して HTML 形式のレポートを生成するユーティリティーで、wsadmin コマンドで実行し

ます。管理コンソールから HTML レポートを生成することはできません。 バイナリー監査ログは、以下のようなフォーマットで出力され、テキスト形式で読む事が可能になって

います。したがって、HTML 形式のレポートが要件に合わない場合は、監査リーダーを使用せずに、バ

イナリー監査ログをを自由にフォーマットしなおすことも可能です。

Seq = 0 | Event Type = SECURITY_AUTHN | Outcome = SUCCESSFUL | OutcomeReason = REDIRECT

| OutcomeReasonCode = 29 | SessionId = r4Vl6_7Oq3GWWD3yxU5tb-3 | RemoteAddr = 9.170.233.19

| RemotePort = 1990 | RemoteHost = host01.makuhari.japan.ibm.com | ProgName = / | Action

= webAuth | RegistryUserName = null | AppUserName = null | AccessDecision = authnRedirect

| ResourceName = GET | ResourceType = web | ResourceUniqueId = 0 | PermissionsChecked =

null | PermissionsGranted = null | RolesChecked = null | RolesGranted = null | EventTrailId

= null | CreationTime = Tue Dec 09 10:19:34 JST 2008 | GlobalInstanceId = 0 | FirstCaller

= null | Realm = defaultWIMFileBasedRealm | RegistryType = WIMUserRegistry | AuthnType

= challengeResponse | Provider = WebSphere | ProviderStatus = providerSuccess

Seq = 1 | Event Type = SECURITY_RESOURCE_ACCESS | Outcome = SUCCESSFUL | OutcomeReason

= SUCCESS | OutcomeReasonCode = 6 | SessionId = r4Vl6_7Oq3GWWD3yxU5tb-3 | RemoteAddr =

9.170.233.19 | RemotePort = 1990 | RemoteHost = host01.makuhari.japan.ibm.com | ProgName

= /logon.jsp | Action = resourceAccess | RegistryUserName = null | AppUserName = null |

AccessDecision = accessSuccess | ResourceName = GET | ResourceType = web | ResourceUniqueId

= 0 | PermissionsChecked = null | PermissionsGranted = null | RolesChecked = unprotected

| RolesGranted = unprotected | EventTrailId = null | CreationTime = Tue Dec 09 10:19:34

JST 2008 | GlobalInstanceId = 0 | FirstCaller = null | Realm = defaultWIMFileBasedRealm

| RegistryType = WIMUserRegistry | Url = /logon.jsp

Seq = 2 | Event Type = SECURITY_RESOURCE_ACCESS | Outcome = SUCCESSFUL | OutcomeReason

= SUCCESS | OutcomeReasonCode = 6 | SessionId = r4Vl6_7Oq3GWWD3yxU5tb-3 | RemoteAddr =

9.170.233.19 | RemotePort = 1990 | RemoteHost = host01.makuhari.japan.ibm.com | ProgName

= /css/ISCTheme/ie/ja/Styles.css | Action = resourceAccess | RegistryUserName = null |

AppUserName = null | AccessDecision = accessSuccess | ResourceName = GET | ResourceType

= web | ResourceUniqueId = 0 | PermissionsChecked = null | PermissionsGranted = null |

RolesChecked = unprotected | RolesGranted = unprotected | EventTrailId = null |

CreationTime = Tue Dec 09 10:19:35 JST 2008 | GlobalInstanceId = 0 | FirstCaller = null

| Realm = defaultWIMFileBasedRealm | RegistryType = WIMUserRegistry | Url =

/css/ISCTheme/ie/ja/Styles.css

例 6-2 バイナリー監査ログの例

監査リーダーは AdminTask オブジェクトの binaryAuditLogReader コマンドを使用します。このコマンド

を使用するには、監査員ロールが割り当てられたユーザーで wsadmin コマンドを実行する必要がありま

す。

AdminTask.binaryAuditLogReader('[-fileName

/<Profile_root>/BinaryAudit_guideCell01_host1_dmgr_08.12.02_15.52.32.log

-outputLocation /auditlog/audit.html -reportMode complete ]')

- 47 -

例 6-3 監査リーダー

-reportMode オプションで生成するレポートのタイプを指定します。有効な値には、basic、complete、また

は custom があります。 basic のレポートには、以下の構成情報が記載されます。

作成時刻 (creationTime)

アクション (action)

プログラム名 (progName)

レジストリー・タイプ (registryType)

ドメイン (domain)

レルム (realm)

リモート・アドレス (remoteAddr)

リモート・ポート (remotePort)

リモート・ホスト (remoteHost)

リソース名 (resourceName)

リソース・タイプ (resourceType)

リソース固有 ID (resourceUniqueId) その他のオプションで監査イベントタイプ（複数可）や監査イベント結果、HTML レポートの開始/終了

順序番号、タイム・スタンプ範囲を指定してフィルタリングをかけて HTML レポートを生成することができ

ます。このように監査リーダーを使用して、同じデータを複数回解析し、要件に応じて別々のレポートを

生成することができます。 例 6-2のバイナリー監査ログから監査リーダーを使用して生成した HTML 形式の監査レポートを図

6-17に示します。

図 6-17 監査リーダーで生成した HTML 形式の監査レポート

- 48 -

6-8 管理ロール この節では、管理ロールとその設定方法について説明します。

6-8-1 管理ロール 管理ロールとは、ユーザーおよびグループに対して割り当てられた役割のことで、管理セキュリティー

が有効なときに使用できます。この管理ロールは 1 ユーザーに対して複数割り当てることが可能です。 WAS V7.0の管理機能へのアクセス制御に使用される管理ロールには、既存の管理者、コンフィギュレ

ーター、オペレーター、モニター、デプロイヤー、AdminSecurityManager、iscadmins の７種類に加えて

監査員が追加され 8 種類になりました。

表 6-3 管理ロール一覧

管理ロール 内容 管理者 オペレーター、コンフィギュレーターに与えられる権限をもち、管理者ロー

ルにだけ許可されている追加権限をもっている ・サーバーID とパスワードの変更 ・管理者ロールにユーザーとグループをマップ ・認証、認可のメカニズムの構成 ・Java 2 セキュリティーを使用可能または使用不可 ・統合リポジトリー構成のユーザーを作成、更新、または削除 ・LTPA パスワードの変更や鍵生成

コンフィギュレーター モニターに与えられる権限をもち、WAS の構成を変更することができる ・リソース作成 ・アプリケーションに、ユーザーおよびグループからロールへのマッピング

の割り当て ・アプリケーション・サーバーをマップ ・アプリケーションのインストール、アンインストール ・アプリケーションのデプロイ ・アプリケーションの Java 2 セキュリティー権限をセットアップ ・CSIv2、SSL 構成をカスタマイズ

オペレーター モニターに与えられる権限をもち、ランタイム状態を変更することができる ・サーバーの起動／停止 ・管理コンソールでサーバーの状態を監視

モニター ・WAS の構成をみる ・アプリケーション・サーバーのランタイム状態をみる

デプロイヤー wsadmin からのみ使用可能（管理コンソールでの作業不可、管理コンソー

ルへのログインは可能） ・アプリケーションの構成とランタイムオペレーションが可能

AdminSecurityManager wsadmin からのみ使用可能（管理コンソールでの作業不可） ・ユーザーやグループを管理ロールにマップすることができる。 ・Fine-grained 管理セキュリティーを使用する場合、この管理ロールをもつ

ユーザーだけが許可グループを管理できる

- 49 -

iscadmins 管理コンソール・ユーザーのみ使用可能 統合リポジトリー構成のユーザーおよびグループを管理することができる ・ユーザーやグループを作成、更新、または削除することができる

監査員 モニターに与えられる権限をもち、セキュリティー監査サブシステムの構成

設定を表示および変更することができる ・セキュリティー監査サブシステムを使用可能/使用不可 ・イベント・ファクトリーのプラグイン・ポイントで使用するイベント・ファクトリー

実装を選択 ・サービス・プロバイダーのプラグイン・ポイントで使用するサービス・プロバ

イダーまたはエミッター (あるいは両方) を選択および構成 ・セキュリティー監査サブシステムにエラーが発生した場合のアプリケーシ

ョン・サーバーの動作を記述する監査ポリシーを設定 ・監査対象のセキュリティー・イベントを定義

管理者と AdminSecurityManager は区別されます。管理ロールをユーザーやグループに割り当てるに

は AdminSecurityManager の権限が必要です。具体的には、管理コンソールから[ユーザーおよびグル

ープ]→[管理ユーザー・ロール]または[管理グループ・ロール]が、AdminSecurityManager が操作できる

特定の項目になります。1 次管理ユーザーは管理者と AdminSecurityManager と監査員の 3 つのロール

をあわせもったユーザーです。

6-8-1-1 監査員 監査員のロールは、セキュリティー監査の管理を管理セキュリティーやその他のアプリケーション管理

と別個に扱います。 監査員のロールが追加されたことで、監査員の権限を管理者の権限から明確に区

別できるようになりました。監査員のロールを持つユーザーのみ、監査員ユーザー/グループのロールを

変更できます。最初にセキュリティーを有効にする場合、監査員のロールが 1 次管理者に割り当てら

れ、監査員のロールのものも含め、すべての管理ユーザー/グループのロールを管理することができま

す。 監査員のロールを管理者に許可することで、これらの権限を組み合わせることができます。使用状況

によって権限を分ける必要があれば、管理者は自身から監査員のロールを除去し、これを他のユーザ

ーに割り当てることができます。 監査員は、管理者により管理されるパネルの表示は許可されますが、変更は行えません。監査員は、

セキュリティー監査サブシステムに関連したパネルの読み取りと変更に関する全権限を持ちます。管理

者は、これらのパネルのモニター・ロールを持ちますが、これらのパネルを変更することはできません。

6-8-2 稼動ユーザー デフォルトでは、Linux、UNIX、または z/OS プラットフォーム上の WAS ノードは、それぞれ root ユー

ザーID を使用して、デプロイメント・マネージャー、ノード・エージェント、およびアプリケーション・サーバ

ーの全てのプロセスを実行します。 WAS V7.0 では、非 root ユーザーでインストール、プロファイル作成が行う事が可能です。非 rooｔユ

ーザーでプロファイルを作成した場合、そのプロセスについては、その非 root ユーザーであれば、修正

プログラムのインストールや起動停止を行う事が出来ます。以前のように Run-Aｓユーザーの設定を特に

行わなくても稼動ユーザーを非 root ユーザーに変更することができます。

- 50 -

ただし、ノード・エージェント・プロセスを root 以外のユーザーID で稼動させる場合は、同じユーザーIDで、ノード・エージェントが制御する全てのアプリケーション・サーバー・プロセスを実行しなければなりま

せん。 また、WAS の稼動ユーザーを root 以外のユーザーID に設定した場合、OS のレジストリーを操作する

権限がないためユーザー・レジストリーとしてローカル OS を選択することはできません。

6-8-3 設定方法 ここでは、WAS の管理ロールおよび稼動ユーザーをデフォルトから変更するための設定方法を紹介し

ます。管理ロールの割り当ては、ユーザーID、グループともに可能です。グループに管理ロールを割り

当てた場合は、そのグループに所属するユーザーすべてにその管理ロールが割り当てられます。運用

面では、ユーザーよりグループにマッピングする方がより効率的です。

6-8-3-1 管理ロールの設定 管理ロールをユーザーに割り当てる方法を紹介します。管理ロール（監査員ロール以外）を操作できる

のは、AdminSecurityManager・ロールの権限をもつユーザーまたは 1 次管理ユーザーです。監査員ロ

ールは、監査員ロールの権限を持つユーザーまたは 1 次管理ユーザーのみ操作できます。 管理コンソールの[ユーザーおよびグループ]→[管理ユーザー・ロール]を選択して[追加]ボタンをクリ

ックし、割り当てるロールを選択し、検索ストリングおよび検索結果の数を入力してユーザーを検索し、ユ

ーザーを[ロールにマップ済み]リストに追加して[OK]ボタンをクリックします。マスター構成へ変更を保

存します。

- 51 -

ユーザー

WAS V6.1 まではユーザーID をテキストボックスに入力していましたが、WAS V7.0 からユ

ーザーレジストリを検索して存在するユーザーを指定する実装に変わっています。

ロール

ユーザーに割り当てるロールを選択します。ロールを複数選択することも可能です。各ロ

ールに与えられる権限に関しては、前述の通りです。

管理コンソールの[ユーザーおよびグループ]→[管理ユーザー・ロール]を選択し、新規マッピング・ユ

ーザーが管理者ロールで表示されることを確認します。

グループに管理ロールをマッピングする場合は同様に、管理コンソールの[ユーザーおよびグループ]→[管理ユーザー・ロール]を選択して[追加]ボタンをクリックします。割り当てるロールを選択し、[特別な

対象からの選択]か[下記の指定どおりにグループをマップする]を選択します。[特別な対象からの選択] を選択した場合、[認証済みすべて]、[トラステッドレルム内で認証済みすべて]、[全員]の中からひとつ

選択して[OK]ボタンをクリックします。 [下記の指定どおりにグループをマップする]を選択した場合、検

索ストリングおよび検索結果の数を入力してグループを検索し、グループを[ロールにマップ済み]リスト

に追加して[OK]ボタンをクリックします。マスター構成へ変更を保存します。 特別な対象とは、特定クラスのユーザーを一般化したものです。特別な対象が [認証済みすべて]で

ある場合、管理ロールのアクセス検査によって、要求を出しているユーザーが少なくとも認証済みである

ことを意味します。特別な対象が全員(Everyone )である場合、認証されているか否かにかかわらず、セ

キュリティーが使用可能になっていない場合と同様に、すべてのユーザーがアクションを実行できること

を意味します。

- 52 -

6-8-3-2 非 root ユーザーでの稼動設定 WAS を非 root ユーザーで稼動させるための設定方法を紹介します。各プロセスを稼動させる非 rootユーザーは、事前に作成しているものとします。 非 root ユーザーで稼動させるためには、プロファイルを作成して、非 root ユーザーにオーナー・シッ

プを割り当てる必要があります。 1. プロファイルを作成します。

プロファイル作成方法については、2章インストール・プロファイル作成をご参照ください。プロファイル

を作成するユーザーは、root ユーザー/非 root ユーザーどちらでも構いません。 非 root ユーザーでプロファイルを作成した場合、プロファイル管理ツールで、固有の名前およびポー

ト値を提案するメカニズムを使用できませんので注意してください。また、オーナー・シップは、プロファイ

ルを作成した非 root ユーザー とは別の非 root ユーザーに割り当てられます。 2. プロファイル・ディレクトリーのオーナー・シップを非 root ユーザーに変更します。

chown -R <ユーザー名> <WAS_root>/profiles/<Profile_name>

3. プロファイルのログ・ディレクトリーのオーナー・シップを非 root ユーザーに変更して、ログ・メッセー

ジがコンソールに表示されないようにします。

chown -R <ユーザー名> <WAS_root>/logs/manageprofiles/<Profile_name>

6-9 Fine-grained 管理セキュリティー この節では、WAS V6.1 から新機能として実装されている Fine-grained 管理セキュリティーの機能およ

びその設定方法について説明します。

6-9-1 Fine-grained 管理セキュリティーとは WAS V6.1 より前のリリースでは、管理ロールを付与されたユーザーは、セルの下のすべてのリソー

ス・インスタンスを管理できました。WAS V7.0 では、Fine-grained 管理セキュリティーを使用することによ

って、リソース・インスタンス単位でユーザーに管理ロールを割り当てることができます。このインスタン

ス・ベースのセキュリティーを実現するには、同じ特権を必要とするリソースを、許可グループと呼ばれる

グループに入れる事が必要です。ユーザーに必要な管理ロールを割り当てることによって、許可グルー

プへのアクセス権を付与できます。リソース・インスタンス単位で管理ロールが付与されると、そのユーザ

ーは許可された範囲のリソース以外にアクセスすることができません。割り当てることが可能なリソース・

インスタンスは次の 8 つです。 セル

ノードグループ

ノード

クラスター

- 53 -

サーバー

アプリケーション

ビジネス・レベル・アプリケーション

アセット

なお、WAS V7.0 からは、Fine-grained 管理セキュリティーの設定を管理コンソールから行えるように

なりました。設定方法については後述します。

6-9-2 許可グループ 許可グループとは、同じ権限をもつリソースを１つにまとめたものをいいます。この許可グループには

特定の管理ロールをもつユーザーやリソースを追加することが可能です。従来の WAS との相互互換性

のため、セル・レベルの管理権限をもつ許可グループがデフォルトで用意されています。この許可グル

ープに割り当てられたユーザーはセル内のリソースすべてにアクセス可能です。 シングル・サーバー構成では、シングル・サーバー内の各種アプリケーションをグループ化して、さま

ざまな許可グループに入れることができます。この場合、アプリケーションによって異なる許可制約を設

ける事が可能です。ただし、許可グループに追加する事が出来るのは、アプリケーションのみです。シン

グル・サーバー環境では、サーバー自体を許可グループの一部にすることはできないので注意してくだ

さい。 図 6-18はリソース・インスタンス間の包含関係を表しています。1 つのリソース・インスタンスは、1 つの

許可グループにのみ属します。 ただし、リソース・インスタンス間には包含関係があります。 親リソース

が子リソース・インスタンスの許可グループとは異なる許可グループに属している場合、 子リソース・イン

スタンスは、暗黙的に複数の許可グループに属すことになります。 同じリソース・インスタンスを複数の

許可グループに追加することはできませんので注意して下さい。

図 6-18 リソース・インスタンスの包含関係

例えば、図 6-19のように許可グループが定義されている場合、Adminuser1 がアクセス可能なリソー

スは、node1、App-Server1-N1、application1、application2、App-Server2-N1 になります。 許可グループ 1 にはリソースである node1 が属しており、Adminuser1 がマッピングされています。よっ

て、Adminuser1 は node1 にアクセス可能です。App-Server1-N1、App-Server2-N1 は Adminuser1 が属

する許可グループ 1 配下には明確に定義されていません。しかし、ノードとサーバーの関係には包含関

セル

ノード・グループ

ノード クラスター

許可グループ

サーバー

アセット

JAVA EE アプリケーション

ビジネス・レベル・アプリケーション

構成単位

セル

ノード・グループ

ノード クラスター

許可グループ

サーバー

アセット

JAVA EE アプリケーション

ビジネス・レベル・アプリケーション

構成単位

- 54 -

係があるため、 Adminuser1 は親リソースである node1 の子リソースである App-Server1-N1 、

App-Server2-N1 にもアクセスすることが出来ることになります。

図 6-19 許可グループ

6-9-3 管理コンソールによる設定方法 Fine-grained 管理セキュリティーを設定するには、管理コンソールまたは wsadmin コマンド・ツールを

使用します。管理コンソールで設定する際には、セル･レベルで定義された「セキュリティー・マネージャ

ーの管理」権限を持つユーザーか、1 次管理ユーザーでログインする必要があります。 以下に、管理コンソールを使用して、許可グループ authGroup1 を作成してリソースを追加し、作成済

みのユーザーにそのリソースの管理ロールを割り当てる手順を記載します。

1). セル・レベルの「セキュリティー・マネージャーの管理」権限を持つユーザーか、1 次管理ユーザー

で管理コンソールにログインします。 2). [セキュリティー]より[管理許可グループ]を選択し、[新規作成]をクリックします。

- 55 -

Fine-grained 管理セキュリティーの設定(1)

3). セル内で固有の管理許可グループ名を[名前]フィールドに入力し、[リソース]セクションから、新し

い管理許可グループでアクセスを制御するリソースを選択します。

Fine-grained 管理セキュリティーの設定(2) 4). 黒いテキストで表示されるリソースは、選択できます。グレーで表示されるリソースは、既に異なる管

理許可グループのメンバーのため、新しい管理許可グループに含めることはできません。既に異な

る許可グループのメンバーであるリソースは、リソース名の横にグループの名前が表示されます。

例: server_1 (group_1)。選択が終了したら[OK]をクリックします。

5). 再び[セキュリティー]より[管理許可グループ]を選択し、作成した管理許可グループの画面を開き

ます。

[追加プロパティー]の下から、ロールを割り当てたい単位に応じて[管理グループ・ロール]か[管理

ユーザー・ロール]を選択します。この例では[管理ユーザー・ロール]を選択しています。

Fine-grained 管理セキュリティーの設定(3)

- 56 -

6). [追加．．．]をクリックします。

Fine-grained 管理セキュリティーの設定(4) 7). [ロール]フィールドから、ユーザーに対して付与したいロールを選択します。

[ストリングの検索]フィールドにテキストを入力して[検索]をクリックすると、定義済みユーザーの一覧

が表示されます。ユーザーを選択し(複数選択可能)、矢印をクリックして、[ロールにマップ済み]フィー

ルドにユーザー を追加します。[すべて選択]をクリックして、全ユーザーを選択する事も可能です。

ユーザーを追加したら[OK]をクリックします。

Fine-grained 管理セキュリティーの設定(5) 8). 構成を保存します。

上記の設定を行うと、Fine-grained 管理セキュリティーを定義されたユーザーは、wsadmin コマンド・ツー

ルを使用してロールに応じた操作を行う事が可能になります。管理コンソールから操作を行えるようにす

るには、上記の設定に加えてセル･レベルのモニター権限の付与が必要です。その場合には下記の手

順を追加で実施します。

- 57 -

9). 管理コンソールで[ユーザーおよびグループ]→ [管理ユーザー・ロール]を選択し、[追加…]をクリ

ックします。

Fine-grained 管理セキュリティーの設定(6) 10). [ロール]フィールドから、[モニター]を選択します。

[ストリングの検索]フィールドにテキストを入力して[検索]をクリックすると、定義済みユーザーの一

覧が表示されます。8)までの手順で作成したユーザーを選択し、矢印をクリックして、[ロールにマッ

プ済み]フィールドにユーザーを追加します。

ユーザーを追加したら[OK]をクリックします。

Fine-grained 管理セキュリティーの設定(７)

11). ユーザーに適切な権限が付与されているのを確認し、構成を保存します。

Fine-grained 管理セキュリティーの設定(8)

- 58 -

6-9-4 wsadmin による設定方法 wsadmin コマンド・ツールで設定する際には、セル･レベルで定義された「セキュリティー・マネージャ

ーの管理」権限を持つユーザーか、1 次管理ユーザーでコマンドを実行する必要があります。セキュリテ

ィー構成を行うコマンドは、AuthorizationGroupCommands コマンド群により提供されています。

wsadmin コマンド・ツールの基本的な使用方法については、第 2 章 1 部「システム運用」を参照して下さ

い。 また、WAS V7.0 から登場したスクリプト・ライブラリーの中には、Fine-grained 管理セキュリティーの構

成管理を行うためのスクリプトも提供されています。以下に、スクリプト・ライブラリーを使用して、許可グ

ループ authGroup1 を作成してサーバー・レベルのリソースを追加し、作成済みのユーザーにそのリソー

スの管理ロールを割り当てる例を記載します。

wsadmin>AdminAuthorizations.createAuthorizationGroup("authGroup1")

---------------------------------------------------------------

AdminAuthorizations: Create a new authorization group

Authorization Group name: authGroup1

Usage: AdminAuthorizations.createAuthorizationGroup("authGroup1")

---------------------------------------------------------------

'cells/guideCell01/authorizationgroups/authGroup1|authorizationgroup.xml#AuthorizationGroup_1228372315070'

wsadmin>AdminAuthorizations.addResourceToAuthorizationGroup("authGroup1","Node=host1Node01:Server=AMember11")

---------------------------------------------------------------

AdminAuthorizations: Add a resource to an authorization group

Authorization group name: authGroup1

Resource name (ResourceType=ResourceName):Node=host1Node01:Server=AMember11

Usage: AdminAuthorizations.addResourceToAuthorizationGroup("authGroup1", "Node=host1Node01:Server=AMember11")

----------------------------------------------------------------

OK: addResourceToAuthorizationGroup('authGroup1', 'Node=host1Node01:Server=AMember11', 'false'):

1

wsadmin>AdminAuthorizations.mapUsersToAdminRole("authGroup1", "administrator", "user01")

---------------------------------------------------------------

AdminAuthorizations: Map user ids to administrative role

Authorization group name: authGroup1

Administrative role name: administrator

User IDs: user01

Usage: AdminAuthorizations.mapUsersToAdminRole("authGroup1", "administrator", "user01")

----------------------------------------------------------------

- 59 -

'true'

wsadmin>

例 6-4 スクリプト・ライブラリーを使用した Fine-grained 管理セキュリティーの構成

6-10 JACC この節では、Ｊava Authorization Contract for Containers(以下、JACC)の機能およびその設定方法につ

いて説明します

6-10-1 JACC とは JACC は、JSR115 プロセスを通じて、J2EE1.4 で導入された J2EE コンポーネントの 1 つです。この仕様

では、J2EEコンテナーと JACCプロバイダーの間の実装方法が定義されています。この仕様に準拠する

ことにより、サード・パーティーの JACC プロバイダーを Java EE アプリケーション・サーバーにプラグイン

し、Java EE リソースがアクセスされた場合の許可決定を行うことができます。 WAS V7.0 では、JACC 仕様 1.4 が適用されています。 JACC 仕様 1.4 では、サーブレット 2.5 およ

び EJB 3 を組み込む Java EE5 をサポートするため、セキュリティー・ポリシー情報を伝搬するための

アノテーションを組み込む事が出来ます。使用できるアノテーションは、下記の Information Center を参

照してください。 WAS V7.0 Information Center「セキュリティー・アノテーション」 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/csec_annotations.html

6-10-2 JACC プロバイダー JACC では、アプリケーション・サーバーおよびプロバイダーの両方のコンテナーがいくつかの要件を

満たしている必要があります。コンテナーは、アプリケーションのデプロイ時にセキュリティー・ポリシー情

報をプロバイダーに伝搬し、全ての許可の決定に対してプロバイダーを呼び出す必要があります。ま

た、プロバイダーは、アプリケーションのデプロイ時に、ポリシー情報をリポジトリーに保管する必要があり

ます。プロバイダーは、この情報を使用してコンテナーから呼び出されたときに許可を決定します。 WAS は JACC をサポートしており、以下のような 2 つのタイプの JACC プロバイダーをサポートしてい

ます。 デフォルトの JACC プロバイダー

WAS のデフォルトの JACC プロバイダーです。Tivoli Access Manager for e-business(以

下、TAM)のクライアントおよびサーバーの両方で実装されています。TAM のクライアント部分

はWASに組み込まれており、サーバー部分はWAS NDのパッケージの一部として付属する別

のインストール可能 CD にあります。

サード・パーティーの JACC プロバイダー

サード・パーティー製の JACC プロバイダーです。WAS にプラグインするには、そのサード・パ

ーティーJACC プロバイダーが、JACC 仕様で必要なポリシー・クラス、ポリシー構成ファクトリ

- 60 -

ー・クラス、およびポリシー構成インターフェースを実装している必要があります。JACC 仕様で

は、コンテナーとプロバイダー間の許可テーブル情報の処理方法が指定されていません。そ

の情報を処理する管理機能の提供は、プロバイダーの責任です。コンテナーがバインディン

グ・ファイルの許可テーブル情報をプロバイダーに提供する必要はありません。

JACC プロバイダーとして TAM を使用することにより、さまざまなメリットを享受できます。例えば、TAM

を使用すれば、パスワードに使用する文字の種類や長さ、有効期限などといったポリシーを設定するこ

とができます。そういった設定内容の変更は WAS を再起動することなく、動的に反映することができま

す。 WAS に同梱されている TAM には、ソフトウェア製品版としての TAM のコンポーネントの一部分が含ま

れており、JACC プロバイダーとしての使用のみがサポートされています。TAM を JACC プロバイダー以

外の目的で使用する場合は、別途 TAM ソフトウェア製品版のライセンス証書を取得する必要がありま

す。

6-10-3 設定方法 ここでは、WAS で JACC プロバイダーを構成するための設定方法を紹介します。図 6-20は、JACC プ

ロバイダーを構成する手順全体の流れを表しています。 図 6-20 JACC の構成手順

ここでは、「①WAS の導入・構成」、「②TAM の導入・構成」、「③LDAP への WAS 管理ユーザーの作

成」、「④WAS のグローバル・セキュリティー設定」に関しては既に完了していることを前提とします。 WAS の管理コンソールを使用して「⑤JACC プロバイダー設定」を行う手順を紹介します。WAS で

は、TAM 用の JACC プロバイダーがデフォルトで構成されています。ここでは、TAM 用の JACC プロバ

イダーを使用可能にする設定を紹介します。

- 61 -

1). JACC プロバイダーの外部許可 管理コンソールの[セキュリティー]→[グローバル・セキュリティー]→[外部許可プロバイダー]を選択し、

ドロップダウンから[外部 JACC プロバイダー]を選択して[構成．．．]をクリックします。

組み込み許可

TAM などの外部セキュリティー・プロバイダーで JACC 仕様に基づいた J2EE アプリケー

ションの許可決定を実行する場合以外は、常にこのオプションを使用します。

外部 JACC プロバイダー

JACC 仕様を仕様する J2EE アプリケーションに対する許可決定を実行するために、TAM

など外部セキュリティー・プロバイダーを使用する場合にのみ、このオプションを使用可

能にします。

- 62 -

2). 外部 JACC プロバイダー TAM 用の JACC プロバイダー設定が表示されますので、TAM 構成を機能させるために、正しく設定さ

れていることを確認します。 各フィールドの詳細情報は下記を参照してください。 WAS V7.0 Information Center「外部の Java Authorization Contract for Containers プロバイダーの設

定」 http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.nd.doc/info/ae/ae/usec_externaljacc.html

- 63 -

3). Tivoli Access Manager プロパティー [追加プロパティー]の[Tivoli Access Manager プロパティー]を開きます。[組み込み Tivoli Access Manager を使用可能にする]にチェックを入れ、TAM と WAS の各値を正しく設定して[OK]をクリックしま

す。

組み込み Tivoli Access Manager を使用可能にする

組み込み Tivoli Access Manager 構成を使用可能または使用不可にします。

組み込み Tivoli Access Manager 使用不可時のエラーを無視

これを選択すると、組み込み Tivoli Access Manager を使用不可にしている間は、エラー

は無視されます。このオプションは、組み込み Tivoli Access Manager を再構成する場

- 64 -

合、または組み込み Tivoli Access Manager を使用不可にしている場合にのみ、適用

できます。

クライアント listen ポートの設定

Tivoli Access Manager クライアントが listen ポートとして使用するポートを入力します。

WAS は、TCP/IP ポートで、ポリシー・サーバーからの許可データベース更新を listen

する必要があります。特定のノードまたはマシン上で複数のプロセスが実行される場合

があるため、それらのプロセスで使用されるポートのリストが必要になります。ポートの

範囲を指定する場合は、下限の値と上限の値をコロンで区切ります。単一ポートとポー

ト範囲は、別々の行で指定します。

ポリシー・サーバー

Tivoli Access Manager ポリシー・サーバーの名前または完全修飾ドメイン・ネームまた

は IP アドレスと、接続ポートを入力します。policy_server:port という形式を使用しま

す。ポリシー・サーバーの通信ポートは、 TAM の構成時に設定されます。デフォルトは

7135 です。

許可サーバーと優先順位

Tivoli Access Manager 許可サーバーの名前または完全修飾ドメイン・ネームまたは IP

アドレス、接続ポート、優先順位を入力します。形式は auth_server:port:priority のよう

になります。許可サーバーの通信ポートは、TAM の構成時に設定され、デフォルトは

7136 が割り当てられます。各サーバーを別々の行に入力することで、複数の許可サー

バーを指定することができます。複数の許可サーバーを構成しておくと、フェイルオーバ

ーやパフォーマンスの点で役に立ちます。優先度の値は、許可サーバーが使用される

順序です。

管理者ユーザー名

TAM の構成時に作成した TAM 管理ユーザーID を入力します。通常は、sec_master で

す。

管理者ユーザー・パスワード

「管理者ユーザー名」で入力したユーザーID に対する、TAM 管理パスワードを入力しま

す。

ユーザー・レジストリー識別名の接尾部

TAM と WAS で共用されるユーザー・レジストリーの、識別名の接尾部を入力します。例

えば、o=ise,c=jp のように設定します。

セキュリティー・ドメイン

WAS のユーザーおよびグループを保管するのに使用される、TAM セキュリティー・ドメイ

ンの名前を入力します。TAM ドメインを指定する必要があるのは、TAM では、管理ユー

ザーごとに複数のセキュリティー・ドメインが作成できるためです。特定のドメイン内にユ

ーザー、グループ、およびその他のオブジェクトが作成され、別のドメイン内のリソース

へのアクセスは許可されません。TAM の構成時にセキュリティー・ドメインを設定してい

ない場合は、値をデフォルト値である Default のままにしておいてください。

管理者ユーザーの識別名

WAS セ キ ュ リ テ ィ ー 管 理 者 ID の 完 全 識 別 名 を 入 力 し ま す 。 例 え ば 、

cn=wasadm,o=ise,c=jp のように設定します。 ID 名は、管理コンソールの「LDAP ユーザ

ー・レジストリー」パネルにある「サーバー・ユーザー ID」と一致している必要があります

のでご注意下さい。

4). 構成の保管 最後に、構成を保管して WAS を再起動します。

- 65 -

6-10 Java 2 セキュリティー この節では、Java 2 セキュリティーについて説明します。

6-10-1 Java 2 セキュリティーとは Java 2 セキュリティーでは、ポリシー・ベースの精密なアクセス制御メカニズムが提供されます。このメ

カニズムにより、保護された特定のシステム・リソースへのアクセスには、必ずアクセス権の検査が行われ

るため、システム全体の保全性が高まります。Java 2 セキュリティーは、ファイル入出力、ソケット、およ

びプロパティーなどのシステム・リソースへのアクセスを保護します。 アプリケーションが Java 2 セキュリティーに対応していない場合、管理者は Java 2 セキュリティーを使

用することによって起こりうる問題を事前に把握しておかなければなりません。

6-10-2 Java 2 セキュリティー・ポリシー・ファイル Java プロセス用のセキュリティー・ポリシーを定義するために、IBM JDK によっていくつかの静的ポリ

シー・ファイルが提供されています。また、WAS は、エンタープライズ・アプリケーションのリソースおよび

ライブラリーに関する動的ポリシーをサポートしています。アクセスの許可は、アプリケーション実行時に

ポリシー・ファイルに基づいて判断されます。 JDK によって提供されるポリシー・ツールを使用することで、ポリシー・ファイルを編集することができま

す。セル構成の場合は、編集前にポリシー・ファイルをリポジトリーから抽出する必要があります。ポリシ

ー・ファイルの抽出後はポリシー・ツールを使用してファイルを編集し、変更したポリシー・ファイルをリポ

ジトリーに入れてから他のノードと同期させる必要があります。ポリシー・ファイルに構文エラーがあると、

エンタープライズ・アプリケーションまたはサーバー・プロセスが始動に失敗する可能性がありますので、

これらのポリシー・ファイルを編集する際は注意が必要です。

6-10-3 静的ポリシー・ファイル WAS でサポートされているポリシー・ファイルのタイプには静的ポリシー・ファイルと動的ポリシー・ファ

イルの 2 種類があります。それらのうち、静的ポリシー・ファイルは、デフォルト・アクセス権を提供します。

静的ポリシー・ファイルは、リポジトリーおよびファイル複製サービスによって管理される構成ファイルで

はありません。このファイルへの変更はローカルであり、他のマシンに複製されることはありません。

静的ポリシー・ファイルには、以下の種類のファイルがあります。

java.policy （<WAS_root>/java/jre/lib/security/java.policy）

全てのクラスに付与されるデフォルトの許可です。このファイルのポリシーは、WAS によっ

て起動される全てのプロセスに適用されます。

server.policy （<AS_Profile_root>/properties/server.policy）

製品の全てのサーバーに付与されるデフォルトの許可です。

client.policy （<AS_Profile_root>/properties/client.policy）

ノード上の全ての製品クライアント・コンテナーおよびアプレットに対するデフォルトの許可

です。

- 66 -

6-10-4 動的ポリシー・ファイル 動的ポリシー・ファイルは、アプリケーションのアクセス権を提供します。動的ポリシーは、特定のリソー

ス・タイプに対するアクセス権のテンプレートです。

動的ポリシー・ファイルには、以下の種類のファイルがあります。

spi.policy （<AS_Profile_root>/config/cells/Cell_name/nodes/Node_name/spi.policy）

このテンプレートは、サービス・プロバイダー・インターフェース（SPI）、または製品に組み

込まれているサード・パーティー製リソースのためのものです。SPI の例には、MQ Series

の Java Message Service（JMS）および JDBC ドライバーがあります。組み込みリソース

のコード・ベースは、構成（resource.xml ファイル）およびランタイム・データから動的に決

定され、spi.policy ファイルで定義されている許可は、自動的にこれらのリソースおよび

ResourceAdapter のクラスパスで指定された JAR ファイルに適用されます。spi.policy フ

ァイルのデフォルト許可は、java.security.AllPermissions です。

library.policy （<AS_Profile_root>/config/cells/Cell_name/nodes/Node_name/library.policy）

このテンプレートは、ライブラリー（Java ライブラリー・クラス）用です。共用ライブラリー

は、複数の製品アプリケーションで使用するように定義できます。library.policy のデフォ

ルトの許可は null です。

app.policy （<AS_Profile_root>/config/cells/Cell_name/nodes/Node_name/app.policy）

このファイルは、Cell_name 内の Node_name で実行される全てのエンタープライズ・アプリ

ケーションに付与されるデフォルトの許可を定義します。

was.policy

（ <WAS_root>/config/cells/Cell_name/applications/ear_file_name/deployments/application_name

/META-INF/was.policy）

このテンプレートは、アプリケーション固有の許可のためのものです。was.policy は、エン

タープライズ・アーカイブ（EAR）ファイルに組み込まれています。

was.policy.rar （rar_file_name/META-INF/was.policy.rar）

このファイルには、ra.xml ファイルで定義された許可の仕様を含めることができます。

ra.xml ファイルは、RAR ファイルに組み込まれています。

6-11 JAAS この節では、WAS が以前のバージョンより引き続きサポートしている JAAS について説明します。

6-11-1 JAAS とは JAAS は、Java 2 プラットフォームの Java 2 セキュリティー・アーキテクチャーを拡張したもので、プリ

ンシパルとユーザーによるアクセス制御の実施がサポートされます。 JAAS は、プラグ可能認証モジュ

ール (PAM) 標準フレームワークの Java バージョンを実装し、Java 2 プラットフォームのアクセス制御

アーキテクチャーを拡張します。WAS は、JAAS アーキテクチャーを完全にサポートします。JAAS は、

- 67 -

アクセス制御アーキテクチャーを拡張して、サーブレット、JSP、および EJB コンポーネントを含む J2EE リ

ソースのロール・ベースの許可をサポートします。

6-11-2 JAAS の許可 Java 2 セキュリティー・ アーキテクチャーは、コードの特性 (コードの発生元、デジタル署名がなされ

ているか、署名者は誰か、など) に基づいて許可が与えられます。JAAS では、ユーザーを中心とする

新規アクセス制御により、コード中心の既存のアクセス制御が強化されます。許可は、実行されているコ

ードとそのコードの実行者に基づいて与えられます。 JAAS 認証によりユーザー認証を行う場合、認証済みユーザーを表す Subject が作成されます。

Subject は、Principal のセットから構成され、各 Principal はそのユーザーの ID を表します。許可は、ポリ

シーで特定の Principal に与えることができます。ユーザーが認証されると、アプリケーションは、Subjectを現行のアクセス制御コンテキストに関連付けることができます。セキュリティーが検査された後続の各

オペレーション毎に、Java ランタイムは、ポリシーが要求された許可を特定の Principal にのみ与えるかど

うかを自動的に判断します。与える場合は、アクセス制御コンテキストに関連した Subject に指定された

プリンシパルのみが含まれる場合に、その操作を行うことができます。 Subject を現行のアクセス制御コンテキストに関連付けるには、その Subject のクラスから静的 doAs メソ

ッ ド を 呼 び 出 し て 、 認 証 済 み の Subject と java.security.PrivilegedAction ま た は java.security.PrivilegedExceptionAction インターフェース実装クラスのインスタンスを渡します。doAs メソ

ッドは、指定された Subject を現行のアクセス制御コンテキストに関連付け、アクションから実行メソッド

を呼び出します。実行メソッドのインプリメンテーションには、指定した Subject として実行されたコードが

すべて含まれています。これにより、アクションは、指定した Subject として実行されます。 J2EE プログラミング・モデルでは、EJB またはサーブレットから EJB メソッドを呼び出す場合、そのメソ

ッドは Run-As 設定により決められるユーザーID を使用して実行されます。J2EE 1.4 では、EJB コード

またはサーブレット・コード内の Subject.doAs アクション・ブロックから EJB を呼び出す場合に使用す

るユーザー ID は示されません。論理拡張機能では、Subject.doAs アクション・ブロック内で EJB メソ

ッドを呼び出す場合に、Subject 内に指定された適切な ID を使用することになっています。 Subject.doAs アクションに Run-As ID 設定を上書きさせるのは、 JAAS プログラミング・モデルを J2EE ランタイム環境に統合する上で理想的な方法です。ただし、JAAS では、JDK V1.3 以降で、 JAAS V1.0 以降のインプリメンテーションと Java 2 セキュリティー・アーキテクチャーを統合する際に、

問 題 が 発 生 し ま し た 。 ア ク セ ス 制 御 コ ン テ キ ス ト に 関 連 付 け ら れ た Subject は 、 AccessController.doPrivileged()呼び出しが Subject.doAs アクション・ブロック内で発生した場合、その AccessController.doPrivileged()呼び出しによりカットオフされます。この問題が解決されるまでは、 J2EE ランタイム環境での Subject.doAs アクションの正しい振る舞いを保証できる、信頼性が高くてランタイム

効率のよい方法はありません。