システムの利用にあたっては、ユーザ情報の登録が必要な場 合が多い。それぞれのシステムに、個々に情報登録が必要にな れば、煩雑であるだけでなく、管理上の問題も起きてくる。セ キュリティの観点からも、アイデンティティの重要性は増して おり、その管理が必然的になりつつある。 アイデンティティ管理とは、複数のシステムが個別に管理す るユーザ情報を効率的に管理する概念である。アイデンティテ ィ管理の効果は、以下の3つと考えられる。 ・管理コストの削減 ・ユーザの手間の軽減 ・セキュリティ向上 アイデンティティ管理の導入は、単なるアプリケーションの 導入ではなく基盤の整備と言える。実現の際には現状システム を再構築する場合もあり、痛みを伴う場合もあるが、早期の導 入が効果的である。 アイデンティティ管理のインフラは、3層のインフラから構 成される。最下層は、メタディレクトリベースの統一的アカウ ント管理インフラであり、その上位としてシングルサインオン （以下、SSO：Single Sign On）システムのアクセス制御イ ンフラがあり、さらにその上位に、PKIシステムの強力な認証 インフラが存在する。（図1参照） メタディレクトリは、異なるデータベースやディレクトリに 接続するアクセス手段と、データベースやディレクトリ上にあ る属性値のフォーマットを変換・コピーする機能をもっている。 各アプリケーションが独自のアカウント管理をしている場
1 はじめに
2 メタディレクトリ
松永 功
Isao Matsunaga
インターネットの普及とともに、数多くのサイトにアプリケーションシステムが稼動している。多くの利用者
が多くのアプリケーションサイトにアクセスしている。このため、利用者に対する利便性の向上を図る一方で、
アプリケーション利用者の認証がシステム構築の重要な鍵となってきた。本稿では、アイデンティティ管理のイ
ンフラを担う３つの要素であるメタディレクトリ、シングルサインオン、PKIシステムをベースにした電子認証
システムの実現方式を紹介する。
概要
アプリケーション 強力な認証インフラ （PKIシステム） アクセス制御インフラ （SSOシステム） 統一的アカウント管理インフラ （メタディレクトリ） 図１ アイデンティティ管理インフラ40周年記念
第2号
I N T E C T E C H N I C A L J O U R N A L2003
合、アプリケーション数が増加すると、アカウント管理のコス トが増大する。このため、統一的アカウント管理の必要性に迫 られる。この実現方法として、2種類のアプローチが考えられ る。ひとつは、集中管理型、もうひとつは、同期管理型である。 集中管理型は、アカウント情報を一箇所に集め、各アプリケ ーションはその情報を参照する方法である。アカウント情報へ のアクセスには標準的プロトコルであるLDAP(Lightweight Directory Access Protocol)を使う。この方法では、アプリ ケーション毎に改修が必要となってくる。また、アプリケーシ ョン独自情報まで集中管理することは困難となる。 一方、同期管理型は、メタディレクトリによって各アプリケ ーションのアカウント情報DBやディレクトリの属性値の同期 をとる方法である。各アプリケーションは自分自身の同期され たアカウント情報DBやディレクトリを参照するものである。 この方法では、各アプリケーションの改修は不要となり、アプ リケーション独自情報は各アプリケーションによって管理され る。（図2、図3参照） メ タ デ ィ レ ク ト リ 商 品 と し て 、 M a X w a r e 社 の D a t a Synchronization Engineがある。この商品は、インテック コミュニケーションズ社が販売代理店となっている。 シングルサインオンシステムとは、一度の認証で複数のリソ ースを利用可能にするシステムである。また、同時にすべての アプリケーションに共通のアクセス制御インフラを提供するも のととらえることもできる。現在は、Webシステムのシング ルサインオンを実現するシステムが主流となっている。 適正なユーザのみが許可されたリソースにアクセスできるよ うにするにはアクセス制御の導入が必要になる。このアクセス 制御のレベルには、何が見れるかを制御する粗レベル、何がで きるかを制御する中レベル、今何ができるかをリアルタイムに 制御する密レベルの3段階がある。アクセス制御情報のメンテ ナンスを容易にする方法としてロールベースアクセス制御があ る。個々のリソースにユーザ個々にアクセス権を登録すると、 リソースあるいはユーザの属性が変更になった場合、リソース 個々への変更処理が発生する。しかし、必要なアクセス制御レ ベルのロールを設けて、ユーザとロール、ロールとリソースの 関係を設定しておけば、ユーザ属性変更の場合、ロールへの登 CN suzuki uid 10001 givenName Ichiro SN Suzuki 社員番号 10001 姓 鈴木 名 一郎 部署名 開発部 役職名 課長 DN CN=suzuki 住所 横浜市... 電話 045-51... mail Suzuki@... EmployeeID10001 DN Uid=10001, O=IC uid 10001 CN 鈴木一郎 SurName 鈴木 GivenName 一郎 street 横浜市... Telephone 045-451.... Mail Suzuki@.... Title 課長 ActiveDirectory LDAP ODBC LDAP NotesAPI LDAP、JDBC ディレクトリサーバ （SunONE DS等） ORACLE Notes/Domino データ統合先 データソース メタディレクトリ 図２ メタディレクトリによる統合データの同期 氏名 鈴木一郎 ふりがな すずきいちろう 姓 鈴木 名 一郎 社員番号 1031001 事業部 開発事業部 部署名 ECソリューション部 役職 一般 アルファベット Suzuki Ichiro メタディレクトリ 人事DB（ORACLE） マスターDB CN 鈴木一郎 Title 一般 department ECソリューション部mail Suzuki_ [email protected] 開発事業部ドメインに追加
EmployeeN 1031001
FullName Suzuki Ichiro
IDFile 1031001.id
MailFile Suzuki Ichiro.nsf IDファイル・メールファイル作成& アドレス帳追加 CN Uid=1031001, O=開発 SN Suzuki givenName Ichiro o 開発事業部 開発事業部ディレクトリに追加 ActiveDirectory Notes/Domino SunONE Directory Server 図３ メタディレクトリによる分散データの同期
3 シングルサインオンシステム
3.1 アクセス制御
特
集
2
シングルサインオンシステムには、個々のサーバにアクセス した後サーバ内のエージェントが認証をつかさどるエージェン ト型SSO、認証サーバが認証後にサーバへのアクセスを許可 するリバースプロキシ型SSOがある。 エージェント型SSOの流れは、以下のとおりである。（図5 参照） ④別のWebサーバBにアクセスする際に、クライアントは、 その認証情報をクッキーに入れてアクセス ⑤WebサーバBのエージェントが、SSOサーバに認証情報を 送り、新たな認証情報を取得 ⑥WebサーバBは、画面とともにクッキーに入れた認証情報 をクライアントに返す リバースプロキシ型SSOの流れは、以下のとおりである。 （図6参照） ①クライアントがログインすると、認証SSOサーバはクッキ ーを返す ②受け取ったクッキーで、認証SSOサーバ経由で、目的の WebサーバAにアクセスして指定ページを受け取る ③別のWebサーバBにアクセスする場合、既に受け取ってい るクッキーを付けて、認証SSOサーバにアクセス
3.2 エージェント型SSO
3.3 リバースプロキシ型SSO
ロール1 ロール2 リソース1 リソース2 リソース3 リソース1 リソース2 リソース3 図４ ロールベースアクセス制御 エージェント 認証情報 認証情報 認証情報 クッキー 認証情報 クッキー WebサーバB WebサーバA SSOサーバ クライアント アクセス アクセス 画面 画面 認証画面 ユーザ認証 エージェント ユーザ認証 認証情報 クッキー 4 1 2 2 5 5 1 3 1 6 認証情報 図５ エージェント型SSO WebサーバA WebサーバB SSOサーバ クライアント 指定ページ 取り出し 指定ページ 取り出し 指定ページ サーバAアクセス サーバBアクセス トップページ ログイン 指定ページ 指定ページ 指定ページ クッキー クッキー クッキー 2 2 1 1 2 3 5 4 4 2 図６ リバースプロキシ型SSO④認証SSOサーバは、目的のWebサーバBにアクセスして指 定ページをとる ⑤認証SSOサーバが指定ページをクライアントに渡す エージェント型、リバースプロキシ型の2つのSSO方式の 比較をすると以下の表1のようになる。 この2つのSSO方式の欠点を補い、長所を生かした方法と して共存方式が考えられる。（図7参照） ①クライアントから最初のWebサーバBにアクセス、ユーザ 情報を送信 ②WebサーバBのエージェントがSSOサーバから認証情報を 受け取り ③クライアントに、指定画面とクッキーに入れた認証情報を返す ④クライアントから別のWebサーバAにアクセスする際に、 リバースプロキシに既に受け取っている認証情報をクッキー に入れてアクセス ⑤リバースプロキシは、その認証情報をもとに、SSOサーバ から新たな認証情報を取得 ⑥リバースプロキシがWebサーバAにアクセスし、指定のペ ージを取得 ⑦リバースプロキシからクライアントに、指定ページとクッキ ーに入った新たな認証情報が渡る これらはWebシステムについてのものであるが、非Webシ ステムをアクセス制御のインフラに取り込むためには、非 WebシステムにSSOエージェント機能を組み込む必要があ る。この組み込まれたエージェントとインタフェースをとるた めのAPIも提供される。但し、基本的にWebシステムとの連 携はできない。 シングルサインオンシステムの代表的なものとして、当社と 業務提携しているRSAセキュリティ社のRSA ClearTrustがある。 SSO環境では、一度のユーザ情報入力で認証されると全て のリソースへのアクセスが可能になる。これは、便利な反面、 認証方式を破られたときの影響範囲が大きくなることを意味す る。このため、強力な認証方式が必要となってくる。その実現 方法として、PKIやワンタイムパスワードなどがある。
40周年記念
第2号
I N T E C T E C H N I C A L J O U R N A L2003
3.4 エージェント/リバースプロキシ共存型SSO
エージェント クッキー クッキー SSOサーバ リバース プロキシ クライアント 画面 ユーザ認証 ユーザ認証 認証画面 ページ取出し ページ アクセス アクセス 1 1 2 2 4 6 5 5 6 1 7 3 認証情報 認証情報 認証情報 WebサーバA WebサーバB 認証情報 認証情報 認証情報 図７ エージェント/リバースプロキシ共存型SSO 利点 欠点 ・SSOサーバ、および SSOサーバが接続さ れたネットワークに 負荷が集中しない ・URLが変更されない ・各Webサーバにエージェント モジュールを組み込む手間が かかる ・OS、Webサーバによってはエ ージェントモジュールが対応 しない場合あり ・Webサーバに手を入 れる必要がない ・SSOサーバ、およびSSOサー バが接続されたネットワーク に負荷がかかる ・URLが変更される ・SSLクライアント証明書の情 報などがWebアプリケーショ ンに渡らない場合がある エージェント 方式 リバースプロキシ 方式 表１ SSO実現方式の比較4 PKIシステム
特
集
2
PKI(Public Key Infrastructure)とは、公開鍵と電子署名 を使って、インターネットで安全な通信ができるようにするた めの基盤である。企業間や、企業と消費者間の電子商取引が活 発化するに伴い、なりすましやデータの盗聴、改ざんといった 危険性が増大している。このため、鍵の管理と通信相手の確認 が重要になってくる。公開鍵暗号方式では、誰もが入手できる 公開鍵で通信データを暗号化し、自分だけが持つ秘密鍵で復号 化する。PKIシステムでは、認証局（CA：Certification Authority）という認証機関を設けて、電子署名による電子証 明書とともに公開鍵を発行、管理し、通信相手の正当性を証明 する機能を実現する。（図8参照） PKIシステム導入の考慮点としては、以下の3つを挙げるこ とができる。 ・ICカードやUSBトークン等を利用 ・リアルタイムの失効情報公開 ・運用可能な証明書配布方法 ICカードやUSBトークン等により、本人の特定をより厳格 に行うことが可能になる。また、異動、退職などにより発生す る失格者情報を、常に最新の状態にしておく必要がある。 具体的な製品として、RSAセキュリティ社のディジタル証 明書管理システムRSA Keon Certificate Authorityがある。 このシステムは、多様な発行プロトコルをサポートし、目的に 応じた証明書失効情報公開機能をもっている。当社は、この RSA Keon Certificate Authorityと連携して大量の電子証
明書を一括発行するシステムWG-AegisRAを商品化してい る。少量の電子証明書発行/失効にも対応しており、簡易、か つ柔軟な入出力データ仕様となっている。証明書所有者と関連 付けた電子証明書管理のシステムである。（図9参照） Webサービス、ポータルが普及し、ブラウザ利用システム の限界が見えて、さらにICカードの普及など、アイデンティ ティ管理を取り巻く状況は、一段と変化が激しくなっている。 特に、情報セキュリティでは、ISMS(Information Security ファイア ウオール 情報システム 部門 ICカード ICカード 発行機 OCSP レスポンダ 保護ネットワーク DMZ 図８ PKI導入例 社員 データベース LDAP ディレクトリ ICカード USB トークン 端末入力 フロッピーディスク Webインターフェース 発行 指示書 ファイル 発行 結果書 ファイル C M P CA 図９ WG-AegisRAの概念図
5 おわりに
Management System)、プライバシーマーク、個人情報保 護法などに関心が高まっている。この環境下で、柔軟でより強 固な、運用しやすい、インフラ構築が求められている。
参考文献
（1）RSAセキュリティ：“Webアプリケーションにおけるア イデンティティとアクセス管理RSA Clear Trustの概要”， （2002.10）
（http://www.rsasecurity.com/japan/products/ cleartrust/CT-J.pdf）
（2）宮下 毅（コンピュータ･アソシエイツ株式会社）：“アイ デンティティマネジメント”、N+I Network Guide P68-81， （2003.04） （3）安東 一真：“シングル・サインオン・ソフト ログイ ン操作の手間を軽減 難所は多様なシステムへの対応”、 日経Internet Solutions P110-117，（2003.１） （4）吉田 晃：“選択肢広がるメタディレクトリ システム ごとの違いを吸収しアカウントの一元管理を実現”、日経 Internet Solutions P86-88，（2003.6） （5）株式会社インテックコミュニケーションズ サービス： “Data Synchronization Engine”
（http://www.inteccoms.co.jp/platform/dse.html） （6）インテック・ウェブ・アンド・ゲノムインフォマティクス株 式会社 商品・サービス：“WG-AegisRA” （http://www.webgen.co.jp/development/ds_fr_top.html）
