課題とスコープ
ブラウザがマルチテナントWebアプリケーションにアクセスするアーキテクチャをレビューしてください。境界とデータフローの策定、アセットと脅威源の特定、対象脅威・実装脅威・外部脅威の区別、そして対策を検証可能なセキュリティ不変条件へ落とし込む作業をどのように進めますか？
W3C Security Interest Groupは、2026年5月26日にThreat Model for the Web Group Note Draftを公開しました。これは情報提供を目的とした非規範的な文書であり、新しいWeb仕様のセキュリティレビューを支援することを意図しています。その簡略化されたモデルには、ブラウザ、DNS、Web Server、ユーザー、およびネットワーク事業者が含まれます。面接ではドラフトの暗記ではなく、手法と証拠チェーン（Evidence Chain）が評価されます。
面接官が評価するポイント
面接官は、脆弱性リストを挙げる前にシステムとデータフローの全体像が描けているか、アセット・ステークホルダー・脅威源が明示されているか、脅威・脆弱性・影響・対策が明確に区別されているか、そしてセキュリティ目標が検証可能な不変条件として表現されているかを確認します。モデルがどのように進化し、設計文書やレビュー文書に反映されるかを説明してください。優れた回答では、抽象化の境界、モデル化されていない攻撃者の前提条件、およびスコープ外の依存関係がどのように引き渡されるかが述べられます。
回答前に確認すべき質問
- ブラウザプラットフォーム、単一のWebアプリケーション、あるいはそれらの間の新しいWeb APIのどれをレビューしていますか？
- 認証情報、ユーザーデータ、コード、セッション、ネットワークメタデータ、および可用性はすべてスコープに含まれますか？
- フローにはサードパーティ製スクリプト、CDN、DNS、アイデンティティプロバイダー、クロスサイトリクエストが含まれますか？
- これはアーキテクチャレビュー、リリース前セキュリティレビュー、または運用変更レビューのどれに該当しますか？
- どの依存関係と外部脅威が明示的にスコープ外であり、そのフォローアップは誰が担当しますか？
30秒で答えるフレームワーク
「私はまず、コンポーネント、データストア、フロー、ステークホルダーに一意のIDを付与したデータフロー図から着手します。アセットと脅威源を列挙し、脅威ごとに対象フロー、前提条件、影響、既存の統制、残留リスクを記録します。これを対象脅威、実装脅威、または外部依存関係として分類します。各対策はテストや監査証拠、オーナー、更新トリガーを持つセキュリティ不変条件へと変換されます。このモデルはユースケースから始まり設計とともに進化するため、正式なセキュリティレビューの前に完成版が準備されます。」
ステップバイステップの詳細解説
1. まずシステム境界を描く
最小限の実用シナリオから始めます：ブラウザプロセスとストレージ、DNSサービス、Web Server、ユーザー、サイト管理者、ネットワーク事業者です。すべてのコンポーネントに短い一意のIDを付与し、その責務と信頼境界（Trust Boundary）を説明する定義書を作成します。新しいAPIをレビューする場合は、孤立した図を作成するのではなく、その入力、出力、権限、依存関係をこの図の中に配置します。
2. アセットとステークホルダーを列挙する
アセットには、認証情報、セッショントークン、ユーザーコンテンツ、スクリプト、生成元アイデンティティ、DNS解決結果、可用性、プライバシーメタデータなどが含まれます。ステークホルダーには、エンドユーザー、サイト運用者、ネットワーク事業者、アプリケーションプロバイダー、公的機関が含まれます。影響を受ける対象と攻撃する可能性のある主体を区別してください。ユーザーを単にアセットとして扱うと、重要な安全性に関する判断が見落とされます。
3. 脅威源と高レベルの脅威を記録する
各脅威について、その発生源、対象アセット、攻撃経路、および影響を記載します。なりすまし（Spoofing）、改ざん（Tampering）、情報漏えい（Disclosure）、サービス拒否（Denial of Service）、認可バイパスなどの観点でリストを整理できますが、すべての項目を具体的なフローにマッピングする必要があります。脅威は、仕様で対処される『対象脅威』、実装者には知られているが規範的制約には適さない『実装脅威』、依存関係やデプロイに起因する『外部脅威』に分類します。
4. 対策を不変条件（Invariants）に変換する
セキュリティ不変条件とは、「クロスオリジンレスポンスは不正な呼び出し元に認証情報を絶対に渡さない」や「リダイレクトによってスクリプト生成元や権限境界をバイパスできない」など、許可されたすべての実行において維持されるべき条件です。各不変条件を統制手段、およびテスト・ログ・監査証拠に結び付けます。それが仕様の保証、実装の保証、またはデプロイ上の前提条件のいずれであるかを明記します。
component/flow -> asset -> threat source -> impact
-> invariant -> control -> evidence -> owner5. 依存関係と外部脅威を処理する
WebはDNS、TLS、HTTP、証明書、ルーティング、スクリプト、その他のレイヤーに依存しています。単一のモデルですべての依存関係をカバーしているかのように装ってはなりません。継承された前提条件と引き渡しポイントをリストアップします。DNSスプーフィング、リソース改ざん、ネットワーク監視は現在の仕様の範囲外である可能性がありますが、関連技術の脅威モデルを引用し、依存している前提条件を記録します。
6. モデルをライフサイクルと整合させる
ユースケース、解説文書（Explainers）、初期の設計ドラフトとともに脅威モデルを開始し、機能やフローが変更されるたびに更新します。トリガーには、新しいエントリポイント、権限変更、新しい依存関係、ブラウザプロセス境界の変更、実際のインシデントなどが含まれます。モデル、レビューノート、差分（Diff）をバージョン管理し、リスクが追加、解決、または再分類されたかどうかをチームが把握できるようにします。正式な横断的セキュリティレビューの前に、完成したバージョンが存在している必要があります。
7. 対策が機能していることを証明する
単体テストや統合テスト、ブラウザセキュリティテスト、攻撃シミュレーション、設定チェック、ログクエリを活用します。直接テストできない不変条件については、監査可能な根拠、残留リスク、およびそれを受け入れるオーナーを提示します。「脆弱性が見つからなかった」ことは証明になりません。観察スコープ、テスト条件、未カバー領域を明示してください。
高品質な回答例
ブラウザプロセスとストレージ、DNS、Web Server、ユーザー、ネットワーク事業者に一意のIDを付与した最小限のブラウザアクセスシナリオを定義し、すべてのフローに対して定義書を提供します。認証情報、セッション、ユーザーコンテンツ、スクリプト、名前解決結果、プライバシーメタデータをアセットとして列挙します。各脅威には発生源、前提条件、影響を受けるフロー、影響を含め、対象脅威、実装脅威、または外部依存脅威に分類します。すべての対策は、統制、テスト、ログ、または監査証拠およびオーナーに紐づく検証可能な不変条件とします。モデルはユースケースと最初の設計ドラフトから開始し、エントリポイント、依存関係、権限が変更されたときに更新し、セキュリティレビューの前にバージョン管理を行います。DNS、TLS、スクリプト、ルーティングについては関連モデルを引用し、残留リスクを明確にします。これにより、レビューは実装と将来の変更の双方にとって有用なものとなります。
よくある落とし穴
- 脆弱性名のみを列挙する → 境界やフローが存在しない → まずコンポーネント、フロー、信頼境界を描く。
- 脅威、脆弱性、影響を混同する → 対策の検証ができなくなる → 発生源、前提条件、影響、統制を分けて記録する。
- すべてのリスクを現在の仕様に詰め込む → スコープが不正確になる → 対象脅威、実装脅威、外部脅威を分類する。
- リリース直前にモデルを1つだけ作成する → 設計変更が見落とされる → ユースケースから開始し、更新トリガーを定義する。
- セキュリティ目標をスローガンとして書く → 受け入れ証拠が存在しない → テスト、ログ、監査に紐づく不変条件として書き直す。
- 残留リスクを無視する → 意思決定の追跡ができなくなる → 未カバー領域、受け入れオーナー、フォローアップアクションを明記する。
フォローアップの質問と回答
なぜ最初にすべての攻撃者を列挙しないのですか？
コンポーネント、アセット、フローを最初に定義することで、スコープの拡散を防ぎます。攻撃者モデルを追加することは可能ですが、動機に関する推測は、境界と検証可能な統制の分析の代わりにはなりません。
サードパーティ製スクリプトはどのように扱いますか？
スクリプトのソース、読み込みフロー、アクセス可能な認証情報、実行権限をモデルに組み込みます。ソースの制限、分離、監視の不変条件を定義します。ベンダーが統制を所有している場合は、引き渡しの証拠と残留リスクを記録します。
外部依存関係がプロジェクトのリスクになるのはどのような場合ですか？
そのセキュリティ上の前提条件がスコープ内のアセットや不変条件に直接影響する場合、またはプロジェクトが依存関係の保証を検証できない場合、脚注で済ませるのではなく、緩和策や受け入れオーナーを設定して現在のリスクとして記録します。
セキュリティレビューモデルが複雑すぎる場合はどうしますか？
主要なリスクをカバーする最小限の図を維持し、プロトコルやデプロイの詳細をリンクされたサブモデルに分割して、コンポーネントとフローのIDによる追跡可能性を維持します。重要な境界を削除することによって複雑さを減らしてはなりません。
プロダクトオーナーに残留リスクをどのように説明しますか？
影響を受けるアセット、考えられる攻撃経路、現在の統制、テスト証拠、ビジネスへの影響を説明します。コスト、期限、明示的な受け入れオーナーを含む選択肢を提示し、「完全に安全」といった表現や根拠のない確率の主張は避けます。