サービス品質要件

サービス品質を実現するには、次のトピックに対処します。

• 「パフォーマンス」

• 「可用性」

• 「スケーラビリティー」

• 「セキュリティー」

パフォーマンス

ポータルシステム管理者およびポータル開発者と話し合い、計画される要件に基づいてポータルのパフォーマンス目標を設定します。目標には、ユーザー数、負荷ピーク時の並行処理ユーザー数、および Portal Server にアクセスする際のユーザーの使用パターンなどがあります。

次の 2 つの要素を決定する必要があります。

• ポータルアプリケーションの迅速な応答を目指してチューニングするのか。

• 多数のユーザーの並行処理に対応できるようにチューニングするのか。

並行してポータルに接続するユーザー数が増加すると、ハードウェアとパラメータセットが同じであれば、応答時間が減少します。そのため、Portal Server の予想使用レベル、任意の時刻に予想される並行処理ユーザー数、ポータルデスクトップのアクティビティー要求数、ポータルチャネル使用量、組織によって決定されるエンドユーザーへの許容応答時間、および基準を満たす最適ハードウェア構成に関する情報を収集してください。

可用性

Portal Server の可用性を高めるには、次の各コンポーネントの可用性を高める必要があります。

• Portal Server。オープンモードでは、ロードバランサを使用して障害が発生したコンポーネントを検出し、要求を他のサーバーにリダイレクトします。セキュアモードでは、ゲートウェイコンポーネントが障害の発生したサーバーコンポーネントの存在を検出し、要求を他のサーバーにリダイレクトします。Web コンテナが Sun Java System Web Server であるかぎりこのようになります。

• ゲートウェイ。ゲートウェイで使用するロードバランサは、障害が発生したゲートウェイコンポーネントを検出し、新しい要求をほかのゲートウェイにルーティングします。ロードバランサは、ワークロードをサーバープールにインテリジェントに分散する能力もあります。障害が発生したゲートウェイが回復すると、ルーティングが元に戻ります。ゲートウェイコンポーネントはステートレスなので ( セッション情報はクライアントで HTTP cookie に格納される)、障害が発生したゲートウェイを迂回した再ルーティングはユーザーには透過です。

• Directory Server。多数のオプションが、LDAP ディレクトリの可用性を高めます。

• Netlet プロキシとリライタプロキシ ソフトウェアのクラッシュが発生した場合、watchdog プロセスがプロキシを自動的に再起動します。さらに、ゲートウェイがプロキシのロードバランスと障害検出フェイルオーバーを実行します。

スケーラビリティー

スケーラビリティーとは、パフォーマンスを低下させることなく、処理リソースを追加することによって、増加するユーザー人口に対応するシステムの能力のことです。システムをスケーリングするための 2 つの一般的な方法には、垂直方向のスケーリングと水平方向のスケーリングがあります。このセクションの主題は、Portal Server のスケーリング技術の応用です。

スケーラブルなシステムの利点を次に示します。

• 応答時間の向上

• 障害許容性

• 管理容易性

• 消耗性

• 簡易化されたアプリケーションの開発

• 構築モジュール

垂直方向のスケーリング

垂直方向のスケーリングでは、CPU、メモリー、Portal Server の複数のインスタンスなどのリソースが 1 つのマシンに追加されます。これより、より多くのプロセスインスタンスが同時に実行できます。Portal Server では、必要な CPU の数に計画およびサイズ指定することによってこれを利用できます。

水平方向のスケーリング

水平方向のスケーリングでは、マシンが追加されます。これは、複数の同時処理とワークロードの分散も可能にします。Portal Server では、Portal Server、Directory Server、および Access Mangaer を異なるノードで実行できるので、水平方向のスケーリングを利用します。水平方向のスケーリングは、さらに CPU を追加するなどして、垂直方向のスケーリングも利用できます。

また、サーバーコンポーネントインスタンスを複数のマシンにインストールすることによって、Portal Server インストールを水平方向にスケールできます。インストールされた各サーバーコンポーネントインスタンスは、HTTP プロセスを実行し、この HTTP プロセスはインストール時に決定された番号の TCP/IP ポートで待機します。ゲートウェイのコンポーネントは、ラウンドロビンアルゴリズムを使用して新しいセッション要求をサーバーインスタンスに割り当てます。セッションが確立されている間は、クライアントに格納された HTTP cookie がセッションサーバーを示します。それ以降の要求はすべてそのサーバーに送られます。

「地域化の設計」のセクションでは、最適のパフォーマンスと水平方向のスケーラビリティーを提供する特定のタイプの構成への取り組み方について説明します。

セキュリティー

セキュリティーとは、サーバーおよびそのユーザーを悪意のある外部の者から保護するハードウェア、ソフトウェア、運用方法、および技術の集合のことです。それに関連して、セキュリティーは予期しない行為から保護します。

セキュリティーには、グローバルに対処し、ユーザーやプロセスだけでなく製品や技術も含める必要があります。あいにく、多くの組織が、唯一のセキュリティー方針としてファイアウォール技術のみに依存しています。それらの組織は、多くの攻撃は外部の者ではなく、従業員によるものであることに気づいていません。したがって、安全なポータル環境を構築するときには他のツールやプロセスを考慮する必要があります。

