|
|
|
|
|
|
| | | |
WebLogic Server デプロイメントのセキュリティ対策
以下の節では、WebLogic Server のセキュリティ機能を使用して、デプロイメントを保護する方法を説明します。
WebLogic Server のセキュリティが重要な理由
アプリケーション サーバは、エンド ユーザと貴重なデータやリソースとの間の重要なレイヤに位置しています。WebLogic Server は、リソースの保護に関して認証および暗号化サービスを提供します。しかし、こうしたサービスでは、デプロイメント環境の弱点を見つけ出して悪用することでアクセスを取得した侵入者から、リソースを守ることはできません。
インターネットまたはイントラネット上で WebLogic Server をデプロイする場合には、独立したセキュリティ専門家に依頼して、セキュリティ プランと手順を検討してもらい、インストール済みシステムの監査を受け、改善点のアドバイスを受けるとよいでしょう。
セキュリティ問題についてできる限り知識を増やすことも重要です。Web サーバのセキュリティ対策の最新情報については、カーネギー メロン大学が運営する CERT(TM) Coordination Center が公開している「Security Improvement Modules, Security Practices, and Technical Implementations」に目を通すことをお勧めします。
BEA の「
security advisories」ページで推奨されている対策は是非、実行してください。また、リリースされている各サービス パックの適用もお勧めします。サービス パックには、製品の各バージョンおよび以前にリリースされた各
サービス パックのすべてのバグの修正が含まれています。BEA 製品にセキュリティ関連の問題が発生した場合は、BEA から、その報告と適切な対策を示した指示が配信されます。サイトのセキュリティ問題を担当されている方は、今後、BEA からセキュリティ関連の問題の通知を受信できるよう、登録を行ってください。BEA では、BEA 製品に関するセキュリティ問題をご報告いただくための電子メール アドレス（security-report@bea.com）も用意しています。
さらに、WebLogic Server のプロダクション環境の保護に役に立つ、パートナ製品もあります。詳細については、 BEA パートナのページを参照してください。
この章では、WebLogic Server に関する具体的なヒントと一般的なヒントを取り上げます。
WebLogic Server デプロイメントに必要なセキュリティの決定
WebLogic Server デプロイメントのセキュリティ対策を行う前に、WebLogic Server 環境で必要なセキュリティを把握してくおくことが重要です。セキュリティ ニーズを明確に把握するために、次の質問の回答を検討してください。
WebLogic Server 環境には、WebLogic Server がアクセスするデータベース内の情報、Web サイトの可用性、パフォーマンス、および整合性を始めとして、保護可能な数多くのリソースがあります。セキュリティのレベルを決める際に、保護するリソースを十分検討します。
ほとんどの Web サイト リソースの場合は、インターネット上のすべてのユーザから保護しなければなりません。しかし、社内のイントラネット上で従業員から Web サイトを保護する必要がありますか。従業員がすべての WebLogic Server リソースにアクセスする必要がありますか。システム管理者がすべての WebLogic Server リソースにアクセスする必要がありますか。システム管理者はすべてのデータにアクセスできる必要がありますか。機密性の高いデータや重要なリソースへのアクセスは、十分に信頼できるごく一部のシステム管理者に限定した方がよい場合もあります。また、データやリソースには、システム管理者がアクセスできないようにする方がよい場合もあります。
場合によっては、セキュリティ スキーマの欠点が簡単に見つけられても迷惑なだけということもあります。また、欠点が原因で、Web サイトを利用する会社や個人の顧客に大きな損害を与えることもあります。各リソースのセキュリティが失敗した場合の結果を理解しておくと、適切な保護のレベルを判断する参考になります。
サイトのセキュリティ対策に関する以下のヒントに目を通す際には、上記の質問に対する回答を念頭に置いてください。
WebLogic Server を実行するマシンのセキュリティ対策
WebLogic Server デプロイメントのセキュリティは、デプロイメントが実行されるマシンのセキュリティと同じです。したがって、物理的なマシン、オペレーティング システム、およびホスト マシン上にインストールされたその他のすべてのソフトウェアのセキュリティ対策を取ることが重要です。ただし、以下のヒントはデプロイメント用マシンのセキュリティ対策に関するもので、マシン、オペレーティング システム、インストール済みソフトウェアに関しては、製造元に確認する必要があります。
UNIX 上の保護されたポートへのアクセス
UNIX システムでは、特権のあるユーザ アカウント (普通は root) で実行されるプロセスだけが、1024 未満のポートにバインドできます。
ただし、WebLogic Server のように長時間実行されるプロセスは、特権のあるアカウントで実行することはできません。代わりに、次のいずれかの方法を使用します。
ノード マネージャを使用してサーバ インスタンスを起動する場合は、セキュア ポートだけで、単一の既知のホストだけからリクエストを受け取るように、ノード マネージャをコンフィグレーションします。
『Administration Console オンライン ヘルプ』の「UNIX 上の保護されたポートへのバインド」を参照してください。
ネットワーク接続の設計
ネットワーク接続を設計する場合は、管理が最も簡単なソリューションの使用を検討します。ソリューションを選ぶには、保護を必要とする重要な WebLogic Server リソースとのバランスを検討しなければなりません。WebLogic Server リソースの設置場所が潜在的な侵入者から遠いほど、セキュリティ侵害の危険性が抑えられます。社内にファイアウォールを導入すると、セキュリティが強固になり、小さなセキュリティの欠点があっても危機的な状況にならずに済みます。たとえば、重要なデータを格納するデータベースはファイアウォールの内側で保護するとよいでしょう。また、データベースのホスト マシンだけでなく、データベース用のユーザ名とパスワードも保護します。誰かがデータベース用のユーザ名とパスワードを入手した場合でも、データベースがファイアウォールで保護されており、インターネット上のコンピュータからの接続を受け取れなければ、損害はほとんどありません。
ファイアウォール、WebLogic Server、およびネットワーク サーバを組み合わせるさまざまな方法があります。 図 3-1 は、WebLogic Server クラスタ宛てのトラフィックをフィルタ処理するファイアウォールを使った代表的な設定を示しています。
図3-1 代表的なファイアウォールの設定
HTTP または HTTPS の Web 接続だけにアクセスを制限するファイアウォール コンフィグレーションも一般的です。ファイアウォールを使用すると、クライアントは、一般に標準の HTTP ポート 80 または HTTPs ポート 443 で動作する Web サーバにのみアクセスを許可されます。Web サーバは、WebLogic Server でも、WebLogic Server へのリクエストをプロキシするサードパーティ製 Web サーバであってもかまいません。たとえば、Netscape Enterprise Server、Microsoft Internet Server、および Apache Server を設定すると、静的な Web ページを提供して、WebLogic Server に対するサーブレットおよび JSP リクエストをプロキシできます。 図 3-2 はこのコンフィグレーションを示しています。
図 3-2 では、Web サーバは非武装地帯（DMZ）で動作するゲートウェイです。コンピュータ ネットワークに関して DMZ とは、会社のプライベート ネットワークと外部のパブリック ネットワークとの間の中立ゾーンとして配置されたコンピュータ ホストまたは小規模ネットワークのことです。これにより、外部のユーザが会社のデータを納めたサーバに直接アクセスすることはできなくなります。DMZ はファイアウォールのオプションの実装方法で、ファイアウォールがプロキシ サーバとしての役割も果たし、セキュリティはさらに強固になります。WebLogic Server の接続は、プロキシされた Web サーバのリクエストだけに基づいているので、WebLogic Server アプリケーションおよびバックエンド リソースのセキュリティが向上します。 図 3-2 のコンフィグレーションでは、クライアントは Web サーバとだけ対話し、WebLogic Server の接続はプロキシされた Web サーバのリクエストだけに基づいて作成されます。その結果、この方法でコンフィグレーションされている WebLogic Server アプリケーションとバックエンド リソースのセキュリティが向上します。
図3-2 Web サーバ ゲートウェイとファイアウォール
ファイアウォールを設定する以外にも、weblogic.security.net.ConnectionFilter インタフェースを実装することで、WebLogic Server デプロイメントへのアクセスを制限できます。このインタフェースを実装すると、接続の起点のマシンのホスト名およびネットワーク アドレスと使用プロトコルに基づいて、ネットワーク接続を受け付けたり拒否したりできます。
WebLogic Server の開発環境とプロダクション環境の管理
さまざまな理由により、プロダクション環境に近いマシンで開発した方が開発もプロダクションも容易です。ただし、セキュリティを考慮して、開発環境とプロダクション環境は以下のように区別します。
<!-- ... --> ではなく、JSP 構文の <%/* ... */%> を使用します。JSP のコンパイル時に JSP のコメントが削除され、参照できなくなるからです。また、JSP ソースの保護強化のために、Administration Console の [ファイル] タブの [大文字/小文字を区別する] フィールドを無効にします。
暗号化の使用
暗号化とは、理解できないようにテキストなどのデータの形式を変換する処理のことです。解読とは、逆に、テキストなどのデータを理解可能な形式に変換する処理のことです。解読処理には、プライベート キーまたはパスワードが必須です。プライベート キーはビットからなる長い文字列で、解読アルゴリズムが正しく機能するための引数として必要になります。暗号化アルゴリズムの強度は、鍵に含まれるビットの数を基準に評価されます。
暗号化のタイプは数多く、それぞれがさまざまな強度で機能します。各アルゴリズムで最も大きな違いは、データの解読にどれだけの CPU 時間が必要で、何個の鍵を使うか（対称鍵アルゴリズムでは暗号化と解読に鍵を 1 個しか使わず、公開鍵アルゴリズムでは暗号化用の 1 個と解読用の 1 個の合わせて 2 個の鍵を使います）という点です。
一般に暗号化は、重要な情報を保存したりやりとりしたりする場所で利用されます。こうした場所は、ネットワーク上のマシン、ディスク、データベース、メモリ、レガシー システムなどさまざまです。
暗号化には以下の欠点があります。
WebLogic Server デプロイメントに関して暗号化を計画する際には、以下の質問の回答を検討してください。
SSL プロトコルの使用
ネットワーク（インターネットまたはイントラネット）上を送信されるデータは、ネットワーク上の相手方が参照できます。ネットワークの目的からすると、これは避けることができません。重要なデータを危険から守るには、データを暗号化する必要があります。
インターネット上で暗号化済みデータを送信するには、HTTP プロトコルではなく、HTTPS プロトコル（セキュア ソケット レイヤ（SSL）上の HTTP）を使用すべきです。SSL プロトコルに合わせて Web アプリケーションをコンフィグレーションするには、web.xml ファイル内で user-data-constraint タグを使用し、transport-guarantee を CONFIDENTIAL に設定しなければなりません。
WebLogic Server 付属のデモ用デジタル証明書はテスト目的でのみ使用してください。WebLogic Server をダウンロードすると、これらのデジタル証明書用のプライベート キーが必ず付属します。これらのデジタル証明書は、デプロイ済みの WebLogic Server では使用しないでください。filerealm.properties ファイルをチェックして、デモ用デジタル証明書がデプロイ済み WebLogic Server から削除されていることを確認してください。
WebLogic Server によってサポートされている最もセキュリティの高い暗号化、1024 ビット キーと 128 バルク データ暗号化をデータに対して使用します。ダウンロード可能なバージョンの WebLogic Server では、512 ビット キーと 40 ビット バルク暗号化のみを使用できます。強度の高いバージョンをお求めになる場合は、BEA 販売代理店にお問い合わせください。
介在者の攻撃の防止
SSL プロトコルを使用している場合は、通信グループ間で送信されたデータが、介在者の攻撃に対して無防備になっていることがあります。介在者の攻撃は、ネットワークに配置されたマシンによって、無防備な通信先に対するメッセージが取り込まれたり、変更されたり、再転送されたりして発生します。介在者の攻撃を回避する 1 つの方法は、接続先のホストが予定していた通信先、または許可された通信先であることを確認することです。SSL クライアントでは、SSL サーバのホスト名と SSL サーバのデジタル証明書を比較して、接続を検証できます。WebLogic Server には、SSL 接続を介在者の攻撃から保護するためのホスト名検証が用意されています。
デフォルトでは、ホスト名検証は有効になっています。ただし、サイトへの WebLogic Server の実装時に、この機能が無効になっていた可能性もあります。WebLogic Server デプロイメントでホスト名検証が使用されるようにするには、Administration Console の [サーバ] ノードの [SSL] タブにある [ホスト名検証を無視] 属性がチェックされていないことを確認します。
サービス拒否攻撃の防止
サービス拒否攻撃を受けると、Web サイトは動作していても使用不能になります。ハッカーは、Web サイトの 1 つまたは複数の重要なリソースを消耗させたり、削除したりすることで、この攻撃を仕掛けます。サービス拒否攻撃は、ハッカーが WebLogic Server に対する管理者特権を得た場合に起こることもありますが、一般には、特権を持たないユーザが必要なリソースを WebLogic Server デプロイメントから削除した場合に発生します。
侵入者は WebLogic Server に対してサービス拒否攻撃を仕掛けるために、サイズが非常に大きく送信が終了するまでに時間がかかるリクエストや、リクエストが終了する前にクライアントがデータの送信を止めてしまうので完了することのないリクエストを大量に送信します。サービス拒否攻撃を防止するために、WebLogic Server では、メッセージのサイズだけでなく、メッセージの到着にかかる最長時間も制限することができます。この情報は、WebLogic Server が使用する 3 つのプロトコル、T3、HTTP、および IIOP のそれぞれに対して個別に設定できます。[最大 T3 メッセージ サイズ]、[T3 メッセージ タイムアウト]、[最大 HTTP メッセージ サイズ]、[HTTP メッセージ タイムアウト]、[最大 IIOP メッセージ サイズ]、および [IIOP メッセージ タイムアウト] フィールドの設定の詳細については、Administration Console のオンライン ヘルプを参照してください。これらのフィールドには、最大メッセージ サイズとして 2GB、完了メッセージ タイムアウトとして 480 秒がデフォルト設定されています。どのフィールドでも値に 0 を指定すると、制限がチェックされなくなります。
HTTP 応答ヘッダのセキュリティ保護
WebLogic Server にサーバ自身の名前とバージョン番号を HTTP 応答で送信させないようにすることを検討しましょう。
デフォルトでは、WebLogic Server のインスタンスが HTTP リクエストに応答する際には、そのサーバの名前と WebLogic Server バージョン番号が HTTP 応答ヘッダに含まれています。そのため、WebLogic Server のそのバージョンに存在する何らかの脆弱性を攻撃者が知っていた場合には、セキュリティ上のリスクにつながるおそれがあります。
WebLogic Server インスタンスにサーバ自身の名前とバージョン番号を送信させないようにするには、Administration Console で [ Send Server Header を有効化] 属性を無効にします。この属性は、[サーバ｜ServerName｜コンフィグレーション｜プロトコル｜HTTP] タブにあります。
ユーザ アカウントの保護
辞書攻撃では、ハッカーは「辞書」から取り出したパスワードを使用してログインを試みるスクリプトをセットアップします。WebLogic Server は、辞書攻撃からユーザ アカウントを守るコンフィグレーション可能な属性を提供します。このような属性のコンフィグレーションは、さまざまな方法で行うことができます（たとえば、すべての属性を無効にする、アカウントをロックするまでの不正なログインの試行回数を増やす、アカウントをロックするまでの不正なログインの試行が行われる期間を増やす、ユーザ アカウントのロック回数を変更するなど）。これらの属性をどう設定するかの判断は、サイト管理者の責任です。この機能を使用して、最大限のセキュリティをかけてアカウントを保護します。WebLogic Server の出荷時には、セキュリティを最高レベルにするようになっています。
注意: 開発中に、これらの属性を変更してセキュリティ レベルを下げる場合、デプロイする前にその属性を戻すことを忘れないでください。
詳細については、 「パスワードの保護」を参照してください。
アプリケーションのコンテンツの保護
デフォルトでは、WebLogic Server では Web ドキュメント ルート ディレクトリと呼ばれる 1 つのディレクトリが、静的なアプリケーションのコンテンツ（HTML ファイルと画像）および動的なアプリケーションのコンテンツ（JSP ファイルと jHTML ファイル）の格納場所として使用されます。Web ドキュメント ルート ディレクトリ内の、動的なコンテンツを含むファイルの作成または変更がアプリケーションで可能な場合には、攻撃される危険性があります。
アプリケーションで Web ドキュメント ルート ディレクトリ内の既存のファイルを変更できる場合には、既存のファイル内に JSP タグまたは jHTML タグの形式で実行可能コードを挿入されるおそれがあります。特定のファイルによって動的なコンテンツが提供される場合、次回、そのファイルがクライアントに提供されると、挿入されたコードが実行されます。
攻撃される危険性のある状況を回避するために、以下のような追加のセキュリティ対策を行うことをお勧めします。
wls_owner など）を WebLogic Server の実行用に設定します。このユーザ アカウントには、最小限のオペレーティング システムの権限およびアプリケーションの正常な実行に不可欠な特権だけを許可する必要があります。
wls_owner）を、Web ドキュメント ルート ディレクトリ内のファイルにアクセスし、ファイルの作成または変更を行うことができる唯一のユーザ アカウントにします。このセキュリティ対策を行うと、WebLogic Server と同じマシンで実行されている他のアプリケーションの Web ルート ディレクトリへのアクセス機能を制限できます。
wls_owner）によってのみアクセスおよび変更できるように、JSP ファイルまたは jHTML ファイルを格納しているディレクトリを保護します。root や Administrator などの管理アカウントには、アーカイブ化用に読み込み専用のアクセス権を付与できます。
wls_owner）には、JSP ファイルまたは jHTML ファイルに対する読み込みおよび実行パーミッションのみを付与します。このセキュリティ対策によって、オペレーティング システム固有のユーザ アカウントによる、これらのファイルへの故意の書き込みを回避できます。
wls_owner）を使用しないことをお勧めします。
ユーザ入力データ中の HTML 特殊文字の置換
ユーザが入力したデータを返す機能があると、クロスサイト スクリプティングと呼ばれるセキュリティ上の弱点が発生し、ユーザのセキュリティ認可を盗むために利用される危険があります。クロスサイト スクリプティングの詳細については、http://www.cert.org/tech_tips/malicious_code_mitigation.html の「Understanding Malicious Content Mitigation for Web Developers」 (CERT によるセキュリティ勧告) を参照してください。
このようなセキュリティ上の弱点を排除するには、ユーザが入力したデータを返す前に、HTML の特殊文字がデータに含まれるかどうかを調べます。特殊文字がある場合は、それを HTML の実体参照または文字参照に置き換えます。文字を置き換えることで、ユーザが入力したデータをブラウザが HTML として実行することを防止できます。
詳細については、「JSP でのユーザ入力データのセキュリティ対策」および「サーブレットでのクライアント入力のセキュリティ対策」を参照してください。
保護された EJB によるビジネス ロジックへのアクセス制限
Web アプリケーションには他よりも重要な部分があります。たとえば、アプリケーションの中で HTML を変更する部分は、キー データベース テーブルにアクセスする部分ほど重要ではありません。Web アプリケーションの重要部分の保護に関しては、さらに配慮が必要です。Web アプリケーションの重要部分を保護する方法の 1 つは、Web アプリケーションの該当部分をエンタープライズ JavaBean（EJB）でラップし、ACL を使ってその EJB を保護するというものです。この手法により、適切な認証を受け、認可を持つユーザだけがその EJB を実行できるようになります。
次の例は、EJB と ACL を使用して Web アプリケーションの重要部分を保護する方法を示します。
何を保護して、特定の処理へのアクセスを誰に許可するかという判断は、アプリケーションごとに行う必要があります。
Web アプリケーションは徐々に発展していくものです。このため、方式を理解することだけでなく、管理することも困難になっていきます。後で混乱しないようにする方法の 1 つは、セキュリティをパッケージ単位でまとめておくことです。たとえば、あるパッケージでは、登録済みユーザがすべてのクラスのすべてのメソッドを使用でき、別のパッケージでは、顧客サービス担当者だけがすべてのクラスのすべてのメソッドを使用できるようにします。誰にどのアクセスを許可するかを最終的に決めるのは EJB デプロイヤですが、パッケージに基づくセキュリティ方式は、デプロイヤにとって実行しやすいメカニズムです。
ACL の使用
ACL は、WebLogic Server リソースへのアクセスを保護する複数のエントリを持つデータ構造です。WebLogic Server で提供する ACL は、以下の WebLogic Server リソースを保護します。
提供されている ACL を使用すると、WebLogic Server デプロイメントのリソースを保護できます。
WebLogic EJB の ACL およびパーミッションは、その他の WebLogic Server リソースの ACL およびパーミッションとは以下の点で異なります。
詳細については、以下の節を参照してください。
適切なセキュリティ レルムの使用
WebLogic Server のセキュリティは、セキュリティ レルムという概念に基づいています。WebLogic Server 内のセキュリティ レルムは、ユーザ、グループ、ユーザとグループの関連データ、および WebLogic Server リソースに関してユーザとグループに割り当てられた許可からなるコレクションです。WebLogic Server には、さまざまなタイプのセキュリティ レルムが用意されています。
デフォルトのセキュリティ レルム、ファイル レルムは、最もセキュリティの低いレルムです。デプロイ済み WebLogic Server にはファイル レルムを使用しないでください。WebLogic Server には、セキュリティ レルムの機能を使って認証と許可を行う代替セキュリティ レルムもあります。使用可能なセキュリティ レルムの詳細については、 セキュリティの基礎概念を参照してください。
データベースのセキュリティ対策
ほとんどの Web アプリケーションはデータベースを使用してデータを保存します。WebLogic Server で使われるデータベースとしては、Oracle、MicroSoft の SQL Server、および Informix が一般的です。データベースには、顧客リスト、顧客の連絡先、クレジット カード情報、その他の独自の情報など、Web アプリケーションの重要なデータを保存することがよくあります。Web アプリケーションを作成する際には、データベースに保存するデータの種類とデータのセキュリティ レベルを考慮する必要があります。また、データベース製造元によるセキュリティ メカニズムを理解し、セキュリティ ニーズに十分に対応できるかどうかを判断することも必要です。メカニズムが十分でない場合は、他のセキュリティ手法を用いて、データベースのセキュリティを向上することができます。一般的な方法の 1 つは、重要なデータをデータベースに書き込む前に暗号化することです。たとえば、クレジット カード情報だけを暗号化して、その他の顧客データはプレーン テキストのままデータベースに保存するという方法でもよいでしょう。
監査の利用
監査とは、WebLogic Server 環境での重要なセキュリティ イベントを記録する処理のことです。通常、監査レコードは、WebLogic Server ログ ファイルとは別に保存されます。監査レコードを参照すると、セキュリティ侵害やその試みがあったかどうかを判断する手がかりになります。何度もログオンしようとして失敗しているとか、変わったパターンでセキュリティ イベントが起こっているといったレコードは、重要な問題を防止するヒントになる可能性があります。監査を使用するには、weblogic.security.audit パッケージを実装します。詳細については、「セキュリティの管理」の「監査プロバイダのインストール」を参照してください。
|
|
|