10 アプリケーション・セキュリティの管理

Oracle HTTP Serverでは、主に3つのセキュリティのカテゴリ、つまり認証、認可および機密保護をサポートします。

Oracle HTTP Serverのセキュリティ機能およびセキュアなWebサイトを設定するための構成情報については、次の項を参照してください。

Oracle HTTP Serverのセキュリティについて

Oracle HTTP Serverでは、すべて3つのセキュリティのカテゴリ、つまり認証、認可および機密保護をサポートします。Oracle HTTP Serverのセキュリティ・インフラストラクチャは、主にApacheセキュリティ・モジュールによって提供されます。

Oracle HTTP ServerはApache HTTP Serverに基づいており、そのセキュリティ・インフラストラクチャは主にApacheモジュール(mod_auth_basic、mod_authn_file、mod_auth_userおよびmod_authz_groupfile)、とWebGateにより提供されます。mod_auth_basic、mod_authn_file、mod_auth_userおよびmod_authz_groupfileモジュールは、ユーザー名とパスワードのペアに基づく認証を提供します。mod_authz_hostはリクエストの特性(ホスト名やIPアドレスなど)に基づいてサーバーへのアクセスを制御し、mod_osslは、SSLを介したX.509クライアント証明書によって秘匿性および認証を提供します。

Oracle HTTP Serverは、httpd.confファイル内のアクセス制御ディレクティブを使用して構成できるアクセス制御、認証および認可の方法を提供します。URLリクエストはOracle HTTP Serverに到達すると、サーバーのデフォルトおよび構成パラメータにより指定されたステップで処理されます。URLリクエストの処理ステップは、多くのWebリスナーに共通のモジュールまたはプラグイン・アーキテクチャを介して実装されます。

ユーザーおよびその権限のクラス

Oracle HTTP Serverは、ユーザーを認可および認証してから、そのユーザー権限に基づいて、そのユーザーにサーバーのリソースへのアクセスまたは変更を許可します。

Oracle HTTP Serverを使用してサーバーにアクセスする3つのユーザー・クラスと、それらの権限を次に示します。

  • 認証を提供せずにサーバーにアクセスするユーザー。これらのユーザーは、保護されていないリソースにしかアクセスできません。

  • Oracle HTTP Server内のモジュールによって認証され、将来的に認可される予定のユーザー。これには、mod_auth_basic、mod_authn_file、mod_auth_userおよびmod_authz_groupfileモジュールのようなApache HTTP ServerモジュールとOracleのmod_osslにより認証されたユーザーが含まれます。これらのユーザーは、http.confファイル内で定義されたURLにアクセスできます。認証、認可およびアクセス制御を参照してください。

  • Oracle Access Managerによって認証されたユーザー。これらのユーザーは、シングル・サインオンによって許可されたリソースにアクセスできます。『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

認証、認可およびアクセス制御

Oracle HTTP Serverは、ユーザーの認証および認可を、アクセス制御、ユーザーの認証および認可の2段階で行います。

  • アクセス制御(第1段階): これは、受信HTTPリクエストとそのヘッダーの詳細(IPアドレスやホスト名など)に基づいています。

  • ユーザーの認証および認可(第2段階): これは、HTTPサーバー構成に応じた様々な基準に基づいています。ユーザー名とパスワードのペアでユーザーを認証するようにサーバーを構成できます。ユーザー名とパスワードは、既知のユーザーおよびパスワードのリストと比較して確認されます。また、Webアプリケーションに対してシングル・サインオン認証を使用するようにサーバーを構成したり、SSLを介したX.509クライアント証明書を使用するようにサーバーを構成することもできます。

アクセス制御

アクセス制御とは、リソースに対するアクセスを制御する手段のことです。

関連項目:

リソースへのアクセス制御の構成方法の詳細は、Apache HTTP Serverドキュメントを参照してください。

ユーザーの認証および認可

認証は、ユーザーが本物であることを確認するプロセスです。認可は、ユーザーにリソースへのアクセスや情報の取得を許可するプロセスです。Apache HTTP ServerモジュールまたはWebGateのいずれかを使用してユーザーを認証できます。

Apache HTTP Serverモジュールを使用したユーザーの認証

Apache HTTP Server認証ディレクティブを使用して、ユーザーが本物であることを確認できます。

