test

Sun Java System Access Manager 7 2005Q4 配備計画ガイド

第 3 章 技術要件

ソリューションのライフサイクルにおける技術要件段階では、使用状況を分析し、ユースケースを特定して、提案された配備ソリューションの QoS 要件を決定します。この章では、Sun JavaTM System Access Manager 7 2005Q4 での、この処理に関する要件の大まかな技術概要を示します。次の節で構成されています。

配備オプション

Access Manager の配備を計画する際に、組織が考慮する必要のある重要な要素がいくつかあります。これらは、通常、リスク評価および成長戦略と関連があります。次に例を示します。

さらに、アーキテクチャーは、以降の節で説明する目標を達成するための基礎を提供する必要があります。

セキュリティー

セキュリティーの確保された内部および外部ネットワーク環境を計画している場合には、以下の選択肢について考慮してください。

高可用性

IT の配備では、ユーザーに対して可用性を継続するとともに、SPOF (Single Point Of Failure) を発生させないことが重要です。可用性を高めるための手法は、クラスタリングやマルチマスターレプリケーションなど、製品ごとに異なります。望ましい高可用性とは、システムやコンポーネントが一定の期間、連続的に使用可能であるということです。システムは一般に複数のホストサーバーで構成されますが、ユーザーには 1 つの高可用性システムのように見えます。すべてのアプリケーションが 1 台のサーバーで動作する、最小構成の配備の場合、SPOF に含まれる要素として次のものが考えられます。

高可用性を実現する場合は、バックアップやフェイルオーバー処理、およびデータストレージやデータアクセスを中心に計画します。ストレージに関する 1 つの手法は、RAID (redundant array of independent disks) です。より高い可用性が求められるシステムでは、システムの各部分が適切に設計され、本稼働に先立ち、十分にテストされていることが必要です。たとえば、テストが十分ではない新規のアプリケーションプログラムほど、本番での稼働中に、システム全体に影響するエラーを引き起こす可能性が高くなります。

クラスタリング

クラスタリングとは、単一の高可用性システムを構築するために複数のコンピュータを使用することを指します。Sun Java System Directory Server のデータストアでは、クラスタリングが非常に重要な手法となる場合が多くあります。たとえば、クラスタ化された 1 組の MMR サーバーでは、可用性が確保されることにより、各マスターインスタンスの可用性を向上させることができます。

スケーラビリティー

「水平スケーリング」は、複数のホストサーバーを接続して1 つの装置として動作させることで実現します。ロードバランスに対応したサービスは、サービスの速度と可用性が向上するため、水平スケーリングが行われていると見なされます。一方、「垂直スケーリング」は、1 台のホストサーバー内部にリソースを追加することにより、既存のハードウェアの容量を拡張します。スケーリング可能なリソースには、CPU、メモリー、および記憶装置が含まれます。水平スケーリングおよび垂直スケーリングは相互排他的なものではないため、配備ソリューションとして両者を併用することができます。通常、環境内のサーバーに容量いっぱいまでリソースがインストールされることはないため、垂直スケーリングを使用してパフォーマンスを改善します。サーバーの容量が限界に近づいた場合も、水平スケーリングを使用して、ほかのサーバーに負荷を分散することができます。

ハードウェア要件

Access Manager を配備する場合の最小構成は、Access Manager と Sun Java System Web Server などの Web コンテナを実行する 1 台のホストサーバーです。Directory Server が稼働するサーバーは、Access Manager と同じでも、違ってもかまいません。複数のサーバーが配備されている環境では、Access Manager インスタンスとそれに対応する Web コンテナは異なるホストサーバーにインストールされ、クライアントの要求は、ロードバランサによって各 Access Manager インスタンスに分配されます。通常、Directory Server と Access Manager は別々のサーバーにインストールされます。

パフォーマンスを最適化するために、Access Manager は 100M バイト以上の Ethernet ネットワーク上で実行してください。Access Manager と 1 つのWeb コンテナを実行する Access Manager 配備の最小構成には、1 個以上の CPU を搭載している必要がありますが、5 個以上の CPU を搭載してもプロセッサのパフォーマンスはそれほど向上しません。ホストサーバーごとに 2 〜 4 個の CPU を強くお勧めします。ソフトウェアの基本的なテストを実行するために、512M バイト以上の RAM が必要です。

実際の配備では、スレッド、Access Manager SDK、HTTP サーバー、およびほかの内部処理用に 1G バイトの RAM、基本操作およびオブジェクト割り当て領域に 2G バイトの RAM、さらに 10,000 並行セッションごとに 100M バイトの RAM が推奨されています。各 Access Manager は、並行セッションが 100,000 でキャップアウトすることが推奨されており、それ以降は、水平ロードバランスを適用する必要があります (32 ビットアプリケーションの 4G バイトメモリー制限を前提とする)。

