CloudNative Kaigi 2026 セキュリティ対策、何からはじめる？ー CloudNative環境の脅威モデリングと リスク評価実践入門 Subaru Nakamura | varu3 Lead Engineer (SRE) 1 

AUDER Inc, Lead Engineer (SRE) 中村 昴 / varu3 経 歴 • ソーシャルゲームや Web サービスのインフラエンジニア・ SRE を 10 年ほど経験 • フリーランスエンジニアとしてSRE / インフラ / 社内 IT 領域 を中心に複数社・プロダクトを支援 • 2026 年 4 月からAUDER 株式会社の Lead Engineerとして入社 • 社内のセキュリティチームや SRE チームの立ち上げを担 当 • CloudNative Days 2023 以来の登壇で、緊張しています！ • 自称「非機能要件なんでもやる」マン 自己紹介 2 

No content

倉 庫 を 取 り 巻 く 紙 帳 票 と 検 品 を 限 り な く ゼ ロ に す る P F 構 築 を 目 指 す 

YOUTUBE チャンネル「TECH WORLD」にて動画公開中 5 https://www.youtube.com/watch?v=wXN04AdHv5E 

YOUTUBE チャンネル「TECH WORLD」にて動画公開中 6 https://www.youtube.com/watch?v=wXN04AdHv5E チャンネル登録・高評価よろしくお願いします！ 

「ランサム攻撃による被害」が11年 連続のランクイン 新たに「AIの利用をめぐるサイバー リスク」が初選出 “「10大脅威」の順位は毎回変動するが、基本的な対策の重要性は変わらない” “脅威に備えるためには攻撃手口や動向、および自組織が 抱える要因等を把握することが重要" “「10大脅威」のランキングは、各組織において実施すべき 対策の優先度とは必ずしも一致はしない 組織ごとの状況を考慮して対策の優先度を決定する” 「情報セキュリティ10大脅威 2026」組織編 プレゼンスライド p4, p.91 https://www.ipa.go.jp/security/10threats/omgdg50000008fi8-att/presen_2026_soshiki_4_3_.pdf 情報セキュリティ10大脅威 2026 

「うちのサービスは、大丈夫なの？」 8 

「うちのサービスは、大丈夫なの？」 9 「脆弱性診断 をやっているから大丈夫です!」 「ISMS を取得しているから大丈夫です!」 「クラウドのベストプラクティスに沿っているから大丈夫です!」 「EDR や SASE を入れているから大丈夫です!」 

「うちのサービスは、大丈夫なの？」 10 「脆弱性診断 をやっているから大丈夫です!」 「ISMS を取得しているから大丈夫です!」 「クラウドのベストプラクティスに沿っているから大丈夫です!」 「EDR や SASE を入れているから大丈夫です!」 

「うちのサービスは、大丈夫なの？」 11 「脆弱性診断 をやっているから大丈夫です!」 「ISMS を取得しているから大丈夫です!」 「クラウドのベストプラクティスに沿っているから大丈夫です!」 「EDR や SASE を入れているから大丈夫です!」 

12 基本用語の整理 

機密性 Confidentiality ・アクセス権が保たれている こと ・第三者に情報が漏洩されて いない性質 完全性 Integrity ・情報の改ざんや破壊が行わ れないこと ・情報が完全かつ正確な情報 である性質 可用性 Availability ・情報が必要な時に利用がで きること ・サービス稼働の継続 を示 す性質 セキュリティ対策 = CIAのどれかを脅かすものを減らすこと 用語の整理: セキュリティの三要素(CIAトライアド) 13 

脅威 脆弱性 資産 リスク セキュリティ施策に より守るべき対象 リスク = 脅威 × 脆弱性 × 資産 システムやプロセス における弱点・欠陥 システムやプロセス に害を及ぼしうる 事象・要因 リスクは脆弱性が脅威に晒されて初めて顕在化する 逆に言えば脆弱性があるからといって、必ずしもリスクになるとは限らない 用語の整理: リスク・脅威・脆弱性・資産 

