プロダクション環境のセキュリティ

プロダクション環境のセキュリティの確保

BEA では、使用しているプロダクション環境のセキュリティを確保するために、次のアクションを実装することをお勧めします。

WebLogic Server ホストのセキュリティ

WebLogic Server プロダクション環境のセキュリティは、動作しているマシンのセキュリティと同程度でしかありません。このため、物理マシン、オペレーティングシステム、およびホストマシンにインストールされたその他のすべてのソフトウェアをロックダウンすることが重要です。プロダクション環境での WebLogic Server ホストのロックダウンについてのヒントを次に示します。また、マシンおよびオペレーティングシステムのメーカーに、適切なセキュリティ対策について確認してください。

表 2-1 WebLogic Server ホストのセキュリティ

セキュリティアクション	説明
ハードウェアを物理的に保護する	権限のないユーザが、デプロイメントマシンまたはそのネットワーク接続を変更できないように、ハードウェアを安全な場所に置く。
オペレーティングシステムが提供するネットワークサービスを保護する	悪意のある攻撃者がオペレーティングシステムにアクセスしたり、システムレベルのコマンドを実行することがないように、電子メールプログラムまたはディレクトリサービスなどのネットワークサービスについて専門家に確認してもらう。ファイルシステムを企業ネットワーク内の他のマシンと共有することを避ける。
不正アクセスを防ぐことのできるファイルシステムを使用する	各 WebLogic Server ホスト上のファイルシステムで、保護されているリソースへの不正アクセスが防止されていることを確認する。たとえば、Windows コンピュータでは、NTFS のみを使用する。
ホストマシンのユーザアカウント数を制限する	WebLogic Server ホストに必要以上のユーザアカウントを作成せず、各アカウントに付与するファイルアクセス特権を制限する。ホストマシンにシステム管理者特権を持つユーザアカウントを 2 つ、WebLogic Server を実行する特権を持つユーザアカウントを 1 つ作成するのが理想的。アクティブなユーザアカウントを定期的に再検討する。退職者があった場合にも見直す。 Background Information: WebLogic Server コンフィグレーションデータの一部と Java Server Pages (JSP) および HTML ページを含む URL (Web) リソースの一部は、ファイルシステム上にクリアテキストで保存される。ファイルおよびディレクトリへの読み込み特権を持つユーザまたは侵入者が、WebLogic Server の認証計画および認可計画で確立するセキュリティメカニズムを破る可能性がある。
システム管理者特権を持つユーザアカウントを少なくとも 2 つ作成する	システム管理者ユーザアカウントの 1 つは、ドメインの作成時に作成される。それ以外のユーザアカウントを作成する。少なくとも 2 つのシステム管理者ユーザアカウントを作成することにより、辞書攻撃によって一方のユーザがロックアウトされた場合でも、もう一方のユーザがアカウントアクセスを保持できる。
システム管理者ユーザアカウントの名前は、簡単に推測されないものにする	安全性を高めるために、「system」、「admin」、「administrator」などのすぐに分かるような名前をシステム管理者ユーザアカウントに使用することは避ける。
パスワードを保護する	プロダクションマシンのユーザアカウントのパスワードは、推測が難しいものに設定し、注意して守る必要がある。パスワードの有効期限が定期的に切れるように、ポリシーを設定する。クライアントアプリケーションでパスワードをコーディングすることは避ける。
各ホストコンピュータで、1 つのユーザアカウントにのみ WebLogic リソースへのアクセス権を付与する	各 WebLogic Server ホストコンピュータでは、オペレーティングシステムを使用して、WebLogic Server の実行用に特別なユーザアカウント (`wls_owner` など) を設定する。このオペレーティングシステム (operating-system: OS) のユーザアカウントには、以下の特権を付与する。 BEA ホームディレクトリ、WebLogic Server 製品ディレクトリツリー、およびドメインディレクトリのみに対するアクセス特権。 BEA ホームディレクトリとは共通ファイル用のリポジトリのことで、同じマシンにインストールされる複数の BEA Products が使用する。WebLogic Server 製品インストールディレクトリには、プログラムファイルを含む、システムにインストールする WebLogic Server ソフトウェアコンポーネントがすべて含まれる。ドメインディレクトリには、コンフィグレーションファイル、セキュリティファイル、ログファイル、J2EE アプリケーション、および単一の WebLogic ドメイン用のその他の J2EE リソースが含まれる。WebLogic Server ホストコンピュータに複数のドメインをインストールする場合、各ドメインディレクトリを保護する必要がある。デフォルトでは、BEA インストールプログラムはすべての BEA ファイルとドメインディレクトリを単一のディレクトリツリーに格納する。このツリーの最上位ディレクトリの名前は `bea` である。WebLogic Server ファイルはすべてこのディレクトリツリーのサブディレクトリ (`bea\weblogic810`) に入り、ドメインファイルは別のサブディレクトリ (`bea\user_projects\domains\domain1`、`bea\user_projects\domains\domain2`、...) に入る。ただし、WebLogic Server 製品インストールディレクトリおよびドメインディレクトリを BEA ホームディレクトリの外部に配置することもできる。詳細については、『インストールガイド』の「WebLogic Platform インストールのためのディレクトリの選択」を参照してください。 BEA ホームディレクトリ、WebLogic Server 製品ディレクトリツリー、およびドメインディレクトリ内での読み込み、書き込み、および実行特権。その他の OS ユーザには、BEA ファイルおよびドメインファイルへの読み込み特権、書き込み特権、または実行特権を付与しない。これにより、WebLogic Server と同じマシンで実行されている他のアプリケーションの BEA ファイルおよびドメインファイルへのアクセスが制限される。このように保護しないと、その他のアプリケーションの一部は書き込み特権を得て、動的コンテンツを提供する JSP およびその他のファイルに悪意のある実行コードを挿入する可能性がある。そのファイルが次にクライアントに提供されると、挿入されたコードが実行される。
特別な OS ユーザアカウント下で WebLogic Server の Windows サービスを実行する	Windows プラットフォーム上で、WebLogic Server インスタンスを Windows サービスとして実行できる。これにより、サーバインスタンスは Windows コンピュータを起動するたびに自動的に起動するようになる。 WebLobic Server インスタンスを Windows サービスとして実行するように設定するには、Windows レジストリを修正する特権を持つユーザアカウントで Windows コンピュータにログインする必要がある。詳細については、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server インスタンスの Windows サービスとしての設定」を参照。 WebLogic Server インスタンスを Windows サービスとして実行するのに、これらの管理者レベルの特権は不要である。その代わり、Windows サービスは WebLogic Server を実行するために作成した特別な OS ユーザアカウント下で実行する必要がある。 WebLogic Server インスタンスが確実に特別な OS ユーザアカウント下で実行されるように、Windows サービスの [プロパティ] ページでユーザ名とパスワードを指定する。詳細については、『WebLogic Server のコンフィグレーションと管理』の「サービスが実行されるユーザアカウントの検証」を参照。
UNIX 上で保護されているポートにバインドするには、ユーザ ID を切り替える、またはネットワークアドレス変換 (NAT) ソフトウェアを使用するよう、WebLogic Server をコンフィグレーションする	UNIX システムでは、特権を付与されたユーザアカウント (大概の場合は root) 下で実行されるプロセスのみが、1024 未満のポートにバインドできる。ただし、WebLogic Server のような長期にわたって実行されるプロセスは、これらの特権を付与されたアカウント下で実行してはならない。その代わり、以下の処理のいずれかを行うことができる。特権を付与されたポートにアクセスする必要のある各 WebLogic Server インスタンスについて、特権を付与されたユーザアカウント下で起動し、特権を付与されたポートにバインドしてから、ユーザ ID を特権のないアカウントに変更するようサーバをコンフィグレーションする。サーバインスタンスの起動にノードマネージャを使用する場合は、セキュアポート上でのみ、また単一の既知のホストのみから、リクエストを受け入れるようにノードマネージャをコンフィグレーションする。 Administration Console オンラインヘルプの「UNIX での保護されたポートへのバインド」を参照。 WebLogic Server インスタンスを特権を持たないアカウントから起動し、ネットワークアドレス変換 (NAT) ソフトウェアを使用して、保護されているポートを保護されないポートにマップするよう、ファイアウォールをコンフィグレーションする。BEA では、NAT ソフトウェアは提供していない。
プロダクションマシンで開発しない	まず開発マシンで開発し、開発が終わりテストが終了したら、コードをプロダクションマシンに移行する。これにより、開発環境でのバグが、プロダクション環境のセキュリティに影響を及ぼすことを防止できる。
開発ソフトウェアおよびサンプルソフトウェアをプロダクションマシンにインストールしない	プロダクションマシンに開発ツールをインストールしない。開発ツールをプロダクションマシンにインストールしないことにより、侵入者が WebLogic Server プロダクションマシンに部分的にアクセスできても、影響を減らすことができる。プロダクションマシンに、WebLogic Server のサンプルアプリケーションをインストールしない。BEA インストールプログラム上で、標準インストールにするかカスタムインストールにするかを尋ねられた場合は、以下の操作を実行する。 1. [カスタムインストール] を選択する。[次へ] をクリックする。 2. [コンポーネントを選択] ページで、[Server Examples] チェックボックスからチェックマークをはずす。[次へ] をクリックする。 BEA インストールプログラムの残りのページの操作を完了する。
セキュリティ監査を有効にする	WebLogic Server が動作するオペレーティングシステムが、ファイルおよびディレクトリアクセスのセキュリティ監査をサポートする場合は、監査ログを使用して、拒否されたディレクトリまたはファイルアクセス違反をトラッキングすることを推奨する。管理者は、監査ログ用に十分なディスクスペースを確保する必要がある。
オペレーティングシステムを保護する追加ソフトウェアの使用を検討する	多くのオペレーティングシステムでは、プロダクション環境を保護するために、追加ソフトウェアを実行することができる。たとえば、侵入検知システム (Intrusion Detection System: IDS) を使用すると、プロダクション環境を変更しようとしたときに、検出できる。使用可能なソフトウェアの情報については、使用しているオペレーティングシステムのベンダに問い合わせる。
オペレーティングシステムのサービスパックおよびセキュリティパッチを適用する	推奨されているサービスパックおよびセキュリティ関連のパッチのリストについては、オペレーティングシステムのベンダに問い合わせる。
最新の BEA のサービスパックを適用し、最新のセキュリティ勧告を実装する	サイトのセキュリティ問題を担当されている方は、新しいセキュリティ勧告についての通知を受け取るために、http://dev2dev.bea.com/advisories の「BEA Advisories & Notifications」ページで登録すること。セキュリティ勧告で推奨されている対策は、「Advisories & Notifications」ページに掲載される。また、各サービスパックがリリースされたら適用すること。サービスパックには、製品の各バージョンおよび以前にリリースされた各サービスパックのすべてのバグの修正が含まれている。サービスパックは、http://commerce.bea.com/downloads からダウンロードできる。 BEA Products でセキュリティ問題が発生した場合は `secalert@bea.com` に報告すること。
プロダクション環境で開発モードの WebLogic Server を実行しない	プロダクションモードでは、プロダクション環境向けにより適切でセキュアな設定で実行されるようにサーバを設定する。
Java Transaction API (JTA) トランザクションログを保護する	「トランザクションのモニタ」で説明しているように、トランザクションログは複数のファイルで構成されている。これらのファイルは、改ざんされないようにオペレーティングシステム固有の方法を用いて保護する必要がある。改ざんされた場合、トランザクションの回復が行えなくなる可能性がある。 JTA の移行を行うには、同じクラスタに属するすべてのサーバに、トランザクションログファイルに対する書き込み、削除、および読み込みのパーミッションが必要になるが、別のドメインまたはクラスタに属するユーザによるアクセスは禁止する必要がある。

