ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド
11g リリース1 (11.1.1.7.0)
B72436-01
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

4 データ特性の定義

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

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

4.1 データソースと所有者の決定

既存のデータを分類する最初の手順では、そのデータの発生源と所有者を特定します。

4.1.1 データソースの特定

ディレクトリに格納するデータを特定するには、既存のデータソースを探して分析します。

  • 情報を提供する組織を特定します。

    企業にとって重要な情報を管理しているすべての組織を特定します。通常、これらの組織には、情報サービス部門、人事管理部門、給与部門、会計部門などがあります。

  • 情報源となるツールおよびプロセスを特定します。

    一般的な情報源には、次のものがあります。

    • Windows、Novell Netware、UNIX NISなどのネットワーク対応オペレーティング・システム

    • 電子メール・システム

    • セキュリティ・システム

    • PBXまたは電話交換システム

    • 人事管理アプリケーション

  • それぞれのデータを集中化することがデータの管理に及ぼす影響を判定します。

    データの集中管理には、新しいツールと新しいプロセスが必要となる場合があります。集中化によって、組織ごとにスタッフを増減することが必要となる場合は、問題が発生することがあります。

4.1.2 データ所有者の決定

データ所有者とは、データを最新の状態に維持することに責任を負う個人または組織のことです。データ設計フェーズで、ディレクトリにデータを書き込みできるユーザーを決定します。データの所有者を決定する一般的な方針は、次のとおりです。

  • 数名のディレクトリ・コンテンツ・マネージャのグループを除くすべてのユーザーに対して、ディレクトリへの読取り専用アクセスを許可します。

  • 個々のユーザーが、情報の戦略的なサブセットを管理できるようにします。

    このような情報のサブセットには、自分のパスワード、ユーザー自身に関する具体的な情報、組織内での自分のロールなどがあります。

  • 連絡先情報や役職など、一部の情報の戦略的なサブセットに対しては、その個人のマネージャに書込みを許可します。

  • 組織の管理者が、その組織に関するエントリを作成および管理できるようにします。

    実質的に、組織の管理者がディレクトリ・コンテンツ・マネージャになります。

  • ユーザーのグループに読取りまたは書込みのアクセス権を付与するロールを作成します。

    たとえば、人事管理、財務、会計などのロールを作成します。これらのロールごとに、そのグループが必要とするデータへの読取りアクセス権、書込みアクセス権またはその両方を許可します。このようなデータには、給与情報、政府指定の識別番号、自宅の電話番号と住所などがあります。

    ロールおよびエントリのグループ化の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第9章「Directory Serverのグループ、ロールおよびCoS」およびOracle Directory Server Enterprise Editionリファレンスの第11章「Directory Serverのグループとロール」を参照してください。

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

ディレクトリのアクセス制御設定の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第6章「Directory Serverのアクセス制御」およびOracle Directory Server Enterprise EditionリファレンスのDirectory Serverがアクセス制御を提供する仕組みに関する説明を参照してください。

4.1.3 ユーザー・データと構成データの区別

Directory Serverやその他のOracle Fusion Middlewareサーバーの構成に使用されるデータと、ディレクトリに格納される実際のユーザー・データを区別するには、次のことを実行します。

  • ユーザー・データおよび構成データに対して、異なるバックアップ計画を用意します。

  • ユーザー・データおよび構成データに対して、異なる高可用性標準を用意します。

  • 構成サーバーを迅速に停止、リストアおよび起動します。

  • 他のDirectory Serverインスタンスのメンテナンス実行中は、構成サーバーを稼働したままにします。

4.2 異種データソースからのデータの特定

データソースを特定する場合は、従来のデータソースを含め、他のデータソースからのデータを必ず対象としてください。このデータは、ディレクトリに格納されていない場合があります。ただし、Directory Serverが、そのデータに関して、なんらかの情報や、制御できることが必要となる場合があります。

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

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

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

4.3 DITの設計

DITの設計では、データを格納する接尾辞の選択、データ・エントリ間の階層関係の決定およびDIT階層内のエントリのネーミングを行います。DITは、ディレクトリ・データへのアクセスをどのように分散、レプリケート、制御するかなどの、設計上のその他の決定事項と緊密に相互作用します。

以降の項では、DITの設計プロセスについて詳しく説明します。

4.3.1 接尾辞の選択

接尾辞は、DITのルートにあるエントリの名前です。共通の実ルートを持たないDITが2つ以上ある場合は、複数の接尾辞を使用できます。デフォルトのDirectory Serverのインストールには、複数の接尾辞が含まれています。一方の接尾辞はユーザー・データの格納に使用されます。もう一方の接尾辞は、構成情報やディレクトリ・スキーマなど、内部的なディレクトリ操作に必要なデータに使用されます。

すべてのディレクトリ・エントリは、共通のベース・エントリ(接尾辞)の下に配置する必要があります。各接尾辞名に必要とされることは、次のとおりです。

  • グローバルに一意であること

  • 静的であり、名前がほとんど変更されないこと

  • 簡潔であり、接尾辞の下のエントリが、オンラインで読みやすいこと

  • ユーザーが入力しやすく、記憶しやすいこと

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

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

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

