|
|
以下の節では、WebLogic ドメインのセキュリティ コンフィグレーション オプションの設定方法について説明します。
| 注意 : | これらの節は、このリリースの WebLogic Server のセキュリティ機能を使用する WebLogic Server デプロイメントと互換性セキュリティを使用するデプロイメントに適用されます。 |
| 注意 : | WebLogic Server ドメイン間の信頼関係を有効にすると、サーバは介在者の攻撃に対して無防備な状態になる可能性があります。プロダクション環境で信頼関係を有効にする場合、十分に注意を払う必要があります。専用の通信チャネルなどの強力なネットワーク セキュリティや、強力なファイアウォールによる保護の実施をお勧めします。 |
ドメイン間の信頼関係が確立されると、一方の WebLogic Server ドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼び出しを実行できます。WebLogic Server は、クロスドメイン ユーザのセキュリティ ロールを確立し、各ドメインの WebLogic 資格マッピング セキュリティ プロバイダを使用してクロスドメイン ユーザが使用する資格を格納します。
資格マッパーは、ドメインをその名前で識別します。したがって、信頼関係に関与する各ドメインにユニークな名前を付けることが重要です。
クロスドメイン セキュリティのコンフィグレーションおよび使用方法については、以下の節を参照してください。
WebLogic Server では、クロスドメイン セキュリティを実現する方法として、資格マッピング セキュリティ プロバイダを使用する方法だけでなく、2 つのドメインで同じドメイン資格を使用してグローバル信頼を確立する方法もサポートされています。2 つのドメインの間でグローバル信頼を有効にすると、遷移的で対称的な信頼関係が確立されます。つまり、ドメイン A がドメイン B を信頼し、ドメイン B がドメイン C を信頼する場合には、ドメイン A もドメイン C を信頼し、ドメイン B とドメイン C の両方がドメイン A を信頼する関係です。ほとんどの場合に望ましいのは、グローバル信頼を使用する方法ではなく、資格マッパーを使用する方法です。これは、クロスドメイン アクション専用のユーザ グループとロールを使用する後者のほうが、セキュリティをより細かく設定できるためです。WebLogic Server でグローバル信頼を使用する方法については、「グローバル信頼の有効化」を参照してください。
WebLogic Server ドメインでクロスドメイン セキュリティをコンフィグレーションするには、SecurityConfigurationMBean.CrossDomainSecurityEnabled 属性を true に設定します。この操作は、WebLogic Server Administration Console で行います。
一部の WebLogic Server ドメインでクロスドメイン セキュリティを有効にしない場合は、それらのドメイン名を SecurityConfigurationMBean.ExcludedDomainNames 属性の除外ドメインのリストに追加する必要があります。この操作は、WebLogic Server Administration Console で行います。
WebLogic Server のクロスドメイン セキュリティでは、CrossDomainConnector というグローバル セキュリティ ロール (リソース タイプはリモート) と、CrossDomainConnectors というグループ (CrossDomainConnector ロールを割り当てるグループ) を使用します。リモート ドメインからの呼び出しリクエストは、CrossDomainConnector ロールのユーザから実行する必要があります。デフォルトでは、CrossDomainConnectors にユーザは登録されていません。1 つまたは複数のユーザを作成し、CrossDomainConnectors グループに追加する必要があります。このようなユーザとしては、通常は仮想的なシステム ユーザを使用し、できれば CrossDomainConnector セキュリティ ロールによって付与される権限のみを付与するようにしてください。
各 WebLogic Server ドメインでは、各ユーザが信頼すべき各リモート ドメインで使用する資格を指定する必要があります。そのためには、接続するドメインごとに資格マッピングをコンフィグレーションします。各資格マッピングでは、以下を指定する必要があります。
クロスドメイン セキュリティ用の資格マッピングをコンフィグレーションするには、WebLogic Server Administration Console の左パネルで [セキュリティ レルム] をクリックし、次の手順に従います。
Administration Console オンライン ヘルプの「クロスドメインのセキュリティ資格マッピングの作成」を参照してください。
WebLogic Server では、2 つ以上のドメインの間にグローバル信頼を確立できます。そのためには、それぞれのドメインに同じドメイン資格を指定します。ドメイン資格はデフォルトではランダムに生成されるため、2 つのドメインが同じドメイン資格を持つことはありません。2 つの WebLogic Server ドメインを相互運用する場合は、生成された資格を選択した資格で置き換えて、同じ資格をそれぞれのドメインで設定する必要があります。詳細については、Administration Console オンライン ヘルプの「ドメイン間のグローバル信頼の有効化」を参照してください。
2 つのドメインの間でグローバル信頼を有効にすると、遷移的で対称的な信頼関係が確立されます。つまり、ドメイン A がドメイン B を信頼し、ドメイン B がドメイン C を信頼する場合には、ドメイン A もドメイン C を信頼し、ドメイン B とドメイン C の両方がドメイン A を信頼する関係です。ほとんどの場合に望ましいのは、グローバル信頼を使用する方法ではなく、「WebLogic Server ドメイン間の信頼関係の有効化」で説明した資格マッパーを使用する方法です。これは、後者のほうがセキュリティをより細かく制御できるためです。
ドメイン間のグローバル信頼が確立されると、一方の WebLogic Server ドメインのサブジェクト内のプリンシパルがもう一方のドメインのプリンシパルとして受け付けられます。この機能が有効になると、ID が WebLogic Server ドメイン間を RMI 接続で渡されます (2 番目のドメインでは認証が不要)。たとえば、ドメイン 1 に Joe としてログインして、ドメイン 2 に対して RMI 呼び出しを行うと、Joe は引き続き認証されます。WebLogic Server は、プリンシパルの作成時にドメイン資格でプリンシパルに署名します。サブジェクトがリモート ソースから受信されると、そのプリンシパルが検証されます (シグネチャが再作成され、それが一致するとリモート ドメインは同じドメインの資格を持ちます)。検証が失敗すると、エラーが生成されます。検証が成功すると、そのプリンシパルはローカルで作成されたかのように信頼されます。
| 注意 : | クリア テキスト形式の資格は、次に config.xml ファイルがディスクに保存されるときに暗号化されます。 |
管理対象サーバ環境でドメイン間のグローバル信頼を有効にする場合は、両方のドメインの管理サーバとすべての管理対象サーバを停止してから、再起動する必要があります。この手順を行わないと、再起動されなかったサーバでは、再起動されたサーバが信頼されなくなります。
WebLogic Server ドメイン間のグローバル信頼を有効化するときには、次の点に注意してください。
これらの問題を回避するため、2 つのドメイン間でグローバル信頼を有効にする方法ではなく、「WebLogic Server ドメイン間の信頼関係の有効化」の説明に従って、CrossDomainConnector ロールのユーザをコンフィグレーションして資格マッピングを使用する方法をお勧めします。
接続フィルタを使用すると、ネットワーク レベルでアクセスを拒否できます。接続フィルタは、個々のサーバ、サーバ クラスタ、または内部ネットワーク (イントラネット) にあるサーバ リソースの保護に使用できます。たとえば、ユーザの企業のネットワーク外部からの非 SSL 接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IP アドレス、および DNS ノード名に基づいてフィルタ処理するようコンフィグレーションできる点において一種のファイアウォールです。
接続フィルタは、管理ポートを使用する場合に特に便利です。ネットワーク ファイアウォール コンフィグレーションによっては、接続フィルタを使用して管理アクセスをさらに制限できる場合もあります。一般的には、管理ポートへのアクセスをドメイン内のサーバやマシンのみに制限するために使用されることが考えられます。攻撃者がファイアウォールの内側にあるマシンにアクセスできても、それが許可されたマシンでない限り、管理操作を実行することはできません。
WebLogic Server では、weblogic.security.net.ConnectionFilterImpl というデフォルトの接続フィルタが用意されています。この接続フィルタは、すべての着信接続を受け入れます。また、サーバは、このクラスが提供する静的ファクトリ メソッドを使うことで、現在の接続フィルタを取得できます。アクセスを拒否するようにこの接続フィルタをコンフィグレーションするには、WebLogic Administration Console で接続フィルタ ルールを入力するだけです。
また、weblogic.security.net パッケージのクラスを実装することで、カスタム接続フィルタを使用することもできます。接続フィルタの記述については、『WebLogic Security プログラマーズ ガイド』の「ネットワーク接続フィルタの使い方」を参照してください。デフォルト接続フィルタと同じように、カスタム接続フィルタも WebLogic Administration Console でコンフィグレーションできます。
接続フィルタをコンフィグレーションするには、次の手順に従います。
Java Authorization Contract for Containers (JACC) 標準は、WebLogic Server が提供する EJB およびサーブレット コンテナのデプロイメントおよび認可に取って代わることができます。WebLogic Server ドメインで JACC を使用するようにコンフィグレーションすると、EJB およびサーブレット認可の決定は、JACC フレームワーク内のクラスによって行われます。WebLogic Server 内における他の認可決定はすべて、引き続き WebLogic Security フレームワークによって行われます。WebLogic JACC プロバイダについては、『WebLogic Security プログラマーズ ガイド』の「Java Authorization Contract for Containers の使用」を参照してください。
WebLogic Server をコンフィグレーションして JACC を使用するには、コマンドライン起動オプションを使用します。詳細については、「weblogic.Server コマンドライン リファレンス」の -Djava.security.manager オプションの説明を参照してください。
ドメインの管理サーバと管理対象サーバは、同じ JACC コンフィグレーションを持つ必要があります。管理サーバの JACC 設定を変更した場合、セキュリティの低下を防ぐため、管理対象サーバを再起動して管理サーバと同じ設定を適用します。このようにしない場合、管理対象サーバは実際には JACC の下で動作しているのに、ドメイン内の EJB とサーブレットが WebLogic Security フレームワークのロールとポリシーによって保護されているように見える場合があります。
[匿名 Admin のルックアップを有効化] オプションでは、MBean API からの WebLogic Server MBean に対する読み込み専用の匿名アクセスを許可するかどうかを指定します。この匿名アクセスを使用すると、WebLogic Server MBean 認可プロセスによる保護が明示的に示されていない任意の MBean 属性の値を参照できます。このオプションは下位互換性を確実にするために、デフォルトで有効になっています。セキュリティを高めるには、この匿名アクセスを無効にします。
WebLogic Administration Console で [匿名 Admin のルックアップを有効化] オプションの設定を検証するには、Administration Console の [ドメイン : セキュリティ : 全般] ページか、SecurityConfigurationMBean.AnonymousAdminLookupEnabled 属性を参照します。
WebLogic Server ドメインのリソースにアクセスするためのパスワードを保護することは重要です。ユーザ名とパスワードは以前、WebLogic セキュリティ レルムにクリア テキストで保存されていました。現在では WebLogic Server ドメインのパスワードはすべてハッシュ化されています。パスワードのハッシュは、SerializedSystemIni.dat ファイルに格納されます。このファイルは特定の WebLogic Server ドメインに関連付けられるため、ドメイン間で移動することはできません。
SerializedSystemIni.dat ファイルが破損した場合は、WebLogic Server ドメインを再コンフィグレーションしなくてはなりません。そのため、以下の注意事項を考慮する必要があります。
WebLogic Server には、ユーザ アカウントを侵入者から保護するためのコンフィグレーション オプションが定義されています。デフォルト セキュリティ コンフィグレーションでは、これらのオプションは最高の保護レベルに設定されています。これらのオプションを変更するには、Administration Console の [コンフィグレーション｜ユーザのロックアウト] ページを使用します。
システム管理者は、すべてのコンフィグレーション オプションを無効にしたり、ユーザ アカウントがロックされるまでのログイン試行回数を増やしたり、ユーザ アカウントがロックされるまでの無効なログイン試行期間を延ばしたり、ユーザ アカウントのロック時間を変更したりできます。これらのコンフィグレーション オプションを変更すると、セキュリティ レベルが低下して攻撃を受けやすくなることに注意してください。Administration Console オンライン ヘルプの「ユーザ ロックアウト属性の設定」を参照してください。
| 注意 : | [ユーザのロックアウト] オプションは、デフォルト セキュリティ レルムとそのすべてのセキュリティ プロバイダに適用されます。[ユーザのロックアウト] オプションは、デフォルト セキュリティ レルム以外のセキュリティ レルムにあるカスタム セキュリティ プロバイダでは機能しません。カスタム セキュリティ プロバイダで [ユーザのロックアウト] オプションを使用するには、デフォルト セキュリティ レルムでカスタム セキュリティ プロバイダをコンフィグレーションします。WebLogic 認証プロバイダや WebLogic ID アサーション プロバイダの後の認証プロセスにカスタム セキュリティ プロバイダを含めます。この順序付けによって、パフォーマンスが若干低下することがあります。 |
| 注意 : | ユーザ アカウントを保護する独自のメカニズムを備えた認証プロバイダを使用する場合は、[ロックアウトを有効化] オプションを無効化します。 |
| 注意 : | ユーザ アカウントがロックされたためそのユーザ アカウントを削除して、同じ名前とパスワードを持つ別のユーザ アカウントを追加しても、[ユーザのロックアウト] コンフィグレーション オプションはリセットされません。 |
管理サーバでのロックされたユーザ アカウントの解除については、Administration Console オンライン ヘルプの「ユーザ アカウントのロック解除」を参照してください。管理対象サーバ上のロックされたユーザ アカウントに対するロックの解除を、WebLogic Administration Console を介して行うことはできません。ロックの解除に関する情報はマルチキャスト メッセージを通じて伝播されますが、このマルチキャスト メッセージがコンフィグレーションされているのはクラスタ環境のみです。代わりに以下のコマンドを使用します。
java weblogic.Admin -urlurl-usernameadminuser
-passwordpasswordforadminuser-type weblogic.management.security.authentication.UserLockoutManager -method clearLockoutlockedusername
また、[ロックアウト期間] 属性に指定した時間だけ待機することもできます。この属性に指定された時間を過ぎるとユーザ アカウントのロックは解除されます。
  
|
