モダンなサイバーセキュリティ監視・インシデント対応システムの設計 Wazuh・SOAR・脅威インテリジェンスを用いた実践的アーキテクチャ
なぜ多くのセキュリティプロジェクトは最初から失敗するのか
多くの日本企業が「セキュリティを強化したい」と考えていますが、実際には次のような状況に陥りがちです。
- アラートは大量に出るが、誰も対応しない
- 高価な製品を導入したが、現場で使いこなせない
- 見た目の良いダッシュボードはあるが、実害を防げない
- 特定の担当者に依存し、その人が不在になると運用が止まる
本当の問題はツールそのものではありません。
問題はシステム設計（System Design）です。
本記事では、私たちが実際の現場で採用している 実運用に耐えるサイバーセキュリティ監視・対応システム の設計思想とアーキテクチャを、日本企業の運用・監査・ガバナンスを前提として解説します。
本当に達成すべき目的（マーケティング用語ではない）
このシステムの目的は、単に「SIEMを導入する」「AIを使う」ことではありません。
本当に重要なのは次の点です。
- ノイズではなく 実際にリスクのある脅威を検知すること
- 誰が・いつ対応すべきか を明確にすること
- 被害が拡大する前に 迅速に対応できること
- 内部監査・ISO 27001・コンプライアンス に耐えうる証跡を残すこと
- 特定ベンダーに依存しない 柔軟で拡張可能な構成 にすること
これは製品選定の問題ではなく、システム工学の問題です。
アーキテクチャ設計の考え方
私たちは、役割を明確に分離します。
Detection ≠ Automation ≠ Escalation ≠ Investigationそれぞれが責務を明確に持ち、疎結合で連携する構成が、長期運用では最も安定します。
採用しているコアスタック（理由とともに）
システム全体アーキテクチャ
graph TD
A["Endpoints / Servers / Cloud"] --> B["Wazuh Agent"]
B --> C["Wazuh Manager (SIEM/XDR)"]
C --> D["Shuffle SOAR"]
D -->|Create / Update Incident| E["DFIRTrack"]
D -->|SEV-1 / SEV-2| F["PagerDuty"]
D -->|Automated Response| G["Firewall / DNS / IAM / EDR"]
F --> H["On-call Engineer"]この図は、検知・判断・通知・調査が明確に分離され、かつ統合されていることを示しています。
1. 検知レイヤー — Wazuh
Wazuhは組織全体の セキュリティセンサー基盤 として機能します。
-
収集対象ログ:
- Firewall
- DNS
- IDS / IPS
- VPN
- サーバー / エンドポイント
- ログの正規化
- 相関ルールによる検知
Wazuhが答える問い：
「何が起きたのか？」
私たちは、Wazuhに過度な業務ロジックを持たせません。役割は検知に限定します。
2. 自動化・判断レイヤー — SOAR（Shuffle）
検知後、次に必要なのは判断です。
- 深刻度はどの程度か
- 既知の脅威（IOC）かどうか
- ブロックすべきか、通知のみか
Shuffleは明示的なプレイブックとしてこれらを制御します。
- 脅威インテリジェンスの付加
- Severity計算
- 条件付きレスポンス
- 他システムとの連携
Shuffleが答える問い：
「次に何をすべきか？」
ここが、システムインテグレーションの経験が最も重要になる部分です。
3. 人による対応を保証する — PagerDuty
自動化が進んでも、最終的な責任は人間が持つ必要があります。
PagerDutyは次を保証します。
- 正しい担当者への通知
- 未対応時のエスカレーション
- 応答時間（SLA）の可視化
PagerDutyが答える問い：
「今、誰が責任を持つのか？」
これは単なるアラートと、責任ある対応の違いです。
4. 調査・監査証跡 — DFIRTrack
重大な事象はすべて インシデント として管理します。
- 証拠
- タイムライン
- 判断の記録
- 対応内容
DFIRTrackは以下の目的で利用します。
- インシデント管理
- 資産との紐付け
- 監査対応・事後レビュー
DFIRTrackが答える問い：
「何が起き、どのように対応したのか？」
これは日本企業において非常に重要なポイントです。
日本企業で実際に有効なユースケース
1. DNSによるマルウェア通信の検知
- C2サーバーへの通信を早期検知
- 情報漏洩前にブロック可能
2. IDS / IPSによる悪性IP通信の検知
- 過剰なシグネチャアラートを抑制
- 重要資産にフォーカスした対応
3. 海外からのVPNログイン成功
- 認証情報漏洩の早期発見
- リモートワーク環境に適合
なぜ脅威インテリジェンスは常に最新である必要があるのか
攻撃者は常に以下を変更します。
- IPアドレス
- ドメイン
- インフラ構成
そのため私たちは、
- 定期的なIOC更新
- 信頼度スコアリング
- 自動失効
を前提とした設計を行います。
なぜこの構成は日本企業に適しているのか
- オープンソース中心でコストを制御可能
- 既存環境に合わせた柔軟なカスタマイズ
- 監査・ガバナンス対応が容易
- 将来的なMDR展開も可能
中堅企業から大企業まで対応できます。
私たちが選ばれる理由
私たちは、
- ツールを導入して終わりにはしません
- ダッシュボードだけを売りません
- 現場で運用できる設計を行います
セキュリティはツールの問題ではなく、
判断・時間・責任の問題です。
同様のシステムを検討されている方へ
もし次のようにお考えであれば、
- 実際のリスクを可視化したい
- インシデントに確実に対応できる体制を作りたい
- 自社で理解・管理できる仕組みが欲しい
このアーキテクチャは現実的で堅牢な出発点になります。
要件整理から設計、構築、運用まで、
エンジニアとして一緒に考え、実装します。
Final thought
良いセキュリティシステムは、
人を疲弊させません。
静かに、確実に、制御されている状態を生み出します。
Get in Touch with us
Chat with Us on LINE
iiitum1984
Related Posts
- AIの導入がシステムを壊すアンチパターン
- なぜ私たちは「ソフトウェアを作るだけ」ではないのか — システムを実際に動かすために
- Wazuh管理者向け 実践プロンプトパック
- なぜ政府におけるレガシーシステム刷新は失敗するのか（そして、実際に機能する方法とは）
- 日本の自治体が「本当に必要とする」Vertical AI活用ユースケース
- マルチ部門政府におけるデジタルサービス提供の設計（日本向け）
- デジタル行政サービスが本番稼働後に失敗する7つの理由
- 都道府県・市町村向けデジタルシステムのリファレンスアーキテクチャ
- 実践的GovTechアーキテクチャ：ERP・GIS・住民向けサービス・データ基盤
- なぜ緊急対応システムは Offline First で設計されるべきなのか（ATAK からの教訓）
- なぜ地方自治体のソフトウェアプロジェクトは失敗するのか —— コードを書く前に防ぐための考え方
- AIブームの後に来るもの：次に起きること（そして日本企業にとって重要な理由）
- システムインテグレーションなしでは、なぜリサイクル業界のAIは失敗するのか
- ISA-95 vs RAMI 4.0：日本の製造業はどちらを使うべきか（そして、なぜ両方が重要なのか）
- なぜローコードはトレンドから外れつつあるのか（そして何が置き換えたのか）
- 2025年に失敗した製品たち —— その本当の理由
- Agentic AI Explained: Manus vs OpenAI vs Google — 日本企業が知るべき選択肢
- AIが実現する病院システムの垂直統合（Vertical Integration）
- Industrial AIにおけるAIアクセラレータ なぜ「チップ」よりもソフトウェアフレームワークが重要なのか
- 日本企業向け｜EC・ERP連携に強いAI×ワークフロー型システム開発
