セキュリティー

業界標準ベース

IBM WebSphere Application Server は、 J2EE 仕様に従って Web リソース、Web サービス・エンドポイント、および Enterprise JavaBeans を保護するための、ポリシー・ベースおよび許可ベースの統合モデルを提供します。 具体的には、 WebSphere Application Server は Java EE 6 仕様に準拠し、 J2EE Compatibility Test Suite に合格しています。

セキュア・ソケット通信、メッセージ暗号化、およびデータ暗号化をサポートする標準のセキュリティー・モデルおよびインターフェースは、Java Secure Socket Extension (JSSE) および Java Cryptographic Extension (JCE) です。

オープン・アーキテクチャー・パラダイム

アプリケーション・サーバーは、複数層のエンタープライズ・コンピューティング・フレームワークの中核をなす部分です。 IBM WebSphere Application Server は、オープン・アーキテクチャー・パラダイムを採用し、エンタープライズ・ソフトウェア・コンポーネントと統合するための多数のプラグイン・ポイントを提供します。 プラグイン・ポイントは、J2EE の標準仕様が適用できるところでは必ず、この仕様を基にしています。

濃い青色の陰影付きの背景は、 WebSphere Application Serverバージョン 9.0 とその他のビジネス・アプリケーション・コンポーネントとの間の境界を示します。

WebSphere Application Server は、認証メカニズムとして Simple WebSphere Authentication Mechanism (SWAM)、Lightweight Third Party Authentication (LTPA)、および Kerberos を提供します。 ただ 1 つのユーザー・レジストリー実装を、 WebSphere Application Server セキュリティー・ドメインのアクティブ・ユーザー・レジストリーとして構成することができます。 WebSphere Application Server は、UNIX、Windows、および IBM i ローカル OS および Lightweight Directory Access Protocol (LDAP) のユーザー・レジストリー実装を提供します。 また、ファイル・ベースおよび Java データベース接続 (JDBC) ベースのユーザー・レジストリー参照の実装も提供します。 この製品は、認証メカニズムとユーザー・レジストリーの柔軟な組み合わせをサポートしています。 SWAM は簡単に構成できるため、単一のアプリケーション・サーバー環境で有用です。 ID アサーションが使用可能になっている場合は、 分散環境で SWAM を使用することもできます。 ID アサーション・フィーチャーは、CSIv2 セキュリティー・プロトコルでのみ 使用可能です。

注: SWAM は、 WebSphere Application Serverの以前のリリースでは推奨されておらず、将来のリリースでは除去される予定です。

LTPA 認証メカニズムは、すべてのプラットフォーム・セキュリティー用に設計されています。 ダウンストリーム・サーバーはセキュリティー・トークンを検証できます。 また、リバース・セキュア・プロキシー・サーバー とシングル・サインオン (SSO) とのトラスト・アソシエーション関係のセットアップもサポートします。 これについては後述します。 LTPA と LDAP またはカスタム・ユーザー・レジストリー・インターフェースとの組み合わせ以外に、 バージョン 6.x 以降 では、LocalOS ユーザー・レジストリー・インターフェースを備えた LTPA にも対応しています。 単一のノードに 複数のアプリケーション・サーバーが組み込まれている場合に、 この新しい構成は特に有効です。 これは、ローカル OS ユーザー・レジストリー実装が Windows ドメイン・コントローラーなどの集中ユーザー・レジストリーである場合、または複数のノードで一貫性のある状態を維持できる場合に、分散環境で機能することができます。

WebSphere Application Server は、 J2EE コネクター・アーキテクチャーをサポートし、コンテナー管理認証を提供します。 これは、デフォルトの Java 2 コネクター (J2C) プリンシパルおよびクレデンシャル・マッピング・モジュールを提供します。このモジュールは、すべての認証済みユーザー・クレデンシャルを、指定されたエンタープライズ情報システム (EIS) セキュリティー・ドメインのパスワード・クレデンシャルにマップします。 マッピング・モジュールは、Java 2 コネクターおよび JAAS 仕様に従って設計された特殊な JAAS ログイン・モジュールです。 他のマッピング・ログイン・モジュールも接続できます。

Web Services Security

WebSphere Application Server を使用すると、Organization for Advancement of Structured Information Standards (OASIS) Web Services Security Version 1.1 仕様に基づいて Web サービスを保護することができます。 このような標準は、Web サービス環境で交換されるメッセージの保護方法を 規定します。 この仕様は、メッセージの保全性と機密性を保護するための中核機構を定義し、セキュリティー関連の要求と メッセージを関連付けるためのメカニズムを提供します。

トラスト・アソシエーション

セキュリティー属性の伝搬

シングル・サインオン・インターオペラビリティー・モード

