ヘッダーをスキップ
Oracle Application Serverベスト・プラクティス・ガイド
10g(10.1.4.0.1)
B31976-02
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

4 セキュリティ

この章では、Oracle Application Serverのセキュリティと管理のベスト・プラクティスについて説明します。この章の内容は次のとおりです。

4.1 一般的なベスト・プラクティス

この項では、セキュリティと管理の一般的なベスト・プラクティスについて説明します。この項の内容は次のとおりです。

4.1.1 HTTPSのベスト・プラクティス

Oracle Application ServerでHTTPSを使用する場合は、次のことをお薦めします。

  • 強度の低い暗号化の使用を試みた場合は失敗するようにOracle Application Serverを構成します。Oracle Application Serverは、HTTPS接続に対応する固有の暗号のみを使用するように構成できます。クライアント側のSecure Sockets Layer(SSL)ライブラリを128ビットにアップグレードしていない、古いWebブラウザからの接続はすべて拒否できます。各接続の暗号化強度をサーバー側から制御できるため、銀行や他の金融機関にとって特に有用な機能です。

  • SSL対応のHTTPを高速化させるために、HTTPアプライアンスにはHTTPSを使用します。HTTPSのパフォーマンス・オーバーヘッドが非常に大きくなると、場合によってはトレードオフが発生します。HTTPアプライアンスでHTTPSを使用すると、500MHzのUNIXでは、スループットを1秒当たり20〜30トランザクションから1秒当たり6000トランザクションへと比較的低コストで改善できるため、このトレードオフを受け入れるかどうかの判断が容易になります。このソリューションは、数式演算カードや暗号カードより優れており、UNIX、WindowsおよびLinuxのコンピュータに追加できます。

  • HTTPSの順次転送が同じWebサーバーに対してリクエストされることを確認します。500MHzのコンピュータでSSLセッションを開始するには、40〜50ミリ秒のCPUタイムがかかると考えてください。このCPUタイムの大半は、バルク暗号化鍵が交換される鍵交換ロジックに費やされます。バルク暗号化鍵をキャッシュすると、後続のアクセスにおけるCPUオーバーヘッドが大幅に削減され、それらのアクセスは同じWebサーバーにルーティングされます。

  • セキュアなページとセキュリティが不要なページは、別々のサーバーに置きます。アプリケーションの全ページを1つのHTTPSサーバーに置くほうが簡単な場合もありますが、パフォーマンス・コストは非常に高くなります。HTTPSサーバーは、SSLが必要なページ専用とし、SSLが不要なページはHTTPサーバーに置いてください。

    セキュアなページが、同じ画面に表示されるGIF、JPEG、その他の多数のファイルで構成されている場合、セキュアな静的コンテンツをセキュアでない静的コンテンツから分離する作業は無意味な場合があります。CPUサイクルが消費される主な原因となるSSL鍵交換は、いずれにしても一度しかコールされない可能性が高く、バルク暗号化のオーバーヘッドはそれほど大きくありません。

4.1.2 タスクの実行に十分な最低レベルの権限を割り当ててセキュリティ・リークを防止する

モジュールに権限を割り当てる際に、モジュールの機能の実行に十分な最低のレベルを使用します。これは、基本的には、障害の封じ込めです。つまり、セキュリティに障害が発生した場合にネットワークの小さな領域にその障害を封じ込め、イントラネット全体を侵害できないようにします。

4.1.3 Cookieセキュリティのベスト・プラクティス

