2

Transcription

1 アイデンティティ管理技術解説 - ドラフト 年 1 月 1

2 2

3 目次 1 基礎概念 アイデンティティ情報 デジタルアイデンティティとは パーソナル情報 プライバシーと個人情報の関係 プライベートなデジタルアイデンティティとプライベートな属性情報 アイデンティティ情報のライフサイクル クレデンシャル管理 クレデンシャルとは X.509 デジタル証明書 クレデンシャルのライフサイクル 運用管理ドメイン 運用管理ドメインとは Windows ドメイン Kerberos レルム PKI ドメイン 基礎理論 エンティティ認証 概要 パスワードによるエンティティ認証 ワンタイムパスワードによるエンティティ認証 X.509 デジタル証明書によるエンティティ認証 アクセス制御のモデル 概要 RBAC(Role Based Access Control) ABAC(Attribute Based Access Control) RBAC と ABAC 利用モデル 組織内のアイデンティティ管理技術 組織内のアカウント管理 概要 Windows ネットワークにおけるアカウント管理 Web アプリケーションにおけるアカウント管理 i

4 3.1.4 アカウント情報管理リポジトリ 組織内のエンティティ認証 概要 NTLM 認証 Kerberos 認証 インターネット上のアイデンティティ情報の運用管理 概要 LDAP ディレクトリサービスの管理 複数ドメイン間にわたるアイデンティティ情報交換 インターネット上のエンティティ認証 エンティティ認証の応用論点 概要 パスワードの推測困難性 クオリファイド証明書 複数ドメイン間のエンティティ認証 概要 SAML 2.0 を利用した Web SSO... エラー! ブックマークが定義されていません OpenID 2.0 を利用した Web SSO エンティティ認証についての保証レベル 概要 エンティティ認証における潜在的なリスクと評価 リスク評価に基づく保証レベルの決定 各保証レベルに求められる対策基準 インターネット上の属性情報交換 SAML 2.0 によるドメイン間の属性情報交換 概要 SAML 2.0 仕様 OpenID 2.0 によるドメイン間の属性情報交換 概要 OpenID 2.0 仕様 属性情報の交換 インターネット上の属性情報に基づくアクセス認可 概要 SAML によるアクセス認可 XACML によるアクセス認可 インターネット上の代理アクセス ii

5 7.1 概要 OAuth 2.0 仕様 付録 1: 用語集 付録 2: 関連団体一覧 付録 3: 参考文献 iii

6 はじめに 今日のアイデンティティ管理技術は 人々に付す識別子 (ID) のみを扱う技術ではなく 多様な属性情報を管理するものとなっています 属性情報をオンラインで利用する際にも複数の目的があり 人々を本人であると認証すること 人々の属性情報を交換することの他 人々の属性情報に基づいてアクセスを制御すること等が挙げられます そして それぞれの目的に利用できる技術仕様が複数 策定されています また 人々がオンラインで利用できるようにするために 運用管理が行われています 図はじめに : 今日のアイデンティティ管理技術 しかしながら このように多種多様性を増しているアイデンティティ管理技術を 全体観をもって解説する取り組みがなされておらず 情報処理技術者が体系的に把握して学習することが容易ではない状況にあります 今日 多種のアイデンティティ管理技術の中から自らのシステム構築に適するものを選択したり 他者が採用しているアイデンティティ管理技術との間で相互運用可能性を確保することを検討したりするためには アイデンティティ管理技術についての全体観を養う必要があります 本書では アイデンティティ管理技術について まず基礎概念と基礎理論について解説し それらをふまえた上で 組織内のアイデンティティ管理技術とインターネット上のアイデンティティ管理技術について解説します そして インターネット上での認証と属性情報交換 さらに属性情報に基づくアクセス制御を実現するための標準仕様である SAML OpenID XACML OAuth などについて解説します iv

7 1 基礎概念 1.1 アイデンティティ情報 本技術解説では 人のみならずデバイス サービス等を含めて属性情報を管理する単位となる主体を エンティティ ( 主体 ) と言います また アイデンティティ情報 はシステムに登録されたエンティティに関する属性情報の集合を言います 下図 ( 図 1.1-1) に エンティティ と アイデンティティ情報 の関係について示します 図 1.1-1: エンティティとアイデンティティ情報 デジタルアイデンティティとは エンティティのうち とりわけ自然人と結びつくアイデンティティは 会社や組織におけるアイデンティティ 国や地域における個人としてのアイデンティティ インターネット上で様々なサービス利用するためのアイデンティティなど 複数のアイデンティティが存在します それらをデジタルに表現したものを デジタルアイデンティティ と言います デジタルアイデンティティの識別対象となるエンティティは 人だけではなく 例えば以下のようなものも対象となります 周辺機器 デバイス コンピュータやサーバ 会社 組織や国 サービス (1) 属性情報これら 人を含めたエンティティは 実態として実在し その実態を表す様々な 属性 によって形成され 識別されます エンティティを形成する 属性 は エンティティを定義する人によって異なる 属性の集合 となり ひとつのエンティティに対して異なるアイデンティティ情報が形成されます 5

8 エンティティを表すアイデンティティ情報が エンティティを定義する人の視点によって異なる 属性 の集合 となって表される例を以下に示します エンティティが人の場合 取引先企業から観たエンティティ A さんの属性会社名 : 株式会社 商事所属部署 : 営業部役職 : 係長担当支部 : 関東支部担当会社電話番号 : 03-xxxx xxxx 勤務先住所 : 東京都 xx 区 xxxx エンティティ A さんが所属するサッカー部の視点から観た属性ポジション : フォワード背番号 : 11 入部年 : 2012 自宅住所 : 神奈川県 xx 区 xxxx 自宅電話番号 : 045-xxxx xxxx エンティティが人以外の場合 日本から観たフランスというエンティティの属性地理的方位 : 西時差 : 8 時間 イタリアから観たフランスというエンティティの属性地理的方位 : 北時差 : 無し EU 同盟国 : yes エンティティが人である場合において 個人識別可能な属性情報の組み合わせを PII(Personally Identifiable Information) と言います PII については 節で解説します 人に限らず エンティティを表すアイデンティティ情報の構成要素 属性の集合 は 不変なものではなく 時間軸とともに変化する可能性があるとともに 他のエンティティとの関係に関わる情報として表されることもあります 時間軸とともに変化する可能性がある属性の例を以下に示します 住所 勤め先 部署 携帯電話番号 等 6

9 他のエンティティとの関係に関わる情報として表される属性の例を以下に示します 卒業した学校 出身地 所属部署 等 前述のように エンティティを表すアイデンティティ情報は エンティティを定義する人の視点によって異なる 属性の集合 となって表されます したがって ひとつのエンティティは 複数のデジタルアイデンティティをもちうることになります 以下に エンティティが人である場合に 同一のエンティティが複数のデジタルアイデンティティを持ちうることを表した例を示します 図 1.1-2: 複数のデジタルアイデンティティをもったエンティティ アイデンティティ情報は エンティティを定義する人の視点によって異なる 属性の集合 として表されますが エンティティを表す属性はエンティティを定義する人によって統一された観点で管理され エンティティを定義する人とエンティティが相互に合意した信頼できるデジタル値として表されます 上図 ( 図 1.1-2) の例で エンティティを識別するのに アイデンティティ情報 1 にある属性情報を用いてエンティティを定義する人は A さん以外のエンティティを識別する場合も 統一された同じ観点 ( 属性 ) からなるアイデンティティ情報を管理します また アイデンティティ情報 1 は組織内で管理されているアイデンティティ情報 アイデンティティ情報 2 はインターネット上で利用されるアイデンティティ情報であり このエンティティは 組織内のデジタルアイデンティティ (Enterprise Identity) と インターネット上のデジタルアイデンティティ (Internet Identity) の 2 つのデジタルアイデンティティを持っていると言えます 属性情報は その真正性の程度によって下記のように 3 つに分類することができます 権威ある源泉 (Authoritative Source) からの属性情報 7

10 検証された (Verified) 属性情報 未検証の (Unverified) 属性情報 上図 ( 図 1.1-2) の アイデンティティ情報 1 の会社名や所属部署などの属性情報は 会社が発行した情報であり 権威ある源泉 (Authoritative Source) からの属性情報 として位置付けることができます また 名前や自宅住所 自宅電話番号などの属性情報があれば 入社時に身分証 ( 運転免許証や旅券など ) や住民票などの提示を求め これらの情報を基に確認することで 検証された (Verified) 属性情報 になります 一方 上図 ( 図 1.1-2) の アイデンティティ情報 2 の姓 名や住所 電話番号などが自己申告されただけで 確認が行われていない属性情報である場合には 未検証の (Unverified) 属性情報 となります 属性情報の中には 2 章で説明するアクセス制御で利用される情報も含まれています アクセス制御モデルのひとつである ロールベースアクセス制御 (RBAC Role Based Access Cotrol) で利用される ロール ( 役割 ) も属性情報のひとつであり 通常は 検証された(Verified) 属性情報 となります (2) 識別子 (ID Identifier) 識別子については下記の 2 つの考え方があります 識別子の ( 事前 ) 割当 識別子の ( 事後 ) 抽出 まず 識別子の事前割当から説明します デジタルアイデンティティは エンティティを定義する人が運用管理する範囲 ( 特定のドメイン / サー ビス / コミュニティ / アプリケーション / ディレクトリ等 管理対象を定められた管理空間 ) の中で エ ンティティを一意に識別するために エンティティ実体に対して識別子が付与されます 識別子は エンティティを定義する人が運用管理する範囲 ( 以降 デジタルアイデンティティの 管 理ドメイン という ) の中で定めた様々な表現方法によって付与されます そのような識別子の例を 以下に示します 数字 : 社員番号 学籍番号 運転免許証番号 保険証番号 銀行口座番号 IP アドレス 電話番号 郵便番号 IMEI(International Mobile Equipment Identity) 等 文字列 : 電子メールアドレス FQDN(Fully Qualified Domain Name) URI(Uniform Resource Identifier) XRI(Extensible Resource Identifier) MAC アドレス 等 8

11 識別子は 管理ドメイン内において一意の情報であるため 識別子をキーにエンティティを特定することができ また識別子からそのアイデンティティ情報を形成する属性情報を確認 ( 検索 ) することができます また エンティティは ひとつの管理ドメイン内で識別子となり得る属性を複数持つ場合もあります 例えば 下図 ( 図 1.1-3) の管理ドメイン 3 では 社内で識別子として付与された社員番号のほか 特定のアプリケーションにおける識別子として付与された A アプリケーションの ID / B アプリケー ションの ID といった属性情報も管理しています 図 1.1-3: 識別子の割当 ( ひとつの管理ドメイン内で複数の識別子を持つ例 ) これは エンティティが人である場合に限らず 例えばエンティティがサーバであった場合などにも 言えることで FQDN IP アドレス Mac アドレス等も識別子となります 次に識別子の事後抽出について説明します あるアイデンティティ情報の属性の中で主体を一意に識別しうる属性の組み合わせとして識別子が規定されることがあります 例えば 住基ネットに記録される基本 4 情報 ( 氏名 住所 生年月日 性別 ) を識別子として用いることが可能であると考えられています このような属性情報の組み合わせは PII(Personally identifiable information) として機能します 関連して パーソナル情報の保護について 次節において説明します 9

12 1.1.2 パーソナル情報 アイデンティティ情報に含まれるパーソナル情報 (/ 個人情報 ) について 我が国の 個人情報の 保護に関する法律 など法規制に基づく概念を解説します 1980 年 OECD 理事会で プライバシー保護と個人データの国際流通についてのガイドラインに関する勧告 が採択され 国際的に個人情報の取り扱いやプライバシーの保護が重要視されるなか 日本では 個人情報の有用性に配慮しつつ 個人の権利利益を保護する ことを目的として 2005 年 ( 平成 17 年 )4 月 1 日に 個人情報の保護に関する法律 ( 以降 個人情報保護法 という ) が施行されました 個人情報保護法は 個人情報の適正な取扱いに関し 国および地方公共団体の責務等を明らかにするとともに 個人情報を取り扱う事業者の遵守すべき義務等を定めた法律です この法律では 基本方針とその他の個人情報の保護に関する施策の基本となる事項を定め 国および地方公共団体の責務等を明らかにするとともに 個人情報を取り扱う事業者の遵守すべき義務等を定めています また 個人情報保護法の成立を受け 各省庁では業界ごとのガイドラインを策定し 公開しています 各ガイドラインでは 法案に使われている用語 ( 個人情報 個人データ 保有個人データ 等 ) や 義務および安全管理について具体例を示しています 個人情報保護法では 個人情報 を以下のように定義しています ( 定義 ) 第二条この法律において 個人情報 とは 生存する個人に関する情報であって 当該情報に含まれる氏名 生年月日その他の記述等により特定の個人を識別することができるもの ( 他の情報と容易に照合することができ それにより特定の個人を識別することができることとなるものを含む ) をいう 経済産業省の 個人情報の保護に関する法律についての経済産業分野を対象とするガイドライ ン では 個人情報 についての法令解釈指針 事例を掲げています 氏名 性別 生年月日等個人を識別する情報に限られず 個人の身体 財産 職種 肩書等の属性に関して 事実 判断 評価を表すすべての情報であり 評価情報 公刊物等によって公にされている情報や 映像 音声による情報も含まれ 暗号化等によって秘匿化されているかどうかを問わない ( ただし 安全管理措置 ( 法第 20 条関連 ) の対策の一つとして 高度な暗号化等による秘匿化を講じることは望ましい ) なお 死者に関する情報が 同時に 遺族等の生存する個人に関する情報でもある場合には 当該生存する個人に関する情報となる また 生存する個人 には日本国民に限られず 外国人も含まれるが 法人その他の団体は 個人 に該当しないため 法人等の団体そのものに関する情報は含まれない ( ただし 役員 従業員等に関する情報は個人情報 ) 10

13 [ 個人情報に該当する事例 ] 例 1 例 2 例 3 例 4 例 5 本人の氏名 生年月日 連絡先 ( 住所 居所 電話番号 メールアドレス ) 会社における職位又は所属に関する情報について それらと本人の氏名を組み合わせた情報 防犯カメラに記録された情報等本人が判別できる映像情報 特定の個人を識別できるメールアドレス情報 (keizai_ichiro@meti.go.jp 等のようにメールアドレスだけの情報の場合であっても 日本の政府機関である経済産業省に所属するケイザイイチローのメールアドレスであることがわかるような場合等 ) 特定個人を識別できる情報が記述されていなくても 周知の情報を補って認識することにより特定の個人を識別できる情報 例 6 雇用管理情報 ( 会社が従業員を評価した情報を含む ) 例 7 個人情報を取得後に当該情報に付加された個人に関する情報 ( 取得時に生存する特定の個人を識別することができなかったとしても 取得後 新たな情報が付加され 又は照合された結果 生存する特定の個人を識別できた場合は その時点で個人情報となる ) 例 8 官報 電話帳 職員録等で公にされている情報 ( 本人の氏名等 ) [ 個人情報に該当しない事例 ] 例 1 企業の財務情報等 法人等の団体そのものに関する情報 ( 団体情報 ) 例 2 例 3 記号や数字等の文字列だけから特定個人の情報であるか否かの区別がつかないメールアドレス情報 ( 例えば abc012345@xyzisp.jp ただし 他の情報と容易に照合することによって特定の個人を識別できる場合は 個人情報となる ) 防犯カメラに記録された情報等本人が判別できる映像情報 個人情報保護法では この個人情報を含む情報の集合物を 個人情報データベース等 とし また 個人情報データベース等を構成する個人情報を 個人データ 個人情報データベース等を事業の用に供している者を 個人情報取扱事業者 個人情報によって識別される特定の個人を 本人 といいます 本法律では 個人情報を提供する本人の権利と個人情報取扱事業者の義務をうたっています なかでも 個人情報を提供する本人に対して 個人情報を収集 利用するその目的を通知または公表し あらかじめ本人の同意を得た上で 特定したその目的の範囲内でのみ個人情報を取り扱うことを重要課題としています なお プライバシーや個人情報の取り扱いに関する法律は国ごとに異なり それぞれの地域でアイデンティティ情報の管理を行う上では 各国の法律を順守することが原則となっています [ プライバシーや個人情報の取り扱いに関する代表的な法律 ] 日本 : 個人情報の保護に関する法律 (Personal Information Protection Law) 英国 : Data Protection Act 1998 ドイツ : Federal Data Protection Act オーストラリア : National Privacy Principles 米国は 各州でプライバシーに関する州法を規定 11

14 また 金融庁の 金融分野における個人情報保護に関するガイドライン でも 取得 利用または第三者提供を禁じ 漏洩があった場合の報告義務を課す機微 ( センシティブ ) 情報として以下の個人情報について記しています 思想 政治的見解 思想 信条又は宗教に関する事項 人種 民族 門地 本籍地 身体 精神障害 犯罪歴その他社会的差別の原因となる事項 労働組合への加盟 勤労者の団結権 団体交渉その他団体行動の行為に関する事項 集団示威行為への参加 請願権の行使その他の政治的権利の行使に関する事項 保健医療又は性生活に関する事項等 信用情報 クレジットカード番号等を含む個人データが漏えいした場合であって 二次被害が発生する可能性が高い場合の報告義務 別途 例外規定はあります 個人情報 について総じて言えることは 上記の各例で示した個別の情報について 個人を特定するに至らない情報は 個人情報 にはなりません 名前 などの明確に個人を特定できる情報と 他の情報と容易に照合することによって特定の個人を識別できる情報 が同一の情報管理下にある集合物にある状態の場合に 個人情報 としてみなされます 個人情報保護法では この個人情報を含む情報の集合物を 個人情報データベース等 とし また 個人情報データベース等を構成する個人情報を 個人データ 個人情報データベース等を事業の用に供している者を 個人情報取扱事業者 個人情報によって識別される特定の個人を 本人 といいます 個人情報保護法では 個人情報を提供する本人の権利と個人情報取扱事業者の義務をうたっています なかでも 本法律の重要な課題として 個人情報の利用目的を明らかにすることとしています 個人情報を提供する本人に対して 個人情報を収集 利用するその目的を通知または公表し あらかじめ本人の同意を得た上で 特定したその目的の範囲内でのみ個人情報を取り扱うものとしています なお プライバシーや個人情報の取り扱いに関する法律は国ごとに異なり それぞれの地域でア イデンティティ情報の管理を行う上では 各国の法律を順守することが原則となっています [ プライバシーや個人情報の取り扱いに関する代表的な法律 ] 日本 : 個人情報の保護に関する法律 (Personal Information Protection Law) 英国 : Data Protection Act 1998 ドイツ : Federal Data Protection Act オーストラリア : National Privacy Principles 米国は 各州でプライバシーに関する州法を規定 12

15 1.1.3 プライバシーと個人情報の関係 個人情報保護とは 個人に関する情報の収集 管理 利用 処分に関する基本的ルール ( ガイドラ イン ) を定めたものであり 個人情報保護法とは 個人情報取扱事業者に対する規制 規律法で あるといえます 一方 プライバシーとは 個人が生まれながら認められた当然の権利として 何を考え 何を思い どのような性格を持つ というような内面的な精神活動の自由をいいます いわば個としての特性である 内心の自由 に由来し この内心の自由を保証する不可侵の権利といえます この 内心の自由 は 個人情報保護法のガイドラインでは 機微 ( センシティブ ) 情報 として表されていますが 個人情報保護法そのものには センシティブ情報に関する規定はなく 個人情報取扱事業者の自主性に任されているといえます 金融庁の 金融分野における個人情報保護に関するガイドライン では 取得 利用または第三者提供を禁じ 漏洩があった場合の報告義務を課す機微 ( センシティブ ) 情報として以下の個人情報について記しています 思想 政治的見解 思想 信条又は宗教に関する事項 人種 民族 門地 本籍地 身体 精神障害 犯罪歴その他社会的差別の原因となる事項 労働組合への加盟 勤労者の団結権 団体交渉その他団体行動の行為に関する事項 集団示威行為への参加 請願権の行使その他の政治的権利の行使に関する事項 保健医療又は性生活に関する事項等 信用情報 クレジットカード番号等を含む個人データが漏えいした場合であって 二次被害が発生する可能性が高い場合の報告義務 別途 例外規定はあります プライバシーは その 侵害 と照らし合わすことによって 定義を解釈しやすいものにできるかもしれません 1960 年の William L. Prosser の論文 Privacy では プライバシーの定義を 侵害 と照らし合わせて行っています 同論文では プライバシーの 侵害 行為の態様を次の 4 つに分類しています Intrusion: 私生活 生活状態への侵入 Public Disclosure of Private Facts: 私的事実の公開 False Light in the Public Eye: 他人をして誤認を生ぜしめる表現 / 公表 Appropriation: 私事 ( 氏名や肖像 ) の営業的利用 プライバシーを定義する際には時代 社会環境 民族 社会構造を反映したものとなります 一定 13

16 の時代の範囲の中で 様々な事実 行動等が積み重ねられ相互に集積し プライバシーが痕跡として残ります 例えば 売買の記録 クレジットカードの利用記録 携帯電話や電話 / インターネットの通信履歴 監視カメラの記録など 事実 行動の結果が何らかの形 ( 主にデータ ) で捕捉され プライバシーが個人情報 / 個人データとなって残ります プライバシーと個人情報の関係を下図 ( 図 1.1-5) に示します 図 1.1-4: プライバシーと個人情報の関係 ( 出典 : プライバシーとはなにか プライバシー保護 と 個人情報保護 の違いに関する考察 / 1999 年 8 月 28 日弁護士牧野二郎 ) 政府関係機関などが発行している報告書などでも 個人情報とプライバシーはほとんど区別されず 同義に扱っていることが多く見受けられますが 1980 年に OECD 理事会が勧告した "Guidelines on the Protection of Privacy and Transborder Flows of Personal Data"( プライバシー保護と個人データの国際流通についてのガイドライン ) では 個人情報 (personal data) とプライバシー (privacy) は明確に区別されています 個人情報は個人に関する情報 ( もしくは情報の集合 ) を言い 制度的に管理され 利用される情報を指します すなわち プライバシーが情報という形を取り 管理できる状態で取り扱い可能なものとなったものを個人情報として表されています このガイドラインでは OECD 加盟国間の情報の自由な流通を促進すること および加盟国間の 経済的社会的関係の発展に対する不当な障害の創設を回避することを目的とし 以下のことを求 めています 14

17 1. 加盟国は 本勧告の主要部分である勧告付属文書のガイドラインに掲げているプライバシーと個人の自由の保護に係わる原則を その国内法の中で考慮すること 2. 加盟国は プライバシー保護の名目で 個人データの国際流通に対する不当な障害を除去すること 又は そのような障害の創設を回避することに努めること 3. 加盟国は 勧告付属文書に掲げられているガイドラインの履行に協力すること 4. 加盟国は このガイドラインを適用するために 特別の協議 協力の手続についてできるだけ速やかに同意すること 同ガイドラインは個人情報の収集と管理に関する一般的な指針についての国際的な合意であるとともに 中心となる原則を設定することで 政府 企業 消費者がプライバシーと個人情報を保護する努力を促しています また オンライン オフライン両方の国境を越えたデータの流出入を不必要に制限することがないよう 国内レベルでも国際レベルでも適用できる以下 8 つの原則を掲げています 基本原則 (BASIC PRINCIPLES OF NATIONAL APPLICATION) Collection Limitation Principle( 収集制限の原則 ) 適法 公正な手段により かつ情報主体に通知又は同意を得て収集されるべき Data Quality Principle( データ内容の原則 ) 利用目的に沿ったもので かつ 正確 完全 最新であるべき Purpose Specification Principle( 目的特定の原則 ) 収集目的を明示し データ利用は収集目的に合致するべき Use Limitation Principle( 利用制限の原則 ) データ主体の同意がある場合 法律の規定による場合以外は目的以外に利用使用してはならない Security Safeguards Principle( 安全保護の原則 ) 合理的安全保護措置により 紛失 破壊 不正アクセス 不正使用 不正修正 不正開示 漏洩等から保護するべき Openness Principle( 公開の原則 ) データ収集の実施方針等を公開し データの存在 利用目的 管理者等を明示するべき Individual Participation Principle( 個人参加の原則 ) 自己に関するデータの所在及び内容を確認させ 内容の削除 修正を要求でき 又は意義申立を保証するべき Accountability Principle( 責任の原則 ) 管理者は諸原則実施の責任を有する これらの基本原則に示されたプライバシーについての権利は しばしば 積極的プライバシー権 と呼ばれます 他者が管理している自己の情報について訂正 削除を求めることができる権利の 15

18 意味があります 昨今では 国をまたいだネットワーク上で 個人を識別することができる情報 もしくは識別するために使用することができる様々な情報がやり取りされ その収集方法ならびに使われ方が多様化しています インターネット上では PII(Personally Identifiable Information)(*1) の売り買いや PII が犯罪に利用されることを防ぐ目的で PII の管理者もしくは PII 情報を収集 管理するサービス等の運営者は PII の利用目的を プライバシーポリシー として公開し 利用者にその提供可否を判断できるようにしています (*1) PII(Personally Identifiable Information) エンティティ ( 主体 ) が人である場合におけて 特定の一個人を識別することが可能な属性情報の 組み合わせを PII と言います PII という略語は 広義としては上記の定義で理解されていますが 厳密には法規や利用目的に応じて以下の言葉の組み合わせによって 使い分けられています Personal Identity Information Personally Identifiable Identifying 例えば 2002 年 4 月に WWW 関連の標準化団体 W3C は プライバシー情報取り扱いに対する個人の選好を支持する技術基盤 (Platform for Privacy Preferences P3P) を標準化しました ここでは Web サイトの運営者が 住所 氏名 メールアドレス cookie IP アドレスといった個人情報の利用基準プライバシーポリシー ) を開示し 利用者がそれに基づいて個人情報の提供を判断できるようにする仕組みを規定しています 1980 年に "Guidelines on the Protection of Privacy and Transborder Flows of Personal Data" が OECD 理事会より勧告されてから 30 年以上が経ち 個人情報の利用 および プライバシー保護における課題への効果的な取り組み の両観点において 環境の大きな変化にあわせてガイドラインの見直しが必要となり 2011 年に "Terms of Reference for the Review of the OECD Guidelines Governing the Protection of Privacy and Transborder Data Flows of Personal Data" が勧告されました この中には プライバシーに関する議論の枠組み ( 以下 プライバシーフレームワーク ) の見直しを必要とする背景として 下記の事項が挙げられています 収集 保存されている個人情報データ量の増大 個人情報から得られる個人やグループの行動 趣向 活動に関する傾向分析が可能な範囲 と深さが増大 16

19 新しいテクノロジーや個人情報の利用によって 社会および経済にもたらす利益と影響の増大 プライバシーに対する脅威の増大 プライバシーを保護する立場にある者であれ プライバシーを危険にさらすことができる者であれ プライバシーを取り巻く環境にいる 人 と 人の種類 が増大 個人情報に関わるやり取りについて理解しておくことが求められる複雑さと頻度の増大 場所を問わずグローバルに個人情報を流通させることが可能な通信ネットワークやプラットフォームの増大 プライバシーフレームワークを見直すにあたって 個人情報の扱いを取り巻く社会的な構図の変化を反映し 個人情報のより効果的な保護と信用を確保しつつ 社会 経済にとって価値のある個人情報の利用を可能とする基盤の整備が必要となります また プライバシーフレームワークは 言論の自由やオープンで透明性の高い行政などといった社会基盤に対する考慮をしながら 個人情報の国際流通において 国内 国際の各規範に基づきオープンで安全かつ信頼性の高いものとなることが不可欠です プライバシーフレームワーク作りに必要とされる要素として下記の事項が掲げられています 国をまたいだ相互運用性の高いプライバシーフレームワークの必要性 および個人情報の国際流通を可能とするプライバシー保護に関する国際的な規範の必要性 行政レベルでプライバシー保護の重要性を高める必要性 国内戦略としてのプライバシー保護政策の必要性 プライバシー保護に関する施策を国際的に行使可能なネットワークの必要性 国枠を超えて個人情報の保護を可能とするリソース ツール メカニズムの共有に関する必要性 顕著に個人情報を利用している組織は特に 個人情報保護の重要性を組織に促す必要性 プライバシーに関するリテラシーへの取り組みを通じて 個人情報を収集 保存している組織や個人に対してプライバシーに関する文化を作り上げる必要性 特にプライバシーを侵す高いリスクを伴う個人情報取扱業者 ( 組織 ) に対して プライバシーに関する影響度評価や管理プロセス プライバシー強化の仕組み ( ツールの利用 ) などを義務化し 施策を促す必要性 グローバルスタンダードとして実践されているプライバシー管理の仕組みを 組織が容易に導入できるよう公開し奨励する必要性 独自に選択可能で且つ管理し得る業界ごとのベストプラクティスを奨励する体制づくりの必要性 日々革新 / 変化し続けるビジネスモデルに適応可能な中立性のある技術およびコンテンツによるプライバシーに関する制度作りの必要性 17

20 1.1.4 プライベートなデジタルアイデンティティとプライベートな属性情報 エンティティ ( 主体 ) が人である場合 エンティティは公に使用するアイデンティティ情報とプライベートで使用する ( 許容した人に対してのみ公開する ) アイデンティティ情報の両方を持っており 目的や公共性の範囲に応じてどの属性情報を提供 / 開示するかはエンティティ自身が判断できる必要があります すなわち デジタルアイデンティティのプライバシーは 個人 グループ または組織が 自己に関する情報を いつ どのように どの程度伝えるかを自ら決定できる 状態にあることによって守られます このことにより 公共性を維持しながら不必要なアイデンティティ情報の公開を防止します また アイデンティティ情報の管理および取り扱いにおいては エンティティの同意がなければこれらの情報を開示してはならず また開示する情報は最小限にし 情報へのアクセスを適切に制限する必要があります ただし 公的地位にある者 ( 公職の選挙に立候補する者 公職にある者 ) あるいは企業に所属し企業の枢要部を構成する者 事業を行い事業内容の公共性ゆえに一定事項の公表が義務づけられている職種 ( 医師等 ) 事業の宣伝のために一定の事項が公開される場合 ( タレント等 ) などについては エンティティに関するアイデンティティ情報が保護されるプライバシーの範囲が事実上狭まることがあります 以下にプライベートなデジタルアイデンティティとプライベートな属性情報に該当する例を示しま す エンティティ自身が管理主体であるデジタルアイデンティティ 機微 センシティブな属性情報 本人しか知り得ない認証情報によってアクセスを保護された属性情報 本人にしか復号できない暗号化された状態で管理された属性情報 中でも エンティティの意思に基づいて特定の属性情報が開示されないように保たなければなら い情報としては 以下のような情報が該当します ( その他 エンティティ自身が開示を求めない属 性情報は すべてプライベートな属性情報になることがあります ) クレジットカード情報 クレジットカード利用明細 カルテ情報 購買記録 通話記録 18

21 一方 アイデンティティ情報の中でも公に用いる属性情報も存在します 公に と言っても 本人の同意なくして第三者に開示していいということではなく ( 例えば 住民基本台帳についても法改正が行われ 閲覧が制限されるようになっている ) 事業者や公共機関に対して情報の開示や各種証明書等の公文書申請を行うにあたり 申請者本人 ( 本人またはその代理人 ) であることの確認方法として提示する情報を指します 提示する情報は 書面の場合もあれば 電子的方式 磁気的方式や人の知覚によっては認識することができない方式で作られる記録の場合もあります ただし 確認の方法は 事業 公共機関の性質 保有個人データの取扱状況 開示等の求めの受付方法等に応じて 適切なものでなければならず 本人確認のために事業者または公共機関が保有している個人データに比べて 必要以上に多くの情報を求めないようにするなど 本人に過重な負担を課すものとならないよう配慮しなくてはなりません 各行政機関や事業者によって 本人を確認するために提示を求められる公的なアイデンティティ情報はそれぞれ異なりますが 下表 ( 表 1.1-1) に法務省の 戸籍の窓口での 本人確認 が法律上のルールになりました が例示している本人確認に必要となる具体的な証明書の種類を挙げます 氏名および住所 または 氏名および生年月日 が確認できるものであることが前提です 証明書の種類 運転免許証 表 1.1-1: 法務省が例示している本人確認に必要な証明書の種類 1 枚の提示で足りるもの ( 例 ) 2 枚以上の提示が必要なもの ( 例 ) 写真付き住民基本台帳カード ( 住所地の市区町村で発行 ) 旅券 ( パスポート ) 国又は地方公共団体の機関が発行した身分証明書 海技免状 小型船舶操縦免許証 電気工事士免状 宅地建物取引主任者証 教習資格認定証 船員手帳 戦傷病者手帳 身体障害者手帳 療育手帳 外国人登録証明書 写真の貼付のない住民基本台帳カード 国民健康保険 健康保険 船員保険 又は介護保険の被保険者証 共済組合員証 国民年金手帳 国民年金 厚生年金保険又は船員保険の年金証書 共済年金又は恩給の証書 戸籍謄本等の交付請求書に押印した印鑑に係る印鑑登録証明書 学生証 法人が発行した身分証明書で写真付きのもの 国又は地方公共団体が発行した資格証明書のうち写真付きのもの ( 左記に掲げる書類を除く ) 等 等 19

22 また オンラインで申請や届出といった行政手続等を行う際に本人確認手段として提供されている 公的個人認証サービス では 都道府県知事が発行する 電子証明書 によって本人確認を行っています 電子証明書は 本人確認以外の目的として 他人による なりすまし やデータの改ざんを防ぐために申請書等に 電子署名 を付し 確かに本人が送付した情報であることを示す用途でも利用されています この 電子証明書 の発行申請にあたり 申請者本人は本人確認を目的とし 住民票のある市区町村窓口へ以下の提出が求められています 住民基本台帳カード ( 住基カード ) 本人確認用書類 ( すなわち 上記に挙げた法務省が例示している本人確認に必要となる具体 的な証明書 ) エンティティが人である場合のみならず エンティティが人以外の場合においてもエンティティを確 認するために利用される公的なデジタルアイデンティティが存在します 例えば サーバ証明書などはその一例と言えます サーバ証明書は 利用者がアクセスする先となるサーバおよびサーバが提供するコンテンツ / サービスの提供者 運営者が 実在する組織であるかを CA(Certificate Authority 認証局) と呼ばれる第三者が証明する仕組みです サーバ証明書は サーバの実在を証明するだけでなく サーバとサーバにアクセスする利用者端末との間の通信を暗号化するためにも使われます たとえ通信の傍受 ( 盗聴 ) をされても第三者に内容を知られることがないため インターネット環境での情報のやり取りが安全にできるようになります このサーバ証明書の申請にあたって 申請者 ( 団体 法人 ) はその組織の実在を証明するため 定款 原本証明書 代表者および代表者印 印鑑証明書 責任者 / 担当者の在籍証明書などの提出を求められます これらの手続を経て取得したサーバ証明書は 利用者により発行元やサーバの所有者に関する組織情報などを確認することができるようになります この場合 サーバ証明書は当該エンティティの公的なデジタルアイデンティティであり 証明書の 発行に際して登録されたサーバ ( エンティティ ) の実体を表す情報は当該エンティティの公的なアイ デンティティ情報であると言えます エンティティ ( 主体 ) が人である場合 エンティティは 公的な用途に用いる情報や公開される情報 と 同意なく公開されないように管理されるプライベートなアイデンティティ情報の両方を持ってい ることになります 20

23 1.1.5 アイデンティティ情報のライフサイクル インターネット環境は いまやコミュニケーションの基盤としてなくてはならないものとなっている一方で 信頼性の低いデジタルアイデンティティの氾濫が社会的な被害 ( オンライン詐欺 アイデンティティ情報の流用 / なりすまし ) をもたらしています インターネット環境上で利用されるデジタルアイデンティティのみならず あらゆる用途におけるデジタルアイデンティティも 信頼できるアイデンティティ情報の収集および管理 維持によって はじめて信頼できるサービスレベル セキュリティレベルの確保ができるようになります アイデンティティ情報の管理を考える上では アイデンティティ情報に関するライフサイクル ( 登録 から抹消までの一連のプロセス ) を視野に入れたプロセスの定義が必要となります アイデンティ ティ情報のライフサイクルを一般的に示してみます ( 図 1.1-7) 図 1.1-5: アイデンティティ情報のライフサイクル 1 アイデンティティ情報の 登録 アイデンティティ情報の登録を希望するエンティティに対し 身元確認 本人確認を行い 情報管理者による審査等を経て エンティティを特定する識別子の生成した上でアイデンティティ情報を利用前に登録します そのような文脈で プロビジョニング と呼ばれることがあり 直訳的には素直ですが この文脈は狭義の意味合いになります ( 後述するように 今日 プロビジョニング は より広く一連のプロセスを指すことが一般的となっています ) アイデンティティ情報を利用可能とするために ステータスを有効化 (Activate) し クレデンシャルを発行します ( クレデンシャルについては 1.2 節で解説します ) 21

24 2 有効 状態のアイデンティティ情報登録されて活性化されたアイデンティティ情報は 利用できるようになります 各エンティティは 生成された識別子を使って サービスを利用することができます サービスの提供者側は 識別子の正当性を確認し 識別子に紐づいた属性情報等をもとに提供するサービスレベルやアクセス制御等を行った上でサービスを提供します アイデンティティ情報の管理者は アイデンティティ情報を安全に管理し 漏洩などの危険からアイデンティティ情報を保護しなければなりません 3 アイデンティティ情報の 更新 登録済みの活性状態にあるアイデンティティ情報に含まれる属性情報は エンティティあるいは情 報管理者 ( サービス提供者 ) の意向や状況により 更新されることがあります 4 アイデンティティ情報の 休止 (Suspension) 抹消 エンティティや情報管理者 ( サービス提供者 ) の意向や状況によって アイデンティティ情報が 休止 の状態にされたり 抹消 されたりします 例えば 組織におけるデジタルアイデンティティの場合 ある従業員が別の組織に一定期間 転籍するとき そのアイデンティティ情報を 休止 の状態にします 休止 されたアイデンティティ情報について 一定期間 アーカイブとして保存することがあります また ある従業員が退職するとき そのアイデンティティ情報を削除することによって 抹消 します このように アイデンティティ情報を利用できるようにするためには ライフサイクル全体に渡って 登録 更新 休止 抹消 のプロセスが適切に行われる必要があります この一連のプロセスに沿った活動を プロビジョニング と呼ぶようになっています ( このように上記 1において述べた プロビジョニング よりは広い意味合いをもちます ) プロビジョニング という用語は このようにアイデンティティ情報のライフサイクル(/ プロセス ) の観点から用いられるのみならず アイデンティティ情報を管理するシステムの文脈からも用いられることがあります 例えば 組織のアイデンティティ情報を管理するシステムに関して 今日 分散型の構成のもとで 複数箇所に同期した情報を保持する必要がある事例があります そのような分散したシステムに同一のアイデンティティ情報を自動的にコピーして同期するようにする処理を サービスプロビジョニング と言うことがあります アイデンティティ情報を登録する際には 所定の本人確認手続を経て 適切な身元確認を行い 登録される情報の信頼性を確保する必要があります アイデンティティ情報の 登録 について そ の流れを解説します 一般的に下図 ( 図 1.1-8) 中の流れで実施されます 22

