test

Sun Java System Access Manager 7 2005Q4 配備計画ガイド

第 2 章 Access Manager のためのビジネス分析

Sun JavaTM System Access Manager を使用すると、組織は、従業員、請負業者、顧客、およびサプライヤのためのアイデンティティー管理ソリューションを配備できます。ソリューションライフサイクルのビジネス分析段階では、ビジネス上の問題点を分析することでビジネス上の目標を定義し、その目標を達成するにあたってのビジネス要件とビジネス制約を明確にします。 この章で説明する内容は、次のとおりです。

ビジネス分析について

ビジネス分析は、ビジネス目標を明らかにすることから始まります。次に、解決が必要なビジネス上の問題を分析し、ビジネス目標を達成するために満たす必要のあるビジネス要件を特定します。また、目標の達成能力を制限するビジネス制約がある場合は、それらの制約についても考慮します。ビジネス要件とビジネス制約を分析することにより、一連のビジネス要件ドキュメントを作成します。

ここで作成された一連のビジネス要件ドキュメントを、技術要件段階で技術要件を導き出すための基盤として使用します。ソリューションライフサイクル全体にわたり、このビジネス分析段階で実施された分析に従って、配備計画、そして最終的にはソリューションが成功するかどうかを判定します。

Access Manager ビジネス要件の定義

ここでは、Access Manager のために考慮する必要のある特定のビジネス要件、つまり、Access Manager ソリューションに必要なビジネス要件について説明します。

Sun JavaTM System Access Manager は、複雑な分散型アイデンティティー管理システムであり、適切な配備によって、企業の組織にまたがる広範なデータおよびサービスへのアクセスがセキュリティー保護されます。企業リソースの適正な制御を確実にするため、配備プロセスの適切な計画が必要になります。この章では、配備の計画方法について説明します。次の節で構成されています。

リソースの定義

アイデンティティー管理ソリューションには、組織全体にわたる多様なシステムが関係するため、Access Manager を適切に配備するにはさまざまなリソースが必要になります。配備プロセスに関係する、または必要とされる企業のリソースを、以下に示します。

人事情報

組織内のさまざまな取引関係および政治的な関係を考慮する必要があります。直接的または多面的な報告体制を備えたチームを編成する必要があります。通常、Access Manager の配備は、1 人のプロジェクトマネージャーと数人の専任システム管理者で構成される小規模なチームで行われます。これらの人々は、チームリーダー、さらには多数の関連プロジェクトの責任を担うオーナーに報告を行います。また、経営権を持つスポンサーに直接報告することもよくあります。このグループは往々にして、Sun の技術リソースや、必要に応じて使用される LOB アプリケーション管理者で構成される仮想のチームメンバーによって増強されます。

この構成では実際のニーズと完全には一致しない可能性もありますが、ほぼ一般的な配備チームモデルを表しています。個々の役割を必ずしも明確に識別する必要はありませんが、さまざまなスキルセットを表す次の抽象技術ロールを使用することで、Access Manager の典型的な配備チームをさらに定義できます。

経営権を持つスポンサー

従来より、アイデンティティー管理の配備を成功させるには、組織的および政治的な境界を超えた企業の決定権を持つ人物の承認やサポートが必要です。このため、経営権を持つスポンサーが管理に関係することは重要です。プランニングのためのミーティングは、配備に関する既得権を保持する人物からの見識を得る上で重要なプロセスです。プロジェクト計画を策定する際、成果が全体としての企業目標に沿っていることを確認してください。たとえば、コスト削減が主な経営目標である場合、現在のアイデンティティー管理コストに関する統計を収集し、パスワードリセット関連のヘルプデスク利用コストなどのコストを判断します。具体的な統計が入手できれば、配備チームが経営陣のサポートを得るために必要な、明確な投資収益率 (ROI) の定義に役立ちます。関連するほかの問題には、以下が含まれます。

多くの場合、アイデンティティー管理の概念や Access Manager 配備の価値を、ほかの経営陣にも納得させることが必要になります。経営面および技術面の「エバンジェリスト」は、新しいインフラストラクチャーを経営陣に売り込み、統合化への要求を喚起したり、インフラストラクチャーの変更を受け入れさせて、最終的な成功を収めるのに寄与します。

チームリーダー

