top of page
Blog article

Blog article

パスキー：アイデンティティセキュリティの新境地を拓く — フィッシング耐性の先にあるエンドポイントの完全性

エグゼクティブサマリー


パスキーは、認証セキュリティにおける画期的な進歩を象徴するものであり、数十年にわたる課題であったクレデンシャルフィッシングの問題を、堅牢な暗号設計によって効果的に解決する。しかし、この進歩はアイデンティティに対する脅威を根絶するものではなく、攻撃対象領域（アタックサーフェス）を認証イベントそのものから、認証後のセッションおよびユーザーのエンドポイントデバイスへと根本的にシフトさせるものである。

この新しい脅威ランドスケープにおいて、主要な攻撃ベクトルはパスキーの秘密鍵の窃取ではなく、デバイス自体の侵害である。特に情報窃取型マルウェア（インフォスティーラー）を介した攻撃が深刻化しており、攻撃者はユーザーが正規の認証を完了した後に発行されるセッションクッキーやトークンを窃取する。これにより、パスキー認証プロセスを完全に迂回し、正規ユーザーになりすましてアカウントを乗っ取ることが可能となる。

このパラダイムシフトへの戦略的対応として、多層的な防御（Defense in Depth）アプローチが不可欠となる。組織はもはや、「玄関の鍵」である認証の強化のみに注力することはできない。今後は、基盤となるエンドポイントセキュリティの徹底、クレデンシャル登録プロセスの堅牢化、セッション自体の保護、そして動的かつリアルタイムなアクセス制御メカニズムの導入を優先しなければならない。

本レポートは、この移行期におけるCISO（最高情報セキュリティ責任者）レベルのロードマップを提供する。具体的には、エンドポイント検知・対応（EDR）の必要性、デバイスアテステーションの戦略的活用、そして最新のゼロトラストアーキテクチャの重要な構成要素として、デバイスバウンドセッションクレデンシャル（DBSC）や継続的アクセス評価（CAE）といった先進的な標準技術の導入について詳述する。


第1章 パスキーのアーキテクチャ的強度：フィッシング防御におけるパラダイムシフト


パスキーの登場は、単なるパスワードの代替ではなく、オンライン認証のセキュリティモデルを根本から変革するものである。その核心には、従来のフィッシング攻撃を原理的に無効化する、洗練された暗号技術とプロトコル設計が存在する。


1.1 フィッシング耐性のメカニズム：公開鍵暗号とオリジンバインディング


パスキーがフィッシングに対して極めて高い耐性を持つ理由は、その基盤技術である公開鍵暗号方式と、Web標準に組み込まれた厳格なオリジンバインディングにある 1。

アカウント登録時、ユーザーのデバイス（スマートフォンやPCなど）は、そのサービス専用のユニークな鍵ペア（公開鍵と秘密鍵）を生成する 3。このうち、秘密鍵はデバイス内のセキュアな領域（TPMやSecure Enclaveなど）に安全に保管され、決してデバイス外部に出ることはない 5。一方、公開鍵はサービス提供者（リライングパーティ）のサーバーに登録される 4。

この仕組みの最も重要な点は、オリジンバインディングである。生成されたパスキーは、それが登録されたウェブサイトのドメイン（リライングパーティID、rpIDと呼ばれる）と暗号学的に固く結びつけられる 9。ユーザーがログインを試みると、ブラウザやOSは、現在アクセスしているサイトのドメインが、パスキーに紐づけられた

rpIDと完全に一致するかを自動的に検証する 11。

もしユーザーが巧妙なフィッシングサイト（例：正規サイトgoogle.comを模倣したgoogle-login.com）に誘導されたとしても、ブラウザやOSはその不正なドメインに一致するパスキーを見つけられないため、認証プロセスを開始すること自体を拒否する。これにより、セキュリティに関する判断の責任が、間違いを犯しやすい人間から、プロトコルという機械的な仕組みへと移管される。これは、ユーザーに「URLを注意深く確認する」といった認知的な負担を強いることなく、安全性を確保する画期的なアプローチである 2。

この信頼の自動化こそが、パスキーの真の革新性である。公開鍵暗号自体は数十年前から存在する技術だが、それをブラウザやOSレベルでシームレスに統合し、ウェブサイトの同一性検証という最も重要なセキュリティ判断を自動化した点に、フィッシング問題の解決に向けた大きなブレークスルーがある。安全な道筋が最も簡単な道筋となるよう設計されているのである。


1.2 FIDOおよびWebAuthn標準：プロトコルレベルのセキュリティによるクレデンシャル窃取の防止


パスキーは、FIDOアライアンスとW3C（World Wide Web Consortium）によって策定されたオープンスタンダードに基づいている 14。一般的に「パスキー」という用語は、FIDOクレデンシャルのうち、WebAuthnという技術標準上に構築されたものを指す、ユーザーフレンドリーなブランド名である 3。

WebAuthnが定める認証フローは、クレデンシャル窃取をプロトコルレベルで防止する。

  1. チャレンジの要求：ユーザーがログインを試みると、リライングパーティのサーバーは、そのセッションでのみ有効な、推測不可能なランダムなデータ（チャレンジ）を生成し、クライアント（ブラウザ）に送信する。

  2. 署名の生成：クライアントは、デバイス内の認証器（Authenticator）に対し、受け取ったチャレンジに署名するよう要求する。認証器は、ユーザーに生体認証（指紋、顔）やPINの入力を求め、本人確認を行った上で、デバイス内に安全に保管されている秘密鍵を用いてチャレンジにデジタル署名を行う 17。

  3. アサーションの送信と検証：この署名されたデータ（アサーションと呼ばれる）がサーバーに返送される 4。サーバーは、登録済みの公開鍵を使って署名を検証する。検証に成功すれば、クライアントが正しい秘密鍵を保持していること、つまり正規のユーザーであることが証明される。

このプロセス全体を通じて、秘密鍵そのものは一切ネットワーク上を流れないため、中間者攻撃（Man-in-the-Middle attack）によって盗聴されるリスクがない 6。また、チャレンジが毎回ユニークであるため、一度傍受したアサーションを再利用するリプレイ攻撃も無効となる 18。

さらに、パスキーは従来の多要素認証（MFA）の概念そのものを再定義する。従来のMFAは、パスワード入力（知識要素）の後に、SMSで送られてくるワンタイムパスワード（OTP）を入力する（所有要素）といった、複数の独立したステップで構成されていた。しかし、SMS OTP自体がフィッシングの対象となるなど、脆弱性も指摘されていた 15。パスキーは、デバイスの保持（所有要素）と、生体認証やPINによるロック解除（生体要素／知識要素）を、一つのシームレスな操作に統合する 3。これにより、パスキーは単なるパスワードの代替ではなく、旧来のMFAのセキュリティとユーザビリティの課題を同時に解決する、より優れた統合的MFAの代替手段として機能する。


1.3 クレデンシャル再利用とパスワード関連侵害の終焉


パスキーの普及は、長年にわたりサイバーセキュリティの主要な課題であった二つの問題に終止符を打つ可能性を秘めている。

第一に、パスワードの使い回し問題の根絶である。ユーザーは利便性のために同じパスワードを複数のサービスで使い回す傾向があるが、これは一つのサービスで情報漏洩が発生すると、他のサービスのアカウントも連鎖的に危険に晒される「クレデンシャルスタッフィング攻撃」の温床となってきた 15。パスキーは、サービスごとに完全にユニークな鍵ペアが自動生成されるため、この問題を設計レベルで解消する 3。

