1. Oracle WebLogic Server本番環境の保護
  2. 本番環境のセキュリティの確保

3 本番環境のセキュリティの確保

WebLogic Server本番環境の包括的なロックダウンには、ホスト・マシンの保護と権限のあるユーザーのみへのアクセス制限が含まれます。また、ロックダウンには、ファイアウォールの作成、管理サーバー通信におけるドメイン全体でのセキュア・ポートの使用、およびWebLogicセキュリティ・サービスの保護も含まれます。

この章には次の項が含まれます:

SSLでのNull暗号の使用に関する重要なノート

SSLクライアントは、サーバーに接続して、SSLハンドシェイクを開始します。接続の一環として、クライアントは、サポートする暗号スイートのリストをサーバーに送信します。

暗号スイートとは、キー交換アルゴリズム、対称暗号化アルゴリズム、およびセキュア・ハッシュ・アルゴリズムを含むSSL暗号方式の一種です。通信の整合性を保護するために使用します。たとえば、RSA_WITH_RC4_128_MD5という暗号スイートは、キー交換用にRSA、バルク暗号化用に128ビット・キーを使うRC4、およびメッセージ・ダイジェスト用にMD5を使用します。

サーバーは、クライアントが提供したリストから、クライアントおよびサーバーの双方がサポートしている暗号スイートを選択し、このセッションで使用します。

ただし、不適切に構成されたクライアントが、null暗号しか含まれない一連の暗号スイートを指定する可能性があります。null暗号では、データがクリア・テキストでネットワークに渡されます。(null暗号を含む暗号スイートの例は、TLS_RSA_WITH_NULL_MD5です。)null暗号を使用した場合、ネットワーク・パケットを傍受して、SSLメッセージを見ることができます。実質的に、SSLは使用されますが、セキュリティは実現されません。

サーバーは、クライアントとサーバーが共通して持っている暗号スイートがnull暗号のみの場合に限り、null暗号を選択します。サーバーがクライアントの暗号スイート・リストからnull暗号を選択した場合、ログには、「Null暗号を使用するセッションがSSLで確立されました。」というメッセージが含まれます。

ただし、不適切に構成されたクライアントが、null暗号しか含まれない一連の暗号スイートを指定する可能性があります。

null暗号では、データがクリア・テキストでネットワークに渡されます。(null暗号を含む暗号スイートの例は、TLS_RSA_WITH_NULL_MD5です。)null暗号を使用した場合、ネットワーク・パケットを傍受して、SSLメッセージを見ることができます。実質的に、SSLは使用されますが、セキュリティは実現されません。

サーバーは、クライアントとサーバーが共通して持っている暗号スイートがnull暗号のみの場合に限り、null暗号を選択します。

サーバーがクライアントの暗号スイート・リストからnull暗号を選択した場合、ログには、「Null暗号を使用するセッションがSSLで確立されました。」というメッセージが含まれます。

このメッセージは、サーバーがクライアントのリストからnull暗号を選択した場合にのみ出力されます。

ノート:

SSLクライアントが、null暗号を使用してサーバーに不適切に接続している可能性が少しでもある場合は、ログ・ファイルを調べて、このメッセージがあるかどうかを確認してください。新しいクライアントの構成の際は、null暗号の使用に関して十分な注意を払い、必ず、適切に構成することをお薦めします。

以前にnull暗号を使用していなければ、既存のクライアントの構成で、突然null暗号の使用が開始されることはほぼありえません。ただし、無意識のうちに誤って構成された既存のクライアントの構成で、null暗号が使用されている場合があります。

null暗号とは関連のない、その他のSSLエラーも生じる可能性があります。どちらの場合も、対応するエラー・メッセージがログに表示されます。

SSLの構成の詳細は、『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。ログ・ファイルの表示の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのログの表示と構成に関する項を参照してください。

null暗号の使用を防ぐための新しいコントロール

WebLogic Server 10g リリース3 (10.3)では、サーバーによるnull暗号の使用を防ぐためのコントロールがWebLogic Server管理コンソールに導入されました。

WebLogic Server管理コンソールで「サーバー」→「ServerName」→「構成」→「SSL」→「詳細」を選択すると表示される「非暗号化Null暗号の許可」コントロールは、null暗号化を許可できるかどうかを決定します。デフォルトでは、この制御は設定されず、Null暗号の使用はサーバーで許可されません。このような構成では、SSLクライアントが(サポートされる暗号スイートとしてTLS_RSA_WITH_NULL_MD5のみを指定して)null暗号スイートの使用を求めた場合、SSLハンドシェークは失敗します。

このコントロールを設定した場合、サーバーはサポートされる暗号スイートのリストにnull暗号スイート(TLS_RSA_WITH_NULL_MD5など)を追加します。SSL接続では、クライアントが求めた場合にNull暗号スイートが使用する場合があります。Null暗号スイートが使用される合、メッセージは暗号化されません。

注意:

設定の意味とその結果を認識しない限り、本番環境ではこのコントロールを設定しないでください。

このコントロールはシステムの実行時パラメータweblogic.security.SSL.allowUnencryptedNullCipher、およびSSLMBeanのAllowUnencryptedNullCipher属性としても公開されます。

WebLogic Serverホストの保護

WebLogic Server本番環境のセキュリティは、その環境が稼働しているマシンのセキュリティと同程度でしかありません。物理マシン、オペレーティング・システム、およびホスト・マシンにインストールされているその他すべてのソフトウェアを保護することが重要です。

ノート:

FIPSモードは、RSAプロバイダを使用するJSSEでサポートされます。

