プロンプトとスコープ
このプロダクトに関する質問では、セキュリティ制御をいかに段階的な体験へと落とし込めるかが試されます。目標はすべてのページでパスワードの再入力を求めることではなく、価値の高いアクション、リスクシグナル、認証強度、リカバリ、および測定指標を定義することです。
面接官が評価しているポイント
- 資産価値と不可逆性に基づいてアクションのリスクをランク付けできるか。
- 再認証、MFA、デバイストラスト、リスクシグナルの明確な役割を理解しているか。
- アクセシビリティ、クロスデバイス利用、エンタープライズSSO、アカウントリカバリに対応できるか。
- セキュリティ、成功率、離脱率、サポートコストを総合的に評価できるか。
確認すべき明確化のための質問
ユーザーロール、テナント権限、可逆性、データの機密性、エンタープライズIDプロバイダーの機能、現在のセッション有効期間、MFAカバー率、リカバリチャネルを確認します。さらに、セッションハイジャック、共有デバイス、内部関係者によるミス、高リスクログイン後のアカウント乗っ取りなど、脅威モデルも明確にします。
30秒の回答フレームワーク
私ならアクションリスクマトリクスを構築します。テナント全体のエクスポート、MFA変更、支払い情報の変更、テナント削除は高リスクとし、レポートの閲覧は低リスクとします。高リスクなアクションでは、既存の強力な要素やWebAuthnなどを使用した時間制限付きの再認証をトリガーし、リスクイベント後や新しいデバイスでは要件をより厳格にします。このフローには、明確な理由付け、アクセシブルな代替手段、制御されたリカバリ、および監査イベントが必要です。段階的にロールアウトし、プロンプトの表示回数だけでなく、高リスクのブロック数、正当な完了率、離脱率、乗っ取りインシデント、サポートコストを測定します。
ステップバイステップの解決策
1. ページ単位ではなく、アクション単位でリスクを定義する
影響範囲（blast radius）、不可逆性、権限昇格、データの機密性によってアクションをスコアリングします。テナント削除、個人データのエクスポート、リカバリ要素の変更、管理者権限の付与は高リスク群に属します。通常の閲覧や可逆的な設定変更は、通常それほど多くの摩擦を必要としません。プロダクト、セキュリティ、法務、サポートの各部門が連携してマトリクスを承認する必要があります。
2. 認証強度と有効期間を選択する
高リスクなアクションには、プライマリクレデンシャルに加えてMFA、またはフィッシング耐性のあるWebAuthnセレモニーを要求できます。再認証アサーションは、ユーザー、テナント、アクションスコープ、および短い有効期間にバインドされている必要があり、長期間有効なパスになってはなりません。新しいデバイス、通常と異なる場所、リカバリ完了直後などのシグナルは、有効期間を短縮したり要件を引き上げたりするために使用すべきであり、自動的に拒否の唯一の理由にしてはなりません。
3. 理解しやすくアクセシブルな体験を設計する
なぜ検証が必要なのか、何が保護されているのか、完了後に何が起こるのかを説明します。キーボード操作、スクリーンリーダー、単一の生体認証に依存しない代替手段をサポートします。エンタープライズSSOユーザーは、各自のIDプロバイダーに戻るようにします。エラーメッセージで内部のリスクルールを明かしたり、失敗を繰り返したユーザーをループに閉じ込めたりしないようにします。
4. リカバリと例外経路を計画する
MFAデバイスの紛失、クロスデバイス承認、アカウントリカバリ、エンタープライズ管理者による支援には、明確な経路が必要です。リカバリ自体が高リスクであるため、より脆弱なバックアップ用の質問によってステップアップをバイパスさせてはなりません。理由を記録し、関係するユーザーに通知し、新しく追加されたリカバリ要素が機密アクションを即座に認可することを制限します。
5. 制御をバックエンドの認可および監査と連携させる
フロントエンドのプロンプトだけでは保護になりません。サーバーはセッションの再認証アサーション、アクション、およびテナントスコープを検証し、別のAPIに対してリプレイできないようにする必要があります。監査イベントには、アクター、テナント、アクション、認証方法、要約されたリスクシグナル、および結果を記録します。ログにはシークレットや完全なクレデンシャルを保持してはなりません。機密データを扱うサービスには、引き続き正しく設定されたTLSが必要です。
6. セキュリティとプロダクトの成果を段階的に検証する
社内テナントと高リスクアクションのごく一部から開始します。拡大する前に、認証成功率、離脱率、リカバリ、誤拒否、サポートチケットを観察します。セキュリティ指標にはブロックされた高リスクアクション、セッション乗っ取り、異常なリカバリが含まれ、体験指標には完了時間、成功率、繰り返しプロンプトが含まれます。リスクが低下する一方で正当なユーザーの失敗が増加した場合は、制御を単に無効化するのではなく、アクショングレード、有効期間、またはリカバリを調整します。
質の高い模範解答
私ならまずセキュリティ、サポート、エンタープライズ管理者とともに脅威モデルを確認し、影響範囲、不可逆性、権限昇格、データの機密性に基づいてアクションをランク付けします。テナント全体のエクスポート、MFA変更、支払い変更、テナント削除は高リスクとし、レポート閲覧は低摩擦のままにします。高リスクなアクションは、WebAuthnやエンタープライズMFAなどを通じて、ユーザー、テナント、アクションにバインドされた短期間のアサーションをトリガーします。新しいデバイス、通常と異なる場所、最近のリカバリなどがある場合は要件を引き上げます。UIでは理由を説明し、キーボード、スクリーンリーダー、エンタープライズIdPのパスをサポートする一方で、リカバリ時に脆弱な要素を用いて保護をバイパスすることは防ぎます。サーバーがアサーションを検証して監査イベントを書き込みます。フロントエンド単体で認可を行うことはできません。段階的にローンチし、高リスクブロック、正当な成功、離脱、乗っ取り、サポートコストを監視した上で、データに基づいてマトリクスや有効期間を調整します。
よくある間違い
- ユーザーが制御をバイパスしたり無効化したりするまで、すべてのページで新規ログインを要求すること。
- APIがアクションスコープを無視しているにもかかわらず、フロントエンドで再認証ダイアログを表示すること。
- 脅威モデルなしに、SMSや秘密の質問を高リスクの唯一のリカバリ経路として使用すること。
- エンタープライズSSO、アクセシビリティ、クロスデバイス、またはMFA紛失時の経路を考慮から外すこと。
- 乗っ取り、誤拒否、完了時間、サポートデータを見ずに、プロンプトの表示回数だけを測定すること。
- ユーザー向け文言や監査ログに生のリスクシグナルを書き込み、検知の詳細を公開してしまうこと。
フォローアップの質問と回答
1回のログインで十分なのはどのような場合ですか？
低リスクで可逆的であり、影響範囲が小さい読み取りや設定変更は、現在のセッションを再利用できます。ステップアップを省略できるかどうかは、アクションのリスク、セッション状態、組織のポリシーに依存します。「ユーザーがすでにログインしているから」だけでは不十分です。
新しいデバイスでは常に機密性の高いアクションをブロックすべきですか？
いいえ。新しいデバイスは確証レベル（assurance）を引き上げるためのシグナルであり、悪意の証明ではありません。より強力なMFAを要求したり、テナント管理者に通知したり、アサーションの有効期間を短縮したりした上で、誤拒否や乗っ取りのデータを見ながら調整します。
再認証アサーションのリプレイをどのように防ぎますか？
サーバー側でユーザー、テナント、アクション、リソース、および短い時間枠にバインドし、操作が成功した後に消費（破棄）するかローテーションします。汎用的な「verified（検証済み）」フラグだけで、すべての機密APIを認可してはなりません。
ユーザーがMFAを完了できない場合はどうしますか？
エンタープライズ管理者による支援や別の強力な要素など、通知とクーリング期間を設けた監査可能なリカバリ経路を提供します。リカバリ自体が高リスクアクションの保護を直接バイパスしてはなりません。