第4回アイデンティティ管理における「レベル合わせ」

連携アイデンティティ管理を実現するには、「その認証は本当にきちんと行われているか」といった条件を満たし、信頼関係を結ぶことが必要になります（編集部）

日本電信電話株式会社
NTT情報流通プラットフォーム研究所
伊藤宏樹
2011/4/11

　これまで、第1回「『アイデンティティ管理』の周辺事情を整理しよう」では主要なシングルサインオン方式について、第3回「OpenID／SAMLのつなぎ方とその課題」では、Kantara Initiative Concordia Discussion Group（Concordia DG）にて行われていたOpenIDとSAMLとの相互連携ユースケースについて解説しました。

　今回から2回にわたり、「サーバ間での信頼構築」の材料の1つとなる「Identity Assurance」（アイデンティティの保証）の考え方について説明したいと思います。

　認証の「レベル合わせ」の必要性

　これまでに説明してきた「連携アイデンティティ管理」では、どのようにすれば、複数のサーバ間でユーザー・アイデンティティにかかわるメッセージを安心、安全に交換できるか、がポイントになります。ここでいう「安心、安全に交換できる」ことの対象は、単なるサーバ間のメッセージ送受信には留まりません。

図1　シングルサインオンの基本的な手順（第1回図2）

　第1回で示した例をもう一度紹介しましょう。ここで「認証サーバ」は、「サービス提供サーバ」が発行した要求メッセージ（図1の②）の内容を、真に検証する手段を持ちません。同様に「サービス提供サーバ」は、「認証サーバ」が発行した応答メッセージ（同⑥）の内容（すなわち、メッセージに含まれるアカウント名などのユーザー・アイデンティティそのもの）を、真に検証する手段を持ちません。

　次に、サービス提供サーバが、「認証サーバでユーザーIDとパスワードを照合してきちんと認証しました」という主張を受け入れるケースを考えてみましょう。この場合、認証サーバがユーザー・アイデンティティをどの程度厳密に管理しているか、例えば、

認証サーバ内のデータベースはどのように管理されているか
認証サーバはそのアカウントが不正利用されていないことを確認できているか
認証サーバにてユーザーにパスワードを定期的に変更させているか

などの体制が不明なままでは、その主張を受け入れることは困難です。サービス提供サーバで高度なサービスを提供するために必要な「ユーザーの正当性」が担保されていない可能性があります。

　第2回で説明した「コンコーディア」における取り組みでも、同様のことがいえます。

図2 サーバ間の依存関係例（第2回図2）

　これは第2回で示した例です。「サーバB」は、「方式A」で受けた要求メッセージを「方式B」に変換した上で「サーバC」に通知し、「方式B」で受けた応答メッセージを「方式A」に変換した上で「サーバC」に通知しています。さて、この「方式A」と「方式B」との間のメッセージの変換の正当性は、いったい誰が担保するのでしょうか？

　これらの課題は「認証のレベル合わせ」「アイデンティティ管理のレベル合わせ」などと表現されます。プロトコルレベル、メッセージレベルで内容の完全性や機密性を図ること、あるいは相互認証や否認防止を図ること、とは異なる概念です。

　相互信頼の構築に必要な手続き

　それでは、連携アイデンティティ管理を実現するにあたって必要な「相互信頼」は、どのように構築されるべきなのでしょうか？大まかに分けて、次の2つの方法があると考えられます。

●相互評価や契約を基にした信頼関係

　先に示した「認証サーバ」と「サービス提供サーバ」のような単純な事例であれば、両者間での接続条件の調整に特に問題は生じないでしょう。これは、相互評価に基づいてサービスが実施される1つの形態だと考えられます。

　また、SAMLやLiberty Alliance ID-WSFといった、サービス提供に際して「信頼の環（トラストサークル：Circle of Trust）」の構築を前提とする仕様もあります。

図3　SAML、Liberty Alliance ID-WSFにおける信頼の環

　この場合、「SAML 2.0に対応した認証サーバと接続する際には、認証サーバが指定した接続条件を満たすこと」といった類の契約に基づき、シングルサインオンなどのサービス実現に必要な環境を整備することになります。

　信頼の環をサービス提供サーバが主導する場合も考えられます。Google AppsをSAML SP（サービス提供サーバ）として利用する場合などがその例です。サービス提供サーバが主導し、SAML IdP（認証サーバ）として機能する各接続元のサービスがサービス提供サーバに要求された接続条件を満たすケースもあります。

●第三者の評価による信頼関係

　前述の「相互評価や契約を基にした信頼関係」は、アイデンティティ管理にかかわる事業者や組織が、自発的、能動的に相互接続条件を評価することを前提としていました。これに対し第三者の評価では、認証サーバ、サービス提供サーバや、それらを運営する事業者、組織が第三者による評価を受け、その上で、ある条件を満たした事業者間でのみ接続を行う形態が考えられます。

図4　監査体制のイメージ

　例えばKantara Initiativeは第三者評価機関として、アイデンティティ管理技術を導入するサービス、事業者に対し、当該事業者、組織がユーザー・アイデンティティを管理、運用する事業者、組織としてふさわしいことを監査し、認定する枠組み作りを進めています。そして、この監査の礎となる仕様の1つが、次回紹介するIdentity Assurance Framework（IAF）です。この仕様は、Kantara Initiative Identity Assurance Work Group（IAWG）にて策定されています。

1/3

Index
アイデンティティ管理における「レベル合わせ」
	Page1 認証の「レベル合わせ」の必要性相互信頼の構築に必要な手続き
	Page2 アイデンティティ保証レベルの規定 Identity Assuranceの運用事例も
	Page3 コラム■アンカンファレンス方式の「Internet Identiry Workshop」

アイデンティティ管理の新しい教科書連載インデックス

Security&Trust フォーラム新着記事

Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。
WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。
Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
　代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する
侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。