プロンプトとコンテキスト
チームでパスキーの導入を進めています。セキュリティ側は単一のデバイスまたはハードウェアキーにバインドされたクレデンシャルを好み、プロダクト側はデバイス変更後にユーザーがアクセスできなくなることを懸念し、同期型パスキーを求めています。脅威モデル、リカバリ、保証レベル、エンタープライズ統制、そしてリライングパーティ（relying party）が観測できる内容を説明してください。
「パスキー」を単一の保証レベルとして扱わないでください。クレデンシャルがバックアップ可能か、複数デバイス間で使用可能か、エンタープライズによって統制されているか、デバイス紛失後にリカバリ可能かを切り分けて検討してください。
面接官がテストするポイント
面接官は、パスキーがバックアップおよび同期のプロパティが異なる WebAuthn 公開鍵クレデンシャルであることを理解しているかを評価します。FIDO は同期型パスキーをパスキープロバイダーを通じて新しいデバイスでも利用できるものと定義し、デバイスバインド型パスキーは単一のデバイスまたはセキュリティキー上にとどまるものと定義しています。WebAuthn Level 3 ではバックアップ適格性（backup eligibility）とバックアップ状態（backup state）を定義しており、NIST は同期可能な認証器に関するガイダンスを提供しています。
優れた回答では、ユーザー体験、アカウントリカバリ、エンタープライズのライフサイクル、プロバイダーへの信頼、高保証アクションを明確に区別します。同期を「安全でない」と同一視したり、デバイスバインディングを「リカバリ不要」と同一視したりすることはありません。
30秒の回答
「どちらもフィッシング耐性のある公開鍵認証を提供できますが、同期型クレデンシャルは複数デバイスでのリカバリ性を高め、デバイスバインド型クレデンシャルはコピー不可能性と集中ハードウェア制御を要求するポリシーに適しています。私はポリシーを階層化します。通常のサインインには同期型パスキーを使用し、管理者や高価値のアクションにはデバイスバインド型または追加のハードウェアクレデンシャルを適用します。サーバーはクレデンシャル ID、公開鍵、バックアッププロパティ、ステータスを保存しますが、それらのプロパティは絶対的な証拠ではなくポリシー判断のシグナルとして扱います。複数のクレデンシャル登録、失効処理、監査可能なリカバリが必須です。」
ステップごとの分析
ステップ 1: 2つのクレデンシャルタイプを定義する
同期型パスキーは、プラットフォームまたはプロバイダーによって暗号化され、ユーザーの登録済みデバイスに同期されます。デバイスバインド型パスキーは、秘密鍵を単一のデバイスまたはハードウェアセキュリティキー内に保持します。実際の保証レベルはプラットフォーム、ユーザー検証（user verification）、ポリシーに依存するため、名称だけで判断するのは不十分です。
ステップ 2: 脅威と保証レベルによる階層化
一般消費者向けのサインインでは、リカバリ性と複数デバイスの利便性が重視されることがよくあります。管理者、財務承認、鍵管理、高価値の取引では、コピー不可能性、デバイス管理、オフボーディングが優先されます。通常の認証には同期型クレデンシャルを許可し、機密性の高いアクションにはデバイスバインド型クレデンシャルまたはステップアップ検証を要求するようにします。
ステップ 3: サーバー側のフィールドを理解する
WebAuthn レコードには、クレデンシャル ID、公開鍵、署名関連情報、バックアップ適格性およびバックアップ状態のプロパティが含まれます。サーバーはこれらをポリシー適用や監査に利用できますが、バックアップ状態をユーザーの物理デバイスの完全なインベントリとして扱うことはできません。コアとなる検証では、引き続き challenge、origin、RP ID、signature、user verification をチェックします。
ステップ 4: 登録と複数クレデンシャルを設計する
複数のクレデンシャル登録を許可し、作成日時、デバイスラベル、最近の使用状況を表示します。高リスクなロールでは、プライマリと管理されたバックアップ用のクレデンシャルを登録する必要があります。新しいクレデンシャルの登録には、盗まれたセッションによって攻撃者のデバイスが密かにバインドされないよう、既存の高保証認証を要求すべきです。
ステップ 5: リカバリと失効を構築する
デバイスバインド型クレデンシャルを紛失するとアクセスできなくなる可能性があるため、2つ目のクレデンシャルまたはより強固な手動リカバリが必要です。同期型クレデンシャルはデバイス移行時の摩擦を軽減しますが、リカバリと同期の信頼の一部をプロバイダーに委ねることになります。リカバリ時には通知、クーリング期間、または承認プロセスを設け、古いクレデンシャルの失効をサポートする必要があります。
ステップ 6: エンタープライズガバナンスへの対応
組織は、どのロールがどのクレデンシャルタイプを使用しているか、個人の同期アカウントが許可されているか、オフボーディング時にどのようにアクセスを失効させるかを把握する必要があります。デバイス管理、アイデンティティプロバイダーのポリシー、WebAuthn RP の構成が連携して機能する必要があり、フロントエンドのボタンを配置するだけではガバナンスとは言えません。
ステップ 7: 段階的な移行と互換性の維持
初期段階では両方のタイプを許可し、登録率、成功率、リカバリ、サポート状況を測定します。高リスクなロールには期限を設定し、一般ユーザーには適切なガイダンスを提供します。実際の環境でリカバリと異常検知が安定するまでは、パスワードや従来の MFA を削除しないでください。
ステップ 8: セキュリティと体験の成果を検証する
セキュリティの成果には、フィッシングによるアカウント乗っ取り、異常なクレデンシャルバインディング、リカバリの不正利用、失効レイテンシが含まれます。体験の成果には、サインイン成功率、クロスデバイス成功率、登録完了率、デバイス紛失時のリカバリ時間、サポートチケット数が含まれます。これらをロール、プラットフォーム、地域ごとにセグメント化して分析します。
トレードオフ、境界、情報利得
同期型クレデンシャルは紛失やデバイス移行のコストを削減しますが、プロバイダー、アカウントリカバリ、エンタープライズポリシーへの依存度を高めます。デバイスバインド型クレデンシャルはコピー不可能性を高めますが、バックアップデバイス、発行、インベントリ、リカバリ運用が必要になります。高保証だからといって、すべてのユーザーがユーザビリティを犠牲にすべきというわけではありません。
バックアップ適格性や状態はポリシー決定の助けになりますが、完全に検証可能な物理的事実ではありません。同期されているからといって秘密鍵が平文で送信されているわけではありません。実装上の保証とプロダクトの脅威モデルを明確に区別してください。
質の高い模範解答
「私はパスキーをリスクに応じて同期型とデバイスバインド型に階層化します。どちらも WebAuthn 公開鍵認証を使用しており一般的なフィッシングに耐性がありますが、同期型クレデンシャルは通常のマルチデバイスリカバリに適しており、デバイスバインド型クレデンシャルは管理者、鍵管理、高価値のアクションに適しています。
サーバーはクレデンシャル ID、公開鍵、バックアッププロパティ、ステータスを保存し、challenge、origin、RP ID、ユーザー検証を確認します。バックアッププロパティはポリシーや監査の参考になりますが、完全なデバイスインベントリではありません。複数クレデンシャルの登録をサポートし、高リスクユーザーには管理されたバックアップを義務付けます。リカバリ、登録、失効には通知、承認、またはクーリング期間を設けます。まずは並行運用で移行し、乗っ取り、リカバリ、サインイン、サポートのメトリクスを基に強制力を高めていきます。」
よくある間違い
- 同期型パスキーを安全でないと決めつける。 プロバイダーの同期、リカバリ、エンタープライズの脅威モデルについて論じる必要があります。
- デバイスバインド型クレデンシャルにはリカバリが不要だと述べる。 唯一のクレデンシャルを失うとユーザーは締め出されてしまいます。
- 1つのバックアップフィールドをデバイスインベントリとして扱う。 サーバーはすべての物理コピーを推測することはできません。
- 既存の認証なしで新しいクレデンシャルを登録する。 セッションが盗まれると、攻撃者のデバイスがバインドされる可能性があります。
- すべてのロールに単一のポリシーを適用する。 管理者と一般ユーザーでは求められる保証レベルが異なります。
- パスワードや従来の MFA を即座に削除する。 検証されていないリカバリパスは、大量のロックアウトを引き起こします。
- オフボーディングや個人の同期アカウントを無視する。 失効処理やコンプライアンスの強制ができなくなります。
- サインイン成功率のみを測定する。 リカバリ、失効、異常なバインディングこそがセキュリティ上の重要成果です。
フォローアップの質問と回答
同期型パスキーは依然としてフィッシング耐性がありますか？
正しく実装された WebAuthn フローでは、署名は引き続き origin と RP ID にバインドされています。同期はポータビリティとリカバリの信頼モデルを変更するだけであり、オリジンバインディングを損なうものではありません。
どのような場合にデバイスバインド型パスキーを使用しなければなりませんか？
ポリシーによってコピー不可能性が要求され、企業がハードウェアを管理でき、発行やリカバリのコストを許容できる場合です（スーパー管理者、鍵管理、高価値の承認など）。必ず2つ目のクレデンシャルを保持してください。
サーバーはユーザーがデバイスを変更したことをどのように検知しますか？
クレデンシャルレコード、バックアッププロパティ、認証イベントがシグナルを提供しますが、完全なデバイスインベントリではありません。デバイス管理やアイデンティティプロバイダーのログが追加の証拠となる場合があります。
1つのアカウントにいくつのクレデンシャルを設定すべきですか？
リスクとサポート対応能力に基づいて制限を設定しつつ、高リスクなロールにはプライマリおよびバックアップのクレデンシャルを確保させます。追加、削除、リカバリの各アクションには通知と監査ログが必要です。
サインインには同期型クレデンシャルを使用し、機密アクションにはデバイスバインド型を使用することは可能ですか？
はい。これは一般的な階層化ポリシーです。機密性の高いアクションでは、同じセッション内で適切なクレデンシャルを再要求し、明確なリカバリパスを用意する必要があります。