Google SecOpsで始めるCloud Runセキュリティ監視

1. Google SecOpsによるCloud Run監視の全体像

Cloud Runのセキュリティ監視では、単にログを保存するだけでなく、検知したい事象と対応方法を決め、ログの収集から調査・対応までを一連の流れとして設計します。

基本的な流れは次のとおりです。

• Cloud Runや関連サービスのログを収集する
• 対応するGoogle SecOpsパーサーでUDMへ正規化する
• YARA-L 2.0の検知ルールで重要な設定変更や不審な活動を評価する
• 条件に一致したイベントから検知・アラートを生成する
• 関連するユーザー、リソース、操作、アクセスを検索・調査する
• アラートと調査結果をケースで管理する
• プレイブックを使い、情報収集や通知などの初動を支援する

図1 Google SecOpsによるCloud Runセキュリティ監視の全体像

最初からすべてを監視するのではなく、Ingressや認証の変更、IAMポリシーの変更、想定外のデプロイなど、運用上の影響が大きい事象から対象を絞ると始めやすくなります。

2. Cloud Runのログを取り込む

監視の第一歩は、検知と調査に必要なログをGoogle SecOpsへ取り込むことです。Cloud Runのリクエストログ、コンテナログ、システムログは、Google SecOpsでGCP_RUNというログタイプとしてサポートされています。設定変更などを追跡するCloud Audit Logsも、別のサポート済みログタイプとして取り込めます。

取り込み対象を決める

すべてのログを一律に取り込むのではなく、検知したい事象と調査時に確認したい情報を先に整理します。例えば、Cloud Runサービスの更新やIAMポリシー変更を検知したい場合はCloud Audit Logsが重要です。変更後のアクセス状況を確認する場合はリクエストログ、アプリケーションの挙動やエラーを確認する場合はコンテナログを組み合わせます。

Google SecOpsへの取り込み方法を選ぶ

Google Cloudのサポート済みログをGoogle SecOpsへ送る方法には、主に直接取り込み（Direct ingestion）とCloud Storageを利用するFeedがあります。

• 直接取り込み：Google Cloud側の対象ログをGoogle SecOpsへリアルタイムに転送します。Cloud Runログ（GCP_RUN）とCloud Audit Logsはサポート対象です。設定した時点以降のログが対象で、設定前のログは遡って取り込まれません。
• Cloud Storage経由：Cloud LoggingからCloud Storageへルーティングし、Feedで定期的に取り込みます。Google SecOpsへ送る前に除外フィルタを細かく適用したい場合などに利用できますが、Cloud Storageの利用料金が別途発生します。

Cloud Runのセキュリティ監視を新しく始める場合は、まずサポート済みログタイプと直接取り込みの対象を確認し、ログ量やフィルタリング要件に応じてCloud Storage経由を検討すると整理しやすくなります。

図2 Cloud RunのログをGoogle SecOpsへ取り込み、UDMで共通化するイメージ

取り込み量と保存期間も確認する

取り込むログが増えるほど調査できる情報も増えますが、Google SecOpsの契約や割り当て、Cloud Logging側のログ量なども考慮する必要があります。Cloud Storage経由を利用する場合は、保存・転送に伴うGoogle Cloud側の費用も確認します。監視目的に対して必要なプロジェクト、ログタイプ、保持期間、フィルタを整理します。

機密情報や個人情報がログへ含まれる場合は、閲覧権限や保持方針も確認します。コンテナログについては、アプリケーションが認証情報や個人情報を不用意に出力していないかも事前に確認します。

UDMへの正規化結果を確認する

Google SecOpsへ取り込まれたデータは、対応するパーサーによってUnified Data Model（UDM）へ正規化されます。Cloud RunのGCP_RUNパーサーでは、サービス名やリビジョン名、HTTPリクエストに関する情報などがUDMへマッピングされます。

ただし、必要な情報が必ず期待するUDMフィールドへ入るとは限りません。Cloud Audit LogsとGCP_RUNではパーサーやマッピングも異なります。テスト用の設定変更やアクセスを行い、主体、対象サービス、操作内容、時刻、リビジョン名など、検知・調査で使いたい情報を実際に検索できることを確認します。

3. 重要な設定変更を検知する

ログを取り込んだ後は、Google SecOpsのYARA-L 2.0検知ルールを使って、重要な設定変更や不審な活動を評価します。YARA-Lでは複数のイベントやデータソースを関連付け、条件に一致したイベントから調査につながるアラートを生成できます。

検知対象を明確にする

「Cloud Runで何か変更された」という広い条件ではなく、確認が必要な状態を具体的に定義します。Cloud RunのUpdateServiceやSetIamPolicyなどの管理操作はAdmin Activity監査ログの対象なので、検知条件を考える際の重要な手掛かりになります。

• Ingressや認証設定が変更され、意図した公開範囲と異なる状態になった
• 想定していないプリンシパルへCloud Run Invokerなどの権限が付与された
• 管理権限やデプロイ権限が追加された
• 実行サービスアカウントが変更された
• 想定していないコンテナイメージや構成がデプロイされた
• 本番トラフィックが想定外のリビジョンへ切り替えられた

実際に検知できる条件は、元の監査ログに含まれる情報とUDMへのマッピング結果に依存します。公開範囲やコンテナイメージなど、特定の設定値までルールで判定したい場合は、テスト操作を行い、必要な値がraw logまたはUDMのどこへ格納されるかを確認してからルールを作成します。

正常な変更を考慮する

