第8章 ディレクトリー設計の例
ディレクトリーサービスの設計は、企業の規模と性質によって異なります。これらの例は、実際のディレクトリーサービスのデプロイメント計画を作成するための出発点となります。
8.1. ローカルエンタープライズの設計例 リンクのコピーリンクがクリップボードにコピーされました!
ExampleCom は自動車部品メーカーの小規模な会社で、従業員数は 500 人です。ExampleCom は、自社で使用するディレクトリー対応アプリケーションをサポートするために、Red Hat Directory Server のデプロイを決定しました。
8.1.1. ローカルエンタープライズのデータ設計 リンクのコピーリンクがクリップボードにコピーされました!
ディレクトリーに保存するデータのタイプを決定するために、ExampleCom はサイト調査を実行するデプロイメントチームを結成します。デプロイメントチームは、次の重要なポイントを決定します。
- メッセージングサーバー、Web サーバー、カレンダーサーバー、人事アプリケーション、およびホワイトページアプリケーションがディレクトリーを使用します。
メッセージングサーバーは、
uid、mailServerName、mailAddressなどの属性に対して 正確な 検索を実行します。データベースのパフォーマンスを向上させるために、ExampleCom はこれらの属性のインデックスを維持します。インデックスの使用に関する詳細は、インデックスを使用してデータベースのパフォーマンスを向上させる を参照してください。
ホワイトページアプリケーションは、ユーザー名と電話番号を検索します。したがって、ディレクトリーは、大量の結果セットを返す頻繁な部分文字列、ワイルドカード、およびあいまい検索を処理する必要があります。ExampleCom 社は、以下のインデックスを維持することにしました。
-
cn、sn、givenName属性の 存在、等価性、近似値、および 部分文字列 インデックス。 -
telephoneNumber属性の 存在、等価性、および 部分文字列 のインデックス。
-
- 組織内にデプロイされた LDAP サーバーベースのイントラネットをサポートするには、ディレクトリーでユーザーとグループの情報を維持する必要があります。ディレクトリー管理者グループは、ExampleCom のユーザーおよびグループ情報のほとんどを管理します。ただし、ExampleCom では、メール情報を管理するために別のメール管理者グループを必要としています。
- ディレクトリーには、S/MIME メールなどの公開鍵基盤 (PKI) アプリケーションをサポートするために、ユーザーの公開鍵証明書を保存する必要があります。
8.1.2. ローカルエンタープライズのスキーマ設計 リンクのコピーリンクがクリップボードにコピーされました!
ExampleCom ディレクトリーがサポートするアプリケーションには、userCertificate および uid (userID) 属性が必要です。したがって、ExampleCom デプロイメントチームは、両方の属性が許可されるため、inetOrgPerson オブジェクトクラスを使用してディレクトリー内のエントリーを表すことにしました。
さらに、ExampleCom は、従業員を表す examplePerson オブジェクトクラスを作成して、デフォルトのディレクトリースキーマをカスタマイズしたいと考えています。このオブジェクトクラスは、inetOrgPerson オブジェクトクラスから派生しています。examplePerson では、1 つの exampleID 属性が許可されます。この属性には、各従業員に割り当てられた特別な従業員番号が含まれます。ExampleCom は今後、examplePerson オブジェクトクラスに新しい属性を追加できます。
8.1.3. ローカルエンタープライズのディレクトリーツリー設計 リンクのコピーリンクがクリップボードにコピーされました!
準備されたデータとスキーマ設計に基づいて、ExampleCom は次のディレクトリーツリーを作成します。
図8.1 ExampleCom のディレクトリーツリー
-
ディレクトリーツリーの root は
dc=example,dc=comで、これは会社のインターネットドメイン名です。 ディレクトリーツリーには 4 つのブランチポイントがあります。
-
ou=people -
ou=groups -
ou=resources -
ou=roles
-
すべての ExampleCom の people エントリーは、
ou=peopleブランチの下に作成されます。people エントリーはすべて、
person、organizationalPerson、inetOrgPerson、およびexamplePersonオブジェクトクラスのメンバーです。uid属性は、各エントリーの識別名 (DN) を一意に識別します。たとえば、会社には Babs Jensen (uid=bjensen) と Emily Stanton (uid=estanton) のエントリーが含まれています。ExampleCom の各部門には、
sales、marketing、およびaccountingロールが作成されます。person エントリーにはそれぞれ、その人が所属する部門を識別するロール属性が含まれます。この会社は、これらのロールに基づいてアクセス制御命令 (ACI) を作成できるようになりました。
ロールの詳細は、「Directory Server のロールについて」 を参照してください。
ou=groupsブランチの下に、以下のグループブランチが作成されます。-
cn=administratorsグループには、ディレクトリーの内容を管理するディレクトリー管理者のエントリーが含まれています。 -
cn=messaging adminsグループには、メールアカウントのみを管理するメール管理者のエントリーが含まれています。このグループは、メッセージングサーバーが使用する管理者グループに対応します。
-
ou=resourcesブランチの下に次のブランチが作成されます。-
会議室用の
ou=conference roomsブランチ。 -
オフィス用の
ou=officesブランチ。
-
会議室用の
-
エントリーが管理グループに属しているかどうかに応じて、
mailquota属性の値を提供する Class of Service (CoS) が作成されます。この CoS では、管理者には 100GB のメールクォータが提供され、一般の ExampleCom の従業員には 5GB のメールクォータが与えられます。
8.1.4. ローカルエンタープライズのトポロジー設計 リンクのコピーリンクがクリップボードにコピーされました!
ExampleCom デプロイメントチームは、ディレクトリーデータベースとサーバートポロジーの設計を開始します。
ExampleCom は次のデータベーストポロジーを設計します。
図8.2 ローカルエンタープライズのデータベーストポロジー
-
Database 1にはou=peopleブランチが格納されます。 -
Database 2にはou=groupsブランチが格納されます。 -
Database 3には、ou=resourcesおよびou=rolesブランチとdc=example,dc=comroot 接尾辞が格納されます。
ExampleCom は次のサーバートポロジーを設計します。
図8.3 ローカル企業のサーバートポロジー
ExampleCom は、2 つのサプライヤーサーバーと 3 つのコンシューマーサーバーを含むサーバートポロジーを作成することにしました。2 つのサプライヤーはそれぞれ、Directory Server のデプロイメント内の 3 つのコンシューマーをすべて更新します。
コンシューマーは、1 つのメッセージングサーバーと他のサーバーにデータを提供します。互換性のあるサーバーからの変更要求は、適切なコンシューマーサーバーにルーティングされます。コンシューマーサーバーは、スマートリファラルを使用して、変更されるデータのメインコピーを担当するサプライヤーサーバーへの要求をルーティングします。
8.1.5. ローカルエンタープライズのレプリケーション設計 リンクのコピーリンクがクリップボードにコピーされました!
ExampleCom は、ディレクトリーデータの高可用性を確保するために、マルチサプライヤーのレプリケーション設計を使用することを決定します。マルチサプライヤーレプリケーションの詳細は、マルチサプライヤーレプリケーション を参照してください。
マルチサプライヤーアーキテクチャー
ExampleCom は、マルチサプライヤーレプリケーションアーキテクチャーで 2 つのサプライヤーサーバーを使用します。サプライヤーが相互に更新することで、ディレクトリーデータの整合性が保たれます。次の図は、ExampleCom のサプライヤー - サプライヤーアーキテクチャーを示しています。
図8.4 ExampleCom マルチサプライヤーアーキテクチャー
サプライヤーコンシューマーアーキテクチャー
以下の図は、ExampleCom のディレクトリーのデプロイメントで、サプライヤーサーバーが各コンシューマーにレプリケートする方法を示しています。
図8.5 ExampleCom サプライヤー - コンシューマーアーキテクチャー
両方のサプライヤーサーバーが 3 つのコンシューマーサーバーを更新します。これにより、サプライヤーサーバーの 1 つに障害が発生しても、コンシューマーが影響を受けることはありません。
8.1.6. ローカル企業のセキュリティー設計 リンクのコピーリンクがクリップボードにコピーされました!
ディレクトリーデータを保護するために、ExampleCom は次のアクセス制御命令 (ACI) を作成します。
-
従業員がエントリーを変更できるようにする ACI。ユーザーは、
uid、manager、department属性を除くすべての属性を変更できます。 - 従業員データのプライバシーを保護するために、従業員と従業員のマネージャーのみが従業員の自宅住所と電話番号を確認できる ACI。
ディレクトリーツリーのルートにある ACI は、2 つの管理者グループに適切なディレクトリーパーミッションを付与します。
- ディレクトリー管理者グループは、ディレクトリーへのフルアクセスが必要です。
-
メッセージング管理者グループには、
mailRecipientおよびmailGroupオブジェクトクラス、およびこれらのオブジェクトクラスで許可される属性 (mail属性を含む) へのwriteおよびdeleteアクセス権が必要です。ExampleCom は、メッセージング管理者グループに、メールグループを作成するためのグループサブディレクトリーへのwrite、delete、およびaddパーミッションも付与します。
-
ディレクトリーツリーのルートにある一般的な ACI で、
read、search、およびcompareアクセスに対する匿名アクセスを許可します。さらに、この ACI は匿名ユーザーによるパスワード情報へのアクセスを拒否します。 - アカウンティングロールのメンバーにすべての給与情報へのアクセス権を与える ACI。
さらに、ExampleCom は次のセキュリティー対策を決定します。
サービス拒否攻撃や不適切な使用からサーバーを保護するために、ExampleCom は、ディレクトリークライアントがバインドに使用する DN に基づいてリソース制限を設定します。
- 匿名ユーザーは、検索要求に応じて一度に 100 件のエントリーを受け取ることができます。
- メッセージング管理者は 1,000 件のエントリーを受信できます。
- ディレクトリー管理者は、無制限の数のエントリーを受け取ることができます。
ExampleCom は、長さが少なくとも 8 文字で、90 日後に期限切れになるパスワードのパスワードポリシーを作成します。
パスワードポリシーの詳細は、パスワードポリシーの設計 を参照してください。
8.1.7. ローカルエンタープライズの運営上の決定 リンクのコピーリンクがクリップボードにコピーされました!
会社は、ディレクトリーの日常業務に関して次の決定を下します。
- 毎晩、データベースをバックアップします。
- SNMP を使用してサーバーの状態を監視します。
- アクセスログとエラーログを自動でローテーションします。
- エラーログを監視し、サーバーが想定どおりに実行されていることを確認します。
- アクセスログを監視して、インデックスを作成できる検索を示します。