パスキーはどのように機能するか？認証フローガイド

パスキーはどのように機能するか？FIDO2公開鍵暗号方式を用いて認証情報の窃取を不可能にします。認証フロー、対応プラットフォーム、導入方法について解説します。

パスキーとは何か？

Verizon 2024 DBIRによると、確認された侵害の22%で盗まれた認証情報が侵入のきっかけとなっています。インフォスティーラーマルウェアやフィッシングキャンペーンによる認証情報の窃取は、従来のパスワードベース認証の弱点として残り続けています。実際のインシデントでもこの傾向が見られます：

• MGM Resorts（2023年）：攻撃者はソーシャルエンジニアリングの電話を利用して認証情報を取得し、最終的にホテルおよびカジノの運営を妨害しました。MGMは四半期で1億ドルの調整後EBITDARへの影響と1,000万ドルの一時的コストを開示しています（MGM Resorts 8-K提出書類）。
• Colonial Pipeline（2021年）：米司法省は、リモートアクセス用のアカウントが侵害されたことがインシデントの発端であり、米国東海岸全体の燃料供給に大規模な混乱をもたらしたと述べています（DOJプレスリリース）。
• Twilio（2022年）：フィッシングキャンペーンにより従業員の認証情報が取得され、内部システムへのアクセスと顧客への影響が発生しました（Twilioインシデントレポート）。

パスキーは、特定ドメインに紐付けられた暗号学的認証により、このような失敗パターンを排除し、認証情報の窃取や再利用を構造的に不可能にします。

パスキーはFIDO2プロトコルに基づく暗号学的認証情報です。パスワードのようなクライアントとサーバーの両方に保存される共有シークレットの代わりに、パスキーは非対称の公開鍵・秘密鍵ペア暗号技術を使用します。デバイスは秘密鍵をTrusted Platform Module（TPM）やセキュアエンクレーブなどのセキュアハードウェア内に生成・保存します。対応する公開鍵はサーバーに送信されます。ログイン時、サーバーは暗号学的チャレンジを発行し、デバイスが秘密鍵で署名し、サーバーは公開鍵で署名を検証します。

秘密鍵はデバイスから決して出ません。サーバーは再利用可能なシークレットを保持しません。フィッシングされるものも、クレデンシャルスタッフィングされるものも、侵害されたデータベースから盗まれるものもありません。

この設計は、組織がアイデンティティ基盤を狙う最も一般的な攻撃ベクトルに対する防御方法に直接影響します。

パスキーとサイバーセキュリティの関係

パスキーは、企業侵害における初期アクセスの主要カテゴリである認証情報の侵害に対応します。Verizon DBIRによると、全体の42%の侵害に認証情報の侵害が関与しています（Verizon 2024 DBIR）。SMSコードやTOTPなど従来のMFA方式は、攻撃者が有効期限前にコードを正規サービスへ中継するリアルタイムフィッシングに依然として脆弱です。パスキーは暗号学的ドメインバインディングを用いるため、認証情報は正規のオリジンドメインでのみ機能します。ユーザーがフィッシングページとやり取りしても、パスキーは偽装ドメインで認証できません。これらの攻撃手法について復習したい場合は、SentinelOneのフィッシング攻撃ガイドをご覧ください。

アイデンティティ基盤を管理するセキュリティチームにとって、パスキーは認証情報窃取の確率を下げる対策から、構造的に不可能にする対策へと防御姿勢を転換します。SentinelOneのアイデンティティセキュリティ概要は、認証強化をより広範なアイデンティティリスク領域にマッピングするのに役立ちます。

この文脈が、パスキーが何を置き換え、何をもたらすのかを直接比較するための前提となります。

パスキーとパスワードの比較

以下の表は、防御側にとって重要なセキュリティおよび運用面でのパスキーとパスワードの主な違いをまとめたものです。

