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

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

DIT の用語

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

• ディレクトリデータの管理を簡単にする

• レプリケーションポリシーとアクセス制御の作成における柔軟性

• ディレクトリを使用するアプリケーションをサポートする

• ユーザーが簡単にディレクトリを操作できるようにする

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

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

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

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

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

図 4–1 単一 Directory Server 内の 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 の階層が深いほどネームスペース内のコンポーネントは多くなり、名前を変更する確率が高くなります。

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

• 企業組織内でもっとも大きい部門区分のみを表すようにツリーを分岐させます。

  分岐点を部門 (企業情報サービス、カスタマサポート、販売、プロフェッショナルサービスなど) に限定します。部門が安定していることを確認します。企業で組織変更が頻繁に行われる場合は、この種の分岐を実行しないでください。

• 組織の実際の名前ではなく、機能を表す名前または一般的な名前を使用します。

  組織名は変更される可能性があり、企業で部門の名前を変更するたびに DIT の変更が必要になるのは問題です。代わりに、組織の機能を表す一般的な名前を使用します。たとえば、「Widget 研究開発」ではなく「エンジニアリング」を使用します。

• 似たような機能を持つ組織が複数ある場合は、部門の構成に基づいて分岐点を作成するのではなく、その機能を表す分岐点を 1 つ作成します。

  たとえば、特定の製品ラインを担当する複数のマーケティング部門がある場合でも、1 つのマーケティングサブツリーのみを作成します。すべてのマーケティングエントリは、そのツリーに所属させます。

• 次の表に示した、従来からある分岐点属性のみを使用するようにします。

  従来からある属性を使用すると、サードパーティーの LDAP クライアントアプリケーションとの互換性が保たれる可能性が高くなります。加えて、従来からある属性はデフォルトのディレクトリスキーマにとって既知であるため、分岐識別名 (DN) のエントリの構築が簡略化されます。

• ディレクトリに格納されるデータの種類に応じた分岐を行います。

  たとえば、人、グループ、サービス、およびデバイスのそれぞれに対応する独立した分岐を作成します。

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

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

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

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

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

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

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

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