| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > プロダクション環境のセキュリティ > プロダクション環境のセキュリティの確保 |
|
プロダクション環境のセキュリティ
|
プロダクション環境のセキュリティを確保するために、以下のアクションを実行することをお勧めします。
WebLogic Server のプロダクション環境は、それが動作しているマシンと同じレベルでしかセキュリティは確保されません。したがって、物理的なマシン、オペレーティング システム、およびホスト マシン上にインストールされたその他のすべてのソフトウェアをロックダウンすることが重要です。以下に、プロダクション環境の WebLogic Server ホストをロックダウンするためのアドバイスを示します。 また、マシンおよびオペレーティング システムのベンダに推奨のセキュリティ対策を確認してください。
|
ハードウェアは、無認可のユーザがデプロイメント用マシンやネットワーク接続に不用意に触れることがないように安全な場所に設置する。 |
|
|
電子メール プログラムやディレクトリ サービスなどのネットワーク サービスを専門家に評価してもらい、悪意ある攻撃者がオペレーティング システムまたはシステムレベルのコマンドにアクセスできないことを確認する。 |
|
|
各 WebLogic Server ホストのファイル システムで、保護対象リソースへの不正アクセスを防止できることを確認する。 たとえば、Windows コンピュータ上では、NTFS のみを使用する。 |
|
|
WebLogic Server ホストで複数のユーザ アカウントを作成することは避け、各アカウントに付与されるファイル アクセス特権を制限する。ホスト マシンでは、システム管理者特権を持つユーザ アカウント 1 つと、WebLogic Server を実行する十分な特権を持つユーザ 1 つが理想的。 アクティブなユーザ アカウントを定期的に再検討する。また、退職者があった場合にも見直す。 背景情報 : |
|
|
プロダクション マシンでのユーザ アカウントのパスワードは推測しにくいものにし、注意深く保護される必要がある。 |
|
|
各 WebLogic Server ホスト コンピュータでは、オペレーティング システムを使用して、WebLogic Server を実行できる特別なユーザ アカウント (wls_owner など) を確立する。 このオペレーティング システム (OS) ユーザ アカウントに以下の特権を付与する。
他の OS ユーザには BEA ファイルおよびドメイン ファイルに対する読み込み、書き込み、および実行のアクセス権を与えないこと。 このセキュリティ対策を行うと、WebLogic Server と同じマシンで実行されている他のアプリケーションの BEA ファイルおよびドメイン ファイルへのアクセス機能を制限できる。 このセキュリティ対策がない場合、他の一部のアプリケーションは書き込みアクセス権を得て、動的コンテンツを提供する JSP などのファイルに悪質な実行可能コードを挿入することができる。そのコードは、次にファイルがクライアントにサービスされるときに実行される。 |
|
|
Windows プラットフォームでは、WebLogic Server インスタンスを Windows サービスとして実行できる。 これにより、サーバ インスタンスは Windows コンピュータを起動するたびに自動的に開始する。 WebLogic Server インスタンスを Windows サービスとして実行するように設定するには、Windows レジストリを修正する特権を持つユーザ アカウントで Windows コンピュータにログインする必要がある。 詳細については、『管理者ガイド』の「WebLogic Server インスタンスの Windows サービスとしての設定」を参照。 WebLogic Server インスタンスの Windows サービスとしての実行には、これらの管理者レベルの特権は不要である。 その代わり、Windows サービスは WebLogic Server を実行するために作成した特別な OS ユーザ アカウント下で実行しなければならない。 WebLogic Server インスタンスが必ず特別な OS ユーザ アカウント下で実行されるようにするには、Windows サービスの [プロパティ] ページでユーザ名およびパスワードを指定する。 詳細については、『管理者ガイド』の「 サービスを実行するユーザ アカウントの確認」を参照。 |
|
|
UNIX 上で保護されているポートにバインドするには、ユーザ ID またはネットワーク アドレス変換 (NAT) ソフトウェアの切り替えを行うよう、WebLogic Server をコンフィグレーションする |
UNIX システムでは、特権を付与されたユーザ アカウント (大概の場合は root) 下で実行されるプロセスのみが、1024 未満のポートにバインドできる。 ただし、WebLogic Server のような長期にわたって実行されるプロセスは、これらの特権を付与されたアカウント下で実行してはならない。 その代わりに、以下の処理のいずれかを行うことができる。
|
|
開発用マシン上でまず開発して、コードが完了し、テストしてから、プロダクション用マシンにコードを移植する。この手順を取ることで、開発環境のバグがプロダクション環境のセキュリティに影響するのを防止できる。 |
|
|
開発ツールはプロダクション用マシンにインストールしない。 開発ツールをプロダクション用マシンに持ち込まないことで、侵入者が WebLogic Server のプロダクション用マシンに部分的にアクセスできた場合でも、悪用されるおそれが少なくなる。 プロダクション用マシンに WebLogic Server サンプル アプリケーションをインストールしない。 BEA インストール プログラム上で、標準インストールにするかカスタム インストールにするかを尋ねられた場合は、以下の操作を実行する。 |
|
|
WebLogic Server が実行されるオペレーティング システムで、ファイルおよびディレクトリへのアクセスのセキュリティ監査がサポートされている場合は、監査ログを使用して、拒否されたディレクトリまたはファイルへのアクセス違反を追跡することをお勧めする。 |
|
|
ほとんどのオペレーティング システムでは、プロダクション環境を保護する追加ソフトウェアを実行できる。たとえば、Intrusion Detection System (IDS) ではプロダクション環境を変更する攻撃を検出できる。 |
|
|
サイトのセキュリティ事項を担当している場合は、BEA の Advisories & Notifications ページ (http://dev2dev.bea.com/advisories) で新しいセキュリティ勧告の通知を受けるよう登録する。 セキュリティ勧告で推奨されている対策は、Advisories & Notifications ページに投稿されている。 また、リリースされている各サービス パックの適用もお勧めする。 サービス パックには、製品の各バージョンおよび以前にリリースされた各サービス パックのすべてのバグの修正が含まれている。 サービス パックは、http://commerce.beasys.com/downloads からダウンロードできる。 |
ネットワーク接続を設計するときには、管理しやすいセキュリティ ソリューションの必要性と重要な WebLogic リソースを保護する必要性のバランスを考える必要があります。次の表に、ネットワーク接続を保護するためのオプションを説明します。
|
ファイアウォールとは、2 つのネットワーク間のトラフィックを制限する機能のこと。ファイアウォールは、ソフトウェアとハードウェア (ルータや専用のゲートウェイ マシンなど) を組み合わせて作成できる。 ファイアウォールは、プロトコル、要求されたサービス、ルーティング情報、パケットの内容、および送信元と送信先のホストまたはネットワークに基づいてトラフィックの通過を許可または拒否するフィルタを利用する。また、アクセス権を認証されたユーザのみに制限することもできる。 WebLogic セキュリティ サービスは、境界に基づく認証 (Web サーバ、ファイアウォール、VPN) を実行し、複数のセキュリティ トークン タイプ/プロトコル (SOAP、IIOP-CSIv2) を処理するサードパーティ ID アサーション プロバイダの使用をサポートする。 詳細については、『WebLogic Security の紹介』の「境界認証」を参照。 WebLogic Server でファイアウォールを使用する方法の詳細については、『WebLogic Server Clusters ユーザーズ ガイド』の「クラスタ アーキテクチャのセキュリティ オプション」を参照。 |
|
|
ハードウェアとサードパーティ ソフトウェアを使用してファイアウォールを作成する代わりに (またはそれに加えて)、WebLogic Server 接続フィルタを使用してプロトコル、IP アドレス、および DNS ノード名に基づいてネットワーク トラフィックを制限することを検討する。 接続フィルタは、WebLogic Server ドメインのマシンがファイアウォールを介せずに互いにアクセスできる場合に最適。たとえば、ファイアウォールを使用してネットワーク外からのトラフィックを制限し、WebLogic Server 接続フィルタを使用してファイアウォールの背後でトラフィックを制限できる。 『WebLogic Security の管理』の「接続フィルタのコンフィグレーション」を参照。 |
|
|
管理ポートは、WebLogic Server ドメインのサーバ インスタンス間のすべての管理トラフィックを単一ポートに制限する。接続フィルタと一緒に使用すると、WebLogic Server インスタンスが単一ポートのみで、既知のマシン セットまたはサブネットからの管理要求のみを受け付けるように指定できる。 ドメイン全体の管理ポートを有効にするには、Administration Console で [DomainName｜コンフィグレーション｜一般] タブを使用する。 Administration Console オンライン ヘルプの「ドメイン管理ポートの有効化」を参照。 |
|
|
サーバ間の管理通信のセキュリティを確保するには、管理チャネルを有効にする必要がある。 管理チャネルなしでは、一部の重要な管理メッセージがクリアテキストで渡され、メッセージの捕捉、修正、削除、および再現が可能になる。 『WebLogic Server のコンフィグレーションと管理』の「管理ポートと管理チャネル」 を参照。 |
ほとんどの Web アプリケーションはデータベースを使用してデータを保存します。 WebLogic Server で使われるデータベースとしては、Oracle、MicroSoft SQL Server、および Informix が一般的です。データベースには、顧客リスト、顧客の連絡先、クレジット カード情報、その他の独自の情報など、Web アプリケーションの重要なデータを保存することがよくあります。Web アプリケーションを作成する際には、データベースに保存するデータの種類とデータのセキュリティ レベルを考慮する必要があります。また、データベース製造元によるセキュリティ メカニズムを理解し、セキュリティ ニーズに十分に対応できるかどうかを判断することも必要です。 メカニズムが十分でない場合は、重要なデータをデータベースに書き込む前に暗号化するなど、他のセキュリティ手法を用いて、データベースのセキュリティを向上することができます。 たとえば、クレジット カード情報だけを暗号化して、その他の顧客データはプレーン テキストのままデータベースに保存するという方法があります。
WebLogic セキュリティ サービスでは、サーバ インスタンスで動作するサブシステムやアプリケーションを保護するための効果的で柔軟性のあるソフトウェア ツールが提供されます。次の表に、プロダクション環境を保護する際に使用することが望ましい重要な機能のチェックリストを示します。
|
サイトのセキュリティ事項を担当している場合は、BEA の Advisories & Notifications ページ (http://dev2dev.bea.com/advisories) で新しいセキュリティ勧告の通知を受けるよう登録する。 セキュリティ勧告で推奨されている対策は、Advisories & Notifications ページに投稿されている。 また、リリースされている各サービス パックの適用もお勧めする。 サービス パックには、製品の各バージョンおよび以前にリリースされた各サービス パックのすべてのバグの修正が含まれている。 サービス パックは、http://commerce.beasys.com/downloads からダウンロードする。 |
|
|
WebLogic セキュリティ サービスは、複数のセキュリティ プロバイダ (それぞれがセキュリティの特定の側面を処理) をデプロイできるプラグイン可能アーキテクチャを使用する。 WebLogic Server には、包括的なセキュリティ ソリューションを提供する独自のセキュリティ プロバイダがデフォルトで含まれている。 独自のセキュリティ プロバイダを購入または作成した場合は、次の処理を実行する。
『WebLogic Security の管理』の「デフォルト セキュリティ コンフィグレーションのカスタマイズ」を参照。 |
|
|
重要なデータを危険から守るには、HTTP プロトコルではなく SSL と HTTPS プロトコル (セキュア ソケット レイヤ (SSL) 上の HTTP) を使用してデータ転送を保護する。 WebLogic Server には、開発のみで使用するデモ用のプライベート キー、デジタル証明書、および信頼性のある認証局が用意されている。WebLogic Server をダウンロードすると、これらのデジタル証明書用のプライベート キーが必ず付属している。 デモ用の ID と信頼は使用しないこと。 『WebLogic Security の管理』の「SSL のコンフィグレーション」を参照。 |
|
|
ダウンロードするバージョンの WebLogic Server では、512 ビット キーと 40 ビット バルク暗号化をサポートしている。 最強の暗号化 (1024 ビット キーと 128 ビット バルク暗号化) をサポートするバージョンを使用する場合は、BEA の販売代理店に問い合わせる。 輸出規制があるため、このバージョンの WebLogic Server は、特定国でのみ利用可能である。 |
|
|
SSL 経由で通信する場合、WebLogic Server はデフォルトで、認証局で定義された Basic Constraint エクステンションを持たない証明書チェーンのデジタル証明書を拒絶する。このレベルのセキュリティ制約の施行では、デジタル証明書のなりすましから Web サイトが保護される。 サーバ起動コマンドで、このセキュリティ制約の施行を無効にする次のオプションが指定されていないようにする。 -Dweblogic.security.SSL.enforceConstraints=false このオプションは起動スクリプト、またはノード マネージャで管理対象サーバを起動する場合は Administration Console の [サーバ｜ServerName｜コンフィグレーション｜リモート スタート] タブで見つかる。 実際の開発環境では、WebLogic Server 7.0 サービス パック 2 以前のリリースで提供されたデモ用デジタル証明書との非互換性を回避するためにセキュリティ制約の施行が無効になっている場合がある。 プロダクション環境ではこの機能を有効にすること。 |
|
|
WebLogic SSL の実装はデフォルトで、接続先のホストが予定していた通信先、または許可された通信先であることを確認する。ただし、サイトへの WebLogic Server の実装時に、ホスト名の検証が無効にされている場合もある。 ホスト名の検証が WebLogic Server デプロイメントで確実に使用されるようにするには、[ホスト名検証を無視] 設定を無効にする。 この設定は、Administration Console の [サーバ｜ServerName｜接続｜SSL] タブにある。 背景情報 : |
|
|
サービス拒否攻撃を防止するために、WebLogic Server では、メッセージのサイズだけでなく、メッセージの到着にかかる最長時間も制限することができる。デフォルト設定では、最大メッセージ サイズとして 2GB、完了メッセージ タイムアウトとして 480 秒が許可される。 HTTP、T3、および IIOP プロトコルのこれらの設定は、Administration Console の [サーバ｜ServerName｜接続｜プロトコル] タブでコンフィグレーションできる。 背景情報 : 侵入者は WebLogic Server インスタンスに対してサービス拒否攻撃を仕掛けるために、サイズが非常に大きく送信が終了するまでに時間がかかるリクエストや、リクエストが終了する前にクライアントがデータの送信を止めてしまうので完了することのないリクエストを大量に送信する。 |
|
|
WebLogic セキュリティ サービスはデフォルトで、ユーザ アカウントの辞書攻撃に対して最大レベルのセキュリティを提供する。 開発時に、アカウントがロックされるまでの無効なログイン試行の回数、アカウントがロックされるまでに無効なログイン試行が行われる期間、またはユーザ アカウントがロックされる時間の設定を変更した場合は、その設定を見直して実際のプロダクション環境に適しているかどうかを検証する。 それらの設定は、Administration Console の [セキュリティ｜レルム｜RealmName｜ユーザ ロックアウト] タブで確認または変更できる。 背景情報 : |
|
|
セキュリティ レルムで複数の認証プロバイダがコンフィグレーションされている場合は、JAAS 制御フラグを設定して各プロバイダの順序と優先順位をコンフィグレーションする。 JAAS 制御フラグは、Administration Console の [セキュリティ｜レルム｜RealmName｜プロバイダ｜認証プロバイダAuthenticatorName｜一般] タブで設定する。 『WebLogic Security の管理』の「JAAS 制御フラグ属性の設定」を参照。 |
|
|
監査とは、WebLogic Server 環境での重要なセキュリティ イベントを記録する処理のこと。 WebLogic セキュリティ サービスが提供する監査プロバイダを有効にすると、イベントが DomainName\DefaultAuditRecorder.log に記録される。 監査プロバイダは、Administration Console の [セキュリティ｜レルム｜RealmName｜プロバイダ｜監査] ページで有効にできる。 詳細については、Administration Console オンライン ヘルプの「監査プロバイダのコンフィグレーション」を参照。 注意: 監査プロバイダを使用すると、数個のイベントがログに記録される場合でも WebLogic Server のパフォーマンスに悪影響が及ぶ場合がある。 監査レコードを定期的に参照し、セキュリティ侵害やその試みを検出する。 何度もログオンしようとして失敗している、または変わったパターンでセキュリティ イベントが起こっていることに注目すると、重大な問題を防止できる。 |
|
|
デフォルトの WebLogic Server セキュリティ ロールにユーザおよびグループが正しく割り当てられていることを確認する |
すべての WebLogic リソースはデフォルトで、デフォルトのセキュリティ ロールに基づくセキュリティ ポリシーで保護される。 目的のユーザおよびグループがそれらのデフォルト セキュリティ ロールに割り当てられていることを確認する。 『管理者ガイド』の「システム管理操作の保護」を参照。 |
|
WebLogic Server のインスタンスが HTTP リクエストに応答するときには、デフォルトで、その HTTP 応答ヘッダにサーバの名前と WebLogic Server バージョン番号が含まれる。 これが原因で、攻撃者が特定バージョンの WebLogic Server の脆弱性を知っている場合にセキュリティ上のリスクが生じることになる。 WebLogic Server インスタンスからその名前とバージョン番号が送信されるのを防止するには、Administration Console で [Send Server Header を有効化] 属性を無効にする。 この属性は、[サーバ｜ServerName｜接続｜HTTP] タブにある。 |
WebLogic Server ドメインの WebLogic リソースを保護する責任のほとんどはサーバにありますが、一部の責任は個々のアプリケーションにあります。一部のセキュリティ オプションでは、WebLogic セキュリティ サービスを利用してサーバと個々のアプリケーションのどちらに責任があるかを判断できます。プロダクション環境にデプロイしたアプリケーションごとに、次の表の項目を検討してリソースが保護されているかを検証する必要があります。
|
各 Web アプリケーションと EJB はデフォルトでデプロイメント記述子 (XML ファイル) を使用して、その保護対象リソースと保護対象リソースにアクセスできるセキュリティ ロールを宣言する。 Web アプリケーションおよび EJB のデプロイメント記述子でセキュリティを宣言する代わりに、Administration Console を使用して Web アプリケーションおよび EJB へのアクセスを保護するセキュリティ ポリシーを設定できる。この方法では、すべての Web アプリケーションと EJB のセキュリティを一元的に管理できる。 以上 2 つの方法を結合し、URL (Web) または EJB リソースの初期デプロイメント時に既存のデプロイメント記述子からセキュリティ コンフィグレーションをコピーするよう WebLogic Server をコンフィグレーションできる。セキュリティ コンフィグレーションをコピーすると、以降の更新では Administration Console を使用できる。 『WebLogic リソースのセキュリティ』の「URL (Web) リソースと EJB (エンタープライズ JavaBean) リソース」を参照。 |
|
|
エンド ユーザ向けではない JSP ファイルのコメントは、HTML 構文 <!-- ... --> ではなく JSP 構文の <%/* ... */%> を使用する必要がある。 JSP コメントは JSP がコンパイルされたときに削除されるので、見ることはできない。 |
|
|
必ず、ソース コードはプロダクション用マシンから遠ざけておくようにする。ソース コードにアクセスできれば、侵入者はセキュリティ ホールを見つけ出すことができる。 JSP をプリコンパイルし、コンパイル済みの JSP のみをプロダクション用マシンにインストールすることを検討する。 JSP のプリコンパイルについては、『WebLogic JSP プログラマーズ ガイド』の「JSP のプリコンパイル」を参照。 |
|
|
web.xml ファイルの user-data-constraint 要素で transport-guarantee を CONFIDENTIAL に設定する。 『Web アプリケーションのアセンブルとコンフィグレーション』の「security-constraint」を参照。 |
|
|
プロダクション環境では Servlet サーブレットを使用しないことをお勧めする。 代わりに、サーブレットを明示的に URI にマッピングする。プロダクション環境で Web アプリケーションを使用する前には、すべての Web アプリケーションから、WebLogic サーブレットと Servlet サーブレットの間の既存のマッピングをすべて削除する。 サーブレットのマッピングについては、『Web アプリケーションのアセンブルとコンフィグレーション』の「サーブレットのコンフィグレーション」を参照。 |
|
|
プロダクション環境では FileServlet サーブレットをデフォルト サーブレットとして使用しないことをお勧めする。 デフォルト サーブレットの設定については、『Web アプリケーションのアセンブルとコンフィグレーション』の「デフォルト サーブレットの設定」を参照。 |
|
|
WebLogic Server 7.0 では、WebLogic リソースに「誰がアクセスできるか」という問いに対し、ACL ではなくセキュリティ ポリシーが答える。 WebLogic リソースからセキュリティ ポリシーが削除されていないこと、そしてセキュリティ ロールの割り当てで意図したタイプのアクセス権がユーザに提供されることを確認する。 『WebLogic リソースのセキュリティ』の「セキュリティ ポリシー」を参照。 |
|
|
Java セキュリティ マネージャは、JVM で動作するクラスのパーミッションを定義し強制する。多くの場合、脅威モデルでは悪意あるコードが JVM で実行されることを想定していないため、Java セキュリティ マネージャは不要。しかし、サードパーティが WebLogic Server を使用し、未知のクラスが実行される場合、Java セキュリティ マネージャが役立つ。 サーバ インスタンスの Java セキュリティ マネージャを有効にするには、サーバの起動時に次の Java オプションを使用する。 -Djava.security.manager 『WebLogic Security プログラマーズ ガイド』の「Java セキュリティを使用しての WebLogic リソースの保護」を参照。 |
|
|
ユーザの供給によるデータを返す機能により、クロスサイト スクリプトと呼ばれるセキュリティの脆弱性がもたらされる。これは、ユーザのセキュリティ認可を盗用するために利用される可能性がある。 クロスサイト スクリプトの詳細については、http://www.cert.org/tech_tips/malicious_code_mitigation.html の「Understanding Malicious Content Mitigation for Web Developers」(CERT のセキュリティ勧告) を参照。 セキュリティの脆弱性をなくすには、ユーザが供給したデータを返す前に、そのデータをスキャンして HTML 特殊文字を探す。 該当する文字が見つかれば、それらを HTML のエンティティまたは文字参照と置き換える。 文字を置換することによって、ブラウザがユーザの供給によるデータを HTML として実行することが回避される。 『WebLogic JSP プログラマーズ ガイド』の「JSP におけるユーザ入力データのセキュリティ」および『WebLogic HTTP サーブレット プログラマーズ ガイド』の「サーブレットでのクライアント入力のセキュリティ 」を参照。 |
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