25 図 1.1-6: アイデンティティ情報の登録フロー 1 登録申請申請を行うエンティティは その目的 ( 一般的には サービス利用申請 入会申込 口座開設申込 等 ) に応じて求められる本人情報を情報管理者に提示するとともに 登録が認められた時に利用に必要となる情報 ( サービス ID 会員 ID 口座番号 等 ) の要求を行います 2 本人確認 (Identification) 本人確認を行う情報管理者 ( サービス提供者 ) は エンティティに対して本人であることを確認するために必要な情報の提供を求め 必要とあらば本人の出頭を求めて 確認作業を行います 本人確認の実施方法や実施レベルは情報管理者が提供するサービス等の種類や目的に応じて異なります 本人確認は 信頼性を第三者が確認可能な仕組みを介して行う必要がある場合もあります 本人確認手続きに使用される所定の証拠資料 証明書等については 前節で挙げた 法務省 が例示している本人確認に必要となる具体的な証明書の種類 を参照してください 3 審査エンティティが提示した本人確認に用いる本人確認情報 ( 属性情報等 ) は 情報管理者によって審査され 登録および提供するサービスの可否判断を行います 一般的には 本人確認と同様に情報管理者が提供するサービス等の種類や目的に応じて審査基準 審査対象情報のレベルは異なります 4 情報登録審査においてサービスの提供が認められたエンティティのアイデンティティ情報を管理情報として利用可能な形式で登録し 所定の格納先に蓄積するとともに これらの情報に対してエンティティおよび管理者がその属性や権限に応じてアクセス ( 参照 更新 削除 ) が許される範囲を定め 利用制限 / 制御設定を行います 一般的には アイデンティティ情報はデータベース等に格納し サービス等の提供時に必要となる最低限度の情報を 暗号化等を施した上で蓄積します 23

26 5 登録通知アイデンティティ情報登録の際に エンティティを特定するための識別子を新たに割当 本人情報 / 属性情報と共に管理します 識別子は 重複することがないよう付与される必要があり 識別子によりエンティティを特定するだけでなく 場合によっては識別子の発行主体を特定することができる必要がある場合もあります 一般的には 情報管理者が提供するサービスごとに独自のルールにより識別子を生成 ( もしくはエンティティが自分で指定 ) するとともに アイデンティティ情報との関連付けを行います 新たに割り当てられた識別子とともに 登録されたアイデンティティ情報はエンティティに通知されます 一般的には 登録された情報は郵送や電子メール送信 Web 画面上への表示等により行われます 6 登録内容の確認 ( 受領 ) エンティティは 情報管理者から通知 ( 受領 ) された登録情報の内容に間違いがないことを確認し 登録プロセスが完了します また アイデンティティ情報は静的なものではなく 時間と共に変化していく可能性を有しています これら変化する情報を最新の状態に保つには 継続的に申請 ( 更新 ) 確認 審査 登録のプロセ スを実施し 信頼性のある情報として管理する必要があります [ アイデンティティ情報の登録 管理における今後の課題 ] ( 出典 : 財団法人日本規格協会情報技術標準化研究センター アイデンティティ管理技術標準化調査研究成果報告書 / 平成 21 年度個人化情報の活用と管理技術の標準化調査研究補助事業 ) 今後アイデンティティ情報を利用したサービスや認証提供者の数が増加するにつれて 認証における信頼性が求められ 認証保証フレームワークの必要性が高まることが予想されます NIST Special Publication や OMB をベースに策定された Liberty Alliance の IAF (Identity Assurance Framework) もしくはそれに準じるフレームワークを日本で運用するとした場合に特に重要になる可能性がある課題を掲げておきます 政府発行の顔写真入り身分証 IAF 保証水準 2 以上においては 政府発行の顔写真入り身分証 (primary Government Picture ID) の所有が求められています 政府発行の顔写真入り身分証としては 日本では運転免許証やパスポートなどがありますが すべての国民がそれらを持っている訳ではなく 発行基準も必ずしも同一ではありません さらに 政府 ( 自治体 ) の発行する戸籍情報にも顔写真は含まれていないため これらの対応が課題となります 24

27 証拠確認手法 IAF 保証水準 3 以上においては 提示されたドキュメントに対して 以下の内容をその発行 機関あるいはデータベースを通して電子的に確認することが求められています 1 参照番号や名前の一致する記録が存在すること 2 名前 生年月日 現住所など 本人を一意に特定する情報が正しいこと 現状日本においては 上記の情報の提示先から発行元へ問い合わせを行い 回答を得る枠 組みは整備されていません そのため これらの対応が課題となります プライバシーアイデンティティ情報を他のサービスと連携する必要がある場合 ( 特別な保護メカニズムによる対処をしていない限り ) 認証提供者が利用者の利用サービスを知りえるという問題があります また 上述の証拠確認機能も運用を誤ると個人情報の流出につながる危険性があります そのため 利用者のプライバシー保護の観点で 今後の課題になります これらを含めた課題の解決には 官民の連携が必要不可欠であり 官民合同の検討の場を設ける必要があると考えられます また クラウド コンピューティング技術の普及発展により 組織間にまたがる一種のドメイン形成やドメイン内での柔軟な連携が必要となってくることが予想されます さらには クラウド同士の間での連携 ( インタークラウド連携 ) も求められてくると考えられます これらの普及発展ならびにニーズに対して セキュリティ上のリスクも十分に理解し 考慮していかなければならなくなっています 相互連携の輪の中に含まれる複数の組織の管理手法の違いや管理ポリシーの違いを吸収していくためには 認証強度 / 信頼性レベルの調整などの技術的側面のみならず 技術標準を定めるとともに 公的な機関や複数の民間企業からアイデンティティ管理技術がサービスとして提供され それらが相互に連携し合って サービスの連携を推進できるような枠組みを整える必要があります 25

28 1.2 クレデンシャル管理 クレデンシャルとは クレデンシャルは アイデンティティ情報と特定のエンティティを結びつけるもので そのエンティティが確かにアイデンティティ情報と結びついたエンティティであることを証明するためのものです 例えば 書面によるクレデンシャルは 個人やそのほかのエンティティの身元識別情報やそのほかの属性を立証する文書が該当します 書面による一般的なクレデンシャルには 旅券 出生証明書 運転免許証 社員証などがあります 一方 電子的なクレデンシャルは エンティティがシステムにアクセスする際に 自分が該当のアイデンティティ情報に結びついた正当なエンティティであることを示すデータであり 構造体として定義されます 電子的な処理において 信任状 のように扱われ システムがエンティティ認証を行う際に使われます 本書では 以降 この電子的なクレデンシャルを クレデンシャル と言います クレデンシャルの例としては 識別子 (ID) とパスワード X.509 デジタル証明書などがあります クレデンシャルの発行までの流れを下図 ( 図 1.2-1) に示します 図 1.2-1: クレデンシャルの発行 1 アイデンティティ情報の登録を行いたいエンティティ ( 申請者 ) は まず RA(Registration Authority 登録機関) に対して申請を行います 2 RA はそのエンティティついて本人確認 身元確認を行います ( 詳細は 1.1 節を参照してください ) 3 確認の結果に問題がなければ RA はそのエンティティのアイデンティティ情報を保証し 連携 26

29 している CSP(Credential Service Provider クレデンシャルサービスプロバイダ) にアイデンティティ情報を送ります 4 CSP は RA から受け取ったアイデンティティ情報を登録します 5 CSP は エンティティに対してクレデンシャルを発行し エンティティとアイデンティティ情報を結びつけます アイデンティティ情報を登録し クレデンシャルを発行するために RA と CSP は常に連携しています 最も単純な形態は RA と CSP が同一のシステムとして提供されている場合です CSP は複数の独立したローカルの RA と連携している場合もあります ( 例えば 自治体の窓口が RA となる場合が挙げられます ) 発行されたクレデンシャルは データとしてディレクトリやデータベースに格納され エンティティの 認証に利用します 27

30 1.2.2 X.509 デジタル証明書 X.509 デジタル証明書は エンティティによって保持される公開鍵 と 対応するプライベート鍵を 利用するエンティティのアイデンティティ情報 を結びつけるクレデンシャルです X.509 デジタル証明書は 証明書 ( 公開鍵証明書 ) の標準として ITU-T ( International Telecommunication Union - Telecommunication Sector: 国際電気通信連合の通信に関する技術の標準化を担当する部門 ) が策定しました X.509 は X.500 ディレクトリシリーズのひとつであり ISO/IEC の国際標準としても規定されています X.509 デジタル証明書に関しては インターネットで利用することを目的とするプロファイルとして IETF(Internet Engineering Task Force) によって 1999 年に RFC 2459 が策定されました その後 2002 年に RFC 3280 として改訂され さらに 2008 年に RFC 5280 として改訂されています X.509 デジタル証明書は 用途によって以下の種類があります ( 表 1.2-1) 一般に 証明書 という 場合は 公開鍵証明書 のことを指します 種類 公開鍵証明書 (Public Key Certificate) 属性証明書 (Attribute Certificate) 表 1.2-1: 証明書の種類 説明 公開鍵とその所有者を証明します 公開鍵証明書で証明された人に対して その人が所有する権限や役割を証明します 公開鍵証明書と組み合わせて使用します また 公開鍵証明書は発行する対象によって 下表 ( 表 1.2-2) のように分類できます 表 1.2-2: 公開鍵証明書の種類 CA 証明書 種類 エンドエンティティ証明書 適格証明書 (Qualified Certificate) 説明 CA に対して発行する証明書です CA 自身のプライベート鍵で署名した自己署名証明書と 他の CA に発行された証明書があります エンドエンティティに対して発行する証明書です エンドエンティティ証明書として自然人に対して発行することによって 法的効果を伴うようにするために規定された専用のプロファイルです CA(Certificate Authority 認証局 ) は X.509 デジタル証明書を発行する認証機関で CSP に 相当しますまた エンドエンティティ (EE End Entity) は CA から証明書の発行を受ける対象で す 28

31 クレデンシャルとしての X.509 デジタル証明書の発行の流れを下図 ( 図 1,2-3) に示します 図 1.2-2: X.509 デジタル証明書の発行 1 証明書の発行を受けたいエンティティ ( 申請者 ) は まず RA(Registration Authority 登録機関 ) に対して申請を行います 2 RA はそのエンティティについて本人確認 身元確認を行います 3 確認の結果に問題がなければ RA はそのエンティティの申請情報を保証し 連携している CA (Certificate Authority 認証局) に証明書の発行を依頼します 4 CA は RA から受け取った申請者の情報を登録します 5 CA は エンティティに対して証明書を発行します X.509 デジタル証明書では エンティティの名前を DN (Distinguished Name) とよばれる形式で表 現します DN は 世界で一意の名前をつけるために考案されたもので 国 組織 名前などの属 性の集合によって エンティティの名前を表します DN の詳細については 1.3 節で解説します 29

32 X.509 デジタル証明書の構造を下図 ( 図 1.2-4) に示します 図 1.2-3: X.509 証明書の構造 RFC 5280 にて定義された X.509 デジタル証明書の基本領域および拡張領域についてのプロファ イルを表 および表 に示します なお ここでは説明のために構造を簡略化しています 正確な情報は RFC 5280 および X.509 を参照してください 表 1.2-3: X.509 デジタル証明書の基本プロファイル 領域名 tbscertificate( 署名前証明書 ) version( バージョン ) serialnumber( シリアル番号 ) signature( アルゴリズム識別子 ) issuer( 発行者 ) validity( 有効期間 ) notbefore( 開始時刻 ) notafter( 終了時刻 ) subject( 主体者 ) subjectpublickeyinfo( 主体者公開鍵情報 ) algorithm( アルゴリズム ) subjectpublickey( 主体者公開鍵 ) issueruniqueid( 発行者ユニーク識別子 ) subjectuniqueid( 主体者ユニーク識別子 ) 説明 証明書の基本的な情報と公開鍵を表します X.509 デジタル証明書のバージョンです 証明書を一意に識別するための番号です issuer が割り当てます 発行者が証明書に署名する際に用いるアルゴリズムです 証明書を発行した機関 ( 認証局 ) の名前です DN で記述されます CA の証明書に含まれる subject と同じ DN が記述されます 証明書の有効期間を表します 証明書が有効になる時刻です 証明書が無効になる時刻です 証明書の所有者の名前です 発行者と同じく DN で記述されます エンティティの名前やサーバ名などが記述されます subject の公開鍵に関する情報です 公開鍵のアルゴリズム名です subject が所有している公開鍵です issuer の名前を再利用した際に isuuer を識別するために使用されます 発行者名は再利用しないことが推奨されており この項目は使用するべきではありません この項目は省略可能です subject の名前を再利用した際に subject を識別するために使用されます この issueruniqueid と同様に 使用しないことが推奨されています この項目は省略可能です 30

33 領域名 extensions( 拡張領域 ) signaturealgorithm( 署名アルゴリズム ) signaturevalue( 署名値 ) 証明書の拡張領域です 説明 issuer が証明書に署名する際のアルゴリズムです tbscertificate の signature( アルゴリズム識別子 )) 同じ値を指定します issuer のデジタル署名が入ります 領域名 Subject Type Extensions ( 主体タイプ拡張 ) basicconstraints ( 基本制約 ) Name Extensions ( 名前拡張 ) issueraltname ( 発行者別名 ) subjectaltname ( 主体者別名 ) nameconstraints ( 名前制約 ) Key Attributes ( 鍵属性 ) keyusage ( 鍵使用目的 ) extendedkeyusage ( 拡張鍵使用目的 ) subjectkeyidentifier ( 主体者鍵識別子 ) authoritykeyidentifier ( 機関鍵識別子 ) Policy Information ( ポリシー情報 ) certificatepolicies ( 証明書ポリシー ) policymappings ( ポリシーマッピング ) policyconstraints ( ポリシー制約 ) inhibitanypolicy (AnyPolicy の禁止 ) Additional Information ( 追加情報 ) crldistributionpoints (CRL 配布点 ) freshestcrl ( 最新 CRL) subjectdirectoryattributes ( 主体者ディレクトリ属性 ) Private Internet Extensions ( 独自インターネット拡張 ) authorityinfoaccess ( 機関アクセス情報 ) subjectinfoaccess ( 主体者アクセス情報 ) 表 1.2-4: X.509 デジタル証明書の拡張プロファイル 説明 CA の証明書であるか否かを示します エンドエンティティに発行した証明書が 不正に CA の証明書として使われることを防ぐために使用します CA の証明書である場合は その CA の下位 CA となることができる階層数を指定できます CA 証明書の場合は この項目は必須です EE 証明書の場合は この項目は使用しないことが推奨されています 発行者 (issuer) の別名を指定します 基本領域の主体者 (subject) の別名 ( メールアドレス等 ) を指定します 下位 CA の証明書に使用されます 下位 CA が発行できる証明書の範囲を限定します 証明書に含まれる公開鍵の使用目的を示します 暗号用の鍵と署名検証用の鍵を区別するために使用します keyusage よりも詳細に 証明書に含まれる公開鍵の使用目的を示します 使用目的は Web や電子メールの保護などがあります 主体者が複数の鍵ペアと証明書を持つ場合に 特定の公開鍵を特定するために用います 公開鍵の特定には 公開鍵のハッシュ値などを用います subjectkeyidentifier と同様 CA が複数の鍵ペアと証明書を持つ場合に 特定の公開鍵を特定するために用います CP(Certificate Policy 証明書ポリシー ) を指定します また CPS(Certification Practice Statement 認証実施規定 ) への URL を指定します CP CPS については にて解説します 複数の CA が横断認証を行う場合に それぞれの CP を対応付けるために使用します 下位 CA に対して ポリシーマッピングの制限と CP の義務付けを行います 下位 CA に対して CP に AnyPolicy を記載した証明書を発行することを禁止します CRL(Certificate Revocation List 証明書失効リスト ) を入手するための情報を記載します CRL を配布する URI と 証明書の失効理由を記述できます デルタ CRL を入手するための情報を記載します 記述方法は crldistributionpoints と同様です 主体者の属性を指定します この項目は使用しないことが推奨されています CA や OCSP サーバなどの認証機関へアクセスするための方法を記載します アクセス方法は URI や電子メールアドレスで指定します 主体者へアクセスするための方法を記載します アクセス方法は authorityinfoaccess と同様です 31

34 X.509 デジタル証明書を発行する CA は その証明書の信用の基盤となるものです そのため CA を運用する際には 証明書の利用目的を定める CP(Certificate Policy 証明書ポリシー) と CA の運用方法を定める CPS(Certification Practice Statement 認証実施規定) を規定します CP と CPS のガイドラインは IETF によって 1999 年に RFC 2527 とし公開され 2003 年に RFC 3647 として改訂されています CP は 特定のコミュニティや共通のセキュリティ要件をもつ特定の分野に対して 証明書の適用 可能性を示すものです つまり この証明書が十分に信用に応えられるかどうか あるいは 特定 のコミュニティや分野に対して適切であるかどうか の判断材料となります CP をサポートするために X.509 デジタル証明書中の次のフィールドが使用されます certificatepolicies( 証明書ポリシー ) この項目は 証明書を発行する CA が 適用可能であると宣言する CP を掲げます policymappings( ポリシーマッピング ) この項目は CA 証明書においてのみ使われます 発行元 CA のポリシーが 発行先の CA のポリシーと同等であることを示すために用います 例えば あるドメイン X の CA が別のドメイン Y 宛に横断証明書 (Cross-Certificate) を発行する場合 この項目を設定することによって ドメイン Y のポリシーをドメイン X の同等なポリシーで処理できることになります policyconstraints( ポリシー制約 ) この項目は 2 つのオプション的な機能をサポートします ひとつは CA が 証明書パス中の後続のすべての証明書の中に CP が明示されていること を要求できる機能です もうひとつは CA が証明書パスにおける後続の CA によるポリシーマッピングを不能にする機能です これは ドメイン外のエンティティを認証する際に 連鎖的な信用に起因するリスクをコントロールすることができます 例えば ドメイン A はドメイン B を信用し ドメイン B はドメイン C を信用するが ドメイン A はドメイン C を信用することを強制されたくない場合に有効です CPS(Certification Practice Statement 認証実施規程) は CA によって 証明書を発行する際の運用についての宣言や証明書ライフサイクルにわたるサービス ( 例 : 発行 管理 失効 更新 鍵の再生成など ) に関する運用を規定する文書です CPS は 一般的にひとつの CA またはひとつのドメイン内の複数の CA が従うべき手順と手続きを包括的に規定したものです CPS は 信頼性の高いシステムの詳細や システムの運用と証明書の発行を支援するための手順の詳細を 認証局が宣誓するという形式をとることがあります また 認証局に適用する規約または規則の形をとったり 認証局と証明書の発行対象者であるエンティティとの間の契約に含まれることもありま 32

35 す 詳細な CPS は 取り扱いに注意を要する そのシステムについての詳細を含む可能性がある ため CA はその CPS の全体を発行しないことを選ぶことができます CP と CPS は 公開鍵証明書が信頼されるべき程度 および 公開鍵証明書が信頼されるべき目的 の観点からは 同じ論点に対応します CP と CPS の違いは その目的にあります CP の目的は要求を確定することですが CPS の目的は手順と手続きを明らかにすることです 言い換えれば CP は WHAT( 要求が何か ) を明らかにするもので CPS は HOW( どのように要求に対応するか ) を明らかにするものであるといえます CP と CPS の違いの概略を下表 ( 表 1.2-5) に示します 表 1.2-5: CP と CPS の違い CP( 証明書ポリシー ) CPS( 認証実施規定 ) 内容証明書の目的や利用用途を規定する CA の運用管理について規定する 目的 関係者に対する要求を明確にする関係が何を (WHAT) を行う必要があるかを説明する 位置づけ最上位レベルのポリシー文書 CP よりも下位の文書 関係者が要求に対応する方法を明確にする関係者がどのような方法で (HOW) 実施するかを説明する 詳細度詳細は他の文書に任せている詳細の多くまたはすべてを提示する 範囲 一般に複数の CA を扱う 一般にひとつの CA( またはひとつのドメインが運用する複数の CA) を扱う 33

36 1.2.3 クレデンシャルのライフサイクル クレデンシャルには限られた有効期間が設定されます エンティティの状態 ( 例えば 所属している企業との関係やシステムとの関係など ) が変化するにつれて その身元も変化することがあります また クレデンシャルの秘密情報が事故によって漏洩したり 攻撃者が解読に成功したりして クレデンシャルがエンティティの身元を保証できなくなることもあります このような場合には クレデンシャルを失効して 必要に応じて再発行します クレデンシャルの発行から失効 更新まで クレデンシャルの発行から失効 更新までのライフサイクルを下図 ( 図 1.2-5) に示します 図 1.2-4: クレデンシャルのライフサイクル 1 クレデンシャルの発行 クレデンシャルを生成して エンティティに配布するまでのフェーズです 申請 RA はエンティティ ( 申請者 ) からの発行申請を受け付け エンティティの本人確認 ( 身元確認 ) を行います 発行 RA が確認を行った結果 問題がなければ CSP はアイデンティティ情報の登録とクレデンシャルの発行を行います 配布 CSP は発行したクレデンシャルを申請者に配布します 34

37 2 クレデンシャルの利用 活性化クレデンシャルを各エンティティが利用することができます 利用各エンティティは認証などでクレデンシャルを利用します 保護各エンティティはクレデンシャルを安全に管理し 漏洩などの危険からクレデンシャルを保護しなければなりません 3 クレデンシャルの休止 クレデンシャルの利用が休止されるフェーズです 4 クレデンシャルの失効 クレデンシャルの期限切れなどの理由によって クレデンシャルの利用を終了するフェーズです 期限切れ クレデンシャルには有効期間が設定されており 期限切れになるとクレデンシャルは無効に なります 5 更新 クレデンシャルの期限切れ後も引き続き利用する場合は 更新の手続き ( パスワードや秘密情報 の変更など ) を行います X.509 デジタル証明書のライフサイクル具体的なクレデンシャルのライフサイクルについて X.509 デジタル証明書を例にとって解説します 順に説明する便宜上 X.509 デジタル証明書 ( 図中 証明書 ) のライフサイクルを下図 ( 図 1.2-6) のように再整理します 35

38 図 1.2-5: X.509 デジタル証明書のライフサイクル 1 証明書の発行証明書を生成して エンティティに配布するまでのフェーズです 証明書の発行プロセスには 大別して 2 つのモデルがあります ひとつはエンティティ ( 申請者 ) が鍵ペアを生成する方式 ( 図 1.2-7) であり もうひとつは RA もしくは CA が一括して鍵ペアを生成する方式 ( 図 1.2-8) です これらのモデルは 用途に応じて使い分けられます 図 1.2-6: 証明書発行 ( エンティティ鍵生成モデル ) 36

39 図 1.2-7: 証明書発行 ( 一括鍵生成モデル ) 証明書発行の流れは 以下のようになります 申請エンティティは CA または RA に対して 証明書の発行申請を行う CA または RA は エンティティの本人確認 身元確認を行います 要求される本人確認レベルは CP および CPS に定められた証明書の利用用途と運用ポリシーによって異なります 鍵ペア生成エンティティあるいは RA が鍵ペア ( 公開鍵とプライベート鍵のペア ) を生成します IC カードなどのハードウェアトークンを利用する場合は ハードウェアトークン内で鍵ペアを生成する方法と 安全な暗号鍵生成装置で生成した鍵ペアおよび証明書を後から格納する方法があります 発行 CA は確認した申請内容とエンティティの公開鍵に対してデジタル署名を施し 証明書を発行します 配布発行した証明書をエンティティに配布する 鍵ペアを RA で生成した場合は プライベート鍵も一緒に配布します あるいはプライベート鍵と証明書を格納した IC カードなどのハードウェアトークンを安全な方法で配布します 公開証明書の利用者がその証明書を参照できるように CA は発行した証明書を LDAP ディレクト 37

40 リや Web サーバのようなリポジトリに登録します ( リポジトリが存在する場合に限ります ) 2 証明書の利用 発行された証明書をエンティティが利用するフェーズです 取得証明書の利用者は 公開されているリポジトリなどから証明書を取得します 有効性検証証明書の利用者は 取得した証明書が信頼できるものであることを確認します 利用エンティティは 証明書とプライベート鍵を認証 暗号化 デジタル署名などで利用します また エンティティの公開鍵証明書の利用者は 復号やデジタル署名の検証などを行います 保護エンティティは プライベート鍵を安全に管理し 漏洩などの危険から保護しなければなりません 鍵回復プライベート鍵を破損してしまうと 暗号化したデータが読めなくなってしまいます このような場合 センターにバックアップしておくことで プライベート鍵を復旧させることが可能です ただし バックアップするプライベート鍵は 暗号化目的のものに限るべきです エンティティの否認防止の効果が無くなるため デジタル署名目的のプライベート鍵はバックアップするべきではありません 3 証明書の失効 更新 期限切れや失効などの理由で 証明書の利用を終了するフェーズです 引き続き証明書を利用する場合は 証明書の更新を行います 期限切れ証明書には有効期間が設定されており notafter( 終了時刻 ) に設定された時刻を越えると 証明書は無効になってしまいます これを証明書の期限切れといいます 失効プライベート鍵の漏洩や証明書の記載内容の変更などの理由で 有効期間内であっても証明書の信頼性が保たれなくなる場合があります この場合 CA は その証明書がもはや無効であることを証明書の利用者に通知します これを証明書の失効といいます 証明書が失効されたあとでも デジタル署名の検証を行うために 証明書を保存しておく場合があります 更新 38

41 証明書の期限切れ後も引き続き証明書を利用する場合は 有効期限切れとなる前に鍵ペアを再生成し 証明書の更新手続きを行います 証明書が破棄された後で更新を行うと 全く新規に発行する場合と同様の手続きが必要となってしまいます 証明書が有効であれば その証明書を使って本人認証を行うことができるので オンライン ( ネットワーク経由 ) で更新が行えます 39

42 1.3 運用管理ドメイン 運用管理ドメインとは ドメイン を経営学上の事業ドメインとして表す場合 組織が経営活動を行う 活動の範囲や領域 のことを指します 一方で ネットワークの世界での ドメイン は ネットワークを利用する組織 利用者 サービス コンピュータ サーバ プリンタやネットワーク機器などネットワーク上に存在する様々なエンティティやリソースを管理する範囲を表します インターネット上でドメインを識別するために それぞれのドメインには名前 ( ドメイン名 ) が割り当てられ 重複しないように発行 管理されています ドメインの運用管理における代表的な例として ディレクトリサービス が挙げられます ネットワーク上のエンティティやリソースとその属性を ディレクトリサービス と呼ばれるシステムによって管理するもので ドメイン内のエンティティやリソースの管理を一元的かつ体系的に行い これらのリソースの検索を行える仕組みを提供しています また ディレクトリサービス 内で対象のエンティティやリソースを運用管理する範囲 / 領域を 運用管理ドメイン と呼びます ディレクトリサービスの特徴は 主に以下の点となります ネットワーク上の様々なエンティティやリソース ( 人 属性 グループ 組織 ネットワーク機器 コンピュータ資源 セキュリティ情報 等 ) に関する情報を一元的 体系的に管理 情報の物理的な位置と論理的な位置を分離し 透明性を高めている 高度な検索サービスをきめ細かく提供 汎用的である ( 標準アクセスプロトコル 標準スキーマ 標準 API) データ ( エントリ 属性 ) をオブジェクトのツリー構造で表現 ディレクトリサービス は ITU-T(International Telecommunication Union - Telecommunication Sector: 国際電気通信連合の通信に関する技術の標準化を担当する部門 ) で X.500 として標準化されており Active Directory を含む多くの製品がこれに準拠しています ディレクトリサービス プロトコルとしては LDAP(Lightweight Directory Access Protocol) が広く使われています ディレクトリサービス では オブジェクトを一意に識別するために 識別名(DN Distinguished Name) を使用しています 複数の LDAP 相対識別名 (RDN Relative Distinguished Name) をカンマで区切って並べて表記します オブジェクトを表す識別名は ディレクトリサービス のツリー構造に従って 下位から上位へと属性を並べて表記します 40

43 例えば example.co.jp ドメインにある Sales という組織単位 (OU Organization Unit) に属する Saito というオブジェクトは 以下のような識別名で表されます 図 1.3-1: ディレクトリサービスのツリー構造例 cn=saito,ou=sales,dc=example,dc=co,dc=jp ドメインには組織全体で運用管理するドメインもあれば 組織内部門で運用管理するドメインもあります また インターネット上で複数の組織にまたがる運用管理ドメインも存在します これら いずれのドメインもその大小に関わらず 運用管理ドメイン内のエンティティを一意 ( ユニーク ) に管理するため エンティティに対して一意の識別名を割り当てます 図 1.3-2: 組織内ドメインおよびインターネット上の複数組織が含まれるドメイン 41

44 1.3.2 Windows ドメイン Windows システム上のネットワークリソース ( ユーザ グループ コンピュータ サーバ プリンタ フォルダ / ディレクトリ ファイル アプリケーション等 ) やその属性および権限を管理する範囲 / 領域の単位を Windows ドメインと呼びます Windows ドメイン領域内では 共通のセキュリティ原則とネットワークのユーザアカウントを共有することができ ドメイン内のリソースを一元的に管理することができます Windows ネットワークでは ドメイン内のリソースは Active Directory (Windows 2000 以降 ) ディレクトリサービスで管理され 同じディレクトリ データベースを共有する範囲をドメインと呼び ドメイン全体に対して統一されたセキュリティ設定を適用することができます 図 1.3-3: Active Directory Active Directory は エンティティ認証の基盤としての機能の他 ネットワークリソースの一元管理 グループポリシーの展開等の機能も提供できます また ドメインを DNS( ドメインネームシステム ) と関連付けることにより 複数の Active Directory ドメインを階層的な構造として管理することができるようになっています Active Directory のドメイン階層は DNS の名前階層を流用するため DNS の規則に従って階層を構成します すなわち 子ドメインは親ドメインの名前を継承ことになります このとき ツリーに参加するすべてのドメイン間には双方向の推移する信頼関係が結ばれます 実際にドメイン ツリーを作成する場合は 必ずツリーの末端にドメインを追加する必要があり 親 ( 上位 ) ドメインを後から追加することはできません 42

45 図 1.3-4: Active Directory のドメイン階層 なお 運用管理する範囲が異なる複数のドメイン ツリーからなる場合 ドメイン間に信頼関係を結び フォレスト (forest 森という意味) を構成することができます フォレストは ひとつ以上のツリーで構成された Active Directory における最も大きな管理単位となります 運用管理する範囲内に異なる名前空間にしたいドメイン ツリーが複数あり それぞれのドメイン ツリーから別ツリーのドメインの資源にアクセスするには ドメイン間に信頼関係を結びフォレストを構成する必要がでてきます ユーザやグループ コンピュータなど Active Directory で管理される情報の最小単位を Active Directory オブジェクト といいます オブジェクトには いくつかの属性 ( プロパティ ) が定義されており 関連付けられた情報をまとめて扱うことができます 例えば ユーザオブジェクトでは ユーザ名 の他に ログイン名 住所 電話番号 といった値を保持し検索することができます 43

46 図 1.3-5: Active Directory ユーザオブジェクトの属性 ( プロパティ ) オブジェクトの中には ユーザやコンピュータといったオブジェクトとは異なり オブジェクトの内部 にオブジェクトを含むことができるものがあります これを コンテナ オブジェクト と呼びます Active Directory では オブジェクトを一意に識別するために 識別名 (DN Distinguished Name) を使用しています また Active Directory ではオブジェクトの作成時にすべてのオブジェクトに対して 128bit のランダムな数値からなる一意の GUID(Globally Unique Identifier) を付け 内部的に管理しています オブジェクトを移動したり 変更したりしても この識別子は不変です アプリケーションなどは 利用するオブジェクトを GUID で格納して使用することにより 識別名 (DN) とは関係なくオブジェクトを検索することができます Active Directory には 認証の対象となりアクセス権の付与対象となるオブジェクトとしてセキュリ ティプリンシパル (Security Principal) があります 具体的にはユーザやユーザが所属するグルー プなどを指します また セキュリティオブジェクトには カテゴリおよび組織が含まれます 44

47 図 1.3-6: Active Directory のセキュリティプリンシパルとセキュリティオブジェクト セキュリティプリンシパルには GUID のほか一意のセキュリティ識別子 (SID) が割り当てられます Windows 自身がアカウントを参照する場合 ユーザ名やグループ名ではなく アカウントの SID を 参照します 一方 ユーザにとって分かりやすい名前でセキュリティプリンシパルを表す方法としてユーザプリンシパル名 (UPN) があります UPN は ユーザの略名とユーザオブジェクトがあるドメイン ツリーのドメインネームサービス (DNS) 名で構成されます 例えば example.co.jp ドメイン ツリーのユーザアカウント名 Saito の UPN は などになります このように 誰が何を参照するか あるいは相手が何を信頼するかによって Windows では異なる 識別子を使い分けています なお Windows ドメインへのログオン認証として Windows 2000 より Kerberos が採用されており マスタ鍵などのセキュリティ上重要な情報は Active Directory 機構に格納されます この仕組みは標準的な Kerberos の相互運用性の要件を満たしているため Windows システム / アプリケーションのみならず 非 Windows システム / アプリケーション間で後述の Kerberos チケット交換が可能となり 一度のログオン認証で Kerberos 化された非 Windows を含むシステム / アプリケーションを利用することができるようになります 45

48 1.3.3 Kerberos レルム Kerberos は そのプロトコル仕様が RFC 4120 や RFC 4121 によって規定されているネットワーク認証システムの名称です 信頼された第三者機関による認証方式 (Trusted Third Party Authentication) を行うインターネット標準プロトコル仕様となっており ネットワーク上のサーバとクライアント間で 秘密鍵暗号 ( 共通鍵暗号 ) を用いて通信経路上の安全が保証された状態で身元の確認を行います これによって オープンで保護されていないネットワーク上で ホスト OS の認証機構に頼ることなく またネットワーク上の全ホストが物理的に安全であることを要求せず ネットワーク上を流れるパケットは 読み 書き ( 改変 ) 変更( 偽造 / 改竄 ) され得ることを前提として クライアント / サーバ双方の身元をセキュリティが確保された状態で確認できる手段を提供しています また Kerberos 認証サービスでは 複数のサーバと複数のユーザの認証情報を一元管理してお り ユーザが複数のサーバを利用する際 一度認証を受けるだけで他のサーバへもアクセスでき る仕組みを提供しています Kerberos による認証は ネットワークへのログオン と リソースへのアクセス の 2 つのフェーズ で行われます (1) Kerberos 認証構成コンポーネントサーバやユーザに関しての信頼関係の情報を一括して管理する機関を KDC(Key Distribution Center) といいます KDC は ユーザからの認証を受け付ける AS(Authentication Server) 各サーバを利用するためのチケットを発行する TGS(Ticket Granting Server) により構成されています KDC が認証するサーバやユーザのことを プリンシパル (Principals) と呼び これらを 1 ひとつの かたまりとして扱い そのかたまり ( ひとつの KDC が管理するプリンシパルの集合 ) を レルム と 呼びます ここでは レルム (Realm) は 運用管理ドメイン の同義語と見なします 46

49 図 1.3-7: Kerberos 認証に関係するコンポーネントとその名称 すべてのプリンシパルは あらかじめ KDC に自らの鍵データを登録しておく必要があります KDC は 自分のレルム内のすべてのプリンシパルの識別子 (Principal Identifier) とその秘密鍵を管理し プリンシパルから要求があれば プリンシパル間での認証処理を行えるように手配します このように専用の鍵管理サーバによってクライアント / サーバ間のセキュリティを確保しているため 信頼された第三者機関による認証方式(Trusted Third Party Authentication) と呼ばれています 以下に Kerberos 認証のフローシーケンスをユーザ A が ID/ パスワードによる認証によりファイル サーバ F を利用する時の流れに照らし合わせて説明します 図 1.3-8: Kerberos 認証のフローシーケンス 1 ユーザ A は KDC の AS に認証してもらいます 2 AS の認証評価のもと 正しい ID とパスワードで認証に成功すると AS からユーザに対して TGT(Ticket Granting Ticket: チケット発行のための大もとのチケット ) が発行されます 47

50 3 ユーザは KDC の TGS(Ticket Granting Server) に対して 実際にアクセスしたいサーバへの利用権を請求します 4 TGS はユーザに対して F へのアクセスチケットを発行します 5 ユーザはこれを受取り アクセス先のサーバへ提示します 提示されたチケットを受け取ったサーバは ユーザを認識し そのユーザにあったアクセスを許可します 発行されるそれぞれのチケットには チケットの有効期間が設定されています チケットが期 限切れになると プリンシパルは承認されなくなり 新しいチケットを入手するまでは追加の作 業を行うことはできなくなります Kerberos レルムは 同じ Kerberos データベースを共用する一組の管理対象ノードを指します 個々の Kerberos プリンシパルはプリンシパル識別子によって識別されます プリンシパル名は サービスまたはユーザ名 インスタンス名 およびレルム名という 3 つの部分から構成され 次のような形式で表されます user-name.instance-name@realm-name 例えば ユーザ プリンシパルについては joe.user@realm1 のように 特定のレルムについてユーザが持っている許可の役割を表したプリンシパル名を使用できます また サービス プリンシパルについては ftp.host1@realm2 のように コンピュータシステム上のサービスの位置を表したプリンシパル名を使用できます プリンシパル名のインスタンス部分は任意指定ですが 指定しておけばサービスが置かれているコンピュータシステムを識別するのに便利です Kerberos は 異なるコンピュータシステム上にある同じサービスを 別々のサービス プリンシパルとして認識します プリンシパルはそれぞれプリンシパル パスワードを持ち Kerberos は認証プロセス中にサービスとユーザを認証するためにこれを使用します Kerberos では ネットワーク上のひとつのコンピュータシステム上のプリンシパルは ネットワーク内の別のコンピュータシステム上のプリンシパルと対話するときに サービスやユーザが自称しているとおりの存在であることを確認することができます (2) レルム間横断運用 (Cross-realm Operation) Kerberos プロトコルは 組織間の壁を越えて動作するように設計されています ある組織のクライアントは 他の組織のサーバで認証できます Kerberos サーバを実行したい各組織は 独自の レルム を確立します 48

