第 2 章ディレクトリデータの計画とアクセス

ディレクトリに格納されるデータには、ユーザー名、電子メールアドレス、電話番号、ユーザーが所属するグループの情報が含まれ、それ以外の種類の情報が含まれる場合もあります。ディレクトリ内のデータのタイプによって、ディレクトリの構成方法、データへのアクセスが可能なユーザー、およびアクセスの要求方法と応答方法が決まります。Directory Server では、LDAP または DSML 経由でディレクトリデータにアクセスできるので、データと直接やり取りを行えるアプリケーションのタイプが広がります。

この章では、ディレクトリデータの計画とアクセスに関連する問題点と手法について説明します。この章は、次の節で構成されています。

ディレクトリデータの概要

データのタイプには、ディレクトリに適しているものとそうでないものがあります。ディレクトリに入れるのに最適なデータには、次のような特性があります。

たとえば、ある社員のアプリケーションの環境設定は、そのアプリケーションだけがこの情報にアクセスできればよいため、ディレクトリには適しません。ただし、このアプリケーションにディレクトリから環境設定を読み込む機能がある場合は、環境設定情報をディレクトリに入れておくと、別のサイトでそのアプリケーションを使用するときに自分の環境設定をディレクトリから読み込めるので便利です。

ディレクトリに格納できるデータ

電話番号、住所、電子メールアドレスなどの連絡先情報

社員番号、役職、管理者 ID、業務に関する利害関係などの記述的な情報

電話番号、住所、管理者 ID、業務についての説明などの組織の連絡先情報

プリンタの設置場所、プリンタの機種、プリンタの印刷速度などの機器に関する情報

会社の取引先、得意先、顧客などの連絡先情報と明細書情報

顧客名、期限、作業内容、価格情報などの契約情報

ユーザーのソフトウェアの環境設定情報や設定情報

Web サーバーへのポインタ、特定のファイルやアプリケーションのファイルシステムなどのリソースの場所

サーバー管理データとは別に、ディレクトリに次のような情報を格納することもできます。

ディレクトリに含めないデータ

Directory Server は、クライアントアプリケーションが読み取りや書き込み (頻繁ではない) を行う膨大な量のデータを管理するには適していますが、画像やほかのメディアなど、構造化されていない大きなオブジェクトを処理するようには設計されていません。このようなオブジェクトは、ファイルシステムで管理する必要があります。ただし、FTP、HTTP、またはその他の URL タイプを使用して、このようなタイプのアプリケーションへのポインタをディレクトリに格納することはできます。

Directory Server は読み取り操作で効果を発揮するので、頻繁に更新させる情報はディレクトリに入れないようにします。書き込み操作の回数を減らすことにより、検索処理全体のパフォーマンスが向上します。

データ要件の定義

ディレクトリデータを設計するときは、現在必要なデータだけでなく、将来含める可能性のあるデータも考慮に入れてください。設計の段階で将来ディレクトリに必要となる要件を考慮することが、データを拡張したり分散させる際に影響します。

現時点でどのようなデータをディレクトリに入れるか。ディレクトリの配備により解決したい当面の問題は何か。使用するディレクトリ対応アプリケーションですぐに必要となるデータは何か

近い将来どのようなデータをディレクトリに入れるか。たとえば、使用している会計パッケージが現時点では LDAP に対応していないが、近い将来 LDAP または DSML に対応することがわかっている場合など。この場合、アプリケーションで使用するデータを判別しておき、その機能が利用可能になったときに、データをディレクトリに移行するようにする

将来ディレクトリに格納する可能性のあるデータがあるか。たとえば、ホスト環境の場合、新しい顧客が現在の顧客とは異なるデータを要求することも考えられる。新しい顧客が、JPEG 画像の格納にディレクトリを使用する可能性もある。少なくとも、このような方法で計画を行なっていれば、ほかの方法では思いつかなかったデータソースを特定するのに役立つ

サイト調査の実施

サイト調査は、ディレクトリの内容を調べ、その特性を把握するための適切な手法です。ディレクトリアーキテクチャで重要なのはデータです。サイト調査には十分な時間をかけてください。サイト調査では次の作業を行います。ここではそれぞれについて簡単に説明し、詳細については後述します。

クライアントアプリケーションにどの程度までディレクトリデータの利用を許可するかを決定し、それに応じてアーキテクチャを設計します。ディレクトリデータをどの程度まで利用可能にするかによって、データのレプリケート方法や、リモートサーバーに格納されているデータに接続するための連鎖ポリシーの設定が変わってきます。

