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

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

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

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

表 3-1 WebLogic Server ホストのセキュリティ
セキュリティアクション	説明
ハードウェアを物理的に保護する	権限のないオペレーティングシステムのユーザが、デプロイメントマシンまたはそのネットワーク接続を変更できないように、ハードウェアを安全な場所に置く。
オペレーティングシステムが提供するネットワークサービスを保護する	悪意のある攻撃者がオペレーティングシステムにアクセスしたり、システムレベルのコマンドを実行したりできないように、電子メールプログラムまたはディレクトリサービスなどのネットワークサービスについて専門家に確認してもらう。使用するオペレーティングシステムによって方法は異なる。ファイルシステムを企業ネットワーク内の他のマシンと共有する場合、そのファイルシステムはリモート攻撃される危険性がある。WebLogic Server をホストするマシンのファイルシステムを共有する前に、リモートマシンとネットワークがセキュアであるかどうかを確認すること。
不正アクセスを防ぐことのできるファイルシステムを使用する	各 WebLogic Server ホスト上のファイルシステムで、保護されているリソースへの不正なアクセスができないようになっていることを確認する。たとえば、Windows コンピュータでは、NTFS のみを使用する。
ディスクに保存されたデータにファイルアクセスパーミッションを設定する	ディスクに保存されたデータへのアクセスを制限するために、オペレーティングシステムのファイルアクセスパーミッションを設定する。このデータには以下が含まれる (ただしこれに限るものではない)。セキュリティ LDAP データベース。デフォルトでは `\domains\domain-name\servers\server-name\data\ldap\ldapfiles`。プライベートキーストアのディレクトリとファイル名の場所。「プライベートキー、デジタル証明書、信頼性のある認証局の格納」を参照。ルート認証局 (CA) キーストアのディレクトリとファイル名の場所。「プライベートキー、デジタル証明書、信頼性のある認証局の格納」を参照。たとえば Unix、Linux などのオペレーティングシステムには、ファイルアクセスパーミッションの設定用に umask や chmod といったユーティリティが用意されている。少なくとも、Group と Others に対する読み取りおよび書き込みパーミッションを拒否する「umask 066」の使用を検討する。
永続ストアに保存されたデータにファイルアクセスパーミッションを設定する	永続ストアに保存されたデータへのアクセスを制限するために、オペレーティングシステムのファイルアクセスパーミッションを設定する。「永続ストアの概要」に、永続ストアへの接続を作成できる WebLogic サービスおよびサブシステムの多くを示す。これには以下が含まれる。 JMS メッセージ。JMS メッセージについては、『WebLogic JMS プログラマーズガイド』の「メッセージングモデルについて」を参照。 Web サービス。Web サービスについては、『WebLogic Web サービスプログラマーズガイド (応用編)』の「Web サービスの信頼性のあるメッセージングの使用」を参照。 EJB タイマーサービス。EJB タイマーサービスについては、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズガイド』の「EJB タイマーサービスのプログラミング」を参照。ストアアンドフォワードサービス。ストアアンドフォワードサービスについては、『WebLogic ストアアンドフォワードのコンフィグレーションと管理』の「ストアアンドフォワードサービスについて」を参照。 JTA トランザクションログ (TLOG)。JTA トランザクションログについては、『WebLogic JTA プログラマーズガイド』の「トランザクションの管理」を参照。デフォルト永続ストアは、ドメインのルートディレクトリの `servername` サブディレクトリにある `data\store\default` ディレクトリに保持される。
ホストマシンのユーザアカウント数を制限する	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」などの分かりやすい名前を選択しないようにする。
パスワードを保護する	プロダクションマシンのユーザアカウントのパスワードは、推測が難しいものに設定し、注意して守る必要がある。パスワードの有効期限が定期的に切れるように、ポリシーを設定する。クライアントアプリケーションでパスワードをコーディングすることは避ける。
各ホストコンピュータでは、アクセス特権を持つ 2 つのシステム管理者ユーザのほかに、1 つのユーザアカウントにのみ WebLogic リソースへのアクセス権を付与する	各 WebLogic Server ホストコンピュータでは、オペレーティングシステムを使用して、WebLogic Server の実行用に特別なユーザアカウント (`wls_owner` など) を設定する。このオペレーティングシステム (operating-system: OS) のユーザアカウントには、以下の特権を付与する。 BEA ホームディレクトリ、WebLogic Server 製品ディレクトリツリー、およびドメインディレクトリのみに対するアクセス特権。 BEA ホームディレクトリとは共通ファイル用のリポジトリのことで、同じマシンにインストールされる複数の BEA Products が使用する。WebLogic Server 製品インストールディレクトリには、プログラムファイルを含む、システムにインストールする WebLogic Server ソフトウェアコンポーネントがすべて含まれる。ドメインディレクトリには、コンフィグレーションファイル、セキュリティファイル、ログファイル、Java EE アプリケーション、および単一の WebLogic ドメイン用のその他の Java EE リソースが含まれる。WebLogic Server ホストコンピュータに複数のドメインをインストールする場合、各ドメインディレクトリを保護する必要がある。デフォルトでは、BEA インストールプログラムによってすべての BEA ファイルとドメインディレクトリが単一のディレクトリツリーに格納される。このツリーの最上位ディレクトリの名前は `bea` である。WebLogic Server ファイルはすべてこのディレクトリツリーのサブディレクトリ (`bea\wlserver_10.0`) にあり、ドメインファイルは別のサブディレクトリ (`bea\user_projects\domains\domain1`、 `bea\user_projects\domains\domain2`、...) にある。ただし、WebLogic Server 製品インストールディレクトリおよびドメインディレクトリを BEA ホームディレクトリの外部に配置することもできる。詳細については、『インストールガイド』の「インストールのためのディレクトリの選択」を参照。その他の OS ユーザには、BEA ファイルおよびドメインファイルへの読み込みアクセス権、書き込みアクセス権、または実行アクセス権を付与しない (システム管理者ユーザは、デフォルトでアクセス特権を保持する)。これにより、WebLogic Server と同じマシンで実行されている他のアプリケーションの BEA ファイルおよびドメインファイルへのアクセスが制限される。このように保護しないと、その他のアプリケーションの一部は書き込みアクセス権を得て、動的コンテンツを提供する JSP およびその他のファイルに悪意のある実行コードを挿入する可能性がある。そのファイルが次にクライアントに提供されると、挿入されたコードが実行される。
各ホストコンピュータでは 1 つのユーザアカウントにのみ WebLogic リソースへのアクセス権を付与する (続き)	知識の豊富なオペレーティングシステムのユーザが、以下のファイルに対して書き込みアクセス権 (場合によっては読み込みアクセス権) を付与されている場合、WebLogic Server のセキュリティを無視することができる。 WebLogic Server インストール JDK ファイル (通常、WebLogic Server インストール内にある。ただし、別になるようにコンフィグレーションできる) ドメインディレクトリ JMS SAF ファイル HTTP セッションをバックアップしたファイル永続ストアを使用するすべてのファイル (JMS SAF ファイルなど) には、読み込みアクセス権と書き込みアクセス権から保護する必要のある重要なデータがある。永続ストアは、ファイルベースのストアまたは JDBC 対応データベースの永続性をサポートする。ファイルストアを使用して WebLogic Server でファイルを保存する場合、アプリケーションを任意の場所に保存できる。読み込みアクセス権および書き込みアクセス権からアプリケーションを保護するには、すべてのファイルの場所を覚えておく必要がある。 JDBC ストアを使用してアプリケーションを保存する場合、読み込みアクセス権および書き込みアクセス権から JDBC ストアを守ることでデータベースを適切に保護する。永続ストアの使用の詳細については、『WebLogic Server 環境のコンフィグレーション』の「WebLogic 永続ストアの使い方」を参照。
UNIX 上で保護されているポートにバインドするには、ユーザ ID を切り替える、またはネットワークアドレス変換 (NAT) ソフトウェアを使用するよう、WebLogic Server をコンフィグレーションする	UNIX システムでは、特権を持つユーザアカウント (ほとんどの場合、root) で実行されるプロセスのみを、1024 より小さいポートにバインドできる。UNIX システムでは、システム管理者 (root) ユーザのみが許可される。ただし、WebLogic Server のような長期にわたって実行されるプロセスは、これらの特権を付与されたアカウント下で実行してはならない。その代わり、以下の処理のいずれかを行うことができる。特権を付与されたポートにアクセスする必要のある各 WebLogic Server インスタンスについて、特権を付与されたユーザアカウント下で起動し、特権を付与されたポートにバインドしてから、ユーザ ID を特権のないアカウントに変更するようにサーバをコンフィグレーションする。サーバインスタンスの起動にノードマネージャを使用する場合は、セキュアポート上でのみ、また単一の既知のホストのみから、要求を受け入れるようにノードマネージャをコンフィグレーションする。なお、ノードマネージャは特権を付与されたユーザアカウントで起動する必要がある。 Administration Console オンラインヘルプの「UNIX 上で実行するマシンの作成とコンフィグレーション」を参照。 WebLogic Server インスタンスを特権を持たないアカウントから起動し、ネットワークアドレス変換 (NAT) ソフトウェアを使用して、保護されているポートを保護されないポートにマップするよう、ファイアウォールをコンフィグレーションする。BEA では、NAT ソフトウェアは提供していない。
プロダクションマシンで開発しない	まず開発マシンで開発し、開発が終わりテストが終了したら、コードをプロダクションマシンに移行する。これにより、開発環境でのバグが、プロダクション環境のセキュリティに影響を及ぼすことを防止できる。
開発ソフトウェアおよびサンプルソフトウェアをプロダクションマシンにインストールしない	プロダクションマシンに開発ツールをインストールしない。開発ツールをプロダクションマシンにインストールしないことにより、侵入者が WebLogic Server プロダクションマシンに部分的にアクセスできたとしても、影響を減らすことができる。プロダクションマシンに、WebLogic Server のサンプルアプリケーションをインストールしない。BEA インストールプログラム上で、標準インストールにするかカスタムインストールにするかを尋ねられた場合は、以下の操作を実行する。 [カスタムインストール] を選択する。[次へ] をクリックします [コンポーネントを選択] ページで、[Server Examples] チェックボックスからチェックマークをはずす。[次へ] をクリックします BEA インストールプログラムの残りのページの操作を完了する。
セキュリティ監査を有効にする	WebLogic Server が動作するオペレーティングシステムが、ファイルおよびディレクトリアクセスのセキュリティ監査をサポートする場合は、監査ログを使用して、拒否されたディレクトリまたはファイルアクセス違反を追跡することを推奨する。管理者は、監査ログ用に十分なディスクスペースを確保する必要がある。
オペレーティングシステムを保護する追加ソフトウェアの使用を検討する	多くのオペレーティングシステムでは、プロダクション環境を保護するために、追加ソフトウェアを実行することができる。たとえば、侵入検知システム (Intrusion Detection System: IDS) を使用すると、プロダクション環境を変更しようとしたときに検出できる。使用可能なソフトウェアの情報については、使用しているオペレーティングシステムのベンダに問い合わせる。
オペレーティングシステムのサービスパックおよびセキュリティパッチを適用する	推奨されているサービスパックおよびセキュリティ関連のパッチのリストについては、オペレーティングシステムのベンダに問い合わせる。
BEA の最新のサービスパックを適用し、最新のセキュリティ勧告を実装する	サイトのセキュリティ問題の担当者は、新しいセキュリティ勧告に関する通知を受け取るために、http://dev2dev.bea.com/advisoriesnotifications の「Security Advisories and Notifications」ページで登録する。セキュリティ勧告で推奨されている対策は、「Security Advisories and Notifications」ページに掲載される。また、各サービスパックがリリースされたら適用すること。サービスパックには、製品の各バージョンおよび以前にリリースされた各サービスパックのすべてのバグの修正が含まれている。サービスパックは、http://www.beasys.co.jp/evaluation/index.html でダウンロード可能。 BEA Products でセキュリティ問題が発生した場合は `secalert@bea.com` に連絡する。
プロダクション環境では開発モードで WebLogic Server を実行しない	プロダクションモードでは、プロダクション環境にとってよりセキュアで適切な設定を使用してサーバが実行されるように設定される。

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

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