項目	パスワード	パスキー
認証モデル	クライアントとサーバーの両方に保存される共有シークレット	非対称鍵ペア：デバイス上の秘密鍵、サーバー上の公開鍵
フィッシングリスク	高い：ユーザーが偽装ドメインに認証情報を入力可能	排除：暗号学的ドメインバインディングにより不正オリジンでの利用を防止
サーバー侵害時の露出	パスワードハッシュが流出し、オフラインで解読される可能性	公開鍵は対応する秘密鍵がなければ無意味
認証情報の使い回し	一般的：成人の52%が複数アカウントでパスワードを使い回し（Google/Harris調査）	不可能：各パスキーは単一ドメイン・アカウント専用
MFA要件	別途要素が必要（SMS、TOTP、プッシュ）	内蔵：所持（デバイス）＋生体認証または知識（PIN）を1ステップで実現
ログイン成功率	従来方式で平均約63%	パスキーログインで93%（FIDO Alliance Passkey Index）
ログイン速度	MFA利用時平均31.2秒	平均8.5秒、73%短縮（FIDO Alliance Passkey Index）
ヘルプデスク負荷	パスワードリセットはITサポートコストの主因	パスキー導入企業はサインイン関連のヘルプデスク問い合わせが81%減少（FIDO Alliance Passkey Index）
リカバリーモデル	メールまたはSMSリセット（フィッシング可能なチャネルを再導入）	プラットフォームマネージャー経由の同期認証情報または事前登録済みバックアップパスキー

このパスキーとパスワードの比較から、業界が急速に移行している理由が分かります。次のセクションでは、パスキー認証を成立させる構成要素を解説します。

パスキー認証のコアコンポーネント

パスキー認証は、各段階で認証情報を保護するプロトコル、ハードウェア、プラットフォームサービスの多層スタックを使用します。各コンポーネントは、認証情報をフィッシング耐性かつ暗号学的にバインドするための特定の役割を担います。

1. FIDO2プロトコルスタック：FIDO2は2つの主要仕様からなる包括的フレームワークです。WebAuthnはW3C Web Authentication仕様で定義され、リライングパーティがJavaScript経由で公開鍵認証情報を作成・検証するためのブラウザ向けAPIです。CTAP（Client to Authenticator Protocol）は、USB、NFC、Bluetooth Low Energy（BLE）経由でクライアントプラットフォームと認証器ハードウェア間の通信を処理します。WebAuthnとCTAPがアプリケーション、ブラウザ、秘密鍵を保護するセキュアハードウェアを橋渡しします。
2. 認証器タイプ： FIDO Alliance認証器仕様は2つのカテゴリを定義しています。プラットフォーム（組み込み）認証器はデバイスハードウェアに直接統合され、秘密鍵をセキュアエンクレーブやTPMに保存します。ローミング（クロスプラットフォーム）認証器は外部ハードウェアデバイスで、USB、NFC、BLE経由でシステム間を横断し、秘密鍵が専用セキュアイレメント内に留まるため最も強力な分離を提供します。認証器の選択が保証レベル、リカバリープラン、ユーザー体験を左右します。
3. セキュアハードウェア層：すべてのパスキーのセキュリティは、秘密鍵を保護する認証器に依存します。ハードウェアセキュリティキーは、物理的・論理的抽出攻撃の両方に耐性を持つ専用セキュアイレメントにより最強の保護を提供します。
4. アテステーション：認証情報登録時、アテステーションにより、パスキーがセキュリティ要件（ハードウェアバックドキー保存やFIPS 140-2認証など）を満たす承認済み認証器モデル（AAGUIDで識別）で作成されたことを検証できます。

これら4層（FIDO2プロトコルスタック、認証器タイプ、セキュアハードウェア、アテステーション）は、すべてのパスキー操作時に連携します。次のセクションでは、登録とログイン時にこれらがどのように組み合わさるかを解説します。

パスキー認証の仕組み

パスキーのライフサイクルには、登録（認証情報の作成）と認証（所持証明）の2つのセレモニーがあります。いずれも公開鍵暗号を用いたチャレンジレスポンスモデルに従います。

登録：パスキーの作成

