WebSphere Application Server のセキュリティーに関するよくある質問(FAQ)

処理環境の完全性が危険にさらされるため、セキュリティーに関する質問には、可能な限り早く答える必要があります。そのために、この記事では、IBM WebSphere Application Server のセキュリティーに関する最もよくある質問の一部に対して、簡潔かつ直接的な回答を示しています。

Keys Botzum, Senior Technical Staff Member , MapR Technologies

Keys Botzum 氏IBM Software Services for WebSphere の上級テクニカル・スタッフ・メンバーです。大規模分散システムの設計に 10 年以上携わっており、セキュリティーの専門家でもあります。使用経験のある分散テクノロジーは、Sun RPC、DCE、CORBA、AFS、DFS など多岐にわたります。最近は、J2EE および関連テクノロジーの研究を行っています。Stanford University でコンピューター・サイエンスの修士号を取得しており、Carnegie Mellon University で応用数学/コンピューター・サイエンスの理学修士号を取得しています。 Botzum 氏は WebSphere および WebSphere セキュリティーに関する論文を多数出版している他、記事や発表も http://www.keysbotzum.com ならびに IBM developerWorks WebSphere に掲載されています。『IBM WebSphere: Deployment and Advanced Configuration』(Bill Hines との共著) の著者でもあります。


developerWorks
        プロフェッショナル著者レベル

Bill O'Donnell, Lead WebSphere Security Architect, IBM

Bill O'Donnell is the Lead WebSphere Security Architect working in the WebSphere product development organization. He is responsible for the security architecture for WebSphere Application Server. Bill has has over 25 years experience in large scale mainframe and distributed system with a unique focus on development architecture and infrastructure architecture. Bill specializes in end to end infrastructure and application security. He has published a number of Redbooks and is the author of the Secrets of SOA. Bill is a co-sponsor of the WebSphere Application Server security web site.



2014年 6月 05日

重要なよくある質問

アプリケーション・サーバーのセキュリティーといった重要なテーマにおいては、非常に重要な質問が大量に生じています。IBM WebSphere Application Server のセキュリティー全般について、また、セキュリティーを環境に適用する (または適用すべき) 方法について理解を深められるように、最もよくある質問の一部を紹介します。別途記載がない限り、WebSphere Application Server V6.1 以降に該当します。

以下の一覧で紹介する質問と回答は、大まかに 3 つのカテゴリーに分かれています。


レジストリー

1. WebSphere Application Server がレジストリーのユーザー情報にアクセスするのはどのタイミングですか。

WebSphere Application Server は、ユーザー情報を確認するため、および管理操作のためにレジストリーを照会します。そのため、WebSphere Application Server セルが機能するには、レジストリーがほぼ 100% 使用可能である必要があります。

WebSphere Application Server がレジストリーにアクセスする理由を以下に示します。

  • ユーザーが認証を行うとき (パスワードまたは証明書。Web SSO プロキシーでは不要)。WebSphere Application Server は、以下を行うタイミングでレジストリーを照会する可能性があります。
    • ユーザーのパスワードの検査
    • 証明書情報とユーザー ID とのマップ
    • ユーザー ID をレジストリー固有のID (LDAP DN など) に変換
    • グループ情報の取得
  • LTPA トークンがサーバーに初めて渡されるとき。Lightweight Third Party Authentication (LTPA) トークンにはユーザーの識別名 (DN) しか含まれていないため、WebSphere Application Server は、(WebSEAL やIIOP トラフィックなどによって) LTPA トークンがサーバーに初めて渡されるときも、やはりグループ情報を取得します。トラスト・アソシエーション・インターセプター (TAI) でも、通常はユーザー ID しか提供されないため、同様のことが当てはまります。WebSphere Application Server V5.1.1 を使用しており、かつサブジェクトの伝搬が有効になっており、さらに (WebSphere Application Server V5.1.1 の新しい WebSEAL TAI で可能なように) TAI またはログイン・モジュールによってグループ情報が提示される場合、WebSphere Application Server は LDAP にそのユーザーのユーザー・グループ情報を照会しません。
  • サブジェクトの伝搬プロパゲーションに失敗した場合。サブジェクトの伝搬が有効になっている場合でも、サブジェクトの伝搬が失敗する場合 (サーバーがダウンしている場合など)、WebSphere Application Server は、カスタム・キャッシュ・キーが設定されている場合を除き、サブジェクトの再作成を試行します。
  • ユーザーが管理操作に対する認証を行うとき (Web、JMX など)。
  • アプリケーションが起動するとき (毎回)。ロール・バインディングがレジストリーに照らして検証されます。
  • 管理コンソールで管理者がバインディング情報を設定するとき (毎回)。