51 レルム間 鍵を確立することにより 2 つのレルムの管理者は ローカルレルムで認証されているクライアントがその認証を遠隔から使えるように許可できます レルム間鍵の交換 ( 各方向には独立した鍵が使用されます ) は 各レルムのチケット交付サービスを他のレルム内のプリンシパルとして登録します その後 クライアントは そのローカルのレルムから リモートレルムのチケット交付サービス用のチケット交付チケットを取得できるようになります そのチケット交付チケットが使用されると リモートのチケット交付サービスは レルム間鍵 ( 通常 独自の TGS 鍵とは異なる ) を使用してチケット- グランティングチケットを解読し それがクライアントの独自の TGS によって発行されたことを確証します リモートのチケット交付サービスによって発行されたチケットは クライアントが他のレルムで認証されたことを終端サービスに示します 2 つのレルムがレルム間鍵を共有するか またはローカルレルムがリモートレルムと通信する中 間レルムとレルム間鍵を共有する場合 レルムは他のレルムと通信していることになります 証明 書パスは レルム間で通信する場合に転送される一連の中間レルムです 一般的に レルムは階層的に編成されています 各レルムは 親と鍵を共有し 各子供と別の鍵を共有します レルム間鍵が 2 つのレルムによって直接共有されていない場合 階層的な編成によって容易に証明書パスを作成できます 階層的な編成を使用していない場合 レルムの間の証明書パスを作成するにはデータベースを参照する必要があります 一般的にレルムは階層的ですが 代替の証明書パス経由でクロスレルム認証を行う場合 中間レルムは迂回されることがあります ( これらは 2 つのレルム間の通信をより効率的にするために確立されています ) 認証プロセスの信頼性を決定するのに どのレルムが転送されたかを知っておくことは終端サービスにとって重要です この決定が容易に行えるように 各チケット内のフィールドにはクライアントの認証に関係したレルムの名前が含まれています 49

52 1.3.4 PKI ドメイン PKI ドメイン という言葉を定義するには 信頼関係 の定義を行う必要があります PKI ドメイン は 同じポリシーを持つ PKI と異なるポリシーを持つ PKI との境界を示すためのものと位置付けら れます 異なるポリシーを持つ PKI と相互運用して初めて必要となる概念であるとも言えます PKI の利用者がすべてひとつの CA(Certificate Authority 認証局) だけに依存した管理 運用を行うことは現実的に不可能なため 複数の CA 間の信頼関係により ある CA で作成された本人性を別の CA で信頼することが可能になります その際の信用モデルは CP(Certificate Policy 証明書ポリシー )/CPS(Certification Practice Statement 認証実施規定) によって規定したポリシーを明示的に共有し 同じルールに基づいて利用 / 運用するか トポロジとして階層型の信頼モデルにもとづいた信頼関係のもと 運用するなどの方法があります PKI ドメインにおける信用モデルを以下に示します 種類 単独 CA モデル 階層型モデル メッシュモデル ブリッジ CA モデル Web モデル 表 1.3-1: 信用モデルの種類 説明 ひとつの CA がすべてのエンティティに証明書を発行する方式です 複数の CA を階層型 ( ツリー構造 ) に構成する方式です 複数の CA を横断認証により接続する方式です 複数の CA がブリッジ CA を介して接続する方式です あらかじめクライアントのアプリケーションにルート CA の一覧を埋め込む方式です Web ブラウザで用いられています 実際には これら複数の信用モデルを組み合わせて運用する場合があります これをハイブ リッド型といいます 1 階層型モデル 図 1.3-9: 階層型モデル例 50

53 階層型モデルはエンティティにも 検証者にも分かりやすく 検証のしやすさなどのメリットがある ため 比較的よく用いられる信頼モデルです このモデルでは 信頼点をルート CA とすることで エンティティ同士および検証者が相互に信頼することが可能となります 2 横断認証モデル 図 : 横断認証モデルの例 横断認証モデルとは 各々の階層型モデルのルート CA 間で互いに信頼関係を構築することによ り実現するものです 政府 PKI(GPKI:Government PKI) や地方自治体 PKI(LGPKI:Local Government PKI) の認証基盤 で使われている BCA(Bridge CA ブリッジ CA) による相互接続もこの横断認証モデルに含むこと ができます 横断認証モデルでは 認証ポリシーの異なる階層型モデルのルート CA 同士の信頼関係を構築 するため 本来は信頼関係のなかったエンティティ同士の信頼関係もルート CA の横断認証により 可能になるというものです 3 ブラウザにプリインストールされているルート CA を信頼する (Web モデル ) 51

54 図 : ブラウザにプリインストールされているルート CA の例 Web モデルは一般に広く利用されているブラウザにプリインストールされているルート CA を信頼 するモデルです 信頼といっても信頼点を利用者が選択できるわけではなく 各ブラウザメーカの 信頼点選定基準を満たした信頼点を信頼することになります 52

55 2 基礎理論 2.1 エンティティ認証 概要 エンティティ認証は エンティティのアイデンティティ情報に関する信用を確立するプロセスです 認証要求者であるエンティティは 検証者に対して クレデンシャルと認証プロトコルを使用することによって 自分が確かにアイデンティティ情報に結びついたエンティティであることを証明します すなわち 認証プロセスは 認証要求者のアイデンティティ情報を特定し クレデンシャルを保持していることを検証することによって 当該エンティティが主張するアイデンティティ情報との同一性を検証するプロセスです 図 2.1-1: エンティティ認証 検証者は認証要求者が正当なクレデンシャルの持ち主であることを確認すると 認証要求者のアイデンティティ情報や認証に関する情報を検証結果の利用者 ( 検証結果を利用するシステムやアプリケーション ) に渡します 検証結果の利用者は 検証者から渡された認証要求者のアイデンティティ情報や認証情報に基づき 認証要求者がシステムやアプリケーションの特定のリソースにアクセスする際のアクセス制御または認可を行います 一般的には 検証者と検証結果の利用者は同一のシステムやアプリケーションであることが多いのですが 検証者と検証結果の利用者が別のシステムやアプリケーションである場合 これらの情報を伝達するために検証者が作成するオブジェクトをアサーションといいます アサーションは デジタル署名されたオブジェクトであったり セキュアなプロトコルを通じて信頼できる情報源から取得できたりします アサーションの例としては SAML アサーションやクッキーなどがあります SAML アサーションの詳細については 6.2 節で解説します アサーションを含めたエンティティ認証のモデルを下図 ( 図 2.1-2) に示します 53

56 図 2.1-2: エンティティ認証のモデル 自然人のエンティティ認証について 伝統的には次の 3 つの基本要素が挙げられています 本人の記憶に基づくもの ( パスワード PIN など ) 本人の所持に基づくもの (IC カード ワンタイムパスワードトークンなど ) 本人のバイオメトリクス情報に基づくもの ( 指紋 虹彩など ) ひとつの要素で認証を行うよりも 2 つまたは 3 つの要素で認証を行う多要素認証の方がより強固な認証であるといえます 例えば ワンタイムパスワード認証では PIN とワンタイムパスワードトークンの 2 つの要素で認証を行うことが考えられます また X.509 デジタル証明書による認証では プライベート鍵を IC カードに格納し パスワードやバイオメトリクス認証によってプライベート鍵を活性化することも考えられます 近年 金融系の Web サイト等において リスクベース認証 と呼ばれるエンティティ認証が行われることがあります これは 通常の ID/Password 認証に加えて 内部的に保持する当該エンティティのアクセス状況や IP アドレス パソコンやブラウザの設定情報等の行動パターンと照らして不正アクセスのリスクを判定し 疑いがある場合 追加で別の認証手段を用いたエンティティ認証を行うものです このように行動パターンもエンティティ認証の要素に含められる事例があります 54

57 2.1.2 パスワードによるエンティティ認証 パスワードによる認証は もっとも一般的に利用されているエンティティ認証です パスワード認証 の概略を下図 ( 図 2.1-3) に示します 図 2.1-3: パスワードによる認証 1 認証要求者であるエンティティは 検証者にパスワードを送信します オンラインでの認証で パスワードを平文のまま送信することは ネットワーク上での盗聴の危険性が高いため 通常は暗号化を行います パスワードそのものを暗号化する方法もありますが SSL などの暗号通信プロトコルを利用するのが一般的です 2 検証者は 認証要求者から送られたパスワードを データベース等に格納されているそのエンティティのパスワードと比較し 一致していれば認証が成功します パスワードは データベース等に平文のまま格納されることはなく 通常は解読不能な状態 ( ハッシュ値 ) で格納します 3 検証者は 認証要求者に認証結果を返します パスワードそのものを送信せずに認証を行う方法として チャレンジ / レスポンス方式があります チャレンジ / レスポンス方式によるパスワード認証の概略を下図 ( 図 2.1-4) に示します 55

58 図 2.1-4: パスワードによる認証 ( チャレンジ / レスポンス方式 ) 1 認証要求者であるエンティティが検証者にアクセスすると 検証者はチャレンジコード ( 乱数 ) を認証要求者に返します 2 認証要求者は パスワードのハッシュ値を鍵として使用し 検証者から送られたチャレンジコードを暗号化します 3 認証要求者は 暗号化されたチャレンジコードをレスポンスとして検証者に返します 4 検証者は データベース等に格納されているそのエンティティのパスワードのハッシュ値を鍵として 送られてきたレスポンスを復号し 最初に送ったチャレンジコードと一致すれば認証が成功します 5 検証者は 認証要求者に認証結果を返します パスワード認証は実装が容易で利用者にも受け入れられやすいため 多くのシステムで利用されています しかしながら 偽装者はパスワードを入手するだけで身元を偽ることができてしまいます また 人間が無作為の長いパスワードを記憶する能力は限られているため 推測やよく使われるパスワードを集めた辞書 パスワードとして考えられるすべての可能性を試す単純な行為といった さまざまな攻撃に対して脆弱であることが多い認証方式です パスワードに対する主な攻撃には 下記のものがあります 総当たり攻撃すべてのパスワードの組み合わせを試行する攻撃である 非常に多くの組み合わせがあるため 効率的ではありませんが パスワード長が非常に短い場合 ( 例えば 数字 4 文字など ) には有効です また 総当たりする順番を工夫し 短いパスワード 小文字だけのパスワード 大文字が含まれるパスワード 長いパスワードといった順で攻撃していくこともあります 類推攻撃利用者の個人情報 ( 例えば ユーザ名 / ログイン名 恋人 / 友人 / 身内 / ペットの名前 自 56

59 分 / 友人 / 身内の出身地や誕生日 車のナンバープレート 携帯電話の番号 会社の電話番号 住所 お気に入りの有名人の情報など ) からパスワードを類推する攻撃です 辞書攻撃パスワードとして使われていそうな文字列を数多く収録したリスト ( 辞書 ) を用意して それらを試行する攻撃です 事前計算攻撃 ( オフライン ) パスワードファイルを盗んで パスワード辞書の文字列をハッシュ化して それらを試行する攻撃です これらの攻撃を防ぐためには パスワードの選び方やライフサイクルに関するパスワードポリシーを規定して パスワードを運用 管理することが重要です また 後述するシングルサインオン (SSO) の技術を積極的に利活用することによって 管理対象となるエンティティ認証機能を集約することができます まず パスワードポリシーにおいて考慮する事項を示します 初期パスワードエンティティを登録する際に初期設定するパスワードです 管理者やシステムが決定する場合には 推測しにくいパスワードを設定し 当該パスワードの通知方法についても 本人以外が目にすることがない手段で伝達する必要があります さらに エンティティが初めてシステムにアクセスした時に 初期パスワードを本人のみが知りえるパスワードに変更することを求めるような実装が望ましいといえます また 他のシステムにおいて利用しているパスワードと同一のものを避けたいところです 他のシステムのパスワードが攻撃者に判明してしまった際に 同一のパスワードを試行されたらエンティティ認証を通ってしまうからです パスワードの有効期間パスワードが攻撃者に奪われる懸念がある環境においては 同一のパスワードを使用し続けることができる日数を制限します ( 例えば 組織内で肩越しに打鍵を見られてしまう懸念がある環境が挙げられます ) また パスワードが他人に漏洩している懸念がある際には強制的にパスワードの変更を促す必要があります パスワードの履歴システムは 過去に使用したパスワードの履歴を保持し エンティティがパスワード変更時に新たに設定することができるパスワードを制御する必要があります 例えば 現在使用中のパスワードを含め 直近 3 つまでのパスワードの履歴をシステムで保持する場合 エンティティは これら 3 つのパスワードと同一のパスワードを新しいパスワードとして再利用することを禁じられます 57

60 パスワードの最小有効期間パスワードの変更後から次の変更が可能になるまでの最小期間を規定することにより ユーザがパスワードを繰り返し変更して履歴機能を回避し 旧パスワードをすぐに再利用してしまうことを防ぎます パスワード最小文字長パスワードに割り当てなければならない最小文字数です パスワードの長さを長くすることにより より安全性を高めることができますが 反面 長すぎると覚えにくくなり パスワードを書き留めて 安全でない場所 ( 例えば PC のディスプレイ ) に貼り付けるなどしてしまう危険もあります 禁則文字列パスワードとして使用不可にする文字列です 例えば # $ * を [ 禁則文字列 ] とした場合 システムは pass#word pa$$word および p*ssw*rd などのパスワードを拒否し これらの文字列を排除したパスワードを求めます 利用禁止単語利用禁止単語は パスワードとして使用することができない単語の定義です 辞書ツールを使ったシステムへの侵入攻撃によく使用される password のような単語をパスワードとして使用することを排除します 文字列の組み合わせパスワードに大文字 小文字 アルファベット以外の文字 ( 数字や特殊文字 ) を 1 文字以上指定するルールです ( 例 : Pa9ss!wo6rd ) パスワードポリシーを作成する上で重要なパスワードの強度の考え方については 5.1 節において 解説します また ソーシャルエンジニアリングと呼ばれる 人間の心理的な隙や行動のミスにつけ込んでパスワードを入手する方法もあります 例えば システムの管理者を装って あなたのユーザ情報が消えてしまったので 復元するためにパスワードを教えてください といった電話をして パスワードを聞き出すようなことが考えられます このような攻撃は パスワードポリシーの遵守だけでは 防ぐことができません このような攻撃を防御するためには 自分のパスワードはどんなことがあっても決して他人には教えないことを徹底するか IC カードやワンタイムパスワードトークンを利用した より強力な認証方式を採用する必要があります 58

61 2.1.3 ワンタイムパスワードによるエンティティ認証 ワンタイムパスワードは 使い捨てパスワードとも呼ばれ 一度だけ利用できるパスワードを生成して認証に利用します ワンタイムパスワードには チャレンジ / レスポンス方式 イベント同期方式 時刻同期方式などがありますが ここでは ワンタイムパスワードトークンと呼ばれるハードウェアトークンを利用した時刻同期方式のワンタイムパスワードについて解説します ワンタイムパスワードトークンには 液晶ディスプレイが付いており 6 桁あるいは 8 桁の数字列のパスワードを生成して 表示します エンティティ ( 認証要求者 ) は ワンタイムパスワードトークンに表示される数字列と 記憶している PIN(Personal Identification Number 暗証番号) をクレデンシャルとして検証者に提示します ワンタイムパスワードは ワンタイムパスワードトークン ( 本人の所持に基づくもの ) と PIN( 本人の 記憶の基づくもの ) の 2 つの要素で認証を行う二要素認証となります ワンタイムパスワードによる認証の概略を下図 ( 図 2.1-5) に示します 図 2.1-5: ワンタイムパスワードによる認証 1 認証要求者であるエンティティは 検証者にワンタイムパスワードと PIN を送信します ワンタイムパスワードトークンには シークレットと呼ばれるトークンごとにユニークなコードが割り当てられています このシークレットと現在時刻からワンタイムパスワードが生成されます 2 検証者は 認証要求者から送られた PIN を データベース等に格納されているそのエンティティの PIN と比較し 一致すれば次のステップに進みます 3 検証者は データベース等に格納されているそのエンティティのシークレットと現在時刻からワンタイムパスワードを計算し エンティティから送られたワンタイムパスワードと比較し 一致すればワンタイムパスワードの認証は成功します 4 検証者は 認証要求者に認証結果を返しますす 59

62 時刻同期方式のワンタイムパスワードは ワンタイムパスワードトークンの時刻と検証者側 ( サー バなど ) の時刻が合っていることが前提となりますが 実際にはある程度の時刻のずれを考慮し て 設計 実装されています また 携帯電話やスマートフォンにワンタイムパスワードのソフトウェアを実装し ワンタイムパス ワードトークンとして利用する形態や 電子メールや Web ブラウザにワンタイムパスワードを送付 表示する形態など 様々な実装形態が考案されています ワンタイムパスワードによる認証は 強固かつ安全な認証ではありますが 運用上 実装上で注 意すべき点を以下に示します シークレットの漏洩ワンタイムパスワード認証を利用するにあたって エンティティが最も注意しなければならないのは シークレットの漏洩です シークレットは 通常ワンタイムパスワードトークン ( ハードウェア ) 内に安全に格納されていますので そこから取り出すことはできません 従って 注意すべきはワンタイムパスワードトークンの盗難や紛失です ワンタイムパスワード認証では 通常は PIN と組み合わせて利用するため 万が一トークンが盗難 紛失しても PIN がわからなければ不正に利用されることはありません しかしながら PIN は通常 4 桁程度の数字であることが多く 簡単に推測されてしまう危険性がありますので トークンが盗難 紛失した際には すぐに管理者へ通知して トークンを失効する必要があります また PC や携帯電話 / スマートフォンなどのデバイス上で動作するソフトウェアトークンについては シークレットを外部から入力したり ファイル等に保存したりするため シークレットの漏洩の危険性がありますので 注意が必要です さらに デバイスの盗難や紛失時の不正利用を防ぐために デバイス利用時の認証の仕組み ( パスワードロックなど ) を利用すべきです PIN の漏洩上述のとおり PIN はシークレット漏洩時の不正利用を防ぐためにも設定しておく必要があります 通常は 4 桁程度の数字であることが多いため 連続する数字や推測されやすい数字 ( 誕生日や携帯番号など ) は避ける必要があります また 定期的に変更することも安全性を高める上で考慮すべきです シークレットの漏洩や PIN の漏洩に備えて ワンタイムパスワードの認証失敗回数がシステムで設定された回数 ( 累計回数または連続失敗回数 ) に達した場合 エンティティからのアクセスをロックアウトする仕組みを実装すべきです 中間者による攻撃 (man-in-the-middle attack) この攻撃は ワンタイムパスワードを利用する認証要求者 ( エンティティ ) と検証者 ( 例えば Web サイトなど ) の間の通信を盗聴することによって行います この攻撃は 例えば エンティ 60

63 ティをあたかも本物の Web サイトであるかのように振舞う偽の Web サイトに誘導して ログインさせることによってワンタイムパスワードを盗み そのパスワードで本物の Web サイトにアクセスするという方法があります このような攻撃を防ぐためには アクセスする Web サイトが本物であることを十分に確認する必要があります 61

64 2.1.4 X.509 デジタル証明書によるエンティティ認証 X.509 デジタル証明書による認証は デジタル署名を検証する技術を使って行われます 具体的には X.509 デジタル証明書による認証は 認証プロトコルを用いて X.509 デジタル証明書中の公開鍵に対応するプライベート鍵をエンティティ ( 認証要求者 ) が保持していることを確認することによって行われます X.509 デジタル証明書を用いた認証プロトコルの多くは チャレンジ / レスポンス方式を利用しており サーバがクライアントに送るチャレンジ ( 乱数 ) に自動的に署名させ サーバはその署名を検証してクライアントを認証します X.509 デジタル証明書による認証の概略を下図 ( 図 2.1-6) に示します 図 2.1-6: X.509 デジタル証明書による認証 1 認証要求者であるエンティティは 検証者に対して証明書を提示します 2 検証者は 証明書の有効性を検証します 3 検証者は 証明書が有効であればチャレンジコード ( 乱数 ) を認証要求者に送ります 4 認証要求者は プライベート鍵を使ってチャレンジコードにデジタル署名を行い レスポンスを作成します 5 認証要求者は レスポンスを検証者に送ります 6 検証者は 証明書内の公開鍵で レスポンスのデジタル署名を検証し 署名が正しければ認証が成功します 7 検証者は 認証結果を認証要求者に返します 一方 エンティティ認証に使用する証明書の正当性 有効性を検証するには 信頼できる第三者 (Trusted Third Party) 機関の認証局(CA) より発行された証明書であることを確認する必要があります CA が本当に信頼できる機関でなければ X.509 デジタル証明書による認証は成り立ちません 検証者は あらかじめ信頼できる CA を登録あるいは決定しておく必要があります 62

65 証明書の有効性を検証する手順を下図 ( 図 2.1-7) に示します 図 2.1-7: 証明書の有効性検証 デジタル署名の検証のために取得した証明書は 使用する前にその証明書の有効性を検証する 必要があります 有効性検証は 証明書パスの構築 と 証明書パスの検証 の 2 段階で行われ ます 証明書パスの構築 では 対象となる証明書が信頼している CA と関係あることを確認します 利用者が信頼している CA のことを ルート CA または 信頼点( トラストアンカー ) といいます 対象となる証明書を発行した CA( 図 では下位 CA2) がルート CA ではなく他の CA の子となっている場合は ルート CA に到達するまで上位の CA をたどっていきます 図では頂点の CA( トップ CA) がルート CA なので それぞれの証明書の issuer( 発行者 ) をたどり エンティティ 下位 CA2 下位 CA1 トップ CA が繋がっていることを確認します このような信頼点までの認証チェーンを 証明書パス と呼びます 証明書パスの検証 では 証明書パスのルート CA から対象となる証明書までのすべての証明 書に対して 以下の事項を検証します 証明書のデジタル署名が正しいこと 証明書の有効期間の期限が切れていないこと 証明書が失効されていないこと 63

66 証明書に記載された CP( 証明書ポリシー ) が一致しており 制約条件を満たしていること これらすべての検証が成功した場合にはじめて 対象となる証明書が信頼できることになります X.509 デジタル証明書による認証を利用した代表的な通信プロトコルを以下に示します SSL(Secure Sockets Layer)/TLS(Transport Layer Security) SSL は 1990 年代に Netscape 社によって提唱されたプロトコルであり その後 SSL バージョン 3.0 をベースにして IETF において TLS が策定されました SSL/TLS は X.509 デジタル証明書を利用したクライアント認証とサーバ認証を行うことができ クライアントとサーバ間のデータ通信を暗号化します SSL/TLS は 主に Web ブラウザと Web サーバ間の通信で利用されることが多く https で始まる URL にアクセスすると この SSL/TLS による通信が行われます VPN(Virtual Private Network) VPN はインターネットを利用して安全な仮想的私設網を実現する技術です VPN には 2 つのネットワークを接続する場合と 端末とネットワーク間を接続する場合があります VPN のプロトコルとしては IPSec(Security Architecture for Internet Protocol) と SSL の技術を利用した SSL-VPN がよく使われており ともに X.509 デジタル証明書を利用した認証と暗号通信を行うことができます X.509 デジタル証明書による認証は かなり強固かつ安全な認証ではありますが 運用上 実装 上で注意すべき点を以下に示します プライベート鍵の漏えい X.509 デジタル証明書を利用するにあたって エンティティが最も注意しなければならないのは プライベート鍵の漏洩です プライベート鍵が漏洩すると 対応する X.509 デジタル証明書は安全なクレデンシャルではなくなるため すぐに無効にする ( 失効する ) 必要があります プライベート鍵を保護するためには いくつかの方法があります プライベート鍵を PC 上のファイルで保存しておく場合には パスワードや PIN でプライベート鍵を暗号化しておくことが一般的です しかしながら そのファイル自体が漏えいしてしまった場合には パスワードに対する攻撃手法により 解読されてしまう危険性があります プライベート鍵をより安全に保護するために IC カードなどのハードウェアトークンに保存しておく方法があります ハードウェアトークン内で鍵ペア ( 公開鍵とプライベート鍵 ) を生成するため プライベート鍵はハードウェアトークンから外に出ることがなく 漏えいの危険性が非常に低く安全です ハードウェアトークンを利用する際には パスワードや PIN による認証を行うことで ハードウェアトークンの盗難や紛失時に不正に利用されることを防ぐことができます 64

67 認証プロトコルを悪用した署名 X.509 デジタル証明書による認証は エンティティが行ったデジタル署名を検証者 ( 通常はサーバ ) が署名検証を行うことで エンティティの認証を行います しかしながら 悪しき意図をもったサーバがチャレンジの代わりに特定文書 ( 例えば 1 億円の注文書 ) のハッシュ値をエンティティに送信し エンティティが無条件で ( 機械的に ) このチャレンジにデジタル署名してサーバに返してしまうと このレスポンスをサーバが取りだして当該文書の署名データとして添付すれば エンティティは意図せず署名を行ったことになり 後で多額の請求をされてしまうかもしれません 実際の標準プロトコルでは このようなことができないように エンティティは送られたチャレンジにそのまま署名するのではなく チャレンジにエンティティが指定するテキストを結合したものに署名する方式を取っており このような脅威に対処できるようにしています しかしながら 標準プロトコルを利用せずに 独自にチャレンジ / レスポンスの認証を行うアプリケーションでは 前述の悪しき意図をもったサーバの認証方式を用いることができる可能性があるため 注意すべきです また このような脅威を避けるためにも 認証とデジタル署名は明確にその使用法を分離し それぞれの証明書も認証用証明書と署名用証明書に分けて使用すべきです このために X.509 デジタル証明書に keyusage( 鍵使用目的 ) を明記したものを使うことが薦められます すなわち 認証用証明書は keyusage に digitalsignature ビットのみを指定し 署名用証明書の keyusage には nonrepudiation ビットのみを立てこれを区別するのです 自己署名証明書信頼できる CA で発行された証明書ではなく エンティティ自身が自ら署名する自己署名証明書が使用されることがあります このような自己署名証明書は 攻撃者がなりすましている場合があるため その使用には十分注意すべきです 一般的には 信頼できる CA で発行されていない自己署名証明書は 拒否すべきです 偽の認証機関 攻撃者が偽の認証機関 (CA) で発行した証明書を使用するかもしれません システムでは信 頼する CA( ルート CA) を設定し それ以外の CA で発行された証明書は拒否すべきです 失効した証明書証明書の有効性検証を正しく実装していれば 失効した証明書の利用による不正アクセスは防御できます 証明書が失効していないかどうかは 通常 CRL(Certificate Revocation List) をチェックすることで行いますが システム側で CRL のチェックを実装していなかったり あるいは CRL の更新期間が長すぎて 最新の CRL が反映されるまでの間に失効した証明書が利用されてしまうこともありますので 証明書の失効チェックの実装には注意すべきです 65

68 また オンラインで証明書の失効を確認するプロトコルである OCSP(Online Certificate Status Protocol) を利用する方法もあります 66

69 2.2 アクセス制御のモデル 概要 アイデンティティ管理技術において 運用管理ドメイン内におけるネットワーク上のあらゆるリソースに対して 起こり得る様々な脅威 ( 例えば 外部または内部からの不正な行為による 漏洩 改ざん 破壊等 ) から保護するための適切な安全管理及びセキュリティの確保は重要な要素となります その中で リソースへのアクセスを適切に制御することは極めて重要です [ アクセス制御 ] エンティティの識別子に基づいてリソースに対する権限があるものとないものを区別し 権限のあ るものに対してのみアクセスを許可する仕組みをアクセス制御といいます システムリソースに対する操作を アクセス と呼び プロセスのようにアクセスを能動的に実行するエンティティを サブジェクト (Subject アクセスするエンティティ) 操作されるファイルやデバイスなどのようにアクセスを受動的に受けるエンティティを オブジェクト (Object アクセスされる対象 リソース ) と呼びます アクセスを要求するサブジェクトとアクセス制御の判定およびオブジェクトの関係について 下図 ( 図 2.2-1) に表します 図 2.2-1: アクセス制御 アクセス制御は暗号化と並び リソースの機密性を確保するための基本的な技術です アクセス制御の基本モデルを下図 ( 図 2.2-2) に示します 67

70 図 2.2-2: アクセス制御の基本モデル ( 出典 : COMPUTER SECURITY The fundamental model of access control /Dieter Gollmann, WILLEY, 1999) システムを利用するエンティティ ( サブジェクト ) は あらかじめアイデンティティ情報をシステムに登録します システム内では サブジェクトは識別子 (ID) によって識別されます サブジェクトが識別子を指定してシステムのリソースへの アクセス要求 をすると まずシステムは認証を行います アクセス要求を出しているサブジェクトが認証されると システム内にそのサブジェクトの分身となる プロセス を作成します プロセスはサブジェクトの要求に応じてプログラムを実行し ファイルやデバイスなどのシステムのリソース ( オブジェクト ) の操作を行います サブジェクトがアクセスを実行しようとすると プロセス は システムの レファレンスモニタ (Reference Monitor) に アクセス要求 として報告します レファレンスモニタは アクセスの内容 サブジェクトの属性情報 オブジェクトの属性情報 その他の情報を元に アクセス制御ポリシー に従って 要求されたアクセスを許可するか拒否するかを判定します アクセスが 許可 されると プロセス がオブジェクトに対するアクセスを実行します アクセス制御の核心部はレファレンスモニタによる アクセス可否の判定 にあります すなわち 以下のような考慮を行い 指針を決定することがアクセス制御ポリシーとなります アクセス制御ポリシーはどのような状態を目指しているのか サブジェクトとは具体的に何を意味するのか サブジェクトあるいはオブジェクトに関する属性情報としてどのようなものを用意し それをどのように使うのか その他の情報としてどのようなものを考慮するのか アクセス制御モデルは主に次の 4 つに代表されます 任意アクセス制御 (DAC Discretionary Access Control) オブジェクトの所有者により サブジェクトのアクセス権が設定されるモデルです DAC は 主に OS で採用される方式で 所有者の裁量次第でファイルなどへのアクセス権を決定するため 十 68

71 分な機密情報保護が困難です 強制アクセス制御 (MAC Mandatory Access Control) サブジェクトとオブジェクトの機密レベルに基づき システムリソースへのアクセス制御を行うモデルです 強制アクセス制御には 情報フロー制御や MLS (Multi-Level Security) があり 保護する対象 ( オブジェクト ) とそれを操作する者 ( サブジェクト ) に対して それぞれセキュリティレベルを付与し セキュリティレベルを比較することによって強制的にアクセス制限を行うというものです ロールベースアクセス制御 (RBAC Role Based Access Control) サブジェクトの役割 ( ロール ) に基づいてアクセス制御を行うモデルです ロールは サブジェクトの属性情報のひとつです サブジェクトのロールに応じて オブジェクトに対して実行できる機能を限定するものです 属性ベースアクセス制御 (ABAC Attribute Based Access Control) サブジェクトの属性により規定されるアクセス制御ポリシーに基づいてアクセス制御を行うモデルです サブジェクトがオブジェクトを操作するために十分な属性を所有していることを証明しなければ 実行できる操作が限定されます RBAC と ABAC は 今日のアクセス制御の一般的なアプローチと見なされています 69

72 2.2.2 RBAC(Role Based Access Control) RBAC モデルは基本的に ロールを割り当てられたサブジェクトと ロールに割り当てられた許可 ( アクセス権限 ) によって定義されます ロールは個々のサブジェクトと許可の間の多対多関係につけた名前とみなすことができ ロールへの許可の割り当てとサブジェクトのロールへの割り当てによってアクセス制御管理に大きな柔軟性をもたらします サブジェクトとオブジェクトの間に ( サブジェクト寄りの概念として ) ロール を設け独立して管理す ることにより サブジェクトごとにオブジェクトに対するアクセス権限を付与するなど 以下のように 運用管理面での負荷を軽減することができます 新しいサブジェクトの登録の都度 アクセス制御の可否に関する全属性をサブジェクト個々に直接登録する必要がありません ロールによりアクセス権限の設定をグループ化することで 個別にサブジェクトのアクセス権限を設定する場合に比べて アクセス権限の設定管理が簡易になり 管理者の設定誤りや不整合などの防止に寄与することができます 人の登録についての変化よりも 組織のロールに関する変化は少なくて安定していると仮定できます したがって ロールの管理を行う方が 人の登録管理を行うより 運用管理工数は少なくて済みます RBAC におけるアクセス制御の考え方を下図 ( 図 2.2-3) に示します 図 2.2-3: ロールベースアクセス制御の概念図 サブジェクトごとにオブジェクトへのアクセス権限を直接付与するのではなく オブジェクトへのアク セス権限はロールと関連付け サブジェクトには そのロールを属性として割り当てることにより 割り当てられたロールに許可された権限をサブジェクトに獲得させるアクセス制御方式です RBAC の長所として ロールごとに必要最小限のアクセス権限を設定しておくことで 結果として サブジェクトの権限も限定的になる点が挙げられます そして 万一悪意のある攻撃者から不正 にアクセスされた場合でも 被害の範囲が限定的になることで セキュリティレベルが向上するこ 70

73 とが期待できます 一方 RBAC の短所として ロール定義を誤ると 本来 オブジェクトへアクセスさせたくないサブジェクトにまで権限を与えてしまうことが挙げられます 特に 多数のロールを定義した場合 ロール間の整合性の確保やサブジェクトへのロールの割り当てなど ロール定義の設計が複雑になることが考えられます RBAC の標準的モデルは 以下の 4 つの要素に分割して定義することができます (a) Core RBAC: RBAC の核心部 Core RBAC は RBAC の基本概念である以下の項目を規定します サブジェクトにはロールが割り当てられること ロールには許可が割り当てられること サブジェクトは ロールのメンバとなることで許可を獲得すること Core RBAC には 以下の項目が要求として含まれます サブジェクトとロールの間および許可とロールの間の関係が多対多であること したがって 1 人のサブジェクトに多数のロールを割り当てたり ひとつのロールを多数のサブジェクトに割り当てたりできること 同様に ひとつの許可が多くのロールに割り当てられたり ひとつのロールに多くの許可を割り当てたりできること 特定のサブジェクトに割り当てられたロールを決定したり 特定のロールが割り当てられたサブジェクトを決定したりできるように サブジェクトのロール検査を含むこと また 許可ロール検査は 高度なレビュー機能として課せられること ロールの選択的な開始や終了を許す サブジェクトのセッションの概念を含むこと サブジェクトが同時に複数のロールの許可を行使することを要求できること つまり サブジェクトが一度に開始できるロールをひとつに制限しないこと (b) 階層的 (hierarchical)rbac: ロールの階層化階層的 RBAC は ロールの間の階層に関する要求を与えます 階層はロール間の序列を与える半順序関係であり 下位のロールの許可が上位のロールにも与えられるとともに 上位のロールのメンバーシップが下位のロールにも与えられます 米国標準 (ANSI/INCITS ) では 次の 2 つの型のロール階層を認めています 無制限階層的 RBAC(General Hierarchical RBAC) 任意の半順序関係をロール階層としてサポートします これには ロールの間の許可やメンバーシップの多重継承の概念が含まれます 制限付き階層的 RBAC(Limited Hierarchical RBAC) ロール階層に制約を課します 階層が木や逆転木のような単純な構造に限定されたものが 最も一般的です 71

74 (c) 責務関係の静的な分離 (SSD:Static Separation of Duty relation) 責務関係の静的な分離は サブジェクトのロールへの割り当てを制約します このモデルでは 2 つ以上のロールの集合と サブジェクトに同時に割り当てることが禁止されるロールの数 (2 以上の数 ) によって SSD を規定します このことによって 例えば 1 人のサブジェクトが経理関係のロール 4 つのうちの 3 つ以上に同時に割り当てられてはならないというポリシーを表現することができます ロールに階層関係がある場合には サブジェクトの継承が SSD ポリシーを侵害しないことを保障 するための注意が必要です このため このモデルでは 責務関係の静的な分離があるロールに 割り当てられたサブジェクトに対する制約として SSD を定義します (d) 責務関係の動的な分離 (DSD:Dynamic Separation of Duty relation) 責務関係の動的な分離は セッションに基づいて 開始できるロールに制約を設けることで サブジェクトが利用できる許可を制約します SSD が 責務の衝突 (conflictof-interest) を潜在的に起こす可能性があるロールにサブジェクトが割り当てられるのを排除するのに対し DSD は同時に開始されるとポリシー違反を起こすが独立にふるまう時には権限の衝突を起こさない 2 個以上のロールにサブジェクトを割り当てることを許容します 72

75 2.2.3 ABAC(Attribute Based Access Control) 属性ベースアクセス制御 (ABAC: Attribute Based Access Control) モデルでは サブジェクトやオ ブジェクトに対して直接権限等の設定をするのではなく 認可の評価対象を属性に対して行うこと にあります サブジェクトにおける属性情報は 名前 役職 職務 勤務先 といった固定的な情報である場合もあれば 年齢 現在位置情報 預金残高 マイレージのポイント 日付 ( 時間 ) などといったように 動的に変化する情報である場合もあります サブジェクトおよびオブジェクトは いずれもこれらの属性情報の集合によって表されています アクセス権は これらの属性情報の集合体と評価条件 ( ルール等 ) によって評価し アクセスの許可 / 拒否の認可判定を行います 例 ) age > 18 = 0 ( 0 の場合 許可 / 1 の場合 拒否 ) 上記の例では 年齢 という属性の値が 18 より大きい場合は要求に対して操作を 許可 する という属性ベースのアクセス制御を行っています ABAC におけるアクセス制御の考え方を下図 ( 図 2.2-4) に示します 図 2.2-4: 属性ベースアクセス制御の概念図 属性ベースアクセス制御では 属性の動的な変化に柔軟に対応できるメリットがある一方で 複雑なポリシー ( 評価ルール ) の適用により 本来 オブジェクトへアクセスさせたくないサブジェクトにまで権限を与えてしまう原因となるルール定義の誤りを起こりやすいとも言えます 特に 複数のルールを定義した場合 ルール間の整合性の確保が必要となり ルール定義の設計が複雑になることが考えられます 複雑になりがちな属性ベースのアクセス制御の ルール や ポリシー をよりシンプルに表現する ための言語として XACML(eXtensible Access Control Markup Language) という OASIS 標準のポ リシー記述言語が使われるようになってきています 73

