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およびmod_ossl)とWebGateにより提供されます。mod_auth_basic、mod_authn_file、mod_auth_user、mod_authz_groupfile、mod_osslおよびWebGateモジュールでは、ユーザー名とパスワードのペアに基づいて認証が行われます。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によって処理される静的ファイルなど)に伝搬します。

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機能について説明します。

PKCS #11のサポート

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

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

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 "${PRODUCT_HOME}/modules/mod_certheaders.so"
      
    • Windowsの場合:

      LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
      mod_certheaders.c
  3. HTTPS応答をクライアントに返すように、httpd.confファイルの最後にあるSimulateHttpsディレクティブをたとえば次のように構成します。
    # For use with other load balancers and front-end devices:
    SimulateHttps On
    
  4. Oracle HTTP Serverを再起動してサーバーへのアクセスをテストします。特に、http://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 "${PRODUCT_HOME}/modules/mod_certheaders.so"
    # This only handles https requests that are terminated at the Load Balancer:
       <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を再起動し、サーバーへのアクセスをテストします。最初にhttp://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プラグインを有効にします。
  5. Oracle HTTP Serverを再起動してJavaアプリケーションへのアクセスをテストします。
    たとえば: https://host:port/path/application_name

mod_securityの使用

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

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

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

信頼フラグの使用

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

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

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

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

TLSv1.3およびTLSv1.2プロトコルは、Oracle HTTP Serverのすぐに使用できる構成で有効になっています。TLSv1.3では、完全な前方秘匿性が義務付けられています。SSL接続でTLSv1.3を使用する場合、TLSv1.3プロトコルで完全な前方秘匿性を有効化するために、追加で必要なステップはありません。

SSL接続でTLSv1.2を使用する場合は、Oracle HTTP Serverで次の構成の変更を行ってPFSを有効にします:
  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ディレクティブ」を参照してください。