| Oracle Fusion Middleware Oracle Internet Directory管理者ガイド 11gリリース1（11.1.1） B55919-01 |
|
 戻る |
 次へ |
この章では、ディレクトリ情報の論理編成を設計する場合の考慮事項の詳細を説明します。内容は次のとおりです。
Oracle Internet Directoryは、Oracle Identity Managementインフラストラクチャ全体の共有リポジトリとして機能します。ディレクトリの論理構造を慎重に計画することによって、次のことが可能になります。
デプロイメントの要件を満たすセキュリティ・ポリシーの適用
ディレクトリ・サービスの効率的な物理的デプロイメント
サード・パーティのディレクトリをOracle Internet Directoryと同期化させる場合の簡単な構成
図5-1に、アイデンティティ管理をデプロイしているMyCompanyという架空の会社のディレクトリ情報ツリーを示します。
MyCompanyは、米国内でのデプロイメントにおけるディレクトリの論理編成に関して次の事項を決定しています。
ドメイン名ベースのスキームは、DIT階層全体を表す。アイデンティティ管理インフラストラクチャがusドメイン内で展開されるため、dc=us,dc=mycompany,dc=comがDITのルートとなる。
選択したネーミング・コンテキスト内部では、すべてのユーザーがcn=usersというコンテナの下に表示される。このコンテナ内部では、すべてのユーザーが同一レベルで表示される。組織ベースの階層は存在しない。また、すべてのユーザーの一意の識別子としてuid属性を選択する。
選択したネーミング・コンテキスト内部では、すべての企業グループがcn=groupsというコンテナの下に表示される。このコンテナ内部では、すべての企業グループが同一レベルで表示される。すべてのグループ・エントリのネーミング属性をcnとする。
コンテナdc=usを、アイデンティティ管理レルムのルートとして選択する。この場合、レルムの名前はusとする。デプロイメントでは、usレルムの範囲に該当するすべてのユーザーに対して、同様のセキュリティ・ポリシーを施行することを想定する。
Oracle Identity Managementのディレクトリの論理編成の計画には、次のものが含まれます。
ディレクトリ情報ツリー構造全体の計画
ユーザーおよびグループのディレクトリ格納とネーミングの計画
アイデンティティ管理レルムの計画
このタスクでは、企業内のすべてのアイデンティティ管理統合アプリケーションで使用される基本的なディレクトリ情報ツリーを設計します。この設計を行う場合は、次の考慮事項に注意してください。
ディレクトリ編成によって、明確で効果的なアクセス制御が簡単に実行できるようになる必要があります。完全レプリケーションまたは部分レプリケーションのいずれかのレプリケーションを計画した場合、レプリケーションに対して適切な境界およびポリシーを施行できるのは、DITが分離するように設計された場合のみです。
サード・パーティのディレクトリ・サーバーとの統合を行う企業では、Oracle Internet DirectoryのDITの設計と既存のDITを一致させることをお薦めします。この考慮事項は、現在Oracle Internet Directoryを展開し、後で別のディレクトリ（Microsoft社のソフトウェアの操作に必要なMicrosoft Active Directoryなど）を展開するデプロイメントにも該当します。いずれの場合でも、サード・パーティのDITの設計とより一貫性のあるOracle Internet Directoryのディレクトリ情報ツリーの設計を採用すると、Oracle Delegated Administration Servicesおよび他の中間層アプリケーションを使用した、ユーザー・オブジェクトおよびグループ・オブジェクトの管理をより簡単にできます。
単一企業の使用例では、企業のDNSドメイン名と一致するDIT設計を選択すると、十分な結果が得られます。たとえば、mycompany.comというドメイン名を持つ企業でOracle Internet Directoryを設定する場合は、dc=mycompany,dc=comというルートを持つディレクトリ構造を使用することをお薦めします。部門または組織レベルのドメイン・コンポーネント（engineering.mycompany.comのengineeringなど）は使用しないことをお薦めします。
X500ディレクトリ・サービスを使用し、他のサード・パーティのLDAPディレクトリが本番環境に存在しない企業では、国ベースのDIT設計を選択することをお薦めします。たとえば、o=mycompany, c=USというルートを持つDIT設計は、すでにX.500ディレクトリ・サービスを使用している企業に適しています。
ディレクトリは、Oracleおよびサード・パーティの複数のアプリケーションで使用できるため、DIT構造全体を構成する相対識別名（RDN）で使用されるネーミング属性を、予約済属性に制限する必要があります。通常、次の属性は、ほとんどのディレクトリ対応アプリケーションで予約済です。
c: 国の名前
dc: DNSドメイン名のコンポーネント
l: 地域（都市、国、その他の地域など）の名前
o: 組織の名前
ou: 組織単位の名前
st: 州またはその他の地方行政区画の名前
企業の部門構造または組織構造のいずれかを反映してDITを設計するのは、よくある間違いです。ほとんどの企業が組織および部門の再編成を頻繁に行うため、この方法はお薦めしません。企業のディレクトリは、できるかぎり組織変更とは無関係にしておくことが重要です。
この項では、Oracle Internet Directoryでユーザーおよびグループのモデリングを行う場合の考慮事項について説明します。DIT設計全体に関係する設計時の考慮事項のほとんどは、ユーザーおよびグループのネーミングと格納にも当てはまります。
Oracle Identity Managementインフラストラクチャでは、すべてのユーザーのアイデンティティのリポジトリとしてOracle Internet Directoryを使用します。企業内の複数のアプリケーションにアクセスするアカウントを持つユーザーの場合も、そのユーザーのアイデンティティを示すエントリはOracle Internet Directory内に1つのみです。DIT全体でのこれらのエントリの位置と内容は、Oracle Internet DirectoryおよびOracle Identity Managementインフラストラクチャの他のコンポーネントをデプロイする前に計画する必要があります。
前述のとおり、所属部門の関係や階層に基づいてユーザーを編成する傾向があります。ただし、ほとんどの企業は組織および部門の再編成を頻繁に行うため、この方法はお薦めしません。個人のディレクトリ・エントリの属性として個人の組織情報を捉えると、管理しやすくなります。
部門関係や管理系統に基づいた階層でユーザー編成を行った場合、パフォーマンスは向上しません。ユーザーを格納するDITは、できるかぎり浅い階層にしておくことをお薦めします。
デプロイメントに様々なユーザーの集団が含まれ、それぞれの集団が異なる組織によってメンテナンスおよび管理される場合は、それらの管理境界に基づいてユーザーをいくつかのコンテナに分けることをお薦めします。これによって、アクセス制御の設定が簡単になり、レプリケーションが必要になった場合に役立ちます。
検索操作でユーザーを一意に識別するためのデフォルトのニックネーム属性は、uidです。これはログインで使用するデフォルトの属性です。識別名を構成するためのデフォルトのネーミング属性は、cnです。
ユーザーを一意に識別するためのデフォルトの属性は、cnまたはCommonNameです。CommonNameの一般的な値は、そのユーザーのフルネームです。ただし、名前や電子メール・アドレスは変わることがあるため、この属性の値には適さない場合があります。可能であれば、従業員IDなど、ユーザーを一意に識別できる変更のない値を選択してください。
通常、ほとんどの企業には、従業員に一意の名前と番号を割り当てる規則を定める人事部門があります。ディレクトリ・エントリに対して一意のネーミング・コンポーネントを選択する場合、この管理インフラストラクチャを活用し、そのポリシーを使用するのが有効です。
ディレクトリ内に作成するすべてのユーザー・エントリは、inetOrgPersonおよびorclUserV2というオブジェクト・クラスのメンバーである必要があります。
サード・パーティのディレクトリがすでに存在する場合、または将来それを統合する場合は、Oracle Internet Directoryでのユーザーのネーミングとディレクトリの格納を、サード・パーティのディレクトリ内で使用されるものと一致させるのが効果的です。これによって、分散ディレクトリの同期化およびそれ以降の管理が簡単になります。
|
注意: Oracle Internet Directoryリリース9.0.2では、nickname属性のデフォルト値はcnでした。リリース9.0.4以上では、この属性のデフォルト値はuidです。 |
Oracle Identity Managementインフラストラクチャと統合されたアプリケーションの一部では、Oracle Internet Directoryでのデプロイメントによって作成された企業全体にわたるグループに基づいて認可を行うこともできます。ユーザー・エントリ同様、これらのグループ・エントリの位置と内容も慎重に計画する必要があります。グループ設計時の考慮事項は、次のとおりです。
部門関係や所有権に基づいた階層で企業グループ編成を行った場合、パフォーマンスは向上しません。グループを格納するDITは、できるかぎり浅い階層にしておくことをお薦めします。これによって、すべてのアプリケーションによるグループの検出が簡単になり、アプリケーション間でのこれらのグループの共有が促進されます。
エントリの各セットに個別の管理ポリシーを適用できるように、DIT内のユーザーおよびグループを分けることをお薦めします。
グループを一意に識別するには、cnまたはCommonName属性を使用する必要があります。
企業がディレクトリ内に作成するすべてのグループ・エントリは、groupOfUniqueNamesおよびorclGroupというオブジェクト・クラスに属している必要があります。前者のオブジェクト・クラスは、グループを表すインターネット標準です。後者のオブジェクト・クラスは、Oracle Internet Directoryセルフサービス・コンソールを使用してグループを管理する場合に有効です。
企業全体にわたるグループごとに新しいディレクトリ・アクセス制御を作成するのではなく、次のように対応することを検討してください。
グループのowner属性を使用して、グループの所有者であるユーザーを示します。
owner属性で示されたすべてのユーザーに、様々な操作を実行する特別な権限を付与する上位レベルのアクセス制御ポリシーを作成します。
description属性には、グループの目的をユーザーが理解できるように情報を書き込みます。
オブジェクト・クラスorclGroupでのdisplayName属性の使用を検討します。この属性によって、Oracle Delegated Administration ServicesおよびOracle Internet Directoryセルフサービス・コンソールで読みやすいグループ名を表示できます。
様々なグループのセットがあり、それぞれのセットが独自の管理ポリシーを持つ異なる組織によってメンテナンスおよび管理される場合は、それらの管理境界に基づいてグループをいくつかのコンテナに分けます。これによって、アクセス制御の設定が簡単になります。また、レプリケーションが必要な場合にも役立ちます。
サード・パーティのディレクトリがすでに存在する場合、または将来それを統合する場合は、Oracle Internet Directoryでのグループのネーミングとディレクトリの格納を、サード・パーティのディレクトリ内で使用されるものと一致させます。これによって、分散ディレクトリの同期化およびそれ以降の管理が簡単になります。
サード・パーティ・ディレクトリからDITを移行するには、第35章「他のデータ・リポジトリからのデータの移行」および『Oracle Fusion Middleware Oracle Identity Management統合ガイド』に記載した方法で、サード・パーティのメタディレクトリ・ソリューションとの同期化およびサード・パーティ・ディレクトリとの統合を行います。Microsoft Active Directory環境からDITを移行する場合は、Microsoft Active Directory環境との統合の章も参照してください。Oracle Internet DirectoryのDITがサード・パーティのDITと同一になるように構成することをお薦めします。
