Security-JAWS 第42回レポート #secjaws #secjaws42 #jawsug

こんにちは、臼田です。

Security JAWS 第42回が開催されましたのでレポートします。

Security-JAWS【第42回】 2026年8月26日(水) - connpass

動画

後ほど

レポート

Session1: Kiro5兄弟の今どきセキュリティ基礎知識 NTTテクノクロス株式会社 加藤 洋雄さん

• Kiro CLI推し
  • いっぱい登壇している
• Kiroの最近の使い方
  • 4兄弟でシームレスに連携できるようになっている
• Kiro IDEがクラウドセッションが使える
  • Agent Focusから使える
• Kiro Crewが登場した
  • 後々説明する
• 5兄弟の話
  • 2025/07/14にIDEプレビューが出てから色々出ている
  • 8月も頻繁にリリースが続いている
  • 元々Q Developer CLIがあった
  • IDEが出た後、CLIがKiroに変わった
  • WebがでてMobileもでた
  • 一番最近Crewが出ているがセキュリティが重要
• IDEとCLIの関係性
  • 似ているようで似ていない
  • セッションの保存形式が違う
  • 権限設定も違う
  • Web版はPythonでさらにエージェントハーネスが分かれる予定だったけど統一エージェントハーネスになった
  • IDE/CLIは破壊的だったがWeb経由で統一できる
  • 統合前から書き方が変わりpermissions.yaml定義になった
  • Cedarベースになった
  • capabilityが12種類
• Web/Mobileはブラウザから使える
  • Pro以上が必要
  • クラウドサンドボックスがWeb/Mobileから使える
  • サンドボックスを調査した非公式の結果では、EC2/Docker/bwrap/実際のシェルの状態
  • 4core8スレッド、30GiBメモリと結構大きい
  • 連携したリポジトリからクローンして使われる
  • 設定できる項目は少ない
    • Network configuration
      • アクセスレベルは3段階
      • aallow-listで明示的なアクセス先を指定可能
    • Environment variables/Secrets
      • 環境変数
    • AWS Credentials
      • ロールの設定
      • サービスプリンシパルはqのもの
      • WebからのコマンドだけでなくMCPにも同じ権限を渡していく
• Crew
  • OpenClawに触発されつつセキュリティを意識して開発
  • 直接操作も可能、チャットからの指示も可能
  • Crew Gatewayが5476ポートに常駐
  • kiro-cli v2系が実行される
  • 設定ファイルが古いので注意
  • ちょっと脱線
    • GitHubのセキュリティ関連情報が役に立つ
  • Kiro Crew信頼境界の論理構成図
    • 詳しくはスライドを見てね
  • 物理構成図とシーケンス図もあるよ
  • 資料から読み取れないこともまとめたよ
• Crewのセキュリティ基本
  • Plane AとMCP Appsの2経路
  • deny floorとして139件の禁止コマンドリストは作られている
  • security_policy.jsonは自分で作ってガバナンスを確保する必要がある
  • Crewのセキュリティ設定は他のKiroとは全然別物
  • バイパス経路は2つあるので注意
• まとめ
  • Kiro全体では統合途中で色んなパターンがある
  • CLI v3のセキュリティ設定は変わるよ
  • Crewはドキュメントを読んで

感想

Kiro全体でもいろんなことがどんどん変わっています。それぞれのセキュリティも期にしていく必要がありますが、性質上特にKiro Crewではセキュリティについてよく調べてから使い始めたいですね。

Session2: アクセスキー流出時の対応で再認識した攻撃側と防御側の非対称性について JAWS-UG 神戸 kazzpapa3（ICHINO Kazuaki）さん

• 結論: 正しく怖がりましょう
• アクセスキーの流出に対応することがよくあります
  • いくつかの登壇やイベント開催をしている
• 今日は非対称性の話
  • 防御側がいかに大変かにフォーカス
• 被害の全体像
  • 漏れたアクセスキーにはAdministrator Accessが付いていた
  • 不正に作成されたリソースとそれぞれの所要時間
  • 17分でEC2とか色々作られていた
  • 30分後くらいにAWSから緊急通知が届く
  • リソース削除の完了までが10時間くらい
