以下の内容はhttps://blog.g-gen.co.jp/entry/using-secops-remote-mcp-serverより取得しました。

Google SecOps MCP serverを使ってみた

Google SecOps Google Cloud MCP Servers Gemini CLI 生成AI (Generative AI) セキュリティ Google Cloud
記事タイトルとURLをコピーする

G-gen の三浦です。当記事では、Gemini CLI から Google SecOps MCP server を使用して、ケース確認からログ調査までを自然言語で要約した検証結果を紹介します。

前提知識

Google SecOps とは

Google Security Operations（以下 Google SecOps、旧称 Chronicle）は、Google Cloud が提供する統合セキュリティ運用プラットフォームです。

SIEM、SOAR、脅威インテリジェンス、Gemini を利用した AI による運用支援を提供します。これらにより、脅威の検知・調査・対応を一元的に行えます。結果として、セキュリティ運用の効率化と高度化を実現できます。

詳細は、以下の記事をご参照ください。

blog.g-gen.co.jp

Gemini CLI とは

Gemini CLI とは、ターミナルから直接 Gemini の機能を利用できるオープンソースのコマンドラインインターフェイスです。詳細は以下の記事をご参照ください。

blog.g-gen.co.jp

概要

Google SecOps MCP server とは

Google SecOps MCP server は、Google Cloud が提供する Google Cloud MCP Servers の 1 つです。Gemini CLI などの MCP クライアントから、自然言語で Google SecOps を操作することができます。

なお Google Cloud MCP Servers では、Google SecOps の他にも、Compute Engine や Google Kubernetes Engine（GKE）、Google Maps などのための MCP サーバーが提供されています。

Google Cloud MCP Servers の詳細は、以下の記事や公式ドキュメントを参照してください。

blog.g-gen.co.jp

使用可能なツール

Google SecOps MCP server で使用可能な主なツールとユースケースは以下のとおりです。以下は一部抜粋であり、他にも多数のツールがあります。詳細は公式ドキュメントをご確認ください。

カテゴリ ツール ユースケース
ケース運用 list_cases, get_case, update_case 未対応ケースの棚卸し、ケース詳細の確認、担当者の更新
検索・調査 translate_udm_query, udm_search, search_entity 検索条件（UDM クエリ）の作成・変換を行い、ログ/イベントを検索して、関連するユーザー/端末/IP などのエンティティを特定
ルール運用 create_rule, list_rules, list_rule_errors 検知ルールの作成と棚卸し、適用・運用上のエラーの把握
取り込み/整備 create_feed, create_parser, list_parsers ログ取り込み設定（フィード）の作成、ログ整形のためのパーサー作成、パーサーの一覧取得

注意点

Google SecOps MCP server は、2026年2月現在、Preview 版です。当記事で解説する内容は一般提供（GA）の際に変更される可能性があることを予めご了承ください。

Preview 版のサービスや機能を使うに当たっての注意点は、以下の記事も参考にしてください。

blog.g-gen.co.jp

検証手順

検証の流れは以下のとおりです。

項番 項目 内容
1 事前準備 MCP サーバーの有効化、IAM 権限の付与、Customer ID の確認、Gemini CLI の設定
2 ケース運用 未対応ケースの一覧取得、高優先度ケースの確認、関連アラートと 関与したユーザー／IP の確認
3 検索・調査 ケース／アラートで得たユーザーや IP などの手がかりを起点に、Google SecOps に取り込まれたログ（例：Google Workspace / AWS）を検索し、重要な操作を時系列で整理

事前準備

IAM 権限の付与と MCP サーバーの有効化

Google SecOps MCP を実行するプリンシパル（Google アカウント/サービスアカウント）に、SecOps インスタンスが紐付くプロジェクトで以下の IAM ロールを付与します。

  • MCP ツールのユーザー（ベータ版）（roles/mcp.toolUser）
  • Chronicle API 管理者（roles/chronicle.admin）
  • Chronicle SOAR 管理者（ベータ版）（roles/chronicle.soarAdmin）

※roles/chronicle.admin と roles/chronicle.soarAdmin は管理者権限相当です。SecOps 運用に必要なメンバーのみに付与することを推奨します。

SecOps インスタンスが紐付くプロジェクトで、Google SecOps MCP を有効化します。

# SecOps が紐付くプロジェクト ID
export PROJECT_ID="YOUR_PROJECT_ID"
　
gcloud beta services mcp enable chronicle.googleapis.com --project="$PROJECT_ID"

※ gcloud beta services mcp コマンドが「Invalid choice: 'mcp'」等のエラーで使用できない場合は、gcloud CLI が古い可能性があります。最新バージョンに更新してから再試行してください。

