プロンプトとコンテキスト
担当するB2B SaaSにおいて、フィッシングによる管理者アカウントの乗っ取りが発生しました。管理者は顧客データのエクスポート、アイデンティティポリシーの変更、メンバーの招待を行う権限を持っています。チームはパスキーまたはFIDO2セキュリティキーの必須化を検討していますが、移行コスト、デバイスの紛失、サポート件数の増加を懸念しています。
必須化すべきかどうか、どのユーザーを対象に先行導入するか、移行とリカバリーをどのように機能させるか、例外の有効期限をどのように設定するか、そしてセキュリティ上の価値をビジネスとしてどのように証明するかを決定してください。これはプロダクトの意思決定であり、ベンダーの選定から始めないでください。
面接官が見ているポイント
面接官は、脅威の深刻度、影響を受けるユーザー、変更の可逆性、コンプライアンス上の責務、および開発・運用コストを考慮した1つの意思決定を求めています。CISAはフィッシング耐性のあるMFAへの移行を組織に推奨しており、NISTは検証者名バインディング（verifier name binding）を定義し、OWASPは高リスクなアクションに対するリスクベースMFAや再認証を推奨しています。
優秀な候補者は、「今日すべてのユーザーに強制する」ことだけを選択肢とは捉えません。管理者を階層化し、安全基準のベースラインを作成し、リカバリープロセスを設計し、観測されたデータに基づいて対象を拡大します。また、フィッシング耐性のある方式と、セキュリティレベルや移行に伴う摩擦が異なるSMSや通常のプッシュ通知とを明確に区別します。
30秒の回答
「権限とリスクの露出度に基づいて管理者をランク付けし、フィッシング耐性のあるMFAへの移行を進めます。まず特権管理者（スーパー管理者）およびデータエクスポート権限を持つロールに対してパスキーまたはFIDO2セキュリティキーを必須とし、その他の管理者には移行期限を設定します。強制適用前に、互換性、セカンド認証器の登録、およびリカバリーのテストを実施します。例外措置には期限を設け、最小権限を適用し、承認と監視を必須とします。アカウント乗っ取り件数、フィッシング耐性MFAのカバー率、完了率、サポートチケット数、高リスクアクションのブロック件数を測定します。セキュリティ価値が実証され、摩擦がガードレール内に収まっていれば、ロールごとに対象を拡大します。」
ステップごとの分析
ステップ 1: 意思決定と脅威の定義
管理者の権限を整理します。顧客データの閲覧、データのエクスポート、SSOの変更、メンバーの招待では、それぞれ影響度が異なります。アカウント乗っ取りインシデント、攻撃経路、データの機密性、潜在的な損失に基づいてベースラインを確立します。目標は、指定期間内における高影響な乗っ取りインシデントの測定可能な削減です。
ステップ 2: 認証オプションの比較
フィッシング耐性のある方式は、検証者バインディングと公開鍵暗号を使用するため、偽サイトが再利用可能な共有シークレットを簡単に取得することはできません。パスキーはプラットフォームや同期されたクレデンシャルに依存する場合があり、セキュリティキーはハードウェアの調達とライフサイクル管理が必要です。SMS、秘密の質問、通常のメールコードは移行期やリカバリー手段としては使用できますが、同等の保護手段として提示すべきではありません。
ステップ 3: ユーザーと権限のセグメンテーション
特権管理者、請求・データエクスポート管理者、アイデンティティポリシー管理者、高権限のサポートツールから開始します。閲覧専用の管理者は、まず移行タスクとリスク教育の対象とすることができます。企業規模のみよりも、付与されている権限とアクセス可能なデータの方が優先度を判断する上で強力な指標となります。
ステップ 4: 移行とリカバリーの設計
ブラウザ、OS、ハードウェアの互換性データを収集します。少なくとも2つの登録パスを提供し、セカンド認証器または組織が保持するセキュリティキーの登録をユーザーに求めます。デバイス紛失時には、既存の管理者による承認とビジネス上の証跡を伴う監査可能なリカバリープロセスが必要であり、サポートが無条件のリセット用バックドアになってはなりません。
ステップ 5: 例外処理と段階的な強制適用
レガシーデバイス、特定の地域、または自動化アカウントに対する期限付きの例外を定義します。各例外には、最小権限、追加の承認、短い有効期間、アラートを紐づけます。登録リマインダーから、リスクの高いアクション実行時のチャレンジ、高リスク操作の制限、そして最終的なログイン時の強制適用へと段階的に進めます。
ステップ 6: 成果とガードレールの定義
成果指標には、管理者アカウントの乗っ取り件数、フィッシング耐性MFAのカバー率、高リスクアクションのブロック件数が含まれます。ガードレール指標には、登録完了率、失敗率、リカバリー時間、サポート件数、ログイン成功率、誤検知によるブロック率が含まれます。ロール、地域、デバイス、顧客規模ごとにセグメント化し、少数のグループの失敗が平均値によって隠れないようにします。
ステップ 7: 判定基準（ゲート）を設けたパイロット運用の実施
社内管理者または協力的な顧客を対象にパイロット運用を実施し、リマインダー、リスクベースのチャレンジ、強制登録の効果を比較します。コンバージョンデータを取得するために、高リスクグループを長期間の無作為化実験に晒してはなりません。事前/事後のベースライン、段階的ロールアウト、過去のデータとの比較を使用します。開始前に、拡大、一時停止、ロールバックの条件を策定しておきます。
ステップ 8: 長期的な運用の構築
認証器の登録、失効、リカバリー、従業員のオフボーディング、顧客管理者の変更を追跡します。プロダクト、サポート、セキュリティ、コンプライアンスが共同でポリシーを所有する必要があります。重大なインシデントが発生した後は、単に一時的な確認プロンプトを増やすのではなく、セグメンテーション、リカバリーの証跡、例外の期限を見直します。
トレードオフ、境界条件、得られる情報
強制適用を早めればリスクに晒される時間は短縮されますが、互換性やリカバリーへの負荷が増大します。段階的な移行は業務への影響を低減しますが、移行期間中の継続的な監視が必要です。パスキーはハードウェアキーよりも日常的な摩擦を減らせる可能性がありますが、エンタープライズ企業では調達、配布、オフボーディングの管理が必要となる場合があります。
フィッシング耐性のあるMFAは、リバースプロキシサイトによるクレデンシャルの詐称奪取を低減しますが、悪意のある管理者が自らアクションを承認することを防ぐことはできず、最小権限の原則、承認フロー、異常検知、エクスポートの監査に代わるものではありません。自動化アカウントには、人間のログインポリシーではなく、ワークロードアイデンティティ（workload identity）や有効期間の短いクレデンシャルを使用する必要があります。
模範解答の例
「リスクベースで階層化したプロダクトプログラムとして、フィッシング耐性のあるMFAの導入を進めます。乗っ取り時の被害が最も大きい特権管理者、データエクスポート担当、アイデンティティポリシー担当を最初の対象とします。パスキーおよびFIDO2セキュリティキーを目標とする方式とし、SMSや通常のプッシュ通知は移行期またはリカバリー用の選択肢として明確に位置付けます。
まず社内パイロットを実施してプラットフォームの互換性、セカンド認証器の登録、紛失時のリカバリーをテストします。その後、3つの段階（リマインダーとリスクベースのチャレンジ、期限前の高リスクアクション制限、最終的なログイン強制）で適用を進めます。例外には有効期限、最小権限、承認フロー、アラートが必要です。成果指標は乗っ取り件数、カバー率、完了率、高リスクブロック件数とし、ガードレールはリカバリー時間、サポート件数、誤ブロック率とします。事前に設定したセキュリティ価値とガードレールが満たされた場合にのみ対象を拡大します。」
よくある間違い
- 初日からすべてのユーザーに強制する。 互換性の確認やリカバリーのリハーサルを行わないと、アカウントロックアウトのインシデントが発生します。
- SMS、通常のプッシュ通知、フィッシング耐性MFAを同等に扱う。 リバースプロキシ型フィッシングに対する耐性が異なります。
- 登録率のみを測定する。 高リスクなロールが除外されたままでも、全体のカバー率が見かけ上上昇することがあります。
- セカンド認証器とリカバリーの証跡を省略する。 デバイス紛失時にサポート窓口がセキュリティのバックドア化してしまいます。
- 例外を恒久化する。 例外リストの肥大化は、最も攻撃されやすい経路になります。
- 顧客規模のみで優先順位をつける。 権限の強さとデータへの影響度の方がより直接的な指標です。
- 自動化アカウントを無視する。 人間向けのMFAでは、長期有効なサービスクレデンシャルの問題は解決しません。
- 高リスクユーザーを危険に晒すセキュリティ実験を行う。 パイロットユーザーを保護し、中止条件をあらかじめ定義してください。
フォローアップの質問と回答
なぜ最初に全員に対してSMS MFAを必須化しないのですか？
SMSはベースラインのセキュリティを向上させますが、フィッシング耐性はありません。高権限ロールに明確な移行期限を設けた上で、一時的な移行手段として活用することは可能です。
強制適用がビジネスを損なわなかったことをどのように証明しますか？
成果指標とガードレールを併せて追跡します。乗っ取り件数、高リスクブロック件数、カバー率が改善する一方で、リカバリー時間、チケット数、誤ブロック率が閾値以下に収まっていることを確認します。結果はロールおよび地域別にセグメント化して分析します。
顧客がセカンド認証器の登録を拒否した場合はどうしますか？
高権限ロールの利用条件とし、監査可能な組織リカバリー経路を提供し、例外には明示的な有効期限を設定します。登録拒否が無条件のサポートリセットにつながる状態にしてはなりません。
同期型パスキーはセキュリティを弱めますか？
画一的な回答をするのではなく、脅威モデルとプラットフォームの実装に基づいて判断します。極めて高い保証レベルが求められるロールにはハードウェアキーが必要な場合がありますが、一般的な管理者であってもデバイス管理、失効、リカバリーの統制は依然として必要です。
一般の管理者にはいつ拡大しますか？
高権限ロールを対象としたパイロットにおいて、カバー率、完了率、乗っ取り削減の目標を達成し、リカバリーとサポートのガードレールが安定していることを確認した後に拡大します。スケジュールだけでなく、権限とデータへの影響度に基づいて拡大を判断します。