Oracle® Fusion Middleware

Oracle WebLogic Server本番環境の保護

12c (12.1.2)

E48033-02(原本部品番号:E28146-02)

2014年2月

このドキュメントでは、WebLogic Serverの本番環境を保護する方法について説明します。

Oracle Fusion Middleware Oracle WebLogic Server本番環境の保護, 12c (12.1.2)

E48033-02

Copyright © 2007, 2014, Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 概要とロードマップ

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連情報

- セキュリティのサンプルとチュートリアル

- Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

- WebLogic Server配布キットのセキュリティ・サンプル

- ダウンロード可能なその他のセキュリティ・サンプル

- このリリースでの新機能と変更された機能

2 セキュリティ・ニーズの決定

- 環境の理解

- セキュリティ・コンサルタントの採用または診断ソフトウェアの使用

- セキュリティ関連の公開資料の参照

- WebLogic Serverのセキュアなインストール

3 本番環境のセキュリティの確保

- SSLでのnull暗号の使用に関する重要な注意点

- null暗号の使用を防ぐための新しいコントロール

- WebLogic Serverホストの保護

- ネットワーク接続の保護

- データベースの保護

- WebLogicセキュリティ・サービスの保護

- アプリケーションの保護

はじめに

ここでは、このガイド『Oracle WebLogic Server本番環境の保護』で使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

Oracleのお客様は、My Oracle Supportから電子サポートにアクセスできます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害があるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 概要とロードマップ

このドキュメントでは、WebLogic Serverの本番環境を保護する方法について説明します。

次の各項では、このガイド『Oracle WebLogic Server本番環境の保護』の内容と構成について説明します。

- ドキュメントのスコープと対象読者

- このドキュメントの手引き

- 関連情報

- セキュリティのサンプルとチュートリアル

- このリリースでの新機能と変更された機能

ドキュメントのスコープと対象読者

このドキュメントは、次の読者を対象としています。

- アプリケーション設計者 - セキュリティの目標を設定し、組織の全体的なセキュリティ・アーキテクチャを設計するだけでなく、WebLogic Serverのセキュリティ機能を評価して最適な実装方法を判断する設計者です。アプリケーション設計者は、セキュリティ・システムや最先端のセキュリティ技術とツールだけでなく、Javaプログラミング、Javaセキュリティ、およびネットワーク・セキュリティにも精通しています。

- セキュリティ開発者 - WebLogic Serverに統合されるセキュリティ製品のシステム・アーキテクチャとインフラストラクチャの定義、およびWebLogic Serverで使用するカスタム・セキュリティ・プロバイダの開発を主な業務とする開発者です。セキュリティ開発者は、認証、認可、監査(AAA)、Java Management eXtension (JMX)などのJavaに対する深い知識、およびWebLogic Serverとセキュリティ・プロバイダの機能に対する実践的な知識をはじめとしたセキュリティ概念をしっかりと理解しています。

- アプリケーション開発者 - WebアプリケーションとEnterprise JavaBeans (EJB)の開発およびセキュリティ機能の付加、さらに他のエンジニアリング・チーム、品質保証(QA)チーム、データベース・チームとの連携によるセキュリティ機能の実装を行うJavaプログラマです。アプリケーション開発者は、Java(サーブレットやJSPなどのJava Platform, Enterprise Edition (Java EE)バージョン5コンポーネントとJSEE)、およびJavaセキュリティについて実用的かつ深い知識を備えています。

- サーバー管理者 - アプリケーション設計者と密接に連携しながら、サーバーやサーバー上で動作するアプリケーションのセキュリティ方式の設計、潜在的なセキュリティ・リスクの特定、およびセキュリティ上の問題を防止する構成の提案を行います。関連する責務として、重要な本番システムの保守、セキュリティ・レルムの構成と管理、サーバー・リソースとアプリケーション・リソースへの認証および認可方式の実装、セキュリティ機能のアップグレード、およびセキュリティ・プロバイダのデータベースの保守などが含まれる場合もあります。サーバー管理者は、Webサービス、WebアプリケーションとEJBのセキュリティ、公開鍵セキュリティ、SSL、SAML (Security Assertion Markup Language)を含むJavaセキュリティ・アーキテクチャに関する深い知識を備えています。

- アプリケーション管理者 - サーバー管理者と共同でセキュリティ構成や、認証および認可方式を実装および管理したり、定義されたセキュリティ・レルムでデプロイされたアプリケーション・リソースへのアクセスを設定および管理したりします。アプリケーション管理者は、セキュリティの概念やJavaセキュリティ・アーキテクチャの一般的な知識を備えています。また、Java、XML、デプロイメント記述子を理解し、サーバー・ログおよび監査ログでセキュリティ・イベントを特定できます。

このドキュメントの手引き

このドキュメントの構成は次のとおりです。

- この章第1章「概要とロードマップ」では、このガイドの構成を紹介します。

- 第2章「セキュリティ・ニーズの決定」は、特定の環境に対するセキュリティ・ニーズの決定方法、およびそのニーズを確実に満たすための基本的な基準について説明します。

