Security-JAWS 第40回レポート #secjaws #secjaws40 #jawsug #サイバーセキュリティは全員参加
Security-JAWS 第40回のレポートです。
2026.02.12
こんにちは、臼田です。
Security JAWS 第40回が開催されましたのでレポートします。
Security-JAWS【第40回】 2026年2月12日(木) #サイバーセキュリティは全員参加 - connpass
動画
のちほど
レポート
Session1: サイバーセキュリティ月間＋新たな法律、新たな体制、新たな戦略のご紹介 国家サイバー統括室 総括戦略ユニット 戦略企画班 上席サイバーセキュリティ分析官 中山 翔太さん
- 新たな法律・新たな体制・新たな戦略について紹介する
- 中山さんは以前はリーガルの対応などを行っていた
- サイバーセキュリティ月間とは
- 毎年2/1から3/18(サイバーの日)まで
- 今年で16回目
- 「サイバーはひとごとじゃない」が今回のテーマ
- 鈴木福さんが普及啓発にご協力いただけている
- 特設サイトがあります
- 全国各地で行われているイベントについても掲載されているのでぜひチェックしてみてほしい
- 2/2にリアルイベントがあって鈴木福さんとミャクミャクが登場した
- 最近のサイバー攻撃・サイバー犯罪
- ランサムウェアやフィッシングや不正送金が多い
- 2025年5月にサイバー対策強化に向けた政策
- サイバー対処能力強化法及び関連整備法が整備された
- 官民連携・通信情報の利用・アクセス無害化
- 3つの能動的サイバー防御を実現する
- 2025年7月に政府の体制が強化された
- 内閣総理大臣を長にした体制に強化
- もともとNISCだったのがNCOとなった
- 2025年12月に新たなサイバーセキュリティ戦略
- 国家安全保障戦略及びサイバー対処能力強化法等に基づく取り組み
- 世界水準に引き上げる
- ベンダー・中小企業等を含めたサプライチェーン全体のサイバーセキュリティ及びレジリエンスの確保が施策の中で注目する内容の1つ
- 政府は人材フレームワークを整備して演習訓練を充実させていく
- 好循環のエコシステムを形成する
- AIにかかる安全確保を行う
- まとめ
- サイバーセキュリティ対策推進が本格化している
- これまで以上に国が積極的に関与していくが、協力連携が必要
- 社会全体のサイバーセキュリティを底上げしていくために、国民一人ひとりの意識や理解を深めていく必要がある
- 政府だけでは限界があるのでセキュリティの専門家である皆様が啓蒙していくことが必要
- つまり「
#サイバーセキュリティは全員参加」のハッシュタグを付けていっぱいつぶやこう！
感想
みんないっぱいつぶやこうね！
Session2: re:Inventに見る生成AIで進化するセキュリティ対策 Amazon Web Service Japan Senior Security Solutions Architect 保里 善太さん
- re:Invent 2025で発表された代表的なサービス
- AI SecurityだとAWS Security Agentがプレビューででた
- AWS Security Hubが一般提供開始
- IAM Policy Autopilotも登場した
- AIのポートフォリオが増えている
- AWS Security Agentはフロンティアエージェントとして3つのサービスが出たうちの1つ
- フロンティアエージェントとは
- 有用性の高いエージェントを3つに整理した
- Kiro Autonomous AgentやAWS DevOps Agentもある
- 今回はこれらの話というより今後どうなるのかの話をしていく
- アプリケーションエージェントが重要
- Kiro / Q Developerもある
- Q Developer
- これは開発者向けだけではない
- SDLC全体の体験を再構築している
- KiroはAI IDE
- ゲームを作ってくれというと作ってくれる
- 自然言語で指示すればできる
- AIエージェントは開発だけではなく運用もモダナイズする
- 手動運用時はAWSのコマンドやサービスの知識が必要
- AIエージェント時代は自然言語で要件を伝えるだけ
- コマンドの知識は不要
- 運用に使える！
- AWSのビジョンはセキュリティのモダナイゼーション
- AI Operations
- AIOpsを発展させていこうとしている
- 生成AIを活用したセキュリティオペレーションの効率化
- AIエージェント型開発ができるようになった
- 運用も同じように要件を伝えて実現する
- AIエージェントが答える最適設計
- 高トラフィックに耐えられるセキュアでコスト効率の良いWebアプリを作りたい
- デプロイしてくれといえばデプロイもしてくれる
- トラブルシュートもできるしインシデント対応もできる
- NIST CSFのどこで生成AIが使えるのか？
- 5つのコアすべてでAIエージェントによって効率化できる
- IdentifyではConfig Rulesでドリフト検出やIAMポリシーの最小権限チェック
- 生成AIによるインシデント対応、コンプライアンス、監査を加速するワークショップがある
- AWS Security Agent入門ワークショップもある
- ProtectではWAFルールチューニングやIAM Access Analyzerの分析ができる
- DetectではSecurity HubやGuardDutyのアラートを分析させたり修正提案させられる
- 次世代SOCのワークショップもある
- AWS DevOps AgentでECSトラブルシュートのワークショップがある
- Respond & Recoverではインシデント対応手順提案や封じ込め戦略の提案
- 提案だけではなくそのまま実行させてインフラ修正もできる
- ただ修正は慎重に行うべきなので人が承認したほうがいい
- Kiroで攻撃の分析対応をするワークショップもある
- 気をつけるのはHuman-in-the-Loop
- 確実性が必要な部分には決定論的処理を要求仕様
- 生成AIの確率論的な動作に頼らないようにRunbookを生成AIに作らせたあと確認して実行するなど
- 実装例
- 分析層にKiroやQ Developer
- 判断は必ず人が行う
- 実行は確実性を求める場合にはSystems ManagerやLambdaなどのRunbook
- 挑戦的な環境ではKiroに直接やらせてもよい
感想
生成AIにやってもらえることが増えていますが、セキュリティ対策で扱う場合でも様々な活用方法がありますね。ワークショップもたくさんありますから触って体験していきましょう！
Session3: 猫でもわかるKiro CLI(セキュリティ編) NTTテクノクロス株式会社 IOWNデジタルツインプラットフォーム事業部 加藤 洋雄さん
- Kiro CLI(旧Amazon Q Developer CLI)についてこれまで触っていて話してきていた
- 今回はその続編なので以前の話もぜひ見てください(詳しくはQiita)
- 話すこと
- AWS開発におけるKiro CLIの適用事例
- 知っておいてほしいこと
- 基本的なAgentの作成例、レビュー結果
- お詫びその1
- 全身のQ CLIはOSSで公開されていたが、Kiro CLIになってクローズドになってソースを見ながら解説できなくなった
- その2
- Kiro CLIでhelp Agentが実行された(すごく便利
- セキュリティ設定は/helpコマンドで調べて設定指示すればよくなった
- すごい
- というわけでKiro CLI自体の説明を多めにしています
- 持ち帰ってほしいこと
- Context Windowの仕組み
- Plan Agentの偉大さ
- みんなKiro CLI使ってる？
- 最新の1.25.0でもいろんな機能が追加されている
- Kiro CLIの更新履歴
- 1.23.0のPlan Agentと1.24のSkillsが注目機能
- 小西さんのZennでの発信もわかりやすいので見て
- 利用実績
- 業務で半年ぐらい使っている
- 最初はAzureからAWSへの移行で使った
- 過去案件と比べると半分くらいの稼働で設計構築できた
- Strandsを使ったAIエージェント開発を行った
- 社外SIでも活用し始めた
- AWS初学者への導入をした
- もともとオンプレの開発経験がある人がKiro CLIが無くてはならないとなった
- 要件定義や基本設計はKiroに書かせてレビューは人で
- コードを書くのもKiroでレビュー
- レビューが人の仕事のメインになってきている
- 書かせるコードも可読性が大事
- 誤解を恐れずにいうとClaude Code ≒ Kiroともいえる
- モデルが同じであるのでノウハウを活用できる
- 既存の情報を活用しよう
- Kiro CLIがAWS開発に向いている
- CDKが大得意
- IaCなので複雑なロジックは必要とされない
- 特許を気にしなくて良い
- AWS環境の調査ができて実践の活用もしやすい
- ドキュメント作成も任せられる
- Kiro CLIを使うための基礎知識
- Context Windowについて資料をまとめているので見てね
- とりあえずLLMのなかで覚えられるサイズの上限があると覚えればよい
- /contextを叩くと確認できる
- 使用量が増えるとconpactionされる
- usageの可視化をしておくとよい
- 上手な使い方も資料を読んでね
- Kiro CLIに考えさせよう
- planモードがある
- 書かせずに考えさせるモード
- 書き込み権限が無いモードでとにかく考えさせる
- 調査不足による低品質コード生成を防止できる
- お金があるならハイエンドモデルを使うのも手
- Opus4.6がでた
- お金で時間が買えます
- Sonnet4.5とOpus4.6はめちゃくちゃちがう(体験談
- エージェントを作ってみよう
- Kiro CLI自身に設定させてみる
- 最小構成のAgentを作成
- ファイル書き込み権限を追加
- 無制限に書かれると嫌なのでパスを絞る
- プロンプトを外部ファイル化
- 幸せになれる
- AWS MCP Serversを追加
- AWSのドキュメントにアクセスしたりいろいろできる
- ファイル保存ルールを追加
- ツール仕様のログを追加
- 出力フォーマットと図解を追加
- レビュー結果として確認したい出力フォーマットを指定する
- 図解するとわかりやすいのでおすすめ
- セルフレビュー機能を追加
- 想像で書くことが多いのでレビューさせるとよい
- この完成版は資料にあるので見てね
- 実際にやってみた
- CloudWatch Logsのワイルドカード指定をやめようと指摘される
- リスクと対策も出てくる
- 権限やポリシーの指摘などもしてくれる
- 参照すべきドキュメントURLも付けてくれる
- まとめ
- Context Windowの状態をいつも意識しよう
- Plan Agentで深く考えさせよう
- 自分専用のAgentを作ろう
感想
生成AIと一緒に開発をするのも非常に現実的になりましたね。参考になるアプローチなのでぜひ真似してみてください
Session4: 脱PPAP対策mxHEROとAWSについて mxHERO, Inc. APAC事業開発マネージャー 上田さん
- mxHEROとは
- 2012年設立
- PPAP対策のMail2Cloudという製品を展開している
- mxHEROがどういうプロダクトなのかはブログも参照して
- メールから添付ファイルを剥がしてクラウドストレージに保存する
- 添付がリンクに置き換わる
- 簡単にセットアップができるのが特徴
- AWS hostの場合のアーキテクチャ
- KubernetesでマルチAZ展開できる
- アクセス制御が厳しくされている
- DoS耐性などもある
- セキュリティの観点
- メールコンテンツを非保持としている
- 一時的な処理のみ
- E2E暗号化
- データは顧客環境に置く
- 顧客利用のBoxなどに依存する
- アイデンティティとアクセス制御
- 監査対応
- SOC 2 TypeⅡ準拠
- メールコンテンツを非保持としている
- AWS上でどのようにセキュリティを確保しているか
- EC2を利用している
- SESはメール通知の送信にのみ利用している
- S3を利用している
- KMSでAWS Managed Keyを利用している
- ログはS3に保存、分析はAmazon Athena利用
- 障害の対応
- mxHEROの障害の場合で受信できて配送できなかったものはS3に補完されているので戻り次第再送する
- クラウドストレージ障害の場合には40分リトライして最終的に送信者に戻される
- 受信側のメールサービスがメールを受信できなかった場合は最大24時間キューしてバウンスする
- Roadmap
- 2026年3月にAWSの日本リージョンを選択できる予定
感想
利用者の体験を損なわないで添付ファイルを分離できるソリューションであるmxHEROをチェックしてみてください
Session5: 1,000 にも届く AWS Organizations 組織のポリシー運用をちゃんとしたい、という話 kazzpapa3（ICHINO Kazuaki）さん
- みなさん、ポリシーの管理してますか？
- 大まかな背景
- リセールアカウントの提供仕様を管理する部門の仕事もしている
- 細かい差分でポリシーが乱立する
- 共通する部分のアップデートが必要だがたいへん
- 差分が生まれる背景
- リセラー提供の場合にはAWS OrganizationsやAWS Control Towerが使えないイメージがあるかもだけどそうでもないこともある
- ただ管理のために色々差分が生まれていく
- 今回の前提
- マサカリは怖いけどアドバイス大歓迎
- 差分の例
- お客様のサポートケース起票はしてほしくないけど一部OKにしていることもある
- メンバーアカウントのroot管理がお客様の時もある
- でも組織離脱は禁止している
- IAMでもSCPでもいろいろ差分がある
- 1,000近い管理アカウント
- 全部がバラバラではないけど数パターン乱立している
- パーツ化したりモジュール化して組み合わせるやり方をしたい
- CDKとかでIaCしてみる？
- PolicyStatementを関数やクラスで部品化する？
- 共通はjsonで差分だけコード？
- IaCを使わない方法ができないか生成AIと相談
- やってみた
- ポリシーはYAMLで書く
support: *をDenyと許容するバージョンを用意- yqコマンドでくっつけてみている
- くっつけたらjson化
- accessanalyzerのvalidate-policyでポリシードキュメントとしての評価を行う
- ポリシーはYAMLで書く
- やってみた感想
- パーツ化の手応えはある
- パーツごとcommitできる
- yamlにしたのでコメントを書けるようになった
- おわりに
- IaCを使わないことを前提としたもののCFnなどを使いたくないわけではない
- もっと良いやり方があるんじゃない、などお話できたら嬉しい
感想
環境ごとのポリシーの調整はホント難しい課題ですなー。json/yaml問題も根本的な解決の見込みが無いのが困りごとですね。わいわい意見を出してみましょう
Session6: ドコモCCoEがAWS Step Functionsで実現した大規模ログ統合基盤 ドコモ・テクノロジ株式会社 サービスインテグレーション事業部 神崎 由紀さん
- NTTドコモCCoEのログ管理の話
- CCoEの業務
- ドコモブループ全体に提供している
- 社内コミュニティなどもある
- 共通基盤の取り組み
- 世間で広く利用されているクラウドサービスをドコモグループ全体へ提供
- のべ9万人のユーザーが利用
- そのセキュリティなどについて話していく
- CCoEの役割とログ管理の課題
- 一番利用が多いSlackの場合アクティブユーザー46,000人、ワークスペース480、チャンネルは163,000以上など規模が大きい
- 属人的な対応でログ抽出が不十分
- ルールが曖昧、安全性・透明性が欠如している
- 課題解決のアプローチ
- ガイドライン作成で基準を統一
- 多重承認フローで透明性と安全性を担保
- サーバレスアーキテクチャの採用
- 完全自動化により16万チャンネル規模のログも安定収集
- ログ管理のルール策定
- ログ抽出の基本方針
- 各プロジェクトで抽出できる情報は各プロジェクトで
- ガバナンスが求められる案件のみCCoEで対応
- 削除された情報やプライベートなDMなど
- インシデントやコンプライアンスに関わるもののみ
- プライバシー保護と透明性担保の承認フロー
- 依頼は情報セキュリティ部門への報告と事前承認が必要
- インシデントなら管理職からCCoEに依頼
- コンプライアンスならリスク・コンプライアンスのリーダーがCCoEに依頼
- CCoE管理職が受け付けて組織内で承認
- 承認後担当者が抽出するが依頼者と作業者を分離
- ログ抽出の基本方針
- アーキテクチャと実装
- Slackは監査用のAPIで日次収集
- S3に保存
- CloudTrailでアクセスログ取得なども行っている
- EventBridgeからStep Functionsを実行してLambdaでAPI呼び出し
- 分析はAthena
- Step Functionsを使っているのは並列実行のため
- 多数のチャンネルがあるため
- 長時間処理を安定化させるため
- 疎結合にする
- 再利用性や拡張性
- 他の対象ログでも使いまわしができる
- 分散マップで並列処理
- Slackだけ採用している
- 処理が多すぎる
- 実行履歴25,000イベントの制約があるが親フローの履歴が消費されない
- S3を活用したワークフロー設計のコツ
- 途中で失敗したりレートリミットもあるので進捗をS3に保存している
- 対象リストもS3に
- エラーログもS3に入れている
- Athenaによる分析基盤
- 毎日見るわけではないのでAthenaで足りる
- 年月日でパーティション射影
- クエリパターンはテンプレート化
- Slackは監査用のAPIで日次収集
- 1日のログ収集量
- 1.3GBメッセージログなど
- 安定して収集できている
- AWS利用料
- 金額は出せないがStep Functionsが6割を占める
- びっくりするような金額ではない
- 導入効果
- 処理能力向上
- 運用プロセスの効率化
- ガバナンスの強化
- 今後の展望
- 収集基盤の確立
- 他の基盤への展開
- 統合分析基盤の構築
感想
しっかりしている話でした。AWS設計もそうですが、業務の設計が大事だなということがわかる内容でしたね。みなさん、業務設計をしっかりやりましょう！
