中堅・中小企業こそOSSで統合監視：Wazuhで作る低コストSOC/XDR基盤

経営層からは「コストを抑えろ」と言われ、現場からは「PCが重い」と文句を言われ、監査法人からは「ログのモニタリング体制はどうなっていますか」と詰められる。これが、多くの中堅・中小企業（SMB）のIT管理者が置かれている過酷な現実ではないでしょうか。

CrowdStrikeやSentinelOneといった商用のEDR（Endpoint Detection and Response）や、SplunkのようなSIEM（Security Information and Event Management）は、確かに素晴らしい製品です。しかし、ライセンス費用だけで年間数百万円、さらに運用するためのSOC（Security Operation Center）を外部委託すれば月額数十万円が飛んでいきます。

「うちはそんな予算出ないよ」で終わらせてはいけません。予算がないなら、OSS（オープンソースソフトウェア）で戦う術があります。

本記事では、世界で最も利用されているOSSのXDR/SIEMプラットフォームである「Wazuh」を活用し、 ライセンスコストほぼゼロで、エンタープライズレベルのセキュリティ監視基盤（簡易SOC）を構築する方法を解説します。

なぜ今、Wazuhなのか？

かつてOSSのセキュリティツールといえば、「設定が難しい」「GUIが貧弱」「誤検知が多い」というのが相場でした。しかし、Wazuhはその常識を過去のものにしています。

1. SIEMとXDRの「いいとこ取り」

Wazuhは、ログを集約・分析する SIEM機能と、エンドポイント（PCやサーバー）の挙動を監視・対処する XDR機能を統合しています。 Elastic Stack (Elasticsearch, Kibana) をベースに開発されており、検索パフォーマンスや可視化能力は折り紙付きです。

2. エージェントが超有能

各端末にインストールするWazuh Agentは非常に軽量ですが、以下の機能を単体でこなします：

ファイル改ざん検知 (FIM): 重要ファイルが書き換えられたら即座に発報。
設定診断 (SCA): 「パスワードポリシーが甘い」「不要なサービスが動いている」などの設定不備を自動監査。
脆弱性検知: インストールされているソフトのバージョンをCVEデータベースと照合し、危険な脆弱性をリストアップ。
詳細ログ収集: WindowsイベントログやLinuxのSyslogを吸い上げ、サーバーへ転送。

3. コンプライアンス対応の可視化

PCI DSS, GDPR, NIST, HIPAAなどのセキュリティ基準に対応したダッシュボードが標準で用意されています。「コンプライアンス要件満たしてますか？」という監査対応の際、この画面を見せるだけで説明の手間が激減します。

Wazuhのアーキテクチャと仕組み

Wazuhは単なる「ログ収集サーバー」ではありません。その裏側では、高度な技術要素が連携して動いています。

コンポーネントの役割

Wazuh Agent: エンドポイント（PC/サーバー）で動作する軽量プログラム。ログ収集、コマンド実行、ファイル監視、インベントリ収集を行います。収集したデータを暗号化してManagerへ送ります。
Wazuh Server (Manager): Agentから送られてきたデータを復号し、数千以上の「デコーダー」と「ルール」に基づいて解析します。「これはSSHの失敗だ」「これは攻撃の予兆だ」と判断する頭脳です。
Wazuh Indexer: 解析されたアラートデータを高速に検索・保存するためのデータベース（OpenSearchベース）。数億件のログから一瞬で目的のデータを抽出します。
Wazuh Dashboard: データを可視化するWeb UI（OpenSearch Dashboardsベース）。運用者が普段見る画面です。

データの流れ

発生: ユーザーがPCで不正なファイルをダウンロード。
検知: Agentがファイル作成イベントを検知し、ハッシュ値を取得。
転送: Agentが暗号化チャネルを通じてManagerへ送信。
分析: ManagerがVirusTotalと連携（オプション）し、ハッシュ値が黒であると判定。
発報: アラートレベル12（High）としてインデックス化。
通知: Slackやメールへ通知が飛ぶ。

この一連の流れが、OSSだけで完結するのです。

導入前のサイジングガイド（推奨スペック）

「とりあえず入れる」でも動きますが、ログデータは意外とディスクを食います。SMB環境での現実的なサイジング目安です。

