この節では、Identity Managerを実装するときの高レベルな策略的側面およびプロジェクト管理面についての概要を説明します。(技術的側面については、セクション 2.3, Identity Managerの実装に関する技術面の計画を参照してください)。
この計画用資料では、Identity Managerプロジェクトの始まりから、運用環境に完全に展開されるまでに通常、行うと想定されるアクティビティの概要が示されます。識別情報管理を導入する上では、環境内の要件と対象となるユーザを見極め、ソリューションを設計し、当事者の賛同を得た上で、十分にテストを行い、このソリューションを展開するということが不可欠です。この節の目的は、そのプロセスを十分に理解するための指針を示すことで、Identity Managerを最大限に活用できるようにすることです。
ソリューション展開時には、Identity Managerのエキスパートの参加を要請するよう強くお勧めします。パートナーオプションの詳細については、Novell PartnerNetのWebサイトを参照してください。Novellトレーニングでは、Identity Managerの実装を扱う各種コースもご提供しています。
この節は内容を完全に網羅しているわけではなく、可能性のあるすべての環境設定を扱うことや、そのまま実行に移すことを目的とはしていません。各環境は異なっており、使用するアクティビティの種類によって柔軟性を必要としています。
Identity Managerを展開するときのベストプラクティスとして、次のアクティビティが挙げられます。
Identity Managerの実装は、調査プロセスから始めるのが妥当です。調査プロセスでは次のタスクを行います。
調査を行うことにより、すべての関係者間で問題とソリューションについて共通の見解が得られます。ディレクトリ、Novell eDirectory、Novell Identity Manager、XML統合に関する基礎知識を、分析段階で関係者に周知することが求められます。調査プロセスは、そうした情報の理解に大変役立ちます。
調査により、そのすぐ後の手順を識別することもできます。たとえば、次の手順などがあります。
この分析フェーズでは、プロジェクトの技術およびビジネスの両方の側面について詳細に調べ、データモデルと高レベルなIdentity Managerアーキテクチャ設計を生成します。このアクティビティは、ソリューションを実装する上で非常に重要な、起点となる手順です。
設計の焦点は特に識別情報管理にありますが、ファイルおよび印刷など、従来リソース管理ディレクトリと関連付けられていた要素の多くも扱うことができます。次に示す各項目の例も参照してください。
要件分析の後、実装の範囲およびプロジェクト計画を確立して、あらかじめ必要なアクティビティを行う必要があるかどうかを決定できます。大幅な手戻りを未然に防ぐため、情報の収集と要件の文書化はできる限り徹底的に行ってください。
要件を検討することで、同時に次のタスクを完了できる場合があります。
組織のビジネスプロセスと、これらのビジネスプロセスを定義するビジネス要件を収集します。
たとえば、従業員の退職時のビジネス要件は、ネットワークおよび電子メールアカウントへのアクセス権を、その従業員の退職と同日に削除することです。
次のタスクは、ビジネス要件の定義を理解する上で役立ちます。
たとえば、特定のプロセスで何かが発生する場合、そのプロセスが原因で発生するのは何か。また、それによってトリガされる他のプロセスは何か。
特定の値が変更された場合、その値に従属関係があるかどうかを調べるのは重要なことです。特定のプロセスが変更された場合、そのプロセスに従属関係があるかどうか知っておくことも重要です。
たとえば、人事システムで従業員のステータス値として「臨時」を選択するには、制限された権限と特定の勤務時間のネットワークへのアクセス権を持つユーザオブジェクトを、IT部署がeDirectoryで作成する必要があることを意味しています。
関係者全員のすべての要求、要望を即座に満たせるわけではありません。プロビジョニングシステムの設計と展開の優先度を考慮することは、ロードマップを計画するのに役立ちます。
展開のある部分を先に実装して、展開の他の部分を後で実装することができるように、展開を複数のフェーズに分けることが役立つ場合があります。段階的な展開方法も同様に行うことができます。組織内のグループ別に行ってください。
展開の特定のフェーズを実行するのに必要な前提条件は、文書化する必要があります。これには、Identity Managerとのインタフェースになる接続システムへのアクセス権も含まれます。
システム管理者やマネージャが自分の担当範囲と考えている項目を早期に知ることが、関係者全員の同意を得て、円滑に作業を進めることにつながります。
たとえば、アカウント管理者には、特定のファイルおよびディレクトリに対する権限を従業員に付与するため、所有権が必要な場合があります。これは、アカウントシステムでローカルトラスティの割り当てを実装することにより行うことができます。
ビジネスプロセスの分析は、多くの場合アプリケーションやシステムを実際に使用するマネージャ、管理者、および従業員など、中心となる個人へのインタビューから始まります。想定される問題としては、次のようなものが上げられます。
たとえば、人事部のPeopleSoftシステムの管理者への質問として想定する場合、次のようなものが考えられます。
主要な人へのインタビューにより、プロセス全体をよりはっきりと把握できる、組織の他の領域を導き出すこともあります。
ビジネスプロセスの定義が完了した後は、現在のビジネスプロセスを反映するデータモデルの設計に着手できます。
モデルには、データの送信元、送信先、および送信不可能な場所を示す必要があります。重要なイベントがデータフローにどのような影響を与えるかも示す必要があります。
ビジネスプロセスの案と、そのプロセスで自動化されたプロビジョニングを実装する利点を示す図を開発することもできます。
モデルの開発は、次のような質問に回答することから始めます。
システム間のさまざまな値の相互関係について考慮することも重要です。
たとえば、PeopleSoftの従業員ステータスフィールドには、従業員、契約社員、およびインターンの3つの設定値があるとします。一方、Active Directoryシステムには、常駐および臨時の2つの値しかないとします。この場合では、PeopleSoftの「契約社員」ステータスと、Active Directoryの「常駐」および「臨時」の値との間の関係を決定する必要があります。
この作業の焦点は、各ディレクトリシステム、相互の関係、システム全体で同期する必要のあるオブジェクトおよび属性について理解することです。
このアクティビティを行うことで、会社のビジネスポリシーおよびデータフローを反映するサンプル実装を、テスト環境で実施できます。これは、要件分析および設計時に開発されたデータモデルの設計を基にし、運用準備段階の最終手順になります。
メモ:この手順を行うことで、管理サポートを得ることができ、最終的な実装作業を行う能力を培うことができます。
運用システム内のデータでは、品質と整合性が保たれない場合があるため、システムの同期時に不整合が発生する可能性があります。このフェーズでは、リソース実装チームと、統合されるシステム内のデータを「所有」、あるいは管理するビジネス単位またはグループとを分けるためのポイントが、明白になります。場合によっては、関連付けられたリスクとコストの要素が、1つのプロビジョニングプロジェクトには収まらない場合もあります。
このアクティビティの目的は、運用環境への移行を開始することです。このフェーズ中には、追加のカスタマイズが発生する可能性があります。この限定的な導入では、先行するアクティビティの期待される結果を確認でき、運用開始の合意を得ることができます。
メモ:このフェーズでは、ソリューションの受け入れ条件と、完全な運用までに必要なマイルストーンが得られる可能性があります。
このフェーズでは、運用展開の計画に移ります。計画では、次のことを行う必要があります。
このフェーズでは、運用環境で実際のデータ全体に対し、試験的なソリューションを拡張します。通常、運用準備がすべての技術的要件およびビジネス要件を満たしたという合意に基づいて行われます。