本文へ移動
CASE STUDY 18 / SECURITY GOVERNANCE / WORDPRESS

セキュリティ機能を増やさず、
保守できる構成へ統一する。

防御機能が多いほど安全とは限りません。同じ領域を複数の機能が制御すると、原因の特定と変更が難しくなり、正規の問い合わせまで止める可能性があります。役割を調べ、主軸を決め、業務機能と一緒に検証できる構成を検討します。

THEME
Security Governance
CASE EXAMINED
京都御所西 小川金正堂
PRIMARY CONTROL
All-In-One Security
EVIDENCE STATUS
Audited / Publication Ready
CENTRAL QUESTION

防御機能は、多いほど安全なのか。

WordPressのセキュリティを、機能の追加数ではなく、誰が構成を把握し、競合を特定し、業務を止めずに調整できるかで設計できるか。
CASE CONTEXT

複数の機能が、同じ入口と通信を制御していた。

既存WordPressでは、AIOSとSiteGuardを含む複数のセキュリティ機能が確認されました。

ログイン制御、アクセス制限、Bot対策などの役割が重なり、どの設定が挙動へ影響しているかを追跡しにくい状態でした。2026年6月9日の調査では、ログイン画面へ到達できない挙動についてAIOS側の影響を確認し、SiteGuard停止だけでは状況が変わらないことも確認しました。

その後、AIOSを主軸として構成を整理しました。しかし7月6日には、AIOSのREST API保護がContact Form 7の正規送信を403で止める問題が発生しました。セキュリティを統一した後も、業務機能との両立を検証・調整する必要がありました。

ANALYSIS

安全性は、設定の強さだけでは維持できない。

設定を増やせば遮断対象は増えますが、同時に構成理解、原因特定、更新、例外管理の負荷も増えます。少人数で保守する環境では、防御と運営の両方を確認できることが必要です。

Ownership

どの機能がログイン、通信、フォーム、ファイルを制御するかを一つずつ把握する。

Overlap

同じ役割を複数のプラグインへ持たせず、主軸と補助の境界を決める。

Compatibility

防御設定だけで確認せず、ログイン、フォーム、外部連携を実際に動かす。

Observability

403、警告、ログ、スキャン結果から、影響元を追跡できる状態を残す。

分析上の結論:保守できるセキュリティとは、すべてを遮断する構成ではありません。守る対象と正規の業務通信を区別し、問題発生時に影響元を特定して修正できる構成です。

DECISION FRAMEWORK

把握・統合・検証・調整の四段階。

01

Inventory

プラグイン、サーバー機能、ログイン、API、フォームの制御主体を洗い出す。

02

Consolidate

重複する役割の主軸を決め、不要な制御と管理対象を減らす。

03

Exercise

ログイン、表示、フォーム、外部連携を実際に動かして影響を確認する。

04

Adjust

警告や通信失敗の原因を特定し、必要な通信だけが通るよう再設定する。

IMPLEMENTATION

CASEで行われた構成整理。

4/9〜

既存環境の調査を開始

PHP、プラグイン構成、セキュリティ設定、更新・保守状態を確認し、改善対象を整理しました。

5/31

プラグインと役割を台帳化

利用状況、更新状態、重複機能、削除候補、保守上の注意を記録しました。

6/9

ログイン制御の影響元を切り分け

SiteGuardだけを止めても挙動が変わらず、AIOSを停止すると標準ログイン画面が表示されることを確認し、重複制御の影響元を調査しました。

6/13

AIOSを主軸に構成を統一

セキュリティ機能をAIOSへ整理し、ログインURL、ファイアウォール、REST API、ハニーポット、管理画面からのPHP編集、404監視、重要ファイル権限などを確認・設定しました。

6/13

不要な管理対象を整理

未使用テーマと不要プラグインを整理し、緊急復旧用の標準テーマは一系統残しました。権限スキャンとダッシュボード警告の状態も確認しました。

7/6

正規フォーム通信を止めた設定を再調整

Contact Form 7のREST API通信が403となる原因をAIOSの保護設定へ特定し、一般利用者のTurnstile、Ajax送信、完了表示が成立するよう設定を修正しました。

VERIFIED RESULTS

一次情報で確認できた整理結果。

CONFIRMED / CONSOLIDATED CONTROL

