モデルケースについて——本ページは、当社の技術・製品（Previento / GENBA Gate / クラウド・組込の構築）で構成した架空の事例です。業種・規模・システム構成は典型例として設定したもので、実在の企業・案件とは関係ありません。攻撃の手口は、防御のために一般に知られている範囲で記載しています。
想定するシステムと課題
近畿圏に実店舗を持つ小売業で、自社ECサイト（PHP製のECパッケージ＋WordPressの特集ページ）を運用しているモデルケースです。会員数は数万人規模、サイトは制作会社が構築し、運用は社内の兼任担当者1名。サーバーのアクセスログは保存されていますが、誰も見ていませんでした。
きっかけは、同業他社の個人情報漏えいの報道でした。「うちは大丈夫か」を確かめたいが、WAFを入れればよいのか、監視を入れればよいのか、何から手を付ければよいかが分からない、というご相談を想定しています。
AIによる攻撃は、こう来る
ATTACK SCENARIO
- 偵察——ECパッケージとWordPressのバージョンを、公開されているファイルのパスや応答ヘッダーから機械的に特定する。会社を選んではいない
- 既知の脆弱性の試行——古いプラグインの脆弱性を突く要求や、SQLインジェクションの文字列を、ツールが数分間に数百件送る。WAFがあれば大半はここで止まる
- すり抜け——WAFのパターンを少し変えた要求が1件だけ通り、アップロード領域に
.phpのファイル（Webシェル）が置かれる - 足場づくり——Webシェル経由でDBの接続情報を読み、会員情報のテーブルを確認する
- 持ち出し——注文番号を1ずつ変えて注文ページを数千件取得する（連番IDの総なめ）。どれも「ふつうのアクセス」に見える
この流れで厄介なのは、段階3以降がWAFでは止めにくいことです。Webシェルへのアクセスも、連番IDの取得も、攻撃の文字列を含まない正規の形のHTTP要求だからです。入口の防御だけでは、「通り抜けた1回」に気づけません。
課題と解決アプローチ
⚠ CHALLENGE（課題）
- PHP 7.4（サポート終了）と古いプラグインが本番で稼働
- WAFなし。設定ファイルやバックアップが公開領域に残存
- アクセスログは保存のみで、誰も見ていない
- 会員情報ページの権限確認が、一部の画面で漏れている
- 専任のセキュリティ担当がいない
→
✅ SOLUTION（解決策）
- 読み取り診断で穴を一覧化し、公開中かつ危険なものから対応
- PHP 8.3 系へ更新、不要プラグイン削除、公開領域の掃除
- WAF（クラウド型）を入口に設置、管理画面はIP制限
- Previento で攻撃の成功判定・Webシェル検知・連番ID監視を24時間
- 重大判定は自動遮断、LINE・Slackへ即時通知。兼任担当でも判断できる解説付き
防御の構成（従来型の層 ＋ AIの層）
インターネット（自動スキャン・攻撃ツール） │ ▼ [入口] クラウド型 WAF ── 既知の攻撃パターン・スキャナを遮断 │ 管理画面 /wp-admin・/admin は 保守元IPのみ許可 ▼ Webサーバー（PHP 8.3 / Apache） ├─ [公開範囲] php.ini-production 適用、.env・バックアップは公開領域外 ├─ [公開範囲] アップロード領域での PHP 実行禁止 └─ [監視] Previento エージェント ── アクセスログ・認証ログ・公開ディレクトリの変化を収集 │ ▼ Previento（クラウド） ├─ 攻撃の試行と 成功の兆候 を区別（応答サイズ・ステータスを比較） ├─ アップロード領域の .php 新規設置・Webシェルの特徴を検知 ├─ 同じIPの 連番ID 大量取得・個人情報ページへの集中アクセスを検知 ├─ 「偵察 → 攻撃 → 成功 → 大量取得」を同じIPで 時系列相関 └─ 重大 → 自動遮断 ＋ LINE / Slack / メール通知 DBサーバー（MySQL） ── [公開範囲] FW で Web サーバーからのみ接続可
凡例：緑＝従来型の防御（ファイアウォール・WAF・VPN・認証・分離）／青＝AIによる監視・判定（Previento）／赤＝攻撃
AIは、ここで何を判定するのか
- 「試行」と「成功」を分ける——SQLインジェクションの文字列を含む要求に 200 が返っても、応答サイズがそのページのふだんと同じなら「値は無視された」とみなして重大にしない。WAFの検知件数を毎日通知しても誰も見なくなるため、通知は成功の兆候に絞る
- ファイルの変化を見る——アクセスログだけではWebシェルは見落としやすい。公開ディレクトリのスクリプトが増えた・変わったこと自体を検知し、
eval(base64_decode(…))のような特徴を持つ記述を探す - 正規の形のアクセスの「量と形」を見る——連番IDの総なめは攻撃文字列を含まない。同じIPが同じ形のURLで異なるIDを短時間に大量取得している、という「形」で検知する
- 同じIPの前後をつなぐ——1行ずつでは「よくある試行」でも、「偵察 → 攻撃 → 成功の兆候 → 大量取得」と並べると侵害の進行が見える。この流れを「侵害の疑い」「データ持ち出しの疑い」として1件にまとめて通知する
AIが判定するのは「兆候」です。通知には、そのIPの前後のログ、「何が起きているか」「放置するとどうなるか」「今すぐやること」「誤検知の可能性」が添えられ、兼任の担当者が数分で事実を確認し、当社に相談できる状態にします。自社の固定IPや保守会社の接続元は「信頼済み」に登録し、誤検知を減らします。
導入ステップ（想定）
Week 1
読み取り診断
PHP・ECパッケージ・プラグインのバージョン、php.ini の設定値、公開領域のファイル、権限確認の漏れを読み取りで確認。高・中・低で報告
Week 2
暫定策
管理画面のIP制限、公開領域の設定ファイル・バックアップの除去、不要プラグインの削除。本番停止なし
Week 3-6
PHP更新とWAF設置
検証環境でPHP 8.3 へ更新し、非互換の修正と動作確認。WAFを設置し、誤検知を見ながら遮断モードへ移行
Week 4
Previento 導入
エージェント設置、通知先（LINE・Slack）と自動遮断のルールを当社が初期設定。信頼済みIPの登録
Week 7〜
継続
検知のしきい値調整、月次の検知レポート、PHP・プラグインのサポート期限の管理と再診断