サイトの情報漏洩というと、外部からの高度な攻撃を想像しやすい。しかし実際には、自分で公開ディレクトリに置いたまま忘れたファイルが入口になることがある。作業中に作ったバックアップ、データベースのダンプ、設定ファイルの控え。URL が分かれば、誰でもブラウザで取得できてしまう。この記事では、なぜそれが起きるのか、自分のサイトで落ち着いて点検する方法、そして「そもそも公開領域に置かない」という置き場所の原則を整理する。
なぜ「置き忘れ」が起きるのか
レンタルサーバーでは、ドメインに対応する 公開ディレクトリ（public_html など）の下にあるファイルは、原則として URL でアクセスできる。つまり、そこに置いたものは「公開したもの」と同じ扱いになる。
置き忘れは、たいてい悪意のない作業の途中で生まれる。
- 更新や移行の前に、念のため作業用のアーカイブ（圧縮ファイル）を同じ場所に作った
- データベースを書き出して、手元に落とすまでの「一時置き場」にした
- 設定ファイルを編集する前に、控えとして別名で保存した
- 検証用に作ったページやテストファイルを、片付けずにそのまま残した
どれも「あとで消すつもり」で作られる。問題は、消し忘れても何も警告が出ないことだ。サイトは普通に表示され続けるため、気づく機会がない。
何が漏れうるのか
置き忘れの中身によって、影響の大きさは大きく変わる。
- データベースのダンプ: 投稿やユーザー情報、問い合わせの内容などがまとまって入っている。パスワードそのものは変換（ハッシュ化）されて保存されるのが一般的だが、メールアドレスや氏名など、そのまま読めるものも多い
- サイト全体のアーカイブ: 設定ファイルを含んでいれば、データベースの接続情報や認証用のキーまで一緒に出てしまう
- 設定ファイルの控え: 本物の設定ファイルは PHP として実行されるため、中身は表示されない。ところが、拡張子を変えた控え（別名で保存したもの）はただのテキストとして配信されることがある。これが事故につながりやすい点だ
- ログファイルやデバッグ出力: 内部のパスや、エラー時の情報が含まれる（詳しくは別の記事で扱う）
特に3つ目は見落とされがちだ。「設定ファイルは PHP だから中身は見えない」という理解が、控えの段階では成り立たなくなる。
自分のサイトでの見つけ方
点検は、自分のサーバー・自分のサイトに対して、落ち着いて行えば足りる。順番に挙げる。
1. ファイルの一覧で、拡張子から探す
SSH でサーバーに入れる場合は、公開ディレクトリの下に、バックアップや書き出しに使われがちな拡張子のファイルがないかを見る。
cd ~/example.com/public_html
find . -type f \( -name "*.sql" -o -name "*.zip" -o -name "*.tar.gz" -o -name "*.bak" -o -name "*.old" -o -name "*.orig" -o -name "*~" \) -ls
SSH が使えない場合は、FTP/SFTP クライアントで同じ場所を眺めるだけでも役に立つ。ファイルの更新日が古く、サイトの運用上の覚えがないものは、候補になる。
2. 「公開されているか」を実際に確かめる
ファイルがあること自体と、外から取得できる状態であることは別だ。気になるファイルが見つかったら、自分のブラウザや curl で、そのファイルの URL にアクセスして応答を確かめる。
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/見つけたファイルのパス
200 が返れば、外から取得できる状態にある。403 や 404 なら、少なくともその URL では取得できない。ただし、サーバーの設定次第で他の経路から取れる場合もあるため、「取れなかったから置いたままでよい」とは考えない。
3. 検索エンジンに載っていないかも見る
自分のドメインに絞った検索（site: 検索）で、想定していない種類のファイルが出てこないかを確認する。出てくる場合は、すでに外から見つけられる状態にあったことを意味する。
見つけたときの対応
見つけたら、まずその場で削除するか、公開ディレクトリの外に移す。そのうえで、次を考える。
- 中身を確認する: データベースのダンプや設定ファイルの控えであれば、どの情報が入っていたかを把握する
- 認証情報が含まれていたなら、入れ替える: データベースのパスワードや、
wp-config.phpの認証用キー（salt）が含まれていた場合は、ファイルを消すだけでは足りない。外から取得できた期間があった可能性を踏まえ、新しいものに差し替える - アクセスの記録を見る: アクセスログに、そのファイルへの取得の記録が残っていないかを確認する。残っていれば、取得された可能性がある。記録がない・残っていない場合も、「取られていない」とまでは言えない
- 個人情報が含まれていた場合: 影響範囲によっては、法令上の対応が必要になることがある（この点は別の記事で整理する）
慌てて広範囲を操作するより、何が・いつから・外から取得できる状態だったかを順に確かめるほうが、結果として判断を誤りにくい。
置き場所の原則：そもそも公開領域に置かない
一度点検して終わりにせず、置き忘れが起きにくい習慣を作っておくほうが長持ちする。
- 作業用のファイルは、公開ディレクトリの外に置く: ホームディレクトリ直下など、URL で到達できない場所を作業用にする。
public_htmlの外であれば、置き忘れても外からは取得できない - バックアップは、サイトと別の場所に保管する: 同じサーバーの公開領域内に置くのではなく、公開されない場所や別の保管先へ。保管先も、誰が読めるかを決めておく
- 控えは別名ではなく、バージョン管理や公開外の場所で持つ: 「
wp-config.php.bak」のような別名保存は、事故の元になりやすい - 作業の最後に「片付けの確認」を入れる: 更新や移行の手順に、「作業用ファイルを消した」ことの確認を1行入れておく
- 定期的に棚卸しする: 月1回などの保守の中で、上の点検コマンドを実行するだけでも、長く残るものを減らせる
サーバーの設定で、特定の拡張子の配信を拒否する方法もある。ただし、それは置き忘れに対する追加の層であって、置かないことの代わりにはならない。設定の誤りや、環境の変更で効かなくなる可能性があるためだ。
まとめ
- 公開ディレクトリの下にあるものは、原則として URL で取得できる。置き忘れた作業用ファイルが、情報漏洩の入口になりうる
- 特に、データベースのダンプ、サイト全体のアーカイブ、別名で保存した設定ファイルの控えは影響が大きい
- 自分のサイトで、拡張子での探索・実際の応答の確認・検索エンジンでの確認を、落ち着いて行う
- 見つけたら削除（または公開外へ移動）し、認証情報が含まれていた場合は入れ替え、アクセスの記録を確認する
- 長期的には「公開領域に置かない」「作業の最後に片付けを確認する」「定期的に棚卸しする」を習慣にする
保守の作業は、ファイルを増やす場面が多い。増やしたものを、同じ流れの中で片付けるところまでを1セットにしておきたい。