test

Sun Java System Portal Server 7.1 配備計画ガイド

Secure Remote Access ゲートウェイ

Secure Remote Access ゲートウェイはスタンドアロン Java プロセスです。状態情報をエンドユーザーにとって透過的に再構築することができるので、ステートレスと考えることができます。SRA ゲートウェイは、設定されたポートで待機し、HTTP 要求と HTTPS 要求を受け入れます。要求を受け取ると、セッションの有効性とヘッダー情報を確認して、要求のタイプを判別します。SRA ゲートウェイは要求のタイプに応じて次の処理を実行します。

すべてのゲートウェイ設定情報は、Access Manager の LDAP データベースにプロファイルとして保管されます。ゲートウェイプロファイルは、ゲートウェイに関連するすべての設定情報を含んでいます。

ホスト名や IP アドレスなどのマシン固有の情報は、ゲートウェイがインストールされているローカルファイルシステムの設定ファイルに保管されます。この情報により、複数のマシンで動作するゲートウェイどうしの間で 1 つのゲートウェイプロファイルを共有できます。

上述のとおり、SRA ゲートウェイは、HTTP モードと HTTPS モードの両方で同時に稼働するように設定できます。この設定により、イントラネットとエクストラネットの両方のユーザーが同じゲートウェイにアクセスできます。エクストラネットのユーザーは HTTPS を使用し、イントラネットのユーザーは SSL オーバーヘッドのない HTTP を使用します。

複数のゲートウェイインスタンス

必要に応じて、1 台のマシンで複数のゲートウェイインスタンスを実行できます。それぞれのゲートウェイインスタンスは、別々のポートで待機します。ゲートウェイインスタンスを設定して、同じ Portal Server インスタンスまたは異なる Portal Server インスタンスと通信できます。同じマシンのゲートウェイで複数インスタンスを実行する場合は、個別の証明書データベースをゲートウェイの各インスタンスに関連付け、そのゲートウェイをドメインにバインドすることができます。これにより各ドメインで異なるゲートウェイサーバーの証明書を使用でき、柔軟性が高まります。

複数の Portal Server インスタンス

注 –

ゲートウェイの前では、Netlet を使用しているのでないかぎりセッション固定は不要です。パフォーマンスは、セッション固定により向上します。一方、Portal Server インスタンスへのセッション固定は Secure Remote Access によって維持されます。

プロキシ

ゲートウェイは、ゲートウェイのプロファイルで指定されたプロキシを使用して、イントラネットとエクストラネット内部のさまざまな Web サーバーからコンテンツを取得します。プロキシは、ホストおよび DNS のサブドメインとドメインの専用にすることができます。ゲートウェイは、プロキシ設定に応じて適切なプロキシを使用し、要求されたコンテンツを取得します。プロキシで認証が要求される場合は、プロキシ名がゲートウェイプロファイルの一部として保管され、ゲートウェイはプロキシに接続する際にその名前を自動的に使用します。

ゲートウェイと HTTP 基本認証

ゲートウェイは基本認証をサポートするので、ユーザー ID とパスワードの入力を求めるプロンプトを表示しますが、ユーザーのコンピュータからサイトの Web サーバーまでの送信時にそれらの資格を保護しません送信する資格を保護するには、セキュリティー保護された HTTP 接続を確立する必要があり、通常はSSL を使用します。

Web サーバーが基本認証を要求する場合、クライアントはユーザー名とパスワードの入力を求めてプロンプトを表示し、要求しているサーバーに情報を送信します。HTTP 基本認証が有効なゲートウェイは、ユーザー名とパスワードの情報を捕捉し、その後に行われる認証とログインに備えて、それらの情報のコピーを Access Manager のユーザープロファイルに保存します。元のデータはゲートウェイから宛先 Web サーバーに送信され、基本認証が実行されます。Web サーバーはユーザー名とパスワードを検証します。

ゲートウェイにより、個々のホストでこの機能を拒否および許可する設定を細かく制御することもできます。

ゲートウェイと SSL サポート

SRA ゲートウェイは、HTTPS モードで動作するとき、SSL v2 と SSL v3 の両方の暗号化をサポートします。Portal Server 管理コンソールを使用して、特定の暗号化機能を有効または無効にできます。ゲートウェイは Transport Layer Security (TLS) もサポートします。

SSL v3 には、2 つの認証モードがあります。

Personal Digital Certificate (PDC) 認証は、SSL クライアント認証によってユーザーを認証するメカニズムです。ゲートウェイは、Access Manager 認証モジュールをサポートすることによって PDC 認証をサポートします。SSL クライアント認証を使用して、SSL ハンドシェークがゲートウェイで終了します。この PDC ベースの認証は、Access Manager の証明書ベースの認証とともに統合されます。したがってクライアント認証は、ゲートウェイによってではなく Access Manager によって処理されます。

セッション情報が HTTP または HTTPS 要求の一部として検出されない場合、ゲートウェイは、Access Manager からログイン URL を取得して、ユーザーを直接認証ページに誘導します。同様に、セッションが要求の一部として無効であることを検出すると、ゲートウェイはユーザーをログイン URL に誘導し、ログインが正常に行われるとユーザーを要求された宛先に誘導します。

SSL セッションが確立されると、ゲートウェイは送信されてくる要求を受信し続け、セッションの有効性を確認し、宛先の Web サーバーに要求を転送します。

ゲートウェイサーバーはすべての Netlet トラフィックを処理します。送信されてくるクライアント要求が Netlet トラフィックの場合、ゲートウェイはセッションの有効性を確認し、トラフィックを復号化して、アプリケーションサーバーに転送します。Netlet プロキシが有効な場合、ゲートウェイはセッションの有効性を確認して、Netlet プロキシに転送します。Netlet プロキシはトラフィックを復号化してアプリケーションサーバーに転送します。

注 –

40 ビットの暗号化は安全性が低いので、ゲートウェイには、40 ビット暗号化ブラウザからの接続を拒否するためのオプションが用意されています。

ゲートウェイのアクセス制御

ゲートウェイは、許可される URL リストと拒否される URL リストを使用してアクセス制御を実施します。URL のアクセスが許可されている場合でも、ゲートウェイは、Access Manager セッションサーバーと照会してセッションの有効性を確認します。許可される URL リストと拒否される URL リストと同様、非認証 URL リストにある URL はセッション検証を省略します。拒否される URL リストのエントリは、許可される URL リストのエントリよりも優先されます。特定の URL がいずれかのリストに記載されていない場合、その URL に対するアクセスは拒否されます。許可される URL リストと拒否される URL リストのどちらの場合でも、URL の一部としてワイルドカード文字 * も使用できます。

ゲートウェイのロギング

ゲートウェイでのロギングを有効にすることにより、ユーザーの動作をすべて監視できます。ゲートウェイは Portal Server ロギング API を使用してログを作成します。

ゲートウェイでのアクセラレータの使用

専用ハードウェアコプロセッサであるアクセラレータを設定して、サーバーの CPU から SSL 機能の負荷を取り除くことができます。アクセラレータを使用すると、CPU をほかのタスクに振り分けられるようになり、SSL トランザクションの処理速度が向上します。