3 WebLogicドメインのセキュリティの構成
Oracle WebLogic Server環境用のセキュリティの構成は、WebLogic Serverのセキュア・インストールの作成から始めます。これには、証明書の取得および格納、ユーザー・アカウントの保護、ドメインが実行されるネットワークの保護など、ドメインが実行される環境に適したセキュリティ構成オプションの選択も含まれます。
この章の内容は次のとおりです。
本番環境で保護する必要があるWebLogic Serverのすべてのコンポーネントと、セキュアなドメインの構成やWebLogic Serverで使用されるネットワーク、ファイルおよびデータベースの保護のために推奨される特定のタスクを含む完全なチェックリストは、『Oracle WebLogic Server本番環境の保護』の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データベースや、キーストアが作成されて管理されるディレクトリなど)へのアクセスを制限します。
-
ホスト・マシンのユーザー・アカウント数を制限します。グループを作成しして、次のユーザー・アカウントのみを含めます。
-
WebLogic Serverをインストールするユーザーのみ
-
WebLogicドメインを作成し、ノード・マネージャを使用して、管理サーバーと各管理対象サーバー・インスタンスをドメインで起動するユーザー
これらのユーザー・アカウントの権限を次のディレクトリのみに制限します。
-
Oracleホーム — ホスト・コンピュータ上のすべてのOracle Fusion Middleware製品に対して作成されるルート・ディレクトリ
-
WebLogicホーム — WebLogic Serverインストールのルート・ディレクトリ
-
ドメイン・ホーム — WebLogicドメインのルート・ディレクトリ
ノート:
一部のプロセスは、デフォルトではUnixプラットフォームの
/tmpのような一時ディレクトリへのアクセス権が必要です。ユーザー・アカウントの権限がOracleホーム、WebLogicホームおよびWebLogicドメイン・ディレクトリのみに制限される場合、ユーザーは自らがアクセス権を持つディレクトリを指すように環境変数(TEMPまたはTMPなど)を変更する必要があります。 -
-
ホスト・マシンのすべてのWebサーバーが、権限のないユーザーとしてのみ実行するようにします。決して
rootとして実行してはなりません。 -
ソフトウェア開発ツールまたはサンプル・ソフトウェアがインストールされていないことを確認します。
-
評価の高い侵入検知システム(IDS)など、オペレーティング・システムを保護する追加ソフトウェアの使用を検討します。
『Oracle WebLogic Server本番環境の保護』のホスト環境の保護を参照してください。
インストールの完了直後
-
Derby DBMSデータベースを削除します。WebLogic Serverにバンドルされているこのデータベースは、サンプル・アプリケーションやサンプル・コードでデモンストレーション・データベースとして使用されます。Derby DBMSは
WL_HOME/common/derbyディレクトリにあります。 -
次のサイトのクリティカル・パッチ・アップデート、セキュリティ・アラートおよび掲示板のページにアクセスして、WebLogic Serverのセキュリティの注意事項を確認してください:
『Oracle 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管理コンソール・オンライン・ヘルプの本番ドメインの保護に関する項を参照してください。
-
ドメインの作成時に
setOptionWLSTオフライン・コマンドを使用し、ServerStartMode引数をsecure設定して保護された本番モードでドメインを作成します。『WebLogic Server WLSTコマンド・リファレンス』のsetOptionに関する項を参照してください。 -
ドメイン環境を本番モードから保護された本番モードに変更する方法を学ぶには、『WebLogic Scripting Toolの理解』のWLSTオンラインを使用した既存のWebLogicドメインの更新に関する項を参照してください。
ノート:
ドメインのモードは、開発から本番、本番から開発、本番から保護された本番モードに変更できます。しかし、保護された本番モードを有効にするには、ドメインが本番モードである必要があることに留意してください。 セキュリティ要件が厳しい本番環境では、(開発モードのドメインを本番モードに変更するのではなく)ドメインの作成時に本番ドメイン・モードを設定することをお薦めします。ドメイン・モードの変更方法の詳細は、『Oracle WebLogic Serverドメイン構成の理解』の開発モードと本番モードに関する項を参照してください。 -
-
ドメインが他のWebLogicドメインと相互運用する場合、または将来にその予定がある場合は、注意してリソース名を選択します。多くのリソース名はドメインの作成時に確定されます。クロス・ドメイン・セキュリティ、トランザクションおよびメッセージングを使用するときは、リソース名に厳しい要件を適用する必要があります。
『Oracle WebLogic Server JTAアプリケーションの開発』のトランザクション通信の要件に関する項を参照してください。
-
WLSTを使用してドメインを作成するとき、次のようなパスワードが必要なエンティティを構成するために、暗号化されていないパスワードをコマンドに入力しないでください。
-
ドメイン管理者
-
ノード・マネージャ・ユーザー
-
データベース・ユーザー
-
JKSおよびPKCS12キーストア(キーストアの作成時とWebLogic Serverでのキーストアの構成時)
-
ウォレット
WLSTコマンドで暗号化されていないパスワードを指定するのはセキュリティ・リスクです。その他のユーザーがモニター画面から簡単に見ることができます。また、それらのコマンドの実行をログするプロセスのリストにそのパスワードが表示されます。したがって、コマンドにはパスワードを指定しないでください。コマンドが実行されるとき、ドメインの構成を完了するために必要なパスワードがあれば、WLSTによって自動的にプロンプトが表示されます。
-
ドメイン作成後の保護
秘密キー、デジタル証明書、信頼性のある認証局からの証明書の取得
-
本番環境の場合、EntrustやSymantec Corporationなどの信頼できる認証局からのみ秘密キーやデジタル証明書を取得することを強くお薦めします。「本番環境のための証明書の取得と格納」を参照してください。
-
WebLogic Serverで提供されるデジタル証明書、秘密キー、信頼性のあるCA証明書を使用できるのは開発環境のみです。keytoolまたはCertGenユーティリティを使用して、自己署名証明書を生成することもできます。「開発環境でのキーストアと証明書の使用」を参照してください。
秘密キー、デジタル証明書、信頼性のある認証局からの証明書の格納
| 項目 | 次のトピックを参照してください |
|---|---|
|
キーストアの作成 |
|
|
WebLogic Serverで使用されるキーストアの構成 |
|
|
キーストアを作成してキーと証明書をその中に保存するためのkeytoolユーティリティの使用ステップの例 |
|
|
キーストアに含まれる証明書の表示 |
|
|
まもなく期限切れになる証明書の更新 |
|
| 証明書の有効期限に関するリマインダの設定 |
ユーザー・アカウントの保護
システム管理者は、すべての構成オプションを無効にしたり、ユーザー・アカウントがロックされるまでのログイン試行回数を増やしたり、ユーザー・アカウントがロックされるまでの無効なログイン試行期間を延ばしたり、ユーザー・アカウントのロック時間を変更したりできます。これらの構成オプションを変更すると、セキュリティ・レベルが低下して攻撃を受けやすくなることに注意してください。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー・ロックアウト属性の設定に関する項を参照してください。
ノート:
「ユーザーのロックアウト」オプションは、デフォルト・セキュリティ・レルムとそのすべてのセキュリティ・プロバイダに適用されます。「ユーザーのロックアウト」は、すべてのセキュリティ・レルムで作動します。構成されているすべてのプロバイダ(カスタム・プロバイダも含む)に対応し、デフォルトで有効になっています。
独自のメカニズムでユーザー・アカウントを保護する認証プロバイダを使用する場合、セキュリティ・レルムでの「ユーザーのロックアウト」を無効にしても問題ないかどうかを検討してください。他の認証プロバイダがセキュリティ・レルムで構成される可能性があるためです。
ユーザー・アカウントがロックされたためそのユーザー・アカウントを削除して、同じ名前とパスワードを持つ別のユーザー・アカウントを追加しても、「ユーザーのロック・アウト」構成オプションはリセットされません。
ロックされたユーザー・アカウントの解除については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー・アカウントのロック解除に関する項を参照してください。ロックされたユーザー・アカウントに対するロックの解除は、WebLogic Server管理コンソールや、UserLockoutManagerRuntimeMBeanのclearLockout属性を介して行うことができます。
接続フィルタの使用
接続フィルタは、管理ポートを使用する場合に特に便利です。ネットワーク・ファイアウォール構成によっては、接続フィルタを使用して管理アクセスをさらに制限できる場合もあります。一般的には、管理ポートへのアクセスをWebLogicドメイン内のサーバーやマシンのみに制限するために使用されることが考えられます。攻撃者がファイアウォールの内側にあるマシンにアクセスできても、それが許可されたマシンでない限り、管理操作を実行することはできません。
WebLogic Serverでは、weblogic.security.net.ConnectionFilterImplというデフォルトの接続フィルタが用意されています。この接続フィルタは、すべての着信接続を受け入れます。また、サーバーは、このクラスが提供する静的ファクトリ・メソッドを使うことで、現在の接続フィルタを取得できます。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic Server管理コンソールで接続フィルタ・ルールを入力してください。
また、weblogic.security.netパッケージのクラスを実装することで、カスタム接続フィルタを使用することもできます。接続フィルタの作成の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のネットワーク接続フィルタの使用に関する項を参照してください。デフォルト接続フィルタと同じように、カスタム接続フィルタもWebLogic Server管理コンソールで構成できます。
接続フィルタを構成するには:
次のトピックを参照してください。
-
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続フィルタの構成に関する項を参照してください。
-
接続フィルタのルール、およびカスタム接続フィルタの作成については、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のネットワーク接続フィルタの使用に関する項およびカスタム接続フィルタの開発に関する項を参照してください。
-
WebLogic Scripting ToolまたはJava Management Extensions (JMX) APIを使用して新しいセキュリティ構成を作成することもできます。
Oracle WebLogic ServerでのJEP 290の使用
セキュリティを高めるために、WebLogic Serverは、JDK JEP 290メカニズムを使用して受信したシリアライズJavaオブジェクトをフィルタして、デシリアライズできるクラスを制限します。フィルタにより、サービス拒否(DOS)攻撃やリモート・コード実行(RCE)攻撃を引き起こす可能性のある、特別に作成された悪意のあるシリアライズ・オブジェクトによる攻撃から保護できます。
デシリアライズ攻撃を防ぐには、ブロックリストと許可リストという2つのモデルがあります。ブロックリスト・モデルでは、WebLogic Serverは、脆弱な既知のクラスおよびパッケージのセットを定義し、それらをデシリアライズからブロックし、他のすべてのクラスはデシリアライズできるようにします。許可リスト・モデルでは、WebLogic Serverおよび顧客は、デシリアライズを許可されている受入れ可能なクラスおよびパッケージのリストを定義し、他のすべてのクラスをブロックします。どちらのアプローチも利点がありますが、許可リスト・モデルは、WebLogic Serverおよび顧客アプリケーションで必要とされることがわかっているクラスおよびパッケージのデシリアライズのみを許可するため、よりセキュアです。
ノート:
2021年7月のパッチ・セット更新(PSU)では、WebLogic Serverの許可リストのサポートが追加されます。ブロックリストと許可リストのどちらを使用するかを選択できます。
-
WebLogic Serverではデフォルトでブロックリストが使用されます。起動時にWebLogic Serverにより、グラフの最大深度と、デシリアライズできない禁止されたクラスおよびパッケージのセットを指定する、デフォルトのJEP 290ブロックリスト・フィルタが構成されます。その後、WebLogic Server JEP 290のプロパティを使用してブロックリストをカスタマイズし、クラスまたはパッケージをさらに追加できます。また、動的ブロックリストを使用すると、サーバーの実行中に更新または置換できる構成ファイルを作成することで、ブロックリスト・フィルタを更新できます。「動的ブロックリスト構成ファイルの使用」を参照してください。
ノート:
これらのデフォルトのブロックリスト設定(デフォルト・フィルタで指定されている禁止クラスのセットを含む)は今後変わる可能性があります。WebLogicサーバーのパッチ・セット更新(PSU)には、デフォルト・フィルタで使用される一連の禁止されたクラスおよびパッケージの更新が含まれる場合があります。システムが最新のデフォルト・フィルタで保護されるようにするには、最新のWebLogic Server PSUおよびJavaクリティカル・パッチ・アップデート(CPU)をリリース後すぐに適用してください。クリティカル・パッチ・アップデート、セキュリティ・アラートおよび掲示板のページには、My Oracle Supportで入手可能な最新のJavaおよびWebLogic Serverのアップデートが一覧表示されています。
-
または、許可リストを使用することもできます。最初に、ドメイン内のアプリケーションでデシリアライズされるクラスおよびパッケージを含む許可リストを作成する必要があります。これを行うには、記録を有効にして、WebLogic Serverと顧客アプリケーションの両方のデシリアライズで使用されるクラスおよびパッケージをすべて記録します。デシリアライズが発生すると、各クラスが許可リスト構成ファイル内に記録されます。許可リストに問題がなければ、JEP 290フィルタリングに許可リスト構成ファイルを使用するようにWebLogic Serverを構成します。「JEP 290フィルタリング用の許可リストの使用」を参照してください。
JEP 290のフィルタ構文は、ブロックリスト・モデルと許可リスト・モデルの両方をサポートします。JEP 290のフィルタ構文については、http://openjdk.java.net/jeps/290のプロセス全体のフィルタに関する項を参照してください。WebLogic Serverがクラスをブロックまたは許可するために使用する構成ファイルは、JEP 290の構文に準拠しています。たとえば、パターン!foo.bar.Mumbleはクラスfoo.bar.Mumbleをブロックします。!が前に付いていないクラスおよびパッケージは許可されます。
WebLogic ServerがJEP 290のブロックリストおよび許可リストを使用する方法
WebLogic Serverは、JEP 290ブロックリスト・モデルと許可リスト・モデルの両方を使用して、デシリアライズ攻撃を防ぎます。
ブロックリスト・モデルを使用している場合、WebLogic ServerではJEP 290を次のように使用します:
-
WebLogic Server固有のJEP 290フィルタを実装して、WebLogic Serverによって使用されるデシリアライズに対して禁止されたクラスおよびパッケージのブロックリストを適用し、他のすべてのクラスおよびパッケージを許可します。フィルタでは、デシリアライズ・オブジェクト・ツリーの最大の深さのデフォルト値も適用されます。
-
グローバルJEP 290フィルタを実装して、アプリケーションまたはサード・パーティ・ライブラリで使用されるデシリアライズに対して禁止されているクラスおよびパッケージのブロックリストを適用します。
-
クラスおよびパッケージをデフォルト・フィルタに追加または削除して特定のクラスをブロックするなど、デフォルト・フィルタをカスタマイズするために使用できるWebLogic Server JEP 290プロパティを提供します。
許可リスト・モデルを使用している場合、WebLogic ServerではJEP 290を次のように使用します:
-
WebLogic Server固有のJEP 290フィルタを実装して、WebLogic Serverによって使用されるデシリアライズに対して許可されたクラスおよびパッケージの許可リストを適用し、他のすべてのクラスおよびパッケージをブロックします。
-
グローバルJEP 290フィルタを実装して、アプリケーションまたはサード・パーティ・ライブラリによって使用されるデシリアライズに対して許可されたクラスおよびパッケージの許可リストを適用し、他のすべてのクラスおよびパッケージをブロックします。
-
クラスおよびパッケージを記録されたフィルタに追加または削除して特定のクラスを許可またはブロックするなど、許可リストをカスタマイズするために使用できるWebLogic Server JEP 290プロパティを提供します。
JEP 290プロパティを使用して、デシリアライズ・オブジェクトのネストの深さ、デシリアライズ・オブジェクト内の内部参照の数、配列のサイズ、デシリアライズ・オブジェクトの最大サイズ(バイト単位)に基づいてデシリアライズ・クラスをフィルタすることもできます。
プロパティを使用したJEP 290フィルタのカスタマイズ
WebLogic Serverには、必要に応じてJEP 290フィルタをカスタマイズ、置換または無効にするために使用できるプロパティが含まれます。これらのプロパティは、システム・プロパティとしてコマンドラインで指定することも、JEP 290動的構成ファイルおよび許可リスト構成ファイルにプロパティとして含めることもできます。
次の表は、プロパティについて説明しており、使用例が含まれています。
表3-2 WebLogic Server JEP 290のプロパティ
| プロパティ | 説明 |
|---|---|
|
|
このプロパティは、JEP 290の標準フィルタ構文を使用してWebLogic ServerのカスタムJEP 290フィルタを設定する場合に使用します。JEP 290のフィルタ構文については、 デフォルトでは、このカスタム・フィルタはデフォルトのWebLogic Serverフィルタと結合され、いずれかのフィルタ要素が競合した場合にはカスタム・フィルタがデフォルト・フィルタより優先されます。許可リスト・モデルを使用している場合、ブロックされたすべてのクラスおよびパッケージは、許可リスト・フィルタで最も優先度が高くなります。 たとえば、
この設定により、デフォルト・フィルタで許可されている場合でもクラス |
|
|
このプロパティは、デフォルトのWebLogic Serverフィルタを結合、置換または無効化する機能を提供する、カスタム・フィルタのフィルタ・モードを指定する場合に使用します。有効な値は次のとおりです。
たとえば、デフォルトのWebLogic Serverフィルタをカスタム・フィルタに置き換えるには、次の設定を使用します。 -Dweblogic.oif.serialFilterMode=replace |
|
|
このプロパティは、フィルタをJVM全体(顧客アプリケーションおよびサード・パーティ・ライブラリのデシリアライズ)にグローバルに適用するか、内部WebLogic Serverのデシリアライズにのみ適用するかを指定する場合に使用します。有効値は ノート: JDK 7 Update 191 (JDK 7u191)以上およびJDK 8 Update 181 (JDK 8u181)以上の場合、デフォルトはglobalです。それより前のサポートされているJDKのバージョンの場合、デフォルトはweblogicです。
たとえば、JVM全体ではなく、内部WebLogic ServerのデシリアライゼーションにのみWebLogic Serverのデフォルトまたはカスタム・フィルタを適用するには、次の設定を使用します。 -Dweblogic.oif.serialFilterScope=weblogic |
|
|
このプロパティは、JEP 290の標準フィルタ構文を使用してWebLogic ServerのカスタムJEP 290グローバル・フィルタを設定する場合に使用します。JEP 290のフィルタ構文については、 デフォルトでは、このカスタム・グローバル・フィルタはデフォルトのWebLogic Serverフィルタと結合され、いずれかのフィルタ要素が競合した場合にはカスタム・グローバル・フィルタがデフォルト・フィルタより優先されます。このグローバル・フィルタは、アプリケーションおよびサード・パーティ・ライブラリのデシリアライズに使用されるオブジェクト入力ストリームに適用され、WebLogic Serverのデシリアライズには適用されません たとえば、
この設定により、デフォルト・フィルタで許可されている場合でも、顧客アプリケーションおよびサード・パーティ・ライブラリのデシリアライズからクラス |
|
|
このプロパティは、JEP 290の標準フィルタ構文を使用してWebLogic ServerのカスタムJEP 290フィルタをオーバーライドする場合に使用します。JEP 290のフィルタ構文については、 デフォルトでは、このヘッド・フィルタはカスタムおよびデフォルトのWebLogic Serverフィルタと結合され、いずれかのフィルタ要素が競合した場合にはヘッド・フィルタがカスタム・フィルタとデフォルト・フィルタの両方より優先されます。 たとえば、 -Dweblogic.oif.head.serialFilter=”!foo.bar.Mumble” この設定により、カスタム・フィルタおよびデフォルト・フィルタで許可されている場合でも、クラス |
|
|
このプロパティは、JEP 290の標準フィルタ構文を使用してWebLogic ServerのカスタムJEP 290グローバル・フィルタをオーバーライドする場合に使用します。JEP 290のフィルタ構文については、 デフォルトでは、このカスタム・グローバル・フィルタはカスタムおよびデフォルトのWebLogic Serverフィルタと結合され、いずれかのフィルタ要素が競合した場合にはヘッド・グローバル・フィルタがカスタム・フィルタとデフォルト・フィルタの両方より優先されます。このグローバル・フィルタは、アプリケーションおよびサード・パーティ・ライブラリのデシリアライズに使用されるオブジェクト入力ストリームに適用され、WebLogic Serverのデシリアライズには適用されません たとえば、
この設定により、カスタム・フィルタおよびデフォルト・フィルタで許可されている場合でも、顧客アプリケーションおよびサード・パーティ・ライブラリのデシリアライズからクラス |
|
|
このプロパティは、JEP 290の標準フィルタ構文を使用してWebLogic Serverの未認証コード・パスのカスタムJEP 290フィルタを設定する場合に使用します。JEP 290のフィルタ構文については、 ノート: このフィルタは、リモート匿名RMI T3およびIIOPリクエストを無効にした場合に使用されます。ユーザーは未認証コード・パス・フィルタをカスタマイズする必要はありません。未認証コード・パスで許可されているクラスの現在のセットで十分です。デフォルトでは、このカスタム・フィルタはデフォルトのWebLogic Server未認証フィルタと結合され、いずれかのフィルタ要素が競合した場合にはカスタム・フィルタがデフォルト・フィルタより優先されます。 たとえば、 -Dweblogic.oif.serialUnauthenticatedFilter="foo.bar.Mumble"この設定により、未認証コード・パスでクラス |
動的ブロックリスト構成ファイルの使用
動的ブロックリストでは、サーバーの実行中に更新または置換できる構成ファイルを作成することで、ブロックリスト・フィルタを更新できます。
-
デフォルトでは、WebLogic Serverは、
DOMAIN_HOME/config/securityディレクトリにある動的ブロックリスト構成ファイルの存在を検出し、構成ファイルで指定されたクラスのデシリアライズをブロックします。 -
WebLogic Serverでは、他のディレクトリ(Oracleホーム・ディレクトリなど)に配置した動的ブロックリスト構成ファイルを検索し、必要に応じてそれらのファイルを使用してデシリアライズをブロックできます。WebLogic Serverでこれらのファイルの存在を検出するには、新しいシステム・プロパティ
weblogic.oif.serialPropDirectoriesを使用してファイルの場所を指定し、そのプロパティをWebLogic Serverの起動スクリプトに含める必要があります。
2021年7月のPSUでは、WebLogic Serverは、ORACLE_HOME/oracle_common/common/jep290ディレクトリにある動的ブロックリスト構成ファイルの存在を検出し、ファイルで指定されたクラスおよびパッケージのデシリアライズをブロックすることもできます。
ブロックリスト・ファイルがこれらの場所に保存されると、WebLogic Serverは指定された時間間隔でブロックリスト・ファイルを読み取り、指定されたブロックの強制をすぐに開始します。サーバーを停止せずにファイルを更新または置換できます。
動的ブロックリストを使用するには:
-
目的のWebLogic、グローバルおよび未認証フィルタを含む構成ファイルを作成し、接尾辞
serial.propertiesを使用して保存します。フィルタ文字列に空白が含まれていないことを確認します。また、WebLogic Serverに構成ファイルに対する読取り権限があることを確認してください。そうしないと、サーバーの起動に失敗します。serial.propertiesファイルのサンプルを次に示します:weblogic.oif.serialFilter=\ !MyCustomer1.Employee;\ !MyCustomer2.Employee2;\ !MyCustomer3.*;\ !MyCustomer4.**;\ !MyCustomer5.Employee5 weblogic.oif.serialGlobalFilter=\ !MyCustomer1.Employee;\ !MyCustomer2.Employee2;\ !MyCustomer3.**;\ !MyCustomer4.**;\ !MyCustomer5.Employee5この例では:
-
weblogic.oif.serialFilterは、WebLogic Serverのデシリアライズに適用されます。 -
weblogic.oif.serialGlobalFilterは、顧客アプリケーションおよびサード・パーティ・ライブラリのデシリアライズに適用されます。
どちらのフィルタでも、最初に一致したものがフィルタ内の他のものより優先されます。これらのフィルタの詳細は、表3-2を参照してください。
-
-
デフォルトの場所を使用するには、ファイルを
DOMAIN_HOME/config/securityディレクトリに保存します。このパス名では、DOMAIN_HOMEはWebLogicドメイン・ルート・ディレクトリを表します。WebLogic Serverは、デフォルトでこのディレクトリのファイルを検出します。デフォルトの場所を使用していない場合は、接尾辞
serial.propertiesが付いたファイルを目的のディレクトリに保存し、起動スクリプトのweblogic.oif.serialPropDirectoriesシステム・プロパティを使用してディレクトリの場所を指定します。複数のファイルと場所を指定できます。たとえば:-Dweblogic.oif.serialPropDirectories=/u01/oracle/fmw/app1:/u01/oracle/fmw/app2 -
デフォルトでは、これらのディレクトリは60秒ごとにポーリングされます。デフォルトのポーリング間隔を変更するには、起動スクリプトで
weblogic.oif.serialPropPollingFileIntervalシステム・プロパティを設定します。たとえば、ポーリング間隔を10秒に設定するには、次を使用します:-Dweblogic.oif.serialPropPollingFileInterval=10000
JEP 290フィルタリング用の許可リストの使用
許可リストは、デシリアライズを許可するWebLogic Serverと顧客アプリケーションのクラスおよびパッケージのリストを定義する構成ファイルです。許可リストを作成および構成して、実行中のシステムでデシリアライズ(またはブロック)されるパッケージおよびクラスを制御できます。
顧客の許可リストを作成および構成するには:
-
ステージング環境またはテスト環境で、次のいずれかの方法を使用して記録を有効にします:
-
WebLogic Server管理コンソールを使用します:
ノート:
許可リスト・モデルのコンソール・サポートが2021年10月のPSUに追加されました。- 管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。
- 管理コンソールの左ペインの「ドメイン構造」の下で、ドメイン名を選択します。
- 「構成」→「許可リスト」を選択し、記録有効チェック・ボックスを選択します。
- 「保存」をクリックして、「チェンジ・センター」で「変更のアクティブ化」をクリックします。
-
WLSTオンラインを使用して、
AllowListMBeanにAllowListRecordingEnabled属性を設定します:edit() startEdit() cd("AllowList/mydomain") cmo.setAllowListRecordingEnabled(true) save() activate() disconnect()
記録が有効になっている場合、ブロックリストで指定されているクラスを除き、デシリアライズ時にすべてのクラスが許可されます。
-
-
記録された許可リスト構成ファイルによって、アプリケーションが正常に実行されるために許可する必要があるすべてのパッケージおよびクラスを適切にカバーしていることを確認するために、テストの完全なセットを実行します。デシリアライズが発生すると、各クラスが次の構成ファイル内に記録されます:
DOMAIN_HOME/config/security/jep290-recorded.serial.propertiesこのパス名では、
DOMAIN_HOMEはWebLogicドメイン・ルート・ディレクトリを表します。jep290-recorded.serial.propertiesのサンプルを次に示します:Wed May 19 23:55:13 UTC 2021 weblogic.oif.serialFilter=\ com.company1.common.collections.objs.*;\ com.company1.common.tools.Calculator;\ com.company2.shared.tools.Converter weblogic.oif.serialGlobalFilter=\ com.company1.common.lists.AList;\ com.company1.common.tools.Calculator;\ com.company2.shared.tools.* -
WebLogic Server管理コンソールまたはWLSTオンラインを使用して記録を無効にします:
-
WebLogic Server管理コンソールで、「許可リスト」ページの記録有効チェック・ボックスをクリアし、「保存」、「変更のアクティブ化」の順にクリックします。
-
WLSTオンラインを使用して、
AllowListRecordingEnabled属性をfalseに設定します。
-
-
次のいずれかの方法で許可リストまたはブロックリストを使用するようにWebLogic Serverドメインを構成します:
-
WebLogic Server管理コンソールで、「許可リスト」ページの「違反アクション」コントロールから目的の設定を選択し、「保存」をクリックして、「変更のアクティブ化」をクリックします。
-
WLSTオンラインを使用して、
AllowListMBeanにAllowListViolationAction属性を設定します。
次の設定が可能です:
-
IGNORE- 許可リストを無視し、ブロックリストを使用します。デシリアライズ中に見つかったクラスがブロックリストに存在する場合、そのクラスのデシリアライズはブロックされます。 -
DENY- 許可リストで指定されているクラスを除くすべてをブロックし、クラスがブロックされたときにメッセージをログに記録します。 -
LOG- 違反が発生した場合はメッセージをログに記録しますが、ブロックリストに記載されていないかぎり、クラスを許可します。
ノート:
ネットワーク・アクセス・ポイントを使用して、チャネルにAllowListViolationActionを設定することもできます。これにより、信頼性のない外部チャネルでは許可リストを、内部の信頼性のあるチャネルではブロックリストを使用できます。 -
-
デフォルトでは、許可リスト構成ファイルを含むディレクトリは60秒ごとにポーリングされます。デフォルトのポーリング間隔を変更するには、次のいずれかを行います:
-
WebLogic Server管理コンソールで、「許可リスト」ページのシリアル・プロファイル・ポーリング間隔コントロールから目的の間隔を入力し、「保存」をクリックして、「変更のアクティブ化」をクリックします。
-
AllowListMBeanのserialPropPollingFileInterval属性を目的の間隔に設定します。 -
起動スクリプトで
weblogic.oif.serialPropPollingFileIntervalシステム・プロパティを設定します。たとえば、ポーリング間隔を10秒に設定するには、次を使用します:-Dweblogic.oif.serialPropPollingFileInterval=10000
-
-
ステップ2で作成した記録された許可リスト構成ファイルを本番ドメインの
DOMAIN_HOME/config/securityディレクトリにコピーして、許可リストを使用するように本番ドメインを構成します。ノート:
すべてのクラスおよびパッケージが確実に記録されるように、AllowListViolationActionをLogに設定して本番ドメインを一定期間実行することをお薦めします。 -
許可リスト構成ファイルの精度を維持します。新規アプリケーションがドメインにデプロイされるか、またはアプリケーションの新しいバージョンがデプロイされるたびに、ステップ1から開始してこのプロセスを繰り返して、許可リストを再作成するか、新しいアプリケーションで許可リストを検証し、新規または更新されたアプリケーションに必要なすべてのパッケージおよびクラスが許可リストに含まれていることを確認する必要があります。
記録後の許可リストのカスタマイズ
許可リストを作成する際には、可能なかぎり記録する方法を使用することをお薦めします。許可リスト構成ファイルの作成後にカスタマイズが必要な場合は、次のようにします:
-
記録をオフにします。
-
jep290-recorded.serial.propertiesファイルのバックアップ・コピーを作成します。 -
DOMAIN_HOME/config/security/ディレクトリのjep290-recorded.serial.propertiesを編集して、必要に応じてクラスを追加または削除します。「プロパティを使用したJEP 290フィルタのカスタマイズ」を参照してください。
このリストは、次のサンプルのjep290-recorded.serial.propertiesファイルの編集例を示しています:
Wed May 19 23:55:13 UTC 2021
weblogic.oif.serialFilter=\
com.company1.common.collections.objs.*;\
com.company1.common.tools.Calculator;\
com.company2.shared.tools.Converter
weblogic.oif.serialGlobalFilter=\
com.company1.common.lists.AList;\
com.company1.common.tools.Calculator;\
com.company2.shared.tools.*
-
記録されたファイルからのクラスの削除
記録された許可リスト・ファイルが、ブロックするクラスを許可している場合は、記録された
jep290-recorded.serial.propertiesファイルを編集して、そのクラスを削除します。たとえば、サンプルの記録された許可リスト・ファイルのWebLogicフィルタとグローバル・フィルタの両方からクラスcom.company1.common.tools.Calculator;を削除するには、weblogic.oif.serialFilter=\とweblogic.oif.serialGlobalFilter=\の両方のスタンザから行を削除します。結果のサンプル・ファイルは次のようになります:
Wed May 19 23:55:13 UTC 2021 weblogic.oif.serialFilter=\ com.company1.common.collections.objs.*;\ com.company2.shared.tools.Converter weblogic.oif.serialGlobalFilter=\ com.company1.common.lists.AList;\ com.company2.shared.tools.* -
記録された許可リスト・ファイルへのクラスの追加
ブロックされている記録された許可リスト・ファイルにクラスを追加する場合は、記録された
jep290-recorded.serial.propertiesファイルを編集して、目的のフィルタにクラスを追加します。たとえば、サンプルの記録されたファイルのWebLogicフィルタとグローバル・フィルタの両方にクラスcom.company1.MyApplication1を追加するには、weblogic.oif.serialFilter=\とweblogic.oif.serialGlobalFilter=\の両方のスタンザに行を追加します。結果のサンプル・ファイルは次のようになります(太字のテキストは、追加されたコンテンツを示します):
Wed May 19 23:55:13 UTC 2021 weblogic.oif.serialFilter=\ com.company1.common.collections.objs.*;\ com.company1.common.tools.Calculator;\ com.company2.shared.tools.Converter;\ com.company1.MyApplication1 weblogic.oif.serialGlobalFilter=\ com.company1.common.lists.AList;\ com.company1.common.tools.Calculator;\ com.company2.shared.tools.*;\ com.company1.MyApplication1 -
WebLogic Serverがブロックしているクラスの許可
「フィルタ順序プリファレンスの理解」で説明しているように、ブロックされたすべてのクラスおよびパッケージは、
weblogic.oif.head.serialGlobalFilterまたはweblogic.oif.head.serialFilterプロパティで特に許可されていないかぎり、許可リスト・フィルタで最も優先度が高くなります。したがって、クラス
org.codehaus.groovy.runtime.ConvertedClosureがWebLogic Serverのカスタム・フィルタまたはデフォルト・フィルタによってブロックされており、このクラスをグローバル・オブジェクト入力ストリーム(アプリケーションおよびサード・パーティ・ライブラリのデシリアライズに使用)に対して許可する場合は、weblogic.oif.head.serialGlobalFilterJEP 290プロパティを使用してフィルタの設定をオーバーライドできます。次のいずれかの方法を実行します。-
コマンドラインでシステム・プロパティとして次のプロパティを指定します:
-Dweblogic.oif.head.serialGlobalFilter=org.codehaus.groovy.runtime.ConvertedClosure
-
サンプルの記録された
DOMAIN_HOME/config/security/jep290-recorded.serial.propertiesファイルに次の行を追加します:weblogic.oif.head.serialGlobalFilter=\ org.codehaus.groovy.runtime.ConvertedClosure結果のサンプル許可リスト・ファイルは次のようになります(太字のテキストは、追加されたコンテンツを示します):
Wed May 19 23:55:13 UTC 2021 weblogic.oif.serialFilter=\ com.company1.common.collections.objs.*;\ com.company1.common.tools.Calculator;\ com.company2.shared.tools.Converter weblogic.oif.serialGlobalFilter=\ com.company1.common.lists.AList;\ com.company1.common.tools.Calculator;\ com.company2.shared.tools.* weblogic.oif.head.serialGlobalFilter=\ org.codehaus.groovy.runtime.ConvertedClosure weblogic.oif.serialUnauthenticatedFilter=\
クラス
org.codehaus.groovy.runtime.ConvertedClosureがWebLogic Serverのカスタム・フィルタまたはデフォルト・フィルタによってブロックされており、このクラスをWebLogic Serverのデシリアライズに対して許可する場合は、次のいずれかを実行します:-
コマンドラインでシステム・プロパティとして次のプロパティを指定します:
-Dweblogic.oif.head.serialFilter=org.codehaus.groovy.runtime.ConvertedClosure
-
サンプルの記録された
DOMAIN_HOME/config/security/jep290-recorded.serial.propertiesファイルに次の行を追加します:weblogic.oif.head.serialFilter=\ org.codehaus.groovy.runtime.ConvertedClosure結果のサンプル・ファイルは次のようになります(太字のテキストは、追加されたコンテンツを示します):
Wed May 19 23:55:13 UTC 2021 weblogic.oif.serialFilter=\ com.company1.common.collections.objs.*;\ com.company1.common.tools.Calculator;\ com.company2.shared.tools.Converter weblogic.oif.serialGlobalFilter=\ com.company1.common.lists.AList;\ com.company1.common.tools.Calculator;\ com.company2.shared.tools.* weblogic.oif.head.serialFilter=\ org.codehaus.groovy.runtime.ConvertedClosure weblogic.oif.serialUnauthenticatedFilter=\
-
必要に応じてファイルを編集して保存すると、サーバーは指定されたポーリング間隔後に編集されたファイルを取得します。
フィルタ・ロギングの有効化
WebLogic Serverでは、システム・プロパティweblogic.oif.serialFilterLoggingおよびデバッグ・フラグDebugAllowListがServerDebugMBeanに用意されており、これを使用して、現在のブロックリストと許可リストのクラスおよびパッケージをログに記録できます。
ログを有効にするには、weblogic.oif.serialFilterLoggingシステム・プロパティをtrueに設定してWebLogic Serverを起動します。たとえば:
./startWebLogic.sh -Dweblogic.oif.serialFilterLogging=true
ノート:
2021年7月のPSUで、新しいプロパティDebugAllowListがServerDebugMBeanに追加されました。実装固有のロギングの詳細を取得するには、WebLogic Server管理コンソール、WLSTまたはコマンドラインを使用して、このプロパティをtrueに設定します(たとえば-Dweblogic.debug.DebugAllowList=true)。
次のログは、システム・プロパティを使用したサンプル出力を示しています。フィルタ設定、およびブロックリストと許可リストのクラスとパッケージが、サーバー・ログに表示されます。
<Jul 1, 2021 9:07:33,787 PM UTC> <Info> <WebLogicServer> <BEA-003807> <The WebLogic Server JEP 290 filter mode is COMBINE>
<Jul 1, 2021 9:07:33,787 PM UTC> <Info> <WebLogicServer> <BEA-003808> <The WebLogic Server JEP 290 filter scope is GLOBAL>
<Jul 1, 2021 9:07:33,788 PM UTC> <Info> <WebLogicServer> <BEA-003810> <WebLogic Server JEP 290 filter limit element for scope WEBLOGIC is: maxdepth=250>
...
<Jul 1, 2021 9:07:33,790 PM UTC> <Info> <WebLogicServer> <BEA-003811> <WebLogic Server JEP 290 filter blocklist package for scope WEBLOGIC is: org.apache.commons.collections.functors>
...
<Jul 1, 2021 9:07:33,802 PM UTC> <Info> <WebLogicServer> <BEA-003812> <WebLogic Server JEP 290 filter blocklist class for scope WEBLOGIC is: java.rmi.server.RemoteObject>
...
<Jul 1, 2021 9:07:33,806 PM UTC> <Info> <WebLogicServer> <BEA-003813> <WebLogic Server JEP 290 filter allowlist for scope WEBLOGIC is: weblogic.**>
<Jul 1, 2021 9:07:33,806 PM UTC> <Info> <WebLogicServer> <BEA-003813> <WebLogic Server JEP 290 filter allowlist for scope WEBLOGIC is: oracle.**>
...
<Jul 1, 2021 9:07:33,827 PM UTC> <Info> <WebLogicServer> <BEA-003813> <WebLogic Server JEP 290 filter allowlist for scope GLOBAL is: java.**>
...
ノート:
フィルタ・ログには、使用されているフィルタと、追加または削除も表示されます。使用される各フィルタ・タイプ(weblogic.oif.serialFilter、weblogic.oif.serialGlobalFilter、weblogic.oif.serialUnauthenticatedFilterなど)のフィルタ文字列には、フィルタ内のブロックリスト・エントリと許可リスト・エントリの順序が示されます。
フィルタ順序プリファレンスの理解
WebLogic Serverは、プロパティおよび構成ファイルを使用して指定された、ブロックおよび許可されたクラスおよびパッケージを組み合せて、ブロックリストおよび許可リストの順序プリファレンスを決定するために使用されるフィルタを作成します。
作成されたフィルタの優先順位は、優先順位の高いものから低いものの順に、次のように決定されます:
-
weblogic.oif.head.serialFilterおよびweblogic.oif.head.serialGlobalFilterプロパティを使用して、サーバー起動時に指定されたカスタム・フィルタ(最高)。 -
weblogic.oif.serialFilterおよびweblogic.oif.serialGlobalFilterプロパティを使用して、サーバー起動時に指定されたカスタム・フィルタ。 -
weblogic.oif.serialPropDirectoriesプロパティを使用して、構成ファイルで指定されたカスタム・フィルタ。 -
デフォルト・ディレクトリ
DOMAIN_HOME/config/securityにある構成ファイルで指定されたカスタム・フィルタ。 -
Oracleホーム・ディレクトリ
ORACLE_HOME/oracle_common/common/jep290にある構成ファイルで指定されたカスタム・フィルタ。 -
WebLogic Serverのデフォルト・フィルタ(最低)。
ノート:
許可リストを使用している場合、ブロックされたすべてのクラスおよびパッケージは、weblogic.oif.head.serialFilterまたはweblogic.oif.head.serialGlobalFilterプロパティで特に許可されていないかぎり、許可リスト・フィルタで最も優先度が高くなります。
デシリアライズ・タイムアウト間隔の設定
デシリアライズに時間制限を設定することで、潜在的なサービス拒否攻撃に対する保護を強化できます。時間制限が経過すると、デシリアライズ・プロセスは自動的に終了します。
2022年4月のパッチ・セット更新(PSU)では、RMIプロトコルによって使用される場合のKernelMBean属性RMIDeserializationMaxTimeLimitおよびweblogic.rmi.stream.deserialization.timelimitmillisシステム・プロパティのサポートが追加されています。2023年1月のPSUでは、この機能をIIOPに拡張しています。
デフォルトでは、Javaオブジェクトのデシリアライズ時に時間制限が無効になり、強制されません。制限を追加するには、KernelMBeanのRMIDeserializationMaxTimeLimit属性またはweblogic.rmi.stream.deserialization.timelimitmillisシステム・プロパティを使用して、必要な時間間隔をミリ秒単位で設定します。WebLogic Serverでは、複数のJavaオブジェクト対して1つの間隔が適用されません。かわりに、トップレベル・オブジェクトそれぞれが、独自の時間制限をトリガーします。
たとえば、時間制限を10秒に設定するには、-Dweblogic.rmi.stream.deserialization.timelimitseconds=10000を使用します。
100ミリ秒以上の間隔を入力します。非常に短い間隔では、デシリアライズがスムーズに動作しない可能性があります。
時間制限を無効にするには、0を入力します。
ノート:
JEP 290システム・プロパティweblogic.oif.serialFilterModeがdisableに設定されている場合、デシリアライズ時間制限は有効になりません。
JTA TransactionLoggable許可リスト
JTAトランザクション・ログ・ストアの実装の脆弱性に対処するため、JTA TransactionLoggable許可リストが追加されました。
TransactionLoggableオブジェクトが永続ストアに書き込まれると、クラス名が保持され、TransactionLoggableクラスの新しいインスタンスをインスタンス化するためにリカバリ中に使用されます。TransactionLoggable許可リストは、永続ストアとの間のTransactionLoggableクラスの書込みと読取りを制限します。
許可リストは、デフォルトでは無効です。有効にすると、許可リストにWLS内部のTransactionLoggableクラスのセットが移入されます。
- デフォルトの許可リストを有効にするには、システム・プロパティを
weblogic.transaction.loggable.allowListに設定します。 - クラスを有効にしてデフォルトの許可リストに追加するには、完全修飾クラス名をカンマで区切ってリストにし、システム・プロパティを設定します。たとえば、
weblogic.transaction.loggable.allowList=p1.ClassA,p2.ClassBです。