CloudflareのETLレス脅威インテリジェンスをSOC運用に落とす: リアルタイム意思決定の設計

Cloudflareが公開した脅威インテリジェンス基盤の進化（ETLレス志向）は、SOCにとってデータ処理の改善ではなく、意思決定速度そのものの再設計です。攻撃の変化が時間単位で起こる時代に、日次バッチ前提の検知設計は限界を迎えています。

なぜ従来ETL中心のSOCは遅れるのか

典型的な流れは「収集→正規化→夜間集約→翌日分析」です。以前はこれで回りましたが、現在は以下が顕在化します。

• 初動で必要なコンテキストが遅れて到着する
• スキーマ差分で下流ルールが崩れる
• 文脈不足のアラートが増え、アナリスト疲弊が進む

結果として、検知数は増えても意思決定は遅くなります。

ETLレスの実務定義

ETLレスは「変換しない」ではなく「変換を遅延させない」です。現実的には次の構成になります。

• 入口での軽量パースとバージョン管理
• ストリーム上での相関・エンリッチ
• ID/ネットワーク/ワークロードを横断したリスクスコア計算
• 判定結果をポリシーエンジンへ即時接続

要点は、データレイク中心の後工程最適化から、判定時点最適化へ軸足を移すことです。

SecOpsとPlatformのテレメトリ契約を統一する

多くの企業で、セキュリティログとアプリ観測データは別々に管理されています。これでは相関速度が落ちます。統一時の必須項目は以下です。

• 共通イベントID
• 主体キー（user/device/service/workload）
• エンリッチ情報の由来と信頼度

この3点がそろえば、SOCとSREが同じ事実を見て議論できます。

ダッシュボードより運用導線を再設計する

可視化を強化しても、運用導線が古いままなら効果は限定的です。推奨は3層です。

• Tier 0: 決定論的な自動隔離・遮断
• Tier 1: 文脈付きクラスタを人が確認
• Tier 2: 横断的・新規性の高い事案を深掘り

KPIはアラート件数削減より、確信を持った判断までの時間短縮で置くべきです。

ガバナンスとプライバシーの同時設計

リアルタイム相関を強化すると、過収集のリスクも上がります。最低限、次を固定化します。

• 信号種別ごとの最小収集方針
• スコア根拠の説明可能性
• 地域規制に沿った保持・削除
• 自動封じ込めの不変監査ログ

検知性能だけを追うと、後で法務・監査負債が爆発します。

90日で回す導入ステップ

• 1カ月目: 主要ユースケースの検知遅延を測定、ボトルネック特定
• 2カ月目: 高頻度攻撃2種類でストリーム相関を試験導入
• 3カ月目: 信頼度スコアと限定自動対応を接続し効果測定

一気に全域展開せず、攻撃種別ごとに再現性を確認しながら広げるのが安全です。

まとめ

CloudflareのETLレス志向は、SOCが「データ処理組織」から「リアルタイム判断組織」へ移るための示唆です。AI時代の攻撃テンポに追従するには、バッチ後分析ではなく、判定時点での相関・説明・実行を一体設計する必要があります。