プロジェクトの成功に責任を持つ当事者として、チームリーダーを 1 人選ぶ必要があります。このチームリーダーは、プロジェクトの目標を達成するという責任を担い、そのための権限を持ちます。このチームリーダーは、テクニカルリーダー、プロジェクトマネージャー、執行責任者などに論理的に分散されたロールである場合があります。このロールをどのように定義するとしても、その目標は配備プロセスが着実に前進し、成功していることを示して、経営陣の支援を維持することです。

プロジェクト管理

プロジェクトマネージャーは、スケジュールの調整を担当します。また、利用可能なサービス、コア IT グループの提供するサポート、およびさまざまな事業分野 (LOB) のアプリケーション統合に関連するスケジュールを管理します。この役割を担う担当者は、優れたコミュニケーション能力を持ち、企業の政治的側面を理解できる必要があります。プロジェクトマネージャーはまた、環境に追加される新規アプリケーションが円滑に機能するために、内部顧客のニーズとリソースの利用状況とのバランスを取る必要もあります。

LOB アプリケーションは、組織の運営に欠かすことのできないものです。通常、これらは、データベースおよびデータベース管理システムとの接続機能を持つ大規模なプログラムです。会計、サプライチェーン管理、およびリソース計画アプリケーションがこれに含まれます。現在、LOB アプリケーションは、ユーザーインタフェースを備えたネットワークアプリケーションや、電子メールや住所録などの個人向けアプリケーションとの接続機能を持つようになりつつあります。

システムアナリスト

システムアナリストは、Access Manager 配備に統合されるさまざまなデータやサービスの評価および分類を担当します。システムアナリストは、LOB アプリケーションのオーナーにインタビューを行い、プラットフォーム、アーキテクチャー、およびその配備スケジュールの技術要件に関する詳細情報を収集します。システムアナリストは、この情報を使用して顧客の要件を満たすようにアプリケーションを配備に統合する方法を計画します。システムアナリストは、さまざまなアプリケーションのアーキテクチャーおよびプラットフォームに関する広範な知識を持つ、IT ゼネラリストでなければなりません。また、Access Manager のアーキテクチャー、サービス、エージェント、および API に関する詳細な知識も必要になります。

事業分野別 (LOB) アプリケーション管理者

LOB アプリケーション管理者は、LOB アプリケーションに関する詳細な知識を持つと同時に、それらのアプリケーションを管理することのできる技術の専門家であり、Access Manager ポリシーエージェント (ポリシー適用ポイント) のアプリケーションへの統合を担当します。LOB アプリケーション管理者には、LOB アプリケーションのアーキテクチャー、統合ポイント、および適切なスケジュールに関する明確な意思伝達能力が必要です。通常、LOB アプリケーション管理者は、Access Manager ポリシーに示されるアクセス制御モデルの定義を担当します。この人物は、カスタムプログラミングを行って、Access Manager とそのアプリケーション (セッション調整など) 間の統合を拡張することもあります。さらに、通常は品質保証 (QA) および新たに配備された環境でのアプリケーションの回帰試験を担当します。

システム管理者

Access Manager を配備し、その可用性を維持する上で、適切なリソースが存在することは重要です。以下に示すレベルで、システム管理者が必要です。補助的な管理者には、Access Manager の配備先ソフトウェアコンテナの配備およびパフォーマンスを担当する Web コンテナ管理者も含まれます。

Access Manager 管理者

Access Manager 管理者は、Access Manager の配備と保守を担当します。この管理者は、共通サービスの可用性を保証し、一般的にインフラストラクチャーに必要な拡張を加え、特にポリシーとロールを設定します。また、ガイドラインを策定して統合作業のサポートに役立てるとともに、LOB アプリケーション管理者への技術サポートも行います。Java、XML、LDAP、HTTP、および Web アプリケーションアーキテクチャーの理解が必須です。

Directory Server 管理者

Access Manager の配備を考慮する前から、認証および承認に使用される企業のディレクトリサービスが組織内のグループにより管理されていることがよくあります。Directory Server 管理者は、ディレクトリサービスの可用性の管理だけでなく、アイデンティティー管理インフラストラクチャーのサポートに必要な変更も含め、現在定義されているLDAP スキーマやアイデンティティーデータへの追加や変更の受け入れおよび統合も担当します。

ハードウェア、データセンター、ネットワーク管理者

大規模な組織は、通常、ハードウェア、オペレーティングシステム、データセンター、およびネットワーク管理をミドルウェア管理から切り離すことでスケールメリットを追求します。この種の企業の場合、これらの管理者間で明確に意思を疎通させることが重要になります。配備を成功させる上で、特定のマシンにアクセスできることや、特定のネットワーク構成を確立することが重要な場合があります。これらの管理者に常にプロジェクトの主要管理点や要件を意識させることで、スムーズなロールアウトが可能になります。

