ソリューションライフサイクルの論理設計段階では、論理アーキテクチャーを作成します。論理アーキテクチャーでは、ソリューションの実装に必要なソフトウェアコンポーネント間の関係を識別します。
この章で説明する内容は次のとおりです。
高レベルの論理アーキテクチャーは、低レベルの論理アーキテクチャーの基になります。高レベルの論理アーキテクチャーは、事前に確定した業務および技術上の要件を満たす必要があります。論理アーキテクチャーは、システム全体を構成するさまざまなアプリケーションに従って、またユーザーがシステムと対話する方法に従って分解されます。一般に、論理アーキテクチャーには、Portal Server Secure Remote Access、高可用性、セキュリティー (Access Manager を含む)、および Directory Server アーキテクチャーコンポーネントが含まれます。
高レベルおよび低レベルのアーキテクチャーでは、ポータルの制御を超える要素、つまりネットワーク、ハードウェアの障害、不適切なチャネルの設計なども考慮する必要があります。
低レベルの設計では、物理アーキテクチャー、ネットワークインフラストラクチャー、ポータルデスクトップのチャネルおよびコンテナの設計、実際のハードウェアおよびソフトウェアのコンポーネントなどのアイテムを指定します。
高レベルの論理アーキテクチャーは、業務の要件と技術要件の両方をサポートします。高レベルの論理アーキテクチャーでは、次のような問いに答えます。
提案したアーキテクチャーが業務の要件と技術要件の両方をサポートするか。
何らかの変更でこのアーキテクチャーを強化できるか。
これを実現する代わりのアーキテクチャーがあるか。
システムの物理的なレイアウトはどのようなものであるか。
さまざまなコンポーネントと接続のマッピングはどのようなものであるか。
ユーザー、システム、およびユーザーがアクセスできるアプリケーションのさまざまな分類を記述する論理定義はどのようなものであるか。
時間の経過に伴う Web トラフィックの増加によって必要になるシステムへのハードウェアの追加を考慮した設計になっているか。
低レベルのアーキテクチャーでは、ポータルソリューションを構築するために使用するプロセスおよび標準の指定、また次のものを含む実際のハードウェアおよびソフトウェアコンポーネントの指定に焦点を合わせます。
Portal Server サーバーの複雑性。
ネットワーク接続: ポータルコンプレックスを「外の世界」にどのように接続するかを示します。ここでは、セキュリティーの問題、プロトコル、速度、および他のアプリケーションまたはリモートサイトへの接続を考慮する必要があります。
情報アーキテクチャー: ユーザーインタフェース、コンテンツのプレゼンテーションおよび構成、データソース、フィードなど。
Access Manager のアーキテクチャー: 長期にわたる成功に重要な、組織、サブ組織、ロール、グループ、ユーザーなどの方針および設計など。
統合方針: さまざまな情報を統合し、新しい方法でユーザーをまとめるための統合点としてポータルがどのようにふるまうかなど。
Portal Server の配備は、次のコンポーネントで構成されます。
Sun JavaTM System Access Manager
Access Manager により、ユーザーとサービスの管理、認証サービスとシングルサインオンサービス、ポリシー管理、ロギングサービス、デバッグユーティリティー、管理コンソール、および Portal Server のクライアントサポートインタフェースを使用できます。次のコンポーネントで構成されています。
Java Development Kit (JDKTM)。
Java Development Kit ソフトウェアは、Portal Server のすべての Java ソフトウェアおよび Portal Server を構成するコンポーネントに、Java ランタイム環境を提供します。Portal Server は、Web コンテナの JDK ソフトウェアに依存して動作します。
Java ソフトウェアのネットワークセキュリティーサービス
Sun Java System Web Server
Java API for XML Processing (JAXP)
Sun Java System Directory Server
Directory Server は、Portal Server の主要な設定およびユーザープロファイルデータリポジトリです。Directory Server は LDAP に準拠し、拡張可能なオープンスキーマを実装しています。
Web コンテナ
Sun Java System Web Server
Sun Java System Application Server Enterprise Edition
Web Server および Application Server ソフトウェアの代わりに、以下の Web コンテナを使用できます。
BEA WebLogic Server
IBM WebSphere® Application Server
さまざまな Web コンテナへの Portal Server の配備については、『Sun Java Enterprise System 2006Q5 インストールガイド』を参照してください。
Portal Server でサポートされる製品の特定のバージョンについては、最新の Portal Server リリースノートを参照してください。
設計には、ポータルを構成するコンポーネントだけでなく、次のものを含めるようにしてください (ただし、次のものに限定されません)。
RDBM からのコンテンツ
サードパーティーのコンテンツプロバイダ
カスタム開発のプロバイダおよびコンテンツ
メッセージングシステムやカレンダシステムなどのバックエンドシステムとの統合
コンテンツ管理システムのロール
顧客リソースの管理
ポータルがオープンモードまたはセキュアモード (Secure Remote Access が必要) のどちらで動作するか
使用の見積もり: これには、登録ユーザーの総数、1 日にログインする登録ユーザーの割合の平均、1 日に同時にログインするユーザーの平均の数、平均ログイン時間、ログインしたユーザーが選択したコンテンツチャネルの平均数、ログインしたユーザーが選択したアプリケーションチャネルの平均の数に対する予測が含まれます。
また、次の 3 つのネットワークゾーンがどのように設計に適合するかを考慮する必要があります。
インターネット。一般のインターネットとは、イントラネットと DMZ の外側にあるネットワークのことです。ユーザーのポータルサーバーとゲートウェイにここから安全にアクセスします。
非武装ゾーン (DeMilitarized Zone、DMZ)。2 つのファイアウォールの間にある安全な領域であり、無許可の侵入を防止し、内部リソースへのアクセスを可能にします。ゲートウェイは、この場所に存在し、ここからアプリケーションサーバーやコンテンツサーバーからのトラフィックをインターネットへ安全に転送できます。
イントラネット。すべてのリソースサーバーが含まれます。これには、イントラネットアプリケーション、Web コンテンツサーバー、およびアプリケーションサーバーが含まれます。Portal Server および Directory Server はここに存在します。
論理アーキテクチャーは、また次のようなものを含む、ポータルデスクトップの見た目と使い心地を記述します。
デフォルトのページ: デフォルトのバナー、ロゴ、チャネル、ページの重みの合計、つまりページのすべてのコンポーネント (HTML、スタイルシート、JavaScriptTM、イメージファイルなど) の総バイト数、ページに対する HTTP 要求の総数、つまりそのページをダウンロードするために必要な HTTP 要求の数が表示される。
パーソナライズされたページ: ユーザーが表示できるチャネルと利用できる設定などが表示される。
サイトが必要とする場合、キャッシングの方針も論理アーキテクチャーに含めます。ユーザーに返されるページに多数のイメージへの参照が含まれる場合、Portal Server がそれらのイメージをすべてのユーザーに配信できます。ただし、それらのタイプの要求を逆プロキシタイプのキャッシング装置にオフロードできる場合、Portal Server が他のユーザーにサービスを提供できるようにシステムリソースを解放できます。また、キャッシング装置をエンドユーザーの近くに配置することによって、それらのイメージをエンドユーザーにいくらか速く配信することができるので、エンドユーザーの使い勝手がよくなります。
このセクションでは、次の Secure Remote Access コンポーネントについて説明します。
Secure Remote Access ゲートウェイはスタンドアロン Java プロセスです。状態情報をエンドユーザーにとって透過的に再構築することができるので、ステートレスと考えることができます。SRA ゲートウェイは、設定されたポートで待機し、HTTP 要求と HTTPS 要求を受け入れます。要求を受け取ると、セッションの有効性とヘッダー情報を確認して、要求のタイプを判別します。SRA ゲートウェイは要求のタイプに応じて次の処理を実行します。
Netlet 要求。ユーザーがポータルデスクトップでクリックした Netlet ルールで指定されるサーバーに、要求 (トラフィック) を経路指定します。
HTTP(S) トラフィック。HTTP ヘッダーによって指定されたサーバーに要求を経路指定します。サーバーから応答を受け取ると、ゲートウェイは応答を変換し、応答内のすべてのイントラネットリンクがエクストラネットで有効になるようにします。
すべてのゲートウェイ設定情報は、Access Manager の LDAP データベースにプロファイルとして保管されます。ゲートウェイプロファイルは、ゲートウェイに関連するすべての設定情報を含んでいます。
ホスト名や IP アドレスなどのマシン固有の情報は、ゲートウェイがインストールされているローカルファイルシステムの設定ファイルに保管されます。この情報により、複数のマシンで動作するゲートウェイどうしの間で 1 つのゲートウェイプロファイルを共有できます。
上述のとおり、SRA ゲートウェイは、HTTP モードと HTTPS モードの両方で同時に稼働するように設定できます。この設定により、イントラネットとエクストラネットの両方のユーザーが同じゲートウェイにアクセスできます。エクストラネットのユーザーは HTTPS を使用し、イントラネットのユーザーは SSL オーバーヘッドのない HTTP を使用します。
必要に応じて、1 台のマシンで複数のゲートウェイインスタンスを実行できます。それぞれのゲートウェイインスタンスは、別々のポートで待機します。ゲートウェイインスタンスを設定して、同じ Portal Server インスタンスまたは異なる Portal Server インスタンスと通信できます。同じマシンのゲートウェイで複数インスタンスを実行する場合は、個別の証明書データベースをゲートウェイの各インスタンスに関連付け、そのゲートウェイをドメインにバインドすることができます。これにより各ドメインで異なるゲートウェイサーバーの証明書を使用でき、柔軟性が高まります。
ゲートウェイの前では、Netlet を使用しているのでないかぎりセッション固定は不要です。パフォーマンスは、セッション固定により向上します。一方、Portal Server インスタンスへのセッション固定は Secure Remote Access によって維持されます。
ゲートウェイは、ゲートウェイのプロファイルで指定されたプロキシを使用して、イントラネットとエクストラネット内部のさまざまな Web サーバーからコンテンツを取得します。プロキシは、ホストおよび DNS のサブドメインとドメインの専用にすることができます。ゲートウェイは、プロキシ設定に応じて適切なプロキシを使用し、要求されたコンテンツを取得します。プロキシで認証が要求される場合は、プロキシ名がゲートウェイプロファイルの一部として保管され、ゲートウェイはプロキシに接続する際にその名前を自動的に使用します。
ゲートウェイは基本認証をサポートするので、ユーザー ID とパスワードの入力を求めるプロンプトを表示しますが、ユーザーのコンピュータからサイトの Web サーバーまでの送信時にそれらの資格を保護しません送信する資格を保護するには、セキュリティー保護された HTTP 接続を確立する必要があり、通常はSSL を使用します。
Web サーバーが基本認証を要求する場合、クライアントはユーザー名とパスワードの入力を求めてプロンプトを表示し、要求しているサーバーに情報を送信します。HTTP 基本認証が有効なゲートウェイは、ユーザー名とパスワードの情報を捕捉し、その後に行われる認証とログインに備えて、それらの情報のコピーを Access Manager のユーザープロファイルに保存します。元のデータはゲートウェイから宛先 Web サーバーに送信され、基本認証が実行されます。Web サーバーはユーザー名とパスワードを検証します。
ゲートウェイにより、個々のホストでこの機能を拒否および許可する設定を細かく制御することもできます。
SRA ゲートウェイは、HTTPS モードで動作するとき、SSL v2 と SSL v3 の両方の暗号化をサポートします。Portal Server 管理コンソールを使用して、特定の暗号化機能を有効または無効にできます。ゲートウェイは Transport Layer Security (TLS) もサポートします。
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 により、イントラネットで使用可能な固定ポートアプリケーションと一部の動的ポートアプリケーションに対するイントラネットの外部からのアクセスをセキュリティー保護します。クライアントは、リモートファイアウォールと 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 によってサポートされていますが、以下の制約があります。
Portal Server の version 6.3 以前の場合 :
Exchange は静的ポートを使用するように設定する必要があります。
Netlet は Microsoft Windows 2000 および XP では動作しません。これは、Microsoft Windows 2000 と XP のクライアントが、RPC Portmapper の Exchange 用ポート (ポート 135) を Active Directory 用に予約しているからです。それ以前のバージョンの Microsoft Windows は、このポートを予約していません。ポートが予約されているので、そのポートに Netlet を割り当てることができず、そのためポートで必要なトンネリング機能を提供できません。
Outlook 2000 クライアントの場合は、Exchange サーバーに接続するときに使用するポートを変更できません。
Portal Server 6.3 以降のバージョンの場合、OWA、Sun Java Enterprise Server、Portal Server Secure Remote Access の配備に関する問題に使用できるプロキシレットテクノロジが導入されています。Portal Server 管理者は、ユーザーの使い心地をよくするために、このテクノロジを検討するようにしてください。
Netlet は、Graphon、Citrix、pcAnywhere などの多くのサードパーティー製品で動作します。それらの各製品は、リモートマシンからユーザーのポータルデスクトップへのアクセスを Netlet を使用してセキュリティー保護します。
スプリットトンネリングにより、VPN クライアントは、VPN に接続または VPN から切断することなく、セキュリティー保護されたサイトおよびセキュリティー保護されていないサイトの両方に接続できます。この場合の VPN は Netlet です。クライアントは、暗号化パスを通して情報を送信するか、または非暗号化パスを使用して送信するかどうかを判別します。スプリットトンネリングの問題点は、セキュリティー保護されていないインターネットから、クライアントを介して VPN によるセキュリティー保護ネットワークに直接接続が可能であることです。スプリットトンネリングをオフにすると両方の接続が同時に許可されることがなくなり、インターネット侵入に対する VPN 接続 (この場合は Netlet 接続) の脆弱性が低減します。
Portal Server は、ポータルサイトに接続されている間、複数のネットワーク接続を禁止したりシャットダウンしたりしませんが、権限のないユーザーが他のユーザーのセッションに便乗 (piggybacking) する行為を次の方法で阻止します。
Netlet は、アプリケーション特有の VPN であり、汎用 IP ルーターではありません。Netlet は、Netlet ルールによって定義されたパケットを転送するだけです。この仕組みは、一度ネットワークに接続すれば LAN 全体へのアクセス権が与えられる標準的な VPN とは異なります。
Netlet を実行できるのは、認証済みのポータルユーザーだけです。ポータルアプリケーションはユーザーが正常に認証されるまで実行されることはなく、認証されたセッションがなければ新規接続は確立されません。
アプリケーション側の所定のアクセス制御すべては有効に機能し続けるので、攻撃者はバックエンドアプリケーションにも侵入しなければならなくなります。
Netlet 接続が確立されると、認証されたユーザーの JVM TM で動作する Netlet によって、毎回ダイアログボックスによる通知が認証されたユーザーの画面に表示されます。ダイアログボックスでは、検証と確認を行なって新規接続を許可するかどうか尋ねられます。攻撃者が Netlet 接続を利用するためには、Netlet が実行していたこと、Netlet が待機していたポート番号、およびバックエンドアプリケーションへの侵入方法を知っており、ユーザーに安心して接続を認めさせることが必要になります。
Netlet プロキシは、ゲートウェイと宛先ホストを接続するために、ファイアウォールで開く必要のあるポート数を少なくするのに役立ちます。
たとえば、イントラネット内部で多数の Telnet、FTP、および Microsoft Exchange サーバーを接続するために、Netlet を必要とする設定について考えてみます。ゲートウェイは DMZ 内にあると仮定します。ゲートウェイがトラフィックをすべての宛先サーバー向けて経路指定する場合は、第 2 ファイアウォールでかなりの数のポートを開いておく必要があります。この問題を軽減するため、第 2 ファイアウォールの背後に Netlet プロキシを配置し、Netlet プロキシにトラフィックを転送するようにゲートウェイを設定できます。その後、Netlet プロキシがすべてのトラフィックをイントラネット内のすべての宛先サーバーに経路指定するので、第 2 ファイアウォールで開く必要のあるポート数を減らすことができます。また、第 2 ファイアウォールの背後に複数の Netlet プロキシを配置して、シングルポイント障害を回避することもできます。
サードパーティーのプロキシを使用して第 2 ファイアウォールのポートを 1 つだけ使用することも可能です。
Netlet プロキシを別のノードにインストールすると、Netlet トラフィックの負荷が別のノードに分散されるので、Portal Server の応答時間を短くすることができます。
NetFile により、企業のイントラネット内部にセキュリティー保護されて常駐するファイルシステムに、リモートアクセスして操作することができます。
NetFile は、NFS、jCIFS、および FTP などの標準プロトコルを使用して、ユーザーがアクセス権を持つすべての UNIX または Microsoft Windows ファイルシステムに接続します。NetFile を使用して、ファイル管理アプリケーションで一般的なほとんどのファイル操作を実行できます。
さまざまなファイルシステムにアクセスするため、NetFile には 3 つのコンポーネントが組み込まれています。
NetFile Java 1 アプレット 。AWT ベースのユーザーインタフェースを搭載しています。Java 2 をサポートできない旧バージョンのブラウザの場合に使用します。
NetFile Java 2 アプレット 。Swing ベースのユーザーインタフェースを搭載しています。Java プラグインをサポートするブラウザの場合に使用します。
NetFile サーブレット 。Web コンテナには、NetFile アプレットの種類ごとに 1 つずつ、合計 2 つの NetFile サーブレットが入っています。サーブレットは、異なるタイプのファイルシステムに接続し、NetFile に設定された操作を実行し、表示用の情報をアプレットに返信する機能を実行します。
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 はこれら 3 つの操作を同時に実行し、さらにユーザーがファイルのリストを参照することを許可します。
リライタは、HTML と JavaScript コードの両方ですべての URI を変換し、イントラネットのコンテンツを常にゲートウェイを通して取得できるようにする独立コンポーネントです。ルールの集合であるルールセットを定義し、ページにリライトする必要のあるすべての URL を特定します。ルールセットは、Document Type Definition (DTD) に従って記述される XML コードです。リライタに付属する一般ルールセットを使用すれば、ルールを追加せずにほとんどの URL をリライトできます。ルールセットをドメインに関連付け、ドメインベースの変換も実行できます。
外部ルールセットはコンテンツの URI を識別します。Secure Remote Access によるサービスを必要とする要求はすべて、次の経路で処理されます。
Secure Remote Access は、サービスを必要とするイントラネットページまたはインターネットページの URI を要求から特定します。
Secure Remote Access は、プロキシ設定を使用して特定された URI に接続します。
URI のドメインは、このコンテンツをリライトするために使用するルールセットを特定するために使用されます。
コンテンツとルールセットを取得すると、Secure Remote Access はそれらの情報をリライタに入力し、特定された URI はそこで変換されます。
元の URI はリライトされた URI によって置き換えられます。
このプロセスがドキュメントの最後まで繰り返されます。
生成されたリライタ出力は、ブラウザに経路指定されます。
ファイアウォールで開くポート数を最小限に抑えるには、リライタプロキシを使用します。リライタプロキシをインストールすると、HTTP 要求は、宛先ホストに直接送信される代わりに、リライタプロキシにリダイレクトされます。次にリライタプロキシは、受け取った要求を宛先サーバーに送信します。
リライタプロキシを使用すると、ゲートウェイとイントラネットコンピュータの間の HTTP トラフィックをセキュリティー保護し、次の 2 つの利点を生かすことができます。
ファイアウォールがゲートウェイとサーバーの間にある場合、ファイアウォールで開く必要のあるポートは 2 つだけです。1 つのファイアウォールをゲートウェイとリライタプロキシの間に、もう 1 つをゲートウェイと Portal Server の間に配置します。
サードパーティーのプロキシを使用して第 2 ファイアウォールのポートを 1 つだけ使用し、リライタプロキシを読み取ることができます。
宛先サーバーが HTTPS ではなく HTTP プロトコルのみをサポートしている場合でも、ゲートウェイとイントラネットの間の HTTP トラフィックはセキュリティー保護されます。
複数のリライタプロキシを稼働させれば、シングルポイント障害を防止し、ロードバランスを実現できます。
プロキシレットは、クライアントマシン上で稼働する動的なプロキシサーバーです。プロキシレットは URL をゲートウェイにリダイレクトします。プロキシレットは、この機能を実現するために、クライアントマシン上のブラウザのプロキシ設定を読み込んでから、その設定がローカルプロキシサーバー ( プロキシレット) をポイントするように変更します。
プロキシレットでは、HTTP および SSL がサポートされ、ゲートウェイのトランスポートモードが継承されます。ゲートウェイが SSL に基づいて動作するように設定されている場合には、クライアントマシンとゲートウェイ間のチャネルのセキュリティーが確保されます。クライアントの JVM が 1.4 以降の場合または必要な jar ファイルがクライアントマシン上にある場合には、Java 2 Enterprise Edition API が使用されます。それ以外の場合には、KSSL API が使用されます。
プロキシレットは、クライアントの IP アドレスとポートが指定されている Portal Server 管理コンソールから有効にします。
プロキシレットは、リライタと異なり、インストール後の変更をほとんどまたはまったく必要としません。また、プロキシレットは Web コンテンツを処理しないので、ゲートウェイのパフォーマンスが向上します。
必ずではありませんが、通常は、以下のさまざまなポータルノード (サーバー) Portal Server ソフトウェアを配備して、連携動作することによってポータルを実装します。
Portal Server ノード。Portal Server が常駐する Web サーバーです。必要であれば、このノードに検索コンポーネントをインストールすることもできます。Access Manager もここに常駐可能です。
Access Manager ノード 。Access Manager が常駐可能なサーバーです。Access Manager は、Portal Server と同じノードに常駐する必要はありません。
検索ノード 。オプションです。Portal Server の検索サービスで使用するサーバーです。Portal Server 検索サービスは、パフォーマンス、スケーラビリティー、および可用性を高めるために、独自のサーバーにインストールできます。
ゲートウェイノード 。オプションです。Secure Remote Access ゲートウェイが常駐するサーバーです。ゲートウェイはポータルノードにインストールできます。ゲートウェイは DMZ に配置するので、分離されたポータル以外のノードにインストールされます。
Netlet プロキシノード 。オプションです。ユーザーのイントラネットでアプリケーションを実行しているリモートデスクトップとサーバーの間で、アプリケーションをセキュリティー保護して実行するために使用されるサーバーです。
リライタプロキシノード 。オプションです。ユーザーのイントラネットでアプリケーションを実行しているリモートデスクトップとサーバーの間で、アプリケーションをセキュリティー保護して実行するために使用されるサーバーです。
Directory Server ノード 。Directory Server ソフトウェアを実行しているサーバーです。Directory Server はポータル以外のノードにインストールできます。
その他のサーバー 。メールサーバーやファイルサーバーのようなサーバーおよび旧バージョンのサーバーは、バックエンドサポート、データ、およびアプリケーションをポータルユーザーに提供します。
Portal Server と Access Manager は異なるノードに置くことができます。このタイプの配備には、次の利点があります。
アイデンティティーサービスをポータルサービスとは別に配備できます。Portal Server は、アイデンティティーサービスを使用する多くのアプリケーションのうちの 1 つにすることができます。
認証サービスとポリシーサービスを、Portal Server 関連のアプリケーションを含むプロバイダのアプリケーションから分けることができます。
他の Web コンテナが Access Manager を使用して、そのポータルのカスタマイズの開発を支援できます。
Portal Server と Access Manager を異なるノードに置く場合、Access Manager SDK は Portal Server と同じノードに存在する必要があります。Web アプリケーションとサポートする認証デーモンは、Portal Server インスタンスとは別のノードに置くことができます。
Access Manager SDK は、次のコンポーネントから構成されています。
アイデンティティー管理 SDK — ユーザー、ロール、グループ、コンテナ、組織、組織単位、およびサブ組織を作成および管理するための枠組みを提供します。
認証 API および SPI — 認証サービスのすべての機能へのリモートアクセスを可能にします。
ユーティリティー API — システムのリソースを管理します。
ロギング API および SPI — 数ある中でも、アクセスの承認、アクセスの拒否、およびユーザーの活動を記録します。
クライアント検出 API — リソースへアクセスしようとしているクライアントのブラウザのタイプを検出し、適切にフォーマットされたページで応答します。
SSO API — セッショントークンの検証と管理のインタフェース、またユーザー認証の資格を管理するインタフェースを提供します。
ポリシー API — Access Manager のポリシーを評価および管理し、ポリシーサービスの追加機能を提供します。
SAML API — 認証、承認決定、および属性の情報を交換します。
連携管理 API — Liberty Alliance Project 仕様に基づいた機能を追加します。
図 4–1 は、ソリューションの可用性に重要な Portal Server システムのプロセスおよび通信リンクを示しています。
この図では、Web Server 技術で稼働する Portal Server インスタンスがボックスで囲まれています。このインスタンスには、5 つのサーブレット (認証、Portal Server 管理コンソール、ポータルデスクトップ、通信チャネル、および検索) と 3 つの SDK (Access Manager SSO、Access Manager ロギング、および Access Manager 管理) が含まれています。認証サービスサーブレットは、LDAP サービスプロバイダモジュールも利用します。
ユーザートラフィックは、適切なサーブレットにダイレクトされます。通信は、認証サービスの LDAP モジュールと LDAP 認証サーバー間、通信チャネルサーブレットと SMTP/IMAP メッセージングサーバー間、Access Manager SSO SDK と LDAP サーバー間、Access Manager 管理 SDK と LDAP サーバー間で行われます。
図 4–1 は、次のプロセスまたは通信リンクに障害が発生すると、エンドユーザーがポータルソリューションを利用できなくなることを示しています。
Portal Server インスタンス。Web コンテナのコンテキストで実行されます。インスタンスに含まれるコンポーネントは、Java API を使用して JVM を介して通信します。インスタンスは、完全修飾ドメイン名と TCP ポート番号です。Portal Server サービスは、サーブレットまたは JSPTM ファイルとして実装される Web アプリケーションです。
Portal Server は、認証シングルサイオン (セッション) 管理、ポリシー、およびプロファイルデータベースアクセスのために Access Manager 上に構築されます。したがって、Portal Server は可用性と障害許容性に関して Access Manager のすべての利点 (および制約) を継承します。
設計により、Access Manager のサービスは、ステートレス、またはサービスがコンテキストデータを共有できるのどちらかになります。サービスは、サービスに障害が発生した場合に前の状態に戻ることができます。
Portal Server では、ポータルデスクトップはインスタンス間で状態データを共有しません。これは、インスタンスのリダイレクトによって、有効になったサービスに対してユーザーコンテキストが再作成されることを意味します。通常、リダイレクトされたユーザーはこれに気がつきません。これは、Portal Server サービスがユーザーコンテキストをユーザーのプロファイルから、また要求に格納されたコンテキストデータを使用することによって再作成できるためです。これは一般にインストール後即使用可能なサービスに当てはまりますが、チャネルやカスタムコードには当てはまらないことがあります。開発者は、インスタンスのフェイルオーバー時にコンテキストを失うのを避けるためにステートフルチャネルを設計しないように注意する必要があります。
プロファイルデータベースサーバー 。プロファイルデータベースサーバーは、Directory Server ソフトウェアによって実装されます。このサーバーは厳密には Portal Server の一部ではありませんが、このサーバーの可用性とデータベースの完全性はシステムの可用性に欠かせません。
認証サーバー 。これは LDAP 認証のためのディレクトリサーバーです (通常、プロファイルデータベースサーバーと同じサーバー)。このサーバーには、プロファイルデータベースサーバーと同じ高可用性技術を適用できます。
Secure Remote Access ゲートウェイとプロキシ 。Secure Remote Access ゲートウェイは、状態情報をエンドユーザーに透過に再作成できるため、ステートレスとみなすことのできるスタンドアロンの Java テクノロジプロセスです。ゲートウェイプロファイルは、Portal Server インスタンスのリストを維持し、ゲートウェイインスタンス間でラウンドロビン方式のロードバランスを行います。ゲートウェイの前ではセッション固定の必要はありませんが、セッションが固定されると、パフォーマンスが向上します。一方、Portal Server インスタンスに対するセッション固定は Secure Remote Access によって実施されます。
Secure Remote Access には、Netlet プロキシとリライタプロキシと呼ばれるほかの Java テクノロジプロセスも含まれます。これらのプロキシを使用して、ファイアウォールの背後からセキュリティーの適用範囲を拡張し、DMZ の穴の数を制限できます。これらのプロキシは、別々のノードにインストールできます。
このセクションでは、Portal Server の論理アーキテクチャー例をいくつか説明します。
図 4–2 は、ポータル配備のコンポーネントをいくつか図示していますが、実際の物理ネットワーク設計、シングルポイント障害、または高可用性については説明していません。
この図は、企業サイトにインストールされた標準的な企業対社員用ポータルの高レベルアーキテクチャーを示しています。この図では、プロキシ/キャッシュサーバー、Web サーバー、メールゲートウェイなどのインターネットからアクセス可能なほかのシステムと一緒に、ゲートウェイが企業の非武装ゾーン (DMZ) に配置されています。ポータルノード、ポータル検索ノード、およびディレクトリサーバーは、個々の社員のデスクトップシステムから旧バージョンのシステムにいたるまで、ユーザーがアクセス可能なシステムやサービスが存在する内部ネットワークに配置されています。
独自のポータルを希望するビジネスの顧客ごとに別々の Portal Server インスタンスをホストする ISP ホスティングの配備を設計している場合は、Sun Java System の担当者にご連絡ください。Portal Server は、ISP ホスティング機能を提供するためにカスタマイズする必要があります。
図 4–2 では、インターネットのユーザーがブラウザからゲートウェイにアクセスします。ゲートウェイは、ユーザーがアクセスしようとしているポータルの IP アドレスとポートにユーザーを接続します。たとえば、B2B ポータルは通常、HTTPS ポートである 443 番ポートにのみアクセスを許可します。ゲートウェイは、認証された使用法に応じて、要求をポータルノードに転送するか、企業の内部ネットワークのサービスに直接転送します。
図 4–3 は、Secure Remote Access サービスを使用した Portal Server の配備を示しています。
Portal Server の配備は多くの他のシステムも関係する複雑な処理であるため、ここでは最高のパフォーマンスと水平方向のスケーラビリティーを提供する特定の構成について説明します。この構成は、Portal Server 構築モジュールと呼ばれます。
Portal Server 構築モジュールは、共有サービスに限定的に依存、またはまったく依存しないハードウェアおよびソフトウェアの構成です。一般的な配備では、複数の構築モジュールを使用して、最高のパフォーマンスと水平方向のスケーラビリティーを実現します。図 4–4 は、構築モジュールのアーキテクチャーを示しています。
Portal Server 構築モジュールは、単なる推奨構成です。場合によっては、別の構成のほうがスループットが若干よくなることがあります。この場合、一般的に構成はより複雑になります。たとえば、4 CPU システムに Portal Server の別のインスタンスを追加すると、スループットが最高 10 % 向上する可能性がありますが、単一システムのみを使用する場合でもロードバランサを追加する必要があるという代償を払う必要があります。
Portal Server は、高可用性に関して次の 3 つのシナリオを提供します。
ハードウェアに障害が発生しないかぎり、また watchdog プロセスによって Portal Server プロセスを再起動できるかぎり、システムを利用できます。
ハードウェアとソフトウェアのレプリケーションにより、ノーシングルポイント障害 (No Single Point of Failure、NSPOF) の配備を構築します。コンポーネントの連鎖のどこかで連続的に複数の障害が発生しないかぎり、システムは常に利用可能です。ただし、障害が発生した場合は、ユーザーセッションは失われます。
システムは常に利用可能ですが、NSPOF に加えて、バックアップインスタンスへのフェイルオーバーがエンドユーザーに透過に行われます。ほとんどの場合、ユーザーは別のノードまたはインスタンスにリダイレクトされたことに気がつきません。セッションは、ノード間にわたって維持されるので、ユーザーは再認証する必要がありません。Portal Server サービスは、ステートレス、またはチェックポイントメカニズムを使用して現在の実行コンテキストを特定の時点まで再構築します。Portal Server の高可用性とセッションのフェイルオーバーに関する設定情報の詳細については、『Sun Java System Portal Server 7.1 Configuration Guide 』を参照してください。
サポート可能なアーキテクチャーを次に示します。
ここでは、高可用性の観点から、これらのアーキテクチャーの実装方法について、また構築モジュール概念を活用する方法について説明します。
表 4–1 は、これらの高可用性シナリオと、シナリオをサポートする技術の要約です。
表 4–1 Portal Server 高可用性シナリオ
コンポーネントの要件 |
ベストエフォート配備に必要ですか ? |
NSPOF 配備に必要ですか ? |
透過フェイルオーバー配備に必要ですか ? |
---|---|---|---|
はい |
はい |
はい |
|
Portal Server の構築モジュール |
いいえ |
はい |
はい |
いいえ |
はい |
はい |
|
ロードバランス |
はい |
はい |
はい |
いいえ |
いいえ |
はい |
|
いいえ |
いいえ | ||
いいえ |
いいえ |
はい |
ロードバランスは、Sun JavaTM System Web Server 製品では出荷時の状態では提供されていません。
このシナリオでは、可用性が続くように、Sun Fire UltraSPARCTM III マシンなどの、ハードウェアが保護された単一ノードに Portal Server と Directory Server をインストールします。SolarisTM オペレーティング環境システムを保護するには、デフォルトの設定を変更する必要があります。
このタイプのサーバーではハードウェアが完全に冗長であり、次のものを備えています。冗長電源、冗長ファン、冗長システムコントローラ、動的再構成、CPU ホットプラグ、オンラインアップグレード、および RAID 0+1 (ストラインピングにミラーリングもプラス) またはボリューム管理システムを使用する RAID 5 で構成できるディスクラック (ディスククラッシュ発生時にデータが失われるのを防止する)。図 4–5 は、構築モジュールのアーキテクチャーを使用する、小規模のベストエフォート配備を示しています。
このシナリオでは、1 つの構築モジュールには、メモリーの割り当ては 4 CPU × 8G バイト RAM (4 × 8) で十分です。Portal Server コンソールは、ほかのリソースと共有できるように構築モジュールの外にあります。実際のサイズの計算結果は、これとは異なる割り当て量になる場合があります。
このシナリオは、タスククリティカルな要件には十分です。このシナリオの主な弱点は、システムのシャットダウンが必要な保守作業によってサービスが中断されるということです。
Secure Remote Access を使用している場合に、ソフトウェアのクラッシュが発生すると、watchdog プロセスがゲートウェイ、Netlet プロキシ、およびリライタプロキシを自動的に再起動します。
Portal Server は、ノーシングルポイント障害 (NSPOF) シナリオを基本機能としてサポートしています。NSPOF は、ベストエフォートシナリオをベースにし、それに加えてレプリケーションとロードバランスを採り入れています。
図 4–6 は、Portal Server インスタンス、プロファイルの読み込みのための Directory Server レプリカ、および検索エンジンのデータベースから構成されている構築モジュールを示しています。そのため、NSPOF を実現するには少なくとも 2 つの構築モジュールが必要であり、それによって構築モジュールのどちらかに障害が発生した場合のバックアップを提供します。これらの構築モジュールは、4 CPU × 8G バイト RAM で構成されます。
ロードバランサが Portal Server の障害を検出すると、ユーザーの要求をバックアップ構築モジュールにリダイレクトします。障害検出の正確さは、ロードバランス製品によって異なります。一部の製品は、サーバーのいくつかの機能領域に関係するサービス、たとえばサーブレットエンジンや JVM を検索することによってシステムの可用性を確認できます。特に、Resonate、Cisco、Alteon、およびその他のほとんどのベンダーソリューションを使用する場合は、ユーザーがサーバーの可用性のためのスクリプトを任意に作成できます。ロードバランサは Portal Server ソフトウェアの一部ではないので、サードパーティーベンダーから個別に入手する必要があります。
Access Manager は、セッション固定を実施するためにロードバランス を設定することを要求します。これは、特定のインスタンスに対するセッションを確立すると、ロードバランサはそのセッションのために常に同じインスタンスに戻る必要があります。ロードバランサは、セッション cookie にインスタンスの識別名をバインドすることによってこれを実現します。原則としては、障害が発生したインスタンスを終了したときに、そのバインドは再設定されます。セッション固定は、パフォーマンス上の理由からも推奨します。
マルチマスターレプリケーション (Multi-master replication、MMR) は、構築モジュール間で行われます。各ディレクトリで発生する変更は他のディレクトリにレプリケートされます。つまり、各ディレクトリがサプライヤとコンシューマの両方の役割を果たします。MMR の詳細については、『Sun Java System Directory Server 配備計画ガイド』を参照してください。
一般に、各構築モジュール内の Directory Server インスタンスは、ほかの場所で実行されるマスターディレクトリのレプリカとして構成されます。ただし、マスターディレクトリを構築モジュールの一部として使用するのを妨げるものはありません。専用ノードでマスターを使用しても、ソリューションの可用性は向上しません。専用マスターは、パフォーマンスのために使用します。
構築モジュール間でのコンシューマレプリケーションを伴う、管理コンソールまたはポータルデスクトップを使用したプロファイルの変更を常に維持できるように、冗長性もディレクトリマスターにとって同じように重要です。Portal Server と Access Manager は、MMR をサポートします。NSPOF シナリオは、マルチマスター構成を使用します。この構成では、2 つのサプライヤが更新を受け入れること、互いに同期をとること、またすべてのコンシューマを更新することが可能です。コンシューマは、更新要求を両方のマスターに任せることができます。
Secure Remote Access は、NSPOF を実現するために Portal Server と同様にレプリケーションとロードバランスを採用します。そのため、このシナリオでは 2 つの Secure Remote Access ゲートウェイとプロキシのペアが必要になります。Secure Remote Access ゲートウェイは、特定のタイムアウト値後、要求に対して Portal Server インスタンスが応答しない場合に、Portal Server インスタンスの障害を検出します。これが発生すると、HTTPS 要求はバックアップサーバーにルーティングされます。Secure Remote Access ゲートウェイは、最初の Portal Server インスタンスが再び稼働するまで定期的に可用性を確認します。
NSPOF の高可用性シナリオは、ビジネスクリティカルな配備に適しています。しかし、このシナリオの高可用性の制限の一部は、ミッションクリティカルな配備の要件を満たさない場合があります。
透過フェイルオーバーは、NSPOF シナリオと同じレプリケーションモデルを使用しますが、追加の高可用性機能があり、これによってエンドユーザーに透過なバックアップサーバーにフェイルオーバーが行われます。
図 4–7 は、透過フェイルオーバーのシナリオを示しています。4 CPU × 8G バイト RAM から構成される 2 つの構築モジュールを示しています。ロードバランスは、Portal Server の障害を検出し、構築モジュール内のバックアップ Portal Server に要求をリダイレクトする責任があります。構築モジュール 1 は、セッションをセッションリポジトリに格納します。クラッシュが発生した場合、アプリケーションサーバーは構築モジュール 1 が作成したセッションをセッションリポジトリから取得します。
セッションリポジトリは、アプリケーションサーバーソフトウェアで提供されます。Portal Server は、アプリケーションサーバーで稼働します。Portal Server は、HttpSession フェイルオーバーをサポートするアプリケーションサーバーで透過フェイルオーバーをサポートします。詳細は、付録 A 「Portal Server とアプリケーションサーバーの理解」を参照してください。
セッションフェイルオーバーを使用すると、クラッシュ発生後にユーザーを再認証する必要はありません。また、ポータルアプリケーションは、セッションが固定されるという前提で、チェックポイントで使用するコンテキストデータを保存できます。AMConfig.properties ファイルで com.iplanet.am.session.failover.enabled property を true に設定することによって、セッションのフェイルオーバーを設定できます。
Netlet プロキシは、TCP プロトコルの制限により透過フェイルオーバーシナリオをサポートできません。Netlet プロキシは、TCP 接続をトンネルし、オープンな TCP 接続を別のサーバーに移すことはできません。Netlet プロキシのクラッシュによって、再確立する必要があるすべての未処理の接続がなくなります。
ここでは、構築モジュールソリューションを配備するためのガイドラインを説明します。
構築モジュールの構築方法によってはパフォーマンスに影響します。
構築モジュールを適切に配備するためには、次に示す推奨事項を考慮してください。
1 台のマシンに 1 つの構築モジュールを配備します。
複数のマシンを使用する場合、または Portal Server マシンが多数のインスタンスを稼働させている場合は、高速ネットワークインターコネクトを使用します。
8 個を超える CPU が搭載されているサーバーでは、2 個または 4 個の CPU からなるプロセッサセットまたはドメインを作成します。たとえば、Portal Server の 2 つのインスタンスを 8 個の CPU が搭載されたサーバーにインストールする場合は、4 個の CPU からなる 2 つのプロセッサセットを作成します。
構築モジュールを配備するための Directory Server の要件を確認します。Directory Server の配備の特定の情報は、『Directory Server 配備計画ガイド』を参照してください。
Portal Server の配備を計画する際には、次に示す Directory Server のガイドラインを考慮してください。
Directory Server コンシューマレプリカプロセッサセットに必要な CPU の量は、構築モジュールに含まれる Portal Server インスタンスの数、またパフォーマンスおよび容量の考慮事項によって決定されます。
可能であれば、1 つの Directory Server インスタンスを1 つの構築モジュール内の Portal Server インスタンス専用にします。
ディレクトリデータベースインデックス全体とメモリー内のキャッシュをマップして、ディスクの遅延に関する問題を防止します。
複数の構築モジュールを配備するときは、Directory Server サプライヤに対するプ ロファイルの更新とレプリケーションのオーバーヘッドによる障害を回避するためにマルチマスター構成を使用します。
構築モジュールのスケーラビリティーは、プロファイルの更新によって生じる LDAP の書き込みの数と LDAP データベースの最大サイズによります。
/tmp ディレクトリに _db ファイルがある場合に LDAP サーバーがクラッシュすると、サーバーが再起動するときにこのファイルは失われます。これはパフォーマンスを向上させますが、可用性にも影響します。
特定のサイトの分析結果が、LDAP の書き込み操作が実際に制約となっていることを示す場合は、この問題の解決策として、受信要求をポータルの適切なインスタンスに転送するディレクトリの特定の分岐とその前にある層のみをレプリケートする構築モジュールを作成することができます。
検索エンジンを構築モジュールソリューションの一環として配備するときには、次の点を考慮してください。
各構築モジュールでは、1 つの Portal Server インスタンスだけの検索エンジンデータベースにリソース記述 (RD) が含まれているようにします。残りの Portal Server インスタンスの検索エンジンデータベースは、デフォルトの空の状態であるようにします。
ポータルの検索データベースに構築モジュールを使用するかどうかに影響する要素には、同時並行検索の数に加えて、Portal Server 配備の検索活動の程度、検索のヒットの範囲、すべてのユーザーの検索ヒットの平均数があります。たとえば、検索エンジンによるサーバーへの負荷は、大きなインデックスや高負荷のクエリーの場合はメモリーと CPU の両方をかなり使用することがあります。
検索機能を Portal Server とは別のマシンにインストールして、主なサーバーをポータルの活動専用にすることができます。そのようにする場合、検索プロバイダの searchURL プロパティーを使用して、検索機能がインストールされた 2 番目のマシンを指すようにします。検索インスタンスは、通常のポータルインスタンスです。ポータルインスタンスをインストールするのと同様に検索インスタンスをインストールしますが、検索インスタンスは検索機能のみに使用します。
図 4–8 は、別々のノードに存在する Access Manager と Portal Server を示しています。
Portal Server と Access Manager を分けて実装すると、次の 3 つの図が示すようなポータルサービスアーキテクチャーの配備に対する他のトポロジの並びが可能になります。
図 4–9 は、1 つの Access Manager および 2 つの Directory Server と機能するように構成された 2 つの Portal Server インスタンスを示しています。ここでは、Access Manager と Directory Server の両方が Java Enterprise System Sun Cluster 環境で動作します。この構成は、Access Manager インスタンスと Directory Server インスタンスが障害でない場合に理想的です。
図 4–10 は、水平方向のサーバーファームによって実現された最大の水平方向のスケーラビリティーと、より高い可用性の構成を示しています。最大のスループットと高可用性の実現のために、2 つの Portal Server の前にロードバランサを置くことができます。
別のロードバランサを、Portal Server と Access Manager の間に置いて、認証プロセスとポリシープロセスが高可用性のための負荷の分散とフェイルオーバーの手段となるようにできます。
このシナリオでは、Portal サービスに Blade 1500s を利用して負荷を分散し、これと似た Blade を使用して Access Manager サービスと Directory サービスのそれぞれをホストできます。図 4–10 に示されたアーキテクチャーでは、製品スタックのそれぞれに冗長のサービスが存在するので、計画外の停止時間を最小限に、またはなくすことがで きます。
ただし、予定された停止時間は依然問題になります。アップグレードまたはパッチに Access Manager ソフトウェアが使用する Directory Server ソフトウェアスキーマの変更が含まれる場合、Directory Server に格納されたスキーマ情報を更新するためにこのソフトウェアのすべてのコンポーネントを停止する必要があります。ただし、スキーマ情報の更新は、ほとんどのパッチアップグレードではめったに発生しないとみなすことができます。
図 4–11 は、Portal Server からの認証スループットを 2 つの Access Manager にロードバランスすることを可能にする構成を示しています。
この構成は、Portal Server が広い帯域幅のネットワーク接続を備えたハイエンドの中規模から大規模のサーバー (つまり 1 〜 4 個のプロセッサ) に存在するときに実現できます。ポリシーサービスと認証サービスを提供する Access Manager は、2 つの中規模のサーバーに置くことができます。
Secure Remote Access ゲートウェイは、インターネットから送信されるリモートユーザーセッションと企業イントラネットの間のインタフェースおよびセキュリティーバリアとして機能します。ゲートウェイには、次の 2 つの主な機能があります。
受信ユーザーセッションに対する、身元の確認やプラットフォームへのアクセス の許可または拒否などの基本認証サービスを提供します。
ユーザー向けにイントラネットのコンテンツへの Web ベースのリンクを有効にするためのマッピングサービスと書き換えサービスを提供します。
インターネットアクセスの場合、128 ビット SSL を使用して、ユーザーのブラウザとPortal Server 間の最高のセキュリティー対策と暗号化、または通信を実現します。ゲートウェイ、Netlet、NetFile、Netlet プロキシ、リライタプロキシ、およびプロキシレットが Secure Remote Access の主なコンポーネントです。
ここでは、それらのコンポーネントの可能な構成をいくつか示します。このセクションでは、指針を示すだけで、完全な配備の参考情報を提供するわけではありません。業務のニーズに基づいて構成を選択してください。
authlessanonymous ページをゲートウェイ経由で表示するように設定するには、ゲートウェイプロファイルの非認証 URL に /portal/dt を追加します。ただし、これは、普通のユーザーの場合でも、ポータルページは認証を必要とせず、セッションの検証が実行されないことを意味します。
図 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–13 は、Netlet が無効ということ以外は基本 Secure Remote Access 構成と同様のシナリオを示しています。クライアントの配備がイントラネットと通信する必要があるアプリケーションを安全に実行するために Netlet を使用しない場合は、パフォーマンス向上のためにこの構成を使用します。
この構成を拡張して、他の配備シナリオと組み合わせて、パフォーマンスを向上し、拡張可能なソリューションを提供できます。
図 4–14 で示すプロキシレットは、イントラネットのリソースをクライアントに公開しなくても、ユーザーがインターネットを使用してイントラネットのリソースに安全にアクセスできるようにします。
プロキシレットでは、ゲートウェイのトランスポートモード (HTTP または HTTPS のどちらか) が継承されます。
図 4–15 は、Secure Remote Access の基本構成の拡張を示しています。複数のゲートウェイインスタンスが、同じマシンまたは複数のマシンで稼働します。別々のプロファイルで複数のゲートウェイインスタンスを起動できます。
図 4–15 はゲートウェイと Portal Server の 1 対 1 の対応を示していますが、実際の配備では必ずしもこのようになる必要はありません。複数のゲートウェイインスタンスや複数の Portal Server インスタンスを配備可能であり、また構成によってはどのゲートウェイも任意の Portal Server にアクセスできます。
この構成の欠点は、各接続要求のために 2 番目のファイアウォールで複数のポートを開く必要があるということです。これは、セキュリティーの問題になる可能性があります。
図 4–16 は、Netlet プロキシとリライタプロキシがある構成を示しています。これらのプロキシの場合、2 番目のファイアウォールではポートが 2 つだけ開いている必要があります。
この構成では、ゲートウェイはアプリケーションホストと直接やり取りする必要はありませんが、すべての Netlet トラフィックを Netlet プロキシへ、リライタトラフィックをリライタプロキシへ転送します。Netlet プロキシはイントラネット内にあるので、2 番目のファイアウォールで複数のポートを開かなくても、すべての必要なアプリケーションホストと直接やり取りできます。
DMZ 内のゲートウェイと Netlet プロキシとの間のトラフィックは暗号化され、Netlet プロキシでのみ復号化されるので、セキュリティーが向上します。
リライタプロキシが有効な場合、要求が Portal Server ノード宛てのものかどうかにかかわらず、すべてのトラフィックがリライタプロキシに転送されます。これによって、DMZ 内のゲートウェイからイントラネットへのトラフィックは常に暗号化されることが保証されます。
Netlet プロキシ、リライタプロキシ、および Portal Server がすべて同じノードで稼働するので、そのような配備シナリオではパフォーマンスの問題が発生する場合があります。この問題は、Portal Server ノードの負荷を軽減するためにプロキシを別々のノードにインストールすると解決できます。
Portal Server ノードの負荷を軽減し、なおかつパフォーマンスを向上させて同じレベルのセキュリティーを提供するには、Netlet プロキシとリライタプロキシを別々のノードにインストールできます。この配備は、プロキシを使用して Portal Server を DMZ から保護できるというさらなる利点があります。これらのプロキシを実行するノードは、DMZ から直接アクセス可能である必要があります。
図 4–17 は、別々のノードにある Netlet プロキシとリライタプロキシを示しています。ゲートウェイからのトラフィックは別のノードに転送され、そのノードはトラフィックをプロキシ経由で、必要なイントラネットのホストに転送します。
Netlet プロキシとリライタプロキシの複数のインスタンスを持つことや複数の Netlet プロキシとリライタプロキシをインストールすることが可能です。各ゲートウェイを、可用性に応じてラウンドロビン方式でプロキシのさまざまなインスタンスとのやり取りを試みるように設定できます。
ロードバランサは、Portal Server および Access Manager の冗長サービスの高可用性のためのフェイルオーバーのメカニズムを提供します。
外部の SSL デバイスをオープンモードでゲートウェイの前で実行するように設定できます。これは、クライアントと Secure Remote Access の間に SSL リンクを提供します。アクセラレータの詳細は、Sun Java System Portal Server 7.1 Secure Remote Access 管理ガイドを参照してください。
図 4–20 は、サードパーティーのプロキシを使用して、2 番目のファイアウォールのポートの数を 1 つに制限する例を示しています。サードパーティーのプロキシを使用して、リライタプロキシまたは Netlet プロキシに到達するようにゲートウェイを設定できます。
プロキシサーバーがインターネットのコンテンツをイントラネットに配信するのに対して、逆プロキシサーバーはイントラネットのコンテンツをインターネットに配信します。逆プロキシの特定の配備の際に、インターネットコンテンツのロードバランスおよびキャッシングが行われるように設定できます。
図 4–21 は、インターネットとイントラネットの両方のコンテンツを承認されたユーザーに配信するために、ゲートウェイの前に逆プロキシを配置する方法を示しています。ゲートウェイが Web コンテンツを配信するときには、このコンテンツに基づいた後続するブラウザの要求すべてがゲートウェイを通じてルーティングされるようにする必要があります。これは、このコンテンツ内のすべての URL を確認し、必要に応じて書き換えることによって実現します。
完成した論理アーキテクチャー設計それ自体は、ソリューションライフサイクルの配備設計段階に移るには不十分です。技術要件段階で、論理アーキテクチャーとサービス品質 (QoS) 要件とを組み合わせる必要があります。論理アーキテクチャーと QoS 要件を組み合わせることで、配備シナリオとなります。
第 5 章「配備設計の計画」の説明のとおり、配備アーキテクチャーの設計は配備シナリオから始めます。