ネットワーク接続のセキュリティ

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

表 2-2 ネットワーク接続のセキュリティ

セキュリティアクション	説明
ハードウェアおよびソフトウェアを使用して、ファイアウォールを作成する	ファイアウォールとは、2 つのネットワーク間のトラフィックを制限する機能のこと。ファイアウォールは、ソフトウェアとルータや専用ゲートウェイマシンなどのハードウェアを組み合わせることができる。ファイアウォールでは、プロトコル、要求されたサービス、ルーティング情報、パケット内容、および送信元や送信先のホストやネットワークに基づいて、トラフィックの通過を許可したり否認したりするフィルタが使用される。また、アクセス権を認証されたユーザのみに限定できる。 WebLogic セキュリティサービスでは、境界ベースの認証 (Web サーバ、ファイアウォール、VPN) を実行し、複数のセキュリティトークンタイプおよびプロトコル (SOAP、IIOP-CSIv2) を扱う、サードパーティの ID アサーションプロバイダを使用できる。詳細については、『WebLogic Security の紹介』の「境界認証」を参照。 WebLogic Server でファイアウォールを使用する場合の詳細については、『WebLogic Server クラスタユーザーズガイド』の「クラスタアーキテクチャのセキュリティオプション」を参照。
WebLogic Server の接続フィルタを使用する	ハードウェアおよびサードパーティのソフトウェアを使用してファイアウォールを作成するだけでなく、WebLogic Server の接続フィルタを使用し、プロトコル、IP アドレス、および DNS ノード名に基づいてネットワークトラフィックを制限することを検討する。接続フィルタは、WebLogic Server ドメイン内のマシンがお互いにファイアウォールを通過せずにアクセスできる場合に最も適している。たとえば、ネットワークの外からのトラフィックの制限にはファイアウォールを使用し、ファイアウォールの後ろでのトラフィックの制限には WebLogic Server の接続フィルタを使用できる。『WebLogic Security の管理』の「接続フィルタのコンフィグレーション」を参照。
管理トラフィックにドメイン全体の管理ポートを使用する	管理ポートにより、WebLogic Server ドメインのサーバインスタンス間のすべての管理トラフィックが 1 つのポートに制限される。管理ポートを使用せずにサーバを実行した場合、アプリケーションが誤って機密のサーバコンフィグレーションをネットワーク上でクリアテキストで送信するおそれがある。管理ポートを使用してサーバを実行することで、こうしたハプニングの発生する可能性を大幅に減らすことができる。さらに、管理ポートをコンフィグレーションしておくと、サービス拒否攻撃が発生した場合に便利 (管理ポートリクエストに対する制限により、リクエストを処理するためのリソースがサーバのそれ以外のリソースから切り離されているため)。接続フィルタと組み合わせて使用すると、WebLogic Server インスタンスが、既知のマシンまたはサブセットからのみ、かつ単一のポートでのみ管理要求を受け入れるように指定できる。管理ポートを有効にすると、クライアントは SSL を使用して Administration Console と対話しなければならなくなる。これにより、機密データを攻撃者によるネットワーク上の盗聴や一部のクロスサイトスクリプティング攻撃から保護できる。ドメイン全体の管理ポートは、Administration Console の [DomainName｜コンフィグレーション｜全般] タブで有効にする。 Administration Console オンラインヘルプの「ドメイン全体の管理ポートの有効化」を参照。
管理チャネルを有効にする	サーバ間の管理通信のセキュリティを確保するためには、管理チャネルを有効にする必要がある。管理チャネルがないと、一部の重要な管理メッセージがクリアテキストで渡され、メッセージの捕獲、修正、削除、および再送が可能となる。『WebLogic Server のコンフィグレーションと管理』の「管理ポートと管理チャネル」を参照。
組み込み LDAP ポートを保護する	組み込み LDAP ポートを総当たり攻撃から保護するには、単一サーバコンフィグレーションでは接続フィルタを使用して組み込み LDAP リスンポートを閉じる。この方法では複数サーバコンフィグレーションにおける組み込み LDAP ポートは保護されないが、組み込み実装によって、ドメイン内のサーバからのアクセスのみを許可するのに使用される、ソース IP アドレスに基づくフィルタ処理がサポートされる。そのため、ドメイン内のマシンのみが LDAP ポートにアクセスできる。接続フィルタの使用の詳細については、『WebLogic Security プログラマーズガイド』の「ネットワーク接続フィルタの使い方」を参照。