ユーザーの認証の詳細は、Apache HTTP Serverのドキュメントを参照してください。

WebGateを使用したユーザーの認証

WebGateによって、Oracle HTTP Serverのシングル・サインオン(SSO)が可能になります。WebGateは受信リクエストを調べて、リクエストされたリソースが保護されているかどうかを判断し、保護されている場合は、ユーザーのセッション情報を取得します。

WebGateを使用すると、Oracle HTTP ServerはSSO対応のパートナ・アプリケーションとなり、SSOを使用してユーザーを認証することが可能になり、Oracleシングル・サインオンを使用してユーザーのアイデンティティの取得ができるようになり、また、Oracle HTTP ServerからアクセスされるWebアプリケーションはユーザーのアイデンティティを使用することが可能になります。

WebGateを使用することで、Webアプリケーションは、SSO認証を必要とするURLを登録できます。WebGateは、Oracle HTTP Serverが受信したクエストからSSO認証が必要なリクエストを検出し、それらをSSOサーバーにリダイレクトします。SSOサーバーによってユーザーが認証されると、ユーザーの認証済アイデンティティをWebGateにセキュア・トークンで渡します。WebGateがトークンからユーザーのアイデンティティを取得すると、それをOracle HTTP Serverからアクセスされるアプリケーション(Oracle WebLogic Server上で実行されているアプリケーション、CGI、Oracle HTTP Serverによって処理される静的ファイルなど)に伝搬します。

FMW監査フレームワークのサポート

Oracle HTTP Serverは、FMW共通監査フレームワークを使用した認証および認可の監査をサポートしています。監査の有効化の一部として、Oracle HTTP ServerはOraAuditEnableと呼ばれるディレクティブをサポートしています(デフォルトはOn)。有効化されると、auditconfig.xmlで有効化されている監査イベントが監査ログに記録されます。デフォルトでは、auditconfig.xmlで有効化されている監査イベントはありません。

OraAuditEnableOffに設定されている場合は、auditconfig.xmlでの設定に関係なく監査は無効になります。

Fusion Middleware Controlを使用するか、またはauditconfig.xmlを直接編集することで、監査フィルタを構成できます。

関連項目:

Oracle Platform Security Servicesによるアプリケーションの保護監査機能の概要

Fusion Middleware Controlを使用した監査ポリシーの管理

Fusion Middleware Controlの「監査ポリシー」ページを使用して、監査ポリシーを選択したOracle HTTP Serverインスタンスに割り当てます。

  1. 「Oracle HTTP Server」ホーム・ページに移動します。
  2. 監査ポリシーを適用するサーバー・インスタンスを選択します。
  3. Oracle HTTP Serverのドロップダウン・メニューから、「セキュリティ」を選択し、「監査ポリシーを選択します。

    「監査ポリシー」ページが表示されます。

監査ポリシーの設定の詳細は、Oracle Platform Security Servicesによるアプリケーションの保護Fusion Middleware ControlによるJava Componentsの監査ポリシーの管理を参照してください。

SSLの実装

Oracle HTTP Serverは、Secure Sockets Layer (SSL)プロトコルを使用して通信を保護します。SSLは、メッセージの暗号化、整合性および認証を提供することで、通信を保護します。SSL標準により、関係するコンポーネント(ブラウザやHTTPサーバーなど)は、どの暗号化、認証および整合性メカニズムを使用するかのネゴシエーションができます。

Oracle HTTP Serverに対するSSLの実装方法の詳細は、Oracle Fusion Middlewareの管理Web Tierに対するSSLの実装を参照してください。OracleのSSLモジュールであるmod_osslの使用の詳細は、mod_osslモジュール—暗号(SSL)の有効化を参照してください。mod_osslディレクティブの詳細は、「mod_osslモジュール」を参照してください。

mod_wl_ohsモジュールにもSSL用の構成が含まれています。『Oracle WebLogic Serverプロキシ・プラグインの使用』SSLのプラグインとの使用に関する項およびWebサーバー・プラグインのパラメータに関する項を参照してください。

この項では、このリリースでサポートされているSSL機能について説明します。

グローバル・サーバーIDのサポート

グローバルIDサポート機能は、「ステップアップ」「サーバー・ゲート暗号化」または「グローバル・サーバーID」などと様々に呼ばれる、サポートSSLプロトコル機能を追加します。