4.3.2.1 ブランチ・ポイントとネーミングに関する考慮事項

ブランチ・ポイントとは、DIT内に新しいサブ区分を定義するポイントのことです。ブランチ・ポイントを決定する場合は、問題のある名前変更が発生する可能性がないようにします。名前変更の可能性は、名前の中の、変更される可能性のあるコンポーネントの数に比例します。DITの階層が深くなるほど、名前の中により多くのコンポーネントが含まれ、名前が変更される可能性が高まります。

ブランチ・ポイントを定義および命名する場合は、次のガイドラインに従います。

  • 企業内で最大の組織サブ区分のみを表すように、ツリーにブランチを作成します。

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

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

    名前は変更されるため、企業が部門の名前を変更するたびにDITの変更が必要になることは適切ではありません。そのかわり、組織の機能を表す汎用的な名前を使用します。たとえば、Widget研究開発ではなく、エンジニアリングを使用します。

  • 類似した機能を持つ複数の組織がある場合は、部門の構成に基づいてブランチを作成するのではなく、その機能を表す単一のブランチ・ポイントを作成します。

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

  • 次の表に示す、従来のブランチ・ポイント属性のみを使用するようにします。

    従来の属性を使用すると、サード・パーティのLDAPクライアント・アプリケーションとの互換性が保たれる可能性が高くなります。さらに、従来の属性は、デフォルトのディレクトリ・スキーマに対応しているため、ブランチの識別名(DN)のエントリ構築が容易になります。

  • ディレクトリに格納されるデータのタイプに応じてブランチを作成します。

    たとえば、ユーザー、グループ、サービスおよびデバイスについて、個別のブランチを作成します。

表4-1 従来のDNブランチ・ポイントの属性

属性名 定義

c

国名。

o

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

ou

組織単位。この属性は、通常、企業における、組織よりも小さい部門のブランチを表すために使用します。一般的に、組織単位はすぐ上の組織に属しています。

st

都道府県名。

l

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

dc

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

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

4.3.2.2 レプリケーションに関する考慮事項

DITを設計する場合は、どのエントリが他のサーバーにレプリケートされるかを検討します。エントリの特定グループを同じ一連のサーバーにレプリケートする場合は、それらのエントリが特定のサブツリーの下に配置されている必要があります。レプリケートするエントリのセットを記述するには、サブツリーの最上部でDNを指定します。エントリをレプリケートする方法の詳細は、Oracle Directory Server Enterprise Editionリファレンスの第7章「Directory Serverのレプリケーション」を参照してください。

4.3.2.3 アクセス制御に関する考慮事項

DIT階層では、特定のタイプのアクセス制御を有効にできます。レプリケーションの場合と同様、類似のエントリをグループ化して、そのエントリを単一のブランチから管理すると、より簡単になります。

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

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

ただし、ACIフィルタは管理が難しい場合があります。対象のディレクトリに最適なアクセス制御方法が、DIT階層で組織に対応したブランチの作成、ACIフィルタ、その2つの組合せなどのうち、どれであるかを判断する必要があります。

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

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

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

4.4.1 スキーマ設計プロセス

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

  • デフォルト・スキーマへのデータのマッピング

    既存のデータをデフォルト・スキーマにマップするには、各データ要素で記述されるオブジェクトの型を識別してから、類似のオブジェクト・クラスをデフォルト・スキーマから選択します。グループ、ユーザー、組織など、共通のオブジェクト・クラスを使用します。データ要素に最も一致するオブジェクト・クラスから、類似の属性を選択します。

  • 一致しないデータを特定します。

  • デフォルト・スキーマを拡張して、残りのニーズを満たす新しい要素を定義します。

    デフォルトのディレクトリ・スキーマで定義されているオブジェクト・クラスおよび属性に一致しないデータ要素がある場合は、スキーマをカスタマイズします。また、スキーマを拡張して、既存のスキーマに制約を追加することもできます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のカスタム・スキーマに関する説明を参照してください。

  • スキーマのメンテナンスを計画します。

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

4.4.2 データの一貫性の維持

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

スキーマの一貫性を維持するには、次の手順を実行します。

  • スキーマ・チェックを使用して、属性とオブジェクト・クラスがスキーマ・ルールに従っていることを確認します。

    スキーマ・チェックの詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第11章「Directory Serverのスキーマ」を参照してください。

  • 一貫性のあるデータ形式を選択して適用します。

    LDAPスキーマを使用すると、任意の属性値に必要なデータを格納できます。ただし、使用するLDAPクライアント・アプリケーションおよびディレクトリ・ユーザーに適切な形式を選択して、DIT内で一貫性を保ってデータを格納する必要があります。LDAPプロトコルおよびDirectory Serverを使用する場合は、RFC 4517で規定されたデータ形式を使用して、データを表現する必要があります。

4.5 その他のディレクトリ・データ・リソース

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

Directory Server Enterprise Editionでサポートされている、すべてのRFCおよび標準規格の一覧は、『Oracle Directory Server Enterprise Edition評価ガイド』の付録A「Directory Server Enterprise Editionでサポートされている標準規格とRFC」を参照してください。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引