データベースのセキュリティ

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

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

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

表 2-3 WebLogic セキュリティサービスのセキュリティ

セキュリティアクション	説明
最新の BEA のサービスパックを適用し、最新のセキュリティ勧告を実装する	サイトのセキュリティ問題を担当されている方は、新しいセキュリティ勧告についての通知を受け取るために、http://dev2dev.bea.com/advisories の「BEA Advisories & Notifications」ページで登録すること。セキュリティ勧告で推奨されている対策は、「Advisories & Notifications」ページに掲載される。また、各サービスパックがリリースされたら適用すること。サービスパックには、製品の各バージョンおよび以前にリリースされた各サービスパックのすべてのバグの修正が含まれている。サービスパックは、http://commerce.bea.com/downloads からダウンロードできる。 BEA Products でセキュリティ問題が発生した場合は `secalert@bea.com` に報告すること。
プロダクション対応のセキュリティプロバイダをセキュリティレルムにデプロイする	WebLogic セキュリティサービスでは、複数のセキュリティプロバイダをデプロイでき、各プロバイダでは特定のセキュリティ分野に対応するプラグイン可能なアーキテクチャが使用される。 WebLogic Server には、デフォルトで完全なセキュリティソリューションを提供する独自のセキュリティプロバイダがある。ユーザ独自のセキュリティプロバイダを購入、または記述した場合は、次の操作を実行する。正しくデプロイし、コンフィグレーションしていることを確認する。Administration Console の [セキュリティ｜レルム｜RealmName｜プロバイダ] フォルダで、現在どのセキュリティプロバイダがデプロイされているのかを確認できる。セキュリティプロバイダをデプロイしたレルムがデフォルトの (アクティブ) レルムであることを確認する。左ペインでセキュリティレルムフォルダの名前をクリックし、右ペインでドメインのセキュリティ設定を指定して、Administration Console でレルムをアクティブにする。『WebLogic Security の管理』の「デフォルトセキュリティコンフィグレーションのカスタマイズ」を参照。
プロダクション環境では SSL を使用し、デモ用のデジタル証明書を使用しない	重要なデータを危険から守るには、HTTP プロトコルではなく、SSL および HTTPS プロトコル (セキュアソケットレイヤ (Secure Sockets Layer: SSL) での HTTP) を使用してデータの転送を保護する。 WebLogic Server には、開発のみの目的で、デモ用のプライベートキー、デジタル証明書、および信頼された認証局が用意されている。WebLogic Server をダウンロードするユーザは、これらのデジタル証明書に対してプライベートキーが付属する。デモ用の ID および信頼を使用しないこと。 Administration Console オンラインヘルプの「キーストアおよび SSL のコンフィグレーション」を参照。
最も強力な暗号を有効にする	ダウンロードする WebLogic Server のバージョンでは、512 ビットキーおよび 40 ビットバルク暗号をサポートしている。最強の暗号化 (1024 ビットキーと 128 ビットバルク暗号) を使用する場合は、BEA の販売代理店に問い合わせる。輸出規制があるため、このバージョンの WebLogic Server は、特定国でのみ利用可能である。
WebLogic Server で、デジタル証明書にセキュリティ制約が設定されていることを確認する	SSL を使用して通信するとき、デフォルトでは WebLogic Server は、認証局によって定義された Basic Constraint エクステンションを持たない証明書チェーンのデジタル証明書を拒否する。これにより、デジタル証明書のなりすましから Web サイトを保護する。この設定を無効にする次のオプションを含むサーバ起動コマンドがないことを確認する。 `-Dweblogic.security.SSL.enforceConstraints=false` このオプションは、起動スクリプトにある可能性がある。また、管理対象サーバの起動にノードマネージャを使用する場合は、Administration Console の [サーバ｜ServerName｜コンフィグレーション｜リモートスタート] タブにある可能性がある。開発環境では、7.0 (Service Pack 2) 以前のリリースで WebLogic Server が提供したデモ用のデジタル証明書との非互換性に対処するために、セキュリティ制約の設定を無効にしている可能性がある。プロダクション環境では、この機能を有効にする。
介在者の攻撃を避けるために、ホスト名検証が有効になっていることを確認する	WebLogic SSL はデフォルトで、接続が確立したホストが対象のパーティまたは認可されたパーティであることを検証する。ただし、サイトで WebLogic Server を実装するときに、ホスト名検証が無効になっている場合がある。 Administration Console の [サーバ｜ServerName｜コンフィグレーション｜キーストア & SSL] タブに移動し、[詳細オプション] の [表示] をクリックして、ホスト名検証を有効化できる。『WebLogic Security の管理』の「ホスト名検証の使い方」を参照。 Background Information: ネットワークに配置されたマシンによって、無防備なパーティへのメッセージが取り込まれたり、変更されたり、再送信されると、介在者の攻撃が発生する。接続が確立したホストが対象のパーティまたは認可されたパーティであることを検証すると、介在者の攻撃を避けることができる。SSL クライアントは、SSL サーバのデジタル証明書を使用して、SSL サーバのホスト名を比較することで、接続を検証することができる。WebLogic Server のホスト名検証は、介在者の攻撃から SSL 接続を保護する。
サービス拒否攻撃を防ぐために外部チャネルでのリクエストのサイズおよび時間を制限する	サービス拒否攻撃を防ぐために、WebLogic Server ではメッセージのサイズ、およびメッセージの到着にかかる最大時間を制限できる。デフォルトの設定では、メッセージの最大サイズは 10MB に、メッセージのタイムアウトは 480 秒に制限される。以下の対策を推奨。管理対象サーバが管理サーバからのメッセージを受信できるように、内部チャネルでのリクエストのサイズ制限を設定する。外部チャネルでのリクエストのサイズおよび時間を制限する。外部からではなく内部からのみアクセスできるように内部チャネルをコンフィグレーションする。上記の対策を行うには、HTTP、T3、および IIOP プロトコルの場合、これらの設定を Administration Console の [サーバ｜ServerName｜プロトコル] タブでコンフィグレーションする。 Administration Console オンラインヘルプで次のタスクを参照。 HTTP プロトコルのコンフィグレーション T3 プロトコルのコンフィグレーション IIOP プロトコルの有効化およびコンフィグレーション Background Information: サービス拒否攻撃が実行されると、Web サイトは動作しているが、実行できない。ハッカーは、1 つまたは複数の重要な Web サイトリソースを使い果たしたり、削除したりする。 WebLogic Server インスタンスでサービス拒否攻撃を行うとき、侵入者は、サイズが非常に大きいリクエスト、実行に時間がかかるリクエスト、完了しないリクエストを多数使用してサーバを攻撃することにより、リクエストが完了する前にクライアントによるデータの送信を停止させる。
サーバに対して許可されるソケットの数を設定する	サービス拒否攻撃を防ぐために、サーバに対して許可されるソケットの数を制限する。これにより、オペレーティングシステムの制限によって許可されたファイル記述子の数が超過しなくなる。この設定は MaxOpenSockCount フラグを使用してコンフィグレーションできる。 Administration Console オンラインヘルプで次のタスクを参照。 [サーバ] --> [コンフィグレーション] --> [チューニング]
ユーザアカウントの攻撃を防ぐために、ユーザのロックアウトおよびログイン時間制限をコンフィグレーションする	デフォルトでは、WebLogic セキュリティサービスでは、ユーザアカウントの辞書攻撃に対して、最高度のセキュリティが提供されている。アカウントがロックされるまでの無効なログイン試行回数、アカウントがロックされるまでの無効なログイン試行期間、またはユーザアカウントのロック時間を開発時に変更した場合は、設定内容を確認して、その設定がプロダクション環境に適しているかどうかを検証する必要がある。これらの設定は、Administration Console の [セキュリティ｜レルム｜RealmName｜ユーザロックアウト] タブで検証、または変更できる。 Administration Console オンラインヘルプの「ユーザアカウントの保護」を参照。 Background Information: 辞書攻撃では、ハッカーはスクリプトを作成し、「辞書」に登録されているパスワードを使用してログインを試みる。WebLogic Server のユーザロックアウトおよびログイン設定により、辞書攻撃からユーザアカウントを保護することができる。
複数の認証プロバイダを使用する場合は、JASS 制御フラグを設定する	セキュリティレルムに複数の認証プロバイダがコンフィグレーションされている場合、JAAS 制御フラグを設定して、各プロバイダの順序および優先度をコンフィグレーションする。 JAAS 制御フラグは、Administration Console の [セキュリティ｜レルム｜RealmName｜プロバイダ｜認証｜AuthenticatorName｜全般] タブで設定する。 Administration Console オンラインヘルプの「JAAS 制御フラグの設定」を参照。
セキュリティ監査を有効にする	監査は、主要なセキュリティイベントを WebLogic Server 環境に記録する処理である。WebLogic セキュリティサービスが提供する監査プロバイダを有効にすると、イベントが `DomainName\DefaultAuditRecorder.log` に記録される。 Administration Console の [DomainName｜コンフィグレーション｜全般] タブで、管理変更の監査を有効に設定できる。 Administration Console オンラインヘルプの「コンフィグレーション監査」を参照。 Administration Console の [セキュリティ｜レルム｜RealmName｜プロバイダ｜監査] ページで、監査プロバイダを有効に設定できる。 Administration Console オンラインヘルプの「WebLogic 監査プロバイダのコンフィグレーション」を参照。注意 :監査プロバイダを使用すると、少数のイベントのみが記録される場合でも、WebLogic Server のパフォーマンスが低下する場合がある。監査レコードを定期的に確認し、セキュリティ違反または違反未遂を検出する。度重なるログインの失敗や、予期しないパターンのセキュリティイベントに注目することで、重大な問題を防げる可能性がある。
デフォルトの WebLogic Server セキュリティロールにユーザおよびグループを正しく割り当てたことを確認する	デフォルトでは、すべての WebLogic リソースは、セキュリティロールのデフォルトセットに基づくセキュリティポリシーによって保護されている。目的のユーザおよびグループをこれらのデフォルトセキュリティロールに割り当てる。『WebLogic リソースのセキュリティ』の「セキュリティロール」を参照。
システム管理者特権を持つユーザアカウントを少なくとも 2 つ作成する	システム管理者ユーザアカウントの 1 つは、ドメインの作成時に作成される。それ以外のユーザアカウントを作成し、Admin セキュリティロールを割り当てる。システム管理者ユーザアカウントの作成時には、簡単に推測されないユニークな名前にする。少なくとも 2 つのシステム管理者ユーザアカウントを作成することにより、辞書攻撃や総当たり攻撃によって一方のユーザがロックアウトされた場合でも、もう一方のユーザがアカウントアクセスを保持できる。
WebLogic Server が HTTP 応答で名前およびバージョン番号を送信しないように考慮する	デフォルトでは、WebLogic Server のインスタンスが HTTP リクエストに応答するとき、HTTP 応答ヘッダには、サーバ名および WebLogic Server のバージョン番号が含まれる。攻撃者が WebLogic Server の特定のバージョンの脆弱性についての知識がある場合、これによりセキュリティリスクが発生する可能性がある。 WebLogic Server インスタンスがその名前およびバージョン番号を送信しないようにするには、Administration Console で [Send Server Header を有効化] 属性を無効にする。この属性は、[サーバ｜ServerName｜コンフィグレーション｜プロトコル｜HTTP] タブの [詳細オプション] セクションにある。