安全な環境で Portal Server を稼働させるには、Solaris^TM オペレーティング環境、ゲートウェイとサーバーの設定、ファイアウォールのインストール、および Directory Server による認証と Access Manager による SSO に対して特定の変更を行う必要があります。また、証明書、SSL 暗号化、グループおよびドメインアクセスを使用できます。

アクセス制御

Portal Server では、UNIX システムのセキュリティー機能に加え、HTTPS 暗号化プロトコルに依存して、Portal Server システムソフトウェアを保護しています。

セキュリティーは Web コンテナによって実現され、必要に応じて SSL を使用するように設定できます。Portal Server は、認証とエンドユーザー登録の場合の SSL もサポートしています。Web サーバーで SSL 証明書を有効にすることにより、ポータルデスクトップや他のアプリケーションにもセキュリティー保護してアクセスできます。Access Manager ポリシーを使用して、URL ベースのアクセスポリシーも設定できます。

Portal Server は、Access Manager によって提供される認証サービスを利用して、Access Manager SSO メカニズムを使用するすべての製品間でのシングルサインオン (SSO) をサポートします。SSO メカニズムでは、エンコードされたクッキーを使用してセッション状態を保持します。

Secure Remote Access には、さらに別のセキュリティー機能があります。Secure Remote Access では、デフォルトで HTTPS を使用して、クライアントのブラウザをイントラネットに接続します。ゲートウェイでは、リライタまたはプロキシレットを使用して、インターネットに直接コンテンツを公開せずにイントラネットの Web サイトにアクセスする仕組みを実現しています。またゲートウェイにより、アクセスされる Web サーバーに変更を加えずに、URL ベースのアクセスポリシーも設定できます。

ゲートウェイからサーバーおよびイントラネットリソースへの通信には、HTTP または HTTPS を使用できます。Web アプリケーションとディレクトリサーバーとの間の通信のように、Portal Server 内での通信では、デフォルトで暗号化を使用しませんが、SSL を使用するように設定できます。

UNIX ユーザーのインストール

次に示す 3 種類の UNIX ユーザー下に Portal Server をインストールおよび構成できます。

• root。これはデフォルトのオプションです。すべての Portal Server コンポーネントは、システムスーパーユーザーとして実行されるようにインストールおよび設定されます。この設定では、次のようなセキュリティーの問題が生じます。

  • アプリケーションのバグを利用して、システムに root アクセスが可能です。

  • 一部のテンプレートを変更するのに、root アクセスが必要になります。root アクセスは、システム管理者でないユーザーにこの権限が通常付与されることになるので、セキュリティーの問題になる可能性があります。

• ユーザー nobody。Portal Server をユーザー nobody (uid 60001) としてインストールできます。ユーザー nobody には何の権限もないため、システムファイルを作成、読み取り、あるいは変更することはできないので、システムのセキュリティーを向上できます。この機能は、ユーザー nobody が Portal Server を使用してシステムファイルにアクセスし、システムに侵入するのを防止します。

  ユーザー nobody にはパスワードがないので、正規のユーザーが nobody になるのを防止します。スーパーユーザーのみが、パスワードの入力を求められずにユーザーを変更できます。したがって、Portal Server サービスを起動および停止するには引き続き root アクセスが必要です。

• 非 root ユーザー。正規の UNIX ユーザーとして Portal Server を実行できます。正規ユーザーのセキュリティーの利点は、ユーザー nobody のセキュリティーの利点と似ています。正規の UNIX ユーザーには、サービスを起動、停止、および設定できるといった他の利点もあります。インストール後、一部のファイルの所有権を変更する必要があります。

  詳細は、『Sun Java Enterprise System 5 インストールガイド』を参照してください。

アクセス制御の制限

従来の UNIX のセキュリティーモデルは通常、絶対的ですが、代替ツールを使用していくらか柔軟にできます。それらのツールは、異なる UNIX コマンドなどの個々のリソースに対するきめ細かなアクセス制御を可能にするために必要な手段になります。たとえば、このツールセットは、Portal Server を root として稼働させるのを可能にし、また特定のユーザーおよびロールに Portal Server フレームワークの起動、停止、および維持のためのスーパーユーザー権限を与えます。

それらのツールを次に示します。

• Role-Based Access Control (RBAC)。 Solaris^TM 8 以降には、スーパーユーザー権限をパッケージ化し、それらをユーザーカウントに割り当てるための Role-Based Access Control (RBAC) が含まれています。RBAC は、権限の分離、ユーザーに対する権限付き操作の付与の制御、およびアクセス制御のさまざまなレベルを実現可能にします。

• Sudo。Sudo は公開されているソフトウェアであり、システム管理者が特定のユーザーに別のユーザーとしてコマンドを実行する権限を付与することを可能にします。次の URL を参照してください。

  http://www.courtesan.com/sudo/sudo.html

セキュアアクセスゾーンの使用

最高のセキュリティーを実現するには、2 つのファイアウォール間にゲートウェイをインストールします。もっとも外側のファイアウォールはインターネットからゲートウェイへの SSL トラフィックのみを通し、次にゲートウェイがトラフィックを内部ネットワークのサーバーへ転送します。