SOAを技術面から支える「アイデンティティ管理」の重要性

SOAシステムで本領を発揮するアイデンティティ管理基盤の構築ポイント

（2007年03月20日）

複数のアーキテクチャが混在するSOA（サービス指向アーキテクチャ）システム上で、利用者の職務や権限に応じて適切なサービスを提供するためには、利用者とサービスとの関係の変化に合わせてアイデンティティ情報を継続的に追加・変更・削除する必要がある。そこで、注目されることになるのが、SOA環境におけるアイデンティティ情報を一元的かつ統合的に管理するアイデンティティ管理である。本稿では、SOA対応のアイデンティティ管理基盤の技術概要を紹介するとともに、その導入を検討するにあたってITマネジャーが知っておくべきポイントを明らかにしたい。

工藤達雄　http://blogs.sun.com/tkudo/
サン・マイクロシステムズ

SOAにおけるアイデンティティ管理の役割

　情報システムにおけるアイデンティティ情報は、

●サービスを利用しようとしているのはだれか（認証）
●その利用者にはどのような権限があるか（認可）
●その利用者のプロファイルはどのようなものか（属性）

という3種類の情報から構成される。これらの情報は、すべての情報システムにおいて、利用者に適切なサービスを提供するうえで欠かすことのできない要素である。なかでも、認証、認可情報はサービスにアクセスする際のセキュリティの確保に、属性情報はサービスの質に、直接的な影響を及ぼす。

　このアイデンティティ情報を設定・運用するための仕組みがアイデンティティ管理である。

　アイデンティティ管理は、これまでシステム運用の効率化やセキュリティの向上を目的に導入されることが一般的であったが、昨今は、新会社法や金融商品取引法に代表されるコンプライアンスのための内部統制整備を契機に導入されるというケースが増えてきている。

　というのも、情報システムにおいて職務分掌を徹底させるためには、利用者の職責の変化に応じて継続的にシステムへのアクセス権限を設定（変更）するとともに、だれがどのシステムへアクセスするのか（したのか）を把握する必要があるからである。

　SOA（サービス指向アーキテクチャ）の実現においても、アイデンティティ管理が必要となるのは言うまでもない。サービスに対するアクセス権限設定（アイデンティティ・プロビジョニング）は、従来型の「アプリケーション・サイロ」と同様に徹底する必要がある。さらに新たな課題として、サービス間でのアイデンティティ情報の相互運用（アイデンティティ・フェデレーション）も検討しなくてはならない（図1）。

図1：アイデンティティ・プロビジョニングとアイデンティティ・フェデレーションの関係

　以下では、アイデンティティ・プロビジョニングとアイデンティティ・フェデレーションを概観し、SOAに対応したアイデンティティ管理基盤を構築するためのステップについて解説する。

アイデンティティ・プロビジョニング

　アイデンティティ情報の最も基本的な管理形態は、個々のサービスが内部にアイデンティティ情報のデータベース、すなわちアイデンティティ・リポジトリを持つというものである。

　ところが、アイデンティティ情報、例えばユーザーのアカウント名やパスワード、ロール、グループなどは、どのサービスにおいても共通となることが多い。そこで、このアイデンティティ・リポジトリを切り出し、サービスに対する共用サービスとして提供しようというねらいで考案されたのが「認証基盤」である。認証基盤はアイデンティティ情報を一元的に保管し、各サービスにおいて利用者を特定したりアクセス範囲を決定したりする際に必要な情報を提供する。

　ただし認証基盤の役割は、認証情報やアクセス権限情報などを確実に格納・提供することであり、それらの情報の正確性や妥当性については関知しない。つまり、すでに退職した社員アカウントの確実な消去・無効化や、異動により職責に沿わなくなったアクセス権限の剥奪の徹底、あるいは紙ベースのアクセス権限申請プロセスにおける承認ミスや不正の防止には、認証基盤は何ら関与しないのである。

　サービスに提供するアイデンティティ情報を常に正確に保つためには、利用者の立場や与えられた職責の変化、あるいは利用者の参加・離脱に応じて、アイデンティティ情報を適時・的確に再設定する必要がある。これを実現するためのサービスがアイデンティティ・プロビジョニング・システムである。

　アイデンティティ・プロビジョニング・システムには、以下のような役割が求められる（図2）。

図2：アイデンティティ・プロビジョニング・システムの概要

アイデンティティ・ライフサイクル・プロセスの自動化

　アイデンティティ情報のライフサイクル管理は、単に人事情報CSVファイルを読み取り、それらを別のシステムに複製するだけでなく、ユーザーやその部門の責任者からのアクセス権限申請を受理したり、リクエストに対する承認者を探索・決定したり、承認後にサービス固有のアクセス権限情報を即時反映あるいはスケジューリングしたり、といった一連の処理を統合的に行う必要がある。

