test

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

Secure Remote Access コンポーネント

このセクションでは、次の Secure Remote Access コンポーネントについて説明します。

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 トランザクションの処理速度が向上します。

Netlet

Netlet により、イントラネットで使用可能な固定ポートアプリケーションと一部の動的ポートアプリケーションに対するイントラネットの外部からのアクセスをセキュリティー保護します。クライアントは、リモートファイアウォールと SSL プロキシの背後に配置することも、直接インターネットに接続することもできます。Netlet を介して、イントラネットの外部からイントラネットアプリケーションにセキュリティー保護して確立される接続は、Netlet ルールに従って制御されます。

ブラウザで動作する Netlet アプレットにより、リモートクライアントマシンとリモートホストのイントラネットアプリケーションの間で、暗号化された TCP/IP トンネルが設定されます。Netlet は事前設定されたポートで待機して接続を受け入れ、クライアントと宛先サーバーの間で送受信されるトラフィックを経路指定します。送受信される両方のトラフィックは、ユーザーが選択した、または管理者によって設定された暗号化アルゴリズムによって暗号化されます。Netlet ルールには、接続で使用されるすべてのサーバー、ポート、および暗号化アルゴリズムに関する詳細が記述されています。管理者は、Portal Server 管理コンソールを使用して Netlet ルールを作成します。

静的および動的なポートアプリケーション

静的ポートアプリケーションは、既知つまり静的ポートで動作します。たとえば、IMAP や POP サーバー、Telnet デーモン、jCIFS などがあります。静的ポートアプリケーションの場合は、Netlet ルールに宛先サーバーポートが記述されているので、要求を直接宛先に経路指定できます。

動的アプリケーションは、ハンドシェークの一部で通信用ポートについて同意します。宛先サーバーポートを Netlet ルールの一部にすることもできます。Netlet は、プロトコルを理解し、データを調べて、クライアントとサーバーの間で使用されるポートを検出する必要があります。FTP は動的ポートアプリケーションです。FTP の場合、クライアントとサーバー間の実際のデータ転送用ポートは、PORT コマンドによって指定されます。この場合、Netlet はトラフィックをパースして、動的にデータチャネルポートを取得します。

現行では、FTP と Microsoft Exchange だけが、Portal Server によってサポートされる動的ポートアプリケーションです。

注 –

Microsoft Exchange 2000 は Netlet によってサポートされていますが、以下の制約があります。

Netlet とアプリケーション統合

Netlet は、Graphon、Citrix、pcAnywhere などの多くのサードパーティー製品で動作します。それらの各製品は、リモートマシンからユーザーのポータルデスクトップへのアクセスを Netlet を使用してセキュリティー保護します。

スプリットトンネリング

スプリットトンネリングにより、VPN クライアントは、VPN に接続または VPN から切断することなく、セキュリティー保護されたサイトおよびセキュリティー保護されていないサイトの両方に接続できます。この場合の VPN は Netlet です。クライアントは、暗号化パスを通して情報を送信するか、または非暗号化パスを使用して送信するかどうかを判別します。スプリットトンネリングの問題点は、セキュリティー保護されていないインターネットから、クライアントを介して VPN によるセキュリティー保護ネットワークに直接接続が可能であることです。スプリットトンネリングをオフにすると両方の接続が同時に許可されることがなくなり、インターネット侵入に対する VPN 接続 (この場合は Netlet 接続) の脆弱性が低減します。

Portal Server は、ポータルサイトに接続されている間、複数のネットワーク接続を禁止したりシャットダウンしたりしませんが、権限のないユーザーが他のユーザーのセッションに便乗 (piggybacking) する行為を次の方法で阻止します。

Netlet プロキシ

Netlet プロキシは、ゲートウェイと宛先ホストを接続するために、ファイアウォールで開く必要のあるポート数を少なくするのに役立ちます。

たとえば、イントラネット内部で多数の Telnet、FTP、および Microsoft Exchange サーバーを接続するために、Netlet を必要とする設定について考えてみます。ゲートウェイは DMZ 内にあると仮定します。ゲートウェイがトラフィックをすべての宛先サーバー向けて経路指定する場合は、第 2 ファイアウォールでかなりの数のポートを開いておく必要があります。この問題を軽減するため、第 2 ファイアウォールの背後に Netlet プロキシを配置し、Netlet プロキシにトラフィックを転送するようにゲートウェイを設定できます。その後、Netlet プロキシがすべてのトラフィックをイントラネット内のすべての宛先サーバーに経路指定するので、第 2 ファイアウォールで開く必要のあるポート数を減らすことができます。また、第 2 ファイアウォールの背後に複数の Netlet プロキシを配置して、シングルポイント障害を回避することもできます。

サードパーティーのプロキシを使用して第 2 ファイアウォールのポートを 1 つだけ使用することも可能です。

注 –

Netlet プロキシを別のノードにインストールすると、Netlet トラフィックの負荷が別のノードに分散されるので、Portal Server の応答時間を短くすることができます。

NetFile

NetFile により、企業のイントラネット内部にセキュリティー保護されて常駐するファイルシステムに、リモートアクセスして操作することができます。

