test

Sun Java System Directory Server Enterprise Edition 6.3 配備計画ガイド

第 4 章 データ特性の定義

ディレクトリに格納するデータの種類によって、ディレクトリの構造、データにアクセスできるユーザー、およびアクセス権限の付与方法が決定されます。特によく利用されるデータの種類には、ユーザー名、電子メールアドレス、電話番号、ユーザーが所属するグループについての情報などがあります。

この章では、データを検索、分類、構造化、および整理する方法について説明します。また、Directory Server のスキーマにデータをマップする方法についても説明します。この章の内容は次のとおりです。

データソースと所有者の設定

既存のデータを分類する最初のステップでは、データがもともとどこに存在していたものか、またそのデータの所有者がだれであるかを特定します。

データソースの特定

ディレクトリに含めるデータを特定するには、既存のデータソースの位置を特定して分析します。

データ所有者の決定

「データ所有者」とは、データを最新の状態に維持する責任のある個人または組織のことです。データの設計時に、ディレクトリにデータを書き込めるユーザーを決めておきます。データの所有者を決めるには、一般に次の規則に従います。

データに書き込みを許可するユーザーを決定するときに、複数のユーザーに対して同じデータへの書き込み権限が必要になることがあります。たとえば、情報システムまたはディレクトリ管理グループには、従業員のパスワードへの書き込み権限を許可するのが一般的です。同時に、すべての従業員にも自分自身のパスワードへの書き込み権限を許可する場合があります。複数のユーザーに同じ情報への書き込み権限を与えなければならない場合がありますが、このような場合はこのグループを少人数に保ち、容易に特定できるようにします。グループを少人数にすることは、データの完全性の保証に役立ちます。

ディレクトリのアクセス制御の設定については、『Sun Java System Directory Server Enterprise Edition 6.3 管理ガイド』の第 7 章「Directory Server のアクセス制御」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の「How Directory Server Provides Access Control」を参照してください。

ユーザーデータと設定データの区別

Directory Server やその他の Java Enterprise System サーバーを設定するために使用するデータと、ディレクトリに格納される実際のユーザーデータを区別するには、次の手順に従います。

異なるデータソースからのデータの特定

データソースを特定するときは、従来のデータソースを含め、ほかのデータソースからのデータを必ず含めるようにしてください。このデータはディレクトリに格納されていない場合もあります。ただし、Directory Server がデータについて何らかの情報を持っている、またはデータを制御できることが必要な場合があります。

Directory Proxy Server には、複数のデータリポジトリからリアルタイムで情報を集約する「仮想ディレクトリ」機能が用意されています。このようなリポジトリには、LDAP ディレクトリ、JDBC 仕様に準拠するデータ、LDIF フラットファイルなどがあります。

仮想ディレクトリは、複数の異なるデータソースからの属性を処理する複合フィルタをサポートします。また、複数の異なるデータソースからの属性を結合する変更もサポートします。

データ分析フェーズの間、複数のアプリケーションが同じデータを異なる形式で必要とすることが判明する場合があります。このような情報 (データ) については、複製するのではなく、アプリケーションの側でそれぞれの要件に合わせて変換させるのが適切な方法です。

ディレクトリ情報ツリーを使用したデータの構造化

ディレクトリ情報ツリー (DIT) は、ディレクトリデータを構造化し、クライアントアプリケーションからデータを参照できるようにするための手段です。DIT は、ディレクトリデータの分散、レプリケート、アクセス制御の方法など、その他の設計判断と緊密に連携します。

DIT の用語

適切に設計された DIT は、次のような利点をもたらします。

DIT の構造は、階層型の LDAP モデルに従います。DIT では、たとえば、グループ、ユーザー、あるいは場所ごとにデータを編成できます。また、ディレクトリツリーによって複数のサーバー間でどのようにデータを分散して配置するかが決まります。

DIT の設計は、レプリケーション設定や、Directory Proxy Server を使用してデータを分散させる方法に影響を及ぼします。DIT の特定部分をレプリケートまたは分散する場合は、レプリケーションおよび Directory Proxy Server の要件について設計時点で検討します。また、分岐点にアクセス制御を適用する必要があるかどうかについても設計時に検討します。