アプリケーションについては、第 6 章「レプリケーションについての理解」を参照してください。連鎖については、第 5 章「分散、連鎖、およびリフェラル」を参照してください。

ほかのソースからデータをインポートする場合は、一括インポートと増分更新について計画を立てます。この手法の一環として、どのデータについてもマスターは 1 か所に配置し、そのデータを変更できるアプリケーションの数を制限します。また、データに書き込みを行えるユーザーの数も制限します。このグループのメンバー数が少ないほど、データの整合性が確保でき、管理に伴うオーバーヘッドを軽減できます。

多くの組織がディレクトリによって影響を受けるため、影響のある各組織からの代表者によるディレクトリ導入チームを編成することをお勧めします。このチームでサイト調査を実施します。

会社は一般に、人事、経理、製造 (1 つまたは複数)、営業 (1 つまたは複数)、開発 (1 つまたは複数) などの部署から形成されています。これらの各組織からの代表者をチームに加えると、調査を迅速に進めることができます。また、影響を受けるすべての組織が直接参加することで、部署ごとのローカルデータ保管から、ディレクトリによる集中化されたデータ管理へ移行しやすくなります。

クライアントアプリケーションの識別

一般的に、ディレクトリにアクセスするアプリケーションと、それらのアプリケーションで必要となるデータが、ディレクトリの内容を決定する主な原因となります。ディレクトリを使用する一般的なアプリケーションには、次のアプリケーションが含まれます。

White pages などのディレクトリブラウザアプリケーション。これらのアプリケーションは、通常は電子メールアドレス、電話番号、社員名などの情報にアクセスします。

メッセージングアプリケーション、特に電子メールサーバー。すべての電子メールサーバーは、電子メールアドレス、ユーザー名、およびルーティング情報を必要とします。サーバーの中には、ユーザーのメールボックスが格納されているディスク上の格納場所、休暇通知情報、およびプロトコル情報 (たとえば、IMAP や POP) など、さらに高度な情報を必要とするものもあります。

ディレクトリ対応の人事管理アプリケーション。このアプリケーションは、政府指定の ID 番号、自宅の住所、自宅の電話番号、生年月日、給与明細、役職など、個人に関する詳細な情報を必要とします。

セキュリティ、Web ポータル、個人化用アプリケーション。これらのアプリケーションは、プロファイル情報にアクセスします。

ディレクトリを使用するアプリケーションを調査するときは、各アプリケーションが使用する情報のタイプに注目します。次の表に、アプリケーションと各アプリケーションが使用する情報の例を示します。

表 2-1 アプリケーションが必要とするデータ
アプリケーション	データクラス	データ
電話帳	people	名前、電子メールアドレス、電話番号、ユーザー ID、パスワード、部署番号、マネージャ、メールの配信停止
Web サーバー	people、groups	ユーザー ID、パスワード、グループ名、グループのメンバー、グループの所有者
Calendar Server	people、meeting rooms	名前、ユーザー ID、広さ、会議室の名前
Web ポータル	people、groups	ユーザー名、ユーザー ID、パスワード、グループ名、グループのメンバー

アプリケーションおよび各アプリケーションが使用する情報を特定すると、いくつかのタイプのデータが複数のアプリケーションによって使用されていることがわかってきます。データの計画段階でこのような課題に取り組むことで、ディレクトリ内のデータが重複する問題を避けることができます。

ディレクトリ内で管理されるデータと、その管理が開始される時期は、次のことに影響されます。

データソースの特定

ディレクトリに含まれているデータを特定するには、既存のデータソースを調査します。調査では、次の作業を行います。

調査中に、次の表のような雛形を用意して、企業内の情報ソースをすべて特定しておくことをお勧めします。

表 2-2 情報ソース
データソース	データクラス	データ
人事管理データベース	people	名前、住所、電話番号、部署番号、マネージャ
電子メールシステム	people、groups	名前、電子メールアドレス、ユーザー ID、パスワード、電子メールの環境設定
設備システム	Facilities	建物の名前、フロアの名前、広さ、アクセスコード

ディレクトリデータの特徴づけ

特定するデータは、次のように特徴づけることができます。

ディレクトリに含める計画のある各データをよく調査して、ほかのデータと共通している特徴を明確にします。これにより、第 3 章「Directory Serverスキーマ」で説明しているスキーマの設計段階で、時間を節約することができます。

たとえば、ディレクトリデータの特徴を記載した次のような表を作成することができます。