アプリケーションのセキュリティ

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

表 2-4 アプリケーションのセキュリティ

セキュリティアクション	説明
どの技術が Web アプリケーションおよび EJB を保護しているのかを判断する	デフォルトでは、各 Web アプリケーションおよび EJB はデプロイメント記述子 (XML ファイル) を使用して、保護されたリソースおよびそれにアクセスできるセキュリティロールを宣言する。 Web アプリケーションおよび EJB デプロイメント記述子でセキュリティを宣言せずに、Administration Console を使用して、Web アプリケーションおよび EJB へのアクセスを保護するセキュリティポリシーを設定することができる。この技術により、すべての Web アプリケーションおよび EJB に対するセキュリティを、1 つの場所から集中管理できる。これらの 2 つの技術を組み合わせ、URL (Web) または EJB リソースの初期デプロイメントで、既存のデプロイメント記述子からセキュリティコンフィグレーションをコピーするように WebLogic Server をコンフィグレーションできる。これらのセキュリティコンフィグレーションをコピーした後は、Administration Console を使用して更新できる。『WebLogic リソースのセキュリティ』の「セキュリティロール」を参照。
HTML コメントタグではなく、JSP コメントタグを使用する	エンドユーザを対象としていない JSP ファイル内のコメントには、HTML 構文の `<!-- ... -->` ではなく、JSP 構文の `<%/` ... `/%>` を使用する。JSP コメントは、JSP がコンパイルされると削除され、表示できなくなる。
プロダクションマシンには未コンパイルの JSP およびその他のソースコードをインストールしない	常に、ソースコードをプロダクションマシンに置かないようにする必要がある。ソースコードにアクセスすると、侵入者はセキュリティホールを発見できる。 JSP をプリコンパイルし、コンパイルされた JSP のみプロダクションマシンにインストールすることを検討する。JSP のプリコンパイルの詳細については、『WebLogic JSP プログラマーズガイド』の「JSP のプリコンパイル」を参照。
SSL を使用するようにアプリケーションをコンフィグレーションする	`web.xml` ファイルの `user-data-constraint` 要素で `transport-guarantee` を `CONFIDENTIAL` に設定する。『WebLogic Server Web アプリケーションの開発』の「security-constraint」を参照。
SSL を使用してトランザクションデータの整合性を保証する	『WebLogic Security プログラマーズガイド』の「SSL を使用するアプリケーションの記述」で説明しているように、BEA WebLogic Server は、WebLogic Server クライアントとサーバ、Java クライアント、Web ブラウザ、および他のサーバの間で転送されるデータを暗号化するためにセキュアソケットレイヤ (SSL) をサポートしている。RMI 呼び出しによって転送されるトランザクションデータの整合性を保証するためには、アプリケーションで SSL を使用する必要がある。アプリケーションは、RMI を使用してリモート呼び出しを行い、EJB や JDBC リソースなどのリモートオブジェクトを呼び出すことができる。これらの RMI 呼び出しがトランザクションのスコープ内で行われた場合、そのトランザクションコンテキストは RMI 呼び出しとともに伝播される。したがって、トランザクションのスコープ内でリモート呼び出しを行うアプリケーションでは、トランザクションコンテキスト、アプリケーションデータ、およびセキュリティコンテキストが改ざんされないように、SSL を使用する必要がある。改ざんされた場合、データの整合性に影響が生じる可能性がある。
`Servlet` サーブレットを使用しない	プロダクション環境での `Servlet` サーブレットの使用はお勧めしない。代わりに、サーブレットを URI に明示的にマップする。プロダクション環境で Web アプリケーションを使用する前に、すべての Web アプリケーションから、WebLogic サーブレットと `Servlet` サーブレットの間の既存のマッピングをすべて削除する。サーブレットのマップの詳細については、『WebLogic Server Web アプリケーションの開発』の「サーブレットのコンフィグレーション」を参照。
プロダクション環境で、`FileServlet` をデフォルトサーブレットとして使用しない	プロダクション環境で `FileServlet` サーブレットをデフォルトサーブレットとして使用することはお勧めしない。デフォルトサーブレットの設定の詳細については、『WebLogic Server Web アプリケーションの開発』の「デフォルトサーブレットの設定」を参照。
すべての WebLogic セキュリティポリシーを確認する	WebLogic Server 7.0 では、ACL に代わってセキュリティポリシーが使用され、WebLogic リソースに誰がアクセスしたのかを判断する。 WebLogic リソースからセキュリティポリシーを削除していないこと、およびセキュリティロールの割り当てによってユーザに目的のアクセス権を提供していることを確認する。『WebLogic リソースのセキュリティ』を参照。
アプリケーションのセキュリティを検査する	アプリケーションにセキュリティの脆弱性がもたらされるおそれのある典型的な事例がある。これらの事例の多くは、OWASP (Open Web Application Security project) などの第三者組織によって定義されている (よくある問題のリストについては http://www.owasp.org/documentation/topten.html を参照)。 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 Security プログラマーズガイド』の「Java セキュリティマネージャを使用しての WebLogic リソースの保護」を参照。
サーブレットまたは JSP がユーザの供給によるデータを返した場合に、HTML 特殊文字を置換する	ユーザが入力したデータを返す機能により、クロスサイトスクリプトと呼ばれるセキュリティの脆弱性がもたらされる。これは、ユーザのセキュリティ認可を盗用するために利用される可能性がある。クロスサイトスクリプティングの詳細については、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 サーブレットプログラマーズガイド』の「サーブレットでのクライアント入力のセキュリティ」を参照。