10.2. 設計の例: 多国籍企業とそのエクストラネット
この例では、Example Corp. 用のディレクトリーインフラストラクチャーを構築します。国際。前述の例の Example Corp. は、大規模な多国籍企業に成長しました。この例は、Example Corp. の最後の例で作成されたディレクトリー構造に基づいて構築されており、新しいニーズに合わせてディレクトリー設計を拡張しています。
Example Corp. は、アメリカ、ヨーロッパ、アジアの 3 つの主要地域に広がる組織に成長しました。Example Corp. には現在 20,000 人を超える従業員がおり、その全員が Example Corp. のオフィスがある国に住んで働いています。Example Corp. は、社内コミュニケーションを改善し、Web アプリケーションの開発とデプロイメントを容易にし、セキュリティーとプライバシーを強化するために、全社的な LDAP ディレクトリーを開始することを決定しました。
国際企業のディレクトリーツリーを設計するには、ディレクトリーエントリーを論理的に収集する方法、データ管理をサポートする方法、およびグローバルスケールでのレプリケーションをサポートする方法を決定する必要があります。
さらに、Example Corp. は、部品サプライヤーと取引先が使用するエクストラネットを作成したいと考えています。エクストラネット は、企業のイントラネットを外部クライアントに拡張したものです。
以下のセクションでは、Example Corp. 向けに多国籍ディレクトリーサービスとエクストラネットをデプロイするプロセスの手順について説明します。国際。
10.2.1. 多国籍企業のデータ設計
Example Corp.International は、サイト調査を行うためのデプロイメントチームを作成します。デプロイメントチームは、サイトサーベイから以下を決定します。
- メッセージングサーバーは、ほとんどの Example Corp. のサイト向けに、電子メールルーティング、配信、および読み取りサービスを提供するために使用されます。企業サーバーは、ドキュメント公開サービスを提供します。すべてのサーバーは Red Hat Enterprise Linux 7 で実行されます。
- Example Corp. は、データをローカルで管理できるようにする必要があります。たとえば、ヨーロッパのサイトは、ディレクトリーのヨーロッパのブランチを管理します。これは、ヨーロッパが自身のデータのメインコピーに責任を持つということでもあります。
- Example Corp. のオフィスは地理的に分散しているため、ユーザーやアプリケーションが 24 時間ディレクトリーを利用できるようにする必要があります。
- データ要素の多くは、複数の異なる言語のデータ値に対応している必要があります。注記すべてのデータは UTF-8 文字セットを使用しています。他の文字セットは LDAP 標準に違反しています。
デプロイメントチームは、エクストラネットのデータ設計に関する以下についても決定します。
- パーツのサプライヤーは、Example Corp. のディレクトリーにログインして、Example Corp との契約を管理する必要があります。パーツのサプライヤーは、名前やユーザーパスワードなどの、認証に使用するデータ要素に依存します。
- Example Corp. のパートナーは、ディレクトリーを使用して、パートナーネットワーク内の人々の連絡先情報 (メールアドレスや電話番号など) を検索します。
10.2.2. 多国籍企業のスキーマ設計
Example Corp. は、エクストラネットをサポートするスキーマ要素を追加することにより、元のスキーマ設計に基づいて構築されています。Example Corp. は、exampleSupplier オブジェクトクラスと examplePartner オブジェクトクラスの 2 つの新しいオブジェクトを追加します。
exampleSupplier オブジェクトクラスでは、1 つの属性(
exampleSupplierID 属性)が許可されます。この属性には、Example Corp. によって割り当てられた一意の ID が含まれます。国際から、提携している各自動車部品サプライヤーへ。
examplePartner オブジェクトクラスでは、1 つの属性(
examplePartnerID 属性)が許可されます。この属性には、Example Corp. によって割り当てられた一意の ID が含まれます。各トレードパートナーへの International。
デフォルトのディレクトリースキーマのカスタマイズに関する詳細は、「スキーマのカスタマイズ」 を参照してください。
10.2.3. 多国籍企業のディレクトリーツリー設計
拡張された要件に基づいて、Example Corp. は以下のディレクトリーツリーを作成します。
- ディレクトリーツリーの root は、
dc=com接尾辞です。この接尾辞の下に、Example Corp. は 2 つのブランチを作成します。1 つのブランチdc=exampleCorp,dc=comには、Example Corp の内部のデータが含まれます。国際。他のブランチdc=exampleNet,dc=comには、エクストラネットのデータが含まれます。 - イントラネットのディレクトリーツリー(
dc=exampleCorp,dc=com)下)には、Example Corp. がオフィスを持つリージョンの 1 つに対応する 3 つの主要なブランチがあります。これらのブランチは、l（ローカリティー）属性を使用して識別されます。 dc=exampleCorp,dc=com下の各メインブランチは、Example Corp の元のディレクトリーツリー設計に似ています。各ローカリティーの下に、Example Corp. はou=people、ou=groups、ou=roles、およびou=resourcesブランチを作成します。このディレクトリーツリーの設計の詳細は、図10.1「Example Corp. のディレクトリーツリー」 を参照してください。dc=exampleNet,dc=comブランチの下に、Example Corp. は 3 つのブランチを作成します。サプライヤー用に 1 つのブランチ(o=suppliers)、Partner (Partner) (o=partners)用ブランチを 1 つ、および groups]-[ 用にブランチを 1 つ、および 1 つのブランチです。ou=groups- エクストラネットの
ou=groupsブランチには、エクストラネットの管理者のエントリーと、パートナーが自動検出したパーツの製造に関する最新情報をサブスクライブするメーリングリストのエントリーが含まれています。
以下の図は、上記の設計手順から得られる基本的なディレクトリーツリーを示しています。
図10.6 Example Corp. の基本的なディレクトリーツリーインド在外のお客様:
以下の図は、Example Corp. イントラネットのディレクトリーツリーを示しています。
図10.7 Example Corp. のディレクトリーツリーInternational のイントラネット
l=Asia エントリーのエントリーは、以下のように LDIF に表示されます。
dn: l=Asia,dc=exampleCorp,dc=com objectclass: top objectclass: locality l: Asia description: includes all sites in Asia
以下の図は、Example Corp. のエクストラネットのディレクトリーツリーを示しています。
図10.8 Example Corp. のディレクトリーツリーInternational のエクストラネット
10.2.4. 多国籍企業のトポロジー設計
この時点で、Example Corp. はデータベースおよびサーバートポロジーを設計します。以下のセクションでは、各トポロジーの詳細を説明します。
10.2.4.1. データベーストポロジー
以下の図は、Example Corp. の主要地域の 1 つであるヨーロッパのデータベーストポロジーを示しています。
図10.9 Example Corp. のデータベーストポロジーヨーロッパ
データベースリンクは、各国にローカルに保存されたデータベースを参照します。たとえば、Example Corp. から受信した操作リクエストなどです。
l=US ブランチ下のデータのヨーロッパサーバーは、オーストイン Texas 内のサーバー上のデータベースへのデータベースリンクによってチェーンされます。データベースリンクおよびチェーンの詳細は、「チェーンの使用」 を参照してください。
dc=exampleCorp,dc=com およびルートエントリーである dc=com のデータのメインコピーは、l=Europe データベースに保存されます。
ヨーロッパのデータセンターには、エクストラネットのデータのメインコピーが含まれます。エクストラネットデータは、メインのブランチごとに 1 つずつ、3 つのデータベースに保存されます。
o=suppliers のデータのメインコピーは 1 つ(DB1)に保存され、o=partners 用の ou=groups はデータベース 2 (DB2)に保存され、の場合はデータベース 3 (DB3)に保存されます。
エクストラネットのデータベースのトポロジーは以下のようになっています。
図10.10 Example Corp. のデータベーストポロジーInternational のエクストラネット
10.2.4.2. サーバートポロジー
Example Corp. は、企業イントラネット用とパートナーエクストラネット用の 2 つのサーバートポロジーを開発しています。
イントラネットの場合、Example Corp. は主要な地域ごとにサプライヤーデータベースを用意することにしました。つまり、3 つのデータセンターがあり、それぞれサプライヤーサーバー 2 台、ハブサーバー 2 台、およびコンシューマーサーバー 3 台が含まれます。
次の図は、Example Corp のアーキテクチャーを示しています。ヨーロッパのデータセンター:
図10.11 Example Corp. のサーバートポロジーヨーロッパ
Example Corp.のエクストラネットのデータサプライヤーはヨーロッパにあります。このデータは、米国のデータセンターにある 2 つのコンシューマーサーバーと、アジアのデータセンターにある 2 つのコンシューマーサーバーにレプリケートされます。全体として、Example Corp. はエクストラネットをサポートするために 10 台のサーバーを必要とします。
次の図は、ヨーロッパのデータセンターにある Example Corp. のエクストラネットのサーバーアーキテクチャーを示しています。
図10.12 Example Corp. のサーバートポロジーInternational のエクストラネット
ハブサーバーは、ヨーロッパ、米国、アジアの各データセンターにある 2 つのコンシューマーサーバーにデータを複製します。
10.2.5. 多国籍企業のレプリケーション設計
Example Corp. では、ディレクトリーのレプリケーションを設計する際に、以下の点を考慮しています。
- データはローカルで管理されます。
- ネットワーク接続の品質は、サイトごとに異なります。
- データベースリンクは、リモートサーバー上のデータを接続するために使用されます。
- データの読み取り専用コピーを含むハブサーバーは、コンシューマーサーバーにデータを複製するために使用されます。
ハブサーバーは、メールサーバーや Web サーバーなどの重要なディレクトリー対応アプリケーションの近くに配置されます。
ハブサーバーは、サプライヤーサーバーからレプリケーションの負担を取り除くため、サプライヤーサーバーは書き込み操作に集中できます。将来、Example Corp. が拡大し、さらに多くのコンシューマーサーバーを追加する必要がある場合、追加のコンシューマーがサプライヤーサーバーのパフォーマンスに影響を与えることはありません。
ハブサーバーの詳細は、「カスケードレプリケーション」 を参照してください。
10.2.5.1. サプライヤーアーキテクチャー
Example Corp. のイントラネットの場合、各地域はそのデータのメインコピーを格納し、データベースリンクを使用して他の地域のデータにチェーンします。データのメインコピーについては、各地域でマルチサプライヤーレプリケーションアーキテクチャーが使用されています。
次の図は、ヨーロッパのサプライヤーアーキテクチャーを示しています。これには、
dc=exampleCorp,dc=com および dc=com の情報が含まれます。
図10.13 Example Corp. のサプライヤーアーキテクチャーヨーロッパ
各地域には 2 つのサプライヤーが含まれており、そのサイトのデータのメインコピーを共有しています。したがって、各地域は、独自のデータのメインコピーを担当します。マルチサプライヤーアーキテクチャーを使用すると、データの可用性が確保され、各サプライヤーサーバーによって管理されるワークロードのバランスを取ることができます。
全体的な障害のリスクを軽減するために、Example Corp. では、各サイトで複数の読み書き可能なサプライヤーディレクトリーサーバーを使用しています。
以下の図は、ヨーロッパの 2 つのサプライヤーサーバーと、米国内の 2 つのサプライヤーサーバー間の対話を示しています。
図10.14 Example Corp. のマルチサプライヤーレプリケーション設計ヨーロッパと Example Corp.US
Example Corp. の間にも同じ関係が存在します。米国および Example Corp.アジア、および Example Corp. 間ヨーロッパと Example Corp.Asia.
10.2.6. 多国籍企業のセキュリティー設計
Example Corp.International は、以前のセキュリティー設計を基に、新しい多国籍イントラネットをサポートするために以下のアクセス制御を追加しました。
- Example Corp. は、一般的な ACI をイントラネットのルートに追加し、各国および各国の下の支社により制限の厳しい ACI を作成します。
- Example Corp. は、マクロ ACI を使用して、ディレクトリー内の ACI の数を最小限に抑えることにしました。Example Corp. はマクロを使用して、ACI のターゲットまたはバインドルール部分で DN を表します。ディレクトリーが着信 LDAP 操作を取得すると、ACI マクロは LDAP 操作の対象となるリソースと照合されます。一致する場合、マクロはターゲットリソースの DN の値に置き換えられます。マクロ ACI の詳細は、『Red Hat Directory Server Administrator's Guide』を参照してください。
Example Corp. は、自社のエクストラネットをサポートするために、以下のアクセス制御を追加します。
- Example Corp. は、すべてのエクストラネットアクティビティーに証明書ベースの認証を使用するかどうかを決定します。ユーザーがエクストラネットにログインする際には、デジタル証明書が必要となります。ディレクトリーは証明書を保存するために使用されます。ディレクトリーは証明書を保存するため、ディレクトリーに保存された公開鍵を検索することで、暗号化されたメールを送信することができます。
- Example Corp. は、エクストラネットへの匿名アクセスを禁止する ACI を作成します。これにより、サービス拒否攻撃からエクストラネットを守ることができます。
- Example Corp. は、Example Corp.がホストするアプリケーションのみから、ディレクトリーデータの更新を行うようにしています。つまり、エクストラネットを利用するパートナーやサプライヤーは、Example Corp. が提供するツールのみを利用できることを意味します。エクストラネットのネットユーザーを Example Corp. の推奨するツールに制限することで、Example Corp. の管理者は監査ログを使用してディレクトリーの使用状況を追跡することができ、Example Corp. 以外のエクストラネットのユーザーがもたらす可能性のある問題の種類を制限することができます。国際。
