3 WebLogic Serverのロックダウン

セキュアなインストールを実行し、保護された本番モードを使用するようにドメインを構成し、ファイアウォールを使用してネットワーク・リソースを保護し、WebLogicリソースおよびアプリケーションを保護することで、WebLogic Serverをロック・ダウンします。

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

• WebLogic Serverのセキュアなインストール

• セキュアなドメインの構成

• ネットワークの保護

• ロックダウンされた環境で使用できない構成および設定

• アプリケーションの保護

WebLogic Serverのセキュアなインストール

WebLogic Serverのセキュアな環境を作成するには、最初にセキュアなインストールを計画します。これには、WebLogic Serverホスト・マシンへのアクセスを認可されたユーザーのみに制限すること、ターゲット環境で必要なWebLogic Serverのコンポーネントのみをインストールすることが含まれます。

• WebLogic Serverをインストールする前に、ホスト・マシン、オペレーティング・システムおよびファイル・システムを保護して、アクセスが認可されたユーザーのみに制限されるようにしてください。具体的な推奨事項については、「ホスト環境の保護」を参照してください。

• インストール・プログラムの実行時には、WebLogic Serverサンプル・アプリケーションをインストールせず、セキュリティ更新を受信するオプションを選択してください。詳細な手順は、『Oracle WebLogic Serverセキュリティの管理』のWebLogic Serverのセキュア・インストールの実行に関する項を参照してください。

最新のパッチおよび更新の適用

インストールした環境のセキュリティを確保するために、最新のWebLogic Server、Javaおよびデータベースのクリティカル・パッチ・アップデートをリリース後すぐに適用することを強くお薦めします。

次の表では、WebLogic Serverインストールを最新のソフトウェア更新で保護するために適用する必要があるパッチおよび更新について説明します。

表3-1 最新のパッチ・セットおよび更新の適用

セキュリティ・アクション	説明
最新のパッチ・セット更新(PSU)をインストールします。	WebLogic Serverのセキュリティ脆弱性の修正は、クリティカル・パッチ・アップデート(CPU)プログラムでリリースされたWebLogic ServerのPSUに含まれています。PSUは計画されたスケジュールに基づき、クリティカル・パッチ・アップデート、セキュリティ・アラートおよび掲示板に従って、サポートが有効でエラー修正対象のWebLogic Serverバージョンおよびパッチ・セットに対して発行されます。 これらのPSUのインストールをスケジュールし、リリースされたら適切なタイミングで適用することを強くお薦めします。 サイトのセキュリティ関連の問題の担当者は、インストールしたWebLogic ServerをOracle Supportに登録し、https://support.oracle.comでMy Oracle Supportアカウントを作成してください。 PSUがリリースされると、その内容がMy Oracle SupportのドキュメントOracle WebLogic Server (WLS)のパッチ・セット更新(PSU)のリリース一覧(ドキュメントID 1470197.1)に記載されます。 WebLogic Serverのセキュリティ脆弱性の詳細はMy Oracle SupportドキュメントのOracle DatabaseおよびFusion Middleware製品のセキュリティ脆弱性に関するFAQ (ドキュメントID 1074055.1)を参照してください。
使用しているWebLogic Serverのバージョンおよびパッチ・セットのサポートが有効で、エラー修正対象であることを確認します。	セキュリティ脆弱性の修正を含む新しいバグ修正は、PremierまたはExtended Support対象およびエラー修正対象の製品バージョンとパッチ・セットの場合のみ提供されます。 WebLogic ServerバージョンがPremierまたはExtended Supportの対象か確認するには、Oracle Fusion MiddlewareのOracleのライフタイム・サポート・ポリシーを参照してください。 WebLogic Serverバージョンおよびパッチ・セットがエラー修正の対象か確認するには、My Oracle SupportドキュメントのOracle WebLogic Serverのエラー修正のサポート日(ドキュメントID 950131.1)に記載されているOracleのエラー修正ポリシーを参照してください 必要に応じて、使用しているWebLogic Serverバージョンおよびパッチ・セットのアップグレードを先見的に計画し、Premier SupportまたはExtended Supportおよびエラー修正の対象となるようにしておく必要があります。
本番システムで使用されるJDKおよびJVMバージョンのセキュリティを維持します。	JDKおよびJVMバージョンとWebLogic Serverの組合せがOracle Fusion Middlewareサポートされているシステム構成で動作保証され、ベンダーによって現在サポートされ、最新のセキュリティ更新が適用されていることを確認します。 Oracle JDKおよびJVMのユーザーには、次のことを強くお薦めします。 Oracle Java SEサポート・ロードマップに従って、現在サポートされているJDKおよびJVMバージョンを使用してください。 最新のJavaクリティカル・パッチ・アップデート(CPU)がリリースされたら、ただちに適用してください。クリティカル・パッチ・アップデート、セキュリティ・アラートおよび掲示板ページで、My Oracle Supportで使用可能な最新のOracle Java SEの使用可能なパッチに関するドキュメントを参照できます。

セキュアなドメインの構成

セキュアなドメインの構成には、保護された本番モードの使用、パスワード検証プロバイダの構成、監査およびユーザー・ロックアウトの構成、WebLogicリソースへのアクセス権を持つアカウントの制限などが含まれます。

内容は次のとおりです:

• 保護された本番モードの構成

• ドメインの管理ポートの構成

• 未使用の内部アプリケーションの無効化

• ドメイン作成後の追加のセキュリティ設定の構成

• WebLogicリソースへのアクセスを単一のユーザー・アカウントに制限する権限の設定

• 暗号化されていないパスワードをコマンドおよびスクリプトに含めない

• WebLogicリソースの保護

• 潜在的なセキュリティの問題の確認

保護された本番モードの構成

脅威に対する脆弱性を軽減するために、ドメインを保護された本番モードで実行するように構成することを強くお薦めします。

セキュリティおよびロギングに関するデフォルトの設定は、ドメイン・モードにより決定されます。開発モードでは、セキュリティ構成が比較的緩和されます。起動IDファイルを使用して管理サーバーを起動するか、autodeployディレクトリを使用してアプリケーションをデプロイできます。本番モードでは、アプリケーションのデプロイおよび管理サーバーの起動にはユーザー名とパスワードが必要になるなど、セキュリティ構成がさらに厳しくなっています。保護された本番モードでは、セキュリティ構成のデフォルトがよりセキュアであり、セキュアでない構成アイテムは警告として記録され、デフォルトの認可およびロール・マッピング・ポリシーはより制限的であるため、本番ドメインは非常にセキュアです。「ドメインのモードがデフォルトのセキュリティ構成に与える影響の理解」を参照してください。

保護された本番モードを構成するには、まずドメインが本番モードであることを確認する必要があります。保護された本番モードは、開発モードで実行しているドメインには使用できません。ドメイン内のWebLogic Serverインスタンスが本番モードで実行されるように変更する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの本番モードへの変更に関する項を参照してください。WebLogic Scripting Toolを使用してドメイン構成に移動し、ProductionModeEnabled MBean属性をtrueに設定することで、DomainMBeanで本番モードを有効化することもできます。MBean Oracle WebLogic ServerリファレンスのDomainMBeanに関する項を参照してください。

保護された本番モードの構成方法の詳細は、『Oracle WebLogic Serverセキュリティの管理』の本番用のWebLogicドメインの作成に関する項を参照してください。

また、WebLogic Server MBeanの最もセキュアな値を有効にすることを強くお薦めします。WebLogic Serverには、WebLogicドメインのセキュリティに影響する属性を持つ、多数のMBeansが含まれています。保護された本番モードを有効にすると、これらの属性のほとんどは自動的に最もセキュアな値に設定されます。ただし、一部のMBean属性は自動的に設定されず、環境に応じて最もセキュアな値に手動で設定する必要があります。たとえば、SSLはデフォルトで有効になっていますが(SSL MBeanではEnabled=true)、SSLMBeanおよびNetworkAccessPointMBeanのTwoWaySSLEnabledおよびClientCertificateEnforced属性は、すべてのクライアントからの証明書を必要とするためtrueに設定されません。双方向SSLが必要な場合は、これらの属性を手動で設定します。これらの属性の包括的なリストと、その最もセキュアな値については、『Oracle WebLogic Server MBeanリファレンス』のMBean属性のセキュアな値に関する項を参照してください。

ノート:

保護された本番モードでは、管理コンソールにアクセスするためのURLはhttps://hostname:port/consoleです。httpの後のsに注意してください。保護された本番モードのデフォルトのポート番号は9002です。

ドメインのモードがデフォルトのセキュリティ構成に与える影響の理解

選択したドメイン・モードにより、そのドメインのデフォルトのセキュリティ構成が決定されます。ドメインの構成時には、WebLogic Serverの実行環境のセキュリティ要件に最も合うドメイン・モードを選択してください。

表3-2に、ドメインを開発モード、本番モードまたは保護された本番モードで構成した場合の、セキュリティおよびパフォーマンス関連の構成パラメータの違いを示します。デフォルトをオーバーライドする属性値を設定することで、様々なドメイン・モードの動作をカスタマイズできます。たとえば、本番モードのドメインで管理ポートを有効にできます。

ノート:

WebLogic Serverは、ドメインが特定のセキュリティ標準を満たしているかどうかを自動的にチェックします。ドメイン内の潜在的なセキュリティの問題ごとに、警告がログに記録され、管理コンソールのセキュリティ警告レポートに表示されます。ドメインが開発モードから本番モード、保護された本番モードへと進むにつれて、セキュリティ検証チェックはより厳格になります。

表3-2 ドメイン・モードでの相違点

