バックアップを公開ディレクトリに置いていて、全部インターネットに出ていた話

ファイルを更新する前にバックアップを取る。ここまでは誰でもやります。問題は、そのバックアップをどこに置くかでした。私は更新するファイルの隣に置いていました。つまり、公開されている場所に。

何が起きていたか

静的サイトを運用していると、HTMLを差し替える前に「戻せるようにしておく」という手順が自然に入ります。私がやっていたのはこれでした。

差し替えるファイルの隣に index.html.bak-20260721 のようなコピーを作る
差し替える
うまく動いていたらそのまま次の作業へ

3つめが問題です。「そのまま」というのは、消していないということです。そして置いた場所は、Webサーバーが配信しているディレクトリの中。つまり .bak ファイルは、URLを推測すればそのままブラウザでダウンロードできる状態でした。

これに気づいて実際に数えたら、こうなっていました。

.bak 系のファイルが 28件
過去にまとめて取った圧縮アーカイブが 55本、合計約750MB
そのうち3本に、アプリの設定ファイル（認証情報を含む形式のもの）が入っていた
別サイト一式のディレクトリコピー（17MB）が、関係のないドメインの下から配信されていた

全部 HTTP 200 で返っていました。アクセス制限もかかっていません。

いちばん効いた勘違い

ここが本題です。私はこの問題を一度片付けています。142件を退避して、これで解決したと思っていました。

2日後に28件に戻っていました。

原因は、退避したあとも「バックアップは差し替えるファイルの隣に作る」という手順書をそのまま使い続けていたことです。作業するたびに、手順に従って、律儀に公開領域へバックアップを置いていました。

つまりこれは不注意の問題ではなく、手順の問題でした。不注意なら気をつければ減りますが、手順に埋まっている場合、丁寧に作業する人のほうがたくさん作ります。私は手順を守っていたから再発させました。

片付ける作業（掃除）と、発生を止める作業（手順の修正）は別物です。掃除だけして「対応した」と思ったのが、この一件でいちばん大きな失敗でした。

どう直したか

1. バックアップの置き場を、公開領域の外に移した

Webサーバーが配信するディレクトリと、バックアップを置くディレクトリを完全に別の場所にしました。配信対象のツリーの中に一段掘って置くのではなく、外に出します。

ここで大事なのは、手順書のコマンドそのものを書き換えたことです。「公開領域には置かないように気をつける」ではなく、コピー先のパスを手順から変えました。気をつける対象が増えると、いつか忘れます。

2. サーバー側で、そもそも配信させないようにした

バックアップ系の拡張子（.bak、圧縮アーカイブ、SQLダンプ、ログ）と、ドットで始まるファイルを、Webサーバーの設定で拒否するようにしました。

ただしこれは保険です。本筋は「置かない」ことで、この設定は置いてしまったときに被害を止めるための二重化にすぎません。逆順に考えると危ないところで、「拒否設定を入れたから公開領域に置いても大丈夫」にはなりません。拡張子を1つ足すたびに設定が追いつかなくなります。

3. 作業の最後に、必ず0件を確認するようにした

手順の末尾に、公開ディレクトリ配下からバックアップ系ファイルを検索して件数が0であることを目視する工程を足しました。

「1ファイル差し替えただけだから」で飛ばしたくなりますが、飛ばしたときに限って残ります。実際、別のツールで作業したあとに残っていたことがあったので、作業に使った道具が変わっても必ず通すと決めています。

持ち帰れること

自分のサイトで確認するなら、まずこの2つだけでも効きます。

公開ディレクトリの中に .bak、.tgz、.zip、.sql、.old、.orig が無いか検索する。無いと思っていても検索する。私も無いと思っていました
バックアップを取る手順のコピー先が、公開領域の外を指しているか読み返す。ここが内側を指している限り、掃除しても戻ってきます

もう1つ、これは自動化されたスキャンの話です。個人サイトのアクセスログを見ると、設置してもいないWordPressの管理画面や、既知の設定ファイル名へのリクエストが毎日並びます。これは「置いてあるファイル名を推測して機械的に叩く」動きです。URLが複雑だから見つからない、というのは成り立ちません。誰にも知られていないサイトでも、ファイル名の推測は毎日されています。

まとめ

この件で学んだのは、事故そのものより「掃除で終わらせると2日で戻る」という部分でした。

再発したときに「気をつけよう」と思っていたら、また戻ってきていたはずです。手順に原因が埋まっているタイプの問題は、手順のどの行が原因かを特定して、その行を書き換えるまで終わりません。直したい気持ちの強さは、まったく関係がありませんでした。