コンテンツへスキップ
WordPress保守

攻撃面を狭めるチェックリスト — 管理者・編集権限・ファイル権限・wp-config.php・uploads の5点

更新を当てる、侵害されていないか点検する。どちらも大切な作業だが、その前に「そもそも入口を減らす」という考え方がある。この記事では、WordPress の攻撃面（アタックサーフェス）を狭めるための5つの見直し — 管理者アカウント、管理画面からのファイル編集、ファイル権限、wp-config.php の扱い、uploads での PHP 実行 — を、既存の解説記事を束ねる形で整理する。どれも安全を請け合う設定ではなく、被害の起きやすさ・広がりやすさを下げるための見直しとして読んでほしい。

攻撃面とは何か

攻撃面とは、外部から（あるいは侵入後に内部から）触れられる入口や機能の総量のことだ。入口が多いほど、見落としの確率は上がる。逆に、使っていない入口を閉じておけば、更新が間に合わなかった日の影響が小さくなる。

ここで大切なのは、攻撃面を狭める作業は「脆弱性が見つかったときの被害を小さくする」ものであって、脆弱性そのものを消すものではない、という点だ。脆弱性への根本的な備えは、引き続き更新と点検である。以下は、それを補う層として並べる。

見直す点 狭めるもの 詳しい記事
① 管理者アカウント 乗っ取られたときに使える権限の量 侵害点検の記事
② 管理画面でのファイル編集 管理者ログイン後にコードを書き換えられる経路 wp-config.php 定数解説
③ ファイル権限 同じサーバー上の他者・他プロセスから見える範囲 ファイル権限と最小権限
④ wp-config.php 認証情報が載ったファイルの露出 wp-config.php 定数解説
⑤ uploads のコード実行 アップロードされた PHP が動く可能性 本記事

① 管理者アカウントを減らす

管理者は、プラグインの導入・ユーザーの作成・設定の変更など、ほぼ何でもできる。つまり 管理者アカウントの数は、乗っ取られたときの影響範囲の数 でもある。

見直しの観点は次のとおり。

  • 管理者は「今そのサイトの管理作業をしている人」だけにする。過去の担当者、退職・契約終了した人のアカウントは外すか、権限を下げる
  • 記事を書くだけの人には、編集者や投稿者の権限で十分なことが多い。必要な作業に足りる最小の権限 を渡す
  • 共有アカウントは、誰が操作したかが分からなくなる。可能なら個人ごとに分ける
  • 管理者のメールアドレスが、今も受信できる宛先か確認する（パスワード再設定の経路になる）

一覧は、次の読み取り専用コマンドで確認できる。

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

全員について「誰で、なぜ管理者なのか」を説明できるかが基準になる。説明できないアカウントがあれば、削除する前に、まず記録を残して確認する。

② 管理画面からのファイル編集を止める

WordPress の管理画面には、テーマやプラグインのファイルをその場で編集できる機能がある。便利な反面、管理者ログインさえ突破されれば、そこからサーバー上のコードを書き換えられる経路 にもなる。

wp-config.php に次の定数を入れると、この編集機能が無効になる。

define( 'DISALLOW_FILE_EDIT', true );

wp-config.php の主要定数の記事でも触れたとおり、これは「管理画面でコード編集をしない運用」なら副作用が小さい。ただし、プラグインやテーマの導入・更新まで止めたい場合は別の定数（DISALLOW_FILE_MODS）があり、こちらは更新も止まるため、保守の運用と相性を確認してから使う。更新を止めてしまっては、本末転倒になるからだ。

③ ファイル権限を必要最小限にする

Unix 系のサーバーでは、ファイルごとに「所有者・グループ・その他」へ読み書き実行の権限が付く。ファイル権限と最小権限の記事で書いたとおり、考え方は 「必要な相手に、必要な操作だけ」 に尽きる。

  • 全員が書き込める権限（777 など）は、特別な理由がない限り付けない
  • 一般的な目安として、ファイルは 644、ディレクトリは 755 程度から始める。ただしサーバーの構成（PHP の動かし方、所有者の設定）によって適切な値は変わるので、ホスティング事業者の案内を優先する
  • 権限を変更する前に、現状を記録しておく。変えて動かなくなったときに、元へ戻せるようにするためだ