2. WebSphere Application Server は NIS と連携しますか。

WebSphere Application Server は、認証に対して NIS (Network Information Service) を直接サポートしていません。LDAP、OS、およびカスタムがサポートされます。UNIX オペレーティング・システム上で実行されている場合、WebSphere Application Server は、ユーザー・パスワードの検証に標準の UNIX パスワード API (getpw* など) を使用します (これが機能するには、WebSphere Application Server を root として実行する必要があります)。それらの API が NIS に対して呼び出しを行う場合、WebSphere Application Server は認証に NIS を使用することになりますが、これは WebSphere Application Server からは透過的に行われます。ただし、UNIX 上で OS レジストリーが使用されている場合、マルチノード・セルはサポートされません。

NIS を使用するようなカスタム・レジストリーを記述することも可能です。

ほとんどの場合、この質問に対する回答は「いいえ」となります。

3. Windows 環境で、非管理者アカウントを使用してセキュリティーをオンにしたい場合、どうすればよいですか。

WebSphere Application Server プロセスを非管理者として実行しているときに、グローバル・セキュリティーが有効になっている場合、ユーザー・レジストリーは LDAP またはカスタム・レジストリーのいずれかにする必要があります。

ローカル OS ユーザー・レジストリーを使用するには、ユーザーおよびグループ情報を認証または収集する Windows オペレーティング・システム API を呼び出すために、製品プロセスを実行するユーザーに管理特権および「オペレーティング システムの一部として機能」特権がある必要があります。このプロセスには、これらの特権によって付与される特殊権限が必要です。ここでの例におけるユーザーは、セキュリティー・サーバー ID と同じであってはなりません (ユーザーの要件は、レジストリー内の有効なユーザーです)。このユーザーは、マシン (コマンド・ラインを使用して製品プロセスを開始している場合) またはサービス・パネルの「ログオン・ユーザー」設定 (製品プロセスがサービスを使用して開始されている場合) にログインします。マシンがドメインにも属している場合、ドメイン内のオペレーティング・システム API を呼び出すには、このユーザーは、ローカル・マシンの「オペレーティング システムの一部として機能」特権があることに加えて、ドメイン内の Domain Admins グループに属している必要があります。

4. UNIX 環境で、非 root サーバー ID を使用してセキュリティーをオンにしたい場合、どうすればよいですか。

WebSphere Application Server を非 root として実行しているときに、グローバル・セキュリティーが有効になっている場合、ユーザー・レジストリーは LDAP またはカスタム・レジストリーのいずれかにする必要があります。

ローカル OS ユーザー・レジストリーを使用するには、製品プロセスを実行するユーザーに root 特権がある必要があります。この特権は、ユーザーおよびグループ情報を認証または収集する UNIX オペレーティング・システム API を呼び出すために必要です。このプロセスには、root 特権によって付与される特殊権限が必要です。ローカル OS ユーザー・レジストリーを使用するには、root として実行されるノード・エージェント、デプロイメント・マネージャー、およびアプリケーション・サーバー・プロセスが必要です。

5. 分散環境で、ローカル OS 認証は機能しますか。

アプリケーション・サーバー・ノードが複数の物理マシンに分散している WebSphere Application Server Network Deployment では、ローカル OS 認証を使用できません。この環境では、LDAP またはカスタム・レジストリーのいずれかを使用する必要があります。ただし 1つ例外があります。Windows ドメイン・レジストリーは集中レジストリーであり、この状況で使用できます。NIS は技術的には集中レジストリーですが、WebSphere Application Server Network Deployment での使用には適していないことに注意してください。

詳細情報は、インフォメーション・センターの次の項目を参照してください。ローカル・オペレーティング・システムのレジストリー

6. 複数のユーザーが 1 つのユーザー ID を使用して認証を行っていますが、LDAP からの別の ID を使用してユーザーを識別する必要があります。これは可能ですか。

まさにそれを行うように WebSphere Application Server を構成する方法があります。これは、各ユーザーの LDAP エントリーに、2 つ目のユーザー ID として使用できる文字列を含む属性があることを前提としています。たとえば、この属性を myname としましょう。また、認証に使用されるユーザー ID が、uid と呼ばれる LDAP 属性に含まれていると仮定しましょう。