DIT はサフィックス、サブサフィックス、および連鎖サフィックスによって定義されます。「サフィックス」とは分岐またはサブツリーであり、サフィックスの内容全体が管理タスクの単位として扱われます。インデックス生成はサフィックス全体に対して定義され、サフィックス全体を 1 回の操作で初期化できます。サフィックスは通常、レプリケーションの単位でもあります。同じ方法でアクセスおよび管理するデータは、同じサフィックスに格納する必要があります。サフィックスは、「ルートサフィックス」と呼ばれるディレクトリツリーのルートに配置することもできます。

データはサフィックスレベルのみで分割できるため、複数のサーバー間でデータを分散するには、適切なディレクトリツリー構造が必要です。

次の図は、2 つのルートサフィックスを持つディレクトリを示しています。各サフィックスは独立した企業エンティティーを表します。

図 4–1 単一 Directory Server 内の 2 種類のルートサフィックス

2 つのルートサフィックスを持つディレクトリ情報ツリー

サフィックスは、他のサフィックスの分岐となることもできます。その場合は「サブサフィックス」と呼ばれます。親サフィックスには、管理操作のためのサブサフィックスの内容は含まれません。サブサフィックスはその親とは別個に管理されます。LDAP 操作の結果にはサフィックスに関する情報は含まれないため、ディレクトリクライアントは、エントリがルートサフィックスの一部であるか、サブサフィックスの一部であるかを認識できません。

次の図に、大規模な企業エンティティーに対して、単一のルートサフィックスと複数のサブサフィックスを配置したディレクトリを示します。

図 4–2 複数のサブサフィックスを持つ単一のルートサフィックス

単一のルートサフィックスと複数のサブサフィックスを持つディレクトリ情報ツリー

サフィックスは、サーバー内の個々のデータベースに対応します。ただし、データベースとそのファイルはサーバーによって内部的に管理され、データベースの用語は使用されません。

連鎖サフィックスは、仮想 DIT を作成して、別のサーバー上にあるサフィックスを参照します。Directory Server は、連鎖サフィックスを使用してリモートサフィックスに対する操作を実行します。ディレクトリはその後、操作がローカルで実行された場合と同じように結果を返します。データの位置は透過的です。クライアントの側では、サフィックスが連鎖されている、またデータがリモートサーバーから取得されているという認識はありません。あるサーバー上のルートサフィックスが、別のサーバーに連鎖されているサブサフィックスを持つ場合があります。この場合、クライアントは単一のツリー構造を認識します。

カスケード型連鎖の場合、連鎖サフィックスはリモートサーバー上などの別の連鎖サフィックスを参照することがあります。各サーバーは操作を転送し、最終的にクライアントの要求を処理するサーバーへ結果を返します。

DIT の設計

DIT の設計では、データを格納するサフィックスの選択、データエントリ間の階層関係の決定、DIT 階層内のエントリのネーミングを行います。次に、設計の各段階について詳しく説明します。

サフィックスの選択

サフィックスは、DIT のルートにあるエントリの名前です。共通のルートを持たない DIT が 2 つ以上ある場合、複数のサフィックスを使用できます。デフォルトの Directory Server のインストールには、複数のサフィックスが含まれています。1 つのサフィックスはユーザーデータの格納に使用されます。その他のサフィックスは、設定情報やディレクトリのスキーマなど、内部的なディレクトリ操作に必要なデータの格納に使用されます。

ディレクトリ内のすべてのエントリは、共通のベースエントリ (サフィックス) の下に格納する必要があります。各サフィックス名は次のように指定する必要があります。

一般的には、企業のドメイン名を識別名 (DN) にマップすることがベストプラクティスと考えられています。たとえば、example.com というドメイン名を持つ企業は「dc=example,dc=com」という DN を使用します。

DIT 構造の作成とエントリのネーミング

DIT の構造は、フラットまたは階層型から選択できます。フラットツリーのほうが管理が容易ですが、データのパーティション分割、レプリケーション管理、およびアクセス制御のために、ある程度の階層が必要な場合もあります。

分岐点とネーミングの考慮事項

