2.3. サイト調査の実行
サイト調査 は、ディレクトリーの内容を検出し特徴付けるための正式な方法です。ディレクトリーアーキテクチャーの準備は非常に重要なので、調査の実行にはさらに時間を割くよう計画してください。サイト調査は次のタスクで構成されます。
ディレクトリーを使用するアプリケーションを特定する。
エンタープライズ全体にデプロイされるディレクトリー対応アプリケーションとそのデータのニーズを判断する。
データソースを特定する。
企業を調査し、Active Directory、その他の LDAP サーバー、PBX システム、人事データベース、メールシステムなどのデータソースを特定します。
ディレクトリーに含まれる必要のあるデータを特徴付ける。
ディレクトリーに存在すべきオブジェクト (例: 人またはグループ) と、ディレクトリーで維持すべきこれらのオブジェクトの属性 (ユーザー名とパスワードなど) を決定します。
提供するサービスレベルを決定する。
クライアントアプリケーションのディレクトリーデータの可用性を決定し、それに応じてアーキテクチャーを設計します。ディレクトリーの可用性は、リモートサーバーに保存されているデータを接続するためのデータレプリケーションおよびチェイニングポリシーを設定する方法に影響を及ぼします。
データサプライヤーを特定する。
データサプライヤーには、ディレクトリーデータのプライマリーソースが含まれます。負荷分散と回復の目的で、このデータを他のサーバーにミラーリングすることができます。各データのデータサプライヤーを決定します。
データの所有者を決定する。
データごとに、データ更新の責任者を決定します。
データアクセスを決定する。
他のソースからデータをインポートする場合は、一括インポートと増分更新の両方のストラテジーを立てます。このストラテジーの一部として、データを 1 カ所で管理し、データを変更できるアプリケーションの数を制限するようにします。また、任意のデータに書き込みするユーザーの数を制限します。グループを小さくすると、管理オーバーヘッドが削減され、データの整合性が確保されます。
- サイト調査を文書化します。
ディレクトリーが複数の組織に影響を与える場合は、影響を受ける各組織の代表者を含むディレクトリーデプロイメントチームを編成してサイト調査を実施することを検討してください。
企業には、一般的に、人事部門、経理部門、製造部門、営業部門、および開発部門があります。これらの各組織の代表者を含めると、調査プロセスを実行し、ローカルデータストアから集中型ディレクトリーに移行しやすくなります。
2.3.1. ディレクトリーを使用するアプリケーションの特定
ディレクトリーにアクセスするアプリケーションおよびこれらのアプリケーションのデータニーズが、ディレクトリー内容の計画におけるガイドとなります。ディレクトリーを使用するさまざまな一般的なアプリケーションには、以下があります。
- オンライン電話帳などのディレクトリーブラウザーアプリケーション。ユーザーが必要とする情報を決定し、それをディレクトリーに含めます。
- 電子メールアプリケーション (特に電子メールサーバー)すべてのメールサーバーでは、ディレクトリー内でルーティング情報が利用可能である必要があります。ただし、ユーザーのメールボックスが保存されるディスク上の場所、休暇通知の詳細、IMAP と POP などのプロトコル情報など、より詳細な情報が必要になる場合もあります。
- ディレクトリー対応人事アプリケーション。これらには、政府発行の身分証明書番号、自宅住所、自宅電話番号、生年月日、給与、役職などの追加の個人情報が必要です。
- Microsoft Active Directory.Windows User Sync を使用すると、Windows ディレクトリーサービスを統合して、Directory Server と連携して機能させることができます。どちらのディレクトリーにも、ユーザー情報とグループ情報を保存できます。既存の Windows サーバーのデプロイメントの後に Directory Server のデプロイメントを設定して、ユーザー、グループ、およびその他のディレクトリーデータを同期できるようにします。
ディレクトリーを使用するアプリケーションを評価するときは、各アプリケーションが使用する情報の種類を考慮してください。次の表は、アプリケーションとそのアプリケーションが使用する情報の例を示しています。
表 2.1.アプリケーションデータニーズの例
Application | データのクラス | データ |
---|---|---|
電話帳 | 人 | 名前、メールアドレス、電話番号、ユーザー ID、パスワード、部署番号、マネージャー、メール停止 |
Web server | 人、グループ | ユーザー ID、パスワード、グループ名、グループメンバー、グループ所有者 |
カレンダーサーバー | 人、会議室 | 名前、ユーザー ID、部屋番号、会議室名 |
アプリケーションと各アプリケーションが使用する情報を特定すると、複数のアプリケーションで使用されるデータの種類がわかります。この計画手順により、ディレクトリー内のデータの冗長性を防ぎ、ディレクトリーに依存するアプリケーションに必要なデータを明確に示すことができます。
ディレクトリーに保持されるデータの種類と、情報をディレクトリーに移行するタイミングに関する最終決定には、次の要因が影響します。
- さまざまなレガシーアプリケーションとユーザーが必要とするデータ
- レガシーアプリケーションの LDAP ディレクトリーと通信する能力
2.3.2. データソースの特定
ディレクトリーに含めるすべてのデータを決定するには、既存のデータストアの調査を実行します。調査には以下を含める必要があります。
情報を提供する組織を特定する。
情報サービス、人事、給与、経理部門など、重要な情報を管理するすべての組織を特定します。
情報ソースであるツールおよびプロセスを特定する。
情報の一般的なソースには、ネットワークオペレーティングシステム (Windows、Novell Netware、UNIX NIS)、電子メールシステム、セキュリティーシステム、PBX (電話交換) システム、および人事アプリケーションなどがあります。
各データの集中化がデータ管理にどのような影響を与えるかを判断します。
集中データ管理では、新しいツールおよび新しいプロセスが必要になる場合があります。場合によっては、集中化により組織内での人員配置や人員削減が必要になることがあります。
調査中は、次の表のように企業内のすべての情報ソースを特定するマトリックスを作成します。
表 2.2.情報源の例
データソース | データのクラス | データ |
---|---|---|
人事データベース | 人 | 名前、住所、電話番号、部署番号、マネージャー |
E メールシステム | 人、グループ | 名前、メールアドレス、ユーザー ID、パスワード、メール設定 |
ファシリティーシステム | ファシリティー | ビル名、フロア名、部屋番号、アクセスコード |
2.3.3. ディレクトリーデータの特徴付け
ディレクトリーに含めるデータを次の方法で特徴付けます。
- 形式
- サイズ
- 各種アプリケーションで発生回数
- データの所有者
- 他のディレクトリーデータとの関係
ディレクトリーに含めるデータの共通の特性を見つけます。これにより、ディレクトリースキーマの設計 で説明したスキーマ設計段階での時間を節約できます。
ディレクトリーデータの特徴を示す以下の表を検討してください。
表 2.3.ディレクトリーデータの特性
データ | 形式 | サイズ | 所有者 | 関連 |
---|---|---|---|---|
従業員名 | テキスト文字列 | 128 文字 | 人事 | ユーザーエントリー |
Fax 番号 | 電話番号 | 14 桁の数字 | ファシリティー | ユーザーエントリー |
メールアドレス | テキスト | 多くの文字 | 情報システム部門 | ユーザーエントリー |
2.3.4. サービスレベルの決定
提供するサービスレベルは、ディレクトリー対応アプリケーションを利用するユーザーの期待に応じて異なります。各アプリケーションに必要なサービスレベルを決定するには、アプリケーションがいつ、どのように使用されるかを決定します。
ディレクトリーは、進化するにつれて、実稼働レベルからミッションクリティカルなレベルまで、さまざまなサービスレベルをサポートする必要が生じる場合があります。ディレクトリーのデプロイメント後にサービスレベルを上げることは難しいため、初期設計が将来のニーズを満たしていることを確認してください。
たとえば、完全な障害のリスクを排除するには、複数のサプライヤーが同じデータを処理するマルチサプライヤー設定を使用します。
2.3.5. データサプライヤーの検討
データサプライヤー は、データを供給するサーバーです。同じ情報を複数の場所に保存すると、データの整合性が低下します。データサプライヤーにより、複数のロケーションに保存されているすべての情報の一貫性が保たれ、正確性が確保されます。次のシナリオではデータサプライヤーが必要です。
- Directory Server 間のレプリケーション
- Directory Server と Active Directory との間の同期
- Directory Server データにアクセスする独立したクライアントアプリケーション
マルチサプライヤーレプリケーションを使用すると、Directory Server は複数のサーバー上に情報のメインコピーを含むことができます。複数のサプライヤーが changelog を保持し、競合を安全に解決します。変更を受け入れ、レプリカサーバーまたはコンシューマーサーバーにデータをレプリケートできるサプライヤーサーバーの数を制付きで設定できます。 [1].複数のデータサプライヤーサーバーは、サーバーがオフラインになった場合に安全なフェイルオーバーを提供します。マルチサプライヤーレプリケーションの詳細は、TBA[レプリケーションプロセスの設計] を参照してください。
同期を使用すると、Directory Server のユーザー、グループ、属性、およびパスワードを Microsoft Active Directory のユーザー、グループ、属性、およびパスワードと統合できます。ディレクトリーサービスが 2 つある場合は、同じ情報を管理するかどうか、その情報をどの程度共有するか、どのサービスがデータを提供するかを決定します。可能ならば、データを管理するために 1 つのアプリケーションを選択し、同期プロセスによって他のサービスのエントリーを追加、更新、または削除します。
ディレクトリーと間接的に通信するアプリケーションを使用する場合は、データのサプライヤーソースを考慮してください。データ変更プロセスをできるだけシンプルに保ちます。データを管理する場所を決定したら、そこに含まれる他のすべてのデータを同じ場所で管理します。企業全体でデータベースの同期が失われた場合、1 カ所にデータがあるとトラブルシューティングが簡単になります。
データを提供するには、次の方法を実装できます。
ディレクトリーと、ディレクトリーを使用しないすべてのアプリケーションの両方でデータを管理します。
複数のデータサプライヤーを維持する場合、データを転送するためのカスタムスクリプトは必要ありません。この場合、企業全体でデータの非同期化を防ぐために、他のすべてのサイトでデータを変更する必要がありますが、これはディレクトリーの目的に反します。
ディレクトリー以外のアプリケーションでデータを管理し、そのデータをディレクトリーにインポートするためのスクリプト、プログラム、またはゲートウェイを作成します。
すでにアプリケーションを使用してデータを管理している場合は、ディレクトリー以外のアプリケーションでデータを管理することが最も理想的です。また、ディレクトリーは、オンラインの企業電話帳などの検索にのみ使用します。
データのメインコピーをどのように維持するかは、特定のディレクトリーのニーズによって異なります。ただし、メンテナンスは常にシンプルかつ一貫したものにしてください。たとえば、複数の場所でデータを管理し、競合するアプリケーション間でデータを自動的に交換するような試みは行わないでください。このような試みが行われると、更新が失われ、管理オーバーヘッドが増加します。
たとえば、ディレクトリーは、LDAP ディレクトリーと人事データベースの両方に保存されている従業員の自宅電話番号を管理します。人事アプリケーションは LDAP 対応であり、LDAP ディレクトリーから人事データベースへ、またその逆方向にデータを自動的に転送できます。
LDAP ディレクトリーと人事データベースの両方で従業員の電話番号の変更を管理しようとすると、電話番号が最後に変更された場所の情報が他のデータベースの情報を上書きします。これは、データを書き込んだ最後のアプリケーションに正しい情報があった場合にのみ許容されます。
その情報が古くなっている場合 (たとえば、人事データがバックアップから復元された場合)、LDAP ディレクトリー内の正しい電話番号は削除されます。
2.3.6. データの所有者の決定
データの所有者 は、データを最新の状態に維持する人または組織を指します。データ設計フェーズで、ディレクトリーにデータを書き込むことができるユーザーを決定します。データの所有権を決定するための一般的なストラテジーは次のとおりです。
- ディレクトリーコンテンツマネージャーの小さなグループ以外のすべてのユーザーに対して、ディレクトリーへの読み取り専用アクセスを許可します。
- 個々のユーザーが、パスワード、組織内でのロール、自動車のナンバープレート番号、電話番号やオフィス番号などの連絡先情報、自分自身の説明情報など、戦略的な情報のサブセットを管理できるようにします。
- 人事マネージャーが、連絡先情報や役職など、その人事情報の戦略的なサブセットを書き込むことを許可します。
- 組織管理者がその組織のエントリーを作成および管理できるようにし、ディレクトリーコンテンツマネージャーとして機能できるようにします。
- 読み取りまたは書き込みアクセス権限を持つユーザーグループのロールを作成します。人事、財務、会計のロールを作成できます。これらの各ロールに、グループが必要とするデータへの読み取りアクセス、書き込みアクセス、またはその両方を許可します。これには、給与情報、マイナンバー、および自宅電話番号および住所が含まれる可能性があります。
複数の個人が同じ情報への書き込みアクセス権を必要とする場合があります。たとえば、情報システムまたはディレクトリー管理グループでは、従業員のパスワードへの書き込みアクセス権が必要になる場合があります。また、従業員には自分のパスワードへの書き込みアクセス権が必要です。複数の人が同じ情報にアクセスできますが、データの整合性を確保するために、このグループを小規模かつ識別可能な状態に保つようにしてください。
2.3.7. データアクセスの決定
データの所有権を決定した後、各データを読み取るアクセス権を誰が持つかを決定します。たとえば、従業員の自宅電話番号はディレクトリーに保存できます。このデータは、従業員マネージャーや人事部門を含む多くのユーザーにとって役立つ可能性があります。従業員は、検証目的でこの情報を読み取ることができる必要があります。ただし、自宅の連絡先情報は機密情報とみなされる可能性があります。
ディレクトリーに保存されるすべての情報について、次の点を考慮してください。
誰かが匿名でデータを読むことはできますか?
LDAP プロトコルは匿名アクセスをサポートし、情報を簡単に検索できるようにします。ただし、匿名性により誰でもディレクトリーにアクセスできるため、この機能は慎重に使用してください。
誰かが企業全体でデータを広く読み取ることができますか?
アクセス制御は、クライアントが特定の情報を読み取るためにディレクトリーへログイン (またはバインド) する必要があるのと同じ方法で設定できます。匿名アクセスとは異なり、このタイプのアクセス制御では、組織のメンバーのみがディレクトリー情報にアクセスできます。さらに、Directory Server のアクセスログには、情報にアクセスしたユーザーに関する記録が含まれます。
アクセス制御の詳細は、アクセス制御の設計 を参照してください。
データにアクセスする必要がある、識別可能な人々またはアプリケーションのグループはありますか?
データへの書き込み権限を持つユーザーは、読み取りアクセスも必要です (パスワードへの書き込みアクセスを除く)。ディレクトリーには、特定の組織またはプロジェクトグループに固有のデータも含めることができます。これらのアクセスのニーズを特定することは、ディレクトリーが必要とするグループ、ロール、およびアクセス制御を把握するのに役立ちます。
グループとロールの詳細は、ディレクトリーツリーの設計 を参照してください。アクセス制御の詳細は、アクセス制御の設計 を参照してください。
ディレクトリーデータごとに、これらの決定を行うと、ディレクトリーのセキュリティーポリシーが定義されます。これらの決定は、サイトの性質と、そのサイトですでに利用可能なセキュリティーによって異なります。たとえば、ファイアウォールがあったりインターネットに直接アクセスできない場合は、ディレクトリーがインターネットに直接配置される場合よりも匿名アクセスのサポートは安全です。さらに、一部の情報では、アクセスを適切に制限するためにアクセス制御と認証手段のみが必要になる場合があります。その他の機密情報は、データベースに保存される際に暗号化する必要がある場合があります。
ほとんどの国のデータ保護法では、企業が個人情報をどのように維持し、アクセスするかを規定しています。たとえば、法律により、情報への匿名アクセスが禁止されていたり、ユーザーが自分を表すエントリーの情報を表示および編集する権限を持つことが求められたりする場合があります。組織の法務部門に問い合わせて、ディレクトリーのデプロイメントが企業が運営されている国のデータ保護法に準拠していることを確認します。
セキュリティーポリシーの作成とその実装方法は、安全なディレクトリーの設計 で詳しく説明されています。
レプリケーションでは、コンシューマーサーバー (レプリカサーバー) がサプライヤーサーバーまたはハブサーバーから更新を受信します。