# DBへの直接アクセスとバックアップ持ち出しを防ぐ｜個人情報漏洩の2つの手口と、監視で止める方法｜株式会社テクノスフィア

> 個人情報は、Webの画面を経由せず、データベースへの直接接続やバックアップファイルの持ち出しで丸ごと漏れることがあります。2つの手口の入口とログに残る痕跡、個人情報保護委員会が2026年10月に示した安全管理措置の見直し内容に沿った防止策、監視サービス「Previento」で被害が広がる前に気づき止める方法を解説します。

URL: https://technosphere.co.jp/blog/db-backup-data-leak-prevention

** 目次
1. 画面を通らない2つの漏洩経路
2. 手口1：データベースへの直接アクセス
3. 手口2：バックアップファイルの持ち出し
4. 防止策の全体像：「防ぐ」と「気づく」
5. Previento の監視で止める
6. よくある質問（FAQ）
7. まとめ
   ** 本記事について

本記事は、当社の情報漏洩未然検知サービス「[Previento](https://technosphere.co.jp/previento)（プレビエント）」の設計の考え方をもとにまとめたものです。記事中のログはすべて**説明用に作成した架空のもの**で、IPアドレスは文書用に予約されたアドレスを使っています。法令・ガイドラインの記載は2026年10月21日時点の公表資料にもとづきます。

## 画面を通らない2つの漏洩経路

 Webサイトの個人情報対策というと、ログイン画面の強化や、SQLインジェクションなど画面への攻撃を防ぐ WAF が思い浮かびます。しかし、個人情報が実際に保存されている場所は**データベース（DB）と、そのバックアップ**です。ここに画面を通らずに手が届けば、画面側の対策は1つも働きません。
- **DBへの直接アクセス**——漏れたパスワードや乗っ取ったサーバーを使ってDBに直接接続し、会員テーブルなどを丸ごと読み出す
- **バックアップファイルの持ち出し**——DBの中身を書き出したファイル（ダンプ）を、置き場所から丸ごとダウンロードする

 どちらも、1回成功すれば**全件が一度に漏れる**のが特徴です。画面から1件ずつ盗み見られるのとは、被害の桁が違います。

 個人情報保護委員会は2026年10月7日、大量の個人データが外部からの不正アクセスで漏えいした事案を踏まえ、[「大規模な漏えい等事案を踏まえた対応について（注意喚起）」](https://www.ppc.go.jp/files/pdf/261007_alert_dataleakage.pdf)を公表しました。ガイドラインの技術的安全管理措置を見直す予定（確定は2027年4月の予定）で、その内容を先取りして示しています。注目すべきは、これまでの4項目に**「(5) 不正アクセス等の検知等」**が加わり、ログの保管と定期的な分析、常時監視による早期検知、被害拡大の防止が「講じなければならない措置」として並んだことです。

 同日に改訂された[「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」](https://www.ppc.go.jp/files/pdf/261007_warning.pdf)でも、不正ログインの事例の原因として「ログの保存・監視についてのルールがなかったため、不正アクセスの検知が遅れた」ことが挙げられています。**防ぐ対策に加えて、気づく仕組みを持つこと**が、はっきり求められるようになりました。

## 手口1：データベースへの直接アクセス  （図: 本来の通り道であるWebサーバーの建物を経由せず、外から伸びたオレンジ色のケーブルがデータベースの裏口に直接つながり、人のアイコンのカードが列になって流れ出しているイメージイラスト）

 本来、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：バックアップファイルの持ち出し  （図: サーバーの横の棚に圧縮ファイルの箱が並び、そのうちの1つが鍵のかかっていない扉からオレンジ色の台車で運び出されているイメージイラスト）

 攻撃者から見ると、バックアップファイルは**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 * c
```

 1つ目のログでは、ありそうなファイル名を順に試し（404）、3回目で当たって**約700MBのファイルに 200 が返っています**。攻撃ツールはこうした名前の候補を大量に持っていて、日付入りのファイル名も推測の範囲です。「長いファイル名にしておけば見つからない」は対策になりません。

### 防止策
- **公開領域・FTPで取得できる場所に置かない**——バックアップの保存先は、Webサーバーの公開ディレクトリやFTPのフォルダとは分ける。作業で一時的に置いたら、その日のうちに消す
- **暗号化し、鍵は別に管理する**——個人情報保護委員会の[ガイドライン（通則編）](https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/)でも、高度な暗号化等の秘匿化がされている場合は、漏えい等報告を要しない例として挙げられています。鍵が同じサーバーにあれば意味がない点に注意します
- **保存する世代と期間を決め、古いものを消す**——注意喚起でも、利用する必要がなくなった個人データを遅滞なく消去するよう、改めて求めています
- **保存先へのアクセスを専用アカウントに限る**——バックアップを取得・復元できるアカウントを最小限にし、ふだんの作業用アカウントからは読めないようにする
- **テスト環境に本番のダンプを持ち込まない**——テスト用のデータは、個人データを他のデータに置き換えたものを使う

## 防止策の全体像：「防ぐ」と「気づく」

 2つの手口の防止策を、個人情報保護委員会が示した見直し後の技術的安全管理措置の5項目に当てはめると、次のようになります。
| 技術的安全管理措置 | DBへの直接アクセス | バックアップの持ち出し |
| **(1) アクセス制御** | 接続元をWebサーバーに限定、権限の最小化 | 保存先へのアクセスを専用アカウントに限定 |
| **(2) 識別と認証** | 管理者の多要素認証、アカウントの棚卸し | FTP・SSHのアカウント管理、多要素認証 |
| **(3) 外部からの不正アクセス等の防止** | DBポートを公開しない、ソフトの更新 | 公開領域に置かない、保存先の公開設定の確認 |
| **(4) 使用に伴う漏えい等の防止** | 接続情報の保護、通信の暗号化 | バックアップの暗号化、テストデータの置き換え |
| **(5) 不正アクセス等の検知等** | ログの保管と分析、常時監視による早期検知、被害拡大の防止（遮断・アカウントの無効化） |

 (1)〜(4) は「防ぐ」ための対策です。ただし、防ぐ対策には必ず穴が残ります。消し忘れた1つのファイル、退職者の残ったアカウント、どこかで漏れたパスワード——どれも、ふだんの運用の中で起きることです。(5) は、その穴を通られたときに**全件が持ち出される前に気づき、止める**ための対策で、今回の見直しで独立した項目になりました。

## Previento の監視で止める  （図: 白いロボットが警告マークの出たモニターを確認し、データベースへ外から伸びるオレンジ色のケーブルの途中に青い遮断ゲートが降りているイメージイラスト）

 当社の「[Previento](https://technosphere.co.jp/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 の製品ページ](https://technosphere.co.jp/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](https://technosphere.co.jp/previento)」は、この検知と遮断を、初期費用0円・月額3万円〜（税別）で始められるサービスです。「DBやバックアップがどこから触れる状態か分からない」「ログはあるが誰も見ていない」という段階のご相談も歓迎です。