NetFile は、NFS、jCIFS、および FTP などの標準プロトコルを使用して、ユーザーがアクセス権を持つすべての UNIX または Microsoft Windows ファイルシステムに接続します。NetFile を使用して、ファイル管理アプリケーションで一般的なほとんどのファイル操作を実行できます。

コンポーネント

さまざまなファイルシステムにアクセスするため、NetFile には 3 つのコンポーネントが組み込まれています。

NetFile は国際化されているので、ロケール (文字エンコード) に関係なくファイルシステムにアクセスできます。

NetFile は、Access Manager を使用して、NetFile 自体のプロファイル、ユーザー設定、および優先設定を保存します。NetFile は、Portal Server 管理コンソールを使用して管理します。

初期化

Portal Server デスクトップでユーザーが NetFile リンクを選択すると、NetFile サーブレットは、ユーザーが有効な SSO トークンを持ち、NetFile を実行する権限を持っているかどうかを確認します。有効なトークンと権限を確認できると、アプレットがブラウザにレンダリングされます。NetFile アプレットは、もう一度サーブレットに接続して、サイズ、ロケール、リソースバンドル、およびユーザー設定と優先設定など、それ自体の設定情報を取得します。NetFile は、ユーザーの SSO トークンを使用して、ロケール情報と、ユーザー名、メール ID、およびメールサーバーなどの他のユーザー情報を取得します。ユーザー設定には、ユーザーが組織またはロールから継承した設定、ユーザーによってカスタマイズされた設定、および前の NetFile セッションを終了するときにユーザーが保存した設定などがあります。

資格の検証

NetFile は、ユーザーによって入力される資格を使用して、ファイルシステムへのアクセスを許可する前にユーザーを認証します。

資格には、ユーザー名、パスワード、および Microsoft Windows または Novell のどちらか該当するドメインなどがあります。それぞれの共有では独立パスワードを使用するので、ユーザーは共通ホストを除き、すべての追加する共有ごとに自分の資格を入力する必要があります。

NetFile は、Access Manager から UNIX 認証を使用して、NFS ファイルシステムへのアクセス権を与えます。FTP プロトコルと jCIFS プロトコルに従ってアクセスするファイルシステムの場合は、プロトコル自体が備える手法を使用して資格を検証します。

アクセス制御

NetFile は、さまざまな方法でファイルシステムのアクセス制御を行います。プロトコルに基づいて、特定のファイルシステムへのユーザーのアクセスを拒否できます。たとえば、NFS によってのみアクセス可能なファイルシステムへの特定のユーザー、ロール、または組織のアクセスを拒否できます。

NetFile を設定し、組織からサブ組織、およびユーザーにいたるまでのすべてのレベルで、ファイルシステムへのアクセスを許可または拒否できます。また、特定のサーバーへのアクセスを許可または拒否することも可能です。ユーザーのファイルシステムへのアクセスは、Microsoft Windows、FTP、NFS、および NetWare を介した FTP などのホストのタイプに応じて許可または拒否できます。たとえば、組織のすべてのユーザーに対し Microsoft Windows ホストへのアクセスを拒否できます。また、組織またはロールのレベルで共通ホストのセットを指定し、その組織またはロールのすべてのユーザーが共通ホストにアクセスできるようにして、ユーザーが各組織またはロールのすべてに自分を追加する必要をなくすこともできます。

NetFile サービスの一部として、許可される URL リストまたは拒否される URL リストを設定し、組織、ロール、またはユーザーのレベルでサーバーへのアクセスを許可または拒否できます。拒否される URL リストは、許可される URL リストよりも優先されます。許可される URL リストと拒否される URL リストには、ワイルドカード文字 * を使用して、同一ドメインまたはサブドメイン内のサーバーセットへのアクセスを許可または拒否できます。

セキュリティー

SSL 対応の Secure Remote Access を有効にして NetFile を使用すると、NetFile アプレットから背後のファイルシステムへのすべての接続は、ゲートウェイとブラウザの間に確立された SSL 接続を使用して実行されます。通常は、ゲートウェイを DMZ に設置し、第 2 ファイルウォールで開くポートの数を制限する (通常は 1 つのみ) ので、ファイルシステムへのアクセスを許可してもセキュリティーは低下しません。

特殊操作

NetFile は、一般的なファイル管理アプリケーションと同様、リモートファイル管理アプリケーションに適した機能セットを備えています。NetFile によりユーザーは、ローカルとリモートのファイルシステムの間でファイルをアップロードまたはダウンロードできます (共有)。ローカルからリモートファイルシステムにアップロードするファイルのサイズは、Portal Server 管理コンソールを使用して制限できます。

またユーザーは、複数のファイルを選択し、GZIP および ZIP で圧縮することも可能です。複数のファイルを選択し、複数の添付ファイルとして 1 通の電子メールで送信できます。NetFile は、Access Manager の SSO トークンを使用し、IMAP サーバー、ユーザー名、パスワード、および返信アドレスなどのユーザーの電子メール設定にアクセスして、電子メールを送信します。