76 XACML では XML で表現されるデータに関するアクセス要求について その要求元の情報と要求の内容 アクセス対象の組み合わせから そのアクセス要求が許可されるか拒否されるかを判断するためのルールを記述することができます つまり XACML は アクセス制御を実際に行うのではなくて アクセス制御を実施するための基となるデータの表現方法を定義しています そして この基となるデータを ルール または ポリシー と呼びます また XACML では アクセス制御に関するすべての項目を定義するのではなく 他の有効な規格 / 勧告 ( 案 ) と協調し それを利用することで 重複定義に伴ういろいろな問題を回避しようとしています 例えば アクセス要求の内容としては様々な要求事項 ( 例えば 読む 書くなど ) が考えられますが その定義は SAML を利用します さらに ポリシー の正当性 ( だれも改竄していないことの証明 ) は XML Digital Signature( デジタル署名 ) を用いることを推奨しています XACML の仕様については 7 章にて解説します 74

77 2.2.4 RBAC と ABAC 利用モデル 権限の管理において 概念的に 属性管理 と ポリシー管理 は 2 つの異なる管理要素として分けることができます そもそも 属性とポリシーはその管理主体が異なる可能性があり 管理主体そのものの構成要素も異なるため 両者を同一の基準で定義することができないと考えられるからです XACML は 企業レベルでのアクセス権限管理に必要となる基礎的要素は満たしていると言えます ただし アクセス制御管理を全体的に運用 管理する上では ポリシーの作成や管理 ポリシーの強制 属性の収集 属性の定義といった側面を網羅する必要があることを視野に入れなければなりません 図 2.2-5: アクセス制御管理における関連要素 標準化された属性ベースのアクセス制御の方式が求められていることは間違いありませんが 様々なバリエーションに対応し得るアクセス制御モデルの適用が必要となっています アクセス制御の方式において 他の方式と明確にその特徴を異にしている下記の 3 つの方式が 現在 企業などの組織のアクセス制御において検討すべき方式であると考えられます アイデンティティベースアクセス制御 (IBAC Identity-Based Access Control) ロールベースアクセス制御 (RBAC Role-Based Access Control) 属性ベースアクセス制御 (ABAC Attribute-Based Access Control) このアイデンティティベースアクセス制御 (IBAC) は エンティティ認証を行うのみでアクセス制御は行いません 企業レベルでのアクセス制御の管理を行うにあたっては これらの方式を組み合わせて活用します 企業内で規定したポリシーにしたがって 利用するアクセス制御システムの方式を検討ことが求められます 75

78 3 組織内のアイデンティティ管理技術 3.1 組織内のアカウント管理 概要 内部統制を整備してコンプライアンス ( 準拠性 ) を確保することが強く求められるようになった環境のもと 組織内における情報システムの多様化も進んでおり 管理すべきシステムおよびこれらのシステムを利用する利用者のアカウント管理は多岐にわたり複雑性を増しています 企業は 企業経営の主目的である企業価値の向上を目指すなか 業務効率やサービスの向上を図る一環として様々な IT 投資を行っています 一方 システムが多様化するなかで 相互に連携すべき処理が複雑化すればするほど 情報セキュリティに関わるリスクは増えていきます そのため ネットワークリソース / コンピュータリソースや利用者を電子的手段で特定し 定義されたアクセス権等に基づいてこれらのリソースへのアクセスを管理する仕組み 組織全体で統制されたポリシーとそれを強制する仕組みが必要とされています 組織内のシステムでありながら アカウント情報やアクセス権限に関わる情報をシステム毎に登録 管理しなければならず 情報が組織内で分散してしまっている状態から より統合的にアイデンティティ情報を管理することが求められています そこで 組織内の分散されたシステムにおけるアカウント情報を一元的に管理するために設ける 統合ドメイン の果たす役割が重要となっています この 統合ドメイン は 組織内のネットワークや各サービスの提供範囲を超えてく 統合するソリューションとなります 統合ドメイン では システムが利用者を識別し 利用者本人であることの正当性を検証する 認証 (Authentication) に関わる情報(ID/ パスワードなど ) や ロール情報など認可 (Authorization) に必要となるアクセス制御のための属性情報のみならず メールアドレス / 所属組織情報などアプリケーション処理や業務処理に要する属性情報を管理し 組織内の様々な業務を円滑に行うためのマスターデータとしての側面も担います なお アカウント管理とアクセス制御は 相互に密接に関連付けられていますが 別の活動と機能です アカウント管理は 例えば 従業員の入社や退職といった ビジネス上のイベントに対応して発生するものと言えます これに対して アクセス制御は 利用者がオンラインでシステムリソースへのアクセスを要求するごとに発生します このため アカウント管理を司るシステムコンポーネントにたとえ障害が発生しても システムリソースへのすべてのアクセスが停止されるわけではありません 新規の利用者に対するアカウントの作成 / 登録が対象システムに行われず 利用状態になるまで 当該利用者がシステムを使用することができない点を除けば システムリソースはそれまでと同じように使用し続けることができます 76

79 一方 アカウント管理の対象となるシステムリソースは その種類にかかわらず 広範囲にわたるため 単一の利用者が組織内で複数のシステムリソースにアカウントを持って それぞれのリソースを使用することができます 利用者の権限とビジネスとの関係に応じて規定されるアクセス制御ポリシーは 利用者のアカウントとシステムリソースの関連性を紐付けて運用するものとなり アカウント管理と互いに密接な関連性のもと定義運用することが必要となります また 組織内のアカウントには アプリケーション開発者 オペレータ 管理者などが利用するシステム管理用のアカウントや サーバ OS データベース ネットワーク機器等の人以外に結び付けられたアカウントなど 高い特権を付与されたアカウントが存在します これらのアカウントには 一般のアカウントと異なる権限が与えられており 故意か否かに関わらず誤った使い方をされることによる重大なセキュリティ上のリスクを有しています これらの高い特権アカウントに対するポリシーと運用上の管理方針 責任の所在を明確にすることが必要となります このように 企業がシステム全体に対して一貫したポリシーのもと 体系的かつ安全 合理的にシ ステムを利用するにあたり 多数の利用者 アプリケーション 機器などのアイデンティティ情報を 迅速かつ簡単に管理できるよう 組織内のアカウント管理に対する施策が必要となっています 77

80 3.1.2 Windows ネットワークにおけるアカウント管理 組織内のネットワークを構成するシステムリソースは多種多様にわたります 利用者 グループ 端末 サーバ プリンタ ネットワーク機器 アプリケーション その他 IT インフラストラクチャはそれぞれのコンポーネントが相互に関連付けられ 最終的に所定の目的に対して適切な利用者に使用してもらうために構成されています 一方 それぞれのレイヤにおけるセキュリティを実装するアプローチは無数にありますが IT インフラストラクチャを構成するコンポーネントは 利用者のアカウント ( アカウントに紐づけられた属性情報を含む ) という観点で 密接に関連付けられています 組織内における IT インフラストラクチャ構成範囲の基本単位として ドメイン があり そのドメインを管理するコンピュータを ドメインコントローラ (Domain Controller) と呼びます ドメインコントローラは ドメインを制御するための中心的なシステムであり その主な役割はドメインの構成要素となるアカウント情報やネットワーク上のコンピュータ アプリケーションなどを含むリソース情報を登録したデータベース ( ディレクトリ ) の保持と 認証機能を提供することにあります Windows ネットワーク環境においては 組織のネットワークを構成する様々なリソースに対する認証とアクセス制御 アカウント管理を行うための包括的な機能を提供する中核サービスとして Active Directory ドメインサービスがドメインコントローラの役割として位置付けられています Active Directory ドメインサービスは 社内システムへの透過的な認証や権限管理 ネットワーク 上のコンピュータリソース アプリケーションなど ディレクトリ対応オブジェクトを一元的に管理する 仕組みを提供しています Windows 環境のリソース管理を行う統合ディレクトリサービスの概念を下図 ( 図 3.1-1) に示します 図 3.1-1: Active Directory をとりまく Windows 環境のリソース 78

81 Active Directory ドメインサービスは 認証基盤および組織内の各種ポリシー管理機能を提供して おり 組織におけるシステムを利用する上で 管理性向上 TCO 削減 セキュリティ向上 利便 性向上 といった効果をもたらすことが期待されています 例えば 認証 / 認可機能により 分散されたシステムに対する透過的な認証を実現するシングルサインオン機能や Active Directory による集中管理されたアカウント管理により その複雑さを緩和することができます また グループポリシーにより ドメイン配下のクライアントコンピュータに関する各種設定を一括管理し パスワードポリシーにより 厳格なパスワード管理を行うこともできます Active Directory の特徴として 以下が挙げられます 中央での集中管理 / 拠点ごとの分散管理の実現 全社共通ポリシーの強制管理実現 OU による拠点ごとの分散管理により 効率的な管理を実現 OU による階層管理が可能 人事異動時は OU 間の移動操作で実現 管理権限委任による管理の効率化 セキュリティポリシーにより全社的セキュリティ方針の適用が可能 アカウントの一元化 利用者は アクセスするサーバ毎に複数の ID とパスワードを管理する必要から開放される (Kerberos 認証 ) Active Directory ドメインサービスにおける集中管理により 管理者および利用者双方が享受する 効果のポイントを下図 ( 図 3.1-2) に示します 図 3.1-2: Active Directory による集中管理がもたらす効果 79

82 Windows ネットワーク環境に限らず アプリケーションの処理は システムまたは利用者がアプリケーション ( あるいはアプリケーションの内部機能 ) にアクセスする必要が発生したときに始まります このとき 最初のプロセスは 認証 です すなわち アプリケーションの利用者は 一様に身元を確認し その身元によるアプリケーションのアクセス ( 操作 ) 権限許可を受ける必要があります したがって アプリケーション ( 自身もしくはアプリケーションに代わって権限付与の管理を行うリポジトリ ) は 利用者に対して自らの内部にある様々なリソースや機能にアクセスする権限の管理と制御を行わなければなりません アカウント管理 とは 認証に始まる身元確認プロセスで利用されるアイデンティティ情報と認証に必要となるパスワードなどのクレデンシャル管理だけでなく アクセス制御プロセスを記録および監視する能力をも含むことになります アカウント管理の運用においては 利用者のシステムに対するあらゆるアクションとその結果 ( 認証の成功 / 失敗 保護されたどのリソースに対するアクセスを要求したか 要求したリソースに対する結果 : 許可 / 拒否 など ) を記録し 記録された証跡から利用者を特定することができる必要があります Windows ネットワーク環境では これらの管理を Active Directory ドメインサービスが担っています なお Active Directory では RBAC( ロールベースアクセス制御 ) を利用しています [ コンテナ オブジェクト ] Active Directory のドメインで利用者 ( ユーザ ) やコンピュータなどの情報をまとめて管理するための格納先としてコンテナ オブジェクトがあります コンテナ オブジェクトには Active Directory をインストールすると自動的に作成されるコンテナ オブジェクトと 管理者が作成するコンテナ オブジェクトがあります 管理者が作成するコンテナ オブジェクトを OU と呼びます Active Directory をインストールすると 下表 ( 表 3.1-1) のコンテナ オブジェクトが自動的に作成 されます これらのコンテナ オブジェクトは削除できません Builtin Computers Domain Controllers ForeignSecurityPrincipals Users 表 3.1-1: Active Directory に自動作成されるコンテナ オブジェクト Active Directory のインストールの前にそのコンピュータに作成されていたローカルグループが格納されます ドメインに参加しているドメインコントローラ以外のコンピュータアカウントの情報が格納されます そのドメインのドメインコントローラのコンピュータカウントが格納されます 信頼関係で結ばれた他のドメインのユーザやグループの情報が格納されます ドメイン内のユーザアカウントの情報が格納されます 80

83 [OU] OU は Active Directory ドメインに管理者が追加するコンテナ オブジェクトで ドメイン内のユー ザやコンピュータを 部や課といった組織ごとにまとめて管理するために使用します [ ユーザアカウント ] ユーザアカウントは ドメインに参加するコンピュータを利用するユーザの登録情報です ユーザアカウントは ログオン時の認証やリソースの利用に対するアクセス許可の確認に使用します また ユーザアカウントには 氏名や連絡先 作業環境を管理するための属性情報が含まれます ドメインのユーザアカウントは ドメインコントローラのディレクトリ データベースに登録されます ユーザはドメイン内の各コンピュータから ユーザアカウントを使用してドメインにログオンします また Active Directory ドメインの管理のためにいくつかのユーザアカウントが自動的に作成されます これらのアカウントは ビルトインユーザアカウント と呼びます Administrator アカウントは 管理に必要な権利のすべてを保有し ユーザ管理やセキュリティの管理 インストールなどすべての管理作業を行うことができるビルトインユーザアカウントです [ コンピュータアカウント ] コンピュータアカウント は ドメインに参加するコンピュータの登録情報です [ グループアカウント ] グループアカウント は ユーザアカウントをまとめた論理グループの登録情報です グループアカウントは 複数のユーザアカウントをまとめて管理したり 共通のセキュリティ設定を行ったりする場合に使用します 例えば 共有リソースに対して ユーザ毎にアクセス許可を設定すると そのユーザ数分の設定作業を行わなければなりません そこで同じアクセス許可を持つユーザをまとめてひとつのグループとして管理し このグループに対してアクセス許可の設定を行うことで運用していくことができます グループに設定されたアクセス許可はそのグループのメンバに適用されるため グループ単位でアクセス許可の管理を行うことができます [ グループポリシー ] グループポリシー とは Active Directory のドメインに所属しているコンピュータやユーザの作業環境に対して様々な設定を行い ネットワークを介してその設定を適用させることができる機能です 設定できる項目は非常に多く デスクトップ環境やセキュリティ設定 ソフトウェアのインストール設定などが行えます グループポリシーは ドメインや OU 単位に設定することができます OU 単位に設定することで 81

84 企業の部門ごとに異なるポリシーを設定することができます グループポリシーの情報の集まりを グループポリシーオブジェクト と呼び グループポリシーには コンピュータの構成 と ユーザの構成 があります コンピュータの構成は 選択したドメインまたは OU に所属するコンピュータに適用されるグループポリシーです ユーザの構成は 選択したドメインまたは OU に所属するユーザに適用されるグループポリシーです [ アカウントポリシーの設定 ] アカウントポリシーは ユーザのログオンに関するルールを設定します 一般にドメインのグループオブジェクトに設定し ドメイン全体に適用するように設定します アカウントポリシーには パスワードのポリシー アカウントロックアウトのポリシー Kerberos ポリシー があります このように Windows ネットワーク環境では Active Directory を中核として アカウント管理に関わ る各種機能が提供されています 82

85 3.1.3 Web アプリケーションにおけるアカウント管理 クライアント / サーバ型のアプリケーションから Web ベースのアプリケーションが台頭し 様々な業務でブラウザを利用した Web アプリケーションが使われるようになっています Web サーバ (Apache HTTP サーバや IIS サーバ等 ) と Web アプリケーション技術 (CGI ASP サーブレット CORBA DCOM JAVA 等 ) が組み合わされて アプリケーションとしての表現能力 機能は目まぐるしく進歩を遂げています しかしながら Web アプリケーションにおけるアカウント管理やアクセス制御は 個々のアプリケーション固有のものであり セキュリティを考慮した標準が存在していません また 組織の中には多種多様な Web サーバ /Web アプリケーションサーバが分散しており 同一の利用者がシステムをまたがって 業務を行っています これらを同一のセキュリティ標準のもと アカウント管理やアクセス制御を共有する仕組みを確立するのは 非常に難しい状況にあるといえます この問題を解決する方法のひとつとして シングルサインオン (SSO Single Sign-On) システムの導入があります 様々な種類からなる Web アプリケーションの認証とアクセス制御シを中央集中型の認証と権限付で実現するのが SSO システムです SSO システムでは アカウント情報 ( アクセス制御に必要なロールなどの属性情報を含む ) とアクセス制御ポリシー ( ロールとリソースの情報 ) をデータベースやディレクトリ (LDAP ディレクトリや Active Directory) で一元的に管理し 監査やモニタリングのためにログを集中管理しています 従来 Apache などの Web サーバにおけるアクセス制御は.htaccess というファイルを使って行われ Web サーバの動作をディレクトリ ( フォルダ ) 単位で制御していました このファイルは 保護が必要なそれぞれのディレクトリに定義 格納し 当該ディレクトリに対するアクセス制御ルールをユーザやロールとともに記述します 中央集中型の Web SSO システムでは アカウント情報やアクセス制御ポリシーを中央のリポジトリ ( ディレクトリサーバやデータベース ) に格納し 管理します 認証においては LDAP 認証や Active Directory 認証による柔軟なパスワードポリシーの適用が可能なほか より強固な認証方式 ( クライアント証明書とリポジトリ内のアカウント情報の照合による認証 ワンタイムパスワード認証 等 ) と連携し Web アプリケーション間をまたがる透過的な認証を行うことができます また ロールベースまたはルールベース ( あるいはその混成 ) のアクセス制御を リポジトリ内にある利用者の属性およびロールを評価して行います また SSO を実現するための認証済みトークン ( アサーション ) には ブラウザクッキーが広く使われ クッキーには権限付与情報 タイムスタンプ ユーザ名 IP アドレス セキュリティ情報 セッション情報などが暗号化された状態で格納されています 83

86 組織内で分散された多種多様な Web アプリケーションのアカウントは これら中央集中型の Web SSO システムにより提供されている認証技術やアクセス制御の仕組みにより 共通のポリシーとアカウント属性を使ったアクセス制御を行うことによって 様々なセキュリティリスクから守られた状態で 管理することができるようになります なお Web アプリケーションに限らず アプリケーションにはアプリケーション内部コードにハードコードされたアカウント情報が存在することがあります 例えば アプリケーションがアカウント情報を管理するリポジトリに接続し 検索を行うためのアカウントがこれに該当します これらのアプリケーションアカウント ( 人に結び付けられたアカウントではないアカウント ) には 必要最低限の権限を付与することが求められていますが とかく高い権限を付与しているケースが見受けられます アプリケーションアカウントには適切な権限付与を行うほか その特性上パスワードなどのクレデンシャルを頻繁に変更することができないため 限られた管理者により厳重にクレデンシャルを管理する運用上の対処が必要となります 84

87 3.1.4 アカウント情報管理リポジトリ 従来 アカウント管理は システムやアプリケーションの一機能として位置付けられ システムやアプリケーション単位で利用者の認証や認可などに関わるアカウント情報を管理していました つまり 利用者はシステムリソース ( アプリケーション等 ) に対して 1 対 1 の関係で管理されていました 概要 でも述べたように セキュリティ対策 内部統制の観点のみならず 業務処理を円滑に行うためのマスターデータとしての側面からも 組織内アカウント情報を一元的に管理するため 統合されたアカウント情報管理リポジトリが不可欠となっています 前項では 企業内で一般的に導入されている Active Directory による Windows ネットワークのアカウント管理や Web アプリケーションのアカウント管理について解説をしてきましたが 組織内のリソースは Windows システムのリソースにとどまらず 多種多様なプラットフォーム / アプリケーション / リポジトリからなり これらを含めて統合的にアカウント情報を管理することが必要となっています これら 多様化したシステムリソースに対して アカウント情報を取り巻く様々なステークホルダ ( 利害関係者 ) の種類 役割 目的 ポリシーなど相互関連性を包括的に考慮し アカウント情報管理リポジトリの設計にあたる必要があります アカウント情報管理リポジトリには 組織に関するアカウント情報やセキュリティ関連情報がすべて格納されます その格納先として利用されるのが ディレクトリやリレーショナルデータベースです リポジトリには 認証やアクセス制御の基となる各種リソースの属性情報などの重要な情報を格納するため 情報へのアクセスはリポジトリへの通信パスと共に厳格に制御されていなければなりません また リポジトリに格納されるアカウント情報は リポジトリのドメイン空間のなかで一意に識別することができる必要があり 識別子が付与されます この識別子によって アプリケーションは アカウントを検索し ロールなどのアカウントの属性情報を検索し 抽出した上で利用することができるようになります [ リポジトリ設計 ] アカウント情報管理リポジトリ設計を行うにあたり 最も重要なことはリポジトリの用途を明確にす ることです リポジトリの設計について LDAP ディレクトリを例にとって解説します データ設計リポジトリ内に格納される情報 ( データ ) を以下の点を考慮して設計します リポジトリを使用するアプリケーションの特定 リポジトリを使用するアプリケーションが利用するデータの特定 リポジトリに登録するデータソース ( マスタとなる源泉情報 ) の特定 将来必要とされる可能性があるデータの特定 85

88 スキーマ設計リポジトリの利用用途を明確にし リポジトリ上に必要とされるデータを特定した上で これらのデータを LDAP ディレクトリの標準スキーマへマッピングし データをアプリケーションが利用可能な状態に正規化します また 同時に標準スキーマで網羅できない拡張スキーマを抽出し スキーマ全体の設計を行います リポジトリにリレーションナルデータベースを利用する場合は リレーショナルなテーブル構造 の設計とカラムの設計に該当します ディレクトリ情報ツリー (DIT Directory Information Tree) 設計 LDAP ディレクトリでは ディレクトリ情報ツリー (DIT) と呼ばれる階層化された名前空間の構造に情報を格納します 一般にドメインネームシステム (DNS Domain Name System) 構造などの既存のドメイン構造や地理的および組織的な構造に基づいて階層を構成します DIT 設計は 管理権限の委譲やアカウントの所属先変更等における影響をはじめ 運用後の管理 メンテナンスを大きく左右することになりますので この段階での検討は非常に重要になります ディレクトリ情報ツリー (DIT) については 4.2 アイデンティティ情報管理技術 で詳説いた します レプリケーション設計リポジトリには アカウントの認証やアクセス制御に利用する情報などが格納されているため リポジトリはビジネスクリティカルな役割を担っています 従って 万一の場合に備え レプリケーション ( データの複製 / 同期 ) を行っておく必要があります レプリケーションは 主に以下の要素を考慮し 設計します 冗長性の確保 負荷分散 フェールオーバ バックアップ パフォーマンス これらは システムに求められるサービスレベルに応じて 構成を含めた設計が必要です セキュリティ設計 セキュリティ設計は リポジトリのその特性から非常に重要となります 代表的な設計項目を以下 に挙げますが セキュリティ設計に求められる要素はこの限りではなく リポジトリの利用目的や 86

89 求められるサービスレベルと照らし合わせて検討する必要があります 認証方式 パスワードポリシー データの暗号化 データへのアクセス制御 通信の保護 ( 暗号化等 ) アカウントの有効 / 無効およびロックポリシー 組織内のアカウント管理について 本節では Windows ネットワークにおける Active Directory Web アプリケーションのアカウント管理 およびアカウント情報管理リポジトリについて解説しました これら アイデンティティ情報の格納先に対する日々の運用管理が正しく行われてはじめて 組織内のシステムやアプリケーションを安全に利用することが可能となります そのためには アカウントは必要なエンティティにのみ発行され 正しいポリシーのもと 必要最小限の権限が付与された状態を常に保つ運用管理を行わなければなりません そのためには アイデンティティ情報のライフサイクルを視野に入れながら 信頼できるアイデンティティ情報の収集 最新化および管理 維持をはじめ アカウントの登録 活性化 更新 休止 抹消の各プロセスの定義と履行を組織内で徹底する必要があります 87

90 3.2 組織内のエンティティ認証 概要 エンティティ認証の基礎理論については 2.1 節で解説しました この節では 組織内のエンティティ認証としてもっとも広く使われている Windows ネットワークにお ける認証方式である Windows NTLM 認証と Kerberos 認証について解説します NTLM 認証 NTLM(NT LAN Manager Authentication) 認証は Windows NT 4.0 以前の Windows NT シリーズの OS で標準的に使われていたネットワークログオンのためのユーザ認証方式です NT 4.0 の後継にあたる Windows 2000 からは デフォルトの認証方式に Kerberos 認証が採用されていますが 旧環境との互換性を保つため NTLM 認証も利用可能となっています NTLM 認証は 企業内ネットワークでアカウント情報を集中管理しているドメインコントローラに ネットワークを介してログオンしたり 共有フォルダや共有プリンタなどにアクセスしたりする際の 認証などに使われます NTLM 認証は チャレンジ / レスポンス方式と呼ばれる方式を利用しています チャレンジ / レスポンス方式では まず認証を受けたいクライアント ( ユーザが利用するコンピュータ ) が認証要求をサーバに送り サーバはそれに対しランダムな数値列 ( チャレンジ ) を返信します クライアントは ユーザが入力したパスワードとチャレンジを特定のアルゴリズム (NTLM ハッシュ ) に従って合成し レスポンスと呼ばれる数値列 ( ハッシュ値 ) を作成し サーバに送信します サーバ側では 送信したチャレンジとあらかじめ登録されたそのユーザのパスワードから同じようにレスポンスを作成し 送られてきたレスポンスと比較することによって 認証を行います レスポンスが一致すれば パスワードは正しいことになり 認証成功となります 平文のパスワードではなくチャレンジを送信することにより パスワードの盗聴を防ぐことにもなります ただし パスワードハッシュが施されているとはいえ パスワードに依存するデータをネットワーク上でやり取りしているため 盗聴によってハッキングされる危険性は排除できません そこで Windows 2000 以降ではログオン時の標準認証方式を Kerberos に変更しています 88

91 NTLM 認証の処理フローを下図 ( 図 3.2-1) に示します 図 3.2-1: NTLM 認証の処理フロー NTLM ハッシュの処理を下図 ( 図 3.2-2) に示します 図 3.2-2: NTLM ハッシュの処理 NTLM ハッシュでは パスワードを UNICODE 文字列に変換した後 MD4 アルゴリズムでハッシュ 化した文字列となります NTLM ハッシュでは パスワードの大文字と小文字が区別され パス ワード長は 128 文字まで可能となっています NTLMv2 認証 NTLMv2 認証は NTLM 認証を改良した認証システムです NTLMv2 認証では NTLM 認証と同様 に NTLM ハッシュを暗号化キーとして使用したチャレンジ / レスポンスを行います ただし チャレ 89

92 ンジに対するレスポンスの作成方法が NTLM 認証と異なります NTLMv2 認証では その暗号化 に HMAC-MD5 アルゴリズムを使用しています HMAC-MD5 アルゴリズムのキー長は 128 ビットと なるため NTLM 認証よりキーの推測は難しくなります 図 3.2-3: NTLM v2 ハッシュの処理 90

93 3.2.3 Kerberos 認証 Kerberos は 保護されていないオープンなネットワーク上で ユーザやサーバなどのエンティティ認証を行う手段を提供しています これは 特定の OS による認証機構に頼ることなく ネットワーク上のすべてのクライアントやサーバが物理的に安全であることをも要求せず さらにネットワーク上を流れるパケットは自由に読まれ 改変され 偽造され得るという仮定のもとで使用することのできる仕組みを提供しています 図 3.2-4: Kerberos のサポートするシステム モデル Kerberos 認証の特徴として 以下を挙げることができます シングルサインオン (SSO) の実現 横断認証 信頼できる第三者機関による認証の集中化 Kerberos 認証によるシングルサイオンの概要を下図 ( 図 3.2-5) に示します 図 3.2-5: Kerberos 認証におけるシングルサイオン 91

94 また Kerberos 認証の特徴である横断認証 (Mutual Authentication) の概要を下図 ( 図 3.2-6) に示 します 図 3.2-6: クライアント / サーバ間の横断認証 Kerberos 認証は パスワードによる認証ではなく 共通鍵暗号による認証を行っています 共通鍵 暗号方式では 相手が増えれば増えるほど相互に交換する回数が増え その鍵の受け渡しや保 管方法がセキュリティ上の問題となってしまいます このような問題を解決するために Kerberos 認証では ネットワークに参加するクライアントおよびサーバなどのすべてのエンティティ (Kerberos 認証ではプリンシパル Principal と呼びます ) は 予め自分の鍵データを 鍵配布センター (KDC Key Distribution Center) と呼ばれるサーバに登録します KDC は 鍵の管理や各エンティティの身元保証を行う役割を担います ひとつの KDC が管理するエンティティの集合のことを レルム (Realm) と呼びます KDC は 自分が管理するレルム中のすべてのエンティティの識別子 ( プリンシパル識別子 Principal Identifier) とその鍵を管理し エンティティから要求があれば 所定の手続きを経てエンティティ間での認証作業を行えるように手配します このように 専用の鍵管理サーバによってクライアントおよびサーバ間のセキュリティを確保するため 信頼された第三者機関による認証方式 (Trusted Third Party Authentication) と呼ばれています なお クライアントおよびサーバがそれぞれ KDC と共有する自分の鍵は 有効期限を長くとった共通鍵です 92

95 図 3.2-7: Kerberos レルムの概念図 この共通鍵を使った Kerberos 認証のフローを下図 ( 図 3.2-8~ 図 ) に示します 図 3.2-8: Kerberos 認証フロー 1/3 93

96 あるサーバ A の提供する機能をクライアント B が利用したいとします 1 クライアント B は KDC に対して A へのチケットを要求するメッセージを送ります Kerberos 認証では 自分の身分を証明するものをチケットと呼び 自身が KDC に認証されたエンティティであることを証明するものです クライアント B は このチケットを KDC から受け取って サーバ A に渡すことによって サーバ A に認証してもらいます 2 KDC はこの要求を受け取ると A へのチケットを含むクレデンシャルをクライアント B の共通鍵で暗号化して クライアント B に返します ここでいうクレデンシャルは 身元を識別する一時的なクレデンシャルであり X.509 証明書 とは異なる概念のものとなります 証明書には チケットのほかに クライアントの鍵ともサーバの鍵とも異なる第三の鍵 ( セッション鍵 ) が含まれます この第三の鍵は 一時的なやり取りでしか使用しない鍵で 時限クレデンシャル (short-lived credential) とも呼ばれ 使用できる短い有効期間があり その期間しか使うことができません 図 3.2-9: Kerberos 認証フロー 2/3 3 証明書を受け取ったクライアント B は 自分の共通鍵を使ってデータを復号して チケットと セッション鍵を取りだし チケットをサーバ A に送ります 94

97 4 サーバ A へ渡されたチケットには クライアント B の身元に関するデータとセッション鍵が含ま れており KDC によって全体がサーバ A の共通鍵で暗号化されています 図 : Kerberos 認証フロー 3/3 5 チケットを受け取ったサーバ A は 自分の共通鍵でチケットを復号し クライアント B の身元と セッション鍵を取りだします この時点で サーバ A とクライアント B は同じセッション鍵を共有 し サーバ A はクライアント B の身元を確認することができます サーバ A は チケット内のデータより クライアント B の身元が分かります また KDC がクラ イアント B の鍵を用いて暗号化した証明書を復号して チケットを取り出せているということか ら チケットを送った相手はクライアント B に間違いないということが分かります クライアント B は この後の通信で サーバ A が正しくセッション鍵を使えることを確かめられれば サーバ A がチケットを復号できたことを意味し KDC がチケットの暗号化に用いたサーバ A の共通鍵を持っているということが分かるため 相手が目的のサーバ B であることを確認できます [ レルム間処理 (Cross-realm Operation)] インターネットでは ドメインネームシステム (DNS:Domain Name System) と呼ばれる階層的な名前空間を使用しますが このドメインに Kerberos のレルムをマップすることで Kerberos をインターネットに導入することができます この場合 下位のレルムは上位のレルムに含まれることになります また レルム間の関係は このような階層的構造ではなく 水平的な構造をとることもできます いずれの場合も 複数のレルムにまたがった処理が必要になることがあり そのような処理をレルム間処理 (Cross-realm Operation) と呼びます 95

98 レルム間処理を実現するためには 必要とするサーバの存在するすべてのレルムの KDC に あらかじめクライアントを登録しておく方法もありますが 多くのクライアントがそのような要求を行うと 複雑な構成となります そこで Kerberos では レルム間処理実現のため 自レルムで管理するサーバのひとつとして 他のレルムの KDC を登録しておくことで実現します この場合 他のレルムのサーバを利用したいと考えるクライアントは そのレルムの KDC に対してチケットの発行を依頼するためのチケット (Ticket Granting Ticket) を自レルムの KDC から発行してもらいます そのチケット (TGT) を改めて他のレルムの KDC に対して提示することで そのレルム上の必要なサーバに対するチケットを入手できるようになります 図 : Kerberos レルム間処理の実現方法 96

99 4 インターネット上のアイデンティティ情報の運用管理 4.1 概要 組織内で管理されているアイデンティティ情報について 3 章で解説しました 本章では インター ネット上で利用されるデジタルアイデンティティに関するアイデンティティ情報の運用管理について 解説します クラウドサービスや e-コマースサイトなどのインターネット上のサービスは 組織内のネットワークにおいても広く利用されるようになってきました これらのサービスは 誰もがアクセスし閲覧できるコンテンツの利用にとどまらず 利用者は社内のシステムやアプリケーションを利用する際と同様に インターネット上のサービスを利用するにあたってエンティティ認証を求められます 利用者を識別する識別子 (ID) およびそれに付随した属性情報をサービス側で保持した上で それらの情報の検索 更新 同期等を行いながら 利用者の属性や権限に基づいて最適化されたサービスを提供 ( パーソナライズ ) するようになっています また 組織内で管理されているアイデンティティ情報と インターネット上のサービスで管理するア イデンティティ情報を相互に交換することによって その一意性 および本人確認 身元確認の信 頼性を確保することもあります インターネット上のサービス間でアイデンティティ情報を交換する相互運用の観点から アイデン ティティ情報を格納するデータベースとして スキーマが標準化されたディレクトリサービスが使わ れてきています 図 4.1-1: インターネット上のアイデンティティ情報を管理するディレクトリサービス 97

100 ここでは インターネット上のサービスでアイデンティティ情報を管理する LDAP ディレクトリサービ スについて 解説します 98

101 4.2 LDAP ディレクトリサービスの管理 LDAP ディレクトリは エンティティ認証を行う認証システムとしての用途のほか 組織内あるいはインターネット上のアイデンティティ情報を管理するためのリポジトリとして利用されています LDAP ディレクトリには アイデンティティ情報についての表現力が備わっており 多様な属性を定義し 格納することができます LDAP ディレクトリサービスの利用目的として 下記の目的を挙げることができます ネットワーク上にある様々な情報を汎用的に一元管理する 情報の物理的な位置と論理的な位置を分離し 透過性を高める 高度で高速な検索サービスを提供する リレーショナルデータベースでも同様にデータを格納し 検索 更新の手段を提供していますが リレーショナルデータベース (RDB) が頻繁に更新される動的な情報を扱ったり 複数の処理をトランザクション管理する場合 または情報間の複雑な関係の処理が要求される場合などに向いているのに対して ディレクトリサービスは 複数のアプリケーションからの共通のアクセスがある場合や 比較的静的な情報に対する検索に向いています 例えば ディレクトリサービスは下記のような用途に広く使われています ホワイトページ イエローページやメールアドレス帳 認証情報の一元化 下表 ( 表 4.2-1) にディレクトリと RDB の特徴的な差異を示します 表 4.2-1: ディレクトリと RDB の主な差異 ディレクトリ データ表現データはオブジェクトの階層構造で表現データは表 ( テーブル ) の集合で表現 データ間の構造 システム形態 検索 更新 アクセス方法 格納データ 属性値を持つオブジェクトとその階層構造からなる 分散された汎用的なシステム構築が可能 更新よりも 比較的静的なデータの検索に最適化 標準アクセスプロトコル 標準スキーマ 標準 API に対してアクセス 人 組織 ネットワーク機器 コンピュータ資源 セキュリティ情報 RDB 複数のデータ群がその 関係 ( リレーション ) と呼ばれる構造で相互連結 データベースは基本的に一極集中型のシステム形態 頻繁にデータを更新するトランザクション系の更新処理に最適化 ユーザ定義のテーブル 列 ( カラム ) リレーション構造に対してアクセス 業務データ ( 商品情報 在庫情報 受注情報 ) に代表されるトランザクションデータ 99

102 ディレクトリに格納したひとつひとつのデータのまとまりをエントリ (Entry) といいます エントリは リレーショナルデータベースのレコードに相当するもので 属性と属性値のペアとしてデータを格 納しています 図 4.2-1: エントリと属性 LDAP の属性には多くの種類が存在するため いくつかの属性をお互いに関連したひとつのまとまりとして扱える仕組みがあります それぞれのまとまりをオブジェクトクラス (object class) と言います オブジェクトクラスでは どのような属性がそこに含まれるのかが定義されています LDAP のエントリでは そのエントリがどのようなオブジェクトクラスを持つのかを決め それに沿った属性を必要に応じて格納していきます オブジェクトクラス エントリおよび属性の具体例を下図 ( 図 4.2-2) で示します 人 の属性が規定されているオブジェクトクラス : inetorgperson 図 4.2-2: オブジェクトクラス 属性および属性値の具体例 LDAP ディレクトリでは ツリー上にエントリを管理します このときディレクトリサービスの基点とな るディレクトリを ベース DN(suffix) と呼びます そして このベース DN を基点にツリー上にエント リを格納します 100