WebSphere Application Server の LDAP 構成画面で、「ユーザー ID マップ」フィールドを「*:uid」から「*:myname」に変更します。これは基本的に、WebSphere Application Server に、アプリケーションに返される J2EE プリンシパルを myname LDAP 属性の値に設定するよう指示します。WebSphere Application Server は通常、ログオンに使用されたものと同じユーザー ID を返します。

例として、ユーザーの LDAP エントリーに次の属性/値のペアがあるとします。uid=dale.sue.ping、myname=sueping

上記のように WebSphere Application Server の LDAP 構成を変更すると、ユーザーは dale.sue.ping というユーザー ID でログオンして、WebSphere Application Server/LDAP で認証を行い、認証が成功した場合、WebSphere Application Server は J2EE プリンシパルを sueping に設定します。
アプリケーションに J2EE プリンシパルを抽出する機能がある場合、アプリケーションではユーザーが「dale.sue.ping」ではなく「sueping」として表示されます。

7. 統合リポジトリーを使用している場合、LDAP サーバーがダウンしているときにファイル・ベースのレジストリーが引き続き機能するようにする方法はありますか。

はい、引き続き稼働および機能しているいずれかのレジストリーに ID が含まれているかぎり、1 つ以上の他のレジストリーがダウンしている場合に認証の継続を可能にする構成オプションがあります。これを許可するための統合リポジトリー構成コマンドは以下のとおりです。

$AdminTask updateIdMgrRealm -name <byRealmName> -allowOperationIfReposDown true

詳細情報は、インフォメーション・センターの次の項目を参照してください。AdminTask オブジェクトの IdMgrRealmConfig コマンド・グループ


認証

8. WebSphere Application Server アプリケーションでフォーム・ベースのログインを使用しているときに、SSO を有効にする必要があるのはなぜですか。

SSO を有効にすると、WebSphere Application Server はユーザーの状態を、すべての Web 要求にわたる LTPA Cookie として維持します。SSO が有効になっていない場合、個々の要求のたびに認証が必要です。フォーム・ベースのログインを使用する場合、フォームでの認証が完了すると、ユーザーは当初要求された URL にリダイレクトされます。SSO を利用しない場合、ユーザーの認証情報はこの時点で失われ、許可に失敗します。基本認証を使用している場合は、すべての HTTP 要求に認証情報が含まれており、WebSphere Application Server が必要な場合にいつでもこれを利用できる (これは、セキュリティーとパフォーマンスの両方に影響します) ため、この現象は発生しません。

9. 設定した「非アクティブ・タイムアウト」期間の経過後に、ユーザーに強制的に再度ログインさせる必要があります。WebSphere Application Server は、セッション・タイムアウトおよび LTPA タイムアウトに関して、どのように機能しますか。

WebSphere Application Server の LTPA トークンは、非アクティブ状態ではなく、ログイン・セッションの存続期間に基づいて有効期限が切れます。そのため、WebSphere Application Server のログイン・セッションは、ユーザーが一定期間操作を行わない場合でも有効期限が切れません。一方、HTTPSession は非アクティブ状態に基づいて有効期限が切れます。アプリケーションで、アイドル状態に基づいてアプリケーション使用の有効期限が切れるようにする必要がある場合は、アプリケーションでこの処理を明示的にコーディングする必要があります。ユーザーが、セッションの有効期限が切れた状態で (実際には新しいセッションで) アクセスする場合をキャプチャーし、必要と考えられる場合に強制的に再度ログインさせることができます。これを行うと、アプリケーション間のシングル・サインオンが妨げられることに注意してください。

1 つ目と多少異なる 2 つ目のアプローチは、HTTPSession.getLastAccessTime() を使用して、最後のクライアント要求が行われた時刻を計算することです。その時刻から時間が経過しすぎている場合は、もちろん、アクセスを失敗させて新しい認証を強制できます。

これらのアプローチはいずれも、サーブレット・フィルターの使用によって、アプリケーション・コードに対して透過的にすることができます。

IBM Tivoli Access Manager では、存続期間、および、アイドル状態に基づいた認証セッションのタイムアウトをサポートしています。

