【要約】GCP×コンテナEDR×再販GCP：SCC＋SecOps の使い分けで踏んだ3つの罠 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
筆者がセキュリティ診断の指摘対応とコンテナEDR要件の充足を同時に進める中で、製品仕様の誤解や環境制約に直面した。
- ・SCC PremiumとEnterpriseの機能差（SecOps統合の有無）の混同。
- ・EDR要件を定義せず、検知機能のみで代替可能と判断したこと。
- ・Cloud Run環境において、K8s前提のコンテナEDRが導入不能である点。
- ・再販GCPにおいて、組織レベルの操作権限がなくサービスを起動できない問題。
// Approach
筆者は、製品の機能差を定量的に評価し、既存の通知基盤へ統合する設計手法を採用した。
- ・EDR要件をR1（検知）からR6（マネージドSOC）まで分解し、製品を比較。
- ・Cloud Runの制約を考慮し、検知できない領域を事前に定義。
- ・通知経路を、型が確実なCloud Logging方式と、拡張性のあるSecOps方式の二系統で設計。
- ・既存のWorkerロール分岐設計を活用し、通知処理を共通化。
// Result
筆者は、要件の範囲に応じて工数と機能を最適化した、二系統の通知構成を提案した。
- ・診断指摘への確実な対応を目的とした、Cloud Logging経由の構成。
- ・将来的な相関分析を見据えた、SecOps経由の構成。
- ・診断指摘のみなら約4人日、将来リスク対応を含めると15〜25人日の工数を見積もり。
- ・再販環境での組織権限の有無を、導入可否の最優先判定軸として確立。
Senior Engineer Insight
> 製品のカタログスペックに惑わされず、要件をR1〜R6で分解して比較する手法は、設計の妥当性を担保する上で極めて実戦的だ。特にCloud Runのようなマネージド環境では、従来のK8s前提のEDRは機能しない。検知できない領域を事前に合意する重要性は、現場のトラブル回避に直結する。また、再販GCPにおける組織権限の制約は、設計の根幹を破壊しうる致命的なリスクだ。契約形態だけでなく、リソースの所在を初期段階で精査する姿勢が、プロの設計者には求められる。