第 8 章   ディレクトリの設計例


企業の規模や業種によって、ディレクトリの設計方法は異なります。この章では、さまざまに設定を想定したディレクトリの導入例を紹介します。この章の例を利用して、独自のディレクトリの導入計画を立てることができます。

この章では、次のような組織にディレクトリを導入する際の設計例を紹介します。

• 一般企業

• 多国籍企業およびそのエクストラネット

一般企業

---

自動車部品の製造業者である siroe.com 社は、社員 500 人の小規模な会社です。siroe.com 社は、Directory Server を導入して、現在のディレクトリ対応アプリケーションをサポートすることを決定しました。siroe.com 社のディレクトリの設計過程を、次の設計段階ごとに説明します。

• 「データの設計」

• 「スキーマの設計」

• 「ディレクトリツリーの設計」

• 「トポロジの設計」

• 「レプリケーションの設計」

• 「セキュリティの設計」

• 「チューニングと最適化」

• 「運用に関する決定」

データの設計

siroe.com 社が最初に行うのは、ディレクトリに格納するデータのタイプの特定です。そのために、siroe.com 社は、導入チームを編成して、これからのディレクトリの使用状況を決定するサイト調査を実施します。導入チームは、次の事項を決定しました。

• ディレクトリにユーザとグループの情報を保持し、全社的に導入されている iPlanet サーバベースのイントラネットをサポートする。ユーザとグループの情報のほとんどを、ディレクトリの管理者グループが集中的に管理する。ただし、電子メールの情報は別のメールの管理者グループが管理する

• ディレクトリを、iPlanet Messaging Server、iPlanet Web Server、iPlanet Calendar Server、人事管理アプリケーション、および個人別電話帳アプリケーションで使用する

• iPlanet Messaging Server では、uid、mailServerName、mailAddress などの属性に対して完全一致検索を行う。データベースの性能を向上させるために、siroe.com 社は iPlanet Messaging Server で検索をサポートするこれらの属性のインデックスを管理する

  インデックスの使用については、「インデックスを使用したデータベース性能の向上」を参照してください。

• 個人別電話帳アプリケーションでは、ユーザ名と電話番号が頻繁に検索される。そのため、ディレクトリは、大量の検索結果を返す、膨大な数の部分文字列検索、ワイルドカード検索、および近似 (音による) 検索を処理できなければならない。そのためsiroe.com 社では、dn、sn、および givenName の各属性に対して近似インデックスと部分文字列インデックスを使用する

• 将来、s/mime 電子メールなどの公開鍵インフラストラクチャ (PKI) アプリケーションをサポートする予定なので、ディレクトリ内にユーザの公開鍵証明書を格納できるように準備する

スキーマの設計

siroe.com 社の導入チームは、ディレクトリ内のエントリを表すために inetOrgPerson オブジェクトクラス (object class) を使用することを決定しました。このオブジェクトクラスを使用するのは、siroe.com 社のディレクトリでサポートされるアプリケーションが必要とするuserCertificate と uid(userID) 属性の両方を使用できるためです。

また、siroe.com 社はデフォルトのディレクトリスキーマ (schema) をカスタマイズしたいと考えています。siroe.com 社は、自社の社員を表すために siroePerson オブジェクトクラスを作成します。このオブジェクトクラスは、inetOrgPerson オブジェクトクラスから派生させます。

siroePerson オブジェクトクラスでは、 siroeID 属性だけを使用できるようにします。この属性には、siroe.com 社の各社員に割り当てられている特別な社員番号が含まれます。

siroe.com 社は将来、必要に応じて、新しい属性を siroePerson オブジェクトクラスに追加することができます。

ディレクトリツリーの設計

siroe.com 社は、次のようにディレクトリツリー (directory tree) を作成します。

• ディレクトリツリーのルートを、siroe.com 社のインターネットドメインである dc=siroe,dc=com に設定する

• ディレクトリツリーに、ou=people、ou=groups、ou=roles 、およびou=resources の 4 つの分岐点を持たせる

• 全社員のエントリを、ou=people 分岐の下に作成する

  社員のエントリはすべて、person、organizationalPerson、inetOrgPerson、および siroePerson の各オブジェクトクラスのメンバーになります。uid 属性は、各エントリの DN を一意に識別します。たとえば、siroe.com 社のエントリには Babs Jensen 用のエントリ (uid=bjensen) と Emily Stanton 用のエントリ (uid=estanton) が含まれます。

