組織内、組織間の資産保護に必要なアイデンティティ基盤と関連技術の最新動向

2025/7/17 Findy Tools主催のDeep Security Conferenceで話した資料。

企業などの組織における従業員のID管理や認証強化がゼロトラストやフィッシング対策の文脈で注目されています。また、サプライチェーンなど組織を超えたデータ交換の安全性を確保することはビジネスのグローバル化や拡大に伴い非常に重要なトピックスとなってきています。しかしながら、実際にID基盤の導入を考える時、どのような機能をどのレベルまで実装すれば良いのかについて考え設計するのは非常に困難です。本セッションではパスキーやVerifiable Credentials、IPSIEなどデジタルIDに関連する最新の技術仕様の動向を紹介しつつ、今後組織におけるID基盤のあるべき姿について考えます。

Transcript

1. 組織内、組織間の資産保護に必要な アイデンティティ基盤と関連技術の最新動向 2025/7/17 伊藤忠テクノソリューションズ株式会社 一般社団法人 OpenID ファウンデーション・ジャパン/代表理事 米国OpenID Foundation/共同議長 eKYC&IDA WG 富士榮 尚寛（ふじえ なおひろ）
2. 自己紹介 デジタルアイデンティティ分野で約20年の経験を持ち、大手自動車製造業のグローバルID基盤に関するコンサルティ ング～PMなどを歴任。 2018年よりOpenIDファウンデーション・ジャパンの理事に就任、KYC WGを設立。2020年1月より米国OpenID FoundationにてeKYC and Identity Assurance Working Groupの設立および共同議長に就任。2021年6月 よりOpenIDファウンデーション・ジャパンの代表理事に就任。 CTCでは研究部門の責任者を務める。 各種役割 OpenIDファウンデーション・ジャパン代表理事/KYC WG発起人 米OpenID Foundation/eKYC&Identity Assurance WG共同議長 日本ネットワークセキュリティ協会/デジタルアイデンティティWG, ISOリエゾン 各種政府委員会構成員（Trust、デジタルアイデンティティ関連） 慶應義塾大学SFC研究所/研究員、大阪大学/客員教員 富士榮 尚寛（ふじえ なおひろ） Copyright © 2025, Naohiro Fujie, All Rights Reserved 2
3. IDとトラスト（信頼）の基礎 組織におけるID管理の重要性 ID基盤導入のプラクティスと標準技術仕様 境界の変化とパラダイムシフト 本日お話しすること 3 Copyright © 2025, Naohiro Fujie, All Rights Reserved
4. IDとトラスト（信頼）の基礎 Copyright © 2025, Naohiro Fujie, All Rights Reserved 4
5. • Identifier：識別子 集合の中で実体を一意に識別するための属性情報（一つとは限らない） 日本の中に「富士榮」は複数いるので苗字は識別子にならないが、大阪府の中 なら苗字で識別できる • Identity：アイデンティティ 実体を構成する属性の集合（ISO/IEC 24760-1より） 識別子もアイデンティティを構成する要素の一つ そもそもIDとは？ 5 Copyright © 2023, Naohiro Fujie, All Rights Reserved ⽇本 ⼤阪府 富⼠榮 富⼠榮 富⼠榮 富⼠榮 要素 解説 例 属性 後天的に取得された主体に関わる情報（後から変化する） 名前、電話番号、社員番号、メールアドレス、 認証状態、位置情報 好み 主体の嗜好に関わる情報 甘いものが好き 形質 主体の先天的な特有の性質（後から変化しにくい） 生年月日、性別 関係性 他の主体との関係に関わる情報（一部属性と重複） XX大学卒業、YY部所属 「ID管理」で言う IDはこちら
6. エンティティとアイデンティティの関係性 6 Copyright © 2025, Naohiro Fujie, All Rights Reserved 出典）@_NAT ZONE https://www.sakimura.org/2011/06/1124/ • エンティティ（主体・実体）は直接 観測できない • アイデンティティ（属性の集合）を 通じて認識・観測する • 自観：提供する属性を通じ、他人に 見てほしい「自己像」 • 他観：提供された属性を通じ、実際 に感じ取った「自己像」 • 提供する相手毎に提供する属性を変 えて「自己像」を形成 （コンテキストの切り替え） 余 談
7. コンテキスト毎に自己像を構築し、やりとりを行う 7 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 XX大学出身 YY社での実績 ⇒採用 ZZ社所属 ⇒取引 XX大学出身 ⇒採用 A県出身 ⇒入寮許可 家族構成 ZZ社所属 ⇒補助金 XX大学出身 ZZ社所属 ⇒結婚 コンテキスト・関係性 余 談
8. コンテキスト侵害→プライバシー侵害 8 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 親戚関係の構造 ⇒労働には無関係 A県出身 XX大学出身 ⇒取引には不要 職場での姿 ⇒家族に知られたく ない？ 学生時代の交友関係 ⇒労働には無関係 ◦◦地区出身 ⇒採用には無関係 職場での姿 ⇒家族に知られたく ない？ 余 談
9. コンテキスト侵害→プライバシー侵害 9 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 親戚関係の構造 ⇒労働には無関係 A県出身 XX大学出身 ⇒取引には不要 職場での姿 ⇒家族に知られたく ない？ 学生時代の交友関係 ⇒労働には無関係 ◦◦地区出身 ⇒採用には無関係 職場での姿 ⇒家族に知られたく ない？ コンテキスト毎に自己像を 自身の意思で形成することが 必要 余 談
10. 属性の信頼性が求められる 10 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 XX大学出身 YY社での実績 ⇒採用 ZZ社所属 ⇒取引 XX大学出身 ⇒採用 A県出身 ⇒入寮許可 家族構成 ZZ社所属 ⇒補助金 XX大学出身 ZZ社所属 ⇒結婚 本当に？ 本当に？ 本当に？ 本当に？ 本当に？ 本当に？
11. 属性付与主体による証明（KYC） 11 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 XX大学出身 YY社での実績 ⇒採用 ZZ社所属 ⇒取引 XX大学出身 ⇒採用 A県出身 ⇒入寮許可 家族構成 ZZ社所属 ⇒補助金 XX大学出身 ZZ社所属 ⇒結婚 大学への照会 卒業証明書 職歴（履歴書） 住民票 課税証明 会社への照会 身分証提示 家族への照会 住民票 大学への照会 卒業証明書 探偵？ KYC（Know Your Customer）： →顧客確認≒身元確認
12. なぜ信じられるのか（属性付与主体の信頼性） 12 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 存在する大学か？ レベルは？ 存在する会社か？ 財務状態は？ 存在する大学か？ レベルは？ 存在する国か？
13. 13 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 存在する大学か？ レベルは？ 存在する会社か？ 財務状態は？ 存在する大学か？ レベルは？ 存在する国か？ 属性付与主体の有効性 （人の前に組織の信頼性） なぜ信じられるのか（属性付与主体の信頼性）
14. 属性付与主体の信頼性をどのように測るのか？ 14 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 採用時に身元確認 をしているか ちゃんと試験をして 卒業させているか 行政システムが有効 に働いているか？
15. 属性付与主体の信頼性をどのように測るのか？ 15 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 採用時に身元確認 をしているか ちゃんと試験をして 卒業させているか 行政システムが有効 に働いているか？ 各属性付与主体の中で アイデンティティマネジメント が有効に働いているか？
16. 属性付与主体の信頼性をどのように測るのか？ 16 国 地域 現在の 職場 取引先 出身校 以前の 職場 家族 身分に変更はないか 家族構成、雇用状態 に変化はないか？ 継続的に管理されているか？
17. 何をもって信頼できるか？を定めた枠組み 国や業界毎に定められ運用されている 米国における政府調達：NIST SP800-63 日本の学術ネットワーク・リソース共有：学術認証フェデレーション（学認） 日本の金融取引：犯罪収益移転防止法 日本の携帯電話契約：携帯電話不正利用防止法 サービス提供者目線だけではなく、利用者目線も大切 サービス提供者目線：利用者・顧客は信頼できるのか？ 利用者目線：そのサービスは情報を適切に扱ってくれるのか、信頼できるのか？ トラストフレームワーク 17 Copyright © 2025, Naohiro Fujie, All Rights Reserved
18. IAL/AAL/FALの3軸でリスクに応じて採用強度を決定 例）NIST SP800-63-3 18 Copyright © 2025, Naohiro Fujie, All Rights Reserved 63A：IAL（Identity Assurance Level） ユーザが申請者（Applicant）として新規登 録（SignUp）する際に、CSP（Credential Service Provider）が行う本人確認 （Identity Proofing）の厳密さ、強度を示す 63B：AAL（Authenticator Assurance Level） 登録済みユーザー（Claimant）がログインす る際の認証プロセス（単要素認証or多要素認 証、認証手段）の強度を示す 63C：FAL（Federation Assurance Level） IDトークンやSAML Assertion等、Assertion のフォーマットやデータやり取りの仕方の強 度を示す
19. 19 Copyright 2018 OpenID Foundation Japan - All Rights Reserved. 出典）JICS2013 学認トラストフレームワーク 東京大学 佐藤先生 学生、教職員 大学、機関 電子ジャーナル などのアプリ 国立情報学研究所 （NII）が運営
20. 組織におけるID管理の重要性 Copyright © 2025, Naohiro Fujie, All Rights Reserved 20
21. IDの利用用途 業務に必要なITシステムや情報を利用させること ID管理の目的 • 正しい利用者に業務に必要なITシステムや情報を正しく利用させること ITシステムを利用させるために必要なプロセス 「正しい利用者に」 • 識別（Identification）：利用者を他者と区別する • 認証（Authentication）：利用者の正当性を検証する 「正しく利用させる」 • 認可（Authorization）：利用者応じた権限を与える 信頼を得るために組織が行うIDマネジメント 21 Copyright © 2025, Naohiro Fujie, All Rights Reserved これらのプロセスを 管理・制御すること が必要
22. 2つの管理 Management（マネージメント） Do Right Things 何が正しい状態なのかを定義する ルール化、手順化 Control（コントロール） Do Things Right 正しい状態へ持っていく 制御、統制 予防的：抑止力、違反できないようにする仕組み 発見的：証拠、違反したことを気づけるための仕組み 「管理」とは？ 22 Copyright © 2025, Naohiro Fujie, All Rights Reserved ルールの定義 プロセスの実行 ルールどおりにプロ セスを実行させる （予防と発見） この道は60km/h制限 制限速度で運転する 予防 - 監視ｶﾒﾗ ポリシー 道路交通法 目標 交通事故を減らす マネジメント・システム 発見 - 取締り
23. ID基盤が必要な理由 23 Copyright © 2025, Naohiro Fujie, All Rights Reserved ルールの定義 プロセスの実行 ルールどおり にプロセスを 実行させる ポリシー 目標 正しい利用者に業務に必要なITシステムや情報を正しく利用させる 例）企業に在籍する者に、役職に応じて情報を開示する 管 理 制 御 ・社員番号を使って識別 する ・入社～退社の間のみ利用 させる ・パスワードで認証する ・パスワードは8文字以上 とする ・有効期限は90日とする ・利用者の役職属性に応じ て情報を開示する 識別 認証 認可 ・社員番号を人事システム から取得し、ITシステム へ登録する ・入社時に有効化、退社時 に無効化する ・パスワードが間違って いると認証しない ・8文字未満のパスワード を登録させない ・有効期限間近に通知する ・人事システムから最新の 役職属性の値を取得し、 ITシステムへ登録する 予防 ・人事システム以外から登 録されたIDの有無を棚 卸・確認する ・在籍状態以外のIDの有無 を棚卸・確認する ・パスワード間違い履歴 を確認する ・パスワード期限切れの ユーザ一覧の棚卸をする ・アクセス履歴と利用 者の権限の棚卸する 発見 手動での管理・制御は 不確実かつ煩雑 システム化（ID基盤の整備）が必要
24. ID基盤を構成する要素と役割分担 24 Copyright © 2025, Naohiro Fujie, All Rights Reserved ルールの定義 プロセスの実行 ルールどおり にプロセスを 実行させる ポリシー 目標 正しい利用者に業務に必要なITシステムや情報を正しく利用させる 例）企業に在籍する者に、役職に応じて情報を開示する 管 理 制 御 ・社員番号を使って識別 する ・入社～退社の間のみ利用 させる ・パスワードで認証する ・パスワードは8文字以上 とする ・有効期限は90日とする ・利用者の役職属性に応じ て情報を開示する 識別 認証 認可 ・社員番号を人事システム から取得し、ITシステム へ登録する ・入社時に有効化、退社時 に無効化する ・パスワードが間違って いると認証しない ・8文字未満のパスワード を登録させない ・有効期限間近に通知する ・人事システムから最新の 役職属性の値を取得し、 ITシステムへ登録する 予防 ・人事システム以外から登 録されたIDの有無を棚 卸・確認する ・在籍状態以外のIDの有無 を棚卸・確認する ・パスワード間違い履歴 を確認する ・パスワード期限切れの ユーザ一覧の棚卸をする ・アクセス履歴と利用 者の権限の棚卸する 発見 統合認証システム ID管理システム ID管理システム ＋ログ管理システム アプリケーション
25. ID基盤の構成 25 Copyright © 2025, Naohiro Fujie, All Rights Reserved 棚卸・ログ管理機能（ID管理システム、ログ管理システム） • 各システムのID状態を棚卸しし、意図した状態でない場合は警告を出す • 各システムのID状態、運用ログ情報を収集する 管理者 源泉情報（人事DB等） ID管理システム 統合認証システム アプリケーション （クラウド/オンプレ） - IDライフサイクル管理機能 （人事業務/イベントに合わせた アカウント管理） - ID同期機能 （認証用IDの同期） - ID棚卸し SSO 利用者 IDメンテナンス - PWDリセット - ID作成/更新/削除 IDメンテナンス - PWDリセット、 - プロファイルメンテナンス 認証/ID管理に関連する機能 認証機能（統合認証システム） • ID/PWDなどでログオン制御を行う • アプリケーションの認証機能を外出し、共同で利用することでシングルサインオ ンを実現する • 一般に、認証に使うID情報（社員番号やパスワード）はID管理システムを使っ て管理される 認可機能（アプリケーション） • ログオン後、ユーザの権限（メニューを出す・出さない等）制御を行う • 一般に制御自体はアプリケーション側で行い、認可に必要な情報（役職や所属組 織）はID管理システムを使って管理される ID同期機能（ID管理システム） • ID管理システムから認証システムへ、認証に使うID情報（社員番号やパスワー ド）を同期する • ID管理システムからアプリケーションへ、認可に使うID情報（役職や所属組 織）を同期する - ID同期機能 （認可用IDの同期） - ID棚卸し IDライフサイクル管理機能（ID管理システム） • ID情報を源泉（人事等）から取り込み、人事イベントに応じて認証システムや 各アプリケーションへ必要なID情報を同期する • 管理者や利用者自身でIDのメンテナンスを行う（パスワード・リセット、プロ ファイルメンテナンス等） ログ管理システム ログ収集機能 一般的な認証/ID管理システムのスコープ
26. ID基盤の構成 26 Copyright © 2025, Naohiro Fujie, All Rights Reserved 棚卸・ログ管理機能（ID管理システム、ログ管理システム） • 各システムのID状態を棚卸しし、意図した状態でない場合は警告を出す • 各システムのID状態、運用ログ情報を収集する 管理者 源泉情報（人事DB等） ID管理システム 統合認証システム アプリケーション （クラウド/オンプレ） - IDライフサイクル管理機能 （人事業務/イベントに合わせた アカウント管理） - ID同期機能 （認証用IDの同期） - ID棚卸し SSO 利用者 IDメンテナンス - PWDリセット - ID作成/更新/削除 IDメンテナンス - PWDリセット、 - プロファイルメンテナンス 認証/ID管理に関連する機能 認証機能（統合認証システム） • ID/PWDなどでログオン制御を行う • アプリケーションの認証機能を外出し、共同で利用することでシングルサインオ ンを実現する • 一般に、認証に使うID情報（社員番号やパスワード）はID管理システムを使っ て管理される 認可機能（アプリケーション） • ログオン後、ユーザの権限（メニューを出す・出さない等）制御を行う • 一般に制御自体はアプリケーション側で行い、認可に必要な情報（役職や所属組 織）はID管理システムを使って管理される ID同期機能（ID管理システム） • ID管理システムから認証システムへ、認証に使うID情報（社員番号やパスワー ド）を同期する • ID管理システムからアプリケーションへ、認可に使うID情報（役職や所属組 織）を同期する - ID同期機能 （認可用IDの同期） - ID棚卸し IDライフサイクル管理機能（ID管理システム） • ID情報を源泉（人事等）から取り込み、人事イベントに応じて認証システムや 各アプリケーションへ必要なID情報を同期する • 管理者や利用者自身でIDのメンテナンスを行う（パスワード・リセット、プロ ファイルメンテナンス等） ログ管理システム ログ収集機能 認証/シングルサインオン プロビジョニング ID連携/フェデレーション
27. 認証/シングルサインオン）原始的なSSO 27 • シングルサインオン • アプリケーション毎に持っていた認証機能を外部へ出し一元化 • 認証Cookieを共有することでシングルサインオンを実現 分散管理状態（SSO不可） アプリケーション アプリケーション 認証サーバ アプリケーション アプリケーション 認証サーバの外部化、 認証Cookieを共有（SSO可） Cookie有効範囲 （ドメイン） ドメイン外アプリ Cookieが共有不可 ⇒SSO不可 関連キーワード解説
28. 認証/シングルサインオン）WAMの活用 28 関連キーワード解説 • WAM（Web Access Management）による解決 • アプリケーション側にAgentを導入し認証状態を確認、Cookieの有効範囲 （ドメイン）を超えたSSOを実現 認証サーバ アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 （ドメイン） ドメイン外 アプリ 認証サーバ アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 （ドメイン） ドメイン外アプリ Agent 認証状態の確認 ドメイン外はAgentが認証状態を問い合わせてSSO Agent Agent導入が不可、 認証サーバと通信 不可なアプリ ⇒SSO不可
29. 認証/シングルサインオン）ID連携/フェデレーション 29 関連キーワード解説 • ID連携/フェデレーションによる解決 • 認証結果表明（アサーション）をクライアント（ブラウザ）を経由して受け渡 すことにより、Cookieの有効範囲（ドメイン）を超えたSSOを実現 • アプリケーションと認証サーバ間の直接の通信が不要なので、クラウドに最適 認証サーバ アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 （ドメイン） ドメイン外 アプリ 認証サーバ アプリケーション ドメイン内は認証Cookieを共有しSSO Cookie有効範囲 （ドメイン） ドメイン外 アプリ アサーション ドメイン外はアサーションを渡すことでSSO 連携方法や形式の 標準化が重要 ⇒SAML,OpenID Connect
30. 認証/シングルサインオン）構成の比較 30 関連キーワード解説 構成パターン ドメイン跨ぎの SSO アプリケーション構成 アプリ ⇒認証サーバ通信 適用対象の例 認証Cookieの共 有 不可 同一認証Cookieを利用す る必要あり 不要 小規模イントラネット、 自前アプリのみ WAM 可 Agent導入が必要 必要 大規模イントラネット、 Agent導入可能アプリの み ID連携 可 ID連携プロトコルへの対 応が必要 不要 大規模分散環境（イント ラ/B2B/クラウド）
31. ID管理）プロビジョニング 31 関連キーワード解説 • 認証/認可の大前提となるIDの登録 • 「認証の8プロセス」（出典：2015年のIDビジネス/野村総合研究所著） 存 在 確 認 身 分 証 明 書 発 行 シ ス テ ム 用 の ID コ ー ド と 認 証 手 段 の デ ー タ ベ ー ス 登 録 ユ ー ザ ー 認 証 認 証 結 果 表 明 発 行 認 証 結 果 表 明 送 付 認 証 結 果 表 明 確 認 リ ソ ー ス 使 用 の 認 可 IDと認証手段を認証システムへ 登録しないと認証はできない 認可に使用する属性をアプリへ 登録しないと認可はできない 余談）分散システム構成で認証 結果を受け渡すのがID連携
32. ID管理）プロビジョニング 32 関連キーワード解説 • 認証/認可の大前提となるIDの登録 • 認証/認可を正しく行うために信頼できるID情報を登録する必要がある • 人事DBからID情報を取得し、認証システムや各種アプリケーションへ配信する （企業において最も信頼できるID情報の源泉が人事である場合が多いため） 人事DB 入社、異動、退社などの イベントに合わせて人事 情報を取込み 利用ポリシーに合わせて 各システムへ ID を配信 ID管理システム アプリケーション 認証システム 配信されたIDを利用して 認証を行う 配信されたIDを利用して 認可を行う プロビジョニング 配信に利用できる方式がポイント 例）LDAP/JDBC/CSVなど
33. ID管理）プロビジョニング 33 関連キーワード解説 • プロビジョニングの重要性 • ID管理システムが正しく、信頼できるプロビジョニングを行うことにより識別、認証、 認可が正しく実行できる状態になる 信頼 信頼 信頼 認証用属性の提供 （クレデンシャル） 認可用属性 の提供 認証結果の提供 ID管理 システム 統合認証 システム アプリ ID管理システムの役割 - 他のシステムに信頼に足るID情報を提供する 実現方法の例） 人事情報など信頼できる情報ソースと連携する 認証システムの役割 - ユーザの正当性を検証する 実現方式の例）IDとパスワードのマッチング、SMS 通知への応答 アプリケーションの役割 - 認可コントロールを行う
34. ID基盤導入のプラクティスと標準技術仕様 Copyright © 2025, Naohiro Fujie, All Rights Reserved 34
35. 組織内には様々な業務が存在 扱う情報の重要度・機密度 業務の継続性要件（クリティカル度合い） 利用環境、利用時間帯、利用者（組織内のみ、組織外との連携） 業務の要件に応じてID基盤に求める要件を整理 ID管理レベル（セッションやIDライフサイクルの厳密性） 認証強度（多要素認証、フィッシング耐性） 可用性（認証機能の停止に対する許容度） リーズナブルな統合範囲を決定、充足する製品・サービス を選定するのが大事 ID基盤の統一・統合は果たして正解なのか？ 35 Copyright © 2025, Naohiro Fujie, All Rights Reserved
36. 要件整理の例 36 Copyright © 2025, Naohiro Fujie, All Rights Reserved アプリケーション 機密性要件 - アクセス管理 - ID管理 - 認証強度 完全性要件 - アクセス管理 - ID管理 - 認証強度 可用性要件 - インフラ強度 - 継続可能性 インシデント発生時のリ スク（インパクト x 発生 の可能性） 生産管理 高 高 高 高 研究管理 高 高 低 中 顧客管理 高 高 中 中 ポータル 中 中 中 中 メール 高 高 中 中 ネットワーク 低 中 高 中 経費精算 中 中 低 低 勤怠管理 中 中 低 低 提供するID基盤が保証するID管理・認証強度レベル、可用性を含め統合対象とする業務やアプ リケーションを決定していくことが重要（全てをカバーするのは非現実的） ID基盤への統合対象（例）
37. 既存のフレームワークを参照しつつ要件を整理するのも大事 再掲）NIST SP800-63-3 37 Copyright © 2025, Naohiro Fujie, All Rights Reserved 63A：IAL（Identity Assurance Level） ユーザが申請者（Applicant）として新規登 録（SignUp）する際に、CSP（Credential Service Provider）が行う本人確認 （Identity Proofing）の厳密さ、強度を示す 63B：AAL（Authenticator Assurance Level） 登録済みユーザー（Claimant）がログインす る際の認証プロセス（単要素認証or多要素認 証、認証手段）の強度を示す 63C：FAL（Federation Assurance Level） IDトークンやSAML Assertion等、Assertion のフォーマットやデータやり取りの仕方の強 度を示す
38. 各機能を独自に実装するリスクの例 アプリケーションとの接続の都度作り込みが発生する セキュリティ上の問題が発生した際は自己責任 標準技術仕様の採用の意味 同じ標準の採用による接続性の担保 完全ではないがある程度はつながる（後述） エキスパートによるセキュリティ上の考慮、学術機関による検査（Formal Verification）が行われることもある 標準技術仕様自体の不備：自己責任ではないと言い張れる 実装の不備：やっぱり自己責任 標準技術仕様を採用することの重要性 38 Copyright © 2025, Naohiro Fujie, All Rights Reserved
39. 標準技術仕様等の例 39 Copyright © 2025, Naohiro Fujie, All Rights Reserved カテゴリ 関連仕様・フレームワーク 説明 策定団体 認証 WebAuthn ブラウザシナリオでFIDO認証を利用するための仕様 W3C CTAP 認証器とプラットフォームの間の通信方式を策定した仕様 FIDO Alliance TOTP 時刻ベースで一定期間ごとに新しいOTPを生成する仕様 IETF WebOTP SMSで受け取ったOTPをWebサイトに自動入力する仕様 W3C フェデレーション （ID連携） OpenID Connect ID情報をOPとRPでセキュアに受け渡すための仕様 OpenID Foundation SAML ID情報をIdPとSPでセキュアに受け渡すための仕様 OASIS Ws-federation 異なるセキュリティ領域間でID情報を連携するための仕様 Microsoft,IBM,BEA API認可 OAuth APIクライアントへリソースアクセスを認可するためのフレーム ワーク IETF アクセス制御 AuthZEN ゼロトラストアーキテクチャに適応するためのアクセス制御フ レームワーク OpenID Foundation XACML アクセス制御に関して記述、評価するための仕様 OASIS プロビジョニング SCIM ユーザアカウントや属性情報等のプロビジョニングを行うため の仕様 IETF シグナリング SSF イベント情報を通知・共有するためのフレームワーク OpenID Foundation
40. 組み合わせ問題 ID連携はOpenID Connect、SAML、ws-fed。プロビジョニングはSCIM。継続 的認証はSSF。API認可はOAuth2.0。。。複数の仕様の十分な理解は困難 各仕様には必須とオプショナルパラメータが存在。。。何を採用すべきか不明 OpenID Foundation/IPSIE（いぷしー） WG Interoperability Profiling for Secure Identity in the Enterprise OpenID ConnectやShared Signal Framework、OAuth、SCIMなどの標準 やフレームワークはオプション性が非常に高いため、うまく調整しないと相互運用 性が担保されないケースが多い。本WGでは既存の仕様のプロファイルを開発し 相互運用性を実現しつつ、セキュアなデフォルト設定を検討することが目的 どのように標準技術を利用すれば良いのか 40 Copyright © 2025, Naohiro Fujie, All Rights Reserved
41. 企業や組織がリスクレベルに応じて対応すべき管理レベ ルを選択、レベルに応じて実装内容を決めていく 想定している利用用途 サプライチェーンでレベルXXを取引要件として求める 企業・組織が製品選定をするときにレベルXXに対応しているものを選定する 現時点で以下の2点について定義（次ページより） セッションライフサイクル アイデンティティライフサイクル ※https://github.com/openid/ipsie/blob/main/ipsie-levels.md IPSIE WGで定義する管理レベル 41 Copyright © 2025, Naohiro Fujie, All Rights Reserved
42. セッションライフサイクル（SL） 42 Copyright © 2025, Naohiro Fujie, All Rights Reserved IPSIE LEVEL 実現すること 要件 アプリケーション IDサービス SL1 • IDサービスとアプリケーションとの基 本的なシングルサインオン • ユーザのアイデンティティに関する情 報の伝達 • NIST SP800-63-4 FAL2に準拠 すること • アプリケーション側のセッションはア サーションからセットされること（ID サービスが発行するアサーションの セッションライフタイムとアプリケー ション側のセッションライフタイムを 合わせること） • NIST SP800-63-4 FAL2に準拠 すること • 多要素認証を強制し、認証コンテ キストをアプリケーションへ伝えるこ と SL2 • SL1に加え、アプリケーションから ユーザがIDサービスへログインする 際の認証手段の指定 • IDサービスからの要求に応じてアプ リケーション側のセッションを破棄す ること • アプリケーションからの要求に応じ た認証手段を強制すること SL3 • SL2に加え、IDサービスとアプリケー ションの間の継続的な認証 • セッション状態の変化をIDサービス へ伝えること • ユーザ、セッション、デバイスの状態 変化をアプリケーションへ伝えること
43. アイデンティティライフサイクル（IL） 43 Copyright © 2025, Naohiro Fujie, All Rights Reserved IPSIE LEVEL 実現すること 要件 アプリケーション IDサービス IL1 • アイデンティティサービスがユーザとプ ロファイル情報をアプリケーションへ プロビジョニングし同期（Just In Timeプロビジョニングでも可能だが IPSIEの要件ではない） • 事前にIDサービスからユーザの作 成・更新・削除ができること • IDサービスによって提供されるプロ ファイルのアプリケーション側での作 成・更新・削除は許可しないこと • プロビジョニングされたユーザとプロ ファイル情報をアプリケーション側と 同期すること IL2 • IDサービスからグループ情報をアプ リケーションへ同期 • グループ属性とアプリケーション側の ロールをマッピングすること • グループメンバーシップ情報をアプリ ケーションと同期すること IL3 • アプリケーション側のロール情報を IDサービス側へ伝達し、IDサービス 側でユーザをマッピング、アプリケー ション側と同期 • アプリケーション側のロール情報を IDサービスへ提供すること • アプリケーション側のロール情報を 取り込み、ユーザへ割り当てること • ユーザのロール情報をアプリケーショ ンと同期すること
44. 境界の変化とパラダイムシフト Copyright © 2025, Naohiro Fujie, All Rights Reserved 44
45. IDの利用用途 業務に必要なITシステムや情報を利用させること ID管理の目的 • 正しい利用者に業務に必要なITシステムや情報を正しく利用させること ITシステムを利用させるために必要なプロセス 「正しい利用者に」 • 識別（Identification）：利用者を他者と区別する • 認証（Authentication）：利用者の正当性を検証する 「正しく利用させる」 • 認可（Authorization）：利用者応じた権限を与える 「正しい利用者」の範囲の拡大 45 Copyright © 2025, Naohiro Fujie, All Rights Reserved これらのプロセスを 管理・制御すること が必要 従来は「正しい＝組織（≒信頼できる境界線）の中」 という仮定があった 「境界の変化」 物理的な境界であるファイアウォール 論理的な境界であるFederationの中 • さらにその外へ？→FALでは測れない世界との連携
46. 本人確認済みアカウントは不正を働かないのか？ あくまでデジタルIDと現実社会のエンティティとのバインディングが高いことによるトレーサビリティ の向上による牽制が効いているだけ これまでの信頼レベルによるリスクへの対応 IAL：信頼できるデータベースとの突合によるID保証 対応するリスク：複数アカウント、捨てアカウントへの対策 AAL：認証強度の保証（登録した人＝利用している人である確率の向上） 対応するリスク：アカウント盗難、なりすまし 実ビジネスを行う上で必要な信頼 ビジネス相手の実在性だけでなく、十分な業務遂行能力があるか検証する必要がある IAL/AALだけで信頼できるのか？ 46 Copyright © 2025, Naohiro Fujie, All Rights Reserved
47. 徳≒不正をしないという期待度 構成する要素の例 レピュテーション ソーシャルアクティビティ 裏書・保証 当該エンティティと他のエンティティの関係性 直接的なKYCによるIALを補完する役割となり得る DXに必要な信頼の拡張 47 Copyright © 2025, Naohiro Fujie, All Rights Reserved 徳 IAL AAL IAL/AALで測れない軸 の定義が必要
48. TrustはIdentity Graphにより構築されるという考え方 NFTのようなトークンに所有者の情報をつけたもの、という側面で語られることが 多いが、論文*を読むとソウルの信頼を形成するためにはアクティビティと他のソウ ルとの関係性とReputationが必要という考え方であることがわかる 論文の参照数のような考え方 徳と裏書を形成するための考え方の一つとも捉えられる SBT（Soul Bound Token）が目指すもの 48 Copyright © 2025, Naohiro Fujie, All Rights Reserved ソウル 作品 トークン ソウル ソウル ソウル 作者 購入者 購入者が多い作品 の作者は良い作者 * https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763
49. これまで＋これから IdP（Identity Provider）、CSP（Credential Service Provider）が集中的にIALやAALを高める 利用者自身が信頼を形成するためのID情報を集めてくる IdP/CSPと繋がったシステム以外からも情報を集めるために 利用者自身によるポータビリティ 直接信頼していないシステムの発行したクレーム（属性）への 信頼 ができる仕組みが必要 検証可能な資格情報（Verifiable Credentials）の活用 49 Copyright © 2025, Naohiro Fujie, All Rights Reserved
50. 検証可能性と制御可能性の両立を目指す アイデンティティ情報の発行と提示を分離、利用者による提示情報の制御 公開鍵暗号などによるデータの真正性の担保 IHVモデルへの流れ 50 Copyright © 2025, Naohiro Fujie, All Rights Reserved Issuer Holder Verifier Verifiable Data Registry（公開鍵等の情報を保存） ID情報 登録～発行 デジタル署名 行政/キャリア/企業 など 個人のID Wallet アプリケーション ID情報の提示 発行者へ問い合わせが 発生しない 利用者の意思で選択的 情報開示を行う 直接の接続がない 署名検証 公開鍵等の登録 公開鍵等の登録 ※IHV: Issuer, Holder, Verifier
51. 世界が注目・実際に動き始めている NIST SP800-63-4では組み込まれる見込み カリフォルニア州等のデジタル運転免許証（mDL） EUにおける国民ID、学修歴、パスポートへの展開（eIDAS2.0） 内閣官房Trusted Web推進協議会～デジタル庁DIWプロジェクト 相互運用性と包摂を目指した動き 人口動態、ボーダーレスの移動やデータ流通を見据えたグローバルの動き DFFT（Data Free Flow with Trust）：2019年ダボス会議～G20首脳宣言 SIDI Hub：持続可能で相互運用性のあるデジタルアイデンティティの実現を目指したグロー バルイニシアティブ IHVモデルへの流れ 51 Copyright © 2025, Naohiro Fujie, All Rights Reserved
52. ID基盤のパラダイム変化 52 Copyright © 2025, Naohiro Fujie, All Rights Reserved ✓ ID管理は最低限 → ID管理は利用者側へシフト ✓ 本人確認（eKYC等）によるIDリカバリが重要 ✓ 提供するIDサービス（認証等）も最低限 → 影響度低 ✓ サービスとID基盤が疎結合 → スケールしやすい、他の ID情報も合わせて利用できる ✓ 利用者のIDの維持が重要 ✓ 滅多にログインしないユーザでもID維持が必要 ✓ 利用者へIDサービス（認証等）を提供 → 可用性が大切 ✓ サービスとID基盤が密結合 → スケールしにくい、自ID基 盤で確認したID以外の情報は利用できない ID基盤 サービス ID管理 管理者 利用者 利用者 頻度低 攻撃者 ID搾取 ID連携（密結合） なりす まし サービス 利用 認証 滅多に使わない人の IDも維持・管理が必要 （ライセンス費用増） 滅多に使わない人の 認証情報は漏洩しても 気が付きにくい （リスク増） ID基盤 サービス ID管理 管理者 利用者 利用者 頻度低 ID情報 ID連携不要（疎結合） サービス 利用 最低限のID管理で十分 （ライセンス最適化、 リスク低減） ID情報を個人に持たせ る＝ロストした場合の リカバリが必要 （本人確認） ID発行 /取消 ID情報 本人確認 ～リカバリ 従来のID基盤 検証可能な資格情報による変化 ID情報 他のID基盤が発行 したID情報
53. ID基盤のパラダイム変化 53 Copyright © 2025, Naohiro Fujie, All Rights Reserved ✓ ID管理は最低限 → ID管理は利用者側へシフト ✓ 本人確認（eKYC等）によるIDリカバリが重要 ✓ 提供するIDサービス（認証等）も最低限 → 影響度低 ✓ サービスとID基盤が疎結合 → スケールしやすい、他の ID情報も合わせて利用できる ✓ 利用者のIDの維持が重要 ✓ 滅多にログインしないユーザでもID維持が必要 ✓ 利用者へIDサービス（認証等）を提供 → 可用性が大切 ✓ サービスとID基盤が密結合 → スケールしにくい、自ID基 盤で確認したID以外の情報は利用できない ID基盤 サービス ID管理 管理者 利用者 利用者 頻度低 攻撃者 ID搾取 ID連携（密結合） なりす まし サービス 利用 認証 滅多に使わない人の IDも維持・管理が必要 （ライセンス費用増） 滅多に使わない人の 認証情報は漏洩しても 気が付きにくい （リスク増） ID基盤 サービス ID管理 管理者 利用者 利用者 頻度低 ID情報 ID連携不要（疎結合） サービス 利用 最低限のID管理で十分 （ライセンス最適化、 リスク低減） ID情報を個人に持たせ る＝ロストした場合の リカバリが必要 （本人確認） ID発行 /取消 ID情報 本人確認 ～リカバリ 従来のID基盤 検証可能な資格情報による変化 ID情報 他のID基盤が発行 したID情報 卒業生、研究者のID管理シナリオ • 過去に在籍したことの証明 • 卒業・離籍後も大学に残した研究データへ継続的にアクセス許可 サプライチェーンのID管理シナリオ • 企業への所属証明、アクセス権限の証明 • OEM企業側でのID管理・パスワード管理の手間を大幅に削減 顧客、自治体における個人ID管理シナリオ • SNSを使った簡易ID登録と身元保証の両立、事業者への依存度低減 • 年齢等の身元確認（公的な身分証明の電子化） 従業員、学生のID管理シナリオ • 入社、入学時の身元確認（公的な身分証明の電子化） • パスワードレス、オンラインでのアカウント払い出し
54. 利用者がID情報をWalletに入れて持ち運ぶ Walletの信頼性（そのWalletにID情報を発行して安心できるのか？） クレデンシャルの目的が多岐にわたる 資格証明と身分証明？ 目的によってはHolderとの紐付けを厳密に検証できるようにしないといけない どんなVerifierへクレデンシャルを渡すべきなのか？ 利用者の自己責任として良いのか？ など 従来のIDモデルとは異なる考慮点 54 Copyright © 2025, Naohiro Fujie, All Rights Reserved
55. https://dal.sfc.keio.ac.jp/ja/TR/management-requirements-for-digital-credentials/ ディスカッションペーパー with 慶應
56. アーキテクチャ概要 56
57. 既存のトラストフレームワークの拡張検討 with NII 57 Copyright © 2025, Naohiro Fujie, All Rights Reserved 学術機関 Issuer 認定サービス Verifier ウォレットプロバイダー ウォレットインスタンス 例 在学証明書 Status List プロバイダー 利用者 提供・維持 使用・有効化 参照 登録・維持 発行 提示 参照 トラストリスト プロバイダー 参照 非認定サービス Verifier 例 在学証明書 教育資格基準準拠 教育機関レポジトリー 質評価機関 Trust Framework Qualification Framework 信頼評価機関 評価を実施し、参加エンティティが定められた 基準に準拠して運用していることを担保 教育資格基準 への準拠品質 参加エンティティ運用基準への準拠品質 Framework の保証対象 関連する Framework と そのエンティティ 学術機関 Issuerを 運営する 機関が 定められた 教育資格 基準を 満たすことの 信頼アンカー としてQF を参照 評価を実施し、学術機関が定められた 教育資格基準に準拠していることを担保
58. ビジネス遂行において組織の信頼性を担保するためにID 管理をしっかり固めることは非常に重要 一方でID基盤を導入する際は、業務の重要性などを考 慮して統合対象を絞り込むことも重要 また標準技術仕様への準拠することは相互運用性やセ キュリティ面からも非常に重要 境界の変化に伴いIHVモデルに注目が集まるが、安全に 運用するための新たな考慮点も多く、研究が進む まとめ 58 Copyright © 2025, Naohiro Fujie, All Rights Reserved