インターネットで情報にアクセスする場合は、 Web サーバーおよび製品サーバーを介してバックエンドのエンタープライズ・データに接続します。 このセクションでは、いくつかの典型的な構成および共通のセキュリティー実践方法について検討します。
このセクションでは、各セキュリティー層で提供されるセキュリティー保護、 およびエンドツーエンド・セキュリティーにおける良質な保護の共通のセキュリティー実践方法についても検討します。 以下の図は、WebSphere Application Server 内のセキュリティーの オペレーティング環境を構成するビルディング・ブロックを示しています。
後方互換性のために、WebSphere Application Server は、WebSphere Application Server の前のリリースや 他の IBM 製品で使用されていた Secure Authentication Service (SAS) セキュリティー・プロトコルを サポートします。
基礎となるオペレーティング・システムのセキュリティー・インフラストラクチャーは、 特定のセキュリティー・サービスを 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) および Resource Access Control Facility (RACF)、 または同等の SAF ベースの製品に関する知識が必要です。
ユーザーの識別と確認は、 ローカル・オペレーティング・システムをユーザー・レジストリーとして使用することにより管理できます。 あるいは、RACF または同等の SAF ベースの製品を使用して管理することもできます。 代わりに、LDAP、カスタムまたは統合ユーザー・レジストリーを使用することもできます。
WebSphere は、SAF 許可を使用するように構成できます。 この場合は、RACF または同等の SAF ベースの製品を使用して、ユーザーとグループ・リソースが管理および保護さ れます。 代わりに、WebSphere 許可または JACC 外部許可プロバイダーを使用するように WebSphere を構成することもできます。
ローカル・オペレーティング・システムをユーザー・レジストリーとして使用する場合、 および/または SAF 許可を使用する場合、セキュリティー監査は RACF または同等の SAF ベースの製品の継承フィーチャーです。
各製品のアプリケーション・サーバーは、Web コンテナー、 Enterprise Java Beans (EJB) コンテナー、および管理サブシステムで構成されます。
WebSphere Application Server デプロイメント・マネージャーには、 WebSphere Application Server 管理コードと管理コンソールのみが含まれています。
管理コンソールは、 特殊な J2EE Web アプリケーションであり、管理機能を実行するためのインターフェースを提供します。 WebSphere Application Server 構成データは、オペレーティング・システム・セキュリティー が保護する必要のある、XML ディスクリプター・ファイルに保管されています。パスワードおよびその他の機密構成データは、管理コンソールを使用して変更できます。 ただし、これらのパスワードおよび機密データを保護する必要があります。詳しくは、ファイル内のパスワードのエンコード を参照してください。
管理コンソール Web アプリケーションには、 セットアップ・データの制約があります。 この制約によって、管理セキュリティー が使用可能になっている 際には、SSL 接続のみを使用して管理コンソール・サーブレットおよび JavaServer Pages (JSP) ファイルへアクセスする必要があります。
インストールした後、管理コンソール HTTPS ポートは、 デフォルトの自己署名証明書を用いて DummyServerKeyFile.jks および DummyServerTrustFile.jks を 使用するように構成されます。ダミー鍵およびトラスト・ストア証明書の使用は安全ではなく、 自ら所有する証明書を生成して、直ちにダミー証明書と置き換える必要があります。最初にグローバル・セキュリティーを使用可能にし、 グローバル・セキュリティーが実施されてから他の構成タスクを完了すれば、さらにセキュアになります。
次の図は、典型的な多層ビジネス・コンピューティング環境を
示しています。
WebSphere Application Servers は、 HTTP や HTTPS プロトコルだけでなく、CSIv2 や Secure Authentication Services (SAS) セキュリティー・プロトコルを介して、 相互に対話します。
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 を使用可能にして機密性が高い構成データを保護することをお勧めします。
グローバル・セキュリティーおよび管理セキュリティー構成は、セル・レベルで行われます。 グローバル・セキュリティーが使用可能な場合は、 サーバー・レベルで「グローバル・セキュリティーの使用可能化」オプションをクリアすることで、 個々のアプリケーション・サーバーのアプリケーション・セキュリティーを使用不可にできます。 詳しくは、特定のアプリケーション・サーバーの保護 を参照してください。アプリケーション・サーバーの セキュリティーを使用不可にしても、そのアプリケーション・サーバー内の管理サブシステム には影響を及ぼしません。この管理サブシステムは、グローバル・セキュリティー構成によってのみ 制御されています。管理サブシステムとアプリケーション・サーバー内のアプリケーション・コードはいずれも サーバーごとのオプションのセキュリティー・プロトコル構成を共用しています。
J2EE リソースのためのセキュリティーは、Web コンテナーおよび EJB コンテナーから提供されます。 それぞれのコンテナーは、 2 種類のセキュリティー (宣言セキュリティーとプログラマチック・セキュリティー) を提供します。
宣言セキュリティーでは、アプリケーションのセキュリティー構造に、 ネットワーク・メッセージの保全性と機密性、認証要件、セキュリティーの役割、およびアクセス制御などが含まれます。 アクセス制御はそのアプリケーション外部の形式で表されます。特にデプロイメント記述子は、 J2EE プラットフォームにおける宣言セキュリティーの主要な手段です。WebSphere Application Server は、 デプロイメント記述子から引き出され、XML ディスクリプター・ファイルのセットでデプロイヤーおよびアドミニストレーターが 指定する情報を含む J2EE セキュリティー・ポリシーを維持します。コンテナーは、 実行時には XML ディスクリプター・ファイルで定義されたセキュリティー・ポリシーを使用して、 データ制約とアクセス制御を実行します。
宣言セキュリティー単独ではアプリケーションの セキュリティー・モデルを表現するのに十分でない場合には、プログラマチック・セキュリティーを使用して アクセス判断を行うことができます。管理セキュリティー が使用可能で、 アプリケーション・サーバーのセキュリティーがサーバー・レベルで使用不可にされていない場合、 J2EE アプリケーション・セキュリティーが実施されます。 Web リソースに対して セキュリティー・ポリシーが指定されている場合、Web コンテナーは、Web クライアントがそのリソースを 要求したときにアクセス制御を実行します。Web コンテナーはそのクライアントの認証データで、指定した認証メソッドに適合するクライアントがないかを調べ、データ制約が満たされていることを確認して、 認証済みユーザーに必要なセキュリティー役割があるかどうかを判断します。Web セキュリティー・コラボレーターは、アクセス・マネージャー・インプリメンテーションを使用して、役割ベースのアクセス制御を実行します。 アクセス・マネージャーは、デプロイメント記述子から派生したセキュリティー・ポリシー に基づいて許可を決定します。認証済み のユーザー・プリンシパルは、必要なセキュリティー役割のいずれかを持っている場合に、要求したサーブレットまたは JSP ファイル へアクセスできます。 サーブレットと JSP ファイルは、HttpServletRequest メソッド (isUserInRole および getUserPrincipal) を使用できます。
グローバル・セキュリティーが 使用可能になっていて、アプリケーション・サーバーのセキュリティーが使用不可になっていない場合、 EJB コンテナーは EJB メソッドを起動してアクセス制御を実行します。
認証は、メソッド許可が特定の EJB メソッド用に定義されているか どうかに関係なく行われます。EJB セキュリティー・コラボレーターは、アクセス・マネージャー・インプリメンテーションを使用して、 役割ベースのアクセス制御を実行します。 アクセス・マネージャーは、デプロイメント記述子から派生したセキュリティー・ポリシー に基づいて許可を決定します。 認証済みのユーザー・プリンシパルは、必要なセキュリティー役割のいずれかを持っている場合に、要求した EJB メソッドへアクセスできます。EJB コードでは、EJBContext メソッドの isCallerInRole および getCallerPrincipal が使用できます。 J2EE 役割ベースのアクセス制御は、重要なビジネス・データがインターネットおよびイントラネットを介して、 無許可ユーザーによってアクセスされるのを防止するために使用します。 アセンブリー・ツールを使用した Web アプリケーションの保護 、および エンタープライズ Bean アプリケーションの保護 を参照してください。
コンフィギュレーター役割を持つユーザーは、 新規アプリケーションおよびアプリケーション・サーバーのインストールを含む、最も管理的な作業を実行できます。 管理セキュリティー が使用可能な場合に、コンフィギュレーターには十分な実行権限がない、 特定の構成タスクがあります。 これらのタスクには、WebSphere Application Server の ID とパスワードの変更、 Lightweight Third-Party Authentication (LTPA) パスワードと鍵の変更、 および管理セキュリティー役割へのユーザーの割り当てが含まれます。 これらの重要な構成タスクでは、 サーバー ID が管理者役割にマップされるため、管理役割が必要です。
WebSphere Application Server 管理セキュリティーは、 グローバル・セキュリティーが使用可能な場合に実施されます。 管理サブシステムの保全性を保護するために WebSphere Application Server グローバル・セキュリティーを使用可能にします。 保護すべき機密情報がない場合、アプリケーション・サーバーのセキュリティーは、 選択的に使用不可にできます。 管理セキュリティーの保護については、管理の役割へのアクセスの許可 および役割へのユーザーおよびグループの割り当て を参照してください。
WebSphere Application Server は、 Java 2 セキュリティー・モデルを使用して、アプリケーション・コードを実行するためのセキュア環境を作成します。 Java 2 セキュリティーは、きめの細かいポリシー・ベースの アクセス制御を提供して、ファイル、システム・プロパティーなどのシステム・リソース、ソケット接続の開始、ライブラリーのロードなどを保護します。 J2EE バージョン 1.4 仕様は、Web および EJB コンポーネントが持つと 予想される Java 2 セキュリティー許可の標準セットを定義します。これらの許可を、次の表に示します。
セキュリティー許可 | ターゲット | アクション |
---|---|---|
java.lang.RuntimePermission | loadLibrary | |
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | 接続 |
java.io.FilePermission | * | 読み取り、書き込み |
java.util.PropertyPermission | * | 読み取り |
セキュリティー許可 | ターゲット | アクション |
---|---|---|
java.lang.RuntimePermission | queuePrintJob | |
java.net.SocketPermission | * | 接続 |
java.util.PropertyPermission | * | 読み取り |
ポリシー管理を単純化するため、 WebSphere Application Server ポリシーは、コード・ベース (ロケーション) ではなく、 リソース・タイプに基づいています。 次のファイルは、WebSphere Application Server サブシステムの デフォルト・ポリシー・ファイルです。WebSphere Application Server ランタイムの拡張機能であるこれらのポリシー・ファイルは、 Service Provider Programming Interfaces (SPI) と呼ばれ、複数の J2EE アプリケーションによって共用されます。
このファイルは、Java Message Service (JMS)、JavaMail および JDBC ドライバーなど、 resources.xml ファイルに定義される組み込みリソースに使用されます。
このファイルは、WebSphere Application Server 管理コンソールが定義する共用ライブラリーによって使用されます。
このファイルは、J2EE アプリケーションにデフォルト・ポリシーとして使用されます。
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 セキュリティーを使用不可にすることができます。
管理コンソールの「グローバル・セキュリティー」パネルで「グローバル・セキュリティーの使用可能化」および「Enable Java 2 security」オプションを指定すると、 その情報、およびその他の機密性の高い構成データは、XML 構成ファイルのセット内に保管されます。 役割ベースのアクセス制御および Java 2 セキュリティー許可ベース のアクセス制御は、いずれも構成データの保全性を保護するために使用されます。システム保全性の維持を 示すために、例では構成データの保護が使用されています。
その他の WebSphere Application Server ランタイム・リソースは、 前述のような類似するメカニズムで保護されています。 WebSphere Application Server 管理セキュリティー の使用可能化および Java 2 セキュリティーの実施は非常に重要です。J2EE 仕様は、 HTTP 基本認証、フォーム・ベース認証、および HTTPS クライアント証明書認証などの Web コンポーネント向けの幾つかの認証メソッドを定義します。クライアント証明書ログインを使用する場合、 Web リソースが完全な、または機密のデータ制約を持っていれば、 ブラウザー・クライアントにとっては、さらに好都合になります。ブラウザーが HTTP を 使用して Web リソースにアクセスする場合、Web コンテナーはブラウザーを自動的に HTTPS ポートに リダイレクトします。CSIv2 セキュリティー・プロトコルも、クライアント証明書認証をサポートします。 SSL クライアント認証を使用して、信頼関係に基づいて、 選択された一連のサーバー間でセキュアな通信をセットアップすることもできます。
IKEYMAN に関して詳しくは、鍵管理ユーティリティー (iKeyman) の開始 を参照してください。
サーバー | 鍵 | 信頼 |
---|---|---|
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 は、ユーザー・レジストリー構成または管理ユーティリティーを提供しません。 また、ユーザー・レジストリーのパスワード・ポリシーを指示しません。 使用しているユーザー・レジストリーで推奨されているパスワード・ポリシーを、 パスワードの長さおよび有効期限も含めて使用することをお勧めします。