• 営業、マーケティング、経理の各部署に 1 つずつ、計 3 つのロールを作成する

  各ユーザエントリに、ユーザが所属する部署を特定するロール (role) 属性を追加します。これにより、これらのロールに基づいて ACI を作成できます。ロールについては、「管理されているロール、フィルタを適用したロール、入れ子のロール」を参照してください。

• ou=groups 分岐の下に 2 つのグループの分岐を作成する

  最初のグループ cn=administrators に、ディレクトリの内容を管理するディレクトリ管理者用のエントリを追加します。

  メール管理者は、2 番目のグループ cn=messaging admin を使用して、メールアカウントを管理します。このグループは、iPlanet Messaging Server で使用する管理者グループと対応させます。siroe.com 社では、Messaging Server 用に構成するグループと Directory Server 用に作成するグループを、別々のグループにします。

• 会議室用 (ou=conference rooms) とオフィス用 (ou=offices) にそれぞれ 1 つずつ、計 2 つの分岐を ou=resources 分岐の下に作成する

• エントリが管理者グループに属するかどうかによって、異なる値を mailquota 属性に提供する CoS (サービスクラス (Class of Service)) を作成する

  この CoS によって、管理者には 500M バイトのメールサイズが、一般社員には 100M バイトのメールサイズが割り当てられます。CoS については、「サービスクラス」を参照してください。

次の図に、上記の設計ステップの結果として作成されたディレクトリツリーを示します。

図 8-1    siroe.com 社のディレクトリツリー

トポロジの設計

次に、siroe.com 社はデータベーストポロジとサーバトポロジの両方を設計します。次に、各トポロジ (topology) について詳しく説明します。

データベーストポロジ

siroe.com 社では、ユーザの分岐を 1 つのデータベース (DB1) に格納し、グループの分岐をもう 1 つのデータベース (DB2) に格納し、資源の分岐、ロールの分岐、およびルート接尾辞 (root suffix) の情報を 3 番目のデータベース (DB3) に格納するように、データベーストポロジを設計します。siroe.com 社のディレクトリのデータベーストポロジは、次のようになります。

図 8-2    siroe.com 社のデータベーストポロジ

サーバトポロジ

siroe.com 社が導入する Directory Server では、2 つのサプライヤ (supplier) サーバのそれぞれが 3 つのコンシューマ (consumer) サーバのすべてに対して、更新処理を実行します。これらのコンシューマは、iPlanet Data Access Router (iDAR) を使用して、1 つの iPlanet Messaging Server とそれ以外の Unified User Management 製品にデータを提供します。

iPlanet Unified User Management 製品については、http://www.iplanet.com/products/ を参照してください。

siroe.com 社のサーバトポロジは次のようになります。

図 8-3    siroe.com 社のサーバトポロジ

iPlanet のサーバ製品 (Calendar Server、Delegated Admin Server など) から送られた変更要求は、iDAR によって適切なコンシューマサーバに転送されます。コンシューマサーバはスマートレフェラルを使用して、変更されるデータのマスターコピーを保持するサプライヤサーバに要求を転送します。

レプリケーションの設計

siroe.com 社は、ディレクトリのデータが高い可用性を得るためにマルチマスターレプリケーション (multi-master replication) を使用することにします。マルチマスターレプリケーションについては、「マルチマスターレプリケーション」 を参照してください。

次に、サプライヤサーバのアーキテクチャとサプライヤサーバ / コンシューマサーバのトポロジについて詳しく説明します。

サプライヤのアーキテクチャ

siroe.com 社では、マルチマスターレプリケーションアーキテクチャで 2 つのサプライヤサーバを使用します。これらのサプライヤは、ディレクトリデータの整合性を維持するために、互いに更新を行います。サプライヤのアーキテクチャを次の図に示します。

図 8-4    siroe.com 社のサプライヤのアーキテクチャ

サプライヤ / コンシューマアーキテクチャ

siroe.com 社が導入するディレクトリで、サプライヤサーバから各コンシューマにレプリケーションが行われる方法を次の図に示します。

図 8-5    siroe.com 社のサプライヤ / コンシューマアーキテクチャ