「分岐点」とは、DIT の内部で新しいサブ区分を定義するポイントのことです。分岐点を決定するときは、問題が生じる可能性のある名前の変更は避けてください。名前を変更する確率は、名前が変更される可能性があるコンポーネントが、ネームスペース内に多く含まれているほど高くなります。DIT の階層が深いほどネームスペース内のコンポーネントは多くなり、名前を変更する確率が高くなります。

分岐点を定義および命名するときは、次のガイドラインを使用します。

表 4–1 従来からある DN 分岐点の属性

属性名 

定義 

c

国名。 

o

組織名。この属性は通常、大規模な部門の分岐を表すために使用します。そのような分岐の例には、企業の部門、教育機関の学部、子会社、企業内のその他の主要部門などがあります。また、ドメイン名を表す場合もこの属性を使用することをお勧めします。 

ou

組織の構成単位。通常この属性は、組織よりも小さな組織内の部門を表すために使用します。組織単位は、一般にすぐ上の組織に属します。 

st

州または県の名前。 

l

地域 (都市、地方、オフィス、施設名など)。 

dc

ドメインのコンポーネント。 

分岐点の属性を選択するときは、整合性を保つようにしてください。DIT 全体で DN の形式が統一されていないと、一部の LDAP クライアントアプリケーションで問題が発生する可能性があります。DIT のある部分で l (localityName) が o (organizationName) の下位にある場合、必ず、ディレクトリのその他すべての部分でも l が o の下位にあるようにしてください。

レプリケーションに関する検討事項

DIT を設計するときは、どのエントリがほかのサーバーにレプリケートされるかを考慮します。エントリの特定グループを同じサーバー集合にレプリケートする場合、それらのエントリを特定のサブツリー下に配置することをお勧めします。レプリケートするエントリの集合を記述するには、サブツリーの頂点で DN を指定します。エントリのレプリケーションの詳細は、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 4 章「Directory Server Replication」を参照してください。

アクセス制御に関する検討事項

DIT 階層では、特定のタイプのアクセス制御を有効にできます。レプリケーションの場合と同様に、類似したエントリをグループ化したり、エントリを 1 つの分岐から管理したりすることがさらに容易になります。

また、DIT 階層で管理を分散させることもできます。たとえば、DIT を使用して、マーケティング部門の管理者にはマーケティング関連エントリへのアクセス権を付与し、セールス部門の管理者にはセールス関連のエントリへのアクセス権を付与することができます。

DIT ではなくディレクトリの内容に基づいてアクセス制御を設定することもできます。ACI でフィルタされたターゲット機構を使用して、単一のアクセス制御規則を定義します。この規則では、1 つのディレクトリエントリが、特定の属性値を含むすべてのエントリにアクセスできることを記述します。たとえば、ou=Sales という属性を含むすべてのエントリへのアクセス権を営業部の管理者に与える ACI フィルタを設定できます。

ただし、ACI フィルタは管理が簡単ではありません。対象のディレクトリにもっとも適したアクセス制御方法を決定する必要があります。DIT 階層で組織に対応した分岐を作成する、ACI フィルタを適用する、あるいはこの両者を組み合わせる、などの方法から選択します。

ディレクトリデータのグループ化と属性の管理

ディレクトリ情報ツリーは、エントリを階層構造で構成します。この階層は、グループ化メカニズムの 1 種です。この階層は、分散しているエントリの関連付け、頻繁に変更される組織、または多数のエントリで繰り返されるデータには適していません。Directory Server のグループとロールは、エントリ間のより柔軟な関連付けを提供します。サービスクラス (CoS) のメカニズムを使用すると、属性がエントリ間で共有されるように各属性を管理できます。この共有は、アプリケーションには見えない方法で実行されます。

これらのエントリのグループ化と属性管理のメカニズムは、『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 8 章「Directory Server Groups and Roles」および『Sun Java System Directory Server Enterprise Edition 6.3 Reference』の第 9 章「Directory Server Class of Service」で詳細に説明されています。

ここでは、管理戦略の設計には十分なグループ化メカニズムの概要について説明します。ただし、このメカニズムの動作の仕組みや、それらの設定方法については説明していません。

この節は、次の項目で構成されています。

スタティックグループ、ダイナミックグループ、および入れ子のグループ

Directory Server は、スタティックグループ、ダイナミックグループ、および入れ子のグループを識別します。