独立系ソフトウェアベンダー

Sun Microsystems およびほかの独立系ソフトウェアベンダー (ISV) は、Access Manager の配備を成功させる上で重要なパートナーです。パッケージソフトウェアを購入することで、企業は複数の組織にまたがるソフトウェア開発を行うコストとリスクを軽減および分散させることができます。

ISV は、1 つ以上のタイプのコンピュータハードウェアまたはオペレーティングシステムプラットフォームで実行可能な製品を製造および販売します。プラットフォームを製造する企業 (Sun、IBM、Hewlett-Packard、Apple、Microsoft など) は、ISV を支援 し、サポートを提供します。

ISV に関係する当事者すべてにとって最大の関心事は、協力関係を強化して配備を成功させることです。Sun テクニカルサービスやほかの ISV に働きかけ、プロジェクトの立ち上げの支援や、以前の Access Manager 配備で得た知識を提供してもらってください。対策チーム (Access Manager のエンジニアと配備チームとの仲介役として機能できる) と率直な討議を行うとともに、テクニカルサービスを利用すると、投資を有効に活用したり、配備を成功させるのに役立ちます。

提携先のサードパーティー

Access Manager の連携管理機能を活用することを計画している場合、外部パートナーや提携しているサードパーティーと共同して作業を行います。連携管理機能の初期配備を、独自の内部配備とともに考慮してください。この場合、重要なのは、提供するビジネス機能を保持する LOB アプリケーションを含めること、および当事者すべての技術リソースとの通信を管理することです。弁護士も、関係する当事者間の良好な関係を築く助けになります。

資金の調達

多くの場合、配備プロジェクトのコスト面の責任はコア IT グループが担います。実際、内部資金を LOB アプリケーションからコアグループに移して、アイデンティティー管理プロジェクトの資金の一部にあてるのが一般的な方法です。ただし、単一の LOB アプリケーショングループが内部資金を提供する場合でも、より大きな組織のニーズと資金調達グループのニーズとのバランスを取る必要があります。

目標の設定

組織は、目標を設定することにより、Access Manager 配備が完了したあとのあるべき 状態を定義します。配備の戦略とは、これらの目標に達するためのロードマップを計画し、目標に向かって進むことです。目標は、関係する当事者すべてが期待することを定義し、プロセスの初期にその承認を得て作成します。

一般に、アイデンティティー管理ソリューションでは、セキュリティーを拡張し、インフラストラクチャーの管理機能を向上させるとともに、コストを削減します。より具体的にいえば、Access Manager が組織に設定を許可する一般的な目標 (およびそのメリット) には、以下が含まれます。

最終的に、これらの目標を、関係するグループすべてのモチベーションの理解および実地調査から得られた情報と結び付けて、配備用のインフラストラクチャーの設計に使用できます。また、これらを配備プロセス全体で使用して、当事者の関係を維持し、プロジェクトの支持を得られるようにします。

情報の収集

実地調査を行い、配備に統合するアプリケーションやデータストアに関する情報を収集できます。さらに、これらの部門間の情報収集は、特定の機能および目標を定義し、関係するグループのモチベーションの理解を深めるのに役立ちます。収集が済んだら、情報を設計の青写真として、および経営権を持つスポンサーから確実な承認を得るために活用できます。実地調査の際、以下のグループの支援を得られます。

初期調査には、次の項目に関する情報の収集が含まれます。

ビジネスプロセス

ビジネスプロセスとは、組織内のさまざまなグループがそれぞれの業務の実行を定義する手順です。プロセスには、次の手順を含めることができます。

通常、これらのプロセスは、業務単位ごとに使用されるアプリケーションによりサポートされるため、これらのプロセスの評価は必須です。考慮すべき内容には、以下が含まれます。

プロセスに加える変更はすべて、配備を開始する前に行う必要があります。

IT インフラストラクチャー

IT インフラストラクチャーには、Access Manager の配備に統合されるすべてのハードウェアサーバー、オペレーティングシステム、および統合化アプリケーションが含まれます。次の点について考慮します。

さらに考慮する必要のある技術的な内容は、次のとおりです。

詳細は、「アプリケーションの評価」を参照してください。

仮想データ