図 8-5 に示すように、2 つのサプライヤサーバによって 3 つのコンシューマサーバがそれぞれ更新されます。これにより、1 つのサプライヤサーバが故障しても、コンシューマサーバは影響を受けずに済みます。

セキュリティの設計

siroe.com 社は、ディレクトリのデータを保護するために次のようなセキュリティの設計を決定しました。

• 社員が自分のエントリを変更できるような ACI を作成する

  ユーザは、uid、manager、および department 属性を除くすべての属性を変更できます。

• 社員データの機密性を保護するために、社員とその上司だけに社員の自宅の住所と電話番号の読み取り権限を与える ACI を作成する

• ディレクトリツリーのルートに、2 つの管理者グループに対して適切なディレクトリへのアクセス権を与える ACI を作成する

  ディレクトリの管理者グループは、ディレクトリへのフルアクセスを必要とします。メッセージングの管理者グループは、mailRecipient オブジェクトクラスと mailGroup オブジェクトクラス、これらのオブジェクトクラスに含まれている属性、および mail 属性への書き込みおよび削除権限を必要とします。また、siroe.com 社は、メッセージングの管理者グループがメールグループを作成できるように、グループのサブディレクトリへの write、delete、および add の各権限を与えます。

• ディレクトリツリーのルートに汎用的なアクセス制御を作成し、匿名アクセスに対して読み取り、検索、および比較の各権限を許可する

  この ACI では、匿名ユーザによるパスワード情報へのアクセスは拒否されます。

• サービス拒否攻撃および不正な使用からサーバを保護するために、ディレクトリクライアントがバインドに使用する DN に基づいて資源制限を設定する

  siroe.com 社では、検索要求の応答として受信するエントリ数を、匿名ユーザに 100 エントリまで、管理者ユーザに 1,000 エントリまで許可し、システム管理者には制限を加えません。ユーザのバインド DN に基づく資源制限の設定方法については、『iPlanet Directory Server 管理者ガイド』の「ユーザアカウントの管理」を参照してください。

• パスワードの長さを 8 文字以上に、パスワードの有効期限を 90 日に設定するパスワードポリシー (password policy) を作成する

  パスワードポリシーについては、「パスワードポリシーの設計」を参照してください。

• 経理ロール (role) のメンバーにすべての給与関連情報へのアクセス権を与える ACI を作成する

チューニングと最適化

siroe.com 社では、導入するディレクトリを次の方法で最適化します。

• idsktune ユーティリティを実行する (Solaris 9 プラットフォームでは directoryserver idsktune を実行する)

  このユーティリティを使用すると、使用システムのパッチレベル、カーネル、およびシステムのネットワーク設定を簡単に確認できます。idsktune については、『iPlanet Directory Server インストールガイド』を参照してください。

• エントリとデータベースのキャッシュを最適化する

  siroe.com 社では、すべてのインデックスが確実に RAM に収まるように、エントリキャッシュを 2,000 エントリに設定し、データベースキャッシュを 250M バイトに設定して、サーバの性能を最適化します。

運用に関する決定

siroe.com 社では、ディレクトリの日々の運用に関して次を事項を決定しました。

• データベースを毎晩バックアップし、週に 1 度バックアップをテープに書き込む

• SNMP を使用してサーバの状態を監視する

  SNMP については、『iPlanet Directory Server 管理者ガイド』を参照してください。

• アクセスログを自動的にローテーションさせる

• エラーログを監視して、サーバが正常に動作しているかどうかを確認する

• アクセスログを監視して、インデックス付けが必要な検索を選別する

アクセスログ、エラーログ、および監査ログについては、『iPlanet Directory Server 管理者ガイド』の「サーバとデータベースアクティビティの監視」を参照してください。

多国籍企業およびそのエクストラネット

---

次に、siroe.com International 社のディレクトリインフラストラクチャを構築する例を示します。前述の例の siroe.com 社が大規模な多国籍企業に成長したと仮定します。ここで示す例では、siroe.com 社で作成したディレクトリ構造を元に、ディレクトリの設計を拡張して新しい要件を満たしていきます。

