パスキーとは？最新認証の基礎

パスキーは暗号鍵ペアを使用してパスワードを置き換え、フィッシングや認証情報の窃取を排除します。その仕組みや導入のベストプラクティスについて解説します。

パスキーとは何か？

攻撃者が従業員のパスワードをフィッシングし、SMSによる二要素認証を回避してネットワーク内を横移動します。Verizon DBIRによると、認証情報ベースの攻撃パターンによる侵害の88%が盗まれた認証情報を含み、フィッシングはソーシャルエンジニアリングインシデントの57%で使用されていました。

パスキーはこの攻撃経路全体を排除します。パスキーは暗号学的なパスワードレス認証を使用し、秘密鍵がユーザーデバイスから離れることがないため、認証情報の窃取を事実上不可能にします。

パスキーは公開鍵暗号方式に依存しています。デバイスが一意の鍵ペアを生成し、秘密鍵はTrusted Platform ModuleやSecure Enclaveなどのハードウェア保護ストレージに保存され、公開鍵はサービスプロバイダーに送信されます。認証時、サービスはチャレンジを送信し、デバイスが秘密鍵で署名します。パスワードはネットワークを通過しません。これにより、フィッシング、クレデンシャルスタッフィング、パスワード再利用攻撃が排除されます。秘密鍵はデバイスから離れず、再利用可能な秘密情報も送信されません。

パスキーはFIDO2標準（WebAuthn + CTAP）を実装しており、プラットフォーム、ブラウザ、サービス間で一貫したセキュリティを保証します。デバイスバウンドパスキーは秘密鍵をハードウェアセキュリティモジュールに保存し、最高レベルの保証を提供します。同期型パスキーは鍵を暗号化し、プラットフォームエコシステム間で同期して利便性を高めます。

パスキーが従来のパスワードとどのように異なるかを理解することで、セキュリティ向上の理由が明確になります。

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

パスキーは暗号レベルでフィッシングを阻止します。攻撃者がユーザーに対してフィッシングキャンペーンを実施しても、WebAuthnプロトコルによるオリジンバインディングが偽装ドメインでの認証を防ぎます。ユーザーがフィッシングリンクをクリックしてログインしようとしても、正規ドメインへの暗号的バインディングにより認証フローが完了しません。

ハードウェアセキュリティモジュールに保存された秘密鍵はソフトウェア攻撃で抽出できません。データベース侵害でも再利用可能な認証情報は漏洩せず、クレデンシャルスタッフィングもパスキーがサービスごとに一意であるため失敗します。

実際のインシデントがこの重要性を示しています。2023年9月、MGM Resortsは攻撃者が従業員になりすましてITヘルプデスクに連絡し、認証情報を取得して ランサムウェアを展開し、 1億ドルの損失を被りました。2022年には、大手IDプロバイダーがサードパーティ委託先の侵害を通じて認証情報窃取インシデントを経験し、数百社の顧客に影響を与えました。

パスキーで保護されたアカウントは、初期アクセス手段としての認証情報窃取を排除し、これらの侵害の大半を占める攻撃ベクトルを除去します。その保護の強さは、特定の技術コンポーネントが連携して動作することに由来します。

パスキーとパスワードの違い

パスワードは共有秘密です。ユーザーが作成し、サーバーに送信し、サーバーはハッシュ化したコピーを保存します。この一連の流れのすべてが攻撃対象となります。ユーザーは弱いパスワードを選び、複数サービスで使い回し、リアルタイムで収集するフィッシングページに騙されます。ハッシュ化されたパスワードデータベースも侵害され、オフラインで解読されることがあります。

パスキーはすべてのレベルで異なります。デバイスが暗号鍵ペアを生成し、秘密鍵はデバイスから離れません。サーバーは公開鍵のみを保存し、攻撃者は対応する秘密鍵がなければ無意味です。認証は署名付きチャレンジで行われ、再利用可能な情報はネットワークを通過しません。

実用面での違いも大きいです。パスワードは複雑な文字列の記憶や定期的な変更が必要で、使い回しや弱い選択につながります。パスキーは生体認証やデバイスPINのみで解除でき、記憶は不要です。パスワードリセットは 企業のITヘルプデスクへの問い合わせの20～50%を占めますが、パスキーはこのカテゴリ自体を排除します。

セキュリティの観点では、パスワードはフィッシング、ブルートフォース攻撃、クレデンシャルスタッフィング、データベース侵害に依然として脆弱です。パスキーはこれら4つすべてに耐性があります：