第二に、サーバーサイドでのデータ侵害の影響を劇的に低減させることである。従来のシステムでは、サービス提供者はユーザーのパスワードハッシュ値をデータベースに保管していた。たとえソルト処理やハッシュ化が適切に行われていても、データベースが侵害されれば、これらのハッシュ値はオフラインでのブルートフォース攻撃の標的となり得た 6。しかし、パスキーのモデルでは、サーバーが保管するのは公開鍵のみである。公開鍵は、その名の通り公開されても問題ない情報であり、それ単体では攻撃者にとって何の価値もない。対応する秘密鍵がなければ認証を突破することは不可能であり、公開鍵から秘密鍵を計算することも現在のコンピュータ技術では事実上不可能である 2。これにより、大規模なデータ侵害が発生しても、ユーザーの認証情報が直接的に危険に晒されるリスクは大幅に低減される。


第2章 暗黙の前提：パスキーのセキュリティと侵害されたエンドポイント


第1章で詳述した通り、パスキーの認証プロトコルは極めて堅牢である。しかし、そのセキュリティモデルは、一つの重大かつ暗黙的な前提の上に成り立っている。それは、「ユーザーのクライアントデバイス（OS、ブラウザ、ハードウェア）が、信頼できる状態にある」という前提である 23。この前提が崩れたとき、パスキーの強固な防御は迂回され、新たな脅威が現実のものとなる。


2.1 戦場のシフト：サーバーとネットワークからクライアントデバイスへ


パスキーは、認証情報の窃取を目的とした攻撃の主戦場を、サーバーやネットワーク経路から、ユーザーのエンドポイントデバイスそのものへと移行させた。ユーザーからの問い合わせのきっかけとなった「デバイス感染には無力」という指摘は、この本質を的確に捉えている 24。パスキーは認証という「儀式」を保護するものであり、その儀式が行われる「場」であるデバイスがマルウェアによって既に汚染されている場合、その保護機能は及ばない。

攻撃者の視点から見れば、パスキーの導入は、フィッシングやパスワードクラッキングといった従来の攻撃手法を非効率化させた。その結果、攻撃の労力は、侵害がより容易で、かつ効果的なエンドポイントデバイスの掌握へと集中することになる。


2.2 パスキーがマルウェアに「無力」な理由：認証後の死角


デバイスに感染したマルウェアは、パスキーの秘密鍵を直接盗み出す必要はない。多くの場合、それは技術的に困難であり、また非効率的である。代わりに、マルウェアはユーザーがパスキーを使って正規の認証を完了するのを待ち、その結果としてサーバーから発行されるセッションクッキーや認証トークンを窃取する 19。

これらのセッショントークンは、多くの場合「ベアラートークン」として機能する。これは、トークンを保持している者（bearer）が正規の認証済みユーザーであるとサーバー側が見なす仕組みである。攻撃者は、窃取したこのトークンを自身のブラウザにインポートし、標的のサービスにアクセスする。サーバー側から見れば、これは有効なセッショントークンを持つ正規のユーザーからのリクエストにしか見えないため、パスキーやMFAによる再認証を要求することなく、アクセスを許可してしまう 23。これがセッションハイジャック攻撃の本質であり、パスキーが作り出した「認証後の死角」を突く攻撃手法である。

この攻撃モデルの変化は、セキュリティの考え方に重要な示唆を与える。攻撃者の目的は、もはや「ユーザー本人であると証明すること（認証）」ではなく、「既に認証されたユーザーの権限を奪うこと（認可の悪用）」へとシフトしている。パスキーは認証を強固にするが、一度確立された認可（セッション）の保護は、そのプロトコルの直接的な責務の範囲外なのである。


2.3 脅威インテリジェンスの洞察：インフォスティーラーの台頭


この理論的な脅威は、既に現実世界で大規模に展開されている。Constella Intelligence社の脅威インテリジェンスレポートは、この新たな攻撃トレンドを明確に示している 23。

サイバー犯罪は産業化しており、Lumma、Raccoon、RedLineといった情報窃取型マルウェア（インフォスティーラー）が、サービスとしてのマルウェア（MaaS）としてアンダーグラウンド市場で広く販売されている 23。これにより、高度な技術を持たない攻撃者でも、容易に大規模な攻撃キャンペーンを展開できるようになった。

これらのインフォスティーラーは、感染したデバイスのブラウザやアプリケーションのローカルストレージを標的とし、パスワードだけでなく、認証トークンやセッションクッキーを積極的に収集する 23。Constella社の調査では、1年間で数千万件ものインフォスティーラーのログがダークウェブ市場で流通しており、その中には企業の役員や開発者、システム管理者のアカウントに紐づくセッショントークンが多数含まれていたことが確認されている 23。

これは、攻撃者がすでにパスキーの普及を見越して戦術を適応させていることを示唆している。彼らの戦略は「侵入するのではなく、ログインする」というものであり、窃取したセッションアーティファクトを再利用することで、強固な認証システムを無力化しているのである 23。

この状況は、パスキーの導入が、意図せずしてセッショントークンの価値を高めてしまったという側面を浮き彫りにする。パスワード窃取やフィッシングという攻撃経路が閉ざされつつある今、攻撃者にとってセッショントークンは、アカウント乗っ取りを実現するための最も価値ある標的の一つとなった。その結果、インフォスティーラーの開発と流通に対する経済的インセンティブは、かつてないほど高まっている。


第3章 パスキーエコシステムに対する現代的脅威の分類


パスキーのセキュリティモデルは、特定の攻撃ベクトルに対しては非常に強力だが、万能ではない。攻撃者はプロトコルの弱点を突くのではなく、プロトコルが動作する環境（エンドポイント、ブラウザ）や、プロトコルが利用されるプロセス（登録、回復）の脆弱性を狙う。本章では、パスキーエコシステムに対する現代的な脅威を体系的に分類し、その手口と影響を詳述する。


3.1 セッションハイジャック：インフォスティーラーマルウェアによる主要攻撃ベクトル


  • メカニズム：これは現在、パスキー環境における最も現実的かつ深刻な脅威である。攻撃者は、フィッシングメールの添付ファイル、悪意のある広告（マルバタイジング）、海賊版ソフトウェアなどを通じて、ユーザーのデバイスにインフォスティーラーを感染させる 23。デバイスに常駐したマルウェアは、ユーザーがパスキーで正常に認証を完了し、サービスとの間でセッションが確立されるのを待つ。そして、ブラウザのクッキーストアやアプリケーションのローカルストレージに保存されているアクティブなセッショントークンやクッキーを抽出し、攻撃者のC2（Command and Control）サーバーに送信する 33。

  • 影響：攻撃者は窃取したセッショントークンを自身のブラウザにインポートすることで、正規ユーザーになりすますことができる。サーバー側は有効なトークンを持つリクエストとして処理するため、パスキーによる再認証やMFAを要求することなく、アカウントへの完全なアクセスを許してしまう 23。この攻撃は、認証が完了した「後」のセッションを標的とするため、パスキーの認証プロトコル自体は一切関与せず、その防御機構は完全にバイパスされる。従来のログインページを監視するような防御策では検知が困難である 23。


