ディレクトリに格納するデータの種類によって、ディレクトリの構造、データにアクセスできるユーザー、およびアクセス権限の付与方法が決定されます。特によく利用されるデータの種類には、ユーザー名、電子メールアドレス、電話番号、ユーザーが所属するグループについての情報などがあります。
この章では、データを検索、分類、構造化、および整理する方法について説明します。また、Directory Server のスキーマにデータをマップする方法についても説明します。この章で説明する内容は次のとおりです。
既存のデータを分類する最初のステップでは、データが元々どこに存在していたものか、またそのデータの所有者が誰であるかを特定します。
ディレクトリに含めるデータを特定するには、既存のデータソースの位置を特定して分析します。
情報を提供する組織を特定する。
企業にとって重要な情報を管理している組織をすべて特定します。通常、これらの組織には、情報サービス部、人事部、給与計算部、および経理部が含まれます。
情報のソースであるツールとプロセスを特定する。
情報の一般的なソースには、次のものがあります。
Windows、Novell Netware、UNIX® NIS などのネットワークオペレーティングシステム
電子メールシステム
セキュリティーシステム
PBX (構内交換機) または電話交換システム
人事アプリケーション
データの集中化が各データに与える影響を判定する。
集中データ管理では、新しいツールとプロセスが必要になることがあります。集中化によって、ある組織のスタッフを増員してほかの組織のスタッフを減らすことが必要になる場合は、問題が生じる可能性もあります。
「データ所有者」とは、データを最新の状態に維持する責任のある個人または組織のことです。データの設計時に、ディレクトリにデータを書き込めるユーザーを決めておきます。データの所有者を決めるには、一般に次の規則に従います。
ディレクトリの内容を管理する少人数のマネージャグループを除くすべてのユーザーに対して、ディレクトリへの読み取り専用アクセスを許可する。
各ユーザーが自分自身に関する重要な情報を管理できるようにする。
このような情報には、ユーザーのパスワード、ユーザー自身についての説明的情報、組織内でのユーザーのロールなどがあります。
人に関する重要な情報 (連絡先情報や役職など) を上司が書き込めるようにする。
組織の管理者がその組織に関するエントリを作成および管理できるようにする。
これにより、実質的に組織の管理者が、ディレクトリ内容の管理者にもなります。
グループ内のユーザーに読み取りアクセス権または書き込みアクセス権を与えるロールを作成する。
たとえば、人事、財務、経理などのロールを作成します。これらのロールごとに、そのグループが必要とするデータへの読み取りアクセス権、書き込みアクセス権、またはその両方を許可します。このようなデータには、給与情報、政府指定の ID 番号、自宅の電話番号と住所などがあります。
ロールとエントリのグループ化の詳細は、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の第 9 章「Directory Server のグループ、ロール、および CoS」および『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の第 8 章「Directory Server Groups and Roles」を参照してください。
データに書き込みを許可するユーザーを決定するときに、複数のユーザーに対して同じデータへの書き込み権限が必要になることがあります。たとえば、情報システムまたはディレクトリ管理グループには、従業員のパスワードへの書き込み権限を許可するのが一般的です。同時に、すべての従業員にも自分自身のパスワードへの書き込み権限を許可する場合があります。複数のユーザーに同じ情報への書き込み権限を与えなければならない場合がありますが、このような場合はこのグループを少人数に保ち、容易に特定できるようにします。グループを少人数にすることは、データの完全性の保証に役立ちます。
ディレクトリのアクセス制御の設定については、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の第 6 章「Directory Server のアクセス制御」および『Sun Java System Directory Server Enterprise Edition 6.1 Reference』の「How Directory Server Provides Access Control」を参照してください。
Directory Server やその他の Java Enterprise System サーバーを設定するために使用するデータと、ディレクトリに格納される実際のユーザーデータを区別するには、次の手順に従います。
ユーザーデータと設定データのそれぞれに対して、異なるバックアップ方針を用意します。
ユーザーデータと設定データのそれぞれに対して、異なる高可用性基準を用意します。
設定サーバーをすみやかにシャットダウンし、復元し、再起動します。
ほかの Directory Server インスタンスの保守を実行している間、設定サーバーの稼働を維持します。
データソースを特定するときは、従来のデータソースを含め、ほかのデータソースからのデータを必ず含めるようにしてください。このデータはディレクトリに格納されていない場合もあります。ただし、Directory Server がデータについて何らかの情報を持っている、またはデータを制御できることが必要な場合があります。
Directory Proxy Server には、複数のデータリポジトリからリアルタイムで情報を集約する「仮想ディレクトリ」機能が用意されています。このようなリポジトリには、LDAP ディレクトリ、JDBC 仕様に準拠するデータ、LDIF フラットファイルなどがあります。
仮想ディレクトリは、複数の異なるデータソースからの属性を処理する複合フィルタをサポートします。また、複数の異なるデータソースからの属性を結合する変更もサポートします。
データ分析フェーズの間、複数のアプリケーションが同じデータを異なる形式で必要とすることが判明する場合があります。このような情報 (データ) については、複製するのではなく、アプリケーションの側でそれぞれの要件に合わせて変換させるのが適切な方法です。
ディレクトリ情報ツリー (DIT) は、ディレクトリデータを構造化し、クライアントアプリケーションからデータを参照できるようにするための手段です。DIT は、ディレクトリデータの分散、レプリケート、アクセス制御の方法など、その他の設計判断と緊密に連携します。
適切に設計された DIT は、次のような利点をもたらします。
ディレクトリデータの管理を簡単にする
レプリケーションポリシーとアクセス制御の作成における柔軟性
ディレクトリを使用するアプリケーションをサポートする
ユーザーが簡単にディレクトリを操作できるようにする
DIT の構造は、階層型の LDAP モデルに従います。DIT では、たとえば、グループ、ユーザー、あるいは場所ごとにデータを編成できます。また、ディレクトリツリーによって複数のサーバー間でどのようにデータを分散して配置するかが決まります。
DIT の設計は、レプリケーション設定や、Directory Proxy Server を使用してデータを分散させる方法に影響を及ぼします。DIT の特定部分をレプリケートまたは分散する場合は、レプリケーションおよび Directory Proxy Server の要件について設計時点で検討します。また、分岐点にアクセス制御を適用する必要があるかどうかについても設計時に検討します。
DIT はサフィックス、サブサフィックス、および連鎖サフィックスによって定義されます。「サフィックス」とは分岐またはサブツリーであり、サフィックスの内容全体が管理タスクの単位として扱われます。インデックス生成はサフィックス全体に対して定義され、サフィックス全体を 1 回の操作で初期化できます。サフィックスは通常、レプリケーションの単位でもあります。同じ方法でアクセスおよび管理するデータは、同じサフィックスに格納する必要があります。サフィックスは、「ルートサフィックス」と呼ばれるディレクトリツリーのルートに配置することもできます。
データはサフィックスレベルのみで分割できるため、複数のサーバー間でデータを分散するには、適切なディレクトリツリー構造が必要です。
次の図は、2 つのルートサフィックスを持つディレクトリを示しています。各サフィックスは独立した企業エンティティーを表します。
サフィックスは、他のサフィックスの分岐となることもできます。その場合は「サブサフィックス」と呼ばれます。親サフィックスには、管理操作のためのサブサフィックスの内容は含まれません。サブサフィックスはその親とは別個に管理されます。LDAP 操作の結果にはサフィックスに関する情報は含まれないため、ディレクトリクライアントは、エントリがルートサフィックスの一部であるか、サブサフィックスの一部であるかを認識できません。
次の図に、大規模な企業エンティティに対して、単一のルートサフィックスと複数のサブサフィックスを配置したディレクトリを示します。
サフィックスは、サーバー内の個々のデータベースに対応します。ただし、データベースとそのファイルはサーバーによって内部的に管理され、データベースの用語は使用されません。
連鎖サフィックスは、仮想 DIT を作成して、別のサーバー上にあるサフィックスを参照します。Directory Server は、連鎖サフィックスを使用してリモートサフィックスに対する操作を実行します。ディレクトリはその後、操作がローカルで実行された場合と同じように結果を返します。データの位置は透過的です。クライアントの側では、サフィックスが連鎖されている、またデータがリモートサーバーから取得されているという認識はありません。あるサーバー上のルートサフィックスが、別のサーバーに連鎖されているサブサフィックスを持つ場合があります。この場合、クライアントは単一のツリー構造を認識します。
カスケード型連鎖の場合、連鎖サフィックスはリモートサーバー上などの別の連鎖サフィックスを参照することがあります。各サーバーは操作を転送し、最終的にクライアントの要求を処理するサーバーへ結果を返します。
DIT の設計では、データを格納するサフィックスの選択、データエントリ間の階層関係の決定、DIT 階層内のエントリのネーミングを行います。次に、設計の各段階について詳しく説明します。
サフィックスは、DIT のルートにあるエントリの名前です。共通のルートを持たない DIT が 2 つ以上ある場合、複数のサフィックスを使用できます。デフォルトの Directory Server のインストールには、複数のサフィックスが含まれています。1 つのサフィックスはユーザーデータの格納に使用されます。その他のサフィックスは、設定情報やディレクトリのスキーマなど、内部的なディレクトリ操作に必要なデータの格納に使用されます。
ディレクトリ内のすべてのエントリは、共通のベースエントリ (サフィックス) の下に格納する必要があります。各サフィックス名は次のように指定する必要があります。
グローバルに一意の名前にする
変更しない、または名前をまれにしか変更しないようにする
そのサフィックスの下にあるエントリがオンラインで読みやすいように短い名前にする
ユーザーが容易に入力および記憶できるものにする
一般的には、企業のドメイン名を識別名 (DN) にマップすることがベストプラクティスと考えられています。たとえば、example.com というドメイン名を持つ企業は「dc=example,dc=com」という DN を使用します。
DIT の構造は、フラットまたは階層型から選択できます。フラットツリーのほうが管理が容易ですが、データのパーティション分割、レプリケーション管理、およびアクセス制御のために、ある程度の階層が必要な場合もあります。
「分岐点」とは、DIT の内部で新しいサブ区分を定義するポイントのことです。分岐点を決定するときは、問題が生じる可能性のある名前の変更は避けてください。名前を変更する確率は、名前が変更される可能性があるコンポーネントが、ネームスペース内に多く含まれているほど高くなります。DIT の階層が深いほどネームスペース内のコンポーネントは多くなり、名前を変更する確率が高くなります。
分岐点を定義および命名するときは、次のガイドラインを使用します。
企業組織内でもっとも大きい部門区分のみを表すようにツリーを分岐させます。
分岐点を部門 (企業情報サービス、カスタマサポート、販売、プロフェッショナルサービスなど) に限定します。部門が安定していることを確認します。企業で組織変更が頻繁に行われる場合は、この種の分岐を実行しないでください。
組織の実際の名前ではなく、機能を表す名前または一般的な名前を使用します。
組織名は変更される可能性があり、企業で部門の名前を変更するたびに DIT の変更が必要になるのは問題です。代わりに、組織の機能を表す一般的な名前を使用します。たとえば、「Widget 研究開発」ではなく「エンジニアリング」を使用します。
似たような機能を持つ組織が複数ある場合は、部門の構成に基づいて分岐点を作成するのではなく、その機能を表す分岐点を 1 つ作成します。
たとえば、特定の製品ラインを担当する複数のマーケティング部門がある場合でも、1 つのマーケティングサブツリーのみを作成します。すべてのマーケティングエントリは、そのツリーに所属させます。
次の表に示した、従来からある分岐点属性のみを使用するようにします。
従来からある属性を使用すると、サードパーティーの LDAP クライアントアプリケーションとの互換性が保たれる可能性が高くなります。加えて、従来からある属性はデフォルトのディレクトリスキーマにとって既知であるため、分岐識別名 (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.1 Reference』の第 4 章「Directory Server Replication」を参照してください。
DIT 階層では、特定のタイプのアクセス制御を有効にできます。レプリケーションの場合と同様に、類似したエントリをグループ化したり、エントリを 1 つの分岐から管理したりすることがさらに容易になります。
また、DIT 階層で管理を分散させることもできます。たとえば、DIT を使用して、マーケティング部門の管理者にはマーケティング関連エントリへのアクセス権を付与し、セールス部門の管理者にはセールス関連のエントリへのアクセス権を付与することができます。
DIT ではなくディレクトリの内容に基づいてアクセス制御を設定することもできます。ACI でフィルタされたターゲット機構を使用して、単一のアクセス制御規則を定義します。この規則では、1 つのディレクトリエントリが、特定の属性値を含むすべてのエントリにアクセスできることを記述します。たとえば、ou=Sales という属性を含むすべてのエントリへのアクセス権を営業部の管理者に与える ACI フィルタを設定できます。
ただし、ACI フィルタは管理が簡単ではありません。対象のディレクトリにもっとも適したアクセス制御方法を決定する必要があります。DIT 階層で組織に対応した分岐を作成する、ACI フィルタを適用する、あるいはこの両者を組み合わせる、などの方法から選択します。
ディレクトリスキーマは、ディレクトリに格納できるデータの種類を記述します。スキーマ設計により、個々のデータ要素が LDAP 属性にマップされます。関連する要素は LDAP オブジェクトクラスにまとめられます。適切に設計されたディレクトリスキーマは、データ値のサイズ、範囲、および形式を制限することによって、データの整合性の維持に役立ちます。ディレクトリに含めるエントリの種類と、各エントリで使用できる属性を決定します。
Directory Server に付属の定義済みスキーマには、Internet Engineering Task Force (IETF) 標準の LDAP スキーマが含まれます。このスキーマには、サーバーの機能をサポートするための、アプリケーション固有の追加スキーマが含まれます。また、Directory Server 固有のスキーマ拡張も含まれています。定義済みのスキーマは大半のディレクトリの要件を満たしますが、対象のディレクトリに固有のニーズに対応するために、このスキーマを拡張して新しいオブジェクトクラスと属性を追加することが必要な場合もあります。
スキーマ設計では、次のことを行う必要があります。
デフォルトスキーマへのデータのマッピング
既存のデータをデフォルトスキーマにマップするには、各データ要素が記述するオブジェクトの種類を識別してから、類似のオブジェクトクラスをデフォルトスキーマから選択します。group、people、organization などの共通オブジェクトクラスを使用します。データ要素にもっとも一致するオブジェクトクラスから、類似の属性を選択します。
一致しないデータを特定します。
デフォルトスキーマを拡張して、残りの要件を満たす新しい要素を定義します。
デフォルトのディレクトリスキーマで定義されているオブジェクトクラスと属性に一致しないデータ要素がある場合は、スキーマをカスタマイズできます。スキーマを拡張して、既存のスキーマに制約を追加することもできます。詳細は、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の「カスタムスキーマについて」を参照してください。
スキーマの保守を計画します。
可能であれば、デフォルトの Directory Server スキーマで定義されている既存のスキーマ要素を使用します。標準のスキーマ要素を使用することにより、ディレクトリ対応アプリケーションとの互換性を保ちやすくなります。このスキーマは LDAP 標準に基づいており、多数のディレクトリユーザーによる検討および合意を経ています。
データの整合性を保つことにより、LDAP クライアントアプリケーションがディレクトリエントリを検索しやすくなります。ディレクトリに格納される情報の種類ごとに、その情報をサポートするために必要なオブジェクトクラスと属性を選択します。常に同じオブジェクトクラスと属性を使用します。整合性のないスキーマオブジェクトを使用すると、情報の検索が難しくなります。
次のようにすると、整合性のあるスキーマを維持できます。
スキーマ検査を使用して、属性とオブジェクトクラスが必ずスキーマ規則にマッチしていることを確認する。
スキーマ検査の詳細は、『Sun Java System Directory Server Enterprise Edition 6.1 管理ガイド』の第 11 章「Directory Server のスキーマ」を参照してください。
整合性のあるデータ形式を選択して適用する。
LDAP スキーマを使用して、必要なデータを任意の属性値に格納できます。ただし、LDAP クライアントアプリケーションとディレクトリユーザーに適切な形式を選択して、DIT 内で整合性を維持するようにデータを格納することをお勧めします。Directory Server で LDAP プロトコルを使用する場合、RFC 4517 仕様で定められたデータ形式を使用してデータを表現する必要があります。
標準 LDAP スキーマおよび DIT 設計の詳細は、次のサイトを参照してください。
RFC 4510: Lightweight Directory Access Protocol (LDAP): 技術仕様ロードマップ http://www.ietf.org/rfc/rfc4510.txt
RFC 4511: Lightweight Directory Access Protocol (LDAP): プロトコル http://www.ietf.org/rfc/rfc4511.txt
RFC 4512: Lightweight Directory Access Protocol (LDAP): ディレクトリ情報モデル http://www.ietf.org/rfc/rfc4512.txt
RFC 4513: Lightweight Directory Access Protocol (LDAP): 認証方法とセキュリティー機構 http://www.ietf.org/rfc/rfc4513.txt
RFC 4514: Lightweight Directory Access Protocol (LDAP): 識別名 (DN) の文字列表現 http://www.ietf.org/rfc/rfc4514.txt
RFC 4515: Lightweight Directory Access Protocol (LDAP): 検索フィルタの文字列表現 http://www.ietf.org/rfc/rfc4515.txt
RFC 4516: Lightweight Directory Access Protocol (LDAP): URL http://www.ietf.org/rfc/rfc4516.txt
RFC 4517: Lightweight Directory Access Protocol (LDAP): 構文とマッチングルール http://www.ietf.org/rfc/rfc4517.txt
RFC 4518: Lightweight Directory Access Protocol (LDAP): 国際化された文字列の準備 http://www.ietf.org/rfc/rfc4518.txt
RFC 4519: Lightweight Directory Access Protocol (LDAP): ユーザーアプリケーション用スキーマ http://www.ietf.org/rfc/rfc4519.txt
『Understanding and Deploying LDAP Directory Services』T. Howes, M. Smith, G. Good. Macmillan Technical Publishing, 1999
Directory Server Enterprise Edition でサポートされているすべての RFC および標準規格の一覧は、『Sun Java System Directory Server Enterprise Edition 6.1 Evaluation Guide』の付録 A「Standards and RFCs Supported by Directory Server Enterprise Edition」を参照してください。