セキュリティー設計 1 WASV7.0によるWebシステム基盤設計Workshop

WASV7.0によるWebシステム基盤設計Workshop
セキュリティー設計
1
当セッションの目的
„
WASセキュリティー設計に必要な知識の習得
‹
WASを使用したシステムにおいて、以下のセキュリティー対策毎の
設計手法を理解する
¾
¾
¾
¾
¾
ハードニング
認証
認可
暗号化 / 署名
監査
2
2
Agenda
1. はじめに
2. WASセキュリティー設計
2-1 ハードニング
2-2 認証
2-3 認可
2-4 暗号化 / 署名
2-5 監査
まとめ・参考文献
3
1章では、セキュリティー要件の検討方法とWebシステムにおける脅威と対策についてご説明致しま
す。2章では、Webシステムにおける脅威と対策毎に、WASを使用したシステムでの対応項目につい
てご説明致します。
3
1. はじめに
4
1章では、セキュリティー要件の検討方法とWebシステムにおける脅威と対策についてご説明致しま
す。
4
はじめに、
„
セキュリティー要件の検討
守るべき保護対象リソースを決定する
保護対象リソースに対する脅威を洗い出す
脅威に対抗する手段を検討し、実装する
‹
‹
‹
„
セキュリティー対策
・ハードニング
・ハードニング
・認証
・認証
・認可
・認可
・暗号化
・暗号化 // 署名
署名
必要な機能以外は停止、遮断する
必要な機能以外は停止、遮断する
利用者が正当なユーザーであることを確認する
利用者が正当なユーザーであることを確認する
保護対象リソースに対して適切なアクセス権限を付与する
保護対象リソースに対して適切なアクセス権限を付与する
通信経路等の暗号化をおこなうことにより保護対象リソースの盗聴を防ぐ
通信経路等の暗号化をおこなうことにより保護対象リソースの盗聴を防ぐ
デジタル署名等により保護対象リソース(データ)の改ざんを防ぐ
デジタル署名等により保護対象リソース(データ)の改ざんを防ぐ
保護対象リソースに対して、いつ、誰が、何をしたのかを確認する
保護対象リソースに対して、いつ、誰が、何をしたのかを確認する
・監査
・監査
セキュリティー追加費用増加分
費用
セキュリティー事件発生による追加費用
追加対策のために必要とな
る継続的運用費用
セキュリティーを、インフラ設計の
一部として組み込むことが重要
セキュリティーに配慮しないで構築したシステム
セキュリティーに配慮して構築したシステム
設計 構築
5
運用
セキュリティー要件は以下を検討する必要があります。
・守るべき保護対象リソースを決定する
・保護対象リソースに対する脅威を洗い出す
・脅威に対抗する手段を検討し、実装する
また、セキュリティーをインフラ設計の一部として組み込むことが重要です。
5
Webシステムにおける脅威と対策
脅威
対策
WAS設計
サービス妨害
セキュリティーホール悪用
ハードニング
ゾーニング
コンポーネントの制限
非rootユーザー稼動
IHSセキュリティー対策
なりすまし
認証
グローバル・セキュリティー
複数セキュリティー・ドメイン
シングルサインオン (SSO)
不正アクセス
認可
管理ロール
Fine-grained管理セキュリティー
情報の盗聴
情報の改竄
不正コードの埋め込み
暗号化 / 署名
SSL
証明書
否認
監査
セキュリティー監査
„
„
セキュリティー強化 ≠ ユーザーの利便性向上
セキュリティー強化 ≠ パフォーマンス向上
6
上表は、Webシステムにおける代表的な脅威と対策、WASを使用したシステムでの対応項目につい
てまとめています。
2章では、この表の順番で、WASが提供しているセキュリティーを強化する様々な機能や対策につい
てご説明致します。
また、ここでご注意頂きたいのですが、必ずしも全ての機能や対策を設定する必要はありません。セ
キュリティーを強化すると、その反面、ユーザーの利便性やパフォーマンスが低下してしまいます。
従いまして、事前に保護対象や保護対象に対する脅威を明確にし、利便性やパフォーマンスを考
慮した上で、必要最小限のセキュリティー設定を行うことを意識して下さい。
6
セキュリティー関連情報
„
セキュリティー・ホールは事前に全てを見つけられないので、日々の運用
の中で、下記の対策を実施して下さい
インターネット・サイトの運営にあたり
セキュリティー対策は必須です
„
対策1：情報収集
‹
各製品に関連するセキュリティー関連の情報や、セキュリティー対策を施した
Fixが提供されているかを確認する
<重要セキュリティー情報サイト>
http://www-06.ibm.com/ibm/jp/security/info/
<WebSphere関連>
http://www-06.ibm.com/jp/services/security/websphere.html
„
対策2：セキュリティー・Fixの適用
‹
セキュリティー・ホールへの対応策、もしくはFixが提供された場合は速やか
に適用する
7
インターネットに公開されるサーバーは、前項の対策では対応できないセキュリティーの脆弱性が発
見される場合があります。公開されている情報の収集と、セキュリティー・Fixの適用を行って下さい。
7
WebSphereセキュリティーを支える技術
階層化セキュリティー・アーキテクチャー
オープン・アーキテクチャー・パラダイム
Java 2 セキュリティーは、 「セキュリティー設計-参考」のP.3をご参照下さい。
JACCは、「セキュリティー設計-参考」のP.4をご参照下さい。
JAASは、「セキュリティー設計-参考」のP.5をご参照下さい。
8
WebSphereセキュリティーは、上左図の階層化セキュリティー・アーキテクチャー上に構築されます。
WASリソースに対して、WASセキュリティー、Javaセキュリティー、プラットフォーム・セキュリティーを設
定致します。
WASはオープン・アーキテクチャー・パラダイム（ハードウエアやソフトウエアの仕様が第三者に公開
されている）を採用し、エンタープライズ・ソフトウェア・コンポーネントと統合するプラグイン・ポイントを
多数提供します。(上右図の水色の背景は、 WAS V7.0と他のビジネス・アプリケーション・コンポー
ネントとの境界を示します。)
例えば、トラスト・アソシエーションは、WASとサード・パーティー製セキュリティー・サーバーとを統合
する場合には設定します。ユーザー・レジストリーは、カスタム・レジストリーおよびユーザー・アカウ
ント・リポジトリーのフェデレーテッド・リポジトリー・オプションの両方の実装に使用されます。
8
2. WASセキュリティー設計
2-1
2-2
2-3
2-4
2-5
ハードニング
認証
認可
暗号化 / 署名
監査
ハードニングとは、必要な機能以外は停止、遮断する
9
2章では、Webシステムにおける脅威と対策毎に、WASを使用したシステムでの対応項目についてご
説明致します。はじめに、必要な機能以外は停止、遮断するハードニングについてご説明致します。
9
ゾーニング設計
„
ゾーニングとは
‹
„
サーバーやネットワーク機器などのノードを、セキュリティーレベルに応じて
分割する
ゾーンの分離
‹
Load Balancer、Webサーバー、Proxy Server (Secure Proxy Server)の配置
¾
¾
¾
‹
外部からの不正なアクセスを遮断する
内部ネットワークのマシンを、直接的な攻撃対象とさせない
内部ネットワークのIPアドレスなどの情報を隠蔽させる
SSL通信の解除
¾
¾
前段で解除した方がパフォーマンスが良い
後段で解除した方がセキュリティーが向上する
Uncontrolledゾーン
Controlledゾーン(非武装地帯)
Secure Proxy
Server
Restrictedゾーン
Securedゾーン
Web Server
Application Server
負荷分散装置
Internet
Client
10
Proxy Server
必要な機能以外は遮断する方法として、ゾーニングがあります。
ゾーニングでは、WASに直接アクセスされることを防ぐため、前段のWebサーバーやLoad Balancer
でネットワークを分けています。ゾーンを分離することで、外部からの不正なアクセスを遮断でき、内
部ネットワークのマシンが直接的な攻撃対象とならず、内部ネットワークのIPアドレスなどの情報が隠
蔽することが出来ます。
また、ゾーニングを分けた場合に、SSLをどこで解除するのか検討する必要があります。なるべく前段
で解除すればパフォーマンスは良くなりますが、セキュリティーは低下しますので、要件に合わせた
解除ポイントを検討して下さい。
10
ゾーニング設計
„
～ファイアウォール設定
設計指針
‹
必要なポート以外はオープンしない
ホスト
デフォルト・
ポート(TCP)
向き
ホスト
デフォルト・
ポート(TCP)
備考
Web Server
*
→
App Server
9080
アプリケーション・サーバーのリ
クエスト受付ポート（HTTP）
Web Server
*
→
App Server
9443
アプリケーション・サーバーのリ
クエスト受付ポート（SSL）
Web Server
(IHS only)
8008
←
Deployment
Manager
(管理ｻｰﾊﾞｰ)
*
IHS管理サーバーのポート。
リモートWebサーバーがIHSの
場合、Webサーバー管理のため。
Web Server
80
←
Deployment
Manager
(管理ｻｰﾊﾞｰ)
*
WebサーバーのListenポート。
管理サーバーが、Webサーバー
の稼動状況確認のため。
WASやIHSのListenポートを変更してい
WASやIHSのListenポートを変更してい
る場合には、適宜変更する
る場合には、適宜変更する
Web Server
App Server
Deployment
Manager
11
外部からの不正なアクセスを遮断する方法として、ファイアウォールがあります。
IHS-アプリケーション・サーバー間では、リクエスト受付ポートを空けて必要があります。また、IHSを
管理コンソールで管理する場合には、IHS管理サーバーやIHSのListenポートを空けておく必要があ
ります。
要件により空けておくべきポート番号、向き、ホスト名が異なりますので、事前に十分に確認すること
が重要です。
11
コンポーネントの制限
„
アプリケーション
‹
セキュリティー上好ましくないデフォルトアプリケーションを削除する
‹
セキュリティー上好ましくないサンプルアプリケーションを導入しない
¾
¾
„
Snoopサーブレット、HitCountアプリケーション等
キャッシュ・モニターアプリケーション等
ポート番号
‹
デフォルトのポート番号は、限定的で特定しやすいため、変更する
¾
変更例：WC_defaulthost
9080 →19080
12
必要な機能以外を停止する方法として、コンポーネントの制限があります。
WASではいくつかのサンプル・アプリケーションが提供されており、インストール時等に導入すること
ができます。サンプル・アプリケーションの中にはWASの構成情報やネットワーク通信情報を表示す
るなどといったセキュリティー上好ましくないアプリケーションも含まれています。このアプリケーション
は稼動確認などのために使用されますが、不要になった段階で削除することを検討して下さい。
また、デフォルトのポート番号は限定的で特定しやすいため、WASが使用するポート番号を変更す
ることをご検討下さい。
12
非rootユーザー稼動
„
目的
‹
‹
„
クライアントから直接アクセスされるWebサーバー、Webアプリケーション・サー
バーをrootで稼動させた場合、セキュリティー低下につながる
侵入されてしまった場合の被害を最小限にする
IHS / WASともに非rootでの稼動が可能
‹
IHSは、1024番以降のポート番号とする必要がある
¾
‹
‹
AIX V6.1の新機能である拡張RBAC(Role Based Access Control)機能を使用すると、80番ポー
トを使用してIHSを非rootで稼動させることが可能
IHSをWASとは異なる非rootユーザーで稼動し、かつ管理コンソールから起動/
停止/構成管理を行う場合は、IHS管理サーバー経由とする必要がある
非rootユーザーによる製品インストール、CIM、Fixpackの適用も可能
<WASの場合>
<WASの場合>
非rootユーザーで起動･停止を行うJVMを含むプロファイル･ディレクトリー、プロ
非rootユーザーで起動･停止を行うJVMを含むプロファイル･ディレクトリー、プロ
ファイル･ログ･ディレクトリーのオーナーを変更
ファイル･ログ･ディレクトリーのオーナーを変更
<IHSの場合>
<IHSの場合>
IHSインストール･ディレクトリーのオーナーを変更
IHSインストール･ディレクトリーのオーナーを変更
httpd.confのListenディレクティブで指定するポート番号を1024以降に変更
httpd.confのListenディレクティブで指定するポート番号を1024以降に変更
<IHS管理サーバーの場合>
<IHS管理サーバーの場合>
IHSインストール･ディレクトリーのオーナーを変更
IHSインストール･ディレクトリーのオーナーを変更
admin.confのUser、Groupディレクティブに非rootユーザーを指定
admin.confのUser、Groupディレクティブに非rootユーザーを指定
非rootユーザーにて、htpasswdコマンドを使用し、IHS管理サーバー内で使用す
非rootユーザーにて、htpasswdコマンドを使用し、IHS管理サーバー内で使用す
るユーザーを作成
るユーザーを作成
httpd.confのListenディレクティブで指定するポート番号を1024以降に変更する
httpd.confのListenディレクティブで指定するポート番号を1024以降に変更する
## su
su –– wasadmin
wasadmin
$$ <WAS_PROFILE_ROOT>/bin/startNode.sh
<WAS_PROFILE_ROOT>/bin/startNode.sh
wasadmin
11 11 17:09:17
wasadmin 708764
708764
17:09:17 pts/0
pts/0 0:29
0:29
/usr/IBM/WebSphere/AppServer/java/bin/java
/usr/IBM/WebSphere/AppServer/java/bin/java <中略>
<中略>
nodeagent
nodeagent
#su
#su –– ihsadmin
ihsadmin
$$ /usr/IBM/HTTPServer/bin/apachectl
/usr/IBM/HTTPServer/bin/apachectl –k
–k start
start
ihsadmin
11 00 17:21:20
-- 0:00
ihsadmin 540884
540884
17:21:20
0:00
/usr/IBM/HTTPServer/bin/httpd
-d
/usr/IBM/HTTPServer/bin/httpd -d
/usr/IBM/HTTPServer
/usr/IBM/HTTPServer -k
-k start
start
13
Webクライアントから直接アクセスされるアプリケーション・サーバー・プロセスをrootユーザーで稼動
させることはセキュリティー低下につながってしまいます。侵入されてしまった場合の被害を最小限
にしたい場合には、専用のプロセス起動ユーザーを用意し、必要最低限の権限のユーザーで起動
することを検討して下さい。
IHS、WASともに非rootユーザーでの稼動が可能です。
WASV7.0 InformationCenter - 「非 root インストール」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.insta
llation.nd.doc/info/ae/ae/cins_nonroot.html
IBM HTTP Server V7.0 InformationCenter - 「Installing IBM HTTP Server with a nonadministrator user ID」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.ihs.d
oc/info/ihs/ihs/tihs_nonrootinstall.html
WASを非rootで稼動させている環境で、Fix Pack/Fixをrootで適用した場合、ディレクトリやファイル
のパーミッションがrootによって変更されてしまう可能性がありますので、ご注意下さい。その場合は、
Fix Pack/Fix適用後にパーミッションを手動で戻す必要があります。
・WAS ND V6.0/V6.1 非ルート・ユーザーによる起動について (WAS-08-001)
http://www-06.ibm.com/jp/domino01/mkt/cnpages1.nsf/page/default-000498B5
13
IHSのセキュリティー対策 ～バージョン情報の隠蔽
„
目的
‹
„
設定方法
‹
„
HTTPレスポンスヘッダーやエラー画面のフッターにIHSのバージョン情報が
表示され、悪意のあるユーザーからセキュリティーホールを狙われてしまう可
能性がある
httpd.confの編集
ServerTokens Prod(uctOnly)
ServerSignature Off
バージョン差異による考慮事項
‹
‹
HTTPレスポンスヘッダーに関する設定で
「Prod」でも「ProductOnly」でもOK
サーバーが生成するドキュメント（エラー
画面など）のフッターに関する設定
IHS V6.0以降（Apache2.0.44以降） ServerTokensを「Prod」に設定
それより前のバージョンの場合 ServerTokensとServerSignatureを設定
＜上記の設定になっていない場合＞
satsuki:~ # telnet 123.456.789.123 80
Connected to 123.1456.789.123.
・・・・・
<address>IBM_HTTP_Server/7.0.0.0 (Win32) at
hogehoge.japan.ibm.com Port 80</address>
</body></html>
Connection closed by foreign host.
＜上記の設定の場合＞
satsuki:~ # telnet 123.456.789.123 80
Connected to 123.456.789.123.
・・・・・
<address>IBM_HTTP_Server at
hogehoge.japan.ibm.com Port 80</address>
</body></html>
Connection closed by foreign host.
14
IHSの設定によっては、クライアントに返すHTTPレスポンスヘッダーやIHSで生成するエラー画面の
ようなドキュメントに製品のバージョン情報を表示してしまいます。それにより、悪意のあるユーザー
からバージョン毎のセキュリティーホールを狙われてしまう可能性があります。また、クライアントには
不要な情報を公開しないようにすることが望ましいです。これを防ぐために、バージョン情報を表示し
ない設定を行うことをご検討下さい。
設定方法は、構成ファイルhttpd.confのServerTokensディレクティブとServerSignatureディレクティブ
で行います。ServerTokensディレクティブはHTTPレスポンスヘッダーに関する設定であり、「Prod」あ
るいは「Product」という値を設定することにより、HTTPレスポンスヘッダーにバージョン情報を含まな
いようになります。ServerSignatureディレクティブはサーバーが生成するドキュメントのフッターに関
する設定であり、「Off」という値を設定することにより、ドキュメントのフッターにバージョン情報を含ま
ないようになります。
また、IHSのバージョンによって設定方法が異なります。IHSV6.0以降（Apache2.0.44以降）では、
ServerTokensディレクティブはServerSignatureディレクティブで表示される情報も制御できるように
なったため、ServerTokensが「Prod」あるいは「Product」に設定されていれば、ServerSignatureがOn
であっても、ドキュメントのフッターにもバージョン情報が表示されなくなります。IHSV7では、デフォ
ルトでこの設定（ServerTokensがProd、 ServerSignatureがOn）になっていますので、 HTTPレスポン
スヘッダーにもエラー画面のフッターにもバージョン情報は表示されません。IHSV6.0より前のバー
ジョンでは、 ServerTokensディレクティブとServerSignatureディレクティブの両方を設定する必要が
あります。
14
IHSのセキュリティー対策 ～TRACEメソッドの無効化
„
目的
‹
‹
„
設定方法
‹
„
クライアントが送信したリクエストメッセージをそのまま返す機能である
TRACEメソッドが有効になっていると、悪意のあるユーザーが、別ユーザー
のブラウザーにてこのTRACEメソッドを発行するように仕向けてそのレスポン
スの中のパスワードを奪うという Cross Site Tracing と呼ばれる攻撃を受け
る可能性がある
httpd.confの編集
TraceEnable Off
バージョン差異による考慮事項
‹
‹
IHS V7.0（Apache2.0.55以降）
それより前のバージョンの場合
上記設定で無効化できる
以下のように定義する必要あり
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* - [F]
＜上記の設定になっていない場合＞
satsuki:~ # telnet 123.456.789.123 80
Connected to 123.456.789.123.
OPTIONS / HTTP/1.0
・・・・・
Server: IBM_HTTP_Server
Allow: GET,HEAD,POST,OPTIONS,TRACE
＜上記の設定の場合＞
satsuki:~ # telnet 123.456.789.123 80
Connected to 123.456.789.123.
OPTIONS / HTTP/1.0
・・・・・
Server: IBM_HTTP_Server
Allow: GET,HEAD,POST,OPTIONS
15
TRACEメソッドとは、クライアントが送信したリクエストメッセージをそのまま返す機能です。TRACEメ
ソッドが有効になっている場合、悪意のあるユーザーが別ユーザーのブラウザーがこのTRACEメソッ
ドを発行するように仕向けて、そのレスポンスの中のパスワードを奪うという Cross Site Tracing と呼
ばれる攻撃を受ける可能性があります。これを防ぐために、TRACEメソッドを無効にする設定を行う
ことをご検討下さい。
設定方法は、構成ファイルhttpd.confのTraceEnableディレクティブで行います。 TraceEnableディレ
クティブに「Off」という値を設定することにより、 TRACEメソッドが無効になります。
また、IHSのバージョンによって設定方法が異なります。IHSV7 （Apache2.0.55以降）では、上記に記
載したTraceEnableディレクティブで設定することができます。それより前のバージョンでは、
TraceEnableディレクティブを使用することができませんので、代わりにRewriteEngineを使用します。
デフォルトではrewrite_moduleはロードされませんので、コメントアウト（#）を外してロードした上で
RewriteEngineの設定を行います。
15
2. WASセキュリティー設計
2-1
2-2
2-3
2-4
2-5
ハードニング
認証
認可
暗号化 / 署名
監査
認証とは、利用者が正当なユーザーであることを確認する
16
続きまして、利用者が正当なユーザーであることを確認する認証についてご説明致します。
16
認証
„
アクセス管理 = 認証 ＋ 認可
„
認証(authentication)
‹
利用者の本人性を特定すること
¾
¾
¾
„
知っていること
持っていること
生体個別の特徴を有すること
ユーザーIDやパスワードなど
IDカード、電子証明書など
指紋など（WASでは直接扱いません）
WASで認証を行うためには、グローバル・セキュリティーの設定が必要
17
アクセス管理は、認証と認可から構成されます。はじめに、認証についてご説明致します。
認証とは、利用者の本人性を確認する作業です。確認の手段はIDとパスワードのような「知っている
こと」、IDカードのような「持っていること」、指紋のような「生体固有の特徴を有すること」の3つに大き
く分類できます。セキュリティーの要件に応じた方式を選択、またはそれの組み合わせを採用するこ
とになります。
WASで認証を行うためには、グローバル・セキュリティーを設定する必要があります。以降で、グロー
バルセキュリティーについてご説明致します。
(補足)
WASセキュリティーにおける認証は、Java EEのセキュリティー・モデルに基づいて行われます。
Sun Developer Network (SDN) - Java EE 「Do more with less work.」
http://java.sun.com/javaee/index.jsp
17
グローバル・セキュリティー
„
WAS自体および連携する他のコンポーネントを含むシステムの一部を保
護された状態(認証、認可、暗号化の実施など)にする機能
‹
‹
‹
„
WAS V6.1から管理セキュリティーとアプリケーション・セキュリティーが分離
管理セキュリティーのみの設定が可能
ジョブ・マネージャー、管理エージェントに対しても設定が可能
管理セキュリティー
‹
WASシステムに対する管理全般に対して、認証・認可を設定する
¾
‹
„
（例）管理コンソール、管理コマンド等
プロファイル作成時のデフォルトはON、プロファイル作成後でも変更可能
アプリケーション・セキュリティー
‹
WAS上のアプリケーション・リソースに対して、認証・認可を設定する
‹
前提：管理セキュリティーを有効にする
¾
（例）アプリケーション利用ユーザーに認証を求める
18
グローバル・セキュリティーの設定方法は、「セキュリティー設計-参考-」のP.7をご参照下さい。
グローバル・セキュリティーは、WASセキュリティーの基盤機能になります。グローバル・セキュリ
ティーを有効にすることにより、WAS自体だけではなくWASと通信をおこなうプラグインやWAS上で
稼働するアプリケーションといった連携するコンポーネントを含むシステムの一部を保護された状態
にすることができます。
このグローバル・セキュリティーは、WAS V6.1より管理セキュリティーとアプリケーション・セキュリ
ティーに分離されました。管理セキュリティーはWASシステムに対する管理全般を保護対象とするの
に対し、アプリケーション・セキュリティーはWAS上で稼働するアプリケーション・リソースが保護対象
となります。管理セキュリティーのみを設定することも可能です。また、WAS V7.0の新機能であるジョ
ブ・マネージャー、管理エージェントに対してもグローバル・セキュリティーを設定することが可能で
す。
グローバル・セキュリティーの設定方法は、参考資料をご確認下さい。プロファイル作成後にグロー
バル・セキュリティーを設定する場合は、管理コンソールからセキュリティー構成ウィザードを使用す
ることで簡単に設定することができます。
18
管理セキュリティー
„
WASシステムの管理をセキュアーにする機能
‹
„
特徴
‹
‹
‹
‹
„
WASのシステムの管理を行うユーザーを制限したい場合に設定する
WAS管理のみセキュアーにできる
ウィザードにより簡単に構成できる
WAS導入時に簡単に構成できる
統合リポジトリーの使用により、簡単にユーザ・レジストリーを構築できる
管理セキュリティーをONに設定すると、
‹
‹
LTPAを使用して認証を行う
コンポーネント間の通信が自動的にSSL化される
¾
¾
‹
WAS間(DM,NA,APP)の通信、管理ツールからのアクセスがSSLとなる
Plug-in（IHS等）、WAS間の通信は、自動的にSSL通信とはならない
管理コンソールログイン時、wsadminコマンド実行時、WAS停止時にユーザー
19
IDとパスワードが必要
管理セキュリティーはWASの管理をセキュアーにするための機能です。管理セキュリティーが設定さ
れるとWAS管理ツールを使用するのにユーザー認証が必要となります。管理セキュリティーは、アプ
リケーション・セキュリティーやJava 2 セキュリティーのベース機能となっています。
管理セキュリティーには以下の様な特徴があります。
・統合リポジトリーを使用することによって、LDAPサーバーがなくてもユーザー・リポジトリーを簡単に
作成することが可能
・アプリケーション・セキュリティーと分離されたため、WASの管理のみをセキュアーにすることが可能
（ただし、アプリケーション・セキュリティーを使用する場合には管理セキュリティーを設定する必要が
あります。）
・セキュリティー構成ウィザードを使用することにより、最低限の情報を順番に入力するだけで簡単に
設定することが可能
・セキュリティー構成報告書により、現在のセキュリティー設定情報を一覧として表示することが可能
・WAS導入時に管理セキュリティーの設定が可能になり、初めからセキュアーな環境を構築可能
・統合リポジトリーの使用により、LDAPサーバーが必須ではない
管理セキュリティーをONにすると、以下の様な状態になります。
・LTPAを使用して認証を行う
・コンポーネント間の通信が自動的にSSL化される
同一セル内のWAS（デプロイメント・マネージャー、ノード・エージェント、アプリケーション・サー
バー）間の通信がSSL化されます。
管理コンソールからのアクセスがSSL化されます。ログイン画面のアクセス先は変わりませんが、自動
的にhttpsへリダイレクトされます。管理コンソールとWASの間にFireWall等が存在している場合は、
管理セキュア・ポート（https：デフォルトでは9043）へアクセスできるように設定する必要があります。
・管理操作の実行にユーザー認証が実施される
19
wsadminコマンド / WAS停止コマンドの実行
„
管理セキュリティーを設定すると、wsadminコマンド実行時、WAS停止コ
マンド実行時にユーザー認証が必要となる
stopNode –username xxxx –password xxxx
ユーザーIDとパスワードを指定しな
ユーザーIDとパスワードを指定しな
いと入力用プロンプトが表示される
いと入力用プロンプトが表示される
„
wsadminコマンド / WAS停止コマンド実行の自動化
‹
soap.client.propsファイルを編集
¾
com.ibm.SOAP.securityEnabled=true
com.ibm.SOAP.securityEnabled=true
com.ibm.SOAP.loginUserid=xxxx
com.ibm.SOAP.loginUserid=xxxx
com.ibm.SOAP.loginPassword=xxxx
com.ibm.SOAP.loginPassword=xxxx
実行時プロンプトの制御
z
自動実行時にユーザー入力用のプロンプトを表示させたくない場合に設定する
com.ibm.SOAP.loginSource=none
com.ibm.SOAP.loginSource=none
¾
パスワードの暗号化
z
パスワードを設定後、PropFilePasswordEncoderコマンドを実行する
PropFilePasswordEncoder
PropFilePasswordEncoder <WAS_PROFILE_ROOT>/properties/soap.client.props
<WAS_PROFILE_ROOT>/properties/soap.client.props
com.ibm.SOAP.loginPassword
com.ibm.SOAP.loginPassword
20
管理セキュリティーをONにすると、wsadminコマンド実行時とWAS（デプロイメント・マネージャー、
ノード・エージェント、アプリケーション・サーバー）停止時に、管理セキュリティー用のユーザーIDと
パスワードが必要になります。ユーザーIDとパスワード入力用のプロンプトが表示され、その段階で
コマンドの実行が進まなくなります。実行時にこのプロンプトを表示させたくない場合は、コマンドの
引数にユーザーIDとパスワードを指定して下さい。
>wsadmin -conntype SOAP -user ユーザーID -password パスワード
WAS停止コマンド(DM、AppServer停止コマンドも同様)
>stopNode –username ユーザーID –password パスワード
ユーザーIDとパスワードをあらかじめセキュリティー用プロパティーに設定しておくことにより実行時
にユーザーIDとパスワードを指定しなくてもよくなります。ただし、この状態では誰でも実行できてしま
うので、アクセスできる端末を限定する等、別途セキュリティーを考慮する必要があります。上記スラ
イド部分のように、各プロファイルの以下のプロパティ・ファイルを編集します。
実行時にユーザーID入力用プロンプトを表示させたくない場合は、loginSourceの項目を変更します。
wsadminコマンドがSOAP接続の場合はnoneを、RMI接続の場合はpropertiesを指定します。
プロパティー・ファイルへのパスワード設定は、テキストデータのまま稼動可能です。プロパティー・
ファイルにテキストデータでパスワードを設定後、そのファイルに対してPropFilePasswordEncoderコ
マンドを実行します。コマンドは、<WAS_ROOT>/binディレクトリにあります。一度パスワードの暗号
化を実施すると、パスワードを元に戻す（復号）事はできません。必ずパスワードは忘れないようにし
て下さい。
> PropFilePasswordEncoder <WAS_PROFILE_ROOT>/properties/soap.client.props
com.ibm.SOAP.loginPassword
また、これらに作業を実施する前に、必ずファイルのバックアップを取っておいて下さい。
ファイル編集後、WASを起動した際に設定が有効になります。
20
アプリケーション・セキュリティー
„
WAS上のアプリケーション・リソースをセキュアーにする機能
„
Web サーバーへのユーザー認証
‹
‹
アプリケーション・リソースへのアクセスを制限したい場合に設定する
基本認証（Basic）
¾
‹
フォーム認証（Form）
¾
‹
WebサーバーがWebクライアントに認証を要求し、Web クライアントはHTTP ヘッダーでユー
ザー ID とパスワードを渡す
ログイン・ページにHTMLフォームを使用する認証です
証明書（Certificate）
¾
¾
クライアント・マシンに組み込まれたX.509形式の証明書に基づいて、ユーザーの認証を行う
HTTPSプロトコルを使用する
・フォーム認証
・基本認証
21
アプリケーション・セキュリティーとは、WAS上のアプリケーション・リソースをセキュアーにする機能で
す。Web クライアントまたはWeb ブラウザーは、以下のメカニズムのいずれかを使用して、Web サー
バーへのユーザー認証を行うことができます。
・基本認証（Basic）
ユーザーがブラウザーのポップアップ画面から入力したユーザーIDとパスワードで認証が行われま
す。いったん入力したユーザーIDとパスワードはブラウザーにキャッシュされ、リクエストごとにHTTP
ヘッダーに含められ、自動的にWebサーバーに送信されます。ユーザーIDとパスワードはBase64で
エンコーディングされます。しかし、Base64は暗号化を行うわけではなく、主に通信の間で文字化け
を防ぐ目的でバイナリー化するものであるため、比較的簡単にデコードできてしまいます。したがっ
て、セキュリティーを確保するためにはSSL（通信の暗号化）の併用が必須となります。
・フォーム認証（Form）
ログイン・ページにHTMLフォームを使用する認証です。ログイン・ページはHTMLなので自由にカ
スタマイズ可能です。ユーザーの入力したユーザーIDおよびパスワードはアプリケーション・データと
して、ブラウザーからWAS 上に送信されます。フォームで入力したユーザーIDやパスワードはネット
ワーク上で暗号化されないので、セキュリティーを確保するためにはSSLの併用が必須です。
・証明書（Certificate）
クライアント・マシンに組み込まれたX.509形式の証明書に基づいて、ユーザーの認証が行われま
す。そのため、クライアント側に各自のX.509証明書と秘密鍵を所有している必要があります。SSLに
よって行われる高度な認証で、ネットワーク上に流れるデータを盗聴されても成りすましの危険が小
さく、非常に安全な認証方式です。クライアント証明書を使用するにあたってはWebサーバーで設定
を行う必要があります。
21
認証リポジトリー
„
WAS V7.0でサポートされる認証リポジトリー
‹
① 統合リポジトリー
¾
¾
¾
複数のユーザー・レジストリーを論理的な1つのレジストリーとして使用可能
Virtual Member Manager (VMM)コンポーネントにより統合機能が提供
ファイル・ベース、LDAP、データベース、カスタムの4種類を組み合わせることが可能
z
z
¾
デフォルトはファイル・ベース・リポジトリーで構成
z
z
‹
‹
LDAPをユーザーレジストリーとして利用
③ ローカル・オペレーティング・システム・レジストリー
¾
注意
fileRegistry.xmlファイルにて管理する
ユーザー/グループ管理は、管理コンソールから実施
② スタンドアロンLDAPレジストリー
¾
‹
ファイル・ベースとLDAPは管理コンソールにて設定
データベースとカスタムはwsadminにて設定
¾
リポジトリーとしては、
リポジトリーとしては、
ファイルベースとLDAPを設定
ファイルベースとLDAPを設定
WASが導入されているOS上のOSユーザーをレジストリーとして利用
WAS Base構成でのみ選択可能
④ スタンドアロン・カスタム・レジストリー
¾
¾
データベースやテキストファイルなどをレジストリーとして利用する際に選択
UserRegistry Javaインターフェースを使用し、ユーザーが独自に実装する必要がある
22
統合リポジトリーのアーキテクチャーは、「セキュリティー設計-参考-」のP.8をご参照下さい。
グローバル・セキュリティーでは認証リポジトリーとして、統合リポジトリー、スタンドアロンLDAPレジス
トリー、ローカル・オペレーティング・システム・レジストリー、スタンドアロン・カスタム・レジストリーがサ
ポートされます。
統合リポジトリーは、WAS V6.1の新機能で新しいユーザー・リポジトリーです。複数のユーザー・リポ
ジトリーを論理的に１つのユーザー・リポジトリーとして使用することが可能になります。デフォルトで
は、ファイルベース・リポジトリーがユーザー・リポジトリーとして設定されており、ファイル・ベース、
LDAP（またはLDAPのサブツリー）、データベース、カスタムの4つのリポジトリーを利用できます。
ファイル・ベースとLADPは、管理コンソールから設定可能であり、その他はwsadminコマンドにて設
定致します。
ファイルベース・リポジトリーは、WAS V6.1の新機能でユーザー情報をローカルのファイルに保存す
る機能です。このファイルは、WASの構成リポジトリー内に作成され、他のWAS構成情報と同じ扱い
を受けます。管理コンソールから登録された内容は、デプロイメント・マネージャー内の構成リポジト
リー内に登録され、同期を実行すると各ノードに配布されます。
ファイルベース・リポジトリーの情報は、構成リポジトリー内の以下のファイルに登録されます。
<PROFILE_ROOT>/config/cells/<cell_name>/fileRegistry.xml
上記ファイルに登録される内容は、ユーザー情報とグループ情報になります。
ユーザー情報内にはパスワードも登録されていますが、パスワード自身は暗号化されています。
ユーザー/グループ情報の管理は、管理コンソールやwsadminコマンドで行います。大量ユーザー
登録や定期更新の機能はないので、大量のユーザー管理を行うのにはあまり向いていません。また、
セキュリティー・ポリシーの設定機能はありません。ユーザーIDやパスワードの文字種/文字数、有効
期限と言った制約は設定できませんので、管理者自身で管理する必要があります。
ローカル・オペレーティング・システム・レジストリーはWAS Base構成のみでのサポートとなり、WAS
ND環境ではサポートされませんのでご注意下さい。
22
認証リポジトリーの選択指針
レジストリー
同時複数リポジト
リーサポート
リポジトリーRead
/Writeサポート
レルム名の変更
事例
①統合リポジトリー
②スタンドアロン
LDAP
③ローカル・オペレー
ティング・システム
④スタンドアロン・カ
スタム
ファイル、LDAP、DB、カ
スタム
VMMコンポーネント(API)
経由となる
Yes
スタンドアロンLDAP
ローカル・オペレーティン
グ・システム
スタンドアロン・カスタム
No
No
No
Read/Write
Read
Read
Read
管理コンソールから変更
可能
・WAS管理ユーザーを既
存のLDAP環境に登録で
きない場合に、統合リポ
ジトリーを使用しWAS管
理ユーザーをファイル、
ユーザー情報をLDAPに
て管理する
管理コンソールから変
更可能
・LDAPでしかユーザー
情報を管理しない場合
変更できない
変更できない
・WAS Base構成で、WAS
管理ユーザーをOSで管
理したい場合
・①/②/③では対応でき
ない場合
・将来的に、現在使用し
ているリポジトリー以外
の方式を選択する可能
性がある場合
・既存構成から変更した
・ WAS Base構成で、WAS
くない場合
管理セキュリティーのみ
を構成する場合
・UserRegistoryのモ
ジュールが提供されて
いるパッケージを使用す
る
1セル内で複数の認証リポジトリーの設定が必要な場合には、複数
1セル内で複数の認証リポジトリーの設定が必要な場合には、複数
セキュリティー・ドメインにて対応する
セキュリティー・ドメインにて対応する
23
認証リポジトリーの選択指針をまとめます。この表を参考にされ、システムの認証リポジトリー先を決
定して下さい。
23
複数セキュリティー・ドメイン
„
WAS V6.1での課題
‹
‹
„
New
v7
セルで設定可能なセキュリティー構成は1つのみ
異なる認証リポジトリーを使用する場合は、セルを分割する
WAS V7.0での拡張
‹
‹
セル内にセキュリティー・ドメインを複数定義し、グローバル・セキュリティー
構成を上書きすることが可能
グローバル・セキュリティー構成は、管理セキュリティーおよびデフォルト・セ
キュリティー構成に適用
¾
¾
例1) Cluster_mem1とserver1上のアプリケーションが使用する認証リポジトリーを別レジストリーとする
例2) 管理セキュリティーは統合リポジトリーを、アプリケーション・セキュリティーはLDAPレジストリーを使用
構成
ノード1
構成
レジストリー
ノード3
ノード2
クラスターCluster1
デプロイメント・
マネージャー
構成
レジストリー
凡例
アプリ1
アプリ2
アプリ2
グローバル・
セキュリティー構成
アプリケーション・
サーバー
server1
アプリケーション・
サーバー
Cluster_mem1
アプリケーション・
サーバー
Cluster_mem2
Server1ドメイン構成
Cluster1ドメイン構成
レジストリー
24
複数セキュリティー・ドメインの設定方法は、「セキュリティー設計-参考-」のP.9～ P.10をご参照下さい。
WAS V6.1までは1つのセルでは1つのセキュリティー構成しか有効にできませんでした。WAS V7で
はセル内にセキュリティー・ドメインを複数定義することができるようになり、これらセキュリティー・ドメ
インに対し個別にセキュリティー構成を設定できるようなりました。これにより、管理セキュリティーとア
プリケーション・セキュリティーで使用する認証リポジトリーを変更するといったことが可能になってい
ます。
24
セキュリティー・ドメイン構成ファイル
„
セキュリティードメインの構成ファイル (手動編集不可)
‹
security-domain.xml ファイル
¾
‹
security-domain-map.xml ファイル
¾
„
セキュリティー・ドメインを使用する有効範囲を含むファイル (サーバー、クラスター等)
セキュリティー・ドメイン関連ファイル
‹
全てのセキュリティー・ドメインで、$SecurityDomainNameディレクトリーが作成
¾
„
セキュリティー・ドメインに構成されている属性リスト (ユーザー・レジストリー、ログイン構成等)
<WAS_PROFILE_ROOT>/config/waspolicies/default/securitydomains/$SecurityDomainName
上書き可能なセキュリティー属性一覧
グローバル・セキュリティー
アプリケーション・セキュリティー
Java2セキュリティー
ユーザー・レルム(認証リポジトリー)
トラスト・アソシエーション(TAI)
SPNEGO Web認証設定
RMI/IIOPセキュリティー
JAAS
認証メカニズム属性
許可プロバイダー
カスタム・プロパティー
セキュリティー・ドメインでオーバーライドが可能な項目
○
○
○
○
○
○
○
○
○
○
シングル・サインオン
SSL
セキュリティー監査
LTPA認証メカニズム
25
Kerberos認証メカニズム
セキュリティー・ドメイン情報は、2 つの構成ファイルによって定義されます。一方の構成ファイルには、
セキュリティー・ドメインに構成されている属性のリストが含まれます。もう一方の構成ファイルには、
セキュリティー・ドメインを使用する有効範囲が含まれます。
セキュリティー・ドメイン情報は、
$WAS_HOME/profiles/$ProfileName/config/waspolicies/default/securitydomains/$SecurityDomain
Name ディレクトリーに保管されます。構成されているすべてのセキュリティー・ドメインに、2 つのファ
イルを含む $SecurityDomainName ディレクトリーが作成されます。2 つのファイルの内、securitydomain.xml ファイルには、セキュリティー・ドメイン用に構成されたセキュリティー属性のリストが含ま
れ、もう 1 つの security-domain-map.xml ファイルには、セキュリティー・ドメインを使用する有効範
囲が含まれます。
グローバル・セキュリティー構成に対し、セキュリティー・ドメインで上書きできるセキュリティーとできな
いセキュリティーがありますので、上表にてご確認下さい。
25
サーバー単位でのセキュリティー設定
„
注意
„
WAS V7.0では、サーバー・レベルでセキュリティー設定は非推奨です。
サーバー・レベルで設定する場合は、複数セキュリティー・ドメインを使
用して下さい。
背景
‹
‹
WAS V6.1では、サーバー単位でのセキュリティー設定が可能
WAS V7.0では、そもそもサーバー単位を選択できない
・WASV6.1での設定
・WASV7.0での設定
26
WASV6.1では、サーバー・レベルでセキュリティー設定が可能でした。WASV7.0では、サーバー・レ
ベルでのセキュリティー設定が非推奨になりました。サーバー・レベルで設定したい場合には、複数
セキュリティー・ドメインを使用して下さい。（WAS V7.0ではサーバー単位での設定が不可能になっ
ています。)
26
シングルサインオン (SSO)
„
１回のログインで複数のシステムを利用可能にする認証のこと
‹
„
複数のシステムを利用する度に認証を実施する必要がなくなります
WAS V7.0がサポートしている認証方法
‹
LTPA認証
¾
¾
¾
‹
New
v7
‹
SSOを行うシステム間でLTPA鍵を共有する
最初に認証を受けたサーバーがLTPAを発行する
2回目からのクライアントからのアクセスは、LTPAを提示することで認証が不要となる
Kerberos認証
SPNEGO Web認証
・LTPA認証の処理フロー
27
SSOとは、複数のシステムの認証処理を1回のログインで実行する認証方法です。例えば、システム
AとシステムBがあり、それぞれアクセスするためには認証が必要なシステムを想定します。このシス
テムがSSOを実現していると、システムAで認証を行ったクライアントは、認証を必要とせずにシステ
ムBにアクセスすることが可能になります。
SSOを実現するにあたり必要となる認証方法として、WAS V7.0では、LTPA認証、Kerberos認証と
SPNEGO Web認証をサポートしています。
LTPA認証方式では、クライアントは最初に認証を受けたサーバーからLTPAトークンを受け取ります。
2回目以降のアクセスでは、LTPAトークンを持ってサーバーにアクセスし、サーバーはトークンの内
容に従って認証を行います。従いまして、異なるシステム間で認証に使用するLTPAトークンを共通
化することでSSOを実現することが可能なります。
Kerberos認証、SPNEGO Web認証につきましては、次ページ以降にてご説明致します。
27
Kerberos認証
„
クライアントとサーバー間の通信を暗号化するユーザー認証メカニズム
‹
„
WAS V6.1よりKerberos認証をサポート
‹
„
ギリシア神話に登場する地獄の番犬に由来し、この怪物と同様にネットワーク
にアクセスする者の認証を行う
Windowsを始めとした様々な製品とシングル・サインオンが可能に
Kerberos認証の挙動
‹
①ネットワークへのユーザー・ログオン
¾
KDC (Key Distribution Center)にアクセスして認証を受ける
¾
認証が成功するとクレデンシャルがKDCからユーザーに付与される
z
z
‹
Windows ネットワークでは、Kerberos認証機能が標準で実装されているため、ドメイン・コントローラがKDCとして機能する
クレデンシャルはセッション鍵とTGT(Ticket-Granting Ticket：チケット保証チケット)を含むデータである
②リソースへのアクセス (セッション鍵によりすべて暗号化されている)
¾
¾
¾
¾
リソースを指定し、KDCにTGTを提示する
KDCはTGTに記載されている有効期限などをチェックする
KDCはリソースにアクセスするための「アクセスチケット」をユーザーに返す
ユーザーはアクセスチケットを利用し、リソースにアクセス可能となる
28
ケルベロス認証とは、クライアントとサーバー間の通信を暗号化するユーザー認証メカニズムのひと
つです。ケルベロスという名称は、ギリシャ神話に登場する地獄の番犬に由来し、この怪物と同様に
ネットワークにアクセスする者の認証を行います。
WASは、WASV6.1よりこのKerberos認証をサポートし、Windowsを始めとした様々な製品とのシング
ル・サインオンが可能になりました。
28
SPNEGO Web認証
„
IETF RFC 2478で定義された認証メカニズム
‹
‹
Simple and Protected GSS-API Negotiation Mechanismの略
WASはSPNEGOを使用することで、Window-WAS間の統合シングルサインオン環
境を確立する
„
SPNEGO TAIは非推奨になり、WAS V7.0ではSPNEGO Web認証に変更
‹
New
v7
WAS V7.0での拡張
¾
¾
¾
¾
管理コンソールからの設定が簡便化
SPNEGOランタイムの動的更新
セキュリティー・ドメイン・レベルでカスタマイズが可能
アプリケーション・ログイン・メソッドへのフォールバックが可能
・単一 Kerberos レルム内でのSPNEGO Web認証
Windows2003 Server
Kerberos KDC
Active Directory
Kerberos KDC
認証プロトコル間を
ネゴシエートする
3. TGTを取得（TGT）
4. アクセスチケットを要求（TGS_REQ）
5. アクセスチケットを取得（TGS_REP）
1. HTTP/Post/Get/Webサービス
WebSphere
レジストリー
8. ユーザーIDをレジストリーで確認し、
LTPAトークンを作成
Web認証
7. SPNEGOトークンから
ユーザーIDの取得
SPNEGO
2. HTTP401 認証/ネゴシエーション
ブラウザー
6. HTTP/Post/Get/Webサービス SPNEGOトークン
9. HTTP200 コンテンツ LTPAトークン
Windowsクライアント
krb5.conf
Krb5.keytab
29
WAS V7
SPNEGO Web認証により、Window-WAS間の統合シングルサインオン環境を確立することが可能に
なります。
通常、WAS上の保護されたアプリケーションにアクセスする際、エンドユーザーはOSへログインした
後、 WebブラウザーにてID/パスワードを入力するなどしてWASの認証を受ける必要があります。
SPNEGO Web認証を使用すると、OSへ1度ログインさえすれば、アプリケーションへのアクセス時に
ID/パスワードを入力する必要がなくなり、利便性が向上します。
WAS V6.1ではSPNEGO TAIによって同等の機能が提供されていましたが、WAS V7.0では非推奨と
なっています。SPNEGO Web認証は、SPNEGO TAIと比較して以下の機能が拡張されています。
・管理コンソールにおける設定が1画面でできるようになり、簡便化されています。
・SPNEGOランタイムの更新を動的に行うことが可能です。
・SPNEGO Web認証に失敗した場合、アプリケーション・ログイン・メソッドへのフォールバックを実施
することが可能です。例えば、ドメインに参加していないクライアントマシンからアクセスがあった場合、
アプリケーションが提供しているログイン方法（基本認証やフォーム認証など）にて認証を受けること
が可能です。
・SPNEGOの設定をセキュリティードメインレベルでカスタマイズすることが可能です。例えば、アプリ
ケーションごとにSPNEGOの構成を変更したい場合などに有効です。
なお、SPNEGOWeb認証で対象となるクライアントマシンはWindowsマシンで、かつActive Directory
ドメイン(Windows 2000/2003 Server)に参加している必要があります。クライアントマシン上のWebブ
ラウザーはMicrosoft Internet Explorer 5.5以降、Mozilla Firefox 1.0が前提となります。
29
認証キャッシュ設定
„
New
v7
認証キャッシュ設定
‹
‹
WAS V7.0にて、一部のパラメーターが管理コンソールから設定可能
パフォーマンスの観点から、使用可能に設定することが推奨
・WAS V7.0
WAS
WAS V7.0での拡張機能
V7.0での拡張機能
・WAS V6.1
30
WAS V7.0では、初期キャッシュ・サイズや最大キャッシュ・サイズ等を管理コンソールから容易に設
定できることが可能になっています。また、WAS V6.1と設定箇所が異なっていますので、ご注意下さ
い。
30
2. WASセキュリティー設計
2-1
2-2
2-3
2-4
2-5
ハードニング
認証
認可
暗号化 / 署名
監査
認可とは、保護対象リソースに対して適切なアクセス権限を付与する
31
続きまして、保護対象リソースに対して適切なアクセス権限を付与する認可についてご説明致します。
31
認可 (Authrization)
„
„
前提として認証が必要 (アクセス管理 = 認証 ＋ 認可)
認証されたユーザーが、要求するリソースにアクセスする権限をもってい
るかを判定する
‹
„
管理セキュリティーとアプリケーション・セキュリティーが対象
設定例)：アプリケーションセキュリティー
‹
ロールベースのアクセス管理
¾
Tellerロールをもつユーザー、Teller GroupやBobはAccountBean method のgetBalance や
deposit、withdrawなどが実行可能
・リソース許可
リソースからロールへのマッピング表
・許可テーブル
ユーザーまたはグループに対するロール表
32
認可とは、認証によって確認された利用者を識別して、利用者ごとに個々のリソースへのアクセス権
を与えることです。認可にはACL(Access Control List)が用いられることがよくあります。このACLは
アクセス・コントロール・リストと呼ばれ、利用者ごとのアクセス権とリソースを列挙したリストになります。
大規模なシステムにおいては管理の負荷を軽減するために、ロールベースのアクセス管理が採用さ
れる場合があります。これは、システム内部でいくつかのロール（役割）を定義し、ロールごとにアクセ
ス権を割り当てます。利用者はロールを割り当てられることにより権利を付与されます。
上表は銀行用アプリケーションのサンプルです。
アプリケーションのアセンブル時に、メソッドを起動する許可が、1つ以上のロールに認可されます。
ロールは、一連の許可です。
ロールには、テラー、クラーク、スーパーバイザーおよびその他の銀行業関連の地位が含まれます。
テラーのロールは、口座内のお金の管理に関連するメソッド (例えば、預金の引き出しや預け入れ
のメソッド) を実行するための許可に関連付けられています。表では、AccountBean method の
getBalance やdeposit、withdrawなどを実行することが可能であることがわかります。テラーのロール
には、口座を閉じる許可（closeAccount）は付与されていません。この許可は、スーパーバイザーの
ロールに与えられています。 テラーのロールを持つユーザーは、許可テーブルよりTeller Group と
Bobということがわかります。よって、 Teller Group とBob はAccountBean method のgetBalance や
deposit、withdrawなどを実行することができるユーザーになります。
32
管理ロール
„
WAS管理操作に対して、アクセス制御を提供する機能
‹
権限は管理ロールとして定義され、1ユーザー、1グループに対し複数の管理
ロールを設定可能
※
※ WAS一次管理者に割り当てられる管理ロール
WAS一次管理者に割り当てられる管理ロール
管理ロール名
説明
管理者※
オペレーター、コンフィギュレーターに与えられる権限および管理者ロールのみ
に許可されている追加権限を持つ。
セキュリティー・マネー
ジャーの管理※
New
監査員※
v7
管理者ロールを割り当てることができる。また、Fine-grained管理セキュリティー
使用する際に、このロールを持つユーザーだけが許可グループを管理できる。
コンフィギュレーター
モニターに与えられる権限を持ち、WASの構成を変更することができる。
オペレーター
モニターに与えられる権限を持ち、起動・停止といったランタイムの状況を変更
することができる。
デプロイヤー
アプリケーションに関する変更およびランタイムの操作をおこなうことができる。
ISC管理者
管理コンソールのみ使用可能で、統合リポジトリー構成のユーザーおよびグ
ループを管理することができる。
モニター
WASの構成および現在のランタイムの状況を確認することができる。
セキュリティー監査の確認、設定変更権限を持つ。
33
管理ロールの設定方法は、「セキュリティー設計-参考-」のP.12をご参照下さい。
管理ロールとは、WAS管理操作に対してアクセス制御を提供する機能です。権限は管理ロールとし
て定義され、1ユーザー、1グループに対して複数の管理ロールを設定することも可能です。WAS
V7.0では監査員という管理ロールが新しく追加されました。後述致しますが、WAS V7.0の新機能で
ある監査機能を使用する場合に、この管理ロールの権限が必要となります。
33
Fine-Grained 管理セキュリティー
„
ユーザーの管理ロールを特定のリソース・インスタンスに対してのみ割り
当てることが可能
‹ リソースタイプ
¾ セル、ノードグループ、ノード、クラスター、サーバー、アプリケーション（BLA単位でも可能）
¾ 上位のリソースに対して権限を付与すると、その下のリソースに対する権限が与えられる
‹ 割り当てられたリソース以外にアクセスすることはできない
‹ セキュリティー・マネージャーの管理ロールをもつユーザーが許可グループを
管理する
„
WASV7.0では、管理コンソールでの設定が可能 (一部、wsadminコマンド)
New
v7
許可グループとは同じ権限を持
つリソースを1つにまとめたもの
セル
ノード・グループ
ノード
許可グループ
クラスター
サーバー
アプリケーション
Fine-Grained 管理セキュリティーの設定方法は、「セ
34
キュリティー設計-参考-」のP.13～ P.14をご参照下さい。
管理ロールを与えられたユーザーは、セル全体を管理することができました。これはすべてのリソー
スを管理することを意味しています。
Fine-Grained管理セキュリティーを使用すると、より細かいリソース単位でユーザーに管理ロールを
割り当てることができます。リソース単位での管理ロールは、許可されたリソース以外にはアクセスで
きません。また、WAS V6.1まではFine-grained管理セキュリティーの設定はwsadminコマンドで実施
していましたが、WAS V7.0では管理コンソールからも設定することができるようになりました。しかし、
以下の項目につきましては、wsadminコマンドにて設定する必要があります。
・ユーザーに特定の許可グループのみへのアクセス権を与える
・セル以外の許可グループへの許可を与える
34
管理ロールの設計指針
„
前提
‹
‹
ユーザーに対して、複数の管理ロールを割り当てることが可能
グループに対して、複数の管理ロールを割り当てることが可能
¾
„
グループ内のユーザーすべてにロールが付与される
設計指針
‹ 個々のユーザーではなく、グループに対して管理ロールを付与する
‹
① 許可検査時のパフォーマンスが向上する
¾
‹
‹
通常は、ユーザー数よりグループ数の方がはるかに少ない
② アクセス制御にグループのメンバーシップを使用することにより、柔軟性
が向上する
③ 製品環境の外側で、グループにユーザーを追加したり、グループから
ユーザーを削除したりできる
35
ここで、管理ロールの設計指針についてまとめます。
ユーザーは、複数のロールを割り当てることが可能です。この場合、ユーザーに付与された許可は、
それぞれのロールに与えられた許可の結合体となります。さらに、認証メカニズムがユーザーのグ
ループ化をサポートしている場合、グループにロールを割り当てることが可能です。あるグループを
あるロールに割り当てることは、個々のユーザーをロールに割り当てるのと同じ効果を持ちます。
デプロイメント時のベスト・プラクティスは、ロールに対して、個々のユーザーではなく、グループを割
り当てて下さい。その理由は以下になります。
① 許可検査時のパフォーマンスが向上する。通常は、ユーザー数よりグループ数の方がはるかに
少なくなります。
② アクセス制御にグループのメンバーシップを使用することにより、柔軟性が向上します。
③製品環境の外側で、グループにユーザーを追加したり、グループからユーザーを削除したりする
ことができます。
35
アプリケーション・セキュリティーの認証・認可を行うコンポーネント
Webサーバー
WAS
TAM
認証方法
ベーシック認証
ダイジェスト認証
クライアント証明書
ベーシック認証
フォーム認証
クライアント証明書
ベーシック認証
フォーム認証
クライアント証明書
など
認可レベル
URL
宣言型：URL
プログラム型：自在
URL
ユーザー・ディレクトリー
テキストファイル
LDAP
ファイル
LDAP
データベース
カスタム
LDAP
WASグローバル・セキュリティー
の設定
不要
必要
不要
可能
(LTPAトークンで認証
情報を渡す)
可能
（LTPAトークン、BA
ヘッダーなどで認証情
報を渡すことが可能）
シングル・サインオン
-
認証はTAMで行い、細かなアクセス制御はWASで行う構成も可能
36
ここで、WASを使用したシステムでの、アプリケーション・セキュリティーの認証・許可を行うコンポー
ネントと特徴をまとめます。
ひとつの例として、Tivoli Access Manager for e-business（TAM）を導入し、認証はTAMで行い、細
かなアクセス制御はWASで行うというシステム構成が可能です。
・TAMとは
Webアプリケーションに共通のポリシーを実装して、一元的なアクセス管理を実現する製品です。ポ
リシーベースのシングルサインオン環境を構築することで、不正アクセスを防止しつつユーザーの利
便性を向上させます。
36
TAMと連携したWebシステム構成
„
認証をTivoli Access Manager (TAM)で行う構成
‹
バックエンドシステム（Webサーバー、ホスト等）の認証機能をTAMで代行し、
集約することでセキュリティーレベルをTAMで一括管理する
¾
¾
TAMでは、認証と大まかなアクセス制御を行う
バックエンドのシステムでは、詳細なアクセス制御を行う
TAM
Load Balancer
Web Server
Application Server
認証とURLベースの
認証とURLベースの
アクセス制御
アクセス制御
TAMの管理サーバー
TAMの管理サーバー
LDAP Server
TAM (PolicyServer)
37
TAMと連携したWebシステムの構成例になります。
37
2. WASセキュリティー設計
2-1
2-2
2-3
2-4
2-5
ハードニング
認証
認可
暗号化 / 署名
監査
暗号化とは、通信経路等の暗号化を行うことにより保護対象リソースの盗聴を防ぐ
署名とは、デジタル署名等により保護対象リソース(データ)の改ざんを防ぐ
38
続きまして、通信経路等の暗号化をおこなうことにより保護対象リソースの盗聴を防ぐ暗号化、デジタ
ル署名等により保護対象リソース(データ)の改ざんを防ぐ署名についてご説明致します。
38
SSL (Secure Sockets Layer)
サーバーとクライアント間のセキュアー接続を提供する技術
トランスポート層において機能するプロトコル
„
„
‹
‹
‹
認証性
保全性
機密性
クライアント認証、サーバー認証によるなりすまし防止
データ署名による改ざん防止
暗号化による盗聴防止
X.509証明書
‹ SSL実装には、Java™ Secure Sockets Extension (JSSE)を使用
‹ X.509 証明書ベースの非対称の鍵ペアを信頼する
„
‹
X.509証明書の内容
¾
‹
署名、バージョン、シリアル番号、署名アルゴリズム識別子、発行者名、有効期間、サブジェク
ト名、証明書で公開鍵が識別されているエンティティの名前、サブジェクトの公開鍵情報
X.509証明書の内容の署名
¾
認証局（CA）、ルート証明書、自己署名
SSLハンドシェイクは、「セキュリティー設計-参考-」のP.16をご参照下さい。
39
SSLハンドシェイクのキャッシュは、 「セキュリティー設計-参考-」のP.17をご参照下さい。
SSLとは、クライアントとサーバー間のセキュアー接続のための認証性、保全性、および機密性のあ
るトランスポート層セキュリティーを提供するプロトコルです。このプロトコルは、TCP/IPの上位、かつ
HTTP、LDAP、ORB/IIOPなどのアプリケーション・プロトコルの下位で実行され、トランスポート・
データに信頼性とプライバシーを提供します。
WASでは、セキュア接続の SSL 実装として、Java™ Secure Sockets Extension (JSSE)を使用してい
ます。JSSEは、Java 2 Standard Edition (J2SE) 仕様の一部であり、Java Runtime Extension (JRE)の
IBM® 実装に含まれます。JSSE は、SSL によって提供されるハンドシェーク・ネゴシエーションと保
護機能を処理し、ほとんどのプロトコル全体でセキュアな接続が存在するようにします。 JSSEでは、
セキュア接続の保護とデータ暗号化の一部について、X.509 証明書ベースの非対称の鍵ペアを信
頼します。鍵ペアは、より大きなデータ・ブロックを暗号化するセッション・ベースの秘密鍵を、効果的
に暗号化します。 SSL実装は X.509 証明書を管理します。
クライアントとサーバー双方のSSL構成に応じて、様々なレベルの信頼性、データ保全性、およびプ
ライバシーを確立することができます。適切な構成を行い、クライアントとアプリケーション両方の
データに必要な保護レベルを実現するためには、SSLの基本動作について理解していることが重要
です。
SSLによって提供されるセキュリティー・フィーチャーの中には、データの伝送中に機密情報が漏れ
ないようにするためのデータの暗号化があります。また、データの署名により、データの転送中に
データが許可なく変更されることを防止できます。更に、クライアント認証およびサーバー認証により、
適切なユーザーまたはマシンと通信していることが保証されます。SSLは、エンタープライズ環境の
通信の保護に効果的です。
＜参考情報＞
WAS V7.0 InformationCenter - 「通信の保護」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.d
oc/info/ae/ae/tsec_securecomm.html
39
WASを使用したシステムでのSSL通信
„
SSL通信の設定
‹
IHS-WAS間は、クライアント-IHS間がSSL通信の場合、デフォルトでSSLで
通信となる
Web Server
Client
„
Application Server
HTTP
HTTP
HTTPS
HTTPS
IHS-WAS間のSSL解除
‹
‹
・httpd.conf抜粋
<VirtualHost *:443>
SSLEnable
SSLServerCert selfSigned
</VirtualHost>
KeyFile
"/opt/IBM/HTTPServer70/conf/ihskeys.kdb"
IHSとWASが同一筐体の場合は、パフォーマンスの観点からOFFにすること
を検討する
設定方法
¾
管理コンソールより、アプリケーション・サーバー名 >- Webコンテナー設定 >- Webコンテ
ナー・トランスポート・チェーンを選択し、WCInboundDefaultSecureのトランスポート・チェーン
をOFFにする
WASの各コンポーネント間で使用される
SSL構成は、「セキュリティー設計-参考-」
のP.18をご参照下さい。
40
クライアント-IHS間がSSL通信の場合、IHS-WAS間もデフォルトでSSL通信となります。特に、IHSと
WAS間が同一筐体の場合等、セキュリティーが確保されている場合にはパフォーマンス向上の観点
からIHS-WAS間のSSL通信を解除することをご検討下さい。
40
証明書と鍵の管理
„
証明書有効期限の管理
‹
WASによって管理されるキー・ストアに格納された証明書の期限を監視、期限
切れ前に警告を出す
¾
„
自己署名証明書を自動更新することも可能
IBM 鍵管理ユーティリティ (iKeyman)と同等の機能が、管理コンソールか
ら使用可能に
‹
‹
ikeymanは引き続き利用可能
証明書要求は生成したツールを使用して受信する必要がある
・管理コンソール
・ikeyman
同じ機能が提供
・新しいキー・データベースを作成する
・新しいキー・データベースを作成する
・新しい鍵のペアと認証要求の作成
・新しい鍵のペアと認証要求の作成
・自己署名付き証明書の作成
・自己署名付き証明書の作成
・認証要求の再作成
・認証要求の再作成
・CA署名付き証明書をキー・データベースに受け取る
・CA署名付き証明書をキー・データベースに受け取る
・CAのルート証明書を保管する
・CAのルート証明書を保管する
・キー・データベースをオープンする
・キー・データベースをオープンする
・鍵を別のデータベースまたはPKCS12ファイルにエクスポー
・鍵を別のデータベースまたはPKCS12ファイルにエクスポー
ト・インポートする
ト・インポートする
・キーの抽出・削除
・キーの抽出・削除
・認証局（CA）と認証要求をリストする
・認証局（CA）と認証要求をリストする
・キー・データベースのデフォルト鍵を作成する
・キー・データベースのデフォルト鍵を作成する
・暗号化されたデータベース・パスワードをstashファイルに保
・暗号化されたデータベース・パスワードをstashファイルに保
管する
管する
41
WASの管理下にある鍵ストアに含まれる証明書に関しては、証明書の期限を監視し、期限切れ前に
警告を出すことも可能です。管理コンソールから、有効期限の閾値の設定と、期限切れ通知先のe
メールアドレスを登録します。また、期限が切れる証明書を自動的に更新するオプションもあります。
管理コンソールから証明書と鍵の管理が可能です。ikeymanと同等の操作を管理コンソールから行う
ことができるようになります。
セキュア・ネットワーク接続を行うには、セキュア・ネットワーク通信のための鍵を作成し、ご使用の
サーバーでトラステッドCA として指定された認証局 (CA) から証明書を受信します。 IBM鍵管理
ユーティリティ(iKeyman) を使用すると鍵データベース、公開鍵と秘密鍵のペアおよび認証要求を作
成することができます。ユーザーが自分自身のCA として機能する場合は、iKeymanを使用して自己
署名証明書を作成することもできます。
41
証明書の有効期限切れ問題
„
WAS V6.1FP5での課題
‹
証明書の有効期限(デフォルト：1年)が切れ、以下のような事象が発生する
¾
¾
„
デプロイメント・マネージャーとの通信に失敗する
プロセスの起動に失敗する
証明書の署名方法
‹
‹
‹
認証局（CA）
自己署名証明書
ルート証明書
¾
¾
¾
WAS V6.1
WAS V7.0
ルート証明書の有効期限が切れない限
ルート証明書の有効期限が切れない限
りは、WAS V6.1の問題は発生しない
有効期限のデフォルトは15年
りは、WAS V6.1の問題は発生しない
WAS V7.0では、チェーン証明書をデフォルトの個人証明書として使用する
チェーン証明書は、ルート証明書によって署名される
証明書C１ R１
公開鍵C１
秘密鍵C１
署名R１
(※)以降、下図のように表現
証明書C１ R１
秘密鍵C１
42
各コンポーネント内の証明書関連図は、「セキュリティー設計-参考-」のP.19～ P.20をご参照下さい。
WAS V6.1では、自己署名証明書の有効期限がデフォルトで1年であり、有効期限が切れるとデプロ
イメント・マネージャーとの通信に失敗したり、プロセスの起動に失敗する事象が発生します。(WAS
V6.1 FP7では発生しません。)これは、WASV6.1では証明書の署名に自己署名証明書を使用して
いたことが起因致します。WAS V7.0では証明書の署名をルート証明書を使用しており、有効期限が
切れない限りは、WAS V6.1の課題は発生致しません。(だたし、自動更新する際には、NodeAgent
が稼動している必要があります。NodeAgentが稼動していない時に自動更新されてしまった場合に
は、syncNodeコマンドを実行して構成情報を同期させて下さい。)
WAS V6.1での対応方法につきましては、下記リンク先をご確認下さい。
・【ご注意下さい】 WAS 6.1の自己署名証明書・自動更新機能を使用する場合の考慮点
http://www-06.ibm.com/jp/domino01/mkt/websphere.nsf/doc/0033ED2E
また、各コンポーネント内の証明書の関係についてご説明致します。
デフォルトで、WASは、ノードごとに、固有のチェーン証明書を作成します。チェーン証明書は、
ルートで署名された、 DmgrDefaultRootStore または NodeDefaultRootStore に保管された証明書で
す。デフォルトの鍵ストア key.p12 およびトラストストア trust.p12 は、ノード・ディレクトリー内の構成リ
ポジトリーに保管されます。デフォルトのルート証明書は、ノード・ディレクトリーの下の構成リポジト
リーにある root-key.p12 に保管されています。
すべてのノードでは、この共通トラストストア(trust.p12)に、デフォルトのルート証明書が置かれます。
さらに、ノードを統合した後で、共通トラストストア(セル・ディレクトリーにあります)を指すように、デ
フォルトの SSL 構成が自動的に変更されます。これで、ノードはセル内のすべての他のサーバーと
通信できるようになります。
42
2. WASセキュリティー設計
2-1
2-2
2-3
2-4
2-5
ハードニング
認証
認可
暗号化 / 署名
監査
監査とは、保護対象リソースに対して、いつ、誰が、何をしたのかを確認する
43
続きまして、保護対象リソースに対して、いつ、誰が、何をしたのかを確認する監査について、ご説
明致します。
43
セキュリティー監査機能とは
„
New
v7
セキュアーIT環境の統制に利用できる監査記録を提供
‹
‹
‹
„
WAS管理操作、アプリケーションでの認証・認可やその他セキュリティーイベ
ントをモニター
｢いつ｣、｢誰が｣、｢何をおこなったのか｣を監査ログに記録
法令遵守を証明するための仕組みや脆弱性分析に利用可能
WAS V7.0セキュリティー監査機能の特徴
‹
‹
前提：グローバル・セキュリティーを有効にする
監査ログファイルはバイナリー保存(可読性あり)
¾
¾
¾
‹
管理者(Administrator)と監査員(Auditor)の権限を分離
¾
¾
‹
JVM単位で出力(ファイル名: BinaryAudit_<cell_name>_<node_name>_<server_name>.log)
監査ログデータをHTML形式のレポートに変換するAudit Readerが提供されている
ログはデータの暗号化、署名による保護が可能
管理者権限では監査記録やポリシーの表示および変更ができない
監査員権限ではWASの構成やランライムの変更ができない
サード・パーティー製セキュリティー監査サービスとの統合も可能
44
WAS V7の新機能として、セキュリティー監査が追加されました。セキュリティー監査機能を有効にす
ることで、WASシステムインフラやアプリケーションでの認証・認可、その他のセキュリティーイベント
を監査ログから詳細にモニターすることができるようになります。このセキュリティー監査機能を使用
するためには、グローバル・セキュリティーを有効にすることが前提になります。
このセキュリティー監査機能は、サード・パーティー製品セキュリティー監査サービスをプラグインす
ることもできます。現在、z/OSのSMF(System Management Facility)へ監査データを記録するプロバ
イダー・プラグインが提供されています。
44
WAS V6.1のセキュリティー監査機能
„
監査対象
‹
作成、変更、削除などの構成変更
FileRepositor
FileRepositor A
A ADMR0016I:
ADMR0016I: ユーザー
ユーザー defaultWIMFileBasedRealm/server:IBMdefaultWIMFileBasedRealm/server:IBM69F48DB266CCell01_IBM-69F48DB266CCellManager01_dmgr
69F48DB266CCell01_IBM-69F48DB266CCellManager01_dmgr は文書
は文書 cells/IBMcells/IBM69F48DB266CCell01/security.xml
69F48DB266CCell01/security.xml を変更しました。
を変更しました。
‹
MBeanの開始・停止などの操作
AdminHelper
AdminHelper A
A ADMN1020I:
ADMN1020I: nodeagent
nodeagent サーバーを停止しようとしました。
サーバーを停止しようとしました。 (ユーザー
(ユーザー ID
ID ==
defaultWIMFileBasedRealm/aaa)
defaultWIMFileBasedRealm/aaa)
„
„
出力先ログ
考慮点
‹
‹
‹
Activity.log / 該当サーバーのSystemOut.log
何らかの構成変更、または操作を行った場合のみ、ロギングされる
構成監査では、ユーザー名を確認できない
操作監査では、管理セキュリティーを有効にするとユーザー名を確認できる
OFF ログ取得
可能？
管理
セキュリティー
ON
そのまま
ログアウト
ログ取得
可能？
操作変更
ログ取得
可能？
構成変更
ログ取得
可能？
45
WAS V6.1にて実施できるセキュリティー監査機能についてご説明致します。
セキュリティー監査ログは、activity.logおよび該当サーバーのSystemOut.logに出力されます。監査
対象は、すべての構成変更と起動・停止などの操作コマンドです。これについては管理セキュリ
ティーが無効でもデフォルトでロギングされます。また、ログに記録される監査メッセージは、構成変
更の監査にはADMRxxxxI 、操作監査にはADMN10xxｘｘI というメッセージ IDが付きます。xxxxは
メッセージ番号です。さらに、ユーザー名をログに出力するには、管理セキュリティーを有効にする
必要があります。構成変更のユーザー名は、ノードエージェントの場合、
「ユーザー defaultWIMFileBasedRealm/server:IBM-69F48DB266CCell01_IBM69F48DB266CNode02_nodeagent」という出力になります。
操作の変更のユーザー名はログイン・ユーザー名が出力されます。
また、すべてのログイン・ユーザーについて管理コンソールにログインした時点でそのユーザー名を
記録することは出来ません。何らかの構成変更または操作を行った場合、ユーザー名を含めてロギ
ングすることが出来ます。（ユーザー名を表示するためには、管理セキュリティーを有効にする必要
があります。）
WAS V6.1 InfomationCenter - 「管理監査」
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.d
oc/info/ae/ae/ragt_radminrepos.html
WAS V7.0 InfomationCenter - 「管理監査」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.d
oc/info/ae/ae/ragt_radminrepos.html
45
WAS V7.0 取得可能監査イベント一覧（1/2）
„
以下のイベントに対して監査ログを取得可能 (2009年3月現在)
イベント名
注意
監査取得対象
SECURITY_AUTHN
全ての認証を記録
SECURITY_AUTHZ
全ての認可を記録（管理ロールの確認のみ、アプリケーション･ロール
は含まない）
SECURITY_AUTHN_CREDS_MODIFY
特定のユーザー IDのクレデンシャルを記録する
SECURITY_AUTHN_TERMINATE
認証セッションの終了を記録（任意のログアウトやタイムアウト等によ
るログアウト）
SECURITY_AUTHN_DELEGATION
権限委譲を記録 (WAS V7.0ではRunAS処理のみ)
SECURITY_AUTHN_MAPPING
Trust Association Interceptor、J2EE Connector(J2C)、Java
Authentication and Authorization Service(JAAS)処理を記録
SECURITY_ENCRYPTION
Webサービスの暗号化情報を記録 (※)
SECURITY_MGMT_AUDIT
監査の開始、停止などセキュリティー監査サブシステム操作を記録
SECURITY_MGMT_CONFIG
WASの管理・構成操作を記録
SECURITY_MGMT_POLICY
アクセス制御リストの作成等のセキュリティー・ポリシー操作を記録
SECURITY_MGMT_RESOURCE
ファイル、Webページ等のリソース属性の作成、削除といったリソース
管理を記録
SECURITY_RESOURCE_ACCESS
Webページやデータベースなどリソースに対する全てのアクセスを記録
46
Webサービスの署名操作を記録 (※)
SECURITY_SIGNING
上表は、2009年3月時点(WASV7.0 FP3環境)で取得できる監査イベント一覧になります。((※)は
WAS V7.0 FP5から取得できる予定です。)上記以外のイベントも存在し設定することが可能ですが、
現時点では何も出力されませんのでご注意下さい。これは製品バグという訳ではなく、WASに監査
計測機能があるのですが、その機能を使用するコンポーネントが存在していないというのが理由で
す。従いまして、上表を参考にして、セキュリティー要件から取得すべきイベント名を絞り込んで下さ
い。
WAS V7.0 InformationCetner - 「監査可能なセキュリティー・イベント」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.m
ultiplatform.doc/info/ae/ae/rsec_sa_event_types.html
WAS V7.0 InformationCetner - 「スクリプトによる監査イベント・ファクトリーの構成」
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.nd.m
ultiplatform.doc/info/ae/ae/txml_7auditeventfactory.html
46
WAS V7.0 取得可能監査イベント一覧（2/2）
„
イベントに対する結果を指定する
結果名
説明
SUCCESS
対象イベントが成功したときに記録
FAILURE
対象イベントが失敗したときに記録
REDIRECT
対象イベント発生時にリダイレクトが発生したときに記録（例： SECURITY_AUTHNイ
ベントが発生し、ログインページやエラーページにリダイレクトする）
DENIED
対象イベントが拒否されたときに記録（例： リソースアクセス時に適切な権限がない）
ERROR
対象イベントでエラーが発生したときに記録
WARNING
対象イベントでワーニングが発生したときに記録
„
設計指針
‹
„
パフォーマンスへの影響を考慮し、イベント名と結果名にて取得項目を絞る
監査ログ結果のHTML化
‹
バイナリーファイルであるため、Audit ReaderでHTML形式に変換して内容を確認する
AdminTask.binaryAuditLogReader(‘[-fileName
AdminTask.binaryAuditLogReader(‘[-fileName<<監査ログファイル名
監査ログファイル名>>- outputLocation
出力先ファイル名>> -reportMode
-reportModecomplete
complete]')]')
outputLocation <<出力先ファイル名
47
セキュリティー監査設定方法は、「セキュリティー設計-参考-」のP.22～ P.25をご参照下さい。
さらに、設定した監査イベントに対して、どの結果を取得するかを設定する必要があります。
監査ログを取得量が多いほどパフォーマンスへの影響がありますので、前項のイベント名と結果名
にて取得項目を出来る限り絞り込むことを検討して下さい。
監査ログはバイナリーファイルであるため、出力をHTML形式に変換するAudit Readerツールが提供
されています。 Audit Readerはwsadminコンソールより起動します。
47
例：管理コンソールログイン・ログアウト
„
セキュリティー要件
‹
管理コンソールにログイン・ログアウトしたユーザー情報を取得したい
¾
¾
¾
„
ケース1：正常にログインできた場合
ケース2：不正にログインした場合 (存在しないユーザー、パスワード間違い)
ケース3：正常にログアウトした場合
監査イベント/監査結果の設定
イベント名
監査取得対象
SECURITY_AUTHN
全ての認証を記録
SECURITY_AUTHN_TERMINATE
認証セッションの終了を記録（任意のログアウトやタイムアウト等によるログアウト）
SECURITY_RESOURCE_ACCESS
Webページやデータベースなどリソースに対する全てのアクセスを記録
結果名
説明
SUCCESS
対象イベントが成功したときに記録
REDIRECT
対象イベント発生時にリダイレクトが発生したときに記録（例： SECURITY_AUTHNイベントが発生し、ロ
グインページやエラーページにリダイレクトする）
/loginError.jspへリダイレクトする設定を事前に行う
48
管理コンソールにログイン・ログアウトした時の監査ログ取得例をご紹介致します。
48
ケース1：管理コンソールログイン・ログアウト結果
„
正常にログインできた場合の監査ログ出力
‹
監査イベント：SECURITY_AUTHN、監査結果：SUCCESSの出力を確認する
結果、成功
この時間に
フォームログイン処理
を実施
管理コンソールに対して
ユーザー：noguchiが
49
正常に管理コンソールにログインできた場合には、上記のような出力になります。
49
ケース2：管理コンソールログイン・ログアウト結果
„
不正にログインした場合の監査ログ出力
‹
監査イベント：SECURITY_AUTHN、監査結果：REDIRECTの出力を確認する
この時間に
フォームログイン処理
を実施
結果、リダイレクトされた
管理コンソールに対して
ユーザー：noguchiが
‹
監査イベント：SECURITY_RESOURCE_ACCESS、監査結果：SUCCESSの出
50
力にて、loginError.jspが表示されたことが確認できる
不正に管理コンソールにログインした場合には、上記のような出力になり、/loginError.jspにリダイレ
クトされます。
50
ケース3：管理コンソールログイン・ログアウト結果
„
正常にログアウトした場合の監査ログ出力
‹
監査イベント：SECURITY_AUTHN_TERMINATE、監査結果：SUCCESSの出力
を確認する
結果、成功
この時間に
フォームログアウト処
理を実施
管理コンソールに対して
ユーザー：noguchiが
51
正常に管理コンソールからログアウトできた場合には、上記のような出力になります。
51
まとめ・参考文献
52
52
まとめ
„
WAS V7.0にて実現できる、Webシステムの脅威に対する対
応策
‹
ハードニング
‹
認証
¾
¾
‹
„
SSL、証明書
監査
¾
„
管理ロール、Fine-grained管理セキュリティー
暗号化 / 署名
¾
‹
グローバル・セキュリティー、複数セキュリティー・ドメイン、シングルサインオン
(SSO)
認可
¾
‹
ゾーニング、コンポーネントの制限、非rootユーザー稼動、IHSセキュリティー対策
セキュリティー監査
セキュリティー強化 ≠ ユーザーの利便性向上
セキュリティー強化 ≠ パフォーマンス向上
53
当セッションでは、WAS V7.0にて実現できるWebシステムの脅威に対する対応策をご説明致しまし
た。
繰り返しになりますが、一般的にセキュリティーを強化するほど、システムのパフォーマンスやユー
ザーの利便性は低下します。例えば、監査ログは取得イベントが多くなるほど、ファイル出力量が増
え、結果としてI/O負荷が高くなりパフォーマンスが低下します。また、認証・認可の設定を細かく設
定すればするほど、運用負荷が高まります。従いまして、セキュリティー設定は、保護対象や保護対
象に対する脅威を明確にし、システム・パフォーマンスやユーザーの利便性を考慮した上で、必要
最小限の設定を行うようにして下さい。
53
参考文献
„
Information Center
‹
WebSphere Application Server V7.0
¾
„
ワークショップ資料
‹
WebSphere Application Server V7 アナウンスメント・ワークショップ
‹
WebSphere Application Server V6.1による基幹システム設計ワークショップ
¾
¾
„
http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp
http://www.ibm.com/developerworks/jp/websphere/library/was/was7_ws/
http://www.ibm.com/developerworks/jp/websphere/library/was/was61_guide/index.html
Redbook
‹
IBM WebSphere Application Server V6.1 Security Handbook
¾
http://w3.itso.ibm.com/itsoapps/Redbooks.nsf/RedbookAbstracts/sg246316.html?Open
54
54