siroe.com International 社は、主要な 3 つの地域である米国、ヨーロッパ、およびアジアに拠点を持つ組織へと成長しました。社員数は20,000 人を超えており、社員はそれぞれ siroe.com International 社のオフィスがある国に住み、働いています。siroe.com International 社は、全社規模の LDAP ディレクトリを導入して、社内通信の改善、Web アプリケーションの開発と導入の簡素化、およびセキュリティと機密性の改善を行うことを決定しました。

国際企業向けのディレクトリツリーを設計する場合は、論理的にディレクトリエントリを収集する方法、データ管理をサポートする方法、および世界規模で複製を可能にする方法を決定する必要があります。

また、siroe.com International 社では、部品供給業者および取引先が使用できるエクストラネットも作成します。エクストラネットは、企業のイントラネットを外部のクライアントに対して拡張したものです。

次に、siroe.com International 社が多国籍ディレクトリサービスおよびエクストラネットを導入する過程を設計段階ごとに説明します。

• 「データの設計」

• 「スキーマの設計」

• 「ディレクトリツリーの設計」

• 「トポロジの設計」

• 「レプリケーションの設計」

• 「セキュリティの設計」

データの設計

siroe.com International 社では、導入チームを編成して、サイト調査を実施します。導入チームは、サイト調査によって次の事項を決定しました。

• ほとんどのサイトで、iPlanet Messaging Server を使用して、電子メールの経路指定、配信、および閲覧サービスを提供する。企業サーバを使用して、文書公開サービスを提供する。すべてのサーバを、Solaris UNIX オペレーティングシステム上で稼働させる

• ローカルでもデータ管理ができるようにする。たとえば、ヨーロッパのサイトは、ディレクトリ内のヨーロッパの分岐を管理する責任がある。これは、ヨーロッパのサイトが、そのサイトに保管されているデータのマスターコピーに対しても責任を持つことを意味する

• オフィスが地理的に広い地域に分散しているため、ユーザとアプリケーションからは 1 日に 24 時間ディレクトリを利用できる必要がある

• 多くのデータ要素は、複数の言語と文字セットで表現されるデータ値を格納する必要がある

導入チームは、エクストラネットのデータ設計に関して次の事項を決定しました。

• 供給業者が siroe.com International 社のディレクトリにログインして、siroe.com International 社との契約を管理できるようにする。供給業者は、名前やパスワードなど認証に使用するデータ要素に依存する

• siroe.com International 社の取引先が、ディレクトリを使用して、取引先のネットワークで電子メールアドレスと電話番号を検索できるようにする

スキーマの設計

siroe.com International 社は、エクストラネットをサポートするスキーマ要素を追加することにより、元のスキーマの設計を拡張します。そのため、siroeSupplier オブジェクトクラスと siroePartner オブジェクトクラスの 2 つの新しいオブジェクトを追加します。

siroeSupplier オブジェクトクラスでは、siroeSupplierID 属性だけを使用できます。この属性には、siroe.com International 社が取引先である各自動車部品供給業者に割り当てた一意の ID が含まれます。

siroePartner オブジェクトクラスでは、siroePartnerID 属性だけを使用できます。この属性には、siroe.com International 社が各取引先に割り当てた一意の ID が含まれます。

デフォルトのディレクトリスキーマのカスタマイズ方法については、「スキーマのカスタマイズ」を参照してください。

ディレクトリツリーの設計

siroe.com International 社は、次のようにディレクトリツリーを作成します。

• ディレクトリツリーのルート接尾辞を dc=com にする。この接尾辞の下に 2 つの分岐を作成する。分岐の 1 つ dc=siroeCorp,dc=com には、siroe.com International 社の社内データを入れる。もう 1 つの分岐 dc=siroeNet,dc=com には、エクストラネットのデータを入れる

• イントラネットのディレクトリツリー (dc=siroeCorp,dc=com の下) には、3 つの主な分岐を作成する。各分岐は、siroe.com International 社のオフィスがある地域と対応させる。これらの分岐は、l(locality) 属性を使用して識別する

• dc=siroeCorp,dc=com の下の各分岐は、siroe.com 社に元からあったディレクトリツリーの設計と同じにする。siroe.com International 社は、各地域分岐の下に 、ou=people、ou=groups、ou=roles、および ou=resources の各分岐を作成する。ディレクトリツリーの設計については、「siroe.com 社のディレクトリツリー」を参照