• 対応
  • IAM関連の不審な挙動の調査
  • オプトインされたリージョンすべてで不正利用されたリソースの確認
  • 削除対象リソースの照会
  • 不正構築されたリソースの削除スクリプト作成
  • 削除・確認
• 一覧化と削除が時間がかかる
  • 削除にはID(ARN)が必要
  • リソースの作成は完全に自動化されている
  • しかし削除の場合にはIDを明示的に指定する必要がある
  • つまり一覧化して把握しないといけない
• 依存関係により削除作業に順序が必要
  • 例えばECSはタスク停止、サービス削除、クラスター削除の順序
  • いろんなリソースで全リージョンで対応が必要
  • 正規リソースと不正リソースの選別にも時間がかかる
  • 普段使っていないリージョンであれば判断は簡単だが、使っているリージョンは確認に時間がかかる
• これらの非対称性を整理
  • 攻撃者は自動化している
  • 攻撃の所要時間は17分
  • 防御側は全体の把握と削除対応で7時間半、加えて確認などの待ち時間など
  • 依存関係も防御側は気にしないといけない
  • 判断も攻撃側は迷いなくできる
• 余談
  • コンピュートリソースはAutoScalingGroupから作成される設定になっていた
  • EC2インスタンスを消しても自動で再作成される
• 未知との戦いがしんどい
  • 多くの人にとっては不正利用が始めてとなる
  • 何をされているかわからないことが多い
• 自分が何者か判断がつくと悪用が早い・多様化する
  • AmazonEC2FullAccessが付いていてもEC2インスタンスが急増しなかった例はあった
  • ただIAM権限が付いていなければいいというわけではない
• どう立ち向かうか
  • AWSから届く通知にはやることが書いてある
  • キーをローテーションする、リソースを消すなど
  • 対処の時間はかかるので対処の必要性をそもそも無くそう
• 証拠保全などは今回話していない
  • 実際にはOS以上の調査やデータの漏洩や改ざんなども見ていく必要がある
• AWSのマネージドポリシーも活用できる
  • AWSCompromisedKeyQuarantineV3
  • AWSが付けるがユーザーが使ってはだめとは言われていない
  • リソースの乱立を減らすことに使えそう
  • 根本対応は別途考える必要があるけど暫定的には使える
• 漏れたら困るもの自体が存在しないことが大事
  • aws loginコマンドでローカルから排除
  • OIDC連携でCI/CDから排除
  • IAM Roles Anywhereでオンプレから排除
  • インスタンスプロファイル/タスクロールを活用する
• AWSも進化している
  • 今日IAM roles AnywhereでJava SDK v2の新プラグイン対応した
  • ベストプラクティスも更新される
• 結論
  • 対処の手順は後追いで頑張れる
  • でも時間がかかるし課金は止まらない
  • 結局漏らさないことが大切
  • 漏れたら困るもの自体が存在しないことが大事
  • アクセスキーを使わなくても済むのがいいがせめて最小権限にして

感想

アクセスキーを無くそう！それ以上に適切な管理とセキュリティ対策をしていこう！

Session3: SecurityAgentを使用して自分のサイトにペネトレーションテストを行った結果について いとさんさん

• 今回はAWS Security Agentの他の機能については話さない
• AWS Security Agentについて
  • 設計・コーディング・デプロイを自律検証するフロンティアエージェント
  • つまりそれぞれの段階でのセキュリティテストができる
  • 設計フェーズでは設計ドキュメントをアップロードしてチェック
  • 脅威モデリングもできる
    • STRIDEでの分類を行う
  • 開発フェーズではGitHubと連携してPRごとにセキュリティ基準似合わせてチェック
    • 是正コードも作ってくれる
  • 稼働中のアプリにはペネトレーションテストできる
    • OWASP Top 10ベースでチェックできる
  • 今回はペネトレーションテストについて
  • ペネトレーションテストの料金
    • 1タスクあたり50USD/時
    • 並列で処理がされるので全体の時間ではない
    • 7時間稼働でも合計30タスク時間かかっていたら1500USDということ
    • 2ヶ月の無料トライアル中は毎月最大200タスクアワー無料
  • 分析方法
    • OWASP Top 10から始まってカスタマイズもできる
