| Sun ONE Identity Server 配備ガイド |
第 4 章
配備前の考慮事項SunTM ONE Identity Server 6.1 は、異機種システムの混在するハードウェア、ソフトウェア、およびアプリケーションインフラストラクチャを抱える大規模な組織が、従業員、受託業者、顧客、およびサプライヤのアイデンティティ管理ソリューションを成功裏に配備することを可能にします。この章では、このプロセスに関連する高度な技術的概要を説明します。次の節で構成されています。
配備オプションIdentity Server の配備を計画する際、組織が考慮する必要のある重要な要素がいくつかあります。これらは、通常、リスク評価および成長戦略と関連があります。例を示します。
さらに、アーキテクチャは、以降の節で説明する目標を達成するための基礎を提供する必要があります。
セキュリティ
セキュリティの確保された内部および外部ネットワーク環境を提供する際、考慮する必要のあるオプションが多数存在します。以下にその内容を示します。
- サーバーへのポートレベルのアクセスを制限することにより、追加セキュリティレイヤーを提供するサーバーベースのファイアウォール。標準のファイアウォールと同様、サーバーベースのファイアウォールは、着信および送信 TCP/IP トラフィックを制限します。
- 最小化とは、システムの脆弱性が利用される機会を最小限に抑えるために、不要なソフトウェアおよびサービスをすべてサーバーから削除することを指します。
- 分割 DNS インフラストラクチャは、1 つのドメイン内に 2 つのゾーンが作成されるインフラストラクチャです。1 つのゾーンは組織の内部ネットワーククライアントにより使用され、もう 1 つのゾーンは外部ネットワーククライアントにより使用されます。この手法は、より高度なセキュリティレベルを実現するために推奨されています。DNS サーバーも、ロードバランスを行うことで、パフォーマンスを向上させることができます。
高可用性
IT の配備では、ユーザーの可用性の継続と同様に、SPOF (Single Point Of Failure) が発生しないよう、努力が求められます。可用性を高めるための手法は、クラスタリングやマルチマスターレプリケーションなど、製品ごとに異なります。期待される高可用性とは、システムやコンポーネントが期待とおりに長期間、連続的に使用可能であることです。このシステムは一般的に、複数のサーバーマシンで構成されますが、ユーザーには、1 つの高可用性システムのように見えます。すべてのアプリケーションが 1 台のサーバーで動作する、最小構成の配備の場合、次の SPOF が含まれます。
これらの問題のうち、その大半は事前に予測できるので、高可用性の実現手法は、データストレージのバックアップやアクセスに対するフェイルオーバーの処理を中心に計画することが可能です。ストレージに関する 1 つの手法は、RAID (redundant array of independent disks) です。より高い可用性が求められるシステムでは、システムの各部分が適切に設計され、本稼働に先立ち、十分にテストされていることが必要です。たとえば、テストが十分ではない新規のアプリケーションプログラムほど、本番での稼働中に、システム全体に影響するエラーを引き起こす可能性が高くなります。
クラスタリング
クラスタリングとは、単一の高可用性システムを構築するために複数のコンピュータを使用することを指します。クラスタリングは、Sun ONE Identity Server では使用できないものの、システムの基盤である Sun ONE Directory Server のデータストアでは、極めて重要な手法です。たとえば、クラスタ化された 1 組の MMR サーバーでは、クラスタでの可用性を保証することにより、各マスターインスタンスの可用性を向上させることができます。
スケーラビリティ
「水平スケーリング」は、複数のサーバーマシンを接続して 1 つの装置として動作させることで実現します。ロードバランスに対応したサーバーは、サービスの速度と可用性が向上するため、水平スケーリングが行われていると見なされます。一方、「垂直スケーリング」は、1 台のサーバーマシン内部にリソースを追加することにより、既存のハードウェアの容量を拡張します。スケーリング可能なリソースには、CPU、メモリ、および記憶装置が含まれます。水平スケーリングおよび垂直スケーリングは相互排他的なものではないため、協調動作が可能です。通常、環境内のサーバーのインストールにより能力の限界まで使用されることはないため、垂直スケーリングはパフォーマンスを改善するために使用されます。また、特定のマシンが処理能力の限界に近づいた場合も、水平スケーリングは、多数のサーバーによって負荷を分散します。
ハードウェア要件Identity Server をインストールするハードウェアは、一定の要件を満たす必要があります。Identity Server は、最低限、Sun ONE Directory Server 5.2 (データストアとして使用する) および配備先の Web コンテナと共にインストールする必要があります。Directory Server および Identity Server は、異なるマシンにインストールすることが推奨されています。
詳細な要件は、コンポーネントのデフォルト設定 (Identity Server (Sun ONE Web Server により配備される) の 1 つのインスタンス、および Directory Server の 1 つのインスタンス) に基づいて行われる高度な設定です。Identity Server をインストールする前に、『Directory Server インストールおよびチューニングガイド』、『導入ガイド』、および選択した Web コンテナのマニュアルを参照してください。
注
推奨される手順は、Sun ONE Identity Server を設計および配備する前に Sun ONE プロフェッショナルサービスまたは Sun ONE 認定システムインテグレータに相談することです。
Identity Server は、100M バイト以上の Ethernet ネットワーク上で実行することが推奨されています。Identity Server 配備の最小構成は、Identity Server と Sun ONE Web Server の両方がインストールされたマシンです。1 個以上の CPU を搭載している必要がありますが、5 個以上の CPU を搭載しても効果はあまり期待できません。サーバーごとに 2 〜 4 個の CPU を強くお勧めします。ソフトウェアの基本的なテストを実行するために、256M バイト以上の RAM が必要です。現実の配備シナリオでは、スレッド、SDK、HTTP サーバー、および他の内部処理用に 1G バイトの RAM が推奨されています。各 Identity Server は、並行セッションが 100,000 でキャップアウトすることが推奨されています。その後、水平ロードバランスを適用する必要があります (32 ビットアプリケーションの 4G バイトメモリ制限を前提とする)。
ソフトウェア要件Identity Server のインストール先システムは、最小のソフトウェアおよびオペレーティングシステム要件を満たす必要があります。
オペレーティングシステム要件
Identity Server は、次のプラットフォームでサポートされています。
Solaris 用パッチクラスタ
Directory Server を Solaris 8 オペレーティングシステム上で実行する場合、推奨されるパッチクラスタをインストールする必要があります。パッチクラスタは、108827-15 のように 2 つの番号で識別されます。最初の番号 (108827) は、パッチ自体を識別するためのものです。2 番目の番号により、パッチのバージョン (15) を示します。最新の修正の恩恵を受けるには、最新のパッチをインストールする必要があります。全般的なパッチ情報および推奨されるパッチは、SunSolve Patch Support Portal からダウンロードできます。(パッチクラスタは、Sun ONE Directory Server、Sun ONE Web Server、および Sun ONE Application Server に必須です。)
以下に、Identity Server をインストールする前にインストールしておく必要のあるパッチリストを示します。必要パッチに関する詳細な情報については、『Sun Java Enterprise System 2003Q4 インストールガイド』を参照してください。
JavaTM 要件
Identity Server には、Java バージョン 1.3.1 が必須です。使用が推奨されているのは、Java バージョン 1.4.1 です。
リソース Web サーバー要件
Identity Server でサポートされる Web コンテナは、Sun ONE Web Server 6.1 および Sun ONE Application Server 7.0 です。ポリシーエージェントをこれらの Web サーバーコンテナにインストールする場合、約 10M バイトのディスク容量が使用されます。コンテンツを提供する Web コンテナを設定する場合には、このことを考慮に入れておく必要があります。詳細は、『Sun ONE Identity Server Web Policy Agents Guide』または『Sun ONE Identity Server J2EE Policy Agents Guide』を参照してください。
Web ブラウザ要件
管理者およびエンドユーザーは、Web ブラウザを使用してユーザー管理タスクを実行します。Identity Server は、次の Web ブラウザをサポートします。
Identity Server スキーマの理解スキーマとは、データに課されるルールセットのことで、通常はデータの格納方法の定義に利用されます。Directory Server には、データの格納方法を定義する LDAP (Lightweight Directory Access Protocol) スキーマが含まれます。オブジェクトクラスは、LDAP スキーマ内の属性を定義します。Directory Server では、各データエントリは、内部の属性セットを記述および定義するオブジェクトのタイプを指定するため、1 つ以上のオブジェクトクラスを保持する必要があります。基本的に、各エントリは、属性セットとその対応する値、およびこれらの属性に対応するオブジェクトクラスのリストになります。
Identity Server は、Directory Server を、アイデンティティプロファイル、資格定義、および配備設定情報すべてのデータリポジトリとして使用します。このために、Identity Server は、Directory Server スキーマを拡張する独自のスキーマを保持します。Identity Server のインストール時に、ds_remote_schema.ldif および sunone_schema2.ldif に記述された Identity Server スキーマは、Directory Server スキーマと統合されます。ds_remote_schema.ldif には、特に Identity Server により使用される LDAP オブジェクトクラスおよび属性が記述されます。一般に、これらのオブジェクトクラスおよび属性は、以前のバージョンの Identity Server から受け継いだものです。sunone_schema2.ldif は、Sun Microsystems の新しい内部スキーマドキュメントで定義された Identity Server 固有の LDAP スキーマオブジェクトクラスおよび属性をロードします。参照用に、ds_remote_schema.ldif および sunone_schema2.ldif の内容を、それぞれコード例 4-1 およびコード例 4-2 に示します。
コード例 4-2 sunone_schema2.ldif
add: objectClasses
objectClasses: ( 2.16.840.1.113730.3.2.185 NAME 'sunManagedOrganization' DESC 'Auxiliary class which must be present in an organization entry' SUP top AUXILIARY MAY ( inetDomainStatus $ sunPreferredDomain $ associatedDomain $ sunPreferredOrganization $ sunAdditionalTemplates $ sunOverrideTemplates $ sunRegisteredServiceName $ organizationName ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.75 NAME 'sunManagedSubOrganization' DESC 'Auxiliary class which must be present in an sub organization entry' SUP top AUXILIARY MAY ( inetDomainStatus $ parentOrganization ) X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.29 NAME 'sunNameSpace' DESC 'Auxiliary class which must be present at the root of a subtree representing a namespace' AUXILIARY MAY sunNameSpaceUniqueAttrs X-ORIGIN 'Sun Java System Identity Management' )
objectClasses: ( 1.3.6.1.4.1.42.2.27.9.2.27 NAME 'sunservicecomponent' DESC 'Sub-components of the service' SUP top MUST ou MAY ( sunserviceid $ sunsmspriority $ sunkeyvalue $ sunxmlkeyvalue $ description ) X-ORIGIN 'Sun Java System Identity Management' )
マーカーオブジェクトクラス
Identity Server コンソールを使用して作成し、Directory Server 内に格納したアイデンティティエントリには、マーカーオブジェクトクラスが追加されます。マーカーオブジェクトクラスは、指定されたエントリを Identity Server が管理するエントリとして定義します。オブジェクトクラスは、サーバーやハードウェアなど、ディレクトリツリーの他の面には影響を与えません。また、既存のアイデンティティエントリは、これらのオブジェクトクラスを含めるようにエントリを変更しない限り、Identity Server を使用して管理することはできません。マーカーオブジェクトクラスの詳細は、『Sun ONE Identity Server Customization And API Guide』の第 5 章「Identity Management」を参照してください。既存の Directory Server データを Identity Server で使用するために移行する方法については、『Sun ONE Identity Server Migration Guide』を参照してください。
管理ロール
LDAP エントリの委任された管理 (Identity Server 内の各アイデンティティ関連オブジェクトにマップされる) は、定義済みのロールおよびアクセス制御命令 (ACI) を使用して実装されます。デフォルトの管理ロールおよびその定義済み ACI は、Identity Server のインストール時に作成されます。これは、Identity Server コンソールを使用して表示および管理できます。Identity Server のアイデンティティ関連オブジェクトが作成されると、適切な管理ロール (および対応する ACI) も作成され、そのオブジェクトの LDAP エントリに割り当てられます。その後、ロールは、そのオブジェクトのノード制御を管理する個々のユーザーに割り当てることができます。たとえば、Identity Server が組織を新規作成すると、いくつかのロールが自動的に作成され、Directory Server に格納されます。
これらのロールのいずれかをユーザーに割り当てると、そのロールに適したすべてのアクセス権がユーザーに与えられます。表 4-2 に、Identity Server 管理ロールおよび、各ロールに対応する書き込み権限の範囲を示します。
表 4-2 デフォルトおよび動的なロールとそのアクセス権
ロール
管理サフィックス
アクセス権
最上位組織の管理者 (amadmin)
ルートレベル
最上位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権
最上位組織のヘルプデスク管理者
ルートレベル
最上位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権
最上位組織のポリシー管理者
ルートレベル
最上位組織内で作成されたポリシーに対する読み取りおよび書き込みアクセス権のみ。参照ポリシー作成を委任するため、下位組織により使用される
組織管理者
組織のみ
作成された下位組織内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ
組織のヘルプデスク管理者
組織のみ
作成された下位組織内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ
組織ポリシー管理者 (Organization Policy Admin)
組織のみ
作成された下位組織内のすべてのポリシーに対する読み取りおよび書き込みアクセス権のみ
コンテナ管理者 (Container Admin)
コンテナのみ
作成されたコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ
コンテナヘルプデスク管理者 (Container Help Desk Admin)
コンテナのみ
作成されたコンテナ内のすべてのパスワードに対する読み取りおよび書き込みアクセス権のみ
グループ管理者
グループのみ
作成されたグループ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ
ピープルコンテナ管理者
ピープルコンテナのみ
作成されたピープルコンテナ内のすべてのエントリ (ロール、ポリシー、グループなど) に対する読み取りおよび書き込みアクセス権のみ
ユーザー (自己管理者)
ユーザーのみ
ユーザーエントリ内のすべての属性に対する読み取りおよび書き込みアクセス権のみ
グループベースの ACI の代わりにロールを使用すると、効率を高め、保守の手間を少なくすることができます。フィルタ処理されたロールは、ユーザーの nsRole 属性の確認のみを行うため、LDAP クライアントの処理が簡略化されます。ロールは、そのメンバーの親のピアでなければならない、という範囲制限の影響を受けます。デフォルト ACI の詳細は、『Sun ONE Identity Server Administration Guide』の第 14 章「管理属性」を参照してください。
スキーマの制限
以降の節では、Identity Server スキーマに課される制限のいくつかを説明します。
ピープルコンテナ
Identity Server では、ピープルコンテナは、ユーザー専用の親エントリです。通常は、組織単位がピープルコンテナとして使用されますが、iplanet-am-managed-people-container オブジェクトクラスおよび Identity Server の管理可能な親タイプのオブジェクト、組織、またはコンテナを保持する限り、どのエントリでもピープルコンテナとして使用できます。LDAP エントリに iplanet-am-managed-people-container のマークが付けられると、Identity Server は下位ピープルコンテナまたはユーザーのみが含まれると見なします。このため、ピープルコンテナに含めることができるのは、下位ピープルコンテナまたはユーザーのみです。
1 つの Identity Server 組織のみが許可される
Identity Server 組織のマークを付けることができるのは、1 つの LDAP オブジェクトタイプだけです。つまり、1 つの LDAP タイプエントリに追加できるのは、iplanet-am-managed-org マーカーオブジェクトクラスだけです。(このオブジェクトクラスが追加されるのは、Identity Server がこのエントリを組織であるかのように管理するためです。)
このため、図 4-1 では、dc と o の両方のエントリを Identity Server コンソールを使用して組織として管理することはできません。
図 4-1 管理不可能なディレクトリツリー
図 4-2 に示すツリーは、Identity Server で管理できます。
図 4-2 1 組織ルールの例外
o=continent1 の下に dc=company1 を追加する場合、dc が組織ではなくコンテナとしてマークされている場合にのみ、このツリーは管理可能になります。通常、iplanet-am-managed-container オブジェクトクラスはすべての組織単位に追加されますが、任意のエントリに追加することが可能です。
図 4-3 2 つの組織単位が許可される
この例では、o= と ou= の両方のエントリを組織としてマークすることはできないため、o= エントリを組織としてマークし、ou= エントリをコンテナとしてマークします。Identity Server を使用して両方の組織およびコンテナを管理する場合、利用可能なオプションは同じになります。ピープルコンテナ、下位組織、グループ、ロール、およびユーザーは、両方の内部で作成できます。
サポートされないディレクトリツリー
既存のディレクトリツリーの大半は、Identity Server で動作するように再設定可能ですが、再設定が推奨されない場合もあります。一般に、既存のツリーが、組織の定義に複数タイプの LDAP エントリ (例: dc、o、および ou) を使用する場合、ユーザーデータは、一定の条件下でのみ Identity Server により認識されます。次の例では、3 タイプの組織マーカー、o、ou、および l が必要になります。l=california および l=alabama がピープルコンテナではないと見なされるため、この DIT は Identity Server では動作しません。
図 4-4 シナリオ 1: 許可されない 3 つの LDAP 組織属性
次の例では、3 タイプの Identity Server マーカー (dc、o、ou)、およびピープルコンテナ (ou=people) が必要になります。この条件下では、DIT は Identity Server で動作しません。
図 4-5 シナリオ 2: 許可されない 3 つの LDAP 組織属性
