WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: AIX , HP-UX, i5/OS, Linux, Solaris, Windows, Windows Vista, z/OS

             目次と検索結果のパーソナライズ化

セキュリティー計画の概要

インターネットで情報にアクセスする場合は、 Web サーバーおよび製品サーバーを介してバックエンドのエンタープライズ・データに接続します。 このセクションでは、いくつかの典型的な構成および共通のセキュリティー実践方法について検討します。

このセクションでは、各セキュリティー層で提供されるセキュリティー保護、 およびエンドツーエンド・セキュリティーにおける良質な保護の共通のセキュリティー実践方法についても検討します。 以下の図は、WebSphere Application Server 内のセキュリティーの オペレーティング環境を構成するビルディング・ブロックを示しています。

以下の情報は、前の図で示した WebSphere Application Server セキュリティー、Java セキュリティー、およびプラットフォーム・セキュリティーの各コンポーネントについて説明しています。
WebSphere Application Server セキュリティー
WebSphere セキュリティー
WebSphere Application Server セキュリティーは、Web リソース、エンタープライズ Bean、 および JMX 管理リソースへのアクセスにおいて、セキュリティー・ポリシーおよびサービスを、 統一された方法で実施します。 これは WebSphere Application Server セキュリティー・テクノロジーとフィーチャーで構成され、 セキュア・エンタープライズ環境のニーズをサポートします。
Java セキュリティー
Java 2 Platform, Enterprise Edition (J2EE) セキュリティー・アプリケーション・プログラミング・インターフェース (API)
セキュリティー・コラボレーターは、 Java 2 Platform, Enterprise Edition (J2EE) ベースのセキュリティー・ポリシーを実行し、 J2EE セキュリティー API をサポートします。
CORBA セキュリティー (CSIv2) [AIX HP-UX Linux Solaris Windows] [i5/OS]
セキュアなオブジェクト・リクエスト・ブローカー (ORB) 間 で行われる呼び出しはすべて、Common Security Interoperability バージョン 2 (CSIv2) セキュリティー・プロトコル 上で起動されます。このプロトコルは、セキュリティー・コンテキストおよび必要な保護品質をセットアップ します。セッションが確立された後、呼び出しはエンタープライズ Bean 層に渡されます。

[この情報が適用されるのはバージョン 6.0.x と、バージョン 6.1 セルに統合された以前のサーバーだけです。] 後方互換性のために、WebSphere Application Server は、WebSphere Application Server の前のリリースや 他の IBM 製品で使用されていた Secure Authentication Service (SAS) セキュリティー・プロトコルを サポートします。

CSIv2 セキュリティー [z/OS]
Common Secure Interoperability バージョン 2 (CSIv2) は、オブジェクト管理グループ (OMG) により作成される、IIOP ベースの 3 層のセキュリティー・プロトコルです。このプロトコルにより、 メッセージ保護、相互認証、および代行が提供されます。3 つの層には、基本トランスポート・セキュリティー層、補足的なクライアント認証層、およびセキュリティー属性層が含まれます。WebSphere Application Server for z/OS は、CSIv2 準拠レベル 0 をサポートしています。
Java 2 セキュリティー
Java 2 セキュリティー・モデルは、 ファイル・システム、システム・プロパティー、ソケット接続、スレッド化、 クラス・ロードなどのシステム・リソースに対して、きめの細かいアクセス制御を提供します。 アプリケーション・コードで、保護リソースにアクセスするために必要な許可を明示的に与えなければなりません。
Java 仮想マシン (JVM) 5.0
JVM セキュリティー・モデルは、 オペレーティング・システム層の上にセキュリティーの層を提供します。例えば、JVM セキュリティーは、 無制限のアクセスからメモリーを保護し、エラーがスレッド内で起こった場合に例外を作成し、配列型を定義します。
プラットフォーム・セキュリティー
オペレーティング・システム・セキュリティー [AIX HP-UX Linux Solaris Windows] [i5/OS]

基礎となるオペレーティング・システムのセキュリティー・インフラストラクチャーは、 特定のセキュリティー・サービスを WebSphere Application Server に提供します。 これらのサービスには、 WebSphere Application Server の製品インストールにおいて機密ファイルを保護する ファイル・システム・セキュリティー・サポートが含まれます。システム管理者は、 製品を構成して、オペレーティング・システムのユーザー・レジストリーから認証情報を 直接取得することができます。