1. サーバーがチャレンジを生成。パスキー設定を開始すると、リライングパーティサーバーは暗号学的にランダムなチャレンジと登録パラメータ（RP識別子、ユーザー情報、対応アルゴリズム（通常はES256）、認証器要件）を生成します。
2. デバイスが鍵ペアを生成。クライアントがcredentials.create(challenge)を呼び出します。認証器がセキュアハードウェア内で新しい公開鍵・秘密鍵ペアを生成します。秘密鍵はこの保護境界から決して出ません。
3. 署名付きレスポンスを返送。デバイスは公開鍵、認証情報ID、署名済みチャレンジをサーバーに送信します。W3C仕様により、完全なオリジンがアテステーションオブジェクトに暗号学的に署名され、認証情報が正規ドメインにバインドされます。
4. サーバーが検証・保存。サーバーは署名済みチャレンジを確認し、オリジンを検証し（エンタープライズ導入時はアテステーションも確認）、公開鍵と認証情報IDをアカウントに紐付けて保存します。

この時点で、サーバーは公開鍵と認証情報IDのみを保持し、秘密鍵は一度も見ていません。この非対称性が、以降のログインをフィッシング耐性にします。

認証：パスキーによるサインイン

1. サーバーが新たなチャレンジを発行。各ログイン試行ごとに新しい暗号学的ランダムチャレンジが生成され、リプレイ攻撃を防ぎます。
2. デバイスがチャレンジに署名。クライアントがcredentials.get(challenge)を呼び出します。認証器がユーザー検証（生体認証またはデバイスPIN）を促し、秘密鍵を取得、署名カウンターをインクリメントし、認証器データとクライアントデータハッシュに署名します。
3. サーバーが署名を検証。保存済み公開鍵を用いてサーバーが署名を検証し、秘密鍵の所持を暗号学的に証明します（秘密鍵はデバイスから出ません）。

通信を傍受されても、各セッションで一意のチャレンジが使われるため再利用可能な情報はありません。秘密鍵はハードウェア内に厳重に保管されます。生体情報はサーバーに送信されず、検証は完全にデバイス上で行われます。

いずれのセレモニーも、パスキーがその時点で使用しているデバイス上に存在することを前提としています。実際には、ユーザーは複数デバイスを利用するため、パスキーをどのように移動させるかが課題となります。

クロスプラットフォーム同期

パスキーはデバイスバウンド型またはデバイス間同期型のいずれかです。

• 同期型パスキーは、プラットフォームの認証情報マネージャーを通じてエンドツーエンド暗号化で複製されます。 AppleのiCloudキーチェーンのドキュメントによれば、Appleはクラウドアカウントが侵害されてもキーチェーン内容を読み取れません。ただし、 NIST SP 800-63BはAAL3準拠のために非エクスポータブルな秘密鍵を要求しており、同期型パスキーは秘密鍵が同期のために元デバイスから出るためこの要件を満たしません。
• デバイスバウンド型パスキーは認証器ハードウェアから決して出ず、NIST SP 800-63B AAL3など最も厳格な要件を満たします。同期型パスキーも連邦ガイドライン下でのフィッシング耐性認証としてAAL2認証器に該当します。

デバイスバウンド型と同期型の選択を理解した上で、既にどのサービスやプラットフォームがパスキーをサポートしているか、今後の普及動向を評価できます。

パスキーをサポートするサービスとプラットフォーム

現在、150億以上のオンラインアカウントがパスキー認証に対応し、上位100サイトの48%がパスキーをログインオプションとして提供しています（FIDO Alliance）。消費者向けプラットフォーム、企業向けツール、金融サービスに広がっています。

• OSとブラウザ：Apple（iOS、macOS、Safari）、Google（Android、Chrome）、Microsoft（Windows、Edge）はパスキーを完全統合済み。iOSおよびAndroidデバイスの95%以上がパスキー対応で、WindowsもWindows Hello経由で同期型パスキー対応を拡大中です（Biometric Update）。CTAP over BLEにより、近くのスマートフォンに保存されたパスキーでノートPCの認証も可能です。
• 消費者向けプラットフォーム：Googleは8億以上のアカウントでパスキーを有効化し、パスワードの4倍の成功率を報告。Amazonは1億7500万以上の顧客がパスキーを利用。TikTokはパスキーで97%の認証成功率を達成。他にもPayPal、eBay、GitHub、Targetなど主要サービスがパスキー対応（FIDO Alliance Passkey Index）。
• 企業・業務向けツール：企業導入も加速中。HIDおよびFIDO Allianceのデータによると、約87%の企業がパスキーを導入済みまたは導入中。Okta、HubSpot、Cisco Duoなどがパスキー対応を開始し、HubSpotはログイン成功率25%向上、パスワードや2要素認証比で4倍高速化を報告（Dashlane Passkey Report）。
• 金融サービス・政府：American Express、Bank of America、Wells Fargoなどの銀行がパスキー対応を開始。暗号資産取引所Geminiは全ユーザーにパスキーを義務化。オーストラリアのMyGovは約3,000万人にパスキーを提供し、EUもデジタルIDウォレット基盤にパスキーを中核採用。