MCP サーバーを利用できるアカウントでログインし、アプリケーションのデフォルト認証情報（ADC）を設定します。

gcloud auth application-default login

Customer ID の確認

本記事で利用する MCP ツールには、Google SecOps の Customer ID が必要なものがあります。Customer ID は Google SecOps コンソールの設定画面から確認できます。

確認手順の詳細は、以下の記事の 「Google SecOps 転送用のパラメータと認証情報の取得」 をご参照ください。

blog.g-gen.co.jp

Gemini CLI の設定

Google（Google Cloud）のリモート MCP サーバーは、Gemini CLI では拡張機能として ~/.gemini/extensions/ 配下に設定します。本記事では拡張機能名を secops（任意）とします。

設定用のディレクトリと設定ファイル（~/.gemini/extensions/secops/gemini-extension.json）を作成します。

mkdir -p ~/.gemini/extensions/secops
　
touch ~/.gemini/extensions/secops/gemini-extension.json

作成した設定ファイルに以下を記述します。PROJECT_ID と httpUrl のリージョン（例：asia-northeast1）は環境に合わせて置き換えてください。

{
  "name": "secops",
  "version": "1.0.0",
  "mcpServers": {
    "secops": {
      "httpUrl": "https://chronicle.asia-northeast1.rep.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": {
        "scopes": ["https://www.googleapis.com/auth/chronicle"]
      },
      "headers": {
        "x-goog-user-project": "PROJECT_ID"
      }
    }
  }
}

Gemini CLI を起動し、/mcp コマンドで MCP サーバーへの接続を確認します。ツール一覧が表示されれば、接続は成功です。

> /mcp
Configured MCP servers:
　
🟢 secops (from secops) - Ready (57 tools)
  Tools:
  - list_cases
  - get_case
  - list_case_alerts
  - list_case_comments
  - update_case
  ...（省略）

ケース運用

未対応のケース一覧の取得

以下のようなプロンプトで未対応（OPENED）のケースを直近 10 件取得し、優先度と作成日時の傾向を確認します。

Project ID PROJECT_ID、Customer ID CUSTOMER_ID、Region REGION を使用して 未対応のケースを作成日時の新しい順に 10 件表示してください。

# 出力例
　
✦ 最新の未対応ケース 10 件を取得しました。
　
　
  ┌─────────┬──────────────────────────────────────────┬──────────┬────────┬────────┬────────────────────┐
  │ Case ID │ Display Name                             │ Priority │ Stage  │ Status │ Created Time (UTC) │
  ├─────────┼──────────────────────────────────────────┼──────────┼────────┼────────┼────────────────────┤
  │ 399     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-30 09:33   │
  │ 398     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-30 01:33   │
  │ 397     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-29 19:33   │
  │ 396     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-29 13:33   │
  │ 395     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-29 07:34   │
  │ 394     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-28 23:34   │
  │ 393     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-28 15:34   │
  │ 392     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-28 11:33   │
  │ 391     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-28 05:34   │
  │ 390     │ Replacement of Existing Compute Snapshot │ LOW      │ Triage │ OPENED │ 2026-01-27 23:34   │
  └─────────┴──────────────────────────────────────────┴──────────┴────────┴────────┴────────────────────┘
　
　
  すべてのケースが Replacement of Existing Compute Snapshot（既存のスナップショットの置換）という名称で、優先度は LOW です。

高優先度ケースの抽出と要約

以下のようなプロンプトで優先度が高いケースを抽出し、内容を要約して「先に見るべきケース」を絞り込みます。

Project ID PROJECT_ID、Customer ID CUSTOMER_ID、Region REGION を使用して、優先度が高いケースを検索し、最新の3件の内容を要約してください。

# 出力例
　
✦ 優先度が高いケースの最新3件を取得し、要約しました。
　
  高優先度ケースの要約（最新3件）
　
  検出されたケースはすべて、Workspace 管理者による 2要素認証（2FA）の強制設定解除に関するもので、内容は以下の通りです。
　
   1. Two Factor Authentication Enforcement Removal by a Workspace Admin User (Case ID: 137)
       * 優先度: PRIORITY_HIGH
       * 作成日時: 2025/11/27 19:06:23 (UTC)
       * 概要: 管理者ユーザーによって 2要素認証の強制設定が解除されました。セキュリティポリシー違反の可能性があるため、意図した変更か確認が必要です。
　
   2. Two Factor Authentication Enforcement Removal by a Workspace Admin User (Case ID: 135)
       * 優先度: PRIORITY_HIGH
       * 作成日時: 2025/11/27 10:18:07 (UTC)
       * 概要: 管理者による 2FA 強制解除が検知されました。アラートが 2件紐付いており、繰り返しのアクションや関連操作があった可能性があります。
　
   3. Two Factor Authentication Enforcement Removal by a Workspace Admin User (Case ID: 131)
       * 優先度: PRIORITY_HIGH
       * 作成日時: 2025/11/26 13:33:44 (UTC)
       * 概要: 同様の 2FA 解除検知です。短期間に複数発生しているため、アカウント侵害や誤設定の影響範囲を確認してください。
　
  管理者権限に関わる重要な変更であるため、早急な確認を推奨します。

