パスキーとセキュリティキーとは何か
2021年、Colonial Pipelineはランサムウェアインシデントの原因を侵害されたVPNパスワードにまで遡り、同社は約440万ドルの身代金を支払ったとDOJの発表で報告されています。これは認証情報ベースの初期アクセスの運用上の現実です。攻撃者は、パスワードベースの認証に対してフィッシング、再利用、またはクレデンシャルスタッフィングを実行できる場合、ゼロデイを必要としません。
パスキーと物理セキュリティキーの両方は、そのギャップを埋めるために存在します。両者は同じ暗号基盤を使用しますが、認証情報の保存と管理方法の違いは、エンタープライズを保護する際に重要です。
パスキーは、パスワードを暗号鍵ペアで置き換えるFIDO認証情報です。FIDOアライアンスによると、パスキーはユーザーがデバイスのロック解除と同じプロセス（生体認証、PIN、パターン）でアプリやウェブサイトにサインインできるようにします。パスキーには2つの形式があります：
- 同期型パスキーは、クラウド対応の認証情報マネージャーに認証情報を保存し、複数のデバイス間で同期します。
- デバイスバウンドパスキーは、秘密鍵を単一デバイスにロックします。秘密鍵はそのハードウェアから離れません。
実際には、この保存モデルがエンタープライズの多くのトレードオフを左右します。
ハードウェアセキュリティキー（ローミング認証器とも呼ばれる）は、FIDO2 CTAP（Client-to-Authenticator Protocol）を使用してUSB、NFC、Bluetooth経由でブラウザやOSと通信する外部ハードウェアデバイスです。YubiKeyやスマートカードなどが該当します。これらは定義上デバイスバウンドであり、秘密鍵はハードウェアセキュリティモジュールに保存され、エクスポートやコピーはできません。
両技術は同じ暗号基盤を共有しています。すべての認証情報は一意で、特定のサービスドメインに紐付けられ、標準的な公開鍵暗号に基づいています。生体データはデバイスから離れません。サーバーは公開鍵のみを保存します。この共通設計が、両オプションが同じコアセキュリティ課題に有効である理由です。
.jpg)
パスキーとセキュリティキーのサイバーセキュリティとの関係
2025年版Verizon DBIRによると、認証情報の悪用が初期アクセスの大きな割合を占めています。22%の侵害が初期アクセス手法として認証情報の悪用を含んでいると Verizon DBIRは報告しています。これは現場で見られる傾向と一致します。攻撃者が有効な認証情報を手に入れた時点で、自社のアクセス経路と戦うことになります。
パスキーとセキュリティキーの両方は、設計上フィッシング耐性があります。 WebAuthn仕様で定義されている通り、各認証アサーションは特定のウェブサイトドメインにスコープされているため、異なるドメイン上の認証情報フィッシングサイトは有効なアサーションを取得できません。これにより、認証情報フィッシング、クレデンシャルスタッフィング、Adversary-in-the-Middle攻撃がプロトコルレベルで阻止されます。そのため、各機関や規制業界が フィッシング耐性MFAの導入を推進しています。
このため、OMB M-22-09は連邦機関に対し、フィッシング耐性認証のみの使用を義務付けています。組織にとっての課題はFIDO2認証の採用可否ではなく、どの実装モデルがリスクプロファイルに適合するかです。以下の表は主な違いを並べて示しています。
パスキーとセキュリティキーの比較
| 機能 | パスキー（同期型） | 物理セキュリティキー |
| 認証情報の保存 | クラウド認証情報マネージャー（Apple Keychain、Google Password Manager） | 物理トークン上のハードウェアセキュリティモジュール |
| 鍵のエクスポート可否 | クラウド基盤でデバイス間同期 | エクスポート不可、ハードウェアにロック |
| NIST保証レベル | AAL2 | AAL3 |
| フィッシング耐性 | あり（FIDO2ドメインバインディング） | あり（FIDO2ドメインバインディング） |
| デバイス認証（アテステーション） | 非対応（クラウド同期で信頼チェーンが切れる） | 対応（ハードウェア埋込製造者証明書） |
| リカバリモデル | プロバイダー経由のクラウドアカウントリカバリ | 物理バックアップキーまたは管理者による再登録 |
| ユーザー体験 | 透過的、同期デバイス間で利用可能 | 各ログイン時に物理トークンが必要 |
| ハードウェアコスト | なし（ソフトウェアベース） | ユーザーごとのトークン購入とライフサイクル管理 |
| クロスプラットフォーム対応 | プロバイダーエコシステム依存 | ユニバーサル（USB、NFC、BLE対応FIDO2プラットフォーム） |
| 最適用途 | 一般従業員、BYOD環境 | 特権管理者、規制業界、AAL3準拠 |
各オプションのプロトコルスタック、保存モデル、アテステーション対応が保証レベルを左右します。以下にその構成要素を解説します。
FIDO2認証の仕組み
パスキーとセキュリティキーは同じFIDO2プロトコルスタックに依存していますが、基盤となる暗号素材の保存・保護・管理方法が異なります。これらの構成要素を理解することで、適切な認証情報タイプを適切なリスクレベルに合わせることができます。
FIDO2プロトコルスタック
FIDO2はFIDO仕様で定義された2つのコアコンポーネントで構成されます：
- W3C Web Authentication（WebAuthn）: ウェブサイトやアプリケーションでFIDO認証を可能にするブラウザAPI。
- Client-to-Authenticator Protocol（CTAP）: 外部認証器がFIDO2対応ブラウザやOSと通信するためのプロトコル。
この2層がオリジンバインディングと強力なフィッシング耐性サインインを可能にする暗号証明を提供します。
認証情報保存アーキテクチャ
保存モデルがパスキーとセキュリティキーの決定的な違いです。各方式は秘密鍵の扱いが異なります：
- ハードウェアセキュリティキーは、専用のハードウェアセキュリティモジュール（HSM）、多くの場合TPMチップに秘密鍵を保存します。 Microsoft Entraドキュメントによると、鍵素材はエクスポート不可です。コピー、バックアップ、同期はできません。
- 同期型パスキーは、OSやサードパーティの同期基盤を利用して暗号鍵を複数デバイス間で複製します。FIDOアライアンスの エンタープライズ導入ガイドによれば、これはパスキープロバイダーの同期基盤とそのセキュリティ制御に依存関係を生じさせます。
この保存の違いが、アテステーション、コンプライアンス、リカバリに関するすべての下流の意思決定を左右します。
アテステーション
デバイスアテステーションは、FIDOおよびWebAuthnプロトコルに組み込まれた技術で、認証器がデバイス製造者からの信頼チェーンを暗号的に検証できるようにします。FIDOアライアンスの アテステーションホワイトペーパーによると、これには認証器のセキュアエレメントにハードウェア埋込の製造者証明書が必要です。
同期型パスキーは、クラウド同期によりこの暗号チェーンが切れるため、デバイスの出所証明ができません。IDプラットフォームでアテステーションを強制する場合、デバイスバウンド認証情報のみが対象となります。
コンプライアンス適合
NIST SP 800-63B-4は明確な線引きをしています。AAL2はフィッシング耐性認証を要求し、同期型パスキーとセキュリティキーの両方が該当します。AAL3はエクスポート不可の認証鍵を要求し、同期型パスキーは完全に除外されます。
これらの構成要素は、サインイン時の挙動や両認証情報タイプの違いに直結します。
登録、認証、両者の違い
パスキーとセキュリティキーの認証フローは同じFIDO2パターンに従います。違いは、認証情報の保存、可搬性、リカバリの扱いに現れます。
登録（両方式共通）
登録時、認証器はサービスドメインに紐付けられた一意の公開鍵／秘密鍵ペアを生成します。秘密鍵は認証器に残り、サーバーは公開鍵のみを保存します。
認証（両方式共通）
- サーバーが暗号チャレンジを送信します。
- ローカル認証（指紋スキャン、顔認証、PIN、物理ボタン押下など）を実施します。
- 認証器が秘密鍵でチャレンジに署名します。
- サーバーが保存された公開鍵で署名を検証します。
この共通フローにより、両方式ともプロトコルレベルでフィッシング攻撃を遮断できます。
可搬性
物理セキュリティキーの場合、1つのトークンで無制限のデバイスに認証できます。FIDO2対応ブラウザに挿入またはNFCでタップするだけで利用可能です。
同期型パスキーの場合、認証情報はプロバイダーのエコシステム内で自動的に複数デバイスに複製されます。Apple、Google、サードパーティマネージャーなどです。ノートPCで認証すれば、同じパスキーがスマートフォンでも追加デバイスなしで利用できます。ただし、エコシステム間の可搬性は依然として一貫性がありません。Chrome/Windowsで動作するフローがSafari/macOSでは異なる場合があり、ブラウザレベルのUXギャップがエンタープライズ導入時の課題となっています。
セキュリティ境界
デバイスバウンド認証情報の場合、攻撃者は認証情報、ハードウェアトークンへの物理アクセス、ローカル認証のバイパス能力が必要です。
同期型認証情報の場合、セキュリティ境界はクラウドプロバイダーに移ります。攻撃者がソーシャルエンジニアリングやプロバイダーリセット操作でクラウドアカウントを侵害した場合、攻撃者管理下のデバイスに認証情報を同期できます。
この境界の変化が運用計画のポイントです。両認証情報タイプにはエンタープライズ運用前に考慮すべきトレードオフがあり、選択した認証情報タイプを実際にサポートするプラットフォーム、ブラウザ、IDプロバイダーが必要です。
パスキーとセキュリティキーの現状サポート状況
2025年時点で、パスキーとセキュリティキーの採用は消費者・エンタープライズ両エコシステムで実用的な転換点に達しています。
- OSとブラウザ。 Apple（iOS 16+、macOS Ventura+）、Google（Android 9+）、Microsoft（Windows 10/11、Windows Hello経由）はすべてパスキーの作成と認証をネイティブサポートしています。Chrome、Safari、Edge、Firefoxなど主要ブラウザはすべて WebAuthnをサポートしています。 FIDOアライアンスによると、iOSおよびAndroidデバイスの95%以上がパスキー対応済みで、10億人以上のユーザーが少なくとも1つのパスキーを有効化しています。
- IDプロバイダー。 エンタープライズIdPはFIDO2サポートを広範に追加しています。Microsoft Entra IDはFIDO2セキュリティキーおよびMicrosoft Authenticatorでデバイスバウンドパスキーをサポートし、同期型パスキーはプレビュー中です。OktaはパスキーとFIDO2セキュリティキーの両方をフィッシング耐性認証器としてサポートし、アテステーション強制やAAGUIDベースのポリシー制御も提供しています。Cisco Duo、Ping Identityなど他の主要IdPも両認証情報タイプのFIDO2登録をサポートしています。つまり、IdPが障壁となることはほぼありません。
- ハードウェアセキュリティキーは、USB、NFC、Bluetooth経由でFIDO2対応プラットフォーム全体でユニバーサルに動作します。Yubicoなどの主要メーカーは、FIDO2、PIV/スマートカード、OTPをサポートするマルチプロトコルトークン（YubiKey 5シリーズ）を提供し、モダンおよびレガシー認証ニーズを1つのトークンでカバーします。
- クロスプラットフォーム可搬性のギャップ。同期型パスキーはエコシステム間移行時に依然として摩擦があります。Apple Keychainで作成したパスキーはGoogle Password ManagerやWindowsデバイスにはネイティブ同期されません。FIDOアライアンスは、Apple、Google、Microsoft、1Password、Bitwarden、Dashlaneが開発するCredential Exchange Protocol（CXP）というドラフト仕様で、プロバイダー間の安全な暗号化パスキー転送の標準化に取り組んでいます。CXPは2026年にパブリックレビュー案が予定されています。それまでは、1PasswordやBitwardenなどのサードパーティパスワードマネージャーが最も一貫したクロスプラットフォームパスキー体験を提供します。
エンタープライズ計画において、主要なポイントはプラットフォームサポートがもはや導入障壁ではないということです。残る摩擦は、同期型パスキーのエコシステム間可搬性と、登録・リカバリ・ポリシー強制に関する組織の準備状況です。これらの運用課題は詳細な検討が必要です。
計画すべき課題と制限事項
どの認証方式もすべてのリスクを排除するわけではありません。パスキーとセキュリティキーを大規模展開する際、以下のような課題が繰り返し発生します：
- リカバリワークフローが最前線の制御となる。 攻撃者がヘルプデスクやプロバイダーリセットプロセスに介入できれば、最強のサインインフローも回避されます。
- 鍵の紛失が可用性問題となる。 トークン紛失時、バックアップや管理者ワークフローを事前に用意しないとユーザーがロックアウトされます。
- プラットフォーム差異が摩擦を生む。 ブラウザやOSの断片化によりWebAuthn UXが一貫せず、サポート負荷が増加します。
- ライフサイクル運用負荷が現実的に発生する。 発行、交換、失効などの運用が、特権ユーザー以外にもトークン展開を拡大するほど増加します。
これらは理論上の話ではありません。2023年、MGM Resortsはソーシャルエンジニアリングによるサイバーインシデントを公表し、 MGMの提出書類によれば1億ドル規模の損失が発生しました。強力なサインイン要素は有効ですが、サービスデスクやフォールバックプロセスを含むID運用の強化が不可欠です。良いニュースは、これらの制約がすべて、導入前に実施できる具体的な運用対策に対応していることです。
パスキーとセキュリティキー導入のベストプラクティス
パスキー、セキュリティキー、または両方を展開する場合、以下のプラクティスがリスク、利便性、運用現実に即した導入を支援します：
- リスクと保証レベルでセグメント化。特権管理者、経営層、規制対象ロールなどAAL3や高保証アテステーションが必要な場合はハードウェアセキュリティキーを発行。AAL2要件を満たす一般従業員には同期型パスキーを利用。
- 登録とバックアップを標準化。デバイス導入時にパスキー設定を必須とし、ユーザーごとに 複数の認証器を登録して、容易にフィッシングされる要素に戻らないようバックアップを確保。
- アカウントリカバリとフォールバックを強化。アカウントリカバリを制御として扱い、ヘルプデスクリセットの本人確認を厳格化、フォールバック手段を制限し、異常なフォールバック利用を監視。
- 段階的展開と継続的監視。リスクの高いグループからパイロットし、段階的に拡大、ユーザーサポートとリセットワークフローが安定したら強制化。異常な移動、リスキーなデバイス変更、不審な再登録を継続的に可視化。
これら4つのプラクティスを実施すれば、ロックアウトを減らし、攻撃者の選択肢を狭めつつユーザーの利便性を損ないません。その上で、どの認証情報タイプをどこに割り当てるか明確なセグメントモデルを構築できます。
パスキーとセキュリティキーの選択方法
パスキーとセキュリティキーの選択は二者択一である必要はありません。多くのエンタープライズは、異なるユーザー層に異なる保証レベルやリカバリパスが必要なため、ハイブリッドモデルに落ち着きます。
以下のセグメント化で選択を明確にできます：
- ハードウェアセキュリティキー：AAL3、エクスポート不可の鍵、強力なデバイスアテステーションが必要な特権アクセス時に使用。
- 同期型パスキー： AAL2で十分かつ広範な従業員アクセスにIT運用負荷を抑えたい場合に使用。
- ハイブリッドポリシー：管理者や規制対象ロールにはセキュリティキー、それ以外のユーザーには同期型パスキーを使用。
- リカバリ重視設計：リセットやフォールバック経路も制御セットの一部として扱い、後回しにしない。これらがフィッシング耐性MFAを無効化しうるため。
このセグメント化ができたら、次はサインイン後のID主導アクティビティも検知・阻止できる体制を整えることが重要です。
主なポイント
パスキーと物理セキュリティキーは、FIDO2の暗号技術を通じてフィッシング耐性認証を実現しますが、エンタープライズのニーズは異なります。同期型パスキーはユーザー体験とAAL2での一般従業員向けスケールを重視します。
デバイスバウンドセキュリティキーは、エクスポート不可の認証情報、ハードウェアベースのアテステーション、AAL3準拠を特権ユーザーや規制環境向けに提供します。多くのエンタープライズでは、リスクベースモデルで両者を展開し、認証制御だけでは検知できないID脅威の可視化を重ねることが推奨されます。
よくある質問
パスキーは、パスワードのような共有シークレットの代わりに公開鍵暗号方式を使用するFIDO2認証クレデンシャルです。パスキーを登録すると、デバイスが一意の鍵ペアを生成します。秘密鍵はデバイス上に保持され（またはクラウドプロバイダーを通じて同期され）、サーバーには公開鍵のみが保存されます。
認証は生体認証、PIN、またはデバイスのロック解除で行います。クレデンシャルは特定のドメインに紐付けられ、決して送信されないため、プロトコルレベルでフィッシングやクレデンシャルスタッフィングを防止します。
AAL2およびAAL3は、サインインの信頼性の強度を定義するNISTの認証保証レベルです。AAL2はフィッシング耐性のある認証を要求しますが、プロバイダーの管理下でデバイス間を移動できる同期済み認証情報を許可する場合があります。
AAL3は、ハードウェアによって保護され、エクスポート不可のキーおよびより強力な検証要件を要求することで基準を引き上げます。実際には、同期パスキーはAAL2に適合し、セキュリティキーやその他のデバイスに紐付いた認証器はAAL3で使用されます。
パスキー編集攻撃は、ユーザーインターフェース層を標的とし、パスキーのプロンプトを非表示または抑制することで、ユーザーをパスワードやSMS、その他のより弱いフォールバック手段に誘導します。攻撃者は、中間者プロキシ、操作的なログインページ、またはユーザーの表示内容を変更する悪意のあるブラウザー拡張機能を通じてこれを実行できます。
リスクを低減するためには、フォールバック手段を最小限に抑え、条件付きアクセスルールを適用し、拡張機能ポリシーを厳格に管理してください。また、フォールバック利用の急増が発生した場合には、積極的な強要の兆候であることが多いため、アラートを設定することを推奨します。
段階的な展開は通常、基盤作業から始まります。WebAuthnのサポートを確認し、AAL2とAAL3のポリシーを定義し、堅牢なリセットおよび再登録の手順書を作成します。まず特権ユーザーや高リスクの役割にセキュリティキーを配布し、その後、一般従業員に同期パスキーを段階的に展開します。
導入とサポート体制が安定したら、FIDOのみのポリシーを適用します。移行期間中のロックアウトを防ぐためにレガシー要素は必要な期間のみ維持し、その後廃止します。
はい、ただしガードレールが必要です。企業のパスキーは管理されたコンテナやワークプロファイル内に保存し、個人のクラウドボールトではなく管理下に保管してください。可能な限り管理されたブラウザやアプリでのみパスキー作成を許可し、個人アカウントに登録された企業認証情報を監査してください。
アカウントリカバリーモデルも重要です。リセットがソーシャルエンジニアリングに弱い手順に戻る場合、同期パスキーの保証レベルは大きく低下します。
すべての役割において、単一の認証器が保証、使いやすさ、運用性のバランスを取ることはできないため、両方を使用します。セキュリティキーは、エクスポート不可のキーや認証器の真正性の強力な証明が必要な特権ユーザー、管理者、規制対象の役割に付与します。
同期されたパスキーは、AAL2が十分であり、使いやすさが導入を促進する一般従業員向けに使用します。そして、両グループに対して一貫したフォールバックおよび再登録ポリシーを適用し、攻撃者がユーザーをより弱い要素にダウングレードできないようにします。