オペレーティング・システム・セキュリティー [z/OS]

基礎となるオペレーティング・システムのセキュリティー・インフラストラクチャーは、 特定のセキュリティー・サービスを WebSphere Application Server に提供します。 STARTED プロファイルにより確立される、 サーバント・コントローラーおよび「開始済みタスク」デーモンのオペレーティング・システム ID は、 ファイルまたはソケットなどのシステム・リソースへのアクセスを制御するために使用される ID です。 オプションで、オペレーティング・システム・セキュリティーは、 WebSphere 管理コンソールおよびアプリケーション・サーバーの下で実行するアプリケーションに対して、 ローカル・オペレーティング・システムのユーザー・レジストリーを使用する認証サービス、 および/または SAF 許可を使用する認証サービスを提供することができます。

管理者は、Secure Sockets Layer (SSL) および Transport Layer Security (TLS) の知識のほかに、 System Authorization Facility (SAF) および Resource Access Control Facility (RACF)、 または同等の SAF ベースの製品に関する知識が必要です。

ユーザーの識別と確認は、 ローカル・オペレーティング・システムをユーザー・レジストリーとして使用することにより管理できます。 あるいは、RACF または同等の SAF ベースの製品を使用して管理することもできます。 代わりに、LDAP、カスタムまたは統合ユーザー・レジストリーを使用することもできます。

WebSphere は、SAF 許可を使用するように構成できます。 この場合は、RACF または同等の SAF ベースの製品を使用して、ユーザーとグループ・リソースが管理および保護さ れます。 代わりに、WebSphere 許可または JACC 外部許可プロバイダーを使用するように WebSphere を構成することもできます。

ローカル・オペレーティング・システムをユーザー・レジストリーとして使用する場合、 および/または SAF 許可を使用する場合、セキュリティー監査は RACF または同等の SAF ベースの製品の継承フィーチャーです。

ネットワーク・セキュリティー
ネットワーク・セキュリティー層は、 トランスポート・レベルの認証およびメッセージの保全性と機密性を提供します。 別個のアプリケーション・サーバー間の通信は、Secure Sockets Layer (SSL) を使用するように構成することができます。また、メッセージ保護を更に強化するために、 IP セキュリティーおよび仮想私設網 (VPN) を使用することもできます。

[z/OS] WebSphere Application Server for z/OS では、インターネットを使用して 通信を行うための SystemSSL が提供されています。SystemSSL は、Secure Sockets Layer (SSL) および Transport Layer Security (TLS) から構成され、データ・プライバシーとメッセージの整合性を提供するセキュア・ファイル転送を可能にします。

WebSphere Application Server Network Deployment インストール
重要: すべてのコンピューター・ノード上に、ノード・エージェント・インスタンスがあります。

各製品のアプリケーション・サーバーは、Web コンテナー、 Enterprise Java Beans (EJB) コンテナー、および管理サブシステムで構成されます。

WebSphere Application Server デプロイメント・マネージャーには、 WebSphere Application Server 管理コードと管理コンソールのみが含まれています。

管理コンソールは、 特殊な J2EE Web アプリケーションであり、管理機能を実行するためのインターフェースを提供します。 WebSphere Application Server 構成データは、オペレーティング・システム・セキュリティー が保護する必要のある、XML ディスクリプター・ファイルに保管されています。パスワードおよびその他の機密構成データは、管理コンソールを使用して変更できます。 ただし、これらのパスワードおよび機密データを保護する必要があります。詳しくは、ファイル内のパスワードのエンコード を参照してください。

管理コンソール Web アプリケーションには、 セットアップ・データの制約があります。 この制約によって、管理セキュリティー が使用可能になっている 際には、SSL 接続のみを使用して管理コンソール・サーブレットおよび JavaServer Pages (JSP) ファイルへアクセスする必要があります。

[AIX HP-UX Linux Solaris Windows] [i5/OS] WebSphere Application Server バージョン 6.0.x およびそれ以前では、 管理者コンソールの HTTPS ポートは、 デフォルトの自己署名証明書を用いて DummyServerKeyFile.jks および DummyServerTrustFile.jks を使用するように構成されていました。 ダミー証明書と鍵は、WebSphere Application Server のインストール直後に置換する必要があります。 これは、鍵がすべてのインストールで共通なのでセキュアではないためです。 WebSphere Application Server バージョン 6.1 は、統合証明書と鍵管理を提供します。 これにより、明確に識別できる秘密鍵とサーバー・ホスト名を組み込んだ自己署名証明書が生成され、ホスト名の検証が 可能になります。 WebSphere Application Server バージョン 6.1 では、 外部認証局 (CA) との統合により、CA 発行の証明書を使用することもできます。 WebSphere Application Server バージョン 6.1 インストール・プロセスは、 インストール時に管理セキュリティーを使用可能にするオプションを提供します。 結果として、WebSphere Application Server プロセスは、インストール直後にセキュアになります。