幅広いプラットフォーム対応により、多くの組織が今日からパスキーのパイロット導入を開始できます。ただし、導入が完全にスムーズというわけではなく、次のセクションで運用上の課題を解説します。

パスキー導入時の課題

パスキーは認証情報窃取問題を解決しますが、導入前に計画すべき運用上の課題も生じます。

• リカバリーセキュリティのジレンマ：デバイスバウンド型パスキーを唯一のデバイスで利用し、バックアップ未登録の場合、そのデバイスを紛失するとアカウントは実質的に復旧不能となります。従来のメールやSMSによるリカバリーフローは、パスキーが排除しようとする脆弱性を再導入します。
• レガシーシステムとの互換性：古いアプリケーションはFIDO2/WebAuthn非対応が多いです。FIDO Allianceの エンタープライズパスキーペーパーによれば、フェデレーション環境ではIdPレベルでパスキーを実装することで個別アプリ修正なしに下流サポートが可能です。非フェデレーション環境では各アプリごとにFIDO対応が必要、またはまずフェデレーション化が必要です。
• 組織的・クロスプラットフォーム障壁：セキュリティ上の利点があっても、パスキー導入はリソース、責任範囲、プロセス変更で停滞することがあります。プラットフォームやブラウザごとにパスキーの挙動や登録フロー、同期動作が異なり、トレーニングやサポート負荷が増加します。

これらの課題はいずれも阻害要因ではありませんが、導入後の修正ではなく計画段階での意思決定が必要です。以下のベストプラクティスは、リカバリー、互換性、展開時の摩擦に直接対応します。

エンタープライズ導入のためのパスキーベストプラクティス

パスキーの成功導入には、アーキテクチャ設計、階層化ポリシー、段階的実行が必要です。

• 2層認証情報戦略の確立：ユーザーをリスクプロファイルと保証レベル要件で分離します。AAL3準拠が必要な特権アカウント（管理者、財務、規制対象アクセス）は、デバイスバウンド型パスキーまたは非エクスポータブル秘密鍵を持つハードウェアセキュリティキーを使用します。一般従業員は同期型パスキー（AAL2フィッシング耐性要件を満たす）を利用し、デバイス認証情報マネージャーによる利便性とリカバリーを確保します。
• 3段階で展開：構造化された展開を実施します。まず高価値アプリ（メール、VPN、HRシステム）で50～100名のパイロットを行い、ライフサイクルとリカバリープロセスを確立。次に他アプリ・ユーザー層へ拡大し、プロビジョニング、失効、監査ワークフローを正式化。最終的にパスキーをデフォルト認証方式とし、パスワードベースのフォールバックは緊急時のみとします。
• 導入前にフェデレーション化：認証アーキテクチャがIdPによる集中管理でない場合は、まずそれを実現します。IdPレベルでパスキーを実装したフェデレーション環境では、下流アプリを個別修正せずにサポート可能です。非フェデレーション環境では各アプリごとにパスキー対応が必要となり、より多くのリソースが必要です。
• フィッシング耐性リカバリー設計：SMSやメールベースのリカバリーを段階的に廃止し、時間制限付きリカバリーメカニズムやバックアップパスキーに移行します。リカバリートークンは5～15分の有効期限、発行元セッションへのバインド、1回限りの利用を強制します。セカンダリデバイスに登録したバックアップパスキーが最も強力なフォールバックです。
• エンタープライズ登録時はアテステーション必須：AAGUIDベースのアテステーションフィルタリングを実装し、承認済み認証器モデルのみが認証情報を登録できるようにします。これにより、ハードウェアセキュリティ要件を満たさない認証器での登録を防止します。
• ターゲットを絞ったトレーニング投資：トレーニングは、異なるデバイスでのパスキー登録、デバイス紛失時のリカバリー手順、フォールバック認証の利用、ポリシー変更のセキュリティ的根拠をカバーします。クロスプラットフォームの不整合があるため、実地トレーニングが文書より効果的です。
• 初日から監査ログを実装：すべての登録イベント、認証試行、リカバリー操作、認証情報失効をSIEMで追跡します。パスキーライフサイクルイベントを統合し、ISO 27001管理目的やSOC 2 CC6論理アクセス要件に対応した監査証跡を維持します。SentinelOneの SIEMガイドや XDR概要は、アイデンティティテレメトリをエンドポイントやクラウドシグナルと連携させるのに役立ちます。