表 2-3 ディレクトリデータの特徴
データ	形式	サイズ	所有者	関連するエントリ
社員の名前	テキストの文字列	128 文字	人事	ユーザーエントリ
ファックス番号	電話番号	14 桁の数字	ファシリティ	ユーザーエントリ
電子メールアドレス	テキスト	多くの文字	情報システム部	ユーザーエントリ

ディレクトリの可用性要件の特定

提供するサービスの可用性のレベルは、ディレクトリ対応のアプリケーションを利用するユーザーが必要とするサービスによって決まります。アプリケーションで必要なサービスレベルを決定するには、まずそのアプリケーションがいつどのように使用されているかを確認します。

ディレクトリの利用が進むにつれて、さまざまなサービスレベルをサポートする必要が出てきます。ディレクトリの導入後にサービスレベルを上げることは困難なので、将来の要件にも対応できる設計を初期の段階から心がけるようにしてください。

データマスターサーバーの特定

データマスターは、データのプライマリソースになるサーバーです。データセンターの物理的な位置が複数ある場合は、データのマスターを置くサーバーと、そのデータのマスターから更新を受け取るサーバーを決定する必要があります。

レプリケーション時のデータマスターの作成

レプリケーションを使用する場合は、どのサーバーをデータのマスターソースにするかを決定します。Directory Server では、複数のサーバーが同じデータのマスターとなることができるマルチマスター設定がサポートされています。レプリケーションとマルチマスターレプリケーションについては、第 6 章「レプリケーションについての理解」を参照してください。

もっとも単純な構成では、すべてのデータのマスターソースを 2 つの Directory Server に置き、そのデータを 1 台または複数のコンシューマサーバーにレプリケートするようにします。2 つのマスターサーバーがあれば、1 つのサーバーが故障してオフラインになったときにフェイルオーバーが実行されます。より複雑な構成では、データを複数のデータベースに格納し、データの更新または検索を行うアプリケーションの近くにあるサーバーが、エントリのマスターを作成するようにします。

複数アプリケーションにわたるデータマスターの作成

ディレクトリと間接的に通信するアプリケーションがある場合には、データのマスターソースについても考慮する必要があります。このような場合は、データの変更処理と、データ変更を実行する場所とを、できる限り単純に保ちます。単一のサイトでデータのマスターを作成することにした場合は、同じサイトでそこに含まれているほかのすべてのデータのマスターを作成します。このようにマスターの作成先を単一のサイトにしておくと、企業内でデータベースの同期がとれなくなった場合の障害追跡が簡単になります。

マルチマスターを管理する場合は、ディレクトリやその他のアプリケーションとの間でデータをやり取りするためのカスタムスクリプトは必要ありません。ただし、1 か所でデータが変更されると、ほかのすべてのサイトでもデータを変更する必要があります。ディレクトリおよびそのディレクトリを使用しないすべてのアプリケーションでマスターデータを管理すると、企業全体のデータが同期しなくなることがあります (このような状態をディレクトリが回避しようとする)。

さまざまなディレクトリ対応アプリケーションやデータベースアプリケーションを使用している場合は、ほかのアプリケーションと同期をとるデータマスターを管理する方法がもっとも合理的です。Meta Directory については、Sun Java System 製品の販売店にお問い合わせください。

ディレクトリ以外のアプリケーションでデータマスターを作成してから、そのデータをディレクトリにインポートするスクリプト、プログラム、またはゲートウェイを作成する

すでに使用しているアプリケーションの中にデータマスターを作成できるものが 1 つまたは 2 つあり、ディレクトリを検索の目的 (オンラインの企業電話帳など) にのみ使用する場合は、ディレクトリ対応以外のアプリケーションでデータマスターを作成する方法がもっとも合理的です。

データのマスターコピーの管理方法は、個々の要件によって異なります。ただし、どのような管理方法を選択しても、簡単で一貫性のあるものにしてください。たとえば、複数のサイトでデータマスターを作成し、競合するアプリケーション間で自動的にデータを交換するようなことは避けてください。そのような方法では、「最新の変更が優先される」ことになり、管理に伴うオーバーヘッドが増大します。

ある社員の自宅の電話番号を管理する場合を考えてみます。この情報は、LDAP ディレクトリと人事 (HR) データベースの両方に格納されています。HR データベースは LDAP 対応なので、LDAP ディレクトリと HR データベースの間で自動的にデータを転送するアプリケーションを作成することができます。ここで、電話番号への変更を LDAP ディレクトリと HR データベースの両方でマスタリングすると、最後に変更した電話番号のデータが、もう一方のデータベースの情報を上書きしてしまいます。これは、最後にデータを書き込んだアプリケーションが正しい情報を持っている場合には、適切な処理です。ところが、この情報が古い場合 (たとえば、HR データがバックアップから再読み込みされたものである場合など) は、LDAP ディレクトリ内の正しい電話番号が削除されてしまいます。