WebSphere Application Serverでは、インターオペラビリティー・モード・オプションにより、 WebSphere Application Server バージョン 6.1.x 以降の間のシングル・サインオン (SSO) 接続を有効にして、アプリケーション・サーバーの以前のバージョンと相互運用できるようになります。 このオプションを選択すると、 WebSphere Application Server は、このトークン・タイプでのみ機能する他のサーバーに送信できるように、古いスタイルの LtpaToken を応答に追加します。 このオプションは、Web インバウンド・セキュリティー属性の伝搬オプションが使用可能になっている場合にのみ適用されます。 シングル・サインオンについて詳しくは、 Web ユーザー認証を最小化するためのシングル・サインオンの実装 を参照してください。

Web コンテナーおよび EJB コンテナーを使用した J2EE リソースのセキュリティー

それぞれのコンテナーは、2 種類のセキュリティー (宣言セキュリティー とプログラマチック・セキュリティー) に対応しています。 宣言セキュリティーでは、アプリケーションのセキュリティー構造 (データの保全性と機密性、認証要件、セキュリティーのロール、アクセス制御など) が、そのアプリケーション外部の形式で表されます。 特にデプロイメント記述子は、J2EE プラットフォームにおける宣言セキュリティーの主要な手段です。 WebSphere Application Server は、 J2EE セキュリティー・ポリシーを保守します。これには、デプロイメント記述子から派生し、一連の XML 記述子ファイルでデプロイヤーおよび管理者によって指定された情報が含まれます。 コンテナーは、実行時には XML ディスクリプター・ファイルで定義されたセキュリティー・ポリシーを使用して、データ制約とアクセス制御を実行します。 宣言セキュリティー単独ではアプリケーションのセキュリティー・モデルを表現するのに十分でない場合には、 プログラマチック・セキュリティーがアプリケーション・コードによって使用され、アクセス判断を行うことがあります。 プログラマチック・セキュリティー用のアプリケーション・プログラミング・インターフェース (API) は、Enterprise JavaBeans (EJB) EJBContext インターフェースの 2 つのメソッドで構成されています。isCallerInRole,getCallerPrincipal) およびサーブレット HttpServletrequest インターフェースの 3 つのメソッド (isUserInRole,getUserPrincipal,getRemoteUser).

Java 2 セキュリティー

WebSphere Application Server は、Java 2 セキュリティー・モデルをサポートします。 管理サブシステム、Web コンテナー、および EJB コンテナーなどのシステム・コードは、 WebSphere Application Server セキュリティー・ドメインで実行されます。このセキュリティー・ドメインは、現在の実装では AllPermission を使用して付与され、すべてのシステム・リソースにアクセスできます。 アプリケーションのセキュリティー・ドメイン内で 実行されているアプリケーション・コードは、デフォルトで J2EE 仕様に従ってアクセス権を付与されており、 制限されたシステム・リソース・セットにしかアクセスできません。 WebSphere Application Server ランタイム・クラスは、 WebSphere Application Server クラス・ローダーによって保護され、アプリケーション・コードからは見えない状態に保たれます。

Java 2 Platform、 Enterprise Edition コネクター・セキュリティー

WebSphere Application Server は、 J2EE コネクター・アーキテクチャーをサポートし、コンテナー管理認証を提供します。 WebSphere Application Server は、デフォルトの J2C のプリンシパルおよびクレデンシャル・マッピング・モジュールを提供します。 このモジュールは、任意の認証済みユーザーのクレデンシャルを、指定した EIS (Enterprise Information System) セキュリティー・ドメイン のパスワード・クレデンシャルにマップします。

アプリケーション・サーバー・プロセスはすべて、デフォルトでは、セル・レベルのセキュリティー XML 文書で定義される共通の セキュリティー構成を共有することになっています。 セキュリティー構成は、 WebSphere Application Server セキュリティーを実施するかどうか、Java 2 セキュリティーを実施するかどうか、認証メカニズムとユーザー・レジストリー構成、セキュリティー・プロトコル構成、 JAAS ログイン構成、および Secure Sockets Layer 構成を決定します。 アプリケーションには、それぞれ固有のセキュリティー要件がある場合があります。 各アプリケーション・サーバー・プロセスは、独自のセキュリティー要件に対処するため、または WebSphere セキュリティー・ドメインにマップするために、サーバーごとのセキュリティー構成を作成できます。 セキュリティー構成がすべて、アプリケーション・サーバー・レベルで変更できるわけではありません。 アプリケーション・サーバー・レベルで変更できるセキュリティー構成には、アプリケーション・セキュリティーを実施するかどうか、Java 2 セキュリティーを実施するかどうか、セキュリティー・プロトコル構成などがあります。 WebSphere セキュリティー・ドメインを使用すると、セキュリティー構成をより詳細に制御することができ、個々のサーバーにマップすることができます。 詳しくは、『複数のセキュリティー・ドメイン』を参照してください。

管理サブシステム・セキュリティー構成は、常にセル・レベルのセキュリティー文書で決定されます。 Web コンテナーと EJB コンテナーのセキュリティー構成は、サーバー・レベルのセキュリティー文書ごとのオプションによって決定され、 セル・レベルのセキュリティー文書よりも優先されます。

