いつも記事を読んでいただきありがとうございます！
モブエンジニア（@mob-engineer)です！
今回は2025.05.07（火）に開催したCloud Security Night #2に参加しましたので、アウトプットとしてイベントレポートを執筆しました。
初見の方でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。
誤字脱字、わかりづらい表現、認識相違などは極力なくすように心がけています。そのうえで、リアルタイムで執筆しておりますので、誤字脱字、わかりづらい表現、認識相違などがあるかもしれません。
イベントページ
本日司会の桑原さん過去登壇資料
- セッション
- AWS診断200件の分析から見る頻出指摘と対策
- サイバーエージェントにおけるクラウドセキュリティエンジニアの仕事
- LLMアプリケーションのCSPMのはなし
- まとめ
セッション
AWS診断200件の分析から見る頻出指摘と対策
参考サイト
- 自己紹介
- 2022年にGMOイエラエへ新卒入社されたセキュリティエンジニアの方
- （個人的意見）GMOイエラエはセキュリティ界隈では有名ですよね
- 分析対象
- 2021年1月から2025年3月の期間（約213件）
- 総合評価としてA～Eのランク付け
- （個人的意見）ランク付けすると分かりやすいんですよね
- 分析した結果、70％がCランク（リスクレベル中の脆弱性）がある
- リスクレベル別分析
- パブリックアクセス可能なAWSサービスが大半
- よくあるケースとしてS3バケットでパブリックアクセスが有効化している
- パブリックアクセス可能なAWSサービスが大半
- リスクレベル高
- 認証機能の不備
- 機微情報を取り扱うエンドポイントに認証処理を行っていない
- WebアプリにログインしないでAPIゲートウェイへアクセスする
- Cognitoを利用することで対処可能
- 既知の脆弱性が存在している
- Log4Shellが環境に混在していた
- （個人的意見）開発環境は特に考慮しないですよね
- Log4Shellが環境に混在していた
- 認証機能の不備
- リスクレベル中
- 強い権限のIAMユーザにMFAが設定されていない
- 大規模インシデントもMFA認証を設定していたら防げる可能性も
- 対処策としてIAMポリシーでMFAを強制的に有効化させることが必要
- 強い権限のIAMロールが複数サービスに権限づけられている
- 予期せぬ処理が行われるリスクがある
- 最小権限の原則を順守することが大切
- IAMにおける特権昇格
- 強い権限のIAMユーザにMFAが設定されていない
- リスクレベル亭
- 不適切な機密情報の管理
- 平文で機密情報を管理している状態
- （個人的意見）EC2・ECSはあるあるなのでリスクですね
- 対策としてSecret ManagerやParametor Storeを利用することがある
- （個人的意見）Parameter Storeは利用難易度は低いですね
- trufflehogを利用することで効率的に情報を取得できる
- 平文で機密情報を管理している状態
- 不適切な機密情報の管理
- CVS関連
- IMDSv1によるメタデータ取得対応
- 対策としてv2に変更することが必要
- （個人的意見）このあたりは意識している開発者は少ないでしょうね
- IMDSv1によるメタデータ取得対応
- まとめ
- 最小権限の考えを順守することが必要
- 実現するためのツールとしてIAM Access Analyzerを利用する
- （個人的意見）ブログで執筆したいですね～
- 最小権限の考えを順守することが必要
サイバーエージェントにおけるクラウドセキュリティエンジニアの仕事
参考サイト
- 自己紹介
- 2022年にサイバーエージェントに入社したセキュリティエンジニアの方
- CSPMや脅威検知の仕組み構築を経験されている方
- パブリッククラウド利用状況
- AWSに関しては750アカウント
- GCに関しても1000以上のプロジェクト
- （個人的意見）大規模運用ですね～
- クラウドセキュリティ
- 定義にのっとるとクラウド内のリソースのセキュリティを担保するとなる
- 責任共有モデルで考えるのとわかりやすくなる
- クラウドセキュリティの範囲自体広いためすべてを実施するのは大変
- （個人的意見）確かにセキュリティ周りのルールは多い印象ですね
- セキュリティエンジニアのあれこれ
- 国内ではセキュリティエンジニアとしての募集は少ない
- （個人的意見）クラウドエンジニアが兼任する場合が多いですよね
- 採用分布をみてみるとプロダクト・クラウド環境全体で分かれる
- プロダクトチームにJoinしセキュリティを強化する
- SRE・プラットフォームエンジニア的動き方も
- 国内ではセキュリティエンジニアとしての募集は少ない
- クラウド導入の進め方
- AWS CAFなどをもとに枠組みを作っていく
- フレームワークだけでなく実例も必要
- サイバーエージェントの取り組み
- クラウドセキュリティチームを発足
- CSPMをもとにインシデントを検知⇒修復する取り組みを行った
- 結果として、設定不備の大幅な改善を行った
- ターニングポイントとしてチームの体制変化
- 体制変化後には設定不備以外にも広げていきたい
- （個人的意見）仕組化は本当に大切ですね
- 現在は予防的取り組み（ガードレール）の実装を目指している
- レジリエンスも担保したセキュリティ実装を
- （個人的意見）ビジネスに生かしていけるかが気もかもしれませんね
- 具体的な取り組みとしてクラウドセキュリティガイドラインの策定と普及を行っている
- クラウドサービス（CloudTrailなど）を利用して実装している
- クラウドセキュリティチームを発足
- 質疑応答
- クラウドセキュリティガイドラインの策定と普及方法は
LLMアプリケーションのCSPMのはなし
参考サイト
- 自己紹介
- 2022年にKintoテクノロジーに入社された方
- 昨年CCoEプロジェクトの立ち上げを実施
- Kintoテクノロジーズ
- トヨタ自動車の孫会社
- 内製開発に注力している
- Security CCoEグループ
- クラウドセキュリティの専門部隊としての動き方をしている
- SOCやCSIRTの取り組みを行っている
- （個人的意見）SOCは育てたいのよね
- LLMアプリケーションのためのクラウドセキュリティ
- LLMアプリケーション開発を行っているがセキュリティに懸念が
- （個人的意見）マルチクラウドだとそろえるのが大変そうですね
- セキュリティ強化しつつ、アジリティも担保したいといった課題を抱えている
- 発見的ガードレール（CSPM）だけだと厳しい場合も
- OWASP Top 10から比較的多いLLM攻撃を知ることから行った
- LLMアプリケーション開発を行っているがセキュリティに懸念が
- LLM関連の攻撃
- プロンプトインジェクション：プロンプトによって意図しない操作を行う
- サプライチェーンリスクなどもある
- （個人的意見）責任あるAIを知ると対策につながる印象ね
- AWSで考えてみると
- 有名サービスとしてAmazon Bedrockがある
- プロンプトインジェクションであればPrompt Attacksがある
- （個人的意見）Prompt Attacksは効果あるかもしれませんね
- 個人情報漏洩の防止であればsensitive Information Filtersがある
- （個人的意見）ガードレール機能を活用するのも一つの手よね
- 過剰なエージェンシー対策であればBedrock Toolsを利用すれるのも手
- Contexual grounding Checkを利用すれば誤情報防止できる
- （個人的意見）Langfuseとの違い（精度など）が気になりますね
- まとめ
- 現在CSPMについてRegoを用いて実装予定
- （個人的意見）マルチクラウドでのセキュリティ対策は知っておかないとなぁ
- 現在CSPMについてRegoを用いて実装予定
まとめ
セキュリティ関連の話は理解しているようできちんと理解できていなかったので、本勉強会を通じて自身が不足している部分と社内に実装する必要があるセキュリティ対策を再確認することができました。
そのうえで、今回得たセキュリティ情報を自身の知識としてアウトプットしていきたいと思います。
最後まで、記事をお読みいただきありがとうございます！！
Views: 1