表 3-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 Server のセキュリティ』の「接続フィルタの使用」を参照。
管理トラフィックにドメイン全体の管理ポートを使用する	管理ポートにより、WebLogic Server ドメインのサーバインスタンス間のすべての管理トラフィックが 1 つのポートに制限される。管理ポートを使用せずにサーバを実行すると、サーバの機密性のあるコンフィグレーションがアプリケーションからネットワーク上にクリアテキストで送信されてしまう可能性がある。管理ポートを使用してサーバを実行すれば、この問題が起こる可能性は大幅に低くなる。さらに、管理ポートをコンフィグレーションすると、要求を処理するためのリソースや管理ポートの要求に対する制限がサーバの他の部分と異なるためにサービス拒否攻撃が発生した場合に便利。接続フィルタと組み合わせて使用すると、WebLogic Server インスタンスが、既知のマシンまたはサブセットからのみ、かつ単一のポートでのみ管理要求を受け入れるように指定できる。管理ポートを有効にするには、クライアントが SSL を使用して Administration Console と対話する必要がある。SSL では、ネットワーク上での攻撃者による重要なデータの傍受や一部のクロスサイトスクリプティング攻撃を防止している。 Administration Console オンラインヘルプの「ドメイン全体の管理ポートのコンフィグレーション」および「コンフィグレーション監査の有効化」を参照。
組み込み LDAP ポートを保護する	総当たり攻撃から組み込み LDAP ポートを保護するには、接続フィルタを使用して、単一のサーバコンフィグレーションで組み込み LDAP リスンポートを閉じる。この方法では、複数のサーバコンフィグレーションで組み込み LDAP ポートを保護しないが、デフォルトの接続フィルタを実装すると、ドメインを構成するサーバからのアクセスのみを許可する際に使用する、ソースの IP アドレスに基づいたフィルタリングがサポートされる。この結果、ドメイン内のマシンのみが LDAP ポートにアクセスできる。接続フィルタの使用については、『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 セキュリティ機能 (http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html#remote を参照) によってのみ保護できる。WebLogic Server 実行時 MBean サーバをプラットフォーム MBean サーバとしてコンフィグレーションした場合、プラットフォーム MBean サーバへのリモートアクセスを有効にすると WebLogic Server MBean へのアクセスパスが作成される。このアクセスパスは、WebLogic Server セキュリティフレームワークでは保護されない。リモートの JMX クライアントが JVM MBean にアクセスできるようにする必要がある場合は、WebLogic Server の実行時 MBean サーバを介してアクセスすることをお勧めする。『JMX による管理の容易なアプリケーションの開発』の「JVM プラットフォーム MBean サーバへの MBean の登録」を参照。

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

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

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

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

セキュリティアクション

説明

プロダクション対応のセキュリティプロバイダをセキュリティレルムにデプロイする

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

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

正しくデプロイおよびコンフィグレーションしていることを確認する。Administration Console に現在デプロイされているセキュリティプロバイダを確認できる。Administration Console の左ペインで [セキュリティレルム] を選択後、レルムの名前をクリックして [プロバイダ] タブを選択する。
セキュリティプロバイダをデプロイしたレルムがデフォルトの (アクティブ) レルムであることを確認する。Administration Console でデフォルトセキュリティレルムを設定する手順については、Administration Console オンラインヘルプの「デフォルトセキュリティレルムの変更」を参照。
『WebLogic Server のセキュリティ』の「デフォルトセキュリティコンフィグレーションのカスタマイズ」を参照。

プロダクション環境では SSL を使用し、デモ用のデジタル証明書を使用しない

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

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

Adminstration Console オンラインヘルプの「サーバ : コンフィグレーション : キーストア」および『WebLogic Server のセキュリティ』の「SSL のコンフィグレーション」を参照。

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

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

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

-Dweblogic.security.SSL.enforceConstraints=false

このオプションの詳細については、『WebLogic Server のセキュリティ』の「SSL 証明書の検証」を参照。

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

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

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

ホスト名検証を有効にするには、Administration Console オンラインヘルプの「カスタムホスト名検証のコンフィグレーション」を参照。

『WebLogic Server のセキュリティ』の「ホスト名検証の使い方」を参照。

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

サービス拒否攻撃を防ぐために、外部チャネルに対して要求のサイズおよび時間を制限する

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

以下を推奨。

管理対象サーバが管理サーバからのメッセージを受信できるように内部チャネルに対して要求のサイズを制限する。
外部チャネルに対して要求のサイズおよび時間を制限する。
外部からではなく、内部からのメッセージのみを受信できるように内部チャネルをコンフィグレーションする。

HTTP、T3、および IIOP プロトコルでこれらの設定をコンフィグレーションするには、Administration Console オンラインヘルプの以下のタスクを参照。

予備知識 :
サービス拒否攻撃が実行されると、Web サイトは動作しているが、使用できない。ハッカーは、1 つまたは複数の重要な Web サイトリソースを使い果たしたり、削除したりする。

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

サービス拒否攻撃を防ぐために、サーバに許可されるソケット数を設定する

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

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

MaxOpenSockCount flag を使用してこの設定のコンフィグレーションが可能。

Administration Console オンラインヘルプの「サーバ : コンフィグレーション : チューニング」を参照。

過負荷状態を回避するために、WebLogic Server をコンフィグレーションする

過負荷状態を回避して十分な処理能力を得られるように WebLogic Server をコンフィグレーションする。サーバにかかる負荷が大きい場合に、管理者が WebLogic Server に接続して問題を修正できるようにする。

システムが過負荷状態のときには、管理チャネルを介した通信は妨げられないため、現在の過負荷がどのような状態であっても管理者は常に接続できる。

負荷が大きい場合、管理者はサーバを管理状態にして、不正なユーザを探し出し、そのユーザが要求によってサーバを過負荷状態にすることを防止する。

過負荷状態を回避するために WebLogic Server をコンフィグレーションするには、過負荷保護の MBean で共有容量の属性を設定する。管理者からではない要求が WebLogic Server で受信されなくなった後は、この属性で選択した設定がしきい値となる。

過負荷状態の詳細については、『WebLogic Server 環境のコンフィグレーション』の「過負荷の回避と管理」を参照。

ユーザアカウントの攻撃を防ぐために、ユーザのロックアウトおよびログイン時間制限をコンフィグレーションする

WebLogic Security サービスには、デフォルトでユーザアカウントの辞書攻撃および総当たり攻撃に対するセキュリティが用意されている。アカウントがロックされるまでの無効なログイン試行回数、アカウントがロックされるまでの無効なログイン試行期間、またはユーザアカウントのロック時間を開発時に変更した場合は、設定内容を確認して、その設定がプロダクション環境に適しているかどうかを検証する必要がある。

Administration Console オンラインヘルプの「ユーザアカウントの保護」を参照。

予備知識 :
辞書攻撃および総当たり攻撃では、ハッカーはスクリプトを作成し、「辞書」に登録されているパスワードを使用してログインを試行する。WebLogic Server のユーザロックアウトおよびログイン設定により、辞書攻撃および総当たり攻撃からユーザアカウントを保護することができる。

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

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

Administration Console オンラインヘルプの「JAAS 制御フラグの設定」を参照。

セキュリティ監査を有効にする

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

Administration Console の [セキュリティレルム｜RealmName｜プロバイダ｜監査] ページで、監査プロバイダを有効にする。

Administration Console オンラインヘルプの「監査プロバイダのコンフィグレーション」を参照。

注意 :

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

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

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

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

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

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

『ロールおよびポリシーによる WebLogic リソースの保護』の「ユーザ、グループ、セキュリティロール」を参照。

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

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

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

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

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