検索

第8章 ディレクトリー設計の例

download PDF

ディレクトリーサービスの設計は、企業の規模と性質によって異なります。これらの例は、実際のディレクトリーサービスのデプロイメント計画を作成するための出発点となります。

8.1. ローカルエンタープライズの設計例

ExampleCom は自動車部品メーカーの小規模な会社で、従業員数は 500 人です。ExampleCom は、自社で使用するディレクトリー対応アプリケーションをサポートするために、Red Hat Directory Server のデプロイを決定しました。

8.1.1. ローカルエンタープライズのデータ設計

ディレクトリーに保存するデータのタイプを決定するために、ExampleCom はサイト調査を実行するデプロイメントチームを結成します。デプロイメントチームは、次の重要なポイントを決定します。

  • メッセージングサーバー、Web サーバー、カレンダーサーバー、人事アプリケーション、およびホワイトページアプリケーションがディレクトリーを使用します。
  • メッセージングサーバーは、uidmailServerNamemailAddress などの属性に対して 正確な 検索を実行します。データベースのパフォーマンスを向上させるために、ExampleCom はこれらの属性のインデックスを維持します。

    インデックスの使用に関する詳細は、インデックスを使用してデータベースのパフォーマンスを向上させる を参照してください。

  • ホワイトページアプリケーションは、ユーザー名と電話番号を検索します。したがって、ディレクトリーは、大量の結果セットを返す頻繁な部分文字列、ワイルドカード、およびあいまい検索を処理する必要があります。ExampleCom 社は、以下のインデックスを維持することにしました。

    • cnsngivenName 属性の 存在等価性近似値、および 部分文字列 インデックス。
    • 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 のディレクトリーツリー

dg ローカル企業の例 1
  • ディレクトリーツリーの root は dc=example,dc=com で、これは会社のインターネットドメイン名です。
  • ディレクトリーツリーには 4 つのブランチポイントがあります。

    • ou=people
    • ou=groups
    • ou=resources
    • ou=roles
  • すべての ExampleCom の people エントリーは、ou=people ブランチの下に作成されます。

    people エントリーはすべて、personorganizationalPersoninetOrgPerson、および examplePerson オブジェクトクラスのメンバーです。uid 属性は、各エントリーの識別名 (DN) を一意に識別します。たとえば、会社には Babs Jensen (uid=bjensen) と Emily Stanton (uid=estanton) のエントリーが含まれています。

  • ExampleCom の各部門には、salesmarketing、および 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 ローカルエンタープライズのデータベーストポロジー

dg ローカル企業の例 2
  • Database 1 には ou=people ブランチが格納されます。
  • Database 2 には ou=groups ブランチが格納されます。
  • Database 3 には、ou=resources および ou=roles ブランチと dc=example,dc=com root 接尾辞が格納されます。

ExampleCom は次のサーバートポロジーを設計します。

図8.3 ローカル企業のサーバートポロジー

dg ローカル企業の例 3

ExampleCom は、2 つのサプライヤーサーバーと 3 つのコンシューマーサーバーを含むサーバートポロジーを作成することにしました。2 つのサプライヤーはそれぞれ、Directory Server のデプロイメント内の 3 つのコンシューマーをすべて更新します。

コンシューマーは、1 つのメッセージングサーバーと他のサーバーにデータを提供します。互換性のあるサーバーからの変更要求は、適切なコンシューマーサーバーにルーティングされます。コンシューマーサーバーは、スマートリファラルを使用して、変更されるデータのメインコピーを担当するサプライヤーサーバーへの要求をルーティングします。

8.1.5. ローカルエンタープライズのレプリケーション設計

ExampleCom は、ディレクトリーデータの高可用性を確保するために、マルチサプライヤーのレプリケーション設計を使用することを決定します。マルチサプライヤーレプリケーションの詳細は、マルチサプライヤーレプリケーション を参照してください。

マルチサプライヤーアーキテクチャー

ExampleCom は、マルチサプライヤーレプリケーションアーキテクチャーで 2 つのサプライヤーサーバーを使用します。サプライヤーが相互に更新することで、ディレクトリーデータの整合性が保たれます。次の図は、ExampleCom のサプライヤー - サプライヤーアーキテクチャーを示しています。

図8.4 ExampleCom マルチサプライヤーアーキテクチャー

dg ローカル企業の例 4

サプライヤーコンシューマーアーキテクチャー

以下の図は、ExampleCom のディレクトリーのデプロイメントで、サプライヤーサーバーが各コンシューマーにレプリケートする方法を示しています。

図8.5 ExampleCom サプライヤー - コンシューマーアーキテクチャー

dg ローカル企業の例 5

両方のサプライヤーサーバーが 3 つのコンシューマーサーバーを更新します。これにより、サプライヤーサーバーの 1 つに障害が発生しても、コンシューマーが影響を受けることはありません。

8.1.6. ローカル企業のセキュリティー設計

ディレクトリーデータを保護するために、ExampleCom は次のアクセス制御命令 (ACI) を作成します。

  • 従業員がエントリーを変更できるようにする ACI。ユーザーは、uidmanagerdepartment 属性を除くすべての属性を変更できます。
  • 従業員データのプライバシーを保護するために、従業員と従業員のマネージャーのみが従業員の自宅住所と電話番号を確認できる ACI。
  • ディレクトリーツリーのルートにある ACI は、2 つの管理者グループに適切なディレクトリーパーミッションを付与します。

    • ディレクトリー管理者グループは、ディレクトリーへのフルアクセスが必要です。
    • メッセージング管理者グループには、mailRecipient および mailGroup オブジェクトクラス、およびこれらのオブジェクトクラスで許可される属性 (mail 属性を含む) への write および delete アクセス権が必要です。ExampleCom は、メッセージング管理者グループに、メールグループを作成するためのグループサブディレクトリーへの writedelete、および add パーミッションも付与します。
  • ディレクトリーツリーのルートにある一般的な ACI で、readsearch、および compare アクセスに対する匿名アクセスを許可します。さらに、この ACI は匿名ユーザーによるパスワード情報へのアクセスを拒否します。
  • アカウンティングロールのメンバーにすべての給与情報へのアクセス権を与える ACI。

さらに、ExampleCom は次のセキュリティー対策を決定します。

  • サービス拒否攻撃や不適切な使用からサーバーを保護するために、ExampleCom は、ディレクトリークライアントがバインドに使用する DN に基づいてリソース制限を設定します。

    • 匿名ユーザーは、検索要求に応じて一度に 100 件のエントリーを受け取ることができます。
    • メッセージング管理者は 1,000 件のエントリーを受信できます。
    • ディレクトリー管理者は、無制限の数のエントリーを受け取ることができます。
  • ExampleCom は、長さが少なくとも 8 文字で、90 日後に期限切れになるパスワードのパスワードポリシーを作成します。

    パスワードポリシーの詳細は、パスワードポリシーの設計 を参照してください。

8.1.7. ローカルエンタープライズの運営上の決定

会社は、ディレクトリーの日常業務に関して次の決定を下します。

  • 毎晩、データベースをバックアップします。
  • SNMP を使用してサーバーの状態を監視します。
  • アクセスログとエラーログを自動でローテーションします。
  • エラーログを監視し、サーバーが想定どおりに実行されていることを確認します。
  • アクセスログを監視して、インデックスを作成できる検索を示します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.