• ペネトレーションテスト実行概要
  • 調査想定と目的
    • 攻撃シナリオ: 外部攻撃者によるWebアプリへの侵入
  • 対象サイトはWordPress
  • 手順
    • 対象スコープ定義
    • Security Agent有効化
    • テスト設定
    • 実行前の確認
  • 実際の流れ
    • ドメインを選択
      • Route53に登録があればそこからも選べる
    • 選択したドメインがアクセス可能か、所有者であるかなどが確認される
    • VPCの設定などもオプションである
    • ページ内に含まれる外部ドメインや攻撃したくないパスなどを指定する
    • ログインがある場合に認証リソースを登録する
    • 脆弱性が見つかった場合の自動コード修正機能も選択できる
    • 最大タスク時間を設定できる
      • 推奨は30時間
      • これを超える例もあるので制限なしも活用したほうがいい
    • リスクタイプの除外も可能
      • 一度スキャンした後上手く動かなかった場合にここで指定して除外して再実行などにも使える
    • 実行開始
• ペネトレーションテストを行ってみた結果
  • 1回目
    • SSL証明書の期限切れを検知
    • 最初の読み込みができなかった
  • 2回目
    • 途中でWordPressの安全装置が働いてサイトが停止
    • コードインジェクションを除外して再開
  • 3回目
    • 無事完了
    • 途中で壊れてももとに戻せるようにするのが大事
    • 17時間4分で約$850
  • 結果
    • 発見したものの重要度やレベルがサマリででる
    • 詳細な項目がその後並ぶ
    • 今回は沢山出ている
    • レポートも作れる
    • 再現手順やエビデンスも入れられる
    • ただし英語
• 別環境での参考
  • 設計書があると30時間を超える
  • 似たような環境では同じようなスキャン時間
• まとめ
  • カスタム診断ができた
  • 料金が不透明なので見積もりが欲しい
  • レポートが英語なので日本語対応してほしい

感想

料金感は結構気になりますね。日本語対応はよ！

Session4: AWSのログ/アラートの調査をAIで自動化してみた話 株式会社ヤグラ 竹次智優さん

• ヤグラはAIでセキュリティを守るスタートアップ
• いわゆるAI SOCの会社
• 話すこと
  • AIによるログ監視は今後必須になる
  • なぜなら攻撃者がAIを使うから
  • 普遍的な考え方を共有
• 話さないこと
  • 詳細なログ分析
  • AWSのログ監視機能
• AIログ監視/アラート監視
  • AIがいい感じに対応してくれないかなあ
  • 本気で開発している話
  • セキュリティにおけるAI活用でログ監視は効果が高い
    • 人間だと大変だけどAIなら大丈夫
  • CloudTrailのログやアラートを例に見えてきたポイントの話
• 結論
  • 人間がログ調査の時に見る場所はAIにも見えるようにしましょう
  • なぜか、AIに情報を渡す仕組みはどうするかはこれから話す
• 例: CloudTrailでネットワークACL削除のログを見る
  • CloudTrailからいつ、どの権限で、どのIPから、どのネットワークACLを削除したか確認できる
  • でも人間ではそれだけ見るのか？違う
  • 実際に人間が何をするのか、同じ時刻、ユーザー、IP、端末、ID製品やEDRのログなども見る
  • AIログ監視でも一緒
  • 特定の製品のログだけでは足りない
  • 統合ログ監視が大切
  • 今回の例ならEntra ID/Oktaとか、メールやEDR製品があればそれらのログ・イベントも必要
• 実際の構成例
  • 各種ログを一箇所に集めてアラートを出しAIで自動分析させる
  • AWS CloudTrail/Google Workspace/CrowdStrikeなど
• アラート処理例
  • アラート基準の設定
    • ログをアラートに変える必要がある
    • 何を基準にアラートを上げるか設定する
  • アラートに対するAI調査
    • サイバー攻撃に関する知識が必要
    • 何を調査するのか、調査プランを建てて調査できる仕組みが必要
  • 封じ込め
    • EDRに指示して端末の切り離しをするなど、AIにアクションを提案させる
    • 場合によっては対応も自動化
