|
| Sun ONE Directory Server 5.2 配備ガイド |
ビジネス上の課題
ExampleBank 銀行は国際的な銀行で、顧客と従業員に電子バンキングと電話バンキングの機能を提供しようとしています。顧客は、たとえば、口座残高の確認、同一銀行内または他行への振り替え、投資ポートフォリオの確認、管理者行員との打ち合わせの設定、オンラインニュースの表示、プロファイル情報の変更などを期待しており、行員は、自宅から業務へのログイン、銀行電話帳の検索、プロファイル情報の変更、電話バンキングサービスを使用する顧客から依頼される振り替えの実行を望んでいます。ExampleBank 銀行のビジネス上の課題は、特定範囲の銀行サービスへのアクセスを次の条件でユーザー (顧客と従業員) に提供することです。
- 危険にさらされることのないセキュリティ
- 優れた性能
- スケーラビリティ
- 管理容易性
ExampleBank 銀行は、このビジネス上の課題を克服するために、銀行業務配備の基盤として Sun ONE Directory Server 5.2 を配備しました。ExampleBank のユーザーが、ポータル経由または電話経由で銀行のオンラインシステムへの認証を行うたびに使用される、ユーザー認証データとプロファイルデータは、すべて Directory Server に保持されます。次の配備例は、ExampleBank 銀行が電子バンキングと電話バンキングのビジネス目標を達成するために、Directory Server をどのように実装したかを詳細に説明しています。説明する内容は次のとおりです。
配備コンテキストとレプリケーショントポロジ
配備コンテキスト
ExampleBank の配備では、電子バンキングサービスと電話バンキングサービスの両方を提供し、両サービスへの認証はセキュリティ保護され、管理が容易で、迅速かつスケーラブルである必要があります。ExampleBank は、両タイプのサービスへのアクセスに、次に説明する同一の製品群を使用します。
ExampleBank の電子バンキング機能にアクセスするユーザーは、主に Sun ONE Portal Server を使用します。ポータルは、ExampleBank の容易なログイン管理に必要なシングルサインオンソリューションを提供する Sun ONE Identity Server と組み合わされた Sun ONE Web Server で実行されます。ExampleBank は、Directory Server の操作フローの負荷分散と透過的なフェイルオーバーを行うサーバー群へのリフェラルを管理できる Sun ONE Directory Proxy Server を、配備の次のスタックにディレクトリプロキシサーバーとして配備しました。配備スタックの最後に Directory Server が配置されます。ここには、銀行業務に必要なユーザープロファイルと認証データが格納されます。
電話バンキング機能を利用する ExampleBank ユーザーは、指定の番号に電話をかけ、口座番号と電話バンキングの暗証番号を入力します。特別な電話バンキング認証モジュールが Directory Server にアクセスして口座番号を検索し、暗証番号が正しいかどうかを検証します。正しい場合は、電子バンキング担当者を呼び出します。
図 9-1 は、ExampleBank の銀行業務向け配備スタックを示しています。
図 9-1 ExampleBank の銀行業務向け配備スタック
レプリケーショントポロジ
ここでは、ExampleBank のレプリケーション戦略について次の内容を説明します。
レプリケーショントポロジの概要
ExampleBank には、ニューヨークとパリに 2 つの主要データセンターがあります。サービスには 1 日 24 時間アクセスできる必要があり、ローカル書き込みフェイルオーバーも必要であるため、各データセンターでマスターのペアを持つレプリケーション設計が採用されました。ExampleBank の 2 つの大陸にまたがる 4 方向のマスターレプリケーショントポロジは、Sun ONE Directory Server 5.2 の新機能である WAN 経由の 4 方向マルチマスターレプリケーションによって可能になりました。負荷を分散するために、このレプリケーショントポロジにはハブも含まれ、各データセンターの 4 つのコンシューマによって読み取り (検索) 操作のスケーラビリティが確保されます。図 9-2 は、別の大陸にある ExampleBank の 2 つのデータセンターのレプリケーショントポロジを示しています。
図 9-2 ExampleBank の 2 つのデータセンターのレプリケーショントポロジ
図 9-2 は、マスターとハブ、ハブとコンシューマの間のレプリケーションアグリーメント (デフォルトで有効化されます) を示しています。また、マスター 1 と 3、マスター 2 と 4 の間の復元レプリケーションアグリーメントも示されます。これは、マスターがオフラインになった場合に有効化されます。Sun ONE Directory Server 5.2 では、最初にレプリケーションアグリーメントを設定し、後から必要に応じて有効化または無効化できるので、トポロジに柔軟性が得られます。これにより、復元の準備が可能になるだけでなく、必要であればネットワーク使用量の最適化や、一時に送信される変更の数の最小化も可能になります。
注 データセンター間のリンクには、可用性を最適化するために複数の WAN 接続を使用することをお勧めします。
障害と復元
配備に影響するいくつもの障害が発生する可能性があります。ネットワークリンクに関連するものに限っても、Directory Server プロセス (slapd)、ハードウェア、レプリケーション障害、過度の読み取りまたは書き込み操作によるシステムへの過度な負荷などが挙げられます。必要な復元ソリューションが提供されるようにレプリケーショントポロジを設定することが重要です。
1 つのマスターがオフラインになった場合であれば、図 9-2 に示されるように、適切な復元レプリケーションアグリーメントを有効化するだけで解決できます。1 つのデータセンターで 2 つのマスターが同時にオフラインになった場合は、いくつかのオプションが考えられます。1 つの復元ソリューションは、障害が発生していないデータセンターの 1 つのマスターと、障害が発生しているデータセンターの 1 つのハブの間で、事前に設定されているレプリケーションアグリーメントを有効化する方法です。もう 1 つの復元ソリューションは、Sun ONE Directory Server 5.2 のオンラインでのレプリカ昇格、降格機能を使用する方法です。障害が発生しているデータセンターの 1 つのハブをマスターに昇格させ、障害が発生したマスターがオンラインに戻るまでローカルな書き込み要求を担当させます。レプリケーショントポロジの例、障害からの復元、バックアップ戦略については、第 10 章「アーキテクチャ戦略」を参照してください。レプリケーションの手順に関する情報については、『Sun ONE Directory Server 管理ガイド』の「Managing Replication」の章を参照してください。
パフォーマンス要件
電子バンキングと電話バンキングの実行可能性は、操作の処理速度に大きく依存するため、ExampleBank の配備では、パフォーマンスは非常に重要です。優れたパフォーマンスに加え、ExampleBank では年率 6% の予定成長率を前提にオンラインバンキングのスタックをスケーラブルにする必要もあります。Directory Server は、両方の要件に対応できます。
ここでは、ExampleBank のパフォーマンス要件について説明します。説明する内容は次のとおりです。
ユーザーからの要求
ExampleBank の現在のユーザーベースには 1,000 万人のユーザーが登録され、そのうち 10,000 人が従業員です。表 9-1 は、従業員ユーザーと顧客ユーザーの要件を示しています。これらの要件に基づいて、ExampleBank はオンラインバンキングが 1 秒間に処理する必要のある書き込みと読み取りの回数を計算します。
上の表で説明したトランザクションは、表 9-2 に示される LDAP 操作に変換されます。
表 9-2 ユーザーの要求と LDAP 操作の関係
ユーザーからの要求
対応する LDAP 操作
ログイン
検索 + バインド + 検索
銀行トランザクション
検索 + 変更
残高照会
LDAP 操作ではない
プロファイル変更
検索 + 変更
検索
検索
上記条件から、ExampleBank は次の検索、バインド、変更操作に対応する必要があることがわかります。
- 687 回の検索操作
- 197 回のバインド操作
- 98 回の変更操作
ハードウェアのガイドライン
この例のように、中規模から大規模の配備として位置付けられる配備では、基本的に次のような構成のハードウェアをお勧めします。
- 8 CPU
- 32 〜 64G バイトの RAM
- RAID 構成の それぞれが 655G バイトの 3 ディスクアレイで、たとえば、次のように設定する
- 最初のアレイにデータベース
- 第 2 アレイにトランザクションログ
- 第 3 アレイに変更ログ、アクセスログ、エラーログ
スキーマ、データ、ディレクトリ情報ツリーの設計
ここでは、ExampleBank のスキーマ、データ、ディレクトリ情報ツリーの設計について詳しく説明します。説明する内容は次のとおりです。
- スキーマ
- データ
- ディレクトリ情報ツリー
注 ここで紹介するスキーマとディレクトリ情報ツリーは実装例であり、完全または確実な情報ではありません。Sun ONE Identity Server と Sun ONE Portal Server はいくつかのオブジェクトクラスと属性を必要とします。詳細については、Sun ONE Identity Server と Sun ONE Portal Server のマニュアルを参照してください。
スキーマ
ExampleBank では、ユーザープロファイル、電子バンキングサービス、電話バンキングサービスを表わすスキーマが必要です。ここでは、このスキーマについて説明します。説明する内容は次のとおりです。
属性
ExampleBank は、ebStatus 属性を使用して属性レベルだけで顧客と従業員を区別します。次の 2 つの表は、ユーザープロファイル、バンキングサービス、追加のポートフォリオ管理バンキングサービスに関連する属性を示しています。
表 9-3 は、基本的なユーザープロファイル属性を示しています。
ExampleBank のユーザープロファイル属性に加え、表 9-4 に示される属性は、特定のユーザーでどの ExampleBank サービスが有効化されているかどうかを指定します。
オブジェクトクラス
ディレクトリ内のエントリは、inetOrgPerson オブジェクトクラスの次に ebPerson オブジェクトクラスから継承されます。ExampleBank は、次の表に示されるオブジェクトクラスを使用します。
データ
前述のスキーマに基づくサンプルコンテナは、次のようになります。
dn: dc=eb,dc=com
objectclass:top
objectclass:organization
dc: eb
o:ExampleBank
dn: ou=people, dc=eb,dc=com
ou:people
description: Customers and employees of ExampleBank
objectclass:top
objectclass: organizationalunit
objectclass: example-am-managed-org-unitExampleBank 銀行の従業員である Bill Smith は、電子バンキングサービスと電話バンキングサービスの両方が有効化されていると仮定します。しかし、口座へのアクセスは主に Web 経由で行うため、Bill Smith は電話による残高確認と住所変更を残してその他の電話バンキングサービスを無効にするように求めました。この場合のサンプルエントリは次のようになります。
dn:ebid=123456789,ou=people,dc=eb,dc=com
objectclass:top
objectclass:person
objectclass:organizationalPerson
objectclass:inetOrgPerson
objectclass:ebPerson
objectclass:ebEBankingUser
objectclass:ebPhoneBankingUser
objectclass:example-am-web-agent-service
objectclass:example-am-managed-person
objectclass:example-am-user-device
objectclass:inetuser
objectclass:examplePreferences
objectclass:inetOrgPerson
objectclass: sunPortalDesktopPerson
objectclass: sunPortalNetmailPerson
ebid:123456789
displayname:Bill Smith
userPassword:{SSHA}Ek12JHYZ87op9645==
uid: 123456789
inetuserstatus: active
sn:Smith
givenname:William
cn:William F. Smith
mail:Bill.Smith@eb.com
telephonenumber:+1-256-556-5896
facsimiletelephonenumber:+1-256-556-5897
ebStatus:employee
ebAreaCode:CA-17B
ebPreferedLanguage:en
ebSecondaryLanguage:fr
ebCheckingsAccountNumber:133003300
ebSavingsAccountNumber:233003300
ebPhoneBankingEnabled:active
ebPhoneBankingPin:123456
ebEBankingEnabled:active
ebNewsletterSubscription:active
ebNewsletterType:email
ebEBankingCheckBalanceEnabled:active
ebEBankingIntraBankTransfersEnabled:active
ebEBankingInterBankTransfersEnabled:active
ebEBankingChangeProfileEnabled:active
ebEBankingPortfolioManagementEnabled:active
ebEBankingLoanServicesEnabled: inactive
ebPhoneBankCheckBalanceEnabled:active
ebPhoneBankingLoanServicesEnabled: inactive
ebPhoneBankIntraBankTransfersEnabled:inactive
ebPhoneBankInterBankTransfersEnabled:inactive
ebPhoneBankChangeProfileEnabled:active
ebPhoneBankPortfolioManagementEnabled:inactiveディレクトリ情報ツリー
組織変更が頻繁に行われる ExampleBank 銀行では、データの階層構造を連鎖反応から保護するために、比較的フラットなディレクトリ情報ツリー構造を採用しました。図 9-3 に示されるように、情報ツリーの異なる部分に従業員、顧客、パートナー企業を配置したことで、それぞれの違いが明確になりました。
図 9-3 ExampleBank のディレクトリ情報ツリー
それぞれの分岐に異なるセキュリティポリシーを適用できるため、顧客、従業員、パートナー企業を分けて配置することは、ExampleBank にとってセキュリティ上の理由からも求められます。また、この区分は検索の負荷が少なく、操作も容易で、アクセス制御管理の向上と合わせてパフォーマンスの最適化と使い勝手の向上にも役立ちます。
注 図 9-3 のディレクトリ情報ツリーは、既存のディレクトリ構造がないことが前提で選択された設計を反映しています。多くの企業では、o=enterprise、o=customer、o=partner レベルを含まないディレクトリ構造を保有している可能性があり、このようなディレクトリツリーを作成するには、ディレクトリ構造を改造するための多大な労力と関連オーバーヘッドが必要になるかもしれません。しかし、それ以後のパフォーマンスおよび使い勝手の向上を考えると、これは価値のある投資であるといえます。
ディレクトリ情報ツリーとグループメカニズムによるユーザー管理だけでなく、ExampleBank は Sun ONE Directory Server 5.2 がサポートするロール機能の実装も選択しました。Directory Server のロール機能を使用することで、ユーザーを意味のあるユーザーセットに割り当て、アクセス制御、アカウントロックアウト、パスワードポリシーなどの Directory Server のその他の機能で内部的に使用するだけでなく、電話バンキングや ExampleBank が実装する人事アプリケーションなどの外部アプリケーションでも使用できます。
表 9-8 は、ユーザー管理のために ExampleBank が実装できるロールを示しています。もちろんこれは完全なリストではありません。管理機能を活用しようとする ExampleBank が、電話バンキングサービスと電子バンキングサービスに関連するユーザーをどのようにロールとしてグループ化するかについて考えるための出発点です。
表 9-8 に示されるロールは、それぞれの所属に応じてディレクトリ情報ツリーの o=enterprise、o=customer、o=partner 分岐の ou=people サブツリーの下に配置されます。これは、ロールとロール内の属性に対するアクセス権を持つロールマネージャエントリによって管理されます。このロールマネージャエントリは、o=enterprise の下に配置されます。各ロールとロールマネージャのアクセス権は、アクセス制御によって管理されます。
コード例 9-1 は、ldif ファイル内の信頼されている貢献者ロールのエントリを示しています。このロールの機能がどのように実装されるのかをより詳細に示しています。
この信頼されている貢献者ロールのすべてのメンバーに、電話帳データに対する読み取り、検索、比較アクセス権を与えるアクセス制御は、コード例 9-2 に示されるように、o=enterprise,dc=ExampleBank,dc=com の下に指定されます。
注 このロール機能の範囲拡張は、Directory Server 5.2 の新機能です。Sun ONE Identity Server 6.0 はこの新機能を認識しません。
図 9-4 は、ロール設定のグローバルビューと、それがどのようにディレクトリ情報ツリー構造に組み込まれているかを示しています。
図 9-4 ExampleBank のロール、ロールマネージャ、およびサンプルエントリ
セキュリティ上の注意点
金融業界では、危険にさらされないセキュリティを提供することが成功の鍵となります。オンラインバンキング配備スタックの一部に Directory Server を使用することで、ExampleBank はチャンネルの保護、データに対するアクセスの制御、保管中機密データの暗号化、柔軟なパスワードポリシーの提供、SSL 接続の最適化において、最適なセキュリティを提供できます。
ここでは、ExampleBank のセキュリティポリシーについて次の内容を説明します。
通信チャンネルのセキュリティ保護
ExampleBank の第一の責務は、配備スタック内要素間のすべての通信チャンネルを確実にセキュリティ保護することです。このために、ExampleBank はデータ転送を確実にセキュリティ保護する SSL を実装します。さらに、証明書ベースの認証を行う SSL (Secure Sockets Layer) プロトコルを使用する通信のパフォーマンスを向上するために、ExampleBank は Directory Server 5.2 の新機能である Sun Crypto アクセラレータボードを利用します。Sun Crypto アクセラレータボードのインストール方法と設定方法については、『Sun ONE Directory Server インストールおよびチューニングガイド』の付録 B 「Using the Sun Crypto Accelerator Board」を参照してください
保管中データのセキュリティ保護
第二の責務は、暗証番号などの、保管中の機密データを最大限に保護することです。ExampleBank は、Sun ONE Directory Server 5.2 の属性暗号化機能を使用してデータを保護します。この属性暗号化機能では、どの属性を暗号化形式で格納するかを ExampleBank が決定できます。この機能は、データベースレベルで設定されます。つまり、ExampleBank が属性の暗号化を決定すると、データベース内のすべてのエントリでその属性が暗号化されます。暗号化された上で格納されている属性には、適用された暗号化アルゴリズムを示す暗号化方式タグが最初につけられます。DES 暗号化アルゴリズムを使用して暗号化された属性は、次のように表示されます。
{DES}3hakc&jla+=snda%
セキュリティの面では、実際の暗号化がエントリレベルではなく属性レベルで行われるため、エントリ全体を暗号化するには、ExampleBank はそのエントリのすべての属性を暗号化しなければならない、ということが重要です。また、属性暗号化の目的は保管中の機密データの保護であるため、属性暗号化は常に可逆的であることにも注意してください。つまり、暗号化された属性は、検索要求の結果として返されるときは復号化されるため、通信チャンネルを SSL でセキュリティ保護する必要があります。
Sun ONE Directory Server 5.2 の属性暗号化機能、ExampleBank が必要とするレベルのセキュリティを提供します。この機能では、サーバーの SSL 証明書の秘密鍵を使用して専用の鍵が作成され、暗号化と復号化にはこの鍵が使用されます。このため、ExampleBank は暗号化とさらに重要な復号化を行う前に、鍵を生成するために SSL 設定を行う必要があります。Directory Server の属性暗号化機能が NSS ライブラリに基づいていることは、ExampleBank にさらに有利に働きます。さまざまな暗号化アルゴリズムを選択することが可能となり、異なるプラットフォーム間での可搬性も保証されます。
パスワード認証のセキュリティ保護
ExampleBank のユーザーは従業員、顧客、契約業者、パートナー企業で、全員がサードパーティ製のシングルサインオンアプリケーションを通じてオンラインバンキングスタックへの認証を行います。ExampleBank の希望は、契約業者などの一部のユーザーのパスワードポリシーをより厳しくし、顧客と従業員に適用されるパスワードポリシーをより緩いものとすることでした。サードパーティ製シングルサインオンアプリケーションが Sun ONE Directory Server 5.2 の複数パスワードポリシー機能を利用することで、この希望はかなえられます。指定したユーザーまたはユーザーセットに個別にパスワードポリシーを定義することができます。ユーザーセットに適用するパスワードポリシーを割り当てる一般的な方法は、CoS 定義を設定し、ユーザーエントリが持つロールの機能として、ユーザーエントリ内の passwordPolicySubentry 属性に値を指定する方法です。
このため、ExampleBank はユーザーのセキュリティ要件に合わせてパスワードポリシーを調整できるだけでなく、すでに定義されているロールを使用することでパスワードポリシーを簡単に管理できます。
実装
Sun ONE Directory Server オンラインバンキングスタックを世に送り出すことは、大規模な事業であり、広範な計画、分析、組織的なサポートを必要とします。
実装前に、試験的なディレクトリ作成と実装の概要について、『Understanding and Deploying LDAP Directory Services』 (T. Howes、M. Smith、G. Good 著、Macmillan Technical Publishing 発行、1999 年) を参照することを強くお勧めします。
実装は複雑であるため、段階的なアプローチが必要です。次に、このアプローチの概要を説明します。実装では、時間の経過とともに論理段階が切り替わります。これらの段階は、およそ次のようになります。
- ディレクトリインフラストラクチャの分析と計画
この段階では、Directory Server インフラストラクチャの機能要件とビジネス要件を評価、分析します。この分析は、システムのカスタマイズまたは拡張に必要な機能の特定に役立ちます。既存の実装の運用環境を技術面から見直すことで、提案されているハードウェアおよびネットワーク環境でのスケーラビリティ、パフォーマンス、信頼性に関する潜在的な問題を特定できます。
上の分析に基づいて高度なアーキテクチャ定義が行われ、推奨されるサイズ、スケーリング、パフォーマンス、物理的な分散、レプリケーションとリフェラル、セキュリティ、フェイルオーバー、バックアップ、他のデータソースとの同期、認証メカニズムはこの段階で決定されます。
- ディレクトリインフラストラクチャの設計と構築
第 2 段階では、Sun ONE と ExampleBank プロジェクトチームの設計者が共同でコアオンラインバンキング配備スタックを設計、構築します。この段階で重要なアクティビティには、サーバーのサイズと配置の決定、サーバーの設定、既存のバックエンドアプリケーションとディレクトリインフラストラクチャの統合、配備プロセスと管理プロセスの計画、追加の必要機能の特定が含まれます。
- コアディレクトリインフラストラクチャの実装
この段階では、Sun ONE はコアディレクトリインフラストラクチャを運用環境に実装、配備します。設定と管理に関する適切な技術指導および教育が提供されることが重要です。プロジェクトチームは、Sun ONE と共同でエンドユーザーに与える影響を評価し、必要な連絡とトレーニングの計画を策定します。
- E2E (Enterprise to Employee) 機能の有効化
最初に有効にする機能は、E2E (Enterprise to Employee) 機能です。通常、この準備では次の作業が行われます。
- LDAP アクセス可能ユーザーリストの作成
- 認証ソースのマッピングとユーザーデータのクリーンアップ
- 標準 ID の自動生成
- フラグによるアカウントの停止
- LDAP アプリケーションの有効化
- イントラネットアプリケーションによる認証
上のような操作環境が整ったら、E2E 機能の詳細を設定します。別のデータリポジトリとのリンクを自動化し、段階的な拡張を行います。パスワード同期などのセキュリティ要件も解決します。
最終段階直前のこの段階では、すべての Web アプリケーションとバックエンドアプリケーションで、スケーラブルなシングルサインオンアーキテクチャを利用できるようにすることを目指します。次に、実装テストを行います。このテストには、統合、パフォーマンス、E2E 機能の否定テストとユーザー承認テストを含める必要があります。適切なトレーニングと連絡を準備するために、シングルサインオンアーキテクチャに関連するエンドユーザーへの影響をもう一度評価します。
プラットフォームの Web アプリケーションとバックエンドアプリケーションのシングルサインオンが Directory Server インフラストラクチャで有効化されたら、企業内の他のアプリケーションとビジネスグループの同様の E2E 機能の実装に役立つように、プロジェクトチームは手順を文書化します。
- コア Directory Server インフラストラクチャの拡張による追加共通サービスのサポート
目的は、追加の共通サービスおよび機能のサポートを拡張し続け、さらなる E2E、B2B (Business to Business)、B2C (Business to Consumer) などの要件に対応することです。各部署でビジネス要件が決定、承認された時点で、B2B や B2C に固有の機能を定義、設計、実装します。
このように、Directory Server の配備スタックを公開する作業は簡単なものではありません。最適な実装のためにも、Sun ONE Professional Service との連携を強くお勧めします。Sun ONE Professional Service の連絡先は、http://jp.sun.com/service/sunps/sunone/ です。