これらの運用基盤により、パスキーを監査対応コントロールへと転換でき、コンプライアンスや規制当局の期待に応えることができます。

パスキー認証のコンプライアンス・規制要件

規制圧力によりパスキー導入が加速しています。CISAは、すべての企業に対し、メール、VPN、重要インフラ関連システムでフィッシング耐性MFAの導入を推奨しています。CISAとNISTは、認証トークンの改ざん・窃取・リプレイ攻撃からの保護に関する ドラフト省庁間レポートも公開しています。NIST SP 800-63Bは、AAL2でフィッシング耐性オプションを、AAL3で非エクスポータブル秘密鍵を持つフィッシング耐性認証器を要求しています。

パスキーを監査に適合させるには、通常以下の3点を示す必要があります：

• コントロールマッピング：パスキーが既存のアクセス制御要件（例：ISO 27001 Annex Aアクセス制御要件）をどのように満たすかを文書化します。
• リスクアセスメント：導入によるリスク（デバイス紛失、ベンダーロックイン、リカバリーの複雑さ、ダウングレード攻撃など）と補完的コントロールを記録します。
• 証拠とエンフォースメント：実装文書を維持し、ポリシー施行を証明し、認証・リカバリーイベントの監査証跡を保持します。

これらをまとめることで、パスキーをセキュリティ強化かつ監査対応コントロールとして位置付けられます。ただし、認証はアイデンティティ攻撃対象領域の一層に過ぎず、パスキーを取り巻くツール群が、ログイン後の脅威検知・対応速度を左右します。

SentinelOneによるパスキー認証の強化

パスキーは認証層での認証情報ベース攻撃を排除しますが、アイデンティティセキュリティはログイン画面の先にも広がります。セッショントークン窃取、ラテラルムーブメント、アイデンティティベースの永続化はすべて認証後に発生します。 Singularity Identityは、エンドポイントとアイデンティティのアクティビティを相関させ、パスキーだけでは防げない脅威の検知・トリアージを迅速化します。Active DirectoryやSecureAuth、Ping、Duo、Entra ID、OktaなどのクラウドIDプロバイダーを強化し、早期侵入者捕捉のためのディセプション技術を展開、認証情報窃取や権限昇格をリアルタイムで検知します。

Purple AIは、自然言語クエリをクロスドメイン検索に変換し、アイデンティティ関連アラートの調査を加速します。Purple AIを利用する組織は、脅威対応が最大55%高速化、調査時間が40～50%短縮されています（IDC調査）。

SentinelOneは、2024年独立系MITRE ATT&CK評価において全ベンダー中央値比で88%少ないアラート数を記録し（MITRE ATT&CK Evaluations結果）、実際のインシデント対応に集中できる環境を提供します。

パスキー、エンドポイント、アイデンティティのテレメトリを統合することで、 Singularity AI SIEMが正規化されたセキュリティイベントを一元管理し、迅速なハンティングやフォレンジックを実現します。SentinelOneの Cybersecurity 101ハブは、社内ランブックの補助概念を提供します。 SentinelOneデモに申し込むことで、アイデンティティ、エンドポイント、クラウドテレメトリが1つのプラットフォームで連携する様子をご覧いただけます。