ソフトウェア要件

Access Manager には、次のような固有のソフトウェア要件があります。

サポートされるリリース、必要なパッチ、および既知の制限を含むソフトウェア要件の最新情報については、『Sun Java System Access Manager 7 2005Q4 リリースノート』を参照してください。

オペレーティングシステム要件

Access Manager 7 2005Q4 は、次のプラットフォームでサポートされています。

OS パッチおよびパッチクラスタのダウンロード方法については、http://sunsolve.sun.com/ にある SunSolve Online にアクセスしてください。

現在 Solaris システムにインストールされているパッチを表示するには、showrev -p コマンドを使用します。

Web コンテナ要件

Access Manager 7 2005Q4 は、完全インストール、または SDK のみのインストールのいずれかでの使用に次の Web コンテナをサポートしています。

これらの Web コンテナのサポートされているバージョンについては、『Sun Java System Access Manager 7 2005Q4 リリースノート』を参照してください。

ポリシーエージェントを Access Manager Web コンテナにインストールする場合は、約 10M バイトのディスク容量が使用されます。Web コンテナを設定するときには、この追加容量を考慮に入れる必要があります。詳細は、『Sun Java System Access Manager Policy Agent 2.2 User’s Guide』を参照してください。

Directory Server 要件

Access Manager 7 2005Q4 には、LDAP ディレクトリサーバーに対する次の要件があります。

Access Manager 情報ツリーおよびアイデンティティーリポジトリについては、『Sun Java System Access Manager 7 2005Q4 Technical Overview』を参照してください。

Java Development Kit (JDK) ソフトウェア要件

Access Manager 7 2005Q4 に必要な JDK ソフトウェアに固有のバージョンについては、『Sun Java System Access Manager 7 2005Q4 リリースノート』を参照してください。

Access Manager セッションフェイルオーバー要件

Access Manager セッションフェイルオーバーを実装することを計画している場合、以下のコンポーネントが必要です。

Access Manager のセッションフェイルオーバーは以下のプラットフォームでサポートされています。

これらのプラットフォームおよびコンポーネントがサポートされるバージョンに関する最新の情報については、『Sun Java System Access Manager 7 2005Q4 リリースノート』を参照してください。

詳細は、「Access Manager セッションフェイルオーバーの実装」を参照してください。

Web ブラウザ要件

Access Manager 管理者およびエンドユーザーは、Web ブラウザを使用して、管理タスクおよびユーザー管理タスクを実行します。このリリースでサポートされる Web ブラウザについては、『Sun Java System Access Manager 7 2005Q4 リリースノート』を参照してください。

Access Manager スキーマ

スキーマとは、データに課されるルールセットのことで、通常はデータの格納方法の定義に利用されます。Sun Java System Directory Server は LDAP (Lightweight Directory Access Protocol) スキーマを使用して、データの格納方法を定義します。オブジェクトクラスは、LDAP スキーマ内の属性を定義します。Directory Server では、各データエントリは、内部の属性セットを記述および定義するオブジェクトのタイプを指定するため、1 つ以上のオブジェクトクラスを保持する必要があります。基本的に、各エントリは、属性セットとその対応する値、およびこれらの属性に対応するオブジェクトクラスのリストになります。

Access Manager は、Sun Java System Directory Server をデータリポジトリとして使用します。このリポジトリには Directory Server スキーマを拡張する Access Manager スキーマが組み込まれています。Access Manager のインストール時に、ds_remote_schema.ldif と sunone_schema2.ldif のファイルで構成される Access Manager スキーマは、Directory Server スキーマと統合されます。ds_remote_schema.ldif ファイルは、Access Manager が固有に使用するLDAP オブジェクトクラスと属性を定義します。sunone_schema2.ldif ファイルは、Access Manager LDAP スキーマのオブジェクトクラスと属性をロードします。

ds_remote_schema.ldif、sunone_schema2.ldif 、およびその他の Access Manager LDIF ファイルは、以下のディレクトリにあります。

マーカーオブジェクトクラス

Access Manager コンソールを使用して作成し、Directory Server 内に格納したアイデンティティーエントリには、マーカーオブジェクトクラスが追加されます。マーカーオブジェクトクラスは、指定されたエントリを Access Manager が管理するエントリとして定義します。オブジェクトクラスは、サーバーやハードウェアなど、ディレクトリツリーのほかの面には影響を与えません。また、既存のアイデンティティーエントリは、これらのオブジェクトクラスを含めるようにエントリを変更しない限り、Access Manager を使用して管理することはできません。マーカーオブジェクトクラスについては、『Access Manager 開発者ガイド』を参照してください。既存の Directory Server データを Access Manager で使用するために移行する方法については、『 Sun Java Access Manager 6 2005Q1 Migration Guide』を参照してください。

