インターネットで情報にアクセスする場合は、 Web サーバーおよび製品サーバーを介してバックエンドのエンタープライズ・データに接続します。 このセクションでは、いくつかの典型的な構成および共通のセキュリティー実践方法について検討します。
このセクションでは、各セキュリティー層で提供されるセキュリティー保護、 およびエンドツーエンド・セキュリティーにおける良質な保護の共通のセキュリティー実践方法についても検討します。 以下の図は、WebSphere Application Server 内のセキュリティーの オペレーティング環境を構成するビルディング・ブロックを示しています。
後方互換性のために、WebSphere Application Server は、WebSphere Application Server の前のリリースや
他の IBM 製品で使用されていた Secure Authentication Service (SAS) セキュリティー・プロトコルを
サポートします。
基礎となるオペレーティング・システムのセキュリティー・インフラストラクチャーは、 特定のセキュリティー・サービスを WebSphere Application Server に提供します。 これらのサービスには、 WebSphere Application Server の製品インストールにおいて機密ファイルを保護する ファイル・システム・セキュリティー・サポートが含まれます。システム管理者は、 製品を構成して、オペレーティング・システムのユーザー・レジストリーから認証情報を 直接取得することができます。
各製品のアプリケーション・サーバーは、Web コンテナー、 Enterprise Java Beans (EJB) コンテナー、および管理サブシステムで構成されます。
管理コンソールは、 特殊な J2EE 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 管理セキュリティー を使用可能にすると、 これらのプロトコルを 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 は、 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 セキュリティーを使用不可にすることができます。
その他の WebSphere Application Server ランタイム・リソースは、 前述のような類似するメカニズムで保護されています。 WebSphere Application Server 管理セキュリティーを使用可能にし、 Java 2 セキュリティーを使用してローカル・リソースへのアプリケーション・アクセスを制限することは非常に重要です。 J2EE 仕様は、 HTTP 基本認証、フォーム・ベース認証、および HTTPS クライアント証明書認証などの Web コンポーネント向けの幾つかの認証メソッドを定義します。クライアント証明書ログインを使用する場合、 Web リソースが完全な、または機密のデータ制約を持っていれば、 ブラウザー・クライアントにとっては、さらに好都合になります。ブラウザーが HTTP を 使用して Web リソースにアクセスする場合、Web コンテナーはブラウザーを自動的に HTTPS ポートに リダイレクトします。CSIv2 セキュリティー・プロトコルも、クライアント証明書認証をサポートします。 SSL クライアント認証を使用して、信頼関係に基づいて、 選択された一連のサーバー間でセキュアな通信をセットアップすることもできます。
サーバー | 鍵 | 信頼 |
---|---|---|
WebSphere Application Server プラグイン | W | A、B |
WebSphere Application Server A | A | W |
WebSphere Application Server B | B | W |
WebSphere Application Server が Lightweight Directory Access Protocol (LDAP) ユーザー・レジストリー を使用するように構成されている場合、相互認証を行う SSL も、すべてのアプリケーション・サーバーと 自己署名証明書を使用する LDAP サーバーとの間に構成できます。これにより、 WebSphere Application Server から LDAP サーバーへパスワードが渡されるときにパスワードが不可視になります。
WebSphere Application Server は、 レジストリー構成も管理ユーティリティーも提供しません。 また、レジストリーのパスワード・ポリシーを指示しません。 使用しているレジストリーで推奨されているパスワード・ポリシーを、 パスワードの長さおよび有効期限も含めて使用することをお勧めします。
Simple WebSphere Authentication Mechanism (SWAM) は、
WebSphere Application Server バージョン 6.1 では推奨されません。
将来のリリースでは除去される予定です。
代わりに、Lightweight Third Party Authentication (LTPA) を使用することとお勧めします。