プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティの管理
12c (12.2.1.3.0)
E90347-06
目次へ移動
目次

前
次

4 WebLogicドメインのセキュリティの構成

Oracle WebLogic Server環境用のセキュリティの構成は、WebLogic Serverのセキュア・インストールの作成から始めます。これには、証明書の取得および格納、ユーザー・アカウントの保護、ドメインが実行されるネットワークの保護など、ドメインが実行される環境に適したセキュリティ構成オプションの選択も含まれます。

この章には次のトピックが含まれます:

本番環境で保護する必要があるWebLogic Serverのすべてのコンポーネントと、WebLogic Serverホスト、WebLogicセキュリティ・サービス、WebLogic Serverで使用されるファイルとデータベースを保護するために推奨される特定のタスクを含む完全なチェックリストは、『Oracle WebLogic Server本番環境の保護』の本番環境のセキュリティの確保を参照してください。

WebLogic Serverのセキュア・インストールの実行

セキュア・インストールの実行のステップでは、WebLogic Serverがインストールされているホスト・マシンの保護、そのホストへのアクセスを認可されたユーザーのみに制限すること、インストールの完了直後のクリティカル・パッチ・アップデートのインストールを行います。

WebLogic Serverを本番環境にインストールする場合、次の項で説明するガイドラインを強くお薦めします。

WebLogic Serverのインストール前