管理ロール

LDAP エントリの委任された管理 (Access Manager 内の各アイデンティティー関連オブジェクトにマップされる) は、定義済みのロールおよびアクセス制御命令 (ACI) を使用して実装されます。デフォルトの管理ロールおよびその定義済み ACI は、Access Manager のインストール時に作成され、Access Manager コンソールを使用して表示および管理できます。Access Manager 7 2005Q4 のレルムモードでは、ロールは ACI ではなくポリシーに依存します。

Access Manager のアイデンティティー関連オブジェクトが作成されると、適切な管理ロール (および対応する ACI) も作成され、そのオブジェクトの LDAP エントリに割り当てられます。そのあと、ロールは、そのオブジェクトのノード制御を管理する個々のユーザーに割り当てることができます。たとえば、Access Manager が組織を新規作成すると、いくつかのロールが自動的に作成され、Directory Server に格納されます。

これらのロールのいずれかをユーザーに割り当てると、そのロールに与えられたすべてのアクセス権がユーザーに与えられます。

次の表に、Access Manager 管理ロール、および各ロールに適用される権限の要約を示します。

表 3–1 デフォルトおよび動的なロールとそのアクセス権

ロール 

管理サフィックス 

アクセス権 

最上位組織の管理者 (amadmin) 

ルートレベル 

最上位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権。 

最上位組織のヘルプデスク管理者 

ルートレベル 

最上位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権。 

最上位組織のポリシー管理者 

ルートレベル 

すべてのレベルのポリシーに対する読み取りおよび書き込みアクセス権。参照ポリシー作成を委任するため、下位組織により使用されます。 

組織管理者 

組織のみ 

作成された下位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 

組織のヘルプデスク管理者 

組織のみ 

作成された下位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。 

組織ポリシー管理者 (Organization Policy Admin) 

組織のみ 

作成された下位組織内のすべてのポリシーに対する読み取りおよび書き込みアクセス権のみ。 

コンテナ管理者 (Container Admin) 

コンテナのみ 

作成されたコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 

コンテナヘルプデスク管理者 (Container Help Desk Admin) 

コンテナのみ 

作成されたコンテナ内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。 

グループ管理者 

グループのみ 

作成されたグループ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 

ピープルコンテナ管理者 

ピープルコンテナのみ 

作成されたピープルコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 

ユーザー (自己管理者) 

ユーザーのみ 

ユーザーエントリ内のすべての属性に対する読み取りおよび書き込みアクセス権のみ (nsroledn や inetuserstatus などのユーザー属性を除く)。

グループベースの ACI の代わりにロールを使用すると、効率を高め、保守の手間を少なくすることができます。フィルタ処理されたロールは、ユーザーの nsRole 属性の確認のみを行うため、LDAP クライアントの処理が簡略化されます。ロールは、そのメンバーの親のピアでなければならない、という範囲制限の影響を受けます。

デフォルトACI については、Access Manager コンソールのオンラインヘルプを参照してください。

Access Manager の管理アカウント

Access Manager のインストール時には、次の管理アカウントが作成されます。

puser および dsameuser は関連付けられたパスワードを所有し、それぞれのパスワードは serverconfig.xml に暗号化された形式で格納されています。このファイルは次のディレクトリ内にあります。

インストール後に、puser および dsameuser のパスワードを変更することをお勧めします。ただし、amadmin や amldapuser に使用したものと同じパスワードを使用しないでください。puser または dsameuser のパスワードを変更するには、ampassword ユーティリティーを使用します。

puser と dsameuser のどちらのパスワードを変更するかは、ユーザーの配備によって決まります。

Access Manager が単一のホストサーバー上に配備されている場合は、次の手順を実行します。

  1. ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。

  2. Access Manager Web コンテナを再起動します。

Access Manager が複数のホストサーバー上に配備されている場合は、次の手順を実行します。

  1. 最初のサーバー上で、ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。

  2. ampassword --encrypt (または -e) オプションを使用して、新しいパスワードを暗号化します。

  3. Access Manager の配備されているその他の各サーバー上で、手順 2 で暗号化した新しいパスワードを使用して、serverconfig.xml ファイル内のパスワードを手動で変更します。

  4. パスワードを変更した各サーバー上 (最初のサーバーを含む) で、Access Manager Web コンテナを再起動します。

ampassword ユーティリティーについては、『Sun Java System Access Manager 7 2005Q4 管理ガイド』を参照してください。

スキーマの制限

Access Manager は、管理するエントリを抽象的に表現します。したがって、たとえば、Access Manager 内の組織は、Directory Server 内の組織とは必ずしも同じにはなりません。特定の DIT (Directory Infromation Tree) を管理できるかどうかは、ディレクトリエントリを表すまたは管理する方法と、DIT が各 Access Manager タイプの制限に適しているかどうかによります。