• dc=siroeNet,dc=com 分岐の下に 3 つの分岐を作成する。供給業者用に 1 つの分岐 (o=suppliers)、取引先用に 1 つの分岐 (o=partners)、グループ用に 1 つの分岐 (ou=groups) を作成する

• エクストラネットの ou=groups 分岐には、エクストラネットの管理者用のエントリだけでなく、取引先が参加する、自動車部品の製造に関する最新情報を提供するメーリングリストも入れる

この結果、次のような基本的なディレクトリツリーが作成されます。

図 8-6    siroe.com International 社の基本的なディレクトリツリー

siroe.com International 社のイントラネット用のディレクトリツリーは、次のようになります。

図 8-7    siroe.com International 社のイントラネット用のディレクトリツリー

l=Asia エントリは、LDIF では次のようなエントリとして表示されます。

dn: l=Asia,dc=siroeCorp,dc=com
objectclass: top
objectclass: locality
l: Asia
description: includes all sites in Asia

siroe.com International 社のエクストラネット用のディレクトリツリーは、次のようになります。

図 8-8    siroe.com International 社のエクストラネット用のディレクトリツリー

トポロジの設計

次に、siroe.com International 社はデータベーストポロジとサーバトポロジの両方を設計します。以下に、各トポロジについて詳しく説明します。

データベーストポロジ

siroe.com International 社の主要な拠点の 1 つである、ヨーロッパ支社のデータベーストポロジを次の図に示します。

図 8-9    siroe.com International 社のヨーロッパ支社のデータベーストポロジ

データベースリンクは、各国でローカルに格納しているデータベースをポイントします。たとえば、siroe.com International 社のヨーロッパ支社のサーバが受信した、l=US 分岐の下にあるデータ対して行われた操作要求は、データベースリンク (database link) によってテキサス州オースティンにあるサーバ上のデータベースに連鎖されます。データベースリンクと連鎖 (chaining) については、「連鎖の使用方法」を参照してください。

図 8-9 の点線が示すように、dc=siroeCorp,dc=com にあるデータのマスターコピーとルートエントリの dc=com は、ヨーロッパで保持されています。

ヨーロッパのデータセンターには、エクストラネットのデータのマスターコピーが保管されています。エクストラネットのデータは、主要な分岐にそれぞれ 1 つずつ配置されている 3 つのデータベースに格納されています。エクストラネットのデータベーストポロジを次の図に示します。

図 8-10    siroe.com International 社のエクストラネット用のデータベーストポロジ

図 8-10 に示すように、o=suppliers にあるデータのマスターコピーはデータベース 1 に、o=partners にあるデータのマスターコピーはデータベース 2 に、ou=groups にあるデータのマスターコピーはデータベース 3 に、それぞれ格納されています。

サーバトポロジ

siroe.com International 社では、企業内イントラネット用と、取引先との間で使用するエクストラネット用に、それぞれ 1 つずつ、計 2 つのサーバトポロジを構築します。

siroe.com International 社では、イントラネット用に、主要な拠点がそれぞれマスターデータベースを保持することにします。これはイントラネット用に 3 つのデータセンターが存在することを意味し、各データセンターには 2 つのサプライヤサーバ、2 つのハブサーバ、および 3 つのコンシューマサーバが配置されます。

siroe.com International 社のヨーロッパ支社にあるデータセンターのアーキテクチャは、次のようになります。

図 8-11    siroe.com International 社のヨーロッパ支社のサーバトポロジ

エクストラネットのデータマスターは、ヨーロッパに置きます。このデータは、米国にあるデータセンターの 2 つのコンシューマサーバと、アジアにあるデータセンターの 2 つのコンシューマサーバに複製されます。つまり、siroe.com International 社ではエクストラネットをサポートするために 10 台のサーバが必要です。

siroe.com International 社のエクストラネット用サーバのアーキテクチャは、ヨーロッパ支社のデータセンターからは次のように見えます。

図 8-12    siroe.com International 社のエクストラネット用のサーバトポロジ

データは、ハブサーバによって、ヨーロッパ支社のデータセンターにある 2 つのコンシューマサーバ、米国支社のデータセンターにある 2 つのコンシューマサーバ、アジア支社のデータセンターにある 2 つのコンシューマサーバにレプリケーションされます。

レプリケーションの設計

siroe.com International 社は、次の事項を考慮してディレクトリのレプリケーションを設計します。