[z/OS] インストール時に、管理コンソールは 定義した鍵リングを使用して System SSL ポートを使用するよう構成されます。カスタマイズ・ダイアログは、 RACF カスタマイズ・ジョブを提供し、共通の認証局を使用して、指定されたセル内のサーバー用の固有のサーバー証明書を作成します。最初に 管理セキュリティー を使用可能にし、 管理セキュリティー が実施されてから他の構成タスクを完了すれば、さらにセキュアになります。

[AIX HP-UX Linux Solaris Windows] [i5/OS] 次の図は、典型的な多層ビジネス・コンピューティング環境を 示しています。

[z/OS] 次の図は、典型的な多層ビジネス・コンピューティング環境を 示しています。

管理セキュリティー

[AIX HP-UX Linux Solaris Windows] [i5/OS] [この情報が適用されるのはバージョン 6.0.x と、バージョン 6.1 セルに統合された以前のサーバーだけです。] WebSphere Application Servers は、 HTTP や HTTPS プロトコルだけでなく、CSIv2 や Secure Authentication Services (SAS) セキュリティー・プロトコルを介して、 相互に対話します。
重要: SAS がサポートされるのは、バージョン 6.1 セルに統合されたバージョン 6.0.x と、それより前のバージョンの間のサーバーに限られます。
[z/OS] [この情報が適用されるのはバージョン 6.0.x と、バージョン 6.1 セルに統合された以前のサーバーだけです。] WebSphere Application Servers は、 HTTP や HTTPS プロトコルだけでなく、CSIv2 や z/OS Secure Authentication Services (z/SAS) セキュリティー・プロトコルを介して、相互に対話します。
重要: z/SAS がサポートされるのは、バージョン 6.1 セルに統合されたバージョン 6.0.x と、それより前のバージョンの間のサーバーに限られます。

WebSphere Application Server 管理セキュリティー を使用可能にすると、 これらのプロトコルを Secure Sockets Layer (SSL) を使用するように構成できます。 すべてのサーバー内の WebSphere Application Server 管理サブシステムは、SOAP、 Java Management Extensions (JMX) コネクターおよび Remote Method Invocation over the Internet Inter-ORB Protocol (RMI/IIOP) JMX コネクターを使用して、 管理コマンドおよび構成データを渡します。 管理セキュリティー が使用不可の場合、 SOAP JMX コネクターは HTTP プロトコルを使用し、RMI/IIOP コネクターは TCP/IP プロトコルを使用します。 管理セキュリティー が使用可能な場合、SOAP JMX コネクターは常に HTTPS プロトコルを使用します。 管理セキュリティー が使用可能な場合、 RMI/IIOP JMX コネクターは、SSL または TCP/IP のいずれかを使用するように構成できます。 管理セキュリティー を使用可能にし、 SSL を使用可能にして機密性が高い構成データを保護することをお勧めします。

[z/OS] 管理セキュリティー が使用不可の場合でも、 アプリケーションに対して HTTPS を使用可能にすることができます。 SSL ポートを、環境構成の仮想ホストに追加する場所以外に、 サーバー Web コンテナー内の HTTP ポート・リストにも追加することによって、SSL ポートを 特定のサーバー用に構成できます。HTTPS と正しいポートを使用して、 Web アプリケーションに接続できます。WebSphere Application Server for z/OS の内部通信では、 管理セキュリティー を使用可能にしない限り、SSL は使用されません。

管理セキュリティーが使用可能な場合は、 サーバー・レベルで「管理セキュリティーを有効にする」オプションをクリアす ることで、個々のアプリケーション・サーバーのアプリケーション・セキュリティーを使用不可にできます。 詳しくは、特定のアプリケーション・サーバーの保護 を 参照してください。アプリケーション・サーバーのセキュリティーを使用不可にしても、 そのアプリケーション・サーバー内の管理サブシステムには影響を及ぼしません。 この管理サブシステムは、セキュリティー構成によってのみ制御されています。 管理サブシステムとアプリケーション・サーバー内のアプリケーション・コードはいずれも サーバーごとのオプションのセキュリティー・プロトコル構成を共用しています。