機能	開発モード	本番モード	保護された本番モード
SSL/TLS	WebLogic Serverセキュリティ・サービスによって提供されるデモンストレーション・デジタル証明書とデモンストレーション・キーストアを使用できます。これらの証明書を使用すると、SSL/TLSで保護された環境で動作するアプリケーションを設計できます。 『Oracle WebLogic Serverセキュリティの管理』のWebLogic ServerにおけるSSLの構成の概要に関する項を参照してください。	本番モードでは、デモンストレーション・デジタル証明書とキーストアは推奨されません。使用すると、警告メッセージが表示されます。	このモードでは、SSL/TLS構成がセキュアでない場合に、WebLogic Serverで警告がログに記録されます。また、SSLアイデンティティ証明書が期限切れの場合、管理サーバーは起動しません。WebLogic Serverは、最小SSL/TLSバージョン、制約および暗号を検証します。
管理ポート	管理ポートは、デフォルトでは無効です。	管理ポートは、デフォルトでは無効です。 ドメインに対して管理ポートを有効にする方法は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン全体の管理ポートの構成に関する項を参照してください。	管理ポートは、デフォルトでは有効です。管理トラフィクは、非管理ポートでは許可されなくなります。このモードでは、WLSTを使用して管理サーバーに接続する際には、T3sプロトコルと管理ポートを指定する必要があります。管理コンソールは、管理ポート(デフォルトでは9002)でhttpsを介してのみ使用できます。
リスニング・ポート	サーバーのリスニング・ポートは、デフォルトで有効になります。ポート値のデフォルトは7001です。	サーバーのリスニング・ポートは、デフォルトで有効になります。ポート値のデフォルトは7001です。	リスニング・ポートは、デフォルトでは無効です。 リスニング・ポートの有効化および管理の方法は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのリスニング・ポートの構成に関する項を参照してください。
SSL/TLSリスニング・ポート	SSL/TLSリスニング・ポートは、デフォルトでは無効です。	SSL/TLSリスニング・ポートは、デフォルトでは無効です。 ドメイン内のサーバーのSSL/TLSリスニング・ポートを有効にできます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのリスニング・ポートの構成に関する項を参照してください。	SSL/TLSリスニング・ポートは、デフォルトでは有効です。ポート値のデフォルトは7002です。
監査	セキュリティまたは構成監査は、デフォルトでは無効です。	セキュリティまたは構成監査は、デフォルトでは無効です。	ドメインが作成されると、デフォルトでWebLogic監査プロバイダが構成されます。構成変更は監査されます。WebLogic Serverは、監査プロバイダが構成されていない場合に警告をログに記録します。
アプリケーションのデプロイ	WebLogic Serverインスタンスでは、domain_name/autodeployディレクトリに置かれているアプリケーションを自動的にデプロイおよび更新できます。この方法は、単一サーバー開発環境でのみ使用することをお薦めします。『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.deployerによるアプリケーションおよびモジュールのデプロイに関する項を参照してください。	自動デプロイメント機能は無効化されます。WebLogic Server管理コンソール、weblogic.deployerツールまたはWebLogic Scripting Toolを使用します。	保護された本番モードでの自動デプロイメント機能の動作は、本番モードの場合と同じです。
ログ・ファイルのローテーション	デフォルトでは、WebLogic Serverインスタンスを起動すると、サーバーは自動的にローカル・サーバー・ログ・ファイルの名前をSERVER-NAME.log.nに変更(ローテーション)します。以降のサーバー・セッションでは、ローカル・ログ・ファイルのサイズが500KBに達するまで、メッセージが蓄積されます。 『Oracle WebLogic Server Administration Consoleオンラインヘルプ』のログ・ファイルのローテーションに関する項を参照してください。 ロギング構成の「保持するファイル数の制限」の設定のデフォルト値はtrueです。この値では、古いメッセージを格納するためにサーバー・インスタンスによって作成されるログ・ファイルの数が制限されます。	サーバーは、ローカル・ログ・ファイルのサイズが5000KBになるとファイルのローテーションを実行します。 サーバーが本番モードで構成されている場合は、ログ・ファイルのすべてのバージョンがデフォルトで保持されます。管理者は保持されるログ・ファイルの数をカスタマイズする必要がある場合があります。LogFile MBean属性を使用して、WebLogic Serverインスタンスがログ・メッセージを格納するために使用する場所、ファイルのローテーションの基準およびファイルの数を構成します。 ロギング構成の「保持するファイル数の制限」の設定のデフォルト値はtrueです。サーバーでは、5MBのログ・ファイルが100個作成されます。必要に応じて、ファイルをクリーン・アップする必要があります。	保護された本番モードでのログ・ファイルのローテーション動作は、本番モードの場合と同じです。
boot.properties	boot.propertiesファイルが作成され、このファイルを使用することで、ユーザー名とパスワードを指定しなくてもサーバーを起動できます。	boot.propertiesファイルは作成されません。	boot.propertiesファイルは作成されません。
内部アプリケーションのデプロイメント	開発ドメインの場合、デフォルトでは、WebLogic Serverによって内部アプリケーションが初回アクセス時に(オンデマンドで)デプロイされます。	本番モードの場合、デフォルトでは、WebLogic Serverによって内部アプリケーションがサーバーの起動の一部としてデプロイされます。この動作を変更する場合は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の内部アプリケーションのオンデマンド・デプロイメントに関する項を参照してください。	保護された本番モードでの内部アプリケーションのデプロイメントは、本番モードの場合と同じです。
ノード・マネージャのユーザー名およびパスワード	開発モードでは、ノード・マネージャーはデフォルトのユーザー名およびパスワード資格証明を使用します。	本番モードでドメインが作成されたときに、ノード・マネージャのユーザー名およびパスワードがランダムに生成されます。 『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのユーザー名およびパスワードの指定に関する項を参照してください。	保護された本番モードでは、ノード・マネージャのユーザー名とパスワードは本番モードと同じ方法で生成されます。
Webサービスのテスト・クライアント	開発環境では、デフォルトで、Webサービスのテスト・クライアントは有効です。	本番環境では、Webサービスのテスト・クライアントはデフォルトでは無効です(デプロイされていません)。本番モードではWebサービスのテスト・クライアントを有効にしないことをお薦めします。 Webサービス・テスト・クライアントは、管理コンソール、Fusion Middleware ControlまたはWLSTを使用して有効または無効にできます。 『Webサービスの管理』のWebサービスのテスト・クライアントの有効化と無効化に関する項を参照してください。	保護された本番モードでのWebサービス・テスト・クライアントのデフォルトの動作は、本番モードの場合と同じです。
クラスローダー分析ツール	開発モードでは、クラスローダー分析ツール(CAT)は内部のオンデマンド・アプリケーションとしてのみデプロイされます。デプロイメントは初回のアクセス時に実行されます。	サーバーが本番モードで稼働中の場合、自動的にデプロイされません。本番モードでデプロイする際には、その使用に制限はありませんが、他のWebアプリケーションと同様に手動でデプロイする必要があります。 『Oracle WebLogic Serverアプリケーションの開発』のクラスローダー分析ツール(CAT)の使用に関する項を参照してください。	保護された本番モードでのCATツールの動作は、本番モードの場合と同じです。
FastSwapデプロイメント	FastSwapデプロイメントを使用して、再デプロイメントを最小化できます。FastSwapは、WebLogic Serverが開発モードで実行している場合にのみサポートされます。 『Oracle WebLogic Serverへのアプリケーションのデプロイ』のFastSwapデプロイメントによる再デプロイメントの最小化に関する項を参照してください。	本番モードでは、FastSwapは自動的に無効になります。	保護された本番モードでは、FastSwapは自動的に無効になります。
管理コンソールのチェンジ・センター	管理コンソールのチェンジ・センターは、ドメイン構成をロックする手段を提供します。これにより、編集セッションの間は他のアカウントが変更を行えない状態にして、構成を変更できます。 開発モードでドメインが実行されている場合は、この機能はデフォルトで無効になります。開発ドメインでは有効にしたり無効にしたりできます。 『Oracle WebLogic Server Administration Consoleオンラインヘルプ』のドメイン構成ロックの有効化と無効化に関する項を参照してください。	本番モードでは、ドメインの構成を変更する前に、ロックおよび編集セッションを取得する必要があります。このため、このドメイン構成ロック機能は、本番ドメインでは常に有効になっています。	ドメイン構成ロック機能は、本番モードの場合と同じです。
アプリケーションによるRMIを介したJDBCの使用	開発モードでは、DataSourceMBeanのRmiJDBCSecurity属性がCompatibilityに設定されているため、アプリケーションはRMIを介してJDBCオブジェクトにアクセスできます。	本番モードでは、RmiJDBCSecurity属性のデフォルト設定は開発モードと同じCompatibilityです。ただし、RMI経由のJDBCアプリケーション・コールを無効にするようにRMI JDBCセキュリティを構成することを強くお薦めします。これには、DataSourceMBeanのRmiJDBCSecurity属性をSecureに設定します。	保護された本番モードでは、DataSourceMBeanのRmiJDBCSecurity属性はSecureに設定され、リモート・クライアントおよびサーバーによるRMIを介した受信アプリケーションJDBCコールはすべて拒否されます。RMI JDBCセキュリティでは、複数のサーバーにまたがるロギング・ラスト・リソース、1フェーズ・コミットおよび2フェーズ・コミットのエミュレートのデータ・ソース・トランザクション参加者は無効化されません。
JMSファイル・ストア	ファイル・ストアは、ファイル・システムに自動的に作成されます。	ファイル・ストア・ディレクトリはファイル・システムに自動的に作成されず、ユーザーは必要な権限を持つディレクトリを手動で作成する必要があります。	JMSファイル・ストアのデフォルトの動作は、本番モードと同じです。

ドメインの管理ポートの構成

管理トラフィックにドメイン全体の管理ポートを使用することを強くお薦めします。

ノート:

ドメインが保護された本番モードで実行するように構成されている場合は、デフォルトで管理ポートが有効になり、非管理ポートでは管理トラフィックは許可されなくなります。このモードでは、管理ポートが有効になっていないと、WebLogic Serverで警告がログに記録されます。

管理ポートにより、WebLogic Serverドメインのサーバー・インスタンス間のすべての管理トラフィックが1つのポートに制限されます。管理ポートが有効になっている場合、WebLogic Serverはサーバー・インスタンスの起動時にポート設定に基づいて自動的にドメインの管理チャネルを生成します。管理チャネルは、管理トラフィックを処理するためのリスニング・アドレスおよびリスニング・ポートを用意します。

管理ポートを使用せずにサーバーを実行すると、管理クライアントが誤って機密性の高いサーバー構成をクリアテキストでネットワーク上に送信する可能性があります。管理ポートを使用してサーバーを実行すれば、この問題が起こる可能性は大幅に低くなります。さらに、管理ポートを構成することは、管理ポートへのリクエストを処理するためのリソースや管理ポートへのリクエストに対する制限がサーバーの他の部分から分離されるため、サービス拒否(DoS)攻撃が発生した場合に有用です。

接続フィルタと組み合せて使用すると、WebLogic Serverインスタンスが、既知のマシンまたはサブセットからのみ、かつ単一のポートでのみ管理リクエストを受け入れるように指定できます。

管理ポートを有効にするには、クライアントがSSLを使用してWebLogic Server管理コンソールと対話する必要があります。SSLは、ネットワーク上での攻撃者による機密データの傍受や一部のクロスサイト・スクリプティング攻撃を防止します。

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

• Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン全体の管理ポートの構成に関する項

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

未使用の内部アプリケーションの無効化

アプリケーションの用途とドメインの構成によっては、特定のドメインでいくつかの内部アプリケーションを使用しない場合があります。攻撃面を減らすために、これらのアプリケーションへのアクセスを無効にすることを強くお薦めします。

構成設定を使用して、未使用の内部アプリケーションを無効化できます。いくつかの内部アプリケーションは、デフォルトで無効になります。これらは、必要な場合にのみ有効にする必要があります。次の表に、無効にできる内部アプリケーションとそれらを無効にするプロセスのリストを示します。

表3-3 内部アプリケーションの無効化

内部アプリケーション	無効化のプロセス
WebLogic Server管理コンソール	DomainMBeanのConsoleEnabled属性をfalseに設定するか、管理コンソールで、ドメインの詳細構成設定にある「コンソールの有効化」チェック・ボックスの選択を解除します。
RESTfulサービス	RestfulManagementServicesMBeanのEnabled属性をfalseに設定するか、管理コンソールで、ドメインの詳細構成設定にある「RESTful管理サービスの有効化」チェック・ボックスの選択を解除します。
管理EJB (Java EE管理API)	JMXMBeanのManagementEJBEnabled属性をfalseに設定するか、管理コンソールで、ドメインの詳細構成設定にある「管理EJBの有効化」チェック・ボックスの選択を解除します。
デフォルトの内部サーブレット	ServerMBeanのDefaultInternalServletsDisabled属性をtrueに設定します。保護された本番モードでは、この属性はデフォルトでtrueに設定され、内部サーブレットは無効です。
Webサービス非同期リクエスト-レスポンス	OptionalFeatureMBeanを使用してJAXRPC_ASYNC_RESPONSEという名前の非同期リクエスト-レスポンス内部アプリケーションを追加し、その機能をfalseに設定します。これは、次のスニペットに示すようにWLSTを使用して実行できます。 optf = cmo.getOptionalFeatureDeployment() async = optf.createOptionalFeature("JAXRPC_ASYNC_RESPONSE") async.setEnabled(false)
Webサービスの原子性トランザクション(WSAT)	OptionalFeatureMBeanを使用してWSATという名前のWSAT内部アプリケーションを追加し、その機能をfalseに設定します。これは、次のスニペットに示すようにWLSTを使用して実行できます。 optf = cmo.getOptionalFeatureDeployment() wsat = optf.createOptionalFeature("WSAT") wsat.setEnabled(false)
準備完了アプリケーション	OptionalFeatureMBeanを使用してREADYAPPという名前の機能を追加し、その機能をfalseに設定します。これは、次のスニペットに示すようにWLSTを使用して実行できます。 optf = cmo.getOptionalFeatureDeployment() ra = optf.createOptionalFeature("READYAPP") ra.setEnabled(false)

ドメイン作成後の追加のセキュリティ設定の構成

ドメインを作成して保護された本番モードを構成した後、ドメインを保護するために完了する必要がある追加のステップおよび構成がいくつかあります。

次の表では、ドメインのセキュリティを確保するために構成する必要がある追加の構成および設定について説明します。

表3-4 ドメインを保護するための追加の構成および設定

