| Oracle® Fusion Middleware Oracle WebLogic Server プロダクション環境の保護 11g リリース 1 (10.3.1) B55514-01 |
|
 戻る |
Oracle では、使用しているプロダクション環境のセキュリティを確保するために、次のアクションを実装することをお勧めします。
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 暗号を選択した場合、ログには、「SSL has established a session that uses a Null cipher.」というメッセージが含まれます。
このメッセージは、サーバがクライアントのリストから null 暗号を選択した場合にのみ出力されます。
|
注意 : SSL クライアントが、null 暗号を使用してサーバに不適切に接続している可能性が少しでもある場合は、ログ ファイルを調べて、このメッセージがあるかどうかを確認してください。新しいクライアントのコンフィグレーションの際は、null 暗号の使用に関して十分な注意を払い、必ず、適切にコンフィグレーションすることをお勧めします。以前に null 暗号を使用していなければ、既存のクライアントのコンフィグレーションで、突然 null 暗号の使用が開始されることはありません。ただし、無意識のうちに誤ってコンフィグレーションされた既存のクライアントのコンフィグレーションで、null 暗号が使用されている場合があります。 |
null 暗号とは関連のない、その他の SSL エラーも生じる可能性があります。どちらの場合も、対応するエラー メッセージがログに表示されます。
SSL のコンフィグレーションの詳細については、『Oracle Fusion Middleware Securing Oracle WebLogic Server』の「SSL のコンフィグレーション」を参照してください。ログ ファイルの表示の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「ログの表示とコンフィグレーション」を参照してください。
Weblogic Ｓerver 10g リリース 3 (10.3) では、サーバによる null 暗号の使用を防ぐためのコントロールが Administration Console に導入されました。
WebLogic Server Administration Console ServerName ｜Configuration ｜SSL｜Advanced page で使用できる Allow Unencrypted Null Cipher control は、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 ホストの保護についてのヒントを次に示します。また、マシンおよびオペレーティング システムのメーカーに、適切なセキュリティ対策について確認してください。
|
注意 : サーバの SSL 実装で FIPS 準拠の (FIPS 140-2) 暗号モジュールを使用するように WebLogic Server インスタンスを設定するには、サーバの起動スクリプト (startWebLogic.cmd/sh など) に以下を含めます。
FIPS 140-2 は、重要だが非機密的な使用に関する米国連邦政府の要件が記述された標準です。 |
表 3-1 WebLogic Server ホストのセキュリティ
| セキュリティ アクション | 説明 |
|---|---|
|
ハードウェアを物理的に保護する |
権限のないオペレーティング システムのユーザが、デプロイメント マシンまたはそのネットワーク接続を変更できないように、ハードウェアを安全な場所に置く。 |
|
非セキュアサイトを移動する前に、Administration Console からログアウトする |
WebLogic Server Administration console にログオンしている場合は、未知のサイトや非セキュア Web サイトを表示する前に、完全にログアウトする。 |
|
オペレーティング システムが提供するネットワーク サービスを保護する |
悪意のある攻撃者がオペレーティング システムにアクセスしたり、システム レベルのコマンドを実行したりできないように、電子メール プログラムまたはディレクトリ サービスなどのネットワーク サービスについて専門家に確認してもらう。使用するオペレーティング システムによって方法は異なる。 ファイル システムを企業ネットワーク内の他のマシンと共有する場合、そのファイル システムはリモート攻撃される危険性がある。WebLogic Server をホストするマシンのファイル システムを共有する前に、リモート マシンとネットワークがセキュアであるかどうかを確認すること。 |
|
不正アクセスを防ぐことのできるファイル システムを使用する |
各 WebLogic Server ホスト上のファイル システムで、保護されているリソースへの不正なアクセスができないようになっていることを確認する。たとえば、Windows コンピュータでは、NTFS のみを使用する。 |
|
ディスクに保存されたデータにファイル アクセス パーミッションを設定する |
ディスクに保存されたデータへのアクセスを制限するために、オペレーティング システムのファイル アクセス パーミッションを設定する。このデータには以下が含まれる (ただしこれに限るものではない)。
たとえば Unix、Linux などのオペレーティング システムには、ファイル アクセス パーミッションの設定用に umask や chmod といったユーティリティが用意されている。少なくとも、Group と Others に対する読み取りおよび書き込みパーミッションを拒否する「umask 066」の使用を検討する。 |
|
永続ストアに保存されたデータにファイル アクセス パーミッションを設定する |
デフォルト永続ストアは、ドメインのルート ディレクトリの servername サブディレクトリにある |
|
ホスト マシンのユーザ アカウント数を制限する |
WebLogic Server ホストで必要とされる数を超えるユーザ アカウントを作成しないようにして、各アカウントに付与されるファイル アクセス特権を制限する。ホスト マシンでは、複数のシステム管理者ユーザを許可するオペレーティング システムでシステム管理者特権を持つ 2 つのユーザ アカウントがあり、WebLogic Server を実行する特権を持つ別のユーザがあることが理想的。2 つのシステム管理者ユーザがあればバックアップが常に提供される。WebLogic Server のユーザは、システム管理者ユーザではなく制限されたユーザであること。システム管理者ユーザの 1 つが、必要に応じて新しい WebLogic Server ユーザを常に作成できる。 アクティブなユーザ アカウントを定期的に再検討する。退職者があった場合にも見直す。 予備知識 : WebLogic Server コンフィグレーション データの一部と Java Server Pages (JSP) および HTML ページなどの URL (Web) リソースの一部は、ファイル システム上にクリア テキストで保存される。ファイルおよびディレクトリへの読み込みアクセス権を持つユーザまたは侵入者が、WebLogic Server の認証計画および認可計画で確立するセキュリティ メカニズムを破る可能性がある。 |
|
システム管理者のユーザ アカウントの場合、分かりにくい名前を選択する |
セキュリティを強化するには、システム管理者のユーザ アカウントに「system」、「admin」、または「administrator」などの分かりやすい名前を選択しないようにする。 |
|
パスワードを保護する |
プロダクション マシンのユーザ アカウントのパスワードは、推測が難しいものに設定し、注意して守る必要がある。 パスワードの有効期限が定期的に切れるように、ポリシーを設定する。 クライアント アプリケーションでパスワードをコーディングすることは避ける。 注意 : ユーザ名 |
|
コマンドラインで暗号化されていないパスワードを含まない |
スクリプトでのWLST および コマンド ウィンドウまたはスクリプトで、暗号化されていないパスワードが必要であるコマンドを入力するとき、パスワードは安全に入力されていることを確認するには、以下の注意事項を考慮してください。
ユーザ資格をスクリプトに安全に渡すことに関する詳細情報については、以下のトピックを参照してください。
|
|
各ホスト コンピュータでは、アクセス特権を持つ 2 つのシステム管理者ユーザのほかに、1 つのユーザ アカウントにのみ WebLogic リソースへのアクセス権を付与する |
各 WebLogic Server ホスト コンピュータでは、オペレーティング システムを使用して、WebLogic Server の実行用に特別なユーザ アカウント ( このオペレーティング システム (OS) のユーザ アカウントには、以下の特権を付与する。
知識の豊富なオペレーティング システムのユーザが、以下のファイルに対して書き込みアクセス権 (場合によっては読み込みアクセス権) を付与されている場合、WebLogic Server のセキュリティを無視することができる。
永続ストアを使用するすべてのファイル (JMS SAF ファイルなど) には、読み込みアクセス権と書き込みアクセス権から保護する必要のある重要なデータがある。永続ストアは、ファイルベースのストアまたは JDBC 対応データベースの永続性をサポートする。 ファイル ストアを使用して WebLogic Server でファイルを保存する場合、アプリケーションを任意の場所に保存できる。読み込みアクセス権および書き込みアクセス権からアプリケーションを保護するには、すべてのファイルの場所を覚えておく必要がある。 JDBC ストアを使用してアプリケーションを保存する場合、読み込みアクセス権および書き込みアクセス権から JDBC ストアを守ることでデータベースを適切に保護する。 永続ストアの使い方については、『Oracle Fusion Middleware Oracle WebLogic Server のサーバ環境設定』の「WebLogic 永続ストアの使い方」を参照してください。 |
|
新しい WebLogic ドメインをコンフィグレーション直後、パスワード検証プロバイダのコンフィグレーションをします。 |
WebLogic Serverに含まれているパスワード検証プロバイダによって、パスワード構成ルールを実施と管理するために、複数の用意されている認証プロバイダでコンフィグレーションができます。そのため、セキュリティ レルムでパスワードを作成または更新された場合は、パスワードは確立された構成要件を満たしていることを確認するために、対応する認証プロバイダによって、パスワード検証プロバイダが自動的に呼び出されます。 パスワード検証プロバイダをコンフィグレーションする方法および使用方法については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「パスワード検証プロバイダのコンフィグレーション」を参照してください。 |
|
UNIX 上で保護されているポートにバインドするには、ユーザ ID を切り替える、またはネットワーク アドレス変換 (NAT) ソフトウェアを使用するよう、WebLogic Server をコンフィグレーションする |
UNIX システムでは、特権を持つユーザ アカウント (ほとんどの場合、root) で実行されるプロセスのみを、1024 より小さいポートにバインドできる。UNIX システムでは、システム管理者 (root) ユーザのみが許可される。 ただし、WebLogic Server のような長期にわたって実行されるプロセスは、これらの特権を付与されたアカウント下で実行してはならない。その代わり、以下の処理のいずれかを行うことができる。
|
|
Web サーバを |
Apache HTTP サーバ、Microsoft IIS または Sun Java System Web Server などの Unix システムでは Web サーバを実行するとき、以下を確認してください。
これらの手順により、Web サーバによって実行可能なコードに非特権ユーザはコードを挿入することができないことを確認できます。 |
|
プロダクション マシンで開発しない |
まず開発マシンで開発し、開発が終わりテストが終了したら、コードをプロダクション マシンに移行する。これにより、開発環境でのバグが、プロダクション環境のセキュリティに影響を及ぼすことを防止できる。 |
|
開発ソフトウェアまたはサンプル ソフトウェアをプロダクション マシンにインストールしない |
プロダクション マシンに開発ツールをインストールしない。開発ツールをプロダクション マシンにインストールしないことにより、侵入者が WebLogic Server プロダクション マシンに部分的にアクセスできたとしても、影響を減らすことができる。 プロダクション マシンに、WebLogic Server のサンプル アプリケーションをインストールしない。インストール プログラム上で、標準インストールにするかカスタム インストールにするかを尋ねられた場合は、以下の操作を実行する。次の点に注意してください。
インストール プログラムの残りのページの操作を完了する。 |
|
セキュリティ監査を有効にする |
WebLogic Server が動作するオペレーティング システムが、ファイルおよびディレクトリ アクセスのセキュリティ監査をサポートする場合は、監査ログを使用して、拒否されたディレクトリまたはファイル アクセス違反をトラッキングすることを推奨する。管理者は、監査ログ用に十分なディスク スペースを確保する必要がある。 |
|
オペレーティング システムを保護する追加ソフトウェアの使用を検討する |
多くのオペレーティング システムでは、プロダクション環境を保護するために、追加ソフトウェアを実行することができる。たとえば、侵入検知システム (Intrusion Detection System: IDS) を使用すると、プロダクション環境を変更しようとしたときに検出できる。 使用可能なソフトウェアの情報については、使用しているオペレーティング システムのベンダに問い合わせる。 |
|
オペレーティング システムのサービス パックおよびセキュリティ パッチを適用する |
推奨されているサービス パックおよびセキュリティ関連のパッチのリストについては、オペレーティング システムのベンダに問い合わせる。 |
|
最新のメンテナンス パックおよび重大なパッチ更新を適用します。 |
サイトのセキュリティ問題の担当者は、WebLogic Server のインストールを My Oracle Support に登録してください。「 「 WebLogic Server 10g リリース 3 ( 10.3 )または以前のリリースのインストールがある場合、「 また、リリースされている各サービス パックの適用もお勧めします。メンテナンス パックには、製品の各バージョンおよび以前にリリースされた各メンテナンス パックのすべてのバグの修正が含まれています。メンテナンス パックのインストールについては、『Oracle Smart Update パッチおよびメンテナンスパックのインストール』の「メンテナンス パックのダウンロードとインストール」を参照してください。 セキュリティ問題を報告するために、以下のいずれかを実行する。
|
|
プロダクション環境では開発モードで WebLogic Server を実行しない。 |
プロダクション モードでは、プロダクション環境にとってよりセキュアで適切な設定を使用してサーバが実行されるように設定される。 注意 : WebLogic Server は開発モードでコンフィグレーションした場合、不正な処理をしたアプリケーションまたは WebLogic Server の無効なのコンフィグレーションのようなエラー条件を表示しているトレース スタックに結果として発生する場合もあります。一般的に、エラー応答は問題はありません。悪意の目的で使用できる、アプリケーションおよび WebLogic Server インストールの情報を犯人に示します。ただし、WebLogic Server はプロダクション モードでコンフィグレーションする場合、スタック トレースが発生されていません。したがって、WebLogic Server がプロダクション環境での、開発モードに実行する必要がありません。 プロダクション モードで実行されるようにドメイン内にある WebLogic Server インスタンスをを変更する方法については、『Oracle Fusion Middleware Oracle WebLogic Server 管理 Console ヘルプ』の「プロダクション モードへの変更」を参照してください。 |
ネットワーク接続を設計するときには、管理が容易なセキュリティ ソリューションのニーズと、戦略上重要な WebLogic リソースを保護するためのニーズのバランスを取ります。次の表で、ネットワーク接続を保護するためのオプションを示します。
表 3-2 ネットワーク接続のセキュリティ
| セキュリティ アクション | 説明 |
|---|---|
|
ハードウェアおよびソフトウェアを使用して、ファイアウォールを作成する |
ファイアウォールとは、2 つのネットワーク間のトラフィックを制限する機能である。ファイアウォールは、ソフトウェアとハードウェア (ルータや専用のゲートウェイ マシンなど) を組み合わせて作成できる。ファイアウォールでは、プロトコル、要求されたサービス、ルーティング情報、パケット内容、および送信元や送信先のホストやネットワークに基づいて、トラフィックの通過を許可したり否認したりするフィルタが使用される。また、認証されたユーザのみにアクセス権を限定できる。 WebLogic セキュリティ サービスでは、境界ベースの認証 (Web サーバ、ファイアウォール、VPN) を実行し、複数のセキュリティ トークン タイプおよびプロトコル (SOAP、IIOP-CSIv2) を扱う、サード パーティの ID アサーション プロバイダを使用できる。詳細については、『Oracle Fusion MiddlewareWebLogic Security の紹介』の「境界認証」を参照してください。 WebLogic Server でのファイアウォールの使用については、『Oracle Fusion Middleware Oracle WebLogic Server 用のクラスタの使い方』の「クラスタ アーキテクチャのセキュリティ オプション」を参照してください。 |
|
WebLogic Server の接続フィルタを使用する |
ハードウェアおよびサード パーティのソフトウェアを使用してファイアウォールを作成するだけでなく、WebLogic Server の接続フィルタを使用し、プロトコル、IP アドレス、および DNS ノード名に基づいてネットワーク トラフィックを制限することを検討する。 接続フィルタは、WebLogic Server ドメイン内のマシンがお互いにファイアウォールを通過せずにアクセスできる場合に最も適している。たとえば、ネットワークの外からのトラフィックの制限にはファイアウォールを使用し、ファイアウォールの後ろでのトラフィックの制限には WebLogic Server の接続フィルタを使用できる。 『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「接続フィルタの使用」を参照してください。 |
|
管理トラフィックにドメイン全体の管理ポートを使用する |
管理ポートにより、WebLogic Server ドメインのサーバ インスタンス間のすべての管理トラフィックが 1 つのポートに制限される。管理ポートを使用せずにサーバを実行すると、サーバの機密性のあるコンフィグレーションがアプリケーションからネットワーク上にクリアテキストで送信されてしまう可能性がある。管理ポートを使用してサーバを実行すれば、この問題が起こる可能性は大幅に低くなる。さらに、管理ポートをコンフィグレーションすると、要求を処理するためのリソースや管理ポートの要求に対する制限がサーバの他の部分と異なるためにサービス拒否攻撃が発生した場合に便利。 接続フィルタと組み合わせて使用すると、WebLogic Server インスタンスが、既知のマシンまたはサブセットからのみ、かつ単一のポートでのみ管理要求を受け入れるように指定できる。 管理ポートを有効にするには、クライアントが SSL を使用して Administration Console と対話する必要がある。SSL では、ネットワーク上での攻撃者による重要なデータの傍受や一部のクロスサイト スクリプティング攻撃を防止している。 『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「ドメイン全体の管理ポートのコンフィグレーション」および「コンフィグレーション監査の有効化」を参照してください。 |
|
組み込み LDAP ポートを保護する |
総当たり攻撃から組み込み LDAP ポートを保護するには、接続フィルタを使用して、単一のサーバ コンフィグレーションで組み込み LDAP リスン ポートを閉じる。 この方法では、複数のサーバ コンフィグレーションで組み込み LDAP ポートを保護しないが、デフォルトの接続フィルタを実装すると、ドメインを構成するサーバからのアクセスのみを許可する際に使用する、ソースの IP アドレスに基づいたフィルタリングがサポートされる。この結果、ドメイン内のマシンのみが LDAP ポートにアクセスできる。接続フィルタの使用については、『Oracle Fusion Middleware WebLogic Security プログラマーズガイド』の「ネットワーク接続フィルタの使い方」を参照してください。 |
|
JVM のプラットフォーム MBean サーバへのリモート アクセスを有効にしない |
JDK 1.5 以降では、MBean サーバ (プラットフォーム MBean サーバ) と、JVM のモニタ情報を含む一連の MBean が提供される。WebLogic Server の実行時 MBean サーバをコンフィグレーションしてプラットフォーム MBean サーバとして実行できる。これにより、JMX クライアントは単一の MBean サーバ接続から JVM MBean および WebLogic Server MBean にアクセス可能。 プラットフォーム MBean サーバへのリモート アクセスは、標準の JDK 1.5 セキュリティ機能によってのみ保護される ( リモートの JMX クライアントが JVM MBean にアクセスできるようにする必要がある場合は、WebLogic Server の実行時 MBean サーバを介してアクセスすることをお勧めする。『Oracle Fusion Middleware Oracle WebLogic Server JMX による管理の容易なアプリケーションの開発』の「JVM プラットフォーム MBean サーバへの MBean の登録」を参照してください。 |
|
SNMP を有効にしている場合は、ファイアウォールやその他のネットワーク セキュリティ対策を使用してポート番号へのアクセスを制限する |
Weblogic Server バージョン 6.x から 11g リリース 1 (10.3.1) でサポートされている Simple Network Management Protocol バージョン 2 (SNMPv2) はセキュリティが不足している。デフォルトでは、WebLogic Server で SNMP は無効になっている。ただし、一度 SNMP を有効にすると、SNMPv2 プロトコルでは、権限のないアクセスやサービス拒否攻撃など、SNMP サービス上で特定のセキュリティ問題が発生する可能性が生じる。 SNMPv2 が有効な場合にこれらのセキュリティ問題を制限するには、ネットワークを保護し、WebLogic Server 環境のポートへのアクセスを制限するためにファイアウォールをコンフィグレーションすること。 詳細については、『Oracle Fusion Middleware WebLogic SNMP 管理ガイド』を参照してください。 |
多くの Web アプリケーションでは、データの格納にデータベースが使用されます。WebLogic Server で使用されるデータベースとしては、Oracle、Microsoft SQL Server、および Informix が一般的です。これらのデータベースには、顧客リスト、顧客の連絡先情報、クレジット カード情報、およびその他の顧客データなど、Web アプリケーションの重要なデータが保存されることがよくあります。Web アプリケーションを作成するときは、どのデータをデータベースに保存し、そのデータを作成するためにどのようなセキュリティが必要なのかを考慮する必要があります。また、データベース メーカーが提供するセキュリティ メカニズムを理解し、それがセキュリティ ニーズを満たすうえで十分かどうかを判断する必要があります。提供されたセキュリティ メカニズムで不十分な場合は、重要なデータをデータベースに書き込む前に暗号化するなど、その他のセキュリティ技術を使用して、データベースのセキュリティを改善することができます。たとえば、クレジット カード情報は暗号化し、それ以外のすべての顧客データはプレーン テキスト形式でデータベースに保存します。
WebLogic Security サービスには、多彩で柔軟なソフトウェア ツールがあり、サーバ インスタンスで実行するサブシステムおよびアプリケーションの保護に使用できます。次の表は、使用しているプロダクション環境を保護するために推奨される基本機能のチェックリストです。
表 3-3 WebLogic Security サービスのセキュリティ
| セキュリティ アクション | 説明 |
|---|---|
|
プロダクション対応のセキュリティ プロバイダをセキュリティ レルムにデプロイする |
WebLogic Security サービスでは、複数のセキュリティ プロバイダをデプロイでき、各プロバイダでは特定のセキュリティ分野に対応するプラグイン可能なアーキテクチャが使用される。 WebLogic Server には、デフォルトで完全なセキュリティ ソリューションを提供する独自のセキュリティ プロバイダがある。ユーザ独自のセキュリティ プロバイダを購入、または記述した場合は、次の操作を実行する。
|
|
プロダクション環境では SSL を使用し、デモ用のデジタル証明書を使用しない |
重要なデータを危険にさらさないためには、HTTPS を使用してデータ転送を保護する。 WebLogic Server には、開発のみの目的で、デモ用のプライベート キー、デジタル証明書、および信頼性のある認証局が用意されている。WebLogic Server をダウンロードするユーザには、これらのデジタル証明書に対してプライベート キーが付属される。デモ用の ID および信頼を使用しないこと。 『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「キーストアのコンフィグレーション」および『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ 』の「SSLのコンフィグレーション」を参照してください。 |
|
WebLogic Server で、デジタル証明書にセキュリティ制約が設定されていることを確認する |
SSL を使用して通信する場合、WebLogic Server ではデフォルトで、認証局によって定義された基本制御拡張を持たない証明書チェーンのデジタル証明書を拒否する。これにより、デジタル証明書のなりすましから Web サイトを保護する。 この設定を無効にする次のオプションを含むサーバ起動コマンドがないことを確認する。
詳細情報については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「SSL 証明書の検証」を参照してください。 開発環境では、7.0 サービス パック 2 以前のリリースで WebLogic Server が提供したデモ用のデジタル証明書との非互換性に対処するために、セキュリティ制約の設定を無効にしている可能性がある。この機能がプロダクション環境で有効になっていることを確認する。 |
|
介在者の攻撃を避けるために、ホスト名検証が有効になっていることを確認する |
WebLogic SSL はデフォルトで、接続が確立したホストが対象のパーティまたは認可されたパーティであることを検証する。ただし、サイトで WebLogic Server を実装するときに、ホスト名検証が無効になっている場合がある。 ホスト名検証を有効にするには、『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「カスタム ホスト名検証のコンフィグレーション」を参照してください。 『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「ホスト名検証の使い方」を参照してください。 予備知識 : ネットワークに配置されたマシンによって、無防備なパーティへのメッセージが取り込まれたり、変更されたり、再送信されたりすると、介在者の攻撃が発生する。接続が確立したホストが対象のパーティまたは認可されたパーティであることを検証すると、介在者の攻撃を避けることができる。SSL クライアントは、SSL サーバのデジタル証明書を使用して、SSL サーバのホスト名を比較することで、接続を検証することができる。WebLogic Server のホスト名検証は、介在者の攻撃から SSL 接続を保護する。 |
|
サービス拒否攻撃を防ぐために、外部チャネルに対して要求のサイズおよび時間を制限する |
サービス拒否攻撃を防ぐために、WebLogic Server ではメッセージのサイズ、およびメッセージの到着にかかる最大時間を制限できる。デフォルトの設定では、メッセージのサイズは 10MB に、メッセージのタイムアウトは 480 秒に制限される。以下を推奨。
HTTP、T3、および IIOP プロトコルでこれらの設定をコンフィグレーションするには、『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の以下のタスクを参照してください。 予備知識 : サービス拒否攻撃が実行されると、Web サイトは動作しているが、使用できない。ハッカーは、1 つまたは複数の重要な Web サイト リソースを使い果たしたり、削除したりする。 侵入者が WebLogic Server インスタンスに対してサービス拒否攻撃を実行する場合、サイズが非常に大きい要求、完了までに時間がかかる要求、完了しない要求を多数使用してサーバを攻撃するため、要求が完了する前にクライアントからのデータの送信が停止する。 |
|
サービス拒否攻撃を防ぐために、サーバに許可されるソケット数を設定する |
サービス拒否攻撃を防ぐためには、プロセス全体に許可されるソケット数よりも少なくなるように、サーバに許可されるソケット数を制限する。これにより、オペレーティング システムの制限で許可されるファイルの記述子の数を超えないようにできる。 サーバの制限を超えたとしても、管理者は管理ポートを介してサーバにアクセスできる。 MaxOpenSockCount flag を使用してこの設定のコンフィグレーションが可能。 『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「サーバ : コンフィグレーション : チューニング」を参照してください。 |
|
過負荷状態を回避するために、WebLogic Server をコンフィグレーションする |
過負荷状態を回避して十分な処理能力を得られるように WebLogic Server をコンフィグレーションする。サーバにかかる負荷が大きい場合に、管理者が WebLogic Server に接続して問題を修正できるようにする。 システムが過負荷状態のときには、管理チャネルを介した通信は妨げられないため、現在の過負荷がどのような状態であっても管理者は常に接続できる。 負荷が大きい場合、管理者はサーバを管理状態にして、不正なユーザを探し出し、そのユーザが要求によってサーバを過負荷状態にすることを防止する。 過負荷状態を回避するために WebLogic Server をコンフィグレーションするには、過負荷保護の MBean で共有容量の属性を設定する。管理者からではない要求が WebLogic Server で受信されなくなった後は、この属性で選択した設定がしきい値となる。 過負荷状態の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境設定』の「過負荷の回避と管理」を参照してください。 |
|
ユーザ アカウントの攻撃を防ぐために、ユーザのロックアウトおよびログイン時間制限をコンフィグレーションする |
WebLogic Security サービスには、デフォルトでユーザ アカウントの辞書攻撃および総当たり攻撃に対するセキュリティが用意されている。アカウントがロックされるまでの無効なログイン試行回数、アカウントがロックされるまでの無効なログイン試行期間、またはユーザ アカウントのロック時間を開発時に変更した場合は、設定内容を確認して、その設定がプロダクション環境に適しているかどうかを検証する必要がある。 注意 : ユーザ ロックアウトはサーバ単位で WebLogic Security サービスによってサーバごとに有効にされる。たとえば、特定の管理対象サーバ (またはクラスタ) でホストされているアプリケーションからロックアウトされたユーザは、必ずしも Administration Console でロックアウトされるわけではない。同様に、Administration Console からロックアウトされたユーザは、必ずしも管理対象サーバでホストされているアプリケーションへのログインができなくなるわけではない。 『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「ユーザ アカウントの保護」を参照してください。 予備知識 : 辞書攻撃および総当たり攻撃では、ハッカーはスクリプトを作成し、「辞書」に登録されているパスワードを使用してログインを試行する。WebLogic Server のユーザ ロックアウトおよびログイン設定により、辞書攻撃および総当たり攻撃からユーザ アカウントを保護することができる。 |
|
複数の認証プロバイダを使用する場合は、JAAS 制御フラグを適切に設定する |
セキュリティ レルムに複数の認証プロバイダがコンフィグレーションされている場合、JAAS 制御フラグを設定して、各プロバイダの順序および優先度をコンフィグレーションする。 『Oracle Fusion Middleware Oracle WebLogic Server Administration Console ヘルプ』の「JAAS 制御フラグの設定」を参照してください。 |
|
セキュリティ監査を有効にする |
監査は、主要なセキュリティ イベントを WebLogic Server 環境に記録する処理である。WebLogic Security サービスが提供する監査プロバイダを有効にすると、イベントが Administration Console の [セキュリティ レルム｜RealmName : プロバイダ : 監査] ページで、監査プロバイダを有効にする。 『Oracle Fusion Middleware Oracle WebLogic Server Administrator Console ヘルプ』の「監査プロバイダのコンフィグレーション」を参照してください。 注意 : 監査プロバイダを使用すると、少数のイベントのみが記録される場合でも、WebLogic Server のパフォーマンスが低下する場合がある。 監査レコードを定期的に確認し、セキュリティ違反または違反未遂を検出する。度重なるログインの失敗や、予期しないパターンのセキュリティ イベントに注目することで、重大な問題を防げる可能性がある。 独自のカスタム監査プロバイダを開発して、プロバイダの MBean から監査イベントをポストする場合の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server セキュリティ プロバイダの開発』の「ベスト プラクティス : プロバイダの MBean からの監査イベントのポスト」を参照してください。 |
|
デフォルトの WebLogic Server セキュリティ ロールにユーザおよびグループを正しく割り当てたことを確認する |
デフォルトでは、すべての WebLogic リソースは、セキュリティ ロールのデフォルト セットに基づくセキュリティ ポリシーによって保護されている。 目的のユーザおよびグループをこれらのデフォルト セキュリティ ロールに割り当てる。 『Oracle Fusion Middleware ロールおよびポリシーによる WebLogic リソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。 |
|
システム管理者特権を持つ、少なくとも 2 つのユーザ アカウントを作成する |
ドメインの作成時に、システム管理者ユーザのうち 1 つを作成する必要がある。他のユーザ (複数可) を作成し、これらを Admin セキュリティ ロールに割り当てる。システム管理者ユーザを作成したら、それらに対して容易に推測できないユニークな名前を付与する。 少なくとも 2 つのシステム管理者のユーザ アカウントがあれば、1 つのユーザが辞書攻撃や総当り攻撃でロックアウトになった場合でも、もう 1 つのユーザでアカウント アクセスを保持できる。 |
WebLogic Server ドメイン内の WebLogic リソースのセキュリティ対策業務のほとんどはサーバに関するものですが、個々のアプリケーションに対して行うセキュリティ業務もあります。一部のセキュリティ オプションについては、WebLogic Security サービスを使用すると、サーバまたは個々のアプリケーションのいずれの分担であるのかを判断できます。プロダクション環境にデプロイする各アプリケーションについて、次の表の項目を確認して、そのリソースが保護されていることを確認してください。
|
注意 : 『Oracle Fusion Middleware Oracle WebLogic Server の Web アプリケーション、サーブレット、JSP の開発』の「HTTP パブリッシュ - サブスクライブ サーバのの使用」に、WebLogic Server に含まれているHTTP パブリッシュ - サブスクライブ サーバの具体的な lockdown手順が説明されています。 |
表 3-4 アプリケーションのセキュリティ
| セキュリティ アクション | 説明 |
|---|---|
|
どのデプロイメント モデルが Web アプリケーションおよび EJB を保護しているのかを判断する |
デフォルトでは、各 Web アプリケーションおよび EJB はデプロイメント記述子 (XML ファイル) を使用して、保護されたリソースおよびそれにアクセスできるセキュリティ ロールを宣言する。 Web アプリケーションおよび EJB デプロイメント記述子でセキュリティを宣言せずに、Administration Console を使用して、Web アプリケーションおよび EJB へのアクセスを保護するセキュリティ ポリシーを設定することができる。この技術により、すべての Web アプリケーションおよび EJB に対するセキュリティを、1 つの場所から集中管理できる。 これらの 2 つの技術を組み合わせ、URL (Web) または EJB リソースの初期デプロイメントで、既存のデプロイメント記述子からセキュリティ コンフィグレーションをコピーするように WebLogic Server をコンフィグレーションできる。これらのセキュリティ コンフィグレーションをコピーした後は、Administration Console を使用して更新できる。 『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「Web アプリケーションおよび EJB リソースの保護のオプション」を参照してください。 |
|
リダイレクト攻撃を防止するには、 |
Web アプリケーションの要求は別の場所にリダイレクトした場合、要求でのホスト ヘッダは、デフォルトで応答のロケーション ヘッダに使用されます。 ホスト ヘッダ は、別のホスト名または他のパラメータを含まれるように破損させる、つまりなりすます可能性があります。そのため、サードパーティでリダイレクト拒否攻撃を起動するには、この動作は、返す機能があります。 リダイレクト対象のすべての URL が送られるホストを指定するには、WebserverMBean または ClusterMBeanに 『Oracle Fusion Middleware Oracle WebLogic Server MBean リファレンス』の「 |
|
HTML コメント タグではなく、JSP コメント タグを使用する |
JSP ファイル内にある、機密データを含むコメントやエンド ユーザを対象としていないコメントは、HTML 構文の |
|
プロダクション マシンには未コンパイルの JSP およびその他のソース コードをインストールしない |
常に、ソース コードをプロダクション マシンに置かないようにする必要がある。ソース コードにアクセスすると、侵入者はセキュリティ ホールを発見できる。 JSP をプリコンパイルし、コンパイルされた JSP のみプロダクション マシンにインストールすることを検討する。JSP のプリコンパイルの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server の Web アプリケーション、サーブレット、JSP の開発』の「JSP のプリコンパイル」を参照してください。 |
|
SSL を使用するようにアプリケーションをコンフィグレーションする |
web.xml ファイルの 『WebLogic Server に Web アプリケーション、サーブレット、JSP の開発』の「security-constraint」を参照してください。 |
|
|
プロダクション環境での 代わりに、サーブレットを URI に明示的にマップする。プロダクション環境で Web アプリケーションを使用する前に、すべての Web アプリケーションから、WebLogic サーブレットと マッピング サーブレットの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server の Web アプリケーション、サーブレット、JSP の開発』の「サーブレットのコンフィグレーション」を参照してください。 |
|
プロダクション環境で、 |
プロダクション環境で デフォルト サーブレットの設定の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server の Web アプリケーション、サーブレット、JSP の開発』の「デフォルト サーブレットの設定」を参照してください。 |
|
すべての WebLogic セキュリティ ポリシーを確認する |
WebLogic Server 9.0 では、ACL に代わってセキュリティ ポリシーが使用され、WebLogic リソースに誰がアクセスしたのかを判断する。 WebLogic リソースからセキュリティ ポリシーを削除していないこと、およびセキュリティ ロールの割り当てによってユーザに目的のアクセス権を提供していることを確認する。 『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。 |
|
アプリケーションのセキュリティを検査する |
アプリケーションにセキュリティの脆弱性がもたらされるおそれのある典型的な事例がある。これらの事例の多くは、OWASP (Open Web Application Security Project) などの第三者組織によって定義されている (よくある問題のリストについては「 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
『Oracle Fusion Middleware Oracle WebLogic Server Security プログラマーズガイド』の「Java セキュリティ マネージャを使用しての WebLogic リソースの保護」を参照してください。 |
|
サーブレットまたは JSP がユーザの供給によるデータを返した場合に、HTML 特殊文字を置換する |
ユーザが入力したデータを返す機能により、クロスサイト スクリプトと呼ばれるセキュリティの脆弱性がもたらされる。これは、ユーザのセキュリティ認可を盗用するために利用される可能性がある。クロスサイト スクリプティングの詳細については、 セキュリティの脆弱性をなくすには、ユーザが供給したデータを返す前に、そのデータをスキャンして HTML 特殊文字を探す。該当する文字が見つかれば、それらを HTML のエンティティまたは文字参照と置き換える。文字を置換することで、ブラウザでユーザ入力によるデータが HTML として実行されることを回避する。 『Oracle Fusion Middleware Oracle WebLogic Server の Web アプリケーション、サーブレット、JSP の開発』の「JSP でのユーザ入力データのセキュリティ」および「クライアント入力のセキュリティ」を参照してください。 |
|
JMS リソースに対してセキュリティ チェックが行われていることを確認する |
|