グループが識別するメンバーはディレクトリ内のどこに配置してもかまいませんが、グループ定義自体は ou=Groups のように適切な名前が付けられたノードに配置するようにします。このようにすることで、バインド資格がグループのメンバーである場合にアクセス権を付与または制限するアクセス制御命令 (ACI) を定義するときなどに、グループ定義を簡単に見つけることができます。

スタティックグループ

スタティックグループは、メンバーエントリの名前を明示的に指定します。たとえば、次の図のように、ディレクトリ管理者のグループにはグループを構成する特定のユーザーの名前が指定されます。

スタティックグループの論理を示す図です

次の LDIF の抜粋は、このスタティックグループのメンバーが定義される方法を示しています。

dn: cn=Directory Administrators, ou=Groups, dc=example,dc=com
...
member: uid=kvaughan, ou=People, dc=example,dc=com
member: uid=rdaugherty, ou=People, dc=example,dc=com
member: uid=hmiller, ou=People, dc=example,dc=com

ダイナミックグループ

ダイナミックグループはフィルタを指定し、そのフィルタと一致するすべてのエントリがグループのメンバーとなります。このようなグループは、フィルタが評価されるたびにメンバーが定義されるため、ダイナミックグループと呼ばれます。

たとえば、すべての管理職とそのアシスタントがビルの 3 階におり、各社員の部屋番号がその階の数字で始まるとします。3 階にいる社員のみを含むグループを作成するのであれば、次の図のように、部屋番号を使用してそれらの社員だけを定義することができます。

ダイナミックグループの論理を示す図です

次の LDIF の抜粋は、このダイナミックグループのメンバーが定義される方法を示しています。

dn: cn=3rd Floor, ou=Groups, dc=example,dc=com
...
memberURL: ldap:///dc=example,dc=com??sub?(roomnumber=3*)

入れ子のグループ

入れ子のグループでは、別のグループの DN をスタティックまたはダイナミックグループの uniqueMember 属性として使用して、他のグループの内部にグループを配置します。Directory Server では、個々のエントリ、スタティックグループ、およびダイナミックグループを参照する混合グループもサポートしています。

たとえば、すべてのディレクトリ管理者、およびすべての管理職とそのアシスタントを含むグループを作成するとします。この場合、先ほど定義した 2 つのグループの組み合わせを使用して、次の図のように 1 つの入れ子のグループを作成することができます。

入れ子のグループの論理を示す図です

次の LDIF の抜粋は、この入れ子のグループのメンバーが定義される方法を示しています。

dn: cn=Admins and 3rd Floor, ou=Groups, dc=example,dc=com
...
member: cn=Directory Administrators, ou=Groups, dc=example,dc=com
member: cn=3rd Floor, ou=Groups, dc=example,dc=com

入れ子のグループはグループ化の手法として必ずしも効率的ではありません。ダイナミックな入れ子のグループには、非常に大きなパフォーマンスコストが必要となります。このようなパフォーマンス上の問題を避けるために、グループではなくロールの使用を考慮してください。

管理されているロール、フィルタを適用したロール、入れ子のロール

ロールは、エントリのグループ化メカニズムです。ロールを使用すると、エントリがディレクトリから取得されるとすぐに、ロールのメンバーシップを決定できます。各ロールはメンバー (そのロールを所有するエントリ) を持ちます。グループと同じようにロールのメンバーを明示的またはダイナミックに指定できます。

Directory Server は、次の 3 種類のロールをサポートしています。

グループとロールのどちらを使用するかの決定

グループとロールのメカニズムは、一部の機能が重なっています。どちらのメカニズムにも利点と欠点があります。一般に、ロールメカニズムのほうが、頻繁に必要となる機能を効率的に提供できるように設計されています。グループ化メカニズムはサーバーの複雑さに影響を及ぼし、グループ化メカニズムを選択することで、クライアントがどのようにメンバー情報を処理するかが決まるため、グループ化メカニズムは慎重に計画する必要があります。どちらのメカニズムがより適しているかを判断するには、実行する標準的なメンバーシップクエリーと管理操作を理解してください。

グループメカニズムの利点

グループには、次の利点があります。

ロールメカニズムの利点

ロールには、次の利点があります。

ロールに対するアクセス権の制限

ロールを使用する場合は、次の問題に注意してください。