103 図 4.2-3: ディレクトリサービスのベース DN また 他のエントリと識別できるように エントリには 相対識別名 (RDN Relative Distinguished Name) と呼ばれる名前を付けます RDN は 上位のエントリから見て 直接下位のエントリを識別するために使用される名称です 例えば 斉藤太郎 という人のエントリが cn 属性の値 Saito というエントリを識別する場合 RDN は cn=saito となります そして DN は RDN とその上位エントリの DN を連結して表されます 上図 ( 図 4.2-3) の例では 斉藤太郎 という人のエントリの RDN は cn=saito で DN は cn=saito,ou=sales,dc=example,dc=co,dc=jp となります アイデンティティ情報を LDAP ディレクトリに格納するためには データ種別や形式を定義する必要があり これを ディレクトリスキーマ と呼びます また LDAP ディレクトリを使用したディレクトリサービスでは データをツリー構造によって階層化して管理しています そのデータの格納構造を DIT(Directory Information Tree ディレクトリ情報ツリー) と呼びます LDAP ディレクトリスキーマは 下表 ( 表 4.2-2) に示す要素から構成されています 要素名 オブジェクトクラス定義 属性型定義 属性構文定義 照合規則定義 名前形式定義 DIT 構造規則定義 DIT 内容規則定義 表 4.2-2: LDAP ディレクトリスキーマの基本要素 説明 エントリ作成の際のひな形となる 属性が保持する情報の種類を示す 属性値に使用できる文字と属性値の形式を規定する エントリの属性を照合条件と比較照合する際に どのような場合に指定された照合条件を満たすとするかを規定する オブジェクトクラスごとのエントリの相対識別名 (RDN) を構成する名前用属性 (naming attribute) を規定する エントリの配置制限を規定する オブジェクトクラスごとに付加することが可能なオブジェクトクラスを規定する 上記の構成要素からディレクトリスキーマと DIT の関係を示します 101

104 図 4.2-4: LDAP ディレクトリスキーマと DIT の関係 LDAP ディレクトリスキーマは あらかじめ国際的な標準が存在し 汎用的なオブジェクトクラス定 義や属性型定義 またその中で LDAP ディレクトリが必ずサポートしなければならないものが下記 の RFC に規定されています RFC 4517(Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules) RFC 4519(Lightweight Directory Access Protocol (LDAP): Schema for User Applications) 例えば 人 を表すエントリを検索する場合 どのディレクトリサーバに対しても (objectclass=person) といった検索条件( フィルタ ) を使用することができるのは 標準で規定されているからです 人 を表すためのオブジェクトクラスに 基本的なクラスである person 従業員など組織に属する人を表すためにある organizationalperson (person クラスにオプション属性を追加したもの ) organizationalperson にさらにオプション属性を追加した inetorgperson があります 102

105 図 4.2-5: 人 を表すためのオブジェクトクラス インターネット環境において 人 の属性項目についての仕様として inetorgperson が RFC 2798(Definition of the inetorgperson LDAP Class) に規定されています [inetorgperson] インターネット環境における人を表現するためのオブジェクトクラス定義です X.500 で定義されている Person や OrganizationalPerson に対して インターネットに必要と思われるいくつかの属性を追加しています 当初 Netscape 社ディレクトリサーバの固有のオブジェクトクラスとして定義されていましたが IETF(Internet Engineering Task Force) に提案され 若干の修正を経て RFC (Request for Commnets) になりました 現在では デファクト標準のオブジェクトクラスとなっており 多くの LDAP サーバ製品で扱うことができます 表 4.2-3: 人に関するオブジェクトクラス (person organizationalperson) クラス名種類基礎クラス属性名前用属性 person 構造型 top ( 必須 ) cn cn ( オプション ) userpassword telephonenumber seealso description organizationalperson 構造型 person ( オプション ) title x121address registeredaddress destinationindicator preferreddeliverymethod telexnumber telexterminalidentifier telephonenumber internationalisddnumber facsimiletelephonenumber street postofficebox postalcode postaladdress 103 cn cn ( オプション ) ou

106 クラス名種類基礎クラス属性名前用属性 physicaldeliveryofficename ou st l inetorgperson 構造型 organizationalperson ( オプション ) audio businesscategory carlicense departmentnumber displayname employeenumber employeetype givenname homephone homepostaladdress initials jpegphoto labeleduri mail manager mobile o pager photo preferredlanguage roomnumber secretary usercertificate x500uniqueideng usersmms userpkcs12 cn 下記にユースケースとして会社の組織情報を格納した場合の DIT を示します 104

107 図 4.2-6: 組織内の DIT の例 エントリから DIT のルートに向かうそれぞれの上位エントリの RDN を順に連結することによって そのエントリの 識別名 (Distinguished Name) を得ることができます 上図 ( 図 4.2-6) では DN は cn=yamada,ou= 第二課,ou= 営業部,dc=example,dc=co,dc=jp となります 105

108 4.3 複数ドメイン間にわたるアイデンティティ情報交換 インターネット技術の利用は ひとつの組織内での利用にとどまらず ドメインをまたいで利用されており アイデンティティ情報もドメイン横断的に管理する必要がでてきています B2B B2C B2E などの組織を超えたサイト間/Web サービス間でのアイデンティティ情報の交換をはじめ 近年関心が高まっているクラウド コンピューティング環境で 組織とクラウドサービス間でもアイデンティティ情報の交換が求められています このような環境のなかで 利用者の認証や属性 認可に関する情報を複数のドメイン間にわたる Web サイトや Web サービスの間で交換することで 一度の認証で複数のサービスが利用できるシングルサインオン (SSO Single Sign-On) を実現し サイト間で一貫性のとれた属性情報を利用したアクセス制御を実現する技術が登場し 標準化されています 異なるドメインで管理するそれぞれのアイデンティティ情報は 標準化された LDAP スキーマに基づいて管理され これらを標準化されたプロトコル上でやり取りすることによって複数ドメイン間にわたるアイデンティティ情報交換を可能にしています 図 4.3-1: 複数ドメイン間にわたるアイデンティティ情報の交換 海外では 次世代インターネット研究開発コンソーシアム Internet2 の MACE(Middleware Architecture Committee for Education) が発足したプロジェクトで 複数のドメイン間にわたるアイデンティティ情報交換とシングルサインオンを Shibboleth というオープンソースソフトウェアを開発して 実現しています MACE の名称の通り 教育機関間のアーキテクチャを研究開発するプロジェクトで 日本では 学術認証基盤 (GakuNin) として 全国の大学等が Shibboleth による連携を 106

109 行い 平成 20 年度の実証実験を皮切りに 平成 22 年度から本格運用を開始しました 一度の認証で複数のサービスを利用できる複数ドメイン間のシングルサインオン技術のひとつとして注目を集めています Shibboleth では 複数の組織を含むフェデレーションを形成し その内部で属性情報の交換を可能にします この属性情報の判定結果によってアクセス制御を行うため 形成したフェデレーションにログインした後は関連する組織のサイトにアクセスすることが可能となっています Shibboleth では LDAP ディレクトリの標準スキーマに加えて 学術系の 人 に関係する属性およ びオブジェクトクラス eduperson が組み込まれています 表 4.3-1: Shibboleth の人に関するオブジェクトクラス (eduperson) クラス名種類基礎クラス属性名前用属性 eduperson 構造型 Person ( オプション ) edupersonaffiliation edupersonnickname edupersonorgdn edupersonorgunitdn edupersonprimaryaffiliation edupersonprincipalname edupersonentitlement edupersonprimaryorgunitdn edupersonscopedaffiliation edupersontargetedid edupersonassurance cn 下図 ( 図 4.3-2) にユースケースとして大学の組織情報を格納した場合の DIT と eduperson オブ ジェクトクラスを定義したエントリの例を示します 107

110 図 4.3-2: 大学の組織情報を格納した DIT と eduperson オブジェクトクラスを利用したエントリ例 なお 本節で解説した複数ドメイン間にわたるアイデンティティ情報交換の概念は 次章以降で詳 説するインターネット上のエンティティ認証 属性情報交換 アクセス認可よび代理アクセスの基 礎概念となります 108

111 5 インターネット上のエンティティ認証 5.1 エンティティ認証の応用論点 概要 単一ドメインによるエンティティ認証の基礎理論については 2.1 節おいてすでに解説しました また 組織内のエンティティ認証については 3.2 で解説しました 次に インターネット上におけるエンティティ認証について解説します インターネット上には 多くの脅威が存在します 中でも 悪意を持った攻撃者が正当なエンティティになりすまして 不正なアクセスを行う危険性は 組織内などクローズされた空間の比ではありません 本節では インターネット上のエンティティ認証として もっとも広く利用されているパスワード認証の安全性 信頼性を確保する観点から パスワードの強度の尺度であるエントロピーという概念について解説します また より高い保証レベルでエンティティを認証するために 公的個人認証にも利用できる クオリファイド証明書 (Qualified Certificate)( 適格証明書 ) についても解説します クオリファイド証明書については 公的個人認証の必要性から欧州の標準化団体が提唱した標準をもとに 法的に認められるための証明書のセキュリティポリシーとそれを反映した証明書フォーマットが RFC として規定されています パスワードの推測困難性 パスワードによる認証を少しでも安全にかつ強固にするためには パスワードを推測または特定する難しさ ( 推測困難性 ) を確保する必要があります 本節では パスワードの推測困難性を示す尺度であるエントロピーについて NIST Special Publication の付録 A エントロピーと強度の推定 を参考に解説します 情報理論においてエントロピー (Entropy) という用語の使用を考案したのは Claude Shannon です Shannon は通常の英語の文字列に着目し それらを可能な限り効率的な方法で符号化するのに 何ビット必要であるかを考えました 以下は Shannon の文献から引用です エントロピーは ある意味では 言語の文章の各文字についてどの程度の情報量が平均とし て生成されるのかを測る統計パラメータである 言語を最も効率的な方法で 2 進数 (0 または 1) に変換した場合 エントロピー H は 元の言語の 1 文字あたりに必要な 2 進数の平均数である Shannon がこの用語を考案して以来 暗号の分野では 推測エントロピー や 最小エントロピー 109

112 といったエントロピーの代替となる尺度が考案されました 推測エントロピー(Guessing entropy) 特定のエンティティのパスワードを推測するのに必要となる作業の平均量の推定値のことである パスワードの推測エントロピーが n ビットならば 攻撃者が平均的なパスワードを推測する難しさは n ビットのランダムな数値を推測する難しさと同等である 最小エントロピー(Min-entropy) 母集団の中から最も容易に推測できる単一のパスワードを推測する難しさを示す尺度である パスワードの最小エントロピーが n ビットならば 攻撃者が該当パスワードを持つエンティティを見つけ出す難しさは n ビットのランダムな数値を推測する難しさと同等である 一連の特定の推測のもとで選択されるパスワードの度数分布が十分に分かっていれば いかなるパスワードについても推測エントロピーあるいは最小エントロピーを知ることは容易です パスワードの分布を知っている攻撃者ならば 選択したエンティティについて 最初に最も可能性の高いパスワードを試し 次に 2 番目に可能性の高いパスワードを試す というように 成功するパスワードが見つかるまで可能性の高い順からパスワードを試すことによって 選択したエンティティのパスワードを見つけることができます すべてのパスワードを対象にしたときの平均が 推測エントロピーということになります 任意のエンティティのパスワードを見つけることができればよいという攻撃者であれば 別の攻撃を行うことが予想されます つまり すべてのエンティティを対象に最も可能性の高いパスワードを試し 次にすべてのエンティティを対象に 2 番目に可能性の高いパスワードを試します 以下同様に試行を続け 最初に 当たり となるものを見つけるのです これが最小エントロピーです パスワードには ランダムに選択するパスワードとエンティティが選択するパスワードがあります (1) ランダムに選択するパスワード 長さが l 文字のパスワードを b 個の文字で構成されるアルファベットからランダムに選択したパス ワードのエントロピー H は 次の一般公式で与えられます H = log 2 ( b l ) 例えば 通常のキーボードに刻印されている 94 個の印字可能な ISO 文字から 8 文字で構成されるパスワードをランダムに選択した場合のエントロピーは 上記の公式に当てはめると 52 ビットのエントロピーを持つといえます ランダムに選択したパスワードの場合は 推測エントロピー 最小エントロピーも同じ値となりま 110

113 す (2) エンティティが自分で選択するパスワード [ 推測エントロピー ] エンティティが自分で選択するパスワードのエントロピーを推定することは非常に難しいことです これは ランダムに選択されるものではなく 一様にランダムな分布にならないためです おそらく エンティティが自分で選択するパスワードは 通常の英語の文字列の傾向や文字の度数分布をおおむね反映し エンティティ自身が覚えておけるものが選択されると考えられます エンティティが自由にパスワードを選べる場合には 経験的に 多くの人が容易に推測できるパスワードを選びます そして 人がよく選択する数千のパスワードを収めたかなり小さな辞書であっても 実際に選択したパスワードを突き合わせると それらのパスワードの多くを クラックする ( 破る ) ことができてしまいます この場合の推測エントロピーは 標的を定めた帯域内パスワード推測攻撃に対する耐性を大きく左右するので パスワードシステムの強度を測る最も重要な尺度であるといえます まず エンティティが自分で選択するパスワードのエントロピーを推定するためには 通常の英語の文字列のエントロピーを推定する Shannon の方法を使用します Shannon は 文字の確率分布が一様ではないものの 英語の文字列の最初の文字を予測することは比較的困難であるが 最初の文字がわかれば 2 番目の文字はずっと容易に推測でき 最初の 2 文字がわかれば 3 番目の文字はさらに容易に推測でき 以下同様であることを発見しました 次に 攻撃者に容易に推測されてしまうような不適切なパスワードの選択を防ぐために 以下のよ うな規則を課し パスワードの耐性を高めます 辞書規則一般的な単語や一般に使用されているパスワードからなる 大規模な辞書テスト を実施して 辞書のなかでみつかったパスワードは許可しない ( 辞書には少なくとも 50,000 語の単語が含まれているべきである ) 組み合わせ規則 小文字 大文字 およびアルファベット以外の記号 ( 特殊文字や数字 ) を含むパスワードを選 択するようエンティティに求める このような条件に基づくと エンティティが自分で選択するパスワードの推測エントロピーとパス ワード長との関係は おおよそ下表 ( 表 5.1-1) のような概算値となります 111

114 この表では 通常のキーボードのアルファベットから選択すること以外に規則を設けなかった場合 一般的な単語や一般に選択されるパスワードの使用を防止する辞書規則のみを適用する場合 および組み合わせ規則と辞書規則の両方を適用する場合のそれぞれについて推定を行っています また 10 桁のアルファベット ( 数字 ) で構成されるパスワードや暗証番号についても推定を行っています この場合は 少なくともすべて同じ数字からなるパスワードや 連続する数字の並び ( 1234 や など) で構成されるパスワードの選択を防ぐ規則が適用されています 比較のために ランダムに選択したパスワードのエントロピーも算出しています パスワード長 5.1-1: パスワードの推測エントロピーの推定値 ( ビット数 ) とパスワード長 規則なし エンティティによる選択 94 文字のアルファベット 辞書規則 組み合わせ規則と辞書規則 10 文字のアルファベット 94 文字のアルファベット ランダムの選択 10 文字のアルファベット [ 最小エントロピー ] 経験が示すところでは かなり多くの人が非常に推測されやすいパスワードを選択します 例えば 1,000 人のうち 1 人が 最も一般的な 2 つのパスワードのうちのひとつを選択するとします また パスワードを試せるのは 3 回までで 移行はシステムがパスワードをロックするものとします 攻撃者は エンティティの識別子 (ID) の一覧を入手し 最も一般的な 2 つのパスワードを試す自動攻撃を 700 人分のエンティティに対して行えば どちらかのパスワードが誰かに当たることが期待できます 選択した特定のエンティティになりすますのではなく システムへのアクセスだけが目的であれば 明らかにこうした攻撃は実際的です ここでは 保証レベル 2 の要求事項である少なくとも 10 ビットの最小エントロピーを保証することを目的として 次のような辞書テストを規定します 112

115 パスワード内の大文字をすべて小文字に変換し 規則がない場合に一般に選択される正当なパスワードを少なくとも 50,000 個含む辞書と比較して 一致するパスワードは許可しない エンティティの名前や識別子 (ID) の並べ替えとして認識できるパスワードの使用を禁止する また 15 文字以上のパスワードにしたり システムがランダムに選択した 2 文字の文字列をエン ティティが選択した 2 文字以上のパスワードと組み合わせることでも 10 ビットの最小エントロピー を保証することができます (3) パスワードの例パスワード強度へのアプローチは エンティティの名前以外に何も知らない攻撃者が帯域内のパスワード推測攻撃によって エンティティのパスワードを見つけ出すことができる確率を測ることです 保証レベル 1 および 2 における最大の確率は次のとおりです レベル 1: 2-10 (1,024 分の 1) レベル 2: 2-14 (16,384 分の 1) 以下に ランダムに選択するパスワードとエンティティが自分で選択するパスワードの例をあげて パスワードの強度を考えてみます [ ランダムに選択するパスワードの例 ] 94 個の印字可能なアルファベット文字の中からランダムに 6 文字のパスワードをエンティティに割り当てるシステムを考えます 表 5-x から そのようなパスワードは 39.5 ビットのエントロピーを持つとみなせるので 認証失敗の許容回数を / 2 14 = 回に制限すれば レベル 2 におけるパスワード強度の要求事項が満たされます これは 認証失敗の合計回数が 回 ( 約 4,500 万回 ) に達した時点でパスワードをロックするカウンタを設けるだけでもよいですし 認証失敗が 3 回連続したあと 認証要求者を 1 分間ロックアウトする方式でもかまいません 後者の方式であれば 自動化された攻撃の試みを 1 分間で 3 回に限定することになり 乗回の試みを実行するのに約 90 年かかることになります システムにおいて 3 回の試行が失敗したらパスワード認証を 1 分間ロックし 10 年ごとにパスワードを変更することを求めるとすれば 標的を定めたパスワード推測攻撃に対するレベル 2 の要求事項を十分に満たすことになります また ランダムに選択されるパスワードの最小エントロピーは 推測エントロピーと同じであるため レベル 2 における最小エントロピーの要求事項も満たされます 113

116 [ エンティティが自分で選択するパスワードの例 ] 次のようなシステムを考えます エンティティが 94 個の印字可能なアルファベットから最低 8 文字のパスワードを使用する パスワードに少なくとも大文字を 1 個 小文字を 1 個 数字を 1 個 特殊文字を 1 個 それぞれ含めることをエンティティに求める 一般的な単語が含まれるのを防ぐために辞書を使用し 名前や識別子 (ID) の並べ替えをパスワードとして使用することを防止する このようなパスワードであれば エンティティが自分で選択するパスワードについて表 で示した組み合わせ規則と辞書規則を満たし 表 5-x から推測エントロピーは 30 ビットと推定されます パスワードの有効期限の間に エンティティによる認証失敗を 2 30 / 2 14 = 2 16 回 ( 約 65,000 回 ) 未満に制限するシステムであれば 標的を定めた推測攻撃に対するレベル 2 の要求事項を十分に満たすことになります 例えば パスワードを 2 年ごとに変更し 認証の試みが 6 回連続して失敗したらパスワード認証を 24 時間ロックすれば 攻撃者はパスワードが有効な間に = 4,380 回の試みが可能となりますが これは標的を定めた攻撃に対するレベル 2 の要求事項を十分に満たします また 辞書テストを行っているため レベル 2 における最小エントロピーの規則も満たすことになります 114

117 5.1.3 クオリファイド証明書 本節では 公的個人認証に利用できる高い保証レベルを持った クオリファイド証明書 (Qualified Certificate 適格証明書 ) について解説します 欧州政策が理想とした 域内各国共通のアイデンティティ管理の実現 に向けた施策の一環として クオリファイド証明書 が制定されてきました クオリファイド証明書 には 人々の法的な根拠に基づいて登録したアイデンティティ ( クォリファイドアイデンティティ ) の証明書を発行している意義と 相互運用性確保などのために証明書のプロファイルを標準化したことの意義があります まず アイデンティティを法的な根拠に基づいて登録することによって 域内の電子商取引や 各 種行政手続きに使える適格な証明書であることが明記されます 次にプロファイルを標準化したことによって 相互運用可能な PKI システムが開発可能となりました 欧州の標準化団体によって提唱されたプロファイル規格が IETF においても採択されて 2001 年に RFC 3039 として発行されました その後 2004 年にこのプロファイルが改訂されて RFC 3739 として発行されました クオリファイド証明書は 以下の要件を満たした証明書です 証明書がクオリファイド証明書の目的を果たすことを宣言する認証局により発行される 認証局で行われる義務 実施および手続きと整合する証明書ポリシー (CP) を含む 自然人 ( 既存の人 ) 宛に発行される subject( 主体者 ) の本当の名前や仮名に基づく名前を含む クオリファイド証明書は 電子署名についての欧州指令 といった適用する法的なフレームワーク により規定されるいくつかの資格要件に見合うものですが 利用される国や団体の幅広い要件に 対応できるように汎用的な内容になっています X.509 デジタル証明書のプロファイルは RFC 5280で規定されていますが 汎用性が高い反面そのまま利用すると技術的にも保証レベルの観点からも相互運用性の確保が難しいという問題があります このため 一定水準の CP と 下表 ( 表 5.1-2) に示す限定的なプロファイルを要件とした より具体的な標準規格にすることにより相互運用可能性を確保しています 115

118 表 5.1-2: クオリファイド証明書プロファイル 領域項目内容 基本領域 拡張領域 issuer ( 発行者 ) subject ( 主体者 ) subject AltName ( 主体者別名 ) subjectdirectoryattributes ( 主体者ディレクトリ属性 ) certificatepolicies ( 証明書ポリシー ) KeyUsage ( 鍵使用目的 ) biometricinfo ( 生体情報 ) qcstatements (QC 宣言 ) 証明書の発行に対して責任を負う組織を識別するものとし 名前は公式に登録された組織の名称である必要があります issuer によって保証される個々の人間に対して一意となる識別名を含み 少なくとも commonname givenname pseudonym のひとつを含むものとします directoryname の名称がある場合は subject と同じ規約に従う必要があります dateofbirth( 生年月日 ) placeofbirth( 出生地 ) gender ( 性別 ) countryofcitizenship( 国籍 ) countryofresidence( 居住地 ) が解釈できる必要があります 証明書ポリシー (CP) を最低一つは含む必要があります この項目は必ず設定することになっています 否認防止 (nonrepudiation) に指定した場合は他の使用目的の指定はしないことになっています 写真 署名筆跡 指紋などの生体情報のハッシュ値などを指定することができます 値の実態を格納したアドレス (URL など ) も指定できます 証明書の明示的な特性を定義する宣言 ( 法的な宣言 ) を指定することができます クオリファイド証明書は 電子署名法への対応のために 主に電子署名アプリケーションで利用さ れてきました 欧州においては インターネットを利用した行政サービスの普及に伴って 利用者 の認証のためにも利用されるようになってきました 116

119 5.2 複数ドメイン間のエンティティ認証 概要 通信販売 ソーシャルネットワーク クラウドサービスなどのインターネット技術を利用したサービスが普及し 利用者もこのようなインターネットサービスに依存した生活が当たり前となってきています ただし それらの恩恵を受けるためには それぞれのサービスに利用者登録を行い 利用に際しては認証を行う必要があります 利用者にとっては 利用するサービスが多くなればなるほど それぞれ独立した認証を求められる場面が多くなり 極めて面倒であるばかりではなく それぞれのログイン ID やパスワードを個別に覚えておくことが現実的ではなくなってきています 例えば 旅行の予約を取る場合 航空会社やレンタカー会社 ホテルの Web サービスがそれぞれ別の認証を求めてくるのでは 利用者にとって極めて不便です 一度航空会社の Web サイトで認証されたら 航空会社と連携しているレンタカー会社やホテルの Web サイトには 認証なしでアクセス つまり Web シングルサインオン (SSO Single Sign-On) ができると便利ではないでしょうか 図 5.1-1: Web サイト間へ一度の認証でアクセスできるシングルサインオン環境 117

120 このような Web SSO を実現するためには ある Web サイトがエンティティ認証の結果を元にした情報を Cookie として Web ブラウザにセットし 他の Web サイトがその Cookie をチェックすることにより 再度の認証を省略する方法があります しかし この方法では Cookie は同じ DNS ドメイン内での利用に制限されているため 異なるドメイン間での Web SSO には利用することができません エンティティ認証の結果を複数ドメインにまたがって利用するには Web ブラウザによる Web ページの遷移時に HTTP GET リクエストや HTTP POST リクエストのクエリに認証要求メッセージ 認証応答メッセージを記述し サーバ間でメッセージの送受信を行う いわゆるフロントチャネル方式を用いる必要があります なお Web ブラウザとは独立して サーバ間で直接メッセージの送受信を行う方式を バックチャネル方式と呼びます このフロントチャネル方式については 伝達手段 認証要求 応答メッセージの記述の方法が 幾つか提案 策定されています また 従来からのアイデンティティ情報交換は 同じネットワーク内 ( あるいは同じドメイン内 ) の利用者やシステムに対して セキュリティを確保するために行われてきましたが 利用者が外部のシステムにアクセスしたり 外部の利用者が内部システムにアクセスしたりすることも多くなってきました このため システムと利用者の分離は重要課題となり 企業間 運用管理ドメイン間のアイデンティティ情報の連携の必要性から アイデンティティフェデレーション という新たな手法が生まれ そこで注目を集めているのが 分散連携型管理モデルを採用した SAML(Security Assertion Markup Language) や OpenID です Web SSO に関する SAML と OpenID の特徴は下表の通りです SAML OpenID 表 5.1-3: SAML と OpenID の特徴 概要 Web SSO の位置づけ Web サイト間の信頼関係 サービス間での セキュリティ アサーション交換のフレームワーク Web サイト間での Web ブラウザを用いた 認証結果と属性情報の要求 提供のプロトコル Web SSO をプロファイルのひとつとして規定 Web SSO はそのプロトコルの利用例のひとつ Web サイトが属するドメイン間の信頼関係を 事前に確立することが前提 Web サイト間はユーザの意図にしたがって動的に信頼関係を確立 SAML と OpenID は いずれもインターネット上の Web SSO をサポートしますが 下記のような違いがあります まず 仕様の構成です SAML はアイデンティティ連携に必要な要素を包括的にカバーしたモジュール構造の仕様群であり これらモジュールを組み合わせることによって実現されるユースケースのひとつが Web SSO である という位置づけになります 一方 OpenID ( 厳密にいえば OpenID Authentication) は Web SSO を実現するためのモノリシックな仕様であり その仕 118

121 様拡張は Web SSO をベースに さらにその過程で交換される情報を追加することによって行われます 次に ドメイン間での事前の信頼関係の有無も異なります SAML 仕様では あらかじめ両者間で PKI の公開鍵証明書を交換し やりとりするメッセージの真正性を検証することが推奨されています 一方 OpenID では, 仕様上は事前の信頼関係の確立は求められておらず ユーザが任意のドメイン同士を結びつけることになります 次節以降 SAML の現行版である SAML 2.0 と OpenID の現行版である OpenID 2.0 について 解 説します 119

122 5.2.2 SAML 2.0 を利用した Web SSO SAML(Security Assertion Markup Language) は 標準化団体 OASIS(Organization for the Advancement of Structured Information Standards) セキュリティ サービス技術委員会によって策定された認証 認可の要求 / 応答のプロトコルとその情報を表現するための標準で 複数の組織間で認証するための標準手法として開発された規格である AuthXML と セキュアな電子商取引を実現するための XML ベースのマークアップ言語仕様である S2ML(Security Services Markup Language) を統合して 柔軟でかつセキュアなシングルサインオン (SSO Single Sign-On) を実現することを目的として標準化したものです 2002 年 11 月に SAML 1.0 が OASIS 標準となり 2003 年 9 月に v1.1 が発行され 2005 年 3 月に v2.0 が発行されました 本書では主に SAML 2.0 を解説します SAML は Web サイトや Web サービスの間で認証 / 属性 / 認可決定に関する情報を交換することで 一度の認証で複数のサービスが利用できる SSO を実現することができます 認証 / 属性 / 認可決定に関する情報の交換方法は SAML プロトコルとしてまとめられており メッセージの送受信には HTTP もしくは SOAP(Simple Object Access Protocol) が使われます SAML 2.0 における構成概要を下図 ( 図 5.2-2) に 構成要素を下表 ( 表 5.2-2) に示します 図 5.1-2: SAML 2.0 構成概要図 120

123 構成要素 IdP SP トラストサークルメタデータ Name Identifier 役割 表 5.1-4: SAML 2.0 構成要素 アイデンティティプロバイダ (Identity Provider) の略 認証 / 属性 / 認可決定の情報を提供する役割を担う IdP で認証された利用者は SP のサービスにアクセスできるようになる サービスプロバイダ (Service Provider) の略 SSO の対象となる Web アプリケーションなどを指す IdP が発行した認証 / 属性 / 認可決定の情報に応じて利用者にサービスを提供する SAML 2.0 では 事前に SP と IdP との間に信頼関係を結ぶ必要がある 具体的には 契約や SLA(Service Level Agreement) ガイドラインなどに合意し メタデータを交換することでこれを実現する これらの信頼関係で結ばれた単位をトラストサークル (Circle of Trust) と呼び トラストサークルに属した組織間でアイデンティティ情報の連携が可能となる XML で定義され 連携先のサービスエンドポイントや公開鍵情報などが記述される IdP と SP でアイデンティティ情報を連携する際に利用する識別子で IdP と SP の双方でそれぞれのアイデンティティ情報に紐付けし Name Identifier を共有する これにより IdP および SP で 共通の識別子を使って 利用者を識別できるようになる Name Identifier では メールアドレス 利用者の属性情報 仮名 (SP ごとに異なるランダム文字列による識別 ) X.509 の Subject Name の 4 つになります SAML 2.0 は柔軟でかつセキュアな SSO を実現し クッキーを用いず クッキーの柔軟性はそのままに クッキーの持つスケーラビリティの制限とセキュリティ問題を解決することを目指して設計されました しかし 実際のアプリケーションでは 認証の後に利用者の資格などの属性によって アクセスできるページや Web サイトを制限したり また与えられたアクセス権限によりリソースへのアクセスを制御したりする いわゆる認可サービスが必要となります SAML 2.0 には認証情報伝達サービス (Authentication Assertion) に加え 2 つの認可サービスが加えられており ひとつは属性情報の伝達 (Authorization Assertion ) であり もうひとつはアクセス制御情報の伝達 (Authorization Decision Assertion) です SAML はセキュリティ情報交換のための XML ベースのフレームワークであり アサーションと そのアサーションのリクエスト ( 要求 ) とレスポンス ( 応答 ) のプロトコルの構文仕様を定めたものです アサーションは 対象となるエンティティ ( 人またはコンピュータ ) の認証情報 属性情報 認可決定情報を XML 形式で表現します SAML では 特定の認証モデル ( パスワード認証 Kerberos 認証 X.509 デジタル証明書認証など ) を規定しておらず エンティティのクレデンシャルを検証して認証を行った結果をアサーションで返します アサーションは エンティティのおおもとのクレデンシャルに比べて 有効期間が短期であるため時限クレデンシャル (short-lived credential) と呼ばれます SAML 2.0 では アイデンティティ情報の連携の仕組みとして SP-Initiated SSO と IdP-Initiated 121

124 SSO の 2 種類があります これは ブラウザが IdP と SP のどちらに最初にアクセスしたか とい うことではなく SAML として連携のトリガーが IdP と SP のどちらか ということです 以下に SAML 2.0 における SP-Initiated SSO と IdP-Initiated SSO の仕組みを示します [SP-Initiated SSO シーケンス ] 利用者は SP にアクセスして IdP での認証に成功した後に 再度 SP にアクセスします 図 5.1-3: SP-Initiated SSO 概要 1 利用者が SP へアクセスします 2 SP は SAML リクエストを生成し IdP へ送信します 3 IdP は利用者を認証します 4 認証に成功すると IdP はアサーションを生成し SP に送信します (SAML レスポンス ) 5 SP はアサーションを元にアクセス制御を行い サービスを提供します 図 5.1-4: SP-Initiated SSO 認証シーケンス 122

125 [IdP-Initiated SSO 方式シーケンス ] 利用者は IdP へアクセスし 認証に成功した後に SP へアクセスします 図 5.1-5: IdP-Initiated SSO 概要 1 利用者は IdP へアクセスします 2 IdP は利用者を認証します 3 IdP での認証に成功すると IdP は SP にアサーションを生成し送信します (SAML レスポンス ) 4 SP は受け取ったアサーションを元にアクセス制御を行い サービスを提供します 図 5.1-6: IdP-Initiated SSO シーケンス 123

126 SAML で信頼関係を結んでいるサイト間でのアイデンティティ情報の連携について ユースケース を以下に示します 図 5.1-7: SAML で信頼関係を結んでいるサイト間でのアイデンティティ情報の連携 [SAML の認証コンテクスト ] SAML の認証コンテクスト拡張では 認証手段 (ID/ パスワード X.509 証明書など ) に加えて 認証対象 ( ネットワーク 端末 個人の情報 ) の組み合わせを SP から指定することを可能にしています 図 5.1-8: 認証コンテクストによる認証条件の要求 124

127 5.2.3 OpenID 2.0 を利用した Web SSO 現行の OpenID の仕様である OpenID Authentication 2.0 および OpenID Attribute Exchange 1.0 ( 以下 OpenID 2.0 と呼びます ) は 2 つの Web サイト間における Web ブラウザを用いたアイデンティティ情報 ( エンティティの認証結果と属性情報 ) の要求と応答を行うためのプロトコルとして策定されました 現在までに インターネットサービス事業者 携帯通信事業者 ネット決済事業者などのような 多数の利用者を抱える Web サイトが OpenID を採用し 他社 Web サイトとアイデンティティ情報を連携するための API(Application Programming Interface) を提供しています OpenID2.0 は OP(OpenID Provider) と RP(Relying Party) から構成されます OP は OpenID として利用できる識別子 (ID) を発行するサイトで RP は OP から認証結果を受けて サービスを提供するサイトです OpenID 2.0 では 利用者が RP に対して提供する識別子 (RP へのログイン時に入力する識別子 ) を User-Supplied Identifier と呼びます OpenID 1.0 では Claimed Identifier と呼ばれる OP が発行した識別子 (URL/XRI 形式の文字列 ) だけが認証時に利用可能でしたが OpenID 2.0 では User-Supplied Identifier として Claimed Identifier に加えて OP Identifier が利用できるようになりました OP Identifier とは OP を表す識別子です OP Identifier を User-Supplied Identifier として利用することにより 利用者は RP に対して Claimed Identifier を提供せずに OP で RP に渡す識別子を選択して認証を行うことができます OpenID 2.0 における構成概要と認証のフローを下図 ( 図 ) に 構成要素を下表 ( 表 5.2-3) に 示します 図 5.1-9: OpenID2.0 の構成概要 125

128 OP RP 用語 User-Supplied Identifier Claimed Identifier OP Identifier 表 5.1-5: OpenID 2.0 構成要素 説明 OpenID Provider の略で OpenID として利用できる識別子 (ID) を発行するサイトを表す Relying Party の略で OpenID の識別子を使った認証結果を OP から受け付けてサービスを提供するサイトを表す 利用者が認証時に利用する ( 入力する ) 識別子の総称 User-Supplied Identifier には Claimed Identifier と OP Identifier が利用できる 利用者が所有していると主張する識別子で OP が発行する URL/XRI 形式の文字列です OP によって この識別子を検証することによって 認証が行われる OP 自身をあらわす識別子 OpenID 2.0 の認証の概要を下図 ( 図 ) に示します 図 : OpenID 2.0 の認証 1 利用者は RP にアクセスし User-Supplied Identifier として OP から発行された Claimed Identifier(URL または XRI 形式の文字列 ) を入力するか OP Identifier を入力 ( あるいはプルダウンやボタン等により OP を選択 ) します 2 RP は利用者により入力された User-Supplied Identifier から OP を決定します 3 RP は OP との間で暗号化のための鍵を共有します 4 RP は利用者を OP にリダイレクトして認証を要求します 5 利用者は普段利用しているクレデンシャルを使って認証を受けます 6 OP は認証結果と利用者の属性情報を RP へリダイレクトします 7 認証が成功した場合 RP は利用者のアクセスを許可します 126

129 OpenID 2.0 のユースケースを下図 ( 図 ) に示します 図 : OpenID 2.0 のユースケース [PAPE(OpenID Provider Authentication Policy Extension 1.0)] OpenID 2.0 の拡張機能の 1 つである PAPE(OpenID Provider Authentication Policy Extension 1.0) では RP から OP に認証方法を要求する機能を提供しています OP は 自身がサポートする認証ポリシーを エンドユーザの XRDS 文書に記述し RP に広告 (advertise) します 以下の例では OP は当該エンドユーザを フィッシング耐性のある (phishing-resistant) 方法に よって認証を行なうことが広告されています <xrd> <Service> <Type> <Type> <URI> </Service> </xrd> あるいは以下の例のように OP がどの保証フレームワークに準拠するかを 独自の 名前空間 として広告することも可能です 127

130 <xrd> <Service> <Type> <Type> <URI> </Service> </xrd> OpenID Authentication のプロセスにおいては RP は OP のエンドポイントの場所を入手するために エンドユーザが指定した User-Supplied Identifier( 自身を識別する URL / XRI あるいは OP の識別子 ) に基づき XRDS 文書を取得します このとき XRDS 文書に OP がサポートする認証ポリシー が記載されていることによって RP は エンドユーザに関するアサーションをどの OP にリクエストするかを認証ポリシーに基づいて判断することができるようになります また RP は OP に OpenID 認証リクエストを行なう際 そのメッセージのパラメータとして アサー ション発行時に適用してほしい 認証ポリシー や 保証フレームワークの名前空間 などを含めま す (PAPE リクエスト ) 認証リクエストを受け取った OP は 認証ポリシーに従い ユーザを認証します OP は認証結果 ( アサーション ) を RP に返却する際 そのメッセージのパラメータとして アサーション発行時に適用した 認証ポリシー や 保証フレームワークの名前空間 実際の保証レベル などを含めます (PAPE レスポンス ) なお OP は RP からの PAPE リクエストの有無にかかわらず PAPE レスポンスを返却することができます RP は OP からの PAPE レスポンスの内容 すなわち適用された認証ポリシーを判断し エンド ユーザからのアクセスの可否を決定します 128

