Secure Remote Access 論理アーキテクチャーの例

Secure Remote Access ゲートウェイは、インターネットから送信されるリモートユーザーセッションと企業イントラネットの間のインタフェースおよびセキュリティーバリアとして機能します。ゲートウェイには、次の 2 つの主な機能があります。

• 受信ユーザーセッションに対する、身元の確認やプラットフォームへのアクセス の許可または拒否などの基本認証サービスを提供します。

• ユーザー向けにイントラネットのコンテンツへの Web ベースのリンクを有効にするためのマッピングサービスと書き換えサービスを提供します。

インターネットアクセスの場合、128 ビット SSL を使用して、ユーザーのブラウザとPortal Server 間の最高のセキュリティー対策と暗号化、または通信を実現します。ゲートウェイ、Netlet、NetFile、Netlet プロキシ、リライタプロキシ、およびプロキシレットが Secure Remote Access の主なコンポーネントです。

ここでは、それらのコンポーネントの可能な構成をいくつか示します。このセクションでは、指針を示すだけで、完全な配備の参考情報を提供するわけではありません。業務のニーズに基づいて構成を選択してください。

• 「基本 Secure Remote Access 構成」

• 「Netlet の無効化」

• 「プロキシレット」

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

• 「Netlet プロキシとリライタプロキシ」

• 「別々のノードにある Netlet プロキシとリライタプロキシ」

• 「2 つのゲートウェイと Netlet プロキシ」

• 「アクセラレータを使用するゲートウェイ」

• 「サードパーティーのプロキシを使用する Netlet」

• 「逆プロキシ」

authlessanonymous ページをゲートウェイ経由で表示するように設定するには、ゲートウェイプロファイルの非認証 URL に /portal/dt を追加します。ただし、これは、普通のユーザーの場合でも、ポータルページは認証を必要とせず、セッションの検証が実行されないことを意味します。

基本 Secure Remote Access 構成

図 4–12 は、Secure Remote Access のもっとも単純な構成を示しています。この図では、クライアントのブラウザが NetFile および Netlet を実行しています。ゲートウェイは、2 つのファイアウォールの間の DMZ 内の個別のマシンにインストールされています。Portal Server は、イントラネット内の 2 番目のファイアウォールの外側に置かれています。クライアントがアクセスする他のアプリケーションホストも、イントラネット内の 2 番目のファイアウォールの外側に置かれています。

ゲートウェイは、DMZ 内にあり、ファイアウォール内の開いた外部ポートを通してクライアントのブラウザがゲートウェイと通信します。2 番目のファイアウォールでは、HTTP または HTTPS トラフィックのために、ゲートウェイは内部ホストと直接通信できます。セキュリティーポリシーがこれを許可しない場合は、ゲートウェイと内部ホストとの間に Secure Remote Access プロキシを使用します。Netlet トラフィックの場合、ゲートウェイから目的のホストへの直接接続になります。

Secure Remote Access プロキシを使用しない場合、SSL トラフィックはゲートウェイに制限され、ゲートウェイと内部ホスト間ではトラフィックは暗号化されません (内部ホストが HTTPS モードで実行されていないかぎり)。内部ホストに対してゲートウェイが Netlet 接続を開始する必要がある内部ホストは、DMZ から直接アクセス可能である必要があります。これはセキュリティーの問題になる可能性があるので、この構成はもっとも単純なインストールにのみ推奨します。

図 4–12 基本 Secure Remote Access 構成

Netlet の無効化

図 4–13 は、Netlet が無効ということ以外は基本 Secure Remote Access 構成と同様のシナリオを示しています。クライアントの配備がイントラネットと通信する必要があるアプリケーションを安全に実行するために Netlet を使用しない場合は、パフォーマンス向上のためにこの構成を使用します。

この構成を拡張して、他の配備シナリオと組み合わせて、パフォーマンスを向上し、拡張可能なソリューションを提供できます。

図 4–13 Netlet の無効化

プロキシレット

図 4–14 で示すプロキシレットは、イントラネットのリソースをクライアントに公開しなくても、ユーザーがインターネットを使用してイントラネットのリソースに安全にアクセスできるようにします。

プロキシレットでは、ゲートウェイのトランスポートモード (HTTP または HTTPS のどちらか) が継承されます。

図 4–14 プロキシレット

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

図 4–15 は、Secure Remote Access の基本構成の拡張を示しています。複数のゲートウェイインスタンスが、同じマシンまたは複数のマシンで稼働します。別々のプロファイルで複数のゲートウェイインスタンスを起動できます。

図 4–15 複数のゲートウェイインスタンス