サービスクラスによる属性の管理

サービスクラス (CoS) メカニズムを使用すると、エントリ間で属性を共有できます。ロールメカニズムと同様に、エントリが検出されると、CoS がそのエントリに対して仮想属性を生成します。CoS はメンバーを定義しませんが、一貫性の保持と容量の節約のために、関連するエントリがデータを共有できるようにします。CoS の値は、それらの値が要求されたときに動的に計算されます。CoS 機能や、CoS のさまざまな種類については、『Sun Java System Directory Server Enterprise Edition 6.3 Reference 』で詳細に説明されています。

以降の節では、パフォーマンスの低下を回避しながら、CoS 機能を意図したとおりに使用する方法について詳しく説明します。

注 –

CoS の生成は、常にパフォーマンスに影響します。実際に必要とするより多くの属性を検索するクライアントアプリケーションによって、この問題がさらに悪化する可能性があります。

クライアントアプリケーションの記述方法を指示できる場合は、実際に必要な属性値のみを検索するようにクライアントアプリケーションを記述することで、パフォーマンスの大幅な向上が期待できることを開発者に伝えてください。

多数のエントリが同じ値を共有する場合の CoS の使用

CoS は、サブツリー内の多数のエントリに同じ属性値を表示する必要がある場合に、比較的低いコストで大きな利点を提供します。

たとえば、ou=People の下のすべてのユーザーエントリに companyName 属性が含まれている、MyCompany, Inc. のディレクトリを考えてみます。請負業者のエントリには companyName 属性に直接値がセットされていますが、すべての正社員の companyName には、CoS で生成された値 MyCompany, Inc. がセットされています。次の図は、この例でポインタ CoS を使用した場合を示しています。CoS によって、すべての正社員の companyName 値が生成されるが、請負業者の従業員用に直接設定されている実際の companyName 値は置き換えられないことに注意してください。会社名は、companyName が許可された属性になっているエントリに対してのみ生成されます。

図 4–3 ポインタ CoS を使用した CompanyName の生成

図は、ポインタ CoS を使用して生成された CompanyName 属性を示しています。

多数のエントリが同じ値を共有する場合は、ポインタ CoS が特にうまく機能します。正社員に対する companyName の管理が容易になることで、属性値を生成するための追加の処理コストが相殺されます。深いディレクトリ情報ツリー (DIT) は、一般的な特性を共有するエントリをまとめる傾向があります。深い DIT でポインタ CoS を使用すると、ツリー内の適切な分岐に CoS 定義を配置することによって、一般的な属性値を生成できます。

エントリが自然な関係を持っている場合の CoS の使用

CoS はまた、ディレクトリデータが自然な関係を持っている場合も、データ管理の大きな利点を提供します。

すべての従業員にマネージャーがいる企業ディレクトリを考えてみます。すべての従業員がメールストップと Fax 番号を、もっとも近い管理アシスタントと共有しています。図 4–4 は、間接 CoS を使用して、マネージャーのエントリから部門番号を取得する様子を示しています。図 4–5 では、メールストップと Fax 番号が管理アシスタントのエントリから取得されています。

図 4–4 間接 CoS を使用した DepartmentNumber の生成

図は、間接 CoS を使用して生成された DepartmentNumber 属性を示しています。

この実装では、マネージャーのエントリに departmentNumber の実際の値が含まれ、生成されているどの値よりもこの実際の値が優先されます。Directory Server は、CoS で生成された属性値からは属性値を生成しません。そのため、図 4–4 の例では、部門番号の属性値をマネージャーのエントリ上でのみ管理する必要があります。同様に、図 4–5 に示されている例では、メールストップと Fax 番号の属性を管理アシスタントのエントリ上でのみ管理する必要があります。

図 4–5 間接 CoS を使用したメールストップと Fax 番号の生成

図は、間接 CoS を使用して生成されたメールストップと Fax 番号の属性を示しています。

単一の CoS 定義エントリを使用して、このような関係をディレクトリ内のさまざまなエントリに利用できます。

別の自然な関係に、サービスレベルがあります。顧客にスタンダード、シルバー、ゴールド、およびプラチナのパッケージを提供しているインターネットサービスプロバイダを考えてみます。顧客のディスク割り当て、メールボックスの数、前払いのサポートレベルに対する権限などは、購入したサービスレベルによって異なります。次の図は、クラシック CoS スキーマによってこの機能が可能になるようすを示しています。