131 5.3 エンティティ認証についての保証レベル 概要 エンティティ認証を必要とする電子的なトランザクション ( 組織内でのオンライン業務やインターネット上でのサービスなど ) においては エンティティの身元保証のためのクレデンシャルに適切なレベルの保証を与えることは 非常に重要です このクレデンシャルの 保証レベル は エンティティの身元を保証するための 登録時の審査プロセス の信頼性の程度と そのクレデンシャルを使用するエンティティが確かに本人であることの信頼性の程度を表します また 保証レベル は 認証方式の強度の違いを表す指標とも言えますので システムの認証方式を検討するためにも使われます 米国大統領府行政管理予算局の E-Authentication Guidance for Federal Agencies( 連邦政府機関向けの電子認証に関わるガイダンス ) (M-04-04) および米国 NIST(National Institute of Standards and Technology) の Electronic Authentication Guideline( 電子認証に関するガイドライン ) (NIST Special Publication ) では 下表 ( 表 5.3-1) に示す 4 つの保証レベルを定義しています 保証レベルレベル 1 レベル 2 レベル 3 レベル 4 表 5.3-1: 保証レベル レベルの定義 主張されたクレデンシャルの有効性についてほぼ あるいはまったく信頼性がない 主張されたクレデンシャルの有効性についてある程度の信頼性がある 主張されたクレデンシャルの有効性について高い信頼性がある 主張されたクレデンシャルの有効性についてきわめて高い信頼性がある 我が国でも 電子政府システムに同様の保証レベルを採用し 内閣官房が オンライン手続にお けるリスク評価及び電子署名 認証ガイドライン を発行しています 本節では 電子的なトランザクションにおける様々な脅威に対する潜在的なリスクの影響度を踏ま え 合理的な認証方式を検討するために 下記について解説します エンティティ認証における潜在的なリスクと評価 リスク評価に基づく保証レベルの決定 各保証レベルに求められる対策基準 129

132 5.3.2 エンティティ認証における潜在的なリスクと評価 認証プロトコルは 認証要求者 ( エンティティ ) と検証者のあいだで取り交わされるメッセージの定義とシーケンスを規定したものです 認証プロトコルによって 検証者は 認証要求者が自身の身元を証明するための有効なクレデンシャルを所有していることを検証します 認証要求者と検証者の間のメッセージ交換の結果 認証要求者は認証に成功もしくは失敗することになります [ 認証の脅威 ] 認証における脅威は 実行中の認証プロトコルそのものに対する攻撃を伴うものと クレデンシャルを暴く攻撃や機密情報を危険な状態にさらす攻撃を伴うものに分けることができます 一般に クレデンシャルを暴く攻撃は 攻撃者がその後で そのクレデンシャルを使用して本来の認証要求者を装うことができるので なんらかの機密情報を危険な状態にさらす攻撃よりも悪質であるといえます エンティティ認証における攻撃として考えられる脅威については 2.1 エンティティ認証 で挙げています [ 潜在的なリスク ] エンティティが主張するクレデンシャルについて 保証レベルを決定するためには 潜在的なリスクを評価し それらの影響を最小限に抑える対策を特定する必要があります 認証に関するリスクが より深刻な結果を招く可能性がある場合には より高い保証レベルの認証が必要となります 認証に関するリスクは 次の 2 つの要素からなると考えることができます 潜在的なリスク そのようなリスクが生じる可能性の高さ 米国大統領府行政管理予算局の E-Authentication Guidance for Federal Agencies( 連邦政府機 関向けの電子認証に関わるガイダンス ) (M-04-04) では 潜在的なリスクを次のように分類して います 不便 苦痛もしくは地位または評判に対する打撃 財務上の損失または政府機関の賠償責任 政府機関の活動計画または公共の利益に対する害 機密情報の無許可の公開 身の安全 民事上または刑事上の法律違反 130

133 上記の潜在的なリスクは その影響度を評価して 低位 中位 高位 の 3 つのレベルに分けら れます それぞれの潜在的リスクの影響度について 表 5.3-2~ 表 に示します レベル 低位 中位 高位 表 5.3-2: 不便 苦痛もしくは地位または評判に対する打撃 の影響度 ( 米国 ) 影響 最悪の場合 限定的かつ短期間の不便 苦痛または任意の当事者の当惑 最悪の場合 深刻かつ短期間または限定的かつ長期間の不便 苦痛または任意の当事者の地位または評判に対する打撃 深刻または長期間の不便 苦痛または任意の当事者の地位または評判に対する打撃 レベル低位中位高位 表 5.3-3: 財務上の損失または政府機関の賠償責任 の影響度 ( 米国 ) 影響 最悪の場合 任意の当事者の回復不能で軽微または若干の財務上の損失 もしくは最悪の場合 政府機関の軽微または若干の賠償責任 最悪の場合 任意の当事者の深刻で回復不能な財務上の損失 もしくは政府機関の深刻な賠償責任 任意の当事者の壊滅的で回復不能な財務上の損失 もしくは政府機関の深刻または壊滅的な賠償責任 レベル 低位 中位 高位 表 5.3-4: 政府機関の活動計画または公共の利益に対する害 の影響度 ( 米国 ) 影響 最悪の場合 組織の運営または資産もしくは公共の利益に対する限定的な悪影響 限定的な悪影響の例としては (i) 組織が 著しく 低下した効率で主要な機能を実施せざるを得ず その状態が継続する 業務能力の劣化 (ii) 組織の資産または公共の利益の軽微な損害 最悪の場合 組織の運営または資産もしくは公共の利益に対する深刻な悪影響 深刻な悪影響の例としては (i) 組織が 大幅に 低下した効率で主要な機能を実施せざるを得ず その状態が継続する 業務能力の大幅な劣化 (ii) 組織の資産または公共の利益の重大な損害 組織の運営または資産もしくは公共の利益に対する重大または壊滅的な悪影響 重大または壊滅的な悪影響の例としては (i) 組織が主要な機能のひとつ以上を実施できず その状態が継続する 業務能力の激しい劣化または喪失 (ii) 組織の資産または公共の利益の際立った損害 レベル 低位 中位 表 5.3-5: 機密情報の無許可の公開 の影響度 ( 米国 ) 影響 最悪の場合 許可のない当事者に対する個人情報 合衆国政府の機密情報または企業秘密の限定的な公開に起因する FIPS PUB 199 に規定されている 低位の影響 をもたらす機密性喪失 最悪の場合 許可のない当事者に対する個人情報 合衆国政府の機密情報または企業秘密の公開に起因する FIPS PUB 199 に規定されている 中位の影響 をもたらす機密性喪失 131

134 レベル 高位 影響 許可のない当事者に対する個人情報 合衆国政府の機密情報または企業秘密の公開に起因する FIPS PUB 199 に規定されている 高位の影響 をもたらす機密性喪失 レベル低位中位高位 表 5.3-6: 身の安全 の影響度 ( 米国 ) 影響 最悪の場合 医療措置を必要としない軽症 最悪の場合 軽症が生じる中程度のリスクまたは医療措置を必要とする負傷が生じる限定的なリスク 深刻な負傷または死亡のリスク レベル低位中位高位 表 5.3-7: 民事上または刑事上の法律違反 の影響度 ( 米国 ) 影響 最悪の場合 通常は法執行の対象とならないような性質の民事上または刑事上の法律違反のリスク 最悪の場合 法執行の対象となる可能性のある民事上または刑事上の法律違反のリスク 法執行の計画にとって特に重要とされている民事上または刑事上の法律違反のリスク 一方 日本の内閣官房の オンライン手続におけるリスク評価及び電子署名 認証ガイドライン で は オンライン手続きにおける潜在的なリスクを考えると 金銭的損害 と 機密情報の漏えい の 2 つを主なリスクと考え それらのリスクの影響度を 4 つのレベルに分類しています 影響度特高高中低 表 5.3-8: リスクの影響度の定義 ( 日本 ) 定義 当該リスクの影響による損失が 組織の運営 組織の資産 または個人に致命的または壊滅的な悪影響を及ぼすと予想される 当該リスクの影響による損失が 組織の運営 組織の資産 または個人に重大な悪影響を及ぼすと予想される 当該リスクの影響による損失が 組織の運営 組織の資産 または個人に限定的な悪影響を及ぼすと予想される 当該リスクの影響が 測定可能な結果をもたらさない 金銭的損害 に係るリスクの影響度は 事案がもたらす被害規模 と 申請等に係る厳格さ の 2 つの評価軸を設定して それぞれの影響度を評価します 事案がもたらす被害規模 のレベルを表 に 申請等に係る厳格さ のレベルを表 に示します 132

135 レベル特高高中低 表 5.3-9: 事案がもたらす被害規模 のレベル( 日本 ) 金銭的損害の程度 1,000 万円以上の金銭的損害 100 万円以上 1,000 万円未満の金銭的損害 100 万円未満の金銭的損害 金銭的損害なし レベル特高高中低 表 : 申請等に係る厳格さ のレベル ( 日本 ) 申請等に係る厳格さの程度 当該手続の申請等にあたり 本人確認または申請書等の真正性確保のため 当該手続を所管する主体が保有するデータベースに加え 主体以外が保有するデータベースとの照合を実施している もしくは厳格な公的証明書等注による確認を実施している 当該手続の申請等にあたり 本人確認または申請書等の真正性確保のため 当該手続を所管する主体が保有するデータベースとの照合 もしくは公的証明書等による確認を実施している 当該手続の申請等にあたり 本人確認または申請書等の真正性確保のため 上記の方法ほどの厳格さはないが 何らかの確認を実施している 当該手続の申請等にあたり 特に確認を実施していない 金銭的損害 に係るリスクの影響度は 事案がもたらす被害規模 と 申請等に係る厳格さ の 2 軸を用いたマトリクス表に基づき レベルを決定します 機微情報の漏えい に係るリスクの影響度は 情報の重要度 という評価軸を設定して 評価し ます レベル特高高中低 表 : 情報の重要度 のレベル ( 日本 ) 情報に含まれる機微 ( センシティブ ) の度合い 生命の危険または差別や名誉毀損等の社会的不利益につながるもののうち 回復が困難なもの ( 個人情報保護マネジメントシステム - 要求事項 (JIS Q 15001) で収集禁止の個人情報として定義されているものなど ) 特高と中の中間に位置するもの 公知のもの 機微情報ではないもの 133

136 5.3.3 リスク評価に基づく保証レベルの決定 米国大統領府行政管理予算局の E-Authentication Guidance for Federal Agencies( 連邦政府機関向けの電子認証に関わるガイダンス ) (M-04-04) では 下表 ( 表 ) に示すように リスク評価から得られた影響度から求められる保証レベルを決定します 求められる保証レベルは すべての分類の中で一番高い保証レベルとなります 例えば 潜在的なリスクの 5 つの分類が保証レベル 1 に該当し ひとつの分類が保証レベル 2 に該当する場合は 求められる保証レベルはレベル 2 となります 表 : 各保証レベルにおける最大の潜在的リスクの影響度 ( 米国 ) 潜在的なリスク 保証レベル 不便 苦痛もしくは地位または評判に対する打撃低位中位中位高位 財務上の損失または政府機関の賠償責任低位中位中位高位 政府機関の活動計画または公共の利益に対する害該当なし低位中位高位 機密情報の無許可の公開該当なし低位中位高位 身の安全 該当なし 該当なし 低位 中位 高位 民事上または刑事上の法律違反該当なし低位中位高位 一方 日本の内閣官房の オンライン手続におけるリスク評価及び電子署名 認証ガイドライン では 総合的なリスク評価を行った後に 求められる保証レベルを決定します 総合的なリスク評価は 金銭的損害に係るリスク の影響度を決定した後に 機微情報の漏えいに係るリスク の影響度を決定し 両リスクの影響度に差があるようであれば リスクの回復可能性について考慮した上で 2 つのリスクにおける総合的なリスクの影響度を決定します 下表 ( 表 ) に総合的なリスク評価の例を示します 金銭的損害に係るリスクの影響度 表 : 総合的なリスク評価の例 ( 日本 ) 機微情報の漏えいに係るリスクの影響度 総合的なリスクの影響度 高中変更について検討 ( 中 or 高 ) 高高高 高特高変更について検討 ( 高 or 特高 ) 求められる保証レベルは 下表 ( 表 ) に示すように 総合的なリスクの影響度に応じて 決 定します 134

137 表 : 総合的なリスクの影響度と保証レベルの対応付け ( 日本 ) 総合的なリスクの影響度対応する保証レベル特高レベル 4 高レベル 3 中レベル 2 低レベル 1 135

138 5.3.4 各保証レベルに求められる対策基準 エンティティ認証を行うために必要な構成要素は アイデンティティ情報の登録 クレデンシャルの発行 管理 トークン 認証プロセス であり アサーション が加わる場合があります NIST Special Publication には これらの構成要素のそれぞれについて各保証レベルに求められる対策基準が掲げられています 登録による身元確認の結果 認証の対象者 ( エンティティ ) はシステムの 利用者 となります 利用者に対しては アイデンティティ情報に関連付けられたクレデンシャル ( およびクレデンシャル情報を格納するトークン ) が発行されます 認証プロセスでは 利用者が認証要求者としてアイデンティティ情報をシステムに主張するとともに クレデンシャル情報を認証要求者が保持していることをシステムが検証します この検証によって 認証要求者とアイデンティティ情報との同一性 すなわち認証要求者が利用者であることを判定することが可能となります 構成要素 アイデンティティ情報の登録 クレデンシャルの発行 管理 トークン 認証プロセス アサーション 説明 表 : エンティティ認証を行うための構成要素 認証の対象者の身元確認を行なうプロセスであり 機能的には RA(Registration Authority 登録機関 ) が担う アイデンティティ情報の登録による身元確認の結果 ( 身元の保証 ) に基づいて クレデンシャル ( およびクレデンシャル情報を格納するトークン ) の発行と管理を行なうプロセスであり 機能的にはクレデンシャルプロバイダが担う 認証要求者が所持し管理する何かであり クレデンシャル情報を格納または出力するハードウェア (IC カード ワンタイムパスワードトークン等 ) やソフトウェア ( ファイル等 ) あるいは知識等のクレデンシャル情報そのもの ( パスワード等 ) がある 認証要求者のアイデンティティ情報を特定し クレデンシャルを保持していることを検証することによって 当該対象者が主張するアイデンティティ情報との同一性を検証するプロセスである 検証者が利用サイト宛に送る認証要求者に関するステートメントであり 認証結果を伝える [ アイデンティティ情報の登録 ] 認証要求者は 申請者 としてアイデンティティ情報の登録申請を行ないます 登録申請にあたっては 申請者がひとつまたは複数の本人確認書類を提示することによって RA(Registration Authority 登録機関) による身元確認が行なわれます 表 はアイデンティティ情報の登録申請における脅威と対策の例であり 表 は対面によりアイデンティティ情報の登録申請を実施する場合 表 は遠隔 ( 郵送やオンライン等 ) によりアイデンティティ情報の登録申請を実施する場合の各保証レベルの対策基準です 表 に記載したの通り レベル 4 の保証レベルでは遠隔によるアイデンティティ情報の登録申請が認められません 高い保証レベルほど 身元確認のために用いられる本人確認書類および当該本人確認書類の提示プロセスに求めら 136

139 れる信頼性は厳しいものとなります また レベル 1 の保証レベルでは 申請者の身元確認は特 に必要ではなく 申請者が名前等の情報を提示した場合 そのまま受け入れます そのため レ ベル 1 において登録された名前などはすべて仮名として扱われます 表 : アイデンティティ情報の登録における脅威と対策の例 脅威 / 攻撃説明脅威の例対策の例 存在性の詐称 生存性の詐称 当人性の詐称 唯一性の詐称 現実には存在しない架空の人物へのなりすまし 過去に存在していたが 現在は生存していない人物へのなりすまし 実在する他の人物へのなりすまし 同一人物による不正な重複登録 偽造パスポートの提示 死亡した人物の本人確認書類の提示 他人の本人確認書類の提示 個人情報を一部変更する等して登録を申請 登録の否認 登録事実の否認 トークン受領後に登録 事実を否認 発行元への問い合わせ等による偽造パスポートの検証 生存していなければ提示困難な本人確認書類の提示を求め矛盾点を検出 顔写真付の本人確認書類によりなりすましの検出 過去の記録と照合し 類似の申請事実を検出 登録申請書への署名 対策基準 表 : アイデンティティ情報の登録の保証レベルと対策基準 ( 対面の場合 ) 電子メールアドレスが申請された場合 有効性 ( 到達性 ) を確認する 申請者は 公的な写真つきの身分証明書 ( 運転免許証 パスポート等 ) を 1 種類 または その他の身分証明書を 2 種類提示する 申請者の氏名や住所等の公的な台帳との照合 または申請書に添付された公的証明書 ( 住民票等 ) によりチェックする 重複登録ではないことを確認する 保証レベル ( 1) ( 2) ( 3) 1 は各保証レベルへの準拠にあたり必須の対策基準 は任意の対策基準であることを示す 2 公的な写真つきの身分証明書を必須とする 3 公的な台帳との照合を必須とする 137

140 対策基準 表 : アイデンティティ情報の登録の保証レベルと対策基準 ( 遠隔の場合 ) 電子メールアドレスが申請された場合 有効性 ( 到達性 ) を確認する 申請者の氏名と住所等 および身元確認に有効な他機関の登録情報 ( クレジットカード番号等 2) が記載された申請書により申請する 申請者の氏名や住所等の公的な台帳との照合 または申請書に添付された公的証明書 ( 住民票等 ) によりチェックする 申請者の氏名と住所等が記載された申請書に本人の電子署名 ( 郵送の場合は署名または捺印 ) を付与して申請する 保証レベル ( 1) ( 3) 1 は各保証レベルへの準拠にあたり必須の対策基準 は任意の対策基準であること を示す 2 登録申請にあたってクレジットカードによる決済行為を伴う場合には 結果として他機関であ るクレジットカード会社の登録情報に基づく対象者の存在確認の効果が得られると考えられる 3 電子署名は対象の保証レベルと同等の基準を満たすものの利用が望ましい [ クレデンシャルの発行 管理 ] クレデンシャルの発行 管理では アイデンティティ情報の登録申請の結果を受けて 認証要求者に対し クレデンシャルとトークンの発行を行います 簡易なクレデンシャル発行システムでは アイデンティティ情報の登録の一環として 認証要求者がトークン ( 例えば パスワード ) の登録を行うことも含まれます 利用期限切れ または失効したクレデンシャルやトークンに対して 再発行や回収も行います 表 は クレデンシャルの発行 管理における脅威と対策の例であり 表 は各保証レベルの対策基準です 138

141 暴露 ( 漏えい ) 改ざん 表 : クレデンシャルの発行 管理における脅威と対策の例 脅威脅威例対策例 権利を持たない者への発行 クレデンシャル ( パスワード等 ) が CSP (Credential Service Provider) から利用者に送付される過程 あるいは CSP の装置内の残留によって 攻撃者に流出する 利用者によるクレデンシャル ( パスワード等 ) の変更の過程で ( 例えば 利用者から CSP にパスワードを送信中に ) 攻撃者によってクレデンシャル ( パスワード等 ) が不正に変更される 利用者であると主張する不正な利用者に 正規利用者に発行されるべきクレデンシャル ( パスワード等 ) が発行される 本人に直接クレデンシャル ( パスワード等 ) を手渡す 本人の確認済み住所に郵送する 高い機密性を持つプロトコルを用いてオンラインにて発行する CSP の設備を隔離された部屋に設置する等して保護する 本人の確認済み住所に郵送する 高い機密性を持つプロトコルを用いてオンラインにて発行する 認証によって CSP の正当性を確認する クレデンシャル ( パスワード等 ) を受領する者が登録手続を行った者と同一であることを確認する 保証レベルレベル1 レベル 2 レベル 3 表 : クレデンシャルの発行 管理の保証レベルと対策基準 対策基準 発行 クレデンシャルおよびトークンが 本人の電子メールアドレスに対して送付される または オンラインでの登録手続の過程で 本人がクレデンシャルおよびトークンをダウンロードする 管理 検証者が使用する秘密情報はアクセス制御によって保護され パスワードのような秘密情報を平文のままで含まない 発行 クレデンシャルおよびトークンが 以下のいずれかの方法により本人に配付される (1) 窓口にて直接手渡される (2) 2 つに分割され ( 例えば ID とパスワード等 ) 少なくともそのひとつが本人住所に普通郵便により送付される (3) 本人の電子メールアドレスに対して入手サイト先の情報とパスワードが通知され 本人が当該パスワードによる認証の上で 当該サイトからダウンロードする 管理 レベル 1 と同等以上の対策基準とする 更新 / 再発行 クレデンシャルおよびトークンの更新 再発行に関する運用ポリシー ( クレデンシャルや登録されたアイデンティティ情報の更新の必要性や手続方法等 ) が策定され 周知されている 記録保管 クレデンシャルおよびトークンの発行 管理に関する記録を 当該クレデンシャルの有効期限または失効時期の遅い方の時期から一定期間保管する 発行 クレデンシャルおよびトークンが 以下のいずれかの方法により本人に配付される (1) 窓口にて直接手渡される (2) 本人住所に書留郵便または本人限定受取郵便にて送付される (3) 本人住所に書留郵便または本人限定受取郵便にてパ 139

142 保証レベル レベル 4 対策基準 スワードが送付され 本人が当該パスワードによる認証の上で クレデンシャルおよびトークンをダウンロードする (4) 申請者が電子署名を付与した申請を行い それが検証された後で クレデンシャルおよびトークンをダウンロードする 管理 レベル 2 と同等以上の対策基準とする 更新 / 再発行 レベル 2 と同等以上の対策基準に加え 特にオンラインによる手続の場合には 既存のクレデンシャルおよびトークンを用いた認証の上で 通信を暗号化して行なう 失効 クレデンシャルおよびトークンが有効ではなくなった または危殆化されたことを通知された時から クレデンシャルおよびトークンを遅滞なく失効する 記録保管 レベル 2 と同等以上の対策基準に加えて 記録を定期的に分析 評価する 発行 クレデンシャルおよびトークンが窓口にて直接手渡される ( 本人限定受取郵便基本型および同サービスと同等の手段による身元確認は対面として扱う ) 管理 レベル 3 と同等以上の対策基準とする 更新 / 再発行 レベル 3 と同等以上の対策基準とする 失効 レベル 3 と同等以上の対策基準とする 記録保管 レベル 3 と同等以上の対策基準とする [ トークン ] トークンとは 認証要求者が所持し管理する何かであり 認証に用いるクレデンシャル情報を格納または出力するハードウェアやソフトウェア (IC カード ワンタイムパスワード生成機器等 ) あるいは知識等のクレデンシャルそのもの ( パスワード等 ) 等があります トークンは 2.1 節で解説した認証の 3 要素 ( 本人の記憶に基づくもの 本人の所持に基づくもの 本人のバイオメトリクス情報に基づくもの ) の内 ひとつ以上のものを利用し 認証プロトコルに対する入力となるクレデンシャル情報を出力します 表 に 代表的なトークンの種類を示します 種類 ハードウェアトークン ソフトウェアトークン 表 : トークンの種類 定義 保護された暗号鍵を備えているハードウェアデバイス この鍵を利用してクレデンシャル情報を出力することで認証を達成させる 暗号鍵の保護機構はハードウェアにより実装され ハードウェアトークンからは暗号鍵を取り出すことができないものとする また トークンを活性化させるためにパスワードの入力を利用者に求める機能を有する場合がある ハードディスクなどの媒体に暗号鍵を格納し この鍵を利用してクレデンシャル情報を出力することで認証を達成させる 暗号鍵の保護機構 140

143 種類 ワンタイムパスワードトークン パスワードトークン 定義 はソフトウェアにより実装されるため 柔軟な運用が可能である一方で 一般的にハードウェアトークンよりも暗号鍵の複製に対する耐性を確保しづらい また トークンを活性化させるためにパスワードの入力を利用者に求める機能を有する場合がある 認証に使用する ワンタイム (1 回限り ) のパスワードを生成する機能を有するトークンであり 装置や紙等のハードウェア あるいはソフトウェアといったさまざまな実装方法が有り得る また トークンを活性化させるためにパスワードの入力を利用者に求める機能を有する場合がある 利用者が記憶している秘密情報のみを利用して認証を行う 表 はトークンにおける脅威と対策の例であり 表 は各保証レベルの対策基準です また 表 にはトークンの対策基準の実現例を示します 盗聴 表 : トークンにおける脅威と対策の例 脅威説明脅威例対策例 トークンやクレデンシャルを使用する過程で攻撃者に盗聴される 肩越しからのパスワードの覗き見 キーボードの入力ログからパスワード等を不正に取得 認証時の入力機器を通じて PIN や指紋情報等を不正に取得 ワンタイムパスワードトークンを使用する オンライン上での推測 オンラインにて認証要求を行なう方法によってクレデンシャルを推測する 辞書に掲載された単語を元にする等して 考えうるクレデンシャルをオンラインにて認証に使用し 正しいものを推測 エントロピーの高い十分な複雑性を備えたクレデンシャル情報を格納あるいは生成するトークンを使用する オフライン分析 トークンが不正に解析される 盗まれたハードウェアトークンに対する物理的な解析 ソフトウェアトークンに対する PIN の推測による特定 耐タンパ性が立証されたハードウェアトークンを使用する PIN 認証の失敗が一定回数繰り返された場合に以降の PIN 認証を禁止し 使用不能となるトークンを使用する フィッシング (phishing) ファーミング (pharming) サービス提供者へのなりすまし等によりトークンやクレデンシャルが盗まれる 不正なサービス提供者 ( 銀行等 ) を装った偽のメールにより 不正な Web サイトに利用者を ワンタイムパスワードトークンを使用する 141

144 脅威説明脅威例対策例 誘導し パスワードを不正収集 DNS の登録情報の改ざんにより不正な Web サイトに誘導し パスワードを不正収集 ハードウェア危殆化 技術革新等に安全性が低下する危うくなる 技術革新等により ハードウェアの耐タンパ性や暗号機能が危殆化する ハードウェアを交換する ハードウェアのファームウェアを更新する 142

145 対策基準 ( 対策を講ずるべき脅威 ) 表 : 認証プロセスの保証レベルと対策基準 [ 記憶された秘密など ] 攻撃者が有効なクレデンシャルを推測できる確率 ( 2) は トークンの有効期間を通じて 2-10 (1024 分の 1) 未満とすること [ 記憶された秘密など ] 攻撃者が有効なクレデンシャルを推測できる確率は 2-14 (16384 分の 1) 未満とすること [ 複数要素認証または複数トークンによる認証 ] 複数の認証要素を利用すること [ 所有による認証かつ複製に対する強い耐性を有する認証 ] 耐タンパ性 (Common Criteria による EAL4+ 又は JCMVP のセキュリティ評価に基づく耐タンパ性等 ) が確保されたハードウェアトークンを利用し トークン クレデンシャルの複製に対し強い耐性を有すること 保証レベル ( 1) は各保証レベルへの準拠にあたり必須の対策基準 は任意の対策基準であること を示す 2 確率とは 攻撃者が有効期間内に不正に認証を繰り返して正しいクレデンシャルを推測でき る度合いであり 例えばパスワードの場合 パスワードに用いる文字の種類 パスワードの長さ 有効期間 認証を規定回数失敗した際のロックが解除されるまでの時間 等によって推測できる 確率は変動する ( このようなパスワード強度の考え方については 5.1 節で解説している ) 保証レベル 表 : トークンの対策基準の実現例 143 実現例 レベル 1 ( パスワード 事前登録知識の確認など ) 94 種類の文字 ( アルファベット 数字 記号 ) による 4 桁以上の無作為 ( ランダム ) のパスワード かつ 3 回連続失敗時は 1 日間パスワード入力不可 かつ有効期限 10 年以内 94 種類の文字 ( アルファベット 数字 記号 ) による 7 桁以上のユーザ選択によるパスワード かつアルファベット 数字 記号のすべてを用い かつ辞書に掲載された単語ではない かつ 3 回連続失敗時は 1 日間パスワード入力不可 かつ有効期限 10 年以内 数字による 8 桁以上の無作為 ( ランダム ) のパスワード かつ 3 回連続失敗時は 1 日間パスワード入力不可 かつ有効期限 10 年以内 数字による 8 桁以上のユーザ選択によるパスワード かつ 5 回連続失敗時はパスワード変更を強制 レベル 2 ( パスワード 事前登録知識の確認など ) 94 種類の文字 ( アルファベット 数字 記号 ) による 5 桁以上の無作為 ( ランダム ) のパスワード かつ 3 回連続失敗時は 1 日間パスワード入力不可 かつ有効期限 10 年以内

146 保証レベル 実現例 94 種類の文字 ( アルファベット 数字 記号 ) による 8 桁以上のユーザ選択によるパスワード かつアルファベット 数字 記号のすべてを用い かつ辞書に掲載された単語ではない かつ 3 回連続失敗時は 1 日間パスワード入力不可 かつ有効期限 10 年以内 数字による 9 桁以上の無作為 ( ランダム ) のパスワード かつ 3 回連続失敗時は 1 日間パスワード入力不可 かつ有効期限 10 年以内 数字による 12 桁以上のユーザ選択によるパスワード かつ 5 回連続失敗時はパスワード変更を強制 レベル 3 ( ソフトウェアトークンとパスワードなどの複数のトークンの組み合わせ ) パスワード付きソフトウェアワンタイムパスワードトークン パスワード付きソフトウェアトークン パスワード付きハードウェアワンタイムパスワードトークン レベル 4 ( 耐タンパ性を有する IC カードや USB トークンなど ) 耐タンパ性を有するパスワード付きハードウェアトークン [ 認証プロセス ] 認証プロセスは 認証要求者がクレデンシャルを保持していることを確認することによって 認証要求者と 認証要求者が主張するアイデンティティ情報の同一性を検証するプロセスです 認証要求者は クレデンシャル情報をトークンに格納した上で保持するため 認証プロセスにおいては 認証要求者が正当なトークンの保持者であることの検証も行われます 表 は 認証プロセスの実行過程において想定される主な脅威と対策の例です これらを踏 まえ 表 に 認証プロセスに関する各保証レベルの対策基準を示します 表 : 認証プロセスにおける脅威と対策の例 脅威説明脅威例対策例 オンライン上での推測 フィッシング (phishing) ファーミング (pharming) 攻撃者が 繰り返しログインを試行するなどして クレデンシャル ( パスワード等 ) を推測する 利用者を欺いて 不正なサイトに誘い出し 情報を不正に取得する 利用者を 強制的に不正なサイトにアクセスさせ 情報を不正に取得する 144 攻撃者が Web ページにアクセスし 加入者の ID と一般的な文字列等を元にして推測したパスワードを入力して ログインを試みる 不正な電子メールによる不正な Web サイトに利用者を誘導し ユーザ名やパスワード等の情報を入力させる DNS の登録情報の改ざんにより偽の Web サイトに利用者を導き ユーザ名やパスワード等の情報を入力させる 一定期間内に実行可能な認証の回数を制限する パスワードによる認証とキャプチャを組み合わせる 正当なサービス提供者に接続したことを認証プロトコル (EV-SSL 証明書を用いた TLS 等 ) によって確認する データを傍受されても 当該データを悪用できないように正しい相手との間で通信内容に暗号化を施す 盗聴通信を盗聴し 情報を利用者がサービス提供 通信内容を暗号化

147 リプレイ攻撃 脅威説明脅威例対策例 セッション ハイジャック 中間者攻撃 不正に取得する 認証に関する通信を盗聴し 同じ内容を再度送信してなりすましを行う 認証プロトコルが完了した後に 利用者とサービス提供者の接続を奪うことによって 正当な利用者に代わってサービスを利用する 利用者とサービス提供者の通信を中継する形で横取りし 改ざん等の不正を行なう サイトにアクセスする際の通信内容を傍受し パスワード等のクレデンシャルを取得する 利用者とサービス提供サイトの間の通信を盗聴することによって 認証プロトコルの一部または全部を傍受し 再度送信する HTTP プロトコル等により交換されるセッション情報 ( クッキー等 ) を盗聴または推測することによって 接続を乗っ取る ルータに侵入する等して サービス提供者と利用者の間の通信に割り込み 両者が暗号通信のための鍵を交換する際 代わりに攻撃者の鍵をそれぞれに送信することによって 攻撃者の存在を気づかせることなく 以後の暗号化された通信内容を傍受する する 認証要求ごとにランダムなデータを生成し これを認証プロトコルにて交換される情報に含めることによって 攻撃者が同じデータを使用して認証要求を行なっても 認証に成功しないようにする 端末に対して ウイルス トロイの木馬などの不正検知等のための総合的なセキュリティ対策 ( ウイルスチェックソフトの導入等 ) を実施する 正当なサービス提供者に接続したことを認証プロトコルによって確認する 表 : 認証プロセスの保証レベルと対策基準 対策基準 ( 対策を講ずるべき脅威 ) 保証レベル ( 1) オンライン上の推測 リプレイ攻撃 盗聴 セッション ハイジャック 中間者攻撃 フィッシング / ファーミング 1 は各保証レベルへの準拠にあたり必須の対策基準 は対策の強度に制約を設け て良いことを示す 145

148 これまで解説したように エンティティ認証は 潜在的なリスクと評価を行った上で 求められる保証レベルを決定し 該当する保証レベルにおける対策 ( 認証方式の選択を含む ) を講じることで 適切なレベルの保証を与えることができます しかしながら 認証における保証レベルが高くなると 身元証明書の証拠力は高くなりますが 一方でリスクを抑制するための技術レベルが上がり コストが増えることも考慮しておかなければなりません 図 5.3-1: エンティティ認証における保証レベル 146

149 6 インターネット上の属性情報交換 6.1 SAML 2.0 によるドメイン間の属性情報交換 概要 SAML 2.0 は 5.2 節で概要を説明したように ある Web サイトが保持しているアイデンティティ情報を 他の提携先 Web サイトでも共通的に利用するために アイデンティティ情報の交換を可能とするものです SAML2.0 は XML ベースのフレームワークで 要求 ( リクエスト ) と応答 ( レスポンス ) のプロトコルと 応答に含まれるアサーションの構文仕様を定めたものです アサーションは 対象となるエンティティ ( 人またはコンピュータ ) の認証情報 / 属性情報 / 認可情報を XML 形式で表現したもので 認証アサーション ( 認証情報の伝達 ) 属性アサーション( 属性情報の伝達 ) 認可決定アサーション ( アクセス制御情報の伝達 ) から構成されます SAML 2.0 を利用することにより アイデンティティ情報の連携 シングルサインオン 識別子 (ID) の管理 シングルログアウト 属性や認可決定情報を使ったアクセス制御などが可能となります アサーションの提供を受けたエンティティは これらのアサーションをそれぞれのポリシーを実行するアプリケーションに渡します アプリケーションでは 認証アサーションにより エンティティを認証して 指定した Web ページ等へアクセスさせたり 属性アサーションに含まれるエンティティの資格属性等によって特定のページへのアクセスを制御したり 認可決定アサーションに含まれるエンティティの認可権限によって特定のリソースへのアクセスを許可したりすることができます (1) SAML 2.0 における利用者の識別 SAML 2.0 では 異なるドメイン間での利用者の特定のために IdP(Identitiy Provider) と SP (Service Provider) の間でデジタルアイデンティティの関連付けを行い それらを Name Identifier (NameID 名前識別子) と呼ばれる識別子 (ID) を利用して交換し アイデンティティ情報の連携を行います NameID は 下図 ( 図 6.1-1) に 実名を利用する場合と 仮名を利用する場合があります 147

150 図 6.1-1: アイデンティティ情報を連携するための識別子 (NameID) (2) SAML 2.0 における利用者の認証 SAML 2.0 では 下図 ( 図 6.1-2) のように利用者の認証を行います 図 6.1-2: 利用者の認証フロー 1 利用者が SP へアクセスします 2 SP が IdP に対して SAML リクエスト ( 認証要求 ) を送信します 3 IdP が利用者を認証していない場合は 認証処理を実行します 4 IdP が SP に対して SAML レスポンス ( 認証アサーション ) を送信します 148

151 (3) シングルサインオン SAML2.0 による信頼関係の構築とアイデンティティ情報の連携が完了すると 複数ドメイン間での シングルサインオン (SSO) が可能となります 図 6.1-3: シングルサインオン概要 1 利用者が SP1 にアクセス要求 2 SP1 は利用者を介して IdP へリダイレクトし認証確認 ( 認証済みであるか確認 ) 3 認証済みか否かを判断し 未認証であれば初期認証を利用者に要求 4 利用者より ID とパスワードを受取り初期認証実施 5 認証成功後 認証アサーションを生成し署名を施して SP1 へ返送 6 SP1 で認証アサーションの署名を検証しログイン許可 7 利用者が SP2 にアクセス要求 8 SP2 は利用者を介して IdP へリダイレクトし認証確認 ( 認証済みであるか確認 ) 9 認証済みか否かを判断し 認証済みであることを確認 10 認証アサーションを生成し署名を施して SP2 へ返送 11 SP2 で認証アサーションの署名を検証しログイン許可 149

152 6.1.2 SAML 2.0 仕様 (1) SAML 2.0 のフレームワーク SAML 2.0 のアサーションは SAML オーソリティが発行し エンティティの名前 / 属性 / エンティティがアクセスを許可されたリソースなどの情報が SAML オーソリティのデジタル署名により改ざん不可能な形式で含まれます SAML オーソリティには認証オーソリティ 属性オーソリティ 認可決定オーソリティの 3 つがあり それぞれの役割を下表 ( 表 6.1-1) に示します 表 6.1-1: SAML オーソリティの役割 オーソリティ役割発行するアサーション 認証オーソリティ 属性オーソリティ 認可決定オーソリティ エンティティの認証を行い 認証情報の再利用 (SSO などでの利用 ) を可能にする認証アサーションを発行する 認証アサーションを受け取り エンティティに付与された資格や役職などの属性を記述した属性アサーションを発行する 認証アサーションと属性アサーションを受け取り エンティティが求めるリソースへのアクセス可否を決定するアサーションを発行する 認証アサーション 属性アサーション 認可決定アサーション SAML 2.0 のフレームワークと処理概要を下図 ( 図 6.1-4) に示します 認証 / 属性 / 認可決定の各オーソリティは それぞれの判断結果に基づき アサーションを発行します 利用者がアクセスするアプリケーションでは 発行されたアサーションにより リソースへのアクセス制御を実行します 図 6.1-4: SAML 2.0 フレームワーク 150

