WordPressのSOC連携：セキュリティ監視チームに送るログと対応手順の決め方

SOC（Security Operations Center）は、ログを常時監視して攻撃の兆候を見つけ、分析と対応の指示を行うチームや体制のことです。社内に置く場合も、外部の監視サービスに委託する場合もあります。WordPress サイトを SOC の監視対象にするとき、WordPress 側に「SOC 連携」という標準機能や設定画面はありません。連携の実体は、次の2つです。

• SOC が使うログ収集基盤（SIEM など）に、WordPress とサーバーのログを送ること
• アラートが出たときに、誰が何をするかを取り決めておくこと

この記事では、この2つを WordPress の運用担当者の立場で準備する手順を説明します。コードと設定は2026年10月時点の WordPress 6.x・PHP 8.x・rsyslog（Ubuntu / Debian 系）で確認できる仕様に基づいています。

連携の前に SOC と決めること

ログを送り始める前に、次の項目を SOC（または委託先）と文書で取り決めます。ここが曖昧なままだと、アラートが出ても誰も動けません。

WordPress まわりで集めるログ

WordPress 本体は、ログインやユーザー操作の履歴をファイルに残しません。操作ログが必要な場合は、監査ログ用のプラグインを使うか、フックを使って自分で書き出します。プラグインで記録する方法は WordPressのセキュリティ監査ログを設定する方法 を参照してください。ここでは、SOC に転送しやすいように syslog へ1行の JSON で書き出す方法を紹介します。

手順1: WordPress の操作を syslog に書き出す

次のファイルを wp-content/mu-plugins/soc-event-logger.php として置きます（mu-plugins ディレクトリが無ければ作ります）。mu-plugin は管理画面から無効化できないため、監視用のコードに向いています。