以下の項で、Access Manager スキーマに課される制限について説明します。この節の最後には、「サポートされない DIT の例」も複数記載しています。

組織としてマークできるエントリのタイプは 1 つに限られる

Access Manager sunISManagedOrganization 予備クラスを、任意のエントリに追加することにより、 Access Manager では、このエントリを組織であるように管理できます。ただし、組織としてマークできるエントリのタイプは 1 つに限られます。たとえば、DIT にエントリ o=sun と別のエントリ dc=ibm がある場合、両方のエントリを組織としてマークすることはできません。

次の例では、dc と o の両方のエントリを組織にしようとしていますが、この DIT 構造は Access Manager で管理できません。

Access Manager では管理できない DIT 構造

ただし、Access Manager ルートサフィックスでのエントリは、1 つのエントリには数えられません。したがって、次の例のDIT 構造は、Access Manager で管理できます。

Access Manager で管理できる DIT 構造

o=continent1 の下に dc=company1 を追加した場合、dc がコンテナとしてマークされている場合にのみ、このDIT の管理が可能になります。コンテナは、Access Manager の別の抽象タイプであり、通常、OrganizationalUnit にマッピングされます。ほとんどの DIT では、 iplanet-am-managed-container エントリをすべての OrganizationlUnits に追加します。

Access Manager で管理できる DIT 構造

ただし、このマーカーオブジェクトクラスはどのエントリタイプにも追加できます。次の例の DIT 構造が可能です。

Access Manager で管理できる DIT 構造

この例では、o= と ou= の両方のエントリを組織としてマークすることはできないため、o= エントリを organization としてマークし、ou= エントリを containers としてマークしています。コンソールに表示されるときに、組織とコンテナで利用できるオプションは同じです。従属または下位区分、ピープルコンテナ、グループ、ロール、およびユーザーは、両方の内部で作成できます。

ピープルコンテナをユーザーの親エントリにする必要がある

もう 1 つの抽象エントリタイプはピープルコンテナです。Access Manager タイプは、このエントリがユーザーの親エントリであると想定します。ピープルコンテナとしてエントリに iplanet-am-managed-people-container のマークが付けられていると、UI は、このコンテナには下位ピープルコンテナまたはユーザーだけが存在すると見なします。属性 OrganizationUnit が通常、ピープルコンテナとして使用されますが、iplanet-am-managed-people-container オブジェクトクラスを保有し、Access Manager の管理可能な親タイプの organization または container を保持する限り、Access Manager のどのエントリでもピープルコンテナとして使用できます。

Access Manager XML で可能な組織の説明は 1 つに限られる

Access Manager の組織は、amEntrySpecific.xml で定義されます。このファイルでは、1 つの組織の説明だけを記述できます。この結果、ディレクトリエントリのプロパティーをカスタマイズしたり、管理ページや検索ページを UI 内に作成すると、カスタム属性は Access Manager 設定全体に適用されます。この Access Manager 要件は、特にホスティングサービスを行う企業など、配備における組織ごとに異なる表示属性を必要とする諸企業のニーズに合わない場合があります。

次の例で、Edison-Watson 社はホスティング企業として、インターネットサービスを多数の企業に提供しています。企業 A では、ユーザーの姓、名、バッジ番号を入力するフィールドを表示する必要があります。企業 B では、ユーザーの姓、名、社員番号を入力するフィールドを表示する必要があります。

他の 2 社に対してインターネットサービスを提供するホスティング企業の組織

組織の説明は、組織レベルではなくルートレベル (o=EdisonWatson) で定義されます。デフォルトでは、企業 A と 企業 B の両方の UI を同一にする必要があります。また、すべてのサービスは、下位スキーマタイプユーザーの属性になるように、属性をグローバルに定義します。したがって、企業 A が、予備クラス CompanyA-user にそのユーザー用の属性を保持し、企業 B が、CompanyB-user に属性を保持している場合、企業 B の属性は上書きされ、表示されません。

回避策としては、ユーザー表示に対処するように ACI を修正する方法があります。ただしこの回避策は、「検索」および「作成」ウィンドウでの属性には対処しません。

サポートされない DIT の例

次の例では、次の 3 タイプの組織マーカーが必要になります。o、ou、および l。 l=california および l=alabama がピープルコンテナではないと見なされるため、この DIT は Access Manager では動作しません。

Access Manager によってサポートされない DIT の例

次の例では、3 タイプの Access Manager マーカー (dc、o、ou)、およびピープルコンテナ (ou=people) が必要になります。この条件下では、DIT は Access Manager で動作しません。

Access Manager によってサポートされない DIT の例