データ所有者の決定

「データ所有者」とは、データを最新の状態に維持する責任のある個人または組織のことです。データの設計時に、ディレクトリにデータを書き込めるユーザーを決めておきます。データの所有者を決めるには、一般に次の規則に従います。

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

ロールとエントリのグループ化については、第 4 章「ディレクトリ情報ツリー」を参照してください。

データに書き込みを許可するユーザーを決定するときに、複数のユーザーに対して同じデータへの書き込み権限が必要になることがあります。たとえば、社員のパスワードへの書き込み権限を、情報システムまたはディレクトリ管理グループに許可するとします。同時に、社員にも自分のパスワードへの書き込み権限を許可する場合があります。複数のユーザーに同じ情報への書き込み権限を与えなければならない場合がありますが、このような場合はこのグループを少人数に保ち、容易に識別できるようにします。グループを少人数に保つことにより、データの整合性を維持しやすくなります。

データアクセスの決定

データ所有者を決定したら、各データを読み取ることができるユーザーを決定します。たとえば、ある社員の自宅の電話番号をディレクトリに保存することにした場合を考えてみます。このデータは、その社員の上司や人事部など、多くの組織にとって有用です。また、その社員自身が確認のためにこの情報を読み取れるようにしたい場合もあります。しかし、自宅の連絡先情報は機密事項とも考えられます。したがって、この種のデータを企業全体で広く利用可能にするかどうかを決定する必要があります。

ディレクトリに格納する各情報について、次の事項を決定します。

ディレクトリにログイン (あるいはバインド) しない限り、特定の情報を読み取れないようにアクセス制御を設定することができます。匿名アクセスとは異なり、この形式のアクセス制御では、ディレクトリの情報を閲覧できるユーザーを組織内のメンバーだけに限定できます。また、ログイン情報をディレクトリのアクセスログに取り込めるので、情報にアクセスしたユーザーの記録を残すことができます。

アクセス制御については、「アクセス制御の設計」を参照してください。

一般に、データへの書き込み特権を持つユーザーには読み取り権限も必要です (パスワードへの書き込み権限は例外)。また、特定の組織やプロジェクトグループだけが必要とするデータが存在することがあります。これらのアクセス要件を特定しておくと、ディレクトリで必要となるグループ、ロール、およびアクセス制御を決める際に役立ちます。

グループとロールについては、第 4 章「ディレクトリ情報ツリー」を参照してください。アクセス制御については、第 7 章「アクセス制御、認証、および暗号化」を参照してください。

ディレクトリの各データに対してこれらの事項を決定する際には、ディレクトリのセキュリティポリシーを定義していることが前提となります。これらの決定は、サイトの性質と、すでに利用可能なセキュリティのタイプによって異なります。たとえば、サイトにファイアウォールが使用されている場合や、インターネットに直接アクセスしていない場合は、インターネット上に直接ディレクトリを配置している場合に比べ、匿名アクセスをサポートしやすくなります。

多くの国では、データ保護に関する法律によって個人情報をどのように管理すべきかが規定されており、個人情報にアクセスする人を制限しています。たとえば、法律によって住所や電話番号への匿名アクセスが禁止されていたり、住所や電話番号を表すエントリ内の情報を閲覧、訂正する許可をユーザーに与えなければならない場合があります。社内の法務部に問い合わせて、ディレクトリの導入が、業務拠点としている国々の該当する法律に違反していないことを確認してください。

サイト調査の記録

データの設計は複雑なため、サイト調査の結果は文書に記録しておくことをお勧めします。サイト調査の各段階で、データを把握するための簡単な表を作成することをお勧めしました。決定事項と未解決の問題を概説する簡単な表を作成することを検討してください。

表 2-4 は、基本的なデータ追跡例を示しています。この表には、データ所有者と、サイト調査で特定した各データについてのデータアクセス権限が示されています。

表 2-4 サイト調査を記録するためのデータ追跡表の例
データ名	所有者	マスターサーバーアプリケーション	本人による読み取り / 書き込み	全員による読み取り	人事部 (HR) による書き込み	情報システム部 (IS) による書き込み
社員の名前	HR	PeopleSoft	読み取り専用	可 (匿名)	可	可
ユーザーパスワード	IS	Directory US-1	読み取り / 書き込み	不可	不可	可
自宅の電話番号	HR	PeopleSoft	読み取り / 書き込み	不可	可	不可
社員の所属場所	IS	Directory US-1	読み取り専用	可 (ログインが必要)	不可	可
会社の電話番号	ファシリティ	電話スイッチ	読み取り専用	可 (匿名)	不可	不可

