security-threat-model

セキュリティ脅威モデル

目次

1. ワークフロー
2. STRIDE フレームワーク
3. 信頼境界のマッピング
4. 一般的なパターン
5. ガードレール
6. クイックリファレンス

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Security Threat Model Progress:
- [ ] Step 1: Map system architecture and data flows
- [ ] Step 2: Identify trust boundaries
- [ ] Step 3: Classify data and compliance requirements
- [ ] Step 4: Apply STRIDE to identify threats
- [ ] Step 5: Define mitigations, monitoring, and prioritize risks

ステップ 1：システムアーキテクチャとデータフローをマッピングする

コンポーネント、外部サービス、ユーザー、データストア、通信経路を記録します。アーキテクチャの例については、一般的なパターンを参照してください。単純なシステムの場合 → resources/template.mdを使用してください。

ステップ 2：信頼境界を特定する

データがセキュリティドメインをまたぐ箇所（ユーザー → サーバー、サーバー → データベース、内部 → サードパーティ）をマークします。境界の種類については、信頼境界のマッピングを参照してください。

ステップ 3：データとコンプライアンス要件を分類する

データの機密性（公開、内部、機密、制限対象）を評価し、PII/PHI/PCI を特定して、コンプライアンス上の義務（GDPR、HIPAA、PCI DSS）を記録します。分類表については、resources/template.mdを参照してください。

ステップ 4：STRIDE を適用して脅威を特定する

各信頼境界とデータフローについて、STRIDE の 6 つの脅威カテゴリすべてを体系的に確認します。脅威の特定については、STRIDE フレームワークを参照してください。複数の攻撃対象領域がある複雑なシステムの場合 → 高度な攻撃ツリー分析と DREAD スコアリングについて、resources/methodology.mdを確認してください。

ステップ 5：緩和策、監視、リスクの優先順位を定める

予防・検知・是正のための対策を提案し、監視とアラートを設定して、リスクスコア（可能性 × 影響度）に基づいて優先順位を付けます。resources/evaluators/rubric_security_threat_model.jsonを使用して自己評価してください。最低基準：平均スコア ≥ 3.5。

STRIDE フレームワーク

S - なりすまし

• 脅威：攻撃者が正規のユーザーまたはシステムになりすまします
• 例：認証情報の窃取、セッションハイジャック、発信者番号の偽装、メールの偽装
• 緩和策：多要素認証、証明書の検証、暗号署名、相互 TLS

T - データの改ざん

• 脅威：転送中または保存中のデータが不正に変更されます
• 例：中間者攻撃、SQL インジェクション、ファイルの改変、メッセージのリプレイ
• 緩和策：HTTPS/TLS、入力検証、パラメーター化クエリ、デジタル署名、チェックサム、イミュータブルストレージ

R - 否認

• 脅威：ユーザーが実行した操作を否認し、活動の証拠がありません
• 例：ログの削除、署名のないトランザクション、監査証跡の欠落
• 緩和策：包括的な監査ログ、トランザクションへのデジタル署名、改ざん防止ログ、第三者によるタイムスタンプ付与

I - 情報漏えい

• 脅威：機密情報が権限のない相手に漏えいします
• 例：データベースダンプ、詳細すぎるエラーメッセージ、暗号化されていないバックアップ、API による過剰なデータ取得
• 緩和策：保存時および転送時の暗号化、アクセス制御、データの最小化、安全な削除、ログ内の情報のマスキング

D - サービス拒否

• 脅威：システムが利用不能になる、またはパフォーマンスが低下します
• 例：リソースの枯渇、分散攻撃、アルゴリズムの計算量を悪用する攻撃、ストレージの容量不足
• 緩和策：レート制限、自動スケーリング、サーキットブレーカー、入力サイズ制限、CDN/DDoS 保護

E - 権限昇格

• 脅威：攻撃者が不正にアクセス権または権限を取得します
• 例：SQL インジェクションによる管理者権限の取得、IDOR による他のユーザーデータへのアクセス、パストラバーサル、権限昇格の脆弱性
• 緩和策：最小権限の原則、入力検証、すべてのリクエストに対する認可チェック、ロールベースのアクセス制御

信頼境界のマッピング

信頼境界：信頼レベルの異なるセキュリティドメイン間でデータが移動する場所です。

一般的な境界：

• ユーザー → アプリケーション：信頼できない入力がシステムに入ります（検証、サニタイズ、レート制限）
• アプリケーション → データベース：アプリケーションの認証情報とユーザー権限の境界です（パラメーター化クエリ、コネクションプーリング）
• 内部 → 外部サービス：データが管理下から離れます（暗号化、監査ログ、契約条件）
• パブリックネットワーク → プライベートネットワーク：インターネットから内部システムへの境界です（ファイアウォール、VPN、API ゲートウェイ）
• クライアント側 → サーバー側：JavaScript からバックエンドへの境界です（クライアントを決して信用せず、サーバー側で再検証）
• 特権コード → 非特権コード：管理者機能とユーザーコードの境界です（隔離、プロセスの分離、セキュリティ境界）

境界分析の質問：

• この境界を越えるデータは何ですか？（機密性を分類する）
• それぞれの側にいるのは誰／何ですか？（認証、認可）
• この境界を越える際に何が問題になる可能性がありますか？（STRIDE を適用する）
• この境界を保護する制御は何ですか？（認証、暗号化、検証、レート制限）