• フィッシング — ドメインバインディングにより偽サイトでの認証情報利用を防止
• ブルートフォースおよびクレデンシャルスタッフィング — 推測やリプレイできるパスワードが存在しない
• データベース侵害 — サーバーは公開鍵のみを保存し、秘密鍵がなければ無意味
• 認証情報の再利用 — サービスごとの一意性により、1つのアカウントが侵害されても他は影響しない

パスワードが「知っているもの」という単一要素認証であるのに対し、パスキーは「持っているもの」（秘密鍵を保存するデバイス）と「本人であること」（生体認証）を組み合わせ、多要素認証を1ステップで実現します。

これらの違いは、パスキーが実際の攻撃シナリオに直面した際のセキュリティ成果に直結します。

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

パスキー認証は、フィッシング耐性を持つ認証を実現する5つの技術コンポーネントに依存しています：

• 暗号鍵ペアが基盤となります。各パスキーは数学的に関連する公開鍵と秘密鍵で構成されます。公開鍵はサービスプロバイダーのサーバーに、秘密鍵はユーザーデバイスのハードウェア保護ストレージに保存されます。
• 認証器がパスキーを生成・保存します。プラットフォーム認証器はTPM、Secure Enclave、Trusted Execution Environment（TEE）を通じてデバイスに統合され、秘密鍵を特定ハードウェアにバインドします。ローミング認証器にはUSBセキュリティキーやBluetoothトークンがあります。いずれもCTAPおよびWebAuthn仕様を実装し、ドメインバインディング、フィッシング耐性、暗号的所有証明を提供します。
• WebAuthn APIはWebアプリケーションやブラウザが認証器と連携するためのものです。このW3C標準は登録と認証の実行方法を定義し、プラットフォーム間で一貫した実装を保証します。
• リライングパーティはパスキー認証を実装するサービスで、チャレンジの生成、応答の検証、公開鍵レジストリの管理を行います。
• ユーザー検証は、正当なユーザーが認証器を操作していることを生体認証、デバイスPIN、パターンで確認します。検証はローカルで行われ、生体データがデバイスから離れることはありません。

これらのコンポーネントは、登録と認証という2つのコアプロセスで連携します。

パスキーの仕組み

両プロセスとも、認証情報の送信を完全に排除する暗号的チャレンジレスポンスに依存しています。

登録プロセス

登録時、リライングパーティがユーザーのブラウザに要件を送信し、WebAuthnを呼び出します。認証器がそのドメインにスコープされた一意の鍵ペアを生成します。このオリジンバインディングが認証情報の再利用やフィッシングを防ぎます。

秘密鍵はハードウェア保護メモリに保存されます。デバイスバウンド実装ではハードウェアセキュリティモジュール、TPM、Secure Enclave、セキュリティキーチップなどが該当します。同期型実装では、エクスポート不可の暗号化クラウドストレージが使用されます。認証器は公開鍵と認証情報メタデータをリライングパーティに返します。登録は数秒で完了し、パスワード作成不要のパスワードレスログイン体験を提供します。

認証プロセス

ユーザーが認証する際、リライングパーティはランダムなチャレンジを生成し、認証情報IDとともに送信します。生体認証、PIN入力、デバイスロック解除によるユーザー検証後、認証器が秘密鍵でチャレンジに署名します。

署名済みチャレンジはリライングパーティに返送され、検証されます。署名が一致すれば認証が完了します。チャレンジは数分で失効し、リプレイできません。

クロスデバイス認証シナリオ

同期型パスキーは、クラウドキーチェーン（iCloud KeychainやGoogle Password Manager）で秘密鍵を暗号化し、同一エコシステム内の複数デバイスでアクセス可能にします。利便性は高いですが、完全なアテステーションサポートが限定的で、組織が使用中のセキュリティハードウェアを暗号的に検証できない場合があります。デバイスバウンドパスキーは各ログイン時に物理認証器が必要で、完全なアテステーション機能により、使用中のセキュリティキーモデルやハードウェアセキュリティモジュールを検証できます。

企業にとって、同期型とデバイスバウンド認証情報の選択はリスク許容度に依存します。特権管理者アカウントなど高セキュリティ環境ではデバイスバウンド実装が有効で、一般従業員認証には利便性重視の同期型が適しています。

仕組みを理解した上で、パスキーが組織にもたらす価値を見ていきます。

パスキーの主な利点

パスキーは、セキュリティ、運用、コンプライアンスにわたる4つの測定可能な改善をパスワードベース認証に対して提供します。