セキュリティ・アクション	説明
システム管理者権限を持つ、少なくとも2つのユーザー・アカウントを作成します。	少なくとも2つのシステム管理者のユーザー・アカウントがあれば、1つのユーザーが辞書攻撃や総当り攻撃でロックアウトになった場合でも、もう1つのユーザーでアカウント・アクセスを保持できます。 システム管理者ユーザーのうちの1つは、ドメインの作成時に作成されます。他のユーザー(複数可)を作成し、これらをAdminセキュリティ・ロールに割り当てます。システム管理者ユーザーを作成したら、それらに対して容易に推測できない一意の名前を付与します。system、admin、administratorなどの明白な名前は使用しないでください。 ノート: 保護された本番モードを有効にしている場合、WebLogic Serverは、管理者グループのユーザーにsystem、admin、administratorまたはweblogicなどのわかりやすい名前が付いていると、警告をログに記録します。
新しいWebLogicドメインを構成した後、ただちにパスワード検証プロバイダを構成します。	WebLogic Serverに含まれているパスワード検証プロバイダは、いくつかの即時利用可能な認証プロバイダでパスワード作成ルールを実施および管理するように構成できます。そのため、セキュリティ・レルムでパスワードを作成または更新された場合は、パスワードは確立された構成要件を満たしていることを確認するために、対応する認証プロバイダによって、パスワード検証プロバイダが自動的に呼び出されます。 パスワード検証プロバイダの構成方法および使用方法の詳細は、『Oracle WebLogic Serverセキュリティの管理』のパスワード検証プロバイダの構成に関する項を参照してください。
UNIX上で保護されているポートにバインドするには、ユーザーIDを切り替えるか、またはネットワーク・アドレス変換(NAT)ソフトウェアを使用するようにWebLogic Serverを構成します。	UNIXシステムでは、権限があるユーザー・アカウント(ほとんどの場合、root)で実行されるプロセスのみを、1024より小さいポートにバインドできます。UNIXシステムでは、システム管理者(root)ユーザーのみが許可されます。 ただし、WebLogic Serverのような長期にわたって実行されるプロセスは、これらの権限が付与されたアカウント下で実行しないでください。かわりに、次のいずれかを行います。 権限を付与されたポートにアクセスする必要のある各WebLogic Serverインスタンスについて、権限があるユーザー・アカウント下で起動し、権限を付与されたポートにバインドしてから、ユーザーIDを権限のないアカウントに変更するようにサーバーを構成します。 サーバー・インスタンスの起動にノード・マネージャを使用する場合は、セキュア・ポート上でのみ、また単一の既知のホストのみから、リクエストを受け入れるようにノード・マネージャを構成します。なお、ノード・マネージャは権限があるユーザー・アカウントで起動する必要があります。 Oracle WebLogic Server管理コンソール・オンライン・ヘルプのUNIX上で稼働するマシンの作成と構成に関する項を参照してください。 WebLogic Serverインスタンスを権限を持たないアカウントから起動し、ネットワーク・アドレス変換(NAT)ソフトウェアを使用して、保護されているポートを保護されないポートにマップするよう、ファイアウォールを構成します。 ノート: 保護された本番モードで実行するドメインを使用している場合、WebLogic Serverは次に該当する場合に警告をログに記録します: 1024より小さいポートが使用されている。 UnixMachineMBeanのPostBindGIDEnabledおよびPostBindUIDEnabled属性がtrueに設定されていない。
JNDIルート・コンテキストを保護します。	WebLogic Server管理コンソールが外部から参照できる場合、EveryoneグループがJNDIルート・コンテキストのリソースにアクセスできてはいけません。デフォルトでは、JNDIリソースにはEveryoneのデフォルト・グループ・セキュリティ・ポリシーがあります。 ノート: ドメインに対して保護された本番モードが有効になっている場合、WebLogic Serverでは、リストまたは変更操作のためのリモート匿名JNDIアクセスは許可されません。匿名JNDIアクセスは、SecurityConfigurationMBeanに含まれているRemoteAnonymousJNDIEnabled属性を設定することによって制御できます。
過負荷状態を回避するために、WebLogic Serverを構成します。	過負荷状態を回避して十分な処理能力を得られるようにWebLogic Serverを構成します。サーバーにかかる負荷が大きい場合に、管理者がWebLogic Serverに接続して問題を修正できるようにします。 システムが過負荷状態のときには、管理チャネルを介した通信は妨げられないため、現在の過負荷がどのような状態であっても管理者は常に接続できます。 負荷が大きい場合、管理者はサーバーを管理状態にして、問題のあるユーザーを特定し、そのユーザーがリクエストによってサーバーを過負荷状態にすることを防止する必要があります。 過負荷状態を回避するためにWebLogic Serverを構成するには、過負荷保護のMBeanで共有容量の属性を設定します。管理者からではないリクエストがWebLogic Serverで受信されなくなった後は、この属性で選択した設定がしきい値となります。 『Oracle WebLogic Serverセキュリティの管理』の過負荷の回避と管理に関する項を参照してください。
ユーザー・アカウントの攻撃を防ぐために、ユーザーのロックアウトおよびログイン時間制限を構成します。	WebLogicセキュリティ・サービスには、デフォルトでユーザー・アカウントの辞書攻撃および総当たり攻撃に対するセキュリティが用意されています。アカウントがロックされるまでの無効なログイン試行回数、アカウントがロックされるまでの無効なログイン試行期間、またはユーザー・アカウントのロック時間を開発時に変更した場合は、設定内容を確認して、その設定が本番環境に適しているかどうかを検証する必要があります。 ノート: ユーザー・ロックアウトはサーバー単位でWebLogicセキュリティ・サービスによってサーバーごとに有効にされます。たとえば、特定の管理対象サーバー(またはクラスタ)でホストされているアプリケーションからロックアウトされたユーザーは、必ずしもWebLogic Server管理コンソールでロックアウトされるわけではありません。同様に、WebLogic Server管理コンソールからロックアウトされたユーザーは、必ずしも管理対象サーバーでホストされているアプリケーションへのログインができなくなるわけではありません。 Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザー・ロックアウト属性の設定に関する項を参照してください。 背景情報: 辞書攻撃および総当たり攻撃では、ハッカーはスクリプトを作成し、辞書に登録されているパスワードを使用してログインを試行します。WebLogic Serverのユーザー・ロックアウトおよびログイン設定により、辞書攻撃および総当たり攻撃からユーザー・アカウントを保護することができます。 ノート: 保護された本番モードで実行するようドメインを構成している場合、WebLogic Serverは、ユーザー・ロックアウトがデフォルト値よりも小さい値に構成されていると警告をログに記録します。
セキュリティ監査を有効にします。	監査は、主要なセキュリティ・イベントをWebLogic Server環境に記録する処理です。WebLogicセキュリティ・サービスが提供する監査プロバイダを有効にすると、イベントがDomainName\DefaultAuditRecorder.logに記録されます。 監査プロバイダは、WebLogic Server管理コンソールの「セキュリティ・レルム」→「レルム名」→「プロバイダ」→「監査」ページで有効にします。 Oracle WebLogic Server管理コンソール・オンライン・ヘルプの監査プロバイダの構成に関する項を参照してください。 ノート: 監査プロバイダを使用すると、少数のイベントのみが記録される場合でも、WebLogic Serverのパフォーマンスが低下する場合があります。 監査レコードを定期的に確認し、セキュリティ違反または違反未遂を検出します。度重なるログインの失敗や、予期しないパターンのセキュリティ・イベントに注目することで、重要な問題を防げる可能性があります。 独自のカスタム監査プロバイダを開発して、プロバイダのMBeanから監査イベントをポストする場合の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のベスト・プラクティス: プロバイダのMBeanからの監査イベントのポストを参照してください。 ノート: ドメインに対して保護された本番モードが有効になっている場合、WebLogic Serverは、監査プロバイダが構成されていないと警告をログに記録します。このモードでは、ConfigurationAuditTypeドメイン構成要素にはセキュアなデフォルト値CONFIG_CHANGE_AUDITが設定されています。監査が有効でない場合に警告をログに記録するかどうかを指定するには、SecureModeMBeanに含まれているWarnOnAuditing属性を使用します。
デフォルトのWebLogic Serverセキュリティ・ロールにユーザーおよびグループを正しく割り当てたことを確認します。	デフォルトでは、すべてのWebLogicリソースは、セキュリティ・ロールのデフォルト・セットに基づくセキュリティ・ポリシーによって保護されています。 目的のユーザーおよびグループをこれらのデフォルト・セキュリティ・ロールに割り当てます。 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。
Federal Information Processing Standards (FIPS) 140-2に準拠する必要がある場合は、FIPSモードが有効になっていることを確認します。	FIPSモードは、RSAプロバイダを使用するJSSEでサポートされます。FIPS 140-2は、重要だが非機密的な使用に関する米国連邦政府の要件が記述された標準です。 インストール済のJDKファイルからFIPSを有効にする方法は、『Oracle WebLogic Serverセキュリティの管理』のjava.securityからのFIPS 140-2モードの有効化に関する項を参照してください。

WebLogicリソースへのアクセスを単一のユーザー・アカウントに制限する権限の設定

各ホスト・コンピュータで、(アクセスの権限を持つ2つのシステム管理者ユーザーに加えて)1つのオペレーティング・システム(OS)ユーザー・アカウントにのみWebLogicリソースへのアクセス権を付与し、ディスクおよび永続ストアに格納されているデータへのアクセスを制限するためのオペレーティング・システム・ファイルのアクセス権を設定します。

重要: WebLogicドメインおよびサーバーの構成ファイルには、WebLogicサーバーを構成または実行するオペレーティング・システム・ユーザーしかアクセスできないようにする必要があります。他のオペレーティング・システム・ユーザー(システム管理者以外)には、WebLogic Serverの製品ファイルおよびドメイン・ファイルの読取り、書込み、実行のためのアクセス権を付与しないでください。

ノート:

デフォルトでは、WebLogic Serverスクリプトはumaskとして027を使用します。これにより、グループ内の他のメンバーからの読取りおよび実行のためのアクセスが可能になります。他のグループ・メンバーからWebLogicリソースにアクセスできないようにするには、オペレーティング・システム・ユーザーがグループの唯一のメンバーであることを確認します。

各WebLogic Serverホスト・コンピュータで、オペレーティング・システムを使用して、WebLogic Serverの実行用に特別なユーザー・アカウント(wls_ownerなど)を設定します。このオペレーティング・システム(OS)・ユーザー・アカウントには、次のディレクトリへのアクセス権限のみを付与します。

• Oracleホーム

  マシンにインストールされているすべてのOracle Fusion Middleware製品用に作成される最上位ディレクトリ。このディレクトリは、WebLogic Serverのインストール時に作成されます。

• WebLogic Server製品インストール・ディレクトリ

  このディレクトリには、システムにインストールすることを選択したすべてのWebLogic Serverソフトウェア・コンポーネントがプログラム・ファイルも含めて格納されます。デフォルトでは、このディレクトリはOracleホームのサブディレクトリであり、wlserverという名前になります。

• WebLogicドメイン・ディレクトリ

  これらのディレクトリには、単一のWebLogicドメインの構成ファイル、 SerializedSystemIni.Datなどのセキュリティ・ファイル、ログ・ファイル、Java EEアプリケーション、その他のJava EEリソースが格納されます。デフォルトでは、ドメインはOracleホームのサブディレクトリです(Oracle/WebLogicServer/user_projects/domains/domain1など)。ただし、ドメイン・ディレクトリはWebLogic Serverインストール・ディレクトリやOracleホーム以外に配置することもできます。WebLogic Serverホスト・コンピュータに複数のドメインを作成する場合は、各ドメイン・ディレクトリを保護する必要があります。

• キーストア・ディレクトリ

  これらのディレクトリには、秘密キー、秘密キーに関連付けられたデジタル証明書、信頼できるCA証明書を含む秘密キーストアとルート認証局(CA)キーストアが含まれます。『Oracle WebLogic Serverセキュリティの管理』の秘密キー、デジタル証明書、信頼できる認証局の格納に関する項を参照してください。

• アプリケーション・アーカイブ・ディレクトリ

  これらのオプションのディレクトリには、ドメインのプロビジョニング・ステージでデプロイメント中にWebLogicサーバーにプロビジョニングされるアプリケーション・アーカイブが含まれます。これらのディレクトリは、WebLogic Serverのインストールおよびドメイン・ディレクトリとは別です。

これにより、WebLogic Serverと同じマシンで実行されている他のアプリケーションのWebLogic Serverファイルおよびドメイン・ファイルへのアクセス権が制限されます。このように保護しないと、他のアプリケーションが書込みアクセス権を得て、動的コンテンツを提供するJSPやその他のファイルに悪意のある実行コードを挿入する可能性があります。そのファイルが次にクライアントに提供されると、挿入されたコードが実行されます。

知識の豊富なオペレーティング・システムのユーザーが、以下のファイルに対して書込みアクセス権(場合によっては読込みアクセス権)を付与されている場合、WebLogic Serverのセキュリティを無視することができます。

• WebLogic Serverのインストール

• JDKファイル(通常、WebLogic Serverインストール内にあります。ただし、別になるように構成できます)

• ドメイン・ディレクトリ

• JMS SAFファイル

• HTTPセッションをバックアップしたファイル

永続ストアを使用するすべてのファイル(JMS SAFファイルなど)には、読込みアクセスと書込みアクセスから保護する必要のある重要なデータが含まれています。永続ストアは、ファイルベースのストアまたはJDBC対応データベースの永続性をサポートします。

ファイル・ストアを使用してWebLogic Serverにファイルを格納する場合、ファイルを任意の場所に格納できます。読込みアクセス権および書込みアクセス権からアプリケーションを保護するには、すべてのファイルの場所を覚えておく必要があります。

