|
| Sun ONE Directory Server 5.2 配備ガイド |
ディレクトリに格納されるデータには、ユーザー名、電子メールアドレス、電話番号、ユーザーが所属するグループの情報が含まれ、それ以外の種類の情報が含まれる場合もあります。ディレクトリ内のデータのタイプによって、ディレクトリの構成方法、データへのアクセスが可能なユーザー、およびアクセスの要求方法と応答方法が決まります。Sun ONE Directory Server 5.2 では、LDAP または DSML 経由でディレクトリデータにアクセスできるので、アプリケーションがディレクトリデータと直接やり取りを行える可能性もあります。
この章では、ディレクトリデータの計画とアクセスに関連する問題点と手法について説明します。この章は、次の節から構成されます。
ディレクトリデータの概要
データのタイプには、ディレクトリに適しているものとそうでないものがあります。ディレクトリに入れるのに最適なデータには、次のような特性があります。
- 読み取り回数が書き込み回数より多い
ディレクトリは読み取り操作用に調整されているため、書き込み操作はサーバーのパフォーマンスを低下させます。
- 属性データの形式で表現できる (たとえば、surname=jensen)
- 多くのユーザーにとって重要である
たとえば、社員の名前やプリンタが実際に置かれている場所は、多くのユーザーやアプリケーションにとって重要です。
- 複数の場所からアクセスされる
たとえば、ある社員のアプリケーションの環境設定は、そのアプリケーションだけがこの情報にアクセスできればよいため、ディレクトリには適しません。ただし、このアプリケーションにディレクトリから環境設定を読み込む機能がある場合は、環境設定情報をディレクトリに入れておくと、別のサイトでそのアプリケーションを使用するときに自分の環境設定をディレクトリから読み込めるので便利です。
ディレクトリに格納できるデータ
次に、ディレクトリに格納できるデータの例を示します。
- 電話番号、住所、電子メールアドレスなどの連絡先情報
- 社員番号、役職、管理者 ID、業務に関する利害関係などの記述的な情報
- 電話番号、住所、管理者 ID、業務についての説明などの組織の連絡先情報
- プリンタの設置場所、プリンタの機種、プリンタの印刷速度などの機器に関する情報
- 会社の取引先、得意先、顧客などの連絡先情報と明細書情報
- 顧客名、期限、作業内容、価格情報などの契約情報
- ユーザーのソフトウェアの環境設定情報や設定情報
- Web サーバーへのポインタ、特定のファイルやアプリケーションのファイルシステムなどのリソースの場所
サーバー管理データとは別に、ディレクトリに次のような情報を格納することもできます。
- 契約や顧客アカウントに関する情報
- 給与データ
- 物理的なデバイス情報
- 自宅連絡先情報
- 企業のさまざまなサイトに関する職場連絡先情報
ディレクトリに含めないデータ
ディレクトリサーバーは、クライアントアプリケーションが読み取りや書き込み (頻繁ではない) を行う膨大な量のデータを管理するには適していますが、画像やほかのメディアなど、構造化されていない大きなオブジェクトを処理するようには設計されていません。このようなオブジェクトは、ファイルシステムで管理する必要があります。ただし、FTP、HTTP、またはその他の URL タイプを使用して、このようなタイプのアプリケーションへのポインタをディレクトリに格納することはできます。
ディレクトリは読み取り操作で効果を発揮するので、頻繁に更新させる情報はディレクトリに入れないようにします。ディレクトリで実行される書き込み操作の回数を減らすことにより、検索処理全体のパフォーマンスが向上します。
ディレクトリ要件の定義
ディレクトリデータを設計するときは、現在必要なデータだけでなく、将来含める可能性のあるデータも考慮に入れてください。設計の段階で将来ディレクトリに必要となる要件を考慮することが、ディレクトリデータを拡張したり分散させる際に影響します。
設計時には、次の点を考慮してください。
- 現時点でどのようなデータをディレクトリに入れるか。ディレクトリの配備により解決したい当面の問題は何か。使用するディレクトリ対応アプリケーションですぐに必要となるデータは何か
- 近い将来どのようなデータをディレクトリに入れるか。たとえば、使用している会計パッケージが現時点では LDAP に対応していないが、近い将来 LDAP または DSML に対応することがわかっている場合など。この場合、アプリケーションで使用するデータを判別しておき、その機能が利用可能になったときに、データをディレクトリに移行するようにする
- 将来ディレクトリに格納する可能性のあるデータがあるか。たとえば、ホスト環境の場合、新しい顧客が現在の顧客とは異なるデータを要求することも考えられる。新しい顧客が、JPEG 画像の格納にディレクトリを使用する可能性もある。これは予想される中でもっとも困難な場合であるが、考慮しておけば予想しなかった事態に対処できる可能性がある。少なくとも、このような方法で計画を行っていれば、ほかの方法では思いつかなかったデータソースを特定するのに役立つ
DSML による HTTP/SOAP 経由のディレクトリデータへのアクセス
ディレクトリデータへのアクセスに LDAP (Lightweight Directory Access Protocol) だけを使用する従来バージョンの Directory Server とは異なり、Sun ONE Directory Server 5.2 では、DSMLv2 (Directory Service Markup Language バージョン 2) を使用して HTTP/SOAP 経由でディレクトリデータにアクセスすることもできます。
DSMLv2 はマークアップ言語、つまり、ディレクトリサービスによるデータ処理の構造と内容を XML (eXtensible Markup Language) ドキュメントとして記述するためのボキャブラリとスキーマです。DSMLv2 は、XML でディレクトリサービス情報を表現する方法を標準化します。この標準を使用することで、DSMLv2 を使用し、ディレクトリサービスのスケーラビリティ、レプリケーション、セキュリティ、管理の各機能を強化したアプリケーションを記述することができます。DSMLv2 はアクセスプロトコルではありませんが、ディレクトリに格納されているデータへの実際のアクセスする上で、DSMLv2 はアクセスプロトコルに依存します。Directory Server は、HTTP/1.1 (Hypertext Transfer Protocol) 経由での DSMLv2 の使用、および DSML コンテンツを転送するためのプログラミングプロトコルとして SOAP 1.1 (Simple Object Access Protocol) の使用をサポートしています。
HTTP/SOAP 経由で DSMLv2 を使用してディレクトリにアクセスできるようになったため、アプリケーションは LDAP アプリケーションである必要がなくなり、ディレクトリとの間でデータをやり取りするアプリケーションの範囲にも変化がもたらされています。次に、HTTP/SOAP 経由の新しい DSMLv2 によるアクセスの可能性について詳細に説明します。DSMLv2 を使用して HTTP/SOAP 経由でデータにアクセスしたり、データを検索する方法については、付録 A 「DSMLv2 を使用した HTTP/SOAP 経由のデータへのアクセス」を参照してください。
HTTP/SOAP 経由の DSMLv2 の配備
DSML に対応した Directory Server と Sun ONE Web Proxy Server (非 LDAP クライアントがディレクトリデータを利用できます) を利用した配備の一例を図 2-1 に示します。
図 2-1 DSML 対応 Directory Server の配備例
非 LDAP クライアントアプリケーションからの DSML 形式の更新要求は、まず、HTTP ポート 80 でファイアウォールを通過し、非武装地帯に入ります。ここから、逆プロキシサーバーとして設定された Sun ONE Web Proxy Server は、セキュリティ保護された HTTP ポート 443 の使用を強制し、要求は第 2 のファイアウォールを越えてイントラネットドメインに入ります。要求は、DSML に対応していないコンシューマ C、D にレプリケートされる前に、2 つのマスターレプリカ Master A、B で処理されます。
この配備の主な目的は、非 LDAP アプリケーションがディレクトリ操作を行うことで、ディレクトリデータと通信できるようにすることです。クライアントからの要求が検索要求だけであれば、Directory Server に保持されているデータのコピーが読み取り専用であっても、読み書き両方に対応していても、どちらも検索要求を処理できるので問題ありません。しかし、非 LDAP クライアントが変更要求を送信する場合、DSML 対応 Directory Server は読み書きに対応したデータコピー (マスターレプリカ) を保持している必要があります。これはレプリケーションの特性で、変更要求を受け取るコンシューマ (読み取り専用のデータコピーを保持しています) は、デフォルトの設定では、クライアントからの変更要求を満足できる可能性のあるマスターの LDAP URL リストのリフェラルを返すためです。非 LDAP クライアントアプリケーションに対して HTTP 経由で LDAP URL を返しても意味がありませんし、クライアントとディレクトリの間のトラフィックで LDAP を使用しないという当初の目的を果たすことができません。このために読み書き両方に対応したコピーが必要なのです。図 2-1 の配備では、クライアントからの変更要求を処理する DSML 対応 Directory Server のマスター A、B は読み書き両方に対応したデータコピーを保持し、DSML に対応していないコンシューマ C、D にデータがレプリケートされます。
前述のように、HTTP/SOAP 経由の DSML アクセスにより XML および Web サービスでもディレクトリデータを利用できるようになりますが、それに応じてセキュリティ上のリスクも高まります。Directory Server の DSML フロントエンドは、DSML HTTP ポスト処理だけを受け付け、SOAP/DSML 仕様に準拠していない要求を拒否することで、アクセスを制限した HTTP サーバーを構築しています。これにより、その他の種類の HTTP Web サーバーと比較してリスクの範囲は狭められています。配備に DSML 対応 Directory Server を含めるときは、それでもなお次のセキュリティ上の注意点に留意することをお勧めします。
- ファイアウォールを実装して、DSML 対応 Directory Server を保護します。
- ポート 443 で SSL によってセキュリティ保護された HTTP を使用するか、クライアントで SSL 経由の HTTP を使用したくない場合は、Web プロキシサーバーを実装します。
サイト調査の実施
サイト調査は、ディレクトリの内容を調べ、その特性を把握するための適切な手法です。ディレクトリアーキテクチャで重要なのはデータです。サイト調査には十分な時間をかけてください。サイト調査では次の作業を行います。ここではそれぞれについて簡単に説明し、詳細については後述します。
- ディレクトリを使用するアプリケーションを特定する
導入するディレクトリ対応アプリケーションとそのデータ要件を決定します。
- アプリケーションがどのようにディレクトリにアクセスするかを特定する
アプリケーションが LDAP または HTTP/SOAP 経由の DSML のどちらのモードを使用するかを決定します。
- データソースを特定する
自社内を調査して、データの取得元 (Windows、NetWare ディレクトリ、PBX システム、人事部データベース、電子メールシステムなど) を確認します。
- ディレクトリに入れる必要があるデータの特性を把握する
ディレクトリに入れる必要のあるオブジェクト (ユーザーまたはグループなど) と、ディレクトリ内で管理するオブジェクトの属性 (ユーザー名やパスワードなど) を決定します。
- 提供すべきサービスレベルを決定する
クライアントアプリケーションにどの程度までディレクトリデータの利用を許可するかを決定し、それに応じてアーキテクチャを設計します。ディレクトリデータをどの程度まで利用可能にするかによって、データのレプリケート方法や、リモートサーバーに格納されているデータに接続するための連鎖ポリシーの設定が変わってきます。
レプリケーションについては、第 6 章「レプリケーションの設計」を参照してください。連鎖については、第 5 章「ディレクトリトポロジの設計」を参照してください。
- データマスターを特定する
データマスターには、ディレクトリデータのプライマリソースが含まれます。このデータは、ロードバランスと回復の目的のために、ほかのサーバーにコピーされている場合があります。各データについて、そのデータのマスターを特定します。
- データ所有者を決定する
各データについて、データを最新の状態に保つ責任のあるユーザーを決定します。
- データアクセスを決定する
ほかのソースからデータをインポートする場合は、一括インポートと増分更新の両方について計画を立てます。この手法の一環として、どのデータについてもマスターは一か所に配置し、そのデータを変更できるアプリケーションの数を制限します。また、データに書き込みを行えるユーザーの数も制限します。このグループのメンバー数が少ないほど、データの整合性が確保でき、管理に伴うオーバーヘッドを低減できます。
- サイト調査の結果を文書化する
多くの組織がディレクトリによって影響を受けるため、影響のある各組織からの代表者によるディレクトリ導入チームを編成することをお勧めします。このチームでサイト調査を実施します。
会社は一般に、人事、経理、製造 (1 つまたは複数)、営業 (1 つまたは複数)、開発 (1 つまたは複数) などの部署から形成されています。これらの各組織からの代表者をチームに加えると、調査を迅速に進めることができます。また、影響を受けるすべての組織が直接参加することで、部署ごとのローカルデータ保管から、ディレクトリによる集中化されたデータ管理へ移行しやすくなります。
- サイト調査の繰り返し
企業の事務所が複数ある場合は、事務所ごとにサイト調査を繰り返す必要があります。各事務所でサイト調査チームを作り、結果を中央のサイト調査チーム (各地の代表者で構成) に送ります。
ディレクトリ対応のアプリケーションの特定
一般的に、ディレクトリにアクセスするアプリケーションと、それらのアプリケーションで必要となるデータが、ディレクトリの内容を決定する主な原因となります。ディレクトリを使用する一般的なアプリケーションには、次のアプリケーションが含まれます。
- White pages などのディレクトリブラウザアプリケーション。これらのアプリケーションは、通常は電子メールアドレス、電話番号、社員名などの情報にアクセスします。
- メッセージングアプリケーション、特に電子メールサーバー。すべての電子メールサーバーは、ディレクトリで利用できる電子メールアドレス、ユーザー名、およびルーティング情報を必要とします。サーバーの中には、ユーザーのメールボックスが格納されているディスク上の格納場所、休暇通知情報、およびプロトコル情報 (たとえば、IMAP や POP) など、さらに高度な情報を必要とするものもあります。
- ディレクトリ対応の人事管理アプリケーション。このアプリケーションは、政府指定の ID 番号、自宅の住所、自宅の電話番号、生年月日、給与、役職など、個人に関する詳細な情報を必要とします。
- セキュリティ、Web ポータル、個人化用アプリケーション。これらのアプリケーションは、プロファイル情報にアクセスします。
ディレクトリを使用するアプリケーションを調査するときは、各アプリケーションが使用する情報のタイプに注目します。次の表に、アプリケーションと各アプリケーションが使用する情報の例を示します。
アプリケーションおよび各アプリケーションが使用する情報を特定すると、いくつかのタイプのデータが複数のアプリケーションによって使用されていることがわかってきます。データの計画段階でこのような課題に取り組むことで、ディレクトリ内のデータが重複する問題を避けることができ、ディレクトリを利用するアプリケーションが必要とするデータの特定に役立ちます。
ディレクトリで管理するデータのタイプと、そのデータの管理を開始する時期についての最終的な決定は、次の要因に影響されます。
- さまざまな旧バージョンのアプリケーションで必要とされるデータと、そのアプリケーションを使用するユーザーの数
- 旧バージョンのアプリケーションが LDAP ディレクトリと通信できるかどうか
アプリケーションがディレクトリにアクセスする方法の特定
非 LDAP アプリケーションが、ディレクトリ操作を行ってディレクトリデータをやり取りしなければならない場合は、HTTP/SOAP 経由の DSML によるディレクトリへのアクセスを検討してください。ただし、クライアントアプリケーションが LDAP アプリケーションであれば、LDAP アクセスを選択します。選択するアクセスモードは、どのアプリケーションがディレクトリにアクセスするかによって異なります。
データソースの特定
ディレクトリに入れるすべてのデータを調べるには、現存のデータの格納場所について、次のような調査を実施する必要があります。調査では、次の作業を行います。
- 情報を提供する組織を特定する
企業にとって重要な情報を管理している組織をすべて特定します。通常、この組織には、情報サービス部、人事部、および経理部が含まれます。
- 情報のソースであるツールとプロセスを特定する
一般的な情報ソースには、ネットワーク用のオペレーティングシステム (Windows、Novell Netware、UNIX NIS)、電子メールシステム、セキュリティシステム、PBX (電話交換) システム、人事管理アプリケーションなどがあります。
- データの集中化が各データに与える影響を判定する
集中データ管理では、新しいツールとプロセスが必要になることがあります。集中化によって、ある組織のスタッフを増員してほかの組織のスタッフを減らすことが必要になる場合は、問題が生じる可能性もあります。
調査中に、次の表のような雛形を用意して、企業内の情報ソースをすべて特定しておくことをお勧めします。
表 2-2 情報ソース
データソース
データクラス
データ
人事管理データベース
people
名前、住所、電話番号、部署番号、マネージャ
電子メールシステム
people、groups
名前、電子メールアドレス、ユーザー ID、パスワード、電子メールの環境設定
設備システム
facilities
建物の名前、フロアの名前、広さ、アクセスコード
ディレクトリデータの特徴づけ
ディレクトリに含めるために特定したすべてのデータは、次のような一般的な観点から特徴づけることができます。
- 形式
- サイズ
- さまざまなアプリケーションで使用される回数
- データ所有者
- ほかのディレクトリデータとの関係
ディレクトリに含める計画のある各データをよく調査して、ほかのデータと共通している特徴を明確にする必要があります。これにより、第 3 章「スキーマの設計」で詳しく説明しているスキーマの設計段階で、時間を節約することができます。
たとえば、ディレクトリデータの特徴を記載した次のような表を作成することができます。
表 2-3 ディレクトリデータの特徴
データ
形式
サイズ
所有者
関連するエントリ
社員の名前
テキストの文字列
128 文字
人事
ユーザーエントリ
ファックス番号
電話番号
14 桁の数字
設備
ユーザーエントリ
電子メールアドレス
テキスト
多くの文字
情報システム部
ユーザーエントリ
ディレクトリの可用性要件の特定
提供するサービスの可用性のレベルは、ディレクトリ対応のアプリケーションを利用するユーザーが必要とするサービスによって決まります。各アプリケーションで必要なサービスレベルを決定するには、まずそのアプリケーションがいつどのように使用されているかを確認します。
ディレクトリの利用が進むにつれて、通常の運用レベルからミッションクリティカルなレベルまで、さまざまなサービスレベルをサポートする必要が出てきます。ディレクトリの導入後にサービスレベルを上げることは困難なので、将来の要件にも対応できる設計を初期の段階から心がけるようにしてください。
たとえば、システム全体に及ぶような障害が発生する可能性を排除する場合は、同じデータに対して複数のマスターが存在する、マルチマスター設定を使用します。次に、データマスターの特定について詳しく説明します。
データマスターサーバーの特定
データマスターは、データのマスターソースになるサーバーです。データが複数の場所に存在する場合は、どのサーバーをデータマスターにするかを考慮します。たとえば、レプリケーションを使用する場合、あるいは LDAP 経由で通信できないアプリケーションを使用する場合は、データが複数のサイトに分散されていることがあります。あるデータが複数の場所に存在する場合は、マスターコピーを置くサーバーとこのマスターコピーから更新を受け取るサーバーを決定しておく必要があります。
レプリケーション時のデータマスターの作成
Sun ONE Directory Server では、複数のサーバーに情報のマスターソースを置くことができます。レプリケーションを使用する場合は、どのサーバーをデータのマスターソースにするかを決定します。Sun ONE Directory Server では、複製のサーバーが同じデータのマスターソースとなる可能性があるマルチマスター設定がサポートされています。レプリケーションとマルチマスターレプリケーションについては、「レプリケーションの設計」を参照してください。
もっとも単純な構成では、すべてのデータのマスターソースを 2 つの Directory Server に置き、そのデータを 1 台または複数のコンシューマサーバーにレプリケートするようにします。2 つのマスターサーバーがあれば、1 つのサーバーが故障してオフラインになったときでも安全が保障されます。より複雑な構成では、データを複数のデータベースに格納し、データの更新または検索を行うアプリケーションの近くにあるサーバーが、エントリのマスターを作成するようにします。
複数アプリケーションにわたるデータマスターの作成
ディレクトリと間接的に通信するアプリケーションがある場合には、データのマスターソースについても考慮する必要があります。このような場合は、データの変更処理と、データ変更を実行する場所とを、できる限り単純に保ちます。単一のサイトでデータのマスターを作成することにした場合は、同じサイトでそこに含まれているほかのすべてのデータのマスターを作成します。このようにマスターの作成先を単一のサイトにしておくと、企業内でデータベースの同期がとれなくなった場合の障害追跡が簡単になります。
次に、データマスターの作成方法を示します。
- ディレクトリおよびそのディレクトリを使用しないすべてのアプリケーションの両方でデータマスターを作成する
マルチマスターを管理する場合は、ディレクトリやその他のアプリケーションとの間でデータをやり取りするためのカスタムスクリプトは必要ありません。ただし、一か所でデータが変更されると、ほかのすべてのサイトでもデータを変更する必要があります。ディレクトリおよびそのディレクトリを使用しないすべてのアプリケーションでマスターデータを管理すると、企業全体のデータが同期しなくなることがあります (このような状態をディレクトリが回避しようとする)。
- ディレクトリでデータマスターを作成し、Sun ONE Meta Directory を使用してほかのアプリケーションとデータの同期をとる
さまざまなディレクトリ対応アプリケーションやデータベースアプリケーションを使用している場合は、ほかのアプリケーションと同期をとるデータマスターを管理する方法がもっとも合理的です。Sun ONE Meta Directory の詳細については、Sun ONE 製品の販売店にお問い合わせください。
ディレクトリ以外のアプリケーションでデータマスターを作成してから、そのデータをディレクトリにインポートするスクリプト、プログラム、またはゲートウェイを作成する
すでに使用しているアプリケーションの中にデータマスターを作成できるものが 1 つまたは 2 つあり、ディレクトリを検索の目的 (オンラインの企業電話帳など) にのみ使用する場合は、ディレクトリ対応以外のアプリケーションでデータマスターを作成する方法がもっとも合理的です。
データのマスターコピーの管理方法は、個々の要件によって異なります。ただし、どのような管理方法を選択しても、簡単で一貫性のあるものにしてください。たとえば、複数のサイトでデータマスターを作成し、競合するアプリケーション間で自動的にデータを交換するようなことは避けてください。そのような方法では、「最新の変更が優先される」ことになり、管理に伴うオーバーヘッドが増大します。
たとえば、ある社員の自宅の電話番号を管理する場合を考えてみます。この情報は、LDAP ディレクトリと人事データベースの両方に格納されています。人事アプリケーションは LDAP 対応なので、LDAP ディレクトリと人事データベースの間でデータを転送する自動アプリケーションを作成することができます。ここで、その社員の電話番号への変更を LDAP ディレクトリと人事管理データの両方でマスタリングすると、最後に変更した電話番号のデータが、もう一方のデータベースの情報を上書きしてしまいます。これは、最後にデータを書き込んだアプリケーションが正しい情報を持っている場合には、適切な処理として許容できます。ところが、この情報が古い場合 (たとえば、人事管理データがバックアップから再読み込みされたものである場合など) は、LDAP ディレクトリ内の正しい電話番号が削除されてしまいます。
データ所有者の決定
「データ所有者」とは、データを最新の状態に維持する責任のある個人または組織のことです。データの設計時に、ディレクトリにデータを書き込めるユーザーを決めておきます。データ所有者を決めるには、一般に次の規則に従います。
- ディレクトリの内容を管理する少人数のマネージャグループを除くすべてのユーザーに対して、ディレクトリへの読み取り専用アクセスを許可する
- 各ユーザーが自分自身に関する重要な情報を管理できるようにする
この情報には、パスワード、そのユーザーに関する情報と組織内での役割、自動車のナンバープレート番号、自宅やオフィスの電話番号などの連絡先の情報が含まれます。
- 人に関する重要な情報 (連絡先情報や役職など) を上司が書き込めるようにする
- 組織の管理者がその組織に関するエントリを作成および管理できるようにする
この方法では、実質的に組織の管理者が、ディレクトリの内容の管理者にもなります。
- グループ内のユーザーに読み取りと書き込みのアクセス権限を与えるロールを作成する
たとえば、人事、財務、経理などのロールを作成します。これらのロールごとに、給与情報や政府指定の ID 番号 (米国の場合は社会保障番号)、自宅の電話番号と住所など、そのグループが必要とするデータへの読み取りアクセス権、書き込みアクセス権、またはその両方を許可します。
ロールとエントリのグループ化については、「ディレクトリツリーの設計」を参照してください。
データに書き込みを許可するユーザーを決定するときに、複数のユーザーに対して同じデータへの書き込み権限が必要になることがあります。たとえば、社員のパスワードへの書き込み権限を、情報システムまたはディレクトリ管理グループに許可するとします。同時に、社員にも自分のパスワードへの書き込み権限を許可する場合があります。複数のユーザーに同じ情報への書き込み権限を与えなければならない場合がありますが、このような場合はこのグループを少人数に保ち、容易に識別できるようにします。グループを少人数に保つことにより、データの整合性を維持しやすくなります。
ディレクトリのアクセス制御の設定については、第 7 章の「安全なディレクトリの設計」を参照してください。
データアクセスの決定
データ所有者を決定したら、各データを読み取ることができるユーザーを決定します。たとえば、ある社員の自宅の電話番号をディレクトリに保存することにした場合を考えてみます。このデータは、その社員の上司や人事部など、多くの組織にとって有用です。また、その社員自身が確認のためにこの情報を読み込めるようにしたい場合もあります。しかし、自宅の連絡先情報は機密事項とも考えられます。したがって、この種のデータを企業全体で広く利用可能にするかどうかを決定する必要があります。
ディレクトリに格納する各情報について、次の事項を決定する必要があります。
- データを匿名で読み取れるようにするか
LDAP プロトコルでは匿名アクセスがサポーされているので、オフィスの場所、電子メールアドレス、会社の電話番号などの一般情報を簡単に検索できます。ただし、匿名アクセスの場合は、ディレクトリへのアクセス権を持つユーザーであればだれでも一般情報にアクセスできてしまいます。そのため、匿名アクセスの使用はできるだけ避けてください。
- データを企業全体で広く読み取れるようにするか
ディレクトリにログイン (あるいはバインド) しないかぎり、特定の情報を読み取れないようにアクセス制御を設定することができます。匿名アクセスとは異なり、この形式のアクセス制御では、ディレクトリの情報を閲覧できるユーザーを組織内のメンバーだけに限定できます。また、ログイン情報をディレクトリのアクセスログに取り込めるので、情報にアクセスしたユーザーの記録を残すことができます。
アクセス制御については、「アクセス制御の設計」を参照してください。
- データを読み取る必要があるユーザーグループまたはアプリケーションを特定できるようにするか
一般に、データへの書き込み特権を持つユーザーには読み取り権限も必要です (パスワードへの書き込み権限は例外)。また、特定の組織やプロジェクトグループだけが必要とするデータが存在することがあります。これらのアクセス要件を特定しておくと、ディレクトリで必要となるグループ、ロール、およびアクセス制御を決める際に役立ちます。
グループとロールについては、57 ページの第 4 章「ディレクトリツリーの設計」を参照してください。アクセス制御については、第 7 章の「安全なディレクトリの設計」を参照してください。
ディレクトリの各データに対してこれらの事項を決定する際には、ディレクトリのセキュリティポリシーを定義していることが前提となります。これらの決定は、サイトの性質と、サイトですでに利用可能なセキュリティのタイプによって異なります。たとえば、サイトにファイアウォールが使用されている場合や、インターネットに直接アクセスしていない場合は、インターネット上に直接ディレクトリを配置している場合に比べ、匿名アクセスをサポートしやすくなります。
多くの国では、データ保護に関する法律によって個人情報をどのように管理すべきかが規定されており、個人情報にアクセスする人を制限しています。たとえば、法律によって住所や電話番号への匿名アクセスが禁止されていたり、住所や電話番号を表すエントリ内の情報を閲覧、訂正する許可をユーザーに与えなければならない場合があります。必ず社内の法務部に問い合わせて、ディレクトリの導入が、業務拠点としている国々の該当する法律に違反していないことを確認してください。
セキュリティポリシーの作成と実装方法については、第 7 章の「安全なディレクトリの設計」で詳しく説明します。
サイト調査の記録
データの設計は複雑なため、サイト調査の結果は文書に記録しておきます。サイト調査の各段階で、データを把握するための簡単な表を作成することをお勧めしました。決定事項と未解決の問題を概説する簡単な表を作成することを検討してください。使い慣れたワードプロセッサでこの表を作成したり、表の内容を簡単に保存・検索できるようにスプレッドシートを使用することもできます。
表 2-4 は、基本的なデータ追跡例を示しています。この表には、データ所有者と、サイト調査で特定した各データについてのデータアクセス権限が示されています。
社員名を表す行には、次の項目が含まれています。
- 所有者
人事部がこの情報を所有し、この情報の更新と変更の責任を負います。
- マスターサーバー / アプリケーション
PeopleSoft というアプリケーションで社員名に関する情報を管理します。
- 本人による読み取り / 書き込み
ユーザーは自分の名前の読み取りはできますが、書き込み (変更) はできません。
- 全員による読み取り
ディレクトリへのアクセス権を持つすべてのユーザーは、匿名で社員名を読み取ることができます。
- 人事部 (HR) による書き込み
人事グループのメンバーは、ディレクトリ内の社員名を変更、追加、および削除できます。
- 情報システム部 (IS) による書き込み
情報サービスグループのメンバーは、ディレクトリ内の社員名を変更、追加、および削除できます。
サイト調査の繰り返し
サイト調査は数回実施した方が良い場合があります。特に、複数の都市や国にオフィスを持つ企業の場合は、これが当てはまります。情報に関する要件があまりにも複雑なため、中央のサイトで情報を一元的に管理するよりも、複数の組織がそれぞれの現地オフィスで情報を保管するようにしなければならない場合もあります。このような場合は、情報のマスターコピーを保管する各オフィスで、独自のサイト調査を実施するようにします。この過程の完了後、中央のチーム (各オフィスの代表者で構成される) に各調査結果が戻され、企業全体のデータスキーマモデルとディレクトリツリーの設計に使用します。