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