Tweet

アーキテクチャ・ジャーナル クレーム ベースのアイデンティティ管理 ―― オンプレミス ソリューションとクラウド ソリューション ―― Vittorio Bertocci 2009/07/06

Page1 Page2 Page3 Page4

■概要

　今日実践されているアイデンティティ管理は、多くの場合、不完全な複数のソリューションをつぎ合わせたものです。どうにか機能はしているものの、異なるテクノロジを使用し、複数の環境にまたがって存在するアプリケーションやエンティティを統合できる真のソリューションとは言えません。現在、SaaS（Software as a Service: サービスとしてのソフトウェア）やクラウド コンピューティングの時代を迎え、企業は複数のテクノロジや環境をまたがってビジネスを運用する必要に迫られており、こうした場当たり的なソリューションの限界が明らかになっています。そこで、個々に分離されたアイデンティティ管理システムを統合し、壁のない IT 環境を構築していこうとする新しいアプローチが出現しています。

　この記事では、従来型のシナリオと新しいクラウド シナリオの双方に同じメリットをもたらすモデルである、クレーム ベースのアイデンティティ管理の原則について説明します。クラウド コンピューティング ソリューションと汎用的な分散システムを対象に、最も標準的なトークン交換のパターンを導入した場合のメリットと活用方法を主に取り上げます。

■クラウドの無限の可能性

　天上の雲（クラウド）を見上げると、幼いころ夢中になったドラゴン城の物語の一場面 - 雲間を駆け巡るドラゴンの姿 - がよみがえります。しかし、アーキテクトの皆さんがこの記事を読んでしまったら、雲の向こうにはドラゴンの代わりに金貨の山が見えるようになるでしょう。クラウド コンピューティングの根底には、“企業が自社施設の外で資産を管理し、インフラストラクチャを保守する手間を一掃することにより、資産の価値を大幅に向上させる”という考え方があります。企業では、このクラウド コンピューティングに基づいて IT のとらえ方を再検討することにより、大きなメリットを得ることができます。これは、ある意味で SaaS に似ています。SaaS の核にあるのは、“企業が、自社の中核ビジネス以外の分野においてアプリケーションを企業内で保守する負荷を回避するために、対応する機能をサービスとして購入する”という考え方です。クラウド コンピューティングは、その SaaS をさらに発展させています。従来型の CRM パッケージや HR パッケージのような完成したサードパーティ アプリケーションを購入する代わりに、クラウド コンピューティングでは、プラットフォームの形態を取るデータ センター内で自社のリソースをホストできます。これにより、CPU や帯域幅の使用量の制御、ハードウェアの管理、サーバー ルームの冷却などの負荷から解放され、システムに修正プログラムを適用する必要すらなくなります。その一方、リソースに対するコントロールはそのまま維持できます。お使いの Web アプリケーションで処理するデータが日々増加していても、クラウド内のデータ ストアを使用すれば、データの増加に合わせて頻繁にハードウェアを購入する必要はありません。何よりも大きなメリットは、事前にハードウェアやインフラストラクチャへの投資を行う必要がなく、実際にリソースで使用した量に応じた金額を支払えばよいという点です。“クラウド コンピューティング”は、しばしば“ユーティリティ コンピューティング”とに呼ばれることがありますが、その理由は、こうした従量課金方式に基づいています。従量課金方式のメリットは、CPU を大量に使用するタスクにおいて特に顕著です。予想される最大使用量に対応する規模のデータ センターを構築しても、ピーク時を除いて、その処理能力は無駄になってしまいます。一方、CPU 使用量の最も多いプロセスをクラウド プロバイダーがホストする巨大なデータ センターに展開すれば、要求に応じていくらでも CPU を使用でき、支払いも使用量に応じた額で済みます。こうしたメリットは IT マネージャーに特に強く訴えるものですが、クラウドはそのほか、アーキテクトにとっても非常に魅力的な特長を備えています。クラウド プロバイダーは、複数のリソースを同一のインフラストラクチャ上でホストし、開発や保守作業の簡素化に役立つサービスをすべてのリソースに対して提供します。サービスとして提供される機能には、名前付け、メッセージのディスパッチ、ログ記録、アクセス制御などがあります。クラウド インフラストラクチャを使用することで、リソース側での機能の実装が不要になります。

