LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Wazuhとは何か、SIEM/XDRとしての位置づけ

Wazuhとは、ログ収集・脅威検知・コンプライアンス支援を1つの基盤に統合したオープンソースのセキュリティ監視プラットフォームである。Wazuh公式は自社をSIEM（Security Information and Event Management、セキュリティ情報イベント管理）とXDR（Extended Detection and Response、拡張型検知・対応）の機能を統合した無償のオープンソースプラットフォームと位置づけている^*1。

SIEMは複数システムのログを集約し相関分析で脅威を検知する仕組み、XDRはエンドポイント・ネットワーク・クラウドなど複数レイヤーの検知情報を統合して対応する仕組みである。Wazuhはこの2領域を単一の無償OSSで提供する点が特徴と言えます。エージェント方式でエンドポイントを継続監視し、収集データを中央のサーバーで解析する構造を採用しています^*1。

ライセンスはGPLv2（GNU General Public License version 2）で、ソースコードはGitHub上で公開されています^*2。OSSEC（オープンソースのホスト型侵入検知システム）を前身として開発が進められた経緯があり、無償で利用できる範囲はプラットフォーム本体そのものです。専門的なサポート・トレーニング・コンサルティングやクラウドホスティングは、Wazuh Inc.が有償サービスとして別途提供しています^*1。

indexer・server・dashboard・agentの4要素構成

Wazuhの構築を検討する際に最初に理解すべきは、中央コンポーネントとエージェントという2層構造です。中央コンポーネントは「Wazuh indexer」「Wazuh server」「Wazuh dashboard」の3つに分かれ、監視対象の端末には「Wazuh agent」を配置します^*3。

Wazuh agentは監視対象のエンドポイントに常駐し、イベントを継続的にWazuh serverへ送信する役割を担います^*3。マルチプラットフォーム対応で、サーバー・ワークステーション・クラウドインスタンスなど幅広い環境に配置できます。Wazuh serverは受信したイベントをデコードし、ルールと照合して脅威を検出する中核部分です。エージェントからの接続はTCP 1514ポートで受け付けます^*3。

Wazuh indexerはサーバーが生成したアラートデータをFilebeat経由で受け取り、保存・索引化を担う要素です。TCP 9200ポートで通信します^*3。Wazuh dashboardはこのindexerに問い合わせて、アラートの可視化とセキュリティイベントの調査を行うWebインターフェースであり、HTTPS 443ポートでアクセスします^*3。この4要素をどう配置するかで、構築の難易度と運用負荷が変わってきます。

デプロイ方式は仮想マシン・AMI（Amazon Machine Image）・Docker・Kubernetesなど複数の選択肢があり、Ansibleなどのオーケストレーションツールで自動化することも可能です^*4。オンプレミスでのセルフホストに加え、Wazuh Inc.が提供する有償のクラウドサービス（Wazuh Cloud）を利用する選択肢もあります^*4。

ログ収集からFIM・侵入検知まで、検知機能の中身

Wazuhの検知機能の土台になっているのはログデータ分析です。OS・アプリケーションのログを収集・解析し、異常なパターンやセキュリティイベントを抽出します^*1。この上に、より専門的な検知モジュールが積み重なる構成になっています。

ファイル完全性監視（FIM、File Integrity Monitoring）は代表的なモジュールの一つです。監視対象ファイルの暗号化チェックサムと属性を記録してベースラインを作成し、ファイルが変更されるとそのチェックサムと属性をベースラインと比較して不一致を検出する仕組みです^*5。リアルタイムスキャンとスケジュールスキャンの両方に対応し、システムファイル・設定ファイル・Windowsレジストリ・ディレクトリ構造全体を監視対象にできます^*5。ファイルの変更が誰によって、いつ、どのように行われたかを追跡できるため、不正な変更の検出と規制遵守の証跡確保の両方に役立ちます^*5。

侵入検知（HIDS、Host-based Intrusion Detection System）の系譜も持っており、Wazuhの前身であるOSSECがホスト型侵入検知システムとして開発された経緯からも分かるように、エンドポイント上の不審な挙動やマルウェア・ルートキットの検知を担う機能です^*2。脅威ハンティング機能ではMITRE ATT&CK（攻撃者の戦術・技術を体系化したフレームワーク）へのマッピングも提供され、検知したイベントがどの攻撃手法に該当するかを可視化できます^*1。

これらの機能はいずれもagentが収集したデータをserverが解析するという同じ流れの中で動作するため、監視対象を増やすほどserver側の処理負荷とルール調整の工数が増える点は見落とされがちです。

脆弱性検知とコンプライアンス対応の仕組み

脆弱性検知はWazuhの実務的な価値が出やすい機能です。Wazuh agentが監視対象エンドポイントにインストールされているアプリケーションの一覧（ソフトウェアインベントリ）を収集し、Wazuh serverへ送信します^*6。

サーバー側ではこのインベントリ情報を、Wazuh CTI（Cyber Threat Intelligence）プラットフォーム内の脆弱性リポジトリと相関させて既知の脆弱性を洗い出します^*6。インターネットに接続できない環境向けには、このリポジトリのローカルコピーを使うオフライン脆弱性リポジトリの選択肢も用意されています^*6。CVE(共通脆弱性識別子)ベースでインストール済みソフトウェアを継続的に照合できるため、パッチ適用の優先順位づけに使いやすい仕組みと言えます。