JSSEでFIPSを有効にするには、次のステップに従います。

  1. クラスパスでcryptoj.jarよりも前にjarファイルcryptojFIPS.jar (WL_HOME/server/lib/cryptojFIPS.jar)を配置します。たとえば、サーバー起動スクリプト(通常はstartWebLogic.cmd/sh)のPRE_CLASSPATH変数にcryptojFIPS.jarを追加します。

  2. 『Oracle WebLogic Serverセキュリティの管理』のWebLogic ServerでのRSA JSSEプロバイダの使用に関する項の手順に従って、RSA JSSEプロバイダを有効にします。

FIPS 140-2は、重要だが非機密的な使用に関する米国連邦政府の要件が記述された標準です。

次に示すのは、本番環境のWebLogic Serverホストを保護する際の推奨事項です。マシンやオペレーティング・システムのメーカーが推奨しているセキュリティ対策も確認してください。

重要:

WebLogicドメインおよびサーバーの構成ファイルには、WebLogic Serverを構成または実行するオペレーティング・システム・ユーザーしかアクセスできないようにする必要があります。

表3-1 WebLogic Serverホストの保護

セキュリティ・アクション 説明

ハードウェアを物理的に保護します。

権限のないオペレーティング・システムのユーザーが、デプロイメント・マシンまたはそのネットワーク接続を変更できないように、ハードウェアを安全な場所に置きます。

非セキュア・サイトに移動する前に、WebLogic Server管理コンソールからログアウトします。

WebLogic Server管理コンソールにログオンしている場合は、未知のサイトや非セキュアWebサイトを表示する前に、完全にログアウトします。

オペレーティング・システムが提供するネットワーク・サービスを保護します。

悪意のある攻撃者がオペレーティング・システムにアクセスしたり、システム・レベルのコマンドを実行したりできないように、電子メール・プログラムまたはディレクトリ・サービスなどのネットワーク・サービスについて専門家に確認してもらいます。使用するオペレーティング・システムによって方法は異なります。

ファイル・システムを企業ネットワーク内の他のマシンと共有する場合、そのファイル・システムはリモート攻撃される危険性があります。WebLogic Serverをホストするマシンのファイル・システムを共有する前に、リモート・マシンとネットワークがセキュアであるかどうかを確認してください。

不正アクセスを防ぐことのできるファイル・システムを使用します。

各WebLogic Serverホスト上のファイル・システムで、保護されているリソースへの不正なアクセスができないようになっていることを確認します。たとえば、Windowsコンピュータでは、NTFSのみを使用します。

ディスクに保存されたデータにファイル・アクセス許可を設定します。

ディスクに保存されたデータへのアクセスを制限するために、オペレーティング・システムのファイル・アクセス許可を設定します。このデータには以下が含まれます(ただし、これに限定されるわけではありません):

たとえばUnix、Linuxなどのオペレーティング・システムには、ファイル・アクセス許可の設定用にumaskやchmodといったユーティリティが用意されています。少なくとも、GroupとOthersに対する読取りおよび書込み許可を拒否する「umask 066」の使用を検討します。

永続ストアに保存されたデータにファイル・アクセス許可を設定します。

永続ストアに保存されたデータへのアクセスを制限するために、オペレーティング・システムのファイル・アクセス許可を設定します。同期書込みポリシーDirect-Write-With-Cacheを使用する際には、プライマリ・ディレクトリへのユーザー・アクセスに関して独自の制限が構成されている場合は特に、キャッシュ・ディレクトリへのアクセスを制限します。永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムについては、『Oracle WebLogic Serverサーバー環境の管理』の「WebLogic永続ストアの使い方」にある永続ストアの概要に関する項を参照してください。

デフォルト永続ストアは、ドメインのルート・ディレクトリのservernameサブディレクトリにあるdata\store\defaultディレクトリに保持されます。

ホスト・マシンのユーザー・アカウント数を制限します。

WebLogic Serverホスト・マシンに必要な数を超えるユーザー・アカウントを作成するのは避け、各アカウントに付与されるファイル・アクセス権限を制限します。複数のシステム管理者ユーザーを許可するオペレーティング・システムでは、システム管理者権限を持つユーザー・アカウント2つと、WebLogic Serverの実行に十分な権限を持つユーザー1つがホスト・マシンに必要です。システム管理者ユーザーが2つあれば、常にバックアップを確保できます。WebLogic Serverのユーザーは、システム管理者ユーザーではなく制限付きユーザーであることが必要です。いずれかのシステム管理者ユーザーが、必要に応じて新しいWebLogic Serverユーザーをいつでも作成できます。

重要: WebLogicドメインおよびサーバーの構成ファイルには、WebLogic Serverを構成または実行するオペレーティング・システム・ユーザーしかアクセスできないようにする必要があります。(この表で後述するセキュリティ・アクションでは、アクセス権限を持つ2つのシステム管理者ユーザーの他に1つのユーザー・アカウントにのみWebLogicリソースへのアクセス権限を付与するように勧告していますので参照してください。)

アクティブなユーザー・アカウントを定期的に再検討します。退職者があった場合にも見直します。

背景情報: WebLogic Server構成データの一部とJava Server Pages (JSP)およびHTMLページなどのURL (Web)リソースの一部は、ファイル・システム上にクリア・テキストで保存されます。ファイルおよびディレクトリへの読込みアクセス権を持つユーザーまたは侵入者が、WebLogic Serverの認証計画および認可計画で確立するセキュリティ・メカニズムを破る可能性があります。

システム管理者のユーザー・アカウントには、わかりにくい名前を選択します。

