UNIX Cafe | 第102回
データベース削除の完全ガイドとサブディレクトリ運用の真実
長くWordPressを運用していると、サーバーの中には、いつ作ったのか分からないデータベースが増えていきます。
- テスト用に作ったサイト
- 一時的に立ち上げたブログ
- もう使っていないサブディレクトリ
それらは、静かにサーバーの中に残り続けます。
しかし、こうした「過去の遺産」は、単なる不要データではありません。
時には、攻撃者にとって格好の入り口になってしまうこともあります。
今回は、実体験をもとにした安全なデータベース整理の方法と、サブディレクトリ運用の注意点について、やさしく解説していきます。
不要データベースを安全に削除する「4つのステップ」
データベース削除で一番怖いのは、稼働中のサイトのDBを消してしまうことです。
これを防ぐためには、次の順番で作業を進めるのが安心です。
正解は wp-config.php の中にある
サーバーパネルに表示されるDB名だけを見て判断するのは危険です。
必ず、実際のサイトフォルダに入り、wp-config.php を確認しましょう。
define( 'DB_NAME', 'xsXXXXX_wp1' );この行に書かれている名前が、そのサイトが実際に使用しているデータベースです。
ここに書かれているものは、絶対に削除してはいけません。
サイトごとにこの作業を行い、
「使用中のDB」と「不要なDB」を整理していきます。
バックアップは gz 形式で保存する
削除前には、必ずデータベースのバックアップを取りましょう。
このときおすすめなのが、gz形式でのエクスポートです。
gz形式には、ひとつ大きな利点があります。
もしダウンロード中にデータが欠けてしまった場合、
解凍時にエラーが出るため、バックアップの破損にすぐ気づけるのです。
そのため、通常の .sql ファイルよりも、
復元時の信頼性が高いバックアップになります。
アクセス権を外して「凍結テスト」を行う
いきなり削除するのは危険です。
まずは、データベースのアクセス権だけを解除して様子を見ます。
これは、いわば「凍結テスト」です。
- データベース本体は消えない
- サイトからの接続だけが遮断される
- 間違っていても、権限を戻せば即復旧
この状態で数日間、次の点を確認します。
- トップページが表示できるか
- 記事ページは正常か
- 管理画面にログインできるか
- 予約投稿が動いているか
問題がなければ、そのDBは本当に不要だと判断できます。
問題がなければ、最終削除
数日間の確認で問題がなければ、
安心してデータベースを削除できます。
この段階まで来ていれば、
「削除ボタン」を押す恐怖もかなり小さくなります。
サブディレクトリ運用に潜む「3つのリスク」
WordPressを
example.com/wp/
example.com/blog/のように、サブディレクトリで運用するケースは少なくありません。
便利な構成ですが、いくつかの注意点があります。
.htaccess の設定が干渉する
Apacheの .htaccess は、
親ディレクトリの設定が子ディレクトリに継承される仕組みです。
そのため、
- 親でIP制限を設定した
- 特定のファイルを遮断した
といった変更が、
子サイトの動作に影響することがあります。
突然、ログインできなくなったり、
特定の機能だけ動かなくなることもあります。
原因が分かりにくいのが、この構成の難しいところです。
セキュリティリスクが連鎖する
サブディレクトリ構造では、
親ディレクトリの中にすべてのサイトが入っています。
そのため、
- 親が突破される
- ディレクトリ一覧を見られる
- 子サイトを順番にスキャンされる
という流れで、
芋づる式に侵害される可能性があります。
攻撃者にとっては、
「一箇所突破すれば、複数サイトを調査できる」
効率の良い構造とも言えます。
どのDBがどのサイトか分からなくなる
複数のWordPressを同じサーバー契約内で運用していると、
- テスト用サイト
- 過去のブログ
- 開発環境
などが混在していきます。
すると、
「このDB、何に使っていたっけ？」
という状態になりやすくなります。
これが、不要DBの放置につながる最大の原因です。
ログが語る真実
攻撃者は「忘れ物」を探している
ログを解析してみると、
ある共通したパターンが見えてきます。
攻撃者が狙っているのは、
最新のセキュリティではなく、古い遺物です。
古いファイルへの執拗なアクセス
ログには、次のようなリクエストが何度も現れます。
old-index.php
test.php
bak.php
config.bak.php
wp-conflg.phpこれらは、
- テスト用に作ったファイル
- バックアップとして残したもの
- 名前を変えただけの設定ファイル
などです。
攻撃者は、こうした管理者の「消し忘れ」を狙っています。
古いDBが「踏み台」になる仕組み
たとえ古いデータベースが使われていなくても、
- 古いPHPファイルが残っている
- そこからDBに接続できる
という状態なら、そこが裏口になってしまいます。
攻撃者は、
- 古いファイルを見つける
- そこからDBに侵入
- サーバー内の権限を拡大
- メインサイトを書き換える
という流れで攻撃を進めることがあります。
まとめ
クリーンなサーバーが最大の防御になる
不要なデータベースを整理すると、
思わぬ効果があります。
それは、ログがとても読みやすくなることです。
余計なノイズが減り、
不審なアクセスがすぐに分かるようになります。
覚えておきたいポイントは、この3つです。
- DBは wp-config.php と照合して整理する
- バックアップは gz形式で保存する
- 古いファイルを残さない
サーバーの中を整理することは、
特別なセキュリティ対策ではありません。
けれど、それだけで
トラブルの発生率も、復旧の速さも、大きく変わります。
あなたのサーバーの中にも、
静かに眠っている「過去の遺産」はありませんか。
一度、ゆっくりと見直してみる価値は、きっとあります。
さらに学びたいあなたへ
📘 用途ごとに選ぶ Linux のおすすめ本