JDBCストアを使用してデータを格納する場合、読込みアクセスおよび書込みアクセスから保護することでデータベースを適切に保護します。

ノート:

ドメインが保護された本番モードで実行されていて、ファイル・システムでPOSIXがサポートされている場合には、WebLogic Serverはディレクトリおよびファイル(ドメイン・ディレクトリ、JMS SAFファイルなど)に不正な権限がある場合に警告をログに記録します。権限を設定する際には、最小値としてumask 027を使用します。

$ORACLE_HOME/oracle_common/common/bin/wlst.shや$ORACLE_HOME/oracle_common/common/bin/config.shなどのWebLogic Serverスクリプトは、umaskを027と指定するため、すべてのファイルとディレクトリが適切な権限で作成されます。

暗号化されていないパスワードをコマンドおよびスクリプトに含めない

WLSTおよびweblogic.DeployerコマンドなどのいくつかのWebLogic Serverコマンドでは、暗号化されていないパスワードをコマンド行に指定することができます。暗号化されていないパスワードをコマンド行またはスクリプトに含めないことを強くお薦めします。

コマンド行で暗号化されていないパスワードを指定するのはセキュリティ・リスクです。他のユーザーがモニター画面から簡単に見ることができたり、それらのコマンドの実行をログするプロセスのリストに表示されます。

コマンド・ウィンドウまたはスクリプトで、暗号化されていないパスワードが必要であるコマンドを入力するとき、パスワードは安全に入力されていることを確認するには、以下の注意事項を考慮してください。

• 要求されたときだけパスワードを入力します。コマンド行からパスワードを除くと、コマンドを実行するときにパスワードの入力を要求されます。入力した文字はエコーされません。

• リモート管理サーバー・インスタンスを開始するスクリプト・ベースのノード・マネージャ・コマンドで、リモート起動のユーザー名とパスワードは管理サーバーの起動IDファイルから取得されていることを確認します。

• ユーザー名とパスワードが必要であるコマンドを含むWLSTスクリプトのためにユーザー構成ファイルを作成します。WLST storeUserConfigコマンドを使用して、作成できるこのファイルは、次の情報を含みます。

  • 暗号化された形式の資格証明

  • 資格証明を暗号化するためにWebLogic Serverが使用するキー・ファイル

  WLSTセッション中、または、WLSTスクリプトで、次に示すように、ユーザー構成ファイルをコマンドに渡すことができます:

  • connect — 実行中のWebLogic Serverに接続するため

  • startServer — 管理サーバーを起動するため

  • nmConnect — WLSTをノード・マネージャに接続してセッションを確立するため

• ユーザー名とパスワードが必要であるコマンドを含むweblogic Deployerスクリプトのために、暗号化されていない資格証明を入力するかわりに、WLST storeUserConfigコマンドを使用して、作成したユーザー構成ファイルを指定できます。

ユーザー資格証明をスクリプトに安全に渡すことに関する詳細情報については、以下のトピックを参照してください。

• 『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項および起動IDファイルに関する項。

• 『WebLogic Scripting Toolの理解』のWLSTのセキュリティに関する項。

• 『Oracle WebLogic Serverノード・マネージャの管理』のスクリプトベースのノード・マネージャのリモート・サーバー起動セキュリティの構成に関する項。

• 『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.Deployerを呼び出すための構文に関する項

WebLogicリソースの保護

WebLogicセキュリティ・サービスでは、セキュリティ機能の複数のレイヤーを組み合せることにより、JDBC、JMSまたはEJBリソースなどのWebLogic Serverリソースに対する不正なアクセスを防ぎます。

WebLogicサーバー・ドメインのリソースを保護するには、次の表の各項目を確認します。

表3-5 WebLogicリソースの保護

セキュリティ・アクション	説明
アプリケーションによるRMIを介したJDBCの使用を制限します。	RMIを介したJDBCアプリケーション・コールはセキュアではなく、データベースへの無制限のアクセスが許可される可能性があります。RMIのJDBCセキュリティを構成して、RMIを介したJDBCアプリケーション・コールを無効にすることをお薦めします。そのように行うには: DataSourceMBeanのRmiJDBCSecurity属性をSecureに設定します。これにより、リモート・クライアントおよびサーバーによるRMIを介したすべての受信アプリケーションJDBCコールが拒否されます。 ただし、RMIのJDBCセキュリティでは、サーバーにわたるロギング・ラスト・リソース、1フェーズ・コミットおよび2フェーズ・コミットのエミュレートのデータ・ソース・トランザクション参加者は無効化されません。 WebLogic Server管理コンソールの「構成」→「一般」ページで、サーバーのSSLリスニング・ポート設定が有効なことを確認します。
JTA通信のクロス・ドメイン・セキュリティを構成します。	通信チャネルは、悪質なサード・パーティがトランザクションの結果に影響を与える中間者攻撃を使用できず、1つ以上のドメイン間で管理制御を取得できないようにセキュアにしておく必要があります。ドメイン間のセキュアな通信チャネルを確保するために、WebLogic Serverでは、「クロス・ドメイン・セキュリティ」というドメイン信頼がサポートされています。クロス・ドメイン・セキュリティでは2つのドメイン間(ドメイン・ペア)の信頼関係が確立されて、一方のWebLogicドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼出しを実行できるようになります。WebLogic Serverは、クロス・ドメイン・ユーザーのセキュリティ・ロールを確立し、各ドメインのWebLogic資格証明マッピング・セキュリティ・プロバイダを使用してクロス・ドメイン・ユーザーが使用する資格証明を格納します。 詳細および詳しい構成は、次を参照してください。 『Oracle WebLogic Server JTAアプリケーションの開発』のクロス・ドメイン・セキュリティに関する項 Oracle WebLogic Serverセキュリティの管理のクロス・ドメイン・セキュリティの構成
すべてのWebLogicセキュリティ・ポリシーを確認します。	WebLogic Serverでは、WebLogicリソースへのアクセス権を誰が持っていますか、という質問に対して、セキュリティ・ポリシーが解答を出します。 WebLogicリソースからセキュリティ・ポリシーを削除していないこと、およびセキュリティ・ロールの割当てによってユーザーに目的のアクセス権を提供していることを確認します。 様々なリソース・タイプ、およびポリシーを使用してリソース・タイプを保護する方法の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の次のトピックを参照してください。 WebLogicリソースのセキュリティの理解 ポリシーによるセキュリティの保護が可能なリソースのタイプ

潜在的なセキュリティの問題の確認

WebLogic Serverの2021年7月のパッチ・セット更新(PSU)には、ドメインのセキュリティ構成設定を検証する、新しいWebLogic管理コンソールのセキュリティ検証画面および新しいセキュリティ検証MBeanが含まれています。2021年7月のPSUが適用されると、WebLogic Serverは、ドメイン構成設定を一連のセキュリティ構成ガイドラインに照らし合せて定期的に検証し、ドメインがOracleが推奨する主要なセキュリティ・ガイドラインを満たしているかどうかを判断します。

ドメインがセキュリティ構成設定の推奨事項を満たしていない場合、WebLogic管理コンソールのセキュリティ警告レポートに警告が記録されます。セキュリティ警告レポートにアクティブな警告があると、管理コンソール上部に赤いテキストのバナーが表示されます。テキストをクリックすると、レポートが表示されます。セキュリティ警告レポートには、対処が必要な問題と、どのサーバーについて対処すべきかが表示されます。管理コンソールのホーム・ページでセキュリティ警告レポートの表示をクリックして、現在の警告を確認することもできます。

図3-1 セキュリティ検証の画面

「図3-1 セキュリティ検証の画面」の説明

不適切なSSL/TLS構成、古いパッチ・アップデート、差し迫った証明書の有効期限など、セキュアでないドメインを示している可能性がある一般的な問題について警告が表示されることがあります。ドメインを保護するには、セキュリティおよびビジネスの要件と一致するように、これらの警告を解決します。警告を解決するには、ドメイン構成設定を更新してOracleの推奨事項に合せるか、そのドメイン構成設定のセキュリティ検証チェックを無効にします。

セキュリティ警告レポートの各警告には、ドメイン構成設定の更新方法に関する推奨されるソリューションが含まれています。推奨されるソリューションに従うと、警告は解決されます。同じ問題が、ドメイン内の複数のサーバーに同時に影響を与える可能性があります。セキュリティ警告レポートを確認する際には、影響を受けるすべてのサーバーで問題を修正してください。問題とその解決策によっては、セキュリティ警告レポートを更新するためにサーバーを再起動することが必要な場合があります。

特定されたソリューションの実装に関する詳細なアドバイスについては、My Oracle Supportの記事(ドキュメントID 2788605.1)を参照してください。2021年10月のPSUがインストールされている場合、詳細な解決情報はコンソール内からも利用できます。「セキュリティ警告」表で警告メッセージを選択し、「詳細の表示」をクリックします。「詳細」の横にあるリンクをクリックすると、警告の解決方法に関するガイダンスが表示されます。

Oracleでは、ドメイン構成設定を変更して警告を解決することをお薦めしますが、セキュリティおよびビジネスの要件に基づいて、特定の警告がドメインに適用されないと判断する場合があります。これらの警告については、関連するセキュリティ構成設定を無効にすることができます。WebLogic管理コンソールで、「ドメイン」→「セキュリティ」→「警告」に移動します。警告を表示したくない設定の選択を解除します。

ドメイン構成に移動し、関連する属性をtrueまたはfalseに設定することで、WLSTを使用してSecureMode MBeanにセキュリティ構成設定を構成することもできます。たとえば、WLSTを使用し、次を行います。

edit()
startEdit()
cd("SecurityConfiguration/mydomain/SecureMode/mydomain")
cmo.setWarnOnAnonymousRequests(false)
activate()

アイデンティティおよび信頼の属性の証明書有効期限は、SecurityConfiguration MBeanを使用して構成できます。

WebLogic Serverは、ドメインに最低限必要なJDKバージョンがあるかどうかを常に確認します。JDKのバージョン・チェックを無効にすることはできません。

あるレベルのセキュリティ検証は、すべてのドメイン・モードで行われます。検証は、保護された本番モードでは最も厳格で、開発モードでは最も厳格ではありません。保護された本番モードでは、ほとんどすべてのセキュリティ構成設定がデフォルトで有効になっています。表3-6に、セキュリティ構成設定を示します。

ドメインは24時間ごとにスキャンされます。必要に応じて、スキャンを手動で実行することもできます。

ノート:

ドメインのセキュリティを判断するために、セキュリティ警告レポートだけに依存しないでください。これらのセキュリティ構成設定は、潜在的なセキュリティの問題に幅広く対応していますが、警告が発生しない他のセキュリティの問題がドメイン内にまだ存在している可能性があります。

表3-6 セキュリティ検証チェック

セキュリティ構成設定	説明	適用可能なドメイン・モード
パッチに関する警告	ドメインに最新のWebLogic ServerまたはCoherenceクリティカル・パッチ・アップデートがない場合、警告を発行します。	本番モード
匿名リクエストに関する警告	匿名リクエスト構成属性(RemoteAnonymousRMIT3Enabled、RemoteAnonymousRMIIIOPEnabled)が無効になっていない場合、警告を発行します。	本番モード
アイデンティティ証明書のチェック	警告の有効期限が切れるまでの日数構成設定で指定された期間内にアイデンティティ証明書の期限が切れるように設定されている場合、警告を発行します。	本番モード
信頼証明書のチェック	警告の有効期限が切れるまでの日数構成設定で指定された期間内に信頼証明書の期限が切れるように設定されている場合、警告を発行します。	本番モード
警告の有効期限が切れるまでの日数	WebLogic Serverがアイデンティティ証明書または信頼証明書の期限切れが差し迫っていることを警告するタイミングを日数で入力します。	本番モード
証明書チェック間の日数	WebLogic Serverがアイデンティティ証明書または信頼証明書が期限切れに設定されているかどうかをチェックする頻度を日数で入力します。	本番モード
非セキュアなSSLへの警告	SSL/TLS構成がセキュアでない場合、警告を発行します。これには、ホスト検証、SSLバージョン、制約などのチェックが含まれます。	本番モード
非セキュアなファイル・システムへの警告	ドメイン・ディレクトリのファイル権限がセキュアでない場合、警告を発行します。	本番モード
非セキュアなポートに関する警告	ネットワーク・ポート構成がセキュアでない場合、警告を発行します。	本番モード
ユーザー・ロックアウトに関する警告	ユーザー・ロックアウト設定がセキュアでない場合、警告を発行します。	本番モード
ユーザー名パスワードに関する警告	ユーザー名またはパスワードが推奨される複雑度標準を満たさない場合、警告を発行します。	本番モード
非セキュアなアプリケーションへの警告	アプリケーションがセキュアでない場合、警告を発行します。	本番モード
監査に関する警告	監査が有効でない場合、警告を発行します。	保護された本番モード