セキュリティー構成は、 セル・レベルでもアプリケーション・サーバー・レベルでも、Web ベースの管理コンソール・アプリケーションか、該当するスクリプト・アプリケーションのいずれかで管理されます。

Web セキュリティー

WebSphere Application Serverでは、ローカル OS ユーザー・レジストリーはマッピング機能をサポートしていません。

LTPA 認証メカニズムが構成され、シングル・サインオン (SSO) が有効になっている場合、認証済みクライアントには、指定されたセキュリティー・ドメイン内のユーザーを表すことができるセキュリティー Cookie が発行されます。

セキュリティー Cookie および基本認証情報がインターセプトされたり再実行されたりするのを防ぐために、 Secure Sockets Layer (SSL) の使用をお勧めします。 トラスト・アソシエーションが構成されている場合、 WebSphere Application Server は、セキュア・リバース・プロキシー・サーバーとの間で確立された信頼関係に基づいて、認証済みユーザー ID をセキュリティー資格情報にマップすることができます。

EJB セキュリティー

セキュリティーが有効になっていると、EJB コンテナーは EJB メソッドを起動してアクセス制御を実行します。 認証は、メソッド許可が特定の EJB メソッド用に定義されているかどうかに関係なく 行われます。

Java アプリケーション・クライアントは、いくつかの方法で認証データを提供できます。 使用sas.client.propsファイル。Java クライアントは、認証にユーザー ID とパスワードを使用するか、認証に SSL クライアント証明書を使用するかを指定できます。 クライアント証明書は、以下に定義されているように、鍵ファイルまたはハードウェア暗号カードに保管されます。sas.client.propsを適用します。 ユーザー ID とパスワードは、オプションで以下の場所に定義できます。sas.client.propsを適用します。

実行時に、Java クライアントはプログラマチック・ログインを実行することも、 遅延認証を実行することもできます。

遅延認証では、Java クライアントが初めて保護エンタープライズ Bean にアクセスするときに、セキュリティー・ランタイムは必要な認証データを取得しようとします。 以下の構成設定によって異なります。sas.client.propsfile セキュリティー・ランタイムは、このファイルから認証データを検索するか、ユーザーにプロンプトを出します。 あるいは、Java クライアントでプログラマチック・ログインを使用することもできます。 WebSphere Application Server は、 JAAS プログラミング・モデルをサポートしており、プログラマチック・ログインの推奨方法は JAAS ログイン (LoginContext) です。 login_helper request_login ヘルパー関数は、バージョン 6.x および バージョン 9.0で非推奨になりました。 login_helper APT にプログラムされた Java クライアントは、このバージョンで実行できます。

EJB セキュリティー・コラボレーターは、アクセス・マネージャー実装を使用して、 ロール・ベースのアクセス制御を実行します。

アクセス・マネージャーは、デプロイメント記述子から派生したセキュリティー・ポリシーに基づいて許可を決定します。 認証済みのユーザー・プリンシパルは、必要なセキュリティー・ロールのいずれかを持っている場合に、要求した EJB メソッドへアクセスできます。 EJB コードは、EJBContext メソッドの isCallerInRole および getCallerPrincipal を使用できます。 EJB コードでは、JAAS ログインを実行する JAAS プログラミング・モデル、WSSubject doAs および doAsPrivileged メソッド も使用できます。 doAs および doAsPrivileged PrivilegedAction ブロック内のコードは、サブジェクト ID を使用して実行 されます。 そうでない場合、EJB メソッドは RunAs 構成に応じて、指定した RunAs ID または呼び出し元の ID のいずれかを使用して実行されます。 J2EE RunAs 仕様は エンタープライズ Bean レベルです。 RunAs ID を指定すると、これがすべての Bean メソッドに適用されます。 バージョン4.00で導入されたメソッドレベルのIBM RunAs拡張は、このバージョンでもサポートされている。

連邦情報処理標準 (FIPS) による承認

連邦情報処理標準 (FIPS) は、米国連邦情報・技術局 (NIST) が、連邦コンピューター・システムのために発行した標準およびガイドラインです。 FIPS は、セキュリティーおよびインターオペラビリティーなど、標準に関する連邦政府の切実な要求がある一方で、実施可能な業界標準または解決方法が存在しない場合のために開発されました。

WebSphere Application Server は、FIPS 140-2 認定を受けている Java Secure Socket Extension (JSSE) および Java Cryptography Extension (JCE) を含む暗号モジュールを統合します。

詳しくは、「 連邦情報処理標準 Java セキュア・ソケット拡張機能ファイルの構成」を参照してください。

IBMJCEFIPS 暗号モジュールには、FIPS によって承認されたアルゴリズムが含まれています。これらのアルゴリズムは、 IBM JCE モジュール内のアルゴリズムの適切なサブセットを形成します。