J2EE リソースのためのセキュリティー

J2EE リソースのためのセキュリティーは、Web コンテナーおよび EJB コンテナーから提供されます。 それぞれのコンテナーは、 2 種類のセキュリティー (宣言セキュリティーとプログラマチック・セキュリティー) を提供します。

宣言セキュリティーでは、アプリケーションのセキュリティー構造に、 ネットワーク・メッセージの保全性と機密性、認証要件、セキュリティーの役割、およびアクセス制御などが含まれます。 アクセス制御はそのアプリケーション外部の形式で表されます。特にデプロイメント記述子は、 J2EE プラットフォームにおける宣言セキュリティーの主要な手段です。WebSphere Application Server は、 デプロイメント記述子から引き出され、XML ディスクリプター・ファイルのセットでデプロイヤーおよびアドミニストレーターが 指定する情報を含む J2EE セキュリティー・ポリシーを維持します。コンテナーは、 実行時には XML ディスクリプター・ファイルで定義されたセキュリティー・ポリシーを使用して、 データ制約とアクセス制御を実行します。

宣言セキュリティー単独ではアプリケーションの セキュリティー・モデルを表現するのに十分でない場合には、プログラマチック・セキュリティーを使用して アクセス判断を行うことができます。管理セキュリティー が使用可能で、 アプリケーション・サーバーのセキュリティーがサーバー・レベルで使用不可にされていない場合、 J2EE アプリケーション・セキュリティーが実施されます。 Web リソースに対して セキュリティー・ポリシーが指定されている場合、Web コンテナーは、Web クライアントがそのリソースを 要求したときにアクセス制御を実行します。Web コンテナーはそのクライアントの認証データで、指定した認証メソッドに適合するクライアントがないかを調べ、データ制約が満たされていることを確認して、 認証済みユーザーに必要なセキュリティー役割があるかどうかを判断します。Web セキュリティー・コラボレーターは、アクセス・マネージャー・インプリメンテーションを使用して、役割ベースのアクセス制御を実行します。 アクセス・マネージャーは、デプロイメント記述子から派生したセキュリティー・ポリシー に基づいて許可を決定します。認証済み のユーザー・プリンシパルは、必要なセキュリティー役割のいずれかを持っている場合に、要求したサーブレットまたは JSP ファイル へアクセスできます。 サーブレットと JSP ファイルは、HttpServletRequest メソッド (isUserInRole および getUserPrincipal) を使用できます。

[AIX HP-UX Linux Solaris Windows] [i5/OS] 管理セキュリティーとアプリケーション・セキュリティーが使用可能になっていて、 アプリケーション・サーバー・レベルのアプリケーション・セキュリティーが使用不可になっていない場合、 EJB コンテナーは EJB メソッドを起動してアクセス制御を実行します。

[z/OS] セル・レベル・セキュリティーが使用可能になっている場合、 サーバーのセキュリティーが使用不可になっていない限り、EJB コンテナーは EJB メソッドを起動して アクセス制御を実行します。

認証は、メソッド許可が特定の EJB メソッド用に定義されているか どうかに関係なく行われます。EJB セキュリティー・コラボレーターは、アクセス・マネージャー・インプリメンテーションを使用して、 役割ベースのアクセス制御を実行します。 アクセス・マネージャーは、デプロイメント記述子から派生したセキュリティー・ポリシー に基づいて許可を決定します。 認証済みのユーザー・プリンシパルは、必要なセキュリティー役割のいずれかを持っている場合に、要求した EJB メソッドへアクセスできます。EJB コードでは、EJBContext メソッドの isCallerInRole および getCallerPrincipal が使用できます。 J2EE 役割ベースのアクセス制御は、重要なビジネス・データがインターネットおよびイントラネットを介して、 無許可ユーザーによってアクセスされるのを防止するために使用します。 アセンブリー・ツールを使用した Web アプリケーションの保護 、および エンタープライズ Bean アプリケーションの保護 を参照してください。

役割ベースのセキュリティー