- 第3章「本番環境のセキュリティの確保」は、本番環境にWebLogic Serverをデプロイする前に必要なセキュリティの基準に焦点をあて、様々なセキュリティ設定を使用して本番環境を保護する方法について説明します。

関連情報

以下のOracle WebLogic Serverドキュメントには、WebLogicセキュリティ・サービスに関する情報が記載されています。

- 『Oracle WebLogic Serverセキュリティの管理』: WebLogic Serverのセキュリティの構成方法と互換性セキュリティの使用方法について説明します。

- 『Oracle WebLogic Serverセキュリティ・プロバイダの開発』 - WebLogic Serverとともに使用できるカスタム・セキュリティ・プロバイダをベンダーやアプリケーション開発者が開発する方法について説明します。

- 『Oracle WebLogic Serverのセキュリティの理解』 - WebLogicセキュリティ・サービスの機能やアーキテクチャの概要について説明します。このマニュアルはWebLogicセキュリティ・サービスを理解する上で基本となるものです。

- 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』 - WebLogicリソースを保護する方法について説明します。主にURL (Web)リソースおよびEnterprise JavaBean (EJB)リソースの保護に焦点を当てています。

- Oracle WebLogic Server Java APIリファレンス: このリリースのWebLogic Serverで提供され、サポートされているWebLogicセキュリティ・パッケージのリファレンス・ドキュメントです。

セキュリティのサンプルとチュートリアル

セキュリティ開発者向けに、Java Authentication and Authorization Service用、および発信SSLと双方向SSL用のコード・サンプルが用意されています。これらのサンプルとチュートリアルはWebLogic Serverセキュリティの動作を例示し、主要なセキュリティ開発タスクを実行する実際的な手順を示します。

独自のセキュリティ構成を開発する前に、まずセキュリティ・サンプルの一部またはすべてを実行することをお薦めします。

Avitek Medical Recordsアプリケーション(MedRec)とチュートリアル

MedRecはWebLogic Serverに付属したエンドツーエンドのサンプルJava EEアプリケーションであり、一元的で独立した医療記録管理システムをシミュレートします。MedRecアプリケーションには、患者、医師、および管理者に対して、様々なクライアントを使用して患者のデータを管理するフレームワークが用意されています。

MedRecはWebLogic ServerとJava EEの機能を例示し、Oracle推奨のベスト・プラクティスを重要点として示します。MedRecは、WebLogic Serverインストールで必要に応じてインストールできます。MedRecは、ORACLE_HOME\user_projects\domains\medrecディレクトリから起動できます。ORACLE_HOMEは、Oracle WebLogic Serverのインストール時にOracleホームとして指定したディレクトリです。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

MedRecには、Webアプリケーション、Webサービス、ワークフロー・アプリケーション、および将来のクライアント・アプリケーションからのリクエストを共同で処理する複数のエンタープライズJava Bean (EJB)で主に構成されるサービス層があります。このアプリケーションには、メッセージドリブンEJB、ステートレス・セッションEJB、ステートフル・セッションEJB、およびエンティティEJBが含まれます。

WebLogic Server配布キットのセキュリティ・サンプル

WebLogic Serverでは、必要に応じてAPIサンプル・コードをEXAMPLES_HOME\wl_server\examples\src\examplesにインストールできます。EXAMPLES_HOMEは、WebLogic Serverのサンプル・コードが構成されているディレクトリを示します。詳細は、『Oracle WebLogic Serverの理解』のサンプル・アプリケーションおよびサンプル・コードに関する項を参照してください。

ダウンロード可能なその他のセキュリティ・サンプル

APIのその他のサンプルは、http://www.oracle.com/technetwork/indexes/samplecode/index.htmlでダウンロードできます。これらのサンプルはZIPファイルとして配布されますので、既存のWebLogic Serverサンプル・ディレクトリ構造に解凍してください。