設定変更が行われたことだけで、不正な操作とは判断できません。通常のリリースや保守作業でも同じAPIが呼び出されます。担当者、作業時間帯、対象プロジェクト、対象サービスなど、ログから安定して取得できる情報を条件に利用し、変更申請などログ外の運用情報は調査時に照合します。

条件を広げすぎるとアラートが増え、重要な事象を見落としやすくなります。一方で、条件を限定しすぎると確認すべき変更を検知できません。ルールはテストしてから本番運用へ移し、実際のアラートを見ながら継続的に調整します。

検知後の調査につなげる

検知ルールでアラートを生成した後は、人またはエージェントによるレビューと調査が必要です。ルールのoutcomeへ主体、対象リソース、IPアドレスなどのコンテキストを適切に含めておくと、アラートグラフやUDM検索から関連情報へ移りやすくなります。

4. 関連情報を検索して影響範囲を調査する

アラートが生成された後は、対象の設定変更だけでなく、操作前後の関連イベントを確認します。単独のイベントだけでは、正当な変更か、他の不審な活動と関連しているか、変更後にどのような影響があったかを判断できないためです。

操作した主体を確認する

最初に、変更を行ったユーザーやサービスアカウントを確認します。Cloud Audit LogsのauthenticationInfoやrequestMetadataなどを手掛かりに、同じ主体が近い時間帯に実行した別の操作を追跡します。呼び出し元IPアドレスやUser-Agentなどは記録される場合がありますが、操作方法やプライバシー上の処理によって値が欠落・マスクされる場合もあるため、必ず取得できる前提にはしません。

対象リソースと関連操作を確認する

変更されたCloud Runサービスだけでなく、関連するIAMポリシー、実行サービスアカウント、リビジョン、コンテナイメージなども確認します。必要な情報がUDMへ直接マッピングされていない場合は、raw logも確認します。権限変更とデプロイが連続している場合など、複数の操作を時系列で並べると全体像を整理しやすくなります。

変更後のアクセス状況を確認する

公開設定やトラフィック切り替えなどの変更後は、GCP_RUNのリクエストログを確認します。送信元IP、HTTPステータス、レイテンシ、リクエスト数の変化などを手掛かりに、想定外のアクセスやアプリケーションへの影響が発生していないかを調査します。

調査では、次のような情報を時系列で整理します。

• 誰が設定を変更したか
• 記録されている場合、どのIPアドレスやクライアントから操作したか
• どのCloud Runサービスが変更されたか
• IAMや実行サービスアカウントに関連する変更があったか
• どのリビジョンやコンテナイメージが関係しているか
• 変更後に不審なアクセスやエラー増加が発生したか

5. ケース管理と初動対応につなげる

Google SecOpsでは、検知ルールなどから生成されたアラートを調査し、インシデント対応のワークフローとしてケースで管理できます。共有するエンティティや設定したルールに基づいて、関連するアラートを既存ケースへ自動的にグループ化することもできます。

図3 検知から調査・ケース管理・初動対応へつなげる流れ

ケースへ記録・集約したい情報

• アラートの概要と発生時刻
• 対象のプロジェクト、リージョン、Cloud Runサービス
• 操作したユーザーまたはサービスアカウント
• ログに記録されている呼び出し元情報
• 変更内容と関連するIAM操作
• 変更後のアクセス状況と影響範囲
• 調査結果、判断理由、実施した対応

一定の形式で情報を管理すると、担当者間の引き継ぎがしやすくなり、過去の類似ケースや関連エンティティの履歴も参照しやすくなります。調査で不足したログやコンテキストを振り返り、検知ルールやログ設計の改善につなげます。

プレイブックで初動を支援する

SOARのプレイブックは、条件に応じてアラートへ紐付き、情報のエンリッチメント、担当者への通知、チケット作成などの定型作業を自動または半自動で実行できます。まずは情報収集や通知など、失敗時の影響が小さい処理から始めるのが安全です。

Cloud Runサービスの停止、IAM権限の削除、トラフィックの切り替えなど業務影響の大きい操作は、人による確認や承認を組み込んで段階的に自動化します。なお、ケース全体を対象に実行するCase playbooksは2026年9月時点ではPreviewのため、本記事では一般提供されているアラート単位のプレイブックを前提にしています。

6. 導入・運用設計で押さえたいポイント

7. まとめ

Cloud Runのセキュリティ監視では、目的に応じたログを収集し、Ingressや認証、IAM、実行サービスアカウント、リビジョンなどに関する重要な変更を継続的に確認します。

Google SecOpsでは、Cloud Runログ（GCP_RUN）とCloud Audit Logsを取り込み、UDMへ正規化したうえで、YARA-L 2.0による検知、関連情報の検索・調査、ケース管理、プレイブックによる初動支援へつなげられます。

まずは重要なCloud Runサービスと検知したい事象を一つ選び、ログの取り込みからアラート、ケース、通知までを小規模に検証します。実際のUDMマッピングとアラート内容を確認しながらルールと対応手順を改善し、監視対象と自動化の範囲を段階的に広げることが、継続可能な運用につながります。

8. 参考情報

• Ingest Google Cloud logs
• Collect Cloud Run logs
• UDM overview
• Get Started: YARA-L 2.0 in SecOps
• Detection rules overview
• Investigate alerts
• Investigation and case management overview
• Trigger playbooks by alert type
• Google Security Operations release notes
• Cloud Run audit logging
• Logging and viewing logs in Cloud Run