本記事は、当社の情報漏洩未然検知サービス「Previento（プレビエント）」の設計の考え方をもとにまとめたものです。記事中のログはすべて説明用に作成した架空のもので、IPアドレスは文書用に予約されたアドレスを使っています。法令・ガイドラインの記載は2026年10月21日時点の公表資料にもとづきます。
画面を通らない2つの漏洩経路
Webサイトの個人情報対策というと、ログイン画面の強化や、SQLインジェクションなど画面への攻撃を防ぐ WAF が思い浮かびます。しかし、個人情報が実際に保存されている場所はデータベース（DB）と、そのバックアップです。ここに画面を通らずに手が届けば、画面側の対策は1つも働きません。
- DBへの直接アクセス——漏れたパスワードや乗っ取ったサーバーを使ってDBに直接接続し、会員テーブルなどを丸ごと読み出す
- バックアップファイルの持ち出し——DBの中身を書き出したファイル（ダンプ）を、置き場所から丸ごとダウンロードする
どちらも、1回成功すれば全件が一度に漏れるのが特徴です。画面から1件ずつ盗み見られるのとは、被害の桁が違います。
個人情報保護委員会は2026年10月7日、大量の個人データが外部からの不正アクセスで漏えいした事案を踏まえ、「大規模な漏えい等事案を踏まえた対応について（注意喚起）」を公表しました。ガイドラインの技術的安全管理措置を見直す予定（確定は2027年4月の予定）で、その内容を先取りして示しています。注目すべきは、これまでの4項目に「(5) 不正アクセス等の検知等」が加わり、ログの保管と定期的な分析、常時監視による早期検知、被害拡大の防止が「講じなければならない措置」として並んだことです。
同日に改訂された「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」でも、不正ログインの事例の原因として「ログの保存・監視についてのルールがなかったため、不正アクセスの検知が遅れた」ことが挙げられています。防ぐ対策に加えて、気づく仕組みを持つことが、はっきり求められるようになりました。
手口1：データベースへの直接アクセス
本来、DBに接続してよいのはWebアプリケーション（Webサーバー）と、ごく一部の管理者だけです。直接アクセスの被害は、この前提がどこかで崩れたときに起きます。入口は主に4つあります。
| 入口 | 何が起きるか |
|---|---|
| DBのポートが外に開いている | MySQL（3306番）などの待ち受けがインターネットから見え、管理者アカウントへのパスワード総当たりを受ける |
| 接続情報の漏洩 | .env や wp-config.php などの設定ファイルから、DBのユーザー名とパスワードが漏れ、正規の情報で接続される |
| Webサーバーの乗っ取り | 侵入されたWebサーバーを踏み台にして、内側からDBへ接続される。Webサーバーに保存された接続情報がそのまま使われる |
| 正規の権限の悪用 | 退職者・委託先のアカウントが残っている、権限が広すぎる、などの理由で、業務の範囲を超えて読み出される |
ログには次のように現れます（MySQL のログを簡略化した例です）。
2026-10-20T02:14:07 Access denied for user 'root'@'203.0.113.45' (using password: YES)
2026-10-20T02:14:08 Access denied for user 'admin'@'203.0.113.45' (using password: YES)
（同じ接続元から、認証の失敗が続く）
2026-10-20T03:41:55 Connect app_user@198.51.100.23 on shopdb using TCP/IP ← 初めて見る接続元
2026-10-20T03:41:56 Query SELECT * FROM members前半は総当たりで、失敗の記録が残るため比較的気づきやすいものです。危ないのは後半です。漏れた正しいパスワードを使われると、失敗の記録は1件も残りません。手がかりは「アプリ用のユーザーが、Webサーバーではない見知らぬ場所から接続してきた」という一点だけです。直接アクセスへの備えは、「どこから接続してよいか」を決め、それ以外を見逃さないことに尽きます。
防止策
- DBのポートをインターネットに公開しない——ファイアウォールやクラウドのセキュリティグループで、接続を許すのはWebサーバーのIPアドレスだけにする。ガイドラインの見直し案でも「事前に許可した特定のIPアドレスからのみに限定」が例示されています
- DBユーザーごとに接続元と権限を絞る——アプリ用ユーザーは接続元ホストをWebサーバーに限定し、必要なテーブル・操作だけを許可する。管理者（root）のリモート接続は無効にする
- 管理者の接続は経路を限定し、多要素認証を使う——VPN や踏み台サーバーを経由させ、外から管理者権限で入る経路をなくす
- 接続情報を守る——設定ファイルを公開領域に置かない。漏洩の疑いがあれば、すぐにパスワードを変更する
- アカウントを棚卸しする——退職・異動・委託終了のたびに削除し、定期的に一覧を見直す
手口2：バックアップファイルの持ち出し
攻撃者から見ると、バックアップファイルはDBより狙いやすい対象です。全件が1ファイルにまとまっていて、DBのパスワードもアクセス制御も関係なく、ファイルを取得できればそれで終わりだからです。しかも、退会した会員や古い取引先など、本来は消しておくべきデータまで含まれていることが少なくありません。
| よくある置き場所 | 持ち出され方 |
|---|---|
| Webの公開領域 | 移行作業や調査のために一時的に置いた backup.sql などを消し忘れ、URLを推測されてダウンロードされる |
| FTPで取得できる場所 | 盗まれたFTPアカウントで、バックアップのフォルダごとダウンロードされる |
| サーバー内のフォルダ | SSHで侵入されたあと、ホームディレクトリなどに置いたダンプをコピーされる |
| クラウドストレージ・NAS | 保存先の公開設定や共有リンクの設定ミスで、外から取得できる状態になっている |
Webの公開領域やFTPからの持ち出しは、ログに次のように現れます。
203.0.113.90 - - [20/Oct/2026:04:12:09 +0900] "GET /db.sql HTTP/1.1" 404 196 "-" "Mozilla/5.0"
203.0.113.90 - - [20/Oct/2026:04:12:09 +0900] "GET /backup.zip HTTP/1.1" 404 196 "-" "Mozilla/5.0"
203.0.113.90 - - [20/Oct/2026:04:12:10 +0900] "GET /backup/db_20261019.sql.gz HTTP/1.1" 200 734003200 "-" "Mozilla/5.0"
（FTPの転送ログ。o はダウンロードを表す）
Tue Oct 20 23:41:12 2026 38 198.51.100.61 524288000 /home/web/backup/full_20261020.sql.gz b _ o r webuser ftp 0 * c1つ目のログでは、ありそうなファイル名を順に試し（404）、3回目で当たって約700MBのファイルに 200 が返っています。攻撃ツールはこうした名前の候補を大量に持っていて、日付入りのファイル名も推測の範囲です。「長いファイル名にしておけば見つからない」は対策になりません。
防止策
- 公開領域・FTPで取得できる場所に置かない——バックアップの保存先は、Webサーバーの公開ディレクトリやFTPのフォルダとは分ける。作業で一時的に置いたら、その日のうちに消す
- 暗号化し、鍵は別に管理する——個人情報保護委員会のガイドライン（通則編）でも、高度な暗号化等の秘匿化がされている場合は、漏えい等報告を要しない例として挙げられています。鍵が同じサーバーにあれば意味がない点に注意します
- 保存する世代と期間を決め、古いものを消す——注意喚起でも、利用する必要がなくなった個人データを遅滞なく消去するよう、改めて求めています
- 保存先へのアクセスを専用アカウントに限る——バックアップを取得・復元できるアカウントを最小限にし、ふだんの作業用アカウントからは読めないようにする
- テスト環境に本番のダンプを持ち込まない——テスト用のデータは、個人データを他のデータに置き換えたものを使う
防止策の全体像：「防ぐ」と「気づく」
2つの手口の防止策を、個人情報保護委員会が示した見直し後の技術的安全管理措置の5項目に当てはめると、次のようになります。
| 技術的安全管理措置 | DBへの直接アクセス | バックアップの持ち出し |
|---|---|---|
| (1) アクセス制御 | 接続元をWebサーバーに限定、権限の最小化 | 保存先へのアクセスを専用アカウントに限定 |
| (2) 識別と認証 | 管理者の多要素認証、アカウントの棚卸し | FTP・SSHのアカウント管理、多要素認証 |
| (3) 外部からの不正アクセス等の防止 | DBポートを公開しない、ソフトの更新 | 公開領域に置かない、保存先の公開設定の確認 |
| (4) 使用に伴う漏えい等の防止 | 接続情報の保護、通信の暗号化 | バックアップの暗号化、テストデータの置き換え |
| (5) 不正アクセス等の検知等 | ログの保管と分析、常時監視による早期検知、被害拡大の防止（遮断・アカウントの無効化） | |
(1)〜(4) は「防ぐ」ための対策です。ただし、防ぐ対策には必ず穴が残ります。消し忘れた1つのファイル、退職者の残ったアカウント、どこかで漏れたパスワード——どれも、ふだんの運用の中で起きることです。(5) は、その穴を通られたときに全件が持ち出される前に気づき、止めるための対策で、今回の見直しで独立した項目になりました。
Previento の監視で止める
当社の「Previento（プレビエント）」は、この (5) を担うクラウド型の監視サービスです。Webサーバー・DBサーバーのログを24時間読み取り、2つの手口の兆候を次のように検知します。
| 兆候 | Previento の検知 |
|---|---|
| DBへの認証失敗が続く | 「DB認証失敗の連続」として通知 |
| 見知らぬ場所からDBに接続された | 「DBへの未知の接続元」として通知。正しいパスワードで接続されても検知できる。ログイン状況の画面で、DBの接続元を「信頼済み」「要確認」に分けて一覧表示 |
| サーバーへの不審なログイン | 未知の接続元からのSSHログイン、失敗が続いたあとの成功、深夜のログインを検知。DBの踏み台にされる前の段階で気づける |
| アカウントの作成・管理コマンド | ユーザーの作成・変更と、管理者権限（sudo）での操作を記録 |
| バックアップファイルへのアクセス | .sql・.sql.gz・.zip・/backup などへのアクセスを検知。200 が返った（取得された）ら「攻撃が成功した疑い」として通知し、ファイル名の探索を重ねたあとの取得は重大として扱う |
| 大量のデータが送られた | 同じ接続元への短時間の大量転送を「大量データ取得の疑い」として重大で通知。FTPでの大量ダウンロードも検知 |
| 攻撃のあとの大量取得 | 同じ接続元の「攻撃 → 成功の兆候 → 大量取得」をつなぎ、「データ持ち出しの疑い」として重大で通知 |
検知はLINE・Slack・メールへ即時に届き、必要に応じてアクセスを自動で遮断します。管理画面では、検知ごとに「何が起きているか」「今すぐやること」を確認でき、同じ接続元の前後のログもたどれます。手口1の後半の例のように、失敗の記録が残らない接続でも、「いつもと違う場所から来た」ことに気づければ、全件を持ち出される前に接続元を遮断し、パスワードを変更するところまで進められます。
Previento で見えないこと
Previento は、DBの中のデータを取得しません。判定に使うのは、接続・認証の記録やWebサーバーのアクセスログ、FTPの転送ログなどです。そのため、「どのSQLで、どの行を読んだか」の監査は対象外で、必要な場合はDBの監査ログ機能と組み合わせます。また、SSHでログインしたあとのファイルのコピーは転送量のログに残りにくいため、その手前の「不審なログイン」の段階で気づく設計にしています。なお、検知のしきい値は回避の手がかりになるため公開していません。
管理画面・料金・導入の流れは Previento の製品ページ で紹介しています。初期費用0円、月額3万円〜（税別）、最短3営業日で稼働します。
よくある質問（FAQ）
- Q. データベースをインターネットに公開していなければ、直接アクセスの心配はありませんか？
- A. 外部に公開しないことはもっとも効果のある対策ですが、それだけでは十分ではありません。Webサーバーが乗っ取られると、Webサーバーに保存されたデータベースの接続情報を使って、内側から接続されます。接続元を絞ったうえで、ふだんと違う接続元や、Webサーバーへの不審なログインを監視するのが安全です。
- Q. バックアップを暗号化していれば、持ち出されても問題ありませんか？
- A. 暗号化は被害を大きく減らします。個人情報保護委員会のガイドラインでも、漏えいした個人データに高度な暗号化等の秘匿化がされている場合は、漏えい等報告を要しない例として挙げられています。ただし、復号の鍵が同じサーバーに置かれていれば意味がありません。鍵を別に管理することと、持ち出しそのものに気づく監視の両方が必要です。
- Q. Previento は、データベースの中の個人情報を見ますか？
- A. いいえ。Previento はデータベースの中のデータを取得せず、接続・認証の記録やWebサーバーのアクセスログをもとに判定します。そのため、どのSQLでどのデータを読んだかまで記録・監査したい場合は、データベースの監査ログ機能と組み合わせてください。
まとめ
個人情報の大量漏洩は、Webの画面を通らない2つの経路——DBへの直接アクセスとバックアップファイルの持ち出し——で起きることがあります。どちらも1回の成功で全件が漏れ、漏れた正しいパスワードや、置き忘れた1つのファイルがあれば、画面側の対策はすり抜けられます。
防止の基本は、DBに接続できる場所を絞ること、バックアップを公開領域に置かず暗号化し、不要になったら消すことです。そのうえで、個人情報保護委員会が見直し案で独立した項目にした「不正アクセス等の検知等」——ログを見て、いつもと違う接続や取得に気づき、止める仕組みを持つことが、最後の備えになります。
当社の「Previento」は、この検知と遮断を、初期費用0円・月額3万円〜（税別）で始められるサービスです。「DBやバックアップがどこから触れる状態か分からない」「ログはあるが誰も見ていない」という段階のご相談も歓迎です。