ステップアップとは、旧式で低強度の暗号化ブラウザのステップアップを可能にする機能であり、これにより、512ビットより長い公開キーおよび64ビットより長いバルク暗号化キーをSSLプロトコルで使用できるようになります。つまり、512ビットを超える公開キーを含みかつステップアップ・デジタル著作権を含むサーバーX.509証明書が、Oracle Application Serverで使用できるようになりました。このような証明書は、(通常は証明書自体に1024ビット証明書が含まれますが)しばしば128ビット証明書と呼ばれます。Verisign Secure Site Proはこのような証明書の一例であり、Oracle Application Serverで使用できるようになっています。

グローバル・サーバーID機能は、デフォルトで用意されています。

PKCS #11のサポート

公開キー暗号化規格#11(略してPKCS #11)とは、システムがハードウェア・セキュリティ・モジュールを使用する方法の概要を示した公開キー暗号化仕様であり、これは基本的に、暗号化機能(暗号/復号)が実行され、暗号化キーが格納される「箱」となっています。

Oracle HTTP Serverでは、nCipherによる専用のSSLハードウェアを使用するオプションをサポートしています。nCipherは、認証されたサード・パーティのアクセラレータで、SSLで使用されるPKI暗号のパフォーマンスを改善します。

SSLとロギング

SSLおよび通信関連のデバッグは、SSLTraceLogLevelディレクティブを使用して設定できます。ここでは、ロギング要件に従って、ログ・レベルの様々な冗長性を設定できます。このディレクティブは、SSLログおよび通信ログを生成します。「SSLTraceLogLevelディレクティブ」を参照してください。

ノート:

SSLログは、Oracle HTTP ServerログがINFO以上のレベルに設定されたときに機能します。

SSLリクエストの終了

この項では、mod_wl_ohsモジュールがWebLogic Serverにリクエストを転送する、Oracle HTTP Serverの前あるいはその中で、SSLを使用してリクエストを停止する方法を説明します。リクエストがOracle HTTP Serverに届く前にSSLを停止するか、リクエストがサーバーの中にある時に停止するかは、トポロジによります。SSLを停止する一般的な理由は、第三者によって通信中のデータが傍受されるリスクを伴うことなく、別の方法によって内部ネットワークが保護されている場合の、パフォーマンス上の考慮によるものです。もうひとつの理由としては、WebLogic ServerがHTTPSリクエストを受け付けるように構成されていない場合があります。

この項には次のトピックが含まれます:

ロード・バランサでのSSLの停止について

SSLを使用しているリクエストをOracle HTTP Serverへの到達前に終了させるロード・バランサやリバース・プロキシなどの装置を使用している場合には、サーバーは、あたかもHTTPSを介して受信したようにリクエストを扱う構成とする必要があります。さらに、サーバーは、クライアントにHTTPS応答を返すように構成される必要があります。

表10-1に、ブラウザからHTTPSを介してWebLogic Serverにリクエストが送信される場合の例を示します。ロード・バランサは、SSLを停止し、リクエストをHTTPとして送信します。Oracle HTTP Serverは、あたかもHTTPSを介して受信したようにリクエストを処理する構成とする必要があります。

図10-1 Oracle HTTP Serverの前にSSLを停止

図10-1の説明が続きます
「図10-1 Oracle HTTP Serverの前にSSLを停止」の説明
ロード・バランサでのSSLの停止

Oracle HTTP Serverに命令を与えてHTTPSを介して受信されたかのようにリクエストを扱うには、mod_certheadersモジュールのSimulateHttpsディレクティブでhttpd.confファイルを構成します。

mod_certheadersモジュールでの詳細は、mod_certheadersモジュール—リバース・プロキシの有効化を参照してください。

ノート:

SSLがOracle HTTP Serverで構成されている場合(すなわち、HTTPSを使用して直接Oracle HTTP Serverにアクセスしている場合)には、この手順は不要です。

  1. サーバーの外部名とポート番号を使用して、たとえばhttpd.conf構成ファイルを次のように構成します。
    ServerName <www.example.com:port>
    
  2. mod_certheadersモジュールをロードするように、httpd.conf構成ファイルをたとえば次のように構成します。
    • UNIX:

      LoadModule certheaders_module libexec/mod_certheaders.so
      
    • Windowsの場合:

      LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
      AddModule mod_certheaders.c

      ノート:

      他のAddModuleディレクティブにAddModule行を含めることを推奨します。

  3. HTTPS応答をクライアントに返すように、httpd.confファイルの最後にあるSimulateHttpsディレクティブをたとえば次のように構成します。
    # For use with other load balancers and front-end devices:
    SimulateHttps On
    
  4. Oracle HTTP Serverを再起動してサーバーへのアクセスをテストします。特に、https://host:port/index.htmlのような静的ページにアクセス可能であるかテストします。

    基本設定として構成をテストします。問題が生じた場合には、仮想ホストなどの潜在的な問題とのオーバーラップを避けるため、ここでトラブルシューティングを行ってください。

  5. 理想的には、すべてのHTTPSリクエストを処理するようにhttpd.confファイルのVirtualHostを構成するとよいでしょう。こうすると、HTTPSリクエストがHTTPリクエストからよりスケーラブルに分離されます。多目的サイトの場合や、ロード・バランサなどの装置がHTTPリクエストとHTTPSリクエストの両方を処理するOracle HTTP Serveの前にある場合には、こうした構成がさらに望まれます。

    次の命令例では、mod_certheadersモジュールをロードし、HTTPSリクエストだけを処理するように仮想ホストを生成します。

    # Load correct module here or where other LoadModule lines exist:
    LoadModule certheaders_module libexec/mod_certheaders.so
    # This only handles https requests:
       <VirtualHost <name>:<port>
           # Use name and port used in url:
           ServerName <www.example.com:port>
           SimulateHttps On
           # The rest of your desired configuration for this VirtualHost goes here
       </VirtualHost>
    
  6. Oracle HTTP Serverを再起動し、サーバーへのアクセスをテストします。最初にhttps://host:port/index.htmlのような静的ページをテストし、次にご使用のアプリケーションをテストします。
Oracle HTTP ServerでのSSLの停止について

SSLがOracle HTTP Serverで構成されていてOracle WebLogic Serverでは構成されていない場合には、Oracle HTTP Serverから送信されるリクエストに対するSSLを停止できます。

次の図はリクエスト・フローをまとめたもので、HTTPSがどこで停止するかを示しています。図10-2では、ブラウザからHTTPSリクエストが送信されます。ロード・バランサは、HTTPSリクエストをOracle HTTP Serverに送信します。SSLはOracle HTTP Serverで停止し、HTTPリクエストがWebLogic Serverに送られます。

図10-2 Oracle HTTP ServerでSSLを停止(ロード・バランサあり)

図10-2の説明が続きます
「図10-2 Oracle HTTP ServerでSSLを停止(ロード・バランサあり)」の説明

図10-3では、ロード・バランサは存在せず、HTTPSリクエストは直接Oracle HTTP Serverに送信されます。この場合にも、SSLはOracle HTTP Serverで停止し、HTTPリクエストがWebLogic Serverに送られます。

図10-3 Oracle HTTP ServerでSSLを停止(ロード・バランサなし)

図10-3の説明が続きます
「図10-3 Oracle HTTP ServerでSSLを停止(ロード・バランサなし)」の説明
Oracle HTTP ServerでSSLを停止

