SEC-006

脅威モデル

分類:SECURITY実物サンプルあり

これは何か

脅威モデルは、守るべきもの(資産)、それに近づける入口、狙ってくる相手とそのやり方(脅威)、それぞれに対する対策と、まだ対策していない残りを、一覧と図で整理した成果物です。

「安全に作る」と言うだけでは、何から守るのかが決まりません。脅威モデルは、攻撃する側の目で自分のシステムを見直し、「ここから、こうやって入られる」を先に書き出す作業です(08-01 ログインできれば安全なのか)。書き出してから、対策の優先順位を決めます。

なぜ作るか

誰が使うか・いつ作るか

CASE FACTFROZEN正本に記載されたアステリア案件の事実

守るべきものと入口に関係する記載

  • データ正本:顧客・契約は営業管理システム、社員・組織は人事マスター、工数は勤怠・工数管理SaaS、案件・案件予算・案件原価・請求は新基幹、正式な会計残高・仕訳は FIN-CORE、経営分析は BI
  • システムに SYS-08 認証・ID基盤、SYS-11 監視・ログ基盤、SYS-10 AI開発エージェント がある
  • 外部とつながるものとして SYS-03 勤怠・工数管理SaaS(Vendor D タイムリンク)がある
  • Vendor B クラウドブリッジの担当範囲に IAM(権限と認証の管理)が含まれる
  • P-012 石井 稔 — セキュリティ責任者、P-013 木村 亮 — AIガバナンス責任者
  • セキュリティ例外承認は、AIへ最終委任しない事項

どの資産がどれだけ重いか、どんな脅威が想定され、どんな対策が取られたかは、正本に記載がありません。未確定

主な項目

一般的には、次の項目で構成します。

  1. 資産の一覧と重さ:守るべきデータと機能。漏れたとき・壊れたとき・止まったときの影響の大きさ
  2. 構成と信頼の境目:システム、連携、外部サービス、利用者の種類を図にし、「ここから先は信頼しない」境目を引く
  3. 入口の一覧:境目をまたぐ経路(画面、API、ファイルの受け渡し、運用の操作、開発の道具、AI の実行環境)
  4. 脅威の一覧:入口ごとに、誰が(外部、内部、委託先、自動化された相手)、何を狙って、どうやって。種類の見落としを防ぐため、なりすまし・改ざん・否認・漏えい・妨害・権限の昇格 のような分類で点検する
  5. 対策と残り:脅威ごとに、取っている対策、対策の根拠(どの要件・どの設計か)、残っている危険とその受け入れの判断
  6. 優先順位:資産の重さ × 起こりやすさ で並べ、先に対策するもの
  7. 見直しの条件:構成の変更、新しい入口、公表された弱点、事故

教材用サンプル成果物の読み方を学ぶための例

教材用サンプル — 入口ごとの脅威と対策の表

この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。

次の表は、モデルの書き方を学ぶための例です。脅威・対策・残りはすべて教材上の架空の例で、アステリア案件の記録ではありません。

入口(教材上の例) 脅威 狙われる資産 対策 残っている危険 受け入れの判断
利用者の画面 盗まれた認証情報でのなりすまし 顧客・契約の情報 多要素の認証、異常な場所からのログインの検知 本人の端末が乗っ取られた場合 端末の管理の方針で扱う(別の対策)
外部サービスとの連携 連携の経路での改ざん 工数データ 通信の暗号化、受け取り側での項目の検査 外部サービス側の内部の不正 契約と監査報告で確認(受け入れ)
運用者の本番操作 権限の乱用、操作の否認 すべての業務データ 特権の申請制、操作の記録、2 人での確認 2 人が共謀する場合 記録の定期点検で検知(受け入れ)
開発の道具と AI の実行環境 外部から取り込んだ文書に含まれる指示に AI が従う プログラムと設定 AI の権限を最小にし、本番への変更は人が承認 承認する人が内容を読まない場合 レビューの決まりで扱う(別の対策)
脅威(教材上の例) 資産の重さ(1〜5) 起こりやすさ(1〜5) 積 順位
盗まれた認証情報でのなりすまし 5 4 20 1
運用者の権限の乱用 5 2 10 2
外部文書の指示に AI が従う 4 2 8 3
連携の経路での改ざん 3 2 6 4

読み方

  1. 資産に重さが付いているか(全部「重要」になっていないか)
  2. 入口の一覧に、画面と API だけでなく、運用の操作・開発の道具・AI の実行環境が入っているか
  3. 脅威ごとに「対策」と「残っている危険」の両方が書かれ、残りに受け入れの判断があるか
  4. 対策の根拠が、要件や設計の文書につながっているか
  5. 見直しの条件が書かれ、最後の見直しの日付が新しいか

書き方

  1. 資産を一覧にし、業務部門と重さを決める
  2. 構成図(ARC-001 システム全体構成図)に信頼の境目を引き、入口を列挙する
  3. 入口ごとに脅威を挙げる。分類を使って見落としを点検する
  4. 対策を設計と突き合わせ、残っている危険を書く。受け入れるものは、受け入れる人と理由を残す
  5. 優先順位を付け、対策の計画と評価の計画に渡す

何を書いてはいけないか

どこを見るか

  1. 資産の重さ
  2. 入口の網羅(運用・開発・AI を含むか)
  3. 対策と残っている危険、受け入れの判断
  4. 対策の根拠(要件・設計への参照)
  5. 見直しの条件と日付

赤信号

  • 脅威モデルが評価や監査の直前に初めて作られ、設計に反映されていない
  • 入口の一覧に AI の実行環境や開発の道具がなく、プログラムを変えられる経路が見えていない
  • 残っている危険が書かれておらず、「対策済み」だけが並ぶ
  • 構成が変わっても更新されず、新しい連携や外部サービスがモデルにない

よくある失敗

関係するUnit・成果物・危機演習

AI WORKFLOW

AIは、入口の一覧から、分類(なりすまし・改ざん・否認・漏えい・妨害・権限の昇格)ごとに脅威の候補を挙げ、モデルの抜けを探す下書きに役立ちます。

「次の入口の一覧について、入口ごとに 6 つの分類それぞれで起こりうる脅威の候補を挙げ、添付の脅威モデルにすでにある脅威と、ない脅威を分けて示してください。対策の提案や、危険の大きさの評価はしないでください。攻撃の具体的な手順は書かないでください。」

REVIEW

  • AIが挙げた候補が、この構成で本当に起こりうるか(一般論の候補をそのまま載せていないか)
  • 「ない脅威」とされたものについて、意図して外したのか、見落としかを人が区別したか
  • 構成の情報を AI に渡してよいか(守るための文書そのものが機密であること)を事前に確かめたか

人間が判断すること

  • 資産の重さ
  • 残っている危険を受け入れるか、追加で対策するか
  • 対策の優先順位と、設計への反映の時期

セキュリティ例外承認は、AIへ最終委任しない事項です(正本の方針)。

いつ使うか

この教材では STAGE 08|誰に何を許可するのか の文脈で扱います。 アステリア案件での正式な作成・使用時期(月)は正本に記載がないため、未確定としています。

最後の問い

このモデルを読んだ設計者は、「守るべきものは何で、どこから、誰が、どうやって狙ってくるか。それに対して何をしていて、何をしていないか」を、推測ではなく一覧で説明できますか?

学習上の接続

教材上の学習接続です。成果物とUnitの正式な対応表はbaselineにないため、正式な関連付けとしては登録していません。

  • Stage:未確定(baselineに対応表なし)
  • 危機演習:未確定(baselineに対応表なし)
  • 人物:未確定(baselineに対応表なし)