1. 暗号によるフィッシング耐性：SMSコード付きパスワード認証は、攻撃者が偽サイトを介してリクエストをプロキシするリアルタイムフィッシングに依然として脆弱です。パスキーはドメインバインディングによりこれを排除します。WebAuthn APIは認証前に宛先ドメインを検証し、ドメインが一致しない場合は認証が失敗します。SMSコード、プッシュ通知、TOTPは中間者攻撃、SIMスワップ、プッシュ通知疲労に依然として脆弱ですが、暗号認証情報はそうではありません。
2. 認証情報窃取の防止：秘密鍵はユーザーデバイスから離れません。サーバー侵害でも再利用可能な認証情報は漏洩せず、サーバーは公開鍵のみを保存します。インフォスティーラーマルウェアも、カーネルレベルのアクセスがあってもハードウェアセキュリティモジュールから鍵を抽出できません。パスキーは攻撃者が最も多用する 認証情報収集手法に対応します。
3. 運用効率の向上：パスキー導入により、ユーザーが暗号認証情報を忘れることがないため、パスワードリセット依頼が減少します。USDAのFIDO導入例では、約4万人のユーザーがパスワードレス認証を採用し、ヘルプデスクチケットのカテゴリを丸ごと排除しました。SentinelOneのSingularity IdentityのようなIDセキュリティプラットフォームは、認証基盤を狙う認証情報ベースの脅威に自律的に対応し、パスキーによる防御を補完します。
4. コンプライアンスおよび保証レベルの整合性：パスキーは、フィッシング耐性を持つ多要素認証に関するNIST SP 800-63 AAL3要件に準拠します。CISAはFIDO/WebAuthnパスキーを MFAのゴールドスタンダードと位置付けており、ドメインバウンド認証情報が偽サイトで利用できないことを評価しています。前述の通り、認証情報ベースの侵害の大半は盗まれた認証情報によるものであり、パスキーはこのカテゴリを完全に排除します。

公開鍵暗号は、パスワードポリシーでは実現できない監査可能なセキュリティ特性も提供します。ドメイン固有認証の暗号的証明、ネットワーク上に共有秘密が存在しないこと、ハードウェア起点の鍵生成などです。これらの特性は監査時の証拠となり、SOC 2、HIPAA、PCI DSSなどのフレームワークでのコンプライアンス文書化を簡素化します。

こうしたセキュリティと運用上の利点が、プラットフォームや業界での急速な採用を後押ししています。

パスキーのプラットフォーム対応と業界での採用

Apple、 Google、 Microsoftは、各自のOSやブラウザでパスキーをネイティブサポートしており、ほとんどの企業デバイス環境でクロスプラットフォーム対応が可能です：

• AppleはiOS、iPadOS、macOS全体でiCloud Keychainを通じてパスキーを統合
• GoogleはAndroidおよびChromeでGoogle Password Managerを通じてサポート
• MicrosoftはWindows HelloおよびEntra IDでパスキー認証を有効化

プラットフォームベンダー以外にも、主要な消費者・企業サービスがパスキーログインを採用しています。Amazon、PayPal、GitHub、Shopify、eBayは顧客認証にパスキーをサポートしています。FIDO Alliance Passkey Directoryは銀行、医療、政府分野での採用拡大を追跡しています。FIDO Allianceによると、53%の人が少なくとも1つのアカウントでパスキーを有効化しています。

企業のセキュリティチームにとって、この採用トレンドはパスワードレス認証がもはや将来の話ではないことを意味します。Microsoft Entra ID、Okta、Ping IdentityなどのIDプロバイダーはFIDO2/WebAuthnのネイティブ統合を提供しており、組織での導入が現実的になっています。

ただし、プラットフォーム対応の拡大だけでは導入の複雑さは解消されません。

パスキーの課題と制限

企業でのパスキー導入には、計画と投資が必要な4つの主な障壁があります。