WebSphere Application Server は、 セキュリティー、役割ベースのアクセス制御を、JMX システム管理サブシステム、 ユーザー・レジストリー、および Java Naming and Directory Interface (JNDI) ネーム・スペースを含む管理リソースに拡張しました。 WebSphere 管理サブシステムは、以下の 4 つの管理セキュリティー役割を定義します。
モニター役割
モニターは構成情報および状況を表示できますが、変更することはできません。
オペレーター役割
オペレーターは、アプリケーション・サーバーの始動やアプリケーションの停止など、 ランタイム状態の変更を起動できますが、構成の変更はできません。
コンフィギュレーター役割
コンフィギュレーターは構成情報を変更できますが、ランタイム状態を変更できません。
管理者役割
コンフィギュレーターだけでなくオペレーターの役割も併せ持ち、 さらに、サーバー ID やパスワードの設定などの機密性の高いセキュリティー構成およびセキュリティー・ポリシーを変 更でき、管理セキュリティー および Java 2 セキュリティーを使用可能または使 用不可に設定し、 ユーザーとグループを管理者役割にマップすることができます。
iscadmins
iscadmins 役割は、管理コンソール内のみのユーザーとグループを管理する管理者特権を有しています。
WebSphere Application Server は、wsadmin スクリプトを使用する場合にのみ 使用可能な、2 つの追加の役割を定義します。
デプロイヤー
デプロイヤーは、アプリケーション対し、構成操作、および実行時の操作の両方を実行できます。
Adminsecuritymanager
管理セキュリティー・マネージャーによって、 ユーザーを管理役割にマップすることができます。 また、詳細な管理セキュリティーが使用されている場合、この役割を付与されたユーザーは、許可グループを管理することができます。

コンフィギュレーター役割を持つユーザーは、 新規アプリケーションおよびアプリケーション・サーバーのインストールを含む、最も管理的な作業を実行できます。 管理セキュリティー が使用可能な場合に、コンフィギュレーターには十分な実行権限がない、 特定の構成タスクがあります。 これらのタスクには、WebSphere Application Server の ID とパスワードの変更、 Lightweight Third-Party Authentication (LTPA) パスワードと鍵の変更、 および管理セキュリティー役割へのユーザーの割り当てが含まれます。 これらの重要な構成タスクでは、 サーバー ID が管理者役割にマップされるため、管理役割が必要です。

[z/OS] これらの機密構成タスクでは、管理役割が必要です。

管理サブシステムの保全性を保護 するために、WebSphere Application Server 管理セキュリティーを使用可能にします。 保護すべき機密情報がない場合、アプリケーション・サーバーのセキュリティーは、 選択的に使用不可にできます。 管理セキュリティーの保護については、管理の役割へのアクセスの許可 および役割へのユーザーおよびグループの割り当て を参照してください。

Java 2 セキュリティー許可

WebSphere Application Server は、 Java 2 セキュリティー・モデルを使用して、アプリケーション・コードを実行するためのセキュア環境を作成します。 Java 2 セキュリティーは、きめの細かいポリシー・ベースの アクセス制御を提供して、ファイル、システム・プロパティーなどのシステム・リソース、ソケット接続の開始、ライブラリーのロードなどを保護します。 J2EE バージョン 1.4 仕様は、Web および EJB コンポーネントが持つと 予想される Java 2 セキュリティー許可の標準セットを定義します。これらの許可を、次の表に示します。

表 1. Web コンポーネントの J2EE セキュリティー許可セット
セキュリティー許可 ターゲット アクション
java.lang.RuntimePermission loadLibrary  
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * 接続
java.io.FilePermission * 読み取り、書き込み
java.util.PropertyPermission * 読み取り
表 2. EJB コンポーネントの Java 2 セキュリティー許可セット
セキュリティー許可 ターゲット アクション
java.lang.RuntimePermission queuePrintJob  
java.net.SocketPermission * 接続
java.util.PropertyPermission * 読み取り
WebSphere Application Server Java 2 セキュリティーのデフォルト・ポリシーは、 J2EE バージョン 1.4 仕様をベースにしています。この仕様は、Web コンポーネントに、 ファイル・システム内のすべてのファイルへの、読み取りおよび書き込みのファイル・アクセス許可 を与えますが、これでは、対象範囲が広すぎる場合があります。WebSphere Application Server の デフォルト・ポリシーでは、Web コンポーネントは、Web モジュールがインストールされた サブディレクトリーおよびサブツリーへの読み取りおよび書き込み許可が与えられます。 すべての Java 仮想マシンおよび WebSphere Application Server プロセス用の デフォルトの Java 2 セキュリティー・ポリシーは、以下のポリシー・ファイルに含まれています。
/QIBM/ProdData/Java400/jdk15/lib/security/java.policy [i5/OS]
Java 仮想マシン (JVM) にデフォルト・ポリシーとして使用
${java.home}/jre/lib/security/java.policy [AIX HP-UX Linux Solaris Windows] [z/OS]
このファイルは、Java 仮想マシン (JVM) にデフォルト・ポリシーとして使用されます。
${USER_INSTALL_ROOT}/properties/server.policy [AIX HP-UX Linux Solaris Windows] [i5/OS]
このファイルは、すべての製品サーバー・プロセスにデフォルト・ポリシーとして使用されます。
$WAS_HOME/properties/server.policy [z/OS]
このファイルは、すべての製品サーバー・プロセスにデフォルト・ポリシーとして使用されます。