関連アラートの確認と影響範囲の確認

以下のようなプロンプトで、前項で確認した Case ID 137 に紐づくアラートを取得し、「誰が／どこから／何に対して」の観点で影響対象を整理します。

Project ID PROJECT_ID、Customer ID CUSTOMER_ID、Region REGION を使用して、Case ID 137 に関連するアラートを取得し、影響対象と影響範囲を整理してください。

# 出力例
　
✦ Case ID 137に関連するアラート情報、および影響対象と影響範囲を整理しました。
　
  1. ケース概要
   * Case ID: 137
   * ケース名: Two Factor Authentication Enforcement Removal by a Workspace Admin User
   * 優先度: HIGH
   * ステータス: OPENED
　
  2. 関連アラート
   * アラート名: TWO FACTOR AUTHENTICATION ENFORCEMENT REMOVAL BY A WORKSPACE ADMIN USER
   * 発生日時: 2025-11-26 10:03:52 UTC (1764151432245)
   * 内容: Workspace管理者権限を持つユーザーによって、二要素認証（2FA）の強制設定が解除されました。
　
  3. 影響対象と関与エンティティ
  アラートに関連するエンティティ情報から、以下の事実が確認されました。
　
   * 実行ユーザー (Principal):
       * EXAMPLE@DEV.G-GEN.CO.JP
   * 接続元IPアドレス:
       * 0000:0000:0000:0000:0000:0000:0000:0000 (IPv6)
   * 変更対象リソース (Target):
       * ORGANIZATIONS/1234567890/SECURITYSETTINGS
       * 組織レベルのセキュリティ設定オブジェクトです。
　
  4. 影響範囲の整理
  このアラートは、特定のユーザーに対する操作ではなく、組織レベルのセキュリティ設定に対する変更を示唆しています。
　
   * 直接的な影響: 組織ID 1234567890 （DEV.G-GEN.CO.JP 組織全体、または該当する組織部門）において、二要素認証の強制ポリシーが無効化された可能性があります。
   * セキュリティリスク:
     2FA強制が解除されると、組織内のユーザーアカウントがパスワード漏洩などの攻撃に対して脆弱になります。全ユーザー、または特定の組織部門（OU）配下の全ユーザーが影響を受ける可能性があります。
　
  推奨される次のステップ:
   * 実行ユーザー (EXAMPLE@DEV.G-GEN.CO.JP) に連絡を取り、この設定変更が意図的かつ承認されたものか確認してください。
   * 意図しない変更であれば、直ちに設定を元に戻し、該当ユーザーのアカウントが侵害されていないか調査する必要があります。

検索・調査

特定ユーザーの Google Workspace 操作ログ調査

以下のようなプロンプトで前項で確認した Case ID 137 に関連する特定ユーザーの Google Workspace 操作ログの抽出と整理を実施します。

Project ID PROJECT_ID、Customer ID CUSTOMER_ID、Region REGION を使用して、Case ID 137 で特定した関与ユーザー EXAMPLE@DEV.G-GEN.CO.JP（接続元 IP：0000:0000:0000:0000:0000:0000:0000:0000） が 2025-11-27（UTC） に行った操作をログから抽出し、重要な操作を時系列で整理してください。

※ メールアドレスでヒットしない場合は、ケースで得たユーザーID（@ 前）や接続元 IP で再検索します。