ネットワークの保護

ソフトウェアおよびハードウェアを使用してファイアウォール、受信および送信アプリケーション・トラフィックを分離するネットワーク・チャネルなどのコンポーネント、およびネットワーク・レベルでアクセスを拒否する接続フィルタを作成し、本番環境のネットワークを保護します。

ネットワークの保護の一環として、管理ポートを有効にして、WebLogicサーバー・ドメインのサーバー・インスタンス間のすべての管理トラフィックを単一ポートに制限してください。「ドメインの管理ポートの構成」を参照してください。

内容は次のとおりです:

• ファイアウォールの構成

• 接続フィルタの構成

• タイムアウトの構成

• ソケットおよびファイル記述子の構成

• SSL/TLSの構成

• JEP 290を使用した受信シリアライズJavaオブジェクトの制限

• リモート匿名RMI T3およびIIOPリクエストを無効にします

ファイアウォールの構成

ファイアウォールは、信頼できるネットワークと信頼できないネットワーク間の壁の役割を果たすことでネットワーク・トラフィックを制御します。ファイアウォールとともに、ネットワーク・チャネル、管理ポート、WebLogic Server接続フィルタおよび境界認証を使用して、ユーザーおよびネットワーク情報に基づいてリソースへのアクセスを制限できます。

次のことを強くお薦めします:

• HTTPSプロトコル・ネットワーク・チャネルを構成して、HTTPSアプリケーション・トラフィックを分離します。これにより、HTTPSアプリケーション・トラフィックが単独で専用ポートで実行されるようになります。HTTPSポートへの外部アクセスを許可し、HTTPS以外のポートへの外部アクセスをブロックするようにファイアウォールを構成します。

• HTTPS以外のプロトコルの内部チャネルを構成し、ファイアウォールを使用して信頼できるクライアントIPアドレスのみが内部チャネルにアクセスできるようにします。

• チャネルでトンネリングを有効にしないようにします。

トピック

• HTTPS以外のトラフィックからのアクセスを防止するためのネットワーク・チャネルおよびファイアウォールの構成

• 内部アプリケーションへのアクセスを防ぐためのファイアウォールの構成

• クラスタ通信のためのファイアウォールの構成

HTTPS以外のトラフィックからのアクセスを防止するためのネットワーク・チャネルおよびファイアウォールの構成

ネットワーク・チャネルとファイアウォールの組合せを使用して、外部アクセスをHTTPSアプリケーション・トラフィックのみに制限し、HTTPS以外のトラフィック(T3/T3s/IIOP/IIOPs)の外部アクセスをブロックすることを強くお薦めします。

ネットワーク・チャネルは、ネットワークがサポートするプロトコル、リスニング・アドレス、セキュアな通信およびセキュアでない通信のリスニング・ポートなど、WebLogic Serverへのネットワーク接続の属性を定義します。ネットワーク・チャネルを使用することで、管理者はWebLogicサーバーへのネットワーク・アクセスの公開を詳細に制御できます。『Oracle WebLogic Serverサーバー環境の管理』のネットワーク・チャネルの理解に関する項を参照してください。

ネットワーク・チャネルを定義したら、ロード・バランサまたはファイアウォールを使用してそのチャネルのネットワーク接続をさらに分離できます。

• T3/T3s/IIOP/IIOPsプロトコルの使用をファイアウォールの内側にあるWebLogicサーバーおよびクライアントのみに制限するには:

  1. 外部アプリケーションからのHTTPSトラフィックのみをサポートするネットワーク・チャネルを作成します。ネットワーク・チャネルの作成に必要なステップは、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ネットワーク・チャネルの構成に関する項を参照してください
  2. 前のステップで作成したネットワーク・チャネルが外部で使用可能になり、デフォルトのネットワーク・チャネルおよび他の顧客内部チャネルにのみ内部的にアクセスできるようにファイアウォールを構成します。必要なステップについては、ファイアウォールのドキュメントを参照してください。
  3. 外部で使用可能なネットワーク・チャネルでトンネリングを有効にしないようにします。トンネリングはデフォルトでは有効になっていません。

• 外部アプリケーションからのHTTPSトラフィック用の既存のネットワーク・チャネルがすでにある場合、T3またはIIOP呼出しがHTTPSプロトコル内にラップされないようにトンネリングを無効にすることを強くお薦めします。既存のネットワーク・チャネルでトンネリングが有効化されている場合は、WebLogicサーバー管理コンソールを使用して無効化します:

  1. サーバーを選択します。
  2. 「プロトコル」→「チャネル」に移動します。
  3. 目的の外部チャネルを選択します。
  4. 「トンネリングの有効化」チェックボックスを選択解除します。
  5. 変更を保存してアクティブ化します。

次の図は、ファイアウォール、ネットワーク・チャネルおよび管理ポートを使用したセキュアなWebLogic Serverドメイン構成を示しています。この構成には、次のものが含まれます:

• HTTPSトラフィックに対してのみ開いているファイアウォールを介してユーザーがWeb層にアクセスする外部層。ファイアウォールは、T3/T3s/IIOPやIIOPsなどのHTTPS以外のプロトコルからのアクセスをブロックするように構成されます。

• ロード・バランサと2つのHTTPサーバーで構成されるWeb層。Web層とアプリケーション層の間のファイアウォールは、ポート8102でのみHTTPSトラフィックを許可するように構成されます。

• 管理サーバーと2台の管理対象サーバーで構成されたWebLogic Serverドメインを含むアプリケーション層。ドメインは次を使用して構成されます:

  • ポート9002(保護された本番モードのデフォルト)を使用するように有効化および構成された管理ポート。管理ポートは、ドメイン内のアプリケーション・トラフィックから管理トラフィックを分離し、ドメイン内の各管理対象サーバーによって管理サーバーとの通信にのみ使用されます。管理ポートの使用の詳細は、「ドメインの管理ポートの構成」を参照してください。

  • 2つのネットワーク・チャネル:

    • 1つのネットワーク・チャネルは、信頼できるクライアントからのT3sトラフィックのみをサポートするようにポート7102で構成されます。

    • 2つ目のネットワーク・チャネルは、ファイアウォールを介して外部アプリケーションから送信されるHTTPSトラフィックのみをサポートするようにポート8102で構成されます。

      ネットワーク・チャネルに使用可能な任意のポート番号を指定できます。

• ポート9002で管理トラフィックを許可し、ポート7102でT3sトラフィックを許可するように構成された、アプリケーション層と信頼できるアプリケーション・クライアントの間のファイアウォール。内部ファイアウォール内:

  • 信頼できる管理者グループの管理者は、WLSTおよび管理コンソールを信頼できるIPアドレスのセットとともに使用して、管理ポート9002を使用して管理サーバーと通信します。

  • 一連の信頼できるIPアドレスで実行されている信頼できるJMSクライアントおよびEJBクライアントは、ポート7102でT3sプロトコルを使用して管理対象サーバーと通信します。

図3-2 WebLogic Serverのセキュアな構成

「図3-2 WebLogic Serverのセキュアな構成」の説明

内部アプリケーションへのアクセスを防ぐためのファイアウォールの構成

ドメインの管理ポートを有効にし、管理ポートでアクセス可能な内部アプリケーションへの外部アクセスを防ぐためにファイアウォールを構成します。管理ポートとファイアウォールの両方を使用すると、WebLogicサーバー管理コンソールやRESTfulサービスなどの内部アプリケーションに外部からアクセスできなくなります。

内部アプリケーションへのアクセスをブロックするには:

1. 「未使用の内部アプリケーションの無効化」の説明に従って、未使用の内部アプリケーションが無効になっていることを確認します。
2. SAMLおよびWebサービスなどの非管理ポートでアクセス可能な内部アプリケーションへのアクセスを制限するようにファイアウォールを構成します。これを行うには、適切なコンテキスト・パスへのアクセスを無効にします。

次の表に、WebLogic Serverの内部アプリケーションとそのコンテキスト・パスを示します。

表3-7 WebLogic Serverの内部アプリケーションのコンテキスト・パス

内部アプリケーション	管理ポートのみ(有効な場合)	コンテキスト・パス	説明
ファイルの配布	はい	bea_wls_management_internal2	管理対象サーバーへの初期LDAPデータの配布に使用されます。 管理対象サーバーのみがこの内部アプリケーションにアクセスします。
WebLogic Server管理コンソール	はい	console、console-help	管理およびモニターに使用されます。 WebLogicの管理者、デプロイヤ、モニターおよびオペレータが、クライアント・マシン上のブラウザからコンソールにアクセスします。 コンソールのコンテキスト・パスは、DomainMBeanのConsoleContextPath属性で変更できます。ファイアウォール構成は、デフォルトまたはconfig.xmlの値(指定されている場合)と一致する必要があります。
WebLogicサーバー・テスト・クライアント	はい	wls_utc	クライアント・コードを記述せずにWebサービスをテストするために使用されます。本番モードでは、テスト・クライアントは無効です。 WebLogic開発者が、クライアント・マシン上のブラウザからこのアプリケーションにアクセスします。
RESTfulサービス	はい	wls-management-services	管理およびモニターに使用されるREST API機能を提供します。 WebLogicの管理者、デプロイヤ、モニターおよびオペレータが、クライアント・マシンからRESTfulサービスにアクセスします。
デプロイメント・サービス	はい	bea_wls_deployment_internal/DeploymentService	デプロイメントを調整し、管理サーバーと管理対象サーバーの間の変更をアクティブ化するために使用します。このWebアプリケーションは、WLSTまたはweblogic.Deployerクライアントによって呼び出され、アプリケーション・アーカイブまたはプランをアップロードできます。 WebLogic管理サーバーおよび管理対象サーバーが、このアプリケーションにアクセスします。WebLogicの管理者、デプロイヤおよびオペレータが、クライアント・マシンでWLSTおよびweblogic.Deployerを使用してこのアプリケーションにアクセスします。
クラスタ・サーブレット	はい	bea_wls_cluster_internal	レプリケーション、状態の保存、セッション・リカバリなどのクラスタ通信に使用されます。クラスタ・メンバーのみがこのAPIを使用します。
内部サーブレット	いいえ	bea_wls_internal	HTTPを介したRMI/IIOPのトンネリングに使用されます。このアプリケーションは、デフォルトでは無効になっています。 クライアント・マシン上で実行されている管理対象サーバーおよびWebLogic Serverクライアントが、このアプリケーションにアクセスします。
Webサービス非同期レスポンス	いいえ	_async	Webサービスの非同期レスポンス・サービスが含まれます。このアプリケーションは、デフォルトでは無効になっています。 WebLogic Server JAX-RPC非同期アプリケーション・クライアント(WS-RMなど)がWebLogic Serverサーバー・アプリケーション内で実行されている場合にこのアプリケーションにアクセスします。
WebサービスATアプリケーション	いいえ	wls-wsat	WebLogic Server Webサービス原子性トランザクション・サービスが含まれます。このアプリケーションは、トランザクション・コーディネータとして機能します。 クライアント・マシン上で実行されているWebサービス・クライアントがこのアプリケーションにアクセスします。
クラスローダー分析ツール	はい	wls-cat	Webベースのクラス分析ツール。クラスローダー構成のフィルタリングを簡素化し、競合の検出、アプリケーションのクラスパスやクラス競合のデバッグなどのクラスローディングの問題の分析を支援し、それらの解決に役立つソリューションを提案します。このアプリケーションは本番ドメインでは無効です。 WebLogicアプリケーション開発者が、クライアント・マシン上のブラウザからこのアプリケーションにアクセスします。
SAML ITSアプリケーション基本	いいえ	samlits_ba	基本認証のサイト間転送サービスをサポートします。このアプリケーションは、適切なFederationServiceMBeanのIntersiteTransferURIsが構成されている場合にのみ有効になります。 Webブラウザを使用するアプリケーション・シングル・サインオン(SSO)統合機能、SAMLパートナおよびアプリケーション・ユーザーが、デプロイされたアプリケーションでSAMLシングル・サインオン(SSO)をサポートするためにこれらのエンドポイントにアクセスできます。
SAML ITSアプリケーション証明書	いいえ	samlits_cc	クライアント証明書認証のサイト間転送サービスをサポートします。このアプリケーションは、適切なFederationServiceMBeanのIntersiteTransferURIsが構成されている場合にのみ有効になります。 Webブラウザを使用するアプリケーション・シングル・サインオン(SSO)統合機能、SAMLパートナおよびアプリケーション・ユーザーが、デプロイされたアプリケーションでSAMLシングル・サインオン(SSO)をサポートするためにこれらのエンドポイントにアクセスできます。
SAML ACSアプリケーション	いいえ	samlacs	SAMLアサーション・コンシューマ・サービスをサポートします。このアプリケーションは、適切なFederationServiceMBeanのAssertionConsumerURIsが構成されている場合にのみ有効になります。 Webブラウザを使用するアプリケーション・シングル・サインオン(SSO)統合機能、SAMLパートナおよびアプリケーション・ユーザーが、デプロイされたアプリケーションでSAMLシングル・サインオン(SSO)をサポートするためにこれらのエンドポイントにアクセスできます。
SAML ARSアプリケーション	いいえ	samlars	受信アサーション取得リクエストをリスニングします。このアプリケーションは、FederationServicesMBeanのAssertionRetrievalURIsがsamlarsアプリケーションに対して構成されている場合にのみ有効になります。 Webブラウザを使用するアプリケーション・シングル・サインオン(SSO)統合機能、SAMLパートナおよびアプリケーション・ユーザーが、デプロイされたアプリケーションでSAMLシングル・サインオン(SSO)をサポートするためにこれらのエンドポイントにアクセスできます。
SAML2アプリケーション	いいえ	saml2	SAML 2サポートに使用されるサービスが含まれます。これには、SPイニシエータ、IdP SSOサービス、SPアサーション・コンシューマ・サービスおよびアーティファクト解決サービスが含まれます。このアプリケーションは、SingleSignOnServicesMBeanのServiceProviderEnabledまたはIdentityProviderEnabled属性がtrueに設定されている場合のみ有効です。 Webブラウザを使用するアプリケーション・シングル・サインオン(SSO)統合機能、SAMLパートナ、SPシングル・ログアウトおよびアプリケーション・ユーザーが、デプロイされたアプリケーションでSAMLシングル・サインオン(SSO)をサポートするためにこれらのエンドポイントにアクセスできます。