NetFile ウィンドウのファイルをダブルクリックすると、MIME タイプに対応したアプリケーションが起動し、ファイルが開きます。NetFile には、一般的なほとんどのファイルタイプ (拡張子) をマッピングしたデフォルトの MIME タイプ設定ファイルと、編集して新規マッピングを追加できる MIME タイプがあります。

NetFile を使用してファイルを検索し、別のウィンドウにリストを表示できます。各検索結果は、以前の検索結果のウィンドウを表示した状態で、新規ウィンドウに表示されます。特定の共有で使用される文字エンコードのタイプはユーザーが設定でき、共有の設定項目の一部になっています。文字エンコード方法を指定しないと、共有機能で動作する間、NetFile は ISO-8859-1 を使用します。ISO-8859-1 エンコードは、ほとんどの共通言語を処理することができます。ISO-8859-1 エンコードにより、NetFile は任意の言語でファイルのリストを作成し、内容を破壊せずに任意の言語でファイルを変換できます。

NetFile は、ファイルを電子メールで送信する場合にのみ、NetFile Java 1 と Java 2 の両方で一時ファイルを作成します。一時ファイルは、Microsoft Windows ファイルシステムとローカルシステムファイルの間で、jCIFS プロトコルによってファイルをアップロードおよびダウンロードする時には作成されません。

注 –

NetFile は、ディレクトリとリモートファイルの削除をサポートします。リモートディレクトリ内のすべての内容は、再帰的に削除されます。

NetFile とマルチスレッド化

NetFile では、マルチスレッドを使用して、複数の操作を同時に実行する際の柔軟性を高めています。たとえば、ユーザーは検索操作を行い、ファイルのアップロードを開始して、電子メールでファイルを送信できます。NetFile はこれら 3 つの操作を同時に実行し、さらにユーザーがファイルのリストを参照することを許可します。

リライタ

リライタは、HTML と JavaScript コードの両方ですべての URI を変換し、イントラネットのコンテンツを常にゲートウェイを通して取得できるようにする独立コンポーネントです。ルールの集合であるルールセットを定義し、ページにリライトする必要のあるすべての URL を特定します。ルールセットは、Document Type Definition (DTD) に従って記述される XML コードです。リライタに付属する一般ルールセットを使用すれば、ルールを追加せずにほとんどの URL をリライトできます。ルールセットをドメインに関連付け、ドメインベースの変換も実行できます。

外部ルールセットはコンテンツの URI を識別します。Secure Remote Access によるサービスを必要とする要求はすべて、次の経路で処理されます。

ProcedureSecure Remote Access 要求の経路を指定する

  1. Secure Remote Access は、サービスを必要とするイントラネットページまたはインターネットページの URI を要求から特定します。

  2. Secure Remote Access は、プロキシ設定を使用して特定された URI に接続します。

  3. URI のドメインは、このコンテンツをリライトするために使用するルールセットを特定するために使用されます。

  4. コンテンツとルールセットを取得すると、Secure Remote Access はそれらの情報をリライタに入力し、特定された URI はそこで変換されます。

  5. 元の URI はリライトされた URI によって置き換えられます。

  6. このプロセスがドキュメントの最後まで繰り返されます。

  7. 生成されたリライタ出力は、ブラウザに経路指定されます。

リライタプロキシ

ファイアウォールで開くポート数を最小限に抑えるには、リライタプロキシを使用します。リライタプロキシをインストールすると、HTTP 要求は、宛先ホストに直接送信される代わりに、リライタプロキシにリダイレクトされます。次にリライタプロキシは、受け取った要求を宛先サーバーに送信します。

リライタプロキシを使用すると、ゲートウェイとイントラネットコンピュータの間の HTTP トラフィックをセキュリティー保護し、次の 2 つの利点を生かすことができます。

注 –

複数のリライタプロキシを稼働させれば、シングルポイント障害を防止し、ロードバランスを実現できます。

プロキシレット

プロキシレットは、クライアントマシン上で稼働する動的なプロキシサーバーです。プロキシレットは URL をゲートウェイにリダイレクトします。プロキシレットは、この機能を実現するために、クライアントマシン上のブラウザのプロキシ設定を読み込んでから、その設定がローカルプロキシサーバー ( プロキシレット) をポイントするように変更します。

プロキシレットでは、HTTP および SSL がサポートされ、ゲートウェイのトランスポートモードが継承されます。ゲートウェイが SSL に基づいて動作するように設定されている場合には、クライアントマシンとゲートウェイ間のチャネルのセキュリティーが確保されます。クライアントの JVM が 1.4 以降の場合または必要な jar ファイルがクライアントマシン上にある場合には、Java 2 Enterprise Edition API が使用されます。それ以外の場合には、KSSL API が使用されます。

プロキシレットは、クライアントの IP アドレスとポートが指定されている Portal Server 管理コンソールから有効にします。

プロキシレットは、リライタと異なり、インストール後の変更をほとんどまたはまったく必要としません。また、プロキシレットは Web コンテンツを処理しないので、ゲートウェイのパフォーマンスが向上します。