Cookieに関する次のガイドラインに従ってください。

  • Cookieに適切な有効期限が設定されていることを確認します。永続的なCookieには、3か月以下の比較的短い有効期限を設定する必要があります。これにより、クライアントWebブラウザにCookieが蓄積されるのを防ぎます。そうしないと、Webブラウザから有効なCookieをすべて転送できないと、エラーの原因となる場合があります。一時的なCookieは、関連するアプリケーションの終了時に期限切れになるように設定します。

  • Cookie内の情報にメソッド認証が含まれていることを確認します。認証を使用して、アプリケーションでデータを設定後にCookieデータが改ざんされていないことを確認します。これにより、Cookieを改ざんしてアプリケーションをだますことができなくなります。また、Cookieを誤って破損した場合には、アプリケーションの障害を防ぐのに役立ちます。

  • Cookieのサイズと種類が増えていないことを確認します。WebブラウザがサポートするCookieの数と全体のサイズは限定されています。これを超えると、Webブラウザですべての関連Cookieが送信されなくなり、アプリケーションで障害が発生します。また、膨大な数のCookieを使用すると、パフォーマンスの低下につながる可能性があります。

  • Cookieのドメイン名機能の使用には注意が必要です。Cookieドメインを使用する際には、ドメインの有効範囲を最小限にする必要があります。たとえば、ドメインoracle.comを作成すると、oracle.com内の任意のホストがCookieを取得します。oracle.comの様々な場所に何百ものアプリケーションがある場合、各アプリケーションでoracle.comドメインを使用すると、HTTP入力操作のたびに何百ものCookieが送信されることになります。

4.1.4 システム設定のベスト・プラクティス

