Comments
Description
Transcript
Document 1026252
9. セキュリティー構成 ................................................................................................................ 3
9-1 セキュリティー・アーキテクチャー ......................................................................................... 3
9-1-1 セキュリティー機能を支える技術 ...................................................................................... 3
9-1-2 セキュリティー概観 ............................................................................................................ 4
9-1-3 グローバル・セキュリティー ............................................................................................... 6
9-1-4 グローバル・セキュリティー設定方法 ............................................................................... 7
9-1-4-1 セキュリティー構成ウィザード ....................................................................................... 7
9-1-4-2 セキュリティー構成報告書 .......................................................................................... 10
9-2 複数セキュリティー・ドメイン ............................................................................................... 11
9-2-1 複数セキュリティー・ドメインの概要 ................................................................................ 11
9-2-2 セキュリティー・ドメインの内容 ........................................................................................ 11
9-2-2-1 セキュリティー・ドメイン構成ファイル .......................................................................... 11
9-2-2-2 セキュリティー・ドメインで設定できるセキュリティー属性 .......................................... 11
9-2-2-3 セキュリティー・ドメインへの有効範囲の関連付け .................................................... 12
9-2-3 設定方法 .......................................................................................................................... 13
9-2-4 考慮点 .............................................................................................................................. 15
9-2-4-1 古いサーバー・レベルのセキュリティーと新しいセキュリティー・ドメインの関係 ...... 15
9-2-4-2 セキュリティー・ドメインの使用時のクライアントおよびアプリケーション・セキュリティ
ー・プログラミング・モデル .......................................................................................................... 16
9-2-4-3 複数ドメイン構成におけるアプリケーション・デプロイメント ....................................... 16
9-2-4-4 相互レルム通信........................................................................................................... 16
9-2-4-5 ノードとセキュリティー・ドメインの統合 ....................................................................... 16
9-3 認証 ..................................................................................................................................... 17
9-3-1 認証とは ........................................................................................................................... 17
9-3-2 認証モデル ...................................................................................................................... 17
9-3-3 ユーザー・レジストリー .................................................................................................... 17
9-3-4 認証メカニズム ................................................................................................................ 18
9-3-5 仮想メンバー・マネージャー（VMM:VIRTUAL MEMBER MANAGER） ............................... 19
9-3-6 認証プロセス.................................................................................................................... 19
9-3-7 設定方法 .......................................................................................................................... 20
9-3-7-1 統合リポジトリー .......................................................................................................... 20
9-3-7-2 シングル・サインオン（SSO） ....................................................................................... 23
9-3-7-3 トラスト・アソシエーション............................................................................................. 25
9-4 認可 ..................................................................................................................................... 25
9-4-1 認可とは ........................................................................................................................... 26
9-4-2 認可モデル ...................................................................................................................... 26
9-4-3 宣言セキュリティー .......................................................................................................... 27
9-4-4 プログラマティック・セキュリティー .................................................................................. 27
9-4-5 代行モデル ...................................................................................................................... 28
9-4-6 認可プロセス.................................................................................................................... 29
9-5 SSL ...................................................................................................................................... 30
9-5-1 SSL とは ........................................................................................................................... 30
9-5-2 SSL 構成 .......................................................................................................................... 31
9-5-3 SSL 証明書 ...................................................................................................................... 31
9-5-4 設定方法 .......................................................................................................................... 32
-1-
9-5-4-1 Web ブラウザーと Web サーバー間の SSL 構成 ..................................................... 32
9-5-4-2 Web サーバーと WAS 間の SSL 構成....................................................................... 33
9-6 鍵と証明書 .......................................................................................................................... 35
9-6-1 IKEYMAN と同等の機能を管理コンソールから使用........................................................ 35
9-6-2 証明書の有効期限 .......................................................................................................... 36
9-7 監査 ..................................................................................................................................... 37
9-7-1 監査とは ........................................................................................................................... 37
9-7-2 監査可能なイベント・タイプ ............................................................................................. 39
9-7-3 設定方法 .......................................................................................................................... 39
9-7-4 監査リーダーの使用........................................................................................................ 47
9-8 管理ロール .......................................................................................................................... 49
9-8-1 管理ロール....................................................................................................................... 49
9-8-1-1 監査員 .......................................................................................................................... 50
9-8-2 稼動ユーザー .................................................................................................................. 50
9-8-3 設定方法 .......................................................................................................................... 51
9-8-3-1 管理ロールの設定 ....................................................................................................... 51
9-8-3-2 非 root ユーザーでの稼動設定 .................................................................................. 53
9-9 FINE-GRAINED 管理セキュリティー .................................................................................... 53
9-9-1 FINE-GRAINED 管理セキュリティーとは .......................................................................... 53
9-9-2 許可グループ................................................................................................................... 54
9-9-3 管理コンソールによる設定方法...................................................................................... 55
9-9-4 WSADMIN による設定方法 ............................................................................................... 59
9-10 JACC ................................................................................................................................. 60
9-10-1 JACC とは ...................................................................................................................... 60
9-10-2 JACC プロバイダー ....................................................................................................... 60
9-10-3 設定方法........................................................................................................................ 61
9-10 JAVA 2 セキュリティー ....................................................................................................... 66
9-10-1 JAVA 2 セキュリティーとは ............................................................................................. 66
9-10-2 JAVA 2 セキュリティー・ポリシー・ファイル .................................................................... 66
9-10-3 静的ポリシー・ファイル .................................................................................................. 66
9-10-4 動的ポリシー・ファイル .................................................................................................. 67
9-11 JAAS ................................................................................................................................. 67
9-11-1 JAAS とは....................................................................................................................... 67
9-11-2 JAAS の許可.................................................................................................................. 68
9-12 JASPI ................................................................................................................................ 69
9-12-1 JASPI プロバイダーによる認証 .................................................................................... 69
-2-
9. セキュリティー構成
この章では、WebSphere Application Server(以下、WAS) V8.5 におけるセキュリティーの概念や仕組
み、構成について説明します。また、各項目について、管理コンソールを使用した設定方法についても
紹介します。
9-1 セキュリティー・アーキテクチャー
この節では、WebSphere セキュリティー全体像を理解するために、基盤となっている技術やアーキテ
クチャーについて説明します。
9-1-1 セキュリティー機能を支える技術
WebSphere セキュリティーは、
図 9-1に示すような階層化セキュリティー・アーキテクチャー上に構築されます。
図 9-1 階層化セキュリティー・アーキテクチャー
-3-
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 層に渡されます。
CORBA セキュリティーの下の層が Java 2 セキュリティーです。Java 2 セキュリティー・モデルは、ファ
イル・システム、システム・プロパティー、ソケット接続、スレッド化、クラス・ロードなどのシステム・リソース
に対して、きめの細かいアクセス制御を提供します。アプリケーション・コードで保護されたリソースにアク
セスするためには、必要な許可を明示的に与えなければなりません。
Java 2 セキュリティーの下の層が Java Virtual Machine(以下、JVM)セキュリティーです。JVM セキュリ
ティー・モデルは、オペレーティング・システム層の上にセキュリティーの層を提供します。例えば、JVM
セキュリティーは、無制限のアクセスからメモリーを保護し、スレッド内でエラーが起こった場合には例外
をスローし、そして配列型を定義します。
更にこれらの下の層がオペレーティング・システム・セキュリティーです。基礎となるオペレーティング・
システムのセキュリティー基盤は、特定のセキュリティー・サービスを WAS に提供します。このセキュリテ
ィー・サービスには、WAS の製品インストールにおいて機密ファイルを保護するファイル・システム・セキ
ュリティーのサポートが含まれます。システム管理者は、製品を構成したら、オペレーティング・システム
のユーザー・レジストリーから認証情報を直接取得することができます。
オペレーティング・システム・セキュリティーの下の層がネットワーク・セキュリティーです。ネットワーク・
セキュリティー層は、トランスポート・レベルの認証およびメッセージの保全性と機密性を提供します。別
個のアプリケーション・サーバー間の通信は、Secure Sockets Layer(以下、SSL)を使用するように構成す
ることができます。また、更にメッセージ保護を強化するためには、IP セキュリティーや Virtual Private
Network(以下、VPN)を使用することもできます。
9-1-2 セキュリティー概観
アプリケーション・サーバーは、複数層のエンタープライズ・コンピューティング・フレームワークの中
核をなすコンポーネントです。WAS は、図 9-2に示すようにオープン・アーキテクチャーを採用し、エン
タープライズ・ソフトウェア・コンポーネントと統合するために多数のプラグイン・ポイントを提供します。プ
ラグイン・ポイントは、Java EE の標準仕様が適用できるところでは必ずこの仕様を基にしています。
-4-
図 9-2で影が付いた部分は、WAS と他のエンタープライズ・ソフトウェア・コンポーネントとの境界を示
します。
図 9-2 WebSphere セキュリティー概観
トラスト・アソシエーションにより、WAS セキュリティーとサード・パーティー製セキュリティー・サーバーと
を統合することができます。具体的には、リバース・プロキシー・サーバーがフロントエンド認証サーバー
として機能させることができる一方で、プロキシー・サーバーから渡された認証情報を WAS 製品自体の
認証ポリシーに適用することができます。トラスト・アソシエーション・インターセプターを実装する製品に
は、IBM Tivoli Access Manager for e-business(以下、TAM)、WebSEAL、Caching Proxy などがありま
す。
WAS は、ユーザーの認証情報やドメインなどの情報が含まれたセキュリティー属性を、構成内のサー
バー間で受け渡しすることができます。セキュリティー属性は、ユーザーのアカウント情報が格納された
ユーザー・レジストリーあるいは Java Authentication and Authorization Service(以下、JAAS)ログイン・モ
ジュールから取得することができます。
また、WAS では、Web サービス・セキュリティー仕様に基づいて Web サービスを保護することができま
す。この仕様は、Web サービス環境で交換されるメッセージの保護方法を規定しており、メッセージの保
全性と機密性を保護するための中核機構を定義し、セキュリティー関連の要求とメッセージを関連付け
るためのメカニズムを提供します。
そ の他にも 、J2EE コネ クタ ー・ アーキ テク チ ャー によ るコン テナ ー管 理認 証の サポ ー ト、Java
Authorization Contract for Containers(以下、JACC)インターフェースによる外部 JACC プロバイダーのサ
ポート、CSIv2 セキュリティー・プロトコルのサポートなど、WAS はさまざまなプラグイン・ポイントを提供し
ています。
-5-
9-1-3 グローバル・セキュリティー
グローバル・セキュリティーとは、WAS 自体や連携する他のコンポーネントも含んだシステムの一部を
保護された状態にする機能です。そして、グローバル・セキュリティーはユーザー・レジストリーや認証メ
カニズム、セキュリティー・ドメインの振る舞いを定義するその他のセキュリティー情報から構成されます。
具体的には、Java 2 セキュリティー・マネージャー、JAAS、Java 2 コネクター認証データ・エントリー、
CSIv2 認証プロトコルなどの各種属性があります。
WAS V8.5 におけるグローバル・セキュリティーは、WAS V7.0 と同様に管理セキュリティーとアプリケ
ーション・セキュリティーに分離された形で構成されています。管理セキュリティーとは、WAS の管理をセ
キュアにするための機能で、常時使用を推奨しています。管理セキュリティーを有効にすると管理コンソ
ールや wsadmin といった管理ツールを使用するユーザーに認証やアクセス制御の設定を行う事ができ
ます。尚、管理セキュリティーのデフォルトの認証メカニズムは LTPA となります。アプリケーション・セキュ
リティーとは、WAS 上で稼動するアプリケーションをセキュアにするための機能です。アプリケーション・
セキュリティーを有効にすると、WAS 上で稼動するアプリケーションに対して認証認可などのセキュリテ
ィー設定を行う事ができます。Web リソースの場合、web.xml 内のリソースに対するセキュリティー制約
が実行されます。保護リソースにアクセスすると、Web クライアントに対して、認証を求めるプロンプトが
出されます。
注意点としては、管理セキュリティーは単独で有効にすることが可能ですが、アプリケーション・セキュ
リティーは独立して有効にすることはできません。アプリケーション・セキュリティーを有効にする場合は
必ず管理セキュリティーを有効にする必要があります。
WAS V7.0 で追加された新機能により、セル内にセキュリティー・ドメインを複数定義し、グローバル・
セキュリティー構成を上書きすることが可能になりました。複数セキュリティー・ドメインの詳細については
次の節で解説します。
WAS V7.0 から追加されたジョブ・マネージャーおよび管理エージェントに対してもグローバル・セキュ
リティーを設定することが可能です。ジョブ・マネージャー、管理エージェント上でアプリケーションは稼
働しないため、正確にはこれらに対し管理セキュリティーを設定することが可能です。
認証リポジトリーも、統合リポジトリー、スタンドアロン LDAP レジストリー、ローカル・オペレーティング・
システム・レジストリー、スタンドアロン・カスタム・レジストリーの 4 種類をサポートしています。考慮点とし
て、ジョブ・マネージャーと登録する ND 環境、シングル・サーバー(管理エージェント含む)のグローバ
ル・セキュリティーの設定を同じにしておく必要があります。また、管理エージェントについても登録する
シングル・サーバーのそれを同じ設定にしておく必要があります。
また、WASV8.0 からは、新しいセキュリティー強化機能の一環として、以下のデフォルト設定が変更さ
れています。
CSIv2 トランスポートに対し、「SSL 必須」をデフォルトに変更
LTPA Cookie での HttpOnly 属性をデフォルトで有効化
セッション Cookie の HttpOnly 属性をデフォルトで有効化
セッション・セキュリティー統合がデフォルトで有効化
詳細は以下 URL を参照してください。
WAS V8.0 Information Center「セキュリティー専門家用の新機能」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.mult
iplatform.doc%2Finfo%2Fae%2Fae%2Fwelc_newsecurity.html
-6-
9-1-4 グローバル・セキュリティー設定方法
グローバル・セキュリティーは WAS 導入中、プロファイル作成中、または WAS 導入後に設定すること
が可能です。
まず初めに、WAS 導入中、プロファイル作成中の設定方法を紹介します。WAS 導入ウィザードまたは
プロファイル管理ツールには、管理セキュリティー・パネルが追加されています。WAS 導入ウィザード、
プロファイル作成ウィザードともに同様のパネルが表示されます。
図 9-3 プロファイル管理ツールの管理セキュリティー設定画面
管理セキュリティーを設定する場合は、このパネルの[管理セキュリティーを有効にする]のチェックボッ
クスを ON にします。続いて、任意のユーザー名とパスワードを入力します。このユーザー名はのちに１
次管理ユーザーとなり管理セキュリティーが有効となった管理ツールからログインする際に入力するユ
ーザー名とパスワードになります。このユーザーはファイル・ベースのリポジトリーに格納されます。ここで
設定したユーザー情報は<Profile_Root>/config/cells/<Cell_name> パスに保管されているファイル・レ
ジストリー（fileRegistry.xml）に保管されます。管理セキュリティーは WAS 導入後、またはプロファイル作
成後に有効となります。ただし、有効であるのは管理セキュリティーだけで、このときアプリケーション・セ
キュリティーはデフォルトで使用不可となっています。アプリケーション・セキュリティーを使用可能にする
場合は、あらためて設定する必要があります。
9-1-4-1 セキュリティー構成ウィザード
次に、プロファイル作成後にグローバル・セキュリティーを有効にする方法を説明します。
-7-
グローバル・セキュリティーを WAS 導入後またはプロファイル作成後に設定するには、セキュリティー
構成ウィザードを使用します。セキュリティー構成ウィザードは、基本的な管理とアプリケーションのセキ
ュリティーを構成するために必要なステップを提供しています。具体的には 1 次管理ユーザーの作成
や、使用するユーザー・レジストリーの選択、管理セキュリティーの有効化などになります。管理コンソー
ルから、[セキュリティー]→[グローバル・セキュリティー]を開きます。[セキュリティー構成ウィザード]ボタ
ンをクリックします。
【Step1】保護の範囲の指定
アプリケーション・セキュリティーと Java 2 セキュリティーの選択ができますが、これらの選択について
は任意です。必要があれば選択し、[次へ]をクリックします。管理セキュリティーはこのウィザードを使用
して変更した場合、デフォルトで有効になりますので選択するチェックボックスはありませんのでご注意く
ださい。
-8-
【Step2】ユーザー・リポジトリー
ユーザー・リポジトリーの選択を行います。ユーザー・リポジトリーは、認証やアクセス制御のために使
用するユーザーとグループの情報を持ちます。いずれか１つだけ選択し、[次へ]をクリックします。
【Step3】ユーザー・リポジトリーの構成
管理セキュリティーが有効になった管理コンソールにログインする際に必要なユーザー名とパスワー
ドを設定します。このユーザーはファイル・ベースのリポジトリーに保管されます。ファイル・ベースのリポ
-9-
ジトリーに保管されたユーザーは、管理コンソールから、[ユーザーおよびグループ]→[ユーザーの管
理]または[グループの管理]を開くとその管理画面を確認することができます。
【Step4】要約
このページでは設定した内容の確認ができます。
[管理セキュリティーを使用可能にする]が true になっていることを確認します。設定に間違いがなければ
[OK]ボタンをクリックし、保管します。
管理コンソールからログアウトし、変更を有効にするためにサーバーを再起動します。サーバーの再
起動が完了したら、管理セキュリティーが有効になった管理コンソールを立ち上げます。ログイン・ユー
ザーを要求されますので、セキュリティー構成ウィザードの Step3 で設定した 1 次管理ユーザーを入力し
ます。無事、ログインができたら、[セキュリティー]→[グローバル・セキュリティー]画面を開き、[管理セキ
ュリティーを使用可能にする]のチェックボックスが ON になっていることを確認します。
9-1-4-2 セキュリティー構成報告書
導入またはプロファイル作成後に、管理セキュリティーの設定を管理コンソールから確認することがで
きます。
管理コンソールから、[セキュリティー]→[グローバル・セキュリティー]を開き、[セキュリティー構成報告
書]を開きます。
[セキュリティー構成報告書]は、現在のセキュリティーに関する設定の全てを見ることができます。た
だし、機能上の制限により、アプリケーション・レベルのセキュリティー情報は表示されません。また、Java
Message Service (JMS) セキュリティー、バス・セキュリティー、 Web Services セキュリティーに関する情
報も同じく表示されません。
なお、WAS V8.0 からは、セッション・セキュリティー、Web 属性、および HttpOnly 設定に関する情
報が組み込まれました。
- 10 -
9-2 複数セキュリティー・ドメイン
この節では、WAS V8.5 における複数セキュリティー・ドメインについて説明します。
9-2-1 複数セキュリティー・ドメインの概要
WAS V7.0 のセキュリティー新機能として追加された複数セキュリティー・ドメインは、セキュリティー・ド
メイン毎に異なるセキュリティー設定を柔軟に構成することができます。尚、複数セキュリティー・ドメイン
は、単にセキュリティー・ドメインとも呼ばれます。
グローバル・セキュリティーは、すべての管理機能と、ユーザー・アプリケーションのデフォルトのセキ
ュリティー構成に適用されます。セキュリティー・ドメインは、ユーザー・アプリケーション用にカスタマイズ
された構成を定義する場合に使用できます。
セキュリティー・ドメインを作成するには、その前にグローバル・セキュリティー構成を定義しておく必要
があります。例えば管理コンソール、ネーミング・リソース、MBean などの管理アプリケーションには、グ
ローバル・セキュリティー属性が必要です。そして、セル内に複数セキュリティー・ドメインが定義される
と、このグローバル・セキュリティー構成はセキュリティー・ドメインの構成に上書きされます。
これによって異なるアプリケーションに対して異なるセキュリティー属性 (例：認証リポジトリー) を構成
できます。例えば、セル環境内の管理セキュリティーでは統合リポジトリーを使用し、アプリケーション・セ
キュリティーでは LDAP レジストリーを使用する構成や、アプリケーションが使用する認証リポジトリーはク
ラスター毎に別レジストリーにする構成などを組む事ができます。
アプリケーション毎に変える必要のあるセキュリティー属性に対しては、セキュリティー・ドメインを作成
して、それらのユーザー・アプリケーションが実行されるサーバーあるいはクラスターを有効範囲として関
連付けます。また、セキュリティー・ドメインをセルに関連付けることもできます。
また、WAS V6.1 までのサーバー・レベルのセキュリティーを使用していた場合は、複数セキュリティ
ー・ドメインを使用する必要があります。サーバー・レベルのセキュリティーは、WAS V7.0 では非推奨に
なっており、複数セキュリティー・ドメインを使用した方が構成をより柔軟に簡単に行うことができるためで
す。
9-2-2 セキュリティー・ドメインの内容
9-2-2-1 セキュリティー・ドメイン構成ファイル
グローバル・セキュリティー構成データは security.xml ファイルに保管されます。
このファイルは <Profile_root>/config/cells/<Cell_name> ディレクトリーにあります。
セキュリティー・ドメインは、2 つの構成ファイルによって表されます。セキュリティー・ドメイン情報は、
<Profile_root>/config/waspolicies/default/securitydomains/<SecurityDomain_name> デ ィ レ ク ト リ ー に
security-domain.xml ファイルと security-domain-map.xml ファイルが保管されます。security-domain.xml
ファイルには、セキュリティー・ドメイン用に構成されたセキュリティー属性のリストが含まれ、もう 1 つの
security-domain-map.xml ファイルには、セキュリティー・ドメインを使用する有効範囲が含まれます。
9-2-2-2 セキュリティー・ドメインで設定できるセキュリティー属性
表 6-1 にグローバル・セキュリティー構成とセキュリティー・ドメイン構成で設定できるセキュリティー属
性の一覧を示します。下記表より、すべてのセキュリティー属性を上書きできるわけではないことがわか
ります。
- 11 -
WAS V7.0 では、統合リポジトリー・ユーザー・レジストリーは、グローバル・レベルでしか構成できず、
セルあたり 1 インスタンスしか持つことができませんが、WAS V8.0 以降では、複数のセキュリティー・ド
メイン環境のドメイン・レベルで統合リポジトリーの固有インスタンスを構成できます。
表 9-1 セキュリティー・ドメインで構成できるセキュリティー属性
グローバル・セキュリティー構成
(security.xml)
アプリケーション・セキュリティーの使用可能化
Java 2 セキュリティー
ユーザー・レルム（レジストリー）
トラスト・アソシエーション・インターセプター(TAI)
SPNEGO Web 認証
RMI/IIOP セキュリティー(CSIv2 プロトコル)
JAAS
認証メカニズム属性
許可プロバイダー
カスタム・プロパティー
Web 属性(SSO)
SSL
監査
LTPA 認証メカニズム
Kerberos 認証メカニズム
セキュリティー・ドメイン構成
(security-domain.xml)
アプリケーション・セキュリティーの使用可能化
Java 2 セキュリティー
ユーザー・レルム（レジストリー）
トラスト・アソシエーション・インターセプター(TAI)
SPNEGO Web 認証
RMI/IIOP セキュリティー(CSIv2 プロトコル)
JAAS
認証メカニズム属性
許可プロバイダー
カスタム・プロパティー
-
9-2-2-3 セキュリティー・ドメインへの有効範囲の関連付け
WAS V8.5 では、セキュリティー・ドメインに以下の有効範囲を関連付けることができます。
セル
サーバー
クラスター
SIBus
セキュリティー・ドメインを作成して、ある有効範囲に関連付けると、その有効範囲内のユーザー・アプ
リケーションだけが、そのセキュリティー・ドメインで定義されているセキュリティー属性を使用します。た
だし、その有効範囲内でのネーミング操作、管理アプリケーションにおいては、グローバル・セキュリティ
ー構成が使用されます。グローバル・レベルにあるセキュリティー属性で、変更する必要のあるセキュリ
ティー属性は、ドメイン・レベルで定義します。情報が共通の場合は、セキュリティー・ドメインにその情報
を重複して持たせる必要はありません。ドメインに欠落している属性は、グローバル構成から取得されま
す。
サーバーがクラスターの一部である場合は、セキュリティー・ドメインをそのクラスターに関連付けること
はできますが、そのクラスター内の個々のメンバーに関連付けることはできません。したがって、セキュリ
ティーの動作は、すべてのクラスター・メンバーに渡って一貫性のあるものになります。
セキュリティー・ドメインをセルに関連付ける場合は、通常、WAS 内のすべてのユーザー・アプリケー
ションをセキュリティー・ドメインに関連付けたい場合です。この場合、すべての管理アプリケーションとネ
ーミング操作は、グローバル・セキュリティー構成を使用するのに対し、すべてのユーザー・アプリケーシ
ョンは、ドメイン・レベルの構成を使用します。管理アプリケーションおよびユーザー・アプリケーションの
セキュリティー構成情報を分割するのであれば、有効範囲をセル・レベルにしてください。
- 12 -
9-2-3 設定方法
1).
2).
［セキュリティー］→［セキュリティー・ドメイン］を選択します。セキュリティー・ドメインを作成する方法
として、新規作成、既存セキュリティー・ドメインをコピー、グローバル・セキュリティーをコピー、の 3
つの方法があります。ここでは新規作成します。
[新規作成]ボタンをクリックします。
3).
[名前]欄にセキュリティー・ドメインの名前を入力します。[説明]欄への入力は任意です。そして[適
用]ボタンをクリックして、セキュリティー・ドメインの詳細ページに進みます。
4).
セキュリティー・ドメインに割り当てる有効範囲を指定します。割り当てたい有効範囲のチェックボッ
クスにチェックを入れます。
- 13 -
5).
新規ドメインにセキュリティー属性を指定して、そのドメイン内のセキュリティー構成をカスタマイズし
ます。ここでは、ユーザー・レルムをスタンドアロン LDAP レジストリーにカスタマイズします。レルム・
タイプから[スタンドアロン LDAP レジストリー] を選択して、[構成]ボタンをクリックします。
- 14 -
6).
既存のレルムを指定する場合は、[レルム名の入力]をクリックしてレルム名の入力を行います。新
規にレルムを作成する場合は、[システムによるレルム名の作成を許可する]をクリックして、適宜必
要な設定を行って[OK]ボタンをクリックします。
7).
8).
[セキュリティー・ドメイン]→[セキュリティー・ドメイン名]にて[適用]ボタンをクリックします。
構成変更を保管したら、サーバーを再始動して変更内容を有効にします。
9-2-4 考慮点
複数セキュリティー・ドメインを構成するにあたっての考慮点を以下に説明します。
9-2-4-1 古いサーバー・レベルのセキュリティーと新しいセキュリティ
ー・ドメインの関係
WAS V6.1 までは、サーバー・レベルのセキュリティー属性セットを関連付けることができました。これら
の属性は、サーバー・レベルのすべてのアプリケーションで使用されていました。セキュリティー属性の
以前の構成方法は、WAS V7.0 からは非推奨になっており、将来のリリースでは削除されます。
スクリプトの互換モードが false になっている場合 (-scriptCompatibility="false")、マイグレーション・
ツールを使用すると、既存のサーバー・レベルのセキュリティー構成情報が、新しいセキュリティー・ドメ
- 15 -
イン構成にマイグレーションされます。スクリプトの互換モードが true に設定されている場合、サーバ
ー・レベルのセキュリティー構成は、新規のセキュリティー・ドメイン構成にマイグレーションされません。
9-2-4-2 セキュリティー・ドメインの使用時のクライアントおよびアプリ
ケーション・セキュリティー・プログラミング・モデル
EJB にアクセスするクライアントとして動作する Java クライアントまたはアプリケーションは、一般に最
初にネーミング検索を実行します。ネーミング・リソースは、管理アプリケーションおよびユーザー・アプリ
ケーションの両方によって使用され、管理リソースとみなされます。ネーミング・リソースは、グローバル・
セキュリティー構成情報によって保護されます。グローバル・セキュリティーがあるレルム (ユーザー・レ
ジストリー) を使用し、ドメインがそれとは異なるレルムを使用している複数ドメイン・セットアップでは、
Java クライアントは 2 つの異なるレルムにより認証を受ける必要があります。最初の認証は、ネーミング
操作を正常に行うために、グローバル・セキュリティー構成内のレルムに対して必要で、2 つ目の認証
は、異なるレルムを使用している EJB にアクセスするために必要です。
すべてのネーミング読み取り操作は、CosNamingRead ロールによって保護されます。このロールに
は、通常 Everyone が割り当てられます。これは、すべてのユーザーが有効であるか否かには関係なく
名前空間を検索できる、ということを意味しています。複数セキュリティー・ドメインが定義されている場
合、CosNamingRead ロールが Everyone を持っていると、クライアント側のセキュリティー・ランタイム・コ
ードは、ログインを促すプロンプトを表示しません。その代わりにこのセキュリティー・ランタイム・コード
は、非認証サブジェクトを使用してネーミング操作にアクセスします。ネーミング検索操作が完了して、ク
ライアントが EJB にアクセスしようとすると、現在 EJB アプリケーションが使用しているレルム (すなわ
ち、ドメインで使用されているレルム) を示すログイン・パネルがプロンプトとしてクライアントに表示され
ます。クライアントはそのレルムに対応する適切なユーザー・クレデンシャルを提供することにより、EJB
にアクセスできます。
9-2-4-3 複数ドメイン構成におけるアプリケーション・デプロイメント
複数ドメイン構成でアプリケーションをデプロイする場合は、同じセキュリティー・ドメインに属するサー
バーまたはクラスターに、アプリケーション内のすべてのモジュールをインストールする必要があります。
もしそうしなかった場合、これらのセキュリティー・ドメインに構成されているセキュリティー属性によって
は、動作の一貫性が失われる可能性があります。異なるドメインに渡ってアプリケーションがデプロイさ
れると、アプリケーションのデプロイメントはほとんどの場合で失敗します。
9-2-4-4 相互レルム通信
アプリケーションが異なるレルムを使用している他のアプリケーションと通信する必要がある場合は、
RMI/IIOP および LTPA トークン使用時に、インバウンド通信とアウトバウンド通信の両方に対して信頼関
係を確立する必要があります。
9-2-4-5 ノードとセキュリティー・ドメインの統合
Base サーバーをセルに統合する場合は、セキュリティー・ドメインに割り当てられたリソースを、セル有
効範囲ではなく、サーバー有効範囲にする必要があります。統合中に Base のセキュリティー・ドメインが
セル・レベルになっている場合、addNode コマンドは失敗します。統合中にセキュリティー・ドメインを組
み込まないようにするためには、-excludesecuritydomains オプションを使用できます。
- 16 -
9-3 認証
この節では、WAS V8.5 における基本的なセキュリティー技術の一つである認証について説明しま
す。
9-3-1 認証とは
認証とは、リソースを要求するユーザーが「誰であるか」、そして「本人であるか」を証明するプロセスで
す。最も一般的に使われる認証手法は、ユーザーID とパスワードの照合による審査です。
9-3-2 認証モデル
WAS セキュリティーにおける認証は、Java EE のセキュリティー・モデルに基づいて行われます。Java
EE については、下記サイトから詳細が得られます。
Oracle Technology Network > Java > Java EE
http://www.oracle.com/technetwork/java/javaee/overview/index.html
WAS の認証モデルは、以下の要素から構成されています。それぞれの詳細は後述します。（「9-3-3
ユーザー・レジストリー（p17）」、「9-3-4認証メカニズム(p18)」参照）
ユーザー・レジストリー
ユーザー情報を登録するレジストリー。OS レジストリーや LDAP などをサポート。
認証メカニズム
ユーザーの提示した情報を登録済みのユーザー情報と照会・確認するための方法。
9-3-3 ユーザー・レジストリー
WAS のユーザー・レジストリーは、管理セキュリティーやアプリケーション・セキュリティーなど WAS が
提供するセキュリティー機能を有効にする場合に使用されます。WAS はユーザー・レジストリーに存在
するユーザーおよびグループ情報を用いて認証をおこなったり、セキュリティー・ロールへのマッピング
などの操作を実施します。
WAS V8.5 では以下のユーザー・レジストリーをサポートしています。
ローカル OS レジストリー
ローカル・マシン上の OS のユーザー情報がレジストリーとして使用され、ユーザーID とパスワー
ド情報が認証時に使用されます。アプリケーション・サーバーが複数のマシンに分散しているセ
ル環境では、各マシンが独自のユーザー・レジストリーを持つため、ローカル OS ユーザー・レジ
ストリーを使用しないでください。ユーザー・レジストリーから取り出した ID は、通常、固有の ID で
あるため、まったく同じユーザーとパスワードが各マシン上に存在しても、マシンごとに異なりま
す。また、UNIX システムでローカル OS ユーザー・レジストリーを使用する場合、WAS プロセス
を実行するプロセス ID は、ユーザーやグループ情報取得用のローカル OS の API を呼び出す
ために、root 権限を持っている必要があります。
スタンドアロン LDAP レジストリー
LDAP バインディングを使用する認証が行われるユーザー・レジストリーです。WAS セキュリティ
ーは、ユーザーおよびグループの情報用リポジトリーとして機能する主要な LDAP ディレクトリ
ー・サーバーのインプリメンテーションを提供し、サポートします。これらの LDAP サーバーは、ユ
- 17 -
ーザー認証やその他のセキュリティー関連タスクの際に呼び出されます。カスタム LDAP フィー
チャーにより、適切なフィルターを使用すれば、製品がサポートする LDAP サーバーのリストには
ない、他の任意の LDAP サーバーをユーザー・レジストリーとして使用できます。
スタンドアロン・カスタム・レジストリー
開発者は、com.ibm.websphere.security.UserRegistry インターフェースを実装することにより、セ
キュリティーに使用するユーザー・レジストリーを自由に作りこむことができます。カスタム・ユーザ
ー・レジストリーは、リレーショナル・データベース、フラット・ファイルなど、事実上あらゆるタイプ
のアカウント・レポジトリーをサポートすることができます。既存のアプケーションでユーザーID、
パスワードを管理するためにデータベースを使用している場合などは、このインターフェースを実
装すればそのデータベースを WAS セキュリティーのユーザー・リポジトリーとすることが可能で
す。
統合リポジトリー
統合リポジトリーは、複数のレジストリーを同時に使用しながら論理的な単一リポジトリーのビュー
を提供します。1 つのレルム下には、下記のような複数のユーザー・リポジトリーの組み合わせが
可能です。
ファイル・ベース
LDAP（または LDAP のサブツリー）
データベース
カスタム
このうちデータベースは管理コンソールから操作することはできません。コマンドラインから
のみサポートされていますのでご注意ください。なお、統合リポジトリーを使用する場合、ユ
ーザー名は統合リポジトリーに追加されている複数リポジトリー内でユニークである必要があ
ります。
9-3-4 認証メカニズム
WAS は認証メカニズムとして LTPA、Kerberos、RSA トークンの 3 種類をサポートしています。
LTPA はプロファイル作成時にセキュリティーが有効であればデフォルトで構成されます。
LTPA
LTPA は、分散環境と複数アプリケーション・サーバーおよび複数マシン環境を対象としていま
す。LTPA は、転送可能な信任状およびシングル・サインオン(SSO)（参照：9-3-7-2）をサポートし
ています。LTPA は、分散環境のセキュリティーを暗号化によりサポートしているので、認証関連
のデータを暗号化し、デジタル署名して安全に伝送し、後で署名を暗号解除して検査することが
できます。複数のノードおよびセルに分散されているアプリケーション・サーバーは、LTPA を使
用することによって安全に通信を行うことができます。また、SSO の機能も提供されます。
Kerberos
WAS V7.0 から新しく Kerberos 認証がサポートされるようになりました。Kerberos 認証はオープン
でかつ成熟したネットワーク認証プロトコルで、認証、相互認証、メッセージの保全性と機密性、
および委任の機能を持ちます。Kerberos はクライアント、サーバー、および Kerberos 鍵配布セ
ンター (KDC) と呼ばれる信頼のおける第三者機関という 3 つのパーツで構成されており、そ
れゆえギリシャ神話の 3 つの頭をもつという地獄の番犬 Kerberos の名前がつけられています。
Kerberos 認証の利点のひとつとして、標準規格のため、様々な製品でサポートされており(.NET
や DB2 など)、他のアプリケーションとのインターオペラビリティーが可能になることがあげられま
す。WAS では LTPA と Kerberos の同時使用もサポートしています。
- 18 -
RSA トークン
RSA トークン認証も WAS V7.0 から新しく導入された認証方式です。この認証方式はフレキシブ
ル・マネジメント環境におけるサーバー間の管理認証 (管理コネクターおよびファイル転送要求)
にのみ使用されます。RSA トークン認証を使用することにより、フレキシブル・マネジメント環境で
の管理プロセス間のセキュリティー構成を各プロファイルのセキュリティー構成から分離すること
が可能になります。
SWAM は WAS V6.1 以降では非推奨となっており、将来のリリースでは除去される予定です。
9-3-5 仮想メンバー・マネージャー（VMM:virtual member
manager）
VMM = Virtual Member Manager
アプリケーション
管理コンソール
wsadmin
Administrative Command Framework
認証
(JAAS)
VMM ユーザー管理
VMM構成管理
VMM
VMM
構成
APIs
ランタイム
APIs
Property Ext
リポジトリー
CUR
LDAP
VMM
WASセキュリティ
Adaptor
Adaptor
Adaptor
Adaptor
File
LDAP
DB
Custom
Adaptor
Local OS
ユーザー・レジストリー
DB
図 9-4 VMM アーキテクチャー概要
統合リポジトリーが提供する、ユーザーやグループを管理する機能や同時に複数のレジストリーをサ
ポートする機能は、仮想メンバー・マネージャー（VMM）によって提供されています。VMM の目的は、
ユーザーおよび組織情報に対して、単一のモデルを提供することです。つまり VMM は、リポジトリーに
特化しない、ユーザーとグループを管理するための API とスキーマを提供します。この管理機能は、管
理コンソール、コマンドライン・ユーティリティ、公開された API から利用できます。
9-3-6 認証プロセス
前述の認証メカニズム機構とユーザー・レジストリーによって行われる WAS V8.5 の認証プロセスは、
図 9-5のような流れとなります。
基本的に、認証が必要なのは EJB クライアントと Web クライアントが保護リソースにアクセスする場合
です。サーブレット、EJB、または純粋な EJB クライアントは、CSIv2 プロトコルを使用して、WAS に認証
情報を送信します。Web クライアントは、HTTP や HTTPS といったプロトコルを使用して認証情報を送信
します。
- 19 -
認証情報は、基本認証、信任状トークン、またはクライアント証明書のいずれかです。Web 認証は
Web オーセンティケーター・モジュールにより実行され、EJB 認証は CSIv2 層にある EJB オーセンティケ
ーター・モジュールにより実行されます。認証モジュールは、JAAS ログイン・モジュールを使用して実装
されます。Web オーセンティケーターおよび EJB オーセンティケーターは、ログイン・モジュールに認証
データを渡し、データを認証するために LTPA の認証モジュールを呼び出します。認証モジュールは、
認証にローカル OS、LDAP、カスタム・レジストリーのいずれかをユーザー・レジストリーとして使用しま
す。
認証後にログイン・モジュールによって作成される信任状は、Web オーセンティケーター・モジュール
または EJB オーセンティケーター・モジュールに返されます。そして、Web オーセンティケーター・モジュ
ールまたは EJB オーセンティケーター・モジュールは、アクセス許可の仕組みが後に参照できるよう、こ
の信任状を保管しておきます。
図 9-5 認証プロセス
9-3-7 設定方法
ここでは、管理コンソールを使用した統合リポジトリー、SSO、トラスト・アソシエーション、ユーザー・レ
ジストリーなどの設定方法を紹介します。
9-3-7-1 統合リポジトリー
統合リポジトリーの設定は 2 つのステップからなります。まず、最初に LDAP などのリポジトリーを追加
し、それを統合リポジトリーに追加するという流れになります。
管理コンソールの[セキュリティー]→[グローバル・セキュリティー]画面を開き、ユーザー・アカウント・リ
ポジトリー・フィールドの[使用可能なレルム定義]で[統合リポジトリー]を選択し、右隣の[構成]ボタンをク
リックします。デフォルトではレルム内のリポジトリーはファイル・ベースのリポジトリーのみです。
- 20 -
統合リポジトリー画面では、[リポジトリー（LDAP、カスタムなど）の追加]ボタンをクリックします。
- 21 -
リポジトリー参照画面で、[新規リポジトリー…]ボタンをクリックし、リポジトリーのタイプを選択し、セキュ
ア・アクセスに関する構成を次画面で行います。必要な項目を入力したら[OK]ボタンを押します。
管理コンソールから、[セキュリティー]→[グローバル・セキュリティー]を開き、ユーザー・アカウント・リ
ポジトリー・フィールドの[使用可能なレルム定義]で[統合リポジトリー]を選択し、右隣の[構成]ボタンをク
リックします。関連項目の[リポジトリーの管理]をクリックすると、追加されたリポジトリーを確認することが
できます。
- 22 -
9-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 でサポート
されています。尚、LTPA トークンは Cookie を利用して連携されるので、同じ DNS ドメイン内のシステム
で SSO が実現できます。
SSO におけるログインの処理の流れを表したのが、図 9-6になります。
/FormAuth/login.html がシステムのログオン画面です。この画面でユーザーID/パスワードを入力して
ログオンボタンをクリックすると、サーバーに対する認証要求が実行されます。ユーザーID とパスワード
が正しい場合には LTPA トークンが発行され、保護されたリソースに対してアクセス可能になります。この
後システム B の保護されたリソースに対してアクセスをします。この際 HTTP リクエストにはシステム A で
発行された LTPA トークンが付加されています。システム B は、LTPA トークンの情報を元に、クライアント
からのリクエストを許可して、画面を返します。
図 9-6 SSO におけるログイン処理の流れ
- 23 -
SSO を行うには、LTPA トークンを共有する範囲を指定するドメイン・ネームを設定し、LTPA 鍵の交換
を行う必要があります。LTPA トークンを共有する範囲の指定は、管理コンソールで[セキュリティー]→[グ
ローバル・セキュリティー]→[認証]→[Web および SIP セキュリティー]→[シングル・サインオン (SSO)]
を開いて、ドメイン・ネームを入力することで行います。クライアントは、ここで設定されたドメインの範囲
で、同じ LTPA トークンを使用します。したがって、ドメインが異なるシステム間では SSO を実現すること
は出来ません。
WAS V8.0 から、シングル・サインオン設定ページに、「セキュリティー Cookie を HttpOnly に設定
して、クロスサイト・スクリプティング・アタックを阻止します」チェックボックスが追加されました。HttpOnly
属性は、クロスサイト・スクリプティングのぜい弱性を回避するために、 クライアント・サイド・アプリケーシ
ョン (Java スクリプトなど) が Cookie にアクセスできないように作成されたブラウザー属性です。この属
性は、LTPA および WASReqURL の Cookie に HttpOnly フィールドを組み込むように指定します。
LTPA 鍵の交換（鍵のエクスポートとインポート）を行います。
まず、一方のサーバーから LTPA 鍵をエクスポートします。管理コンソールで [セキュリティー]→[グロ
ーバル・セキュリティー]→[認証]→[LTPA] を選択し、インポート時に必要となるパスワードとエクスポー
ト先ファイルを完全修飾名で指定し、エクスポートボタンをクリックします。エクスポートした LTPA 鍵はテ
キスト形式ですので、テキスト・エディタで内容を確認することができます。
次に、エクスポートした LTPA 鍵を別のサーバーに移動しインポートします。インポートは、管理コンソ
ールで [セキュリティー]→[グローバル・セキュリティー]→[認証]→[LTPA] を選択し、エクスポート時に
指定したパスワードとファイルを指定し、インポートボタンをクリックすることで行います。
- 24 -
図 9-7 LTPA のインポートエクスポート画面
構成を保管し、アプリケーション・サーバーあるいはデプロイメント・マネージャーを再起動します。
9-3-7-3 トラスト・アソシエーション
トラスト・アソシエーションにより、WAS セキュリティーとサード・パーティー製セキュリティー・サーバーと
を統合することができます（「9-1-2 セキュリティー概観」参照）。トラスト・アソシエーションの設定は、管理
コンソールの[セキュリティー]→[グローバル・セキュリティー]→[認証]→[Web および SIP セキュリティ
ー]→[トラスト・アソシエーション]を開いて行います。各項目に適切な値を設定してから構成を保管し、
アプリケーション・サーバーあるいはデプロイメント・マネージャーを再起動します。
図 9-8 トラスト・アソシエーションの設定画面
トラスト・アソシエーションを使用可能にする
トラスト・アソシエーション機能を有効にするかどうかを指定します。トラスト・アソシエーション機能
により、WAS セキュリティーとサード・パーティー製セキュリティー・サーバーを統合することができ
ます。つまり、リバース・プロキシー・サーバーがフロントエンド認証サーバーとして機能できるよう
になる一方で、プロキシー・サーバーから渡された認証情報をこの製品自体の認証ポリシーに適
用することができるようになります。
9-4 認可
この節では、WAS V8.5 における基本的なセキュリティー技術の一つである認可について説明しま
す。
- 25 -
9-4-1 認可とは
認可とは、認証されたユーザーが、要求するリソースにアクセスする権限をもっているかを判定するプ
ロセスであり、アクセス制御とも言われます。
9-4-2 認可モデル
WAS セキュリティーにおける認可は、Java EE のセキュリティー・モデルに基づいて行われます。個々
のユーザーに対してアクセス制御を行うのではなく、セキュリティー・ロールという概念の元にアクセス制
御を行います。セキュリティー・ロールを使用することによって、ユーザー管理を WAS 環境から分離する
ことができます。HTML、サーブレット、JSP、EJB などといったリソースに対して、図 9-9のようにセキュリ
ティー・ロールを設定してアクセス制御を行うことができます。例えば、Teller ロールを設定します。表から
Teller ロールは AccountBean method の getBalance を実行することが可能です。このロールを持つユー
ザーは、Teller Group と Bob になります。よって、Bob は getBalance を実行することができるユーザー
になります。
図 9-9 セキュリティー・ロールの設定例
WAS の認可モデルには、以下の二形態があります。それぞれの詳細は後述します。（「9-4-3宣言セ
キュリティー(p27)」、「9-4-4プログラマティック・セキュリティー(p27)」参照）
宣言セキュリティー（デクララティブ・セキュリティー）
デプロイメント・ディスクリプターにセキュリティー・ポリシーを記述する方法
プログラマティック・セキュリティー
API を使用してコード内でセキュリティー・タスクを実装する方法
- 26 -
9-4-3 宣言セキュリティー
宣言セキュリティーは、アプリケーションのアセンブリー段階で構成されるもので、セキュリティー・ポリ
シーなどの情報はデプロイメント記述子で宣言または定義されています。宣言セキュリティーは、セキュ
リティー・ランタイムによって実行されます。ここに、Servlet2.5 におけるデプロイメント記述子の一例を示
します。
<security-constraint>
<display-name>ExampleSecurityConstraint</display-name>
<web-resource-collection>
アクセス制限する
Web リソースを設定
<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>
例 9-1 デプロイメント記述子の一例
9-4-4 プログラマティック・セキュリティー
プログラマティック・セキュリティーは、宣言セキュリティー単独ではアプリケーションのセキュリティー・
モデルを表現するのに十分でない場合に、セキュリティーを重視するアプリケーションによって使用され
ます。Servlet と EJB に対して API を提供しており、コードの中でそれらを使用してセキュリティー・タスク
を実装することができます。
プログラマティック・セキュリティーは、HttpServletRequest インターフェースの以下のメソッドから構成さ
れています。
HttpServletRequest.getRemoteUser
クライアント認証に使用したユーザー名を戻します。ユーザーが認証されていない場合は、null
を戻します。
HttpServletRequest.isUserInRole
リモート・ユーザーに指定されたセキュリティー・ロールが与えられている場合は、true を戻しま
す。リモート・ユーザーが、指定されたロールを与えられていない場合、またはユーザーが認証さ
れていない場合は、false を戻します。
- 27 -
HttpServletRequest.getUserPrincipal
リモート・ユーザー名を含む java.security.Principal オブジェクトを戻します。ユーザーが認証され
ていない場合は、null を戻します。
また、javax.ejb.EJBContext インターフェースで提供される次の２つのメソッドを使用すると、EJB の呼
び出し元についてのセキュリティー情報にアクセスすることができます。
isCallerInRole
Bean の呼び出し元に、ロール名で指定されているセキュリティー・ロールが認可されている場合
は、true を戻します。呼び出し元に指定のロールが認可されていない場合、または呼び出し元が
認証されていない場合は、false を戻します。
getCallerPrincipal
Bean 呼び出し元の名前を含む java.security.Principal オブジェクトを戻します。呼び出し元が認
証されていない場合は、認証されていない名前を含むプリンシパルを戻します。
9-4-5 代行モデル
代行とは、セキュリティーID を呼び出し元から呼び出されるオブジェクトに伝搬するプロセスです。
Java EE 仕様により、サーブレットと EJB は、EJB を呼び出す際にクライアント ID を伝搬することも、ある
いはデプロイメント記述子で明示指定された別の ID を使用することもできます。WAS では、図 9-10のよ
うにクライアント ID、指定済み ID、システム ID といった 3 つのタイプの代行が可能です。
図 9-10 代行モデル
- 28 -
9-4-6 認可プロセス
前述のような認可機構によって行われる WAS V8.5 の認可プロセスは、図 9-11のような流れとなりま
す。
図 9-11 認可プロセス
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)を読み取ります。
- 29 -
呼び出し元がサービスの要求に必要な特権を持っているかどうかを判別するためには、許可情報を
使用します。許可情報は、いろいろな方法で保管できます。例えば、リソースごとにアクセス制御リストを
保管することができ、ここには、ユーザーおよびユーザー特権のリストが含まれています。もう１つの保管
方法は、リソースのリストとそれに対応する特権を各ユーザーに関連付けることです。
9-5 SSL
この節では、WAS V8.5 における基本的なセキュリティー技術の一つである SSL について説明しま
す。
9-5-1 SSL とは
SSL とは、クライアントとサーバー間のセキュア接続のための認証性、保全性、および機密性のあるト
ランスポート層セキュリティーを提供するプロトコルです。このプロトコルは、TCP/IP の上位、かつ HTTP、
LDAP、ORB/IIOP などのアプリケーション・プロトコルの下位で実行され、トランスポート・データに信頼
性とプライバシーを提供します。
クライアントとサーバー双方の SSL 構成に応じて、さまざまなレベルの信頼性、データ保全性、および
プライバシーを確立することができます。適切な構成を行い、クライアントとアプリケーション両方のデー
タに必要な保護レベルを実現するためには、SSL の基本動作について理解していることが非常に重要
です。
SSL によって提供されるセキュリティー・フィーチャーの中には、データの伝送中に機密情報が漏れな
いようにするためのデータの暗号化があります。また、データの署名により、データの転送中にデータが
許可なく変更されることを防止できます。更に、クライアント認証およびサーバー認証により、適切なユー
ザーまたはマシンと通信していることが保証されます。SSL は、エンタープライズ環境の通信の保護に効
果的です。
図 9-12 SSL の仕組み
- 30 -
9-5-2 SSL 構成
WAS では、内部にある複数のコンポーネントが SSL を使用することで、データを信頼できるものにし、
プライバシーを保護します。これらのコンポーネントとは、標準装備された HTTP トランスポート、ORB、
およびセキュア LDAP クライアントです。
各コンポーネント間において使用される SSL は、以下の通りです。
HTTP トランスポート
WAS に組み込まれた HTTP トランスポートは、ブラウザーなどの Web クライアントや Web サーバ
ー・プラグインから SSL を介した HTTP 要求を受け入れます。
ORB
WAS で使用される ORB は、SSL を介して IIOP を実行し、メッセージを保護します。
セキュア LDAP クライアント
セキュア LDAP クライアントは、SSL を介して LDAP を使用し、LDAP ユーザー・レジストリーへの
セキュア接続を実現します。このクライアントは、LDAP をユーザー・レジストリーとして構成する場
合にのみ存在します。
9-5-3 SSL 証明書
SSL 通信の際には SSL 証明書が必要になります。デジタル証明書、デジタル ID、単に証明書とも呼
びます。証明書には、ベリサインなどの認証局(CA)によって発行された証明書と自己署名証明書があり
ます。認証局が発行した証明書は認証局の秘密鍵を使用した署名が付いているのに対して、自己署名
証明書は自分自身の秘密鍵を使用した署名が付いています。それらの証明書が使い分けされるケース
としては、ブラウザーと Web サーバー間の SSL 構成には認証局が発行する証明書を使用し、システム
の内部コンポーネント間の SSL 構成には自己署名証明書が使用されるケースが考えられます。
WAS V6.1 の証明書管理機能で作成される証明書はすべて自己署名証明書でした。WAS V7.0 から
は、以前のバージョンとは異なり、チェーン証明書がデフォルトで採用されています。チェーン証明書と
は、証明書に署名するために別の証明書(ルート証明書)が使用された証明書になります。自己署名証
明書は自身によって署名されているのに対して、チェーン証明書は WAS が認証局として発行したルー
ト証明書によって署名されている点が異なります。また、チェーン証明書は、証明書に別の証明書で署
名しているという点において CA 証明書と同じ構造であるといえます。そして、ルート証明書は、チェーン
証明書より有効期限が長く、WAS コンポーネント間で共有されます。
図 9-13はデフォルトで作成されるチェーン証明書になります。図の発行先と発行元に注目すると、チ
ェーン証明書(別名：default)はルート証明書が発行した（署名した）証明書であり、ルート証明書は WAS
内部で発行した自己署名証明書であることがわかります。
デフォルトの有効期限は、チェーン証明書が 1 年、ルート証明書が 15 年になっています。この有効期
限は、プロファイル作成（拡張プロファイル作成）時に変更することが可能です。チェーン証明書が 1 年
～15 年（1 年単位）、ルート証明書が 15 年/20 年/25 年から選択できます。プロファイルツール画面上の
記述は、個人証明書がチェーン証明書、署名者証明書がルート証明書に該当します。
- 31 -
図 9-13 デフォルト個人証明書
9-5-4 設定方法
ここでは、Web ブラウザーと Web サーバー間および Web サーバーと WAS 間を SSL 通信させるため
の設定方法をそれぞれ紹介します。
なお、WASV8.0 からは有効な鍵サイズの値は、512、1024、2048、4096、 および 8192 で、デフォル
トの鍵サイズの値は 2048 ビットです。
9-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
を開き、次の行をファイルの下部に追加します。
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
- 32 -
ホスト名と鍵ファイルのパスは適宜変更してください。また、SSLClientAuth ディレクティブのコメン
トアウトをはずすことにより、クライアント認証をサポートすることができます。
WAS の設定
WAS では、仮想ホスト default_host に SSL 通信用のホスト・エイリアスを追加する必要がありま
す。管理コンソールの[環境]→[仮想ホスト]→[default_host]→[ホスト別名]を選択します。[新規
作成]ボタンをクリックして、該当するフィールドに SSL 通信に使用するポート番号（通常は 443）
を指定して、エイリアスを追加します。
9-5-4-2 Web サーバーと WAS 間の SSL 構成
デフォルト構成では、Web ブラウザーと Web サーバー間が SSL 通信を行っている場合、Web サーバ
ーと WAS 間は自動的に SSL 通信用ポートを使用して SSL 通信を行います。SSL 用 Web サーバー・プ
ラグインの構成手順は以下の通りです。
1). SSL 用 Web サーバー・プラグインの構成
Web サーバー・プラグインはそれ自身の秘密鍵と公開鍵を保管し、Web コンテナーの鍵ファイルの公
開証明書を保管するために、鍵ストア（鍵データベース）を必要とします。
Web サーバー・プラグインが参照する鍵ストア・ファイルを保管するディレクトリーを Web
サーバー・ホスト上に準備します。（例：${plugin_install_root}/etc/keys。デフォルトで
は、プラグイン構成ファイルと同じディレクトリーに保管されます。）
ii). 管理コンソールから[サーバー]→[Web サーバー]→[webserver_name]を選択します。
[プラグイン・プロパティー]→[鍵と証明書の管理]をクリックし、鍵ストアの保護に使用す
るパスワードを変更し、[OK]ボタンをクリックします。
iii). [Web サーバー鍵ストア・ディレクトリーへコピー]をクリックして、鍵ストア・ファイルと
stash ファイルを Web サーバーへコピーします。管理対象外の Web サーバーの場合
は、FTP を使用してこれらをコピーします。
i).
- 33 -
2).
動作確認を行います。
サンプル・アプリケーションの snoopServlet を稼動させ、SSL 通信が行えていることを確認しま
す。
https://[ホスト名]/snoop
図 9-14 snoop 画面
なお、パフォーマンスの観点から、明示的に Web サーバーと WAS 間で SSL 通信をさせないために
は、WAS で定義されている SSL 通信用のトランスポートを削除する必要があります。
※ただし、WAS V8.5.5.0 以降では、SSL 通信用のトランスポートを削除するとエラーとなるため、管理コ
ンソールでカスタム・プロパティーを設定してその動作を使用可能にする必要があります。
[Web サーバー]→[webserver_name]→[プラグイン・プロパティー]→[カスタム・プロパティー]を選択
し、UseInsecure を true に設定します。詳細は以下 URL を参照してください。
WAS V8.5 Information Center「Web サーバー・プラグインのトラブルシューティングのヒント」
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-dist&t
opic=rtrb_plugincomp
- 34 -
9-6 鍵と証明書
この節では、WAS V8.5 における鍵と証明書の管理について説明します。
9-6-1 Ikeyman と同等の機能を管理コンソールから使用
ikeyman と同等の機能が WAS V6.1 より管理コンソールで行うことができます。従来の ikeyman も引き
続き使用することができます。ただし、個人証明書と署名者証明書の管理は ikeyman、管理コンソール
のどちらで行なっても可能ですが、証明書要求は生成したツールを使用して受信する必要があります。
これは、証明書要求を ikeyman で作成された場合は ikeyman で受信する、管理コンソールで作成され
た場合は管理コンソールで受信する、という意味になります。また、鍵や証明書の管理は ikeyman、管理
コンソールのほかに wsadmin からも AdminTask オブジェクトを使用することで可能です。
- 35 -
9-6-2 証明書の有効期限
WAS V6.1 より証明書の有効期限を管理コンソールから管理することができます。対象は鍵ストアに格
納されている証明書と署名のみです。管理コンソールから、[セキュリティー]→[SSL 証明書および鍵管
理]→[証明書有効期限の管理]を選択します。この証明書の有効期限の管理のページでは、スケジュー
ルやしきい値に基づいてすべての証明書を検査します。また、関連項目にある[通知]では、有効期限
切れの警告をログや e-mail で知らせることができます。
有効期限のしきい値に達した場合、同じ証明書情報を使用して自動的に証明書を更新することや、
鍵ストア内にある古い証明書を新しい証明書に置き換えることも可能です。
図 9-15 証明書有効期限の管理と通知画面
WAS V6.1 では証明書自動更新による以下の問題がありました。
【ご注意ください】 WAS 6.1 の自己署名証明書・自動更新機能を使用する場合の考慮点
http://www-01.ibm.com/support/docview.wss?uid=jpn1J1004224
【考慮事項】WAS ND V7.0 証明書自動更新機能について (WAS-09-024)
http://www-01.ibm.com/support/docview.wss?uid=jpn1J1006215
上記 URL では考慮点１～４が報告されています。WAS V7.0 からはデフォルトでチェーン証明書を使
用しているため、考慮点 2、3、4 の SSL 接続障害は発生しません。これはチェーン証明書の署名を、コ
ンポーネント間で共有されるルート証明書で行うためです。チェーン証明書で使用するルート証明書は
- 36 -
15 年という長い有効期限を持っています。したがって、チェーン証明書の更新を 1 年ごとに行ったとして
も、証明書の検証失敗によって SSL 通信ができなくなるという問題は起こりません。
しかし、考慮点 1 については、WAS V7.0 以降のチェーン証明書を使用した場合においても問題が発
生します。セルとノードの同期が行われない場合、セル側の証明書は自動更新処理によって新しい証
明書に置き換えられますが、ノード側は同期が行われないため、ノード側が保持する個人証明書（チェ
ーン証明書）は更新されず古い証明書のまま有効期限が切れた状態となります。この状態でデプロイメ
ント・マネージャーとノード・エージェントが双方向 SSL 接続を行うと、SSL ハンドシェイクに失敗して SSL
通信を行うことができません。対応策としては、syncNode コマンドを使用して手動で同期処理を行った
後にノード・エージェントを起動してください。
WAS V7.0 以降において自己署名証明書を使用する場合においては、WAS V6.1 と同様の問題が発
生しますので、注意してください。自己署名証明書の場合は、トラスト・ストアに保管される署名者証明書
として、自動更新された自己署名証明書を保管する必要があり、SSL 通信を行うノード間でこの署名者
証明書の交換が正常に行えないと SSL 通信に失敗して、環境によっては WAS がサービス停止となって
しまう可能性があります。
WAS V7.0 以降では、wsadmin コマンドを使用して自己署名証明書をチェーン証明書に変換する事
が可能です。AdminTask オブジェクトの convertSelfSignedCertificatesToChained コマンドを使用してくだ
さい。convertSelfSignedCertificatesToChained コマンドは、自己署名証明書の情報 (発行先識別名、
サイズ、および存続期間など) を使用して、同じ情報のチェーン証明書を作成します。新しいチェーン
証明書によって自己署名証明書が置き換えられます。詳細は以下 URL を参照してください。
WAS V8.5 Information Center「AdminTask オブジェクトの SSLMigrationCommands コマンド・グルー
プ」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.nd.doc/ae/rxml_7sslmi
gration.html
9-7 監査
この説では、WAS V7.0 から追加された監査機能について説明します。
9-7-1 監査とは
WAS V7.0 からは、監査機能が追加され、WAS のインフラおよびアプリケーションで認証・認可やその
他のセキュリティー・イベントをモニターし、保護対象リソースに対して、「いつ」、「誰が」、「何をしたの
か」を監査ログに記録することが可能です。
この監査機能の使用目的として、主に２つの目的があります。１つは、既存システムのセキュリティー
構成の有効性と保全性を確保することです。2008 年 4 月から開始された日本版 SOX 法（金融商品取引
法）により、上場企業には「財務報告の適正性」を確保するための内部統制の整備が求められていま
す。そして内部統制の有効性の評価において、システムが出力する監査ログからいつでも必要な情報
を引き出せる必要があります。このように法令遵守を証明し、立証責任と否認防止の証拠の提示に役立
ちます。もう 1 つは、セキュリティー構成の改善が必要な領域を認識するなどの脆弱性分析に利用する
事ができます。監査ログを分析することにより、既存のセキュリティー・メカニズムの欠陥を見つけたり、現
在のセキュリティー・インフラストラクチャーの潜在的な弱点を発見したりすることができます。
- 37 -
セキュリティー監査機能を使用可能にする場合には、ご使用の環境でグローバル・セキュリティーを有
効にする必要があります。また、セキュリティー監査機能の構成設定を表示および変更するには、ユー
ザーに監査員ロールが必要です。監査員ロールの詳細は、「9-8 管理ロール」を参照してください。
そして、セキュリティー監査機能の構成要素として以下のものがあります。
イベント・タイプ・フィルター
監査ログとして記録される監査可能なイベント・タイプをフィルタリングすることができます。
イベント・タイプ・フィルターを構成して、特定の監査可能イベント・タイプのサブセットだけを監査ロ
グに記録することができます。記録されるイベント・タイプをフィルタリングすると、ご使用の環境にと
って重要なレコードのみが確実に保存されるため、監査レコードの分析が容易になります。
監査イベント・ファクトリー
監査イベント・ファクトリーは、監査可能なセキュリティー・イベントに関連付けられたデータを収集
し、監査データ・オブジェクトを作成します。作成されたオブジェクトは、監査サービス・プロバイダー
に送信され、フォーマットされて、指定されたリポジトリーに記録されます。
監査サービス・プロバイダー
監査サービス・プロバイダーを使用して、監査イベント・ファクトリーによって送信された監査データ・
オブジェクトをフォーマットします。監査データは、フォーマットされた後、監査サービス・プロバイダ
ー構成で定義されているリポジトリーに記録されます。
監査サービス・プロバイダーは、デフォルトで組み込まれているバイナリ・ベース・エミッターとサー
ド・パーティー・エミッターのどちらかを選択することができます。
デフォルトの監査サービス・プロバイダーでフォーマットされた監査ログはテキスト形式で保管され、
監査ログ・ファイルの場所／サイズ／最大数／使用可能なフィルターを設定することができます。
また、監査リーダーを使用して HTML 形式の監査データにフォーマットすることが可能です。詳細
は、「9-7-4 監査リーダーの使用」を参照してください。
暗号化および署名
監査の実行においては、記録された監査データのデータ保全性を保護および保証することが重要
です。許可されたユーザーだけが監査データへアクセスでき、改ざんを防止するために、監査デー
タを暗号化および署名することができます。
障害通知
通知を使用可能にして、セキュリティー監査機能に障害が発生したときにアラートを生成することが
できます。通知は、システム・ログにアラートを記録したり、指定した受信者リストにアラートを E メ
ールで送信したりするように構成できます。
監査リーダー
監査リーダーは、デフォルトのバイナリー・エミッター実装によって生成されるバイナリー監査ログを
読み取るためのユーティリティーです。監査リーダーは、監査ログを解析して HTML レポートを生
成します。監査リーダーは、wsadmin コマンドを使用して呼び出します。尚、管理コンソールからア
クセスすることはできません。
- 38 -
9-7-2 監査可能なイベント・タイプ
WAS V8.5 の監査機能を使用して監査可能なイベント・タイプを表 9-2に示します。これらのイベント・
タイプは、イベント・タイプ・フィルターで選択できます。
表 9-2 監査イベント・タイプ一覧
イベント名
SECURITY_AUTHN
SECURITY_AUTHN_CREDS_MODIFY
SECURITY_AUTHN_DELEGATION
SECURITY_AUTHN_MAPPING
SECURITY_AUTHN_TERMINATE
SECURITY_AUTHZ
SECURITY_ENCRYPTION
SECURITY_MGMT_AUDIT
SECURITY_MGMT_CONFIG
SECURITY_MGMT_KEY
SECURITY_MGMT_POLICY
SECURITY_MGMT_PROVISIONING
SECURITY_MGMT_REGISTRY
SECURITY_MGMT_RESOURCE
SECURITY_RESOURCE_ACCESS
SECURITY_RUNTIME
SECURITY_SIGNING
ADMIN_REPOSITORY_SAVE
監査取得対象
全ての認証
ユーザーID に対するクレデンシャルの変更
ID アサーションや RunAs などの委任情報関連
2 つのユーザーID が含まれるクレデンシャルマッピング情
報関連
タイムアウト、ログアウト等による認証の終了
システムのアクセス・コントロール・ポリシー実行時の認証
Web サービスの暗号化など暗号化情報
監査の開始、停止などセキュリティー監査サブシステム操
作関連
WAS の管理・構成操作関連
証明書の作成、更新など証明書に対する管理操作関連
アクセス制御リストの作成等のセキュリティー・ポリシー関
連
ユーザー・アカウントの作成やグループへの追加等のプ
ロビジョニング
ユーザー、グループの作成、変更など認証リポジトリー管
理関連
ファイル、Web ページなどのリソース属性の作成、削除等
のリソース管理
Web ページやデータベースなどリソースに対する全ての
アクセス
サーバーの開始や停止など、ランタイム・イベント
Web サービスに対する SOAP メッセージを有効にするた
めなどの署名操作関連
マスター・リポジトリーの変更を保存するときのイベント
※リポジトリーの自動チェックポイント機能が使用可能に
なっていることが前提となります。
9-7-3 設定方法
監査ログを取得するための設定方法について説明します。
1). セキュリティー監査サブシステムの使用可能化
管理コンソールより、[セキュリティー]→[セキュリティー監査]を選択し、[セキュリティー監査を使用可
能にする]のチェックボックスにチェックを入れます。セキュリティー監査を使用可能にするにはグローバ
- 39 -
ル・セキュリティーが有効になっている必要があります。変更を有効にするためには JVM を再起動する
必要があります。
2). 監査員ロールの割り当て
監査員ロールを持つユーザーは、セキュリティー監査サブシステムを使用可能にして構成する必要
があります。セキュリティー監査を最初に使用可能にしたときには、１次監査員ユーザーは 1 次管理者に
なっています。ご使用の環境で特権を分離する必要がある場合は、デフォルトのロール割り当てを変更
する必要があります。
また、セキュリティー監査を使用可能にした後に１次監査員ユーザーを１次管理者以外の監査ロール
が割り当てられたユーザーに変更することが可能です。尚、監査ロールが割り当てられたユーザーは事
前に作成しておく必要があります。
監査員ロールに関する詳細は、9-8-1-1監査員（P50）を参照してください。
- 40 -
3). イベント・タイプ・フィルターの作成
管理コンソールより、[セキュリティー]→[セキュリティー監査]→[イベント・タイプ・フィルター]→[新規作
成]をクリックします。[名前]フィールドにこのイベント・タイプ・フィルター構成と関連付ける固有の名前を
入力します。このフィルターが適用されるときに記録するイベントとイベント結果を指定して[OK]ボタンを
クリックします。
また、作成後に使用可能フィールドを設定することができ、true/false の選択が可能です。
- 41 -
監査サービス・プロバイダーの構成
管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査サービス・プロバイダー]→[新
規作成]をクリックします。作成する監査サービス・プロバイダーのタイプを選択します。今回はデフォルト
の[バイナリー・ファイル・ベース・エミッター]を選択します。
4).
以下のフィールドに値を設定して、[OK]ボタンをクリックします。
名前
監査ログ・ファイルの場所
監査ログ・ファイル・サイズ
監査ログ・ファイルの最大数
最大数に到達したときの動作
使用可能なフィルター
：任意
：任意
：10 （デフォルト）
：100 （デフォルト）
：最も古いものを上書き（デフォルト）
：この監査サービス・プロバイダーで使用するフィルターを選択可能
なフィルターから選択。
- 42 -
※WAS V8.0 から監査ログが最大数に達したときの動作を指定できるようになりました。これは、バイナリ
ー監査ログの実装にのみ適用できます。
次のオプションから 1 つを選択します。
・最も古いものを上書き： 最大数の監査ログに達すると、最も古い監査ログが書き換えられます。監
査員に通知は送信されません。これがデフォルト・オプションで、WAS V7
以前と同様です。
・サーバーの停止：
監査サービスを停止して、通知を SystemOut.log に送信し、アプリケーシ
ョン・サーバーは静止します。
・ロギングの停止：
監査サービスを停止しますが、アプリケーション・サーバーは停止せず、通
知が SystemOut.log に記入されることはありません。
- 43 -
5). イベント・ファクトリーの構成
管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査イベント・ファクトリー]→[新規作
成]をクリックします。
以下のフィールドに値を設定して、[OK]ボタンをクリックします。
名前
：任意
監査サービス・プロバイダー
：構成済み監査サービス・プロバイダーを選択。
使用可能なフィルター
：この監査サービス・プロバイダーで使用するフィルターを選択可能
なフィルターから選択。
6). 監査データの暗号化（オプション）
このステップはオプションとなります。
i). 監査データの暗号化に使用する鍵ストアと証明書を作成します。
管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査暗号化鍵ストアおよび証明書]を選
択して新規作成をクリックします。以下のフィールドに値を設定して[OK]をクリックします。
名前
：任意
パス
：任意
パスワード
：任意
確認パスワード
：任意
タイプ
：PKCS12（デフォルト）
- 44 -
作成した鍵ストアを選択して、追加プロパティーの[個人証明書]を選択して[自己署名証明書の作
成．．．]をクリックします。必要なフィールドを設定して[OK]をクリックします。
別名
：任意
鍵サイズ
：2048 ビット（デフォルト）
共通名
：任意
有効期間
：365 日間（デフォルト）
- 45 -
ii). 監査レコード暗号化構成を行います。
管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査レコード暗号化構成]を選択します。
[暗号化を使用可能にする]にチェックを入れ、[暗号化証明書が入った監査鍵ストア]に作成した鍵スト
アが選択され、[鍵ストア内の証明書]の[証明書別名]に作成した証明書が選択されている事を確認しま
す。[OK]をクリックして、構成を保存します。
7). 監査データの署名（オプション）
管理コンソールより、[セキュリティー]→[セキュリティー監査]→[監査レコード署名構成]を選択します。
[署名を使用可能にする]にチェックを入れ、[署名証明書が入った管理対象鍵ストア]で作成済みの鍵ス
トアを選択します。証明書は[鍵ストア内の証明書]あるいは[選択した鍵ストア・ファイルに新規証明書を
作成する]のどちらかを選択できます。ここでは、前者を選択しています。
[OK]をクリックして構成を保存します。変更を有効にするにはサーバーの再始動が必要です。
- 46 -
9-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
例 9-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 -
例 9-3 監査リーダー
-reportMode オプションで生成するレポートのタイプを指定します。有効な値には、basic、complete、また
は custom があります。 basic のレポートには、以下の構成情報が記載されます。
作成時刻 (creationTime)
アクション (action)
プログラム名 (progName)
レジストリー・タイプ (registryType)
ドメイン (domain)
レルム (realm)
リモート・アドレス (remoteAddr)
リモート・ポート (remotePort)
リモート・ホスト (remoteHost)
リソース名 (resourceName)
リソース・タイプ (resourceType)
リソース固有 ID (resourceUniqueId)
その他のオプションで監査イベントタイプ（複数可）や監査イベント結果、HTML レポートの開始/終了
順序番号、タイム・スタンプ範囲を指定してフィルタリングをかけて HTML レポートを生成することができ
ます。このように監査リーダーを使用して、同じデータを複数回解析し、要件に応じて別々のレポートを
生成することができます。
例 9-2のバイナリー監査ログから監査リーダーを使用して生成した HTML 形式の監査レポートを図
9-16に示します。
図 9-16 監査リーダーで生成した HTML 形式の監査レポート
- 48 -
9-8 管理ロール
この節では、管理ロールとその設定方法について説明します。
9-8-1 管理ロール
管理ロールとは、ユーザーおよびグループに対して割り当てられた役割のことで、管理セキュリティー
が有効なときに使用できます。この管理ロールはユーザーやグループに対して複数割り当てることが可
能です。
WAS V8.5 の管理機能へのアクセス制御に使用される管理ロールは、管理者、コンフィギュレーター、
オペレーター、モニター、デプロイヤー、セキュリティー・マネージャーの管理者、iscadmins、監査員の 8
種類です。
表 9-3 管理ロール一覧
管理ロール
管理者
コンフィギュレーター
オペレーター
モニター
デプロイヤー
セキュリティー・マネージ
ャーの管理者
内容
オペレーター、コンフィギュレーターに与えられる権限をもち、管理者ロー
ルにだけ許可されている追加権限をもっている
・サーバーID とパスワードの変更
・管理者ロールにユーザーとグループをマップ
・認証、認可のメカニズムの構成
・Java 2 セキュリティーを使用可能または使用不可
・統合リポジトリー構成のユーザーを作成、更新、または削除
・LTPA パスワードの変更や鍵生成
モニターに与えられる権限をもち、WAS の構成を変更することができる
・リソース作成
・アプリケーションに、ユーザーおよびグループからロールへのマッピング
の割り当て
・アプリケーション・サーバーをマップ
・アプリケーションのインストール、アンインストール
・アプリケーションのデプロイ
・アプリケーションの Java 2 セキュリティー権限をセットアップ
・CSIv2、SSL 構成をカスタマイズ
モニターに与えられる権限をもち、ランタイム状態を変更することができる
・サーバーの起動／停止
・管理コンソールでサーバーの状態を監視
・WAS の構成をみる
・アプリケーション・サーバーのランタイム状態をみる
・アプリケーションの構成とランタイムオペレーションが可能
・ユーザーやグループを管理ロールにマップすることができる。
・Fine-grained 管理セキュリティーを使用する場合、この管理ロールをもつ
ユーザーだけが許可グループを管理できる
- 49 -
iscadmins
監査員
管理コンソール・ユーザーのみ使用可能
統合リポジトリー構成のユーザーおよびグループを管理することができる
・ユーザーやグループを作成、更新、または削除することができる
モニターに与えられる権限をもち、セキュリティー監査サブシステムの構成
設定を表示および変更することができる
・セキュリティー監査サブシステムを使用可能/使用不可
・イベント・ファクトリーのプラグイン・ポイントで使用するイベント・ファクトリー
実装を選択
・サービス・プロバイダーのプラグイン・ポイントで使用するサービス・プロバ
イダーまたはエミッター (あるいは両方) を選択および構成
・セキュリティー監査サブシステムにエラーが発生した場合のアプリケーシ
ョン・サーバーの動作を記述する監査ポリシーを設定
・監査対象のセキュリティー・イベントを定義
管理者とセキュリティー・マネージャーの管理者は区別されます。管理ロールをユーザーやグループ
に割り当てるにはセキュリティー・マネージャーの管理者の権限が必要です。具体的には、管理コンソー
ルから[ユーザーおよびグループ]→[管理ユーザー・ロール]または[管理グループ・ロール]が、セキュリ
ティー・マネージャーの管理者が操作できる特定の項目になります。1 次管理ユーザーは管理者とセキ
ュリティー・マネージャーの管理者と監査員の 3 つのロールをあわせもったユーザーです。
9-8-1-1 監査員
監査員のロールは、セキュリティー監査の管理を管理セキュリティーやその他のアプリケーション管理
と別個に扱います。 監査員のロールが追加されたことで、監査員の権限を管理者の権限から明確に区
別できるようになりました。監査員のロールを持つユーザーのみ、監査員ユーザー/グループのロールを
変更できます。最初にセキュリティーを有効にする場合、監査員のロールが 1 次管理者に割り当てら
れ、監査員のロールのものも含め、すべての管理ユーザー/グループのロールを管理することができま
す。
監査員のロールを管理者に許可することで、これらの権限を組み合わせることができます。使用状況
によって権限を分ける必要があれば、管理者は自身から監査員のロールを除去し、これを他のユーザ
ーに割り当てることができます。
監査員は、管理者により管理されるパネルの表示は許可されますが、変更は行えません。監査員は、
セキュリティー監査サブシステムに関連したパネルの読み取りと変更に関する全権限を持ちます。管理
者は、これらのパネルのモニター・ロールを持ちますが、これらのパネルを変更することはできません。
9-8-2 稼動ユーザー
デフォルトでは、Linux、UNIX、または z/OS プラットフォーム上の WAS ノードは、それぞれ root ユー
ザーID を使用して、デプロイメント・マネージャー、ノード・エージェント、およびアプリケーション・サーバ
ーの全てのプロセスを実行します。
WAS V8.5 では、非 root ユーザーでインストール、プロファイル作成を行う事が可能です。非 rooｔユー
ザーでプロファイルを作成した場合、そのプロセスについては、その非 root ユーザーであれば、修正プ
ログラムのインストールや起動停止を行う事が出来ます。以前のように Run-Aｓユーザーの設定を特に行
わなくても稼動ユーザーを非 root ユーザーに変更することができます。
- 50 -
ただし、ノード・エージェント・プロセスを root 以外のユーザーID で稼動させる場合は、同じユーザー
ID で、ノード・エージェントが制御する全てのアプリケーション・サーバー・プロセスを実行しなければなり
ません。
また、WAS の稼動ユーザーを root 以外のユーザーID に設定した場合、OS のレジストリーを操作する
権限がないためユーザー・レジストリーとしてローカル OS を選択することはできません。
9-8-3 設定方法
ここでは、WAS の管理ロールおよび稼動ユーザーをデフォルトから変更するための設定方法を紹介
します。管理ロールの割り当ては、ユーザーID、グループともに可能です。グループに管理ロールを割
り当てた場合は、そのグループに所属するユーザーすべてにその管理ロールが割り当てられます。運
用面では、ユーザーよりグループにマッピングする方がより効率的です。
9-8-3-1 管理ロールの設定
管理ロールをユーザーに割り当てる方法を紹介します。管理ロール（監査員ロール以外）を操作でき
るのは、セキュリティー・マネージャーの管理者ロールの権限をもつユーザーまたは 1 次管理ユーザー
です。監査員ロールは、監査員ロールの権限を持つユーザーまたは 1 次管理ユーザーのみ操作できま
す。
管理コンソールの[ユーザーおよびグループ]→[管理ユーザー・ロール]を選択して[追加]ボタンをクリ
ックし、割り当てるロールを選択します(下記例ではコンフィギュレーターを選択）。検索ストリングを入力
してユーザーを検索し、ユーザーを[ロールにマップ済み]リストに追加して[OK]ボタンをクリックします。
マスター構成へ変更を保存します。
- 51 -
ユーザー
WAS V6.1 まではユーザーID をテキストボックスに入力していましたが、WAS V7.0 からユーザ
ー・レジストリーを検索して存在するユーザーを指定する実装に変わっています。
ロール
ユーザーに割り当てるロールを選択します。ロールを複数選択することも可能です。各ロールに
与えられる権限に関しては、前述の通りです。
管理コンソールの[ユーザーおよびグループ]→[管理ユーザー・ロール]を選択し、新規マッピング・ユ
ーザーがコンフィギュレーター・ロールで表示されることを確認します。
グループに管理ロールをマッピングする場合は同様に、管理コンソールの[ユーザーおよびグループ]
→[管理ユーザー・ロール]を選択して[追加]ボタンをクリックします。割り当てるロールを選択し、[特別な
対象からの選択]か[下記の指定どおりにグループをマップする]を選択します。[特別な対象からの選択]
を選択した場合、[認証済みすべて]、[トラステッドレルム内で認証済みすべて]からひとつ選択して[OK]
ボタンをクリックします。 [下記の指定どおりにグループをマップする]を選択した場合、検索ストリングお
よび検索結果の数を入力してグループを検索し、グループを[ロールにマップ済み]リストに追加して
[OK]ボタンをクリックします。マスター構成へ変更を保存します。
特別な対象とは、特定クラスのユーザーを一般化したものです。特別な対象が [認証済みすべて]で
ある場合、管理ロールのアクセス検査によって、要求を出しているユーザーが少なくとも認証済みである
ことを意味します。
- 52 -
9-8-3-2 非 root ユーザーでの稼動設定
WAS を非 root ユーザーで稼動させるための設定方法を紹介します。各プロセスを稼動させる非 root
ユーザーは、事前に作成しているものとします。
非 root ユーザーで稼動させるためには、プロファイルを作成して、非 root ユーザーにオーナー・シッ
プを割り当てる必要があります。
プロファイルを作成します。
プロファイル作成方法については、「第 2 章 インストール・プロファイル作成・サーバー管理・基本設
定」をご参照ください。プロファイルを作成するユーザーは、root ユーザー/非 root ユーザーどちらでも
構いません。
非 root ユーザーでプロファイルを作成した場合、プロファイル管理ツールで、固有の名前およびポー
ト値を提案するメカニズムを使用できませんので注意してください。また、オーナー・シップは、プロファイ
ルを作成した非 root ユーザー とは別の非 root ユーザーに割り当てられます。
1.
2.
プロファイル・ディレクトリーのオーナー・シップを非 root ユーザーに変更します。
chown -R <ユーザー名> <WAS_root>/profiles/<Profile_name>
3.
プロファイルのログ・ディレクトリーのオーナー・シップを非 root ユーザーに変更して、ログ・メッセ
ージがコンソールに表示されないようにします。
chown -R <ユーザー名> <WAS_root>/logs/manageprofiles/<Profile_name>
9-9 Fine-grained 管理セキュリティー
この節では、WAS V6.1 から新機能として実装されている Fine-grained 管理セキュリティーの機能およ
びその設定方法について説明します。
9-9-1 Fine-grained 管理セキュリティーとは
WAS V6.0 までは、管理ロールを付与されたユーザーは、セルの下のすべてのリソース・インスタンス
を管理できました。WAS V6.1 以降では、Fine-grained 管理セキュリティーを使用することによって、リソー
ス・インスタンス単位でユーザーに管理ロールを割り当てることができます。このインスタンス・ベースのセ
キュリティーを実現するには、同じ特権を必要とするリソースを、許可グループと呼ばれるグループに入
れる事が必要です。ユーザーに必要な管理ロールを割り当てることによって、許可グループへのアクセ
ス権を付与できます。リソース・インスタンス単位で管理ロールが付与されると、そのユーザーは許可さ
れた範囲のリソース以外にアクセスすることができません。割り当てることが可能なリソース・インスタンス
は次の 8 つです。
セル
ノードグループ
ノード
クラスター
サーバー
アプリケーション
ビジネス・レベル・アプリケーション
- 53 -
アセット
なお、WAS V7.0 からは、Fine-grained 管理セキュリティーの設定を管理コンソールから行えるように
なりました。設定方法については後述します。
9-9-2 許可グループ
許可グループとは、同じ権限をもつリソースを１つにまとめたものをいいます。この許可グループには
特定の管理ロールをもつユーザーやリソースを追加することが可能です。従来の WAS との相互互換性
のため、セル・レベルの管理権限をもつ許可グループがデフォルトで用意されています。この許可グル
ープに割り当てられたユーザーはセル内のリソースすべてにアクセス可能です。
シングル・サーバー構成では、シングル・サーバー内の各種アプリケーションをグループ化して、さま
ざまな許可グループに入れることができます。この場合、アプリケーションによって異なる許可制約を設
ける事が可能です。ただし、許可グループに追加する事が出来るのは、アプリケーションのみです。シン
グル・サーバー環境では、サーバー自体を許可グループの一部にすることはできないので注意してくだ
さい。
図 9-17はリソース・インスタンス間の包含関係を表しています。1 つのリソース・インスタンスは、1 つ
の許可グループにのみ属します。 ただし、リソース・インスタンス間には包含関係があります。親リソース
が子リソース・インスタンスの許可グループとは異なる許可グループに属している場合、子リソース・イン
スタンスは、暗黙的に複数の許可グループに属すことになります。同じリソース・インスタンスを複数の許
可グループに追加することはできませんので注意して下さい。
図 9-17 リソース・インスタンスの包含関係
例えば、図 9-18のように許可グループが定義されている場合、Adminuser1 がアクセス可能なリソース
は、node1、App-Server1-N1、App-Server2-N1 になります。
許可グループ 1 にはリソースである node1 が属しており、Adminuser1 がマッピングされています。よっ
て、Adminuser1 は node1 にアクセス可能です。App-Server1-N1、App-Server2-N1 は Adminuser1 が属
する許可グループ 1 配下には明確に定義されていません。しかし、ノードとサーバーの関係には包含関
係 が あ る た め 、 Adminuser1 は 親 リ ソ ー ス で あ る node1 の 子 リ ソ ー ス で あ る App-Server1-N1 、
App-Server2-N1 にもアクセスすることが出来ることになります。
- 54 -
図 9-18 許可グループ
9-9-3 管理コンソールによる設定方法
Fine-grained 管理セキュリティーを設定するには、管理コンソールまたは wsadmin コマンド・ツールを
使用します。管理コンソールで設定する際には、セル･レベルで定義された「セキュリティー・マネージャ
ーの管理」権限を持つユーザーか、1 次管理ユーザーでログインする必要があります。
以下に、管理コンソールを使用して、許可グループ authGroup1 を作成してリソースを追加し、作成済
みのユーザーにそのリソースの管理ロールを割り当てる手順を記載します。
1).
2).
セル・レベルの「セキュリティー・マネージャーの管理」権限を持つユーザーか、1 次管理ユーザー
で管理コンソールにログインします。
[セキュリティー]より[管理許可グループ]を選択し、[新規作成]をクリックします。
- 55 -
3).
セル内で固有の管理許可グループ名を[名前]フィールドに入力し、[リソース]セクションから、新し
い管理許可グループでアクセスを制御するリソースを選択します。
4).
黒いテキストで表示されるリソースは、選択できます。グレーで表示されるリソースは、既に異なる管
理許可グループのメンバーのため、新しい管理許可グループに含めることはできません。既に異な
る許可グループのメンバーであるリソースは、リソース名の横にグループの名前が表示されます。
選択が終了したら[OK]をクリックします。
再び[セキュリティー]より[管理許可グループ]を選択し、作成した管理許可グループの画面を開き
ます。
[追加プロパティー]の下から、ロールを割り当てたい単位に応じて[管理グループ・ロール]か[管理
ユーザー・ロール]を選択します。この例では[管理ユーザー・ロール]を選択しています。
5).
6).
[追加．．．]をクリックします。
- 56 -
7).
[ロール]フィールドから、ユーザーに対して付与したいロールを選択します。
[ストリングの検索]フィールドにテキストを入力して[検索]をクリックすると、定義済みユーザーの一覧
が表示されます。ユーザーを選択し(複数選択可能)、矢印をクリックして、[ロールにマップ済み]フィー
ルドにユーザーを追加します。[すべて選択]をクリックして、全ユーザーを選択する事も可能です。ユ
ーザーを追加したら[OK]をクリックします。
8).
構成を保存します。
上記の設定を行うと、Fine-grained 管理セキュリティーを定義されたユーザーは、wsadmin コマンド・ツ
ールを使用してロールに応じた操作を行う事が可能になります。管理コンソールから操作を行えるように
- 57 -
するには、上記の設定に加えてセル･レベルのモニター権限の付与が必要です。その場合には下記の
手順を追加で実施します。
9). 管理コンソールで[ユーザーおよびグループ]→ [管理ユーザー・ロール]を選択し、[追加…]をクリ
ックします。
10). [ロール]フィールドから、[モニター]を選択します。
[ストリングの検索]フィールドにテキストを入力して[検索]をクリックすると、定義済みユーザーの一
覧が表示されます。8)までの手順で作成したユーザーを選択し、矢印をクリックして、[ロールにマッ
プ済み]フィールドにユーザーを追加します。
ユーザーを追加したら[OK]をクリックします。
11). ユーザーに適切な権限が付与されているのを確認し、構成を保存します。
- 58 -
9-9-4 wsadmin による設定方法
wsadmin コマンド・ツールで設定する際には、セル･レベルで定義された「セキュリティー・マネージャ
ーの管理」権限を持つユーザーか、1 次管理ユーザーでコマンドを実行する必要があります。セキュリテ
ィ ー 構 成 を 行 う コ マ ン ド は 、 AuthorizationGroupCommands コ マ ン ド 群 に よ り 提 供 さ れ て い ま す 。
wsadmin コマンド・ツールの基本的な使用方法については、「第 6 章 システム運用」を参照して下さい。
また、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_12
28372315070'
wsadmin>AdminAuthorizations.addResourceToAuthorizationGroup("authGroup1","Node=host1Node01:Ser
ver=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>
例 9-4 スクリプト・ライブラリーを使用した Fine-grained 管理セキュリティーの構成
9-10 JACC
この節では、Ｊava Authorization Contract for Containers(以下、JACC)の機能およびその設定方法に
ついて説明します
9-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 V8.5 Information Center「セキュリティー・アノテーション」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.nd.doc/ae/csec_annot
ations.html
9-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 仕様で必要なポリシー・クラス、ポリシー構成ファクトリー・クラ
ス、およびポリシー構成インターフェースを実装している必要があります。JACC 仕様では、コン
テナーとプロバイダー間の許可テーブル情報の処理方法が指定されていません。その情報を処
- 60 -
理する管理機能の提供は、プロバイダーの責任です。コンテナーがバインディング・ファイルの
許可テーブル情報をプロバイダーに提供する必要はありません。
JACC プロバイダーとして TAM を使用することにより、さまざまなメリットを享受できます。例えば、TAM
を使用すれば、パスワードに使用する文字の種類や長さ、有効期限などといったポリシーを設定するこ
とができます。そういった設定内容の変更は WAS を再起動することなく、動的に反映することができま
す。
WAS に同梱されている TAM には、ソフトウェア製品版としての TAM のコンポーネントの一部分が含
まれており、JACC プロバイダーとしての使用のみがサポートされています。TAM を JACC プロバイダー
以外の目的で使用する場合は、別途 TAM ソフトウェア製品版のライセンス証書を取得する必要がありま
す。
9-10-3 設定方法
ここでは、WAS で JACC プロバイダーを構成するための設定方法を紹介します。図 9-19は、JACC プ
ロバイダーを構成する手順全体の流れを表しています。
図 9-19 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 V8.5 Information Center「外部の Java Authorization Contract for Containers プロバイダーの設
定」
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.nd.doc/ae/usec_extern
aljacc.html
- 63 -
3). Tivoli Access Manager プロパティー
[追加プロパティー]の[Tivoli Access Manager プロパティー]を開きます。[組み込み Tivoli Access
Manager を使用可能にする]にチェックを入れ、TAM と WAS の各値を正しく設定して[OK]をクリックしま
す。
- 64 -
組み込み Tivoli Access Manager を使用可能にする
組み込み Tivoli Access Manager 構成を使用可能または使用不可にします。
組み込み Tivoli Access Manager 使用不可時のエラーを無視
これを選択すると、組み込み Tivoli Access Manager を使用不可にしている間は、エラーは無視
されます。このオプションは、組み込み Tivoli Access Manager を再構成する場合、または組み込
み 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 -
9-10 Java 2 セキュリティー
この節では、Java 2 セキュリティーについて説明します。
9-10-1 Java 2 セキュリティーとは
Java 2 セキュリティーでは、ポリシー・ベースの精密なアクセス制御メカニズムが提供されます。このメ
カニズムにより、保護された特定のシステム・リソースへのアクセスには、必ずアクセス権の検査が行われ
るため、システム全体の保全性が高まります。Java 2 セキュリティーは、ファイル入出力、ソケット、およ
びプロパティーなどのシステム・リソースへのアクセスを保護します。
アプリケーションが Java 2 セキュリティーに対応していない場合、管理者は Java 2 セキュリティーを使
用することによって起こりうる問題を事前に把握しておかなければなりません。
9-10-2 Java 2 セキュリティー・ポリシー・ファイル
Java プロセス用のセキュリティー・ポリシーを定義するために、IBM JDK によっていくつかの静的ポリ
シー・ファイルが提供されています。また、WAS は、エンタープライズ・アプリケーションのリソースおよび
ライブラリーに関する動的ポリシーをサポートしています。アクセスの許可は、アプリケーション実行時に
ポリシー・ファイルに基づいて判断されます。
JDK によって提供されるポリシー・ツールを使用することで、ポリシー・ファイルを編集することができま
す。セル構成の場合は、編集前にポリシー・ファイルをリポジトリーから抽出する必要があります。ポリシ
ー・ファイルの抽出後はポリシー・ツールを使用してファイルを編集し、変更したポリシー・ファイルをリポ
ジトリーに入れてから他のノードと同期させる必要があります。ポリシー・ファイルに構文エラーがあると、
エンタープライズ・アプリケーションまたはサーバー・プロセスが始動に失敗する可能性がありますので、
これらのポリシー・ファイルを編集する際は注意が必要です。
9-10-3 静的ポリシー・ファイル
WAS でサポートされているポリシー・ファイルのタイプには静的ポリシー・ファイルと動的ポリシー・ファ
イルの 2 種類があります。それらのうち、静的ポリシー・ファイルは、デフォルト・アクセス権を提供します。
静的ポリシー・ファイルは、リポジトリーおよびファイル複製サービスによって管理される構成ファイルで
はありません。このファイルへの変更はローカルであり、他のマシンに複製されることはありません。
静的ポリシー・ファイルには、以下の種類のファイルがあります。
java.policy （<WAS_root>/java/jre/lib/security/java.policy）
全てのクラスに付与されるデフォルトの許可です。このファイルのポリシーは、WAS によって起動
される全てのプロセスに適用されます。
server.policy （<Profile_root>/properties/server.policy）
製品の全てのサーバーに付与されるデフォルトの許可です。
client.policy （<Profile_root>/properties/client.policy）
ノード上の全ての製品クライアント・コンテナーおよびアプレットに対するデフォルトの許可です。
- 66 -
9-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 ファイルに組み込まれています。
9-11 JAAS
この節では、WAS が以前のバージョンより引き続きサポートしている JAAS について説明します。
9-11-1 JAAS とは
JAAS は、Java 2 プラットフォームの Java 2 セキュリティー・アーキテクチャーを拡張したもので、プリ
ンシパルとユーザーによるアクセス制御の実施がサポートされます。 JAAS は、プラグ可能認証モジュ
ール (PAM) 標準フレームワークの Java バージョンを実装し、Java 2 プラットフォームのアクセス制御
アーキテクチャーを拡張します。WAS は、JAAS アーキテクチャーを完全にサポートします。JAAS は、
アクセス制御アーキテクチャーを拡張して、サーブレット、JSP、および EJB コンポーネントを含む J2EE リ
ソースのロール・ベースの許可をサポートします。
- 67 -
9-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 アクションの正しい振る舞いを保証できる、信頼性が高くてランタイム
効率のよい方法はありません。
WAS では WSSubject helper クラスにより、 前述のような J2EE EJB メソッド呼び出しに対する
JAAS 許可を拡張しています。WSSubject クラスは静的 doAs および doAsPrivileged メソッドを提供
し、これらは subject クラスと同じシグニチャーを持ちます。WSSubject.doAs メソッドはサブジェクトを現
在 実 行 さ れ て い る ス レ ッ ド に 関 連 付 け ま す 。 そ し て 、 WSSubject.doAs お よ び
WSSubject.doAsPrivileged メソッドは、対応する Subject.doAs および Subject.doAsPrivileged メソッド
を呼び出します。WSSubject.doAs および WSSubject.doAsPrivileged メソッドの終了時には、オリジナ
ルのクレデンシャルが復元され、実行スレッドに関連付けられます。
WSSubject クラスは Subject オブジェクトの代わりではなく、EJB メ ソッドの呼び出しに関する限り、
一貫性のあるランタイム動作を保証するための helper クラスです。
- 68 -
9-12 JASPI
この節では、Java Authentication SPI for Containers （JASPI）について説明します。
9-12-1 JASPI プロバイダーによる認証
WAS V8.0 からは JSR 196: JASPI（JASPIC と呼ばれることもあります) 仕様をサポートします。これに
より、Web アプリケーションに向けられた HTTP 要求メッセージおよび応答メッセージの Java EE 認証
をサード・パーティーのセキュリティー・プロバイダーが処理できます。JASPI 仕様は、JAAS のプラグ可
能認証の概念を HTTP 要求メッセージおよび応答メッセージの認証に拡張します。アプリケーション・
セキュリティーが使用可能な状態で、保護されている Web リソースがアクセスされた場合は、Web コン
テナーとセキュリティー・ランタイムは共同して呼び出し元の認証の決定を行います。サード・パーティー
の JASPI プロバイダーを使用する場合、認証の決定はそのプロバイダーが代行します。
JASPI 認証を使用したアプリケーション・セキュリティーが使用可能である場合、サーブレットや
JavaServer Pages (JSP) ファイルなどの Web リソースがアクセスされると、セキュリティー・ランタイムは、
セキュリティー構成に定義されている JASPI プロバイダーに Web リソースがマップされているかどうか
を検査します。マップされている場合、ランタイムは JASPI 認証プロバイダーを呼び出して、HTTP 要
求メッセージおよび応答メッセージの認証を実行します。
- 69 -