|
| Sun ONE Directory Proxy Server 管理者ガイド |
第 2 章 Sun ONE Directory Proxy Server の配備例
利用しているコンピュータ環境に応じて、Sun ONE Directory Proxy Server をさまざまな方法で配備することができます。この章では、次のような代表的な配備について説明します。
- 高い可用性の社内構成
- 分散型の LDAP ディレクトリインフラストラクチャ
- 集中型の LDAP ディレクトリインフラストラクチャ
- 1 つのファイアウォールを使用した Directory Proxy Server の配備
- 2 つのファイアウォールによる Directory Proxy Server の配備
高い可用性の社内構成
図 2-1 は、LDAP インフラストラクチャを社内だけで使用するように配備した構成を示しています。この企業の LDAP サービスにアクセスするには、外部ネットワークは必要ありません。社内の LDAP サービスに対するファイアウォールの外部からのアクセスを拒否するように、企業ファイアウォールが配備されています。内部で発生するすべてのクライアント LDAP 要求は、(高可用性のために) Cisco LocalDirector を経由して Directory Proxy Server に入ります。Cisco LocalDirector は、クライアントが少なくとも 1 つの Directory Proxy Server にアクセスできるようにするための IP パケットスイッチの一例に過ぎません。Sun ONE Directory Proxy Server を実行しているホスト以外からは、誰もディレクトリサーバーに直接アクセスできません。この制限は、ディレクトリサーバーと Directory Proxy Server を実行しているホストをファイアウォールによって保護することで行われています。
図 2-1 高い可用性の社内構成
分散型の LDAP ディレクトリインフラストラクチャ
次に、分散型の LDAP ディレクトリインフラストラクチャで Directory Proxy Server が果たす役割について説明します。
事例の背景
図 2-2 は、ロンドンに本社があり、ロンドン、ニューヨーク、香港にデータセンターを持つ大手金融機関の構成を示しています。現在、従業員が利用するデータのほとんどは、ロンドンにある旧式の RDBMS リポジトリに格納されています。この金融機関のクライアントコミュニティからこのデータへのすべてのアクセスは、広域ネットワーク (WAN) を経由します。この金融機関は、この集中型のモデルのスケーラビリティとパフォーマンスに不満を感じており、分散型のデータモデルに移行することを決断しました。また、同時に LDAP ディレクトリインフラストラクチャの配備も決定しました。問題となっているデータは「ミッションクリティカル」であるとされており、高い可用性と耐障害性を持つインフラストラクチャに配備する必要があります。クライアントアプリケーションプロファイルを分析することで、ある地域別クライアントコミュニティによるデータへのアクセスの 95% は、そのコミュニティ自体に対するものであることが判明しました。これは、データが顧客ベースであるためです。アジアのクライアントが北米の顧客データにアクセスすることはほとんどありません。ただし、皆無ではありません。また、クライアントは顧客情報を随時更新する必要があります。
図 2-2 分散型の LDAP ディレクトリインフラストラクチャ
配備例
プロファイルの 95% がローカルデータアクセスであることから、この金融機関は LDAP ディレクトリインフラストラクチャを地域別に分散することにしました。複数のディレクトリコンシューマサーバーが各地域 (香港、ニューヨーク、ロンドン) に配備されます (この図にはロンドンのコンシューマサーバーは含まれません)。これらのコンシューマサーバーは、その地域の顧客データを保持するように設定されています。ヨーロッパと中東の顧客データはロンドンのコンシューマサーバーに格納され、北米と南米の顧客データはニューヨークのコンシューマサーバーに格納されます。アジアと太平洋地域の顧客データは香港のコンシューマサーバーに保持されます。この配備では、ローカルクライアントコミュニティが必要とするデータの大部分はそのコミュニティで保持されます。クライアント要求がローカルに処理されることになるため、集中型モデルと比較してパフォーマンスが大きく向上します。ネットワークのオーバーヘッドが減り、ローカルディレクトリサーバーが効率的にディレクトリインフラストラクチャをパーティション分割します。これにより、ディレクトリサーバーのパフォーマンスとスケーラビリティは向上します。コンシューマディレクトリサーバーの各セットは、クライアントが更新要求を送信した場合、またはクライアントがいずれかの場所に格納されているデータに対する検索要求を送信した場合にリフェラルを返すように設定されています。
LDAP 要求の流れ
クライアントからの LDAP 要求は、Cisco LocalDirector 経由で Sun ONE Directory Proxy Server に送信されます。この Cisco LocalDirector は、クライアントが少なくとも 1 つの Directory Proxy Server にアクセスできるようにするための IP パケットスイッチの一例に過ぎません。ローカル配備された Directory Proxy Server は、まず、すべての要求をローカル顧客データを保持するローカルディレクトリサーバーの配列にルーティングします。Directory Proxy Server のインスタンスは、配列に含まれるディレクトリサーバー間で負荷をバランスするように設定されており、フェイルオーバーとフェイルバックは自動的に行われます。ローカル顧客情報に対するクライアント検索要求は、ローカルディレクトリ内で処理が完了し、適切な応答が Directory Proxy Server 経由でクライアントに返されます。地域が異なる顧客の情報に対するクライアント検索要求は、Directory Proxy Server にリフェラルを返すことで、初期段階はローカルディレクトリサーバー内で完了します。
このリフェラルには、別地域に分散している Directory Proxy Server の適切なインスタンスをポイントする LDAP URL が含まれます。ローカル Directory Proxy Server は、ローカルクライアントの代わりにリフェラルを処理し、遠隔地の Directory Proxy Server の適切なインスタンスに対して検索要求を送信します。遠隔地の Directory Proxy Server は、検索要求を遠隔地のディレクトリサーバーに送信し、適切な応答を受信します。この応答は、遠隔地とローカルの Directory Proxy Server を経由してローカルクライアントに返されます。
ローカル Directory Proxy Server が受信する更新要求も、ローカルディレクトリサーバーがリフェラルを返すことで、その初期段階は内部的に完了します。この場合も、Directory Proxy Server がローカルクライアントの代わりにリフェラルを実行しますが、更新要求の場合は、ロンドンにあるサプライヤディレクトリサーバーが送信先となります。このサプライヤディレクトリは、サプライヤデータベースに更新を適用し、応答をローカル Directory Proxy Server 経由でローカルクライアントに返します。その後、サプライヤディレクトリサーバーは適切なコンシューマディレクトリサーバーに更新を伝達します。
すべての Sun ONE Directory Proxy Server は、起動時にそれぞれの設定情報をサプライヤディレクトリサーバーから検索するように設定されています。これにより、Directory Proxy Server の複数のインスタンスを分散しても、それぞれの設定を集中管理することができます。
集中型の LDAP ディレクトリインフラストラクチャ
次に、集中型の LDAP ディレクトリインフラストラクチャで Directory Proxy Server が果たす役割について説明します。
事例の背景
図 2-3 は、顧客と従業員が世界各地に分散している大規模な多国籍企業での配備例を示しています。この企業は企業電子電話帳を配備することで、紙媒体の電話帳を製作するコストを削減し、企業情報の精度を向上させ、環境資源を節約することを目指しています。電話帳情報は、適切なアクセス制御によって制限することで、顧客と従業員の両方に公開する必要があります。また、顧客と従業員が世界のさまざまなタイムゾーンに分散しており、1 日 24 時間、週に 7 日利用できる必要があるため、この電話帳はミッションクリティカルとして位置付けられています。
図 2-3 集中型の LDAP ディレクトリインフラストラクチャ
配備例
この企業は、電子電話帳を配備するために集中型の LDAP ディレクトリインフラストラクチャを配備することにしました。集中型の配備を選択したのは、この電子電話帳に登録される情報が、従業員に関する情報だけであるためです。これは顧客データベースではありませんが、配備の目的は、顧客が情報にアクセスできるようにすることにあります。予想されるディレクトリデータベースのサイズ (200,000 エントリ以下) では、スケーラビリティとパフォーマンスのどちらにも問題が生じることはないと予想され、より複雑な分散型の配備モデルは必要ないと判断されました。
高い可用性が要求されるため、単一のサプライヤディレクトリサーバーから複数のコンシューマディレクトリサーバーレプリカにデータを伝達する配備が選択されました。単一のサプライヤディレクトリサーバーがシングルポイント障害になるのを避けるため、この企業はバックアップのサプライヤディレクトリサーバーも配備しました。
Sun ONE Directory Proxy Server が配備されたのは、次の 3 つの理由からです。まず、すべての LDAP クライアントとディレクトリサーバーレプリカの配列の間で、ロードバランスと自動フェイルオーバーおよびフェイルバックを行うためです。次に、外部クライアントと内部クライアントを識別してそれぞれに適切なアクセス制御を設定するためです。最後に、電子電話帳を利用する LDAP クライアントとディレクトリサーバー自体との間で互換性を維持するためです。LDAP クライアントは、カスタム構築された電子電話帳アプリケーション以外にも、多数の市販 LDAP 対応アプリケーションを使用しており、これらのアプリケーションではスキーマ要件が固定されています。これらのスキーマ要件は、企業が設計したディレクトリスキーマと常に一致するとは限りません。このため、一部の基本的なスキーマ属性のマッピングが必要となります。さらに、クライアントが使用する LDAP 対応アプリケーションのすべてがディレクトリサーバーから受け取るリフェラルを正しく処理できるわけではありません。Sun ONE Directory Proxy Server は、クライアントの代わりにこれらのリフェラルを実行するように設定されました。
LDAP 要求の流れ
社内クライアント、社外クライアントを問わず、また、それが検索要求であるか、更新要求であるかを問わず、すべてのクライアント要求は、Cisco LocalDirector 経由で Directory Proxy Server のインスタンスに送信されます。この Cisco LocalDirector は、クライアントが少なくとも 1 つの Directory Proxy Server にアクセスできるようにするための IP パケットスイッチの一例に過ぎません。シングルポイント障害が発生しないように、Directory Proxy Server の複数のインスタンスが配備されています。Directory Proxy Server のインスタンスは、配列に含まれるすべてのコンシューマディレクトリの間で、クライアントから受け取ったすべての要求の負荷をバランスさせます。また、Directory Proxy Server はコンシューマサーバーの障害を検出し、配列内で利用可能なコンシューマサーバーにフェイルオーバーします。
コンシューマサーバーは読み取り専用のレプリカなので、クライアントから更新要求を受け取った場合は LDAP リフェラルを返すように設定されています。このリフェラルには、サプライヤディレクトリサーバーをポイントする LDAP URL が含まれます。ディレクトリサーバーがリフェラルを返すと、Directory Proxy Server はそれを認識し、クライアントに代わってそのリフェラルを実行します。Directory Proxy Server はサプライヤディレクトリサーバーにバインドし、更新要求を送信します。このサプライヤディレクトリは、サプライヤデータベースに更新を適用し、Directory Proxy Server 経由でクライアントに応答を返します。その後、サプライヤディレクトリサーバーは適切なコンシューマディレクトリサーバーに更新を伝達します。
クライアントから送信された検索要求は、Directory Proxy Server 経由でコンシューマディレクトリサーバーレプリカの配列にルーティングされます。Sun ONE Directory Proxy Server は、検索要求をディレクトリサーバーに送信する前に、これらの要求を「検査」し、特定のクライアントグループに設定されているアクセス制御規則とセキュリティ規則に違反する要求をフィルタリングして、必要なマッピングを行うように設定することができます。また、ディレクトリサーバーから返される検索結果を「検査」し、適切なフィルタリングとマッピングを行うように Directory Proxy Server を設定することもできます。図 2-3 の例では、社内と社外の両方のクライアントが「Trevor」に属するエントリの検索を要求しています。これらの要求は、Directory Proxy Server ではクライアントの種類に関係なく、同じように扱われます。ディレクトリサーバーは要求を正常に実行し、「Trevor」のエントリを Directory Proxy Server に返します。Directory Proxy Server は、要求の送信元が社内クライアントであるか社外クライアントであるかに応じて、検索結果に異なる処理を行うように設定されています。外部クライアントの場合は、エントリに含まれる携帯電話の番号と自宅の電話番号のフィールドは、顧客向けではないデータとしてフィルタリングされます。また、「ou: development」という属性と値のペアが、「department: development」にマッピングされることに注意してください。これは、クライアントがディレクトリへのアクセスに使用するアプリケーションの 1 つが (たとえば、Outlook、Outlook Express)、企業ディレクトリサーバーに配備されているスキーマ要素と一致しない固定スキーマ要素を持っているためです。社内クライアントの場合は、携帯電話の番号は重要なデータ要素として従業員間で共有されますが、自宅の電話番号は共有されないことになっています。このため、社内クライアントからの要求に対しては、Directory Proxy Server は自宅の電話番号だけをフィルタリングし、携帯電話の番号をクライアントに公開します。ここでも ou 属性が department 属性にマッピングされていることに注意してください。
すべての Sun ONE Directory Proxy Server は、起動時にサプライヤディレクトリサーバー内の設定を検索するように設定されています。これにより、複数の Directory Proxy Server の設定を 1 つのディレクトリから集中的に管理できます。
1 つのファイアウォールを使用した Directory Proxy Server の配備
企業のファイアウォールを図 2-4 のように構成し、LDAP クライアントだけが Directory Proxy Server が稼動するマシンとポートにアクセスできるように制限する必要があります。通常は、LDAP クライアントは TCP ポート 389 に接続します。これにより、未認証でアクセスしようとするクライアントから Directory Proxy Server を実行するホストが保護されます。また、ルータスイッチを使用して、Proxy Server を実行するホストを専用 LAN に設置することで、ネットワークを不要なトラフィックで満たすなどによるサービス拒否攻撃から社内ネットワークを保護することができます。ファイアウォールは、LDAP ディレクトリサーバーが「隠れて」いるマシンとポートに対する LDAP アクセスを拒否するように設定する必要があります。これにより、LDAP ディレクトリデータベースが保護されます。
図 2-4 1 つのファイアウォールによる Directory Proxy Server の設定
2 つのファイアウォールによる Directory Proxy Server の配備
図 2-5 の構成には、図 2-4 の構成のすべての利点のほかに、いくつかのセキュリティが追加されています。2 つのファイアウォールを設置することで、「プロキシ」の周囲に制御可能なゾーンができ、サイト管理者が、外部ネットワークからのトラフィックを制限できるようになります。また、いずれかの「プロキシ」が危険にさらされても、そこから社内ネットワークのその他のマシンを直接攻撃することができなくなります。ファイアウォール A は、宛先 IP アドレスが、TCP または UDP プロトコルを処理するプロキシのアドレスである場合にだけ受信パケットを受け付けるように設定します。ファイアウォール B は、アクセス先のサーバーがプロキシマシンに適している場合にだけ、そのプロキシからのパケットを受け付けるように設定します。
図 2-5 2 つのファイアウォールによる Directory Proxy Server の設定