脅威 脆弱性 資産 ・ガイドラインに準拠するための人・物・金・時間などのリソースや脆弱性の管理コストが膨大 ・ガイドラインの「項目」や「指摘事項」をクリアすることで、どんな脅威を防ぐことができるの か？という観点が抜けがち（その組織にとってやらなくていい対応に時間をかけることも…） ・セキュリティ担当者以外のメンバーが、脅威をどのような施策で防御しているのかがわかりにくい 脆弱性に焦点を当てて、ベースラインとなる ガイドラインを利用して課題を洗い出し、リスクを把握し、対策するアプローチ リスク管理手法: ベースライン（コンプライアンス）型アプローチ 

脅威 脆弱性 資産 ・ビジネスや既存のシステムの「特定の脅威」に対して対策を考えることができる ・限られたリソースの中で優先順位をつけて対応できるので、スタートアップやスモールチームでも 実施しやすい ・「どこで対策するのか」をシナリオで語れるので、経営層への説明しやすい 脅威に焦点を当てて、 攻撃者目線の攻撃シナリオをもとに保護すべき資産に優先度をつけて対処するアプローチ リスク管理手法: 脅威ベースアプローチ 

“「10大脅威」の順位は毎回変動するが、基本的な対策の重要性は変わらない” “脅威に備えるためには攻撃手口や動向、および自組織が 抱える要因等を把握することが重要" “「10大脅威」のランキングは、各組織において実施すべき 対策の優先度とは必ずしも一致はしない 組織ごとの状況を考慮して対策の優先度を決定する” 「情報セキュリティ10大脅威 2026」組織編 プレゼンスライド p.91 https://www.ipa.go.jp/security/10threats/omgdg50000008fi8-att/presen_2026_soshiki_4_3_.pdf ベースライン型アプローチは不要？ 

“「10大脅威」の順位は毎回変動するが、基本的な対策の重要性は変わらない” “脅威に備えるためには攻撃手口や動向、および自組織が 抱える要因等を把握することが重要" “「10大脅威」のランキングは、各組織において実施すべき 対策の優先度とは必ずしも一致はしない 組織ごとの状況を考慮して対策の優先度を決定する” 「情報セキュリティ10大脅威 2026」組織編 プレゼンスライド p.91 https://www.ipa.go.jp/security/10threats/omgdg50000008fi8-att/presen_2026_soshiki_4_3_.pdf ベースライン ベースライン型アプローチは不要？ 

“「10大脅威」の順位は毎回変動するが、基本的な対策の重要性は変わらない” “脅威に備えるためには攻撃手口や動向、および自組織が 抱える要因等を把握することが重要" “「10大脅威」のランキングは、各組織において実施すべき 対策の優先度とは必ずしも一致はしない 組織ごとの状況を考慮して対策の優先度を決定する” 「情報セキュリティ10大脅威 2026」組織編 プレゼンスライド p.91 https://www.ipa.go.jp/security/10threats/omgdg50000008fi8-att/presen_2026_soshiki_4_3_.pdf ベースライン 脅威ベース型 脅威ベース型 ベースライン型アプローチは不要？ 

“「10大脅威」の順位は毎回変動するが、基本的な対策の重要性は変わらない” “脅威に備えるためには攻撃手口や動向、および自組織が 抱える要因等を把握することが重要" “「10大脅威」のランキングは、各組織において実施すべき 対策の優先度とは必ずしも一致はしない 組織ごとの状況を考慮して対策の優先度を決定する” 「情報セキュリティ10大脅威 2026」組織編 プレゼンスライド p.91 https://www.ipa.go.jp/security/10threats/omgdg50000008fi8-att/presen_2026_soshiki_4_3_.pdf ベースライン 脅威ベース型 脅威ベース型 要はバランス！ ベースライン型アプローチは不要？ 

Threat Modeling Manifest より “Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics.” 脅威モデリングとは、システムの構成を分析し、セキュリティやプライバシーに関する懸念事項を明らか にすること “Who should threat model? You. Everyone. Anyone who is concerned about the privacy, safety, and security of their system.” 誰が脅威モデリングをすべきですか？ あなた。すべての人。自分のシステムのプライバシー、安全性、セキュリティに関心のある人なら誰でも 脅威モデリングとは何か 21 https://www.threatmodelingmanifesto.org/ 