管理台数	CPU	メモリ	ディスク (ログ保持期間90日想定)
～25台	4 Core	8 GB	100 GB SSD
～100台	8 Core	16 GB	500 GB SSD
～500台	16 Core	32 GB	2 TB SSD (要クラスタ構成検討)

※ Wazuh Indexer（OpenSearch）はJavaベースのため、メモリを多く消費します。最低でも8GBないと、頻繁にOOM Killer（メモリ不足による強制終了）の餌食になります。ケチらずにメモリは積みましょう。

Wazuh構築完全ガイド (Docker Compose版)

本来、Wazuhの構築はIndexer, Server, Dashboardという3つのコンポーネントをセットアップする必要があり複雑ですが、Docker Composeを使えば一撃です。今回は、SMB環境（管理対象50〜100台程度想定）で現実的に運用できる「シングルノード構成」を紹介します。

前提環境:

OS: Ubuntu 22.04 LTS / Debian 11 / RHEL 9 (またはWSL2上のUbuntu)
メモリ: 最低 6GB (8GB以上推奨)
Docker & Docker Compose: インストール済みであること

1. リポジトリのクローンと証明書生成

まず、Wazuh公式のDockerリポジトリを取得します。

git clone https://github.com/wazuh/wazuh-docker.git -b v4.7.2
cd wazuh-docker/single-node

※ バージョン v4.7.2 は執筆時点の安定版です。最新版はGitHubを確認してください。

SSL証明書を自動生成します。

docker-compose -f generate-indexer-certs.yml run --rm generator

これで config/wazuh_indexer_ssl_certs ディレクトリに証明書が作成されます。

2. docker-compose.yml の調整 (重要)

デフォルトの設定でも動きますが、実運用を見据えて docker-compose.yml を少し調整することをお勧めします。特にデータの永続化とメモリ制限は重要です。

version: '3'

services:
  wazuh.manager:
    image: wazuh/wazuh-manager:4.7.2
    hostname: wazuh.manager
    restart: always
    ports:
      - "1514:1514"  # エージェント通信用
      - "1515:1515"  # エージェント登録用
      - "514:514/udp" # Syslog受信用
      - "55000:55000" # API
    environment:
      - INDEXER_URL=https://wazuh.indexer:9200
      - INDEXER_USERNAME=admin
      - INDEXER_PASSWORD=SecretPassword123! # ★必ず変更
    volumes:
      - wazuh_api_configuration:/var/ossec/api/configuration
      - wazuh_etc:/var/ossec/etc
      - wazuh_logs:/var/ossec/logs # ★ログの永続化
      - wazuh_queue:/var/ossec/queue
    depends_on:
      - wazuh.indexer

  wazuh.indexer:
    image: wazuh/wazuh-indexer:4.7.2
    hostname: wazuh.indexer
    restart: always
    environment:
      - "OPENSEARCH_JAVA_OPTS=-Xms2g -Xmx2g" # メモリ割当(サーバー搭載量に合わせて調整)
      - "discovery.type=single-node"
    volumes:
      - wazuh-indexer-data:/var/lib/wazuh-indexer
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536

  wazuh.dashboard:
    image: wazuh/wazuh-dashboard:4.7.2
    hostname: wazuh.dashboard
    restart: always
    ports:
      - "443:5601" # ブラウザアクセス用
    environment:
      - INDEXER_URL=https://wazuh.indexer:9200
      - OPENSEARCH_HOSTS=https://wazuh.indexer:9200
    depends_on:
      - wazuh.indexer

volumes:
  wazuh_api_configuration:
  wazuh_etc:
  wazuh_logs:
  wazuh_queue:
  wazuh-indexer-data:

# ネットワーク設定などは環境に合わせて適宜追加

3. 起動

docker-compose up -d

起動完了まで2〜3分かかります。ブラウザで https://<サーバーのIP> にアクセスし、ログイン画面が表示されれば成功です。初期ユーザーは admin、パスワードは SecretPassword123! (ymlで指定したもの) です。

エージェントの展開：これがなければ始まらない

サーバーが建っただけでは何も監視できません。PCやサーバーに「Wazuh Agent」を入れましょう。

エージェントの追加手順