WebSphere Application Server がこのような形で動作する理由についてよく質問を受けます。アイドル状態のログイン・セッションがタイムアウトにならないのはなぜでしょうか。それは、WebSphere Application Server が本質的に、疎結合の分散システムであるためです。SSO ドメインに参加するアプリケーション・サーバーは、お互いに通信する必要はありません。さらに、同じセル内に存在する必要さえありません。そのため、LTPA トークン (別名 SSO トークン) のアイドル状態での存続時間を制限したい場合、すべての要求において (または、場合によっては、1 分のインターバルの間に最初に発生した要求において) トークン自体を最後の使用時間で更新する必要があります。つまり、トークン自体が頻繁に変わる (つまり、ブラウザーが新しい Cookie を頻繁に受け入れる) ということ、そして、妥当性検査が行われるとみなされる場合には、WebSphere Application Server はそのインバウンド・トークンの暗号化解除および確認を行う必要があるということです。これにはコストがかかる可能性があります (現行の WebSphere Application Server は、各アプリケーション・サーバーでの初回使用時にのみトークンの妥当性検査を行います)。これらの問題を巧みなキャッシングなどで解決することも不可能ではありませんが、現行の WebSphere Application Server はそのようには動作しません。

10. セル間で LTPA 鍵が同期しなくなることを防ぐために、何かできることはありますか。

はい。WebSphere Application Server V6.1 では、LTPA 鍵の自動再生成をデフォルトで有効にする機能が導入されました。単純なセル構成に対しては非常にすばらしい機能なのですが、複数のセルを持ち、セル間で LTPA 鍵を同期する必要があるユーザーは LTPA の自動再生成機能をオフにします。WebSphere Application Server V7 では、この機能はデフォルトでオフになっています。また、V6.1.0.23 以降で作成される新しいプロファイルについては、この機能はデフォルトでオフになっています。

11. WebSphere Application Server セルは、複数の DNS ドメインにまたがることはできますか。

WebSphere Application Server V6 より前のバージョンでは、その答えは「いいえ」でした。これは、WebSphere Application Server のセキュリティーを構成する際に、指定が必要な項目の 1 つに LTPA トークンの SSO ドメインが含まれていたためです。その項目が空白のままの場合、LTPA トークン/Cookie ドメインは空白に設定されたため、Cookie は同じホストにしか再度適用されませんでした。値を指定した場合、Cookie ドメインはその値に設定され、Cookie が同じ DNS ドメイン内のホストに再度適用されます。これは、HTTP 仕様によって求められる動作です。問題は、セル (実際には Web サーバー) で複数の DNS ドメインの要求に対応する場合に、複数のドメインを指定する方法がなかったことです。WebSphere Application Server V6 以降、WebSphere Application Server に対して指定される SSO ドメインの値に、複数の DNS ドメインを含めることができます。ここで、必要なすべてのドメインを指定します。WebSphere Application Server が Cookie を作成する場合、Cookie のドメイン値 (HTTP 仕様では 1 つの値のみが許可されています) を、構成されたドメインのいずれかに一致するインバウンド要求からの値に設定します。

有効なドメイン名の例は、ibm.comtx.gov です。無効なドメイン名の例は、ibmusstate_tx.gov です。一部のユーザーでは、Internet Explorer (IE) で問題が発生しています。つまり、SSO ドメイン・フィールドで定義されているドメインが 5 文字未満 (ピリオドを除く。「cn.ca」など) の場合、IE 5 と IE 6 は LTPA トークンを受け入れないように見えます。Microsoft は、この点に関する修正を用意しています。

12. SWAM の使用が推奨されていないのはなぜですか。

Simple WebSphere Authentication Mechanism (SWAM) は、分散環境ではない、シンプルな単一のアプリケーション・サーバー・ランタイム環境を対象としています。単一のアプリケーション・サーバーに制限されているのは、転送可能な資格情報を SWAM がサポートしていないためです。つまり、あるアプリケーション・サーバー・プロセスのサーブレットまたはエンタープライズ Bean が、別のアプリケーション・サーバー・プロセスに存在するエンタープライズ Bean のリモート・メソッドを呼び出した場合、呼び出し元の ID が 2 つ目のサーバー・プロセスに送信されないということです。送信されるのは、非認証の資格情報です。EJB メソッドで構成されているセキュリティー権限によっては、このために許可が失敗する場合があります。

SWAM は、WebSphere Application Server のBaseエディションにおける認証メカニズムとして使用できます。SWAM は、WebSphere Application Server Network Deployment V5.0 以降、サポートされているオプションではありません。さらに、ユーザーの状態を維持する上で HTTP セッション・オブジェクトに依存している (HTTP セッション層がセキュリティー・インフラストラクチャーに含まれていないため、問題になります) ため、Base エディションでの使用も推奨されていません。