クラスタ通信のためのファイアウォールの構成

ファイアウォールを適切に構成できるように、クラスタ内のサーバー間の通信を理解することが重要です。

WebLogic Serverでは、クラスタ・メンバー間でマルチキャストまたはユニキャスト通信を構成できます。ファイアウォールを使用すると、クラスタ・メンバーを持つサブネットからのクラスタ・ネットワーク・トラフィックは許可されますが、他のサブネットからのトラフィックは妨げられます。クラスタ内の通信の詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタでの通信に関する項を参照してください。JMSまたはEJBを使用する場合は特に、より複雑なポートの分割が必要になることがあります。このような場合、3つ以上のポートが必要になることがあります。ポートの分割により、様々なプロトコルに対して様々なファイアウォール・ルールを柔軟に定義できます。たとえば、HTTPS以外のプロトコルを使用するリモート・クライアントのIPが認識されている場合は、関連するHTTPS以外のプロトコルが独自のポートに適切に分割されると想定して、そのIPに基づくファイアウォール・ルールを構成できます。

『Oracle WebLogic Serverクラスタの管理』のクラスタ・アーキテクチャのセキュリティ・オプションに関する項を参照してください。

接続フィルタの構成

ファイアウォールの作成に加えて、WebLogic Server接続フィルタを使用して受信接続を制限します。

接続フィルタを使用すると、外部に公開されたポートへの接続は、予期されるフロントエンド・ホストからのみで、管理トラフィックの接続は、他のWebLogic Serverまたは管理コンソールが実行されている予期されるサブネットからのみです。

接続フィルタは、WebLogic Serverドメイン内のマシンがお互いにファイアウォールを通過せずにアクセスできる場合に最も適しています。たとえば、ネットワークの外からのトラフィックの制限にはファイアウォールを使用し、ファイアウォールの後ろでのトラフィックの制限にはWebLogic Serverの接続フィルタを使用できます。

単一サーバー構成では、接続フィルタを使用して組込みLDAPリスニング・ポートを閉じ、組込みLDAPポートをブルートフォース攻撃から保護することを強くお薦めします。この場合、複数サーバー構成における組込みLDAPポートは保護されませんが、デフォルトの接続フィルタ実装ではソースのIPアドレスに基づいたフィルタ処理がサポートされていますので、これを使用してドメインを構成するサーバーからのアクセスのみを許可してください。その結果、ドメイン内のマシンのみがLDAPポートにアクセスできるようになります。

接続フィルタの構成の詳細は、『Oracle WebLogic Serverセキュリティの管理』の接続フィルタの使用に関する項を参照してください。

タイムアウトの構成

サービス拒否(DoS)攻撃の可能性を減らすには、メッセージ・サイズを制限し、システムに適した完全なメッセージのタイムアウトを構成し、サーバーに許可されるソケットの数を制限します。

表3-8 セキュアなタイムアウトの構成

セキュリティ・アクション	説明	詳細
システムに合せてComplete Message Timeoutパラメータを適切に構成します。	Complete Message Timeoutパラメータでは、サーバーが完全なメッセージの受信を待機する最大秒数を設定します。 このタイムアウトは、発信者が特定のサイズのメッセージを送信することを示すが、送信が終了することのないサービス拒否(DoS)攻撃からの保護に役立ちます。 このパラメータのデフォルト値は60秒で、デフォルト・ネットワーク・チャネルのすべての接続プロトコルに適用されます。サーバーに待機時間の長いクライアントが多くある場合、この設定が適切である場合があります。ただし、システムの可用性を侵害することなく、この設定を可能なかぎり小さな値にする必要があります。 特定のプロトコルのために完了メッセージ・タイムアウトを指定する必要がある場合、かわりに、そのプロトコルに対して新しいネットワーク・チャネルを構成できます。	Complete Message Timeoutパラメータを設定できるWebLogic Server管理コンソール・ページの表示の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのプロトコルの構成に関する項を参照してください。
サービス拒否攻撃を防ぐために、外部チャネルに対してリクエストのサイズおよび時間を制限します。	サービス拒否(DoS)攻撃を防ぐために、WebLogic Serverではメッセージのサイズ、およびメッセージの到着にかかる最大時間を制限できます。デフォルトの設定では、メッセージのサイズは10MB、完了メッセージのタイムアウトは480秒です。次のことをお薦めします。 管理対象サーバーが管理サーバーからのメッセージを受信できるように内部チャネルのリクエストのサイズ制限を設定します。 外部チャネルに対してリクエストのサイズおよび時間を制限します。 背景情報: DoS攻撃を受けると、Webサイトは動作するが使用できない状態になります。ハッカーは、Webサイトの1つ以上の重要なリソースを枯渇させたり、削除したりします。 侵入者がWebLogic Serverインスタンスに対してDoS攻撃を実行する場合、サイズが非常に大きいリクエスト、完了までに時間がかかるリクエスト、完了しないリクエストを多数使用してサーバーを攻撃するため、リクエストが完了する前にクライアントからのデータの送信が停止します。	これらの設定をHTTP、T3およびIIOPプロトコルに対して構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプで次のタスクを参照してください: HTTPプロトコルの構成 T3プロトコルの構成 IIOPの有効化と構成 『Oracle WebLogic Serverのパフォーマンスのチューニング』のサービス拒否攻撃の可能性の軽減に関する項も参照してください。

ソケットおよびファイル記述子の構成

DoS攻撃を防ぐために、サーバーに許可されるソケットの数を制限することを強くお薦めします。UNIXシステムでの可用性を最適化するには、ソケットで消費されるファイル記述子の数をシステムに適した数に設定してください。

表3-9は、ソケットおよびファイル記述子の数を設定するために実行する必要があるアクションを示しています。

表3-9 ソケットおよびファイル記述子

セキュリティ・アクション	説明	詳細
DoS攻撃を防ぐために、サーバーに許可されるソケット数を設定します。	DoS攻撃を防ぐためには、プロセス全体で許可されるソケット数よりも少なくなるように、サーバーで許可されるソケット数を制限します。これにより、オペレーティング・システムの制限で許可されるファイルの記述子の数を超えないようにすることができます。 サーバーの制限を超えたとしても、管理者は管理ポートを介してサーバーにアクセスできます。 MaxOpenSockCountフラグを使用してこの設定の構成が可能です。	Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー: 構成: チューニングに関する項を参照してください。
UNIXシステムでは、ファイル記述子の数をシステムに適した値に設定します。	UNIXシステムでは、WebLogic Serverへの各ソケット接続がファイル記述子を消費します。可用性を最適化するには、WebLogic Serverのファイル記述子数がホスト・マシンに適している必要があります。デフォルトでは、WebLogic Serverには、1024個ファイル記述子数が構成されています。ただし、特に本番システムでは、この値は小さく設定される場合があります。 WebLogic Serverのファイル記述子の数をチューニングする場合、完全なメッセージのタイムアウト・パラメータに行った変更とバランスの取れた変更を加える必要があることに注意してください。「完了メッセージ・タイムアウト」パラメータの値が大きい場合、メッセージ・タイムアウトが発生するまでソケットが閉じられません。これにより、ファイル記述子の保留時間が長くなります。したがって、完全なメッセージのタイムアウトの値が大きい場合は、ファイル記述子の上限も大きく設定する必要があります。このようにバランスを取ると、システムの可用性が最適化され、DoS攻撃の可能性も軽減されます。	完全なメッセージのタイムアウト・パラメータの詳細は、「タイムアウトの構成」を参照してください。 使用可能なファイル記述子の数のチューニングの詳細は、UNIXベンダーのドキュメントを参照してください。

SSL/TLSの構成

機密データの漏洩を防ぐには、SSL/TLSを使用してデータ転送を保護します。SSL/TLSは、ネットワークを介して接続する2つのアプリケーションが互いのIDを認証できるようにするとともに、アプリケーション間で交換されるデータを暗号化することで、セキュアな接続を実現します。

管理ポート、ネットワーク・チャネル、データベース接続、LDAPサーバー接続、および保護する必要がある通信を処理するその他のリソースに対してSSL/TLSを構成することを強くお薦めします。特に、ドメイン内のリモート・サーバー・インスタンスへの接続がSSL/TLSで保護されていることを確認します。一方向SSL/TLSまたは双方向SSL/TLSのいずれかを構成する必要がある特定のコンポーネントは、本番環境のトポロジ全体によって異なります。SSL/TLSの構成の詳細は、『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。

HTTPS以外のリスニング・ポートを無効化および管理する場合、『Oracle WebLogic Server Administration Consoleオンライン・ヘルプ』のリスニング・ポートの構成に関する項を参照してください。

WebLogic Serverは、HTTP Strict Transport Security (HSTS)を有効にする機能も備えています。HSTSは、Webブラウザまたは他のユーザー・エージェントがHTTPSなどのセキュアな接続のみを使用してサーバーにアクセスできるようにWebサーバーを構成できるWebセキュリティ・ポリシー・メカニズムです。WebLogic ServerでHSTSを有効にする方法の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のHTTP Strict Transport Securityの使用に関する項を参照してください。

本番環境では、暗号化されていないnull暗号を使用できないようにすることを強くお薦めします。SSL/TLSクライアントは、サーバーに接続してSSL/TLSハンドシェイクを開始します。接続の一環として、クライアントは、サポートする暗号スイートのリストをサーバーに送信します。暗号スイートとは、キー交換アルゴリズム、対称暗号化アルゴリズム、およびセキュア・ハッシュ・アルゴリズムを含むSSL/TLS暗号方式です。通信の整合性を保護するために使用します。ただし、正しく構成されていないクライアントが、クリアテキストでネットワーク上でデータを渡すnull暗号のみを含む暗号スイートのセットを指定する場合があります。サーバーは、それがクライアントと共通の唯一の暗号スイートである場合にのみnull暗号を選択し、SSL/TLSセッションがnull暗号を使用していることを示すメッセージをサーバー・ログに含めます。WebLogic Serverには、サーバーがnull暗号を使用しないようにするための管理コンソール・コントロールが含まれています。null暗号および管理コンソール・コントロールの詳細は、『Oracle WebLogic Serverセキュリティの管理』のSSLでのnull暗号の使用に関するノートに関する項を参照してください。

JEP 290を使用した受信シリアライズJavaオブジェクトの制限

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

