ソリューションのライフサイクルにおける技術要件段階では、使用状況を分析し、ユースケースを特定して、提案された配備ソリューションの QoS 要件を決定します。この章では、Sun JavaTM System Access Manager 7 2005Q4 での、この処理に関する要件の大まかな技術概要を示します。次の節で構成されています。
Access Manager の配備を計画する際に、組織が考慮する必要のある重要な要素がいくつかあります。これらは、通常、リスク評価および成長戦略と関連があります。次に例を示します。
配備環境でどれくらいのユーザーをサポートすることが見込まれているか。予測される成長率はどれくらいか
ユーザーの成長およびシステムの使用状況を監視し、この実データを予測されるデータと比較して、現在の能力で予測される成長を処理可能であることを確認することは重要です。
環境にサービスを追加する計画はあるか。それは現在の設計に影響を及ぼす可能性があるか
これで、開発中のアーキテクチャーは、現在のサービスに対して最適化されます。将来の計画も検討する必要があります。
さらに、アーキテクチャーは、以降の節で説明する目標を達成するための基礎を提供する必要があります。
セキュリティーの確保された内部および外部ネットワーク環境を計画している場合には、以下の選択肢について考慮してください。
サーバーベースのファイアウォールは、サーバーへのポートレベルのアクセスを制限することにより、追加セキュリティーレイヤーを提供します。標準のファイアウォールと同様、サーバーベースのファイアウォールは、着信および送信 TCP/IP トラフィックを制限します。
最小化とは、システムの脆弱性が悪用される可能性を最小限に抑えるために、不要なソフトウェアおよびサービスをすべてサーバーから削除することをいいます。
分割 DNS インフラストラクチャーには、1 つのドメイン内に 2 つのゾーンが作成されます。1 つのゾーンは組織の内部ネットワーククライアントにより使用され、もう1 つのゾーンは外部ネットワーククライアントにより使用されます。この手法は、より高度なセキュリティーレベルを実現するために推奨されています。DNS サーバーでロードバランサを使用することによって、パフォーマンスを向上させることもできます。
IT の配備では、ユーザーに対して可用性を継続するとともに、SPOF (Single Point Of Failure) を発生させないことが重要です。可用性を高めるための手法は、クラスタリングやマルチマスターレプリケーションなど、製品ごとに異なります。望ましい高可用性とは、システムやコンポーネントが一定の期間、連続的に使用可能であるということです。システムは一般に複数のホストサーバーで構成されますが、ユーザーには 1 つの高可用性システムのように見えます。すべてのアプリケーションが 1 台のサーバーで動作する、最小構成の配備の場合、SPOF に含まれる要素として次のものが考えられます。
Access Manager Web コンテナ
Directory Server
JavaTM 仮想マシン (JVM)
Directory Server ハードディスク
Access Manager ハードディスク
ポリシーエージェント
高可用性を実現する場合は、バックアップやフェイルオーバー処理、およびデータストレージやデータアクセスを中心に計画します。ストレージに関する 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 は、次のプラットフォームでサポートされています。
SolarisTM Operating System (OS)、 SPARC® ベースシステム、バージョン 8、9、および 10
SolarisTM OS、x86 プラットフォーム、バージョン 9 および 10
Red HatTM Linux、Advanced Server および Enterprise Server
OS パッチおよびパッチクラスタのダウンロード方法については、http://sunsolve.sun.com/ にある SunSolve Online にアクセスしてください。
現在 Solaris システムにインストールされているパッチを表示するには、showrev -p コマンドを使用します。
Access Manager 7 2005Q4 は、完全インストール、または SDK のみのインストールのいずれかでの使用に次の Web コンテナをサポートしています。
Sun Java System Web Server
Sun Java System Application Server
BEA WebLogic
IBM WebSphere Application Server
これらの 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』を参照してください。
Access Manager 7 2005Q4 には、LDAP ディレクトリサーバーに対する次の要件があります。
Access Manager 情報ツリーが Sun Java System Directory Server に格納されていること。情報ツリーには次の情報が含まれます。
ユーザー認証の方法
ユーザーがアクセス可能なリソース
ユーザーがリソースへのアクセス権を取得したあとに、アプリケーションで使用可能になる情報
Access Manager には、ユーザーやグループなどのユーザーデータを格納するためのアイデンティティーリポジトリが必要です。Access Manager 7 2005Q4 は、Sun Java System Directory Server または LDAP バージョン 3 (LDAP v3) 互換のディレクトリサーバーをアイデンティティーリポジトリとして使用できます。
Access Manager 情報ツリーおよびアイデンティティーリポジトリについては、『Sun Java System Access Manager 7 2005Q4 Technical Overview』を参照してください。
Access Manager 7 2005Q4 に必要な JDK ソフトウェアに固有のバージョンについては、『Sun Java System Access Manager 7 2005Q4 リリースノート』を参照してください。
Access Manager セッションフェイルオーバーを実装することを計画している場合、以下のコンポーネントが必要です。
Access Manager を実行する Web コンテナ: Sun Java System Web Server、Sun Java System Application Server、IBM WebSphere Application Server、または BEA WebLogic。
Sun Java System Directory Server: すべての Access Manager インスタンスが、同じ Directory Server にアクセスする必要があります。
Sun Java System Message Queue。Message Queue ブローカクラスタは、Access Manager インスタンスとセッションストアデータベースの間のセッションメッセージを管理します。
Sleepycat Software, Inc. の Berkeley DB (http://www.sleepycat.com/) が、デフォルトのセッションストアデータベースです。Sun Java Enterprise System 2005Q4 リリースによって配布されるバーションを使用します。
Access Manager のセッションフェイルオーバーは以下のプラットフォームでサポートされています。
SolarisTM OS、SPARC® ベースシステム、バージョン 8、9、および 10
SolarisTM OS、x86 プラットフォーム、バージョン 9 および 10
Red HatTM Linux、Advanced Server および Enterprise Server
これらのプラットフォームおよびコンポーネントがサポートされるバージョンに関する最新の情報については、『Sun Java System Access Manager 7 2005Q4 リリースノート』を参照してください。
詳細は、「Access Manager セッションフェイルオーバーの実装」を参照してください。
Access Manager 管理者およびエンドユーザーは、Web ブラウザを使用して、管理タスクおよびユーザー管理タスクを実行します。このリリースでサポートされる Web ブラウザについては、『Sun Java System Access Manager 7 2005Q4 リリースノート』を参照してください。
スキーマとは、データに課されるルールセットのことで、通常はデータの格納方法の定義に利用されます。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 ファイルは、以下のディレクトリにあります。
Solaris システム: /etc/opt/SUNWam/config/ldif
Linux システム: /etc/opt/sun/identity/config/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 に格納されます。
組織管理者は設定済み組織のすべてのエントリに対する読み取りアクセス権と書き込みアクセス権を持っています。
組織のヘルプデスク管理者は、設定済み組織のすべてのエントリに対する読み取りアクセス権、およびこれらのエントリ内の userPassword 属性に対する書き込みアクセス権を持っています。
組織のポリシー管理者は、組織のすべてのポリシーに対する読み取りアクセス権と書き込みアクセス権を持っています。
これらのロールのいずれかをユーザーに割り当てると、そのロールに与えられたすべてのアクセス権がユーザーに与えられます。
次の表に、Access Manager 管理ロール、および各ロールに適用される権限の要約を示します。
表 3–1 デフォルトおよび動的なロールとそのアクセス権
ロール |
管理サフィックス |
アクセス権 |
---|---|---|
最上位組織の管理者 (amadmin) |
ルートレベル |
最上位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権。 |
最上位組織のヘルプデスク管理者 |
ルートレベル |
最上位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権。 |
最上位組織のポリシー管理者 |
ルートレベル |
すべてのレベルのポリシーに対する読み取りおよび書き込みアクセス権。参照ポリシー作成を委任するため、下位組織により使用されます。 |
組織管理者 |
組織のみ |
作成された下位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 |
組織のヘルプデスク管理者 |
組織のみ |
作成された下位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。 |
組織ポリシー管理者 (Organization Policy Admin) |
組織のみ |
作成された下位組織内のすべてのポリシーに対する読み取りおよび書き込みアクセス権のみ。 |
コンテナ管理者 (Container Admin) |
コンテナのみ |
作成されたコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 |
コンテナヘルプデスク管理者 (Container Help Desk Admin) |
コンテナのみ |
作成されたコンテナ内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ。 |
グループ管理者 |
グループのみ |
作成されたグループ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 |
ピープルコンテナ管理者 |
ピープルコンテナのみ |
作成されたピープルコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ。 |
ユーザー (自己管理者) |
ユーザーのみ |
ユーザーエントリ内のすべての属性に対する読み取りおよび書き込みアクセス権のみ (nsroledn や inetuserstatus などのユーザー属性を除く)。 |
グループベースの ACI の代わりにロールを使用すると、効率を高め、保守の手間を少なくすることができます。フィルタ処理されたロールは、ユーザーの nsRole 属性の確認のみを行うため、LDAP クライアントの処理が簡略化されます。ロールは、そのメンバーの親のピアでなければならない、という範囲制限の影響を受けます。
デフォルトACI については、Access Manager コンソールのオンラインヘルプを参照してください。
Access Manager のインストール時には、次の管理アカウントが作成されます。
管理者ユーザー ID (amadmin) は、Access Manager の最上位管理者で、Access Manager によって管理されるすべてのエントリに無制限にアクセスできます。デフォルト名の amadmin を変更することはできません。
インストール中に、amadmin のパスワードを入力する必要があります。インストール後に amadmin のパスワードを変更するには、Directory Server コンソールか ldapmodify ユーティリティーを使用します。
LDAP、メンバーシップ、およびポリシーサービスのバインド DN ユーザー ( amldapuser) は、すべての Directory Server エントリに対する読み取りおよび検索アクセス権を持つ管理ユーザーです。デフォルト名の amldapuser を変更することはできません。
インストール中に、amldapuser のパスワードを入力する必要があります。amadmin と同じパスワードは使用しないでください。インストール後に amldapuser のパスワードを変更するには、Directory Server コンソールか ldapmodify ユーティリティーを使用します。
amldapuser のパスワードを変更した場合は、LDAP 認証サービスとポリシー設定サービスにも、この変更を反映させる必要があります。amldapuser は、これらのサービスで使用されているデフォルトユーザーだからです。この変更は、これらのサービスを登録している組織ごとに行う必要があります。
プロキシユーザー (puser) は、任意のユーザー (組織管理者またはエンドユーザーなど) の権限を引き受けることができます。
管理ユーザー (dsameuser) は、Access Manager SDK が、特定のユーザーにリンクされていない Directory Server 上で、サービス設定情報の取得などの操作を実行するときバインドするために使用されます。
puser および dsameuser は関連付けられたパスワードを所有し、それぞれのパスワードは serverconfig.xml に暗号化された形式で格納されています。このファイルは次のディレクトリ内にあります。
Solaris システム: /etc/opt/SUNWam/config
Linux システム: /etc/opt/sun/identity/config
インストール後に、puser および dsameuser のパスワードを変更することをお勧めします。ただし、amadmin や amldapuser に使用したものと同じパスワードを使用しないでください。puser または dsameuser のパスワードを変更するには、ampassword ユーティリティーを使用します。
ampassword --admin (または -a) オプションでは、dsameuser のパスワードが変更されます。(このオプションでは、amadmin のパスワードは変更されません。)
ampassword --proxy (または -p) オプションでは、puser のパスワードが変更されます。
puser と dsameuser のどちらのパスワードを変更するかは、ユーザーの配備によって決まります。
Access Manager が単一のホストサーバー上に配備されている場合は、次の手順を実行します。
ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。
Access Manager Web コンテナを再起動します。
Access Manager が複数のホストサーバー上に配備されている場合は、次の手順を実行します。
最初のサーバー上で、ampassword ユーティリティーを使用して、Directory Server とローカルの serverconfig.xml ファイル内のそれぞれのパスワードを変更します。
ampassword --encrypt (または -e) オプションを使用して、新しいパスワードを暗号化します。
Access Manager の配備されているその他の各サーバー上で、手順 2 で暗号化した新しいパスワードを使用して、serverconfig.xml ファイル内のパスワードを手動で変更します。
パスワードを変更した各サーバー上 (最初のサーバーを含む) で、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 の例」も複数記載しています。
Access Manager sunISManagedOrganization 予備クラスを、任意のエントリに追加することにより、 Access Manager では、このエントリを組織であるように管理できます。ただし、組織としてマークできるエントリのタイプは 1 つに限られます。たとえば、DIT にエントリ o=sun と別のエントリ dc=ibm がある場合、両方のエントリを組織としてマークすることはできません。
次の例では、dc と o の両方のエントリを組織にしようとしていますが、この DIT 構造は Access Manager で管理できません。
ただし、Access Manager ルートサフィックスでのエントリは、1 つのエントリには数えられません。したがって、次の例のDIT 構造は、Access Manager で管理できます。
o=continent1 の下に dc=company1 を追加した場合、dc がコンテナとしてマークされている場合にのみ、このDIT の管理が可能になります。コンテナは、Access Manager の別の抽象タイプであり、通常、OrganizationalUnit にマッピングされます。ほとんどの DIT では、 iplanet-am-managed-container エントリをすべての OrganizationlUnits に追加します。
ただし、このマーカーオブジェクトクラスはどのエントリタイプにも追加できます。次の例の 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 の組織は、amEntrySpecific.xml で定義されます。このファイルでは、1 つの組織の説明だけを記述できます。この結果、ディレクトリエントリのプロパティーをカスタマイズしたり、管理ページや検索ページを UI 内に作成すると、カスタム属性は Access Manager 設定全体に適用されます。この Access Manager 要件は、特にホスティングサービスを行う企業など、配備における組織ごとに異なる表示属性を必要とする諸企業のニーズに合わない場合があります。
次の例で、Edison-Watson 社はホスティング企業として、インターネットサービスを多数の企業に提供しています。企業 A では、ユーザーの姓、名、バッジ番号を入力するフィールドを表示する必要があります。企業 B では、ユーザーの姓、名、社員番号を入力するフィールドを表示する必要があります。
組織の説明は、組織レベルではなくルートレベル (o=EdisonWatson) で定義されます。デフォルトでは、企業 A と 企業 B の両方の UI を同一にする必要があります。また、すべてのサービスは、下位スキーマタイプユーザーの属性になるように、属性をグローバルに定義します。したがって、企業 A が、予備クラス CompanyA-user にそのユーザー用の属性を保持し、企業 B が、CompanyB-user に属性を保持している場合、企業 B の属性は上書きされ、表示されません。
回避策としては、ユーザー表示に対処するように ACI を修正する方法があります。ただしこの回避策は、「検索」および「作成」ウィンドウでの属性には対処しません。
次の例では、次の 3 タイプの組織マーカーが必要になります。o、ou、および l。 l=california および l=alabama がピープルコンテナではないと見なされるため、この DIT は Access Manager では動作しません。
次の例では、3 タイプの Access Manager マーカー (dc、o、ou)、およびピープルコンテナ (ou=people) が必要になります。この条件下では、DIT は Access Manager で動作しません。