$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
多様なデジタルアイデンティティを攻撃からどうやって守るのか / 20251212
Search
Ayokura
December 12, 2025
Technology
0
130
多様なデジタルアイデンティティを攻撃からどうやって守るのか / 20251212
2025/12/12 「行く年、来る年、年忘れセキュリティ 2025」 での発表スライドです。
Ayokura
December 12, 2025
Tweet
Share
More Decks by Ayokura
See All by Ayokura
デジタルアイデンティティの技術を学ぼう!~認証認可にまつわる標準仕様文書を読んでみよう~ / OpenID Summit Tokyo 2024
ayokura
0
1.1k
WWDC 2020 参加報告 ~ Sign in with Apple & WebAuthn まわりを中心に #openid #technight / openid-technight-17-wwdc20
ayokura
0
1.3k
公開情報から読むCloud-assisted BLE(caBLE)をつかったWebAuthn
ayokura
2
5.7k
CIBA詳細とCIBAで実現する社会を考えてみたかった / OpenID TechNight Vol.16 LT
ayokura
1
2.4k
Other Decks in Technology
See All in Technology
Ruby で作る大規模イベントネットワーク構築・運用支援システム TTDB
taketo1113
1
190
ログ管理の新たな可能性?CloudWatchの新機能をご紹介
ikumi_ono
0
460
A Compass of Thought: Guiding the Future of Test Automation ( #jassttokai25 , #jassttokai )
teyamagu
PRO
1
240
第4回 「メタデータ通り」 リアル開催
datayokocho
0
110
生成AI・AIエージェント時代、データサイエンティストは何をする人なのか?そして、今学生であるあなたは何を学ぶべきか?
kuri8ive
2
2.1k
20251209_WAKECareer_生成AIを活用した設計・開発プロセス
syobochim
5
1.3k
LLM-Readyなデータ基盤を高速に構築するためのアジャイルデータモデリングの実例
kashira
0
210
Uncertainty in the LLM era - Science, more than scale
gaelvaroquaux
0
790
Kubernetes Multi-tenancy: Principles and Practices for Large Scale Internal Platforms
hhiroshell
0
110
Bakuraku Engineering Team Deck
layerx
PRO
12
7k
品質のための共通認識
kakehashi
PRO
1
190
Gemini でコードレビュー知見を見える化
zozotech
PRO
1
180
Featured
See All Featured
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.1k
Practical Orchestrator
shlominoach
190
11k
The Language of Interfaces
destraynor
162
25k
Docker and Python
trallard
47
3.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
Six Lessons from altMBA
skipperchong
29
4.1k
Build your cross-platform service in a week with App Engine
jlugia
234
18k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
1.8k
jQuery: Nuts, Bolts and Bling
dougneiner
65
8.2k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
How to Ace a Technical Interview
jacobian
280
24k
Transcript
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
1 GMOサイバーセキュリティ byイエラエ株式会社 サイバーセキュリティ事業本部 高度解析部 高度解析課 名古屋 謙彦 (あよくら @ayokura) 多様なデジタルアイデンティティを 攻撃からどうやって守るのか
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
2 ID? • IDってとっても多義的な用語なので、今回使いません! • 以下のいずれを表すこともあるし、会話でも混ざる ‒ Digital Identity • 特定の存在をユニークに表現できる、属性や属性の集合 ‒ 僕が僕であることを、君が君であることを示せる内容 ‒ 記録がどんどん増えていくことで形成されていくもの、とも言えるかも • デジタルIDって言った場合は基本これではある ‒ Identifier • 何らかの単一の識別子属性。何らかの前提を置いた中ではユニーク • データベースとかAPIで見るid属性は大抵これ ‒ Identity Document • 身元確認書類や身分証明書ともいわれる、誰かを証明する書類 • 英語で大文字IDの場合はこれが多い気がする
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
3 自己紹介 ▪基本属性 姓名 名古屋 謙彦 (なごや よしひこ) 所属 サイバーセキュリティ事業本部 高度解析部 高度解析課 (他にOpenID Foundation Japan で事務局のお手伝いもしています) ▪その他の属性 Twitter(X) あよくら @ayokura BlueSky @ayokura.net Discord @ayokura 属性タグ CISSP/クリスチャン 経歴 インフラエンジニア・情シス →アイデンティティアーキテクト → + セキュリティコンサルタント デジタルアイデンティティ大好き! エンジニアではない人でも簡単・安全にインターネットを利用できるように、 デジタルアイデンティティやFederationなどの技術の適切な利用を広めていきたいです
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
4 デジタルアイデンティティとの出会い • その1 ‒ 中学生のころにMMORPG等のハンドルネームやアバターの文化にはまる ‒ その後も、Twitterを活用したり、あるいはVTuberにはまったりする • いわゆる仮名のアカウント・デジタルアイデンティティを、サービス間をまた いだり、サービスの寿命を超えて維持する等について、強く関心がある • その2 ‒ 小学校時代の転校や、大学で関東に戻ったりなどで、身近な人たちが物理的 な距離が離れることがあった ‒ どうせなら身近な人たちが安全にIT技術に触れてほしい • 鍵になったのが認証やFederationの技術
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
5 デジタルアイデンティティと出会って 学ぶうちに、なんか違くない?なんかいろいろある…???というギャップが • いろいろ前提が違う世界がある ‒ 組織内の管理基盤や、それとつながるKerberos / SAML / OIDC等のエン プラ用途でのサービス ‒ 戸籍上の自分と1:1対応する前提の設計のサービス • 実はずっと考えると問題がある ‒ 一つのIdPに集約させて、ソーシャルログインを使う • アカウント凍結時の問題や、Twitterのようにフェデレーションを縮小する等 ‒ 自分自身で管理するモデル(Self-Sovereign Identity) • 結局、人類すべてが秘密鍵を自己管理できないといけなくて無理では…? ‒ そもそも複数のサービスをまたいで自己証明し続けるの困難では
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
6 今日の内容 • サービス内のアカウント種別ごとに、セキュリティを考えていくことでより安全にでき たら…という、ところを時間が許す範囲でお話しできたらと思っています • ずっと僕が興味持ってる、サービス間をまたいでデジタルアイデンティティというか ペルソナを引き回す話はしません ‒ 逆にいえば、何らかのサービス内にある色んなデジタルアイデンティティの話をします • 今年振り返り的な内容は入れられそうなところは入れようとしてみました • AIとかMCPとかエージェント時代のアイデンティティ管理の話は、ほぼ触れません ‒ 最近の状況なら「Agentic AIのためのアイデンティティ管理」とかがおすすめです • https://www.openid.or.jp/Identity-Management-for-Agentic-AI-jp_v1.1.pdf ‒ あとはこの辺、OIDF-Jでも来週イベントあるのでよかったら • OpenID BizDay #18 ~ AIdentity × Security CollabDay https://openid.connpass.com/event/376275/
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
7 多様なデジタルアイデンティティ(1/3) • 明確に法的な個人と紐づくもの ‒ 法的裏付けが必要な個人(マイナンバー・銀行口座など) • Legal Identityと紐づけるKYC(eKYC)が必要 ‒ 法的な個人と紐づけられつつ、さらに何らかの裏付けある属性と紐づけがある • 所属・公的な保険資格・学位・資格・免許など • 原則が仮名であるもの (X、Discord、ゲーム用のIDとかをはじめいろいろ) ‒ 特定の個人(やデバイス)と紐づいているもの ‒ 複数の個人が共同で使っているもの ‒ 法的な個人と紐づけることがあるもの ‒ 特定の属性だけ裏付けがあるが、個人と紐づけがあるもの
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
8 多様なデジタルアイデンティティ(2/3) • 法人が運用するもの(公式アカウントだったり、 SaaSテナントだったり) ‒ 法人の中の個人を識別・認証して使うもの • GビズID(政府認証基盤)でのプライム・メンバーの個別のアカウント • B2Bで契約しているSaaSでの各ユーザーのアカウント ‒ 法人自体を識別・認証してつかうもの • 公式アカウントや、会社単位契約での共通アカウントなど • GビズIDでのプライム・メンバーをまとめた組織としての概念 • その他継続的に利用できる必要があるもの ‒ 世帯などのグループ ‒ 特定の代理人が入れるもの ‒ 複数アカウントで共同管理されるアカウント ‒ 結びつく対象が不定形な、別の属性に紐づくもの(ドメイン・メールアドレス等)
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
9 多様なデジタルアイデンティティ(3/3) • 匿名 かつ ephemeral (はかなく消えゆくもの) ‒ 有効期限が長いもの • ゲーム・サービスのゲストアカウント ‒ すごいロングなセッションとみることもできる ‒ 日付単位 • 掲示板文化における 「ID」の値(日次でリセットされるIdentifier) ‒ 一回のセッションが終わったら再現できないもの • サポートチャットのセッションとか
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
10 デジタルIDへのサイバー攻撃 • 主要な脅威 ‒ なりすまし (Spoofing) ‒ 情報漏洩 (Information disclosure) ‒ フィッシング • 当該システムではなりすましだが、人間に対する攻撃なので他ケースも • アタックサーフェス的な部分 ‒ サービスに対する攻撃 ‒ 人間に対する、ソーシャルエンジニアリング・フィッシング ‒ 悪意あるアプリ・拡張機能
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
11 デジタルIDでのセキュリティ • デジタルアイデンティティを管理するシステムで守りたい部分 ‒ 利用者本人がサインインできる(そのデジタルアイデンティティになれる) • 複数アカウントを持つ場合は希望するアカウントでサインインできること ‒ 他人がサインインできない(保有しないデジタルアイデンティティになれない) ‒ システム内に存在する、利用者が積み重ねた記録 ‒ プライバシー • 利用者が意図する情報を開示し、意図しない情報を開示しない • (Legal / Digital /Physicalともに)Identity間を意図せずLinkさせない • 教育や運用で解決せざるを得ないものもあるが、ある程度技術で解決したい ‒ この部分を担当課題としているのが、僕の属している界隈
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
12 「多様な」デジタルID x セキュリティ • 単一の種別のIdentityのみが使えるサービスの場合 ‒ そのIdentityで使える最も強い方法を使えばいい • 法的裏付けのある個人のみなら、マイナンバーカード等のIdentity Document自体を使う • 個人の仮名アカウントのみなら、パスキーやFederationを使う • でも、サービスは複数の種類のIdentityの存在を受け入れる場合がある ‒ 意図せずのケースも、意図があってのケースもある • 仮名のみのつもりでも、アメリカでのサービス提供では、13歳未満と推測 できる情報を得た時点で、COPPAによりアカウント凍結が必要 ‒ この後、再度利用させるには法的な裏付けのある年齢確認が必須 • 結果として法的裏付けのある個人になってしまうことも
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
13 「多様な」デジタルID x セキュリティ • でも、サービスは複数の種類のIdentityの存在を受け入れる場合がある(続き) ‒ 安直にレベルを上げようとした場合、以下のようになりがち • それぞれの種類で使える中で最も弱いレベルまでしか上げられない • 特定の運用方法をしている存在が利用できなくなる(共用アカウント等) ‒ 強くしていくためには • 選択肢を作って、どの種別でもより安全な方法が使えるようにする • アカウント種別自体を分けて、それぞれで安全な方法を使ってもらう ‒ そもそも、特定の機能は特定の種別でしか使えなくするのも一応あり • 例えば、アカウントリカバリには、身元確認ができなければいけない、など
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
14 デジタルIDを守る技術 • まず読もうという標準文書が2025年に二つほど出たので紹介します ‒ NIST SP 800-63-4 Digital Identity Guidelines • Version 4が出ました ‒ DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱 いに関するガイドライン • 個人的に紹介したくて最近パスキーの話もします。 ‒ パスキーの概要は絶対話す時間がないので、最近気になっているパスキーの アップデートの話をちょっと紹介します。
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
15 NIST SP800-63 Digital Identity Guidelines NIST SP800-63は、アメリカ政府の研究所であるNISTが策定した電子的認証のガイドラインです。 これまで2017年6月発行のversion 3が利用されていましたが、version 4 が2025年8月1日に公開さ れました。(2020年から検討が始まり、2022年と2024年にDraftが公開されるなど、5年間かけて作成さ れたものです ) Digital Identity Modelを3つのフェイズ(Identity Proofing、Authentication、Federation)にわけて、 全体を説明するBase文書と3つの子文書からなり、守るべき内容や保証レベルを定義しています。 https://pages.nist.gov/800-63-4/ 子文書 定義されるレベル 説明 SP 800-63-4A 身元保証レベル (IAL) ユーザーが自己主張する身元が本人の本物の法的な身元と一致するか の確認( Identity Proofing )をどれくらいの確かさで行うか SP 800-63-4B 認証保証レベル (AAL) すでに登録済みのユーザーが認証(Authentication)を行う際の認証 強度を表す指標 SP 800-63-4C フェデレーション保証 レベル(FAL) Federation時に別のプロバイダから渡されるAssertionをどれくらいセ キュアに転送するかを表す指標
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
16 フィッシング耐性 • 800-63-4Bで、フィッシング耐性(Phishing Resistance)が定義されました ‒ https://pages.nist.gov/800-63-4/sp800-63b.html#verifimpers ‒ 基本的には、これまでの「Verifierへのなりすまし」攻撃をフィッシングとして定 義し、「強力な中間者攻撃耐性」をフィッシング耐性としていますが、フィッシング 耐性とその類型がまとめられたのが特徴です。 • フィッシング耐性がある2種類の方法 ‒ チャネルバインディング(Channel Binding) • ネゴシエート時に構築した認証済みのセキュアチャネルと同一の存在が接 続してきたことを確認できる方法(例: クライアントTLS認証) ‒ 検証者名バインディング(Verifier Name Binding) • 接続先のVerifierが正しいことをプロトコルとして確認できる方法 ‒ 例: パスキー(FIDO/WebAuthn)では、接続先ドメインが確認される
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
17 DS-511 行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン 2025年9月30日に日本のデジタル庁が策定した、日本の行政手続等で利用されることを想定したデジタ ルアイデンティティのガイドラインです (リスク評価とかも入ってます) 従来存在したDS-500-1という文書が、身元確認をメインとしていたのに対して、当人認証やフェデレーショ ンについても取り扱い、日本国の中での保証レベルについての定義など、NIST SP800-63のスコープと 類似する範囲をカバーしつつ、日本独自で考慮が必要な点についても触れている文書になります。 ちなみにデジタル庁では、このDS-511の解説編となる、「DS-512 行政手続等での本人確認におけるデ ジタルアイデンティティの取扱いに関するガイドライン 解説書」を今作成中です。 (作成にかかわる有識者会議の情報は https://www.digital.go.jp/councils/identification-guideline- revise-experts-meeting にあります) https://www.digital.go.jp/resources/standard_guidelines#ds511
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
18 パスキー • パスキー ‒ フィッシング耐性があり、デバイスを落としても使えるように、モバイルデバイス のアカウントに紐づいた同期型の実装が普及しています • 代わりにデバイス紐づけよりはちょっとアタックサーフェスが増えました • 最近気になるところ(できる環境が増えつつあるところ) ‒ シームレスなパスキー作成(Passkeys Automatic Creation) • 対応したパスワードマネージャで入った後、一定時間内は生体認証等不要で登録できる ‒ パスキーのポータビリティ • パスワードマネージャー間でパスキーを移行できるように ‒ https://fidoalliance.org/9to5mac-apple-work-passkey-portability-is-finally-here-in-ios-26-and- macos-tahoe-26/?lang=ja • どうやって安全にやっているのかとか、何がトレードオフになってるとか気になる • (パスキーは普及するための障壁になるものを一つ一つ解決しようとしているのかなとおもいます)
Copyright © GMO Cybersecurity by Ierae, Inc. All Rights Reserved.
19 おわりに • 今日の内容、完全にまとめきれた、とはまったく言えないと思うのですが、デジタル アイデンティティの多様さや、それを守るセキュリティについて少し考えるお時間に なってくれていたら嬉しいです。 ‒ あとデジタルアイデンティティ好きな人がもっと増えてほしい! • 今日話した内容は、生成AI技術によるAIエージェントが普及しきる前の時代の話 です。 ‒ これから、エージェントが、各種のAPIを駆使したり、サブとなるエージェントと協 働したりする時代が来るので、来年も考えることは多くあると思っています • エージェントを認証する技術 • 利用者が意図した範囲を超えさせずにエージェントが情報を処理する ‒ 特に、今のフェデレーションの認可の同意はスケールしなかったり……