13. ID 情報の通知には、カスタム・ログイン・モジュールと TAI のどちらを使用すべきですか。

注:WebSphere Application Server 以外の何らかの認証システムによって、ユーザーがすでに認証されている場合、ユーザーに再認証を求めるのではなく、ユーザーの ID 情報を WebSphere Application Server に通知することが可能です。これは ID アサーションと呼ばれています。TAI との関連における ID アサーションの詳細については、「Advanced authentication in WebSphere Application Server」を参照してください。

表 1. ログイン・モジュールと TAI
機能ログイン・モジュールTAI
IBM 固有いいえ。ただし、WebSphere Application Server 固有のコードが必要はい
使いやすさ比較的困難比較的容易
複数フェーズ認証いいえはい
Web ログイン・チャレンジの抑制いいえはい
Web 呼び出しに使用可能はいはい
RMI 呼び出しに使用可能はいいいえ
伝搬ログインでの (再) 呼び出しはいいいえ

セキュリティーに関するその他の質問

14. 停止させずにパスワード (データベースや LDAP など) を変更するにはどうすればよいですか。

  1. ユーザー ID のペア (useridAuseridB など) を交互に使用します。現在は useridA を使って実行していると仮定します。
  2. useridB に新規パスワードを設定します。
  3. useridA のすべての使用箇所を、新しいパスワードを設定した useridB に変更します。ここで適切な文書を残しておくと役に立ちます。
  4. クラスター内の各サーバーを順に再起動して、常に1 つのノードは実行されているようにします。
  5. useridA に新しいパスワードを設定します。ステップ 3 で何か見落とした場合には問題が発生しますが、その他の正しく変更された箇所には影響しません。
  6. 次回パスワードを変更するときに、useridB から元の useridA に切り替えます。

移行中に両方のユーザー ID/パスワードの組み合わせが有効であるため、同期について意識する必要はありません。

15. J2EE セキュリティーに対するWebSphere Application Server の独自拡張にはどのようなものがありますか?

  • LTPA トークンは非標準ですが、単なる資格情報/トークンであり、アプリケーション開発チームには影響を与えません。
  • ユーザーがログアウトした際に LTPA トークンを削除するための、ibm_security_logout URL へのリダイレクト。
  • WSSubject、WSCredential、および WSPrincipal は、標準の J2EE Subject、Credential、および Principal クラスに対する IBM 拡張です。これらは、標準のクラスに不足があるため、場合によっては必要になります。
  • トラスト・アソシエーション・インターセプター (TAI) は、多くの場合、SSO プロキシー (WebSEAL、ClearTrust、Siteminder など) を使用する WebSphere Application Server インターフェースで使用されます。これも単なる認証レイヤーであり、アプリケーションのポータビリティには影響を与えません。ただし、別の J2EE コンテナーに移動する場合は、SSO プロキシーと WebSphere Application Server との間に同様のインターフェースが提供されるようにする必要があります。開発者が SSO プロキシー固有の API を使用している場合は注意してください。
  • カスタム・ユーザー・レジストリー (CUR) も、標準の WebSphere Application Server レジストリー・タイプ (オペレーティング・システム、LDAP) のいずれかを使用していないか、それらを非標準の方法で使用しているユーザー向けの単なる統合レイヤーです。
  • Java 2 セキュリティー・ポリシー・ファイルには、標準に対するいくつかの小さい拡張が含まれています。これらもインフラストラクチャーであり、アプリケーション・コードの一部ではありませんが、was.policy ファイルは EAR ファイルに含まれています。
  • WebSphere Application Server 管理 API は、アプリケーションから呼び出すことができるように API の形式で使用可能な、WebSphere Application Server 管理機能です。このうち一部は JMX 標準を使用して実行できますが、それ以外の API は WebSphere Application Server 固有です。これらをビジネス・アプリケーションで使用することはまずありません (また禁止されるべきです) が、万一、管理アプリケーションを作成している場合はこれらに留意してください。
  • wsadmin スクリプトも技術的にはビジネス・アプリケーションに含まれませんが、管理機能用に書かれたスクリプトは、別の製品に移植する場合に書き直す必要があることに留意してください。デプロイのようなタスクでは、オープン・スタンダードである Ant などを使用するのが最適です。WebSphere Application Server、IBM WebSphere Studio Application Developer、および IBM Rational Application Developer に付属する Ant コマンドの一部は IBM 固有であることに注意してください。

