【イベントレポート】CloudSec JP #001 #cloudsecjp

いつも記事を読んでいただきありがとうございます！
モブエンジニア（[@mob-engineer](https://qiita.com/mob_engineer))です！

今回は2025.02.28（金）に開催した**CloudSec JP #001**へ参加しましたので、アウトプットとしてイベントレポートを執筆しました。

初学者でもサクッと読めるように平易な表現で執筆しておりますので、お気軽に読んでいただければ幸いです。

#### イベントページ

https://cloudsecjp.connpass.com/event/341516/

:::note info
誤字脱字、わかりづらい表現に関しては極力なくすように心がけていますが、リアルタイムで執筆しているため、誤字脱字があるかもしれません。
:::

# 目次
- 概要
- セッション
    - クラウドに関するインシデントで2024年を振り返る(仮)
    - Pwned Labsのすゝめ
    - CSPMとのつきあい方
    - クラウドネイティブ環境でTRP（Technical Recovery Plan）訓練を実施してみた
- まとめ

## 概要
>CloudSec JPは国内のクラウドセキュリティに関わるエンジニア有志によるベンダーニュートラルなコミュニティです。 数多くのパブリッククラウドのベンダーや利用用途、立場などのありとあらゆる垣根を超えてベンダーニュートラルなコミュニティを醸成し、日本におけるクラウドセキュリティの知識・リテラシーの底上げと国内外に対するクラウドセキュリティの認知向上を目的とします。
また本コミュニティは、上記の目的を達成するために、すべてのクラウド技術を対象としたセキュリティの知見を共有する場を提供します。

## セッション

### クラウドに関するインシデントで2024年を振り返る(仮)

#### 参考サイト

https://scientia-security.github.io/translation/NCSC-O365-Mitigation.html

https://scgajge12.hatenablog.com/entry/phishing_aws_mfa

https://www.itmedia.co.jp/enterprise/articles/2302/10/news155.html

https://eset-info.canon-its.jp/malware_info/special/detail/241001.html

https://www.soumu.go.jp/main_content/000948624.pdf

- 自己紹介
    - 伊藤忠サイバー&インテリジェンス所属の方
    - セキュリティレポートが多くて寝不足になった
- インシデント収集する理由
    - クラウド自体歴史が浅い
        - 攻撃・防御に関するナレッジがたまっていない
    - HuntingのTipsとして
        - 個別テクニックは星の数ほどある
        - まずは入口・類似ケースから
    - 日々学んでいくことがたいせつ
        - セキュリティ攻撃は日々進化している
- 認証関連
    - 総当たり攻撃
        - 古の総当たり攻撃はクラウドでも被害がある
    - フィッシング攻撃
        - MFAトークン情報も抜き取ることができる
        - QRコード型だけでなく、MFA疲労攻撃もある
- 脆弱性の悪用
    - ゼロデイ攻撃
        - 収集した範囲では既知の脆弱性を狙っている
    - IMDS・TMDS・クレデンシャルデータ取得
        - クレデンシャルであっても情報は盗まれる
- コンテナ関連
    - 不要なポート開放・サービス公開
        - 不要なポートからワームが侵入
        - 基本的にインターネットに公開しない想定で作られているため弱い
- 設定ミス
    - ストレージ設定ミス
        - Amazon S3の共有設定ミス
        - データ漏洩だけでなくソースコードの不用意な公開も
    - ローコード系
        - アクセス不備による不要な公開
    - （個人的考察）情報共有系が多いのかしら
- ソーシャルエンジニアリングも多くある
- サプライチェーン系
    - 著名なソフトウェアやライブラリを偽装
        - よく利用されるライブラリに似たライブラリを公開
        - Star数も水増しできる
        - （個人的考察）きちんと精査することが大切なんでしょうね
    - 悪意あるコードを注入する
        - 公開できないがベンダも被害があったりする
    - 連携システム側のインシデント
        - クラウド権限を持っている人が侵害されたら...
        - コードや配布物にマルウェアを侵入させて抜き取ることも可能
    - リソース放置
        - 一意なFQDNへの攻撃のターゲットになる
    - その他
        - クラウドにも脆弱性はある（対策は早いが）
        - 攻撃者もクラウド機能を用いて攻撃することもある
    - モチベーション
        - M365環境を用いた悪用が行われている
        - 正規なSaaSアプリから攻撃する場合も
    - ランサムウェア
        - クラウドだから強いわけではない
    - マイニング
        - Azure Batchのような大規模計算用のサービスを悪用する
        - 思わぬ高額請求につながる場合も
    - スパム
        - 踏み台サーバとして利用される場合もある
    - まとめ
        - APIへの制御が必要
- 対策方法
    - IDとクラウドAPIの保護
        - ログイン時の要件を定める
        - アクセス制御も決めておく
    - サービス・リージョン制限
        - 使っていないサービスは使えないようにする
    - 特権管理
        - 権限とアカウントの定期的な棚卸
        - Entra IDは権限が強い   

### Pwned Labsのすゝめ

#### 参考サイト

https://pwnedlabs.io/

https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf

https://note.layerx.co.jp/n/nb84f9e6f695e?magazine_key=m2431cc441d1e&gs=69f6bc2b9932

https://www.smd-am.co.jp/glossary/YST3289/#:~:text=%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%B3%E3%82%B8%E3%83%A5%E3%82%A8%E3%83%AB%EF%BC%88%E3%81%8F%E3%82%89%E3%81%86%E3%82%93%E3%81%98%E3%82%85%E3%81%88%E3%82%8B%EF%BC%89,-%E8%A7%A3%E8%AA%AC&text=%E8%8B%B1%E8%AA%9E%E8%A1%A8%E8%A8%98%E3%80%8Ccrown%20jewel%E3%80%8D%E3%81%AE,%E3%81%95%E3%81%9B%E3%82%8B%E8%A1%8C%E5%8B%95%E3%82%92%E6%8C%87%E3%81%97%E3%81%BE%E3%81%99%E3%80%82

https://aws.amazon.com/jp/security/amazon-security-initiatives/

- 自己紹介
    - LayerX所属の方
    - Fin-Tech事業関連のCI/CDの責任者
- 直面している課題
    - クラウドの構成変更による予期せぬワームホール
    - 構成管理をいい感じに管理したい、できればAIを頼りたい
- 3年間行ってきたこと
    - チーム構成が1名→5名に増えていった
        - セキュリティつよつよ人材でなく各ロールのスペシャリストを結集させた
    - デジタルアイデンティティ・ベースライン構築・運用などを注力していった
        - 優先順位付けを行うことが大切
        - アクションを通じてリスク分散を行っていく
    - プロジェクトメンバーへの教育も行っていく必要がある
        - ネタ元として金融庁のガイドライン
- 教育どうする
    - 外部研修だけに頼ると社内業務にマッチしないのでいまいち
    - クラウンジュエルを目指した教育を
    - 結果として、Pwned Labが良いと判断した
- Pwned Lab
    - ブートキャンプ活動：
        - ラボでの実践スキル
        - コンテンツ自体はそこまで難易度は高くない
    - 学習系CTF：
        - 簡単なものがそろっている
        - 公式回答を見ないでチャレンジするのもあり
    - Cyber Rages：
        - 提供されたWebアプリケーションへのセキュリティ攻撃
        - 実践レベルの内容のため歯ごたえがある
    - クラウドネイティブな開発コンテンツがそろっている
    - 最新のセキュリティ脅威に関してもフォローしている
    - コミュニティ感が強い教育コンテンツ
    - 費用：
        - ブートキャンプ：
            - 期間でなくショット：399ドル
        - 学習系CTF：
            - フリープランはあるが、そこまでそろっていない
            - 月額200ドル
- まとめ
    - 実際にセキュリティ攻撃を座学→実践を通じて学ぶことで実務に使える
    - 受けたきっかけは**面白かったから**
    - 研修予算を確保しながら、徐々にスキルとして身につけていく
- 質疑応答
    - どのくらいの期間で受けられるのか
        - セキュリティ経験にもよるが5年ほどでCISMは取れる

### CSPMとの付き合い方

#### 参考サイト

https://www.g2.com/categories/cloud-security-posture-management-cspm

https://www.nri-secure.co.jp/glossary/cspm

https://www.gartner.co.jp/ja/articles/4-must-have-technologies-that-made-the-gartner-hype-cycle-for-cloud-security-2021

- 自己紹介
    - 伊藤忠サイバー&インテリジェンス所属の方
- 伝えたいこと
    - CSPMと仲良くなってもらう
- 閑話休題
    - CSPM製品はどのくらいあるか
    - 調べてみると87製品あった
- なぜCSPM製品の話をするのか
    - ベンダーフラットな資料は少ない
    - 特にサードパーティは世に出ていない
- CSPMの理想
    - ガードナー定義によると**一般的に普及しているフレームワーク**
    - 製品に特化しているわけではない
- なぜCSPMを利用するか
    - 膨大なリソースを人手で評価するのは厳しい
    - 頻繁に構成変更が行われるクラウドでワンショットの脆弱性診断は厳しい
        - 継続的は評価が必要
    - 楽して運用できることが正義
        - 不要なアラート・環境ごとのチューニングなどは極力なくしたい
- 理想のCSPM像
    - クラウド上のセキュリティリスクをすべて見れる
    - いい感じに対策を自動的に講じてくれる
- CSPMの限界
    - 仕組みとしてクラウドベンダーから提供されるAPI情報をもとに処理を行う
        - レスポンスをもとに機械的に検知してくれる
        - 機械的は判断なので、ちょっとひねると検知してくれない
    - 過剰な検知をしてくれる
        - 過剰なセキュリティをもとに判断しているため、企業経営に最適化してくれない
        - （個人的考察）セキュリティ投資を積極的に行う企業さんは少ないですからね
    - 機械的な仕組みである以上、正確な検知への妥協は必要
        - コンテキストによる判断、通知方法、API公開可否など
- CSPMとの付き合い方
    - 過剰な期待をしなければ仲良くなれる
    - 0→1の判断であれば意外といい感じでできる
    - CSPMが見ているから安心とは思わない
    - 苦手だとわかっているサービス・リソースを把握することが大切
    - サービスによっては他サービスも


### クラウドネイティブ環境でTRP（Technical Recovery Plan）訓練を実施してみた

- 自己紹介
    - KINTOテクノロジーズ所属の方
    - トヨタファイナンスへも所属している
    - セキュリティガバナンスも携わっている
    - 元々はWebアプリ開発を行っている
- 準備
    - 元々はランサムウェア対策から
    - 訓練対象のプロダクトはシンプルなもの
    - ランサムウェアの被害を受けたときの影響を社内検討
        - データ侵害時でも特権ユーザーは利用できるなど
    - とりあえず検討できるところは検討した
- TRPとは
    - ざっくり言えば復旧プラン
    - バックアップは行うが完全復旧は行わないシナリオ
    - VM隔離も行った
    - 訓練自体は平日/半日行ってみた
    - コミュニケーションはSlackを通じて実施
- 結果と考察
    - TRP手順自体は問題なく回せた
    - 場合によってはバックアップ取得できない場合も
    - (個人的考察)コミュュニケーションは難しいからなぁ〜
    - 管理者アカウントの保護・データ復旧に関する気付きを得られた
    - リカバリプランを複数持つことが大切
    - グループ会社からの依頼だったため進めやすかった

## まとめ

セキュリティ関連の有益な情報をキャッチアップできたので、非常に有意義な時間だったと思いました。そのうえで、**今回得たセキュリティ知見をどのように社内外へ展開していくか**を考えていくことが大切だと考えました。

最後までお読みいただきありがとうございました！！