仮想データとは、Access Manager にアクセスするプロファイル、Access Manager からアクセス可能な設定、およびAccess Manager によってセキュリティー保護されるデータなど、あらゆる状況で利用されるデータを指します。仮想データには、ユーザープロファイル (従業員、顧客など)、データおよびサービスアクセスルール、およ びほかのタイプの企業データが含まれます。ただし、含まれるデータはこれだけに限定されるものではありません。

さらに考慮する必要のある技術的な内容は、次のとおりです。

詳細は、「データの分類」を参照してください。

アプリケーションの評価

アイデンティティー管理サービスは、一般に、拡張されたシステムを構成する企業および業務単位向けアプリケーションを備えた、集中管理された IT 機能として提供されます。このシステム階層の維持には、サーバーインフラストラクチャーを管理および保守するコア IT グループ、および LOB アプリケーションを保守する従業員のサテライトグループが関係します。

大規模な組織には、たいてい、数百 (または数千) の内部アプリケーションがあります。それらのすべてを評価するには時間と費用がかかります。アプリケーションの調査を実行する場合は、次の条件を満たすアプリケーションを集中的に調査してください。

スプレッドシートを作成すると、最も将来性の高いアプリケーションから得られた情報の整理に活用できます。全体的な測定基準を策定して、アプリケーション間の統合化の複雑性を比較できます。この測定基準により、アプリケーションがどの程度配備に適しているかを判断できます。適合性の高いアプリケーションの例は、セキュリティー目的で Access Manager ポリシーエージェントがインストールされたアプリケーションサーバーに認証を委任する Web アプリケーションです。すべてのユーザー情報は、LDAP ディレクトリに格納されます。

適合性の低いアプリケーションの例には、メインフレームコンピュータ上で動作する、テキストベースのインタフェースを備えたアプリケーションがあります。この場合、メインフレームアプリケーションの新しいバージョンを待つ間に、ほかのアプリケーションを統合する方が好都合です。

次の節では、組織のアプリケーションを評価する際に収集可能な情報の種類について説明します。この手順は、保護されるリソースを判別するのにも役立ちます。

プラットフォームの情報

既存のテクノロジおよびハードウェアに基づく一般的なプラットフォーム情報を使用して、アプリケーションが統合化に適切かどうかを評価できます。収集されるプラットフォーム情報には、次のものが含まれます。

LOB アプリケーションも、サードパーティー製のアプリケーション (ポータル、コンテンツ管理データベース、人事管理システムなど) を実行している場合があります。これらのアプリケーションが、Access Manager ポリシーエージェントでサポートされるプラットフォーム上に常に配備されているとは限りません。ポリシーエージェントが必要な場合は、これらのアプリケーションの配備基準を確認し、ポリシーエージェントの可用性に基づいてその配備のスケジュール設定を行ってください。

セキュリティーモデル

LOB アプリケーション内で使用する既存のセキュリティーモデルをドキュメント化しておくことは重要です。通常、外部の認証や承認を使用するアプリケーションは、外部のディレクトリサービスに依存するアプリケーションとともに、配備の候補になります。セキュリティー情報には、次のものが含まれます。

セッションのライフサイクル

アイデンティティーのセッションライフサイクルは、認証アプリケーションを評価する場合に考慮する重要な項目です。ユーザーセッションが作成、管理、および破棄される方法について明確に把握しておいてください。アプリケーションの統合時に参照できるよう、このプロセスを明確にドキュメント化してください。

カスタマイズおよびブランド設定

アプリケーションにブランド設定やルックアンドフィールに関する特定の要件がある場合は、それについて検討します。多くの場合、アプリケーション単体のルックアンドフィールを重視するか、ユーザーにとって一貫した使い勝手を重視するかは重要な問題です。カスタマイズやブランド設定を行う場合は、そのための時間もスケジュールに組み込む必要があるため、アプリケーションの評価にその要件が含まれているかどうかを確認してください。

データの分類

アプリケーションの分析と、その適切なレベルへの分類を完了したら、次に、これらのアプリケーションから提供されるデータおよびサービスの分類を開始する必要があります。この情報は、セキュリティーモデルの構築に使用されます。分類自体は、データおよびサービスを分類するプロセスです。それに続き、既存の認証および承認システムのカタログ作成が行われます。

この前者のプロセスに、アプリケーションの評価で収集された情報が使用されます。収集した情報をさまざまなセキュリティー層に編成するのは、良い方法です。これらの層は、データの紛失、アプリケーションの妥協的使用、誤用、その他の不正なアクセスタイプに関係したリスクの量を示すものとなります。正しく定義されたカテゴリを使用すると、リソースをセキュリティモデルにマッピングして、認証および承認要件を組み込む作業が簡単になります。