また、コマンド用 dynacache API など、セキュリティーの一部に該当しない利用可能なその他の固有 API、および Java オブジェクト・キャッシング、JMS 以外の WebSphereMQ 呼び出しなどがあることに留意してください。

16. WebSphere Application Server では CA Siteminder がサポートされますか。

WebSphere Application Server では、(WebSphere Application Server 以外の) ベンダーのセキュリティー・プロバイダーに認証を委任する、トラスト・アソシエーション・インターセプター (TAI) と呼ばれるセキュリティー認証プラグ・ポイントが提供されます。そのように採用されている一般的な製品の例としては、IBM Tivoli Access Manager、CA Siteminder、RSA Clear Trust があります。これらすべての製品により、WebSphere Application Server TAI プラグ・ポイントを活用する独自の実装と、その実装がそれらのソリューションで機能することが保証されます。

たとえば、Siteminder は WebSphere Application Server 用の TAI を開発および販売しています。CA は、Siteminder と、Siteminder の WebSphere Application Server との統合用に設計および開発する TAI のサポートを行います。WebSphere Application Server の観点からは、これらの製品のいずれも使用できますが、生じるすべての質問や問題は、ベンダー (Siteminder の場合の CA など) を通じて対処される必要があります。IBM 製品を利用するときに、ユーザーは CA に対して、Siteminder を使用し、そのサポートを受けるためのライセンス料金を支払います。IBM には、Siteminder、Siteminder TAI、またはすべての Siteminder アクセサリーを修正する手段も責任もありません。

トラスト・アソシエーション・インターセプターに加えて、WebSphere Application Server では、カスタム・ユーザー・レジストリー、JAAS、および JACC といった、活用可能な追加のプラグ・ポイントが提供されます。重要なのは、サポートの境界がプラグ・ポイントにある点を理解することです。設計上、WebSphere Application Server ではプラグ・ポイントまでがサポートされ、そのソリューションと連携するように設計されたプラグ・ポイントの実装は実装者 (Siteminder など) が担当します。

17. WebSphere Application Server は、パスワードを XOR エンコードされた状態で格納します。さらに強力なものを使用したいのですが、どうすればよいですか。

WebSphere Application Server V6.0.2 より前のバージョンでは、一般に、できることはほとんどありませんでした。WebSphere Application Server で J2C リソースのパスワードが格納される方法を変更したい場合、WebSphere Application Server の外部にあるソースからパスワードを取得するための独自のカスタム J2C ログイン・モジュールを作成することもできましたが、この方法は WebSphere Application Server で使用されるその他のパスワード (LDAP バインドや WebSphere Application Server 管理者など) については有効ではありませんでした。

WebSphere Application Server V6.0.2 から、適切と思われる保護を実装可能な独自のカスタム・パスワード・エンコーダーを構成できるようになりました。これを行うには、プラグイン・インターフェース (com.ibm.wsspi.security.crypto.CustomPasswordEncryption) を実装してから、security.xml に 2 つのカスタム・セキュリティー・プロパティーを指定します。これらは、PropFilePasswordEncoder.bat/sh に設定することも可能です。2 つのプロパティーは以下のとおりです。

  • com.ibm.wsspi.security.crypto.customPasswordEncryptionClass
  • com.ibm.wsspi.security.crypto.customPasswordEncryptionEnabled.

詳細については、インフォメーション・センターの次の項目を参照してください。カスタム・パスワード暗号化のプラグ・ポイント

18. Java 2 セキュリティー例外および AccessControlExceptions をデバッグするにはどうすればよいですか。

主に、WebSphere の SystemOut.log ファイルと com.ibm.websphere.java2secman.norethrow プロパティーの 2 つが役立ちます。SystemOut.log ファイルに記録される AccessControlException には、例外の原因となった権限違反、例外の呼び出しスタック、および各スタック・フレームに付与された権限が含まれています。通常、権限の不足や権限が必要なコードを判別するには、この情報で十分です。

WebSphere Application Server で Java 2 セキュリティーが有効になっている場合、権限違反が発生すると、セキュリティー・マネージャー・コンポーネントが java.security.AccessControl 例外をスローします。この例外が処理されないと、多くの場合、ランタイム・エラーが発生します。この例外は、SystemOut.log ファイルにも記録されます。