153 1 利用者であるエンティティは 認証オーソリティに SAML リクエスト ( 認証要求 ) とクレデンシャル ( パスワードや鍵情報など ) を提示します 2 認証オーソリティは 認証ポリシーや外部の認証環境 (PKI 等 ) を検証して エンティティの本人性を証明する認証アサーションを発行します 3 発行された認証アサーションを属性オーソリティまたは認可決定オーソリティに示して 認可権限を問合せます 4 属性オーソリティは ポリシーや属性 DB に従って エンティティの資格や役職などの属性アサーションを発行し 認可決定オーソリティにエンティティのアクセス権限を問合せます 5 認可決定オーソリティは あらかじめ認可権限を登録したポリシーデータベースやアクセス規則に従って 認可決定アサーションを発行し 実際にアクセス制御を行うアプリケーション ( ポリシー実行点 ) に渡し Web ページやリソースへのアクセスを実行させます SAML 2.0 の仕様の概要を下表 ( 表 6.1-2) に示します 仕様アサーションプロトコルバインディングプロファイルメタデータ 表 6.1-2: SAML 2.0 の仕様の概要 説明 IdP が発行するエンティティの認証 / 属性 / 認可決定に関する情報を規定 アサーションの要求 シングルログアウト NameID の変更 マッピングなどを行う方法を規定 プロトコルを HTTP や SOAP にマッピングする方法を規定 プロトコルとバインディングとアサーションを組み合わせる方法を規定 プロファイルを実現するために必要な情報を規定 (2) SAML アサーション SAML アサーションは SAML オーソリティが発行するエンティティの認証 / 属性 / 認可決定に関する情報で XML 規格に基づいて記述します SAML アサーションには 認証アサーション 属性アサーション 認可決定アサーションの 3 つがあります アサーションの種類認証アサーション属性アサーション認可決定アサーション 表 6.1-3: SAML アサーションの種類内容エンティティの認証行為の正当性を表す情報を格納エンティティの属性情報を格納特定のリソースへのアクセス認可に関する情報を格納 151

154 アサーションの構造を下図 ( 図 6.1-5) に示します 図 6.1-5: SAML アサーションの構造 (3) SAML プロトコル SAML プロトコルは SAML アサーションを要求する方法を規定しています プロトコルのメッセージは XML 規格に基づいて記述します SAML プロトコルには 認証要求プロトコル 認証応答プロトコル ログアウト要求プロトコルなど様々なものがあり サーバ間の ( リクエスト ) と応答 ( レスポンス ) の手順を規定しています 下図 ( 図 6.1-6) に SAML プロトコルの概要を示します 図 6.1-6: SAML プロトコル概要 152

155 下表 ( 表 6.1-4) に SAML 2.0 のプロトコルとその動作概要を示します 認証要求 プロトコル 表 6.1-4: SAML プロトコル 内容 SP が IdP に対して エンティティの認証情報を要求する 認証応答 IdP が SP に認証アサーションを送信する シングルログアウト 特定のエンティティに関するすべてのセッションを一括してログアウトする IdP はこれを受け取ると 認証アサーションを発行したすべての SP に対してログアウト要求を送信する NameID 管理 Artifact とは IdP が発行するセッション ID のこと NameID を変更するための手順 IdP SP のどちらが NameID を変更してもよい NameID マッピング NameID を別の SP に発行した NameID に変換したり 別のフォーマットに変換したりする 153

156 Artifact 解決 プロトコル 内容 IdP と SP 間で SAML プロトコルのメッセージ (SAML メッセージ ) を交換するために Artifact と呼ばれる SAML メッセージ識別用のランダム文字列 ( セッション ID) を送受信する その後 この Artifact を利用して SOAP 通信によってメッセージ本体を通信する アサーション問い合わせ / 要求 発行済みアサーションを要求する アサーションの内容を指定して要求する方法とアサーションを指定して要求する方法がある (4) SAML バインディング IdP と SP 間で SAML プロトコルのメッセージを送受信するために トランスポートプロトコル (HTTP および SOAP) へのマッピング方法を規定しています ブラウザを経由する通信 (HTTP) を利用する方法とサーバ間の直接通信 (SOAP) を利用する方法の 2 つがあります 図 6.1-7: バインディング概要 下表 ( 表 6.1-5) にバインディング方式について概要を示します 154

157 バインディング方式 HTTP Redirect バインディング 表 6.1-5: バインディング方式 内容 リダイレクトを表す HTTP ステータス 302 を利用して ブラウザ経由で認証アサーションを送受信する方法 IdP と SP 間の通信は発生しない SAML プロトコルのメッセージ (SAML メッセージ ) を Base64 エンコードして ブラウザの HTTP GET メソッドで SP に送付する HTTP 302 Moved Location: リダイレクト HTTP POST バインディング GET /sso?response=... HTTP/1.1 Host:sp.example.jp... HTTP POST を利用して 認証アサーションを送受信する方法 Java Script などで自動的に POST させることが可能 IdP と SP 間の通信は発生しない SAML メッセージを Base64 エンコードして ブラウザの HTTP POST メソッドで SP に送信する <form action= post > <input name= SAML Response Value=..> <input type= submit > </form> POST /sso HTTP/1.1 HOST:sp.example.com SAML Response=... HTTP Artifact バインディング Artifact と呼ばれる SAML メッセージ識別用のランダム文字列 ( セッション ID) を HTTP ステータス 302 を利用し リダイレクトさせて送信する Artifact を受信した SP は ArtifactResolve プロトコルにより SAML メッセージを取得する (1) HTTP 302 Moved Location: (2) GET /artifact?samlart=...&relaystate=...http/1.1 HOST:sp.example.com 155

158 バインディング方式 内容 (3) <SOAP-ENV:Envelope> <SOAP-Env:Body> <ArtifactResolve> <Artifact> (4) <SOAP-ENV:Envelope> <SOAP-Env:Body> <ArtifactResolve> <RESPONSE>... SOAP バインディング SOAP1.1 を利用して SAML メッセージを IdP と SP 間で直接交換する (1) サービス要求 ( 規定外 ) (4) サービス要求 ( 規定外 ) (2) <SOAP-ENV:Envelope> <SOAP-Env:Body> <AuthnRequest> (3) <SOAP-ENV:Envelope> <SOAP-Env:Body> <RESPONSE>... Reverse SOAP バインディング SAML URI バインディング ブラウザが SOAP Server としてメッセージを交換する ( 後述の Enhanced Client and Proxy プロファイルで利用することが前提 ) Assertion Query and Request プロトコルのみが利用する方法で レスポンスによりアサーションを受け取るのではなく 直接 URI を利用してアサーションを取得する (5) SAML プロファイル SAML のアサーション プロトコル バインディングを組み合わせて シングルサインオンやシングルログアウトを実現する方法 ( プロファイル ) を規定しています SAML で利用できる機能は このプロファイルで定義されています IdP と SP 間で交換される SAML メッセージは SAML プロトコルで定義しており SAML メッセージを送受信する方法は SAML バインディングで規定しています [Web ブラウザ SSO プロファイル ] ブラウザを利用してシングルサインオンを実現するプロファイルです SP はユーザを直接認証せ ずに IdP へ認証要求を送信し IdP が認証アサーションを利用者に送信します 156

159 図 6.1-8: Web ブラウザ SSO プロファイルに基づいたシーケンス [Enhanced Client or Proxy(ECP) プロファイル ] 携帯電話やクッキーが利用できない端末など ブラウザ以外の環境においてもシングルサインオンを実現するためのプロファイルです Enhanced Client(EC) とは IdP に関する情報を保有し SAML が規定するプロトコルに従ったメッセージの送受信が可能なクライアントを指します Enhanced Proxy(EP) は SAML 対応クライアントをエミュレートする HTTP プロキシを指します 図 6.1-9: Enhanced Client or Proxy プロファイルに基づいたシーケンス 157

160 [IdP Discovery プロファイル ] SP が 利用者がどの IdP を使っているかを発見するためのプロファイルです 具体的には IdP が利用者を認証した際に CommonDomain クッキーに情報 (IdP の EntityID) を書き込み SP が CommonDomain クッキーの内容から 利用者が使っている IdP を決定し 認証要求を送信します 図 : IdP Discovery シーケンス [ シングルログアウトプロファイル ] シングルログアウトプロトコルを実行するためのプロファイルです シングルログアウトの開始は IdP SP のどちらから開始しても問題ありません 図 : シングルログアウトプロファイルに基づいたシーケンス 158

161 [NameID 管理プロファイル ] NameID を変更するためのプロファイルです IdP SP どちらが NameID を変更してもかまいません ただし SP が変更する場合は SPProvidedNameID を変更し IdP が変更する場合は NameID を変更します 図 : NameID 管理プロファイルに基づいたシーケンス [Artifact 解決プロファイル ] このプロファイルは Artifact を対応する元のメッセージに復元するための Artifact 解決プロトコルを規定しています HTTP Artifact バインディングは このメカニズムを活用して SAML メッセージを参照先に渡します 図 : Artifact 解決プロファイルに基づくシーケンス 159

162 [ アサーション問い合わせ / 要求プロファイル ] 既に発行されているアサーションの問い合わせや要求の手順を規定したプロファイルで これにより対象とするエンティティの認証や属性あるいはリソースに関する認可権限の証明を取得することができます 図 : アサーション問い合わせ / 要求プロファイルに基づくシーケンス [NameID マッピングプロファイル ] 特定の利用者に関して SP が 別の NameID や別のフォーマットを要求するためのプロファイルです たとえば SP が別の SP と通信したい場合 利用者の NameID は IdP と SP のペアであるため 利用したい SP が異なった場合は 異なった SP 向けの NameID に変換することが必要となります 図 : NameID マッピングプロファイルに基づくシーケンス 160

163 (6) メタデータメタデータとは SAML プロファイルを実行するために利用するバインディング エンドポイント ( サービスに関連した URI たとえばログアウトの URL など ) 証明書 署名 暗号鍵など IdP と SP の間で事前に交換し共有するデータです それぞれのプロバイダ (IdP や SP) が メタデータ仕様に従ってメタデータを作成し 連携するプロバイダへ配布します 図 : メタデータの構造 161

164 6.2 OpenID 2.0 によるドメイン間の属性情報交換 概要 OpenID 2.0 は普段利用者が使っている識別子 (ID) で複数のサイトを利用できるようにする つまり1 人にひとつのデジタルアイデンティティでインターネットの利用を可能にすることを目指した規格です 本書で解説する OpenID2.0 とは OpenID Authentication2.0 と OpenID Attribute Exchange 1.0 から構成されます OpenID 2.0 の特徴は インターネットで使われている URL (uniform resource locator) を識別子 ( 以下 OpenID と呼びます ) として使える点で 利用者は OpenID の発行や認証を担う Web サイト OpenID プロバイダ (OP) に 必要な個人情報などアイデンティティ情報を登録し 名前とパスワードを取得します ここまでは従来の Web サイトのユーザ登録と変わりません OpenID 2.0 ではこれに加えて OP が名前とパスワード その他属性情報を関連付けた OpenID を利用者に発行します この OpenID は OpenID 2.0 対応の他の Web サイト (RP: Relying Party) の利用者登録にも使えるようになります これに OP は名前や住所情報といった属性情報を 他の Web サイト (RP: Relying Party) に提供することが可能となります この OpenID で認証を行う部分や OP の検索部分等の仕様を定義したものが OpenID Authenticaion 2.0 となり 属性交換等の仕様を定義したものが OpenID Attribute Exchange 1.0 となります もうひとつの特徴は OpenID の名称通りの オープン性 です OpenID 2.0 では OIDF(OpenID Foundation) がインターネットに公開している仕様に従って 誰でも OP を開設できることです 利用者は インターネット上の OP の中から 自分の認証を任せる OP を自由に選べるようになります 利用者にとってのメリットは 複数の Web サイトで利用する識別子を OpenID に一本化でき 利用するサイトごとに個別の識別子を覚える必要がない 新たに Web サイトに利用者登録する際に 一から情報を入力する手間が省ける といったメリットがあります サービス提供事業者 (RP) にとっても 利用者に気軽に Web サイトを試してもらうことができる点や OP に認証システムの構築や利用者の個人情報の管理を委ねられる点などのメリットがあります OpenID 2.0 認証の概要図を下図 ( 図 6.2-1) に示します 162

165 図 6.2-1: OpenID 2.0 認証の概念図 OpenID 2.0 による認証と属性交換のフローを下図 ( 図 6.2-2) に示します 図 6.2-2: OpenID 2.0 のフロー 163

166 1 利用者は RP で OpenID を入力します 2 RP は OpenID から OP の位置を取得します 3 OP/RP サイト間で署名用の鍵交換を実施します 4 RP は利用者のブラウザを OP にリダイレクトし 利用者の認証と属性情報を要求します 5 利用者は OP でパスワードを入力し 認証を受けます 6 OP はブラウザリダイレクトを利用して 署名した認証結果と属性情報を RP へ送ります OpenID で使用される通信は HTTP で行われますが メッセージの送受信の方法には 直接通信と 間接通信の 2 種類があります 直接通信直接通信は RP 側から開始され アソシエーションの確立および認証アサーションの検証のために用いられます アソシエーションとは RPと OP 間でメッセージを送受信するための通信路のことです 直接通信では RP が OP に対して HTTP POST により直接要求 ( ダイレクトリクエスト ) を送信し OP から直接応答 ( ダイレクトレスポンス ) を受信することで通信を行います 間接通信間接通信は ユーザエージェント ( ブラウザなど ) を経由して通信を行います RP OP のいずれからでも開始することができ 認証要求 ( 認証リクエスト ) と認証応答 ( 認証レスポンス ) の交換のために用いられます 間接通信には HTTP リダイレクトと HTML フォーム送信の 2 つの方法があります 164

167 OpenID 2.0 のプロトコルシーケンス図を下図 ( 図 6.2-3) に示します 図 6.2-3: OpenID 2.0 のプロトコルシーケンス 1 利用者は RP で OpenID を入力します 2 RP は OpenID から OP の位置を取得します 3 RP は OP にアソシエーション確立要求を送信します 4 OP は RP にアソシエーション確立応答を返します 5 RP は利用者のブラウザを OP にリダイレクトします 6 OP は RP の位置を取得します 7 利用者は OP でパスワードを入力し 認証を受けます 8 OP はブラウザリダイレクトを利用して 署名した認証結果と属性情報をアサーションとして RP へ送ります 9 RP はアサーションを検証します 10 RP は OP にアサーション検証要求を送信します 11 OP は RP にアサーション検証応答を返します 165

168 6.2.2 OpenID 2.0 仕様 (1) ディスカバリディスカバリとは RP が OpenID から OP を見つける処理です OpenID は OP が複数存在することが前提となっており 利用者を適切な OP に誘導することが必要となります この際の方法は HTML から取得する方法と Yadis プロトコルを利用して取得する方法があります Yadis プロトコルとは URL から XRDS 文書を見つける手順などを規定した OpenID とは別の仕様で決められているプロトコルです XRDS 文書とは OP のエンドポイント URL( ログインページ ) が記述された文書です (a) HTML から取得する方法 利用者が OpenID として入力した URL に存在する HTML 文書から OP のエンドポイント URL を取 得し 利用者を誘導します (b) Yadis プロトコルを利用して取得する方法利用者が OpenID として入力した URL から XRDS 文書の URL を入手して その XRDS 文書から OP のエンドポイント URL を取得し 利用者を誘導します ステップがひとつ増えますが HTML 中に URL を書くのではなく別の XML とすることで より柔軟な記述が可能となります 図 6.2-4: Yadis プロトコル : XRDS ベースのディスカバリの流れ 166

169 (2) アソシエーションの確立このプロセスは任意で RP と OP との間でアソシエーションを確立すると 共有秘密鍵が発行されます この共有秘密鍵は その後両者間で交換されるメッセージの検証に使用します RP がアソシエーションを形成できる場合は アソシエーションを形成することが推奨されます RP がアソシエーションを形成 保持できない場合は 認証アサーションの検証のために 後述する OP を通じた直接検証の仕組み ( ステートレスモード ) を用います アソシエーションの形式は 平文 HMAC-SHA1 HMAC-SHA256 の 3 つがあり HMAC-SHA1 HMAC-SHA256 の場合は共有秘密鍵を安全に送信するために Diffie-Hellman 鍵交換を用います (a) アソシエーションの確立要求 アソシエーションを確立するために はじめに RP から OP に直接通信でアソシエーションの確立要 求を送ります 要求は POST メッセージとして送られます (b) アソシエーションの確立応答 OP は RP にアソシエーションの確立応答を直接通信で返します 図 6.2-5: アソシエーションの確立 167

170 (3) 認証要求 RP は ディスカバリによって OP エンドポイント URL を取得し アソシエーションを構築すれば アサーションを得るために OP に認証要求を送ることができます 認証要求は 間接通信になります RPは 利用者のブラウザに認証要求パラメータをつけた OP エンドポイント URL( ログイン画面 ) を送信し リダイレクトさせます 図 6.2-6: 認証要求 168

171 認証要求パラメータを下表 ( 表 :6.2-1) に示します openid.ns 表 6.2-1: 認証要求パラメータ パラメータ値備考 openid.mode " et/auth/2.0" "checkid_immediate" または "checkid_setup" OpenID 2.0 として有効な要求であるためには この値が存在していなければならない 仕様の将来版においては メッセージ受信者が要求を適切に解釈できるように 異なる値が定義される場合もある RP が利用者と OP との対話を望む場合は "checkid_setup" を用いるべきである 利用者と OP との対話を望まない状況の例として JavaScript の中で非同期の認証要求が生じた場合があげられる openid.claimed_id Claimed Identifier "openid.claimed_id" と "openid.identity" について は 両方がともに存在するか ともに存在しないかの いずれかとする openid.identity OP ローカル識別子 openid.identity の値に異なる OP ローカル識別子 が指定されていない場合は その値として Claimed Identifier を用いなければならない openid.assoc_handle openid.return_to openid.realm RP と OP 間のアソシエーションハンドル OP が要求のステータスを示す応答とともにブラウザを戻すべき URL OP が利用者に信任を求めるべきであ URL のパターンデフォルト値 : return_to URL 応答に署名するために用いる このハンドルが送られない場合 アサーションの検証はステートレスモードで行われる 送られた要求の中にこの値が記されていない場合 利用者が戻されることを RP は望んでいないということを意味している openid.return_to を省略した場合は この値を送らなければならない (4) 証要求に対する応答認証要求に対する応答は 認証アサーションという形で RP へリダイレクトします 認証アサーションには肯定アサーションと否定アサーションがあります OP は 認可済みの正規の利用者が認証完了を望んでいる場合は RP に肯定アサーションを送ります 169

172 図 6.2-7: 認証要求に対する応答 (a) 肯定アサーション OP での認証に問題ない場合は 以下のパラメータを含む肯定アサーションを間接通信により送 信します openid.ns openid.mode 表 6.2-2: 肯定アサーションのパラメータ パラメータ値備考 " et/auth/2.0" "id_res" OpenID 2.0 として有効な要求であることを示す openid.op_endpoint URL OP エンドポイント URL openid.claimed_id Claimed Identifier "openid.claimed_id" と "openid.identity" につ いては 両方がともに存在するか ともに存 在しないかのいずれかとする openid.identity OP ローカル識別子 openid.return_to URL 要求時に送られた return_to URL パラメータ そのままコピーする openid.response_nonce 長さが 255 文字以下の文字列 この成功した特定の認証応答に固有のものでなければならず サーバの現在時刻で始まらなければならない 時刻はすべて世界協定時 ( UTC ) 時間帯とし "Z" で示す 小数点以下の秒の記述は認められていない 170

173 パラメータ値備考 openid.invalidate_handle openid.assoc_handle openid.signed アソシエーションハンドル アソシエーションハンドル 署名済みフィールドのコンマ区切りのリスト 要求とともに RP が無効なアソシエーションハンドルを送った場合 その値をここに含める このアサーションに署名するために用いられたアソシエーションのハンドル このエントリは 署名がカバーしているフィールドからなるが "openid." プリフィックスは省略する このリストは 少なくとも "op_endpoint" "return_to" "response_nonce" "assoc_handle" を含まなければならない また 応答に存在する場合は "claimed_id" と "identity" を含まなければならない openid.sig 署名 Base64 でエンコードされたデジタル署名 (b) 否定アサーション OP が利用者を識別できない場合 あるいは利用者が認証要求を承諾しない もしくは承諾できない場合 OP は RP に対して 以下のパラメータを含む否定アサーションを間接通信により送信します 表 6.2-3: 否定アサーションのパラメータ パラメータ値備考 openid.ns " openid.mode "setup_needed" or "cancel" RP が "checkid_immediate" の認証要求に対して "setup needed" 応答を受信した場合 "checked_setup" を用いて新たな認証要求を送信すべきである RP が "cancel" 応答を受信した場合 認証は失敗したことを意味し RP はその利用者が認証されなかったものとして 扱わなければならない (5) アサーションの検証 RP が肯定アサーションを受信した場合は そのアサーションを受け入れる前に 以下の値について検証します "openid.return_to" が現在の要求の URL と一致すること ディスカバリによって得られた情報がアサーションの情報と一致すること "openid.response_nonce" について 当該 OP から これまでに同じ値のアサーションを受け入れたことがないこと アサーションの署名が有効で 署名が必要なすべてのフィールドに署名がされていること 171

174 上記 4つの条件がすべて満たされていれば アサーションが検証されたことになります アサーションに Claimed Identifier が含まれている場合は その識別子について ユーザの認証が成功したことになります アサーションで指定されるアソシエーションハンドルに関連するアソシエーションを RP が保存している場合 RP は OP が署名を生成するのと同じ手順に従って署名を生成し 応答の中の署名と比較して検証します アソシエーションを保存していない場合 RP は OP を通じた直接検証を行う必要があります ( 次項で説明します ) 図 6.2-8: アサーションの検証 (6) OP を通じた直接検証 RP が OP に署名検証を行なわせたい場合は OP に直接要求を送ります OP は 署名検証 のために 肯定アサーション送信時に生成された専用のアソシエーションを用います 172

175 図 6.2-9: OP を通じた直接検証 (a) 要求パラメータ openid.mode 表 6.2-4: 検証要求パラメータ パラメータ値備考 "check_authentication" "openid.mode" を除く認証応答のすべてのフィールドをそのままコピー (b) 応答パラメータ ns 表 6.2-5: 検証応答パラメータ パラメータ値備考 " is_valid "true" または "false" 検証要求の署名が有効かどう かを示す 173

176 パラメータ値備考 invalidate_handle アソシエーションハンドル OP が無効であることを確認した場合に送る "true" に設定された "is_valid" を含む検証応答の中に このパラメータが存在する場合 RP は 保存しているアソシエーションの中から 対 応するものすべてを削除する 174

177 6.2.3 属性情報の交換 属性情報の交換については OpenID Attribute Exchange 1.0( 以下 AX とします ) にて定義され 主に OpenID の認証時に要求と応答の中に任意のパラメータを付与する仕組みを利用して 利用者の名前や住所などの属性情報を RP が扱うことが可能になります 同様の仕様に OpenID Simple Registration Extention( 以下 SREG とします ) というものがありますが SREG はあらかじめ定義された属性情報しか受け渡しができません それに対して AX では OP が拡張することによりあらゆる属性情報の受け渡しが可能です (1) 属性情報の取得 RP は OP から利用者の属性情報を取得するために OP にフェッチ要求を送信し OP が利用者の属性情報をフェッチ応答で返します 利用者は 属性情報を公開するかどうかを設定することができます 図 : 属性情報の取得 1 利用者は属性情報を公開するかどうかを RP に設定します 2 RP は属性情報を取得するために OP にフェッチ要求を送信します 3 OP は属性情報をフェッチ応答として返します (a) フェッチ要求 フェッチ要求のパラメータを下表 ( 表 6.2-6) に示します 表 6.2-6: フェッチ要求パラメータ パラメータ値備考 opened.ax.mode "fetch_request" opened.ax.type.<alias> URI このパラメータの値には送信された属性のタイプ 識別 URI が指定される <alias> は交換される 175

178 パラメータ値備考 opened.ax.required openid.ax.if_available 属性エイリアスまたはエイリアスのリスト 属性エイリアスまたはエイリアスのリスト 属性を識別するのに再度使用される 属性エイリアスか "openid.ax.type.<alias>" パラメータで定義された URI と紐付いたエイリアスのリスト 複数の属性のエイリアスはコンマ (",") で区切られる 属性エイリアスか "openid.ax.type.<alias>" パラメータで定義された URI と紐付いたエイリアスのリスト 複数の属性のエイリアスはコンマ (",") で区切られる openid.ax.count.<alias> 数値 RP が OP から受け取ることを希望している指定された属性エイリアス値の数 もし存在する場合は 値が 0 より大きい もしくは OP が持ちうるかぎりの属性の値を RP が要求していることを表す特別な値 "unlimited" でなければならない もし存在しない場合は 厳密にひとつの値が要求されているということである openid.ax.update_url URL この値が存在する場合 認証の肯定アサーションを使用して 初回の応答が送信された後に OP は指定された URL にフェッチ応答を再送信してもよい (b) フェッチ応答フェッチ応答はフェッチ要求で要求された属性情報を提供します 左辺として各属性は割り当てられた "openid.ax.value." で始まるエイリアス 右辺としてその属性値が提供されます 属性タイプもまた "openid.ax.type.<alias>" パラメータで返されます 属性エイリアスの長さは少なくとも 32 文字までサポートされていなければなりません 受け取ったデータの検証は RP 側で行う必要があります フェッチ応答のパラメータを下表 ( 表 6.2-7) に示します 表 6.2-7: フェッチ応答パラメータ パラメータ値備考 opened.ax.mode "fetch_response" opened.ax.type.<alias> URI このパラメータの値には送信された属性のタイプ 識別 URI が指定される <alias> は交換される 属性を識別するのに再度使用される opened.ax.count.<alias> 数値 <alias> で参照される属性値の個数 opened.ax.value.<alias> 属性の値 <alias> として表された属性の値が割り当てられる "openid.ax.count.<alias>" が送信されていない時は このパラメータ形式を使用しなければならない opened.ax.value.<alias>.< number> 属性の値 176 <alias> として表された属性の値が割り当てられる "openid.ax.count.<alias>" が送信され 少なくともひとつの値が該当する属性値として提供されている場合には このパラメータ形式を使用し

179 パラメータ値備考 なければならない openid.ax.update_url URL フェッチ要求で指定された "update_url" を返す OP が "update_url" パラメータを受け取り 属性更新機能をサポートする意思がある場合 OP はフェッチ応答の一部に update_url パラメータと値を返さなければならない (2) 属性情報の更新 RPは利用者の属性情報を OP に保存するために OPにストア要求を送信します 送信された属性情報は 他の RP にも同様に送信することができます 属性エイリアスは少なくとも 32 文字までサポートされていなければなりません 図 : 属性情報の更新 1 利用者は OP に保存する属性情報を RP に入力します 2 RP は属性情報を含むストア要求を OP に送信します 3 OP は RP に属性情報を保存した結果をストア応答として返します (a) ストア要求 ストア要求のパラメータを下表 ( 表 6.2-8) に示します 表 6.2-8: ストア要求パラメータ パラメータ値備考 opened.ax.mode "store_request" opened.ax.type.<alias> URI このパラメータの値には送信された属性のタイプ識 別 URI が指定される <alias> は交換される属性を 識別するのに再度使用される opened.ax.count.<alias> 数値 <alias> で参照される属性値の個数 177

180 パラメータ値備考 opened.ax.value.<alias> 属性の値 <alias> として表された属性の値が割り当てられる "openid.ax.count.<alias>" が送信されていない時は このパラメータ形式を使用しなければならない opened.ax.value.<alias>.< number> 属性の値 <alias> として表された属性の値が割り当てられる "openid.ax.count.<alias>" が送信され 少なくともひとつの値が該当する属性値として提供されている場合には このパラメータ形式を使用しなければならない (b) ストア応答 保存成功 属性情報の保存が成功した場合のストア応答パラメータを下表 ( 表 6.2-9) に示します 表 6.2-9: ストア応答 ( 成功 ) パラメータ パラメータ 値 備考 openid.ax.mode "store_response_success" 保存失敗 属性情報の保存が失敗した場合のストア応答パラメータを下表 ( 表 ) に示します 表 : ストア応答 ( 失敗 ) パラメータ パラメータ値備考 openid.ax.mode "store_response_failure" openid.ax.error 失敗原因 ユーザへの通知を想定した 失敗応答の 原因となるエラー条件を表すパラメータ 178

181 7 インターネット上の属性情報に基づくアクセス認可 7.1 概要 本章では 6 章で解説した異なるドメイン間の認証連携 ( シングルサインオン ) や属性情報交換を実現する SAML(Security Assertion Markup Language) の仕様に基づいて アクセス認可を行う仕組みについて解説します 加えて SAML を利用して きめ細かなアクセス制御を行うための記述言語である XACML(eXtensible Access Control Markup Language) について ユースケースを交えてその仕様を解説します 7.2 SAML によるアクセス認可 SAML の第一の目的は 柔軟でかつ PKI を導入することによる強力なセキュリティを確保したシングルサイオンオン (SSO) 環境の実現にあります 一方 利用者がアクセスする Web サービスでは 認証後に利用者の権限 資格などの属性に応じて要求したリソースへのアクセスを制御するいわゆる認可サービスが必要となります SAML では 認証情報の伝達 ( 認証アサーション ) に加えて 認可サービスで使用される属性情報の伝達 ( 属性アサーション ) と認可決定情報の伝達 ( 認可決定アサーション ) が行えます Web ユーザが Web サイトのリソースにアクセスする際のアクセス認可のモデルは 基本的に 2 つ のステップを必要とします 1 Web ユーザは Web サイトのリソースに対するアクセスを要求します 2 アクセス制御を実行する Web サイト上のアプリケーション ( ポリシー実行点 ) は認可決定オーソリティに問合せ Web ユーザのアクセス権限をチェックし リソースへのアクセス認可を実行します このモデルは 下図 ( 図 7.2-1) に示すような手順で ひとつのセキュリティゾーン内でのアクセス認可を実行します Web ユーザは セキュリティシステムで認証した後に Web サーバへ動的なリソースを要求します Web サーバは アプリケーションが Web ユーザの認可の権限をチェックができるように認証情報を提供します セキュリティシステムは ユーザのクレデンシャルを収集し SAML オーソリティ ( 認証オーソリティ 属性オーソリティ 認可オーソリティ ) として機能します アプリケーションはポリシー実行点としての機能を持ちます 179

182 図 7.2-1: アクセス認可の手順 SAML では 認証アサーションとともに 属性および認可決定に関するアサーションをエンティティ が指定したリソースにアクセスを要求したときにやり取りし その要求が許可されたか拒否された かの結果を返します 認可決定に関するアサーションは <AuthzDecisionStatement> というエレメント ( 要素 Elements) に エンティティが 指定したリソース に アクセスしたい という リクエストの結果 および必要に応じて 指定されていた何らかの証拠に基づいて指定の権限付与の決定が行われたこと を確認する情報を定義します 下図 ( 図 7.2-2) では <AuthzDecisionStatement> エレメントの定義文 ( スキーマ ) を表しています 図 7.2-2: <AuthzDecisionStatement> エレメントの定義文 ( スキーマ ) 180

183 上記スキーマの StatementAbstractType で指定した追加エレメントと属性について 以下に解説し ます Resource [ 必須 ] アクセス権限が求められているリソースを識別する URI 参照です この属性の値は 空白の URI 参照も許容されています ( 空白の URI 参照の場合は 現在の文書の始まり を表します ) Decision [ 必須 ] アクセス要求を行った指定のリソースに対して その要求が許可されたか拒否されたかの結果を DecisionType で指定した値で返します <Action> [1 個以上 ] 指定されたリソースで実行する権限があるアクションの集合です <Evidence> [ オプション ] 認可決定の根拠となったアサーションの集合です アクセス要求を行った指定のリソースに対して その要求が許可されたか拒否されたかの結果に ついての値を定義する DecisionType の定義文 ( スキーマ ) を下図 ( 図 7.2 3) に示します 図 7.2-3: DecisionType の定義文 ( スキーマ ) 上記スキーマの DecisionType で定義された値について以下に解説します Permit 指定されたアクションは 許可されました Deny 指定されたアクションは 拒否されました Indeterminate 指定されたアクションを許可すべきか拒否すべきか決定できません アクセス要求を行った指定のリソースに対して 許可が求められているアクションを <Action> エレメ 181

184 ントで指定します このエレメントの文字列データの内容は その指定リソースでの実行許可が求 められているアクションのラベルになります <Action> エレメントの定義文 ( スキーマ ) を下図 ( 図 7.2-4) に示します 図 7.2-4: <Action> エレメントの定義文 ( スキーマ ) 上記 <Action> エレメントで指定したアクションについて以下に解説します Namespace [ オプション ] URI 参照で 指定されたアクションの名前を解釈するネームスペースを表します このエレメントが省略されていれば 次のネームスペースが有効になります Read Write Execute Delete Control ~Read ~Write ~Execute ~Delete ~Control これらのアクションは 以下のように解釈されます Read リソースを読むことができます Write リソースを変更することができます Execute リソースを実行することができます Delete リソースを削除することができます Control リソースのアクセス制御ポリシーを指定することができます 頭に波形符号 (~) が付いたアクションは否定された許可です アクセス要求を行った指定のリソースに対して 権限付与の決定の根拠となるひとつ以上のア サーション ( アサーションへの参照を含む ) を定義する <Evidence> エレメントの定義文 ( スキーマ ) を 下図 ( 図 7.2-5) に示します 182

185 図 7.2-5: <Evidence> エレメントの定義文 ( スキーマ ) 上記 <Evidence> エレメントで指定したアサーションについて以下に解説します <AssertionIDRef> [ 任意の数値 ] アサーションの ID 属性の値を示すことで そのアサーションを指定します <AssertionURIRef> [ 任意の数値 ] URI 参照を利用して アサーションを指定します <Assertion> [ 任意の数値 ] 値によってアサーションを指定します <EncryptedAssertion> [ 任意の数値 ] 値によって 暗号化されたアサーションを指定します なお <AuthzDecisionStatement> 機能は SAML 2.0 で仕様凍結されており 将来の改善計画もありません 代わって XML 文書にエレメント単位のアクセスポリシーを定義する XACML(eXtensible Access Control Markup Language) が OASIS によって標準化され より柔軟で高度なアクセス制御ポリシーの設定が可能になっています 次節で XACML によるアクセス認可について解説します 183

186 7.3 XACML によるアクセス認可 SAML では 認証 / 属性 / 認可決定アサーションと それらを送受信する方法 ( プロトコル ) に焦点が絞られていましたが XACML では SAML の仕様では触れられていない認可の内部処理 (SAML におけるポリシー実行点での処理 ) に関して規定されています この処理は OS やプラットフォームなどの実装に依存しやすいため 実装に依存しない標準が存在しませんでした XACML は 実装に依存しない仕様を定めた標準です XACML は SAML のフレームワークの上で 特に認可決定オーソリティに対して 認可決定を判断させるためのポリシーおよびルールの仕様を定め 併せて認可決定オーソリティに対する認可要求やその応答のプロトコルを定めたものです 認可決定オーソリティは この柔軟なポリシーと認可要求の適合性を判断し エンティティ ( アクセス要求者 ) のリソースへのアクセスの許可 拒否を決定します XACML が提供する機能は大きく分けて 2 つありますが アプローチとしては SAML とよく似ていま す アクセス制御ルールの記述に関する部分 ( ポリシー言語 ) と 認可処理要求とその結果のやり とりに関する部分 ( コンテキスト ) です 184

187 下図 ( 図 7.3-1) に XACML のデータフローを示します 図 7.3-1: XACML のデータフロー モデル 1 ポリシー管理点 (PAP) はポリシーとポリシー セットを作成して ポリシー決定点 (PDP) に渡します 2 アクセス要求者がアクセス要求をポリシー実行点 (PEP) に送信します 3 PEP はアクセス要求をコンテキストハンドラに標準の応答フォーマットに基づいて渡します その際 必要に応じて主体 (Subject) の属性 リソース アクション 環境 その他の属性を含めます 4 コンテキストハンドラは XACML 要求コンテキストを生成し PDP に送信します 5 PDP は 主体 リソース アクション 環境 その他の属性をコンテキストハンドラに照会します 6 コンテキストハンドラはポリシー情報取得点 (PIP) から属性を要求します 7 PIP は要求した属性を取得します 185

188 8 PIP はコンテキストハンドラに属性を返します 9 必要に応じて コンテキストハンドラはコンテキストにリソースを埋め込みます 10 コンテキストハンドラは要求された属性および ( 必要に応じて ) リソースを PDP に送ります PDP はポリシーを評価します 11 PDP は応答コンテキスト ( 権限付与の決定を含む ) をコンテキストハンドラに返します 12 コンテキストハンドラは応答コンテキストを PEP の標準応答フォーマットに形式変換し PEP に応答します 13 PEP は責務を実行します 14 アクセスが許可されれば PEP はリソースへのアクセスを許可し そうでなければアクセスを拒否します XACML の特徴は 20 才以上の利用者 とか 利用者登録している者のみ など 複雑な条件判 断によるアクセス制御ができるということです PDP とコンテキストハンドラの間でやり取りされる正規化された要求 / 応答メッセージを XACML コンテキスト と呼びます 図 7.3-2: XACML コンテキスト PDP は コンテキストハンドラから送られた要求コンテキストを あらかじめ登録されたポリシーと 比較し 許可 / 不許可を示す応答コンテキストをコンテキストハンドラに送信します XACML コンテキストは SAML におけるプロトコルと同じものです つまり XACML 処理系への認可要求とそれに対する結果は XACML コンテキストの形で送受信されます XACML コンテキストは 要求と結果の形式のみを定めているため 任意の実装にマッピング可能です 例えば PDP と PEP の間のやりとりを SAML で実装する場合 XSLT などを使って XACML コンテキストと SAML 認可プロトコルの間の変換を行えばよいことになります 186

189 [ アクセス制御ルール ] 使用されるポリシー言語モデルの主な構成要素は ルール ポリシー ポリシー セットです ルールは ポリシーの最も基本的な単位で 対象 結果 条件で構成されます PDP は 対象のルールが条件に適合しているかを評価し 許可 / 不許可の結果を決定します ポリシーは PAP によってはまとめられた複数のルールのことで ポリシー セットは複数のポリシーをまとめたものです 図 7.3-3: ポリシー言語モデル XACML 仕様の大部分を占めているのは ポリシー言語の定義の部分です 非常にきめ細かなア クセス制御ルールを記述できるように設計されており 以下のような要素が定義されています 187

190 図 7.3-4: XACML ポリシー言語モデル Rule 認可に関する規則です 対象 (Target) とそれに対する認可の結果 (Effect) を含みます オプションとして条件 (Condition) を付けることができます XACML におけるアクセス制御の最小単位です Target 認可を行う対象です 誰が ( 対象エンティティ :Subject) 何に対して ( リソース :Resource) 何 を行うことができるか ( 動作 :Action) からなります Subject 認可対象となるエンティティの属性を記述します Resource 認可対象となるリソースの属性を記述します 188