ポリシー管理を単純化するため、 WebSphere Application Server ポリシーは、コード・ベース (ロケーション) ではなく、 リソース・タイプに基づいています。 次のファイルは、WebSphere Application Server サブシステムの デフォルト・ポリシー・ファイルです。WebSphere Application Server ランタイムの拡張機能であるこれらのポリシー・ファイルは、 Service Provider Programming Interfaces (SPI) と呼ばれ、複数の J2EE アプリケーションによって共用されます。

[AIX HP-UX Linux Solaris Windows]
  • profile_root/config/cells/cell_name/nodes/node_name/spi.policy

    このファイルは、Java Message Service (JMS)、JavaMail および JDBC ドライバーなど、 resources.xml ファイルに定義される組み込みリソースに使用されます。

  • profile_root/config/cells/cell_name/nodes/node_name/library.policy

    このファイルは、WebSphere Application Server 管理コンソールが定義する共用ライブラリーによって使用されます。

  • profile_root/config/cells/cell_name/nodes/node_name/app.policy

    このファイルは、J2EE アプリケーションにデフォルト・ポリシーとして使用されます。

[z/OS]
  • $WAS_HOME/config/cells/cell_name/nodes/node_name/spi.policy

    このファイルは、Java Message Service (JMS)、JavaMail API および JDBC ドライバーなど、resources.xml ファイル内で 定義される組み込みリソースに使用されます。

  • $WAS_HOME/config/cells/cell_name/nodes/node_name/library.policy

    このファイルは、WebSphere Application Server 管理コンソールが定義する共用ライブラリーによって使用されます。

  • $WAS_HOME/config/cells/cell_name/nodes/node_name/app.policy

    このファイルは、J2EE アプリケーションにデフォルト・ポリシーとして使用されます。

[i5/OS]
  • profile_root/config/cells/cell_name/nodes/node_name/spi.policy

    Java Message Service (JMS)、JavaMail および JDBC ドライバーなど、 resources.xml ファイルに定義される組み込みリソースに使用。

  • profile_root/config/cells/cell_name/nodes/node_name/library.policy

    WebSphere Application Server 管理コンソールが定義する共用ライブラリーによる使用。

  • profile_root/config/cells/cell_name/nodes/node_name/app.policy

    J2EE アプリケーションにデフォルト・ポリシーとして使用。

一般に、アプリケーションは、 さまざまなアプリケーション・サーバー間で移植できるようにするために、 J2EE 仕様で推奨されるより多くの許可の実行を必要としません。 ただし、一部のアプリケーションは、さらに多くの許可を必要とする場合があります。WebSphere Application Server は、各アプリケーションで was.policy ファイルのパッケージ化をサポートし、 そのアプリケーションに追加の許可を与えます。
重要: システムの保全性を損なう可能性があるため、 慎重に検討してから、追加の許可をアプリケーションに与えるようにしてください。

WebSphere Application Server にライブラリーをロードすると、 アプリケーションは Java サンドボックスから離れることができます。 WebSphere Application Server は、許可がさらに必要なためアプリケーシ ョンのインストールが失敗した場合、許可フィルター・ポリシー・ファイルを使用してユーザーに警報を出します。 例えば、アプリケーション・コードが WebSphere Application Server を 終了できないようにするために、java.lang.RuntimePermission exitVM 許可を アプリケーションに与えないことをお勧めします。