　クラウド コンピューティングについては、現在、さまざまな情報が流通しており、その数は日々増え続けています。これまでの私の説明だけではクラウド コンピューティングの巨大な可能性について今一つ確信が持てないという方は、お好みの検索エンジンを使ってキーワード検索してみてください。そうすれば、IT 業界でどれほど重要なテーマになっているかがおわかりいただけるでしょう。そこで、賢明なアーキテクトは、“自分の会社はこの状況に適切に対応しているのだろうか？”という疑問を持つかもしれません。実際のところ、この疑問に答えるのは難しく、企業のアーキテクチャやシステムのさまざまな側面について検討する必要があります。極端に単純化して言うと、確固たるサービス指向（SO）の原則にのっとってビジネスを運用している場合は、クラウド コンピューティングのメリットを享受できる理想的な状況にあると言えます。自律的な運用を推進し、ポリシーを公開し、さまざまな基準を適用した結果、サービスがどこで実行されているかを気に病むことがない - そのような状況であれば、素晴らしいことです。ただし、私の経験から言わせていただくと、きわめて細かな事柄にまでサービス指向の原則を徹底させることはありません。たとえば、同じテクノロジを使用して開発されたサービスは、連携させることで優れた機能を発揮します。そのような、サービスの連携によってメリットを最大化できるシナリオについては、別途考慮する必要があるでしょう。

　アイデンティティ管理とアクセス制御は、このようなシナリオの好例であると考えられます。通常、企業はディレクトリ ソフトウェアを自社で所有し、リソースのアクセス制御のさまざまな領域で利用しています。これが十分に機能していれば、開発者はアイデンティティ管理の領域に踏み込まずに済むのですが、実際にはほとんどそうなりません。ディレクトリ外部のパートナーとフェデレーションを行ったり、タイプの異なる複数の資格情報を使用するようなタスクが生じると、開発者はアクセス制御の手法とアイデンティティ管理の手法をつぎ合せた、場当たり的な統合ソリューションを生み出してしまう可能性があります。では、こうした低レベルのソリューションにもかかわらず、対処できているのはなぜなのでしょう。

　もちろん、アクセス制御で問題が起きたケースは皆さんもよくご存じでしょうし、“対処できていない”と言い切ってしまうことも可能です。しかし、考えようによっては、“対処している”とも言えるのです。なぜなら、インフラストラクチャのほとんどを自社で保有している限り、過大なリソースを投入したり、しばしば緊急体制を敷いたりして、強力な権限を行使すればなんとかやっていけるからです。しかし現在、インフラストラクチャのほとんどを自社で保有している企業は、市場からの圧力という大きな逆風にさらされています。多くのビジネスで新たなパートナーとの接触や支援を継続的に行う必要がある状況で、自社のインフラストラクチャとパートナーのインフラストラクチャとの間に境界を設けるべきなのでしょうか。クラウド コンピューティングは、この疑問を加速度的にふくらませます。ひとたびクラウドが展開オプションの 1 つに加わると、リソースごとに独自のアクセス コードを作成するという方法は、有効性を失ってしまうのです。

　幸いなことに、アーキテクチャに基づいてアイデンティティ管理とアクセス制御をサポートする汎用的な分散システム向けのアプローチが存在します。これは、オンプレミス、クラウド、および両者を組み合わせたハイブリッド型のシステムでも同様に機能します。基本的な考え方としては、ほぼすべての要素を“クレームの交換”という観点からモデル化し、トランザクションをさらに合理的な方法でモデル化します。