3.2 ブラウザレベルの攻撃：悪意のある拡張機能とWebAuthn APIの傍受


  • メカニズム：ブラウザは、リライングパーティと認証器との間の通信を仲介する重要な役割を担うが、それ自体が攻撃対象となり得る。DEF CONなどのセキュリティカンファレンスで発表された研究では、悪意のあるブラウザ拡張機能や、ウェブサイトのクライアントサイドの脆弱性（例：クロスサイトスクリプティング、XSS）を悪用することで、WebAuthn APIの呼び出しを傍受・改ざんできることが示されている 36。

  • 攻撃シナリオ：

  • 登録ハイジャック：攻撃者は、ユーザーが正規のサイトでパスキーを登録しようとするプロセスに介在し、ユーザーの公開鍵を自身の公開鍵にすり替える。これにより、被害者のアカウントに攻撃者自身のパスキーが登録されてしまう 9。

  • 認証の傍受（クリックジャッキング）：攻撃者は、透明なiframeなどのクリックジャッキング技術を用いて、ユーザーに見えない形で悪意のある操作を実行させる。ユーザーが正規の操作（例：「OK」ボタンのクリック）をしていると信じ込んでいる裏で、実際には攻撃者が用意した別の認証要求に対してパスキーによる署名（アサーション）を行わせてしまう。攻撃者はこの署名済みのアサーションを窃取し、アカウントの乗っ取りに利用する 37。

  • プロンプトの偽装：攻撃者は、OSやブラウザが通常表示する生体認証のプロンプトと全く同じ見た目の偽のプロンプトを画面に表示させることができる。ユーザーがこれに気づかずに認証操作を行うと、その認証情報が悪意のある行為の承認に使われてしまう 36。


3.3 実装および登録プロセスの脆弱性


  • メカニズム：プロトコルの安全性は、その実装の安全性に依存する。リライングパーティによる不適切な実装は、深刻な脆弱性を生む可能性がある。特に危険なのが、パスキーの登録フローを悪用する攻撃である。例えば、攻撃者はフィッシングなどを用いて、まだパスワード認証を利用しているユーザーを騙し、そのアカウントに攻撃者自身のデバイスやセキュリティキーをパスキーとして登録させる 9。

  • 影響：一度攻撃者のパスキーが登録されてしまうと、攻撃者はそのアカウントに対して、フィッシング耐性を持つ極めて強固なアクセス手段を手に入れることになる。これは、認証フローだけでなく、新規登録、認証手段の追加、アカウント回復といった、IDライフサイクル全体のセキュリティを確保することの重要性を示している 9。もし、アカウント回復手段としてSMS OTPのようなフィッシング可能なレガシーな方法が残されている場合、そこがシステムの最も脆弱な環（ウィーケストリンク）となり、攻撃者はそこを突破口としてアカウントを乗っ取り、自身のパスキーを登録しようと試みるだろう 43。


3.4 物理的および近接攻撃ベクトル


  • デバイスの盗難：最も直接的な物理的脅威である。攻撃者がユーザーのデバイス（特にスマートフォン）を盗み、画面ロック（PIN、パスコード、パターン）を何らかの方法で突破できた場合（例：ショルダーサーフィンによる盗み見、脅迫）、そのデバイス上で利用可能な、あるいはクラウド経由で同期されている全てのパスキーにアクセス可能となる 8。これは、デバイスのローカル認証が、パスキーセキュリティの最後の砦であることを意味する。

  • 近接攻撃（Bluetooth LE）：セキュリティ研究者Tobia Righiによって発見された（現在は修正済み）高度な攻撃ベクトルは、将来の脅威モデルを考える上で重要である 47。この攻撃では、攻撃者は被害者のBluetooth LEの通信範囲内（約70-100m）にRaspberry Piのような小型の不正ハードウェアを設置する。このデバイスが中間者として動作し、例えば偽のフリーWi-Fiのログインページを装って被害者を騙し、被害者のスマートフォンに攻撃者のデバイスを認証させる。これは、QRコードを介したデバイス連携フローで用いられる


    FIDO:/というURIスキームが、直接ブラウザで開けてしまう脆弱性を悪用したものだった 47。この脆弱性は各ブラウザベンダーによって修正されたが、ハードウェアを利用した近接中間者攻撃の可能性を実証した例として注目される。

これらの脅威分類から、パスキーの導入によって、攻撃者の関心が「認証情報の窃取」から「セッションの乗っ取り」や「認証プロセスの悪用」へと移行していることがわかる。特に、同期型パスキーの利便性は、セキュリティ上のトレードオフを伴う。一つのデバイスが侵害されると、そのユーザーのデジタルライフ全体が危険に晒される可能性があるため、エコシステム内の最もセキュリティが低いデバイスが、全体のセキュリティレベルを決定づけてしまうという「ウィーケストリンク問題」が顕在化する 49。


第4章 レジリエントなセキュリティ態勢の構築：多層防御フレームワーク


パスキーがもたらした脅威のパラダイムシフトに対応するためには、単一のソリューションに依存するのではなく、複数の防御層を組み合わせた包括的なセキュリティ戦略、すなわち「多層防御（Defense in Depth）」が不可欠である。本章では、ユーザーからの「どう対応するか」という問いに直接答えるべく、基盤となるエンドポイントの衛生管理から、最先端のセッション保護技術に至るまでの4つの防御層からなるレジリエントなフレームワークを提示する。


4.1 第1層：基盤となるエンドポイントの衛生管理


  • 基本原則：これは議論の余地のない絶対的なベースラインである。主要な攻撃ベクトルがデバイスの侵害である以上、最も重要な防御策はエンドポイント自体の保護強化に他ならない 23。

  • 構成要素：

  • エンドポイント検知・対応（EDR）：従来のシグネチャベースのアンチウイルスソフトを超え、プロセスの挙動を監視・分析するEDRの導入は、インフォスティーラーやプロセスインジェクションといった高度なマルウェアを検知するために不可欠である 25。

  • 徹底したパッチ管理：OS、ブラウザ、各種アプリケーションを常に最新の状態に保ち、マルウェアが初期侵入に悪用する脆弱性を迅速に塞ぐことが極めて重要である 52。

  • ユーザーの意識向上とトレーニング：マルウェアを配布するフィッシングメールや不正なダウンロードサイトをユーザー自身が認識し、回避できるようにするための継続的な教育が求められる。海賊版ソフトウェアの使用を禁止するなど、明確なポリシーの策定と周知も重要である 53。

  • セキュアなデバイス構成：強力な画面ロック（生体認証やPIN）の強制、ファイアウォールの有効化、不要な管理者権限の剥奪といった基本的なセキュリティ設定を徹底することが、侵害の拡大を防ぐ上で効果的である 17。


