開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 / Developers autonomously report AWS Security Hub findings Corresponding mechanism and AWS re:Invent 2024 presentation experience

2025/02/07：
Meguro SEC #1 AWSセキュリティ回
https://meguro-sec.connpass.com/event/334674/

開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談

西川 彰
セキュリティエンジニア

Transcript

1. 開発者が自律的に AWS Security Hub findings に 対応する仕組みと AWS re:Invent 2024 登壇体験談 Meguro SEC 2025/02/07
2. 自己紹介 　株式会社カミナシ 　西川　彰（Security Engineering） • 一般社団法人鹿児島県サイバーセキュリティ協議会　代表理事 • 大和セキュリティ Hayabusa, Takajo 開発者 ◦ HITCON 2024（台湾）、SecTor 2024（カナダ）登壇 • CISSP
3. カミナシにおける AWS 環境 • カミナシは複数のプロダクトを提供している • それぞれのプロダクト毎に dev/stg/prod のアカウントが存在する • それらのアカウントでは AWS Security Hub を有効化している サービスA サービスB Prod Stg Dev Prod Stg Dev Audit
4. カミナシにおけるセキュリティエンジニアの役割 • それぞれのサービスのセキュリティへの対応の責任は開発者にある • セキュリティエンジニアは開発チームのイネーブルメントを行う • 開発チームが自分たちのサービスの堅牢化をサポートしたり、教育を行う
5. カミナシにおけるセキュリティエンジニアのミッション セキュリティ文化を構築するのが私たちのミッション！ 具体的には、、、 • 開発者が呼吸するようにセキュリティを意識するようになること • セキュアな環境を構築しながらも敏捷性を保ち続けること • 自浄作用があるということ（問題を放置し続けないということ）
6. Security Hub findings に開発者が自律的に対応できる仕組み（Liver） アカウント A アカウント B アカウント C Audit Security tooling On-call 担当者 AWS Security Hub Amazon EventBridge Amazon EventBridge AWS Lambda
7. Liver のコンセプト 1. アクショナブルであること 　　通知を受け取った人が何をすれば良いかを明確にする 2. 対応責任者を明確にする 　　その通知を”誰が”対応するかを明確にする 3. リスク管理 サービスによってセキュアにしなければいけない度合いは異なるのでカス タマイズできるようにしておく
8. アクショナブルであること 何をしたら良いかがわからない 通知に価値はない アクションを必要としない通知は可能な限り 送らない 対応が必要ない場合でも、何らかのアクション や確認は必要
9. 対応責任者を明確化する カミナシではチームではなく ”個人”に対応責任を持たせる 開発チームは、AWS 環境で発 生したあらゆる問題に対処する 責任を負う 重要な問題やリスクが漏れない ようにする
10. リスクアセスメントマトリクス
11. リスクマネジメント サービスの重要性に基づいて 通知する最低重要度を設定 不要な通知を無くす Security Hub Automations ResourceId に下記が含まれて いれば対象外にしている • ControlTower • aws-controltower 環境によってコントロールを変える Security Hub configuration
12. 運用設計 対応すると判断 対応 自動解決 対応しないと判断 理由をチケットに記 載 CTO が許容するか 否認するか判断 対応する/しない
13. 運用を開始したところ... ちょっとしたインシデントが発生 Security Hub findings は、サービスやシステムのコンテキストを理解していない。サービスやシステム のコンテキストをよく理解しないまま対応すると、インシデントにつながる可能性がある Liver のようなシステムをできるだけ早く導入する Shift Left はやっぱり重要で、本番リリース前に可能な限り問題に対処したい
14. Ramp-up 期間を設けることに Ramp-up 期間の開始 Security Hub findings を確認する 無視したい検知項目が あればリソースに対し てタグをつける 運用開始
15. 成果
16. ここまでが AWS re:Invent 2024 での登壇内容 登壇内容終わり
17. AWS Community Builder で募集されている CFP に応募したら通った • Subject / Abstract の文字数制限が厳しいので弊社 CTO と洗練させた • 最終的なタイトルは CFP のレビュワーの方から提案がきたので変更した • CFP の構成が重要 ◦ Issue → Solution → Result が重要（と思っている） ◦ Issue は少なくともレビュワーが Issue として認識している必要がある なぜ登壇できたのか？
18. AWS re:Invent 前 • 6月初旬 CFP 申し込み開始 • 7月初旬 CFP 締切 • 8月下旬 CFP 結果 & 専用の Slack チャ ンネルに Join • 9月下旬 登壇日時決定 • 10月中旬 登壇資料提出締切 • 11月中旬 登壇内容をチェック（任意） 登壇までの流れ AWS re:Invent 期間中 • 開催初日に到着は登壇の MUST 要件 • 初日の朝 SWAG をもらいに行く（MUST） • 初日の夕方登壇者顔合わせ会（任意） • SRR（Speaker Ready Room）で最終登壇内容 修正（任意） • 12月4日登壇
19. • いろんな人から声をかけてもらえる（英語） • Customer Group Discussion に招待してもらえる（可能性がある） • スピーカー SWAG がもらえる！ 登壇者の特典
20. • とてもとても酷かった ◦ それを踏まえて今後海外で登壇する方々に色々お伝えしたい！（切実） • 何がいけなかった ◦ 暗記で乗り越えようと思ったのがいけなかった ◦ HITCON、SecTor ではスピーカーノートをほぼ頼った • 初めての環境だった ◦ バックステージから出るタイプは人生で初めてだった ◦ 色々なものが目に飛び込んできて脳のリソースを全部持って行かれた • ジョークは通じないと思った方が良い 登壇どうだったの？
21. 大事なことは伝える・伝わること 格好よく登壇とかあまり意味は無い（個人の感想） • AWS re:Invent は登壇者として求められるレベルが非常に高い ◦ でも本質は伝えるということに変わりはない • 日本人のアウトプットが海外に劣っているかというとそんなことはない • 「どう伝えるか」よりも「何を伝えるか」で勝負する みなさんにお伝えしたいこと
22. ご清聴ありがとうございました