なぜ私たちは Tool-to-Tool ではなく SOC Integrator を設計したのか
現代のSOC(Security Operations Center)は非常に強力なツール群で構成されています。
例えば以下のような構成が可能です。
- Wazuh(検知・相関分析)
- Shuffle(SOAR自動化)
- IRIS(インシデント管理)
- PagerDuty(エスカレーション/オンコール対応)
しかし、多くの組織が運用開始から数か月後に直面する問題があります。
ツール同士を直接接続する構成は、時間とともに複雑化し、制御不能になりやすい という点です。
そこで私たちは、単純なツール間連携ではなく、以下のアーキテクチャを採用しました。
SOC Integrator — APIオーケストレーション層
本記事では、この設計判断の背景と意義について解説します。
Tool-to-Tool 連携の課題
多くの環境では、次のような構成が取られます。
- Wazuh → ShuffleへWebhook送信
- Shuffle → IRISでインシデント作成
- Wazuh → PagerDutyへ直接通知
- Shuffle → PagerDutyへ再度エスカレーション
- IRIS → 追加スクリプト実行
初期段階では問題なく動作します。
しかし半年後には、以下のような課題が顕在化します。
- 重複アラートの発生
- Severity(重要度)の不整合
- インシデント命名ルールの不統一
- ルール調整後のワークフロー崩壊
- APIトラブルのデバッグ困難
- 自動化の意思決定ログが分散
これを私たちは SOCスパゲッティ構造 と呼びます。
私たちの設計思想:SOC Integrator を Control Plane として導入
各ツールを直接接続するのではなく、
単一の制御レイヤー を導入しました。
SOC Integrator の役割は以下の通りです。
- Wazuhからアラートを受信
- データの正規化・エンリッチメント
- 顧客環境に応じたロジック適用
- 適切なAPIの呼び出し
- すべてのアクションを監査ログに記録
このモジュールは、SOC全体の Control Plane(制御層) となります。
アーキテクチャ概要
Logical Flow
Log Sources
↓
Wazuh (Detection & Correlation)
↓
SOC Integrator (API Orchestration Layer)
↓
├─ Shuffle (Automation / Enrichment)
├─ IRIS (Case Management)
└─ PagerDuty (Escalation)
System Diagram (Mermaid)
flowchart LR
A["Log Sources\nFirewall / DNS / IDS / VPN / Windows / AD"] --> B["Wazuh\nDetection & Correlation"]
B --> S["SOC Integrator\nAPI Orchestration Layer"]
S --> C["Shuffle\nSOAR Automation"]
S --> D["IRIS (iris-web)\nCase Management"]
S --> E["PagerDuty\nOn-call Escalation"]
C -->|"Enrichment / IOC Match Results"| S
S -->|"Create/Update Case + Evidence"| D
S -->|"SEV-1/SEV-2 Escalation"| E
S --> F["SOC Dashboard / Reporting\n(Optional)"]
重要な原則:
すべての検知後アクションは SOC Integrator を経由する
SOC Integrator の機能
1. アラート正規化(Alert Normalization)
異なるログソースやルールは、形式が統一されていません。
SOC Integrator は以下を実施します。
- フィールドの標準化(src_ip、user、hostnameなど)
- 重要度の統一(Low/Medium/High → SEV-3/2/1)
- Allowlist・抑制ロジックの適用
- 重複イベントの排除
これにより:
- PagerDutyの重複通知防止
- IRISでの重複インシデント作成防止
- スキャン等によるアラート嵐の抑制
2. ワークフロー統合管理(Workflow Orchestration)
意思決定ロジックを各ツールに分散させず、中央集約します。
例:
- IOC検知 → Shuffleでエンリッチメント実行
- VPN海外ログイン → インシデント作成
- ADブルートフォース+IOC一致 → 即時エスカレーション
中央管理により、変更・監査が容易になります。
3. エスカレーション制御(Controlled Escalation)
SOC Integrator が以下を判断します。
- PagerDuty通知対象の選別
- 重要度とエスカレーションポリシーのマッピング
- SLAトラッキング
- 再発時の再オープン制御
不要な経営層通知を防ぎます。
4. APIガバナンスと信頼性
エンタープライズ環境では以下が必須です。
- リトライ制御
- レート制限
- 冪等性(Idempotency)管理
- APIキーの安全管理
- 完全な監査ログ
SOC Integrator はこれらを強制します。
顧客にとっての価値
ルール調整が容易
検知ロジック変更が全体フローに影響しません。
インシデントの標準化
ケース形式・証跡が統一されます。
誤検知の削減
中央集約型の抑制・重複排除。
拡張性
Impossible Travelやランサムウェア検知などを容易に追加可能。
ベンダーロックイン低減
SOARやケース管理を変更しても、修正はSOC Integratorのみ。
戦略的視点
多くのインテグレーターはこう考えます。
「どうやってツールを接続するか?」
私たちはこう考えます。
「どうやって検知フロー全体を制御するか?」
この違いが、PoCと本番運用レベルの差を生みます。
まとめ
各セキュリティツールは強力です。
しかし、統制されたオーケストレーションがなければ、
ノイズと複雑性が増大します。
SOC Integrator APIレイヤー を導入することで、
構造化され、拡張可能で、長期運用に耐えるSOC基盤を構築できます。
Wazuhベースで本番運用可能なSOCを設計する場合、
このアーキテクチャ判断は極めて重要です。
Get in Touch with us
Related Posts
- OCPP 1.6によるEV充電プラットフォーム構築 ダッシュボード・API・実機対応の実践デモガイド
- ソフトウェア開発におけるスキル進化(2026年)
- Retro Tech Revival:クラシックな思想から実装可能なプロダクトアイデアへ
- OffGridOps — 現場のためのオフライン・フィールドオペレーション
- SmartFarm Lite — オフラインで使える、シンプルな農業記録アプリ
- ヒューリスティクスとニュースセンチメントによる短期価格方向の評価(Python)
- Rust vs Python:AI・大規模システム時代における言語選択
- ソフトウェア技術はどのようにしてチャンタブリー県の果物農家が価格主導権を取り戻すのか
- AIはどのように金融機会を発見するのか
- React Native およびモバイルアプリで ONNX モデルを活用する方法
- 葉の病害検出アルゴリズムはどのように動作するのか:カメラから意思決定まで
- Smart Farming Lite:センサーに依存しない実践的デジタル農業
- なぜカスタムMESは日本の工場に適しているのか
- AIが検索に取って代わる時代:書き手と専門家はどう生き残るのか
- リサイクル事業のための金属価格予測 (日本市場向け・投機不要)
- チーズは誰が動かした?
- 日本向け:業務に最適化されたEコマースシステム設計
- AIの導入がシステムを壊すアンチパターン
- なぜ私たちは「ソフトウェアを作るだけ」ではないのか — システムを実際に動かすために
- Wazuh管理者向け 実践プロンプトパック