　このアイデンティティ・ライフサイクルのプロセス・フローは、企業や組織、サービスによってまったく異なる。また、プロセスは一度定義すれば終わりというものではなく、サービスの追加・廃止や組織の変化に合わせて改良し続けていかなければならない。

　これらの要件に対応するためには、

（1）柔軟にカスタマイズ可能なワークフロー開発・実行環境
（2）ユーザーへのセルフサービスと管理権限委譲機能の提供
（3）軽量なアーキテクチャ

の3点がアイデンティティ・プロビジョニング・システムに必要となる。

　この中でも、特に重要な要素が（3）である。アイデンティティ・リポジトリを統合する仕組みとしては、従来「メタディレクトリ」と呼ばれるアーキテクチャが存在したが、メタディレクトリはそれ自身が新たなアイデンティティ・リポジトリとなってしまい、一度構築してしまうと外的環境の変化に合わせて修正するのが難しい。アイデンティティ・プロビジョニング・システムは、それ自身にアイデンティティ情報を何ら持たない「データレス」なアーキテクチャであることが望ましい。

多様なアイデンティティ・リポジトリへの対応

　すでに認証基盤が運用されているような環境であっても、既存のサービスがすべてその単一のアイデンティティ・リポジトリを参照しているようなケースはまずありえない。通常はサービスごとにバラバラのアイデンティティ・リポジトリが存在しており、アイデンティティ情報を利用するためのインタフェースとデータ・モデルもアイデンティティ・リポジトリによって千差万別である。

　例えば、アイデンティティ・リポジトリの一種であるディレクトリ・システムでは LDAP（Lightweight Directory Access Protocol）がアクセス・プロトコルとして主流の座を占めており、ユーザー情報を表現するためのスキーマも標準化されている。しかし実際には、ディレクトリ・システムの機能を最大限に活用するためにはベンダー独自の拡張スキーマを利用せざるをえないようなケースもある。また、メインフレームとかERPシステムとかいったサービスでは、各ベンダーの提供する独自APIを介してしかアイデンティティ情報にアクセスできないことも多い。

　このようなインタフェースとデータ・モデルの違いを吸収し、プロビジョニングを標準化する仕様が、標準化団体OASISにより勧告されているSPML（Service Provisioning Markup Language）である。SPMLの最初のバージョン（1.0）は2003年にリリースされ、2006年には相互運用性を大幅に改善したバージョン2.0が勧告されている。しかし、SPMLは一部のアイデンティティ・プロビジョニング・システムでは実装が進んでいるものの、実際の普及はまだこれからである。

　アイデンティティ・プロビジョニング・システムには、これらのさまざまなアイデンティティ・リポジトリ実装の違いを吸収し、サービスをまたいで包括的にアクセス権限を設定することのできる能力が求められる。

アイデンティティ・リポジトリとオーソリテイティブ・ソースとの整合性の維持

　オーソリテイティブ・ソース（Authoritative Source）とは、その「権威のある源泉」という名が示すとおり、アイデンティティ情報のライフサイクルの起点となるエンティティのことである。一般的には社員の職責を一元的に管理する人事データベースなどが、このオーソリテイティブ・ソースとなる。

　本来アイデンティティ・プロビジョニングによってオーソリテイティブ・ソースとアイデンティティ・リポジトリの整合性は保たれるはずだが、実際にはそうならない。それはアイデンティティ・リポジトリの管理者が勝手に保守用のバックドア・アカウントを作ったり、任意のアカウントに対し、本来必要ないはずのアクセス権限を付与したりすることがあるからだ。

　その結果、設定されたアイデンティティ情報は、アイデンティティ・リポジトリのサービスの信頼性を損ない、ひいてはアイデンティティ・リポジトリを参照するサービスの、アクセスに関するセキュリティを低下させる原因となる。

　これを防止するためにアイデンティティ・プロビジョニング・システムは、アイデンティティ・リポジトリとオーソリテイティブ・ソースとの間で定期的にアイデンティティ情報の突き合わせを行い、設定されているアイデンティティ情報が利用者の職責に従っているという状態を維持する必要がある。

アクセス権限情報の妥当性を示す証拠の提供

　アイデンティティ・プロビジョニング・システムによって設定されたアイデンティティ情報、特にアクセス権限情報が利用者の職責上妥当かどうかを証明するためには、処理履歴ではなく実際の処理結果、すなわち設定したアイデンティティ情報そのものを検証する必要がある。これを「アイデンティティ監査（Identity Auditing）」と言う。

　アイデンティティ監査は通常、以下の活動の継続的な実施によって達成される。