| Sun ONE Identity Server 配備ガイド |
第 2 章
配備の計画SunTM ONE Identity Server は、複雑な分散型アイデンティティ管理システムであり、適切な配備によって、企業の組織境界にまたがる広範なデータおよびサービスへのアクセスがセキュリティ保護されます。企業リソースの適正な制御を確実にするため、配備プロセスの適切な計画が必要になります。この章では、配備の計画方法について説明します。次の節で構成されています。
リソースの定義アイデンティティ管理ソリューションには組織全体の多種多様なシステムが関係するため、Identity Server を適正に配備するには広範なリソースが必要になります。配備プロセスに関係する、または必要とされる企業のリソースを、以下に示します。
人材
組織内のさまざまな取引関係および政治的枠組みに精通しておくことは重要です。直接的または多面的な報告体制を備えたチームを編成する必要があります。通常、Identity Server の配備は、1 人のプロジェクトマネージャおよび 数人の専任システム管理者で構成される小規模なチームで行われます。彼らは、チームリーダーおよび多数の関連プロジェクトの責任を担うオーナーに報告を行います。また、経営権を持つスポンサーに直接報告することもよくあります。チームは、Sun Professional Services リソースおよび必要に応じて段階的に投入および廃止される LOB アプリケーション管理者で構成される仮想チームメンバーにより、しばしば増強されます。これは、現実のニーズを満たすかどうかは別として、ほぼ一般的な配備チームモデルを表したものです。個々の役割を必ずしも明確に識別する必要はありませんが、さまざまなスキルセットを表す次の抽象技術ロールを使用することで、典型的な Identity Server 配備チームをさらに定義できます。
経営権を持つスポンサー
通常、アイデンティティ管理を成功させるには、組織および行政上の境界を超えて配備を行う必要があります。これには、企業の決定権を持つ人物の承認およびサポートが必要です。このため、経営権を持つスポンサーが管理に関係することは重要です。プランニングのためのミーティングは、配備に関する既得権を保持する人物からの見識を得る上で重要なプロセスです。プロジェクト計画を策定する際、成果が全体としての企業目標に沿っていることを確認してください。たとえば、コスト削減が主な経営目標である場合、パスワードリセット関連のヘルプデスク利用コストなどの、現在のアイデンティティ管理コストに関する統計を収集します。具体的な統計を入手することで、配備チームが経営陣のサポートを得るのに役立つ明確な ROI を定義できます。関連する他の問題には、以下が含まれます。
チームリーダー
プロジェクトの成功に責任を持つリーダーとして、1 人の人物を選ぶ必要があります。このチームリーダーは、プロジェクトの目標を達成するという責任を担い、そのための権限を持ちます。これは、テクニカルリーダー、プロジェクトマネージャ、および執行責任者などの間で論理的に分散されたロールとすることも可能です。このロールがどのように定義されるとしても、目標は配備プロセスが着実に前進し、成功していることを示して、経営陣の支援を維持することです。
プロジェクト管理
この担当者は、スケジュールの調整を行います。また、利用可能なサービス、コア IT グループの提供するサポート、およびさまざまな事業分野 (LOB) のアプリケーション統合に関連するスケジュールを管理します。この担当者は、優れたコミュニケーション能力と政治的手腕を持っていなければなりません。環境に追加される新規アプリケーションが円滑に機能するために、内部顧客のニーズとリソースの利用状況とのバランスを取る必要があります。
システムアナリスト
この人物は、Identity Server 配備に統合されるさまざまなデータやサービスの評価および分類を担当します。システムアナリストは、LOB アプリケーションのオーナーにインタビューを行い、プラットフォーム、アーキテクチャ、および配備スケジュールの技術要件に関する詳細情報を収集します。システムアナリストは、この情報を使用して、顧客の要件を満たす仕方でアプリケーションを配備に統合する方法を計画します。システムアナリストは、さまざまなアプリケーションのアーキテクチャおよびプラットフォームに関する広範な知識を持つ、IT ゼネラリストでなければなりません。Identity Server のアーキテクチャ、サービス、エージェント、および API に関する詳細な知識が求められます。
LOB アプリケーション管理者
これは、Identity Server ポリシーエージェントまたはポリシー実施ポイントをアプリケーションに統合する責務を担う人物です。LOB アプリケーション管理者には、LOB アプリケーションのアーキテクチャ、統合ポイント、および適切なスケジュールに関する明確な意思伝達能力が必要です。通常、LOB アプリケーション管理者は、Identity Server ポリシーに示されるアクセス制御モデルの定義を担当します。この人物は、カスタムプログラミングを行って、Identity Server とそのアプリケーション (セッション調整など) 間の統合を拡張することもあります。通常は、最後に QA および新たに配備された環境でのアプリケーションの回帰試験を担当します。このため、LOB アプリケーションに関する詳細な知識および制御能力を備えた、技術面の専門家でなければなりません。
システム管理者
Identity Server を配備し、その可用性を維持する上で、適切なリソースが存在することは重要です。以下に示すレベルで、システム管理者が必要です。補助的な管理者には、Identity Server の配備先ソフトウェアコンテナの配備およびパフォーマンスを担当する Web コンテナ管理者も含まれます。
Identity Server 管理者
この人物は、Identity Server の配備および保守を担当します。通常、専任のユーザーが割り当てられ、共通サービスの可用性の保証や、必要なインフラストラクチャの拡張、およびポリシーやロールの設定を行います。Identity Server 管理者は、ガイドラインを策定して統合化サポートを支援し、LOB アプリケーション管理者に技術サポートを提供します。Java、XML、LDAP、HTTP、および Web アプリケーションアーキテクチャの理解が必須です。
Directory Server 管理者
Identity Server の配備を考慮する前から、認証および承認に使用される企業のディレクトリサービスが組織内のグループにより管理されていることがよくあります。Directory Server 管理者は、定義されている LDAP スキーマおよびアイデンティティデータへの追加や変更を受け入れたり統合したりすると共に、ディレクトリサービスの可用性管理を担当します。アイデンティティ管理インフラストラクチャをサポートするために、ディレクトリサービスの変更が必要になることがあります。
ハードウェア/データセンター/ネットワーク管理者
大規模な組織は、通常、ハードウェア、オペレーティングシステム、データセンターや、ネットワーク管理をミドルウェア管理から切り離すことでスケールメリットを追求します。この種の企業の場合、これらのさまざまな管理者間で明快なコミュニケーションを行うことが重要になります。配備を成功させる上で、特定のマシンにアクセスすることや、特定のネットワークを確立することが重要な場合があります。これらの担当者にプロジェクトの里程標や要件を意識させることで、スムーズなロールアウトが可能になります。
独立系ソフトウェアベンダー
Sun Microsystems および他の独立系ソフトウェアベンダー (ISV) は、Identity Server の配備を成功させる上で重要なパートナーです。パッケージソフトウェアを購入することで、企業は複数の組織にまたがるソフトウェア開発を行うコストとリスクを軽減および分散させることができます。
ISV に関係する当事者すべてにとって最大の関心事は、協力関係を強化して配備を成功させることです。Sun プロフェッショナルサービスおよび他の ISV と契約を結んで、プロジェクトの立ち上げの支援や以前の Identity Server 配備で得た知識を提供してもらってください。アカウントチーム (Identity Server のエンジニアと配備チームとの仲介役として働くことができる) と率直な討議を行うと共に、プロフェッショナルサービスを利用すると、投資を有効に活用し、配備を成功させる助けが得られます。
提携先のサードパーティ
Identity Server の連携管理機能を活用することを計画している場合、外部パートナーや提携しているサードパーティと共同して作業を行います。連携管理機能の初期配備を、独自の内部配備と共に考慮してください。この場合、重要なのは、提供するビジネス機能を保持する LOB アプリケーションを含めること、および当事者すべての技術リソースとの通信を管理することです。弁護士も、関係する当事者間の公平な話し合いの場を設定する助けになります。
資金の調達
多くの場合、配備プロジェクトのコスト面の責任はコア IT グループが担います。実際、内部資金を LOB アプリケーションからコアグループに移して、アイデンティティ管理プロジェクトの資金の一部にあてるのが一般的な方法です。ただし、単一の LOB アプリケーショングループが内部資金を提供する場合でも、より大きな組織のニーズと資金調達グループのニーズとのバランスを取る必要があります。
目標の設定目標を設定することにより、Identity Server の配備完了後のあるべき状態を定義できます。配備の戦略とは、これらの目標に達するためのロードマップを計画し、目標に向かって進むことです。目標は、関係する当事者すべてが期待すること定義し、プロセスの初期にその承認を得て作成します。
一般に、アイデンティティ管理ソリューションでは、セキュリティを拡張し、インフラストラクチャの管理機能を向上させると共に、コストを削減します。より具体的にいえば、Identity Server が組織に設定を許可する一般的な目標 (およびそのメリット) には、以下が含まれます。
最終的に、これらの目標を、関係するグループすべてのモチベーションの理解および実地調査から得られた情報と結び付けて、配備用のインフラストラクチャの設計に使用できます。また、これらを配備プロセス全体で使用して、当事者の関係を維持し、プロジェクトの支持を得られるようにします。
情報の収集実地調査を行い、配備に統合するアプリケーションおよびデータストアに関する情報を収集できます。さらに、これらの部門インタビューは、特定の機能および目標を定義し、関係するグループのモチベーションの理解を深めるのに役立ちます。収集が済んだら、情報を設計の青写真として、および経営権を持つスポンサーから確実な承認を得るために活用できます。実地調査の際、以下のグループの支援を得られます。
初期調査には、ビジネスプロセス、IT インフラストラクチャ、および仮想データに関する情報収集を含めることができます。
ビジネスプロセス
ビジネスプロセスとは、組織内の異なるグループがそれぞれのジョブの実行を定義する手順です。プロセスには、次の手順を含められます。
通常、これらのプロセスは、業務単位ごとに使用されるアプリケーションによりサポートされるため、これらのプロセスの評価は必須です。考慮すべき内容には、以下が含まれます。
プロセスに加える変更はすべて、配備を開始する前に行う必要があります。
IT インフラストラクチャ
IT インフラストラクチャには、Identity Server の配備に統合されるすべてのハードウェアサーバー、オペレーティングシステム、および統合化アプリケーションが含まれます。
さらに考慮する必要のある技術的な内容は、次のとおりです
詳細は、「アプリケーションの評価」を参照してください。
仮想データ
仮想データは、Identity Server にアクセスするプロファイル用の、あらゆる状況で利用可能なデータです。このデータは、Identity Server からアクセス可能な設定でもあり、Identity Server によりセキュリティ保護されるデータでもあります。これには、ユーザープロファイル (従業員、顧客など)、データおよびサービスアクセスルール、および他のタイプの企業データが含まれます。ただし、含まれるデータはこれだけに限定されるものではありません。
さらに考慮する必要のある技術的な内容は、次のとおりです
詳細は、「データの分類」を参照してください。
アプリケーションの評価アイデンティティ管理サービスは、通常、拡張されたシステムを構成する企業および業務単位向けアプリケーションを使用する、集中化された IT 機能として提供されます。このシステム階層の維持には、サーバーインフラストラクチャを管理および保守するコア IT グループ、および LOB アプリケーションを保守する従業員のサテライトグループが関係します。大規模な組織には、たいてい、数百 (または数千) の内部アプリケーションが配備されています。それらのすべてを評価するには時間と費用がかかります。アプリケーションの調査を行う場合は、次のアプリケーションを集中的に調査してください。
スプレッドシートを作成して、最も将来性の高いアプリケーションから取得した情報の整理に活用できます。全体的な測定基準を策定して、アプリケーションの値を統合化の複雑性と比較できます。これにより、アプリケーションがどの程度配備に適しているかを判断できます。適合性の高いアプリケーションの例は、セキュリティ目的で Identity Server ポリシーエージェントがインストールされたアプリケーションサーバーに認証を委任する Web アプリケーションです。すべてのユーザー情報は、LDAP ディレクトリに格納されます。適合性の低いアプリケーションの例は、メインフレームに由来する「グリーンスクリーン」アプリケーション (テキストベースのインタフェースを持つアプリケーション) です。この場合、メインフレームアプリケーションの再ファクタリング/アーキテクチャの待機中に、他のアプリケーションを統合するというメリットを享受できます。次の節では、組織のアプリケーションを評価する際に収集可能な情報の種類について説明します。
プラットフォームの情報
既存のテクノロジおよびハードウェアに基づく一般的なプラットフォーム情報を使用して、アプリケーションが統合化の候補として適切かどうかを評価できます。収集されたプラットフォーム情報には、以下が含まれます。
セキュリティモデル
LOB アプリケーション内で使用する既存のセキュリティモデルをドキュメント化しておくことは重要です。通常、外部の認証や承認を使用するアプリケーションは外部のディレクトリサービスに依存するため、配備の有力な候補になります。セキュリティ情報には、以下を含めることができます。
セッションのライフサイクル
アイデンティティのセッションライフサイクルは、認証アプリケーションの評価を行う上で重要なトピックです。ユーザーセッションが作成、管理、および破棄される方法について明確に理解しているかを確認してください。アプリケーションの統合化を行う際に参照できるよう、このプロセスを正確にドキュメント化してください。このトピックの詳細については、付録 B 「ユーザーセッションのライフサイクル」を参照してください。
カスタマイズおよびブランド設定
アプリケーションのブランド設定やルックアンドフィールに関する特定の要件を考慮する必要があります。多くの場合、アプリケーション単体のルックアンドフィールを重視するか、ユーザーにとって一貫した使い勝手を重視するかは重要な問題です。カスタマイズおよびブランド設定要件を満たす場合、そのための時間もスケジュールに組み込む必要があります。このため、アプリケーションの評価にカスタマイズおよびブランド設定要件が含まれているかどうかを確認してください。
データの分類アプリケーションを分析し、適切なレベルに分類したなら、アプリケーションにより提供されるデータおよびサービスの分類を開始する必要があります。この情報は、セキュリティモデルの構築に使用されます。分類自体は、データおよびサービスを分類するプロセスです。それに続き、既存の認証および承認システムのカタログ作成が行われます。アプリケーションの評価で収集された情報は、プロセスの前の部分で使用されます。収集した情報をさまざまなセキュリティ層に編成するのは、良い方法です。これらの層は、データの紛失、アプリケーションの妥協的使用、誤用、その他の不正なアクセスタイプに関係したリスクの量を示すものとなります。正しく定義されたカテゴリを使用すると、リソースをセキュリティモデルにマッピングして、認証および承認要件を組み込む作業が簡単になります。
図 2-1 は、一般的な組織内のデータを表現したものです。データまたはサービスは、4 つのセキュリティレベルに分類されます。X 軸はデータまたはサービス、Y 軸は関連付けられるセキュリティレベルを表します。層 1 は、セキュリティが最小であることを示します。これは、公開された Web サイトに適用可能なデータです。一方、層 4 は、セキュリティが最大であることを示します。これは財務や HR データなどに適用されます。組織により、これよりも層が多いか少ない場合がありますが、この図から、大量のデータには関連するリスクも低く、そのためセキュリティ要件も低くなることを理解できます。関連するリスクが大きくなるにつれ、セキュリティ要件も大きくなります。(実際のところ、高度なセキュリティ要件を備えたデータはごくわずかであり、大量のデータはセキュリティ要件を必要としません。)
図 2-1 データおよびサービスのセキュリティ要件
認証および承認機能の割り当てが可能な、データおよびサービスタイプの機能グループを構築することが目標であることを念頭に置いてください。層の数が多すぎるとプロセスが過度に複雑になり、層の数が少なすぎると柔軟性に欠けたものになります。さらに、ネットワーク上に配置すること自体が非常に危険なデータもあることも考慮しておくことは重要です。適切であれば、内部で利用可能なデータと外部で利用可能なデータを明確に区別するようにしてください。これらの層を構築する際、認証および承認要件と共に、データのアクセス時刻およびネットワーク上の位置などの修飾条件も念頭に置くようにしてください。
認証へのマッピング
データをセキュリティレベルに応じて分類できたなら、次の段階は、認証および承認メカニズムの一覧を作成することです。利用可能な認証メカニズムに関する手持ちのリストを使用して、これらのメカニズムを定義済みのセキュリティ層に関連付けます。たとえば、図 2-1 で分類したデータの場合、次のようにできます。
認証要件とデータ/サービス分類とのマッピングが、単純で明快なものであるようにしてください。そうでない場合、一致しない項目間で共通の基準を見つけるようにしてください。論理的な差異が存在するなら、ためらわずに複数の図を作成してください。たとえば、イントラネットとエクストラネット用のアプリケーションでは、それぞれ別個の図を作成できます。また、HR や財務などの機能セキュリティドメインに基づいて、データを分類することもできます。このようなデータ分類手法は、万能であるとは言えませんが、セキュリティ要件を理解し、論理的に管理可能なグループにマッピングする助けになります。
承認へのマッピング
アプリケーション評価により入手したデータを使用して各アプリケーションを検証し、スケーラブルな承認モデルを決定します。通常、最善の方法は、アプリケーション間で使用する共通のグループ/ロールを見つけることです。これらは、組織内の機能ロールにマッピングされます。これは理想的な方法です。また、これらのロール/グループのソース (メンバーシップデータの存在位置およびそのモデリング方法) を判別する必要もあります。これは Sun ONE Directory Server に存在するのが理想です。存在しない場合には、カスタムプラグインが必要になります。堅牢なグループモデルが存在する場合、最初に、各アプリケーションを既存のグループまたはロールに関連付けてください。存在しない場合は、最初にロールまたはグループメカニズムを計画し、機能ユーザータイプ間の共通の関係を見つけてから、特定のアプリケーションにアクセスします。作業の完了時点で、以下のものを入手できているはずです。
この基本的なセキュリティモデル (認証および承認メカニズムとの関連を利用したデータの分類) を使用して、配備を実行するスケジュールをまとめることができます。
スケジュールの作成収集した情報から、予備段階のスケジュールを作成できます。次の節では、一般的な配備スケジュールの手順を説明します。
配備の設計
スケジュールのこの段階では、これまでに入手した概念、ビジネスニーズ、およびユーザー要件を適切なコンテキストに配置します。ここで、配備の全体像が明確になります。コンポーネントが記述され、技術要件が定義され、完成したアーキテクチャが立案作成されます。この設計段階を開始する 2 つの方法は、ログイン時の画面案を作成すること、およびデータフローチャートを作成することです。
コンセプト証明
コンセプト証明を使用すると、設計をビジネス環境でテストできます。組織には、大抵、期待される結果を含む設定済みのテストケースセットである、「テストベッド」データベースが存在します。このテストベッドに、コンセプト証明を適用できます。すべてが順調に進めば、新たに得られた結果がドキュメント化された結果と同じになります。コンセプト証明の目的は、「配備の設計」で提起されたすべての疑問に対する答えを提出し、すべてのニーズを効果的に満たすことができること、およびリスクを最小限に抑えられることを証明することです。これは通常高速に行われるため、限定されたデータセットに基づいて設計を改良するための十分な時間を取ることができます。コンセプト証明およびそれに続く設計改良を、数回繰り返す必要があります。最後に実行するコンセプト証明は、いくつかの内部アプリケーションが統合されたものになるはずです。企業の共有サービス統合は、大抵、初期採用者によるサインオン標準モデル、次に一般の参加者によるサインオン標準モデル、最後に残された者たちによるサインオン標準モデルに準拠したものになります。初期の採用者で成功すると、そのアプリケーションを一般の採用での参照用として使用しやすくなります。
初期採用
ミッションクリティカルなアプリケーションや予算作成用のアプリケーションは、最初のアプリケーションとして選択すべきではありません。よりリスクの少ない戦略は、ロールアウト時に問題が発生しても企業運営に大きな混乱をきたさない、重要なハブアプリケーションを選択することです。たとえば、部門ポータルは、会計年度末の会計システムよりも、シングルサインオンロールアウト用の拠点として適しています。また、プロセスの弱点を排除し、成功が迅速に立証および認識されるように、初期段階でアプリケーションロールアウトの数を制限してください。最良のロールアウトの戦略は、可視性を最大限に高めながら、組織上のリスクを最小限に抑えることです。このため、製品に関する適切な経験を持つ配備チームがクリティカルアプリケーションを担当するようにします。
一般の参加
配備プロジェクトは単一のアプリケーションで始まりますが、多目的システムを構築できるように、他の内部顧客の要件も同時に評価する必要があります。中心的な IT グループは、より大規模な組織を代表するサービスを提供するため、サテライトグループのさまざまな基準およびスケジュールを受け入れることができなければなりません。スケジュールは十分に大きなウィンドウに表示し、サテライトグループが変更およびアップグレードを自分たちのアプリケーションの配備および品質分析 (QA) サイクルに組み入れる時間を取れるようにする必要があります。
製品環境
コンセプト証明が終了したら、改良された設計を製品環境内にレプリケートできます。製品環境の目的は、非人工的な環境で設計の機能を実証し、正しく動作することを確認することです。これは、コンセプト証明で観察された動作、および配備設計で定義された動作と比較されます。このテストは、安定性を確認する目的でも行われます。評価が行われ、レポートが生成されます。初期採用アプリケーションは、準備段階が完了しているため、製品環境でも稼働します。新規アプリケーションを、テストベッド段階から製品段階へ、徐々に移行させてゆきます。その他のアプリケーションは、初期採用と同じようにコンセプト証明サイクルで稼働させた後で、徐々に製品環境に追加されてゆきます。
