COLUMN
CMSのセキュリティ点検｜漏えいの入口は新しい技術ではなかった。運営者が毎週確認する5項目
2026年に公表された調査（対象は2025年）で、Webサイトへの侵入口の1位は脆弱性の悪用でした。
Mandiant（M-Trends 2026）で32%、Verizon（DBIR 2026）で31%です。
悪用が始まるまでの時間は、Mandiantの2025年の推定で「マイナス7日」で、パッチが出る前から始まるのが普通になっています。
AIが新しい攻撃を発明したと言われますが、Mandiantは「2025年は侵害がAIの直接の結果だった年とは考えない。成功した侵入の大半は、今も基本的な人の失敗と仕組みの失敗から起きている」と書いています（原文は英語。私の訳）。
CMSを運営する立場から見ると、守る側がやることも、新しい技術ではなく、基本を速く漏れなく続けることだと思います。
件数と規模は分けて見る
個人情報保護委員会の令和7年度年次報告では、事業者から直接報告された漏えい等は13,345件でした。
原因の約81%が、誤交付・誤送付・紛失・誤廃棄です。
不正アクセスは約9%でした。
内訳を見ると、誤交付が6,443件（約48%）、誤送付が3,467件（約26%）、紛失が764件（約6%）です。
不正アクセスは1,256件でした。
割合は、委員会に直接報告された13,345件を母数にして私が計算したものです。
件数は「報告された事案の数」で、漏れた人の数ではありません。
誤交付や誤送付には、病院や薬局の書類、カード類の送付ミスが多く含まれるので、Webサイトの設定ミスの割合ではありません。
ただ、運営者にとって大事なのは、件数ではうっかりのミスが多く、規模の大きい漏えいは基本の抜けを突かれた不正アクセスが中心という点です。
どちらも、新しい防御技術がなくても減らせる部分です。
Webサイトの運営者が受け持つのは、主に後者の不正アクセスの側です。
件数は1割でも、1回で何万人分の情報が出ていくのはこちらなので、下の5項目はそこに絞っています。
最近の事案で、入口が示されたもの
2026年10月に公表された事案のうち、入口が示されたものは2つあります。
ミスターマックスは、公式発表で「第三者が本サービスを構成するソフトウェアの機能を不正に利用してサーバーに侵入した」としています（最大173万5,154人）。
楽天ドライブは、報道によると、管理用アカウントの認証情報が第三者に取得され、その認証情報でシステムに入られました。
どちらも、AIを使った攻撃だったとは報じられていません。
ブックオフや焼肉きんぐのように、入口が調査中の事案も多いので、これだけで傾向までは言えません。
ただ私は、ソフトウェアの守りと、管理アカウントの守りという基本が、そのまま問われた事案だと思います。
毎週確認する5項目
1. 更新を速く入れる
CMS本体、PHP、ミドルウェア、ライブラリの更新を、公開された脆弱性の影響を見てすぐ判断します。
悪用が確認済みのものは、72時間以内の対応を目安にしています。
PHPのサポート終了日は、案件ごとの台帳で把握しておきます。
悪用までの時間が「マイナス7日」というのは、パッチが出た日にはもう攻撃が始まっていることがある、という意味です。
月に1回まとめて更新する運用だと、最長で1か月近く、知られた弱点を開けたままにします。
私たちは毎週月曜に、その週に公開された脆弱性と、悪用が確認されたものの一覧（米国のCISAが公開しているKEVなど）を見て、自分たちの環境に当てはまるものがないかを確かめています。
当てはまらなければ、それで終わりです。
この確認を毎週の決まった作業にしておくと、「急ぎかどうか」の判断に迷う時間が減ります。
2. 公開領域に置いてはいけないものを置かない
.env、.git、SQLのダンプ、.bak・.old・.zip、phpMyAdmin、phpinfo、テスト用ファイル。
これらが外から見える状態は、AIでなくても探せます。
運営者の実験として、何も載せていない「おとり」のサーバーを立てて届く要求を記録していますが、動かし始めてから約2日半で、ログインを試す接続が約1万1千回ありました。
最初の1回は21秒後で、届いていたのは初期設定のパスワードを試す動きや、2021年に見つかったWebサーバーの弱点を突く要求など、古い手口ばかりです。
うちでは自社サイトと個人アプリのURLに、これらのパスを毎週確認しています。
3. 管理画面の入口を固める
ログイン試行の回数制限、接続元のIP制限、可能なら二段階認証です。
IP制限は、X-Forwarded-For を素で信じない作りにします。
ロードバランサーやCDNの配下では、信頼する中継だけを設定します。
このヘッダーは、送る側が自由に書き換えられます。
「社内のIPだけ許可」と設定したつもりでも、ヘッダーをそのまま信じる作りだと、外からでも社内のふりをして入れてしまいます。
Cloudflareの2026年の報告を紹介する記事では、直近3か月のログインの63%が、別の場所で漏れた認証情報を使ったものでした。
ログイン試行の94%はボットからです。
パスワードを推測されにくくするだけでは足りず、入口の回数制限や二段階認証を重ねておく理由はここにあると私は思います。
4. バックアップを、本番と別の場所に持つ
本番と同じサーバー、同じ認証情報の中にだけバックアップがあると、侵入された時に一緒に壊されます。
暗号化して、本番と別の場所に置き、年に一度は実際に復元できるか試します。
復元を試すと、取ったつもりのバックアップに一部のファイルが入っていなかった、ということが分かる場合があります。
毎週見るのは「最後に取れた日時」と「保存先の容量」の2つで十分です。
5. 個人情報は持たない、残さない
収集する項目と保存期間を決めて、不要になったデータは消します。
本番データの写しは、使い終わったら削除します。
残す場合は暗号化します。
私たちは、不具合の調査で本番のデータベースの写しを手元に置いたときは、作業が終わった時点で消しています。
どうしても残す場合は、AES-256で暗号化した圧縮ファイルにします。
開発や動作確認は、本物のデータではなく、項目の形だけを合わせたダミーの値で行います。
持っていないデータは、漏れようがありません。
なぜ「毎週」確認するのか
5項目は、どれも一度設定すれば終わりのように見えます。
でも、実際に崩れるのは設定した後です。
テスト用に置いたファイルを消し忘れる、担当が替わってIP制限の許可リストが古いまま残る、サーバーの移転でバックアップの保存先が変わる。
どれも悪意のない、日々の作業の中で起きます。
攻撃する側は、AIや自動化でこうした抜けを探す速さと量を上げています。
守る側が年に1回の点検だと、その間に開いた穴を1年近く見逃すことになります。
だから私たちは、少なくとも公開領域の確認と脆弱性の確認は、毎週決まった曜日の作業にしています。
残りの3項目も、変わっていないことを見るだけなら、慣れれば数分で終わる量です。
今日できること
全部を一度にやる必要はありません。
まず2番目の「公開領域の確認」を、今週1回やってみてください。
自分のサイトのURLに /.env、/.git/config、/phpmyadmin/ を付けて開き、404か403になることを確認するだけです。
画面に「ページが見つかりません」と出ていても、応答のコードが200のことがあります。
ブラウザの開発者ツールのネットワークの欄で、数字のほうを見てください。
もし中身が表示されたら、そのファイルをすぐ公開領域から外し、中に書かれていたパスワードやAPIキーは漏れた前提で変更します。
消すだけでは、すでに誰かが読んだ可能性が残るからです。
コンテナで標準にしている入口の守り
私たちが作っているCMS「コンテナ」では、3番目の「管理画面の入口」の守りを、追加のプラグインなしで使える標準の機能にしています。
ログインの失敗が続いたアカウントの一時ロック、メールのワンタイムパスワードによる二段階認証、パスキーでのログイン、管理画面に入れるIPアドレスの許可リストです。
管理画面での登録・更新・削除は操作監査ログに残るので、誰がいつ何を変えたかを後から追えます。
※ この記事は、一次資料の調査と下書きをAI（Claude）が行い、数字の確認と公開の判断は人が行っています。