2.3. サイト調査の実行

通常、ディレクトリーにアクセスするアプリケーションおよびこれらのアプリケーションのデータニーズが、ディレクトリーの内容の計画を駆動します。多くの共通アプリケーションはディレクトリーを使用します。

ディレクトリーを使用するアプリケーションを検証する場合は、各アプリケーションが使用する情報の種類を確認します。以下の表は、アプリケーションの例と、各アプリケーションによって使用される情報を示しています。

アプリケーションおよび各アプリケーションによって使用される情報の特定後、一部のタイプのデータが複数のアプリケーションによって使用されていることが明確になります。データ計画段階でこのような演習を実行すると、ディレクトリーにおけるデータ冗長性の問題を回避し、ディレクトリー依存アプリケーションが必要とするデータをより明確にすることができます。

ディレクトリーで維持するデータの種類および情報をディレクトリーに移行する時期に関する最終的な決定は、以下の要因の影響を受けます。

ディレクトリーに含めるすべてのデータを特定するには、既存のデータストアの調査を実行します。調査には以下を含める必要があります。

調査の実行中に、表2.2「 情報ソースの例」のような、エンタープライズのすべての情報ソースを特定するマトリックスの開発を検討します。

ディレクトリーに含まれるように識別されたすべてのデータは、以下の一般的なポイントに従って特徴付けることができます。

ディレクトリーに含める各種類のデータを調査し、他のデータと共有する特性を決定します。これは、スキーマ設計の段階で時間を節約するのに役立ちます。詳細は、3章ディレクトリースキーマの設計で説明されています。

ディレクトリーデータを特徴付ける 表2.3「ディレクトリーデータの特徴付け」のようなテーブルを使用することが良いでしょう。

提供されるサービスレベルは、ディレクトリー対応アプリケーションに依存するユーザーの期待値により異なります。各アプリケーションが想定するサービスのレベルを決定するには、まずアプリケーションの使用方法とタイミングを決定します。

ディレクトリーが発展するにつれて、さまざまなサービスレベル (本番環境からミッションクリティカルまで) をサポートする必要がある場合があります。ディレクトリーのデプロイ後にサービスレベルを上げることは困難な場合があるため、初期設計が今後のニーズを満たすようにしてください。

たとえば、合計の失敗のリスクを排除する必要がある場合は、同じデータに対して複数のサプライヤーが存在する、マルチサプライヤーの設定を使用します。

データサプライヤー は、データソースのサプライヤーであるサーバーです。同じ情報が複数の場所に保存されるたびに、データの整合性が低下する可能性があります。データサプライヤーにより、複数の場所に保存されている全情報の一貫性が保たれ、正確性が確保されます。データサプライヤーが必要なシナリオはいくつかあります。

ディレクトリーに間接的に通信するアプリケーションがある場合には、データソースのサプライヤーについて検討してください。データを変更するプロセスと、データの変更元の場所を可能な限りシンプルに維持します。データを管理する単一のサイトを決定したら、同じサイトを使用して、そこに含まれる他のデータをすべて管理します。単一サイトは、データベースが企業全体で同期を失った場合にトラブルシューティングを簡素化します。

データ提供を実装する方法は複数あります。

データのメインコピーの維持方法は、特定のディレクトリーのニーズによって異なります。ただし、データサプライヤーがどのように維持されているかに関係なく、単純性と一貫性を維持します。たとえば、複数のサイトでデータの管理を試みないでください。その場合、競合するアプリケーション間でデータを自動的に交換します。これを行うと、last change wins のシナリオが発生し、管理のオーバーヘッドが増加します。

たとえば、ディレクトリーは従業員の自宅電話番号を管理します。LDAP ディレクトリーと人事データベースの両方がこの情報を保存します。人事アプリケーションは LDAP 対応のため、LDAP ディレクトリーから人事データベースへデータを自動的に転送するアプリケーションを作成することができます。その逆の場合も、アプリケーションを作成できます。