データまたはサービスは、4 つのセキュリティレベルに分類されます。X 軸はデータまたはサービス、Y 軸は関連付けられるセキュリティレベルを表します。層 1 は、セキュリティーが最小であることを示します。これは、公開された Web サイトに適用可能なデータです。一方、層 4 は、セキュリティーが最大であることを示します。これは財務や人事 (HR) データなどに適用されます。実際の組織の分類に使用される層はこれより多い場合も少ない場合もありますが、この図は、大量のデータには関連するリスクも低く、そのためセキュリティー要件も少なくなるという典型的な例を示しています。関連するリスクが大きくなるにつれ、セキュリティー要件も多くなります。通常、高度なセキュリティー要件が必要なデータはごくわずかであり、多くのデータはセキュリティー要件をほとんど必要としません。

次の図は、典型的な組織内のデータおよびサービスのセキュリティー要件を示しています。

図 2–1 データおよびサービスのセキュリティー要件

データおよびサービスのセキュリティー要件

認証および承認機能を割り当てることができるように、データおよびサービスタイプの機能グループを構築しようとしていることを念頭に置いてください。層の数が多すぎるとプロセスが過度に複雑になり、層の数が少なすぎると柔軟性に欠けたものになります。さらに、ネットワーク上に配置すること自体が非常に危険なデータもあることも考慮しておくことは重要です。可能な場合は、内部で利用可能なデータと外部で利用可能なデータを明確に区別するようにしてください。これらの層を構築する際、認証および承認要件とともに、データのアクセス時刻およびネットワーク上の位置などの修飾条件も念頭に置くようにしてください。

認証へのマッピング

データをセキュリティーレベルに応じて分類できたら、次の段階は、認証および承認メカニズムの一覧を作成することです。利用可能な認証メカニズムに関する手持ちのリストを使用して、これらのメカニズムを定義済みのセキュリティー層に関連付けます。たとえば、次の関連付けは、前の図で分類されたデータに対応しています。

認証要件とデータやサービスの分類とのマッピングが、単純で明快なものであるようにしてください。そうでない場合、一致しない項目間で共通の基準を見つけるようにしてください。論理的な差異が存在するなら、ためらわずに複数の図を作成してください。

たとえば、イントラネットとエクストラネット用のアプリケーションでは、それぞれ別個の図を作成できます。また、人事 (HR) や財務などの機能セキュリティドメインに基づいて、データを分類することもできます。このようなデータ分類手法は万能とは言えませんが、セキュリティー要件を理解し、論理的に管理可能なグループにマッピングする場合に役立ちます。

承認へのマッピング

アプリケーション評価により入手したデータを使用して各アプリケーションを検証し、スケーラブルな承認モデルを決定します。通常、最善の方法は、複数のアプリケーションにわたって使用する共通のグループやロールを見つけることです。これらのグループやロールが、組織内の機能ロールにマッピングされていると理想的です。また、これらのグループやロールのソース (メンバーシップデータの存在位置およびそのモデリング方法) を判別する必要もあります。たとえば、データは Sun Java System Directory Server 内に存在する可能性があります。

存在しない場合は、カスタムプラグインが必要になる場合があります。堅牢なグループモデルが存在する場合、最初に、各アプリケーションを既存のグループまたはロールに関連付けてください。存在しない場合は、最初にロールまたはグループメカニズムを計画し、機能的観点からユーザータイプ間の共通の関係を見つけてから、特定のアプリケーションにとりかかります。作業の完了時点で、以下のものが入手できます。

この基本的なセキュリティーモデル (認証および承認メカニズムとの関連を利用したデータの分類) を使用して、配備を実行するスケジュールをまとめることができます。

スケジュールの作成

収集した情報から、予備段階のスケジュールを作成する必要があります。次の節では、一般的な配備スケジュールを作成するための手順について説明します。

配備の設計

スケジュールのこの段階では、これまでに入手した概念、ビジネスニーズ、およびユーザー要件を適切なコンテキストに配置します。ここで、配備の全体像が明確になります。コンポーネントが記述され、技術要件が定義され、完成したアーキテクチャーが立案作成されます。この設計段階を開始する 2 つの方法は、ログイン時の画面案を作成すること、およびデータフローチャートを作成することです。

コンセプト証明