ただし、JVM の com.ibm.websphere.java2secman.norethrow プロパティーが設定され、その値が true である場合、セキュリティー・マネージャーは AccessControl 例外をスローしません。この情報はログに記録されます。

サーバーの com.ibm.websphere.java2secman.norethrow プロパティーを設定するには、WebSphere Application Server 管理コンソールに移動し、「サーバー」>「WebSphere Application Servers」を選択します。「プロセス定義」>「Java 仮想マシン」>「カスタム・プロパティ」>「新規作成」をクリックします。「名前」フィールドに、「com.ibm.websphere.java2secman.norethrow」と入力します。「値」フィールドに、「true」と入力します。

19. WebSphere Application Server における Microsoft Active Directory の最適な構成方法についての文書はありますか。

はい。このほど、IBM Software Services for WebSphere チームによる他のお客様での経験に基づいて、いくつかの役立つヒントを追加しました。「Using Microsoft Active Directory with IBM WebSphere Application Server」ホワイト・ペーパーを参照してください。

20. J2C 別名構成からパスワードをプログラムで取得するにはどうすればよいですか。

WebSphere Application Server 構成の J2C 別名からユーザー ID およびパスワードをプログラムで取得するには、以下のサンプルを使用できます。DefaultPrincipalMapping LoginContext には、2 つの引数が必要です。

  • パスワードを取得したい別名を (間接的に) 含む WSMappingCallbackHandler。
  • ログイン構成の LoginModules login() メソッドを介して変更される Subject。

WSMappingCallbackHandler が WebSphere Application Server セキュリティー構成から別名のパスワードを取得し、ログイン・モジュールがそれを Subject の PasswordCredential にコピーします。

リスト 1. WebSphere Application Server 構成における J2C 別名からのパスワードの取得
//* Imports needed for this sample
import javax.security.auth.callback.CallbackHandler;
import java.util.Map;
import java.util.HashMap;
import java.util.Set;
import com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory;
import javax.security.auth.Subject;
javax.security.auth.login.LoginContext;

//* Coding example — try/catch blocks have been omitted
Map map = new HashMap();
map.put(Constants.MAPPING_ALIAS, alias);
//create a callback handler with the specified property (to find the alias)
//and null for the managed connection factory (MCF) since we don't need it
CallbackHandler handler = WSMappingCallbackHandlerFactory
				.getInstance().getCallbackHandler(map, null);
Subject subject = new Subject();
LoginContext lc = new LoginContext("DefaultPrincipalMapping", subject, handler);
lc.login();
subject = lc.getSubject();

Set pwdCredentialSet = subject.getPrivateCredentials(PasswordCredential.class);

PasswordCredential cred = (PasswordCredential)  pwdCredentialSet.iterator().next();
String password = null;
String userid = null;
if (cred != null) {
		password = new String(cred.getPassword());
		userid = cred.getUserName();
} else {
		out.println("No password credential");
}

21. WebSphere Application Server では、Microsoft の NTLM がサポートされていますか。

WebSphere Application Server と、WebSphere Application Server 上で実行されるその他の IBM 製品 (WebSphere Portal など) では現在、NTLM (NT LAN Manger) がサポートされていません。IBM も Microsoft も、使用されているアプリケーション・プロトコルに応じて、基本認証、相互認証、および何らかの形の SAML または Kerberos の使用をサポートしています。

さらに、NTLM を使用した完全なソリューションの開発に関して技術的な課題および制限があることから、WebSphere Application Server で NTLM をサポートする予定はありません。手短に言えば、NTLM は Microsoft のクローズド HTTP トランスポート・セキュリティー・プロトコルです。Microsoft プラットフォーム上で動作する Web アプリケーションに認証、完全性、および機密性を提供し、Microsoft ネットワーキング環境内でのみ機能するように設計されています。Microsoft は、NTLM の使用が推奨されなくなった旨の記述も公開しています。

Microsoft は、NTLM に代わるものとして、基本認証、相互認証、Kerberos、SAML といったその他の標準ベースの HTTP トランスポート・オプションを提供しています。これらのすべてが、複数プラットフォーム間での相互運用性を実現し、WebSphere Application Server でサポートされています。