ただし、LDAP ディレクトリーと人事データの両方で、従業員の電話番号の変更を管理しようとしていますが、電話番号が変更された最後の場所が他のデータベースの情報を上書きしてしまいます。これは、データを書き込む最後のアプリケーションに正しい情報がある場合に限り許容されます。

人事データがバックアップからリロードされたため、その情報が古くなっていた場合は、LDAP ディレクトリーの正しい電話番号が削除されます。

マルチサプライヤーレプリケーションにより、Directory Server には、複数のサーバーで情報のソースを含めることができます。複数のサプライヤーは変更ログを保持し、競合をより安全に解決できます。限られた数の Directory Server は変更を受け入れるサプライヤーと見なされ、データをレプリカサーバーまたはコンシューマーサーバーに複製します。^[1] 複数のデータサプライヤーサーバーあると、サーバーがオフになった場合に安全なフェイルオーバーを提供します。レプリケーションおよびマルチサプライヤーレプリケーションの詳細は、7章レプリケーションプロセスの設計を参照してください。

同期により、Directory Server ユーザー、グループ、属性、およびパスワードを Microsoft Active Directory ユーザー、グループ、属性、パスワードと統合できます。2 つのディレクトリーサービスでは、それらが同じ情報を取り扱うか、共有されるその情報の量、およびその情報のデータサプライヤーとなるサービスを決定します。最適なのは、データを管理する 1 つのアプリケーションを選択し、同期プロセスで他のサービスのエントリーを追加、更新、または削除できるようにすることです。

データの所有者 は、データを最新の状態に維持させる人または組織を指します。データ設計フェーズで、ディレクトリーにデータを書き込むことができるユーザーを決定します。以下は、データの所有者を決定する一般的なストラテジーです。

同じ情報への書き込みアクセス権が必要な個人が複数存在する場合があります。たとえば、情報システム (IS) またはディレクトリー管理グループには、おそらく従業員パスワードへの書き込みアクセスが必要になります。また、従業員自体にも自分のパスワードへの書き込みアクセス権があることが望ましい場合があります。一般的には、複数のユーザーが同じ情報への書き込みアクセス権を持つ場合には、このグループを小さくし、簡単に識別できるようにしてください。グループを小さくすると、データの整合性が確保されます。

ディレクトリーのアクセス制御の設定に関する詳細は、9章セキュアなディレクトリーの設計を参照してください。

データの所有者を決定したら、各データを読み取ることができるユーザーを決定します。たとえば、従業員の自宅電話番号はディレクトリーに保存できます。このデータは、従業員のマネージャーや人事など、多くの組織に役に立つ場合があります。従業員は、検証目的でこの情報を読み取ることができる必要があります。しかし、自宅の連絡先情報は機密であるとみなされる可能性があるため、企業全体で広く利用するべきではありません。

ディレクトリーに保存されている各情報について、以下を決定します。

ディレクトリーデータごとに、これらの決定を行うと、ディレクトリーのセキュリティーポリシーが定義されます。この決定は、サイトの性質と、サイトで利用できるセキュリティーの種類によって異なります。たとえば、ファイアウォールがあったりインターネットに直接アクセスできない場合は、ディレクトリーがインターネットに直接配置される場合よりも匿名アクセスのサポートは安全です。さらに、アクセスを制限する際にアクセス制御と認証手段のみが必要になる場合もあります。その他の機密情報は保存時にデータベース内で暗号化する必要がある場合があります。

多くの国では、データ保護の法律で、企業がどのように個人情報を維持するか、個人情報へのアクセスを制限するかが規定されています。たとえば、法律では、アドレスと電話番号への匿名アクセスを禁止したり、ユーザーがそれらを表すエントリーの情報を表示したり、修正できることを要求したりする場合があります。ディレクトリーの導入が、エンタープライズが活動する国で必要なすべての法に従うように、組織の法務部門に必ず確認してください。

セキュリティーポリシーの作成と、実装する方法の詳細は、9章セキュアなディレクトリーの設計を参照してください。