# 出力例
　
✦ 指定された条件（Case ID 137、ユーザー EXAMPLE@DEV.G-GEN.CO.JP、日付 2025-11-27 UTC）に基づき、Chronicle SIEM のログを調査しました。
　
  該当ユーザーによる操作ログが複数確認されました。特に「2段階認証プロセス導入ガイド」の作成や「パスキーの登録」など、認証セキュリティに関連する重要な操作が時系列で確認されています。
　
  以下に、2025年11月27日（UTC）の重要な操作を時系列でまとめます。
　
  ユーザー操作タイムライン (2025-11-27 UTC)
　
  1. OAuth アプリケーションの認可とスクリプト実行 (01:31 - 01:45 UTC)
   * 01:31:08 - 01:45:34: XXXX というアプリケーションに対し、OAuth トークンを認可・取得しました。
       * スコープ: Calendar, Drive, Presentations, Script Deployments 等の権限が含まれています。
       * 操作: USER_RESOURCE_ACCESS (authorize, activity)
       * 詳細: Google Apps Script や Calendar API (calendar.events.list, calendar.events.insert) の呼び出しが記録されています。
　
  2. ドライブ コンテンツの作成と共有 (05:36 - 05:44 UTC)
   * 05:36:14 - 05:38:05: Google ドライブ上で「XXXX プロジェクト」および「2段階認証プロセス導入ガイド」というファイルを編集・更新しました。
   * 05:38:06: 新規ファイル 「2段階認証プロセス導入ガイド」（プレゼンテーション）を作成しました。
   * 05:41:03: 上記ファイルの権限（ACL）を変更し、共有設定を行いました（USER_CHANGE_PERMISSIONS）。
   * 05:41:11: Gmail にて、件名 【GAS自動送信】スライドURLのお知らせ: 2段階認証プロセス導入ガイド」 のメールを送信しました。
       * 接続元IP: 0000:0000:0000:0000:0000:0000:0000:0000 ※提示されたIPと同じサブネット
　
  3. セキュリティ設定の変更 (07:10 UTC)
   * 07:10:03: ユーザー自身の認証設定として、パスキー (Passkey) を登録しました。
       * 操作: STATUS_UPDATE (product_event_type: passkey_enrolled)
       * 接続元IP: 0000:0000:0000:0000:0000:0000:0000:0000
　
  4. デバイス管理 (07:46 UTC)
   * 07:46:49: デバイスの同期/更新イベント (DEVICE_REGISTER_UNREGISTER_EVENT) が記録されています。
　
  考察
  Case ID 137 のアラート名は「Two Factor Authentication Enforcement
  Removal（2要素認証の強制解除）」ですが、ログからは解除操作そのものではなく、逆に「2段階認証プロセス導入ガイド」の作成・配布や、ユーザー自身の「パスキー登録」といった、セキュリティ強化に向けた準備やテストを行っていた動きが顕著に見られます。アラートはこれらの試行錯誤や設定変更の過程でトリガーされた可能性があります。

AWS 特権ユーザーの操作ログ調査

以下のようなプロンプトで、AWS 環境における特権ユーザーの重要な操作（権限変更やリソース削除など）を抽出します。 　

Project ID PROJECT_ID、Customer ID CUSTOMER_ID、Region REGION を使用して、 ユーザー XXX@g-gen.co.jp が 2026年1月26日から1月30日の間に AWS で行った操作の中でセキュリティに影響を与える操作を抽出して要約してください。 　 　

# 出力例
　
✦ ユーザー XXX@g-gen.co.jp の 2026年1月26日から1月30日の間の AWS 操作ログを分析しました。
  主に既存の監視設定の削除と、Google SecOps と連携するための新規 IAM 設定が行われています。
　
  以下にセキュリティに影響を与える主な操作を時系列で要約します。
　
  1. 監視・ログ収集リソースの削除 (1月28日 07:52 - 07:57)
  以前設定されていたと思われる監視用のリソースが一括して削除されました。これにより、一時的に対象環境のログ収集が停止した可能性があります。
   * CloudTrail: トレイル XXXX の削除
   * VPC: VPC フローログの削除
   * S3: バケット XXXX の削除
   * SNS/SQS: 通知用トピックおよびキューの削除
   * CloudWatch Logs: ロググループの削除
　
  2. IAM 権限の操作 (1月28日 04:44 - 09:56)
  特定のユーザーやポリシーに対する権限変更が行われました。
   * ポリシー更新: XXXX ポリシーのバージョン更新（S3バケットやSQSへのアクセス許可設定）。
   * ユーザー権限変更: ユーザー XXXX に対して AdministratorAccess (管理者権限) の付与 (AttachUserPolicy) と、その直後の剥奪 (DetachUserPolicy)
     が行われました。
　
  3. Google SecOps 連携設定の構築 (1月29日 01:59 - 06:01)
  Google SecOps (Chronicle) から AWS 環境を監視・操作するための信頼関係が構築されました。
   * IAM ロール作成: XXXX の作成。
   * OIDC プロバイダ作成: accounts.google.com を信頼する OpenID Connect プロバイダの作成。
   * 信頼ポリシー設定: 作成したロールに対し、Google アカウントからの AssumeRole を許可する設定 (UpdateAssumeRolePolicy)。
　
  結論
  このユーザーは、古いサンドボックス環境の監視設定をクリーンアップし、新たに Google SecOps
  を用いた監視体制を構築するためのセットアップ作業を行っていたと推測されます。

三浦 健斗 (記事一覧)

クラウドソリューション部

2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。

Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026



以上の内容はhttps://blog.g-gen.co.jp/entry/using-secops-remote-mcp-serverより取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます
不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14