プロンプトとコンテキスト
既存のログインシステムは、長寿命Cookieを使用してユーザーのサインイン状態を維持しています。セキュリティチームは、Cookie盗難後のクロスデバイスでのリプレイ攻撃を減らしたいと考えていますが、すべてのクライアントを一度にアップグレードすることや、鍵のローテーション、ブラウザの再起動、デバイスの復元時に大量のログアウトを発生させることはできません。登録、リフレッシュ、失効、フォールバック、監査、段階的ロールアウトを網羅するDBSC統合を設計してください。
面接官がテストしていること
- 長寿命のアイデンティティセッション、短寿命の認可Cookie、デバイスの秘密鍵を分離できているか。
- 登録およびリフレッシュエンドポイント、チャレンジ・レスポンス、サーバー側のバインディングレコードを説明できるか。
- エクスポート不可能な鍵、非対応ブラウザ、Cookieの欠落、デバイスの移行を適切に処理できるか。
- 失効、鍵のローテーション、同時リフレッシュ、異常検知を設計できるか。
- ロールアウト、監視、ロールバックにおいて、互換性とセキュリティの境界が考慮されているか。
最初に明確にすべき質問
- どのタイプのアカウントや操作にデバイスバインディングが必要で、どの場合は通常のCookieを維持してよいか？
- セッションの最大有効期限、リフレッシュ間隔、許容される再ログイン率はどのくらいか？
- 複数デバイス、エンタープライズプロキシ、TPM非搭載デバイス、クロスサイトサブドメインへの対応は必要か？
- 証明の検証に失敗した場合、システムはサインアウトさせるか、MFAにフォールバックするか、それとも高リスクアクションを凍結するか？
- 既存のゲートウェイは登録およびリフレッシュヘッダーを通過させられるか、またどのフィールドをログに記録してよいか？
30秒での回答
「私は既存のログイン状態を互換性レイヤーとして維持します。ログイン後、Secure-Session-Registration レスポンスによってブラウザにデバイス鍵の生成を要求します。サーバーは公開鍵、セッション識別子、リフレッシュエンドポイント、スコープ、ステータスのみを保存し、長寿命Cookieを短寿命Cookieに置き換えます。期限切れになると、ブラウザは鍵の証明を添えてリフレッシュエンドポイントを呼び出し、サーバーは署名、チャレンジ、セッション、リスクポリシーを検証してから新しいCookieを発行します。登録やリフレッシュの失敗時は、機能とリスクに応じて通常のセッションまたはMFAにフォールバックします。失効、ローテーション、監査、ロールアウトのメトリクスによって展開を制御します。」
ステップごとの詳細解説
1. 信頼境界と状態の定義
ログインサービスは引き続きユーザーを認証し、DBSCレイヤーはブラウザがセッションにバインドされた秘密鍵を保持していることを証明します。sessionId、公開鍵、鍵バージョン、リフレッシュURL、スコープ、短寿命Cookie名、ステータス、最終証明時刻を保存します。秘密鍵を保存したり、公開鍵自体をユーザーのアイデンティティとして扱ったりしてはいけません。
2. デバイスバインドセッションの登録
ログイン成功後、登録レスポンスヘッダーを返します。ブラウザは鍵ペアを生成し、公開鍵を登録エンドポイントに送信します。サーバーはワンタイム登録トークン、ログインセッション、オリジンを検証し、バインディングを書き込み、JSONセッション指示と短寿命Cookieを返します。再試行によって失効不能な孤立バインディングが作成されないよう、登録は冪等（べきとう）でなければなりません。
Secure-Session-Registration: (ES256); path="/StartSession"
Set-Cookie: auth_cookie=short-lived; Max-Age=600; Secure; HttpOnly; SameSite=Lax3. リフレッシュ時の鍵証明の検証
短寿命Cookieの期限が近づくと、ブラウザはDBSC証明JWTを添えてリフレッシュエンドポイントを呼び出します。署名アルゴリズム、チャレンジ、セッション識別子、時間枠、鍵バージョン、スコープを検証し、チャレンジまたはリフレッシュカウンターをアトミックに進めます。証明に失敗した後に古いCookieを暗黙的に延長してはなりません。観測可能な理由を返し、リスクポリシーを適用します。
4. フォールバックと複数デバイスの処理
DBSCは追加機能（アドティブ）です。ブラウザやハードウェアがサポートしていない場合は通常のセッションを維持しつつ、高リスクなアクションにはMFAを要求します。デバイスごとに1つのバインディングを保存します。1台のデバイスを失効させるとそのバインディングのみが削除され、グローバルログアウトではすべてのバインディングと通常のセッションが失効します。フォールバックパスが悪用の抜け穴にならないよう、短い有効期間とレート制限が必要です。
5. ローテーション、並行処理、リカバリの設計
鍵のローテーションでは、短い重複期間を持つ新しいバージョンを作成します。古いバージョンには1回限りの制御された移行のみが許可されます。セッションロックまたは条件付きバージョン更新を使用して、同時リフレッシュが互いのチャレンジを上書きしないようにします。ブラウザの復元、サイトデータの消去、または鍵の紛失時は古いバインディングを失効させて再認証を要求します。リフレッシュの失敗が自動的に恒久的な利用停止になってはいけません。
6. 監視、監査、および段階的なロールアウト
登録成功数、証明失敗数、リフレッシュレイテンシ、フォールバック率、デバイス失効理由、ブラウザバージョンの分布を記録しますが、秘密鍵は絶対に記録しません。低リスクのアカウントから開始し、ハイジャックアラートとログイン成功率を比較します。失敗が増加した場合は、登録レスポンスヘッダーを削除して通常のCookieパスを維持しながら新規バインディングを停止します。ポリシーや鍵バージョンの変更は、不変（イミュータブル）な監査ログに記録します。
優れた回答例
「DBSCは、ブラウザがセッションにバインドされた秘密鍵を保持していることのみを証明し、既存のログインシステムが引き続きユーザーを認証します。ログイン後、サーバーは登録レスポンスヘッダーを使用してブラウザに鍵を生成させ、その公開鍵を送信させた後、長寿命Cookieを短寿命Cookieに置き換えます。リフレッシュエンドポイントは、証明JWTの署名、チャレンジ、セッション、時間、スコープを検証してから、アトミックにチャレンジを進めて新しいCookieを発行します。サーバーは公開鍵、ステータス、バージョン、監査データを保存し、秘密鍵は一切保存しません。複数デバイスには個別のバインディングが付与され、失効は単一のデバイスまたはユーザー全体を対象にできます。非対応のクライアントは制限付きの通常セッションまたはMFAを使用します。ロールアウト中は、証明の失敗、フォールバック、ログイン成功率を監視し、リスクが高まった場合は登録ヘッダーを削除して互換性を維持します。」
よくある間違い
- 公開鍵をユーザーのアイデンティティとして扱う → バインディングの主体と認証の主体が混同される → セッション証明の材料としてのみ使用する。
- 長寿命Cookieの有効期限を短くするだけにする → 盗難者がその有効期間中にリプレイできる状態が残る → 短寿命Cookieを鍵の証明にバインドする。
- リフレッシュ時のリプレイ保護を省略する → 1つの証明が再利用される可能性がある → ワンタイムチャレンジ、時間枠、アトミックな状態更新をバインドする。
- 非対応時に全員をサインアウトさせる → 互換性と可用性が損なわれる → 機能とリスクに応じて通常のセッションまたはMFAにフォールバックする。
- DBSCを取り消し不能なものとして扱う → 紛失したデバイスを隔離できない → 監査機能を備えたデバイスレベルおよびユーザーレベルの失効機能を提供する。
フォローアップ質問と回答
秘密鍵はあらゆる形式のCookie盗難を防げますか？
いいえ。DBSCは主に、Cookieが別のデバイスにエクスポートされた後の直接的なリプレイ攻撃を低減します。元のデバイスを制御するマルウェア、ログイン時の攻撃、または侵害されたサーバーに対しては、依然として他の防御策が必要です。脅威モデルと残存リスクを明確に述べてください。
なぜ通常セッションのパスを維持するのですか？
ブラウザ、ハードウェア、エンタープライズネットワークの機能はそれぞれ異なり、DBSCはまだ標準として策定が進んでいる段階だからです。制限付きの互換性パスを設けることで大量ログアウトを防ぎ、ログインを失敗させる代わりに高リスクアクションに対してより厳格なチェックを要求できます。
同時リフレッシュの競合をどのように防ぎますか？
sessionId と鍵バージョンに対する条件付き更新を使用し、現在のチャレンジのみを受け入れ、次のチャレンジとCookieバージョンをアトミックに書き込みます。重複したリクエストには同じ結果を返すか、再度のリフレッシュを要求することで、レスポンスによる相互の上書きを防ぎます。
デバイスの移行や復元時には何が起こりますか？
古い秘密鍵をコピーするのではなく、新しいデバイスとして登録します。リスクチェックを行いつつ古いバインディングを短い猶予期間だけ維持し、再認証後に新しい公開鍵バインディングを作成して、ユーザーがデバイス管理画面から古いレコードを失効できるようにします。