フィルター・ポリシーは、profile_root/config/cells/cell_name/filter.policy ファイルの filtermask によって定義されます。さらに、 WebSphere Application Server は、ランタイム・フィルター・ポリシーに基づいてランタイム許可フィルターも実行し、 システム保全性にとって有害と見なされる許可がアプリケーション・コードに付与されないようにします。

したがって、 WebSphere Application Server の前のリリース用に開発された多くのアプリケーションは、 Java 2 セキュリティーに対応する準備ができていませんでした。 was.policy ファイル内の java.security.AllPermission アクセス権を、 アプリケーションに一時的に与えることで、WebSphere Application Server の最新バージョンに、 これらのアプリケーションを速やかにマイグレーションすることができます。 Java 2 security がアクティブな環境で実行されていることを確認するために、これらのアプリケーションをテストします。 例えば、追加の許可が必要な場合は、どの許可が必要であるかを識別し、 特定のアプリケーションに対してそれらの許可のみを与えます。 アプリケーションに AllPermission 許可を付与しなければ、 システム保全性を危険にさらすリスクを軽減できます。 アプリケーションのマイグレーションについて詳しくは、 Java 2 セキュリティー・ポリシーのマイグレーション を参照してください。

WebSphere Application Server ランタイムは、Java 2 セキュリティーを使用して、 機密性の高いランタイム機能を保護します。 AllPermission 許可を付与されているアプリケーションは、 機密性の高いシステム・リソースへのアクセス権を持つだけでなく、 WebSphere Application Server ランタイムのリソースへのアクセス権も持ち、 両者に被害が及ぶ原因となる可能性があります。 アプリケーションが安全であると信頼できる場合、WebSphere Application Server は、 アプリケーション・サーバーごとに Java 2 セキュリティーを使用不可にすることをサポートします。 管理コンソールで Java 2 セキュリティーをデフォルトで実施し、 Java 2 セキュリティー・フラグをクリアして、 特定のアプリケーション・サーバーで Java 2 セキュリティーを使用不可にすることができます。

管理コンソールの「管理、アプリケーション、インフラス トラクチャーの保護」パネルで「管理セキュリティーを有効にする」および「 Java 2 セキュリティーを使用してアプリケーションのアクセスをローカル・リソースに制限する」オプションを指定すると 、その情報、およびその他の機密性の高い構成データは、XML 構成ファイルのセット内に保管されます。 役割ベースのアクセス制御および Java 2 セキュリティー許可ベース のアクセス制御は、いずれも構成データの保全性を保護するために使用されます。システム保全性の維持を 示すために、例では構成データの保護が使用されています。
重要: WebSphere Application Server の前のリリースの「グローバル・セキュリティーの使用可能化」オプションは、 バージョン 6.1 の「管理セキュリティーを有効にする」オプションと同じです。 また、前のリリースの「Enable Java 2 security」オプションは、 バージョン 6.1 の「Java 2 セキュリティーを使用してアプリケーションのアクセスをローカル・リソースに制限する」オプションと同じです。

その他のランタイム・リソース [AIX HP-UX Linux Solaris Windows] [i5/OS]

その他の WebSphere Application Server ランタイム・リソースは、 前述のような類似するメカニズムで保護されています。 WebSphere Application Server 管理セキュリティーを使用可能にし、 Java 2 セキュリティーを使用してローカル・リソースへのアプリケーション・アクセスを制限することは非常に重要です。 J2EE 仕様は、 HTTP 基本認証、フォーム・ベース認証、および HTTPS クライアント証明書認証などの Web コンポーネント向けの幾つかの認証メソッドを定義します。クライアント証明書ログインを使用する場合、 Web リソースが完全な、または機密のデータ制約を持っていれば、 ブラウザー・クライアントにとっては、さらに好都合になります。ブラウザーが HTTP を 使用して Web リソースにアクセスする場合、Web コンテナーはブラウザーを自動的に HTTPS ポートに リダイレクトします。CSIv2 セキュリティー・プロトコルも、クライアント証明書認証をサポートします。 SSL クライアント認証を使用して、信頼関係に基づいて、 選択された一連のサーバー間でセキュアな通信をセットアップすることもできます。

[z/OS] CSIv2 セキュリティー・プロトコルも、クライアント証明書認証をサポートします。 SSL クライアント認証を使用して、信頼関係に基づいて、 選択された一連のサーバー間でセキュア通信をセットアップすることもできます。