4.2 第2層：デバイスアテステーションによる登録プロセスの堅牢化


  • 基本原則：パスキーを作成する「前」に、その認証器が信頼できるものであることを暗号学的に証明させる。デバイスアテステーションは、認証器がその製造元、モデル、セキュリティ機能（例：セキュアハードウェアの有無）、証明書レベルといった特性を、登録時にリライングパーティに対して証明するプロセスである 57。

  • 実装：

  • FIDOアテステーション形式：WebAuthn標準では、none（アテステーションを要求しない）、indirect（匿名化されたアテステーションを許容）、direct（認証器からの直接的なアテステーションを要求）といった複数のアテステーション伝達モードが定義されている 59。高セキュリティが求められる企業のユースケースでは、


    directアテステーションを要求し、かつ信頼できる認証器のリスト（AAGUIDと呼ばれる一意な識別子で管理）に含まれるもののみ登録を許可するポリシーを適用することで、脆弱なソフトウェアベースのキーや信頼性の低いデバイスが登録されるのを防ぐことができる 57。

  • プラットフォーム固有のアテステーション：Appleの「管理対象デバイスアテステーション」や「App Attest」、Googleの「Play Integrity API」といったプラットフォーム固有の機能を活用することで、ハードウェアの真正性だけでなく、OSやアプリケーションの完全性（改ざんされていないこと）まで検証できる 63。これらの強力なシグナルは、ゼロトラストアーキテクチャにおけるデバイスの信頼性評価に不可欠な要素となる。


4.3 第3層：デバイスバウンドセッションクレデンシャル（DBSC）によるセッションの保護


  • 基本原則：セッションハイジャックの脅威に直接対抗するため、セッショントークンをデバイスのハードウェアに暗号学的に紐付ける。これにより、たとえセッションクッキーが窃取されたとしても、攻撃者のマシンでは無効となり、悪用を防ぐことができる 66。

  • 技術的フロー：現在W3Cで標準化が進められているDBSCプロトコルは、以下のように動作する 66。

  • ログイン時、ブラウザは新しい公開鍵と秘密鍵のペアを生成し、秘密鍵をTPMなどのセキュアなハードウェア内に格納する 67。

  • サーバーは公開鍵を受け取り、従来のような長期間有効なセッションクッキーの代わりに、有効期間の短い（例：10分）クッキーを発行する。

  • 短命なクッキーが失効すると、ブラウザはユーザーには見えない形で、サーバーが指定した更新用エンドポイントと通信する。サーバーはチャレンジを発行し、ブラウザはDBSCの秘密鍵でそれに署名することで、元のデバイスを保持していることを証明する。検証に成功すると、新しい短命なクッキーが発行される 71。

  • 戦略的重要性：DBSCは、第3.1節で詳述したインフォスティーラーによるセッションハイジャックという主要な脅威に対する、最も直接的かつ効果的な技術的対抗策である。この技術は、クッキー窃取を基盤とするサイバー犯罪エコシステム全体を破壊することを目的としている 67。


4.4 第4層：継続的アクセス評価（CAE）による動的な対応


  • 基本原則：認証と信頼を、ログイン時の一回限りのイベントではなく、継続的なプロセスとして捉える。CAEは、リスクシグナルに基づいて、ほぼリアルタイムでセッションを無効化することを可能にするメカニズムである 72。

  • トリガーとメカニズム：Microsoft Entra IDなどのエコシステムで実装されているCAEは、以下のような重大なイベントが発生した場合にセッションを即座に失効させることができる。

  • ユーザーアカウントが無効化された、またはパスワードが変更された。

  • ID保護サービスによって高リスクなサインインが検知された。

  • ユーザーのデバイスが、信頼できるネットワークロケーションから信頼できない場所へ移動した 73。

  • パスキー環境における役割：CAEは、極めて重要なバックエンドの防御機能を提供する。例えば、EDRシステム（第1層）がデバイス上でマルウェアを検知し、そのユーザーアカウントを「高リスク」としてフラグを立てた場合、CAEはそのシグナルを受け取り、そのユーザーに関連する全てのアクティブなセッションを即座に終了させることができる。これにより、セッショントークンが既に窃取されていたとしても、その被害を最小限に食い止めることが可能となる。

これらの4つの防御層は、組織のセキュリティ成熟度に応じた導入ロードマップを形成する。第1層のエンドポイント衛生管理は全ての組織にとっての必須項目であり、第2層のアテステーションは中〜高レベルのセキュリティ要件を持つ組織にとっての次なるステップである。そして、第3層のDBSCと第4層のCAEは、最も高度なセッションベースの攻撃に対抗するための最先端の防御策であり、これからのセキュリティアーキテクチャの中核を担う技術となる。これらの層は独立して機能するだけでなく、相互に連携することで、より強固でレジリエントなセキュリティエコシステムを構築する。例えば、EDR（第1層）の検知情報をCAE（第4層）がトリガーとして利用し、DBSC（第3層）がトークンの悪用を防ぐといったように、一つの防御層の突破を他の層が補完する、真の多層防御が実現されるのである。

表1: パスキーの脅威ベクトルと多層防御マトリクス

脅威ベクトル

第1層: エンドポイントセキュリティ (EDR/AV)

第2層: デバイスアテステーション

第3層: セッションバインディング (DBSC)

第4層: 継続的アクセス評価 (CAE)

第5層: ユーザー教育とポリシー

インフォスティーラー (セッションハイジャック)

主要 マルウェアの検知・駆除

二次的 信頼できないデバイスの登録を防止

主要 窃取されたトークンの再利用をブロック

主要 侵害検知後にセッションをリアルタイムで失効

二次的 マルウェア感染の初期段階を防止

悪意のあるブラウザ拡張機能 (APIハイジャック)

主要 悪意のある拡張機能のインストールを検知・ブロック

二次的 信頼できない環境からの登録を防止

部分的 セッション確立後のトークン保護に有効

二次的 異常なAPI利用パターンを検知した場合にセッションを失効

主要 信頼できない拡張機能のインストールを禁止

登録フローの悪用

部分的 攻撃の前提となるフィッシング等を検知

主要 認証器の真正性を検証し、不正な登録をブロック

対象外

対象外

主要 強固なアカウント回復プロセスの徹底

物理的なデバイス盗難

部分的 デバイスロックの強制

対象外

対象外

二次的 盗難報告後にセッションを失効

主要 強力なデバイスロックと紛失時の報告手順を規定

近接攻撃 (例: BLE MitM)

対象外

部分的 認証器の特性を検証

対象外

二次的 異常な場所からのアクセスとして検知しセッションを失効

二次的 不審なWi-Fi等への接続を避けるよう教育


第5章 実装とガバナンスのための戦略的提言


パスキーを安全かつ効果的に組織へ導入するためには、技術的な実装だけでなく、戦略的な意思決定と明確なガバナンスが不可欠である。本章では、企業のCISOと個人ユーザー、それぞれの視点から、実践的な推奨事項を提示する。


5.1 企業向け：CISOのためのセキュアなパスキー導入ロードマップ



5.1.1 最適なツールの選択：同期型パスキー vs. デバイスバウンドパスキー