図 4–15 はゲートウェイと Portal Server の 1 対 1 の対応を示していますが、実際の配備では必ずしもこのようになる必要はありません。複数のゲートウェイインスタンスや複数の Portal Server インスタンスを配備可能であり、また構成によってはどのゲートウェイも任意の Portal Server にアクセスできます。

この構成の欠点は、各接続要求のために 2 番目のファイアウォールで複数のポートを開く必要があるということです。これは、セキュリティーの問題になる可能性があります。

Netlet プロキシとリライタプロキシ

図 4–16 は、Netlet プロキシとリライタプロキシがある構成を示しています。これらのプロキシの場合、2 番目のファイアウォールではポートが 2 つだけ開いている必要があります。

この構成では、ゲートウェイはアプリケーションホストと直接やり取りする必要はありませんが、すべての Netlet トラフィックを Netlet プロキシへ、リライタトラフィックをリライタプロキシへ転送します。Netlet プロキシはイントラネット内にあるので、2 番目のファイアウォールで複数のポートを開かなくても、すべての必要なアプリケーションホストと直接やり取りできます。

DMZ 内のゲートウェイと Netlet プロキシとの間のトラフィックは暗号化され、Netlet プロキシでのみ復号化されるので、セキュリティーが向上します。

リライタプロキシが有効な場合、要求が Portal Server ノード宛てのものかどうかにかかわらず、すべてのトラフィックがリライタプロキシに転送されます。これによって、DMZ 内のゲートウェイからイントラネットへのトラフィックは常に暗号化されることが保証されます。

Netlet プロキシ、リライタプロキシ、および Portal Server がすべて同じノードで稼働するので、そのような配備シナリオではパフォーマンスの問題が発生する場合があります。この問題は、Portal Server ノードの負荷を軽減するためにプロキシを別々のノードにインストールすると解決できます。

図 4–16 Netlet プロキシとリライタプロキシ

別々のノードにある Netlet プロキシとリライタプロキシ

Portal Server ノードの負荷を軽減し、なおかつパフォーマンスを向上させて同じレベルのセキュリティーを提供するには、Netlet プロキシとリライタプロキシを別々のノードにインストールできます。この配備は、プロキシを使用して Portal Server を DMZ から保護できるというさらなる利点があります。これらのプロキシを実行するノードは、DMZ から直接アクセス可能である必要があります。

図 4–17 は、別々のノードにある Netlet プロキシとリライタプロキシを示しています。ゲートウェイからのトラフィックは別のノードに転送され、そのノードはトラフィックをプロキシ経由で、必要なイントラネットのホストに転送します。

Netlet プロキシとリライタプロキシの複数のインスタンスを持つことや複数の Netlet プロキシとリライタプロキシをインストールすることが可能です。各ゲートウェイを、可用性に応じてラウンドロビン方式でプロキシのさまざまなインスタンスとのやり取りを試みるように設定できます。

図 4–17 別々のノードにあるプロキシ

2 つのゲートウェイと Netlet プロキシ

ロードバランサは、Portal Server および Access Manager の冗長サービスの高可用性のためのフェイルオーバーのメカニズムを提供します。

図 4–18 2 つのゲートウェイと Netlet プロキシ

アクセラレータを使用するゲートウェイ

外部の SSL デバイスをオープンモードでゲートウェイの前で実行するように設定できます。これは、クライアントと Secure Remote Access の間に SSL リンクを提供します。アクセラレータの詳細は、Sun Java System Portal Server 7.1 Secure Remote Access 管理ガイドを参照してください。

図 4–19 外部のアクセラレータを使用する Secure Remote Access ゲートウェイ

サードパーティーのプロキシを使用する Netlet

図 4–20 は、サードパーティーのプロキシを使用して、2 番目のファイアウォールのポートの数を 1 つに制限する例を示しています。サードパーティーのプロキシを使用して、リライタプロキシまたは Netlet プロキシに到達するようにゲートウェイを設定できます。

図 4–20 Netlet とサードパーティーのプロキシ

逆プロキシ

プロキシサーバーがインターネットのコンテンツをイントラネットに配信するのに対して、逆プロキシサーバーはイントラネットのコンテンツをインターネットに配信します。逆プロキシの特定の配備の際に、インターネットコンテンツのロードバランスおよびキャッシングが行われるように設定できます。

図 4–21 は、インターネットとイントラネットの両方のコンテンツを承認されたユーザーに配信するために、ゲートウェイの前に逆プロキシを配置する方法を示しています。ゲートウェイが Web コンテンツを配信するときには、このコンテンツに基づいた後続するブラウザの要求すべてがゲートウェイを通じてルーティングされるようにする必要があります。これは、このコンテンツ内のすべての URL を確認し、必要に応じて書き換えることによって実現します。

図 4–21 ゲートウェイの前に逆プロキシを使用