一般的なパターン

パターン 1：データベースを備えた Web アプリケーション

• 境界：ユーザー ↔ Web サーバー ↔ データベース
• 重大な脅威：SQLi（改ざん）、XSS（なりすまし）、CSRF（なりすまし）、セッションハイジャック（なりすまし）、IDOR（権限昇格）
• 主な緩和策：パラメーター化クエリ、CSP ヘッダー、CSRF トークン、HttpOnly/Secure Cookie、認可チェック

パターン 2：サードパーティー OAuth を使用する API

• 境界：ユーザー ↔ フロントエンド ↔ API サーバー ↔ OAuth プロバイダー ↔ サードパーティー API
• 重大な脅威：トークン窃取（なりすまし）、スコープの拡大（権限昇格）、認可コードの傍受、リダイレクト URI の改ざん
• 主な緩和策：パブリッククライアント向けの PKCE、state パラメーターの検証、トークンローテーション、最小限のスコープ、HTTPS のみを使用

パターン 3：マイクロサービスアーキテクチャ

• 境界：API ゲートウェイ ↔ サービス A ↔ サービス B ↔ メッセージキュー ↔ データベース
• 重大な脅威：サービスのなりすまし（なりすまし）、ラテラルムーブメント（権限昇格）、メッセージの改ざん（改ざん）、サービスの列挙（情報漏えい）
• 主な緩和策：サービス間の mTLS、サービスメッシュ、サービスごとの API 認証、ネットワークポリシー、最小権限の IAM

パターン 4：ファイルアップロードサービス

• 境界：ユーザー ↔ アップロードハンドラー ↔ ウイルススキャナー ↔ オブジェクトストレージ
• 重大な脅威：マルウェアのアップロード（改ざん）、パストラバーサル（情報漏えい）、ファイルの上書き（改ざん）、ストレージの枯渇（DoS）
• 主な緩和策：ファイル形式の検証（拡張子ではなくマジックバイトを確認）、サイズ制限、ウイルススキャン、一意なファイル名、ストレージドメインの分離

パターン 5：バックエンド API を備えたモバイルアプリ

• 境界：モバイルアプリ ↔ API ゲートウェイ ↔ バックエンドサービス
• 重大な脅威：API キーの抽出（情報漏えい）、証明書ピンニングの回避（改ざん）、ローカルデータの窃取（情報漏えい）、リバースエンジニアリング
• 主な緩和策：証明書ピンニング、ProGuard/R8 による難読化、生体認証、ローカル暗号化（Keychain/Keystore）、root 化／脱獄の検出

ガードレール

侵害を前提とする考え方：

• 「攻撃者は侵入できるか？」ではなく、「攻撃者が侵入したとき、どのような被害が発生するか？」を考えます。
• 多層防御：複数の対策を重ね、単一障害点をなくします。
• 最小権限：デフォルトでは最小限の権限のみを付与し、明示的な許可だけを認めます。

現実的に優先順位を付けます：

• まず価値の高い資産（顧客データ、認証情報、財務データ）に注力します。
• あれば望ましい程度の項目よりも、コンプライアンス上重大な脅威（PCI、HIPAA）に先に対処します。
• セキュリティ対策のコストとリスクのバランスを取ります（低リスクのシステムを過剰に設計しないでください）。

セキュリティ劇場を避けます：

• セキュリティ劇場：安全だと感じさせるものの、リスクを実質的に低減しない対策です（例：レート制限を設けずにパスワードを複雑化しても、クレデンシャルスタッフィングには依然として脆弱です）。
• 効果的なセキュリティ：実際の脅威経路に対処し、測定可能なリスク低減を実現します。

前提を文書化します：

• 「データベースはパブリックアクセス不可と想定」（ネットワーク設定で検証します）
• 「TLS 1.2 以降が強制されると想定」（ロードバランサーの設定で確認します）
• 「環境変数は保護されていると想定」（シークレット管理を確認します）

脅威モデルを更新します：

• 脅威モデルは時間とともに劣化します（新機能、新たな攻撃手法、インフラストラクチャの変更）。
• 四半期ごと、またはアーキテクチャに大きな変更があった際に見直します。
• インシデントやセキュリティ調査から得られた教訓を取り入れます。

クイックリファレンス

リソース：

• クイック脅威モデル：resources/template.md
• 高度な手法：resources/methodology.md（攻撃ツリー、DREAD スコアリング、悪用ケース）
• 品質評価基準：resources/evaluators/rubric_security_threat_model.json

5 段階のプロセス：アーキテクチャの把握 → 境界の特定 → データの分類 → STRIDE の適用 → 緩和と監視

STRIDE：なりすまし、改ざん、否認、情報漏えい、サービス拒否、権限昇格

信頼境界：ユーザー→アプリ、アプリ→DB、内部→外部、パブリック→プライベート、クライアント→サーバー、特権あり→特権なし

緩和策の種類：予防的（攻撃を阻止）、検知的（攻撃を特定）、是正的（攻撃に対応）

優先順位付け：価値の高い資産を最優先し、コンプライアンス上重大な脅威に対処して、リスクとコストのバランスを現実的に取ります