パスキーには大きく分けて二つのタイプが存在し、それぞれに異なるセキュリティ特性とユースケースがある。組織はリスクベースのアプローチに基づき、これらのタイプを戦略的に使い分ける必要がある 21。

  • 同期型パスキー（Synced Passkeys）：AppleのiCloudキーチェーンやGoogleパスワードマネージャーなどに保存され、同じアカウントに紐づく複数のデバイス間で自動的に同期されるパスキー。

  • 利点：ユーザーエクスペリエンスに優れ、デバイスを紛失・交換した際の回復が容易であるため、一般従業員への大規模展開に適している 77。

  • リスク：セキュリティはクラウドアカウント（Apple IDやGoogleアカウント）のセキュリティ強度と、同期グループ内で最も脆弱なデバイスのセキュリティレベルに依存する。クラウドサービス自体の侵害や、管理の甘い個人デバイスの侵害が、企業リソースへのアクセスに繋がるリスクを内包する 46。

  • デバイスバウンドパスキー（Device-Bound Passkeys）：YubiKeyのような物理的なセキュリティキーや、デバイスのTPM内に生成され、その特定のハードウェアからエクスポート（コピー）することができないパスキー。

  • 利点：秘密鍵が物理的に隔離されているため、最高レベルのセキュリティ保証を提供する。クラウドアカウントの乗っ取りや、デバイスに感染したマルウェアによる鍵の窃取に対して極めて高い耐性を持つ 80。

  • リスク：利便性に劣り、紛失時の回復プロセスが複雑になる可能性がある。また、物理デバイスの配布・管理コストがかかるため、全従業員への展開は非現実的な場合が多い 81。

この二元性から導かれる戦略は、画一的な導入ではなく、階層的なセキュリティモデルの構築である。一般従業員が日常的に利用するアプリケーションには利便性の高い「同期型パスキー」を許可し、一方で、システム管理者や役員、機密情報を取り扱う研究者といった特権ユーザーには、最高レベルの保証を提供する「デバイスバウンドパスキー」の使用を義務付ける。このリスクに応じた使い分けこそが、ゼロトラストの原則に合致した現実的なアプローチである。

表2: 同期型パスキーとデバイスバウンドパスキーの戦略的比較

属性

同期型パスキー (Synced Passkeys)

デバイスバウンドパスキー (Device-Bound Passkeys)

セキュリティモデル

クラウドプロバイダーとエコシステム内の全デバイスの信頼性に依存

単一の物理ハードウェアの信頼性に依存。鍵のエクスポートは不可。

主要な脅威ベクトル

クラウドアカウントの乗っ取り、同期グループ内の最も脆弱なデバイスの侵害

物理的なデバイスの紛失・盗難、物理的アクセス

ユーザー利便性

高い：デバイス間で自動同期され、シームレスな利用が可能

低い：認証の都度、物理的なデバイスの操作（接続、タッチ）が必要

回復メカニズム

容易：クラウドプロバイダーの回復フロー（例: iCloudキーチェーンエスクロー）を通じて回復可能

複雑：バックアップ用のキーを別途登録しておく必要がある。紛失した場合、アカウント回復プロセスが必要。

展開のスケーラビリティ

高い：ユーザーが自身のデバイスで容易に作成・管理できる

低い：物理デバイスの調達、配布、ライフサイクル管理が必要

保証レベル

中〜高

最高

推奨ユースケース

一般従業員の業務アプリケーション、顧客向けサービス

特権ID管理（管理者、開発者）、機密データへのアクセス、規制遵守が求められる環境


5.1.2 ゼロトラストアーキテクチャへの統合


パスキーは、「決して信頼せず、常に検証する（Never Trust, Always Verify）」というゼロトラストの基本理念を実現するための強力な要素となる 83。

  • 強固な本人認証：フィッシング耐性を持つパスキーは、ユーザー認証の信頼性を飛躍的に高め、アクセス制御の判断基盤を強化する。

  • コンテキストに応じたアクセスポリシー：Microsoft Entra IDの条件付きアクセスのようなポリシーエンジンと組み合わせることで、より高度な制御が可能になる。例えば、「機密情報へのアクセスには、パスキーによるフィッシング耐性のある認証を必須とする」といったポリシーを適用できる 85。

  • デバイス信頼性の検証：さらに、デバイスアテステーションから得られる情報（AAGUIDなど）をポリシーの条件として利用することで、「企業が許可した特定のベンダーのセキュリティキーでのみ、本番サーバーへのアクセスを許可する」といった、デバイスレベルでの厳格な信頼性検証に基づいたアクセス制御が実現できる 62。


5.1.3 インシデント対応プレイブックの更新


アカウント乗っ取りインシデントへの対応は、パスキーの普及に伴い大きく変化する。従来の「パスワードリセット」を中心としたプレイブックはもはや有効ではない。

新しいプレイブックは、セッションハイジャックを主要なインシデントタイプとして想定し、以下の対応を中核に据える必要がある 88。

  1. セッションの即時失効：侵害が疑われるユーザーの全てのアクティブなセッションを、管理コンソールやAPIを通じて即座に強制終了させる。CAEが導入されていれば、リスク検知と連動してこれを自動化できる 74。

  2. 強制的な再認証：ユーザーが利用する全てのデバイスに対して、再度のパスキー認証を強制する。

  3. 侵害エンドポイントの隔離：EDRツールを用いて、マルウェアに感染した可能性のあるデバイスをネットワークから隔離し、被害の拡大を防ぐ。

  4. ログの調査：失敗したログイン試行だけでなく、窃取されたセッショントークンから発信された異常なアクティビティ（例：通常とは異なるIPアドレスからのアクセス、深夜の大量データダウンロードなど）の痕跡を調査する。


5.2 個人ユーザー向け：実践的なセキュリティベストプラクティス



5.2.1 各エコシステムにおけるパスキーの管理


  • Google：Googleアカウント自体のセキュリティ（強力なパスワード、2段階認証プロセス）を確保することが大前提となる。デバイスの画面ロックを有効にすることがパスキー利用の必須条件であり、紛失・盗難時にはGoogleアカウントのデバイス管理ページから該当デバイスをログアウトさせることが重要である 89。

  • Apple：iCloudキーチェーンのセキュリティは、Apple IDの2ファクタ認証に強く依存する。Appleはエンドツーエンド暗号化と、全てのデバイスを失った場合でも安全に回復できる「iCloudキーチェーンエスクロー」という仕組みを提供している 5。

  • Microsoft：Windows Helloを利用したパスキーは、デバイスのTPMに紐づけられることが多い。企業環境ではMicrosoft Entra IDを通じて管理される。共有PCでのパスキー作成は、他のユーザーによる不正利用のリスクがあるため、絶対に避けるべきである 44。


5.2.2 デバイスの紛失、回復、共有時のシナリオ


  • デバイスの紛失：パスキーにおける最大の物理的リスクはデバイスの紛失・盗難である。第一の防御線は、推測されにくい強力なデバイスのパスコードや生体認証である 8。第二の防御線は、各プラットフォームが提供する「デバイスを探す」機能を用いて、遠隔でデバイスをロックまたはデータ消去する機能である 89。

  • アカウントの回復：パスキーで保護されたアカウントのセキュリティは、その最も弱い回復手段のセキュリティレベルに依存する 43。回復オプションがフィッシング可能なSMS OTPに設定されている場合、パスキーの堅牢性は無意味になる。ユーザーは、回復用の物理セキュリティキーを設定したり、信頼できる連絡先を登録するなど、複数の強固な回復手段を事前に設定しておくことが強く推奨される 92。

  • デバイスの共有：家族や同僚と共有しているデバイスでは、パスキーを作成してはならない。デバイスのロックを解除できる人物であれば誰でも、そのデバイス上のパスキーを利用してアカウントにサインインできてしまうためである 44。