ダウンロードしたサンプルは、インストール済のWebLogic Serverサンプルと同じ方法でビルドして実行します。詳細は、個々のサンプルのダウンロード・ページ(http://www.oracle.com/technetwork/indexes/samplecode/index.html)を参照してください。

このリリースでの新機能と変更された機能

このリリースで導入されたWebLogic Serverの新機能の一覧については、『Oracle WebLogic Serverの新機能』を参照してください。

2 セキュリティ・ニーズの決定

この章では、WebLogic ServerとJava EEアプリケーションを本番環境にデプロイする前に、セキュリティ・ニーズを決定し、適切なセキュリティ対策を講じる方法について説明します。

この章の内容は以下のとおりです。

- 環境の理解

- セキュリティ・コンサルタントの採用または診断ソフトウェアの使用

- セキュリティ関連の公開資料の参照

- WebLogic Serverのセキュアなインストール

環境の理解

セキュリティ・ニーズについての理解を深めるために、次の質問の回答を検討してください。

- 保護しているのはどのリソースですか。
本番環境には、WebLogic Serverがアクセスするデータベースの情報、およびWebサイトの可用性、パフォーマンス、アプリケーション、整合性など、保護の対象となるリソースが多数あります。提供する必要のあるセキュリティ・レベルを決定する際に、保護するリソースを考慮します。

- リソースを誰から保護していますか。
多くのWebサイトでは、インターネット上のすべてのユーザーからリソースを保護する必要があります。しかし、社内のイントラネット上の従業員からWebサイトを保護する必要があるでしょうか。従業員がWebLogic Server環境内のすべてのリソースにアクセスできるようにするべきでしょうか。また、システム管理者はすべてのWebLogicリソースに対するアクセス権を持つべきでしょうか。さらにシステム管理者がすべてのデータにアクセスできるようにするべきでしょうか。極秘データまたは戦略上重要なリソースへのアクセス権は、少数の信頼性のあるシステム管理者にのみ付与することを考慮した方がよい場合もあります。一般的には、システム管理者には、このようなデータまたはリソースへのアクセスを許可しないことをお薦めします。

- 戦略上重要なリソースの保護に失敗したらどうなりますか。
セキュリティ計画の欠陥が簡単に検出され、不都合が生じることがあります。また、欠陥によって、そのWebサイトを使用する企業または個人クライアントに大きな被害を与える場合もあります。各リソースのセキュリティの影響を理解することは、セキュリティを適切に保護するうえで役立ちます。

セキュリティ・コンサルタントの採用または診断ソフトウェアの使用

インターネットまたはイントラネットのどちらにWebLogic Serverをデプロイする場合でも、セキュリティ計画および手順の検討、インストールされたシステムの監査、改良点の提案を、第三者にあたるセキュリティ・エキスパートに依頼することをお薦めします。Oracle On Demandでは、WebLogic Serverの本番環境の保護に役立つサービスおよびパートナ製品を提供しています。http://www.oracle.com/ondemand/index.htmlの「Oracle On Demand」ページを参照してください。

セキュリティ関連の公開資料の参照

セキュリティ問題に関する資料を参照してください。

- Webサーバーのセキュリティ対策の最新情報については、カーネギー・メロン大学が運営するCERT Coordination Center(http://www.cert.org/)から入手できる「Security Practices & Evaluations」の情報をお薦めします。

- My Oracle SupportにWebLogic Serverインストールを登録します。登録すると、Oracle Supportからのインストール固有のセキュリティ更新を直ちに受信できます。(http://www.oracle.com/support/index.html)を参照してMy Oracle Supportのアカウントを作成できます。

- セキュリティ勧告については、次の場所にある「重要なパッチ更新およびセキュリティ・アラート」ページを参照してください:
http://www.oracle.com/technetwork/topics/security/alerts-086861.html

WebLogic Server 10g リリース3 (10.3)以前がインストールされている場合は、http://www.oracle.com/technetwork/topics/security/beaarchive-159946.htmlの「BEAセキュリティ勧告アーカイブ」ページを参照してください。

WebLogic Serverのセキュアなインストール

現時点では、WebLogic Serverのインストールには、いくつかのWebLogic Server開発ユーティリティ(wlsvcなど)が含まれています。これらの開発プログラムによって、セキュリティの脆弱性がもたらされるおそれがあります。以下に、WebLogic Serverのインストールをよりセキュアに行うための推奨事項を示します。

- WebLogic Serverのサンプル・アプリケーションをインストールしません。WebLogic Serverをインストールするとき、サーバー・サンプル・コンポーネントをインストールするオプションは選択されていないことを確認します。

- 開発モードで、構成された場合は、WebLogic Serverを実行しない本番モードで動作するために、WebLogic Serverは構成されていることを確認します。本番モードでは、本番環境にとってよりセキュアで適切な設定を使用してサーバーが実行されるように設定されます。

注意:

WebLogic Serverを開発モードで構成した場合、不正を行うアプリケーションやWebLogic Serverの無効な構成などのエラー状況により、デプロイされているトレース・スタックが発生する可能性があります。エラー・レスポンスは一般的には危険ではありませんが、悪意の目的で使用することが可能な、アプリケーションおよびWebLogic Serverインストールの情報を攻撃者に与えるおそれがあります。

- WebLogic Serverのインストールを最小限にするには以下を実行します。

注意:

WebLogic Serverのインストールから実行可能ファイル、ファイルおよびディレクトリを削除する際には、間違いが起こる危険性が常にあります。そのため、セキュアな開発環境で変更をテストしてから、本番環境で実行することをお薦めします。

- 本番環境で使用する予定がない場合は、構成ウィザード、jCOMツールなどの開発ツールを削除します。

- Derbyデータベースを削除します。WebLogic Serverにバンドルされているこのデータベースは、サンプル・アプリケーションやサンプル・コードでデモンストレーション・データベースとして使用されます。

3 本番環境のセキュリティの確保

この章では、使用している本番環境のセキュリティを確保するために推奨されるアクションについて説明します。

この章の内容は以下のとおりです。

- SSLでのNull暗号の使用に関する重要な注意点

- WebLogic Serverホストの保護

- ネットワーク接続の保護

- データベースの保護

- WebLogicセキュリティ・サービスの保護

- アプリケーションの保護

SSLでのNull暗号の使用に関する重要な注意点

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管理コンソール・オンライン・ヘルプのログの表示と構成に関する項を参照してください。

null暗号の使用を防ぐための新しいコントロール

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ホストの保護

WebLogic Server本番環境のセキュリティは、その環境が稼働しているマシンのセキュリティと同程度でしかありません。物理マシン、オペレーティング・システム、およびホスト・マシンにインストールされているその他すべてのソフトウェアを保護することが重要です。

注意:

FIPSモードは、RSAプロバイダを使用するJSSEでサポートされます。

JSSEでFIPSを有効にするには、次の手順に従います。

1. クラスパスでcryptoj.jarよりも前にjarファイルcryptojFIPS.jar(WL_HOME/server/lib/cryptojFIPS.jar)を配置します。たとえば、サーバー起動スクリプト(通常はstartWebLogic.cmd/sh)のPRE_CLASSPATH変数にcryptojFIPS.jarを追加します。

2. 『Oracle WebLogic Serverセキュリティの管理』のWebLogic ServerでのRSA JSSEプロバイダの使用に関する項の手順に従って、RSA JSSEプロバイダを有効にします。

FIPS 140-2は、重要だが非機密的な使用に関する米国連邦政府の要件が記述された標準です。

次に示すのは、本番環境のWebLogic Serverホストを保護する際の推奨事項です。マシンやオペレーティング・システムのメーカーが推奨しているセキュリティ対策も確認してください。

重要:

WebLogicドメインおよびサーバーの構成ファイルには、WebLogic Serverを構成または実行するオペレーティング・システム・ユーザーしかアクセスできないようにする必要があります。

表3-1 WebLogic Serverホストの保護

セキュリティ・アクション

説明

ハードウェアを物理的に保護します。

権限のないオペレーティング・システムのユーザーが、デプロイメント・マシンまたはそのネットワーク接続を変更できないように、ハードウェアを安全な場所に置きます。

非セキュア・サイトに移動する前に、管理コンソールからログアウトします。

WebLogic Server管理コンソールにログオンしている場合は、未知のサイトや非セキュアWebサイトを表示する前に、完全にログアウトします。

オペレーティング・システムが提供するネットワーク・サービスを保護します。

悪意のある攻撃者がオペレーティング・システムにアクセスしたり、システム・レベルのコマンドを実行したりできないように、電子メール・プログラムまたはディレクトリ・サービスなどのネットワーク・サービスについて専門家に確認してもらいます。使用するオペレーティング・システムによって方法は異なります。

ファイル・システムを企業ネットワーク内の他のマシンと共有する場合、そのファイル・システムはリモート攻撃される危険性があります。WebLogic Serverをホストするマシンのファイル・システムを共有する前に、リモート・マシンとネットワークがセキュアであるかどうかを確認してください。

不正アクセスを防ぐことのできるファイル・システムを使用します。

各WebLogic Serverホスト上のファイル・システムで、保護されているリソースへの不正なアクセスができないようになっていることを確認します。たとえば、Windowsコンピュータでは、NTFSのみを使用します。

ディスクに保存されたデータにファイル・アクセス許可を設定します。

ディスクに保存されたデータへのアクセスを制限するために、オペレーティング・システムのファイル・アクセス許可を設定します。このデータには以下が含まれます(ただし、これに限定されるわけではありません):

- セキュリティLDAPデータベース。デフォルトでは\domains\domain-name\servers\server-name\data\ldap\ldapfilesです。

- プライベート・キー・ストアのディレクトリとファイル名の場所。『Oracle WebLogic Serverセキュリティの管理』の秘密鍵、デジタル証明書および信頼性のある認証局の格納に関する項を参照してください。

- ルート認証局(CA)キーストアのディレクトリとファイル名の場所。『Oracle WebLogic Serverセキュリティの管理』の秘密鍵、デジタル証明書および信頼性のある認証局の格納に関する項を参照してください。

たとえばUnix、Linuxなどのオペレーティング・システムには、ファイル・アクセス許可の設定用にumaskやchmodといったユーティリティが用意されています。少なくとも、GroupとOthersに対する読取りおよび書込み許可を拒否する「umask 066」の使用を検討します。

永続ストアに保存されたデータにファイル・アクセス許可を設定します。

永続ストアに保存されたデータへのアクセスを制限するために、オペレーティング・システムのファイル・アクセス許可を設定します。同期書込みポリシーDirect-Write-With-Cacheを使用する際には、プライマリ・ディレクトリへのユーザー・アクセスに関して独自の制限が構成されている場合は特に、キャッシュ・ディレクトリへのアクセスを制限します。永続ストアへの接続を作成できるWebLogicサービスおよびサブシステムについては、『Oracle WebLogic Serverサーバー環境の管理』の「WebLogic永続ストアの使用」にある永続ストアの概要に関する項を参照してください。

デフォルト永続ストアは、ドメインのルート・ディレクトリのservernameサブディレクトリにあるdata\store\defaultディレクトリに保持されます。

ホスト・マシンのユーザー・アカウント数を制限します。

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およびweblogic.Deployerコマンドを含めて多くのWebLogic Serverコマンドにより、暗号化されていないパスワードを指定することができます。しかし、コマンド・ラインで暗号化されていないパスワードを指定するのはセキュリティ・リスクです。その他のユーザーがモニター画面から簡単に見ることができます。また、それらのコマンドの実行をログするプロセスのリストにそのパスワードが表示されます。

コマンド・ウィンドウまたはスクリプトで、暗号化されていないパスワードが必要であるコマンドを入力するとき、パスワードは安全に入力されていることを確認するには、以下の注意事項を考慮してください。

- 要求されたときだけパスワードを入力します。コマンド・ラインからパスワードを除くと、コマンドを実行するときにパスワードの入力を要求されます。入力した文字はエコーされません。

- WebLogic Serverのインスタンスを起動するスクリプトのために起動IDファイルを作成します。起動IDファイルは、WebLogic Serverのインスタンスの起動および停止に関するユーザーの資格証明を格納するテキスト・ファイルです。スクリプトを実行した場合、管理サーバーは、ユーザーに資格証明の提示を求めずに、このファイルを参照してユーザーの資格証明を取得できます。起動IDファイルでは資格証明が暗号化されているので、起動スクリプトまたは停止スクリプトに暗号化されていない資格証明を格納するより、起動IDファイルを使用した方が安全性は確保されます。
リモート管理サーバー・インスタンスを開始するスクリプト・ベースのノード・マネージャ・コマンドで、リモート起動のユーザー名とパスワードは管理サーバーの起動IDファイルから取得されていることを確認します。

- ユーザー名とパスワードが必要であるコマンドを含むWLSTスクリプトのためにユーザー構成ファイルを作成します。WLST storeUserConfigコマンドを使用して、作成できるこのファイルは、次の情報を含みます。

- 暗号化された形式の資格証明

- 資格証明を暗号化するためにWebLogic Serverが使用するキー・ファイル

WLSTセッション中、または、WLSTスクリプトで、次に示すように、ユーザー構成ファイルをコマンドに渡すことができます:

- connect - 実行中のWebLogic Serverに接続するため

- startServer - 管理サーバーを起動するため

- nmConnect - WLSTをノード・マネージャに接続してセッションを確立するため

- ユーザー名とパスワードが必要であるコマンドを含むweblogic Deployerスクリプトのために、暗号化されていない資格証明を入力するかわりに、WLST storeUserConfigコマンドを使用して、作成したユーザー構成ファイルを指定できます。

ユーザー資格証明をスクリプトに安全に渡すことに関する詳細情報については、以下のトピックを参照してください。

- 『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項および起動IDファイルに関する項

- 『WebLogic Scripting Toolの理解』のWLSTのセキュリティに関する項

- 『Oracle WebLogic Serverノード・マネージャの管理』のスクリプトベースのノード・マネージャのリモート・サーバー起動セキュリティの構成に関する項

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.Deployerを呼び出すための構文に関する項

各ホスト・コンピュータで、(アクセス権限を持つ2つのシステム管理者ユーザーの他に)1つのユーザー・アカウントにのみWebLogicリソースへのアクセス権限を付与します。

重要: WebLogicドメインおよびサーバーの構成ファイルには、WebLogic Serverを構成または実行するオペレーティング・システム・ユーザーしかアクセスできないようにする必要があります。他のオペレーティング・システム・ユーザー(システム管理者以外)には、WebLogic Serverの製品ファイルおよびドメイン・ファイルの読取り、書込み、実行のためのアクセス権を付与しないでください。

各WebLogic Serverホスト・コンピュータで、オペレーティング・システムを使用して、WebLogic Serverの実行用に特別なユーザー・アカウント(wls_ownerなど)を設定します。このオペレーティング・システム(OS)・ユーザー・アカウントには、次のディレクトリへのアクセス権限のみを付与します。

- Oracleホーム
マシンにインストールされているすべてのOracle Fusion Middleware製品用に作成される最上位ディレクトリ。このディレクトリは、WebLogic Serverのインストール時に作成されます。

- WebLogic Server製品インストール・ディレクトリ
このディレクトリには、システムにインストールすることを選択したすべてのWebLogic Serverソフトウェア・コンポーネントがプログラム・ファイルも含めて格納されます。デフォルトでは、このディレクトリはOracleホームのサブディレクトリであり、wlserverという名前になります。詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』のインストール・ディレクトリの選択に関する項を参照してください。

- WebLogicドメイン・ディレクトリ
これらのディレクトリには、単一のWebLogicドメインの構成ファイル、セキュリティ・ファイル、ログ・ファイル、Java EEアプリケーション、その他のJava EEリソースが格納されます。デフォルトでは、ドメインはOracleホームのサブディレクトリです(Oracle/Middleware/user_projects/domains/domain1など)。ただし、ドメイン・ディレクトリはWebLogic Serverインストール・ディレクトリやOracleホーム以外に配置することもできます。WebLogic Serverホスト・コンピュータに複数のドメインを作成する場合は、各ドメイン・ディレクトリを保護する必要があります。

これにより、WebLogic Serverと同じマシンで実行されている他のアプリケーションのWebLogic Serverファイルおよびドメイン・ファイルへのアクセス権が制限されます。このように保護しないと、他のアプリケーションが書込みアクセス権を得て、動的コンテンツを提供するJSPやその他のファイルに悪意のある実行コードを挿入する可能性があります。そのファイルが次にクライアントに提供されると、挿入されたコードが実行されます。

知識の豊富なオペレーティング・システムのユーザーが、以下のファイルに対して書込みアクセス権(場合によっては読込みアクセス権)を付与されている場合、WebLogic Serverのセキュリティを無視することができます。

- WebLogic Serverインストール

- JDKファイル(通常、WebLogic Serverインストール内にあります。ただし、別になるように構成できます)

- ドメイン・ディレクトリ

- JMS SAFファイル

- HTTPセッションをバックアップしたファイル

永続ストアを使用するすべてのファイル(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のような長期にわたって実行されるプロセスは、これらの権限を付与されたアカウント下で実行しないでください。そのかわり、以下の処理のいずれかを行うことができます。

- 権限を付与されたポートにアクセスする必要のある各WebLogic Serverインスタンスについて、権限があるユーザー・アカウント下で起動し、権限を付与されたポートにバインドしてから、ユーザーIDを権限のないアカウントに変更するようにサーバーを構成します。
サーバー・インスタンスの起動にノード・マネージャを使用する場合は、セキュア・ポート上でのみ、また単一の既知のホストのみから、リクエストを受け入れるようにノード・マネージャを構成します。なお、ノード・マネージャは権限があるユーザー・アカウントで起動する必要があります。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのUNIX上で稼働するマシンの作成と構成に関する項を参照してください。

- WebLogic Serverインスタンスを権限を持たないアカウントから起動し、ネットワーク・アドレス変換(NAT)ソフトウェアを使用して、保護されているポートを保護されないポートにマップするよう、ファイアウォールを構成します。

rootとしてWebサーバーを実行しないようにします。

Unixシステム上のWebサーバー(Apache HTTP Server、Microsoft IIS、Sun Java System Web Serverなど)を実行する場合は、次のことを確認してください:

- Webサーバーはrootとしてではなく、権限のないユーザーとしてのみ実行します。

- Webサーバーが配置されるディレクトリ構造(すべてのファイルを含む)は、権限のないユーザーによるアクセスから保護する必要があります。

これらの手順により、権限のないユーザーは、Webサーバーによって実行可能なコードにコードを挿入することができないことを確認できます。

本番マシンで開発しないようにします。

まず開発マシンで開発し、開発が終わりテストが終了したら、コードを本番マシンに移行します。これにより、開発環境でのバグが、本番環境のセキュリティに影響を及ぼすことを防止できます。

開発ソフトウェアまたはサンプル・ソフトウェアを本番マシンにインストールしないようにします。

本番マシンに開発ツールをインストールしません。開発ツールを本番マシンにインストールしないことにより、侵入者がWebLogic Server本番マシンに部分的にアクセスできたとしても、影響を減らすことができます。

本番マシンでWebLogic Serverのサンプル・アプリケーションを構成しないでください。インストール・プログラムがインストール・タイプの選択を求めてきたら次のようにします。

- WebLogic Serverのインストール、CoherenceのインストールまたはFusion Middlewareインフラストラクチャを選択した場合、サンプル・アプリケーションはインストール後の構成では使用できません。

- 完全インストールまたは例を使用したFusion Middlewareインフラストラクチャを選択した場合、サンプル・アプリケーションをインストール後の構成で使用できます。この選択は、本番マシンでは回避する必要があります。

セキュリティ監査を有効にします。

WebLogic Serverが動作するオペレーティング・システムが、ファイルおよびディレクトリ・アクセスのセキュリティ監査をサポートする場合は、監査ログを使用して、拒否されたディレクトリまたはファイル・アクセス違反をトラッキングすることを推奨します。管理者は、監査ログ用に十分なディスク・スペースを確保する必要があります。

オペレーティング・システムを保護する追加ソフトウェアの使用を検討します。

多くのオペレーティング・システムでは、本番環境を保護するために、追加ソフトウェアを実行することができます。たとえば、侵入検知システム(Intrusion Detection System: IDS)を使用すると、本番環境を変更しようとしたときに検出できます。

使用可能なソフトウェアの情報については、使用しているオペレーティング・システムのベンダーに問い合せます。

オペレーティング・システムのパッチ・セットおよびセキュリティ・パッチを適用します。

推奨されているパッチ・セットおよびセキュリティ関連のパッチのリストについては、オペレーティング・システムのベンダーに問い合せます。

最新のメンテナンス・パック、マイナー・リリースおよび重要なパッチ更新を適用します。

サイトのセキュリティ問題の担当者は、WebLogic ServerのインストールをMy Oracle Supportに登録してください。「http://www.oracle.com/support/index.html」でMy Oracle Supportアカウントを作成できます。

「http://www.oracle.com/technology/deploy/security/alerts.htm」で重要なパッチ更新およびセキュリティ・アラートのページも参照してください。

WebLogic Server 10g リリース3 (10.3)以前のリリースがインストールされている場合、http://www.oracle.com/technetwork/topics/security/beaarchive-159946.htmlの「BEAセキュリティ勧告アーカイブ」ページから重要なセキュリティ更新を取得できます。

また、リリースされている各サービス・パックやマイナー・リリースを迅速に適用していただくことを推奨します。サービス・パックおよびマイナー・リリースは、My Oracle Supportから取得でき、製品の各バージョンに対するすべてのバグ修正のロールアップが含まれます。

セキュリティ問題を報告するために、以下のいずれかを実行します。

- My Oracle Supportにログオンし、サービス・リクエストを発行します。

- セキュリティの脆弱性を報告するページ(http://www.oracle.com/support/assurance/reporting/index.html)を参照します。

本番環境ではWebLogic Serverを開発モードで実行しないようにします。

本番モードでは、本番環境にとってよりセキュアで適切な設定を使用してサーバーが実行されるように設定されます。

注意: 次の点に注意してください。

- WebLogic Serverを開発モードで構成した場合、不正を行うアプリケーションやWebLogic Serverの無効な構成などのエラー状況により、デプロイされているトレース・スタックが発生する可能性があります。エラー・レスポンスは一般的には危険ではありませんが、悪意の目的で使用することが可能な、アプリケーションおよびWebLogic Serverインストールの情報を攻撃者に与えるおそれがあります。しかし、WebLogic Serverを本番モードで構成するとスタック・トレースが生成されないので、けっして本番環境ではWebLogic Serverを開発モードで実行しないでください。

- 本番モードではWebサービスのテスト・クライアントを有効にしないことをお薦めします。Webサービスのテスト・クライアントの詳細は、『Webサービスの管理』のWebサービスのテストに関する項を参照してください。

開発モードと本番モードの詳細は、『Oracle WebLogic Serverドメイン構成の理解』のドメイン・モードに関する項を参照してください。

ドメイン内のWebLogic Serverインスタンスが本番モードで実行されるように変更する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの本番モードへの変更に関する項を参照してください。WebLogic Scripting Toolを使用して、DomainMBean.isProductionModeEnabled MBean属性をtrueに設定するという方法でも本番モードを有効化できます。

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ポートにアクセスできるようになります。接続フィルタの使用の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のネットワーク接続フィルタの使用に関する項を参照してください。

JVMのプラットフォームMBeanサーバーへのリモート・アクセスを有効にしないようにします。

JDKでは、MBeanサーバー(プラットフォームMBeanサーバー)と、JVMのモニター情報を含む一連のMBeanが提供されます。WebLogic Serverの実行時MBeanサーバーを構成してプラットフォームMBeanサーバーとして実行できます。これにより、JMXクライアントは単一のMBeanサーバー接続からJVM MBeanおよびWebLogic Server MBeanにアクセス可能です。

プラットフォームMBeanサーバーへのリモート・アクセスは、標準のJDKセキュリティ機能によってのみ保護できます(http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.htmlを参照)。WebLogic Server実行時MBeanサーバーをプラットフォームMBeanサーバーとして構成した場合、プラットフォームMBeanサーバーへのリモート・アクセスを有効にするとWebLogic Server MBeanへのアクセス・パスが作成されます。このアクセス・パスは、WebLogic Serverセキュリティ・フレームワークでは保護されません。

リモートの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環境のポートへのアクセスを制限するためにファイアウォールを構成してください。

詳細は、『SNMPによるOracle WebLogic Serverのモニタリング』を参照してください。

完了メッセージ・タイムアウトの構成設定がシステムに適していることを確認します。

サービス拒否(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セキュリティ・サービスの保護

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

表3-3 WebLogicセキュリティ・サービスの保護

セキュリティ・アクション

説明

本番対応のセキュリティ・プロバイダをセキュリティ・レルムにデプロイします。

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

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

- 正しくデプロイおよび構成していることを確認します。管理コンソールに現在デプロイされているセキュリティ・プロバイダを確認できます。管理コンソールの左ペインで「セキュリティ・レルム」を選択後、レルムの名前をクリックして「プロバイダ」タブを選択します。

- セキュリティ・プロバイダをデプロイしたレルムがデフォルトの(アクティブな)レルムであることを確認します。管理コンソールでデフォルト・セキュリティ・レルムを設定する手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのデフォルト・セキュリティ・レルムの変更に関する項を参照してください。

- 『Oracle WebLogic Serverセキュリティの管理』のデフォルト・セキュリティ構成のカスタマイズに関する項を参照してください。

本番環境ではSSLを使用し、デモ用のデジタル証明書を使用しないようにします。

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

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

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項および『Oracle WebLogic Serverセキュリティの管理』のSSLの構成に関する項を参照してください。

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

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

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

-Dweblogic.security.SSL.enforceConstraints=false

このオプションの詳細は、『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管理コンソール・オンライン・ヘルプで次のタスクを参照してください。

- 「HTTPプロトコルの構成」

- 「T3プロトコルの構成」

- 「IIOPの有効化と構成」

『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セキュリティ・サービスが提供する監査プロバイダを有効にすると、イベントがDomainName\DefaultAuditRecorder.logに記録されます。

監査プロバイダは、WebLogic Server管理コンソールの「セキュリティ・レルム」→「レルム名」→「プロバイダ」→「監査」ページで有効にします。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの監査プロバイダの構成に関する項を参照してください。

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

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

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

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

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

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

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。

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

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

少なくとも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のリソースを保護するオプションに関する項を参照してください。

リダイレクト攻撃を防止するには、FrontendHost属性をWebServerMBeanまたはClusterMBeanに設定します。

Webアプリケーションのリクエストは別の場所にリダイレクトした場合、リクエストでのホスト・ヘッダーは、デフォルトでレスポンスのロケーション・ヘッダーに使用されます。ホスト・ヘッダー は、別のホスト名または他のパラメータを含まれるように破損させる、つまりなりすます可能性があります。そのため、サード・パーティでリダイレクト拒否攻撃を起動するには、この動作は、返す機能があります。

リダイレクト対象のすべてのURLが送られるホストを指定するには、WebserverMBeanまたはClusterMBeanにFrontendHost属性をこの発生の可能性が回避するように設定します。元のリクエストに指定したホストではなく、FrontendHost属性に指定したホストが、レスポンスのロケーション・ヘッダーに使用されます。

詳細は、Oracle WebLogic Server MBeanリファレンスのFrontendHostに関する項を参照してください。

HTMLコメント・タグではなく、JSPコメント・タグを使用します。

JSPファイル内にある、機密データを含むコメントやエンド・ユーザーを対象としていないコメントは、HTML構文の<!-- xxx -->ではなく、JSP構文の<%/* xxx */%>を使用します。JSPコメントは、HTMLコメントとは異なりJSPがコンパイルされると削除されるため、ブラウザに表示されなくなります。

本番マシンには未コンパイルのJSPおよびその他のソース・コードをインストールしないようにします。

常に、ソース・コードを本番マシンに置かないようにする必要があります。ソース・コードにアクセスすると、侵入者はセキュリティ・ホールを発見できます。

JSPをプリコンパイルし、コンパイル済のJSPのみを本番マシンにインストールすることを検討します。JSPのプリコンパイルの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のJSPのプリコンパイルに関する項を参照してください。

SSLを使用するようにアプリケーションを構成します。

web.xmlファイルのuser-data-constraint要素でtransport-guaranteeをCONFIDENTIALに適宜設定します。

『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のsecurity-constraintに関する項を参照してください。

Servletサーブレットを使用しないようにします。

本番環境でのServletサーブレットの使用はお薦めしません。

かわりに、サーブレットをURIに明示的にマップします。本番環境でWebアプリケーションを使用する前に、すべてのWebアプリケーションから、WebLogicサーブレットとServletサーブレットの間の既存のマッピングをすべて削除します。

サーブレットのマッピングの詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの構成に関する項を参照してください。

本番環境で、FileServletをデフォルト・サーブレットとして使用しないようにします。

本番環境でFileServletサーブレットをデフォルト・サーブレットとして使用することはお薦めしません。

デフォルト・サーブレットの設定の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のデフォルト・サーブレットの設定に関する項を参照してください。

すべてのWebLogicセキュリティ・ポリシーを確認します。

WebLogic Server 7.0では、ACLにかわってセキュリティ・ポリシーが使用され、WebLogicリソースに誰がアクセスしたのかを判断します。

WebLogicリソースからセキュリティ・ポリシーを削除していないこと、およびセキュリティ・ロールの割当てによってユーザーに目的のアクセス権を提供していることを確認します。

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。

アプリケーションのセキュリティを検査します。

アプリケーションにセキュリティの脆弱性がもたらされるおそれのある典型的な事例があります。これらの事例の多くは、OWASP (Open Web Application Security Project)などの第三者組織によって定義されています(よくある問題のリストは、http://www.owasp.org/index.php/Category:OWASP_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

『WebLogicセキュリティ・サービスによるアプリケーションの開発』の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として実行されることを回避します。

『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のJSPでのユーザー入力データの保護に関する項およびクライアント入力の保護に関する項を参照してください。

JMSリソースに対してセキュリティ・チェックが行われていることを確認します。

weblogic.jms.securityCheckInterval属性を0に設定して、認可チェックがJMSリソースのすべてのSend、Receive、およびgetEnumerationアクションに対して行われていることを確認します。

認証、認可、および検証済の生成元ポリシーを使用するようにWebSocketアプリケーションを構成します。

Webコンテナの標準の認証および認可機能(BASIC、FORM、CLIENT-CERT)を使用して、認可されていないクライアントがWebSocket接続を開かないようにします。

予期される接続元からのWebSocket接続のみを受け入れるようにWebSocketアプリケーションを構成することも可能です。WebSocketListener実装クラスのacceptメソッドのOrigin HTTPヘッダーを指定して、検証済の生成元ポリシーをWebSocketアプリケーションに適用します。

詳細は、『Oracle WebLogic Serverアプリケーションの開発』のWebSocketアプリケーションの保護に関する項を参照してください。

wss:// URIを使用してセキュアなWebSocket接続を確立します。

WebSocketアプリケーションでは、wss:// URIを使用してセキュアなWebSocket接続を確立し、データが傍受されないようにする必要があります。wss:// URIを使用すると、クライアントがハンドシェイク・リクエストをHTTPSリクエストとして送信し、転送されるデータがTLS/SSLによって暗号化されるようになります。

詳細は、『Oracle WebLogic Serverアプリケーションの開発』のWebSocketアプリケーションの保護に関する項を参照してください。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。