WebLogic Serverのインストール・プログラムを開始する前に、次のタスクを実行します。

  • My Oracle Supportアカウントを作成し、WebLogic Serverインストールをオラクル社に登録して、セキュリティの更新を自動的に受け取れるようにします。http://www.oracle.com/support/index.htmlにアクセスしてください。

  • 認可されたユーザーのみにアクセス権を制限して、ホスト・マシン、オペレーティング・システムおよびファイル・システムを保護します。たとえば:

    • 認可されていないオペレーティング・システム・ユーザーが、マシンおよびネットワーク接続を使用できないように、ハードウェアを安全な場所に設置します。

    • 最新のオペレーティング・システム・パッチとセキュリティ更新をホスト・マシンに必ず適用します。

      ノート:

      新しいパッチが入手できるようになったら、すぐにダウンロードしてインストールする必要があります。

  • オペレーティング・システムで提供されるネットワーク・サービスとファイル・システムを保護して、認可されないアクセスを防ぎます。たとえば、すべてのファイル・システム共有を保護するようにします。

  • オペレーティング・システムのファイル・アクセス権限を設定して、WebLogic Serverによって使用または管理されるディスクに格納されているデータ(セキュリティLDAPデータベースや、キーストアが作成されて管理されるディレクトリなど)へのアクセスを制限します。

  • ホスト・マシンのユーザー・アカウント数を制限します。グループを作成しして、次のユーザー・アカウントのみを含めます。

    1. WebLogic Serverをインストールするユーザーのみ

    2. WebLogicドメインを作成し、ノード・マネージャを使用して、管理サーバーと各管理対象サーバー・インスタンスをドメインで起動するユーザー

    これらのユーザー・アカウントの権限を次のディレクトリのみに制限します。

    • Oracleホーム — ホスト・コンピュータ上のすべてのOracle Fusion Middleware製品に対して作成されるルート・ディレクトリ

    • WebLogicホーム — WebLogic Serverインストールのルート・ディレクトリ

    • ドメイン・ホーム — WebLogicドメインのルート・ディレクトリ

    ノート:

    一部のプロセスは、デフォルトではUnixプラットフォームの/tmpのような一時ディレクトリへのアクセス権が必要です。ユーザー・アカウントの権限がOracleホーム、WebLogicホームおよびWebLogicドメイン・ディレクトリのみに制限される場合、ユーザーは自らがアクセス権を持つディレクトリを指すように環境変数(TEMPまたはTMPなど)を変更する必要があります。

  • ホスト・マシンのすべてのWebサーバーが、権限のないユーザーとしてのみ実行するようにします。決してrootとして実行してはなりません。CERT Coordination Center (http://www.cert.org/)の「Security Practices & Evaluations」の情報も参照してください。

  • ソフトウェア開発ツールまたはサンプル・ソフトウェアがインストールされていないことを確認します。

  • 評価の高い侵入検知システム(IDS)など、オペレーティング・システムを保護する追加ソフトウェアの使用を検討します。

『Oracle WebLogic Server本番環境の保護』のWebLogic Serverホストの保護に関する項を参照してください。

インストール・プログラムの実行中

インストール中には次に注意してください。

  • サンプル・アプリケーション・コンポーネントをインストールしないでください。

  • セキュリティ更新の指定インストーラ画面で、「セキュリティ・アップデートをMy Oracle Support経由で受け取る」を選択します。

『Oracle WebLogic Server本番環境の保護』のセキュリティ関連の公開資料の参照に関する項とセキュアな方法でのWebLogic Serverのインストールに関する項を参照してください。

インストールの完了直後

  • Derby DBMSデータベースを削除します。WebLogic Serverにバンドルされているこのデータベースは、サンプル・アプリケーションやサンプル・コードでデモンストレーション・データベースとして使用されます。Derby DBMSはWL_HOME/common/derbyディレクトリにあります。

  • 次のサイトの「重要なパッチ更新およびセキュリティ・アラート」ページにアクセスして、WebLogic Serverのセキュリティの注意事項を確認します。

    http://www.oracle.com/technetwork/topics/security/alerts-086861.html

  • 未使用の内部アプリケーションの無効化および管理ポートの有効化によって、内部アプリケーションへのアクセスを制限します。内部アプリケーションへのアクセスを制限する方法の詳細は、『Oracle WebLogic Server本番環境の保護』のセキュアな方法でのWebLogic Serverのインストールおよび構成に関する項を参照してください。

本番用のWebLogicドメインの作成

本番で使用するWebLogicドメインを作成するには、他のWebLogicドメインと相互運用するかどうかや、ドメインへのアクセス権を持つユーザーのアカウントを保護するのに最適かどうかなど、ドメインが実行される環境を検討します。

本番環境で使用するためにWebLogicドメインを構成する際に、構成ウィザードなどのツール、pack/unpackコマンド、WLSTまたはWebLogic Server管理コンソールを使用するときには、次のことを考慮します。

  • ドメインが本番モードまたは保護された本番モードのいずれかで実行されるように構成します。セキュリティおよびロギングに関するデフォルトの設定は、ドメイン・モードにより決定されます。

    本番モードでは、アプリケーションのデプロイおよび管理サーバーの起動にはユーザー名とパスワードが必要になるなど、セキュリティ構成が比較的厳しくなっています。完全なWebLogicドメインまたはリモート・マシン上の管理対象サーバー・ドメイン・ディレクトリで使用されるドメインのサブセットを、unpackコマンドを使用して作成している場合は、-server_start_mode=prodパラメータを使用して本番モードを構成します。

    保護された本番モードでは、認可とロールのマッピング・ポリシーが制限的であるほど本番環境がセキュアであり、ドメインのセキュアでない構成設定に関する警告がログに記録されます。保護された本番モードを有効にするには、ドメインが本番モードである必要があります。WebLogic Server管理コンソール、Fusion Middleware ControlまたはWLST (オフラインおよびオンライン)を使用して、保護された本番モードを有効にできます。これらのツールを使用して保護された本番モードを有効にする方法の詳細は、次の各トピックを参照してください。
    • 管理コンソールを使用した保護された本番モードおよび関連のセキュリティ設定の有効化の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプ本番ドメインの保護に関する項を参照してください。

    • ドメインの作成時にsetOption WLSTオフライン・コマンドを使用し、ServerStartMode引数をsecure設定して保護された本番モードでドメインを作成します。『WebLogic Server WLSTコマンド・リファレンス』のsetOptionに関する項を参照してください。

    • ドメイン環境を本番モードから保護された本番モードに変更する方法を学ぶには、『WebLogic Scripting Toolの理解』のWLSTオンラインを使用した既存のWebLogicドメインの更新に関する項を参照してください。

    • Fusion Middleware Controlを使用して保護された本番モードおよび関連のセキュリティ設定を有効にするには、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のドメイン・セキュリティの構成に関する項を参照してください。

    ノート:

    ドメインのモードは、開発から本番、本番から開発、本番から保護された本番モードに変更できます。しかし、保護された本番モードを有効にするには、ドメインが本番モードである必要があることに留意してください。

    セキュリティ要件が厳しい本番環境では、(開発モードのドメインを本番モードに変更するのではなく)ドメインの作成時に本番ドメイン・モードを設定することをお薦めします。ドメイン・モードの変更方法の詳細は、『Oracle WebLogic Serverドメイン構成の理解』の開発モードと本番モードに関する項を参照してください。
  • ドメインが他のWebLogicドメインと相互運用する場合、または将来にその予定がある場合は、注意してリソース名を選択します。多くのリソース名はドメインの作成時に確定されます。クロス・ドメイン・セキュリティ、トランザクションおよびメッセージングを使用するときは、リソース名に厳しい要件を適用する必要があります。

    『Oracle WebLogic Server JTAアプリケーションの開発』のトランザクション通信の要件に関する項を参照してください。

  • WLSTを使用してドメインを作成するとき、次のようなパスワードが必要なエンティティを構成するために、暗号化されていないパスワードをコマンドに入力しないでください。

    • ドメイン管理者

    • ノード・マネージャ・ユーザー

    • データベース・ユーザー

    • JKSキーストア(キーストアの作成時とWebLogic Serverでのキーストアの構成時)

    • ウォレット

    WLSTコマンドで暗号化されていないパスワードを指定するのはセキュリティ・リスクです。その他のユーザーがモニター画面から簡単に見ることができます。また、それらのコマンドの実行をログするプロセスのリストにそのパスワードが表示されます。したがって、コマンドにはパスワードを指定しないでください。コマンドが実行されるとき、ドメインの構成を完了するために必要なパスワードがあれば、WLSTによって自動的にプロンプトが表示されます。

ドメイン作成後の保護

WebLogicドメインの作成後には、適切なドメイン・モードの選択、内部アプリケーションへのアクセスの制限、パスワード検証プロバイダの構成など、整合性を確保するための主要なステップがいくつか残っています。作成後にドメインを保護する場合は、次のステップをお薦めします。
  1. ドメインに対して保護された本番モードを有効にして、本番環境を保護します。セキュア本番モードを有効にするには、ドメインは本番モードである必要があります。このモードでは、セキュアな値が本番モードのデフォルト値に優先し、デフォルトの認可ポリシーおよびセキュリティ・ポリシーがより限定的になります。WebLogic Serverではすべてのセキュリティ設定が検証され、セキュアでない設定の場合は警告がログに記録されるため、非常にセキュアな本番環境となります。ドメインのモードを保護された本番モードに変更する方法を学ぶには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプ本番ドメインの保護に関する項を参照してください。
  2. 構成設定またはシステム・プロパティのいずれかを使用して未使用の内部アプリケーションを無効にすることで、内部アプリケーションへのアクセスを制限します。ドメインに対して管理ポートを有効にし、管理ポートでの内部アプリケーションへの外部アクセスを防止するようファイアウォールを構成ます。保護された本番モードでは、デフォルトで管理ポートが有効になっています。内部アプリケーションを無効にする方法の詳細は、『Oracle WebLogic Server本番環境の保護』のセキュアな方法でのWebLogic Serverのインストールおよび構成に関する項を参照してください。
  3. パスワード検証プロバイダを構成して、パスワード作成ルールを管理および適用します。パスワード検証プロバイダは、いくつかのWebLogic認証プロバイダで作動するように構成されています。
  4. セキュリティ・レルムにユーザーを作成または追加するときに、ユーザー・アカウントで「ユーザーのロックアウト」オプションの保護が最大に設定されていることを確認します。「ユーザーのロックアウト」の構成はレルム単位で定義されることに注意してください。したがって、デフォルトの「ユーザーのロックアウト」設定がニーズに合わない場合、新しいセキュリティ・レルムを作成するたびに設定のカスタマイズが必要になることがあります。「ユーザー・アカウントの保護」および「WebLogic Serverでのパスワードの保護の仕組み」を参照してください。

    ドメインが保護された本番モードで実行されている場合、WebLogic Serverでは、ユーザー・ロックアウトがデフォルト値より小さい値に構成されていると、警告がログに記録されます。

  5. 管理サーバーと、複数のマシンに分散する管理対象サーバー・インスタンスの開始、停止および再起動を行うようにノード・マネージャを構成した場合、ノード・マネージャのセキュリティを適切に構成してください。

    Javaノード・マネージャ(本番環境で推奨)を使用している場合は、『Oracle WebLogic Serverノード・マネージャの管理』のJavaベースのノード・マネージャ・セキュリティの構成に関する項を参照してください。

    セキュリティ要件がそれほど厳しくない環境に適した、スクリプト・ノード・マネージャを使用している場合は、『Oracle WebLogic Serverノード・マネージャの管理』のステップ2のノード・マネージャ・セキュリティの構成に関する項を参照してください。

  6. 監査を有効にします。こうすると、システムで発生するイベントやその他のアクティビティに関する情報を自動的に収集して格納できます。監査には次のいずれかの方法があります。
    • 構成監査 — 有効になっている場合、構成管理サーバーが、ユーザーがドメイン内のリソースの構成を変更したときやドメイン内のリソースの管理操作を呼び出したときに、ログ・メッセージの送信と監査イベントの生成を行います。

    • WebLogic監査プロバイダ — リクエストの操作とそれらのリクエストの結果に関する情報を、否認防止を目的として収集、格納、および配布するオプションのセキュリティ・プロバイダ。構成監査が有効になっているとき、WebLogic監査プロバイダも構成監査イベントをロギングします。

    監査によってパフォーマンス・オーバーヘッドが発生する可能性があるため、その考慮も必要です。ただし、監査の構成を調整すると、このようなオーバーヘッドを最小限に抑えることができます。監査を有効にするときは、監査ログに使用できる十分なディスク領域があることを確認します。「WebLogic監査プロバイダの構成」を参照してください。

    ノート:

    保護された本番モードがドメインに対して有効になっている場合、WebLogic Serverでは、監査プロバイダが構成されていないと、警告がログに記録されます。SecureModeMBeanのWarnOnAuditing属性を使用して、監査が有効になっていな場合に警告をログに記録するかどうかを指定できます。
  7. JVMプラットフォームMBeanサーバーにリモートからアクセスできないようにしてください。「JMXテクノロジを使用するモニタリングと管理」(http://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html)を参照してください。
  8. Federal Information Processing Standards (FIPS) 140-2に準拠する要件がある場合は、FIPSモードの有効化に説明されている該当の手順を実行します。
  9. 完了メッセージ・タイムアウトの構成設定がシステムに適していることを確認します。『Oracle WebLogic Serverサーバー環境の管理』の「ネットワーク・リソースの構成」を参照してください。
  10. IDと信頼を保持するために使用されるキーストアを作成して構成します。つまり、ID証明書を含むキーストアと信頼性のある認証局(CA)証明書を含むキーストアです。キーストアの構成を参照してください。

    WebLogic Serverに対してOracle OPSSキーストア・サービス(KSS)を使用している場合、Oracle OPSSキーストア・サービスの構成を参照してください。

    次の項目を確認するように、証明書の検証と失効チェックを構成します。

    • 証明書チェーンの各証明書が認証局によって発行されていること。SSL証明書の検証を参照してください。

    • WebLogic Serverが検証する各証明書の失効ステータスが最新であること。X.509証明書失効チェックを参照してください。

  11. ホスト名検証を構成します。SSL接続を行うとき、ホスト名検証が、クライアントの接続先URLのホスト名と、サーバーが返送するデジタル証明書のホスト名が一致していることを確認します。ホスト名検証の使用方法を参照してください。
    ドメインが保護された本番モードで実行されている場合、WebLogic Serverでは、ホスト名検証が無効になっていると、警告がログに記録されます。ホスト名検証を有効にするには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプカスタム・ホスト名検証の構成に関する項を参照してください。
  12. 管理ポート、ネットワーク・チャネル、データベース接続、LDAPサーバー接続、保護する必要がある通信を処理するその他のリソースについて、SSLを構成します。特に、ドメインのリモート・サーバー・インスタンスへの接続は必ずSSLで保護してください。どのコンポーネントで一方向または双方向SSLを構成する必要があるかは、本番環境の全体的なトポロジーによって異なります。次の項を参照してください。

    表4-1 SSL構成に関するトピック

    項目 参照先

    基本のWebLogicドメインで通信を保護するためのSSL使用方法の概要

    『Oracle WebLogic Serverセキュリティの理解』のSecure Sockets Layer (SSL)に関する項

    基本のWebLogicドメインで一方向SSLを使用する状況と双方向SSLを使用する状況

    『Oracle WebLogic Serverセキュリティの理解』の一方向/双方向SSL認証に関する項

    基本のWebLogicドメインでSSLを構成するステップ

    SSLの設定: 主なステップ

    ドメイン管理サーバーとのセキュアな通信のための管理ポートの構成

    『Oracle WebLogic Serverサーバー環境の管理』の管理ポートと管理チャネルに関する項

    データベース通信の保護

    『Oracle WebLogic Server JDBCデータ・ソースの管理』のデータ・ソース・セキュリティの理解に関する項

    Web層、中間層およびデータ層でコンポーネントを保護するためのOracle Fusion MiddlewareでのSSLの使用方法の概要

    『Oracle Fusion Middlewareの管理』のOracle Fusion MiddlewareでのSSLに関する項

    WebLogic ServerでのSSL構成のベスト・プラクティス

    「セクション2. セキュリティのベスト・プラクティス」、ドキュメントID 1074055.1、My Oracle Support (https://support.oracle.com/)

    ノート:

    次の点に注意してください。

    • デフォルトでは、WebLogic Serverは一方向のSSL認証用に構成されますが、SSLポートは無効化されています。本番ドメインのすべてのサーバー・インスタンスでSSLポートを有効にするように強くお薦めします。

    • WebLogic Serverで提供される、デモ用のデジタル証明書、秘密キーおよび信頼性のあるCA証明書は、決して本番環境では使用しないでください。

    • 保護された本番モードでは、SSL構成がセキュアでないと、WebLogic Serverで警告がログに記録されます。SecureModeMBeanに含まれるWarnOnInsecureSSL属性を使用して、SSL構成がセキュアでない場合に警告をログに記録するかどうかを指定できます。

  13. サービス拒否攻撃を防ぐために、外部チャネルに対してリクエストのサイズおよび時間を制限します。『Oracle WebLogic Serverのパフォーマンスのチューニング』のサービス妨害攻撃の可能性の低減に関する項を参照してください。
  14. 複数の認証プロバイダを使用する場合は、JAAS制御フラグを適切に設定します。「複数の認証プロバイダの使用」を参照してください。
  15. デフォルトのWebLogic Serverセキュリティ・ロールにユーザーおよびグループを正しく割り当てたことを確認します。『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループ、セキュリティ・ロール」を参照してください。

秘密キー、デジタル証明書、信頼性のある認証局からの証明書の取得

WebLogic Server環境用の秘密キー、デジタル証明書、信頼性のあるCA証明書を取得するための選択肢は複数あります。秘密キーおよびデジタル証明書を信頼できる認証局から取得することをお薦めします。これらの項目を選択する際には、次の考慮事項に注意してください。
  • 本番環境の場合、EntrustやSymantec Corporationなどの信頼できる認証局からのみ秘密キーやデジタル証明書を取得することを強くお薦めします。「本番環境のための証明書の取得と格納」を参照してください。

  • WebLogic Serverで提供されるデジタル証明書、秘密キー、信頼性のあるCA証明書を使用できるのは開発環境のみです。keytoolまたはCertGenユーティリティを使用して、自己署名証明書を生成することもできます。「開発環境でのキーストアと証明書の使用」を参照してください。

秘密キー、デジタル証明書、信頼性のある認証局からの証明書の格納

秘密キー、デジタル証明書、および信頼できるCA証明書を取得した後は、それらを格納し、WebLogic Serverでそれらを使用してIDを検索および確認できるようにする必要があります。秘密キー、秘密キーに関連付けられたデジタル証明書、および信頼できるCA証明書は、キーストアに格納されます。 続いて、WebLogic Serverで当該キーストアを構成する必要があります。

項目 参照先

キーストアの作成

「キーストアの作成」

WebLogic Serverで使用されるキーストアの構成

「WebLogic Serverでのキーストアの構成」

キーストアを作成してキーと証明書をその中に保存するためのkeytoolユーティリティの使用ステップの例

キーストアの作成: サンプル

キーストアに含まれる証明書の表示

「キーストアの内容の表示」

まもなく期限切れになる証明書の更新

「期限切れになる証明書の置換」

ユーザー・アカウントの保護

WebLogic Serverには、ユーザー・アカウントを侵入者から保護するための一連の構成オプションが用意されています。デフォルト・セキュリティ構成では、これらのオプションは最高の保護レベルに設定されています。 WebLogic Server管理コンソールで、「構成」「ユーザーのロックアウト」ページ(セキュリティ・レルムごとにある)を使用してこれらのオプションを変更できます。

システム管理者は、すべての構成オプションを無効にしたり、ユーザー・アカウントがロックされるまでのログイン試行回数を増やしたり、ユーザー・アカウントがロックされるまでの無効なログイン試行期間を延ばしたり、ユーザー・アカウントのロック時間を変更したりできます。これらの構成オプションを変更すると、セキュリティ・レベルが低下して攻撃を受けやすくなることに注意してください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプユーザー・ロックアウト属性の設定に関する項を参照してください。

ノート:

「ユーザーのロックアウト」オプションは、デフォルト・セキュリティ・レルムとそのすべてのセキュリティ・プロバイダに適用されます。「ユーザーのロックアウト」は、すべてのセキュリティ・レルムで作動します。構成されているすべてのプロバイダ(カスタム・プロバイダも含む)に対応し、デフォルトで有効になっています。

独自のメカニズムでユーザー・アカウントを保護する認証プロバイダを使用する場合、セキュリティ・レルムでの「ユーザーのロックアウト」を無効にしても問題ないかどうかを検討してください。他の認証プロバイダがセキュリティ・レルムで構成される可能性があるためです。

ユーザー・アカウントがロックされたためそのユーザー・アカウントを削除して、同じ名前とパスワードを持つ別のユーザー・アカウントを追加しても、「ユーザーのロック・アウト」構成オプションはリセットされません。

ロックされたユーザー・アカウントの解除については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプユーザー・アカウントのロック解除に関する項を参照してください。ロックされたユーザー・アカウントに対するロックの解除は、WebLogic Server管理コンソールや、UserLockoutManagerRuntimeMBeanclearLockout属性を介して行うことができます。

接続フィルタの使用

接続フィルタを使用すると、ネットワーク・レベルでアクセスを拒否できます。接続フィルタは、個々のサーバー、サーバー・クラスタ、または内部ネットワーク(イントラネット)にあるサーバー・リソースの保護に使用できます。 たとえば、ユーザーの企業のネットワーク外部からの非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレス、およびDNSノード名に基づいてフィルタ処理するよう構成できる点において一種のファイアウォールです。

接続フィルタは、管理ポートを使用する場合に特に便利です。ネットワーク・ファイアウォール構成によっては、接続フィルタを使用して管理アクセスをさらに制限できる場合もあります。一般的には、管理ポートへのアクセスをWebLogicドメイン内のサーバーやマシンのみに制限するために使用されることが考えられます。攻撃者がファイアウォールの内側にあるマシンにアクセスできても、それが許可されたマシンでない限り、管理操作を実行することはできません。

WebLogic Serverでは、weblogic.security.net.ConnectionFilterImplというデフォルトの接続フィルタが用意されています。この接続フィルタは、すべての着信接続を受け入れます。また、サーバーは、このクラスが提供する静的ファクトリ・メソッドを使うことで、現在の接続フィルタを取得できます。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic Server管理コンソールで接続フィルタ・ルールを入力してください。

また、weblogic.security.netパッケージのクラスを実装することで、カスタム接続フィルタを使用することもできます。接続フィルタの作成の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のネットワーク接続フィルタの使用に関する項を参照してください。デフォルト接続フィルタと同じように、カスタム接続フィルタもWebLogic Server管理コンソールで構成できます。

接続フィルタを構成するには:

  1. 受信メッセージのロギングを有効にします。「接続ログを有効化」オプションを使用すると、成功した接続と接続データがサーバーの接続ログに記録されます。この情報は、サーバーの接続に関連する問題をデバッグするために使用できます。
  2. ドメインで使用する接続フィルタを選択します。
    • デフォルト接続フィルタを構成するには、「接続フィルタ」にweblogic.security.net.ConnectionFilterImplを指定します。

    • カスタム接続フィルタを構成するには、ネットワーク接続フィルタを実装するクラスを「接続フィルタ」フィールドで指定します。このクラス名は、WebLogic ServerのCLASSPATHにも指定する必要があります。

  3. 接続フィルタのルールの構文を入力します。

次のトピックを参照してください。

  • Oracle WebLogic Server管理コンソール・オンライン・ヘルプ接続フィルタの構成に関する項を参照してください。

  • 接続フィルタのルール、およびカスタム接続フィルタの作成については、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のネットワーク接続フィルタの使用に関する項およびカスタム接続フィルタの開発に関する項を参照してください。

  • WebLogic Scripting ToolまたはJava Management Extensions (JMX) APIを使用して新しいセキュリティ構成を作成することもできます。

カスタムJEP 290デシリアライゼーション・フィルタの構成

セキュリティを高めるために、WebLogic Serverは、JDK JEP 290メカニズムを使用して受信したシリアライズJavaオブジェクトをフィルタして、デシリアライズできるクラスを制限します。フィルタにより、サービス拒否(DOS)攻撃やリモート・コード実行(RCE)攻撃を引き起こす可能性のある、特別に作成された悪意のあるシリアライズ・オブジェクトによる攻撃から保護できます。

WebLogic Serverでは、次のようにJEP 290を使用します。

  • WebLogic Server固有のオブジェクト入力フィルタを実装して、WebLogic Serverによって使用される入力ストリームに対して禁止されたクラスおよびパッケージのブロックリストを適用します。フィルタでは、デシリアライズ・オブジェクト・ツリーの最大の深さのデフォルト値も適用されます。

  • デフォルト・フィルタのクラスとパッケージをブロックまたは許可リストの特定のクラスに追加または削除するために使用できるシステム・プロパティを提供します。システム・プロパティを使用して、デシリアライズ・オブジェクトのネストの深さ、デシリアライズ・オブジェクト内の内部参照の数、配列のサイズ、デシリアライズ・オブジェクトの最大サイズ(バイト単位)に基づいてデシリアライズ・クラスをフィルタすることもできます。

JEP 290の詳細は、http://openjdk.java.net/jeps/290を参照してください。

このリリースのJEP 290サポートに必要な最小のJDKレベルについては、『Oracle WebLogic Server本番環境の保護』のネットワーク接続の保護に関する項を参照してください。

WebLogic Server JEP 290デフォルト・フィルタのカスタマイズ

WebLogic Serverには、必要に応じてJEP 290デフォルト・フィルタをカスタマイズ、置換または無効にするために使用できるシステム・プロパティが含まれます。

次の表は、システム・プロパティについて説明しており、使用例が含まれています。

表4-2 WebLogic Server JEP 290のシステム・プロパティ

プロパティ 説明

weblogic.oif.serialFilter

このプロパティは、JEP 290の標準フィルタ構文を使用してWebLogic ServerのカスタムJEP 290フィルタを設定する場合に使用します。JEP 290のフィルタ構文については、http://openjdk.java.net/jeps/290のプロセス全体のフィルタに関する項を参照してください。

デフォルトでは、このカスタム・フィルタはデフォルトのWebLogic Serverフィルタと結合され、いずれかのフィルタ要素が競合した場合にはカスタム・フィルタがデフォルト・フィルタより優先されます。

たとえば、foo.bar.Mumbleという名前のクラスをデフォルトのブロックリストに追加することでカスタム・フィルタを設定するには、次の設定を使用します:

-Dweblogic.oif.serialFilter=”!foo.bar.Mumble”

この設定により、デフォルト・フィルタで許可されている場合でもクラスfoo.bar.Mumbleイベントがブロックされます。

weblogic.oif.serialFilterMode

このプロパティは、デフォルトのWebLogic Serverフィルタを結合、置換または無効化する機能を提供する、カスタム・フィルタのフィルタ・モードを指定する場合に使用します。有効な値は次のとおりです。

  • combine — カスタム・フィルタをデフォルトのWebLogic Serverフィルタと結合します。カスタム・フィルタ設定は、競合するフィルタ要素のデフォルト・フィルタ設定より優先されます。これがデフォルトです。

  • replace — デフォルトのWebLogic Serverフィルタをカスタム・フィルタに置き換えます。

  • disable — デフォルトのWebLogic Serverフィルタを無効化します。

たとえば、デフォルトのWebLogic Serverフィルタをカスタム・フィルタに置き換えるには、次の設定を使用します。

-Dweblogic.oif.serialFilterMode=replace

weblogic.oif.serialFilterScope

このプロパティは、(Java SE jdk.serialFilterプロパティを使用して構成されたかのように)フィルタをJVM全体にグローバルに適用するか、内部WebLogic Serverのデシリアライゼーションにのみ適用するかを指定する場合に使用します。有効値はglobalおよびweblogicです。このリリースのJEP 290サポートに必要な最小のJDKレベルを使用している場合は、デフォルトはglobalです。それ以外の場合は、デフォルトはweblogicです。

たとえば、JVM全体ではなく、内部WebLogic ServerのデシリアライゼーションにのみWebLogic Serverのデフォルトまたはカスタム・フィルタを適用するには、次の設定を使用します。

-Dweblogic.oif.serialFilterScope=weblogic