<?php
/**
 * Plugin Name: SOC Event Logger
 * Description: ログイン・ユーザー・プラグインの操作を syslog に JSON で書き出す。
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

function soc_log_event( $event, array $data = array() ) {
	$record = array_merge(
		array(
			'app'   => 'wordpress',
			'site'  => home_url(),
			'event' => $event,
			'ip'    => isset( $_SERVER['REMOTE_ADDR'] ) ? $_SERVER['REMOTE_ADDR'] : '',
			'time'  => gmdate( 'c' ),
		),
		$data
	);
	openlog( 'wordpress', LOG_PID, LOG_AUTH );
	syslog( LOG_NOTICE, wp_json_encode( $record ) );
	closelog();
}

add_action( 'wp_login', function ( $user_login, $user ) {
	soc_log_event( 'login_success', array( 'user' => $user_login, 'user_id' => $user->ID ) );
}, 10, 2 );

add_action( 'wp_login_failed', function ( $username ) {
	soc_log_event( 'login_failed', array( 'user' => $username ) );
} );

add_action( 'user_register', function ( $user_id ) {
	soc_log_event( 'user_created', array( 'user_id' => $user_id ) );
} );

add_action( 'set_user_role', function ( $user_id, $role, $old_roles ) {
	soc_log_event( 'role_changed', array( 'user_id' => $user_id, 'role' => $role, 'old_roles' => $old_roles ) );
}, 10, 3 );

add_action( 'activated_plugin', function ( $plugin ) {
	soc_log_event( 'plugin_activated', array( 'plugin' => $plugin ) );
} );

add_action( 'deactivated_plugin', function ( $plugin ) {
	soc_log_event( 'plugin_deactivated', array( 'plugin' => $plugin ) );
} );

使っているフックは、いずれも WordPress 本体のアクションです。

ファシリティを LOG_AUTH、識別子を wordpress にしているので、Debian / Ubuntu の標準設定では /var/log/auth.log に記録されます。確認するには、わざと間違ったパスワードでログインしてから次を実行します。

sudo grep 'wordpress' /var/log/auth.log | tail -n 5

CDN やリバースプロキシの後ろにあるサイトでは、REMOTE_ADDR がプロキシの IP になります。その場合は、プロキシが付ける X-Forwarded-For などを信頼できる経路からのものだけ使うよう、サーバー側で実際のクライアント IP を復元する設定（Nginx の real_ip モジュール、Apache の mod_remoteip）を先に行ってください。ヘッダーを無条件に信用すると、攻撃者が IP を偽装できます。

手順2: rsyslog で SOC の収集サーバーへ転送する

SOC が専用のエージェントを指定している場合はその手順に従います。syslog での受け取りに対応している場合は、rsyslog の転送設定を追加します。/etc/rsyslog.d/60-soc.conf の例です。siem.example.com と 514 は SOC から指定された宛先に置き換えます。

# Web サーバーのアクセスログをファイルから読み込む
module(load="imfile")
input(type="imfile" File="/var/log/nginx/access.log" Tag="nginx-access:")

# WordPress の操作ログとアクセスログを TCP で転送する（送れない間はディスクに溜める）
if $programname == 'wordpress' or $programname == 'nginx-access' then {
    action(type="omfwd" target="siem.example.com" port="514" protocol="tcp"
           queue.type="LinkedList" queue.filename="soc_fwd"
           queue.saveOnShutdown="on" action.resumeRetryCount="-1")
}

Apache の場合は File を /var/log/apache2/access.log にします。設定の文法を確認してから再起動します。

sudo rsyslogd -N1
sudo systemctl restart rsyslog
logger -t wordpress '{"event":"soc_test"}'

最後の logger はテスト用のメッセージです。SOC 側でこのメッセージが届いたことを確認してもらいます。

上の例は平文の TCP です。インターネット越しに送る場合は、rsyslog の TLS 設定や VPN など、SOC が指定する暗号化の方法を使ってください。rsyslog の転送設定の詳細は rsyslogでログをリモートサーバーに転送する方法 で説明しています。SIEM 側の取り込みについては WordPressのSIEM連携方法 も参照してください。

手順3: ファイル改ざんの点検結果も送る

WP-CLI の verify-checksums は、WordPress 本体と WordPress.org 配布のプラグインのファイルを公式のチェックサムと照合します。cron で定期実行し、結果を syslog に流しておくと、改ざんの兆候も SOC が見られます。

# crontab -e（WordPress のファイル所有者で実行。毎日 3:00）
0 3 * * * cd /var/www/html && wp core verify-checksums 2>&1 | logger -t wordpress-integrity
10 3 * * * cd /var/www/html && wp plugin verify-checksums --all 2>&1 | logger -t wordpress-integrity

この識別子（wordpress-integrity）も転送したい場合は、手順2の条件に or $programname == 'wordpress-integrity' を加えます。WordPress.org 以外で配布されている有料プラグインなどは照合できないため、警告として出ます。

手順4: アラートの条件を決める

SOC と相談して、検知したら通知する条件を決めます。WordPress でよく使われる例です。

更新作業や担当者の追加など、予定された作業でもアラートが出ます。作業の予定を SOC に事前連絡する手順も決めておくと、誤検知の確認が早く済みます。

手順5: アラートを受けた後の手順を用意する

SOC から連絡を受けたときに、サイト側で行う作業を手順書にしておきます。例として、不審なログインの連絡を受けた場合です。

1. 連絡の内容（日時、IP、ユーザー名）と、操作ログ・アクセスログを照合して事実を確認する。
2. 管理者ユーザーの一覧を確認し、見覚えのないユーザーがいないか調べる。
3. 対象ユーザーのパスワードを変更し、ログイン中のセッションを破棄する。
4. 調査のため、ログとファイルを変更前の状態で保存する。
5. 侵入の可能性が高い場合は、初動対応の手順に移る。

手順2と3で使う WP-CLI のコマンドです。

# 管理者の一覧
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 対象ユーザーのセッションをすべて破棄（ユーザー名は実際のものに置き換える）
wp user session destroy example_user --all

侵入が疑われる場合の隔離・証拠保全・復旧の順番は、サーバーがハッキングされた時の初動対応手順 にまとめています。

注意点

• サーバーの時刻がずれていると、SOC 側で複数のログを突き合わせられません。timedatectl で NTP 同期が有効になっているか確認してください。
• ログには IP アドレスやユーザー名など、個人に関わる情報が含まれます。送る範囲と保存期間を取り決め、プライバシーポリシーとの整合も確認してください。
• アクセスログは量が多くなります。SOC 側の料金や容量の上限がログ量で決まる場合は、送る範囲を相談してください。
• ログを送るだけでは攻撃は止まりません。総当たり攻撃の自動遮断などは、サーバー側でも併用します（WordPressのFail2Banでブルートフォースを防ぐ方法）。

まとめ

• WordPress に SOC 連携の標準機能は無く、連携とは「ログを SOC に送ること」と「アラート後の役割分担を決めること」。
• 送るログは、アクセスログ・PHP エラーログ・WordPress の操作ログ・OS の認証ログが基本。WordPress の操作ログはフック（wp_login_failed など）で syslog に書き出せる。
• 転送は SOC が指定する方法に合わせ、syslog の場合は rsyslog の omfwd と暗号化を使う。
• アラート条件と、連絡を受けた後のサイト側の手順を文書にしておく。

関連記事:

• WordPressのアクセスログを解析してセキュリティ侵害を早期に見つける方法