重要なポイント

本質的に、パスキーとは何か？それは、共有シークレットを非対称暗号に置き換え、侵害の22%を占める認証情報窃取リスクを排除する暗号学的認証情報です（Verizon 2024 DBIR）。エンタープライズ導入には、AAL3準拠特権アカウント向けデバイスバウンド型パスキーと、一般従業員向け同期型パスキーの2層戦略が必要です。

フィッシング耐性リカバリーワークフローを構築し、認証アーキテクチャをフェデレーション化し、段階的に展開してください。CISAやNISTによる規制要件が導入を加速させています。

よくある質問

パスキーとは何ですか？

パスキーは、FIDO2プロトコルに基づいて構築された暗号認証クレデンシャルであり、パスワードの代わりに非対称の公開鍵・秘密鍵ペア暗号を使用します。デバイスは秘密鍵をセキュアなハードウェア内に生成・保存し、公開鍵はサーバーに送信されます。

ログイン時、サーバーがチャレンジを発行し、デバイスが秘密鍵で署名し、サーバーがその署名を検証します。秘密鍵がデバイスから離れることはなく、クレデンシャルの窃取やフィッシングが構造的に不可能となります。

パスキーとパスワードの違いは何ですか？

パスキーとパスワードの違いはアーキテクチャにあります。パスワードは、デバイスとサーバーの両方に保存される共有シークレットです。サーバーが侵害されると、パスワードが漏洩します。パスキーは非対称暗号を使用し、秘密鍵はデバイスのハードウェア内に保持され、サーバーには公開鍵のみが保存されます。

サーバーが完全に侵害されても、利用可能な認証情報は漏洩しません。パスキーは正当なドメインに暗号的に紐付けられるため、フィッシングも不可能です。

パスキーはフィッシングや傍受の被害に遭いますか？

パスキーはフィッシング耐性があります。WebAuthnは正当なウェブサイトのオリジン（リライングパーティIDおよびオリジンバインディング）を含むデータに署名します。偽装ドメインにアクセスした場合、ブラウザと認証器はそのオリジンに対して有効なアサーションを発行しないため、承認してもログインは失敗します。

攻撃者が通信を傍受しても、そのセッションに紐付いた一度限りの署名済みチャレンジレスポンスしか取得できません。チャレンジは一意であるため、再利用はできません。

パスキーを保存しているデバイスを紛失した場合はどうなりますか？

同期されたパスキーでは、iCloudキーチェーンなどのサービスを通じて認証情報がデバイスエコシステム全体に複製され、1台のデバイスを紛失した場合でも復旧が可能です。デバイスに紐付けられたパスキーでは、秘密鍵が元のデバイスから決して外部に出ることはないため、別のデバイスやハードウェアキーに事前登録されたバックアップパスキーが必要です。

エンタープライズ環境では、メールやSMSによるフォールバックに頼るのではなく、時間制限付きトークンと本人確認を用いた管理者によるリカバリーワークフローを実装する必要があります。

パスキーはSOC 2やISO 27001などのエンタープライズコンプライアンス要件を満たしていますか？

同期型パスキーはNIST AAL2要件を満たし、フィッシング耐性認証器として認定されています。ハードウェアセキュリティキー上のデバイスバウンドパスキーはNIST AAL3要件を満たします。

組織は、パスキーの管理策をSOC 2共通基準6やISO 27001のアクセス制御目標など、各自のコンプライアンスフレームワークにマッピングしたリスクアセスメントを実施し、適切な監査ログと文書化された手順を整備する必要があります。

パスキーは異なるOSやブラウザ間でどのように機能しますか？

主要な各プラットフォームは、パスキーを保存するための独自の認証情報マネージャーを提供しています。同期型パスキーはエンドツーエンド暗号化でエコシステム内に複製されます。デバイス間認証はBluetooth Low Energy（BLE）経由のCTAPを利用し、近くのスマートフォンに保存されたパスキーでノートPCの認証が可能です。

WebAuthnのブラウザ対応は広く普及しているため、導入時はブラウザの有効化よりもユーザー教育やリカバリ設計に重点が置かれます。