パスワードからパスキーへの移行は、一夜にして完了するイベントではなく、長期間にわたるプロセスである。この移行期間中、パスワードやレガシーなMFAはパスキーと並存することになる。この過渡期こそが、最も注意を要する時期である。もしパスワードによるログインやアカウント回復が可能である限り、そこが攻撃者にとっての最大の狙い目となる。攻撃者は、パスワードを窃取してアカウントに侵入し、自身のパスキーを登録することで、永続的かつ強固な足場を築こうとするだろう 9。したがって、CISOの戦略的目標は、ユーザーの理解と技術的なサポート体制を整えながら、可能な限り迅速にレガシーな認証・回復手段を廃止していくことにある。


結論：アイデンティティの未来はレジリエントであり、無敵ではない


パスキーは、認証プロトコルの設計における輝かしい成功事例である。公開鍵暗号とオリジンバインディングを巧みに組み合わせることで、長年にわたりユーザーと組織を悩ませてきたクレデンシャルフィッシングという脅威を、技術的にほぼ根絶することに成功した。これは、オンラインセキュリティにおける真のパラダイムシフトと言える。

しかし、本レポートで詳述したように、この勝利は新たな戦いの始まりを意味する。攻撃者はパスキーそのものを破るのではなく、パスキーが動作する土台であるエンドポイントデバイスを侵害し、認証が完了した後の「セッション」を乗っ取るという、より洗練された手法へと戦術を移行させている。パスキーは、認証という「門」を鉄壁にしたが、一度門を通過した後の「内部」の安全までは保証しない。

したがって、ユーザーからの「どう対応するか」という問いに対する最終的な答えは、単一の特効薬を求めることではなく、脅威の進化に適応した、多層的でレジリエントなセキュリティ思想を受け入れることである。

未来のアイデンティティ管理は、以下の原則に基づき構築されなければならない。

  1. エンドポイントを新たな境界線と認識する：ゼロトラストの原則に従い、デバイスの健全性と信頼性を継続的に検証することが、全てのセキュリティ対策の出発点となる。EDRや厳格なパッチ管理は、もはや選択肢ではなく必須要件である。

  2. 認証のライフサイクル全体を保護する：ログインの瞬間だけでなく、パスキーを登録する「入り口」から、セッションが継続している「内部」、そしてアカウントを回復する「裏口」まで、IDライフサイクルのあらゆる段階でセキュリティを確保する必要がある。デバイスアテステーションは入り口を、DBSCやCAEは内部を保護するための重要な技術となる。

  3. 静的な信頼から動的な信頼へ移行する：一度の認証で永続的な信頼を与えるのではなく、リスクシグナルに基づいてアクセス権をリアルタイムで再評価するCAEのような仕組みが、高度な脅威に対抗するための鍵となる。

パスキーは、我々をパスワードの呪縛から解放する強力なツールである。しかし、それは決して「無敵の鎧」ではない。その真価は、エンドポイントの保護、セッションの保全、そして動的なアクセス制御という、より広範なセキュリティ戦略の中に正しく位置づけられて初めて発揮される。我々が目指すべきは、決して破られることのない無敵のシステムではなく、侵害を迅速に検知し、被害を最小限に抑え、速やかに回復できる、強靭で「レジリエント」なアイデンティティ基盤の構築なのである。