• データはローカルで管理する

• ネットワークの接続の品質は、サイトによって異なる

• データベースリンクを使用して、リモートサーバ上のデータに接続する

• データの読み取り専用コピーが格納されているハブサーバは、データをコンシューマサーバに複製するのに使用する

ハブサーバは、メールサーバや Web サーバなどの重要なディレクトリ対応アプリケーションの近くに配置します。

ハブサーバは、サプライヤサーバから複製に伴う負荷を取り除きます。そのため、サプライヤは、書き込み処理に集中できます。将来 siroe.com International 社が発展し、コンシューマサーバを追加する必要が生じても、追加したコンシューマがサプライヤの性能に影響を与えることはありません。

ハブサーバについては、「カスケード型レプリケーション」を参照してください。

サプライヤのアーキテクチャ

siroe.com International 社のイントラネットでは、各拠点で自分が所有するデータのマスターコピーを保持し、データベースリンクを使用してほかの拠点のデータに連鎖しています。各拠点では、所有するデータのマスターコピーについては多重マスター複製アーキテクチャを使用します。たとえば、dc=siroeCorp,dc=com と dc=com の情報が置かれているヨーロッパのサプライヤのアーキテクチャは次のようになります。

図 8-13    siroe.com International 社のヨーロッパ支社のサプライヤのアーキテクチャ

各拠点には、そのサイトのデータのマスターコピーを共有する 2 つのサプライヤを配置します。したがって、各拠点は自分が所有するデータのマスターコピーに責任を持つことになります。多重マスターアーキテクチャを使用することで、ローカルでのデータの利用が保証され、各サプライヤサーバの管理業務にかかる負荷を均等にすることができます。

ディレクトリ全体が機能しなくなる危険を避けるため、siroe.com International 社では各サイトでマルチマスターディレクトリサーバを使用します。

ヨーロッパにある 2 つのサプライヤサーバと米国にある 2 つのサプライヤサーバとの間の相互動作を次の図に示します。

図 8-14    siroe.com International 社のヨーロッパ支社と米国支社用のサプライヤ対サプライヤのアーキテクチャ

図 8-14 で示したのと同じ関係が、米国支社とアジア支社の間、ヨーロッパ支社とアジア支社の間にも存在します。

セキュリティの設計

siroe.com International 社では、新しい多国籍イントラネットをサポートするために次のアクセス制御を追加して、既存のセキュリティ設計を拡張しています。

• 汎用的な ACI をイントラネットのルートに追加して、制限の厳しい ACI を各国の分岐点とその下の分岐に作成する

• マクロ ACI を使用して、ディレクトリ内の ACI の数を最小限にとどめる

  マクロを使用して、ターゲットの DN および ACI のバインド規則部分を表します。ディレクトリが着信 LDAP 操作を受信すると、その LDAP 操作の対象となる資源と ACI マクロがマッチするかどうかが調べられます。マッチした場合、マクロは対象となる資源の DN の値に置き換えられます。

  マクロ ACI については、『iPlanet Directory Server 管理者ガイド』を参照してください。

siroe.com International 社では、次のアクセス制御を追加してエクストラネットをサポートしています。

• エクストラネットのすべての処理について、証明書に基づく認証を使用することを決定した。ユーザがエクストラネットにログインするときに、デジタル証明書が必要になる。証明書の格納にディレクトリを使用する。ディレクトリに証明書が格納されるので、ユーザはディレクトリに格納されている公開鍵を検索することで暗号化した電子メールを送信できる

• エクストラネットへの匿名アクセスを禁止する ACI を作成する。これにより、サービス拒否攻撃からエクストラネットを保護できる

• siroe.com International 社のディレクトリデータへの更新は、siroe.com International 社がホストしているアプリケーションから送られたもの以外は許可しない。つまり、エクストラネットを使用する取引先と供給業者は、siroe.com International 社が提供するツールしか使用できないようにする。エクストラネットのユーザが使用するツールを siroe.com International 社が許可したものに制限することにより、siroe.com International 社の管理者は監査ログを使用してディレクトリの利用状況を追跡することができ、siroe.com International 社以外のエクストラネットユーザが引き起こす問題を限定することができる

• iDAR を使用してセキュリティを強化する。iDAR については、http://www.iplanet.com/ を参照