セキュリティー計画の概要
インターネットで情報にアクセスする場合は、 Web サーバーおよび製品サーバーを介してバックエンドのエンタープライズ・データに接続します。 このセクションでは、いくつかの典型的な構成および共通のセキュリティー実践方法について検討します。
このセクションでは、各セキュリティー層で提供されるセキュリティー保護、 およびエンドツーエンド・セキュリティーにおける良質な保護の共通のセキュリティー実践方法についても検討します。 以下の図は、WebSphere® Application Server 内のセキュリティーの オペレーティング環境を構成するビルディング・ブロックを示しています。
- WebSphere Application Server セキュリティー
- WebSphere セキュリティー
- WebSphere Application Server セキュリティーは、Web リソース、エンタープライズ Bean、および JMX 管理リソースへのアクセスに対して、セキュリティー・ポリシーおよびサービスを統合した方法で実行します。 これは WebSphere Application Server セキュリティー・テクノロジーとフィーチャーで構成され、 セキュア・エンタープライズ環境のニーズをサポートします。
- Java セキュリティー
- Java Platform, Enterprise Edition (Java EE) セキュリティー・アプリケーション・プログラミング・インターフェース (API)
- セキュリティー・コラボレーターは、Java Platform, Enterprise Edition (Java EE) ベースのセキュリティー・ポリシーを実行し、Java EE セキュリティー API をサポートします。
- Common Secure Interoperability Protocol Version 2 (CSIv2) を使用する EJB セキュリティー
- 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 セキュリティーは、 無制限のアクセスからメモリーを保護し、エラーがスレッド内で起こった場合に例外を作成し、配列型を定義します。
- プラットフォーム・セキュリティー
オペレーティング・システム・セキュリティー
基礎となるオペレーティング・システムのセキュリティー・インフラストラクチャーは、 特定のセキュリティー・サービスを WebSphere Application Server に提供します。 これらのサービスには、 WebSphere Application Server の製品インストールにおいて機密ファイルを保護する ファイル・システム・セキュリティー・サポートが含まれます。システム管理者は、 製品を構成して、オペレーティング・システムのユーザー・レジストリーから認証情報を 直接取得することができます。
オペレーティング・システム・セキュリティー
基礎となるオペレーティング・システムのセキュリティー・インフラストラクチャーは、 特定のセキュリティー・サービスを WebSphere Application Server に提供します。 STARTED プロファイルにより確立される、 サーバント、コントローラー、および「開始済みタスク」デーモンのオペレーティング・システム ID は、 ファイルまたはソケットなどのシステム・リソースへのアクセスを制御するために使用される ID です。 オプションで、オペレーティング・システム・セキュリティーは、WebSphere 管理コンソール、およびアプリケーション・サーバーの下で稼働するアプリケーションに対して、ローカル・オペレーティング・システムのユーザー・レジストリーを使用する認証サービス、および SAF 許可を使用する認証サービス、またはそのいずれかを提供することができます。
管理者は、Secure Sockets Layer (SSL) および Transport Layer Security (TLS) の知識の他に、System Authorization Facility (SAF) およびリソース・アクセス管理機能 (RACF®) または同等の SAF ベースの製品に関する知識が必要です。
ユーザーの識別と確認は、ローカル・オペレーティング・システムをユーザー・レジストリーとして使用することにより管理できます。 あるいは、RACF または同等の SAF ベースの製品を使用して管理することもできます。 代わりに、LDAP、カスタムまたは統合ユーザー・レジストリーを使用することもできます。
WebSphere は、SAF 許可を使用するように構成できます。 この場合は、RACF または同等の SAF ベースの製品を使用して、ユーザーとグループ・リソースが管理および保護されます。 代わりに、WebSphere 許可または JACC 外部許可プロバイダーを使用するように WebSphere を構成することもできます。
ローカル・オペレーティング・システムをユーザー・レジストリーとして使用する場合、および SAF 許可を使用する場合、またはそのいずれかの場合、セキュリティー監査は RACF または同等の SAF ベースの製品の継承フィーチャーです。
- ネットワーク・セキュリティー
- ネットワーク・セキュリティー層は、 トランスポート・レベルの認証およびメッセージの保全性と機密性を提供します。 別個のアプリケーション・サーバー間の通信は、Secure Sockets Layer (SSL) を使用するように構成することができます。また、メッセージ保護を更に強化するために、 IP セキュリティーおよび仮想私設網 (VPN) を使用することもできます。
製品の各アプリケーション・サーバーは、Web コンテナー、Enterprise Java Beans (EJB) コンテナー、および管理サブシステムで構成されます。
WebSphere Application Server デプロイメント・マネージャーには、 WebSphere Application Server 管理コードと管理コンソールのみが含まれています。
管理コンソールは、特殊な Java EE Web アプリケーションであり、管理機能を実行するためのインターフェースを提供します。 WebSphere Application Server 構成データは、オペレーティング・システム・セキュリティーが保護する必要のある、XML 記述子ファイルに保管されています。パスワードおよびその他の機密構成データは、管理コンソールを使用して変更できます。 ただし、これらのパスワードおよび機密データを保護する必要があります。詳しくは、ファイル内のパスワードのエンコードを参照してください。
管理コンソール Web アプリケーションには、 セットアップ・データの制約があります。 この制約によって、管理セキュリティー が使用可能になっている 際には、SSL 接続のみを使用して管理コンソール・サーブレットおよび JavaServer Pages (JSP) ファイルへアクセスする必要があります。
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 プロセスは、インストール直後にセキュアになります。WebSphere Application Server バージョン 7.0 では、チェーン証明書 (ルート証明書で署名された個人証明書) を作成することにより、組み込み証明書管理機能を拡張して、確立された信頼性に影響を及ぼさずに、個人証明書の更新を可能にします。
また、プロファイル作成時における証明書の作り替え (ユーザー独自の証明書をインポートするか、デフォルトで作成される証明書の識別名 (DN) を変更することが可能) を可能にしたり、デフォルトの鍵ストア・パスワードを変更する機能を使用可能にします。
次の図は、標準的な多層ビジネス・コンピューティング環境を示しています。
次の図は、標準的な多層ビジネス・コンピューティング環境を示しています。
管理セキュリティー
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
![[z/OS]](../images/ngzos.gif)
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 を使用可能にして機密性が高い構成データを保護することをお勧めします。
管理セキュリティー が使用不可の場合でも、
アプリケーションに対して HTTPS を使用可能にすることができます。
SSL ポートを、環境構成の仮想ホストに追加する場所以外に、
サーバー Web コンテナー内の HTTP ポート・リストにも追加することによって、SSL ポートを
特定のサーバー用に構成できます。HTTPS と正しいポートを使用して、
Web アプリケーションに接続できます。WebSphere Application Server for z/OS の内部通信では、管理セキュリティー を使用可能にしない限り、SSL は使用されません。
管理セキュリティーが使用可能な場合は、 サーバー・レベルで「管理セキュリティーを有効にする」オプションをクリアす ることで、個々のアプリケーション・サーバーのアプリケーション・セキュリティーを使用不可にできます。 詳しくは、特定のアプリケーション・サーバーの保護を参照してください。 アプリケーション・サーバーのセキュリティーを使用不可にしても、 そのアプリケーション・サーバー内の管理サブシステムには影響を及ぼしません。 この管理サブシステムは、セキュリティー構成によってのみ制御されています。 管理サブシステムとアプリケーション・サーバー内のアプリケーション・コードはいずれも サーバーごとのオプションのセキュリティー・プロトコル構成を共有しています。
Java EE リソースのためのセキュリティー
Java EE リソースのためのセキュリティーは、Web コンテナーおよび EJB コンテナーから提供されます。 それぞれのコンテナーは、 2 種類のセキュリティー (宣言セキュリティーとプログラマチック・セキュリティー) を提供します。
宣言セキュリティーでは、アプリケーションのセキュリティー構造に、 ネットワーク・メッセージの保全性と機密性、認証要件、セキュリティー・ロール、およびアクセス制御などが含まれます。 アクセス制御はそのアプリケーション外部の形式で表されます。特にデプロイメント記述子は、Java EE プラットフォームにおける宣言セキュリティーの主要な手段です。 WebSphere Application Server は、デプロイメント記述子から引き出され、XML 記述子ファイルのセットでデプロイヤーおよびアドミニストレーターによって指定された情報を含む Java EE セキュリティー・ポリシーを維持します。 コンテナーは、実行時には XML 記述子ファイルで定義されたセキュリティー・ポリシーを使用して、データ制約とアクセス制御を実行します。
宣言セキュリティー単独ではアプリケーションの セキュリティー・モデルを表現するのに十分でない場合には、プログラマチック・セキュリティーを使用して アクセス判断を行うことができます。管理セキュリティーが使用可能で、アプリケーション・サーバーのセキュリティーがサーバー・レベルで使用不可にされていない場合、Java EE アプリケーション・セキュリティーが施行されます。 Web リソースに対して セキュリティー・ポリシーが指定されている場合、Web コンテナーは、Web クライアントがそのリソースを 要求したときにアクセス制御を実行します。Web コンテナーはそのクライアントの認証データで、指定した認証メソッドに適合するクライアントがないかを調べ、データ制約が満たされていることを確認して、 認証済みユーザーに必要なセキュリティー・ロールがあるかどうかを判断します。Web セキュリティー・コラボレーターは、アクセス・マネージャー実装を使用して、 ロール・ベースのアクセス制御を実行します。 アクセス・マネージャーは、デプロイメント記述子から派生したセキュリティー・ポリシー に基づいて許可を決定します。認証済みのユーザー・プリンシパルは、必要なセキュリティー・ロールのいずれかを持っている場合に、要求したサーブレットまたは JSP ファイルへアクセスできます。 サーブレットと JSP ファイルは、HttpServletRequest メソッド (isUserInRole および getUserPrincipal) を使用できます。
管理セキュリティーとアプリケーション・セキュリティーが使用可能になっていて、
アプリケーション・サーバー・レベルのアプリケーション・セキュリティーが使用不可になっていない場合、
EJB コンテナーは EJB メソッドを起動してアクセス制御を実行します。
セル・レベル・セキュリティーが使用可能になっている場合、
サーバーのセキュリティーが使用不可になっていない限り、EJB コンテナーは EJB メソッドを起動して
アクセス制御を実行します。
認証は、メソッド許可が特定の EJB メソッド用に定義されているか どうかに関係なく行われます。EJB セキュリティー・コラボレーターは、アクセス・マネージャー実装を使用して、 ロール・ベースのアクセス制御を実行します。 アクセス・マネージャーは、デプロイメント記述子から派生したセキュリティー・ポリシー に基づいて許可を決定します。認証済みのユーザー・プリンシパルは、必要なセキュリティー・ロールのいずれかを持っている場合に、要求した EJB メソッドへアクセスできます。EJB コードでは、EJBContext メソッドの isCallerInRole および getCallerPrincipal が使用できます。 Java EE ロール・ベースのアクセス制御は、重要なビジネス・データがインターネットおよびイントラネットを介して、無許可ユーザーによってアクセスされるのを防止するために使用します。 アセンブリー・ツールを使用した Web アプリケーションの保護、および エンタープライズ Bean アプリケーションの保護 を参照してください。
ロール・ベースのセキュリティー
- モニター・ロール
- モニターは構成情報および状況を表示できますが、変更することはできません。
- オペレーター・ロール
- オペレーターは、アプリケーション・サーバーの始動やアプリケーションの停止など、 ランタイム状態の変更を起動できますが、構成の変更はできません。
- コンフィギュレーター・ロール
- コンフィギュレーターは構成情報を変更できますが、ランタイム状態を変更できません。
- 管理者ロール
- オペレーターのほか、コンフィギュレーターのロールも併せ持ち、さらに、サーバー ID やパスワードの設定などの機密性の高いセキュリティー構成およびセキュリティー・ポリシーを変更でき、管理セキュリティーおよび Java 2 セキュリティーを使用可能または使用不可に設定し、ユーザーとグループを管理者ロールにマップすることができます。
- iscadmins
- iscadmins ロールは、管理コンソール内のみのユーザーとグループを管理する管理者特権を有しています。
- デプロイヤー
- デプロイヤーは、アプリケーションに対し、構成操作、および実行時の操作の両方を実行できます。
- Adminsecuritymanager
- 管理セキュリティー・マネージャーによって、 ユーザーを管理ロールにマップすることができます。 また、詳細な管理セキュリティーが使用されている場合、このロールを付与されたユーザーは、許可グループを管理することができます。
- 監査員
- 監査員は、セキュリティー監査サブシステムの構成設定を表示および変更できます。
コンフィギュレーター・ロールを持つユーザーは、 新規アプリケーションおよびアプリケーション・サーバーのインストールを含む、最も管理的な作業を実行できます。 管理セキュリティー が使用可能な場合に、コンフィギュレーターには十分な実行権限がない、 特定の構成タスクがあります。 これらのタスクには、WebSphere Application Server の ID とパスワードの変更、 Lightweight Third-Party Authentication (LTPA) パスワードと鍵の変更、 および管理セキュリティー・ロールへのユーザーの割り当てが含まれます。 これらの重要な構成タスクでは、サーバー ID が管理者ロールにマップされるため、管理ロールが必要です。
管理サブシステムの保全性を保護 するために、WebSphere Application Server 管理セキュリティーを使用可能にします。 保護すべき機密情報がない場合、アプリケーション・サーバーのセキュリティーは、 選択的に使用不可にできます。 管理セキュリティーの保護については、管理ロールへのアクセスの許可およびロールへのユーザーおよびグループの割り当てを参照してください。
Java 2 セキュリティー権限
WebSphere Application Server は、Java 2 セキュリティー・モデルを使用して、アプリケーション・コードを実行するためのセキュア環境を作成します。 Java 2 セキュリティーは、きめの細かいポリシー・ベースのアクセス制御を提供して、ファイル、システム・プロパティーなどのシステム・リソース、ソケット接続の開始、ライブラリーのロードなどを保護します。 Java EE バージョン 1.4 仕様は、Web および EJB コンポーネントが持つと予想される Java 2 セキュリティー権限の標準セットを定義します。
セキュリティー権限 | ターゲット | アクション |
---|---|---|
java.lang.RuntimePermission | loadLibrary | |
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | 接続 |
java.io.FilePermission | * | 読み取り、書き込み |
java.util.PropertyPermission | * | read |
セキュリティー権限 | ターゲット | アクション |
---|---|---|
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | 接続 |
java.util.PropertyPermission | * | read |
/QIBM/ProdData/Java400/jdk15/lib/security/java.policy
Java 仮想マシン (JVM) 用のデフォルト・ポリシーとして使用されます。
${java.home}/jre/lib/security/java.policy
このファイルは、Java 仮想マシン (JVM) 用のデフォルト・ポリシーとして使用されます。
${USER_INSTALL_ROOT}/properties/server.policy
このファイルは、すべての製品サーバー・プロセスにデフォルト・ポリシーとして使用されます。
$WAS_HOME/properties/server.policy
このファイルは、すべての製品サーバー・プロセスにデフォルト・ポリシーとして使用されます。
ポリシー管理を単純化するため、 WebSphere Application Server ポリシーは、コード・ベース (ロケーション) ではなく、 リソース・タイプに基づいています。 次のファイルは、WebSphere Application Server サブシステムの デフォルト・ポリシー・ファイルです。WebSphere Application Server ランタイムの拡張機能であるこれらのポリシー・ファイルは、Service Provider Programming Interface (SPI) と呼ばれ、複数の Java EE アプリケーションによって共有されます。
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
- 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
このファイルは、Java EE アプリケーション用のデフォルト・ポリシーとして使用されます。
![[z/OS]](../images/ngzos.gif)
- $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
このファイルは、Java EE アプリケーション用のデフォルト・ポリシーとして使用されます。
![[IBM i]](../images/iseries.gif)
- 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
Java EE アプリケーション用のデフォルト・ポリシーとして使用されます。
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 セキュリティーがアクティブになっている環境で実行されることを確認するために、これらのアプリケーションをテストします。 例えば、追加の許可が必要な場合は、どの許可が必要であるかを識別し、 特定のアプリケーションに対してそれらの許可のみを与えます。 アプリケーションに 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 セキュリティーが実施されていると、 アプリケーション・コードは必要な WebSphere Application Server ランタイム許可を与えられていない限り、 構成データを管理する WebSphere Application Server ランタイム・クラスにアクセスできません。
- Java 2 セキュリティーが施行されていると、アプリケーション・コードは、必要なファイル読み取りおよび書き込み許可を与えられていない限り、WebSphere Application Server 構成 XML ファイルにアクセスできません。
- JMX 管理サブシステムは、SOAP over HTTP または SOAP over HTTPS、 および RMI/IIOP リモート・インターフェースを提供して、アプリケーション・プログラムが 構成ファイルやデータの抽出および変更をできるようにします。管理セキュリティーが使用可能になっていると、 アプリケーション・プログラムが有効な認証データを提供し、 セキュリティー ID が必要なセキュリティー・ロールを持っている場合に、 アプリケーション・プログラムは WebSphere Application Server 構成を変更できます。
- ユーザーが Java 2 セキュリティーを使用不可にできる場合、 WebSphere Application Server のセキュリティー ID と認証データを含む WebSphere Application Server 構成を、 その他の機密データとともに変更できます。管理者セキュリティー・ロールを持つユーザーだけが、Java 2 セキュリティーを使用不可にできます。
- 管理者ロールには WebSphere Application Server セキュリティー ID が与えられているので、 管理者ロールを持つユーザーだけが、管理セキュリティー の使用不可化、 サーバー ID とパスワードの変更、およびユーザーとグループの管理ロールへのマップなどを実行できます。
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
その他のランタイム・リソース
その他の WebSphere Application Server ランタイム・リソースは、 前述のような類似するメカニズムで保護されています。 WebSphere Application Server 管理セキュリティーを使用可能にし、Java 2 セキュリティーを使用してローカル・リソースへのアプリケーション・アクセスを制限することは非常に重要です。Java EE 仕様は、HTTP 基本認証、フォーム・ベース認証、および HTTPS クライアント証明書認証などの Web コンポーネント向けのいくつかの認証メソッドを定義します。 クライアント証明書ログインを使用する場合、 Web リソースが完全な、または機密のデータ制約を持っていれば、 ブラウザー・クライアントにとっては、さらに好都合になります。ブラウザーが HTTP を 使用して Web リソースにアクセスする場合、Web コンテナーはブラウザーを自動的に HTTPS ポートに リダイレクトします。CSIv2 セキュリティー・プロトコルも、クライアント証明書認証をサポートします。 SSL クライアント認証を使用して、信頼関係に基づいて、 選択された一連のサーバー間でセキュアな通信をセットアップすることもできます。
CSIv2 セキュリティー・プロトコルも、クライアント証明書認証をサポートします。
SSL クライアント認証を使用して、信頼関係に基づいて、
選択された一連のサーバー間でセキュア通信をセットアップすることもできます。

このタスクを実行するために、IKEYMAN および証明書管理ユーティリティーを使用して 3 つの証明書を生成することができます。また、証明書 W を使用し、証明書 A および B を信頼できます。 WebSphere Application Server A の HTTPS サーバーは、証明書 A を使用し、証明書 W を信頼するように構成されます。
このタスクを実行するために、リソース・アクセス管理機能 (RACF) を使用して、W、A、および B という 3 つの証明書を生成できます。 証明書 W を使用し、証明書 A および B を信頼するように WebSphere Application Server プラグインを構成します。 WebSphere Application Server A の HTTPS サーバーは、証明書 A を使用し、証明書 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 | 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 を持つ必要があります。
WebSphere Application Server は、レジストリー構成も管理ユーティリティーも提供しません。また、レジストリーのパスワード・ポリシーを指示しません。
使用しているレジストリーで推奨されているパスワード・ポリシーを、
パスワードの長さおよび有効期限も含めて使用することをお勧めします。