Web サーバーで WebSphere Application Server プラグインから開始する場合、 SSL 相互認証は、プラグインと WebSphere Application Server HTTPS サーバー間で構成できます。 証明書を使用する場合、以下の図に示されているように、WebSphere Application Server プラグイン を制約して、選択された 2 つの WebSphere Application Server とのみ通信するようにすることができます。 自己署名証明書を使用すれば、管理およびコストを削減できることに注意してください。
例えば、WebSphere Application Server A および WebSphere Application Server サーバー B において、HTTPS サーバーが WebSphere Application Server プラグイン W からのセキュア・ソケット接続のみを受信するように制限するとします。
  • [AIX HP-UX Linux Solaris Windows] [i5/OS] このタスクを実行するために、IKEYMAN および証明書管理ユーティリティーを使用して 3 つの証明書を生成することができます。また、証明書 W を使用し、証明書 A および B を信頼できます。 WebSphere Application Server A の HTTPS サーバーは、証明書 A を使用し、証明書 W を信頼するように構成されます。
  • [z/OS] このタスクを実行するために、Resource Access Control Facility (RACF) を使用して、 証明書 W、AB という 3 つの証明書を生成できます。 WebSphere Application Server プラグインは、 証明書 W を使用し、証明書 AB を信頼するように構成されます。 WebSphere Application Server A の HTTPS サーバーは、証明書 A を使用し、証明書 W を信頼するように構成されます。
WebSphere Application Server B の HTTPS サーバーは、証明書 B を使用し、証明書 W を信頼するように構成されます。
前出の図に示した信頼関係を、以下の表に示します。
サーバー 信頼
WebSphere Application Server プラグイン W A、B
WebSphere Application Server A A W
WebSphere Application Server B B W

WebSphere Application Server デプロイメント・マネージャーは管理の中心点です。 システム管理コマンドは、デプロイメント・マネージャーから、 個々のアプリケーション・サーバーに送信されます。 管理セキュリティー が使用可能である場合、WebSphere Application Server は、 SSL および相互認証を必要とするように構成できます。

WebSphere Application Server サーバー A を制限して、WebSphere Application Server C とのみ通信でき、 WebSphere Application Server B は WebSphere Application Server D とのみ通信するようにできます。 すべての WebSphere Application Server は、WebSphere Application Server デプロイメント・マネージャー E と通信可能である必要が あります。したがって、自己署名証明書を使用する場合、以下の表に示すように CSIv2 および SOAP/HTTPS 鍵、 および信頼関係を構成します。
サーバー 信頼
WebSphere Application Server A A C、E
WebSphere Application Server B B D、E
WebSphere Application Server C C A、E
WebSphere Application Server D D B、E
WebSphere Application Server デプロイメント・マネージャー E E A、B、C、D

WebSphere Application Server が Lightweight Directory Access Protocol (LDAP) ユーザー・レジストリー を使用するように構成されている場合、相互認証を行う SSL も、すべてのアプリケーション・サーバーと 自己署名証明書を使用する LDAP サーバーとの間に構成できます。これにより、 WebSphere Application Server から LDAP サーバーへパスワードが渡されるときにパスワードが不可視になります。

この例では、ノード・エージェントのプロセスについては説明されていません。各ノード・エージェントは、 同じノード上のアプリケーション・サーバーおよびデプロイメント・マネージャーと通信する必要があります。 ノード・エージェントは、LDAP ユーザー・レジストリーを使用するように構成されている場合は、 LDAP サーバーとも通信する必要があります。デプロイメント・マネージャーとノード・エージェントに 同じ証明書を使用させると合理的です。アプリケーション・サーバー A および C が、同じコンピューター・ノード上にあるとします。 そのノード上のノード・エージェントが、 自らのトラスト・ストア内に証明書 A および C を持つ必要があります。

[AIX HP-UX Linux Solaris Windows] [i5/OS] WebSphere Application Server は、 レジストリー構成も管理ユーティリティーも提供しません。 また、レジストリーのパスワード・ポリシーを指示しません。 使用しているレジストリーで推奨されているパスワード・ポリシーを、 パスワードの長さおよび有効期限も含めて使用することをお勧めします。




関連概念
アプリケーションとその環境の保護の概要と新機能
関連タスク
Java 2 セキュリティー・ポリシーのマイグレーション
管理の役割へのアクセスの許可
ネーミング役割へのユーザーの割り当て
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/csec_plan.html