ダッシュボード左メニューから Agents > Deploy new agent をクリックします。ウィザード形式でコマンドを自動生成してくれます。

Operating system: Windows / Linux / macOS を選択。
Architecture: 64bit / 32bit などを選択。
Wazuh server address: 構築したサーバーのIPアドレスまたはドメインを入力。
Group: 必要に応じてグループ分け（例: server-group, workstation-group）。

画面下に表示されたコマンドを、対象のマシンで実行するだけです。

Windowsの場合 (PowerShell管理者権限):

Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.7.2-1.msi -OutFile ${env:tmp}\wazuh-agent.msi; msiexec.exe /i ${env:tmp}\wazuh-agent.msi /q WAZUH_MANAGER='192.168.1.100' WAZUH_REGISTRATION_SERVER='192.168.1.100'
NET START WazuhSvc

完了すると、数分でダッシュボードの Agents 一覧にマシンが表示されます。「Active」になっていれば接続成功です。

実践活用シナリオ：明日から使える検知ルール

ここからが本番です。単に「ログが集まりました」では意味がありません。具体的な脅威をどう検知するか、実践的なシナリオを見ていきましょう。

シナリオ1: 重要な設定ファイルの改ざん検知 (FIM)

ランサムウェアや攻撃者は、バックドアを仕掛けるためにシステムファイルを書き換えます。WazuhのFile Integrity Monitoring (FIM) は標準で有効になっていますが、監視対象をカスタマイズすることで真価を発揮します。

設定場所: 各エージェント（または一括配布設定）の ossec.conf

<syscheck>
  <!-- 監視頻度（デフォルトは12時間だが、テスト用に短くしても良い） -->
  <frequency>43200</frequency>

  <!-- Webサーバーのドキュメントルートをリアルタイム監視 -->
  <directories whodata="yes" realtime="yes">/var/www/html</directories>
  
  <!-- 重要設定ファイル（変更されるはずがないファイル） -->
  <directories check_all="yes">/etc/passwd</directories>
  <directories check_all="yes">/etc/shadow</directories>
</syscheck>

whodata="yes" オプションを有効にする（要Auditd連携）と、「誰が（どのユーザーが）」書き換えたかまで特定できます。これがOSSでできるのは驚異的です。

シナリオ2: 脆弱性の可視化 (Vulnerability Detector)

「社内のPC、Chromeのバージョン古くない？」これを調べるために全台回る必要はありません。Wazuhサーバー側で設定を有効にするだけで、Agentが集めたパッケージ情報をCVEデータベースと突き合わせてくれます。

設定場所: サーバー側の ossec.conf

<vulnerability-detector>
  <enabled>yes</enabled>
  <interval>5m</interval>
  <min_full_scan_interval>6h</min_full_scan_interval>
  <run_on_start>yes</run_on_start>
  
  <!-- 各OSのプロバイダを有効化 -->
  <provider name="canonical">
    <enabled>yes</enabled>
    <os>focal</os>
    <os>jammy</os>
  </provider>
  
  <provider name="msu">
    <enabled>yes</enabled>
  </provider>
  
  <provider name="nvd">
    <enabled>yes</enabled>
  </provider>
</vulnerability-detector>

設定を反映（docker-compose restart）してしばらく待つと、ダッシュボードの Vulnerability Detection メニューに、社内の端末にある脆弱性がズラリと表示されます。「Critical」な脆弱性が残っている端末が一目瞭然になるため、パッチ適用の優先順位付けが劇的に楽になります。

シナリオ3: 管理外のUSBメモリ接続検知

情報漏洩の温床となるUSBメモリ。Windowsのイベントログを監視することで、USBが挿された瞬間にアラートを上げることが可能です。

Wazuhの標準ルールセットにはUSB接続の検知ルールが含まれていますが、より明確にアラートを上げるには local_rules.xml に以下のようなルールを追加します。

<group name="pnp_devices,">
  <rule id="100001" level="7">
    <if_sid>60100</if_sid> <!-- 標準のレジストリ監視イベントID -->
    <field name="win.eventdata.imagePath">USBSTOR</field>
    <description>USB Storage Device Connected: $(win.system.computer)</description>
    <options>no_full_log</options>
  </rule>
</group>