セキュリティを強化するには、システム管理者のユーザー・アカウントに「system」、「admin」、または「administrator」などのわかりやすい名前を選択しないようにします。

パスワードを保護します。

本番マシンのユーザー・アカウントのパスワードは、推測が難しいものに設定し、注意して守る必要があります。

パスワードの有効期限が定期的に切れるように、ポリシーを設定します。

クライアント・アプリケーションでパスワードをコーディングすることは避けます。

暗号化されていないパスワードをコマンド行に含めないようにします。

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

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

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

  • WebLogic Serverのインスタンスを起動するスクリプトのために起動IDファイルを作成します。起動IDファイルは、WebLogic Serverのインスタンスの起動および停止に関するユーザーの資格証明を格納するテキスト・ファイルです。スクリプトを実行した場合、管理サーバーは、ユーザーに資格証明の提示を求めずに、このファイルを参照してユーザーの資格証明を取得できます。起動IDファイルでは資格証明が暗号化されているので、起動スクリプトまたは停止スクリプトに暗号化されていない資格証明を格納するより、起動IDファイルを使用した方が安全性は確保されます。

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

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

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

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

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

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

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

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

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

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

各ホスト・コンピュータで、(アクセス権限を持つ2つのシステム管理者ユーザーの他に)1つのユーザー・アカウントにのみWebLogicリソースへのアクセス権限を付与します。

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

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

  • Oracleホーム

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

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

    このディレクトリには、システムにインストールすることを選択したすべてのWebLogic Serverソフトウェア・コンポーネントがプログラム・ファイルも含めて格納されます。デフォルトでは、このディレクトリはOracleホームのサブディレクトリであり、wlserverという名前になります。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』のインストールおよび構成のためのディレクトリの選択に関する項を参照してください。

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

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

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

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

  • WebLogic Serverのインストール

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

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

  • JMS SAFファイル

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

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

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

JDBCストアを使用してアプリケーションを保存する場合、読込みアクセス権および書込みアクセス権からJDBCストアを守ることでデータベースを適切に保護します。

永続ストアの使用の詳細は、『Oracle WebLogic Serverサーバー環境の管理』の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)ソフトウェアを使用して、保護されているポートを保護されないポートにマップするよう、ファイアウォールを構成します。

rootとしてWebサーバーを実行しないようにします。

Unixシステム上のWebサーバー(Apache HTTP Server、Microsoft IIS、Sun Java System Web Serverなど)を実行する場合は、次のことを確認してください:

  • Webサーバーはrootとしてではなく、権限のないユーザーとしてのみ実行します。

  • Webサーバーが配置されるディレクトリ構造(すべてのファイルを含む)は、権限のないユーザーによるアクセスから保護する必要があります。

これらのステップにより、権限のないユーザーは、Webサーバーによって実行可能なコードにコードを挿入することができないことを確認できます。

本番マシンで開発しないようにします。

まず開発マシンで開発し、開発が終わりテストが終了したら、コードを本番マシンに移行します。これにより、開発環境でのバグが、本番環境のセキュリティに影響を及ぼすことを防止できます。

開発ソフトウェアまたはサンプル・ソフトウェアを本番マシンにインストールしないようにします。

本番マシンに開発ツールをインストールしません。開発ツールを本番マシンにインストールしないことにより、侵入者がWebLogic Server本番マシンに部分的にアクセスできたとしても、影響を減らすことができます。

本番マシンでWebLogic Serverのサンプル・アプリケーションを構成しないでください。インストール・プログラムがインストール・タイプの選択を求めてきたら次のようにします。

  • WebLogic Serverのインストール、CoherenceのインストールまたはFusion Middlewareインフラストラクチャを選択した場合、サンプル・アプリケーションはインストール後の構成では使用できません。

  • 完全インストールまたは例を使用したFusion Middlewareインフラストラクチャを選択した場合、サンプル・アプリケーションをインストール後の構成で使用できます。この選択は、本番マシンでは回避する必要があります。

セキュリティ監査を有効にします。

WebLogic Serverが動作するオペレーティング・システムが、ファイルおよびディレクトリ・アクセスのセキュリティ監査をサポートする場合は、監査ログを使用して、拒否されたディレクトリまたはファイル・アクセス違反をトラッキングすることを推奨します。管理者は、監査ログ用に十分なディスク・スペースを確保する必要があります。

オペレーティング・システムを保護する追加ソフトウェアの使用を検討します。

多くのオペレーティング・システムでは、本番環境を保護するために、追加ソフトウェアを実行することができます。たとえば、侵入検知システム(Intrusion Detection System: IDS)を使用すると、本番環境を変更しようとしたときに検出できます。

使用可能なソフトウェアの情報については、使用しているオペレーティング・システムのベンダーに問い合せます。

オペレーティング・システムのパッチ・セットおよびセキュリティ・パッチを適用します。

推奨されているパッチ・セットおよびセキュリティ関連のパッチのリストについては、オペレーティング・システムのベンダーに問い合せます。

使用している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およびエラー修正のサポートを維持する必要があります。

最新のパッチ・セット更新(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)を参照してください。

本番システムで使用されるJDKおよびJVMバージョンのセキュリティを維持します。

JDKおよびJVMバージョンとWebLogic Serverの組合せがOracle Fusion Middlewareサポートされているシステム構成で動作保証され、ベンダーによって現在サポートされ、最新のセキュリティ更新が適用されていることを確認します。

Oracle JDKおよびJVMのユーザーには、次のことを強くお薦めします。

本番環境ではWebLogic Serverを開発モードで実行しないようにします。