引用文献


  1. パスキーはフィッシング詐欺対策に有効なのか？ - Keeper Security, 9月 25, 2025にアクセス、 https://www.keepersecurity.com/blog/ja/2024/01/05/are-passkeys-phishing-resistant/

  2. Passkeys - Google for Developers, 9月 25, 2025にアクセス、 https://developers.google.com/identity/passkeys

  3. Passkeys & Passkey Authentication: Secure Passwordless Login and Auth, 9月 25, 2025にアクセス、 https://www.passkeys.com/

  4. What is a passkey? And why are they better than passwords? - Malwarebytes, 9月 25, 2025にアクセス、 https://www.malwarebytes.com/cybersecurity/basics/passkey

  5. パスキーのセキュリティについて - Apple サポート (日本), 9月 25, 2025にアクセス、 https://support.apple.com/ja-jp/102195

  6. I still don't understand why Passkeys are safe - Reddit, 9月 25, 2025にアクセス、 https://www.reddit.com/r/Passkeys/comments/1mcjva8/i_still_dont_understand_why_passkeys_are_safe/

  7. My understanding of Passkeys used to be that they were hardware-bound, so stored... | Hacker News, 9月 25, 2025にアクセス、 https://news.ycombinator.com/item?id=44794080

  8. Can Passkeys Be Stolen? - Corbado, 9月 25, 2025にアクセス、 https://www.corbado.com/faq/can-passkeys-be-stolen

  9. ワンタイムパスワードでは防げない、リアルタイムフィッシングの脅威～パスキーによるフィッシング耐性の本質とは - Nat Zone, 9月 25, 2025にアクセス、 https://www.sakimura.org/2025/06/7160/

  10. Understanding Relying Parties for Passkeys: A Guide on what, why, and how to use them. - Authsignal, 9月 25, 2025にアクセス、 https://www.authsignal.com/blog/articles/relying-parties-for-passkeys-guide

  11. Are passkeys really phishing resistant? - Reddit, 9月 25, 2025にアクセス、 https://www.reddit.com/r/Passkeys/comments/1i3njpz/are_passkeys_really_phishing_resistant/

  12. Passkey Security, 9月 25, 2025にアクセス、 https://www.passkeycentral.org/introduction-to-passkeys/passkey-security

  13. パスワードがなくならない理由と解決策｜パスキー導入とID統合で安全な認証を実現 - NRIセキュア, 9月 25, 2025にアクセス、 https://www.nri-secure.co.jp/blog/passkey-and-identity-integration

  14. パスキー（Passkey）とは？仕組みや設定・使用方法についてわかりやすく解説！, 9月 25, 2025にアクセス、 https://blog.trustlogin.com/2023/passkey

  15. Passkeys: Passwordless Authentication - FIDO Alliance, 9月 25, 2025にアクセス、 https://fidoalliance.org/passkeys/

  16. パスワードからパスキーへ移行するメリットと課題とは | サイバーセキュリティ情報局 - ESET, 9月 25, 2025にアクセス、 https://eset-info.canon-its.jp/malware_info/special/detail/240118.html

  17. パスキーとは？メリットや概要を解説|セキュリティニュースのセキュリティ対策Lab, 9月 25, 2025にアクセス、 https://rocket-boys.co.jp/security-measures-lab/passkeys-overview-benefits-explained/

  18. The Passwordless Authentication with Passkey Technology from an Implementation Perspective - arXiv, 9月 25, 2025にアクセス、 https://arxiv.org/html/2508.11928v1

  19. パスキーはハッキングされる可能性がありますか？ - Corbado, 9月 25, 2025にアクセス、 https://www.corbado.com/ja/faq/passkey-hack-kanousei

  20. パスキー（Passkey）とは？仕組みやメリットについて解説 - elgana（エルガナ）, 9月 25, 2025にアクセス、 https://elgana.jp/column/security/what-are-passkeys.html

  21. White Paper: FIDO Deploying Passkeys in the Enterprise ..., 9月 25, 2025にアクセス、 https://fidoalliance.org/white-paper-fido-deploying-passkeys-in-the-enterprise-introduction/

  22. パスキー認証とは？デメリットはある？仕組みをわかりやすく解説 | @niftyセキュリティ, 9月 25, 2025にアクセス、 https://security.nifty.com/posts/m2rqo0m5f5/

  23. The Industry's Passkey Pivot Ignores a Deeper Threat: Device-Level Infections, 9月 25, 2025にアクセス、 https://constella.ai/the-industrys-passkey-pivot-ignores-a-deeper-threat-device-level-infections/

  24. パスキー、フィッシングには有効だがデバイス感染には無力 - どう ..., 9月 25, 2025にアクセス、 https://www.sms-datatech.co.jp/securitynow/articles/news/01997c71-6d7e-7b8e-b47f-85205b4d2d20/

  25. パスキーで本当に防げる攻撃、防げない攻撃 ～企業導入で守れる情報と残るリスク, 9月 25, 2025にアクセス、 https://www.securewave.co.jp/blog/047

  26. Defending against account takeovers from today's top threats with passkeys and DBSC | Google Workspace ブログ, 9月 25, 2025にアクセス、 https://workspace.google.com/blog/ja/identity-and-security/defending-against-account-takeovers-top-threats-passkeys-and-dbsc

  27. Threat Actors Use Session Hijacking to Hunt for Cookies | Latest Alerts and Advisories, 9月 25, 2025にアクセス、 https://www.cyber.nj.gov/Home/Components/News/News/1470/214

  28. Account Compromise Arms Race: How Threat Actors Evade Phish-Resistant Security Tools, 9月 25, 2025にアクセス、 https://abnormal.ai/blog/how-threat-actors-evade-phish-resistant-security

  29. Understanding Token Theft | Triskele Labs, 9月 25, 2025にアクセス、 https://www.triskelelabs.com/understanding-token-theft

  30. Understanding the Two Sides of Infostealer Risk: Employees and Users, 9月 25, 2025にアクセス、 https://constella.ai/understanding-the-two-sides-of-infostealer-risk-employees-and-users/

  31. 2025 Identity Breach Report | Constella Intelligence, 9月 25, 2025にアクセス、 https://constella.ai/2025-identity-breach-report/

  32. The Growing Threat from Infostealers - Secureworks, 9月 25, 2025にアクセス、 https://www.secureworks.com/research/the-growing-threat-from-infostealers

  33. Info Stealers | Red Canary Threat Detection Report, 9月 25, 2025にアクセス、 https://redcanary.com/threat-detection-report/trends/info-stealers/

  34. 攻撃者がユーザーのログイン情報を窃取して悪用する仕組みについて - Cisco Blogs, 9月 25, 2025にアクセス、 https://gblogs.cisco.com/jp/2024/02/talos-how-are-user-credentials-stolen-and-used-by-threat-actors/

  35. Analysis of BlackGuard - Info Stealer Malware | Zscaler Blog, 9月 25, 2025にアクセス、 https://www.zscaler.com/blogs/security-research/analysis-blackguard-new-info-stealer-malware-being-sold-russian-hacking

  36. New research shows passkeys can be hijacked through malicious ..., 9月 25, 2025にアクセス、 https://siliconangle.com/2025/08/28/new-research-shows-passkeys-can-hijacked-malicious-extensions/

  37. Your passkeys could be vulnerable to attack, and everyone - including you - must act, 9月 25, 2025にアクセス、 https://www.zdnet.com/article/your-passkeys-could-be-vulnerable-to-attack-and-everyone-including-you-must-act/

  38. Passkey Weaknesses Exposed: How To Stay Secure | SMB Technologies, Inc., 9月 25, 2025にアクセス、 https://www.smbtechnologies.com/2025/09/20/passkey-weaknesses-exposed-how-to-stay-secure/

  39. WebAuthn API Hijacking: A CISO's Guide to Nullifying Passkey Phishing - Freemindtronic, 9月 25, 2025にアクセス、 https://freemindtronic.com/webauthn-api-hijacking-ciso-guide-nullifying-phishing-en/

  40. WebAuthn API hijack could enable passkey login bypass | SC Media, 9月 25, 2025にアクセス、 https://www.scworld.com/brief/webauthn-api-hijack-could-enable-passkey-login-bypass

  41. Researchers reveal passkeys may not be as safe as we think they are - here's how to stay safe - TechRadar, 9月 25, 2025にアクセス、 https://www.techradar.com/pro/security/researchers-reveal-that-passkeys-are-not-as-safe-as-we-think-they-are-heres-how-to-stay-safe

  42. Passkeys Offer Both Benefits and New Attack Surfaces | Blog - hCaptcha, 9月 25, 2025にアクセス、 https://www.hcaptcha.com/post/passkeys-benefits-and-new-attack-surfaces

  43. Passkey Recovery & Fallback: Can Passkeys Stand Alone and Fully Replace Passwords & MFA? - Authsignal, 9月 25, 2025にアクセス、 https://www.authsignal.com/blog/articles/passkey-recovery-fallback

  44. Windowsログインにおけるパスキーの注意点 | ユニコムかつしかのブログ, 9月 25, 2025にアクセス、 https://ameblo.jp/unicom-k/entry-12925354641.html

  45. パスキーとは サインインのセキュリティを確保 | Microsoft Security, 9月 25, 2025にアクセス、 https://www.microsoft.com/ja-jp/security/business/security-101/what-is-passkey

  46. The Different Kinds of Passkeys - Cornell University, 9月 25, 2025にアクセス、 https://it.cornell.edu/secure-connect/deviceboundkey

  47. Risky Bulletin: Passkeys are phishable (but quite difficult through ..., 9月 25, 2025にアクセス、 https://risky.biz/risky-bulletin-passkeys-are-phishable-but-quite-difficult-through/

  48. Passkeys are phishable (but quite difficult through) - Risky Biz News, 9月 25, 2025にアクセス、 https://news.risky.biz/risky-bulletin-passkeys-are-phishable-but-quite-difficult-through/

  49. Device-Bound vs. Synced Credentials: A Comparative Evaluation of Passkey AuthenticationAuthor version of the paper accepted at ICISSP 2025. - arXiv, 9月 25, 2025にアクセス、 https://arxiv.org/html/2501.07380v1

  50. Are users ready to go passwordless? Why it's better to move slowly | SC Media, 9月 25, 2025にアクセス、 https://www.scworld.com/resource/are-users-ready-to-go-passwordless-why-its-better-to-move-slowly

  51. 【話題の】「パスキー」は万能で安全！？ セキュアなネットワーク環境を保つためには？, 9月 25, 2025にアクセス、 https://root-s.co.jp/news/607/

  52. パスキーは本当に必要？Gmail新セキュリティの真実 - note, 9月 25, 2025にアクセス、 https://note.com/noble_guppy6313/n/n61ac3da07204

  53. 【2024年最新】IPA「情報セキュリティ10大脅威」を解説！ 企業がすべき対策とは？, 9月 25, 2025にアクセス、 https://www.skyseaclientview.net/media/article/3183/

  54. IPA「情報セキュリティ10大脅威2024」解説｜TOP10の脅威への適切な対策とは？ - NRIセキュア, 9月 25, 2025にアクセス、 https://www.nri-secure.co.jp/blog/ipa-10-major-threats-2024

  55. IPA「情報セキュリティ10大脅威2025」解説｜専門家が語るTOP10脅威への対策 - NRIセキュア, 9月 25, 2025にアクセス、 https://www.nri-secure.co.jp/blog/ipa-10-major-threats-2025

  56. Microsoft 365 組織の一般的なセキュリティ ポリシー, 9月 25, 2025にアクセス、 https://learn.microsoft.com/ja-jp/security/zero-trust/zero-trust-identity-device-access-policies-common

  57. White Paper: High Assurance Enterprise FIDO Authentication, 9月 25, 2025にアクセス、 https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/

  58. Overview | Passkey workshop - GitHub Pages, 9月 25, 2025にアクセス、 https://yubicolabs.github.io/passkey-workshop/docs/advanced_use_cases/attestation/overview

  59. White Paper: FIDO Attestation: Enhancing Trust, Privacy, and ..., 9月 25, 2025にアクセス、 https://fidoalliance.org/fido-attestation-enhancing-trust-privacy-and-interoperability-in-passwordless-authentication/

  60. Attestation and Assertion - Web APIs - MDN, 9月 25, 2025にアクセス、 https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API/Attestation_and_Assertion

  61. WebAuthn Guide, 9月 25, 2025にアクセス、 https://webauthn.guide/

  62. Enable passkeys (FIDO2) for your organization - Microsoft Learn, 9月 25, 2025にアクセス、 https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

  63. Managed Device Attestation for Apple devices - Apple Support, 9月 25, 2025にアクセス、 https://support.apple.com/guide/deployment/managed-device-attestation-dep28afbde6a/web

  64. Mitigate fraud with App Attest and DeviceCheck - WWDC21 - Videos ..., 9月 25, 2025にアクセス、 https://developer.apple.com/videos/play/wwdc2021/10244/

  65. Enable passkeys in Authenticator for Microsoft Entra ID - Microsoft ..., 9月 25, 2025にアクセス、 https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-authenticator-passkey

  66. Device Bound Session Credentials - W3C, 9月 25, 2025にアクセス、 https://www.w3.org/TR/dbsc/

  67. Fighting cookie theft using device bound sessions - Chromium Blog, 9月 25, 2025にアクセス、 https://blog.chromium.org/2024/04/fighting-cookie-theft-using-device.html

  68. w3c/webappsec-dbsc: Device Bound Session Credentials: A Protocol for Protecting From Cookie Theft - GitHub, 9月 25, 2025にアクセス、 https://github.com/w3c/webappsec-dbsc

  69. First Public Working Draft: Device Bound Session Credentials | 2025 | News - W3C, 9月 25, 2025にアクセス、 https://www.w3.org/news/2025/first-public-working-draft-device-bound-session-credentials/

  70. Device Bound Session Credentials publication history | Standards - W3C, 9月 25, 2025にアクセス、 https://www.w3.org/standards/history/dbsc-1/

  71. Device Bound Session Credentials (DBSC) | Web Platform | Chrome ..., 9月 25, 2025にアクセス、 https://developer.chrome.com/docs/web-platform/device-bound-session-credentials

  72. Continuous Access Evaluation (CAE) in Microsoft Azure, 9月 25, 2025にアクセス、 https://azureperiodic.data3.com/Continuous-Access-Evaluation

  73. Continuous access evaluation in Microsoft Entra - Microsoft Entra ID ..., 9月 25, 2025にアクセス、 https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation

  74. Continuous Access Evaluation – Revoke tokens in real time - SecureCloud Experts, 9月 25, 2025にアクセス、 https://www.sce-it.com/en/blog/continuous-access-evaluation-revoke-tokens-in-real-time

  75. Continuous access evaluation (preview) - Power Platform - Microsoft Learn, 9月 25, 2025にアクセス、 https://learn.microsoft.com/en-us/power-platform/admin/continuous-access-evaluation

  76. Enterprise - FIDO Alliance, 9月 25, 2025にアクセス、 https://fidoalliance.org/passkey-use-case/enterprise/

  77. Passkey Types, 9月 25, 2025にアクセス、 https://www.passkeycentral.org/introduction-to-passkeys/passkey-types

  78. Passkeys vs. Security Keys: What's the Difference? - Rublon, 9月 25, 2025にアクセス、 https://rublon.com/blog/passkeys-vs-security-keys-difference/

  79. What happens when your passkey device is lost? Understanding recovery and device sync, 9月 25, 2025にアクセス、 https://www.authsignal.com/blog/articles/what-happens-when-your-passkey-device-is-lost-understanding-recovery-and-device-sync

  80. Passkeys: Easy, strong, and secure authentication - RapidiOnline, 9月 25, 2025にアクセス、 https://www.rapidionline.com/blog/passkeys-easy-strong-and-secure-authentication

  81. Software passkey vs hardware key - which is more secure? : r/AZURE - Reddit, 9月 25, 2025にアクセス、 https://www.reddit.com/r/AZURE/comments/1j0zuhe/software_passkey_vs_hardware_key_which_is_more/

  82. What is a Passkey? - Yubico, 9月 25, 2025にアクセス、 https://www.yubico.com/resources/glossary/what-is-a-passkey/

  83. Passkeys & Zero Trust | CSA, 9月 25, 2025にアクセス、 https://cloudsecurityalliance.org/blog/2023/06/22/passkeys-zero-trust

  84. Passkeys: Building Blocks for Passwordless Authentication - Beyond Identity, 9月 25, 2025にアクセス、 https://www.beyondidentity.com/resource/passkeys-building-blocks-for-passwordless-authentication

  85. Understanding Authentication Strengths in Conditional Access - SecureW2, 9月 25, 2025にアクセス、 https://www.securew2.com/blog/authentication-strengths-in-conditional-access

  86. Configuring Conditional Access Policies for FIDO2 Security Keys in Microsoft Entra ID, 9月 25, 2025にアクセス、 https://www.youtube.com/watch?v=yPnMZtk_-aI

  87. Overview of custom authentication strengths and advanced options for passkey (FIDO2) and certificate-based authentication in Microsoft Entra ID - Microsoft Learn, 9月 25, 2025にアクセス、 https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-strength-advanced-options

  88. Token theft playbook | Microsoft Learn, 9月 25, 2025にアクセス、 https://learn.microsoft.com/en-us/security/operations/token-theft-playbook

  89. パスキーとは何か？また、なぜパスワードよりも優れているの ..., 9月 25, 2025にアクセス、 https://www.malwarebytes.com/ja/cybersecurity/basics/passkey

  90. パスワードの代わりにパスキーでログインする - Google アカウント ..., 9月 25, 2025にアクセス、 https://support.google.com/accounts/answer/13548313?hl=ja

  91. Passkey's Passwordless Authentication - Google Safety Center, 9月 25, 2025にアクセス、 https://safety.google/authentication/passkey/

  92. About the security of passkeys - Apple Support, 9月 25, 2025にアクセス、 https://support.apple.com/en-us/102195

  93. iCloud data security overview - Apple Support, 9月 25, 2025にアクセス、 https://support.apple.com/en-us/102651

  94. iPhoneの「盗難デバイスの保護」について - Apple サポート (日本), 9月 25, 2025にアクセス、 https://support.apple.com/ja-jp/120340

  95. Sign in with a passkey instead of a password - Google Account Help, 9月 25, 2025にアクセス、 https://support.google.com/accounts/answer/13548313?hl=en

  96. Apple Account のセキュリティキーについて - Apple サポート (日本), 9月 25, 2025にアクセス、 https://support.apple.com/ja-jp/102637



All Tags

bottom of page