パスキーとは何か？
Verizon 2024 DBIRによると、盗まれた認証情報が確認された侵害の22%で侵入口となっています。インフォスティーラーマルウェアやフィッシングキャンペーンによる認証情報の窃取は、従来のパスワードベース認証の弱点として残り続けています。実際のインシデントでもこの傾向が見られます：
- MGM Resorts（2023年）：攻撃者はソーシャルエンジニアリングの電話を利用して認証情報を取得し、最終的にホテルおよびカジノの運営を妨害しました。MGMは四半期で調整後EBITDARに1億ドルの損失、1,000万ドルの一時的コストが発生したと開示しています（MGM Resorts 8-K提出書類）。
- Colonial Pipeline（2021年）：米司法省は、リモートアクセス用のアカウントが侵害されたことが原因で、米国東海岸全体の燃料供給に大きな混乱が生じたと発表しました（DOJプレスリリース）。
- Twilio（2022年）：フィッシングキャンペーンにより従業員の認証情報が取得され、内部システムへのアクセスおよび顧客への影響が発生しました（Twilioインシデントレポート）。
パスキーは、特定ドメインに紐付けられた暗号学的認証により、このような失敗パターンを排除し、認証情報の窃取や再利用を構造的に不可能にします。
パスキーはFIDO2プロトコルに基づく暗号学的認証情報です。パスワードのようなクライアントとサーバーの両方に保存される共有シークレットではなく、パスキーは非対称の公開鍵・秘密鍵ペア暗号を使用します。デバイスは秘密鍵をTPMやセキュアエンクレーブなどのセキュアハードウェア内に生成・保存し、対応する公開鍵をサーバーに送信します。ログイン時、サーバーは暗号学的チャレンジを発行し、デバイスが秘密鍵で署名、サーバーは公開鍵で署名を検証します。
秘密鍵はデバイスから決して出ません。サーバーは再利用可能なシークレットを保持しません。フィッシングされるものも、クレデンシャルスタッフィングされるものも、侵害されたデータベースから盗まれるものもありません。
この設計は、組織がアイデンティティ基盤を狙う最も一般的な攻撃ベクトルに対する防御方法に直接影響します。
.jpg)
パスキーとサイバーセキュリティの関係
パスキーは、企業侵害における初期アクセスの主要カテゴリである認証情報の侵害に対応します。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リセット（フィッシング可能なチャネルを再導入） | プラットフォームマネージャーによる同期認証情報または事前登録済みバックアップパスキー |
このパスキーとパスワードの比較から、業界が急速に移行している理由が分かります。次のセクションでは、パスキー認証を成立させる構成要素を解説します。
パスキー認証のコアコンポーネント
パスキー認証は、各段階で認証情報を保護するプロトコル、ハードウェア、プラットフォームサービスの多層スタックを使用します。各コンポーネントは、認証情報をフィッシング耐性かつ暗号学的にバインドされた状態に保つための役割を担います。
- FIDO2プロトコルスタック：FIDO2は2つの主要仕様からなる包括的フレームワークです。W3C Web Authentication仕様で定義されたWebAuthnは、JavaScript経由で公開鍵認証情報の作成・検証を行うブラウザ向けAPIです。CTAP（Client to Authenticator Protocol）は、USB、NFC、Bluetooth Low Energy（BLE）経由でクライアントプラットフォームと認証器ハードウェア間の通信を担当します。WebAuthnとCTAPがアプリケーション、ブラウザ、秘密鍵を保護するセキュアハードウェアを橋渡しします。
- 認証器タイプ：FIDO Alliance認証器仕様は2つのカテゴリを定義しています。プラットフォーム（組み込み）認証器はデバイスハードウェアに直接統合され、秘密鍵をセキュアエンクレーブやTPMに保存します。ローミング（クロスプラットフォーム）認証器はUSB、NFC、BLE経由でシステム間で動作する外部ハードウェアデバイスで、秘密鍵が専用セキュアイレメント内に留まるため最も強力な分離を提供します。認証器の選択は保証レベル、リカバリ計画、ユーザー体験に影響します。
- セキュアハードウェア層：すべてのパスキーのセキュリティは、秘密鍵を保護する認証器に依存します。ハードウェアセキュリティキーは、物理的・論理的抽出攻撃の両方に耐性を持つ専用セキュアイレメントにより最強の保護を提供します。
- アテステーション：認証情報登録時、アテステーションにより、パスキーがセキュリティ要件（ハードウェアバックドキー保存やFIPS 140-2認証など）を満たす承認済み認証器モデル（AAGUIDで識別）で作成されたことを検証できます。
これら4層（FIDO2プロトコルスタック、認証器タイプ、セキュアハードウェア、アテステーション）は、すべてのパスキー操作時に連携します。次のセクションでは、登録とログイン時にこれらがどのように組み合わさるかを解説します。
パスキー認証の仕組み
パスキーのライフサイクルには、登録（認証情報の作成）と認証（所持証明）の2つのセレモニーがあります。いずれも公開鍵暗号を用いたチャレンジレスポンスモデルに従います。
登録：パスキーの作成
- サーバーがチャレンジを生成。パスキー設定を開始すると、リライングパーティサーバーが暗号学的にランダムなチャレンジと登録パラメータ（RP識別子、ユーザー情報、対応アルゴリズム（通常ES256）、認証器要件）を生成します。
- デバイスが鍵ペアを生成。クライアントがcredentials.create(challenge)を呼び出し、認証器がセキュアハードウェア内で新しい公開鍵・秘密鍵ペアを生成します。秘密鍵はこの保護境界から決して出ません。
- 署名付きでレスポンスを返送。デバイスは公開鍵、認証情報ID、署名済みチャレンジをサーバーに送信します。W3C仕様により、完全なオリジンがアテステーションオブジェクトに暗号学的に署名され、認証情報が正規ドメインにバインドされます。
- サーバーが検証・保存。サーバーは署名済みチャレンジを確認し、オリジンを検証、（エンタープライズ導入時は）アテステーションをチェックし、公開鍵と認証情報IDをアカウントに紐付けて保存します。
この時点でサーバーは公開鍵と認証情報IDのみを保持し、秘密鍵は一度も見ていません。この非対称性が、以降のログインをフィッシング耐性にします。
認証：パスキーでのサインイン
- サーバーが新たなチャレンジを発行。各ログイン試行ごとに新しい暗号学的ランダムチャレンジが生成され、リプレイ攻撃を防ぎます。
- デバイスがチャレンジに署名。クライアントがcredentials.get(challenge)を呼び出し、認証器がユーザー検証（生体認証またはデバイスPIN）を促し、秘密鍵を取得、署名カウンターをインクリメントし、認証器データとクライアントデータハッシュに署名します。
- サーバーが署名を検証。保存済み公開鍵を用いてサーバーが署名を検証し、秘密鍵を所持していることを暗号学的に証明します（秘密鍵はデバイスから一切出ません）。
通信を傍受されても、各セッションで一意のチャレンジが使われるため再利用可能な情報はありません。秘密鍵はハードウェア内に厳重に保管されます。生体情報はサーバーに送信されず、検証は完全にデバイス上で行われます。
いずれのセレモニーも、パスキーがその時点で使用しているデバイス上に存在することを前提としています。実際には、ユーザーは複数デバイスを利用するため、パスキーをどのように移動させるかが課題となります。
クロスプラットフォーム同期
パスキーはデバイスバインド型またはデバイス間で同期型のいずれかです。
- 同期型パスキーは、プラットフォームの認証情報マネージャーを通じてエンドツーエンド暗号化で複製されます。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のサイバーセキュリティ101ハブは、社内ランブックの補助概念を提供します。SentinelOneデモにお申し込みいただくと、アイデンティティ・エンドポイント・クラウドテレメトリが1つのプラットフォームで連携する様子をご覧いただけます。
重要なポイント
本質的に、パスキーとは何か？それは、共有シークレットを非対称暗号に置き換え、侵害の22%を占める認証情報窃取リスクを排除する暗号学的認証情報です（Verizon 2024 DBIR）。エンタープライズ導入には、AAL3準拠の特権アカウント向けデバイスバインド型パスキーと、一般従業員向け同期型パスキーの2層認証情報戦略が必要です。
フィッシング耐性リカバリワークフローを構築し、認証アーキテクチャをフェデレーション化し、段階的に展開してください。CISAやNISTによる規制要件が導入を加速させています。
よくある質問
パスキーは、FIDO2プロトコルに基づいて構築された暗号認証クレデンシャルであり、パスワードの代わりに非対称の公開鍵・秘密鍵ペア暗号を使用します。デバイスは秘密鍵をセキュアなハードウェア内に生成・保存し、公開鍵はサーバーに送信されます。
ログイン時、サーバーがチャレンジを発行し、デバイスが秘密鍵で署名し、サーバーが署名を検証します。秘密鍵がデバイスから離れることはなく、クレデンシャルの窃取やフィッシングが構造的に不可能となります。
パスキーとパスワードの違いはアーキテクチャにあります。パスワードは、デバイスとサーバーの両方に保存される共有シークレットです。サーバーが侵害されると、パスワードが漏洩します。パスキーは非対称暗号を使用し、秘密鍵はデバイスのハードウェア内に保持され、サーバーには公開鍵のみが保存されます。
サーバーが完全に侵害されても、利用可能な認証情報は漏洩しません。パスキーは正当なドメインに暗号的に紐付けられるため、フィッシングも不可能です。
パスキーはフィッシング耐性があります。WebAuthnは正当なウェブサイトのオリジン（リライングパーティIDおよびオリジンバインディング）を含むデータに署名します。偽装ドメインにアクセスした場合、ブラウザと認証器はそのオリジンに対して有効なアサーションを発行しないため、承認してもログインは失敗します。
攻撃者が通信を傍受しても、そのセッションに紐付いた一度限りの署名済みチャレンジレスポンスしか取得できません。チャレンジは一意であるため、再利用はできません。
同期されたパスキーでは、iCloudキーチェーンなどのサービスを通じて認証情報がデバイスエコシステム全体に複製され、1台のデバイスを紛失した場合でも復旧が可能です。デバイスに紐付けられたパスキーでは、秘密鍵が元のデバイスから決して離れないため、別のデバイスやハードウェアキーに事前登録されたバックアップパスキーが必要です。
エンタープライズ環境では、メールやSMSによるフォールバックに頼るのではなく、時間制限付きトークンと本人確認による管理者による復旧ワークフローを実装する必要があります。
同期型パスキーはNIST AAL2要件を満たし、フィッシング耐性認証器として認められます。ハードウェアセキュリティキー上のデバイスバウンドパスキーはNIST AAL3要件を満たします。
組織は、SOC 2共通基準6やISO 27001のアクセス制御目標を含む自社のコンプライアンスフレームワークにパスキー管理をマッピングするリスクアセスメントを実施し、適切な監査ログと手順書を整備する必要があります。
主要な各プラットフォームは、パスキーを保存するための独自の認証情報マネージャーを提供しています。同期型パスキーはエンドツーエンド暗号化でエコシステム内に複製されます。デバイス間認証はBluetooth Low Energy（BLE）経由のCTAPを利用し、近くのスマートフォンに保存されたパスキーでノートPCへの認証が可能です。
WebAuthnのブラウザ対応は広く普及しているため、導入時はブラウザの有効化よりもユーザー教育やリカバリ設計に重点が置かれます。
