WebLogic Server のセキュリティ
|
 |
 |
|
以下の節では、WebLogic ドメインのセキュリティ コンフィグレーション オプションの設定方法について説明します。
注意 : この章は、このリリースの WebLogic Server のセキュリティ機能を使用する WebLogic Server デプロイメントと互換性セキュリティを使用するデプロイメントに適用されます。
注意 : サーバに専用回線などのセキュアな通信手段がなく、サーバがファイアウォールで保護されていない場合は、プロダクション環境で WebLogic Server ドメイン間の信頼関係を有効化することはお勧めしません。
ドメイン間の信頼関係が確立されると、一方の WebLogic Server ドメインのサブジェクト内のプリンシパルがもう一方のドメインのプリンシパルとして受け付けられます。この機能が有効になると、ID は WebLogic Server ドメイン間で RMI 接続で渡されます (2 番目のドメインでの認証は不要)。たとえば、Joe としてドメイン 1 にログインして、ドメイン 2 に対して RMI 呼び出しを行うと、Joe は引き続き認証されます。ドメイン間の信頼関係が有効である場合、トランザクションは複数のドメインにまたがってコミットできます。一方のドメインの資格がもう一方のドメインの資格と一致したときに信頼関係が確立されます。
ドメインの資格は、WebLogic Server ドメインの最初の起動時にランダムに作成されます。このプロセスにより、デフォルトで 2 つの WebLogic Server ドメインが同じ資格を持たないようになります。2 つの WebLogic Server ドメイン間の信頼を有効にするには、両方の WebLogic Server ドメインで資格に同じ値を明示的に指定する必要があります。ドメインの資格を設定するには、[ドメイン] ノードの [セキュリティ｜詳細] ページのコンフィグレーション オプションを使用します。
デフォルトでは、管理サーバを最初に起動するときにはドメイン資格は定義されません。管理サーバは、起動時にドメイン資格が定義されていないことを認識し、ランダム資格を生成します。2 つの WebLogic Server ドメイン間の信頼を有効にするには、ドメインごとに、次の手順に従ってランダム資格の生成を回避します。
WebLogic Server は、プリンシパルの作成時にドメイン資格でプリンシパルに署名します。サブジェクトがリモート ソースから受信されると、そのプリンシパルが検証されます (シグネチャが再作成され、それが一致するとリモート ドメインは同じドメインの資格を持ちます)。検証が失敗すると、エラーが生成されます。検証が成功すると、そのプリンシパルはローカルで作成されたかのように信頼されます。
注意 : クリア テキスト形式の資格は、次に config.xml ファイルがディスクに保存されるときに暗号化されます。
WebLogic Server 6.x ドメインと WebLogic Server ドメインを相互運用する場合、WebLogic Server ドメインの資格を、WebLogic Server 6.x ドメインの system ユーザのパスワードに変更します。
管理対象サーバ環境で信頼を有効にする場合は、両方のドメインの管理サーバとすべての管理対象サーバを停止してから、それらを再起動する必要があります。この手順を行わないと、再起動されなかったサーバでは、再起動されたサーバが信頼されなくなります。
WebLogic Server ドメイン間の信頼関係を有効化するときには、次の点に注意してください。
詳細については、Administration Console オンライン ヘルプの「ドメイン間の信頼の有効化」を参照してください。
注意 : WebLogic Scripting Tool または Java Management Extensions (JMX) API を使用してセキュリティ コンフィグレーションを変更することもできます。
接続フィルタを使用すると、ネットワーク レベルでアクセスを拒否できます。接続フィルタは、個々のサーバ、サーバ クラスタ、または内部ネットワーク (イントラネット) にあるサーバ リソースの保護に使用できます。たとえば、ユーザの企業のネットワーク外部からの非 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 ドメインを再コンフィグレーションしなければなりません。そのため、以下の注意事項を考慮する必要があります。
SerializedSystemIni.dat ファイルのバックアップを作成し、安全な場所に保管します。SerializedSystemIni.dat ファイルにパーミッションを設定します。
WebLogic Server には、ユーザ アカウントを侵入者から保護するためのコンフィグレーション オプションが定義されています。デフォルト セキュリティ コンフィグレーションでは、これらのオプションは最高の保護レベルに設定されています。これらのオプションを変更するには、Administration Console の [コンフィグレーション｜ユーザのロックアウト] ページを使用します。
システム管理者は、すべてのコンフィグレーション オプションを無効にしたり、ユーザ アカウントがロックされるまでのログイン試行回数を増やしたり、ユーザ アカウントがロックされるまでの無効なログイン試行期間を延ばしたり、ユーザ アカウントのロック時間を変更したりできます。これらのコンフィグレーション オプションを変更すると、セキュリティ レベルが低下して攻撃を受けやすくなることに注意してください。Administration Console オンライン ヘルプの「ユーザ ロックアウト属性の設定」を参照してください。
注意 : [ユーザのロックアウト] オプションは、デフォルト セキュリティ レルムとそのすべてのセキュリティ プロバイダに適用されます。[ユーザのロックアウト] オプションは、デフォルト セキュリティ レルム以外のセキュリティ レルムにあるカスタム セキュリティ プロバイダでは機能しません。カスタム セキュリティ プロバイダで [ユーザのロックアウト] オプションを使用するには、デフォルト セキュリティ レルムでカスタム セキュリティ プロバイダをコンフィグレーションします。WebLogic 認証プロバイダや WebLogic ID アサーション プロバイダの後の認証プロセスにカスタム セキュリティ プロバイダを含めます。この順序付けによって、パフォーマンスが若干低下することがあります。
ユーザ アカウントを保護する独自のメカニズムを備えた認証プロバイダを使用する場合は、[ロックアウトを有効化] オプションを無効化します。
ユーザ アカウントがロックされたためそのユーザ アカウントを削除して、同じ名前とパスワードを持つ別のユーザ アカウントを追加しても、[ユーザのロックアウト] オプションはリセットされません。
ロックされたユーザ アカウントの解除については、Administration Console オンライン ヘルプの「ユーザ アカウントのロック解除」を参照してください。管理対象サーバ上のロックされたユーザ アカウントに対するロックの解除を、WebLogic Administration Console を介して行うことはできません。ロックの解除に関する情報はマルチキャスト メッセージを通じて伝播されますが、このマルチキャスト メッセージがコンフィグレーションされているのはクラスタ環境のみです。代わりに以下のコマンドを使用します。
java weblogic.Admin -urlurl-usernameadminuser
-passwordpasswordforadminuser-type weblogic.mangement.security.authentication.UserLockoutManager -method clearLockoutlockedusername
また、[ロックアウト期間] 属性に指定した時間だけ待機することもできます。この属性に指定された時間を過ぎるとユーザ アカウントのロックは解除されます。
|
|
|