wp-config.php、丸見えになってない？ データベース接続情報の安全な管理方法
「…あ」
深夜2時。静まり返った部屋に、自分の間抜けな声が響いた。画面には、見慣れたGitHubのインターフェース。そして、その中央に表示された、一本のプルリクエスト。
「Add .gitignore」
送ってくれたのは、見知らぬ外国人エンジニア。親切心からだろう。僕が公開リポジトリに、WordPressのプロジェクトを丸ごと、そう、wp-config.phpを含んだままプッシュしてしまったのを見つけて、教えてくれたんだ。
血の気が、引いた。
wp-config.php。WordPressサイトの、心臓部だ。データベースのユーザー名、パスワード、接続先ホスト。サイトの全データを握るための「鍵」が、そこには全部書いてある。それが、世界中の誰もが見られる場所に、数時間、無防備に晒されていた。
どうも。WordPressのセキュリティで飯を食ってる、Web屋です。
今日は、このwp-config.phpの話。サイトの「鍵」であるデータベース接続情報を、どうやって安全に管理するか。僕がやらかしたこの大失態も含めて、現場で見てきたヤバい事例と、具体的な対策を全部話す。もし君が、FTPでファイルをアップロードしてるだけ、なんてレベルなら、この記事は最後まで読んだ方がいい。マジで。
なんで「鍵」が狙われるのか？
wp-config.phpは、攻撃者からしたら宝の地図だ。これを手に入れれば、サイトのデータベースに直接アクセスできる。つまり、こういうことが可能になる。
- 個人情報の全抜き取り：顧客の名前、住所、メールアドレス、購入履歴。全部持っていかれる。
- コンテンツの改ざん・削除：君が何年もかけて書いた記事を、一瞬で消したり、アダルトサイトへのリンクに書き換えたり。
- 管理者アカウントの乗っ取り：
wp_usersテーブルを直接いじって、新しい管理者アカウントを作ったり、既存の管理者のパスワードを書き換えたり。 - サイトの完全破壊：データベースを丸ごと削除。
DROP DATABASE。これ一発で、君のサイトは完全に消滅する。
冗談じゃない。これが、wp-config.phpが漏洩するってことの、本当の恐ろしさだ。
お前、まさかやってないよな？ 危険な管理パターン
「いやいや、自分は大丈夫」って思った？ 本当に？ 僕が見てきた中で、特にヤバかったパターンをいくつか挙げる。一つでも当てはまったら、今すぐ改めてほしい。
パーミッションが「777」
論外。話にならない。wp-config.phpのパーミッションが「777」になってるサイトを、僕は何度も見てきた。「なんか上手くいかないから、とりあえず777にしとけ」みたいなノリで設定したんだろう。これは、家の鍵をドアノブにかけっぱなしにしてるのと同じ。誰でも読み書き実行できる。どうぞ、ご自由にお持ちください、と言ってるようなもんだ。
バックアップファイルを同じ場所に放置
wp-config.phpを編集する前に、wp-config-backup.phpとかwp-config.oldみたいな名前でコピーを同じディレクトリに置いておく。これも、よく見る。サーバーの設定によっては、.phpじゃなくて.txtとか.oldの拡張子だと、ただのテキストファイルとして中身がブラウザで丸見えになることがある。そうなったら、もう終わりだ。
公開リポジトリにプッシュ
僕がやったやつだ。言うまでもない。Gitを使うなら、.gitignoreにwp-config.phpを書くのは、呼吸するのと同じレベルの常識。これを忘れるのは、プロとして失格だ。
じゃあ、どうすりゃいいんだよ？
具体的な対策を、3つのレベルに分けて説明する。自分のスキルレベルに合わせて、できるところからでいい。でも、レベル1は最低限のマナーだ。
レベル1：パーミッションを正しく設定する（最低限）
まず、wp-config.phpのパーミッションを「400」か「600」にする。今すぐだ。
- 600：ファイルの所有者だけが読み書きできる。
- 400：ファイルの所有者だけが読み取りできる。
サーバーの仕様にもよるが、基本は「600」でいい。もっと厳しくするなら「400」。これなら、少なくともサーバーに侵入されない限り、他のユーザーからファイルの中身を覗かれることはない。
FTPソフトで設定するか、サーバーにSSHでログインしてコマンドを叩く。
chmod 600 wp-config.phpたったこれだけ。これだけで、セキュリティレベルは格段に上がる。やってないなら、今すぐやれ。
レベル2：ファイルを1階層上に置く（中級者向け）
WordPressは、wp-config.phpを、インストールディレクトリの1階層上に置いても読み込んでくれる。つまり、ドキュメントルート（公開ディレクトリ）の外に置けるってことだ。
例えば、サイトのファイルが/var/www/htmlにあるなら、wp-config.phpを/var/www/に移動させる。こうすれば、万が一、サーバーの設定ミスでPHPが実行されずにソースコードが丸見えになる、なんて事故が起きても、wp-config.phpだけは守られる。ドキュメントルートの外にあるから、ブラウザから直接アクセスされることは絶対にない。
これは、かなり効果的な対策だ。サーバーを直接いじれる知識があるなら、強く推奨する。
レベル3：環境変数を使う（上級者向け）
これが、一番安全な方法。wp-config.phpの中に、データベースのパスワードとかを直接書かない。代わりに、サーバーの「環境変数」っていう仕組みを使って、外から値を渡してやる。
まず、サーバー側で環境変数を設定する。やり方はサーバーによるが、Apacheなら.htaccess、Nginxならnginx.confとかに書く。
# .htaccess の例
SetEnv DB_NAME 'database_name_here'
SetEnv DB_USER 'user_name_here'
SetEnv DB_PASSWORD 'password_here'そして、wp-config.phpの中はこう書き換える。
define( 'DB_NAME', getenv('DB_NAME') );
define( 'DB_USER', getenv('DB_USER') );
define( 'DB_PASSWORD', getenv('DB_PASSWORD') );もっとモダンなやり方だと、vlucas/phpdotenvみたいなライブラリを使って、プロジェクトルートに.envファイルを置いて管理する方法もある。この場合、.envファイルを.gitignoreに必ず追加するのを忘れるなよ。
こうすれば、wp-config.phpが万が一漏れても、そこには接続情報は書かれてない。Gitで管理するのも楽になる。現代的な開発環境なら、これが標準だと思え。
鍵は、金庫にしまえ
wp-config.phpは、サイトの鍵だ。その鍵を、誰でも見える場所に放置しておくのが、どれだけ危険か。分かってくれただろうか。
- パーミッションは「600」か「400」に。
- 可能なら、1階層上に移動させろ。
- Gitを使うなら、
.gitignoreは絶対に忘れるな。
僕がやらかした、あの深夜のミス。幸い、すぐに気づいてリポジトリをプライベートにして、各種パスワードも全部変更したから実害はなかった。でも、あの時の、心臓が凍りつくような感覚は、今でも忘れられない。
君には、あんな思いをしてほしくない。だから、この記事を読み終わったら、すぐに自分のサイトのwp-config.phpがどうなってるか、確認してみてくれ。その数分の確認が、君のサイトを、そして君のビジネスを、救うことになるかもしれないんだから。
追伸：認証キーとソルトについて
wp-config.phpの中には、データベース接続情報の下に、認証キーとソルトっていう、ランダムな文字列が設定されてる部分がある。
define( 'AUTH_KEY', 'put your unique phrase here' );
define( 'SECURE_AUTH_KEY', 'put your unique phrase here' );
// ...これは、ログイン情報とかを暗号化するために使われる、超重要な「塩」だ。これが漏れると、ログインクッキーが偽造されて、パスワードが分からなくても管理画面に侵入される可能性がある。
WordPressの公式ジェネレーターを使えば、いつでも新しいキーを生成できる。もし、wp-config.phpを漏洩させた可能性があるなら、データベースのパスワード変更とセットで、ここのキーも必ず全部、新しいものに差し替えること。忘れがちだけど、めちゃくちゃ重要だ。
「うちのサイト、今どのくらい安全なんだろう?」
そんな疑問を持った方は、まずセキュリティ診断を受けてみるのもいいかもしれない。最近では、30秒ほどでサイトの安全性をチェックできる無料診断サービスもある。暗号化の設定やプラグインの脆弱性、情報漏れのリスクなど、気になるポイントを一通り確認できる。
実は、毎日100サイト以上がハッキングの被害に遭っているという現実がある。「まさか自分のサイトが狙われるなんて」と思っていても、被害は突然やってくる。
早めに問題を見つけて対処しておけば、大きなトラブルを未然に防げる。まずは自分のサイトの「健康診断」から始めてみませんか?
実際にあった、ヤバい事例
これも、僕が経験したり、聞いたりした、本当にあった話だ。
事例1：共有サーバーで、隣のサイトから侵入
格安の共有サーバーを使ってたサイト。ある日、サイトが改ざんされた。調べてみたら、自分のサイトの脆弱性じゃなくて、同じサーバーに入ってる別のサイトの脆弱性を突かれてサーバーに侵入され、そこから自分のサイトのwp-config.phpを盗み見られてた。共有サーバーってのは、こういうリスクがある。パーミッション設定が甘いと、隣の部屋から壁を突き破って侵入されるようなもんだ。
事例2：ステージング環境から漏洩
本番環境はガチガチに固めてたけど、テスト用のステージング環境のセキュリティが甘かった。ステージング環境のwp-config.phpが漏れて、そこから本番環境のデータベースにもアクセスできる設定になってた。ステージング環境だからって、セキュリティを疎かにしちゃダメだ。攻撃者は、一番弱いところを狙ってくる。
事例3：テーマファイルにハードコーディング
これは、僕が改修で入ったサイトの話。なぜか、テーマのfunctions.phpの中に、データベースの接続情報がベタ書きされてた。元の開発者が、wp-config.phpが読み込めない時に備えて、フォールバックとして書いてたらしい。善意だったのかもしれないけど、これは最悪だ。テーマファイルは、wp-config.phpよりもはるかに漏洩しやすい。テーマの脆弱性が見つかったら、一発でアウトだ。
「自分だけは大丈夫」は、ない
セキュリティの世界に、「絶対」はない。どんなに気をつけてても、ミスは起きる。僕だって、あのGitHubのミスは、今でも思い出すと冷や汗が出る。
大事なのは、ミスをしないことじゃない。ミスをしても、被害を最小限に抑えられるように、多重に防御しておくことだ。
- パーミッションを固める。
- ファイルをドキュメントルートの外に置く。
- 環境変数を使う。
これらは、どれか一つだけやればいい、ってもんじゃない。できることは、全部やる。それが、プロの仕事だ。
君のサイトのwp-config.phpは、今、どこにある？ どんな権限で、置かれている？
この記事を閉じる前に、もう一度、考えてみてほしい。
FAQ：よくある質問
Q. レンタルサーバーで、1階層上に置けない場合はどうすればいい？
A. 格安のレンタルサーバーだと、ドキュメントルートより上の階層にアクセスできないことがある。その場合は、せめてパーミッションを「400」に設定すること。それだけでも、やらないよりはずっとマシだ。あとは、.htaccessでwp-config.phpへの直接アクセスを拒否する設定を追加するのもいい。
<files wp-config.php>
order allow,deny
deny from all
</files>Q. 環境変数って、難しそう…
A. 確かに、最初はちょっと戸惑うかもしれない。でも、一度設定してしまえば、あとは楽だ。それに、今の時代、サーバーの知識はWeb屋にとって必須スキルだ。これを機に、勉強してみるのもいいんじゃないか？ Dockerとかを使えば、ローカル環境で簡単に試せる。
Q. .envファイルって、どうやって使うの？
A. vlucas/phpdotenvっていうライブラリをComposerでインストールして、WordPressのルートディレクトリに.envファイルを作る。その中に、DB_USER=...みたいに書いていく。そして、wp-config.phpの先頭で、このライブラリを読み込むように設定する。詳しいやり方は、ライブラリのドキュメントを読んでくれ。英語だけど、頑張って読め。それが勉強だ。
最後に：セキュリティは、面倒くさがった奴から死んでいく
セキュリティ対策は、正直、面倒くさい。パーミッション設定、ファイル移動、環境変数。どれも、サイトの見た目が変わるわけじゃないし、誰も褒めてくれない。
でも、これをサボると、どうなるか。僕が経験した、あの深夜の絶望を、君も味わうことになるかもしれない。
サイトは、ただ作って終わりじゃない。守り、育てていくものだ。その基本が、セキュリティだ。面倒くさがらずに、一つ一つ、確認してほしい。君の大事なサイトを、守れるのは、君だけなんだから。