Oracle HTTP Serverに命令を与えてHTTPSを介して受信されたかのようにリクエストを扱うには、mod_wl_ohs.confファイルのWLSProxySSLディレクティブを構成し、SecureProxyディレクティブが構成されていないことを確認します。

  1. mod_wl_ohs.confファイルを構成して、ご使用の非SSL構成の管理対象サーバーの場所に対するWLSProxySSLディレクティブを追加します。
    たとえば:
    WLProxySSL ON
    
  2. ロード・バランサなどの装置をOracle HTTP Server (同じくSSLを使用)の前で使用している場合には、WL-Proxy-SSLをすでに設定済であるかどうかによって、かわりにWLProxySSLPassThroughディレクティブを構成することが必要な場合があります。
    たとえば:
    WLProxySSLPassThrough ON
    

    詳細は、ご使用のロード・バランサのドキュメントを参照してください。WLProxySSLPassThroughの詳細は、『Oracle WebLogic Serverプロキシ・プラグインの使用』Oracle WebLogic Serverプロキシ・プラグインのパラメータに関する項を参照してください。

  3. コンポーネント間の所定の通信に障害を与えますので、SecureProxyディレクティブが構成されていないことを確認してください。
    SSLが全体的に使用されている場合にかぎり、このディレクティブを使用します。次の例では、SecureProxyディレクティブはコメントアウトされています。
    # To configure SSL throughout (all the way to WLS):
    # SecureProxy ON
    # WLSSLWallet  "<Path to Wallet>" 
    
  4. 管理対象サーバーまたはクラスタに対してWebLogicプラグインを有効にします。
    デフォルトでは、このオプションは有効ではありません。次のステップを完了して、WebLogicプラグイン・フラグを有効にします。
    1. Oracle WebLogic Server管理コンソールにログインします
    2. 「ドメイン構造」ペインで「環境」ノードを開きます。
    3. 「クラスタ」をクリックします。
    4. Oracle HTTP Serverからのリクエストをプロキシ設定する、クラスタを選択します。
      「構成」→「一般」タブが表示されます。
    5. 「詳細」セクションまでスクロール・ダウンして、開きます。
    6. 「ロックして編集」をクリックします
    7. 「WebLogicプラグインの有効化」「はい」に設定します。
    8. 変更を保存してアクティブ化をクリックします。
    9. サーバーを再起動して、変更内容を有効にします。
  5. Oracle HTTP Serverを再起動してJavaアプリケーションへのアクセスをテストします。
    たとえば: https://host:port/path/application_name

mod_securityの使用

mod_securityは、Oracle HTTP Serverに対する侵入攻撃を検出および防止できる、オープンソース・モジュールです。

mod_securityを使用して侵入を防止できる方法の例は、mod_securityルールを指定して、すべての受信リクエストをスクリーニングし、ルールで指定された条件に一致するリクエストを拒否することなどがあります。mod_securityモジュール(バージョン2.7.2)とその前提条件は、mod_security2.soという共有オブジェクトとして、ORACLE_HOME/ohs/modulesディレクトリ内のOracle HTTP Serverインストールに含まれています。

「mod_securityモジュールの構成」を参照してください。

信頼フラグの使用

信頼フラグを使用すると、証明書に割り当てられた適切なロールによる、証明書チェーンの検証やパスの構築などの操作が簡単に実行できます。ただし、デフォルトでは、ウォレットで信頼フラグはサポートされていません。

orapkiユーティリティを使用して、Oracleウォレットにインストールされている証明書に信頼フラグを保持できます。また、信頼フラグをサポートするウォレットの作成と変換、適切なフラグの作成と各証明書での保持などを実行できます。信頼フラグと、それらをセキュリティ戦略に組み込む方法の詳細は、Oracle Fusion Middlewareの管理信頼フラグの作成および管理を参照してください。

Oracle HTTP Serverでの完全な前方秘匿性の有効化

完全な前方秘匿性(PFS)は、サーバーの秘密キーが損なわれた場合でもセッション・キーが損なわれないことを保証する特定のキー・アグリーメント・プロトコルの機能です。

Apacheでは、SSLHonorCipherOrderディレクティブが使用されます。このディレクティブは、Oracle HTTP Server 12.2.1以上でサポートされます。

Oracle HTTP Serverのすぐに利用可能な構成では、完全な前方秘匿性の機能が明示的に有効化されていません。PFSを有効化するには、Oracle HTTP Serverで次の構成の変更を行います:

  1. SSLProtocolディレクティブを使用して、OHSサーバーのTLS1.2プロトコルを構成します。「SSLProtocolディレクティブ」を参照してください。
  2. SSLHonorCipherOrderをONに設定して、サーバー暗号スイートの順序を強制します。「SSLHonorCipherOrderディレクティブ」を参照してください。
  3. Oracle HTTP ServerウォレットでECC証明書を使用します。『Oracle Fusion Middlewareの管理』orapkiを使用したECC証明書のOracleウォレットへの追加に関する項を参照してください。
  4. OHSでECDHE_ECDSA暗号スイートを構成します。サポートされているECDHE_ECDSA暗号スイートのリストは、「SSLCipherSuiteディレクティブ」を参照してください。