| Oracle® Fusion Middleware Oracle WebLogic Serverの保護 11g リリース1 (10.3.6) B61617-06 |
|
 前 |
 次 |
以下の節では、WebLogicドメインのセキュリティ構成オプションの設定方法について説明します。
|
注意: これらの節は、このリリースのWebLogic Serverのセキュリティ機能を使用するWebLogic Serverデプロイメントと互換性セキュリティを使用するデプロイメントに適用されます。 |
この節では、クロス・ドメイン・セキュリティ・ソリューションのサポートに関する重要な情報について説明します。
「WebLogic Serverドメイン間の信頼の有効化」で説明するように、クロス・ドメイン・セキュリティではドメイン間の信頼関係が確立されて、一方のWebLogic Serverドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼出しを実行できるようになります。WebLogic Serverは、クロス・ドメイン・ユーザーのセキュリティ・ロールを確立し、各ドメインのWebLogic資格証明マッピング・セキュリティ・プロバイダを使用してクロス・ドメイン・ユーザーが使用する資格証明を格納します。
このリリースのWebLogic Serverでは、JMS、JTA、MDB、WANレプリケーションなどのサブシステムでクロス・ドメイン・セキュリティを実装しています。これらのシステムはドメイン間で必要な資格証明の認証や送信を行うことができます。
ただし、EJBコンテナはクロス・ドメイン・セキュリティのソリューションを実装していません。そのため、WLSクロス・ドメイン・セキュリティ機能は以下の状況では機能しません。
WLIドメイン
ALSB。SBトランスポートおよびDSPトランスポートを使用するようにALSBが構成されている場合。
ALDSPドメイン
これらのタイプのドメインでは、かわりにグローバル信頼機能を使用します。この機能では、各ドメインで同じドメイン資格証明を使用することにより、2つのドメイン間にグローバルな信頼が確立されます。WLSでグローバル信頼を使用する方法については、「グローバル信頼の有効化」を参照してください。
ドメイン間の信頼関係が確立されると、一方のWebLogicドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼出しを実行できます。以前のリリースのWebLogic Serverでは、現在は「グローバル信頼」と呼ばれる1つのタイプのドメイン信頼しかありませんでした。現在のWebLogic Serverでは、「クロス・ドメイン・セキュリティ」というドメイン信頼もサポートされています。次の項では、各ドメイン信頼の種類を構成する方法を説明します。
クロス・ドメイン・セキュリティでは、資格証明マッピング・プロバイダを使用してWebLogicドメイン間の通信を構成することにより、2つのWebLogicドメイン間に信頼が確立されます。クロス・ドメイン・セキュリティの構成および使用方法については、次の項を参照してください。
WebLogic Serverでは、クロス・ドメイン・セキュリティを実現する方法として、資格証明マッピング・セキュリティ・プロバイダを使用する方法だけでなく、2つ以上のドメインで同じドメイン資格証明を使用してグローバル信頼を確立する方法もサポートされています。2つ以上のドメインの間でグローバル信頼を有効にすると、遷移的で対称的な信頼関係が確立されます。つまり、ドメインAがドメインBを信頼し、ドメインBがドメインCを信頼する場合には、ドメインAもドメインCを信頼し、ドメインBとドメインCの両方がドメインAを信頼する関係です。ほとんどの場合に望ましいのは、グローバル信頼を使用する方法ではなく、クロス・ドメイン・セキュリティを使用する方法です。これは、クロス・ドメイン・アクション専用のユーザー・グループとロールを使用する後者のほうが、セキュリティをより細かく設定できるためです。WebLogic Serverでグローバル信頼を使用する方法については、「グローバル信頼の有効化」を参照してください。
WebLogicドメインでクロス・ドメイン・セキュリティを構成するには、SecurityConfigurationMBean.CrossDomainSecurityEnabled属性をtrueに設定します。この操作は、WebLogic Server管理コンソールで行います。
ホームページの「ドメイン構成」セクションでドメイン名をクリックします。
「セキュリティ」→「全般」を選択します。
「クロス・ドメイン・セキュリティの有効化」を選択します。
一部のWebLogicドメインでクロス・ドメイン・セキュリティを有効にしない場合は、それらのドメイン名をSecurityConfigurationMBean.ExcludedDomainNames属性の除外ドメインのリストに追加する必要があります。この操作は、WebLogic Server管理コンソールで行います。
ホームページの「ドメイン構成」セクションでドメイン名をクリックします。
「セキュリティ」→「全般」を選択します。
「除外するドメイン名」フィールドに、クロス・ドメイン・セキュリティを有効にしないドメインの名前をすべて入力します。複数のドメイン名を入力する場合は、セミコロンで区切るか、改行を挿入します。
WebLogic Serverのクロス・ドメイン・セキュリティでは、CrossDomainConnectorというグローバル・セキュリティ・ロール(リソース・タイプはリモート)と、CrossDomainConnectorsというグループ(CrossDomainConnectorロールを割り当てるグループ)を使用します。リモート・ドメインからの呼出しリクエストは、CrossDomainConnectorロールのユーザーから実行する必要があります。デフォルトでは、CrossDomainConnectorsグループにユーザーは登録されていません。1つまたは複数のユーザーを作成し、CrossDomainConnectorsグループに追加する必要があります。このようなユーザーとしては、通常は仮想的なシステム・ユーザーを使用し、できればCrossDomainConnectorセキュリティ・ロールによって付与される権限のみを付与するようにしてください。
|
注意: 資格証明マッパーは、ドメインをその名前で識別します。したがって、信頼関係に関与する各ドメインに一意の名前を付けることが重要です。 |
各WebLogicドメインでは、各ユーザーが信頼すべき各リモート・ドメインで使用する資格証明を指定する必要があります。そのためには、接続するドメインごとに資格証明マッピングを構成します。各資格証明マッピングでは、次を指定する必要があります。
リソース・プロトコル(cross-domain-protocol)
ローカル・ドメインと対話する必要のあるリモート・ドメインの名前
ローカル・ドメインとの対話を認可されたリモート・ドメインのユーザーの名前
ローカル・ドメインとの対話を認可されたリモート・ドメインのユーザーのパスワード
クロス・ドメイン・セキュリティ用の資格証明マッピングを構成するには、WebLogic Server管理コンソールの左パネルで「セキュリティ・レルム」をクリックします。
セキュリティ・レルムの名前をクリックします(デフォルトはmyrealm)。
「資格証明マッピング」→「デフォルト」を選択して、「新規」をクリックします。
「セキュリティ資格証明マッピングのリモート・リソースを作成」ページで次の操作を行います。
「クロスドメイン・プロトコルの使用」を選択します。
「リモート・ドメイン」フィールドに、ローカル・ドメインと対話する必要のあるリモート・ドメインの名前を入力します。
「次へ」をクリックします。
「新しいセキュリティ資格証明マップ・エントリの作成」ページで次の内容を入力します。
ローカル・ユーザー: cross-domain
リモート・ユーザー: ローカル・ドメインとの対話を認可されたリモート・ドメインに構成されているユーザー。
パスワード: リモート・ユーザーのパスワード。
「終了」をクリックします。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプのクロス・ドメイン・セキュリティの資格証明マッピングの作成に関する項を参照してください。
|
警告: WebLogicドメイン間のグローバル信頼を有効にすると、サーバーは中間者攻撃に対して無防備な状態になる可能性があります。本番環境で信頼関係を有効にする場合、十分に注意を払う必要があります。専用の通信チャネルなどの強力なネットワーク・セキュリティや、強力なファイアウォールによる保護の実施をお薦めします。 |
WebLogic Serverでは、2つ以上のドメインの間にグローバル信頼を確立できます。そのためには、それぞれのドメインに同じドメイン資格証明を指定します。ドメイン資格証明はデフォルトではランダムに生成されるため、2つのドメインが同じドメイン資格証明を持つことはありません。2つのWebLogicドメインを相互運用する場合は、生成された資格証明を選択した資格証明で置き換えて、同じ資格証明をそれぞれのドメインで設定する必要があります。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン間のグローバル信頼の有効化に関する項を参照してください。
2つのドメインの間でグローバル信頼を有効にすると、遷移的で対称的な信頼関係が確立されます。つまり、ドメインAがドメインBを信頼し、ドメインBがドメインCを信頼する場合には、ドメインAもドメインCを信頼し、ドメインBとドメインCの両方がドメインAを信頼する関係です。ほとんどの場合に望ましいのは、グローバル信頼を使用する方法ではなく、「WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化」で説明した資格証明マッパーを使用する方法です。これは、後者のほうがセキュリティをより細かく制御できるためです。
ドメイン間のグローバル信頼が確立されると、一方のWebLogicドメインのサブジェクト内のプリンシパルがもう一方のドメインのプリンシパルとして受け付けられます。この機能が有効になると、2番目のドメインでは認証が要求されることなく、IDがWebLogicドメイン間をRMI接続で渡されます (たとえば、ドメイン1にJoeとしてログインして、ドメイン2に対してRMI呼出しを行うと、Joeは引き続き認証されます)。WebLogic Serverは、プリンシパルの作成時にドメイン資格証明でプリンシパルに署名します。サブジェクトがリモート・ソースから受信されると、そのプリンシパルが検証されます(署名が再作成され、それが一致するとリモート・ドメインは同じドメインの資格証明を持ちます)。検証が失敗すると、エラーが生成されます。検証が成功すると、そのプリンシパルはローカルで作成されたかのように信頼されます。
|
注意: クリア・テキスト形式の資格証明は、次に |
管理対象サーバー環境でドメイン間のグローバル信頼を有効にする場合は、両方のドメインの管理サーバーとすべての管理対象サーバーを停止してから、再起動する必要があります。この手順を行わないと、再起動されなかったサーバーでは、再起動されたサーバーが信頼されなくなります。
WebLogicドメイン間のグローバル信頼を有効化するときには、次の点に注意してください。
ドメインは認証を必要とせずにリモート・プリンシパルを信頼するので、ドメインの認証データベースに定義されていない、認証済みユーザーがドメイン内に存在できることになります。この状況により、認可の問題が発生するおそれがあります。
ドメイン内の認証済みユーザーは、元のドメインとの信頼関係が有効化されている他のドメインに再認証なしでアクセスできます。こうしたログインに対する監査はなく、グループ・メンバーシップは検証されません。そのため、Joeが、認証された元のドメインのAdministratorsグループのメンバーである場合、Joeは自動的にRMI呼出しの対象となるすべての信頼されたドメインのAdministratorsグループのメンバーになります。
ドメイン2がドメイン1とドメイン3の両方を信頼している場合、ドメイン1とドメイン3は暗黙的にお互いを信頼するようになっています。そのため、ドメイン1のAdministratorsグループのメンバーは、ドメイン3のAdministratorsグループのメンバーになります。こうした信頼関係は、本来目的とする信頼関係ではない場合もあります。
WLSUser PrincipalクラスおよびWLSGroup Principalクラスを拡張した場合、カスタムPrincipalクラスは、信頼を共有するすべてのドメインのサーバーのCLASSPATHにインストールされる必要があります。
これらの問題を回避するため、2つのドメイン間でグローバル信頼を有効にする方法ではなく、「WebLogic Serverドメイン間のクロス・ドメイン・セキュリティの有効化」の説明に従って、CrossDomainConnectorロールのユーザーを構成して資格証明マッピングを使用する方法をお薦めします。
接続フィルタを使用すると、ネットワーク・レベルでアクセスを拒否できます。接続フィルタは、個々のサーバー、サーバー・クラスタ、または内部ネットワーク(イントラネット)にあるサーバー・リソースの保護に使用できます。たとえば、ユーザーの企業のネットワーク外部からの非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレス、およびDNSノード名に基づいてフィルタ処理するよう構成できる点において一種のファイアウォールです。
接続フィルタは、管理ポートを使用する場合に特に便利です。ネットワーク・ファイアウォール構成によっては、接続フィルタを使用して管理アクセスをさらに制限できる場合もあります。一般的には、管理ポートへのアクセスをドメイン内のサーバーやマシンのみに制限するために使用されることが考えられます。攻撃者がファイアウォールの内側にあるマシンにアクセスできても、それが許可されたマシンでない限り、管理操作を実行することはできません。
WebLogic Serverでは、weblogic.security.net.ConnectionFilterImplというデフォルトの接続フィルタが用意されています。この接続フィルタは、すべての着信接続を受け入れます。また、サーバーは、このクラスが提供する静的ファクトリ・メソッドを使うことで、現在の接続フィルタを取得できます。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic管理コンソールで接続フィルタ・ルールを入力するだけです。
また、weblogic.security.netパッケージのクラスを実装することで、カスタム接続フィルタを使用することもできます。接続フィルタの記述については、『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使い方に関する項を参照してください。デフォルト接続フィルタと同じように、カスタム接続フィルタもWebLogic管理コンソールで構成できます。
接続フィルタを構成するには:
受信メッセージのロギングを有効にします。「接続ログを有効化」オプションを使用すると、成功した接続と接続データがサーバーの接続ログに記録されます。この情報は、サーバーの接続に関連する問題をデバッグするために使用できます。
ドメインで使用する接続フィルタを選択します。
デフォルト接続フィルタを構成するには、「接続フィルタ」にweblogic.security.net.ConnectionFilterImplを指定します。
カスタム接続フィルタを構成するには、ネットワーク接続フィルタを実装するクラスを「接続フィルタ」フィールドで指定します。このクラス名は、WebLogic ServerのCLASSPATHにも指定する必要があります。
接続フィルタのルールの構文を入力します。
詳細は、以下を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続フィルタの構成に関する項を参照してください。
接続フィルタのルールとカスタム接続フィルタの作成については、『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使い方に関する項およびカスタム接続フィルタの開発に関する項を参照してください。
WebLogic Scripting ToolまたはJava Management Extensions (JMX) APIを使用して新しいセキュリティ構成を作成することもできます。
Java Authorization Contract for Containers (JACC)標準は、WebLogic Serverが提供するEJBおよびサーブレット・コンテナのデプロイメントおよび認可に取ってかわることができます。WebLogicドメインでJACCを使用するように構成すると、EJBおよびサーブレット認可の決定は、JACCフレームワーク内のクラスによって行われます。WebLogic Server内における他の認可決定はすべて、引き続きWebLogicセキュリティ・フレームワークによって行われます。WebLogic JACCプロバイダについては、『Oracle WebLogic Serverセキュリティのプログラミング』のJava Authorization Contract for Containersの使用に関する項を参照してください。
WebLogic Serverを構成してJACCを使用するには、コマンドライン起動オプションを使用します。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』の「weblogic.Serverコマンドライン・リファレンス」のDjava.security.managerオプションの説明を参照してください。
ドメインの管理サーバーと管理対象サーバーは、同じJACC構成を持つ必要があります。管理サーバーのJACC設定を変更した場合、セキュリティの低下を防ぐため、管理対象サーバーを再起動して管理サーバーと同じ設定を適用します。そうしないと、管理対象サーバーは実際にはJACCの下で動作しているのに、ドメイン内のEJBとサーブレットがWebLogicセキュリティ・フレームワークのロールとポリシーによって保護されているように見える場合があります。
「匿名Adminのルックアップを有効化」オプションでは、MBean APIからのWebLogic Server MBeanに対する読取り専用の匿名アクセスを許可するかどうかを指定します。この匿名アクセスを使用すると、WebLogic Server MBean認可プロセスによる保護が明示的に示されていない任意のMBean属性の値を参照できます。このオプションは後方互換性を確実にするために、デフォルトで有効になっています。セキュリティを高めるには、この匿名アクセスを無効にします。
WebLogic Server管理コンソールで「匿名Adminのルックアップを有効化」オプションの設定を検証するには、「ドメイン」→「セキュリティ」→「全般」を選択するか、SecurityConfigurationMBean.AnonymousAdminLookupEnabled属性を表示します。
WebLogicドメインのリソースにアクセスするためのパスワードを保護することは重要です。ユーザー名とパスワードは以前、WebLogicセキュリティ・レルムにクリア・テキストで保存されていました。現在ではWebLogicドメインのパスワードはすべてハッシュ化されています。パスワードのハッシュは、SerializedSystemIni.datファイルに格納されます。このファイルは特定のWebLogicドメインに関連付けられるため、ドメイン間で移動することはできません。
SerializedSystemIni.datファイルが破損した場合は、WebLogicドメインを再構成する必要があります。そのため、次の注意事項を考慮する必要があります。
SerializedSystemIni.datファイルのバックアップを作成し、安全な場所に保管します。
WebLogic Serverデプロイメントのシステム管理者が読み書き権限を持ち、その他のユーザーは何の権限も持たないように、SerializedSystemIni.datファイルに権限を設定します。
WebLogic Serverには、ユーザー・アカウントを侵入者から保護するための構成オプションが定義されています。デフォルト・セキュリティ構成では、これらのオプションは最高の保護レベルに設定されています。これらのオプションを変更するには、管理コンソールの「構成」→「ユーザーのロックアウト」ページを使用します。
システム管理者は、すべての構成オプションを無効にしたり、ユーザー・アカウントがロックされるまでのログイン試行回数を増やしたり、ユーザー・アカウントがロックされるまでの無効なログイン試行期間を延ばしたり、ユーザー・アカウントのロック時間を変更したりできます。これらの構成オプションを変更すると、セキュリティ・レベルが低下して攻撃を受けやすくなることに注意してください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー・ロックアウト属性の設定に関する項を参照してください。
|
注意: 「ユーザーのロックアウト」オプションは、デフォルト・セキュリティ・レルムとそのすべてのセキュリティ・プロバイダに適用されます。「ユーザーのロックアウト」オプションは、デフォルト・セキュリティ・レルム以外のセキュリティ・レルムにあるカスタム・セキュリティ・プロバイダでは機能しません。カスタム・セキュリティ・プロバイダで「ユーザーのロックアウト」オプションを使用するには、デフォルト・セキュリティ・レルムでカスタム・セキュリティ・プロバイダを構成します。デフォルト認証プロバイダやWebLogic IDアサーション・プロバイダの後の認証プロセスにカスタム・セキュリティ・プロバイダを含めます。この順序付けによって、パフォーマンスが若干低下することがあります。 ユーザー・アカウントを保護する独自のメカニズムを備えた認証プロバイダを使用する場合は、「ロック・アウトを有効化」オプションを無効化します。 ユーザー・アカウントがロックされたためそのユーザー・アカウントを削除して、同じ名前とパスワードを持つ別のユーザー・アカウントを追加しても、「ユーザーのロック・アウト」構成オプションはリセットされません。 |
ロックされたユーザー・アカウントの解除については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー・アカウントのロック解除に関する項を参照してください。ロックされたユーザー・アカウントに対するロックの解除は、WebLogic管理コンソールや、UserLockoutManagerRuntimeMBeanのclearLockout属性を介して行うことができます。
WebLogicドメインのセキュリティ構成は、JAAS認可を使用するように変更できます。JAAS認可は、WebLogicセキュリティ・サービスとは異なる方法でサブジェクトを解釈します。たとえば、OPSS (Oracle Platform Security Services)でJavaポリシー・プロバイダによって保護されるリソースへのアクセスをプリンシパルがリクエストする場合、プリンシパルは、ポリシー・ストアに含まれる名前で構築される別のプリンシパルと比較されます。(この比較は、Principal.equals()メソッドが呼び出されると行われます。)2つのプリンシパル・オブジェクトの適切な属性が一致する場合、アクセスは許可されます。
保護されたリソースへのアクセス決定を判断する場合、WebLogicセキュリティ・サービスでプリンシパルの比較は使用されません。ただし、デフォルトのWebLogicドメインでプリンシパルの比較が行われる場合、プリンシパル名の比較では大文字/小文字が区別され、プリンシパル名のみが比較されます。JAAS認可を使用するには、次のプリンシパル比較動作に適応するようにWebLogicドメインのセキュリティ構成を変更できます。
プリンシパル名の比較では大文字/小文字は区別されません。
WebLogicプリンシパル・オブジェクトのGUIDとDNのデータは比較に含まれます。
プリンシパル・オブジェクトをJAAS認可で使用するようにWebLogicドメインのセキュリティ構成を変更するには、次のMBean属性の設定を使用できます。
SecurityConfigurationMBean.PrincipalEqualsCaseInsensitive="true" SecurityConfigurationMBean.PrincipalEqualsCompareDnAndGuid="true"
これらの属性を設定するには、WebLogic Server管理コンソールで次の操作を行います。
管理コンソールの左ペインで、「ドメイン構造」の下にあるドメイン名を選択します。
「構成」→「セキュリティ」を選択して、「詳細」をクリックします。
次の各エントリの横にあるチェック・ボックスを選択します。
Principal Equalsの大文字/小文字を区別しない
Principal EqualsでDNとGUIDを比較
|
注意: プリンシパルでGUIDとDNのデータを使用するようにドメインが構成される場合、他のWebLogicドメイン(特に古いドメイン)との相互運用に影響があります。これは、IDエンティティを渡す方法が変更されることで生じます。 |
Oracle Platform Security Serviceでのプリンシパル比較については、『Oracle Fusion Middlewareセキュリティ・ガイド』のプリンシパル名の比較ロジックに関する項を参照してください。WebLogicドメインにIDを渡す場合の詳細は、『Oracle WebLogic Serverスタンドアロン・クライアントのプログラミング』を参照してください。