WS-Security 標準を使用する Web サービス・アプリケーションについては、Microsoft .NET と WebSphere Application Server の両方のアプリケーションで上述の HTTP トランスポート認証を使用できます。それらは、WS-Security 標準に基づく SOAP メッセージ認証 (UsernameToken、Kerberos トークン、SAML トークン、X509 に基づく認証など) もサポートできます。さらに、Kerberos と SAML の両方が、サーバー ID またはクライアント ID のいずれかを SOAP ベースの Web サービス・プロバイダーに流す機能をサポートします。Microsoft と IBM の両社が投票権を持つメンバーになっている WS-Security OASIS 標準化団体が、WS-Security ベースのアプリケーションにおける SAML Web Services Token Profile の使用を支持していることも注目に値します。

NTLM に関しては、NTLM を使用したソリューションの開発に関する、以下の技術的な課題および制限があります。

  • NTLM は、Microsoft Active Directory 環境で Windows ドメイン・ユーザーおよびシステム・アカウントで自動的に機能する独自プロトコルです。
  • ユーザー、ドメイン名または NETBIOS 名、およびそのユーザーのパスワードに基づいて NTLM トークンを生成できる、多くのオープン・ソース・ライブラリーがあります。WebSphere Application Server が実行される Java 6 ランタイムは、これら 3 つのパラメーターを指定した場合、NTLM を生成できます。ここでも、これらのライブラリーが意味を持つのは、プロセスにアカウントのパスワードへのアクセス権限があるか、プロセスが Windows AD ドメイン ID を持つ Windows マシン上で実行されている環境内です。
  • アプリケーション・サーバーでは、複数のユーザーに代わってスレッドが実行され、それらのユーザーのパスワードは使用不可であり、保管もされません。エンド・ユーザーのパスワードが存在しない場合、定義上、そのエンド・ユーザーの NTLM を生成するためのメカニズムはありません。ライブラリーに単一のユーザー ID およびパスワードを提供することは可能ですが、これによって可能になるのは、サーバー ID の NTLM 認証情報の生成のみです。アプリケーション・サーバー上の NTLM では、サービス呼び出しの一部としてクライアント ID を流す必要があるユース・ケースをサポートできません。

Microsoft が推奨する代替認証テクノロジーである Kerberos では、資格情報の委任がサポートされることに注意してください。この機能によって、ユーザーのパスワードなしでアプリケーションによるユーザー ID の伝搬が可能になります。同様に、SAML ベースの認証では、ユーザー ID (パスワードなし) または元の Kerberos ID の伝搬がサポートされます。

22. DOS 攻撃を防ぐために、WebSphere Application Server ではどのような対応策を用意していますか。

サービス妨害 (DOS) 攻撃の防止および軽減を実現するには、WebSphere Application Server (または任意のミドルウェア) ではなく、ファイアウォールおよびネットワーク構成の使用が最適です。これは、DOS の防止において WebSphere Application Server に依存するということは、DOS 攻撃のトラフィックがすでにネットワークに影響しているということであるため、WebSphere Application Server で提供できるすべての対応策は、その有効性が限られるためです。

とはいえ、WebSphere Application Server HTTP サーバー・プラグインをはじめとする、WebSphere Application Server 要求処理に対する DOS 攻撃の影響を減らすために採用できる、いくつかの構成オプションがあります。HTTP サーバー・プラグイン構成ファイル (plugin-cfg.xml) の以下のプロパティーを設定して、DOS 攻撃に関連する可能性のある、大規模に実行されるまたは長時間実行される要求の影響を制限したり、これらの要求の再試行を防止したりすることができます。

  • MaxConnections
  • ServerIOTimeOut
  • PostSizeLimit
  • PostBufferSize
  • ServerIOTimeoutRetry

キープアライブ (パーシスタント) 接続での要求数および Web コンテナー・トランスポートでのクライアント接続数は、以下を設定することで制限できます。

  • Persistent Connections/Request
  • Maximum Open Connections

加えて、要求サイズを制限できる、以下の HTTP 要求の Web コンテナー属性を設定することでも制限できます。

  • Maximum header field size
  • Maximum headers
  • Limit request body buffer size
  • Maximum request body buffer size

ここでも、HTTP データ・サイズの制限に関しては、WebSphere Application Server ではなくファイアウォールまたは Web サーバーによって行うのが最適です。


まとめ

セキュリティーに関するもっとも重要な質問の回答がここで見つからない場合は、以下の参考文献と、特に developerWorks の新しい WebSphere Application Server security リソース・ページを必ず確認してください。このページでは、WebSphere Application Server セキュリティーに関するもっとも注目すべき資料の多くを継続的に取り上げます。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=972972
ArticleTitle=WebSphere Application Server のセキュリティーに関するよくある質問(FAQ)
publish-date=06052014