図 4–6 クラシック CoS を使用したサービスレベルデータの生成

図は、クラシック CoS を使用して生成されたサービスレベルデータを示しています。

1 つの CoS 定義が複数の CoS テンプレートエントリに関連付けられる場合があります。

過剰な CoS 定義の回避

Directory Server は、1 つのクラシック CoS 定義エントリが複数の CoS テンプレートエントリに関連付けられている場合は CoS を最適化します。Directory Server は、多数の CoS 定義が適用される可能性がある場合は CoS を最適化しません。代わりに、Directory Server は各 CoS 定義をチェックして、この定義が適用されるかどうかを判定します。この動作によって、数千の CoS 定義が存在する場合はパフォーマンスの問題が発生します。

この状況は、図 4–6 で示した例に変更がある場合に発生する可能性があります。顧客に、各顧客のサービスレベルの委任管理を提供しているインターネットサービスプロバイダを考えてみます。各顧客から、スタンダード、シルバー、ゴールド、およびプラチナのサービスレベルの定義エントリが提供されます。顧客数が 1000 に増えると、1000 個のクラシック CoS 定義が作成されることになります。どの定義が適用されるを判定するために 1000 個の CoS 定義のリストがチェックされるため、Directory Server のパフォーマンスが影響を受ける可能性があります。この種の状況で CoS を使用する必要がある場合は、間接 CoS を検討してください。間接 CoS では、顧客のエントリによって、その顧客のサービスクラス割り当てを定義するエントリが特定されます。

1 つまたは 2 つのターゲットエントリごとに別の CoS スキーマを選択することの限界に近づき始めたら、実際の値を更新することをお勧めします。CoS で生成されていない実際の値が読み取られるため、より高いパフォーマンスが実現します。

ディレクトリスキーマの設計

ディレクトリスキーマは、ディレクトリに格納できるデータの種類を記述します。スキーマ設計により、個々のデータ要素が LDAP 属性にマップされます。関連する要素は LDAP オブジェクトクラスにまとめられます。適切に設計されたディレクトリスキーマは、データ値のサイズ、範囲、および形式を制限することによって、データの整合性の維持に役立ちます。ディレクトリに含めるエントリの種類と、各エントリで使用できる属性を決定します。

Directory Server に付属の定義済みスキーマには、Internet Engineering Task Force (IETF) 標準の LDAP スキーマが含まれます。このスキーマには、サーバーの機能をサポートするための、アプリケーション固有の追加スキーマが含まれます。また、Directory Server 固有のスキーマ拡張も含まれています。定義済みのスキーマは大半のディレクトリの要件を満たしますが、対象のディレクトリに固有のニーズに対応するために、このスキーマを拡張して新しいオブジェクトクラスと属性を追加することが必要な場合もあります。

スキーマ設計のプロセス

スキーマ設計では、次のことを行う必要があります。

可能であれば、デフォルトの Directory Server スキーマで定義されている既存のスキーマ要素を使用します。標準のスキーマ要素を使用することにより、ディレクトリ対応アプリケーションとの互換性を保ちやすくなります。このスキーマは LDAP 標準に基づいており、多数のディレクトリユーザーによる検討および合意を経ています。

データの整合性の維持

データの整合性を保つことにより、LDAP クライアントアプリケーションがディレクトリエントリを検索しやすくなります。ディレクトリに格納される情報の種類ごとに、その情報をサポートするために必要なオブジェクトクラスと属性を選択します。常に同じオブジェクトクラスと属性を使用します。整合性のないスキーマオブジェクトを使用すると、情報の検索が難しくなります。

次のようにすると、整合性のあるスキーマを維持できます。

その他のディレクトリデータ関連資料

標準 LDAP スキーマおよび DIT 設計の詳細は、次のサイトを参照してください。

Directory Server Enterprise Edition でサポートされているすべての RFC および標準規格の一覧は、『Sun Java System Directory Server Enterprise Edition 6.3 Evaluation Guide』の付録 A「Standards and RFCs Supported by Directory Server Enterprise Edition」を参照してください。