はじめに
GMOコネクトの平島です。
セキュリティ診断の指摘対応で、ログメトリックフィルタ系7項目（VPC変更・IAM変更・サービスアカウント鍵作成 等）を片付ける必要がありました。同じタイミングで「コンテナEDR要件も埋めてほしい」と言われ、SCC（Security Command Center）を入れれば一気に解決すると思っていたんですが、現実はそんなに甘くなかったです😇
SCCにはStandard/Premium/Enterprise の階層があり、SecOps（Chronicle改め）との統合関係も版によって違う。さらに再販GCP（パートナー契約経由）だと、入れたいのに入れられないサービスがあることが途中で判明します。
結局たどり着いたのは、「SCC Premium をEDRと呼ぶな」「EDR要件はR1〜R6で分解しろ」「再販GCPでは組織レベルリソースが必要なサービスは詰みうる」という3つの教訓でした。設計検討で踏んだ罠を順番に書き残しておきます。
先にまとめ
- SCC PremiumはEDRの「検知」だけ。応答・封じ込め・マネージドSOCは持たず、EDR要件のR2/R3/R6が抜ける
- EDR要件はR1〜R6に分解して比較すると、Falcon系コンテナEDRとSCC+SecOpsの差が定量で見える
- SecOpsの契約単位は組織、インスタンスはプロジェクトの二層構造。再販GCPだと組織レベル操作権限がなくてプロビジョニング自体ができない
- YARA-L検知の通知は直接Webhookに送れず、必ずSOAR Playbook経由
- 診断7件のみなら Cloud Logging方式で 4人日、将来のリスク対応まで含めるなら SecOps方式で 15〜25人日
やりたかったこと
セキュリティ診断の指摘事項として、Cloud Audit Logsに対するログメトリックフィルタとアラートが7項目分未設定でした。VPCルートの変更、ファイアウォールルールの変更、IAMポリシーの変更、サービスアカウント鍵の作成、Cloud Storage IAMの変更、SQLインスタンス設定の変更、カスタムロールの変更、といったあたりです。
これだけならCloud Loggingでログシンクを足せば終わりです。問題は、別ラインで「コンテナEDR要件」も降ってきたこと。Cloud Run中心の構成にFalcon系のコンテナEDR製品をどう入れるか、もしくは入れられないなら何で代替するか。診断指摘の対応とEDR要件の検討を、できるだけひとつの構成にまとめたい。
既存の通知基盤はこういう形でした。
[各種ソース] → Pub/Sub → Worker Pools
├─ WORKER_ROLE=monitoring (Cloud Monitoring系)
├─ WORKER_ROLE=scc (SCC Finding系)
├─ WORKER_ROLE=malware (Cloud Storage マルウェア検知)
└─ WORKER_ROLE=dlq (Dead Letter Queue)
Worker側でロールを分岐して通知先（Slack・メール・チケット起票）を切り替える設計です。ここに監査ログ系のロールを追加することで、診断指摘とEDR両方を吸収できるんじゃないかという仮説からスタートしました。
SCC Premium と Enterprise を混同するな
まずここを誤解したまま設計に入ると後で全部やり直しになります。SCCには3階層あり、SecOpsとの統合関係が版ごとに違います。
3階層の責任範囲
| 観点 | Standard | Premium | Enterprise |
|---|---|---|---|
| 基本セキュリティポスチャ管理（CSPM） | 一部 | フル | フル |
| 脅威検知（Event/Container Threat Detection等） | 限定 | フル | フル |
| 脆弱性管理（VM Manager連携等） | 限定 | フル | フル |
| CNAPP（Cloud-Native Application Protection Platform）統合 | 無 | 部分 | フル |
| SecOps（SIEM/SOAR）統合 | 無 | 無（別契約） | 有（バンドル） |
| Curated Detections（マネージド検知ルール） | 無 | 無 | 有 |
| UEBA / 相関分析 | 無 | 無 | 有 |
最大の罠は Premium と Enterprise の間でSecOps統合の有無が違う ことです。
Premium は「脅威検知＋脆弱性管理＋ポスチャ管理」までで止まります。SIEM（ログ集約・横断検索）やSOAR（プレイブック自動化）は含まれません。Finding が出ても、それを横断的に相関させたり、自動応答したりする層が無い。
Enterprise になるとSecOpsがバンドルされ、CNAPPとして「Findingが出る → SecOps コンソールから直接調査 → SOAR Playbook で対処」までが1つのコンソールに統合されます。
公式ドキュメントを読むと、CNAPPという用語の使い方も版ごとに揺れていて、最初は「Premium も CNAPP では？」と勘違いしていました。レビューで指摘を受けて、3点の表現を直しています（CNAPPの位置づけ、Enterprise連携の正確な表現、SOAR Playbook経路）。
ライセンスは「プロビジョニング可否」に直結する
SCC Enterprise を選んでも、SecOps が自動で使えるわけではありません。SecOps を有効化するには別途プロビジョニングが必要で、後述する「再販GCPの組織権限の罠」がここで効いてきます。
SCC Premium で「コンテナEDR要件を満たせるか？」の罠
Premium には Container Threat Detection という機能があり、「コンテナ内の不審なバイナリ実行」「リバースシェル」「シェルスクリプトの追加」などを検知できます。ここだけ見ると「コンテナEDRじゃん」と判断しがちです。
これが間違いの入口です。
EDR要件の分解：R1〜R6で評価する
「SCC PremiumはコンテナEDRの代替になるか？」という問いには、EDRという語を要件分解しないと答えられません。今回採用した評価軸はR1〜R6です。
| ID | 要件 | 説明 |
|---|---|---|
| R1 | 検知（Detect） | プロセス実行・ファイル操作・ネットワーク通信から脅威を検出 |
| R2 | 応答・阻止（Respond） | プロセス停止・通信ブロック・コンテナ隔離など能動的対処 |
| R3 | 封じ込め（Contain） | 影響範囲の自動限定（ノード隔離・SA無効化・ロールバック等） |
| R4 | 調査（Investigate） | テレメトリを使った後追い調査、攻撃チェーンの可視化 |
| R5 | テレメトリ保持（Retain） | プロセス系統・ファイル系統等を長期保持し、過去分の調査が可能 |
| R6 | マネージドSOC（Managed SOC） | ベンダー側の24/365監視・トリアージサービス |
EDRという語は「検知だけ」を指していないので、R1だけ満たしても代替にはなりません。これを念頭にSCC Premium Container Threat Detection を再評価すると：
| 要件 | SCC Premium CTD | Falcon CS（コンテナEDR） | SCC Enterprise + SecOps |
|---|---|---|---|
| R1 検知 | △（一部の不審挙動のみ） | ◎ | ◎（Curated Detections含む） |
| R2 応答・阻止 | × | ◎（プロセスKill等） | △（SOAR Playbookで自動化可能、ただし対処実行はSecOps外） |
| R3 封じ込め | × | ◎ | △（同上） |
| R4 調査 | △（Finding単発） | ◎ | ◎（UDMで横断検索可能） |
| R5 テレメトリ保持 | × | ◎ | ◎（既定12ヶ月、有償延長可） |
| R6 マネージドSOC | × | ◎（Falcon Complete） | △（Mandiant 連携で IR 支援あり。24/365監視は含まれない） |
SCC Premium はR2/R3/R5/R6 が完全に抜けます。「コンテナEDRです」とは言えません。
SCC Enterprise + SecOps は R1/R4/R5 は強い一方、R2/R3 は「SOAR Playbookで自動化はできるが、対処実行（SAキーの無効化・ロールバック等）はSecOps外の操作」になる点に注意です。R6 のマネージドSOC は GCP標準では提供されません（Mandiant の脅威インテリジェンスとインシデント対応支援はSCC Enterpriseにバンドルされますが、24/365の継続監視サービスとは別物です）。
要件分解しないと「SCCあるからEDR要らないっすよね？」みたいな会話になりがちなので、R1〜R6 で並べて見せると話が早いです。
コンテナEDRの落とし穴：Cloud Run中心の構成
評価軸を整えた後、Falcon系のコンテナEDR製品を本気で入れる前提でドキュメントを書いていたんですが、対象システムのTerraform を読んだ瞬間に方針転換することになりました。
K8s（GKE含む）を使っていなかったんです。Cloud Run と Cloud Run Jobs 中心の構成。
コンテナEDR製品の多くは、K8s の DaemonSet としてエージェントを各ノードに配置する前提です。Cloud Run のようなフルマネージドのコンテナ実行環境にはエージェントを差し込めません。サイドカーで動かせるケースもありますが、起動時間とコストの影響、そして「Cloud Run のサンドボックス内側の挙動はそもそも見せてもらえない」という構造的な制約が残ります。
ここで「コンテナEDR導入」というスコープを再定義することになりました。Cloud Run前提のセキュリティをどう積み上げるか、という問いに変わります。
検知できない領域を最初に整理する
ギャップ分析を19項目で実施した結果、完全に検知できない領域が6つ残りました。
| # | 領域 | 理由 |
|---|---|---|
| 1 | Windowsコンテナ | コンテナEDR製品の多くがLinuxのみ対応 |
| 2 | GKE以外のセルフホスト/他社K8s | エージェント配布前提が崩れる |
| 3 | GKE Sandbox（gVisor） | サンドボックス内挙動が外から見えない |
| 4 | Fargate等フルマネージド内部挙動 | Cloud Run も含む。実行環境を制御できない |
| 5 | AI-SPM | LLM入出力・モデル乱用の検知は別カテゴリのツールが必要 |
| 6 | ASPM | アプリケーションコード〜SBOMの可視化は別カテゴリ |
「ここは見ない（見えない）」を最初に合意するのが大事です。後から「これも検知してほしい」が出てきて全部やり直しになるパターンを防げます。
「EDRで全部見ます」と言ってしまうと、4と5と6 が必ず後で爆発します。
ハマり1：YARA-L検知の通知経路
SCC Enterprise+SecOps 案で進める前提で、既存の通知基盤（Pub/Sub→Worker Pools）に統合する経路を設計していたところ、SecOps 側の通知制約に引っかかりました。
SecOpsには大きく2系統の検知があります。
- Curated Detections：Google が用意するマネージド検知ルール
- YARA-Lルール：ユーザー定義の検知ルール（YARA-L 2.0 構文）
このうち YARA-Lルールからの通知は、直接Webhookに送れません。必ずSOAR Playbook を経由する必要があります。
[YARA-Lルール検知]
│ （直接 Webhook は不可）
▼
[SOAR Playbook]
│
▼
[Webhook]
│
▼
[Pub/Sub] → Worker Pools (WORKER_ROLE=audit-monitor) → 通知
「ルールが発火したら Slack に流す」みたいなシンプルな話のつもりが、SOAR Playbook を1個書かないといけない。Playbook 自体は GUI で組めるんですが、運用するルールが増えてくるとPlaybook の数が膨れます。
ちなみにSCCの Findings（Premium/Enterprise の脅威検知や Container Threat Detection の結果を含む）は Continuous Export で直接 Pub/Sub に出せるので、SecOps の YARA-L 経路と混同しないように注意です。
既存ロールに audit-monitor を1つ足すだけにする
既存の WORKER_ROLE 分岐設計が効いてきたのはここです。新しい通知ソースが増えても、Worker 側にロールを1つ足せばメッセージ整形・通知先振り分けが再利用できます。
Pub/Sub → Worker Pools
├─ monitoring （既存）
├─ scc （既存）
├─ malware （既存）
├─ dlq （既存）
└─ audit-monitor（新規：監査ログ系 / SecOps系）
ロールごとに型定義された前提のメッセージスキーマがあるので、各経路で安全に処理できます。
ハマり2：通知メッセージ形式の確実性
audit-monitor ロールに何を流すかを設計するときに、「Cloud Logging のログシンク経由」と「SecOps からの Webhook 経由」の メッセージ形式の確実性に大きな差 があることが分かりました。
| 観点 | Cloud Logging（ログシンク） | SecOps（YARA-L→SOAR→Webhook） |
|---|---|---|
| メッセージ形式 |
LogEntry 形式で公開仕様あり |
Webhook ペイロードの公式仕様が限定的 |
| 既存ロールとの構造一致 | 既存 malware ロールと同構造 |
別途定義が必要 |
| 型定義の確実性 | 高い | 低い（実環境テスト必須） |
| 既存スキーマの再利用 | できる | できない |
実装観点では、LogEntry を使い回せる Cloud Logging方式の方が手数が少なくて済みます。SecOps の Webhook ペイロードは「公開仕様が限定的」で、フィールドが将来変更されると静かに壊れる可能性があります。
どっちを選ぶか：診断指摘の範囲か、リスクシナリオの範囲か
このタイミングで設計判断を分けました。
- 診断指摘7件のみ対応：Cloud Logging 方式（新規ログシンク追加）で 約4人日
- 将来のリスクシナリオ11件を含めて対応：SecOps 方式で 約15〜25人日
リスクシナリオ側には「不審なIAMロール付与」「異常なBigQueryクエリ量」「データ持ち出しのアクセスパターン」みたいな相関分析・UEBA寄りの検知が並ぶので、Cloud Logging のメトリックフィルタだけでは無理筋でした。SecOps の Curated Detections・UEBA・相関分析を取りに行く価値があるラインです。
工数のレンジが広いのは、SOAR Playbook の数（検知ルールごとに1つ）と既存通知基盤との接続テストの量に依存するためです。
ハマり3：再販GCPの「組織レベルリソース」の罠
ここが今回いちばんの落とし穴でした。SecOps の利用単位について、当初こう回答していました。
SecOps はプロジェクト単位で利用できます
これは半分正しくて半分間違いです。公式ドキュメントを冒頭から精査するように指摘を受けて、訂正することになりました。
契約とリソース作成は別レイヤーで考える
GCPのエンタープライズ系サービスは、契約・プロビジョニングの単位 と リソース作成（インスタンス紐付け）の単位 が独立しています。
| 観点 | SecOps |
|---|---|
| 契約・プロビジョニング | 組織単位 |
| インスタンス紐付け | プロジェクト単位 |
つまり、「プロジェクト単位で使える」のは正しいんですが、組織レベルでSecOpsを契約・プロビジョニングするステップ が先に必要で、ここで詰むことがあります。
なぜ詰むかというと、再販GCPだと組織レベルの操作権限が制限されていることがあるからです。再販パートナー側が組織を持っていて、エンドユーザーは組織配下のフォルダ/プロジェクト権限しか持たない、というケースです。組織レベル操作を必要とするサービスのプロビジョニング自体ができません。
Cloud NGFW Enterprise も同じ構造で詰む
この発見が連鎖して、Cloud NGFW Enterprise も検証することになりました。
ここでよくある誤解が「従量課金だから事前契約不要 → だから再販でも使えるはず」です。これは外します。
| 観点 | Cloud NGFW Enterprise |
|---|---|
| 課金モデル | 従量課金（事前契約不要） |
| 必須リソース | Firewall Endpoint |
| Firewall Endpoint の所在 | 組織レベルリソース |
Firewall Endpoint が組織レベルリソースなので、組織操作権限が無いとそもそも作れない。従量課金なのに払い出しできない、という結論になります。
判定軸：「必須リソースが組織レベルか、プロジェクトレベルか」
GCPの再販環境で新サービス導入の可否を判定するときの軸はこれです。
- 契約形態（事前契約 vs 従量課金）だけ見るのは不十分
- 必須リソースの所在（組織レベル / プロジェクトレベル） を必ずチェックする
- 公式ドキュメントの「Resource hierarchy」や「Permissions」のページを冒頭から読む（検索要約だけだと二層構造を取りこぼす）
この点、SCC Premium/Enterprise も「組織単位での有効化」が前提なので、再販環境では同じ罠を踏みます。Standard なら個別プロジェクト有効化のパスがありますが、Premium/Enterprise を狙うときは組織契約フローを最初に確認したほうが事故が少ないです。
設計の落としどころ
最終的に提案した構成はこうなりました。
┌──────────── GCP 組織 ────────────────────────────────────────┐
│ │
│ [既存] Cloud Audit Logs ─┐ │
│ │ │
│ [新規] Log Sink │ ─→ Pub/Sub ─→ Worker Pools │
│ （診断指摘7件分のフィルタ）│ │ ├ monitoring │
│ │ │ ├ scc │
│ [新規] SCC Enterprise ───┘ │ ├ malware │
│ （Finding 系） │ ├ dlq │
│ │ └ audit-monitor │
│ [新規] SecOps │ │ │
│ ├ Curated Detections ─────────────────┘ │ │
│ └ YARA-L → SOAR Playbook ─→ Webhook ──────────────┘ │
│ │
└────────────────────────────────────────────────────────────────┘
2系統の通知経路を、役割で明示的に分けてあります。
- Cloud Logging 経路：診断指摘の確実な対応（LogEntry形式で型確実）
- SecOps 経路：将来の相関分析・UEBA対応（YARA-L→SOAR→Webhook→Pub/Sub）
両方の経路が audit-monitor ロールに合流するため、Worker側で通知先振り分け・整形・抑制を一元化できます。
再販環境で組織レベル操作権限が確保できるかどうかが先決なので、SecOps/Enterprise の導入はそのチェックが終わってからの後追い実装として扱うのが安全です。組織権限の壁にぶつかったら、Cloud Logging方式単独で診断指摘の対応だけ完了させ、SecOps部分は要件として残す判断もありえます。
まとめ
- SCC PremiumをEDRと呼ばない。EDRをR1〜R6 で分解すると、Premium にはR2/R3/R5/R6 が抜けていることが定量で示せる
- EDR代替の評価軸はR1〜R6。Falcon系 vs SCC+SecOps の比較もこの6軸で並べると意思決定が早い
- コンテナEDR製品はK8s前提。Cloud Run中心の構成ではそもそも刺さらないので、検知できない6領域を最初に合意する
- 再販GCPでは「組織レベルリソース」を要する機能で詰む。従量課金/事前契約だけで判定しないこと。SecOps も Cloud NGFW Enterprise も同じ構造
- 通知統合はWORKER_ROLE分岐パターンが効く。Cloud Logging 経路（型確実）と SecOps 経路（拡張性）を併存させ、
audit-monitorロールに合流させた - 工数感：診断指摘のみで 4人日、将来リスク対応まで含めて 15〜25人日
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、
幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。