システム設定に関する次のガイドラインに従ってください。

  • 関連するセキュリティ・パッチをすべて適用します。最新のセキュリティ・アラートの詳細は、MetaLink(http://metalink.oracle.com)およびOTN(http://www.oracle.com/technology/index.html)を確認してください。これらのパッチの多くは、公表されているセキュリティ問題に対応しています。

  • ソフトウェアをデプロイする際には、デフォルトのパスワードをすべて変更し、サンプルや例に使用したアカウントを閉じます。

  • 使用されていないサービスを全ホストから削除します。使用されていないサービスの例として、FTP、SNMP、NFS、BOOTP、NEWSがあります。かわりに、HTTPやWebDAVで代用するとよい場合があります。

  • root権限や管理権限を持つユーザーの数を制限します。

  • UNIXでは、rコマンドを使用する必要がない場合は無効にします。たとえば、rhostrcpなどです。

4.1.5 証明書の使用時におけるベスト・プラクティス

証明書を使用する場合は、次のガイドラインに従ってください。

  • 証明書の編成単位と発行者のフィールドによって、その組織がインターネット上で一意に識別されるようにします。これを実現するための1つの方法は、発行者と編成単位を表すIDとして、Dun&Bradstreet社またはIRSのIDを証明書に含めることです。

  • 証明書の発行者と識別名によって、ユーザーが一意に識別されるようにします。発行者と識別名の組合せをIDとして使用した場合、重複する可能性はありません。

  • 証明書を使用したアプリケーションのテストに有効期限の近づいた証明書を含めます。有効期限は、数々の理由から重要な検討事項であるといえます。ユーザー名やパスワードをベースにしたほとんどのシステムとは異なり、証明書は自動的に期限切れになります。有効期限の長い証明書の場合、再発行の回数は減りますが、失効リストが大きくなります。

    従来のユーザー名やパスワードのかわりに証明書を使用しているシステムでは、証明書の有効期限が近づいたときに予期しない不具合が発生することがあります。アプリケーション開発者やインフラストラクチャ開発者のほとんどは、トランザクションの最中に認可が変更される可能性のあるシステムの経験がないため、期限切れの影響を入念に検討するとともに新しいポリシーを開発する必要があります。

  • 証明書の再発行を利用して証明書の情報を更新します。証明書は期限切れになるので、期限切れの証明書を更新するためのインフラストラクチャが必要になります。編成単位やその他のフィールドを更新するには、再発行を利用します。合併、買収、個々の証明書保持者の身分変更などの場合は、証明書の期限がまだ切れていなくても再発行を検討してください。ただし、鍵の管理に注意してください。たとえば、ある人の証明書が期限切れになる前に更新された場合、古い証明書を失効リストに追加します。

  • 証明書の失効を監査します。失効監査証跡は、必要に応じて過去の状態を復元する場合に便利です。重要な例として、最初の処理時と同じ結果が確実に実現されるようにトランザクションを再実行する場合があげられます。トランザクションの参加者の証明書が最初の処理時から再実行までの間に取り消された場合は、障害が発生することがあります。この障害は、最初のトランザクションの処理時には発生しなかった場合があります。このような場合、トランザクションが最初に処理された時点でシミュレート済認証に対して監査証跡を表示して確認します。

4.1.6 既知の攻撃に対するコードとコンテンツをチェックして攻撃の再発を最小限に抑制する

ウィルスや既知の攻撃が、形態をわずかに変えて再発するのはめずらしくありません。したがって、脅威がなくなったように思えても、再発しないという保証はありません。脅威の再発を最小限に抑制するには、次のガイドラインに従ってください。

  • ダブル・エンコーディングによる攻撃に対してプログラムをチェックします。クロスサイト・スクリプティングによる攻撃やその他の攻撃を防ぐため、<>|などの特殊文字がエンコードされる場合が多くあります。たとえば、&lt;を、>のかわりに使用できます。ダブル・エンコーディングでは、攻撃者は&をエンコードして、後でデコードされる際に、処理されるスクリプトに><または|の文字が偶然含まれていないかどうかを調べます。このような攻撃を防ぐには、残念ながら、入念にプログラムをチェックするしか方法がありません。後の処理でダブル・エンコーディング問題の原因となる場合があるエスケープ文字をフィルタするユーティリティを使用することはできます。

  • 受信データのバッファ・オーバーフローに対してプログラムをチェックします。

  • クロスサイト・スクリプティングによる攻撃に対してプログラムをチェックします。このような攻撃では通常、Webブラウザ(またはWebブラウザのように動作するプロセス)からの入力を通じてHTMLおよびXMLの処理を細工して、スクリプト・エンジンを不正に起動します。しかし、これはWebテクノロジに限定された問題ではないので、すべてのコードを評価する必要があります。

4.1.7 ファイアウォールのベスト・プラクティス

ファイアウォールに関する一般的な推奨プラクティスを次に示します。これらはOracle Application Serverに限定されるものではありませんが、Oracle Application Server全体のセキュリティを確保する際に重要です。

  • インターネット・サービスを提供するサーバーはステートフル・インスペクション型の外部ファイアウォールの背後に配置します。ステートフル・インスペクションとは、ファイアウォールが各種セッションをプロトコル別に追跡し、不正なプロトコル通信の通過がファイアウォールで禁止されることを意味します。この構成により、不正なプロトコル通信の通過を利用した侵入が遮断されます。

  • インターネットで発生したトラフィックは、SMTP、POP3、IMAPまたはHTTPのサービスが実行されている特定のIPアドレスおよびPORTアドレスでのみ許可するよう、外部ファイアウォールのルールを設定します。プロトコルによっては(IIOPなど)、プロセスを受信しないときでもポートが開いているものがあります。PORTとIPの組合せにおいて実行中のプログラムに割り当てられていない組合せは、許可しないでください。

  • イントラネットに転送されるメッセージは、境界ネットワーク上のサーバーから送信された場合にのみ許可するよう、内部ファイアウォールのルールを設定します。すべての受信メッセージをまず境界ネットワークで処理する必要があります。

  • 送信メッセージは境界ネットワークのプロキシ経由で送信します。

  • レコード情報は要塞ホストに格納しないでください。要塞ホストは、境界ネットワーク上で防御処理が施されたサーバーです。要塞ホストはプロトコルの初期サーバー処理を行い、通常は機密性のある情報が含まれないように、情報と処理を分離する必要があります。データベースのレコードはイントラネットに配置し、機密性の高い処理もすべてイントラネットで行う必要があります。

  • 明確に許可されていないかぎり、すべてのトラフィック・タイプを禁止します。Oracle Application Serverで必要なトラフィック(HTTP、AJP、OCI、LDAPなど)のみを許可することによって、セキュリティを強化します。

4.1.8 宣言セキュリティの利用

Oracle HTTP Serverには、アプリケーションを修正することなくアプリケーションに対してセキュリティを確保するための機能がいくつかあります。アプリケーションをプログラミングして類似機能を実装する前に、これらの機能を利用し評価してください。具体的には、次のことを考慮してください。

  • 認証: Oracle HTTP Serverによるユーザーの認証後、認証されたユーザーIDを標準的な方法でアプリケーションに渡すことができます。また、シングル・サインオンをサポートしているので、既存のログイン・メカニズムを再使用できます。

  • 認可: エンド・ユーザーが認証および認可されている場合にのみ、アプリケーションへのアクセスを許可できるディレクティブがOracle HTTP Serverにあります。ここでも、コードの変更は不要です。

  • 暗号化: Oracle HTTP Serverにより、アプリケーションのコードを変更しなくても、エンド・ユーザーは透過的なSSL通信ができます。

アプリケーション固有のセキュリティ・メカニズムを設計する前に、これらの3つの機能を利用してください。

4.1.9 DMZでのスイッチ接続の使用

バス接続のかわりにスイッチ接続を使用して、すべてのDMZ接続デバイスを接続することをお薦めします。さらに、IP、ポート、および接続デバイスの各ペアにおけるプロトコル・ルールを設定できるデバイス(Cisco 11000シリーズのデバイスなど)の使用をお薦めします。

4.1.10 DMZにアプリケーション・サーバーを配置してセキュリティ問題を防止する

アプリケーション・サーバーはDMZ内に配置されている必要があります。このアーキテクチャでは、OracleAS Web CacheによってWebサーバーを含むコンピュータにのみリクエストが転送されます。Webサーバーはアプリケーション・サーバーにのみリクエストを転送するか、PL/SQLを使用してデータベース・サーバーにリクエストを転送します。アプリケーション・サーバーは、イントラネットにある特殊なメッセージ処理用プロセッサまたはデータベースにのみ内部リクエストを転送します。この構成によって、障害の封じ込めの優れた機能が実現されます。Webサーバーに障害が発生しても、アプリケーション・サーバーに障害が波及しないかぎり、データベースが攻撃されることはないからです。

4.1.11 Secure Sockets Layer暗号化を使用してLDAPとHTTPトラフィックを保護する

Secure Sockets Layer(SSL)暗号化を使用して、Oracle Application Serverの各種コンポーネント間で送受信される、LDAPおよびHTTPトラフィックを保護できます。Oracle Internet Directoryに送信されるすべてのLDAP問合せがSSL暗号化されることを確認するには、SSLで暗号化されているLDAP接続のみをサポートする構成セットで実行するようOracle Internet Directoryインスタンスを構成する必要があります。Oracle Application Serverインストールのデフォルト・モードでは、所定のOracle Internet DirectoryインスタンスがSSLポートと非SSLポートのどちらでもリスニングされるよう構成することができます。

SSL暗号化は、HTTPSのインストールや使用とは関係がありません。HTTPSでは、ユーザーがWebクライアント・パケットの暗号化にSSLを使用する際に、HTTPを介してOracle Application Serverコンポーネントにアクセスすることが可能になります。


関連項目:

SSLによるOracle Internet Directoryインスタンスの構成の詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。

4.1.12 アプリケーションのニーズに合せてSSLSessionCacheTimeoutディレクティブをチューニングする

Oracle Application ServerのApacheサーバーでは、デフォルトでクライアントのSSLセッション情報がキャッシュされます。セッション・キャッシュを使用すると、待ち時間が長いのはサーバーへの最初の接続時のみになります。

SSL対応のサーバーで接続と切断の簡単なテストを行ったところ、SSLセッション・キャッシュを使用しない場合、5回の接続に要した時間は約11.4秒でした。一方、セッション・キャッシュを使用した場合は約1.9秒でした。

SSLSessionCacheTimeoutのデフォルト値は300秒です。SSLセッションの期間は、HTTPの永続的な接続の使用とは関係ありません。httpd.confファイルのSSLSessionCacheTimeoutディレクティブを、アプリケーションのニーズに合せて変更できます。

4.1.13 Oracle Application Serverセキュリティ・コンポーネントをインストールする前に最終的なトポロジの計画を立案する

最終的なトポロジを計画する場合は、『Oracle Application Serverエンタープライズ・デプロイメント・ガイド』および『Oracle Identity Managementインフラストラクチャ管理者ガイド』を参照してください。必要なトポロジを成り行きにまかせて選択するのではなく、Oracle Application Serverの各種コンポーネントのインストールおよび構成の手順を、Oracle Universal Installerのオプションに合せてください。

4.2 Oracle Application Server Java Authentication and Authorization Service(JAAS)Providerのベスト・プラクティス

Oracle Application Serverには、J2EEアプリケーション用にOracleAS JAAS Providerが実装されており、J2EE宣言セキュリティに完全に統合されています。この実装により、J2EEアプリケーションで、プリンシパルベースのセキュリティやプラッガブル・ログイン・モジュールなどのJAAS構成メンバーを利用することができます。また、OracleAS JAAS Providerの実装により、OC4Jで実行されているJ2EEアプリケーションがOracle Identity Managementの集中セキュリティ・サービスを必要に応じて利用できます。

4.3 J2EEセキュリティのベスト・プラクティス

この項では、Oracle Containers for J2EE(OC4J)セキュリティのベスト・プラクティスについて説明します。この項の内容は次のとおりです。

4.3.1 カスタム・ユーザー・マネージャの作成を回避し、用意されているAPIを使用してビジネス・ロジックに専念する

OC4Jコンテナでは、セキュリティ・プロバイダを拡張するいくつかのメソッドとレベルが引き続き用意されています。UserManagerクラスを拡張してカスタム・ユーザー・マネージャを構築し、OracleAS JAAS Providerで用意されている機能を利用することができます。OracleAS Single Sign-OnおよびOracle Internet Directoryはともに、外部の認証サーバーおよびディレクトリと統合するためのAPIを備えています。そのため、開発者は、インフラストラクチャ・コードではなく実際のビジネス・ロジックの作成に、より多くの時間を当てることができます。

4.3.2 JAASプロバイダでの認証メカニズムを使用してメリットを享受する

OC4Jでは、J2EEアプリケーションに対して異なる認証オプションを使用できます。次の理由から、可能な場合はOracleAS Single Sign-On Serverを利用することをお薦めします。

  • Oracle Application Serverのほとんどのコンポーネント(OracleAS Portal、OracleAS Forms Services、OracleAS Reports Services、OracleAS Wirelessなど)にとってデフォルトのメカニズムであるため

  • 宣言型であるため設定が容易で、カスタム・プログラミングを必要としないため

  • PKIをシームレスに統合できるため

OracleAS Single Sign-Onが利用できずカスタム認証が必要な環境では、JAAS準拠のLoginModulesを使用して、OC4J認証を拡張する必要があります。LoginModulesを使用する場合、最小権限の原則を維持するために、認証対象に関連付けられているアプリケーション固有のプリンシパル(ロール)のみを使用することが重要です。

4.3.3 緻密なアクセス制御の使用

OC4Jと統合されているOracleAS JAAS Providerは、現時点で提供されている大まかなJ2EE認可モデルとは異なり、保護されたリソースをJavaパーミッションを使用してモデル化することができます。Javaパーミッション・モデル(および関連するPermissionクラス)は拡張可能で、緻密なアクセス制御を柔軟な方法で定義することができます。

たとえば、サーブレットをSubject.doAsまたはSubject.doPrivilegedで記述し、機密性の高い処理を実行するコードを制御することができます。

4.3.4 Oracle Internet Directoryをセントラル・リポジトリとして使用してLDAP標準機能を用意する

OracleAS JAAS Providerでは、開発およびテスト環境用にフラット・ファイルのXMLベース・リポジトリがサポートされていますが、本番環境用にOracle Internet Directoryを使用するよう構成します。Oracle Internet Directoryは、管理メタデータをモデル化するためのLDAP標準機能を備えており、Oracleデータベース・プラットフォーム上に構築されているため、データベースの特長であるスケーラビリティ、信頼性、管理性およびパフォーマンスもすべて継承しています。パフォーマンスを最適化するには、使用環境に適したキャッシュ構成を調整してください。

4.3.5 ユーザーがWebブラウザを閉じないように適切なログアウト機能を開発する

HTTPのBasic認証を使用する簡単なJ2EEアプリケーションでは、ログアウトの概念をサポートしておらず、Webブラウザの終了はユーザーが行います。OracleAS Single Sign-Onなどの他の認証形式を使用する場合は、様々なログアウトとタイムアウトの流れを考える必要があります。OC4Jには、非アクティブなHTTPセッションに関する調整可能なパラメータがあります。このパラメータはデフォルトで20分に設定されています。OracleAS Single Sign-Onを利用するJ2EEアプリケーションで、ログアウトの全機能をサポートする場合、J2EEアプリケーションは適切なログアウト・ダイナミック・ディレクティブで記述します。


関連項目:

『Oracle Application Server Single Sign-On管理者ガイド』

4.3.6 OC4J環境の保護

この項では、OC4J環境保護のベスト・プラクティスについて説明します。この項の内容は次のとおりです。

4.3.6.1 OC4J Standalone管理のApplication Server Controlへのアクセスを制限する

デフォルトでは、あらゆるOC4JインスタンスにOC4J管理アプリケーションがインストールされます。このアプリケーションへのアクセスはローカル・マシンに制限する必要があります。つまり、接続は127.0.0.1のみからの受信と一連の信頼できるホストへの送信に制限します。これは、OC4Jの組込みIPアクセス制御を使用して実現します。

実装の詳細

  1. application-deploymentsディレクトリにあるorion-web.xmlファイルを開きます。通常は次の場所に存在します。

    $ORACLE_HOME/j2ee/home/application-deployments/ascontrol/ascontrol/orion-web.xml
    
    
  2. orion-web-appに次の要素を追加します。

    <access-mask default="deny">
         <ip-access ip="127.0.0.1" mode="allow"/>
    </access-mask>
    

4.3.6.2 不要な機能を削除する

OC4Jのデフォルト構成には、使用も開発も簡単にできるように、様々な機能が用意されています。多くの機能はデフォルトで使用可能になっており、製品は有益なエラー・メッセージを表示するように構成されています。これは、OC4Jを開発環境で使用するときは何の問題もありません。ただし、この構成は本番環境では要件に合致しないことがあります。

4.3.6.3 デバッグ・モードを無効にする

デバッグ・モードを無効にすると、OC4JでHTTPを介したエンド・ユーザーへのスタック・トレースのエコー・バックが停止されます。ただし、スタック・トレースはログ・ファイルにも記録されているため、それを使用してアプリケーションのデバッグに役立てることができます。

実装の詳細

デバッグ・モードをオフにするには、OC4Jの実行時、またはopmn.xmlでJavaシステム・プロパティを次のように設定します。

java -DDebug=false -jar oc4j.jar

4.3.6.4 Default Invokerを無効にする

Default Invokerは従来型の規則で、構成ファイルの特定のマッピングではなくクラス名で、サーブレットを直接呼び出せるようにするものです。たとえば、servlet com.foo.bar.FooBarServletという名前のサーブレットがあるとします。このサーブレットは構成ファイルによって/FooBarにマップされ、アクセス制御されています。これは機密事項を扱う機能を実行するため、認証されたユーザーしか呼び出すことができません。OC4JでDefault Invoker機能が有効な場合、攻撃者が/servlet/com.foo.bar.FooBarServletのようにリクエストしてサーブレットを直接呼び出すと、この制限が迂回されてしまいます。そのため、この機能を取り除く必要があります。

実装の詳細

このベスト・プラクティスを実施する手順は次のとおりです。

  • global-web-application.xmlファイルまたはorion-web.xmlファイルの<orion-web-app>要素で、次の属性を編集します。

    servlet-webdir-""
    
    
  • opmn.xmlファイルで、起動パラメータとして-Dhttp.webdir.enable=falseを追加します。

4.3.6.5 ディレクトリのブラウズを無効にする

ディレクトリのブラウズを無効にして、アプリケーションの内容が悪意のあるユーザーにわからないようにします。

実装の詳細

orion-web.xmlファイルで、<orion-web-app>要素に次の属性があることを確認します。

directory-browsing="deny"

この設定はデフォルト設定です。

4.3.6.6 ファイルの別名を無効にする

J2EEコンテナおよびWebサーバーに対する攻撃が、コンテナを未処理のリソースに戻すように欺くことによって行われる場合があります。ソース・コードをコンパイルしてサーバー側で実行するのではなく、.jspに戻すような場合です。そのような攻撃を防ぐには、ファイルの別名を無効にします。

実装の詳細

Java起動パラメータを次のように定義します。

-Dhhtp.file.allowAlias=false

4.3.6.7 アカウント・パスワードを変更する

OC4J Standaloneでは、インストール時にOC4J管理者アカウントoc4jadminのパスワードを設定することが求められます。ただし、他のバージョンのOC4J(特にこのOracle製品スタックの別の部分で使用されるバージョン)をインストールした場合、よく知られたパスワードが自動的に設定されます。すべてのパスワードは必ず、簡単に推測されたり見破られないようなものに変更してください。

デフォルトでは、OC4Jでsystem-jazn-data.xmlが使用されます。このファイルにはoc4jadminアカウントが作成されていますが、出荷時には無効になっています。OC4Jのインストール時または最初の起動時に、新しいパスワードを設定してこのアカウントを有効にする必要があります。

4.3.6.8 パスワードのインダイレクションを使用する

パスワードのインダイレクションを使用して、どのOC4J XML構成ファイルにも、クリア・テキスト・パスワードが存在しないようにします。パスワードのインダイレクションを使用すると、格納されているパスワードが不明瞭になり、必要に応じてOC4Jセキュリティ・サブシステムから取り出すことができます。このメカニズムが使用できるのは、アプリケーションのセキュリティ・プロバイダが、XMLファイルベースまたはOracle Identity Managementのプロバイダに設定されている場合のみです。

実装の詳細

XML構成に、パスワードを表す->UserNameを追加します。

4.3.6.9 ネットワーク・サービス・ポートへのアクセスを制限する

デフォルトでは、Remote Method Invocation(RMI)は、ポート23791でリスニングします。これは、次の方法で制限できます。

  • rmi.xmlrmi-server要素にhost属性を追加します。

    <rmi-server port="23791" host="127.0.0.1">
    
    
  • アクセス・リージョン・セット要素を使用します。

    <access-mask default="deny">
         <ip-access ip="127.0.0.1" mode="allow"/>
    </access-mask>
    
    

デフォルトでは、Java Messaging Service(JMS)はポート9127でリスニングします。jms-server要素にhost属性を追加すると、特定のホストにしかアクセスできないように制限できます。

<jms-server port="9127" host="127.0.0.1">

4.4 OracleAS Single Sign-Onのベスト・プラクティス

この項では、Oracle Application Server Single Sign-On(OracleAS Single Sign-On)のベスト・プラクティスについて説明します。この項の内容は次のとおりです。

4.4.1 高可用性用に構成してアクセス不能アプリケーションを防止する

Single Sign-Onの障害が発生すると、シングル・サインオンで保護されたアプリケーションにアクセスできなくなるため壊滅的なダメージを及ぼします。OracleAS Single Sign-Onの高可用性に関しては、次の2つの推奨事項があります。

  • Single Sign-On Serverの動作が不安定になる可能性が高くなるため、種類の異なる処理を含める際には注意が必要です。

  • Single Sign-Onリスナーにおける障害を回避するため、複数のSingle Sign-On Serverの前にロード・バランシングのハードウェアを配置することを検討します。この場合、ロード・バランサのアドレスがSingle Sign-Onアドレスとして使用され、Single Sign-Onのリスナー構成情報がレプリケートされます。さらに、データベースをOracle Real Application Cluster構成にして、可用性を向上させることをお薦めします。


関連項目:

  • 『Oracle Application Server Single Sign-On管理者ガイド』

  • 複数のSingle Sign-On Serverを構成する方法の詳細は、Oracle Technology Network(http://www.oracle.com/technology/index.html)で入手可能なホワイトペーパー「Expose your Intranet Portal to the Outside World in a Secured Manner」を参照してください。


4.4.2 OracleAS Single Sign-Onを利用して管理とユーザー動作を最適化する

OracleAS Single Sign-Onは、主要なセキュリティ・ポイントとして使用します。このコンポーネントは、管理面でのメリットがあり、アプリケーション・ユーザーにとっても非常に便利です。また、OracleAS Single Sign-OnはOracle Application Server Infrastructureの他の部分と緊密に統合されており、Oracle Internet Directoryやその他の方法を使用して、Oracle以外のアプリケーションやインフラストラクチャとも統合できます。さらに、Single Sign-Onでは認証が1箇所で行われるため、現存するサイトの複数の認証エンティティが攻撃される可能性が低くなります。

OracleAS Single Sign-Onでは、ユーザーは1回認証されるだけですべてのアプリケーションを使用できるため、認可の制御をより均一的なものにすることができます。

4.4.3 全社的なディレクトリを使用して複数のシステムにあるユーザー・データを集中管理する

Single Sign-Onソリューションを効率的に配置するには、ユーザー・グループをディレクトリ(できればOracle Internet DirectoryなどのLDAPベースのディレクトリ)で集中管理する必要があります。複数のシステム(複数のMicrosoft Windowsドメインなど)にユーザーが存在していると、共通IDを持つインフラストラクチャの設定がいっそう困難になります。また、ユーザー・プロビジョニング・プロセスを明確に定義したり自動化すると、Single Sign-On環境の管理がさらに容易になります。

4.4.4 OracleAS Single Sign-Onを使用してユーザー資格証明を検証する

OracleAS Single Sign-Onには、資格証明を検証するインフラストラクチャが用意されており、ユーザー名、パスワード、X.509証明書などの各種の認証メカニズムを使用できます。さらに、これらのメカニズムは異なるアプリケーションやWebサイトで共有できるため、エンド・ユーザーは、企業アプリケーションごとに新しいユーザー名やパスワードを作成する必要はありません。

4.4.5 Oracle Application Serverで常にSSLを使用してアプリケーションを保護する

OracleAS Single Sign-On Serverでは、複数のパートナ・アプリケーションで使用可能な1つのユーザー名とパスワードが保持されるメカニズムを提供することによって、ユーザーとのやり取りを簡単にします。ただし、このように使い勝手がよい反面、Single Sign-On Serverが常に正しい方法でアクセスされているかどうかを確認する必要が生じます。共通パスワードが悪用されると、すべてのパートナ・アプリケーションが危険にさらされる場合があります。したがって、Single Sign-On Serverは、SSLモードでのみ接続を許可するよう必ず構成します。これにより、エンド・ユーザーの資格証明がネットワークに流出する事態が防止されます。セキュリティとデータ機密保護が重要なアプリケーションでは、SSLによる保護も実施してください。パフォーマンスの観点から、SSLハードウェア・アクセラレータの使用をお薦めします。

4.4.6 ユーザー名とパスワードのみをログイン画面で入力し、適切でないサーバーへの資格証明の送付を防止する

OracleAS Single Sign-On Serverには、標準的なログイン画面が用意されています。このログイン・ページはSingle Sign-On Serverが用意しているもので、一般的にはエンド・ユーザーがアクセスを試みているコンピュータとは別のコンピュータにインストールされています。したがって、エンド・ユーザーがログイン名とパスワードを入力する前に、有効なSingle Sign-On画面が表示される必要があります。これによって、ユーザーが無意識のうちに適切でないサーバーに対してユーザー名やパスワードを入力する事態が防止されます。

4.4.7 ログアウトによりアクティブなCookieを防止する

ほとんどのユーザーは、インターネット・アプリケーションからログアウトしないため、次の2種類の問題が発生します。

  1. セキュリティのリスク。ワークステーションにアクセスしている別のユーザーが、Cookieを再使用できるようになります。また、セッションはタイムアウトするまで有効なため、ハッカーが別のマシンからセッションIDやCookieの値の推測に使用できる時間が長くなります。

  2. Cookieに関連付けられているサーバー上のシステム・リソースは、セッションが終了するか無効になるまで解放されません。

アプリケーション開発者や管理者の場合は、Single Sign-Onセッションの期間と非アクティブ・タイムアウトが適切に構成されている必要があります。たとえば、機密性の高いアプリケーションでは非アクティブ・タイムアウトを1時間に構成します。

外部アプリケーションの場合は、OracleAS Single Sign-Onでユーザーをログアウトできません。したがって、すべてのWebブラウザ・ウィンドウを終了させることが重要になります。