デシリアライズ攻撃を防ぐには、許可リストとブロックリストという2つのモデルがあります。ブロックリスト・モデルでは、WebLogic Serverは、脆弱な既知のクラスおよびパッケージのセットを定義し、それらをデシリアライズからブロックし、他のすべてのクラスはデシリアライズできるようにします。許可リスト・モデルでは、WebLogic Serverおよび顧客は、デシリアライズを許可されている受入れ可能なクラスおよびパッケージのリストを定義し、他のすべてのクラスをブロックします。どちらのアプローチも利点がありますが、許可リスト・モデルは、WebLogic Serverおよび顧客アプリケーションで必要とされることがわかっているクラスのデシリアライズのみを許可するため、よりセキュアです。

ノート:

2021年10月のパッチ・セット更新(PSU)では、このリリースでのWebLogic Serverの許可リストのサポートが追加されます。

ブロックリストと許可リストのどちらを使用するかを選択できます。両方のメソッドの使用の詳細は、『Oracle WebLogic Serverセキュリティの管理』のOracle WebLogic ServerでのJEP 290の使用に関する項を参照してください。

WebLogic Serverではデフォルトでブロックリストが使用されます。起動時にWebLogic Serverにより、禁止されたクラスおよびパッケージのセットを含むデフォルトのJEP 290ブロックリスト・フィルタおよび、いくつかのJEP 290オプションのデフォルト値が構成されます。WebLogic Serverシステム・プロパティを使用して、フィルタをカスタマイズ、置換、または無効化できます。2021年4月のWebLogic Server PSUでは、動的ブロックリストのサポートが追加されています。これにより、サーバーの実行中に更新または置換できる構成ファイルを作成して、ブロックリスト・フィルタを更新できます。『Oracle WebLogic Serverセキュリティの管理』の動的ブロックリスト構成ファイルの使用に関する項を参照してください。

必要に応じて、許可リスト・モデルの使用を選択できます。最初に、ドメイン内のアプリケーションでデシリアライズされるクラスおよびパッケージを含む許可リストを作成する必要があります。これを行うには、記録を有効にして、WebLogic Serverとアプリケーションの両方のデシリアライズについて、デシリアライズされたクラスおよびパッケージをすべて記録します。デシリアライズが発生すると、各クラスが許可リスト構成ファイル内に記録されます。許可リストに問題がなければ、JEP 290フィルタリングに許可リスト構成ファイルを使用するようにWebLogic Serverを構成します。『Oracle WebLogic Serverセキュリティの管理』のJEP 290フィルタリング用の許可リストの使用に関する項を参照してください。

WebLogic Serverでは、現在のブロックリストおよび許可リストのクラスおよびパッケージをログに記録する機能も提供されます。『Oracle WebLogic Serverセキュリティの管理』のフィルタ・ロギングの有効化に関する項を参照してください。

ノート:

WebLogic Serverパッチ・セット更新(PSU)には、デフォルトのブラックリスト・フィルタで使用される禁止されたクラスおよびパッケージのセットに対する更新が含まれている場合があります。システムが最新のデフォルト・フィルタでデシリアライズの脆弱性に対し保護されるようにするには、最新のWebLogic Server PSUおよびJavaクリティカル・パッチ・アップデート(CPU)をリリース後すぐに適用してください。クリティカル・パッチ・アップデート、セキュリティ・アラートおよび掲示板のページには、My Oracle Supportで入手可能な最新のJavaおよびWebLogic Serverのアップデートが一覧表示されています。

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

リモート匿名RMI T3およびIIOPリクエストを無効にします

デフォルトでは、WebLogic Server 14.1.1以下のリリースはクライアントに匿名RMIリクエストの実行を許可します。2021年4月のパッチ・セット更新(PSU)に、クライアントからの匿名リクエストを無効にする機能が追加されました。

クライアントからの匿名リクエストを無効にする機能には、次の2つの利点があります:

• 認証されていないクライアントは拒否され、WebLogicサーバーでの起動は許可されません。

• 匿名リクエストが無効になっている場合は、追加のJEP 290フィルタリングが実行され、デシリアライズ攻撃からの保護に役立ちます。

匿名RMI T3およびIIOPリクエストを無効にするには、次のいずれかを実行します:

• WebLogic Server管理コンソールを使用して、リモート匿名RMI T3およびIIOPリクエストを無効にします:

  ノート:

  2021年7月のPSUで、リモート匿名RMI T3およびIIOPリクエストを無効にするコンソール・サポートが追加されました。

  1. 管理コンソールの「チェンジ・センター」で、「ロックして編集」をクリックします。

  2. 管理コンソールの左ペインの「ドメイン構造」の下で、ドメイン名を選択します。

  3. 「セキュリティ」→「全般」を選択し、「詳細」ノードを開きます。

  4. IIOP経由でのリモート匿名RMI アクセスおよびT3経由でのリモート匿名RMI アクセスチェック・ボックスの選択を解除します。

  5. 「保存」をクリックして、「チェンジ・センター」で「変更のアクティブ化」をクリックします。

• 匿名リクエストを無効にするには、WLSTを使用して、RemoteAnonymousRMIT3EnabledおよびRemoteAnonymousRMIIIOPEnabled属性をfalseに設定します。(デフォルト値はtrueです。)たとえば、WLSTオンラインの使用:

  edit()
  startEdit()
  cd("SecurityConfiguration/mydomain")
  cmo.setRemoteAnonymousRMIIIOPEnabled(false)
  cmo.setRemoteAnonymousRMIT3Enabled(false)
  activate()

• WebLogic Serverの起動時にRemoteAnonymousRMIT3EnabledおよびRemoteAnonymousRMIIIOPEnabledシステム・プロパティをfalseに設定します。たとえば:

  -Dweblogic.security.remoteAnonymousRMIT3Enabled=false

  -Dweblogic.security.remoteAnonymousRMIIIOPEnabled=false

  ノート:

  これらのシステム・プロパティを使用すると、リモート匿名T3およびIIOPアクセスが無効になりますが、WebLogic Serverの2021年7月のPSUで提供されるセキュリティ検証インフラストラクチャでは、リモート匿名T3およびIIOPアクセスが有効であると誤って警告される場合があります。この警告を解決するには、前述のWebLogic Server管理コンソールまたはWLSTを使用して、リモート匿名T3およびIIOPアクセスを無効にする手順に従います。

WebLogic Server環境で次のいずれかが使用されている場合、リモート匿名RMI T3およびIIOPリクエストを無効にすることはできません:

• JNDI初期コンテキストをWebLogic Serverに作成するときに資格証明(ユーザー名およびパスワード)を渡さないT3またはIIOPクライアント

• 非推奨のweblogic.rmi APIを使用するT3クライアント

• weblogic.j2eeclient.Main APIを利用するクライアント

• セキュリティの相互運用性モードがperformanceまたはdefaultに設定されたドメイン間トランザクション通信を構成する環境(管理チャネルが構成されていない場合)。匿名RMI T3およびIIOPリクエストを無効にする場合、Oracleでは、ドメイン間通信に対してクロス・ドメイン・セキュリティを有効にすることをお薦めします。Oracle WebLogic Server JTAアプリケーションの開発で、ドメイン間およびドメイン内トランザクションのセキュアな通信の構成を参照してください。

リモート匿名リクエストを環境内で必要とするときに無効にすると、匿名リクエストが拒否され、<BEA-000582>および<BEA-002045>エラーがサーバー・ログに記録されます。

ロックダウンされた環境で使用できない構成および設定

開発モードやデモ用証明書などのセキュアでない構成および設定を使用しないこと、および環境を保護するために設計されたデフォルトのセキュア設定を無効にしないことを強くお薦めします。

表3-10 ロックダウンされた環境で使用できない構成および設定