　この記事は、上記の新しいアプローチについて紹介するものです。特にクラウドに関連する領域を重点的に取り上げますが、ここで説明するコンセプトとパターンのほとんどは、あらゆる種類の分散システムに適用できます。なお、今回の議論で対象とするのは、メンバーシップ プロバイダーをベースとした単純なシングル サイト向けのシナリオではありません。これから説明する原則は、単純なシナリオも含め、あらゆるシステムに適用できますが、パートナーシップ、複雑なアクセス ルール、構造化されたアイデンティティ情報などがかかわるシナリオで最も威力を発揮します。

　これから述べる内容は、最初、やや取っつきにくいと感じるかもしれません。そのような方は、中世ヨーロッパにおいて、従来ローマ数字で計算を行っていた人々が、“0”という数字の使い方を初めて学ぼうとしたときに直面した困難を想像してみてください。彼らは、既に確立された手法にとらわれず優れたモデルを導入し、ほんとうに大きなメリットを得ることができたのです。

■クレーム ベースのソリューション

　従来のアイデンティティ管理ソリューションの問題は、“前提が多すぎる”という点に集約できます。

　最も代表的なものは、“トランザクションに関与するすべてのエンティティは、アクセスの許可対象と有効期限に関して決定権を持つ中心的な機関によって常に把握されている”という前提です。この前提は、ディレクトリで管理された企業ネットワークを始めとする自己完結型のシステムでは有効です。しかし、独自のアイデンティティ ストアを備えたソフトウェア パッケージを利用する、パートナーや顧客とエクストラネットを介して取引する、コンサルタントの支援を受けるなどの形で、ビジネス プロセスに外部の要素がかかわり始めると成立しなくなります。シャドウ アカウントのような対処療法的なソリューションも存在しますが、そのような場合、往々にして実際には所有していないものを管理しているように見せる必要が生じるため、多大な労力が必要になります。

　もう 1 つよくある前提は、“トランザクションに関与するすべてのエンティティは共通のアイデンティティ管理テクノロジを使用している”というものです。これも、ネットワーク ソフトウェアなどの自己完結型のシステムでは有効ですが、外部の要素が関与すると成立しなくなります。複数のテクノロジを運用する際の一般的な対処法は、例外を適用することです。結果として、アイデンティティ管理のノウハウを持たない開発者が、リソースに数々の配管処理を埋め込むことになります。これは、“プレゼンテーション レイヤーにビジネス ロジックを埋め込む”という周知のタブーにも匹敵する、またはそれ以上にお粗末な手法です。アイデンティティ管理に関する配管処理をリソースに直接埋め込むことは、システムを不安定にし、運用を困難にするばかりでなく、システム管理者を悲惨な状況に追いやります。リソース自体の内部でロジックがロックされてしまうと、展開時にアクセス制御を管理する術はありません。

　クレーム ベースのアプローチでは、こうした問題を解消するために、すべてのタスクを本来の所有元のエンティティに割り当てます。また、すべてのエンティティの自律性を確保することにより、非合理な依存関係や前提を取り入れることを回避しています。これは、すでに十分な実績を確立した SO アーキテクチャの原則がもたらしてくれた資産と言えるでしょう。

　この後、クレーム ベースのアプローチについて簡単に説明します。このトピックは、それ自体で非常に奥深く、私自身、共著書を 1 冊執筆しています。このトピックをより詳しく学びたい方は『Understanding Windows CardSpace』の第 2 章（MSDN から無料でダウンロード可能、URL は「参考資料」セクションに記載）をご覧ください。

INDEX
	［アーキテクチャ・ジャーナル］
	クレーム ベースのアイデンティティ管理
	1．クラウドの無限の可能性とクレーム・ベースのソリューション
	2．クレーム・ベースのアイデンティティ管理を理解するための基礎知識
	3．クレーム・ベースのアイデンティティ管理のアーキテクチャ・パターン
	4．クレーム・ベースのアイデンティティ管理をクラウドで利用する利点

「アーキテクチャ・ジャーナル」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）