191 Action 認可対象となる動作の属性を記述します Effect 規則の結果です 許可 (Permit) または拒否 (Deny) で記述されます Condition 対象に関する属性以外の条件を記述します Policy 複数の規則をまとめたものです PAP が規則結合アルゴリズム (RuleCombiningAlgorithm) に 従って生成します オプションとして責務 (Obligation) を付けることができます RuleCombiningAlgorithm 複数の規則をまとめるための方法です Deny-overrides Permit-overrides First-applicable の 3 つから選択できます Obligation PEP がポリシー実行時に併せて実行すべき責務です PolicySet 複数のポリシーをまとめたものです PAP がポリシー結合アルゴリズム (PolicyCombiningAlgorithm) に基づいて生成します オプションとして責務 (Obligation) を付けることができます PolicyCombiningAlgorithm 複数のポリシーをまとめるための方法です 規則結合アルゴリズムと同じ 3 つのアルゴリズム から選択できます XACML の認可決定は 主に認可要求で受け取ったコンテキストに含まれる対象と PAP で生成されたポリシーに含まれる対象の属性を比較評価することで行われます 従ってポリシー言語で記述される対象の各要素 ( 主体 資源 動作 ) の属性には コンテキストに含まれる対象の属性とどういう比較評価を行うかを詳しく記述することになります XACML では 文字列関数 算術関数 論理関数 集合関数など この記述に用いることができる多くの評価関数を用意しています XACML ポリシーの記述例を以下に紹介します 下図 ( 図 7.3-5) は "example.co.jp" というドメイ 189

192 ン名からなる 属性値を持つすべての利用者は どのリソースに対しても動作を実行できる ことを表現しています 図 7.3-5: XACML ポリシーの記述例 190

193 8 インターネット上の代理アクセス 7.1 概要 分散 Web サービスやクラウド コンピューティングの利用が進み サードパーティアプリケーションがサーバ上にあるリソースにアクセスする機会が増えてきました インターネット上のサーバにリソースを持つエンティティは これらのリソースをクレデンシャル ( 例えば ユーザ名とパスワード ) により保護しており リソースにアクセスするためには認証が必要となります 従来のクライアントサーバ型の認証モデルでは エンティティはクレデンシャルを使ってサーバに対して認証を行い サーバ上の保護リソースにアクセスしなければなりません しかしながら このモデルでは サードパーティアプリケーションに保護リソースへのアクセス権を与えるには エンティティは自身のクレデンシャルをサードパーティアプリケーションと共有する必要があり これはいくつかの問題と制限をもたらします エンティティは 秘密のクレデンシャルをサードパーティアプリケーションに委ねることになり 自ら管理することができなくなります 例えば クレデンシャルとしてパスワードを利用している場合 サードパーティアプリケーションが パスワードを平文で保存してしまう危険性があります サードパーティアプリケーションは保護リソースに対してすべてのアクセス権を得ることになります エンティティは サードパーティアプリケーションからのアクセスをリソースのサブセットに限定したり アクセス可能な期間を制限したり リソースに対して一部の操作のみを許可するといったことができません エンティティが複数のサードパーティアプリケーションに保護リソースへのアクセスを許可している場合 同じクレデンシャルを委ねているため サードパーティアプリケーション毎にアクセス権を無効化する ( 例えば パスワードを変更する ) ことはできず アクセス権を無効化する際にはすべてのサードパーティが持つアクセス権を無効化しなければなりません これらの問題を解決するために OAuth 2.0 という標準仕様が策定され RFC 6749 として発行されました OAuth 2.0 は リソースへアクセスするためのクレデンシャルを保持している本来のエンティティ ( リソースオーナ ) と リソースへ実際にアクセスするエンティティ ( クライアント ) の役割を分け リソースオーナはクライアントに秘密のクレデンシャル ( 例えば パスワード ) を渡すことなく クライアントがリソースにアクセスすることを可能にしています クライアントは Web サーバ上のアプリケーションや Web ブラウザなど リソースへアクセスするサードパーティアプリケーションです OAuth 2.0 では クライアントはリソースオーナのコントロール下にあり リソースオーナの代理とし て リソースサーバに存在するリソースへのアクセス権を要求します そして リソースオーナが持 191

194 つ本来のクレデンシャルとは別のクレデンシャル ( アクセストークン ) を取得します アクセストークンとは ある特定の範囲や期間などにアクセス権限を限定したクレデンシャルです アクセストークンは 認証サーバがリソースオーナの同意に基づき クライアントに対して発行するものであり クライアントはリソースサーバ上の保護リソースにアクセスするために アクセストークンを利用します 例えば ある利用者 ( リソースオーナ ) が 印刷サービス ( クライアント ) に対して 写真共有サービス上 ( リソースサーバ ) に保管されている自分の写真へのアクセス権を与えるとします その際 OAuth 2.0 では 利用者のユーザ名とパスワードを印刷サービスに与える必要はありません その代わりに 利用者は写真共有サービスの信任を得た認可サーバに対して認証を行い 認可サーバが印刷サービスに専用のアクセストークンを発行します 図 7.1-1: OAuth 2.0 の認証 / 認可概要 以上のように OAuth 2.0 はリソースオーナの代わりに保護リソースにアクセスする方法をクライア ントに提供します (1) プロトコル概要クライアントは 保護リソースにアクセスする前に リソースオーナの認可を得て アクセストークン ( 権限の範囲 期間 他の属性を示している ) を取得しなければなりません クライアントは リソースサーバにアクセストークンを渡すことにより 保護リソースにアクセスすることが可能になります 192

195 (2) 構成要素構成要素保護リソースリソースサーバリソースオーナ認可サーバクライアントアクセストークン認可グラント 表 7.1-1: OAuth 2.0 構成要素 説明 アクセスが制限されたリソース OAuth 2.0 認証済みリクエストを利用して取得が可能である 保護リソースに対するリクエストを受付け レスポンスを返すサーバ 保護リソースへのアクセスを許可するエンティティ リソースオーナの認証とリソースオーナからの認可取得が成功した後 アクセストークンをクライアントに発行するサーバ 認可を取得して 保護リソースに対するリクエストを行うアプリケーション クライアントがリソースオーナに変わって認証済みリクエストを行うために使われるトークン リソースオーナからの保護されたリソースへのアクセスを行うことに対する認可を示し クライアントがアクセストークンを取得する際に用いられる (3) 基本プロトコルフロー OAuth 2.0 の基本的なプロトコルフローの概要を下図 ( 図 8.1-2) に記載します 詳細は認可グラン トタイプごとに異なりますので 8.2 節で解説します 図 7.1-2: OAuth 2.0 プロトコルフローの概念図 1 クライアントは リソースオーナからの認可を要求します その際の認可リクエストは リソースオーナへ直接送るか または間接的に認可サーバを経由して送信します 2 クライアントは リソースオーナの認可を表すクレデンシャルとして認可グラントを受け取ります 認可グラントは 仕様上定義された 4 つのグラントタイプの内のひとつ または拡張されたグラントタイプで発行されます どの認可グラントタイプを用いるかは クライアントの利用する認可リクエストの方式と認可サーバがサポートするグラントタイプに依存します 3 クライアントは 認可サーバに対して自身を認証し 認可グラントを提示することで アクセストークンを要求します 193

196 4 認可サーバは クライアント認証と認可グラントの正当性を確認し 正当であればアクセストークンを発行します 5 クライアントは リソースサーバの保護されたリソースへのアクセスを要求し 発行されたアクセストークンにより認証を行います 6 リソースサーバは アクセストークンの正当性を確認し 正当であればリクエストを受け入れ 保護されたリソースへアクセスを許可します (4) 認可グラント 認可コード インプリシット リソースオーナパスワードクレデンシャル クライアントクレデンシャル の 4 つのグラントタイプが定義されており 拡張仕様によってタイプを追加することもできる 認可コード認可コードは 認可サーバがクライアントとリソースオーナの仲介者となって発行します リソースオーナへ直接認可を要求する代わりに クライアントはリソースオーナを認可サーバへリダイレクトさせ リソースオーナがリダイレクトして戻ってきた際に認可コードを取得します リソースオーナを認可コードとともにリダイレクト経由でクライアントに戻す前に 認可サーバはリソースオーナを認証し認可を得ます これによりリソースオーナは 認可サーバによってのみ認証され リソースオーナのクレデンシャルはクライアントへ共有されません 認可コードは クライアントを認証する機会を提供したり リソースオーナのユーザエージェントを経由せずにアクセストークンをクライアントに直接伝搬できる ( リソースオーナを含む第三者にアクセストークンを露出しない ) など いくつかの点で重要なセキュリティ的なメリットを提供します インプリシットインプリシット ( 黙示的 ) グラントは JavaScript の様なスクリプト言語を使用して ブラウザで実行されるクライアントに最適化され 認可コードフローを単純化したもので クライアントは認可コードの代わりに直接アクセストークンを受け取ります このグラントタイプは 認可コードのような 後にアクセストークンを取得する際に用いられる仲介のクレデンシャルを利用しないため インプリシット (implicit = 暗黙の ) と呼ばれます インプリシットグラントは 認可サーバでクライアントを認証せず アクセストークンを得るのに必要な往復の回数も減らせるため 効率性や利便性を高めますが リソースオーナ ( もしくはリソースオーナのユーザエージェント ) にアクセスすることでアクセストークンが他のアプリケーションに晒されるなどセキュリティ面の影響とトレードオフの関係にあることを考慮すべきです リソースオーナパスワードクレデンシャル リソースオーナパスワードクレデンシャル ( 例 : ユーザ名とパスワード ) を 直接アクセストーク ンを得るための認可グラントとして使用することができます ただし この方法は リソース 194

197 オーナとクライアント ( 例えば デバイス OS や非常に特権のあるアプリケーション ) の間で高い信頼があり 認可コードのような他の認可グラントタイプが利用できない場合のみ使用されるべきです このグラントタイプでは クライアントがリソースオーナのクレデンシャルへ直接アクセスすることになりますが リソースオーナのクレデンシャルは 1 回のリクエストにのみ使用され アクセストークンに交換されます また クレデンシャルを寿命の長いアクセストークンや後述するリフレッシュトークンと交換することにより クライアントがリソースオーナのクレデンシャルを将来的に使用する目的で格納しておく必要がなくなります クライアントクレデンシャル認可範囲がクライアントの管理下の保護されたリソースもしくはあらかじめ認可サーバとの間で調整済の保護されたリソースに制限されている場合は 認可グラントとしてクライアントクレデンシャル ( もしくは他のクライアント認証形式 ) が使用できます クライアントが クライアント自身のために行動している ( またはクライアントがリソースオーナである ) か クライアントがあらかじめ認可サーバとの間で調整済の保護されたリソースアクセスを求めている場合 クライアントクレデンシャルが認可グラントとして使用されます (5) リフレッシュトークンリフレッシュトークンは アクセストークンを取得するために使用されるクレデンシャルです リフレッシュトークンは 認可サーバによってクライアントに対して発行され 現在のアクセストークンが無効化されたあるいは期限切れの際に新しいアクセストークンを取得するため または同一あるいは狭い範囲で追加のアクセストークンを取得するために利用されます その際のアクセストークンは リソースオーナによって認可されるよりも有効期限は短く 権限が少なくてもかまいません リフレッシュトークンの発行はオプションです 認可サーバがリフレッシュトークンを発行する場合 アクセストークン発行の際にリフレッシュトークンも含まれます アクセストークンとは異なり リフレッシュトークンは認可サーバでのみ使用されるものであり リソースサーバに送信されることはありません 195

198 図 7.1-3: 期限切れのアクセストークンのリフレッシュ 1 クライアントは 認可サーバで認証して認可グラントを提示することによって アクセストークンの要求をします 2 認可サーバは クライアントを認証して認可グラントを確認し 有効である場合はアクセストークンとリフレッシュトークンを発行します 3 クライアントは アクセストークンを提示して リソースサーバ上の保護されたリソースに対してリクエストを行います 4 リソースサーバは アクセストークンの正当性を確認し 有効な場合はリクエストを処理します 5 ステップ3と4はアクセストークンの有効期限が切れるまで繰り返されます クライアントがアクセストークンの期限切れを検知した場合 ステップ7にスキップし そうでなければ保護されたリソースへのリクエストを続けます 6 アクセストークンが有効でないとき ソースサーバはエラーを返し トークンが無効なことを伝えます 7 クライアントは 認可サーバで認証してリフレッシュトークンを提示することによって 新しいアクセストークンを要求します クライアント認証の必要条件は クライアントタイプと認可のポリシーに基づきます 8 認可サーバは クライアントを認証してリフレッシュトークンの正当性を確認し 正当であれば新しいアクセストークンと必要に応じてリフレッシュトークンを発行します 196

199 7.2 OAuth 2.0 仕様 (1) クライアント登録と認証 OAuth 2.0 プロトコルを開始する前に クライアントを認可サーバに登録しなければなりません ク ライアントを認可サーバに登録する方法はこの仕様の範囲外ですが 通常リソースオーナである 利用者との対話形式の HTML 登録フォームを使って登録するのが一般的です クライアントを登録する際には クライアントタイプの指定とリダイレクトエンドポイント ( リダイレクト先 URI) を提供し 認可サーバが要求するその他の情報 ( 例えば アプリケーション名 Web サイト 説明 ロゴイメージ 利用規則など ) を提供します 登録が完了すると 認可サーバは 登録済みのクライアントにクライアント識別子 ( クライアントが提供した登録情報を表すユニーク文字列 ) など 認可サーバでのクライアントの認証に使われるクライアントクレデンシャルを発行します クライアント識別子はリソースオーナに露出されるため その情報のみでクライアント認証を行ってはなりません [ クライアントタイプ ] OAuth 2.0 は 2 つのクライアントタイプを定義しています これらの定義はクライアントプロファイル と呼ばれるクライアントの定義に基づいて決められています クライアントプロファイル Web アプリケーション ユーザエージェントベースアプリケーション ネイティブアプリケーション 説明 Web アプリケーションは Web サーバ上で実行されているコンフィデンシャルクライアントである リソースオーナは リソースオーナのデバイス上のユーザエージェントにレンダリングされた HTML ユーザインターフェイスを通してクライアントにアクセスする クライアントに発行されたアクセストークンと同様にクライアントクレデンシャルは Web サーバ上に保存され リソースオーナによって公開されたり アクセス可能な状態にならない ユーザエージェントベースアプリケーションは クライアントコードが Web サーバからダウンロードされリソースオーナのデバイス上のユーザエージェント ( 例えば Web ブラウザ ) 内で実行されるパブリッククライアントである プロトコルのデータとクレデンシャルはリソースオーナに簡単にアクセス ( かつ多くの場合は見ること ) できる このようなアプリケーションはユーザエージェント内にあるので 認可を要求する時ユーザエージェントの能力をシームレスに使用することができる ネイティブアプリケーションは リソースオーナのデバイス上にインストールされ 実行されるパブリッククライアントである リソースオーナはプロトコルのデータとクレデンシャルにアクセス可能である アプリケーションに含まれるいかなるクライアント認証用のクレデンシャルも 抽出可能であると想定される 一方 アクセストークンやリフレッシュトークンといった動的に発行されたクレデンシャルは許容できるレベルの保護 197

200 が得られる 少なくとも これらのクレデンシャルはアプリケーションと対話できる悪意のあるサーバから保護されている プラットフォームによっては これらのクレデンシャルは同じデバイス上に存在する他のアプリケーションからも保護されているであろう クライアントタイプ コンフィデンシャル パブリック 表 7.2-1: OAuth 2.0 クライアントタイプ 説明 クライアントクレデンシャルの機密性を維持することができるクライアント ( 例えば クライアントクレデンシャルへのアクセスが制限されたセキュアサーバ上に実装されたクライアント ) または他の手段を使用したセキュアなクライアント認証ができるクライアント クライアントクレデンシャルの機密性を維持することができず ( 例えば インストールされたネイティブアプリケーションや Web ブラウザベースのアプリケーションのようにリソースオーナのデバイス上で実行するクライアント ) かつ他の手段を使用したセキュアなクライアント認証もできないクライアント クライアントプロファイル Web アプリケーション ユーザエージェントベースアプリケーション ネイティブアプリケーション 表 7.2-2: OAuth 2.0 クライアントプロファイル 説明 Web アプリケーションは Web サーバ上で実行されているコンフィデンシャルクライアントである リソースオーナは リソースオーナのデバイス上のユーザエージェントにレンダリングされた HTML ユーザインターフェイスを通してクライアントにアクセスする クライアントに発行されたアクセストークンと同様にクライアントクレデンシャルは Web サーバ上に保存され リソースオーナによって公開されたり アクセス可能な状態にならない ユーザエージェントベースアプリケーションは クライアントコードが Web サーバからダウンロードされリソースオーナのデバイス上のユーザエージェント ( 例えば Web ブラウザ ) 内で実行されるパブリッククライアントである プロトコルのデータとクレデンシャルはリソースオーナに簡単にアクセス ( かつ多くの場合は見ること ) できる このようなアプリケーションはユーザエージェント内にあるので 認可を要求する時ユーザエージェントの能力をシームレスに使用することができる ネイティブアプリケーションは リソースオーナのデバイス上にインストールされ 実行されるパブリッククライアントである リソースオーナはプロトコルのデータとクレデンシャルにアクセス可能である アプリケーションに含まれるいかなるクライアント認証用のクレデンシャルも 抽出可能であると想定される 一方 アクセストークンやリフレッシュトークンといった動的に発行されたクレデンシャルは許容できるレベルの保護が得られる 少なくとも これらのクレデンシャルはアプリケーションと対話できる悪意のあるサーバから保護されている プラットフォームによっては これらのクレデンシャルは同じデバイス上に存在する他のアプリケーションからも保護されているであろう [ クライアントの認証 ] クライアントタイプがコンフィデンシャルである場合 クライアントと認可サーバは 認可サーバのセ 198

201 キュリティ要求を満たす認証方式を確立します 認可サーバは 自身のセキュリティ要求さえ満たせば どのような方式のクライアント認証に対応しても問題ありません コンフィデンシャルクライアントには 通常は認可サーバでの認証に使われるクライアントクレデンシャル ( 例えば パスワードや公開鍵 / 秘密鍵のペア ) が発行されます 認可サーバは パブリッククライアントとクライアント認証を行っても問題ありませんが 認可サーバは クライアントを識別する目的でパブリッククライアントを信頼してはなりません クライアントは 1 回のリクエストにおいて 2 つ以上の認証方式を利用してはなりません (a) クライアントパスワードクライアントパスワードを保持しているクライアントは 認可サーバ上での認証に HTTP ベーシック認証スキームを使用してもよいことになっています この場合 クライアント識別子がユーザ名 クライアントパスワードがパスワードとして利用されます 認可サーバは以下のパラメータを用いて リクエストにクライアントクレデンシャルを含めてもよいことになっています ただし これは HTTP ベーシック認証スキーム ( もしくは他のパスワードベースの HTTP 認証スキーム ) が直接利用できないクライアントに限定すべきです 表 7.2-3: クライアントクレデンシャル用パラメータ 必須任意 説明 client_id 必須 クライアント登録時に発行されたクライアント識別子 client_secret 必須 クライアントのシークレット 空の場合は省略してもよい (b) そのほかの認証方式認可サーバは セキュリティ要件に適合する適切な HTTP 認証スキームをサポートすべきで 他の認証方式を利用する際には 認可サーバは登録されたクライアントと認証スキームのマッピングを明確にしなければなりません (2) 各種エンドポイント 認可プロセスは 2 つのエンドポイント (HTTP リソース ) を利用します エンドポイント 認可エンドポイント 表 7.2-4: エンドポイント 説明 認可サーバの HTTP エンドポイントで ユーザエージェント経由でリソースオーナから認可を得るために利用される リソースオーナとのやりとりが完了した後 認可サーバはリソースオーナのユーザエージェントをクライアントへ誘導する 認可サーバはユーザエージェントをクライアント登録プロセス中 もしくは認可リクエスト時に認可サーバに事前に確立されたクライアントのリダイレクトエンドポイントへリダイレクトする 199

202 エンドポイント トークンエンドポイント 説明 認可サーバの HTTP エンドポイントで 認可グラントもしくはリフレッシュトークンを提示することで クライアントがアクセストークンを取得するために利用される トークンエンドポイントは インプリシットグラントタイプを除くすべてのグラントタイプで利用される コンフィデンシャルクライアントは トークンエンドポイントへのリクエスト時に 認可サーバとの間で認証を行わなければならない (3) 認可の取得とフロー認可グラントは リソースオーナの認可 ( 保護されたリソースへのアクセスを行うことに対する認可 ) を示し クライアントがアクセストークンを取得する際に用いられます 認可グラントでは 認可コード インプリシット リソースオーナパスワードクレデンシャル クライアントクレデンシャルの 4 つのグラントタイプを定義しており 拡張仕様によってタイプを追加することもできます これら 4 つのグラントタイプごとに アクセストークン取得までのフローが用意されています [ 認可コード ] 認可コードは 認可サーバがクライアントとリソースオーナの仲介者となって発行します 認可コードは アクセストークンとリフレッシュトークンの両方を取得するために用いられ コンフィデンシャルクライアントに最適化されています 認可コードでは リダイレクトベースのフローが利用されるため クライアントはリソースオーナのユーザエージェント ( 通常は Web ブラウザ ) と対話し 認可サーバによるリダイレクトを通したリクエストを受け付けることができなくてはなりません 図 7.2-1: 認可コード処理フロー 200

203 1 クライアントがリソースオーナのユーザエージェントを認可エンドポイントに送ることで フローが開始します このときクライアントは クライアント識別子 アクセス範囲 ローカルステート および認可サーバがアクセス許可取得後にユーザエージェントを戻すリダイレクト URI をリクエストに含めます 2 認可サーバは ユーザエージェントを通してリソースオーナを認証し リソースオーナにアクセス要求の許可 / 拒否を尋ねます 3 リソースオーナがアクセスを許可した場合 認可サーバは リクエストもしくはクライアント登録時に指定されるリダイレクト URI を用いて ユーザエージェントをリダイレクトさせてクライアントに戻します リダイレクト URI には 認可コード クライアントから事前に送られたローカルステートが含まれます 4 クライアントは 前のステップで取得した認可コードを認可サーバのトークンエンドポイントに送ることでアクセストークンを要求します このとき クライアントは認可サーバとの間で認証を行います またクライアントは認可コード取得時に使用したリダイレクト URI を検証のためリクエストに含めます 5 認可サーバは クライアントを認証し 認可コードを検証し 受け取ったリダイレクト URI がステップ 3で使用した URI と同一であることを確かめます その結果 正当である場合 認可サーバはアクセストークンと任意でリフレッシュトークンを返却します (a) 認可リクエスト クライアントは 認可リクエストに以下のパラメータを付与します 表 7.2-5: 認可リクエストのパラメータ パラメータ必須任意備考 response_type 必須レスポンスタイプ 値は必ず code にしなければならない Client_id 必須 クライアント識別子 認可サーバがクライアントに発行した識別子 ( ク ライアントが事前に提供した登録情報を表すユニーク文字列 ) Redirect_uri 任意 リダイレクト URI リソースオーナとのやりとりが完了した後 認可サー バがリソースオーナのユーザエージェントをクライアントへ誘導する際 の URI Scope 任意アクセス範囲 認可サーバによって定義されているアクセス範囲 State 任意 ローカルステート リクエストとコールバックの間で状態を維持するた めに使用するランダムな値 認可サーバはリダイレクトによってクライ アントに処理を戻す際にこの値を付与する 認可サーバは 必要なリクエストパラメータがすべて揃っていて かつ正当であることを検証しま す リクエストが正当であれば 認可サーバはリソースオーナを認証し リソースオーナに確認す ることによって ( または他の手段によって承認を確立することによって ) 認可の判定を得ます 201

204 判定が成立すると 認可サーバは HTTP リダイレクトレスポンスまたはユーザエージェントを介した その他の利用可能な手段を用いて 与えられたリダイレクト URI にユーザエージェントを送ります (b) 認可レスポンス リソースオーナがアクセス要求を許可した場合 認可サーバは認可コードを発行し 認可レスポン スに以下のパラメータを付与してクライアントに送ります 表 7.2-6: 認可レスポンスのパラメータ パラメータ必須任意説明 code 必須 認可コード 認可サーバによって許可され クライアント識別子とリダイレクト URI に関連付けられる 漏洩のリスクを軽減するため 認可コードは発行されてから短期間で無効にしなければならない クライアントは 2 回以上認可コードを使用してはならず もし認可コードが 2 回以上使用された場合は 認可サーバはリクエストを拒否し この認可コードを基に発行されたこれまでのすべてのトークンを無効化すべきである State 任意 ローカルステート クライアントからの認可リクエストに state パラメータが 含まれていた場合は必須 クライアントから受け取った値をそのまま返 す (c) エラーレスポンスリクエストが リダイレクト URI の欠落 / 不正 / ミスマッチによって失敗した場合 もしくはクライアント識別子が不正な場合は 認可サーバはリソースオーナにエラーを通知する必要があります 不正なリダイレクト URI に対してユーザエージェントを自動的にリダイレクトさせてはなりません リソースオーナがアクセス要求を拒否した場合 もしくはリダイレクト URI の欠落 / 不正以外でリクエストが失敗した場合は 認可サーバは以下のようなパラメータを付与してクライアントに返却します 表 7.2-7: エラーレスポンスパラメータ パラメータ必須任意値説明 error 必須 invalid_request リクエストに必要なパラメータが含まれていない サポート外のパラメータが付与されていた場合や その他不正な形式であった場合もこれに含まれる Unauthorized_client Access_denied Unsupported_respon se_type クライアントは現在の方法で認可コードを取得することを認可されていない リソースオーナまたは認可サーバがリクエストを拒否した 認可サーバは現在の方法による認可コード取得をサポートしていない 202

205 パラメータ必須任意値説明 Error_descr iption 任意 Invalid_scope Server_error Temporarily_unavaila ble リクエストスコープが不正 未知 もしくはその他の不当な形式である 認可サーバがリクエストの処理ができないような予期しない状況に遭遇した 認可サーバが一時的な過負荷やメンテナンスによってリクエストを扱うことができない クライアント開発者が発生したエラーを理解する際の手助けとなる UTF-8 エンコードされた可読性のある追加情報 Error_uri 任意 クライアント開発者が発生したエラーに関する追加の情報を得ることがで きる Web ページの URI State 任意 もし正当な state パラメータがクライアントからの認可リクエストに含ま れていた場合は必須 クライアントから受け取った値をそのまま返す (d) アクセストークンリクエスト クライアントはトークンエンドポイントに対して 以下のようなパラメータを付与してリクエストを送信 します 表 7.2-8: アクセストークンリクエストパラメータ パラメータ必須任意説明 grant_type 必須グラントタイプ 値は authorization_code でなければならない Code 必須認可コード 認可サーバから受け取った認可コード redirect_uri 任意 リダイレクト URI 認可リクエストに redirect_uri パラメータが含まれていた 場合は必須 その値をそのまま付与しなくてはならない クライアントタイプがコンフィデンシャルである場合 あるいはクライアントクレデンシャルが発行さ れた ( もしくはその他の認証が要求された ) クライアントは 認可サーバにより認証されなければな りません (e) アクセストークンレスポンスアクセストークンリクエストが正当かつ認可された場合 認可サーバはアクセストークンと任意でリフレッシュトークンを発行します もしリクエストが失敗もしくは不正だった場合 エラーレスポンスを返します アクセストークンレスポンスの詳細は (4) アクセストークンの発行 を参照してください [ インプリシットグラント ] インプリシット ( 黙示的 ) グラントタイプは アクセストークンを取得するために用いられ 特定のリダイレクト URI を利用することが前提となっているパブリッククライアントに適合します これらのクライアントは 通常 JavaScript などのスクリプト言語を使用し ブラウザ上で動作します インプリシッ 203

206 トグラントタイプでは リフレッシュトークンの発行はサポートされていません このグラントタイプではリダイレクトを利用したフローとなっているため クライアントはリソースオーナのユーザエージェント ( 通常は Web ブラウザ ) と対話し 認可サーバによるリダイレクトを通したリクエストを受け付けることができなくてはなりません 認可取得とアクセストークン取得のリクエストが分離されている認可コードグラントタイプと異なり クライアントは認可リクエストの結果としてアクセストークンを受け取ります インプリシットグラントタイプではクライアント認証は行わず リソースオーナの介在とリダイレクト URI の事前登録に頼っています 図 7.2-2: インプリシットグラント処理フロー 1 クライアントがリソースオーナのユーザエージェントを認可エンドポイントに送ることで フローが開始します このときクライアントは クライアント識別子 アクセス範囲 ローカルステート および認可サーバがアクセス許可取得後にユーザエージェントを戻すリダイレクト URI をリクエストに含めます 2 認可サーバは ユーザエージェントを通してリソースオーナを認証し リソースオーナにアクセス要求の許可 / 拒否を尋ねます 3 リソースオーナがアクセスを許可した場合 認可サーバは予め与えられていたリダイレクト URI を用いて ユーザエージェントをリダイレクトさせてクライアントに戻します リダイレクト URI には アクセストークンが含まれます 204

207 4 ユーザエージェントは リダイレクトの指示に従い Web 上のクライアントリソースにリクエストを送信します ( このときフラグメントは送信されません ) ユーザエージェントはフラグメントの情報をローカルに保持します 5 Web 上のクライアントリソースにアクセスすると Web ページ ( 通常 埋め込みのスクリプトが含まれる HTML ドキュメント ) が返されます その Web ページでは ユーザエージェントによって保持されているフラグメントを含む完全なリダイレクト URL にアクセスし フラグメントに含まれているアクセストークンとその他のパラメータを取り出すことができます 6 ユーザエージェントは 上記 Web ページに含まれるスクリプトをローカルに実行し アクセストークンを取り出してクライアントに渡します (a) 認可リクエスト クライアントは 認可リクエストに以下のパラメータを付与します 表 7.2-9: 認可リクエストのパラメータ パラメータ必須任意説明 response_type 必須レスポンスタイプ 値は必ず token にしなければならない client_id 必須 クライアント識別子 認可サーバがクライアントに発行した識別子 ( ク ライアントが事前に提供した登録情報を表すユニーク文字列 ) redirect_uri 任意 リダイレクト URI リソースオーナとのやりとりが完了した後 認可サー バがリソースオーナのユーザエージェントをクライアントへ誘導する際 の URI scope 任意アクセス範囲 認可サーバによって定義されているアクセス範囲 state 推奨 ローカルステート リクエストとコールバックの間で状態を維持するた めに使用するランダムな値 認可サーバはリダイレクトによってクライ アントに処理を戻す際にこの値を付与する クライアントは HTTP リダイレクトまたはユーザエージェントを介したその他の利用可能な手段に よって リソースオーナを構築された URI に送ります 認可サーバは 必要なリクエストパラメータがすべて揃っていて かつ正当であることを検証しま す 認可サーバは アクセストークンを返すリダイレクト URI が事前登録されたリダイレクト URI と 一致することを検証しなければなりません (b) アクセストークンレスポンス リソースオーナがアクセス要求を許可した場合 認可サーバはアクセストークンを発行し アクセ ストークンレスポンスに以下のパラメータを付与してクライアントに送ります 205

208 表 : アクセストークンレスポンスのパラメータ パラメータ必須任意説明 access_token 必須認可サーバによって発行されたアクセストークン token_type 必須 トークンタイプ アクセストークンのタイプとアクセストークンを適切に用いるために必要な情報を提供する クライアントはトークンタイプが想定外のものであるとき または信頼できない時にはそのアクセストークンを利用するべきではない expires_in 任意 有効期間 アクセストークンの有効期間を秒で表したもの 例えばこの 値が 3600 であれば そのアクセストークンは発行から 1 時間後に期 限切れとなる scope 任意アクセス範囲 認可サーバによって定義されているアクセス範囲 state 任意 ローカルステート クライアントからの認可リクエストに state パラメー タが含まれていた場合は必須 クライアントから受け取った値をそのま ま返す エラーレスポンスについては リダイレクト URI の欠落 / 不正 / ミスマッチによって失敗した場合 もしくはクライアント識別子が不正な場合は 認可サーバはリソースオーナにエラーを通知する必要があります 不正なリダイレクト URI に対してユーザエージェントを自動的にリダイレクトさせてはなりません リソースオーナがアクセス要求を拒否した場合 もしくはリダイレクト URI の欠落 / 不正以外でリクエストが失敗した場合は 認可サーバは以下のようなパラメータを付与してクライアントにエラーレスポンスを返します 表 : エラーレスポンスパラメータ パラメータ必須任意値説明 error 必須 invalid_request リクエストに必要なパラメータが含まれていない サポート外のパラメータが付与されていた場合や その他不正な形式であった場合もこれに含まれる error_descript ion 任意 unauthorized_client access_denied unsupported_respons e_type invalid_scope server_error temporarily_unavailab le クライアントは現在の方法で認可コードを取得することを認可されていない リソースオーナまたは認可サーバがリクエストを拒否した 認可サーバは現在の方法による認可コード取得をサポートしていない リクエストスコープが不正 未知 もしくはその他の不当な形式である 認可サーバがリクエストの処理ができないような予期しない状況に遭遇した 認可サーバが一時的な過負荷やメンテナンスによってリクエストを扱うことができない クライアント開発者が発生したエラーを理解する際の手助けとなる UTF-8 エンコードされた可読性のある追加情報 206

209 パラメータ必須任意値説明 error_uri 任意 クライアント開発者が発生したエラーに関する追加の情報を得ること ができる Web ページの URI state 任意 もし正当な state パラメータがクライアントからの認可リクエストに含 まれていた場合は必須 クライアントから受け取った値をそのまま返 す [ リソースオーナパスワードクレデンシャル ] リソースオーナパスワードクレデンシャルグラントタイプは 例えばリソースオーナの所有するデバイス OS や特別に許可されたアプリケーションなど 信頼関係が確立されているような環境で リソースオーナのクレデンシャル ( 通常は対話型入力フォームにて取得するユーザ名とパスワード ) を取得できるクライアントに適しています また 保存済みのクレデンシャルをアクセストークンへ変換できるため ベーシック認証やダイジェスト認証のような直接的な認証スキームを利用している既存のクライアントを OAuth 2.0 へ移行する際にも利用できます 認可サーバは このグラントタイプを有効にする際は特に注意するべきであり 他のフローが利用できない場合にのみ許可するべきです 図 7.2-3: リソースオーナパスワードクレデンシャルのフロー 1 リソースオーナは クライアントにユーザ名とパスワードを提供します 2 クライアントは 認可サーバのトークンエンドポイントにリソースオーナから取得したクレデンシャルを含めることでアクセストークンを要求します リクエストを生成する際に クライアントは認可サーバによって認証されます 3 認可サーバは クライアントを認証し リソースオーナのクレデンシャルを検証します もし有効であればアクセストークンを発行します (a) 認可リクエストとレスポンス 207

210 クライアントがリソースオーナのクレデンシャルを取得する方法は この仕様の範囲外です クライ アントはアクセストークン取得直後にクレデンシャルを破棄しなければなりません (b) アクセストークンリクエスト クライアントは 下記のパラメータを付与したリクエストを構築します 表 : アクセストークンリクエストパラメータ パラメータ 必須任意 説明 grant_type 必須 グラントタイプ 値には password を指定しなければならない username 必須 ユーザ名 UTF-8 エンコードされたリソースオーナのユーザ名 password 必須 パスワード UTF-8 エンコードされたリソースオーナのパスワード scope 任意 アクセス範囲 認可サーバによって定義されているアクセス範囲 クライアントタイプがコンフィデンシャルである場合 あるいはクライアントクレデンシャルが発行さ れた ( もしくはその他の認証が要求された ) クライアントは 認可サーバにより認証されなければな りません 認可サーバは コンフィデンシャルクライアントあるいはクライアントクレデンシャルが発行された ( もしくはその他の認証が要求された ) クライアントにクライアント認証を要求し クライアントの認証情報が含まれていた場合はクライアントを認証し リソースオーナパスワードクレデンシャルの妥当性を確認します (c) アクセストークンレスポンスアクセストークンリクエストが正当かつ認可された場合 認可サーバはアクセストークンと任意でリフレッシュトークンを発行します クライアント認証に失敗 もしくはリクエストが不正であった場合 認可サーバはエラーレスポンスを返します アクセストークンレスポンスの詳細は (4) アクセストークンの発行 を参照してください [ クライアントクレデンシャル ] クライアント自身のコントロール下にある保護リソースまたは認可サーバとの間で調整済みの保護リソースにアクセスする場合 クライアントはクライアントクレデンシャル ( あるいはサポートされているその他の認証方式 ) のみでアクセストークンをリクエストすることができます コンフィデンシャルクライアントのみが クライアントクレデンシャルグラントタイプを利用できます 208

211 図 7.2-4: クライアントクレデンシャル処理フロー 1 クライアントは 自身の認証情報を含めてトークンエンドポイントにアクセストークンリクエスト を送ります 2 認可サーバは クライアントを認証し 認証に成功すればアクセストークンを発行します (a) 認可リクエストとレスポンス クライアント認証が認可グラントとして利用されるため 追加の認可リクエストは必要ありません (b) アクセストークンリクエスト クライアントは 以下のパラメータを追加し トークンエンドポイントにリクエストを送ります 表 : アクセストークンリクエストパラメータ パラメータ 必須任意 説明 grant_type 必須 グラントタイプ 値は client_credentials を指定しなければならない scope 任意 アクセス範囲 認可サーバによって定義されているアクセス範囲 クライアントは 認可サーバに対して認証を行わなければなりません 認可サーバは クライアントを認証しなければなりません (c) アクセストークンレスポンスアクセストークンリクエストが正当かつ認可された場合 認可サーバはアクセストークンを発行します リフレッシュトークンは含むべきではありません クライアント認証に失敗 もしくはリクエストが不正であった場合 認可サーバはエラーレスポンスを返します アクセストークンレスポンスの詳細は (4) アクセストークンの発行 を参照してください [ グラントタイプの拡張 ] クライアントは トークンエンドポイントの grant_type パラメータの値に 認可サーバによって定義された絶対 URI を指定し 追加の必須パラメータを付与することによって 拡張グラントタイプを利用できます 209