脅威モデリングとは何か 22 1 What are we working on? 我々は何を作っているのか? 参加者の決定 システムの可視化 (DFD) 2 What can go wrong? 何がうまくいかないか? 脅威の特定 3 What are we going to do about it? 我々はそれに対して何をするか? リスク分析・対策 4 Did we do a good enough job? 十分な仕事ができたか？ 検証・振り返り 脅威モデリングの４つの質問（Shostack's Four Question） 

1 DFD、システム構成図を描き、関係者を幅広く集める 何を作っているのか? 2 ブレインストーミングやSTRIDE分析で脅威を洗い出す 何がうまくいかないか? 3 洗い出した脅威をMITRE ATT&CK などを参考に具体的な手法に落とし込む 脅威を具体化する 4 リスク評価で優先順位を決める それに対して何をするか? 5 設計に反映し、振り返る 十分にできたか? 23 ４つの質問から具体的にステップに落とし込む これらを繰り返す！ 

24 脅威モデリングを実践してみよう！ 

架空ECサイト: クラウドマート 25 業態 食品・日用品の中規模 EC 規模 MAU 50万 / ピーク 5,000 req/sec インフラ AWS EKS (Tokyo) / Istio / ArgoCD / RDS / ElastiCache 外部連携 決済 (Stripe) / 配送API / OIDC 認証 取扱データ 個人情報、決済情報 (トークン化済)、注文履歴、在庫 規制・契約 個人情報保護法 チーム 開発・SRE・CS、計 30名程度 

クラウドマートの構成図: Data Plane 26 主要コンポーネント • Frontend Pod: Next.js (SSR) • Order Pod: 注文処理、在庫引当 • Payment Pod: 決済処理、Stripe連携 (IRSA) • Inventory Pod: 在庫管理、RDS書き込み • Catalog Pod: 商品一覧、RDS読み込み • Search Pod: 商品検索、OpenSearch読み込み • Auth: OIDC + Istio AuthN/AuthZ • Data: RDS / ElastiCache / OpenSearch / S3 

1 DFD、システム構成図を描き、関係者を幅広く集める 何を作っているのか? 2 ブレインストーミングやSTRIDE分析で脅威を洗い出す 何がうまくいかないか? 3 洗い出した脅威をMITRE ATT&CK などを参考に具体的な手法に落 とし込む 脅威を具体化する 4 リスク評価で優先順位を決める それに対して何をするか? 5 設計に反映し、振り返る 十分にできたか? 27 ４つの質問から具体的にステップに落とし込む 

「何を作っているのか」を絵にすることでシステムの全体像が見える コードを読めなくても参加できるので、エンジニア以外のメンバーも巻 き込める 信頼境界を引いて、視覚的にどこを守るべきかがわかる AIが書く設計書は長大で読まれにくい。図示ことで認知負荷を下げる 図を書くことの意義 28 

DFD の描き方 — 5つの要素 29 データストア 外部エンティ ティ プロセス データフロー 信頼境界 要素が少なく表現力も制限されるが、その分シンプルに図示することができる システムの概要を理解するコミュニケーションに非常に便利 

DFD - Context Diagram: 事業レベルのモデリング 30 外部エンティティに焦点を当て、システムを1つのプロセスとして描く 

DFD - Context Diagram: 事業レベルのモデリング 31 パスワードの漏洩 アカウントの乗っ取り 決済情報の漏洩 配送先情報（住 所など）の漏洩 誤操作で存在し ない商品を登録 大量アクセスによ るサービスダウン 外部エンティティに焦点を当て、システムを1つのプロセスとして描く 

DFD – Level ０ 32 ■ データの流れに着目して、Context Diagramから分解・詳細化する ■ どんな情報を入力し、手続きの結果、ど んな情報が出力されるのかを考えながら 少しづつ繋ぎ合わせる 入力（→）プロセス（→）出力 