これにより、従業員が勝手にUSBメモリを挿した瞬間、管理者へ通知を飛ばす運用が可能になります。

運用のアドバイス：通知地獄にならないために

SIEM導入の最大の失敗パターンは、「アラート通知を全ONにしてしまい、メールが大量に来て無視するようになる（オオカミ少年化）」です。

Level 12以上のみ通知: 最初は、Wazuhのアラートレベル「High (12以上)」のみをSlackやメールに通知するように設定しましょう。
ホワイトリストの活用: 業務上必要な夜間バッチ処理などで誤検知する場合、そのルールIDとホスト名の組み合わせを除外設定（ruleset/rules/local_rules.xml）に追加してミュートします。
週次レビュー: ダッシュボードの「Security events」を週に1回見る時間をカレンダーに入れます。重大ではないが気になる傾向（例えば、特定のユーザーだけログイン失敗が多いなど）がないかを確認します。

Slackへの通知設定：メールは見ないあなたへ

Wazuhはデフォルトでメール通知に対応していますが、今どきの現場ではSlackやTeamsへ通知したいでしょう。Wazuhは標準でSlack連携機能を持っています。

1. Slack Webhook URLの取得

Slack側で Incoming Webhook アプリを追加し、通知先チャンネルのWebhook URL (https://hooks.slack.com/services/...) を取得しておきます。

2. ossec.conf の編集

Wazuhサーバー（Manager）の ossec.conf に以下を追記します。全体設定(<ossec_config>)の中に記述してください。

<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/YOUR/WEBHOOK/URL</hook_url>
  <level>10</level>  <!-- レベル10以上のアラートのみ通知 -->
  <alert_format>json</alert_format>
</integration>

3. 日本語での通知メッセージカスタマイズ（上級編）

標準の通知は英語でJSONダンプが送られてくるため、少々見づらいです。より親切な通知（「緊急！〇〇さんのPCでウイルス検知！」など）を行いたい場合は、Pythonスクリプトによるカスタムインテグレーションを作成するのが一般的です。 Wazuhは /var/ossec/integrations/ 配下にスクリプトを配置することで、アラート発生時に任意のプログラムをキックできます。

まとめ：防御の自給自足を始めよう

セキュリティ予算が潤沢な大企業であれば、すべてをお金で解決するのも一つの正解です。しかし、我々SMBにはその選択肢はありません。だからといって「やらない」という選択肢もまた、ランサムウェアの餌食になることを意味します。

Wazuhは、「無料だから機能が低い」というツールではありません。むしろ、使いこなせれば商用製品以上に柔軟で強力な武器になります。まずは余っているPCや安価なVPSにDockerを入れて、小さく始めてみてください。自社のネットワークで何が起きているかが「見える」ようになる体験は、一度味わうと手放せなくなるはずです。

AIに相談するためのプロンプト（テンプレート）

Wazuhを導入したものの、「このログ、どういう意味？」「この誤検知、どうやって消すの？」と迷ったときに、AI（ChatGPT/Claude/Gemini）へ的確に質問するためのプロンプトです。

あなたはWazuhとElasticsearchに精通したセキュリティエンジニアです。
現在運用中のWazuhManagerにおいて、意図しないアラートが発生しており、調整を行いたいです。

# 状況
*   特定の正常な業務アプリケーション（App名: HogeBackup）が、定期実行のたびに「異常なファイルアクセス」として検知されてしまいます。
*   検知されているルールID: 554 (File added to the system)

# ログサンプル (JSON)
{
  "timestamp": "2024-01-24T10:00:00.000+0000",
  "rule": {
    "level": 7,
    "description": "File added to the system.",
    "id": "554"
  },
  "agent": {
    "id": "001",
    "name": "FileServer01"
  },
  "syscheck": {
    "path": "/backup/daily/data.zip",
    "event": "added"
  }
}

# 依頼事項
1.  このアラートがなぜ発報されたのか、ログの内容から技術的な根拠を解説してください。
2.  この特定のパス（/backup/配下）に対して、このルールID(554)の発報を抑制するための `local_rules.xml` の記述例（overwriteまたはexclusion設定）を作成してください。
3.  設定を反映させるために必要なコマンド手順を教えてください。

目次