本番モードでは、本番環境にとってよりセキュアで適切な設定を使用してサーバーが実行されるように設定されます。

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

  • WebLogic Serverを開発モードで構成した場合、不正を行うアプリケーションやWebLogic Serverの無効な構成などのエラー状況により、デプロイされているトレース・スタックが発生する可能性があります。エラー・レスポンスは一般的には危険ではありませんが、悪意の目的で使用することが可能な、アプリケーションおよびWebLogic Serverインストールの情報を攻撃者に与えるおそれがあります。しかし、WebLogic Serverを本番モードで構成するとスタック・トレースが生成されないので、けっして本番環境ではWebLogic Serverを開発モードで実行しないでください。

  • 本番モードでは、Webサービス・テスト・クライアントを有効にしないことをお薦めします。Webサービスのテスト・クライアントの詳細は、『Webサービスの管理』のWebサービスのテストに関する項を参照してください。

開発モードと本番モードの詳細は、『Oracle WebLogic Serverドメイン構成の理解』の開発および本番モードに関する項を参照してください。

ドメイン内のWebLogic Serverインスタンスが本番モードで実行されるように変更する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの本番モードへの変更に関する項を参照してください。WebLogic Scripting Toolを使用して、DomainMBean.isProductionModeEnabled MBean属性をtrueに設定するという方法でも本番モードを有効化できます。

JNDIルート・コンテキストを保護します

WebLogic Server管理コンソールが外部から参照できる場合、EveryoneグループがJNDIルート・コンテキストのリソースにアクセスできてはいけません。デフォルトでは、JNDIリソースにはEveryoneのデフォルト・グループ・セキュリティ・ポリシーがあります。

WebLogic Server MBeansの「最もセキュア」値を有効にします

WebLogic Serverには、WebLogicドメインのセキュリティに影響する属性を持つ、多数のMBeansが含まれています。これらの属性のデフォルト値のすべてが最もセキュアというわけではないため、本番環境で、それらをセキュアな値に設定することをお勧めします。これらの属性の包括的なリストと、その最もセキュアな値については、『Oracle WebLogic Server MBeanリファレンス』のMBean属性のセキュアな値に関する項を参照してください。

ネットワーク接続の保護

ネットワーク接続を設計するときには、管理が容易なセキュリティ・ソリューションのニーズと、戦略上重要なWebLogicリソースを保護するためのニーズのバランスを取ります。次の表で、ネットワーク接続を保護するためのオプションを示します。

表3-2 ネットワーク接続の保護

セキュリティ・アクション 説明

ハードウェアおよびソフトウェアを使用して、ファイアウォールを作成します。

ファイアウォールとは、2つのネットワーク間のトラフィックを制限する機能のことです。ファイアウォールは、ソフトウェアとハードウェア(ルーターや専用のゲートウェイ・マシンなど)を組み合せて作成できます。ファイアウォールでは、プロトコル、リクエストされたサービス、ルーティング情報、パケット内容、および送信元や送信先のホストやネットワークに基づいて、トラフィックの通過を許可したり否認したりするフィルタが使用されます。また、認証されたユーザーのみにアクセス権を限定できます。

WebLogicセキュリティ・サービスは、サード・パーティのIDアサーション・プロバイダの使用をサポートしています。IDアサーション・プロバイダは、境界ベースの認証(Webサーバー、ファイアウォール、VPN)を実行し、複数のセキュリティ・トークン・タイプおよびプロトコル(SOAP、IIOP-CSIv2)を処理します。詳細は、『Oracle WebLogic Serverセキュリティの理解』の境界認証に関する項を参照してください。

WebLogic Serverでのファイアウォールの使用の詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタ・アーキテクチャのセキュリティ・オプションに関する項を参照してください。

WebLogic Serverの接続フィルタを使用します。

ハードウェアおよびサード・パーティのソフトウェアを使用してファイアウォールを作成するだけでなく、WebLogic Serverの接続フィルタを使用し、プロトコル、IPアドレス、およびDNSノード名に基づいてネットワーク・トラフィックを制限することを検討します。

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

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

管理トラフィックにドメイン全体の管理ポートを使用します。

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

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

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

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのドメイン全体の管理ポートの構成に関する項および構成監査の有効化に関する項を参照してください。

組込みLDAPポートを保護します。

総当たり攻撃から組込みLDAPポートを保護するには、接続フィルタを使用して、単一のサーバー構成で組込みLDAPリスニング・ポートを閉じます。

この場合、複数サーバー構成における組込みLDAPポートは保護されませんが、デフォルトの接続フィルタ実装ではソースのIPアドレスに基づいたフィルタ処理がサポートされていますので、これを使用してドメインを構成するサーバーからのアクセスのみを許可してください。その結果、ドメイン内のマシンのみがLDAPポートにアクセスできるようになります。接続フィルタの使用の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のネットワーク接続フィルタの使用に関する項を参照してください。

JVMのプラットフォームMBeanサーバーへのリモート・アクセスを有効にしないようにします。

JDK 1.5以降では、MBeanサーバー(プラットフォームMBeanサーバー)と、JVMのモニター情報を含む一連のMBeanが提供されます。WebLogic Serverの実行時MBeanサーバーを構成してプラットフォームMBeanサーバーとして実行できます。これにより、JMXクライアントは単一のMBeanサーバー接続からJVM MBeanおよびWebLogic Server MBeanにアクセス可能です。