構成/設定	説明	詳細
ファイアウォールの外部で使用可能なチャネルでトンネリングを有効にしないようにします。	トンネリングを許可すると、外部クライアントからT3/IIOPトラフィックが送信され、T3/RMIシリアライズ・セキュリティの脆弱性につながる可能性があります。	HTTPS以外のトラフィックからのアクセスを防止するためのネットワーク・チャネルおよびファイアウォールの構成
本番環境ではWebLogic Serverを開発モードで実行しないようにします。	本番モードまたは保護された本番モードでは、本番環境にとってよりセキュアで適切な設定を使用してサーバーが実行されるように設定されます。本番環境に高いセキュリティ標準を確保するために、保護された本番モードを有効にすることを強くお薦めします。 注意: WebLogic Serverを開発モードで構成した場合、不正を行うアプリケーションやWebLogic Serverの無効な構成などのエラー状況により、デプロイされているトレース・スタックが発生する可能性があります。エラー・レスポンスは一般的には危険ではありませんが、悪意の目的で使用することが可能な、アプリケーションおよびWebLogic Serverインストールの情報を攻撃者に与えるおそれがあります。ただし、本番モードまたは保護された本番モードでWebLogic Serverを構成する場合、スタック・トレースは生成されないため、本番環境では開発モードでWebLogic Serverを実行しないでください。	保護された本番モードの構成
本番モードでは、Webサービスのテスト・クライアントを有効にしないでください。	Webサービスのテスト・クライアントを使用すると、基本機能をテストして、Webサービスがデプロイされ、予想どおりに動作していることを確認できます。これには、Basic認証、Web Services Addressing、原子性トランザクション、SOAP Message Transmission Optimization Mechanism (MTOM)およびOracle Web Service Manager (OWSM)セキュリティ・ポリシーが含まれます。 テスト・クライアントは、開発環境でのみ使用するように設計されています。テスト・クライアントは、管理者ロールまたはデプロイヤ・ロールによる認証を必要とします。ただし、テスト・クライアントでは外部WSDL URLを指定してXMLを直接入力できるため、SSRFおよびXXE攻撃に対して脆弱である可能性があります。	『Webサービスの管理』のWebサービスのテストに関する項を参照してください。
MLet MBeanを使用しないようにします。	MLet (管理アプレット) MBeanを使用すると、クライアント・ユーザーはMBean実装をアップロードして、その実装をWebLogic Serverで実行できます。認証されたユーザーはインスタンス化と起動を実行できるため、デフォルトではJMX MBeanのManagementAppletCreateEnabled属性を使用して、WebLogic ServerによりMLet MBeansの使用が無効化されます。 MLet MBeanの使用を有効にしないことを強くお薦めします。MLet MBeanを有効化する場合は、Javaセキュリティ・マネージャとともに実行し、権限を使用してMLet MBeanへのアクセスを制限することにより、認可されたユーザーのみがMLet MBeanにアクセスできるようにする必要があります。管理者ロールまたはデプロイヤ・ロールを持つ認可されたユーザーに、javax.management.loading.MLet MBeanのMBean登録権限を付与するには、プリンシパル付与weblogic.security.principal.WLSPolicyFileGroupPrincipalImplの"Administrators"および"Deployers"要素を使用します。	Oracle WebLogic Server Java APIリファレンスのWLSPolicyFileGroupPrincipalImplに関する項を参照してください。
デジタル証明書のセキュリティ制約を無効にしないようにします。	SSLを使用して通信する場合、WebLogic Serverではデフォルトで、認証局によって定義された基本制御拡張を持たない証明書チェーンのデジタル証明書を拒否します。これにより、デジタル証明書のなりすましからWebサイトを保護します。 この設定を無効にする次のオプションを含むサーバー起動コマンドがないことを確認します。 -Dweblogic.security.SSL.enforceConstraints=false ノート: ドメインに対して保護された本番モードが有効になっている場合、WebLogic Serverは、weblogic.security.SSL.enforceConstraintsシステム・プロパティの値がfalseに設定されている場合に警告をログに記録します。	『Oracle WebLogic Serverセキュリティの管理』のSSL証明書の検証に関する項を参照してください。
本番環境でデモ用のデジタル証明書を使用しないようにします。	WebLogic Serverには、開発のみの目的で、デモ用の秘密キー、デジタル証明書、および信頼性のある認証局が用意されています。WebLogic Serverをダウンロードするユーザーには、これらのデジタル証明書に対して秘密キーが付属します。デモ用のIDおよび信頼を使用しないでください。	Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項 『Oracle WebLogic Serverセキュリティの管理』の「SSLの構成」
SNMPv1およびSNMPv2プロトコルを使用しないようにします。	デフォルトでは、Simple Network Management Protocol (SNMP)はWebLogic Serverで無効になります。SNMPを有効にすると、SNMPv3プロトコルはデフォルトで有効になります。SNMPv1およびv2はクリア・テキスト・パスワードを使用するため、これらは保護されません。 SNMPv3プロトコルを使用している場合、SNMPエージェントおよびマネージャは通信を成功させるためにプロトコル・データ・ユニット(PDU)内で同一の資格証明をエンコードする必要があるため、追加のセキュリティ構成が必要になります。 ノート: SNMPv1およびSNMPv2プロトコルの使用は非推奨であり、デフォルトでは有効になっていません。構成属性でこれらの非推奨プロトコルの使用が有効になっている場合、WebLogicサーバーは起動時に非推奨の警告を記録します。	詳細と構成情報については、次のトピックを参照してください。 『SNMPによるOracle WebLogic Serverのモニタリング』のSNMPのセキュリティに関する項。 Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSNMPv3通信の保護に関する項。
SSLv2、SSLv3、TLSv1.0、TLSv1.1プロトコル・バージョンを使用しないようにします。	TLS V1.2が、WebLogic Serverで構成されているデフォルトの最小プロトコル・バージョンです。本番環境ではTLS V1.2以降を使用することをお薦めします。TLSバージョンが1.2より下位に設定されている場合、WebLogic Serverによって警告がログに記録されます。	『Oracle WebLogic Serverセキュリティの管理』のSSLプロトコル・バージョンの指定に関する項を参照してください。
JVMのプラットフォームMBeanサーバーへのリモート・アクセスを有効にしないようにします。	JDKでは、MBeanサーバー(プラットフォームMBeanサーバー)と、JVMのモニター情報を含む一連のMBeanが提供されます。WebLogic Serverの実行時MBeanサーバーを構成してプラットフォームMBeanサーバーとして実行できます。これにより、JMXクライアントは単一のMBeanサーバー接続からJVM MBeanおよびWebLogic Server MBeanにアクセス可能です。 プラットフォームMBeanサーバーへのリモート・アクセスは、標準のJDKセキュリティ機能によってのみ保護できます(http://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.htmlを参照)。WebLogic Server実行時MBeanサーバーをプラットフォームMBeanサーバーとして構成した場合、プラットフォームMBeanサーバーへのリモート・アクセスを有効にするとWebLogic Server MBeanへのアクセス・パスが作成されます。このアクセス・パスは、WebLogic Serverセキュリティ・フレームワークでは保護されません。 リモートのJMXクライアントがJVM MBeanにアクセスできるようにする必要がある場合は、WebLogic Server実行時MBeanサーバーを介してアクセスすることをお薦めします。	『Oracle WebLogic Server JMXによる管理可能アプリケーションの開発』のJVMプラットフォームMBeanサーバーでのMBeanの登録に関する項。
ホスト名検証を無効化しないようにします。	WebLogic SSLはデフォルトで、接続が確立したホストが対象のパーティまたは認可されたパーティであることを検証します。ただし、サイトでWebLogic Serverを実装するときに、ホスト名検証が無効になっている場合があります: -Dweblogic.security.SSL.ignoreHostnameVerification=true 背景情報: ネットワークに配置されたマシンによって、疑いを持たないパーティへのメッセージがキャプチャされたり、変更されたり、再送信されたりすると、介入者攻撃が発生します。接続が確立したホストが対象のパーティまたは認可されたパーティであることを検証すると、介入者攻撃を避けることができます。SSLクライアントは、SSLサーバーのデジタル証明書を使用して、SSLサーバーのホスト名を比較することで、接続を検証することができます。WebLogic Serverのホスト名検証は、介入者攻撃からSSL接続を保護します。 ノート: ドメインに対して保護された本番モードが有効になっている場合、WebLogic Serverでは、ホスト名検証が無効になっていると警告がログに記録されます。	『Oracle WebLogic Serverのセキュリティの管理』のホスト名検証の使用に関する項。 ホスト名検証が無効になっている場合に有効にする方法は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ホスト名検証の構成に関する項を参照してください。
ネットワーク・クラスローディングを有効にしないようにします。	中央ドメイン構成ファイルのnetwork-class-loading-enabled要素は、サーバーがネットワークからクラスをロードできるかどうかを制御します。デフォルトではfalseに設定されており、サーバーがリモートからクラスをロードできないようになっています。network-class-loading-enabledを有効にすると、WebLogicサーバーがリモート・コード実行の攻撃を受けやすくなります。	『Oracle WebLogic Serverドメイン構成の理解』のドメイン構成ファイルの概要に関する項。

アプリケーションの保護

WebLogicドメイン内のリソースのセキュリティ対策業務のほとんどはサーバーに関するものですが、個々のアプリケーションに対して行うセキュリティ業務もあります。

一部のセキュリティ・オプションについては、WebLogicセキュリティ・サービスを使用すると、これらの設定がサーバーまたは個々のアプリケーションのいずれの分担であるのかを判断できます。本番環境にデプロイする各アプリケーションについて、次の表の項目を確認して、そのリソースが保護されていることを確認してください。

ノート:

WebLogic Serverに含まれるHTTPパブリッシュ/サブスクライブ・サーバーには特別な保護ステップがあります。これについては、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のHTTPパブリッシュ/サブスクライブ・サーバーの使用に関する項で説明されています。

表3-11 アプリケーションの保護

セキュリティ・アクション	説明
どのデプロイメント・モデルがWebアプリケーションおよびEJBを保護しているのかを判断します。	デフォルトでは、各WebアプリケーションおよびEJBはデプロイメント記述子(XMLファイル)を使用して、保護されたリソースおよびそれにアクセスできるセキュリティ・ロールを宣言します。 WebアプリケーションおよびEJBデプロイメント記述子でセキュリティを宣言せずに、WebLogic Server管理コンソールを使用して、WebアプリケーションおよびEJBへのアクセスを保護するセキュリティ・ポリシーを設定できます。この技術により、すべてのWebアプリケーションおよびEJBに対するセキュリティを、1つの場所から集中管理できます。 これらの2つの技術を組合せ、URL (Web)またはEJBリソースの初期デプロイメントで、既存のデプロイメント記述子からセキュリティ構成をコピーするようにWebLogic Serverを構成できます。これらのセキュリティ構成をコピーした後は、WebLogic Server管理コンソールを使用して更新できます。 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のWebアプリケーションおよびEJBリソースの保護のオプションに関する項を参照してください。
リダイレクト攻撃を防止するには、FrontendHost属性をWebServerMBeanまたはClusterMBeanに設定します。	Webアプリケーションのリクエストは別の場所にリダイレクトした場合、リクエストでのホスト・ヘッダーは、デフォルトでレスポンスのロケーション・ヘッダーに使用されます。ホスト・ヘッダー は、別のホスト名または他のパラメータを含まれるように破損させる、つまりなりすます可能性があります。そのため、サード・パーティでリダイレクト拒否攻撃を起動するには、この動作は、返す機能があります。 この発生の可能性を防ぐには、WebserverMBeanまたはClusterMBeanのFrontendHost属性を設定し、リダイレクト対象のすべてのURLが送信されるホストを指定します。元のリクエストに指定したホストではなく、FrontendHost属性に指定したホストが、レスポンスのロケーション・ヘッダーに使用されます。 詳細は、Oracle WebLogic Server MBeanリファレンスのFrontendHostに関する項を参照してください。
HTMLコメント・タグではなく、JSPコメント・タグを使用します。	JSPファイル内にある、機密データを含むコメントやエンド・ユーザーを対象としていないコメントは、HTML構文の<!-- xxx -->ではなく、JSP構文の<%/* xxx */%>を使用します。JSPコメントは、HTMLコメントとは異なりJSPがコンパイルされると削除されるため、ブラウザに表示されなくなります。
本番マシンには未コンパイルのJSPおよびその他のソース・コードをインストールしないようにします。	常に、ソース・コードを本番マシンに置かないようにする必要があります。ソース・コードにアクセスすると、侵入者はセキュリティ・ホールを発見できます。 JSPをプリコンパイルし、コンパイル済のJSPのみを本番マシンにインストールすることを検討します。JSPのプリコンパイルの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のJSPのプリコンパイルに関する項を参照してください。
SSLを使用するようにアプリケーションを構成します。	web.xmlファイルのuser-data-constraint要素でtransport-guaranteeをCONFIDENTIALに適宜設定します。 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のsecurity-constrainに関する項を参照してください。
Servletサーブレットを使用しないようにします。	本番環境でのServletサーブレットの使用はお薦めしません。 かわりに、サーブレットをURIに明示的にマップします。本番環境でWebアプリケーションを使用する前に、すべてのWebアプリケーションから、WebLogicサーブレットとServletサーブレットの間の既存のマッピングをすべて削除します。 サーブレットのマッピングの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの構成に関する項を参照してください。 ノート: ドメインが保護された本番モードで実行されている場合、Webアプリケーション・コンテナは、Servletサーブレットがアプリケーションで使用されている場合に警告をログに記録します。
本番環境で、FileServletをデフォルト・サーブレットとして使用しないようにします。	本番環境でFileServletサーブレットをデフォルト・サーブレットとして使用することはお薦めしません。 デフォルト・サーブレットの設定の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のデフォルト・サーブレットの設定に関する項を参照してください。
アプリケーションのセキュリティを検査します。	アプリケーションにセキュリティの脆弱性がもたらされるおそれのある典型的な事例があります。これらの事例の多くは、OWASP (Open Web Application Security Project)(https://owasp.org/)などの第三者組織によって定義されています。 Javaではネイティブ・コードがJavaセキュリティの範囲外に位置付けられているので、特に問題となるのはJava Native Interface (JNI)を使用するコードです。Javaネイティブ・コードが逸脱した動作をしても、それを制約できるのはオペレーティング・システムだけです。つまり、Javaネイティブ・コードはWebLogic Serverでできることを何でも行えます。この脆弱性は、バッファ・オーバーフロー・エラーがネイティブ・コードでよくある問題であり、任意のコードを実行するために使用できるという事実によってさらに複雑になります。
アプリケーションに信頼性のないコードが含まれる場合は、Javaセキュリティ・マネージャを有効にします。	Javaセキュリティ・マネージャは許可を定義しJVM内で実行するクラスに強制的に付与します。多くの場合、脅威モデルでは悪意のあるコードがJVMで実行されていないため、Javaセキュリティ・マネージャは必要ありません。ただし、サード・パーティがWebLogic Serverを使用し、信頼されていないクラスが実行されている場合、Javaセキュリティ・マネージャが役立つ場合があります。 サーバー・インスタンスでJavaセキュリティ・マネージャを有効にするには、サーバーを起動するときに次のJavaオプションを使用します。 -Djava.security.manager -Djava.security.policy[=]=filename 『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaセキュリティ・マネージャを使用してWebLogicリソースを保護する方法に関する項を参照してください。 ノート: ドメインが保護された本番モードで実行されている場合、WebLogic Serverは、セキュリティ・マネージャが有効でない場合に警告をログに記録します。ただし、この警告をログに記録するかどうかは、SecureModeMBeanに含まれているWarnOnJavaSecurityManager属性を使用して指定できます。
サーブレットまたはJSPがユーザーの供給によるデータを返した場合に、HTML特殊文字を置換します。	ユーザーが入力したデータを返す機能により、クロスサイト・スクリプティングと呼ばれるセキュリティの脆弱性がもたらされます。これは、ユーザーのセキュリティ認可を盗用するために利用される可能性があります。OWASP (Open Web Application Security Project) Webサイトで次のトピックを参照してください。 Input Validation Cheat Sheet (https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html) 「Cross Site Scripting Prevention Cheat Sheet」 (https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) セキュリティの脆弱性をなくすには、ユーザーが供給したデータを返す前に、そのデータをスキャンしてHTML特殊文字を探します。該当する文字が見つかれば、それらをHTMLのエンティティまたは文字参照と置き換えます。文字を置換することで、ブラウザでユーザー入力によるデータがHTMLとして実行されることを回避します。 『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のJSPでのユーザー入力データの保護に関する項およびクライアント入力の保護に関する項を参照してください。
認証、認可、および検証済の生成元ポリシーを使用するようにWebSocketアプリケーションを構成します。	Webコンテナの標準の認証および認可機能(BASIC、FORM、CLIENT-CERT)を使用して、認可されていないクライアントがWebSocket接続を開かないようにします。 予期される接続元からのWebSocket接続のみを受け入れるようにWebSocketアプリケーションを構成することも可能です。WebSocketListener実装クラスのacceptメソッドのOrigin HTTPヘッダーを指定して、検証済の生成元ポリシーをWebSocketアプリケーションに適用します。 『Oracle WebLogic Serverアプリケーションの開発』のWebSocketアプリケーションの保護に関する項を参照してください。
wss:// URIを使用してセキュアなWebSocket接続を確立します。	WebSocketアプリケーションでは、wss:// URIを使用してセキュアなWebSocket接続を確立し、データが傍受されないようにする必要があります。wss:// URIを使用すると、クライアントがハンドシェイク・リクエストをHTTPSリクエストとして送信し、転送されるデータがTLS/SSLによって暗号化されるようになります。 『Oracle WebLogic Serverアプリケーションの開発』のWebSocketアプリケーションの保護に関する項を参照してください。