1. レガシーシステム統合の制約：最新認証サービスと統合できないレガシーアプリケーションが最大の導入障壁です。多くの組織は、レガシー制約によりパスワードと暗号認証情報を混在させたハイブリッドシステムに依存しており、複数の認証基盤を同時に維持する運用上の複雑さが生じます。メインフレームアプリケーション、産業用制御システム、組み込みデバイスはWebAuthnプロトコルを実装するリソースが不足していることが多いです。パスワード認証の孤島を維持するか、認証ゲートウェイに投資するか、特定システムがパスキー対象外となることを受け入れるかの判断が必要です。これらのギャップを早期に計画することで、導入時のセキュリティブラインドスポットを防げます。
2. クロスプラットフォーム実装の不整合：WebAuthn標準化にもかかわらず、プラットフォームやブラウザごとに実装が異なります。同期型パスキーは単一プラットフォームエコシステム内でのみ機能し、iCloud Keychainで同期された秘密鍵はGoogle Password Managerを使うAndroidデバイスからはアクセスできませんし、その逆も同様です。こうした不整合が予測困難な認証フローを生み、企業導入を複雑にします。
3. アカウント復旧の複雑さ：デバイス紛失やハードウェア故障はアカウントロックアウトを引き起こし、堅牢な復旧メカニズムが必要です。ユーザーはアクセス喪失を恐れがちで、その心理的障壁が導入の妨げとなります。復旧を後回しにするとサポートチケットが増加し、導入率も低下するため、復旧メカニズム設計は計画段階から最重要事項とすべきです。
4. 組織的チェンジマネジメント：ユーザーはセキュリティ上の利点を理解しないまま新しい認証フローに抵抗する場合があります。サポートスタッフには、トラブルシューティング、復旧手順、プラットフォーム固有の挙動に関するトレーニングが必要です。UX、開発、プロダクトチームの部門横断的な連携により、パスキーを純粋な技術課題として扱うよりも効果的に導入障壁を解消できます。

これらの課題を把握することで、よくある導入ミスを回避できます。

パスキー導入時によくあるミス

ユーザー体験、エラーハンドリング、フォールバックセキュリティを見落とすと、計画的なパスキー導入でも失敗することがあります。特に多いのは次の4つのミスです。

• 導入前のユーザー教育の省略：ユーザーの懸念に対応せずに導入を発表すると混乱と抵抗を招きます。ユーザーは文脈のない見慣れない認証プロンプトに直面し、多くがパスワードリセットやサポートへの問い合わせに流れます。教育ではデバイス紛失時のシナリオや復旧手順を事前に説明し、iOS、Android、Windowsごとのワークフローを用意すべきです。
• 汎用的なエラーメッセージの使用：「問題が発生しました」のようなエラー表示はユーザーの信頼を損ないます。「この認証情報は別のアカウントに属しています」や「デバイスポリシーの更新が必要です」など、具体的なメッセージが解決への道筋を示し、障害時の信頼維持につながります。
• 復旧テストの不十分さ：十分な復旧テストなしにパスキーを展開すると、ユーザーがロックアウトされるリスクが残ります。ユーザーは予告なくデバイスを紛失し、バックアップ認証器が故障し、クラウド同期が停止することもあります。実際の障害シナリオで復旧手順をテストし、手順書やビジュアルガイドを用意しましょう。
• 安全でないフォールバック認証の維持：メールやSMS OTP単独など弱い単要素方式へのフォールバックは、パスキーが防ぐべき攻撃への脆弱性を残します。フォールバックには多要素要件を設け、復旧ワークフローは通常認証よりも意図的に不便にして、日常的な利用を抑制しつつ緊急時のアクセスは確保しましょう。

実績あるベストプラクティスに従うことで、これらの落とし穴を回避し、堅牢な導入を実現できます。

パスキー導入のベストプラクティス

成功している企業導入には、展開順序、ユーザーターゲティング、復旧設計、プラットフォーム統合に共通パターンがあります。

段階的な展開戦略を実施

段階的に展開します。まずアプリベース認証器による多要素認証の基盤を確立し、組織の能力を高めてからパスキーを導入します。次に、フィッシング耐性MFAとしてパスキーを機密性の高いアプリケーションに導入し、移行期間中はパスワードフォールバックを維持します。

導入が進んだら、ライフサイクルと復旧プロセスを正式化します：

• リモートデバイスのロック解除と認証情報発行
• コンプライアンスのための完全な監査証跡付きの失効手順
• 組織全体での認証情報の一元管理
• パスワード認証は緊急時のフォールバックのみに限定

各段階には、次フェーズに進む前の明確な成功基準を設けましょう。

リスクの高いユーザーグループを優先

特権ユーザー、IT管理者、経営層から導入を開始します。これらの高価値ターゲットは認証情報窃取リスクが最も高く、 Verizon DBIRによるとソーシャルエンジニアリングインシデントの57%がフィッシングを含み、全侵害の16%で初期アクセス手段としてフィッシングが使われています。メール、VPN、HRシステム、財務ツールなどの重要業務アプリケーションを優先的に保護しましょう。

堅牢な復旧基盤を構築

パスワードの抜け道を作らずに複数の復旧手段を実装します。ユーザーには、主要なプラットフォーム認証器とともにバックアップ用ハードウェアセキュリティキーの登録を義務付け、1台紛失しても完全ロックアウトを防ぎます。

