[レポート][A11]クラウドネイティブ時代のウェブセキュリティ再考 ～AWS、コンテナ、CI/CDに潜む死角～ by 徳丸浩- JAWS DAYS 2026 #jawsug #jawsdays2026 #jawsdays2026_a

こんにちは、臼田です。

みなさん、JAWS DAYS 2026楽しんでますか？(挨拶

本日はJAWS DAYS 2026の下記セッションのレポートです。

[A11]クラウドネイティブ時代のウェブセキュリティ再考 ～AWS、コンテナ、CI/CDに潜む死角～ by 徳丸浩

マイクロサービスやコンテナ、CI/CDの普及により、ウェブサービスの開発スピードは飛躍的に向上しました。しかし、インフラがコード化され自動化が進む一方で、従来の境界防御では防ぎきれない「クラウドネイティブ固有の脅威」も生まれています。 本講演では、AWS環境を前提に、SSRFによるクラウド機能の悪用やサプライチェーン攻撃といった現代的な脅威の実態を紹介。AWSのセキュリティ機能を活用した技術的対策だけでなく、組織的な取り組みや、事故を防ぐためにエンジニアが持つべきメンタルモデルについて解説します。

レポート

• 自己紹介
  • だんだんセキュリティをやるようになっていった
  • 今はEGの取締役
  • 徳丸本を書いている
• まずはCI/CDのおさらいから
• CIはソースコードをまとめる
• ビルドしてテストする
• これがなかったときはどうしていたか？
  • 各担当者のローカルで開発してファイルサーバにおいてテストする
• あるとき
  • GitHubで管理してプルリクして自動でビルドテストセキュリティチェックする
  • あるときは効率も制度もぜんぜん違う
• CD
  • テスト済みのコードを本番環境にリリースする、デプロイする
• ないとき
  • 手順書で手作業して、ダメなら切り戻し
• あるとき
  • 自動で動いて切り戻しも自動
• GitHubからAWSデプロイにはGitHub側にAWSの権限が必要
  • 昔ながらの方法ではIAMアクセスキーを発行していた
  • 今でもやっているがアンチパターン
• CI/CDによる開発の高速化
  • CI/CDは表裏一体でだいたい一緒にやる
  • ここにセキュリティを組み込んだらDevSecOps
  • これはざっくりし過ぎな説明だが、やることはだいたいそう
• DevSecOpsでやること
  • SAST
  • DAST
  • SCA
  • 脆弱性診断
• 自動脆弱性診断の種類
  • DASTは動かしてテストする
    • 動かす状態にする必要がある
  • SASTはソースコードで診断
    • 書いたらすぐにスキャンしてくれる
    • プッシュとかいろんなタイミングでも動く
  • SCAは使っているコンポーネントの診断
    • 精度が高くて依存関係を解決できる
    • DependabotやTrivyなど
  • コンテナイメージスキャン
    • ベースイメージに脆弱性があるとか
    • SCA的な機能で依存関係の脆弱性もわかる
    • Trivyが有名
• Dependabotのプルリクの例
  • log4jを見つけてくれる
• こういった脆弱性は作っているときに見つかるよりは使っていたら突然見つかる
  • モニタリングで継続的にSCAやコンテナスキャンが必要
  • 見つけたらプルリク作ってくれてテストしてデプロイまで自動化する
  • ここまでは本題ではない
• CI/CDに対するサプライチェーン攻撃
  • hackerbot-claw: AIによる攻撃キャンペーン
  • 最近TrivyのGitHubリポジトリが消えた
  • 他にもMicrosoftやDataDogといった大手企業のプロジェクトを含むリポジトリが影響を受けた
• 何が起きたか
  • TrivyはOSSなのでプルリクエストは誰でも作れる
  • 有象無象の色々なものがあるのでまずテストが動く
  • それがpull_request_targetを使っていた
  • 強い権限で実行されてRCEになった
• 攻撃の流れ
  • 2/270:18 UTCにPR作成
  • 数時間後に色々されていった
  • 幸いにも汚染されたTrivyはリリースはされていなかった
• プルリクエストの内容
  • curlでコードを落として実行するコマンドが隠さず入っていた
• Codecov事件
  • コードカバレッジツール
  • セキュリティの意識が高い企業がお金を出して買うようなツール
  • 2021年にBash Uploaderが汚染され多くの企業でCIが実行された
  • 同じくコードをcurlして実行されていた
  • こちらはしばらく気づかなくて29,000社が影響を受けた
  • CIなのでGitHubの権限は取られて、AWSのキーなどもあれば取れらた
• メルカリ社も被害を受けてリリースが出た
  • コード上のテストデータに個人情報が含まれていた
  • 幸い本番環境は無事だった
  • しかし仕組み上はCI/CD環境がやられると本番も影響があってもおかしくない
• サプライチェーン攻撃の傾向と対策
  • アメリカもこの辺り注力している
  • 攻撃の起点
    • プルリクエスト
    • 汚染されたCIツール
    • 汚染された依存パッケージ
  • 代表的な対策
    • pull_request_targetは極力使わない
    • プルリクエストの名前が悪用されないように環境変数経由で渡す
    • ツールのバージョン固定化、署名検証
    • 依存パッケージのバージョンピン留め、provenance確認
    • AWS等との連携には長寿命アクセスキーではなくOpenID Connectを利用して最小権限かつ短寿命の権限を付与する
    • 緩和策だが遥かに良い
• マイクロサービスの話
• モノリスとマイクロサービスの違い
  • モノリシックはアプリケーション内でサブルーチンは別れているが1つのアプリケーションになっている
  • マイクロサービスで分割してそれぞれメンテナンスできるようにする
  • 機能変更がマイクロサービスならやりやすい
  • サービスごとにデータベースが分かれるなど
• クラウドネイティブの実装
  • マイクロサービス
  • サーバレス
  • コンテナ
  • これらでスピードが上がるのは良いところ
  • しかしセキュリティの課題もある
• コンテナ技術
  • Dockerfileの例
  • 脆弱な環境を最近も配信している
  • gradleを入れてbuildしてTomcatに配置
  • 手作業でやらなくて良いのでよい
• クラウドネイティブまとめ
  • 柔軟性と迅速性
  • 環境の変化に柔軟に対応したい
  • クラウドネイティブではDevSecOpsなどでこれらの技術が使われる
• クラウドネイティブのセキュリティ課題
  • 各要素にセキュリティ課題がある
  • ウェブシステムとしての課題はクラウドネイティブでも存在する
• マイクロサービスの問題
• SQLインジェクション等の古典的脆弱性はマイクロサービスでも対応が必要
  • サービス間の連携は弱点になりやすい
  • mTLSなどでサービス間の認証をしたり、マイクロサービス間のトランザクション
• ケーススタディ
  • 利用者のメールアドレスに送信する
  • Javascriptでメールアドレスを取得する
  • メール送信サービスにそれを送る
  • ログイン中のユーザーにメールを送るのが正常系
  • メールアドレスを改ざんして送る
  • クライアント側でマイクロサービスで統合するとこうなる
• 7pay事件当時に存在していた脆弱性
  • ID連携をしているときに誰でも他人のIDでログインできる
  • OAuthで認証して、それを持っていく時普通はJWTを使う
  • JWTを使わずにただのjsonで渡していた
• どうすればいいか？
  • BFFによるバックエンドオーケストレーションによる解決
  • API Gatewayでユーザーに見えないように解決する
  • JWTを使う方法もあるが漏れもあるのでBFFの方が良い
• コンテナ環境のアタックサーフェイス
  • コンテナセキュリティ青本がよい
  • レジストリへの攻撃
  • マルウェア入りのイメージが使われる
  • サプライチェーンがあれば汚染される可能性もある
• 対策
  • 信頼できるイメージ
  • CI/CD保護
  • レジストリスキャン
• CapitalOneに対するSSRF攻撃
  • 日本では馴染みがないが有名な企業
  • 先進的なアメリカの金融機関
  • SSRFでやられた
  • Apachとmod_securityでリバースプロキシにしていた
  • mod_securityの導入は簡単だが脆弱になることも
  • ProxyRequests Onはだめ
  • オープンプロキシになる
  • 脆弱性の詳細は出ていないがこれではないかと推測している
• サーバーを安全にするまでProxyRequestsをOnにしてはいけないと警告も出た
• 攻撃の様子
  • リバースプロキシがオープンプロキシになっていた
  • ここからIMDSにアクセスできた
  • 加えてS3への権限が割り当てられていた
  • S3に情報が保管されていた
• IMDSv1とは
  • EC2のエンドポイントなどがわかる
  • 認証情報もとれる
• なぜ攻撃を受けたか
  • S3に大量の個人情報を保存
  • ストレージへのアクセス権がWAFについていた
  • WAFがオープンプロキシになっていた
  • IMDSが無効化されていた
  • 当時はIMDSv1だった
• 脆弱性を産んだメンタルモデル
  • 論文が上がっていた
  • そこではAWSに対する過度な信頼と責任共有モデルの理解不足
  • 曖昧さによるセキュリティへの依存
• 責任共有モデル
  • インフラ事業者と利用者でセキュリティの責任を分け合っている
  • 利用者がやるべきことがある
  • どこまでやるべきか意識する
  • IaaSではパッチ適用はユーザーがやる
  • LambdaだとOSやミドルウェアの面倒はAWS側
  • 自分で面倒を見るのはライブラリなどをやる
• 教訓を活かすなら
  • 最小権限の原則を守る
  • 責任共有モデルを意識
• PLAID社KARTEの脅威分析事例
  • 先駆的な取り組みで参考になる
• まとめ
  • CI/CD、マイクロサービス、コンテナ等についてもセキュリティに課題がある
  • 最小権限と責任共有モデルが出発点
  • 過去のセキュリティ事例を調べて勉強しよう
    • NotebookLMなどを使えばやりやすい
  • DevSecOpsによる素早い開発と脆弱性対応の両立
  • DevSecOpsサイクルに入る前の脅威分析と対策

まとめ

徳丸先生の話非常に興味深かったです。

サプライチェーン攻撃は本当に課題ですが、1つ1つ自分たちの状況ややっていることを確認して潰しこんでいきましょう。