第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=com
root 接尾辞が格納されます。
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 を使用してサーバーの状態を監視します。
- アクセスログとエラーログを自動でローテーションします。
- エラーログを監視し、サーバーが想定どおりに実行されていることを確認します。
- アクセスログを監視して、インデックスを作成できる検索を示します。
関連情報