現状の確認は、読み取りだけで済む。

find . -type f -perm -o+w -not -path "./wp-content/cache/*" | head -20

「その他」に書き込み権限が付いているファイルを一覧にする例だ。出てきたものを機械的に直すのではなく、なぜそうなっているか を確認してから判断する。

④ wp-config.php を守る

wp-config.php には、データベースの接続情報や、ログインの仕組みに使う各種キー（ソルト）が入っている。外部に読まれて困るファイルの筆頭だ。

  • ドキュメントルートの外に置けるか確認する: WordPress は、wp-config.php が1つ上のディレクトリにあっても読み込める。サーバー構成が許すなら、公開領域の外に置く方法がある（ただし、構成によっては動かなくなる場合があるので、バックアップを取ってから）
  • 権限を絞る: 前節の考え方に沿って、他者から読めない権限にする。多くの環境で 600 や 640 が候補になるが、PHP が読めなくなる設定もあるため、動作確認を伴って行う
  • バックアップや一時ファイルを置かない: wp-config.php.bak や wp-config.php.old のようなファイルを公開領域に残すと、元のファイルより保護が弱くなりやすい。編集後に残っていないか確認する
  • ソルトの入れ替え: 鍵を更新すると、既存のログインセッションが無効になる。管理者の見直しと合わせて実施すると効果が分かりやすい
wp config shuffle-salts

実行すると全員が再ログインになるため、作業の時間帯には注意する。

⑤ uploads ディレクトリで PHP を動かさない

wp-content/uploads/ は、画像などのメディアが保存される場所で、本来は PHP のコードを置く場所ではない。もしここに PHP ファイルが置かれ、さらに実行できる状態だと、アップロード経路の不備が深刻な被害につながりやすい。

考え方は単純で、「データを置く場所では、コードを実行させない」だ。実現方法はサーバーの種類で異なる。

  • Apache 系では、uploads 直下に置く .htaccess で PHP の実行を拒否する方法がある（Apache 2.4 の例）
<FilesMatch "\.php$">
    Require all denied
</FilesMatch>
  • Nginx 系では、サーバー設定側で uploads 配下の .php を PHP 処理に渡さない設定にする
  • 共用レンタルサーバーでは、.htaccess の利用可否や記述が管理画面の設定に依存する場合がある。契約中のサービスの案内を確認する

設定の前後で、画像などの通常のメディアが表示され続けること を必ず確かめる。また、プラグインによっては uploads 配下に自分用の PHP を置くものもある。その場合は、拒否を入れる前に、そのプラグインの動作に影響しないかを確認する。

すでに入っているものの確認は、侵害点検の記事の読み取り専用コマンドで行える。

限界を知っておく

  • どの項目も、脆弱性を直すものではない。更新の遅れを埋め合わせる「時間稼ぎ」にはなるが、更新の代わりにはならない
  • 設定を入れた後に動作が変わることがある。変更は1つずつ、バックアップを取ってから行い、変更前後の状態を記録する
  • ホスティングの仕様で、実行できる手段は大きく変わる。ここに書いた値はあくまで一般的な目安であり、環境ごとの確認が前提になる
  • 「一度整えたら終わり」ではない。担当者の入れ替わりやプラグインの追加で、攻撃面は少しずつ元に戻っていく。定期的に見直すことが保守になる

まとめ

  • 攻撃面を狭める作業は、脆弱性が見つかった日の被害を小さくする層。更新と点検の代わりにはならない
  • 見直すのは5点: 管理者の数、管理画面でのファイル編集、ファイル権限、wp-config.php、uploads での PHP 実行
  • どれも変更の前に現状を記録し、変更後に動作を確認する
  • 値は環境で変わる。迷うときはホスティング事業者の案内か、専門の窓口を頼る

今日できる一手は、wp user list --role=administrator の結果を見て、今は使っていないアカウントがないか を確かめること。