セキュリティ管理の主軸をAIOSへ統一した

重複する制御を調査し、AIOSを中心に管理する構成へ整理した実施記録があります。

Evidence: 取引メッセージ・WordPress保守管理資料 / 2026-06-09〜06-13

CONFIRMED / CONFIGURATION CLEANUP

不要テーマ・不要プラグインを整理した

利用状況と役割を確認したうえで削除対象を整理し、標準テーマは復旧用として一系統残しました。

Evidence: WordPress保守管理資料 Version 1.2 / 2026-06-13

CONFIRMED / WARNING & PERMISSION CHECK

警告解消とファイル権限確認を記録した

ダッシュボード上のファイアウォール警告解消、重要ファイル権限、ファイル/ディレクトリスキャンの確認が記録されています。

Evidence: WordPress保守管理資料 Version 1.2 / 2026-06-13

CONFIRMED / OPERATIONAL COMPATIBILITY

AIOSが止めた正規フォーム送信を復旧した

403の原因をAIOSのREST API保護へ特定し、調整後に一般利用者によるTurnstile、Ajax送信、完了表示を確認しました。

Evidence: Contact Form 7送信不具合調査・修正記録 / 2026-07-06

FINDINGS

保守できる防御構成の実務上の示唆。

追加前に重複を調べる

同じ入口を複数機能で守ると、障害時の影響元が分からなくなります。

主軸を決めて管理対象を減らす

一つの管理面から設定を追跡できることが、継続保守につながります。

防御後に業務を実行する

スコアや警告だけでなく、ログインと問い合わせを実際に通します。

例外ではなく必要通信として管理する

正規のAPI通信が止まった場合、無効化で終えず、用途を確認して制御を調整します。

LIMITS

このCASEが証明しないこと。

  • AIOSがすべてのWordPressサイトに最適であることを示すものではありません。既存構成と運営条件により主軸は変わります。
  • セキュリティスコアや警告解消は、脆弱性が存在しないこと、侵入を完全に防げることを証明しません。
  • 第三者による侵入テスト、脆弱性診断、24時間監視を実施した事例ではありません。
  • サーバー側WAFの全設定を変更・最適化したとは断定しません。確認した項目とWordPress側ファイアウォール調整を分離します。
  • Turnstileの受付設計はCASE STUDY 17、本番反映の告知・確認工程はCASE STUDY 19で扱います。
  • ログインURL、認証情報、具体的な防御値、除外ルールなど、攻撃に利用され得る情報は公開しません。
EVIDENCE AUDIT

調査・統一・設定・障害・再調整を分ける。

主張品質区分根拠・処理
AIOSとSiteGuardの重複を調査した調査事実取引メッセージ・設定確認記録、2026-06-09
AIOS停止時にログイン画面が表示された切り分け結果障害調査記録、2026-06-09。公開時は実URLを非掲載。
AIOSを主軸に統一した判断・実施事実取引メッセージ・保守管理資料、2026-06-09〜06-13
ログイン・API・Bot・権限等を設定・確認した実施・確認事実WordPress保守管理資料 Version 1.2、2026-06-13
AIOSのREST API保護がCF7通信を403にした障害原因送信不具合調査記録、2026-07-06
調整後に一般利用者の送信を確認した修正・利用確認同記録。Turnstile→Ajax→送信→完了表示。
管理対象の統合が保守性を高める分析重複調査、主軸決定、障害特定、再調整の事実から導いた解釈
完全に安全になった立証不能絶対的安全性を主張しない。
サーバーWAFを全面的に再設計した未確認WordPress側調整とサーバー側確認を混同しない。

重要な識別:CASE STUDY 17は問い合わせ受付とTurnstileを含むフォーム運営を研究します。本記事は、その正規通信を止めないためのセキュリティ構成と保守判断を研究します。

研究上の核心:AIOSへの統一後に起きた403を隠さず扱うことで、「統一すれば完成」ではなく、業務機能との継続検証までがセキュリティ運営であることを示します。

公開許可:2026年2月16日の実績公開許可と、2026年6月10日のPROJECT全体公開許可を確認しています。

判定:重複調査、影響元切り分け、AIOSへの統一、構成整理、警告・権限確認、CF7障害原因、再調整後の送信確認まで追跡でき、絶対的安全性と未確認のサーバー設定を除外したPublication Readyです。