サイト調査の繰り返し

サイト調査は数回実施した方が良い場合があります。特に、複数の都市や国にオフィスを持つ企業の場合は、これが当てはまります。情報に関する要件があまりにも複雑なため、中央のサイトで情報を一元的に管理するよりも、複数の組織がそれぞれの現地オフィスで情報を保管するようにしなければならない場合もあります。このような場合は、情報のマスターコピーを保管する各オフィスで、独自のサイト調査を実施するようにします。この過程の完了後、中央のチーム (各オフィスの代表者で構成される) に各調査結果が戻され、企業全体のデータスキーマモデルとディレクトリツリーの設計に使用します。

HTTP/SOAP 経由の DSML によるディレクトリデータへのアクセス

従来バージョンの Directory Server では、LDAP (Lightweight Directory Access Protocol) を使用してディレクトリデータにアクセスできました。Directory Server 5.2 では、HTTP/SOAP 経由の DSMLv2 (Directory Service Markup Language version 2) を使用してディレクトリデータにアクセスすることもできます。

DSMLv2 はマークアップ言語、つまり、ディレクトリサービスによるデータ処理の構造と内容を XML (eXtensible Markup Language) ドキュメントとして記述するためのボキャブラリとスキーマです。DSMLv2 は、XML でディレクトリサービス情報を表す方法を標準化します。Directory Server では、ハイパーテキスト転送プロトコル (HTTP/1.1) で DSMLv2 を使用できます。また、DSML の内容を転送するためのプログラミングプロトコルとして SOAP (Simple Object Access Protocol) バージョン 1.1 が使われます。

DSML フロントエンドの設定と、HTTP/SOAP 経由の DSMLv2 を使用したデータの検索については、『Directory Server 管理ガイド』の第 1 章にある「DSML の設定」を参照してください。

HTTP/SOAP 経由の DSMLv2 の配備

DSML 対応の Directory Server と Sun Java System Web Proxy Server を使用した次の配備例では、非 LDAP クライアントがディレクトリデータとやり取りできます。

この配備例では、非 LDAP クライアントアプリケーションからの DSML 形式の更新要求は、まず、HTTP ポート 80 でファイアウォールを通過し、非武装地帯 (DMZ) に入ります。ここから、逆プロキシサーバーとして設定された Directory Proxy Server は、セキュリティ保護された HTTP ポート 443 の使用を強制し、要求は第 2 のファイアウォールを越えてイントラネットドメインに入ります。要求は、DSML に対応していないコンシューマ C、D にレプリケートされる前に、2 つのマスターレプリカ Master A、B で処理されます。

このような配備により、非 LDAP アプリケーションでディレクトリの操作を実行することができます。クライアント要求が単なる検索要求の場合、DSML 対応の Directory Server は、データのコピーが読み取り専用であっても、読み書き両方に対応していても、どちらも検索要求を処理できるので問題ありません。しかし、非 LDAP クライアントが変更要求を送信する場合、DSML 対応 Directory Server は読み書きに対応したデータコピーを保持している必要があります。変更要求を受け取ったコンシューマは、デフォルトの設定では、クライアントの変更要求を正しく実行できる可能性のあるマスターの LDAP URL リストのリフェラルを返します。非 LDAP クライアントアプリケーションに対して HTTP 経由で LDAP URL を返しても、クライアントとディレクトリの間のトラフィックで LDAP を使用しないという目的を果たすことができません。このために読み書き両方に対応したコピーが必要なのです。図 2-1 の配備では、DSML 対応の Directory Server のマスター A、B は読み書き両方に対応したデータコピーを保持します。これらのマスターは、変更要求を処理し、DSML に対応していないコンシューマ C、D にデータをレプリケートします。

DSML フロントエンドは、アクセスを制限した HTTP サーバーを構築しています。このサーバーは、DSML HTTP ポスト処理だけを受け付け、SOAP/DSML 仕様に準拠していない要求を拒否します。これにより、その他の種類の HTTP Web サーバーと比較してリスクの範囲は狭められています。配備に DSML 対応の Directory Server を含めるときは、それでもなお次のセキュリティ上の注意点に留意する必要があります。

前へ目次索引次へ
Sun Java™ System Directory Server 5 2004Q2 配備計画ガイド