コンプライアンス対応の面では、Wazuhはセキュリティ設定評価（SCA、Security Configuration Assessment）機能でシステムとアプリケーションの設定を継続的にチェックし、セキュリティポリシーへの準拠状況を確認します^*1。公式サイトはPCI DSS（クレジットカード業界の国際的なセキュリティ基準）・NIST（米国国立標準技術研究所の基準群）・HIPAA（米国の医療情報保護に関する法律）といった規制・基準への対応を掲げています^*1。

ただし、これらの基準への対応は「基準の要求事項に紐づく検知ルールセットが用意されている」という意味であり、Wazuhを導入するだけで認証や監査を自動的に通過できるわけではありません。ルールセットの適用範囲確認と、監査で求められる証跡の整備は運用側の作業として残ります。

商用SIEMとの違い、Wazuhを選ぶ判断基準

Splunkなど商用SIEMとの違いを整理すると、ライセンス費用の構造がまず挙げられます。商用SIEMはデータ取り込み量やノード数に応じたライセンス費用が発生する一方、Wazuhはプラットフォーム本体が無償のOSSです^*1。この違いはコスト構造だけでなく、運用体制の作り方にも影響します。

この比較から分かるように、Wazuhを選ぶ判断基準はライセンス費用の有無だけではありません。構築・チューニング・監視対応を誰が担うのかという運用体制の設計が、実質的な総コストと検知精度を左右します。

構築で見落としやすい落とし穴とセルフホスト運用の負荷

Wazuhをセルフホストで構築する場合、内製で担うには複数領域の知識が要ります。具体的には、Linuxサーバー運用・OpenSearch（indexerの基盤技術）のクラスタ管理・TLS証明書の設定・検知ルールとデコーダのチューニング・エージェント配布と鍵管理といった領域です。これらを1名で網羅するのは現実的ではなく、複数名での体制構築が前提になります。

構築時に見落とされがちな点として、ルールとデコーダの初期設定がそのままでは自社環境に最適化されていないことが挙げられます。デフォルトルールセットのままでは誤検知（false positive）が積み重なり、アラート疲れを招いて本当に重要な検知を見逃す事態につながりかねません。自社のログ形式・業務パターンに合わせたチューニングは、構築後も継続的に発生する作業です。

indexerの容量設計を誤ると、ログ量の増加に伴いディスクを圧迫し、検索性能が劣化する事態も起こり得ます。ログの保持期間とストレージ容量のバランス設計、インデックスのライフサイクル管理も運用開始前に決めておく必要がある論点です。加えて、agentとserver間の通信が何らかの理由で切れた場合の監視体制、Wazuh本体および依存コンポーネントのバージョンアップ対応も、セルフホストでは自社の責任範囲になります。

これらの作業を後回しにすると、監視基盤自体が「アラートを出すだけで誰も見ていない」状態に陥るリスクがあります。SIEM/XDR基盤は導入した時点で終わりではなく、日々のチューニングと運用体制の維持が検知精度を保つ前提条件です。

内製と外注、どちらを選ぶべきかの判断軸

内製でWazuh基盤を構築・運用するには、前述のとおりLinux・OpenSearch・ネットワーク・セキュリティルールの知識を持つ人材が複数名必要になります。担当者が既存業務と兼務する体制では、初期構築は乗り切れても、継続的なチューニングとアラート監視までは手が回らなくなるケースが少なくありません。

専門パートナーに構築・運用を委託する場合との違いを整理すると、パートナー側は複数の構築経験に基づいたルールセットの初期チューニング指針を持っている点、24時間監視体制の構築を含めて相談できる点が挙げられます。一方で内製には、自社のシステム構成や業務知識を反映した検知ルールを直接調整できる速さという利点もあるでしょう。どちらが正しいという話ではなく、自社の体制と目的に応じた選択が求められます。

判断軸として整理すると、第一に確保できる人員と専門知識の有無、第二に24時間監視体制を自社で維持できるかどうか、第三に構築後のチューニングを継続する運用サイクルを描けているかどうかです。これらのいずれかが不足する場合は、構築フェーズだけを外部に委託する、または運用フェーズも含めて委託するという段階的な選択肢を検討する価値があります。

まとめ：Wazuhの構築・運用を検討する際の3つの判断軸を整理します。第一に、Wazuhはindexer・server・dashboard・agentの4要素からなるオープンソースのSIEM/XDR基盤で、ログ収集・FIM・侵入検知・脆弱性検知・コンプライアンス支援を1つの基盤でカバーできる点です。第二に、商用SIEMと比べてライセンス費用は抑えられる一方、構築・チューニング・運用の負荷は自社の責任範囲として残ります。第三に、必要な専門知識と24時間監視体制を自社で維持できるかどうかが、内製か外注かを分ける実質的な判断基準になるという点です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Wazuh「Wazuh – The Open Source Security Platform」（wazuh.com/platform/）
2. *2　出典：Wazuh「wazuh/wazuh GitHubリポジトリ」（github.com/wazuh/wazuh）
3. *3　出典：Wazuh documentation「Architecture」（documentation.wazuh.com/current/getting-started/architecture.html）
4. *4　出典：Wazuh documentation「Deployment options」（documentation.wazuh.com/current/deployment-options/index.html）
5. *5　出典：Wazuh documentation「File integrity monitoring」（documentation.wazuh.com/current/user-manual/capabilities/file-integrity/index.html）
6. *6　出典：Wazuh documentation「Vulnerability detection」（documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/index.html）

Tweet