プラットフォームMBeanサーバーへのリモート・アクセスは、標準のJDKセキュリティ機能によってのみ保護できます(http://docs.oracle.com/javase/7/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の登録を参照してください。

アプリケーションによるRMIを介したJDBCの使用を制限します。

RMIを介したJDBCアプリケーション・コールはセキュアではなく、データベースへの無制限のアクセスが許可される可能性があります。RMIのJDBCセキュリティを構成して、RMIを介したJDBCアプリケーション・コールを無効にすることをお薦めします。そのように行うには:

  • DataSourceMBeanのRmiJDBCSecurity属性をsecureに設定します。

  • WebLogic Server管理コンソールの「構成」→「一般」ページで、サーバーのSSLリスニング・ポート設定が有効なことを確認します。

ただし、RMIのJDBCセキュリティでは、サーバーにわたるロギング・ラスト・リソース、1フェーズ・コミットおよび2フェーズ・コミットのエミュレートのデータ・ソース・トランザクション参加者は無効化されません。

JTA通信のクロス・ドメイン・セキュリティを構成します。

通信チャネルは、悪質なサード・パーティがトランザクションの結果に影響を与える中間者攻撃を使用できず、1つ以上のドメイン間で管理制御を取得できないようにセキュアにしておく必要があります。ドメイン間のセキュアな通信チャネルを確保するために、WebLogic Serverでは、「クロス・ドメイン・セキュリティ」というドメイン信頼がサポートされています。クロス・ドメイン・セキュリティでは2つのドメイン間(ドメイン・ペア)の信頼関係が確立されて、一方のWebLogic Serverドメインのサブジェクト内のプリンシパルが、もう一方のドメイン内で呼出しを実行できるようになります。WebLogic Serverは、クロス・ドメイン・ユーザーのセキュリティ・ロールを確立し、各ドメインのWebLogic資格証明マッピング・セキュリティ・プロバイダを使用してクロス・ドメイン・ユーザーが使用する資格証明を格納します。

詳細および詳しい構成は、次を参照してください。

SNMPを有効にしている場合は、SNMPv3プロトコルを構成し、使用してください。

デフォルトでは、Simple Network Management Protocol (SNMP)はWebLogic Serverで無効になります。ただし、SNMPを有効にすると、SNMPv1プロトコルとSNMPv2プロトコルが有効になります。SNMPv1とSNMPv2はセキュリティで保護されておらず、SNMPサービス上で不正アクセスやサービス拒否攻撃などのセキュリティ問題が発生する原因となる可能性があります。

SNMPv1プロトコルとSNMPv2プロトコルを無効にし、かわりにSNMPv3プロトコルを使用することを強くお薦めします。 SNMPv3プロトコルを使用している場合、SNMPエージェントおよびマネージャは通信を成功させるためにプロトコル・データ・ユニット(PDU)内で同一の資格証明をエンコードする必要があるため、追加のセキュリティ構成が必要になります。SNMPv3を使用できない場合は、ネットワークが保護され、WebLogic Server環境のポートへのアクセスを制限するようにファイアウォールが構成されていることを確認することで、SNMPv1とSNMPv2のセキュリティの脆弱性の問題を限定する必要があります。

詳細は、『SNMPによるOracle WebLogic Server 12.1.3のモニタリング』の次のトピックを参照してください。

完了メッセージ・タイムアウトの構成設定がシステムに適していることを確認します。

サービス拒否(DoS)攻撃の可能性を軽減するため、完了メッセージ・タイムアウト・パラメータの構成がシステムに適していることを確認してください。このパラメータを使用すると、サーバーが完了メッセージを受信するまでに待機する最大秒数を設定できます。

デフォルト値は60秒で、デフォルト・ネットワーク・チャネルのすべての接続プロトコルに適用されます。サーバーに待機時間の長いクライアントが多くある場合、この設定が適切である場合があります。ただし、システムの可用性を侵害することなく、この設定を可能なかぎり小さな値にする必要があります。

特定のプロトコルのために完了メッセージ・タイムアウトを指定する必要がある場合、かわりに、そのプロトコルに対して新しいネットワーク・チャネルを構成できます。

完了メッセージ・タイムアウト・パラメータを指定できる「WebLogic Server管理コンソール」ページの表示の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのプロトコルの構成に関する項を参照してください。

UNIXシステムでは、ファイル記述子の数をシステムに適した値に設定します。

UNIXシステムでは、WebLogic Serverへの各ソケット接続がファイル記述子を消費します。可用性を最適化するには、ホスト・マシン上のWebLogic Serverのファイル記述子数が適切である必要があります。デフォルトでは、WebLogic Serverには、1024個ファイル記述子数が構成されています。ただし、特に本番システムでは、この値は小さく設定される場合があります。

WebLogic Serverのファイル記述子数をチューニングする場合、ファイル記述子に行った変更は「完了メッセージ・タイムアウト」パラメータに行った変更とバランスが取れている必要があります。「完了メッセージ・タイムアウト」パラメータの値が大きい場合、メッセージ・タイムアウトが発生するまでソケットが閉じられません。これにより、ファイル記述子の保留時間が長くなります。したがって、「完了メッセージ・タイムアウト」パラメータの値が大きい場合、ファイル記述子数の制限も大きく設定する必要があります。このようにバランスを取ると、システムの可用性が最適化され、DoS攻撃の可能性も軽減されます。

使用可能なファイル記述子の数のチューニングの詳細は、UNIXベンダーのドキュメントを参照してください。

Javaセキュリティ・マネージャを使用してMLet MBeansへのアクセスを制御します。

MLet MBeansにより、クライアント・ユーザーはMBean実装をアップロードして、WebLogic Serverでその実装を実行できます。認証されたユーザーはインスタンス化と起動を実行できるため、デフォルトではJMX MBeanのManagementAppletCreateEnabled属性を使用して、WebLogic ServerによりMLet MBeansの使用が無効化されます。WebLogic Serverでは、MLet MBeansの使用を有効化することは推奨されません。

それでもMLet MBeansを有効化する場合は、Javaセキュリティ・マネージャとともに実行して認可されたユーザーのみがMLet MBeansにアクセスできるようにし、権限を使用してMLet MBeansへのアクセスを制限してください。管理者ロールまたはデプロイヤ・ロールを持つ認可されたユーザーに、javax.management.loading.MLet MBeanのMBean登録権限を付与するには、プリンシパル付与weblogic.security.principal.WLSPolicyFileGroupPrincipalImplの"Administrators"および"Deployers"要素を使用します。

受信シリアライゼーション・データを制限します。

Javaのシリアライズは便利な機能ですが、シリアライズされたJavaオブジェクトを使用して、デシリアライズ中にサービス拒否(DoS)またはリモート・コード実行(RCE)攻撃を引き起こす悪意のあるコードが挿入される可能性もあります。 WebLogic Serverは、JDK JEP 290メカニズムを使用して受信したシリアライズJavaオブジェクトをフィルタして、これらの悪意のある攻撃から保護します。

ノート:

WebLogic Serverパッチ・セット更新(PSU)で提供されているデシリアライズの脆弱性に対する特定のWebLogic Server修正はJEP 290フィルタリングおよびJEP 290グローバル・スコープ・フィルタリング機能に依存します。JEP 290グローバル・スコープ・フィルタリングをサポートし、WebLogic Serverで動作保証され、Oracleによって引き続きサポートされているJDKバージョンでWebLogic Serverを実行することを強くお薦めします。このWebLogic Serverリリースでは、少なくとも次のJDK更新レベルを使用することを強くお薦めします:

  • JDK 8 Update 181 (JDK 8u181)以降

  • JDK 7 Update 191 (JDK 7u191)以降

JEP 290グローバル・スコープ・フィルタリングをサポートしないJDKを使用している場合、WebLogic Serverは実行を継続し、既知のデシリアライズ攻撃に対する保護を提供しますが、JEP 290のより高度な機能の保護はありません。

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

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

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

WebLogic Serverデフォルト・フィルタの設定は、時間の経過に伴い変化することがあります。 最新のデフォルト・フィルタ設定およびフィルタのカスタマイズに使用できるシステム・プロパティのリストは、My Oracle Supportのドキュメント受信したシリアライズJavaオブジェクトのOracle WebLogic Serverへの制限(ドキュメントID 2421487.1).を参照してください  My Oracle Supportにはhttps://support.oracle.com/からアクセスできます。

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

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

データベースの保護

多くのWebアプリケーションでは、データの格納にデータベースが使用されます。WebLogic Serverで使用されるデータベースとしては、Oracle、Microsoft SQL Server、およびInformixが一般的です。 

これらのデータベースには、顧客リスト、顧客の連絡先情報、クレジット・カード情報、およびその他の顧客データなど、Webアプリケーションの重要なデータが保存されることがよくあります。Webアプリケーションを作成するときは、どのデータをデータベースに保存し、そのデータを作成するためにどのようなセキュリティが必要なのかを考慮する必要があります。また、データベース・メーカーが提供するセキュリティ・メカニズムを理解し、それがセキュリティ・ニーズを満たすうえで十分かどうかを判断する必要があります。提供されたセキュリティ・メカニズムで不十分な場合は、重要なデータをデータベースに書き込む前に暗号化するなど、その他のセキュリティ技術を使用して、データベースのセキュリティを改善することができます。たとえば、クレジット・カード情報は暗号化し、それ以外のすべての顧客データはプレーン・テキスト形式でデータベースに保存します。

WebLogicセキュリティ・サービスの保護

WebLogicセキュリティ・サービスには、多彩で柔軟なソフトウェア・ツールがあり、サーバー・インスタンスで実行するサブシステムおよびアプリケーションの保護に使用できます。次の表は、使用している本番環境を保護するために推奨される基本機能のチェックリストです。

表3-3 WebLogicセキュリティ・サービスの保護

セキュリティ・アクション 説明

本番対応のセキュリティ・プロバイダをセキュリティ・レルムにデプロイします。

WebLogicセキュリティ・サービスでは、複数のセキュリティ・プロバイダをデプロイでき、各プロバイダでは特定のセキュリティ分野に対応するプラガブルなアーキテクチャが使用されます。

WebLogic Serverには、デフォルトで完全なセキュリティ・ソリューションを提供する独自のセキュリティ・プロバイダがあります。ユーザー独自のセキュリティ・プロバイダを購入、または記述した場合は:

  • 正しくデプロイおよび構成していることを確認します。WebLogic Server管理コンソールに現在デプロイされているセキュリティ・プロバイダを確認できます。管理コンソールの左ペインで「セキュリティ・レルム」を選択後、レルムの名前をクリックして「プロバイダ」タブを選択します。

  • セキュリティ・プロバイダをデプロイしたレルムがデフォルトの(アクティブな)レルムであることを確認します。WebLogic Server管理コンソールでデフォルト・セキュリティ・レルムを設定する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルト・セキュリティ・レルムの変更に関する項を参照してください。

  • 『Oracle WebLogic Serverセキュリティの管理』のデフォルト・セキュリティ構成のカスタマイズに関する項を参照してください。

本番環境ではSSLを使用し、デモ用のデジタル証明書を使用しないようにします。

重要なデータを危険にさらさないためには、HTTPSを使用してデータ転送を保護します。

WebLogic Serverには、開発のみの目的で、デモ用の秘密キー、デジタル証明書、および信頼性のある認証局が用意されています。WebLogic Serverをダウンロードするユーザーには、これらのデジタル証明書に対して秘密キーが付属します。デモ用のIDおよび信頼を使用しないでください。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項、および『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。

WebLogic Serverで、デジタル証明書にセキュリティ制約が設定されていることを確認します。

SSLを使用して通信する場合、WebLogic Serverではデフォルトで、認証局によって定義された基本制御拡張を持たない証明書チェーンのデジタル証明書を拒否します。これにより、デジタル証明書のなりすましからWebサイトを保護します。

この設定を無効にする次のオプションを含むサーバー起動コマンドがないことを確認します。

-Dweblogic.security.SSL.enforceConstraints=false

このオプションの詳細は、『Oracle WebLogic Serverセキュリティの管理』のSSL証明書の検証に関する項を参照してください。

開発環境では、7.0サービス・パック2以前のリリースでWebLogic Serverが提供したデモ用のデジタル証明書との非互換性に対処するために、セキュリティ制約の設定を無効にしている可能性があります。この機能が本番環境で有効になっていることを確認します。

介入者攻撃を避けるために、ホスト名検証が有効になっていることを確認します。

WebLogic SSLはデフォルトで、接続が確立したホストが対象のパーティまたは認可されたパーティであることを検証します。ただし、サイトでWebLogic Serverを実装するときに、ホスト名検証が無効になっている場合があります。

ホスト名検証を有効にするには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのカスタム・ホスト名検証の構成に関する項を参照してください。

『Oracle WebLogic Serverセキュリティの管理』のホスト名検証の使用に関する項を参照してください。

背景情報: ネットワークに配置されたマシンによって、疑いを持たないパーティへのメッセージがキャプチャされたり、変更されたり、再送信されたりすると、介入者攻撃が発生します。接続が確立したホストが対象のパーティまたは認可されたパーティであることを検証すると、介入者攻撃を避けることができます。SSLクライアントは、SSLサーバーのデジタル証明書を使用して、SSLサーバーのホスト名を比較することで、接続を検証することができます。WebLogic Serverのホスト名検証は、介入者攻撃からSSL接続を保護します。

サービス拒否攻撃を防ぐために、外部チャネルに対してリクエストのサイズおよび時間を制限します。

サービス拒否(DoS)攻撃を防ぐために、WebLogic Serverではメッセージのサイズ、およびメッセージの到着にかかる最大時間を制限できます。デフォルトの設定では、メッセージのサイズは10MB、完了メッセージのタイムアウトは480秒です。次のことをお薦めします。

  • 管理対象サーバーが管理サーバーからのメッセージを受信できるように内部チャネルに対しリクエストのサイズを制限します。

  • 外部チャネルに対してリクエストのサイズおよび時間を制限します。

  • 外部からではなく、内部からのメッセージのみを受信できるように内部チャネルを構成します。

  • 外部チャネルを構成し、外部クライアントにより使用されるプロトコルのみをサポートするようにして攻撃面を縮小します。ほとんどの場合、サポートされるプロトコルはHTTPおよびHTTPSです。また、ファイアウォールの外部で使用可能なチャネルのトンネリングを有効にすることはお薦めしません。

これらの設定をHTTP、T3およびIIOPプロトコルに対して構成するには、Oracle WebLogic Server管理コンソール・オンライン・ヘルプで次のタスクを参照してください。

『Oracle WebLogic Serverのパフォーマンスのチューニング』のサービス拒否攻撃の可能性の軽減に関する項も参照してください。

背景情報: DoS攻撃を受けると、Webサイトは動作するが使用できない状態になります。ハッカーは、Webサイトの1つ以上の重要なリソースを枯渇させたり、削除したりします。

侵入者がWebLogic Serverインスタンスに対してDoS攻撃を実行する場合、サイズが非常に大きいリクエスト、完了までに時間がかかるリクエスト、完了しないリクエストを多数使用してサーバーを攻撃するため、リクエストが完了する前にクライアントからのデータの送信が停止します。

DoS攻撃を防ぐために、サーバーで許可されるソケット数を設定します。

DoS攻撃を防ぐためには、プロセス全体で許可されるソケット数よりも少なくなるように、サーバーで許可されるソケット数を制限します。これにより、オペレーティング・システムの制限で許可されるファイルの記述子の数を超えないようにすることができます。

サーバーの制限を超えたとしても、管理者は管理ポートを介してサーバーにアクセスできます。

MaxOpenSockCountフラグを使用してこの設定の構成が可能です。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 構成: チューニング」を参照してください。

過負荷状態を回避するために、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のユーザー・ロックアウトおよびログイン設定により、辞書攻撃および総当たり攻撃からユーザー・アカウントを保護することができます。

複数の認証プロバイダを使用する場合は、JAAS制御フラグを適切に設定します。

セキュリティ・レルムに複数の認証プロバイダが構成されている場合、JAAS制御フラグを設定して、各プロバイダの順序および優先度を構成します。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJAAS制御フラグの設定に関する項を参照してください。

セキュリティ監査を有効にします。

監査は、主要なセキュリティ・イベントをWebLogic Server環境に記録する処理です。WebLogicセキュリティ・サービスが提供する監査プロバイダを有効にすると、イベントがDomainName\DefaultAuditRecorder.logに記録されます。

監査プロバイダは、WebLogic Server管理コンソールの「セキュリティ・レルム」→「レルム名」→「プロバイダ」→「監査」ページで有効にします。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの監査プロバイダの構成に関する項を参照してください。

ノート: 監査プロバイダを使用すると、少数のイベントのみが記録される場合でも、WebLogic Serverのパフォーマンスが低下する場合があります。

監査レコードを定期的に確認し、セキュリティ違反または違反未遂を検出します。度重なるログインの失敗や、予期しないパターンのセキュリティ・イベントに注目することで、重要な問題を防げる可能性があります。

独自のカスタム監査プロバイダを開発して、プロバイダのMBeanから監査イベントをポストする場合の詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のベスト・プラクティス: プロバイダのMBeanからの監査イベントのポストを参照してください。

デフォルトのWebLogic Serverセキュリティ・ロールにユーザーおよびグループを正しく割り当てたことを確認します。

デフォルトでは、すべてのWebLogicリソースは、セキュリティ・ロールのデフォルト・セットに基づくセキュリティ・ポリシーによって保護されています。

目的のユーザーおよびグループをこれらのデフォルト・セキュリティ・ロールに割り当てます。

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

システム管理者権限を持つ、少なくとも2つのユーザー・アカウントを作成します。

システム管理者ユーザーのうち1つは、ドメインの作成時に作成する必要があります。他のユーザー(複数可)を作成し、これらをAdminセキュリティ・ロールに割り当てます。システム管理者ユーザーを作成したら、それらに対して容易に推測できない一意の名前を付与します。

少なくとも2つのシステム管理者のユーザー・アカウントがあれば、1つのユーザーが辞書攻撃や総当り攻撃でロックアウトになった場合でも、もう1つのユーザーでアカウント・アクセスを保持できます。

アプリケーションの保護

WebLogic Serverドメイン内のWebLogicリソースのセキュリティ対策業務のほとんどはサーバーに関するものですが、個々のアプリケーションに対して行うセキュリティ業務もあります。一部のセキュリティ・オプションについては、WebLogicセキュリティ・サービスを使用すると、サーバーまたは個々のアプリケーションのいずれの分担であるのかを判断できます。本番環境にデプロイする各アプリケーションについて、次の表の項目を確認して、そのリソースが保護されていることを確認してください。

ノート:

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

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

セキュリティ・アクション 説明

どのデプロイメント・モデルが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アプリケーションのリクエストは別の場所にリダイレクトした場合、リクエストでのホスト・ヘッダーは、デフォルトでレスポンスのロケーション・ヘッダーに使用されます。ホスト・ヘッダー は、別のホスト名または他のパラメータを含まれるように破損させる、つまりなりすます可能性があります。そのため、サード・パーティでリダイレクト拒否攻撃を起動するには、この動作は、返す機能があります。

リダイレクト対象のすべてのURLが送られるホストを指定するには、WebserverMBeanまたはClusterMBeanにFrontendHost属性をこの発生の可能性が回避するように設定します。元のリクエストに指定したホストではなく、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-constraintに関する項を参照してください。

Servletサーブレットを使用しないようにします。

本番環境でのServletサーブレットの使用はお薦めしません。

かわりに、サーブレットをURIに明示的にマップします。本番環境でWebアプリケーションを使用する前に、すべてのWebアプリケーションから、WebLogicサーブレットとServletサーブレットの間の既存のマッピングをすべて削除します。

サーブレットのマッピングの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの構成に関する項を参照してください。

本番環境で、FileServletをデフォルト・サーブレットとして使用しないようにします。

本番環境でFileServletサーブレットをデフォルト・サーブレットとして使用することはお薦めしません。

デフォルト・サーブレットの設定の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のデフォルト・サーブレットの設定に関する項を参照してください。

すべてのWebLogicセキュリティ・ポリシーを確認します。

WebLogic Server 7.0では、ACLにかわってセキュリティ・ポリシーが使用され、WebLogicリソースに誰がアクセスしたのかを判断します。

WebLogicリソースからセキュリティ・ポリシーを削除していないこと、およびセキュリティ・ロールの割当てによってユーザーに目的のアクセス権を提供していることを確認します。

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

アプリケーションのセキュリティを検査します。

アプリケーションにセキュリティの脆弱性がもたらされるおそれのある典型的な事例があります。これらの事例の多くは、OWASP (Open Web Application Security Project)(https://www.owasp.org/)などの第三者組織によって定義されています。

Javaではネイティブ・コードがJavaセキュリティの範囲外に位置付けられているので、特に問題となるのはJavaネイティブ・インタフェース(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リソースを保護する方法に関する項を参照してください。

サーブレットまたはJSPがユーザーの供給によるデータを返した場合に、HTML特殊文字を置換します。
ユーザーが入力したデータを返す機能により、クロスサイト・スクリプティングと呼ばれるセキュリティの脆弱性がもたらされます。これは、ユーザーのセキュリティ認可を盗用するために利用される可能性があります。OWASP (Open Web Application Security Project) Webサイトで次のトピックを参照してください。

セキュリティの脆弱性をなくすには、ユーザーが供給したデータを返す前に、そのデータをスキャンしてHTML特殊文字を探します。該当する文字が見つかれば、それらをHTMLのエンティティまたは文字参照と置き換えます。文字を置換することで、ブラウザでユーザー入力によるデータがHTMLとして実行されることを回避します。

『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のJSPでのユーザー入力データの保護に関する項およびクライアント入力の保護に関する項を参照してください。

JMSリソースに対してセキュリティ・チェックが行われていることを確認します。

weblogic.jms.securityCheckInterval属性を0に設定して、認可チェックがJMSリソースのすべてのSend、Receive、およびgetEnumerationアクションに対して行われていることを確認します。

認証、認可、および検証済の生成元ポリシーを使用するように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アプリケーションの保護に関する項を参照してください。