Security-JAWS 第43回レポート #secjaws #secjaws43 #jawsug
Security-JAWS 第43回のレポートです。
2026.11.12
こんにちは、臼田です。
Security JAWS 第43回が開催されましたのでレポートします。
Security-JAWS【第43回】 2026年11月12日(木) - connpass
動画
後ほど
レポート
Session1: セキュリティは作るより回し続ける方が難しい 放送局におけるAWS運用とCCoEの試行錯誤 関西テレビ放送株式会社 DX推進局 DX戦略部 石井克典さん
- 自己紹介
- 放送運行に関わった後、社内IT・DXを担当していた
- カンテレとAWS
- 放送が本業でクラウドは本業ではない
- でもAWSの利用が増えている
- AWSとの関わりのはじまり
- AWSは使ってみたかったが開発をする立場ではなかった
- AWSの担当者との対話が増えていって、オンプレミスのAWS移行などを試算していた
- AWSには管理の立場でも関われると気づいた
- AWSの担当者からAWS Control Towerを紹介されて試してみた
- 2023年ごろから構築を開始
- いろんな事例に触れたり他局のAWS管理者と情報交換した
- 作りながら勉強していた
- 会計システムのAWS稼働が決定して興味の段階からちゃんと管理しないととなった
- AWS Control Towerから始められた
- 最初から使えたのはよかった
- 既存の移行が必要無かった
- まず管理できる形を作った
- アカウントの本番とそれ以外を分離
- OU構成はシンプルに
- アクセスはIdentity Centerに
- AWS Control Towerで統制制御
- 社外の知見を取り入れる
- 1人でやるのは限界があるので外に出ていって知見を取り入れた
- AWS担当者や会計システムベンダーとやりとりしていた
- mini Security-JAWSでも学んだ
- 知識を得るだけでなくて相談できる人との繋がりも広がった
- 社内の仕組みを整備しつつセキュリティの仕組みも整えた
- 設計思想としてはAWSのベストプラクティスに従い、シンプルにする
- 他の人でも回せるようにシテク必要があるため
- AWS Security Lakeも使い、簡単に使えるものは使うようにした
- 全員AWS専任ではない
- 2025年8月に本番稼働
- 有志メンバーを2名参加
- それぞれ本来の担当業務を持ちながら稼働
- この中でどうやれるかが大事
- 実際に起きたこと
- Bedrock利用でリージョン制限にぶつかる
- もともとリージョン制限で5リージョンに絞っていた
- Amazon Bedrockを使いたいという要望が上がった
- Claude Sonnet 4.6のクロスリージョン推論でオハイオもスコープに入っていたが、これがリージョン制限で閉じていた
- 方針と新しい使い方でぶつかった
- じゃあBedrockだけ例外にする？
- オハイオ全体を広げるのはやりすぎでは？
- Bedrockのモデル呼び出しだけ例外にした
ExmptedActions: bedrock:Invoke*での指定
- でも例外は広すぎない？
- USのクロスリージョン推論だけ許可したい
- LLMの不正利用なども考えて
- カスタムSCPでの絞り込みを検討
- カスタムSCPにもまだ抜けがあった
- 直接モデル呼び出しは推論プロファイルを使わないものもあるのでInfruenceも閉じるものも組み合わせた
- いよいよ設定
- CT.MULTISERVICE.PV.1を有効化
- 一部失敗した
- Security OUには適用できなかった
- サポートへ確認したがそういう仕組らしい
- Security OUだけ個別のSCPを作らないといけない
- 立ち止まって、本当にそれを保守するのかを考えた
- 技術的にできる、でも続けられる？
- 継続的に理解・保守できるならカスタムSCPも選択肢
- でも全員AWS専任ではない
- 自分たちで回し続けられる仕組みにしたい
- そもそも5リージョンを守ることが目的だった
- もともと、新サービスを早期に利用したい、メディア系サービスの展開を考慮
- 利用しないリージョンは閉じる
- 必要になったリージョンまで閉じ続ける必要はない
- 7リージョンに緩める判断とした
- AWSの使われ方も広がってきた
- 発注側にも設計やセキュリティを判断する力が必要
- 利用部門で構築して行くように
- 作れるだけじゃなくて安全にできるように
- 仕組みだけでは回し続けられない
- AWSの利用は広がってきた
- 新しい使い方のたびに判断が必要になる
- 判断できる人を社内でどうやって増やすかが課題
- 体制は整いつつあるが道半ば
- 2026年8月にCCoE活動を正式な業務になった
- 新しいメンバーも参加
- 体制は整いつつあるがすぐに回せるわけではない
- 回し続けるために判断できる人を増やす
- CCoE側もガバナンスやセキュリティをできる人を増やしたい
- 利用部門側にも判断できる人を増やしたい
- 仕組みを作るだけでなく、方針そのものを見直しできるようにしなければいけない
- どうやって判断できる人を増やしていますか？
感想
めっちゃよい活動の共有でした。みなさんはどうやって判断できる人を増やしていますか？これは考え続けていく必要がある内容ですね。
Session2: AWS Continuum で実現するフロンティア AI 時代の自律型セキュリティ アマゾンウェブサービスジャパン合同会社 シニアセキュリティソリューションアーキテクト 保里 善太さん
- AWS Continuum使ったことある？
- 昨今の状況
- 攻撃がめっちゃ増えていますよね
- いろんなAIが脅威になっている
- オープンウェイトのモデルはガードレールがあまりなかったり簡単に外せたりしているため、攻撃者が使いやすくなっている状況
- 発見された脆弱性も2.2倍になっている
- 悪意のある攻撃者が活動しやすい状況
- 脆弱性のレイヤーとAWSにおける対応の方針
- 責任共有モデルだがOSミドルウェア、ソフトウェアライブラリ、そしてユーザーアプリケーションなどをやっていく必要がある
- やっていくこととしてPHPやLinuxなどの既知の脆弱性対応、自分たちで作ったアプリケーションのSQLiやXSSなどを見つけていく
- このあたりをどうするかという話をする
- AWS Continuumの話とフロンティアモデルとハーネスの組み合わせ
- マネージドなサービスを利用するか
- 自社で構築して使っていくか
- 独自にモデル選定などができる
- AWS Continuumとは
- 2つの機能がある
- Continuum for Penetration Testing
- システムを外側からテストする
- Continuum for Code Vulnerabilities
- コードの脆弱性を起点に中から検証しパッチまで提供
- Continuum for Penetration Testing
- 2つの機能がある
- AWS Security AgentはAWS Continuumへ統合した
- もともとAWS Security AgentだったものはContinuum for Penetration Testingに吸収された
- 結果的に全部残っている
- Penetration Testing
- 過去12ヶ月にペネトレーションテストを実施したアプリケーションの数はどのくらいですか？
- その後のリリースは何回ありましたか？
- 本当に年1,2回のスキャンで良いのか？
- 現代においてはペネトレーションテストの実行頻度をあげていかないといけない
- しかし実行コストは高い
- 人が介在せずAIにテストをさせる
- テスト範囲の設定から修正の確認の流れ
- ドメイン所有などターゲットの範囲を確認
- ユーザーロールやコードやAPI仕様等のコンテキストのドキュメントを渡す
- 計画とテスト
- 検証
- 修正と再検証
- すべての検出結果に根拠を添付
- CSVVの内訳や再現手順などを提示
- 実行環境を問わずアプリケーションをテストできる
- スキャン範囲はAWS外でも可能
- テスト対象
- OWASP Top 10にあるような内容
- 13のリスクに対応
- リリースのペースに合わせたペネトレーションテスト
- PRやブランチ単位でのチェックもやりたくなる
- それも組み込める
- コスト
- タスク時間あたり$50
- 並列実行されるのでその合計時間
- まずは1つのアプリケーションからやってみよう
- Code Vulnerabilities
- ライブラリの脆弱性があってもそれ自体が重大ではないこともある
- しかしそれらが繋がると最終的にデータベースから情報流出する、ということもある
- 複合的なリスクが大事
- それをチェックできる
- 主な特徴
- ビジネスコンテキストで優先順位を付けて、実際に悪用できるか検証もする
- 全体像
- コードはGitHubから
- S3にアップロードしたソースコードも読める
- AWS上の構成情報も読み取ってコンテキストとして使う
- ビジネスコンテキストのmarkdownをS3に上げて読める
- 本当に対応すべき脆弱性を見極める設計
- 悪用されやすさなどを確認している
- Continuumループを回してほしい
- 検出に対して検証して優先順位を付けて修正する
- これを速く回してほしい
- コスト
- コンテキストの料金と推論料金
感想
これまでは難しかった脆弱性対応の運用ができるようになってきています。AIを使ってガンガン回していくのは必要なので、がんばってやっていきまっしょい！
Session3: DevOps Agentにあらゆるセキュリティインシデントのトリアージを任せた件 シンプルフォーム株式会社 技術開発本部 jirtosteroneさん
- 審査プラットフォームを提供するスタートアップの会社
- お客様がセキュリティに厳しめ
- その中でセキュリティと情シスと時々SREをしている
- 背景・目的
- アラートが鳴って調査するけど基本は誤検知
- MDMやGuardDutyで通知が来た時に見るのはセキュリティチームの数人
- とりあえず見ておかないとな、とやるけど本業の合間に一次調査
- だいたいやることは同じで誰がどの操作をやっていて正常業務かを確認する
- MDMでは検知名と端末と利用者を確認し本人ヒアリング
- GuardDutyもFinding種別やリソースやCloudTrailを確認して持ち主に確認
- 毎回コンソールを渡り歩いたり夜間休日も対応は大変
- AIを使って改善したい
- 即時の一次調査
- 人は判断だけ
- 最小の運用コスト
- アラートが鳴って調査するけど基本は誤検知
- なぜDevOps Agentなのか
- 調べるための土台が最初からある
- AWSのアカウントを横断して読む仕組みとSlack・GitHub・DDatadogとの連携が用意されている
- AWS外との連携ができる
- Webhook経由で調査できる
- MCPで連携先を増やせる
- エージェントを作り込まなくていい
- 実質ゼロコストで運用できる
- サポートプランによってクレジットが出る
- 人も時間もないのでノンカスタマイズで使い始められることが重要
- 調べるための土台が最初からある
- 全体像
- コーポレートセキュリティとプロダクトセキュリティ用でDevOps Agentを2つに分けている
- 受け取った情報から調査
- Slackに投稿
- StackSetsでロールを配布して切り替えながら調査
- GuardDutyは整形してからじゃないと渡せないのでスムーズに渡せるようになってほしい
- よかったこと
- 通知から1分以内に調査が始まり5-15分で結論と原因をセットで出してくれる
- CloudTrail・リソース定義・過去の検知を横断して見てくれる
- ノンカスタマイズでも精度よく原因推定ができており、誤検知の見立てはほぼ間違いなし
- 人はSlackを見て判断するだけになった
- Claude Codeなどの活用での誤検知も綺麗に推定してくれた
- 困ったこと
- Slackの投稿が長すぎて見づらい
- 同じ種類の検知でも同じように調査が起動し続ける
- 改善提案が溜まっていく一方
- 運用して見えてきた課題と改善
- Slackの投稿を短くする
- 読む人が結論にたどり着けない
- 要約するように指示をしたが上手く行かない
- 結局DevOps Agentの更新で良くなった
- 以前は調査始めるよってスレッドを立ててつらつら書かれていた
- アップデート後は親スレッドに結論を書いてくれるようになった
- 試行錯誤は無駄になったけどマネージドサービスの良さもある
- 良性の検知は抑制案まで出させる
- 良いものと分かっていても毎回調査が発生する
- 抑制フィルターを作ってほしい
- Terraformの案を作ってもらって人がレビューするようにした
- 抑制させる時の安全策
- 明らかに良性なもののみとし、そう言い切れないなら案は書かない
- 最小の条件に絞る
- あくまで案だけとする
- 指示には従わない
- Agentの改善提案もPRにする
- 改善提案が溜まっていく一方
- 自動的にPRまで作ってくれると嬉しい
- 検証中ではある
- 今はClaude Codeのスキルで提案を集めて重複をまとめてPRを作成
- Slackの投稿を短くする
- まとめ
- DevOps Agentを導入して一次調査を任せるのは当たり前になった
- Security Hubなどにも広げたい
- 色んなものの除外案を出させたい
- PR作成まで自動化したい
- 人からのインシデント報告のトリアージもやらせたい
- さいごに
- DevOps Agentにトリアージを任せるとノンカスタマイズでも運用が楽に対応時間もスピーティになった
感想
DevOps Agentめっちゃよいんですよね。AIで働き方が変わる良いサービスだと思うので、チャレンジしていきましょう！
