Splunk Cloud MCP サーバと 生成 AI によるセキュリティ分析の 効率化

Transcript

1. Splunk Cloud MCP サーバと 生成 AI によるセキュリティ分析の 効率化 KINTOテクノロジーズ株式会社 セキュリティ・プライバシー部 クラウドセキュリティグループ 桑原大輔
2. 自己紹介 • 氏名 ： 桑原 大輔（くわはら だいすけ） • 所属 ： KINTOテクノロジーズ株式会社 (KTC) セキュリティ・プライバシー部 クラウドセキュリティグループ 兼 サイバーセキュリティグループ • 業務 ： 主に AWS や Google Cloud などの クラウドレイヤのセキュリティと SOC (Security Operation Center) 担当 • 趣味：モータースポーツ（ジムカーナ）
3. Agenda 1. KTC の環境と Splunk 活用 2. AWS 環境の脅威検知 3. CloudTrail 分析における課題と、生成 AI ＋ Splunk の 連携による分析の高度化 4. 具体的な構成とアーキテクチャ 5. 実践事例と効果測定 6. 課題とまとめ
4. 1. KTC の環境と Splunk 活用
5. SIEM としての Splunk Cloud • KTC では、Splunk Cloud を SIEM（Security Information and Event Management）として 活用し、マルチクラウド環境のセキュリティログを一元管理。 活用シーン 説明 セキュリティログの集約基盤 複数のクラウドプラットフォーム（AWS、Azure、Google Cloud）や各種 SaaS サービス から出力される膨大なセキュリティログを一元的に集約 高度なログ解析 SPL（Search Processing Language）を用いた柔軟かつ強力なログ解析により、 セキュリティインシデントの詳細分析を実施 可視化とトレンド分析 カスタマイズ可能なダッシュボードにより、セキュリティ状況の傾向把握 脅威の相関分析 複数のログソースを相関分析し、潜在的な脅威パターンを特定 アラート通報と対応フロー 検知した脅威を即座にセキュリティチームへ通知し、迅速なインシデント対応を 可能に
6. クラウド環境でのセキュリティ対策 • KTC では、オンプレミス環境を一切保有せず、完全なフルクラウド環境。 • フルクラウド環境においては、境界型セキュリティに加えて、ID・アクセス管理、データ保護、継続的 な監視など、多層的な防御が必要。 • KTC では特に、各クラウドプラットフォームの監査ログを統合的に分析することで、継続的な監視と セキュリティ担保を実現。 取り組み 内容 監査ログの統合管理 AWS CloudTrail、Azure Activity Log、Google Cloud Audit Logs などの監査ログを集約 ID 管理ログの一元化 Microsoft Entra ID（旧Azure AD）のサインインログ、認証ログを統合 横断的なログ分析 複数のクラウドプラットフォームにまたがるユーザー行動を追跡し、異常なアクセス パターンや権限昇格の試みを検知 脅威の総合的判断 単一のログソースでは判断できない高度な脅威を、複数のログソースを 相関分析することで特定 詳細なフォレンジック分析 インシデント発生時には、時系列に沿った詳細な行動履歴を再構築し、根本原因の 特定と影響範囲の調査を実施
7. 2. AWS 環境の脅威検知
8. AWS 環境内のセキュリティ脅威を検知する サービス：Amazon GuardDuty Amazon GuardDuty AWS 環境のログを継続的にモニタリング、分析を行い、 機械学習（ML）を利用して、疑わしいアクティビティ や潜在的な脅威を検出する。 AWS CloudTrail Amazon VPC Flow logs Amazon Route 53 Resolver query logging Amazon GuardDuty Region 基本データソース Amazon EventBridge Amazon SNS Amazon SNS Email Slack Administrator AWS 環境における脅威検知サービス 脅威の判定は、 1. AWS CloudTrail の管理イベント 2. Amazon VPC Flow logs 3. Amazon Route 53 Resolver クエリログ を自動で収集して使用している。
9. KTC における GuardDuty 検知状況 Discovery:IAMUser/AnomalousBehavior Policy:S3/BucketBlockPublicAccessDisabled InitialAccess:IAMUser/AnomalousBehavior Impact:IAMUser/AnomalousBehavior Exfiltration:S3/AnomalousBehavior Discovery:S3/AnomalousBehavior CredentialAccess:IAMUser/AnomalousBehavior Impact:S3/AnomalousBehavior.Write Stealth:IAMUser/CloudTrailLoggingDisabled Policy:IAMUser/RootCredentialUsage Recon:EC2/Portscan Behavior:EC2/NetworkPortUnusual
10. AnomalousBehavior（異常な振る舞い） AnomalousBehavior の特性： • 「通常とは異なる行動パターン」を機械学習により検知 •普段使用しないリージョンからの API 呼び出し •通常と異なる時間帯の大量操作 •初めて使用する API の実行など • 必ずしも悪意のある行動とは限らない • 業務上の正当な作業である可能性も高い
11. ログ分析の必要性 AnomalousBehavior が検知された場合、以下を確認する必要がある。 1. 操作主体の真正性 正規ユーザー本人による操作か（アカウント乗っ取り・不正アクセスの可能性） 2. 操作の正当性と適切性 業務上必要な作業を、適切な権限と承認された手順で実行したか 3. 意図性の確認 意図的な操作か、誤操作や設定ミスによるものか AWS CloudTrail（監査ログ）の詳細な分析が不可欠
12. 3. CloudTrail 分析における課題と、 生成 AI ＋ Splunk の連携による分析の高度化
13. 分析に必要な調査項目（一例） 調査項目 確認内容 操作主体の識別 人間による操作か、プログラム（サービスロール、Lambda、SageMaker 等の AWS サービス）による自動操作か 操作者の特定 IAM ユーザー名の確認 AssumeRole を使用している場合は、sessionContext や assumedRoleId、PrincipalId から実際の操作者を特定 フェデレーション認証の場合は、元の ID プロバイダーのユーザーを特定 アクセス経路の追跡 AWS Management Console、AWS CLI、SDK、どの経路からアクセスしたか SSO 経由か、直接認証か アクセス元の分析 ソースIPアドレスの特定 IPアドレスから国・地域を特定（GeoIP） 組織が管理するIPアドレス範囲からか、外部からか クライアント環境の把握 userAgent フィールドの分析 Management Console 経由の場合：ブラウザの種類とバージョン CLI/SDK 経由の場合：使用ツールとバージョン（例：aws-cli/2.x.x） 行動パターンの比較 過去の操作履歴と比較し、普段と異なる操作がないか GuardDuty で指摘されている点以外にも不審な操作がないか 操作の時系列を追い、一連の行動として不自然な点がないか
14. 現状の分析作業における課題 GuardDuty の検知をトリガーに、アナリストが手動で SPL クエリを作成・実行して CloudTrail ログを調査 作業の煩雑性 • 都度 SPL を書いてクエリを実行する必要がある • 調査項目を絞り込むたびに新たなクエリを作成 • 試行錯誤を繰り返すため、時間がかかる アナリストの 力量依存 • 分析観点の網羅性：どのような視点で調査すべきか • ログ構造の理解：CloudTrail の JSON 構造やフィー ルドの意味を正確に把握 • SPL 記述能力：複雑な条件や集計を適切に表現でき るか • 結果の解釈力：Splunk が返す結果から正しい判断を 下せるか 属人化のリスク • 経験豊富なアナリストに依存 • ナレッジの共有が困難 • 人材育成に時間がかかる 課題点： 現状の作業フロー：
15. 解決策の第一候補：生成 AI との連携 生成 AI と Splunk を連携させた詳細な脅威分析を試行 期待される効果 分析の標準化 • AI が一定の観点で網羅的に分析を実施 • アナリストのスキルレベルによる品質のばらつきを軽減 作業時間の短縮 • SPL の自動生成により、クエリ作成時間を削減 • 複数の調査項目を並行して実行 分析観点の拡充 • 人間が見落としがちな観点も AI が提示 • 過去の類似ケースとの比較分析 ナレッジの蓄積 • AI が生成した SPL や分析ロジックを組織のナレッジとして蓄積 • 人材教育の教材としても活用可能 優先度 高 高 中 低
16. 4. 具体的な構成とアーキテクチャ
17. Splunk Cloud アーキテクチャ AWS Cloud アナリスト アウトプット 出力先 MCP サーバ Splunk Search Head , Indexer Local PC Script Amazon GuardDuty AWS CloudTrail Amazon Q Claude Sonnet 4.5 0. CloudTrailのログをSplunk で保管 1. 脅威検知 (Finding ID) は Slack に通知 2. Finding ID を引数にスクリプト実行 3. 詳細脅威情報の取得 4. 生成 AI で分析、 SPL の作成 5. CloudTrail 分析部分のみ Splunk MCP 連携 6. MCP 経由でクエリ実行 7. 分析結果を出力 8. 分析結果をベース に脅威を判断 Q Developer CLIエージェント MCP（Model Context Protocol） Amazon Q Developer CLI は 2025 年 11 月 17 日に Kiro CLI にリブランドされました
18. アーキテクチャ コンポーネント 詳細 Amazon Q Developer CLI （CLI エージェント機能） サブスクリプション: Pro プラン 基盤モデル: Claude Sonnet 4.5 役割: ユーザーの自然言語による指示を理解し、適切なツールを呼び出して分析を実行 Splunk Cloud サブスクリプション: 標準サブスクリプション 役割: セキュリティログの集約・保管・検索基盤 Splunk Cloud MCP サーバ プロトコル: Model Context Protocol (MCP) 役割: Amazon Q Developer CLI と Splunk Search Head の橋渡し 機能: SPL クエリの実行、結果の取得、Splunk 環境の情報取得 設定方法: 公式ドキュメントを参照 統合制御スクリプト GuardDuty Findings ID を入力として受け取る Amazon Q Developer CLI を呼び出し、分析を指示 分析結果を整形して出力 $19/月・ユーザー ( 2025 年 11 月時点) Amazon Q Developer CLI は 2025 年 11 月 17 日に Kiro CLI にリブランドされました
19. スクリプトでの実装 • 統合制御スクリプトは、GuardDuty Findings ID を起点に、Amazon Q Developer を介して Splunk へ のクエリ実行と結果分析を自動化。 • 各コンポーネント間の連携により、人手を介さずに包括的な脅威分析レポートを生成。 アウトプット（一部）： GuardDuty Findings の詳細情報（JSON 形式） • Finding Type、Severity、リソース情報、検知時刻など 詳細分析レポート（Markdown 形式） • エグゼクティブサマリー（重要な発見、緊急対応の要否判断、推奨アクション） • 脅威の概要と詳細（攻撃手法、時系列分析、影響範囲） • プリンシパル情報（操作者特定、AssumeRole の逆引き、権限情報） • 異常性分析（時間帯・地理的・操作パターン・認証チェーンの異常性） • リスク評価（総合リスクレベル、誤検知の可能性） • 詳細調査結果（ユーザー特定、追加調査項目、フォレンジック手順） • 推奨対応策（緊急度別の対応、具体的な確認コマンド） など 実行された SPL クエリ一覧 • AI が生成・実行した SPL を記録 • クエリ結果は含まない（機密性の観点から） • 後から手動で再実行可能
20. 技術的なポイント Splunk Cloud MCP （Model Context Protocol）サーバの重要性： • 2025 年 7 月頃にリリースされたことで、生成 AI と Splunk の連携が飛躍的に容易になった • これが本ソリューションの実現における最大の技術的ブレークスルー • MCP により、様々な AI クライアント（Amazon Q Developer CLI ( Kiro CLI ) 、Claude Desktop など）が 標準化された方法で Splunk と対話可能に 適用可能な環境： • Splunk Cloud または Splunk Enterprise にログを保管している環境であれば適用可能 • 特に CloudTrail のような構造化ログを大量に保管している環境で効果を発揮 • 既存の Splunk 投資を活かしながら、AI 活用を推進できる
21. [FYI] Splunk MCP サーバの活用サンプル 紹介されているユースケース： 1. セキュリティオペレーション（SOC） "A SOC analyst uses the MCP server to query Splunk for real-time threat intelligence, asking, 'Show me all failed login attempts from external IPs in the last hour.' The AI executes the search and returns a concise report, reducing response time." 2. 分析の自動化 "Analyst asks, 'Identify infrastructure performance anomalies over the past month that I should worry about.' The LLM client, through the MCP server, will direct Machine Learning Toolkit (MLTK) to perform the anomaly detection analysis of CPU, GPU, memory, disk usage, etc. and bring back a summary report." • Splunk 社の公式ブログ（Unlock the Power of Splunk Cloud Platform with the MCP Server）では、 MCP サーバの活用シナリオが紹介されており、ユースケースは参考になる 出典：https://www.splunk.com/en_us/blog/artificial-intelligence/unlock-the-power-of-splunk-cloud-platform-with-the-mcp-server.html
22. 5. 実践事例と効果測定
23. 現在の運用状況 • 実運用環境で使用中 • 効果を検証しながら段階的に適用範囲を拡大 • 様子見フェーズ • 完全な自動化ではなく、アナリストの判断を支援する ツールとして位置づけ
24. KTC での実運用例 シナリオ：GuardDuty が AnomalousBehavior を検知 従来の方法（手動分析） • 所要時間：30 分〜 1 時間 • アナリストが SPL を複数回作成・実行 • 調査観点の漏れが発生する可能性れが 発生する可能性 AI 連携後（半自動分析） • 所要時間：5 分〜 10 分 • Findings ID を入力するだけで包括的な分析レポートを取得 • 標準化された観点で網羅的に調査 • アナリストは結果の評価と最終判断に集中 評価項目 効果 初期分析時間 約 70% 削減 分析観点の網羅性 向上 分析品質 経験の浅いアナリストでも一定品質の分析が可能に
25. 実際の分析レポート例（一部）1/5
26. 実際の分析レポート例（一部）2/5
27. 実際の分析レポート例（一部）3/5
28. 実際の分析レポート例（一部）4/5
29. 実際の分析レポート例（一部）5/5
30. 6. 課題とまとめ
31. 現在の課題 ① 生成 AI への権限委譲とアクセス制御 ② 生成 AI による分析の精度と信頼性 ③ Splunk MCP サーバの SAML 認証未対応 ④ Amazon Q Developer CLI のコンテキストウィンドウ制限
32. ①生成 AI への権限委譲とアクセス制御 生成 AI が自律的に SPL を生成・実行する仕組み上、以下の課題が存在： • AI の動作を信頼せざるを得ない構造となっている • プロンプトや制約条件である程度の制限は可能だが、実行されるクエリの詳細を事前に完全にコントロール することは困難 • 意図しない範囲のデータへのアクセスや、想定外のクエリ実行のリスクが存在 Splunk 側の権限 管理における 注意点 • MCP 接続用の Splunk ユーザーには最小限の権限のみを付与する必要があるが、 分析の柔軟性確保とのバランスが難しい • インデックスレベル、ロールベースでのアクセス制御を適切に設計し、機密性の 高いログへの不要なアクセスを防ぐ必要がある • 定期的な権限の見直しと、実行されたクエリの監査ログ確認が重要 • 現在、Amazon Q Developer 側で SPL クエリのログを保存し、事後的に監査可能な体制を 構築済み
33. ②生成 AI による分析の精度と信頼性 生成 AI を活用した分析には、以下の制約がある： 1. SPL 生成の不確実性: 意図しない SPL を生成するケースがあり、生成された SPL の妥当性を人間が確認する必要がある 2. ハルシネーションのリスク: 生成 AI にはハルシネーション（幻覚）やミスインフォメーション（誤情報）が存在する 3. 利用範囲の制限: 生成されたレポートは参考情報として扱い、法的証拠やコンプライアンス監査の エビデンスとしては使用できない 4. 人間の判断が必須: 最終的な判断は必ず人間のアナリストが実施し、AI はあくまで作業効率化ツールとしての位置づけ
34. 誤情報の例 1/2 操作者の特定を誤ったケース • 同じ時間帯 • 同じIPアドレス • 同じ権限に昇格 プロンプトを修正し、再度分析した結果
35. 誤情報の例 2/2 操作者の特定を誤ったケース • 同じ時間帯 • 同じIPアドレス • 同じ権限に昇格 プロンプトを修正し、再度分析した結果
36. ③Splunk MCP サーバの SAML 認証未対応 • 2025 年 10 月時点では、MCP サーバは SAML ユーザーに対応していない • MCP 接続用に個別のユーザーを作成してトークンを払い出す必要があり、 セキュリティポリシー上の懸念がある • 今後の Splunk MCP サーバのアップデートで SAML 認証対応を期待
37. ④Amazon Q Developer CLI の コンテキストウィンドウ制限 Amazon Q Developer CLI は反復的に SPL を生成・実行するが、この過程で以下の制約がある： • 生成された SPL、Splunk から返される結果データ、分析内容のすべてがコンテキストウィン ドウ（生成 AI が一度に処理できる情報量の上限）を消費 • 特に大量のログ結果が返される場合、結果データ自体が大きなトークンを消費し、反復処理で さらに蓄積 • 複雑な分析では、コンテキスト制限に達すると新しいセッションを開始する必要がある 影響 • 長時間の分析セッションでは応答の関連性が低下する可能性 • 大規模なログデータを扱う場合、分析の途中で中断が必要になる場合が ある Amazon Q Developer CLI は 2025 年 11 月 17 日に Kiro CLI にリブランドされました
38. 今後の取り組み ① 生成 AI への権限委譲とアクセス制御 ② 生成 AI による分析の精度と信頼性 ③ Splunk MCP サーバの SAML 認証未対応 ④ Amazon Q Developer CLI のコンテキスト ウィンドウ制限 課題 今後の取り組み ① 権限制御の強化、エージェント機能の導入 ② 分析精度の向上 ③ 認証方式の改善
39. 今後の取り組み 項目 ① 権限制御の強化、 エージェント機能の導入 ② 分析精度の向上 ③ 認証方式の改善 • Amazon Q Developer CLI のカスタムエージェント機能の導入検討 • JSON 設定ファイルで使用可能なツール、事前承認するツール、動作パラメータを定義 • 特定のクエリパターンのみ許可、機密インデックスへのアクセス制限、 読み取り専用操作への限定 • 生成 AI への指示文（プロンプト）の精度向上 • 特定のインデックスや機密データへのアクセスを制限した Splunk ロールの導入 • SPL 品質管理の強化 • よく使うクエリパターンのテンプレート化 • SPL 生成プロンプトの継続的な改善 • 分析結果の検証プロセス確立 • 生成された SPL と分析結果の検証プロセスの体系化・標準化 • 誤検知・見逃しのパターン分析とフィードバック • Splunk MCP サーバの SAML 認証対応版のリリース待ちと即座の移行準備 • 個別ユーザーアカウントの削減計画 • より安全な認証方式への移行 内容
40. 本取り組みのポイント 1. Splunk Cloud MCP サーバの登場 2025 年 7 月のリリースにより、生成 AI と Splunk の連携が現実的に 2. 既存資産の活用 Splunk にログを保管している環境であれば、追加投資を最小限に導入可能 3. 段階的な適用 完全自動化ではなく、人間の判断を支援するツールとして位置づけ 4. 実運用での検証 実際のセキュリティオペレーションで効果を確認しながら改善