Sun JavaTM System 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 アプリケーションに関する詳細な知識を持つと同時に、それらのアプリケーションを管理することのできる技術の専門家であり、Access Manager ポリシーエージェント (ポリシー適用ポイント) のアプリケーションへの統合を担当します。LOB アプリケーション管理者には、LOB アプリケーションのアーキテクチャー、統合ポイント、および適切なスケジュールに関する明確な意思伝達能力が必要です。通常、LOB アプリケーション管理者は、Access Manager ポリシーに示されるアクセス制御モデルの定義を担当します。この人物は、カスタムプログラミングを行って、Access Manager とそのアプリケーション (セッション調整など) 間の統合を拡張することもあります。さらに、通常は品質保証 (QA) および新たに配備された環境でのアプリケーションの回帰試験を担当します。
Access Manager を配備し、その可用性を維持する上で、適切なリソースが存在することは重要です。以下に示すレベルで、システム管理者が必要です。補助的な管理者には、Access Manager の配備先ソフトウェアコンテナの配備およびパフォーマンスを担当する Web コンテナ管理者も含まれます。
Access Manager 管理者は、Access Manager の配備と保守を担当します。この管理者は、共通サービスの可用性を保証し、一般的にインフラストラクチャーに必要な拡張を加え、特にポリシーとロールを設定します。また、ガイドラインを策定して統合作業のサポートに役立てるとともに、LOB アプリケーション管理者への技術サポートも行います。Java、XML、LDAP、HTTP、および Web アプリケーションアーキテクチャーの理解が必須です。
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 が組織に設定を許可する一般的な目標 (およびそのメリット) には、以下が含まれます。
予想されるデジタルアイデンティティー (従業員、パートナー、顧客) の増加に対応する、スケーラブルなインフラストラクチャーを実装する
アイデンティティープロファイルの作成および管理を、独自データを制御する各グループと統合する
ベンダーの統合、ユーザーの自己管理、および関連する管理コストによりコストを削減する
アイデンティティープロファイルの迅速な終了により、セキュリティーを改善する
セキュリティーモデルおよびアクセス権の透過性を改善する
クリティカルシステムへのアクセスに必要な時間を短縮する
組織内部のロールまたは連携が変更されたら、クリティカルシステムへのユーザー権限を削除する
最終的に、これらの目標を、関係するグループすべてのモチベーションの理解および実地調査から得られた情報と結び付けて、配備用のインフラストラクチャーの設計に使用できます。また、これらを配備プロセス全体で使用して、当事者の関係を維持し、プロジェクトの支持を得られるようにします。
実地調査を行い、配備に統合するアプリケーションやデータストアに関する情報を収集できます。さらに、これらの部門間の情報収集は、特定の機能および目標を定義し、関係するグループのモチベーションの理解を深めるのに役立ちます。収集が済んだら、情報を設計の青写真として、および経営権を持つスポンサーから確実な承認を得るために活用できます。実地調査の際、以下のグループの支援を得られます。
ユーザーは、日常業務で使用しているアプリケーションに関するフィードバックを提供する
人事担当者は、雇用および雇用終了処理に関する情報を提供する
サポート担当者は、組織の境界をまたがる問題に関して貴重な情報を提供する
アプリケーション管理者および開発者は、配備に統合する事業分野別 (LOB) アプリケーションに関する技術情報を提供できる
ネットワーク管理者は、組織のパフォーマンスや標準に関する技術的基盤の知識を保持している
初期調査には、次の項目に関する情報の収集が含まれます。
ビジネスプロセスとは、組織内のさまざまなグループがそれぞれの業務の実行を定義する手順です。プロセスには、次の手順を含めることができます。
給与の支給
購買および買掛金勘定
従業員の出張の承認
部門の予算管理
従業員の雇用終了
通常、これらのプロセスは、業務単位ごとに使用されるアプリケーションによりサポートされるため、これらのプロセスの評価は必須です。考慮すべき内容には、以下が含まれます。
現在のプロセスで遅延が発生するかどうか
同じ機能を実行する異なるプロセスが多数存在するかどうか
業務単位の境界をまたがってプロセスを標準化できるかどうか
プロセスはどの程度複雑か。プロセスを集約したり簡略化したりできるか
現在のプロセスで組織上の変更を処理できるか
プロセスに加える変更はすべて、配備を開始する前に行う必要があります。
IT インフラストラクチャーには、Access Manager の配備に統合されるすべてのハードウェアサーバー、オペレーティングシステム、および統合化アプリケーションが含まれます。次の点について考慮します。
Access Manager を利用するアプリケーション
アプリケーションには、人事および会計用のアプリケーションなどの重要な内部アプリケーション、またはあまり重要性の高くない従業員のポータルを含めることができます。また、Access Manager の機能を利用するアプリケーションとして、機密性の高い財務情報と機密性の高くない販売物資の両方を処理する外部 B2B アプリケーション、またはクレジットカードデータや購入履歴に関係する B2C のショッピングカートがあります。
Access Manager を利用するシステム
アプリケーションの配備先のハードウェアとそのオペレーティングシステムについて考慮してください。Access Manager の配備には、アプリケーションを実行するための Web コンテナ、Sun Java System Directory Server (または既存のデータストア)、および Access Manager が最低限含まれます。また、企業リソースを使用して独自の Web コンテナを実行する、追加のハードウェアサーバーが含まれることもあります。さらに、セキュリティーを向上させるために、そこに Access Manager ポリシーエージェントをインストールすることもできます。
各部門が利用する Access Manager のサービス
Access Manager 内に統合するデフォルトのサービスやカスタムサービスについて考慮します。ロールおよびポリシーの戦略は、部門ごとに割り当て、定義する必要があります。認証モジュールを評価する必要があります。カスタムサービスが存在する場合はそれを整備する必要があります。
さらに考慮する必要のある技術的な内容は、次のとおりです。
インフラストラクチャー内に非互換性が存在するかどうか
現在のシステムで性能低下やダウンタイムが発生しているかどうか
アプリケーションは十分にセキュリティー保護されているか
ウイルスを制御する手段が存在するか
アプリケーションは、ユーザーの資格に基づいてカスタマイズ可能か
詳細は、「アプリケーションの評価」を参照してください。
仮想データとは、Access Manager にアクセスするプロファイル、Access Manager からアクセス可能な設定、およびAccess Manager によってセキュリティー保護されるデータなど、あらゆる状況で利用されるデータを指します。仮想データには、ユーザープロファイル (従業員、顧客など)、データおよびサービスアクセスルール、およ びほかのタイプの企業データが含まれます。ただし、含まれるデータはこれだけに限定されるものではありません。
Access Manager で保護する対象
Access Manager は、すべての種類のデータおよびサービスへのアクセスをセキュリティー保護します。管理者は、Access Manager データの表示や設定が可能なユーザーを制限したり、アプリケーション、ポータル、およびサービスへのアクセスを制御できます。
Access Manager を利用するユーザー
ユーザーには、従業員、ビジネスパートナー、サプライヤ、現在の顧客、および潜在顧客が含まれます。各ユーザーが保持するプロファイルには、最低限、ユーザー ID とパスワードが含まれます。従業員は、外部の販売情報にアクセスする顧客よりも、明らかにより広範で機密性の高いプロファイルを保持します。
アクセス可能なデータ
データには、公開情報、内部情報、機密情報、秘密データなどが含まれます。さらに、外部 Web サイトの販売情報、従業員の機密プロファイル、企業のリソースを保護するアクセスルール、サーバー設定情報、連携顧客プロファイルなどが含まれる場合もあります。
信頼すべきデータの入手元
多くの場合、異なる種類のデータを定義する複数のスキーマが使用されます。これらの定義を、配備内で調和させる必要があります。データの所有権の問題を銘記しておき、必要な場合には、さまざまな LOB アプリケーションがデータの制御を維持できるようにしてください。より大規模な組織にはすべてのサービスが重要であるため、企業全体を代表するサービスを提供するために、サテライトグループの需要のバランスを取ることが重要です。
さらに考慮する必要のある技術的な内容は、次のとおりです。
複数の属性内で同じ情報が定義されているか
ユーザーは組織の境界をまたがる複数のプロファイルを保持しているか
データストアは、ファイアウォールの内側に存在するか
データは異なるデータストア間で一貫しているか
新規データが追加されたり、既存のデータが変更されたりする頻度はどれくらいか
詳細は、「データの分類」を参照してください。
アイデンティティー管理サービスは、一般に、拡張されたシステムを構成する企業および業務単位向けアプリケーションを備えた、集中管理された IT 機能として提供されます。このシステム階層の維持には、サーバーインフラストラクチャーを管理および保守するコア IT グループ、および LOB アプリケーションを保守する従業員のサテライトグループが関係します。
大規模な組織には、たいてい、数百 (または数千) の内部アプリケーションがあります。それらのすべてを評価するには時間と費用がかかります。アプリケーションの調査を実行する場合は、次の条件を満たすアプリケーションを集中的に調査してください。
組織にとって特に大きな価値を持つアプリケーション
シングルサインオンインフラストラクチャーへの統合で、メリットが期待されるアプリケーション
組織内部の標準的なプログラミングおよび配備プラットフォームを示すアプリケーション
通常、アイデンティティー管理インフラストラクチャーに受け入れられるアプリケーション
現在、配備の初期段階にあり、論理的に Access Manager の配備とスケジュールが一致する可能性のあるアプリケーション
スプレッドシートを作成すると、最も将来性の高いアプリケーションから得られた情報の整理に活用できます。全体的な測定基準を策定して、アプリケーション間の統合化の複雑性を比較できます。この測定基準により、アプリケーションがどの程度配備に適しているかを判断できます。適合性の高いアプリケーションの例は、セキュリティー目的で Access Manager ポリシーエージェントがインストールされたアプリケーションサーバーに認証を委任する Web アプリケーションです。すべてのユーザー情報は、LDAP ディレクトリに格納されます。
適合性の低いアプリケーションの例には、メインフレームコンピュータ上で動作する、テキストベースのインタフェースを備えたアプリケーションがあります。この場合、メインフレームアプリケーションの新しいバージョンを待つ間に、ほかのアプリケーションを統合する方が好都合です。
次の節では、組織のアプリケーションを評価する際に収集可能な情報の種類について説明します。この手順は、保護されるリソースを判別するのにも役立ちます。
既存のテクノロジおよびハードウェアに基づく一般的なプラットフォーム情報を使用して、アプリケーションが統合化に適切かどうかを評価できます。収集されるプラットフォーム情報には、次のものが含まれます。
アプリケーションが動作するオペレーティングシステム (バージョンを含む)
アプリケーションが動作する Web コンテナ (バージョンを含む)
アプリケーションの開発に使用したプログラミングモデル(Java、ASP/.NET、C など)
アプリケーションをアップグレードする計画があるかどうか。あるとすれば、そのスケジュールはいつか
LOB アプリケーションも、サードパーティー製のアプリケーション (ポータル、コンテンツ管理データベース、人事管理システムなど) を実行している場合があります。これらのアプリケーションが、Access Manager ポリシーエージェントでサポートされるプラットフォーム上に常に配備されているとは限りません。ポリシーエージェントが必要な場合は、これらのアプリケーションの配備基準を確認し、ポリシーエージェントの可用性に基づいてその配備のスケジュール設定を行ってください。
LOB アプリケーション内で使用する既存のセキュリティーモデルをドキュメント化しておくことは重要です。通常、外部の認証や承認を使用するアプリケーションは、外部のディレクトリサービスに依存するアプリケーションとともに、配備の候補になります。セキュリティー情報には、次のものが含まれます。
現在どの認証メカニズムを使用しているか
特殊な認証要件 (2 ファクター認証など) は存在するか
外部認証メカニズム用のプラグイン可能なインタフェースが存在するか
現在どの承認メカニズムを使用しているか
承認を外部で行うことは可能か (または、そうすべきか)
どのユーザーデータリポジトリを使用しているか。それを外部で行うことは可能か
誰がアプリケーションにアクセス可能か。既存のロールまたはグループが所定の位置に存在しているか。どのような特殊条件が存在する場合、彼らにアクセスが許可されるのか
アイデンティティーのセッションライフサイクルは、認証アプリケーションを評価する場合に考慮する重要な項目です。ユーザーセッションが作成、管理、および破棄される方法について明確に把握しておいてください。アプリケーションの統合時に参照できるよう、このプロセスを明確にドキュメント化してください。
アプリケーションにブランド設定やルックアンドフィールに関する特定の要件がある場合は、それについて検討します。多くの場合、アプリケーション単体のルックアンドフィールを重視するか、ユーザーにとって一貫した使い勝手を重視するかは重要な問題です。カスタマイズやブランド設定を行う場合は、そのための時間もスケジュールに組み込む必要があるため、アプリケーションの評価にその要件が含まれているかどうかを確認してください。
アプリケーションの分析と、その適切なレベルへの分類を完了したら、次に、これらのアプリケーションから提供されるデータおよびサービスの分類を開始する必要があります。この情報は、セキュリティーモデルの構築に使用されます。分類自体は、データおよびサービスを分類するプロセスです。それに続き、既存の認証および承認システムのカタログ作成が行われます。
この前者のプロセスに、アプリケーションの評価で収集された情報が使用されます。収集した情報をさまざまなセキュリティー層に編成するのは、良い方法です。これらの層は、データの紛失、アプリケーションの妥協的使用、誤用、その他の不正なアクセスタイプに関係したリスクの量を示すものとなります。正しく定義されたカテゴリを使用すると、リソースをセキュリティモデルにマッピングして、認証および承認要件を組み込む作業が簡単になります。
データまたはサービスは、4 つのセキュリティレベルに分類されます。X 軸はデータまたはサービス、Y 軸は関連付けられるセキュリティレベルを表します。層 1 は、セキュリティーが最小であることを示します。これは、公開された Web サイトに適用可能なデータです。一方、層 4 は、セキュリティーが最大であることを示します。これは財務や人事 (HR) データなどに適用されます。実際の組織の分類に使用される層はこれより多い場合も少ない場合もありますが、この図は、大量のデータには関連するリスクも低く、そのためセキュリティー要件も少なくなるという典型的な例を示しています。関連するリスクが大きくなるにつれ、セキュリティー要件も多くなります。通常、高度なセキュリティー要件が必要なデータはごくわずかであり、多くのデータはセキュリティー要件をほとんど必要としません。
次の図は、典型的な組織内のデータおよびサービスのセキュリティー要件を示しています。
認証および承認機能を割り当てることができるように、データおよびサービスタイプの機能グループを構築しようとしていることを念頭に置いてください。層の数が多すぎるとプロセスが過度に複雑になり、層の数が少なすぎると柔軟性に欠けたものになります。さらに、ネットワーク上に配置すること自体が非常に危険なデータもあることも考慮しておくことは重要です。可能な場合は、内部で利用可能なデータと外部で利用可能なデータを明確に区別するようにしてください。これらの層を構築する際、認証および承認要件とともに、データのアクセス時刻およびネットワーク上の位置などの修飾条件も念頭に置くようにしてください。
データをセキュリティーレベルに応じて分類できたら、次の段階は、認証および承認メカニズムの一覧を作成することです。利用可能な認証メカニズムに関する手持ちのリストを使用して、これらのメカニズムを定義済みのセキュリティー層に関連付けます。たとえば、次の関連付けは、前の図で分類されたデータに対応しています。
層 1 のデータは、アクセス制御なしの匿名認証が適切と考えられます。
層 2 のデータは、パスワード保護のみを必要とします。
層 3 のデータは、ハードトークンまたは証明書認証が必要です。
層 4 のデータは、マルチファクター認証を必要とします。または、ネットワーク上には絶対に配置しないようにします。
認証要件とデータやサービスの分類とのマッピングが、単純で明快なものであるようにしてください。そうでない場合、一致しない項目間で共通の基準を見つけるようにしてください。論理的な差異が存在するなら、ためらわずに複数の図を作成してください。
たとえば、イントラネットとエクストラネット用のアプリケーションでは、それぞれ別個の図を作成できます。また、人事 (HR) や財務などの機能セキュリティドメインに基づいて、データを分類することもできます。このようなデータ分類手法は万能とは言えませんが、セキュリティー要件を理解し、論理的に管理可能なグループにマッピングする場合に役立ちます。
アプリケーション評価により入手したデータを使用して各アプリケーションを検証し、スケーラブルな承認モデルを決定します。通常、最善の方法は、複数のアプリケーションにわたって使用する共通のグループやロールを見つけることです。これらのグループやロールが、組織内の機能ロールにマッピングされていると理想的です。また、これらのグループやロールのソース (メンバーシップデータの存在位置およびそのモデリング方法) を判別する必要もあります。たとえば、データは Sun Java System Directory Server 内に存在する可能性があります。
存在しない場合は、カスタムプラグインが必要になる場合があります。堅牢なグループモデルが存在する場合、最初に、各アプリケーションを既存のグループまたはロールに関連付けてください。存在しない場合は、最初にロールまたはグループメカニズムを計画し、機能的観点からユーザータイプ間の共通の関係を見つけてから、特定のアプリケーションにとりかかります。作業の完了時点で、以下のものが入手できます。
既存のグループおよびロールの明確なマッピング
データの存在する位置、その品質と管理に関する権限を持つ人物に関する明確な理解
配備を促進したり、配備のコストや複雑性を低減したりするために作成する必要のある新しいグループまたはロールについての明確な理解
既存および将来のグループメカニズムの、分類されたアプリケーションへのマッピング
特定のグループやロールへのアクセスを可能にするため、アプリケーションが必要とする追加条件に関する注意事項
この基本的なセキュリティーモデル (認証および承認メカニズムとの関連を利用したデータの分類) を使用して、配備を実行するスケジュールをまとめることができます。
収集した情報から、予備段階のスケジュールを作成する必要があります。次の節では、一般的な配備スケジュールを作成するための手順について説明します。
スケジュールのこの段階では、これまでに入手した概念、ビジネスニーズ、およびユーザー要件を適切なコンテキストに配置します。ここで、配備の全体像が明確になります。コンポーネントが記述され、技術要件が定義され、完成したアーキテクチャーが立案作成されます。この設計段階を開始する 2 つの方法は、ログイン時の画面案を作成すること、およびデータフローチャートを作成することです。
コンセプト証明を使用すると、設計をビジネス環境でテストできます。組織には、たいていの場合、期待される結果と一体になった設定済みの一連のテストケースである、テストケースデータベースが存在します。このテストデータベースには、コンセプト証明を適用できます。そして、すべてが順調に進めば、ドキュメント化された結果は新しい結果と等しくなります。コンセプト証明の目的は、「配備の設計」で提起されたすべての疑問に答えることにより、すべてのニーズを効果的に、最小限のリスクで満たせることを証明することです。
これは一般にすばやく実行されるため、限られたデータセットに基づいて設計を改良するための十分な時間を取ることができます。通常は、コンセプト証明とそれに続く設計改良を、数回繰り返す必要があります。最後に実行するコンセプト証明は、いくつかの内部アプリケーションが統合されたものになるはずです。企業の共有サービス統合は、一般に、初期採用者によるサインオン標準モデル、次に一般の参加者によるサインオン標準モデル、最後に残された者たちによるサインオン標準モデルに準拠したものになります。初期の採用者で成功すると、そのアプリケーションを一般の採用での参照用として使用しやすくなります。
ミッションクリティカルなアプリケーションや収益を創出するためのアプリケーションは、最初のアプリケーションとして選択すべきではありません。よりリスクの少ない戦略は、重要なアプリケーションの中でもロールアウト時に問題が発生しても企業運営に大きな混乱をきたさないものを選択することです。たとえば、部門ポータルは、会計年度末の会計システムよりも、シングルサインオン (SSO) ロールアウト用の拠点として適しています。
また、プロセスの弱点を排除し、結果が立証され、成功が迅速に認識されるように、初期段階でアプリケーションロールアウトの数を制限してください。最良のロールアウトの戦略は、可視性を最大限に高めながら、組織上のリスクを最小限に抑えることです。このため、製品に関する適切な経験を持つ配備チームがクリティカルアプリケーションを担当するようにします。
配備プロジェクトは単一のアプリケーションで始まりますが、多目的システムを構築できるように、他の内部顧客の要件も同時に評価する必要があります。中心的な IT グループは、より大規模な組織を代表するサービスを提供するため、サテライトグループのさまざまな基準およびスケジュールを受け入れることができなければなりません。スケジュールは十分に大きなウィンドウに表示し、サテライトグループが変更およびアップグレードを自分たちのアプリケーションの配備および品質保証 (QA) サイクルに組み入れる時間を取れるようにする必要があります。
コンセプト証明が終了したら、改良された設計を製品環境内にレプリケートできます。製品環境の目的は、通常の環境で設計の機能を実証し、正しく動作することを確認することです。この環境は、コンセプト証明で観察された動作、および配備設計で定義された動作と比較されます。このテストは、安定性を確認する目的でも行われます。
評価が行われ、レポートが生成されます。初期採用アプリケーションは、準備段階が完了しているため、製品環境でも稼働します。新規アプリケーションを、テスト段階から製品段階へ、徐々に移行させてゆきます。その他のアプリケーションは、初期採用と同じようにコンセプト証明サイクルで稼働させたあとで、徐々に製品環境に追加されていきます。
スケジュールはプロジェクトの複雑さに応じて変動するため、サンプルスケジュールは利用できません。ただし、このプロセスは通常、2 〜 3 か月の期間をかけて行われます。
Access Manager 統合を確実に成功させるには、詳細な計画が必要不可欠です。このプロセスには、ハードウェア、現在配備されているアプリケーション、アイデンティティーデータ、およびアクセス階層に関する情報の収集が含まれます。Access Manager の配備は、次の各段階に細分化できます。
次に示すようなビジネスの目的を特定する
業務効率を改善する
データのセキュリティーを確保する
組織内の範囲と関係を理解し、ビジネス目的のサポートに必要な行動の変化を分析することにより、確実に生産性を進展させる
ビジネス目的の達成に必要なテクノロジサービスおよびツールを列挙することによって、高度なテクノロジ分析を開発し、それをビジネスの目的に割り当てる
次に示すようなテクノロジサービスの具体策を定義する
パーソナライズにより蓄積された従業員の履歴およびデータを保管する
アイデンティティー管理を使用して、パスワード同期およびアイデンティティー管理を実行する
ロールの戦略を開発して、企業のセキュリティ保護を実現する
統計の精度、予測可能性、範囲、費用、影響、複雑性、行動、インフラストラクチャー、利点、サポート、依存関係などの項目に基づいて、各具体策に優先順位をつける