security-threat-model について
security-threat-modelは、サービスや機能のSTRIDEベースの脅威モデルを作成するスキルです。セキュリティリスクと判断を記録するエンジニアリングチーム向けに、資産、信頼境界、脅威、リスク評価、緩和策を構造化してまとめます。
主な機能
- 01アーキテクチャ、データ、制御情報の収集
- 02STRIDEによる脅威の分類
- 03資産と信頼境界の登録
- 04脅威リスクの評価
- 05緩和策と担当者の定義
- 06受容リスクとレビュー周期の記録
活用シーン
- 01新しいサービスや機能のセキュリティ評価
- 02アーキテクチャ変更に伴う脅威の記録
- 03緩和計画と担当者の整理
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/security-threat-modelを入力して読み込まれたか確認します。
詳細
セキュリティ脅威モデルスキル
サービスまたは機能について、STRIDE に基づく完全な脅威モデルを作成します。脅威モデルは、起こり得る問題を列挙しただけのものではありません。攻撃者、資産、境界、対策を構造的に分析し、エンジニアリングチームが十分な情報に基づいて、文書化されたセキュリティ上の判断を下せるようにするものです。
優れた脅威モデルは、新しいエンジニアが何を保護しているのか、各対策がなぜ存在するのか、チームがどのようなリスクを受け入れたのかを理解できるだけの具体性を備えています。
必須の入力情報
以下の情報がまだ提供されていない場合は、質問してください。
- サービス名と説明 — サービスの機能と利用者
- アーキテクチャの概要 — コンポーネント、依存関係、データフロー（図の説明や ASCII 図でもかまいません）
- デプロイ環境 — クラウドプロバイダー、VPC／ネットワークのトポロジー、実行環境（Kubernetes、ECS、VM、サーバーレス）
- データの機密性 — このサービスが扱うデータの種類（PII、決済データ、認証情報、社内限定データなど）
- 既存の対策 — 認証方式、転送中／保存時の暗号化、現在の WAF／ファイアウォール、既存のセキュリティスキャン
- 信頼レベル — プリンシパルは誰か（匿名の一般ユーザー、認証済みユーザー、内部サービス、管理者など）
出力形式
セキュリティ脅威モデル：[サービス名]
サービス： [名前] | チーム： [チーム名] 作成者： [名前] | レビュー担当者： [セキュリティ責任者／同僚] 日付： [日付] | 次回レビュー： [日付 — 6 か月後、または大規模なアーキテクチャ変更後を推奨] 分類： [社内／機密]
1. 概要
[サービスとシステム内での役割、およびこの脅威モデルの対象範囲を説明する 2～3 文を記述します。対象範囲に含まれるものと、明示的に対象外とするものを記載します。]
対象範囲：
- [コンポーネントまたはデータフロー]
- [コンポーネントまたはデータフロー]
対象外：
- [例：サードパーティ決済プロセッサーの内部]
- [例：社内ネットワーク／エンドユーザーデバイス]
2. 資産一覧
資産とは、データ、機能、評判など、保護する価値のあるものです。
| 資産 | 説明 | 機密性 | 所有者 |
|---|---|---|---|
| [例：ユーザーの PII] | 氏名、メールアドレス、プロフィールデータ | 高 — GDPR の規制対象 | [チーム] |
| [例：API 認証情報] | サービス間認証トークン | 重大 | [チーム] |
| [例：セッショントークン] | ユーザー認証状態 | 高 | [チーム] |
| [例：監査ログ] | ユーザーおよび管理者の操作記録 | 中 | [チーム] |
| [例：サービスの可用性] | [X] エンドポイントの稼働時間 | 中 | [チーム] |
データ分類の基準：
- 重大 — 認証情報。漏えいすると、システムが直接侵害される可能性があります
- 高 — PII、財務データ、健康データ。規制対象、または評判への影響が大きいデータです
- 中 — 内部設定、機密性のない業務データ
- 低 — 公開情報、匿名化されたデータ
3. 信頼境界とアーキテクチャ
信頼境界とは、信頼レベルの異なるゾーンを分ける境界線です。データやリクエストが境界を越える際に、脅威が発生することがよくあります。
┌─────────────────────────────────────────────────────────────────┐
│ INTERNET (Untrusted) │
│ │
│ [Public User] [Bot / Attacker] │
└──────────────────────────────┬──────────────────────────────────┘
│ HTTPS
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
Trust Boundary: Public → DMZ
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
▼
┌──────────────────────────────────────────────────────────────────┐
│ DMZ / Edge Layer │
│ ┌────────────┐ ┌──────────────┐ │
│ │ WAF / CDN │────▶│ API Gateway │ │
│ └────────────┘ └──────┬───────┘ │
└──────────────────────────────┼───────────────────────────────────┘
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
Trust Boundary: Edge → Application VPC
─ ─ ─ ─ ─ ─ ─│─ ─ ─ ─ ─ ─ ─ ─
▼
┌──────────────────────────────────────────────────────────────────┐
│ Application VPC (Private) │
│ ┌──────────────┐ ┌────────────┐ ┌──────────────────┐ │
│ │ [Service A] │────▶│ [Service B]│────▶│ [Database] │ │
│ └──────────────┘ └────────────┘ └──────────────────┘ │
│ ▲ │
│ │ │
│ ┌──────────────┐ │ │
│ │ Admin (IAM) │─────────────┘ │
└──────────────────────────────────────────────────────────────────┘
特定された信頼境界：
| 境界 | 接続元 | 接続先 | 認証方式 | 暗号化 |
|---|---|---|---|---|
| TB-1 | パブリックインターネット | API Gateway | [JWT／OAuth／API key] | TLS 1.2+ |
| TB-2 | API Gateway | Service A | [mTLS／内部 JWT／IAM role] | [はい／いいえ] |
| TB-3 | Service A | データベース | [接続文字列 + IAM／ユーザー名 + パスワード] | [はい／いいえ] |
| TB-4 | 管理者 | Service B | [IAM role／VPN + MFA] | TLS |
4. STRIDE による脅威分析
STRIDE は脅威を分類するフレームワークです。重要なコンポーネントごとに、各カテゴリの脅威を列挙します。
STRIDE の分類：
- S — なりすまし：別のユーザー、サービス、またはシステムになりすますこと
- T — 改ざん：許可なくデータやコードを変更すること
- R — 否認：操作の実行を否認すること。監査証跡が不十分であること
- I — 情報漏えい：許可されていない相手にデータを公開すること
- D — サービス拒否：サービスを利用不能にすること
- E — 権限昇格：許可された範囲を超える機能を取得すること
コンポーネント：[API ゲートウェイ／認証レイヤー]
| ID | カテゴリ | 脅威 | 攻撃ベクトル | 既存の対策 |
|---|---|---|---|---|
| T-001 | S | 攻撃者が JWT トークンを偽造し、別のユーザーとして認証する | 署名キーが弱い、またはアルゴリズムの混同（alg:none） | [例：キーをローテーションする RS256／none] |
| T-002 | S | 攻撃者が盗んだセッショントークンを再利用する | XSS またはネットワークの盗聴による窃取 | [例：トークンの有効期限＋リフレッシュトークンのローテーション] |
| T-003 | T | 攻撃者がリクエストヘッダーを変更し、テナント分離を回避する | テナント ID ヘッダーの検証不足 | [例：サーバー側でのテナント解決／なし] |
| T-004 | R | 管理者の認証イベントの監査証跡がない | 認証失敗のログが設定されていない | [例：CloudTrail を有効化／なし] |
| T-005 | I | 認証エラーメッセージからメールアドレスの登録有無が判明する | 詳細すぎるエラーレスポンス | [例：正規化されたエラーレスポンス／なし] |
| T-006 | D | クレデンシャルスタッフィングによりレート制限が使い果たされ、正規ユーザーがブロックされる | 自動化されたログイン試行 | [例：IP ごとのレート制限＋CAPTCHA／なし] |
| T-007 | E | 侵害された低権限トークンで管理者用エンドポイントが呼び出される | 管理者用ルートでのロールチェック不足 | [例：すべてのルートに RBAC ミドルウェアを適用／なし] |
コンポーネント：[アプリケーションサービス／ビジネスロジック]
| ID | カテゴリ | 脅威 | 攻撃ベクトル | 既存の対策 |
|---|---|---|---|---|
| T-008 | T | サニタイズされていないユーザー入力による SQL／NoSQL インジェクション | パラメーター化されていないクエリ | [例：パラメーター化クエリを使用する ORM／なし] |
| T-009 | T | マスアサインメント — 攻撃者が、本来設定できないフィールド（例：isAdmin: true）を設定する | API が許可リストなしで余分なフィールドを受け入れる | [例：入力検証／なし] |
| T-010 | I | 安全でない直接オブジェクト参照 — ユーザーが別のユーザーのリソースにアクセスする | リソース ID の所有者チェック不足 | [例：所有権ミドルウェア／なし] |
| T-011 | I | アプリケーションログに機密データ（PII、トークン）が含まれる | デバッグモードでの過剰なログ出力 | [例：ログの機密情報除去／なし] |
| T-012 | D | 保護されていない高コストなエンドポイントが大規模な DB スキャンを引き起こす | ページネーションまたはクエリコスト制限がない | [例：ページネーションを必須化／なし] |
| T-013 | R | ビジネス上重要な状態変更が記録されない | [operation] に対する監査イベントがない | [例：監査ログテーブル／なし] |
コンポーネント：[データベース]
| ID | カテゴリ | 脅威 | 攻撃ベクトル | 既存の対策 |
|---|---|---|---|---|
| T-014 | I | データベースがインターネットに公開される（セキュリティグループの設定ミス） | VPC 外部からの直接接続 | [例：パブリック IP なし、セキュリティグループでアプリのサブネットに制限] |
| T-015 | I | バックアップスナップショットが暗号化されていない、または不適切なアカウントからアクセスできる | 暗号化されていないスナップショット、パブリックな S3 | [例：暗号化されたスナップショット、プライベート S3 バケット] |
| T-016 | T | 過剰な権限を持つ DB アカウントによる権限昇格 | アプリがスーパーユーザーの DB アカウントを使用する | [例：サービスごとに最小権限の DB ロールを設定／なし] |
| T-017 | D | 暴走クエリまたは一括削除によりデータ損失や停止が発生する | クエリタイムアウトまたは論理削除がない | [例：ステートメントのタイムアウト、重要なテーブルで論理削除を適用／なし] |
コンポーネント：[内部サービス間通信]
| ID | カテゴリ | 脅威 | 攻撃ベクトル | 既存の対策 |
|---|---|---|---|---|
| T-018 | S | 不正な内部サービスが信頼されたサービスになりすます | サービス間の相互認証がない | [例：mTLS／サービスメッシュ／なし] |
| T-019 | I | 共有ネットワーク上で内部トラフィックが盗聴される | 暗号化されていないサービス間呼び出し | [例：TLS を使用するサービスメッシュ／なし] |
| T-020 | E | 侵害された内部サービスが特権エンドポイントを呼び出す | 内部トークンのスコープ制限がない | [例：スコープを限定したサービストークン／なし] |
5. リスク一覧
各脅威をスコア化します：可能性（1～5） × 影響度（1～5） ＝ リスクスコア（1～25）
優先度区分：クリティカル（20～25） | 高（12～19） | 中（6～11） | 低（1～5）
| ID | 脅威の概要 | 可能性 | 影響度 | スコア | 優先度 | ステータス |
|---|---|---|---|---|---|---|
| T-001 | JWT の偽造 — 認証の回避 | 2 | 5 | 10 | 中 | [未対応 / 軽減済み / 受容済み] |
| T-002 | セッショントークンのリプレイ | 3 | 4 | 12 | 高 | [未対応 / 軽減済み / 受容済み] |
| T-007 | ロールチェックの欠如による権限昇格 | 3 | 5 | 15 | 高 | [未対応 / 軽減済み / 受容済み] |
| T-008 | SQL インジェクション | 2 | 5 | 10 | 中 | [未対応 / 軽減済み / 受容済み] |
| T-010 | IDOR — 他のユーザーのデータへのアクセス | 3 | 4 | 12 | 高 | [未対応 / 軽減済み / 受容済み] |
| T-014 | データベースがインターネットに公開されている | 1 | 5 | 5 | 低 | [未対応 / 軽減済み / 受容済み] |
| T-018 | 不正な内部サービスによるなりすまし | 2 | 4 | 8 | 中 | [未対応 / 軽減済み / 受容済み] |
6. 軽減策一覧
優先度が中以上の未対応の脅威すべてについて、具体的な軽減策を定義します。
| ID | 脅威 | 軽減策 | 担当者 | 目標日 | チケット |
|---|---|---|---|---|---|
| T-002 | セッショントークンのリプレイ | リフレッシュ時にトークンをローテーションし、古いトークンをサーバー側で直ちに無効化する | [エンジニア名] | [日付] | [JIRA-123] |
| T-007 | 権限昇格 | すべての /admin/* ルートに RBAC ミドルウェアを追加し、ロール境界の統合テストを作成する | [エンジニア名] | [日付] | [JIRA-124] |
| T-010 | IDOR | リソースを取得するすべてのサービスメソッドに所有権の確認を追加し、コードレビューのチェックリストにも追加する | [エンジニア名] | [日付] | [JIRA-125] |
| T-011 | ログ内の PII | PII フィールドに関するログ出力呼び出しを監査し、ロガーミドルウェアにスクラビングを追加する | [エンジニア名] | [日付] | [JIRA-126] |
| T-018 | 不正なサービスによるなりすまし | サービスメッシュ経由で mTLS を有効にするか、サービスごとにスコープを限定したサービストークンを発行する | [エンジニア名] | [日付] | [JIRA-127] |
7. 受容済みリスク
受容済みリスクとは、チームが現時点では軽減しないと判断した脅威です。受容済みリスクにはすべて、担当者とレビュー日を明記する必要があります。
| ID | 脅威 | 受容理由 | リスク担当者 | レビュー日 |
|---|---|---|---|---|
| T-014 | データベースの一般公開 | データベースにはパブリック IP が割り当てられておらず、対策がすでに講じられている — 発生可能性が低いため受容 | [氏名] | [日付] |
| [ID] | [脅威] | [理由 — 例：「現時点の規模では、リスクに対して対策の労力が大きいため、トラフィックが10倍になった時点で再評価する」] | [氏名] | [日付] |
8. セキュリティ対策の概要
| 対策 | 種別 | 対象となる脅威 | 実装済み |
|---|---|---|---|
| 有効期限15分の JWT RS256 | 予防 | T-001, T-002 | [はい / 一部 / いいえ] |
| すべてのルートに RBAC ミドルウェアを適用 | 予防 | T-007, T-020 | [はい / 一部 / いいえ] |
| パラメーター化クエリ（ORM） | 予防 | T-008 | [はい / 一部 / いいえ] |
| レート制限（IPごとに100 req/min） | 予防 | T-006, T-012 | [はい / 一部 / いいえ] |
| CloudTrail / 監査ログ | 検知 | T-004, T-013 | [はい / 一部 / いいえ] |
| CI パイプラインでの自動 SAST | 検知 | T-008, T-009 | [はい / 一部 / いいえ] |
| 暗号化バックアップ + プライベート S3 | 予防 | T-015 | [はい / 一部 / いいえ] |
| 最小権限の DB ロール | 予防 | T-016 | [はい / 一部 / いいえ] |
| インシデント対応手順書 | 是正 | すべて | [はい / 一部 / いいえ] |
9. レビューの頻度
| トリガー | 対応 |
|---|---|
| 6か月ごと | 脅威モデル全体をレビューし、リスクスコアを更新して、軽減済みの項目をクローズする |
| アーキテクチャの大幅な変更 | 信頼境界図を更新し、新しいコンポーネントについて STRIDE を再実施する |
| セキュリティインシデント | 関連する脅威をレビューし、新たに発見された攻撃経路を追加する |
| 新しいデータ分類 | 資産を一覧に追加し、新たな STRIDE カテゴリが該当するかを評価する |
| サードパーティ依存関係の追加 | 新しい依存関係に関するサプライチェーンの脅威を評価する |
次回の予定レビュー： [日付] レビュー担当者： [氏名 / セキュリティリード]
品質チェック
- すべての信頼境界に名前が付けられ、認証メカニズムが明記されています。「TBD」のままにしないでください
- リスク登録簿に記載された「重大」および「高」のリスクすべてに、担当者名と目標日を明記した緩和策があります
- 受容したリスクすべてに、担当者名とレビュー日が明記されています。担当者のいない受容済みリスクがあってはいけません
- 資産登録簿にデータの機密性レベルが含まれ、認証情報に関する項目が少なくとも1件あります
- STRIDE 分析は API レイヤーだけでなく、主要なコンポーネントすべてを網羅しています
- 緩和策はチケットにできるほど具体的です（「セキュリティを改善する」ではありません）
- ASCII の信頼境界図が、提示されたアーキテクチャの説明と一致しています
アンチパターン
- STRIDE 分析を API レイヤーだけに限定しないでください。データベースや内部サービスを含め、あらゆるコンポーネントに脅威が存在します
- 「セキュリティを改善する」のような曖昧な指示を緩和策として残さないでください。すべての緩和策は、チケットにできるほど具体的である必要があります
- 担当者名とレビュー日を明記せずにリスクを受容しないでください。担当者のいない受容済みリスクは、管理されているリスクではありません
- 理論上の脅威だけを対象とした脅威モデルを作成しないでください。リスク登録簿を使って、発生可能性と影響に基づいて優先順位を付けてください
- 資産登録簿を省略しないでください。保護対象が分からなければ、STRIDE 分析の拠り所がありません
コメント
Markdown 対応