コンセプト証明を使用すると、設計をビジネス環境でテストできます。組織には、たいていの場合、期待される結果と一体になった設定済みの一連のテストケースである、テストケースデータベースが存在します。このテストデータベースには、コンセプト証明を適用できます。そして、すべてが順調に進めば、ドキュメント化された結果は新しい結果と等しくなります。コンセプト証明の目的は、「配備の設計」で提起されたすべての疑問に答えることにより、すべてのニーズを効果的に、最小限のリスクで満たせることを証明することです。

これは一般にすばやく実行されるため、限られたデータセットに基づいて設計を改良するための十分な時間を取ることができます。通常は、コンセプト証明とそれに続く設計改良を、数回繰り返す必要があります。最後に実行するコンセプト証明は、いくつかの内部アプリケーションが統合されたものになるはずです。企業の共有サービス統合は、一般に、初期採用者によるサインオン標準モデル、次に一般の参加者によるサインオン標準モデル、最後に残された者たちによるサインオン標準モデルに準拠したものになります。初期の採用者で成功すると、そのアプリケーションを一般の採用での参照用として使用しやすくなります。

初期採用

ミッションクリティカルなアプリケーションや収益を創出するためのアプリケーションは、最初のアプリケーションとして選択すべきではありません。よりリスクの少ない戦略は、重要なアプリケーションの中でもロールアウト時に問題が発生しても企業運営に大きな混乱をきたさないものを選択することです。たとえば、部門ポータルは、会計年度末の会計システムよりも、シングルサインオン (SSO) ロールアウト用の拠点として適しています。

また、プロセスの弱点を排除し、結果が立証され、成功が迅速に認識されるように、初期段階でアプリケーションロールアウトの数を制限してください。最良のロールアウトの戦略は、可視性を最大限に高めながら、組織上のリスクを最小限に抑えることです。このため、製品に関する適切な経験を持つ配備チームがクリティカルアプリケーションを担当するようにします。

一般の参加

配備プロジェクトは単一のアプリケーションで始まりますが、多目的システムを構築できるように、他の内部顧客の要件も同時に評価する必要があります。中心的な IT グループは、より大規模な組織を代表するサービスを提供するため、サテライトグループのさまざまな基準およびスケジュールを受け入れることができなければなりません。スケジュールは十分に大きなウィンドウに表示し、サテライトグループが変更およびアップグレードを自分たちのアプリケーションの配備および品質保証 (QA) サイクルに組み入れる時間を取れるようにする必要があります。

製品環境

コンセプト証明が終了したら、改良された設計を製品環境内にレプリケートできます。製品環境の目的は、通常の環境で設計の機能を実証し、正しく動作することを確認することです。この環境は、コンセプト証明で観察された動作、および配備設計で定義された動作と比較されます。このテストは、安定性を確認する目的でも行われます。

評価が行われ、レポートが生成されます。初期採用アプリケーションは、準備段階が完了しているため、製品環境でも稼働します。新規アプリケーションを、テスト段階から製品段階へ、徐々に移行させてゆきます。その他のアプリケーションは、初期採用と同じようにコンセプト証明サイクルで稼働させたあとで、徐々に製品環境に追加されていきます。

スケジュールはプロジェクトの複雑さに応じて変動するため、サンプルスケジュールは利用できません。ただし、このプロセスは通常、2 〜 3 か月の期間をかけて行われます。

配備ロードマップ

Access Manager 統合を確実に成功させるには、詳細な計画が必要不可欠です。このプロセスには、ハードウェア、現在配備されているアプリケーション、アイデンティティーデータ、およびアクセス階層に関する情報の収集が含まれます。Access Manager の配備は、次の各段階に細分化できます。

  1. 次に示すようなビジネスの目的を特定する

    • 業務効率を改善する

    • データのセキュリティーを確保する

    • 組織内の範囲と関係を理解し、ビジネス目的のサポートに必要な行動の変化を分析することにより、確実に生産性を進展させる

  2. ビジネス目的の達成に必要なテクノロジサービスおよびツールを列挙することによって、高度なテクノロジ分析を開発し、それをビジネスの目的に割り当てる

  3. 次に示すようなテクノロジサービスの具体策を定義する

    • パーソナライズにより蓄積された従業員の履歴およびデータを保管する

    • アイデンティティー管理を使用して、パスワード同期およびアイデンティティー管理を実行する

    • ロールの戦略を開発して、企業のセキュリティ保護を実現する

  4. 統計の精度、予測可能性、範囲、費用、影響、複雑性、行動、インフラストラクチャー、利点、サポート、依存関係などの項目に基づいて、各具体策に優先順位をつける