DFD – Level １ 33 ■ Level ０で得たデータの流れから、さらにブ レイクダウン ■ ここではAWSリソースを詳細化 ■ 外部との信頼境界線を引く ■ データがどこからどこに流れていくのか、を 明示的に表現する どのフローが境界を跨ぐかが可視化され脅 威の入り口が見えてくる 

DFD – Level １ 34 ■ Level ０で得たデータの流れから、さらにブ レイクダウン ■ ここではAWSリソースを詳細化 ■ 外部との信頼境界線を引く ■ データがどこからどこに流れていくのか、を 明示的に表現する どのフローが境界を跨ぐかが可視化され脅 威の入り口が見えてくる インターネット 境界 EKS Cluster境 界 AWS Managed Service 境界 外部SaaS境界 外部SaaS境界 

1 DFD、システム構成図を描き、関係者を幅広く集める 何を作っているのか? 2 STRIDE-LM分析で脅威を洗い出す 何がうまくいかないか? 3 洗い出した脅威をMITRE ATT&CK などを参考に具体的な手法に落とし込む 脅威を具体化する 4 リスク評価で優先順位を決める それに対して何をするか? 5 設計に反映し、振り返る 十分にできたか? 35 ４つの質問から具体的にステップに落とし込む 

STRIDE-LM — 7つの脅威カテゴリ 36 カテゴリ名 守るべき要素 意味 S Spoofing (なりすまし) 認証 他のユーザーやシステムコンポーネントに成り すましてシステムへのアクセスを取得する行為 T Tampering (改ざん) 完全性 システムやデータを意図しない形で変更し、正当な 利用者にとって有用性を低下させること R Repudiation (否認) 非否認性 特定のユーザーまたはプロセスによって実行された 行為の正当性を否定できる可能性 I Information Disclosure (情報漏洩) 機密性 権限のない第三者への情報開示 D Denial of Service (サービス不能） 可用性 システムを正当な利用者が 利用できない状態にする攻撃 E Elevation of Privilege （権限昇格） 最小権限の原則 権限のないユーザーやプロセスに対して システムへのアクセスを許可すること LM Lateral Movement （水平移動） 封じ込め 初期侵入ポイントを超えて標的ネットワーク上で制 御範囲を拡大する行為 

STRIDE-LM per Interaction 37 インターネット 境界 EKS Cluster境 界 AWS Managed Service 境界 外部SaaS境界 外部SaaS境界 … 

DFDの 要素タイプごと に適用すべきカテゴリが決まっている 要素 S T R I D E LM プロセス ✓ ✓ ✓ ✓ ✓ ✓ ✓ データストア ✓ ✓ (?) ✓ ✓ データフロー ✓ ✓ ✓ ✓ 外部エンティティ ✓ ✓ STRIDE-LM per Element 38 ■ DFD を描いたら このマトリクスに当てはめるだけで網羅的に脅威を出すことができる ■ 抜け漏れを防ぐチェックシート的な使い方 

MITRE ATT&CK 39 ■ 攻撃グループがよく利用する 戦術(Tactics)・技術(Techniques)・手順 (Procedures)のナレッジベース ■ 実際に観測された攻撃者の行動パターン をもとに、その手法や対策方法をまとめ たもの ■ Container Matrix や IaaS Matrix など それぞれの領域に特化したマトリクスを 活用する ■ どのような脅威がありどのように攻撃を 成立させるのか、を確認する https://attack.mitre.org/matrices/enterprise/containers/ 

1 DFD、システム構成図を描き、関係者を幅広く集める 何を作っているのか? 2 STRIDE-LM分析で脅威を洗い出す 何がうまくいかないか? 3 洗い出した脅威をMITRE ATT&CK などを参考に具体的な手法に落とし込む 脅威を具体化する 4 リスク評価で優先順位を決める それに対して何をするか? 5 設計に反映し、振り返る 十分にできたか? 40 ４つの質問から具体的にステップに落とし込む 

脅威 脆弱性 資産 リスク セキュリティ施策に より守るべき対象 リスク = 脅威 × 脆弱性 × 資産 システムやプロセス における弱点・欠陥 システムやプロセス に害を及ぼしうる事 象・要因 復習: リスク・脅威・脆弱性・資産 

脅威 脆弱性 資産 リスク 漏洩・停止時の ビジネスインパクト 1 (低) - 3 (高) リスク = 脅威 × 脆弱性 × 資産 現状の対策の 有無・弱点 1 (低) - 3 (高) 攻撃者の 動機・能力・機会 1 (低) - 3 (高) 3段階 × 3軸 = 最大27点。 スコアが高い脅威から対策する 完璧じゃなくても、チーム内で 相対的な優先順位 が合意できればよい 復習: リスク・脅威・脆弱性・資産 

脅威モデリングアウトプット例: #2 カート改ざん 項目 内容 No. 2 経路 Frontend Pod → ElastiCache (Redis) データ カート情報（商品ID・数量・単価） 攻撃経路・目標 Redisに直接書き込み、カート単価を改ざんして低額で決済成立させる 対象資産 カートデータ / 売上 前提脆弱性 サーバ側で価格再計算なし / Redis AUTH未設定 / NetworkPolicy未設定 など 脅威の例 SSRF経由でVPC内Redisへ直接接続し、SETコマンドでカート単価を改ざん 脅威種別 (STRIDE) Tampering 重要度 2 発生頻度 2 脆弱性 3 リスク値 2 * 2 * 3 = 12 対策 サーバ側で価格を再計算 / Redis Auth Token + IAM認証 / NetworkPolicyで通信制限 対策後脆弱性 1 対策後リスク 2 * 2 * 1 = 4 

脅威モデリングアウトプット例 44 ■ 対策前後でリスク値が減少していること が一目でわかるように一覧化して管理し ておくと便利 

1 Step 1. DFDを描いてみる • 対象サービスを1つ選び、外部エンティティとデータフローだけでもいいのでまずは小さくはじ めてみよう！ • エンジニアチームだけでなく他チームも巻き込んで一緒に描いてみる 2 Step 2. 信頼境界を引いて STRIDE を1周する • 信頼境界を跨ぐフローを3つ選び、STRIDE 表を埋める • 脅威を洗い出すのが難しい場合は、LLM を壁打ち相手にブレストすると精度が高まる 3 Step 3. リスク値で並べて、上位を対策する • 三軸スコアリングで優先順位を付ける • 対策を設計して実装する、まずは１サイクル回してみてブラッシュアップさせていこう 明日から始める 3 ステップ 45 

46 ■ 「脅威インテリジェンスの教科書」, 石川 朝久, 技術評論社 ■ 「データフローダイアグラム いにしえの技術がもたらすシステム設計の可能性」 大嶋 和幸 , 松永 守峰, 翔泳社 ■ 制御システムのセキュリティリスク分析ガイド 第2版, IPA, https://www.ipa.go.jp/security/controlsystem/riskanalysis.html ■ 情報セキュリティ10大脅威 2026, IPA, https://www.ipa.go.jp/security/10threats/10threats2026.html ■ リスク分析シート, IPA, https://www.ipa.go.jp/security/sme/f55m8k000000587z- att/outline_guidance_risk.pdf ■ THREAD MODELING MANIFEST, https://www.threatmodelingmanifesto.org/ ■ STRIDE-LM Threat Modeling, https://csf.tools/reference/stride-lm 参考文献 

47 ■ 「セキュアなソフトウェアの設計と開発」,ローレン・コンフェルダー (著), 秋 勇紀 (翻訳), 高 田 新山 (翻訳), 小出 洋 (監修), 秀和システム 参考文献 Microsoftで脅威モデリングを開発した ローレン・コンフェルダー氏の “Designing Secure Software” の日本語版 2023年8月と最近発刊されたものの、出版社の都合によ り絶版となってしまっている…（電子書籍版も） 機会があれば、ぜひ復刊してほしい…！！（切に） 

48 ご清聴ありがとうございました