管理者による復旧は、写真付きID確認、上司による承認、セキュリティ質問による本人確認など複数チャネルで実施します。クラウド同期型パスキーは、同一プラットフォームアカウントで代替デバイスにログインすることで自動復旧が可能です。デバイスバウンドパスキーは、ハードウェアアテステーション認証が必要な特権アクセスに限定しましょう。

アイデンティティプラットフォームと統合

Microsoft Entra IDなどの企業IDプラットフォームと連携し、条件付きアクセス ポリシーを活用します。リスクベース認証により、リスクが高い状況ではフィッシング耐性パスキー認証を強制し、低リスク時は認証を簡素化できます。IDプラットフォーム統合により、パスキー認証とアプリケーションアクセス、ユーザー行動を関連付けた一元的な監査証跡も得られます。

継続的な改善プロセスを確立

登録率、認証成功率、復旧頻度、ヘルプデスクエスカレーションなどの導入指標を追跡します。プラットフォーム対応や組織成熟度の進展に合わせて、運用データやユーザーフィードバックをもとに認証フローを継続的に改善しましょう。

パスキーは認証境界を強化しますが、攻撃者は認証情報窃取だけで攻撃を止めるわけではありません。

まとめ

パスキーは、秘密鍵がユーザーデバイスから離れない暗号認証により、認証情報窃取やフィッシングを排除します。パスワードがネットワークを通過しないため、攻撃者が悪用する最も一般的な初期アクセス手段が排除されます。企業導入には、高リスクユーザーや重要業務アプリケーションから段階的に展開し、レガシーシステム制約、クロスプラットフォームの不整合、ユーザー導入障壁への計画的対応が必要です。

ユーザー教育の省略、汎用的なエラーメッセージの使用、弱いフォールバック認証の維持は、パスキーのセキュリティ効果を損なう可能性があります。IDセキュリティプラットフォームは、認証情報層を超えて認証基盤を狙う攻撃（Active Directory侵害、権限昇格、横移動など）を検知し、パスキーによる防御を補完します。

よくある質問

パスキーとは何ですか？

パスキーは、公開鍵暗号を使用してパスワードを置き換えるパスワードレスの暗号認証情報です。デバイスは一意の鍵ペアを生成し、秘密鍵はデバイス上のハードウェア保護ストレージに保持され、公開鍵はサービスプロバイダーに送信されます。

認証は暗号学的なチャレンジレスポンスによって行われるため、パスワードや再利用可能なシークレットがネットワーク上を通過することはありません。

パスキーはパスワードのように盗まれたりフィッシングされることがありますか？

いいえ。パスキーは非対称暗号を利用しており、秘密鍵はデバイス上のハードウェアセキュリティモジュール内に保持され、ネットワークを介して送信されることはありません。

フィッシング攻撃は、パスキーが認証前に宛先ドメインを暗号的に検証するため、偽装サイトでの利用を防止します。

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

復旧方法はアーキテクチャによって異なります。クラウドキーチェーンで暗号化され同期されたパスキーは、プラットフォームアカウントにログインしている任意のデバイスからアクセス可能です。

デバイスに紐づくパスキーは、登録時に設定したバックアップ認証器が必要です。組織はアカウントの完全なロックアウトを防ぐため、複数の復旧手段を実装する必要があります。

パスキーは異なるデバイスやプラットフォーム間で利用できますか？

同期されたパスキーは同一プラットフォームエコシステム（Apple、Google、Microsoft）内のデバイス間で利用可能です。クロスプラットフォーム認証には、各エコシステムごとのパスキー登録やFIDO2規格に準拠したハードウェアセキュリティキーが必要です。

パスキーはNISTや連邦政府のセキュリティ基準に準拠していますか？

はい。パスキーはNIST SP 800-63B AAL3のフィッシング耐性多要素認証要件に準拠しています。ハードウェアアテステーション付きのデバイス紐付けパスキーは、連邦システム向けの最高認証保証要件を満たします。CISAはFIDO/WebAuthnパスキーをMFAのゴールドスタンダードと位置付けています。

パスキーは既存のID・アクセス管理システムとどのように統合されますか？

パスキーはFIDO2/WebAuthn規格を実装しており、Microsoft Entra IDを含むエンタープライズIDプラットフォームでサポートされています。条件付きアクセス ポリシーにより、リスクシグナルに基づいたパスキー認証が強制されます。

導入には、レガシー互換性、復旧手段、チェンジマネジメントに対応した段階的な戦略が必要です。