• まとめ
  • セキュリティにおけるAI活用は攻撃者がAIを活用する以上必須
  • ログ監視・封じ込め領域はAI活用の効果が高い
  • とにかくログを1箇所に集めてAIが見れる状態を作ることが大事

感想

AWS外も含めて、一連で見れるとよいですよね。AWSがどういうアプローチになっていくのかも気になります。

Session5: Security JAWS DaysでCTFを提供した時の話 Azara

• CTFはLLMに殺されたと言われていた
  • そもそもCTFの価値って解けることだったのか？
  • イベント設計を考えながらやっていた
  • LLMを持ち込まれても学びが残る設計にできるかを裏テーマにした
• 1問ずつではなく会社を丸ごと作った
  • 架空企業TechVault社
  • 物語形式にして1つずつ解きながら脆弱性や設定ミスがどう関わってくるのか、どう連鎖するのかを学んでもらった
• 上は堅く、下だけわざと脆弱に
  • シナリオ以外に解くためのプラットフォームも展開
  • 楽しんでもらうためにBedrockなど新しいサービスを入れるなどをした
  • 結果問題が33個になった
  • 高いのはAWS利用料ではなく人間の準備
• 設計の3本柱
  • 脆弱性に人と動機を割り当てる
    • 人がどういう事をやったかを裏のストーリーとして用意していた
    • ミスや悪意も設定があった
  • ブラウザ -> curl -> AWS CLIを段階解放して学びのパスを用意する
    • チュートリアルのように最初は簡単に
  • ヒント・クイズ・自動テスト・可視化ですべての人が取り組めるようにしたり
    • ツールの使い方を渡していきながら教訓を入れたり、理解度を確認するためのクイズを入れたりした
    • クイズがあると解いた後も学べる
    • 初心者を落とさない問題ツリーを組み立てていた
    • 前の問題にヒントや関係性があるようにシナリオを組んだ
• 脆弱性をIaCで宣言する
  • 脆弱性を再現できるようにした
  • コードで書くことでレビューや動作確認までAIに見てもらえる
  • 脆弱性や設定ミスを作って終わりではなく、意図した穴以外をガチガチに固めないといけない
  • 明示的に強固にできる
• ダッシュボードも問題も全部LLMと仕様駆動で作った
  • ほとんどコードを書かなかった
  • 都度CloudTrailのロギングも手作業で作ると大変なのでこれもLLMで収集
  • E2Eテストのためのsolverも作った
• 解けることをCIで担保する
  • cdk deployしたあとsolver実行して33問全部取れたか確認する
• 参加者に見える画面
  • Next.js + Hono(Lambda) + DynamoDB
  • 運営側で詰まりを見えるように
  • 誤回答が多かったりヒントがよく開かれている場所を確認できるように
  • 当日AIエージェントで回しながら直した
• わざと脆弱にすると何をしてもよいは違う
  • 基盤になるダッシュボードが破壊されるとイベントが成り立たない
  • 問題が壊れると誰も解けなくなる
  • 課金が沢山発生するとイベントが回せなくなる
• 失敗談
  • EC2のポートを開けていた
    • Lambdaからの経路だけアクセスできるようにした
  • アクセスキーをインターネットに公開
    • AWSは意図を検知しない
• これからAWSでCTFをつくる人へ
  • 専用アカウントに分離して通知も受けられるように
  • 脆弱性はIaCで宣言する
  • 全問自動で解けるsolverを書く
  • 運営ダッシュボードで詰まりをみる
  • 露出させるキーは認証の内側・最小権限・開催期間限定
• Educational CTFは死んでいない
  • LLMでも学びやすくなっている、脱落が減る

感想

非常に楽しいCTFでした！こういった機会を逃さないようにチャレンジしましょう！

Session6: [クラウドZoom相談] 当日のslido & connpassで受付けた質問に回答する枠 Security-JAWS運営メンバー

• 今回は質問なし

まとめ

今回もいろんな話がありましたね。AIに対する話やAIを活用した話はこれからもどんどん出てくるのでキャッチアップしていきましょう！