セキュリティは全員参加！_JAWSのイベントサイトで脅威モデリングを学んでみよう！

JAWS FESTA 2025
https://jawsfesta2025.jaws-ug.jp/sessions/timetable/71/

Transcript

1. セキュリティは全員参加！ JAWSのイベントサイトで脅威モデリングを学んでみよう！ Azara / Yonezawa
2. Azara @a_zara_n 自己紹介 Yonezawa @takuya_y0ne GMO Flatt Security所属のあざらし セキュリティの専門家 GMO IGでクラウドセキュリティ領域の エキスパートを拝命(らしいですよ) Japan Digital Design所属のSWE 早く/お安くシステムを作るのが得意 かれこれ3つほどJAWSイベントの WEBサイトを構築した Serverless Security
3. はじめに
4. 皆さん脅威モデリングってご存知ですか？ Builderな皆様が今後より良いシステムを構築していくためのヒントとして、 “現在も運用されているWEBシステム”をお題に生々しい知見をお届けします！ 本日の発表内容 2 3 1 システムの概略 JAWS Days 2024・2025のティザーサイトのシステム構成はどのようなものだったか？ 脅威モデリングの実践 実際に試してみた感想や発見についてお話しします！ 脅威モデリングとは セキュリティ文脈で話される「脅威モデリング」とはどのようなもので、どう始めるべきか？
5. 脅威モデリングとは？
6. 脅威モデリングとは、組織全体、特にクラウドワークロードごとに潜在的な脅威を特 定する手法です。機密性、完全性、可用性を損なう可能性のある脅威、その潜在的な 攻撃経路と手法を分析し、最終的に各脅威が成功した場合の潜在的な影響を定量化す ることができるものです。(一つの手法で組織にうまく溶け込ませると良いですよ) セキュリティやシステムの継続性といった システムをおびやかす存在を明らかにする手法 脅威モデリングとは？
7. ※1 脅威モデリングでの課題は、セキュリティ文脈で語られているが、完全性・可用性はSRE文脈でも活用可能です。またBCP/DPなどの文脈(自然的脅威など) も含めることができるので、場面に応じて「どこ」に注力するかをチーム内で定めておくと良いでしょう。(もちろん主軸はセキュリティではあるものの) 脅威モデリングを用いることで開発チームとセキュリティチーム間での「システムの 共通認識」を構築し、システムの持っている「価値」における「課題(※1) 」を明確に し、チームや組織としてどのように解決をしていくかの議論の土台にすることが可能 です。 脅威モデリングで得られるもの 理論を実践へ 多様な視点で 全員で 立ち向かう 共通の言葉で システムを 理解する 体系的な アプローチを用 い脅威を整理 情報に基づいた 創造性 脅威モデリングを用いて得られるメリット
8. 脅威モデリングが世界を救う！ みたいなことは言いません。 セキュリティの対策や施策は多層的に行うことが重要です。 なにかを一つにこだわるのではなく、適度に取り入れ 組織のセキュリティ成熟度に合わせて進めていきましょう。 注意点 脅威モデリングの具現化 僕は怖くないよ！
9. AWS公式も提唱するアプローチ / AWSブログの内容は説明を割愛 https://aws.amazon.com/jp/blogs/news/how-to-approach-threat-modeling/
10. 今日やることを試してみたい場合 - ビルダーのための脅威モデリング https://catalog.workshops.aws/threatmodel/ja-JP あとで読んでみてください！
11. (ざっくり)どのように脅威モデリングを進めるのか？ 共通の言語化 ツールの選定 情報の整理 Let’s modeling 2 3 1 4 今存在する設計ドキュメントや実装されたコード、構成図な どを確認し、どのようなシステムかを整理する。 合わせてそのシステムの仮定や背景などの理解もする。 そのシステムに関連する動作や構成などについて、共通言語 かをして、関わる人間の共通認識を加速させる。 STRIDE(後述)やDFDなどのツールを用いて情報の整理や脅威 がどこに存在するかを確認する。 先に選定したツールを用いて関係するチームみんなでモデリ ングをしてみよう！
12. 情報の整理をどう進めるか？ 1 パイセン！News機能を使う人はど んな属性の人です？ News機能は管理者機能はイベン ト運営が、そうじゃないものはイベ ント参加者が見るで！ コミュニケーション バイアスを取り去るためあえて 知らんふりをして聞くことも大事 設計資料や要件定義、チャットな どを読んで、機能やどのような用 途で使われるかを確認だ！ ドキュメントの確認 既存のドキュメントや必要な情報が書かれているツー ルにアクセスをして機能やシステムの理解をする 今あるものや整理されているもの、そして開発者の考えていること・いたことを理解 するために色々なものや人に当たる。 これ、リポジトリです！
13. 情報の整理をどう進めるか？ 1 今回守りたいものって なんですか？ 情報自体はほぼ載ってないから 改ざんとかブランドイメージが 下がらないようにしたい！ どの範囲を対象とするか？ 重要な箇所はどこで、 何を守りたいのかを考えて、対象を絞り込む なので、NewsやFAQ、 LLMとかを使う部分は 見ていきたい！ それ、 めっちゃ筋良さそうですね！ それでいきましょう！
14. 実際に聞いたり、見た内容などについ て後述するツールやドキュメントに書 き出したり、誰がどのようにどうやっ て操作するかや機能の特性、システム の背景など、できる限り重要な部分は メモなり参照リンクを貼る。 参加する誰もがこのシステムについて わかるようにする。 右図のように、FigjamやMiroなどを用 いて、アクセスの経路や各種必要な情 報をコメントを残していくのも良い。 共通の言語化をしよう！ - 共通認識を「育てる」 2
15. ツールの選定はどうしよう？ - DFD? アーキテクチャ図？ 3
16. ツールの選定はどうしよう？ - DFD? アーキテクチャ図？ 3
17. ツールの選定はどうしよう？ - DFD? アーキテクチャ図？ 3 結論 データの流れやわかりやすさがあれば、 どのようなものを使っても大丈夫！
18. ツールの選定はどうしよう？ - STRIDE 3 Spoofing - 真正性の侵害 S Tampering - 完全性の侵害 T Repudiation - 否認防止の侵害 R Information disclosure - 機密性の侵害 I Denial of service - 可用性の侵害 D Elevation of privilege - 認可の侵害 E 例: JWTの偽装 例: ページの改ざん 例: 監査ログの停止 例: SQL Injection 例: ReDoS 例: 特権ユー ザーの作成
19. ツールの選定はどうしよう？ - 他にもあるよモデリング手法 3 設計・開発・テストにおけるセキュリティの実践と考え方を知ろう https://www.docswell.com/s/a-zara-n/KPGX74-2025-08-14-143959#p62
20. Let’s modeling 4 二人のドタバタ脅威モデリングの始まりです！ ※ドタバタもジタバタもせず、真剣に1時間くらいやりました。 本セクションの後半で結果をお話しします。 前置きはここまで
21. システム概略
22. 本日のお題となるWEBシステム App Runner CloudFront GitHub Actions Bedrock ECR S3（KB用） CloudFront GitHub Actions API Gateway Lambda （Node.js） DynamoDB S3（WEB） CDK
23. GitHub Actions JAWSDAYS 2024 CloudFront API-GW S3 （WEB） Lambda （管理者用） S3 （イベント写真） DynamoDB （News） DynamoDB （FAQ） DynamoDB （FollowUp） Lambda （一般参照用） Lambda （一般参照用） Read Write Read Read 実装方針 /* /assets Cognito （管理者認証） /api ベーシックなAWSサーバレス構成を 意識して構築（JAMstack） 動的コンテンツはDynamoDBに格納 Write作業は管理者のみに縛りたい ので、一部APIにCognito認証を導入 コスト増大NGだったので WAFすらケチって利用せず。 結果的に激安で運用できている ただし、Lambdaが大量に動かないよう CloudFront→API-GW部分はキャッシュ活用で対応 Deploy
24. JAWSDAYS 2025 実装方針 コンテナイメージに詰め込んだ方が 楽じゃね？と思い、App Runner採用 （ECSはオーバーテクノロジーだと思ったので不採用） EDoSされて料金が跳ねたら嫌なので WAFを設置（CommonRuleSet） （AppRunner/Bedrockがお高め） News機能をmicroCMSにお引越し Bedrock KB を利用したQAチャット 機能をイベント用に新規実装 デプロイ無しに機能のOn/Offを切り替えたかったので AppConfigによるFeature Flagも導入 CloudFront WAF App Runner ECR Secrets Manager Bedrock Knowledge Base S3（KB用） GitHub Actions AppConfig チャット機能 On / Off 自動デプロイ VectorDB Push 入力値 バリデーション
25. 脅威モデリングの実践
26. 脅威モデリング結果の要点 JAWSDAYS 2024 JAWSDAYS 2025 1 AWSリソースの利用におけるセキュリティ観点 システムの特性とリスクを勘案し優先度をいかに切り分けるか？ 2 外部との連携(CI/CD)におけるセキュリティ観点 CI/CDでやるべき範囲とそうでないものを「実際の運用」に照らし合わせて考える 3 LLM(Bedrock)における入出力に関する観点 プロンプトインジェクションによる「ブランド」「EDoS」をいかに防ぐか 4 外部サービスの認証の管理に関する観点 シークレットサービスが誰からアクセスできて良いのかの管理 入出力
27. 脅威モデリングが完了し、実際に脅威の洗い出しや現在のセキュリティコントロー ル、不足箇所など概ね把握ができました。その中で、私たちはセキュリティに 「完璧」を求めるべきなのでしょうか？ 脅威モデリング結果をもとに何をするかを考える 結論 完璧に防ぐのではなく、リスクどのようにすべきか決める もちろん業界や企業においては失敗が許されない、リスクが許容されない業界があ るのももちろんですが、脅威モデリングはそれらを全員が求めるものではありませ ん。
28. 発生しうる脅威に対して、まずは何を考えるべきで、どのように対処をすべきで しょうか？ 脅威モデリング結果をもとに何をするかを考える 考えるべきこと = リスクの整理 すべきこと = トリアージ 1 かけられるコストはどの程度？ 2 どの資産を守るべきなの？ 3 攻撃の難易度や蓋然性は？ 4 被害に遭った時のコストは？ 1 修正コストと被害時のコストの計算 2 守るべきものは守られているか確認 3 攻撃経路の整理と難易度の理解 4 包括的にみて攻撃がなされるか整理し 受容・回避・緩和・移転に割り振る
29. 脅威モデリング結果を割り当てると - JAWS DAYS 2024 悪意のある人間が CI/CDを触れてしまう GitHub Actions CloudFront API-GW S3 （WEB） Lambda （管理者用） S3 （イベント写真） DynamoDB （News） DynamoDB （FAQ） DynamoDB （FollowUp） Lambda （一般参照用） Lambda （一般参照用） Read Write Read Read /* /assets Cognito （管理者認証） /api Deploy 脅威と対策 T-完全性の侵害 E-認可の侵害 脅威: 認証情報漏洩でサイトが改ざんされる 対策: 不特定多数にRepositoryを公開しない 脅威: 認証情報を使ってS3以外を操作する 対策: GitHub Actionsにフェデレーションされる IAM RoleのポリシーでS3の特定のバケット のみに制限をする
30. 脅威モデリング結果を割り当てると - JAWS DAYS 2024 GitHub Actions CloudFront API-GW S3 （WEB） Lambda （管理者用） S3 （イベント写真） DynamoDB （News） DynamoDB （FAQ） DynamoDB （FollowUp） Lambda （一般参照用） Lambda （一般参照用） Read Write Read Read /* /assets Cognito （管理者認証） /api Deploy E-認可の侵害 + S-真正性の侵害 脅威と対策 API Gatewayへの迂回接続 脅威: 意図しない迂回接続と料金の増加 受容: API Gatewayのドメインが推測難しいため
31. システムの機能とAWSリソース の設定が一致しているか 脅威モデリング結果を割り当てると - JAWS DAYS 2024 GitHub Actions CloudFront API-GW S3 （WEB） Lambda （管理者用） S3 （イベント写真） DynamoDB （News） DynamoDB （FAQ） DynamoDB （FollowUp） Lambda （一般参照用） Lambda （一般参照用） Read Write Read Read /* /assets Cognito （管理者認証） /api Deploy E-認可の侵害 脅威: Cognito UserPoolに意図しない管理者の追加 対策: 設定値でSelf-SignUpを防止 脅威 S-真正性の侵害 脅威: 管理者になりすます 移転: API GWのAuthorizerを用いるのでAWS側に リスクを移転する
32. 脅威モデリング結果を割り当てると - JAWS DAYS 2025 プロンプトの入力と Bedrockからの出力制御 S-真正性の侵害 脅威: 意図しない出力(ブランド侵害) 対策: 入力Promptの文字数制限などを行い出力制限 脅威 D-可用性の侵害 脅威: 入力値と出力値によるEDoS 経済的サービス停止攻撃 対策: 入力値と出力値の制限をする CloudFront WAF App Runner ECR Secrets Manager Bedrock Knowledge Base S3（KB用） GitHub Actions AppConfig チャット機能 On / Off 自動デプロイ VectorDB Push 入力値 バリデーション 入出力
33. 資格情報の保護 外部サービスとの連携 脅威モデリング結果を割り当てると - JAWS DAYS 2025 I-機密性の侵害 脅威: 資格情報の侵害 受容: Secret managerへのアクセス制御は今回はア プリケーション側に脆弱性がないので、受容 する 脅威 D-可用性の侵害 脅威: 外部サービスから取得したデータによる コンテンツ改ざん 受容: 外部サービスからのデータは一定信頼するも のとして今回は受容する CloudFront WAF App Runner ECR Secrets Manager Bedrock Knowledge Base S3（KB用） GitHub Actions AppConfig チャット機能 On / Off 自動デプロイ VectorDB Push 入力値 バリデーション
34. プロンプトの入力と Bedrockからの出力制御 AWSで特に考えるべきこと(今回の場合) IAMや資格情報の管理 外部との接続部 サービス特性に基づいた セキュリティ デフォルト設定や動作など 入力値と出力の扱い リソース間で扱いが異なるもの CI/CDにおける 最小権限のあり方 外部のサービスの資格情報 のアクセス管理 システムの機能とAWSリソースの 設定が一致しているか リソースがどのような条件で アクセスされるか？ 入出力
35. まとめ ＆ 感想
36. A. やってよかった！ Builder目線で良かった点 （セキュリティ的な観点以外で） Q. 「脅威モデリングやってよかった？」 システムのメンタルモデルの 再構築/思考整理 対話を通じて ”認知バイアス ”が存在していることを知る ドキュメント整備の必要性に気付く
37. まとめ：良い脅威モデリングを行うために 脅威モデリングは ”システムの穴を叩かれる場所 ”ではない！ より良いシステムを実現するためにオープンなマインドで
38. Thank You！
39. Appendix.
40. 1.今日やることを試してみたい場合 - ビルダーのための脅威モデリング https://catalog.workshops.aws/threatmodel/ja-JP