共有サーバーでWordPressを運用していると、他ユーザーと環境を共有する性質から思わぬ速度低下やセキュリティリスクに直面しがちです。
最低限どこを押さえれば安全に運用できるのかを、重要ポイントに絞って分かりやすく解説します。
共有サーバー（レンタルサーバー）特有のリスク
共有サーバー、日本の商習慣的にはレンタルサーバーと言ったほうが分かりやすいかもしれません。
一つのサーバーの中でユーザーを振り分け、それぞれのユーザーでサービスを公開できる環境。今では一人一台のPC環境が当たり前ですが、昔はコンピューターと言えば一つのサーバーの中でそれぞれのユーザーを割り当てて操作するのが一般的だったので、その流れを組んだ使い方が可能となっています。
そして現在では「レンタル」と言っても様々な用途があり、物理的なサーバーを持つ以外にVPSやAWSなどのクラウドも「レンタル」でのサーバーとなっています。本記事では一般的な「レンタルサーバー」と呼ばれている「共有サーバー」について取り扱っていきます。
この共有サーバーではCPUやメモリ、ストレージといったリソースを複数ユーザーで同時に使うことが出来ます。これはメリットとしては安く使用できるのですが、自身のサイトが軽量でも他ユーザーが公開しているサイトの負荷によって速度低下や503エラーが起きることがあります。
また、同じサーバー上の別サイトが攻撃を受けると、間接的に影響を受ける可能性も否定できません。
PHP設定やWAF設定の自由度も低いため、細かい調整が必要なケースでは制約がストレスになることがあります。
基本対策①：ファイル権限と不要ファイルの管理
共有サーバーでは、同じ環境を他ユーザーと使うため、ファイル権限の設定が甘いだけで情報漏えいの原因になります。特に wp-config.php はデータベース情報を含む最重要ファイルのため、もっとも厳しい権限にしておくことが欠かせません。
ファイル権限は「3つの数字」で表され、それぞれが
①所有者 ②グループ ③その他の人
に対して与える権限を意味しています。数字の読み方は次の通りです。
- 0：一切許可しない
- 4：読み取りのみ（r）
- 6：読み取り＋書き込み（rw）
- 7：読み取り＋書き込み＋実行（rwx）
たとえば 400 は「所有者だけが読み取り可、それ以外は何もできない」という状態で、wp-config.php によく使われる安全な設定です。共有サーバーでは、第三者に閲覧されないよう 440 や 400 のように「ほぼ誰も触れない」設定が推奨されます。
一方で、wp-content のように WordPress がファイルを生成する場所は、書き込みが必要なため 755 や 750 など、最低限の実行権限を確保しておく必要があります。ただし権限を広げすぎると、悪意のあるファイルが置かれるリスクも高まるため注意が必要です。
また、初期インストールのまま残りがちな readme.html、sampleファイル、未使用テーマ・プラグイン は、攻撃者に環境情報を与える原因になります。これらは削除しておくことで、余計な「突破口」を減らせます。
ファイル権限の見直しと不要ファイルの削除。この2つを行うだけでも、共有サーバー環境でのWordPressの安全性は大きく向上します。
基本対策②：PHP・WordPressの定期的な更新
共有サーバーでは、サーバー全体のPHPバージョンを自分で自由に選べない場合があり、提供側の更新が遅れるとセキュリティリスクが一気に高まります。
古いPHPは既知の脆弱性が放置されることになり、最新のWordPressやプラグインと相性が悪く、表示崩れや致命的なエラーを引き起こすことも珍しくありません。
WordPress本体やプラグインの更新も同様に重要で、バージョンアップには機能追加だけでなく、脆弱性の修正が含まれているため、更新を先延ばしにするほど攻撃対象になりやすくなります。特に共有サーバーは他のサイトへの攻撃の影響を受けやすい構造のため、「古いソフトウェアを使い続けること」が多サイト巻き込み型の被害を招きやすい点も理解しておくべきです。
更新を安全に進めるための基本は次の通りです。
- PHPの最新化をサーバー管理画面で確認し、古いままならプラン変更や移行も検討
- WordPress本体・テーマ・プラグインはこまめに更新
- 重大更新の前には必ずバックアップを取る
共有サーバーでは細かいセキュリティ設定を自分でコントロールできない分、PHP・WordPressの更新管理こそが「最大の防御」になります。
更新が正常に行われているか定期的に確認するだけでも、トラブルの予防効果は大きくなります。
基本対策③：ログイン管理の強化
共有サーバー環境では、他ユーザー由来の負荷や攻撃が巻き込まれることがあるため、自サイトのログイン周りの防御を固めることが特に重要です。WordPressの管理画面は攻撃者に狙われやすく、総当たり（ブルートフォース）攻撃や不正ログインの試行は日常的に発生します。
最も効果が高い対策は、二要素認証（2FA）の導入です。
パスワードが万一漏えいしても、ログイン時に追加確認が求められるため突破される可能性がほぼありません。Google Authenticator など一般的な認証アプリで簡単に利用でき、管理者アカウントだけでも導入しておく価値があります。
また、ログイン試行回数の制限も有効です。
短時間に何度もパスワードを試す攻撃を自動で遮断できるため、サーバーへの負荷軽減にもつながります。共有サーバーでは大量のログイン試行が他サイトにも影響を与えることがあるため、この対策は特に効果的です。
さらに、管理画面URLの変更（/wp-admin /wp-login.php を隠す）は、攻撃対象になる入口そのものを隠す方法として有効です。完璧な防御ではないものの、攻撃を受ける回数を大幅に減らす効果が期待できます。
管理者アカウントを守ることは、共有サーバー環境における「最後の砦」です。2FA・ログイン制限・URL変更といった対策を組み合わせることで、不正ログインのリスクは大きく低減します。
基本対策④：バックアップの自動化
共有サーバーでは、サーバー運営会社が提供するバックアップ機能があっても、その仕組みや保持期間が限定的で、「必要なときに復元できない」というケースが起こりがちです。
特に、同一サーバー上の別ユーザーが原因で障害が発生した場合、自サイトも巻き込まれて復元ポイントを失う可能性があります。そのため、自前でのバックアップ体制を整えておくことが不可欠です。
バックアップと一口に言っても 「ファイル」 と 「データベース」 の両方が揃っていることで復元することができます。WordPressはデータベースに記事・設定・ユーザー情報が保存され、テーマやプラグイン・画像などはファイルとして保存されるため、どちらか一方だけでは完全に復旧できません。
また、バックアップは取得して終わりではなく、一度だけでもよいので復元テストを実施することが大切です。いざというときに戻せないバックアップほど役に立たないものはありません。
避難訓練と同様に、WordPressサイトも普段からバックアップとリストア（復元）訓練を行えるといざというときに安心です。
バックアップは自動化しておくことで常に最新の状態に戻すことができるので
- 毎日〜毎週の自動バックアップを設定する
- 保存先はサーバーとは別の場所（外部ストレージやPC）にする
- 復元手順を自分でも再現できるようにしておく
を目安に設定しておきましょう。
共有サーバーは安価で便利な反面、不測の事態が起きたときの影響が広がりやすい環境です。バックアップを自動化しておくことで、更新失敗や障害時に備えられ、「最悪のケースでも復旧できる」という安心感を持ちながら運用できます。
基本対策⑤：WAFやサーバー設定の確認
共有サーバーでは、サーバー側で用意されている WAF（Web Application Firewall / 読み方:ワフ） を有効化しておくことが、もっとも手軽で効果の高い防御策になります。
WAFは、XSS（クロスサイトスクリプティング）やSQLインジェクションなどの代表的な攻撃を自動でブロックしてくれるため、積極的に使いましょう。
ただし、WAFは万能ではなく、特定のプラグインやフォーム機能と競合する場合があります。
例えば、管理画面での保存操作や外部APIとの通信がWAFによって「不正なリクエスト」と誤判定されるケースがあり、意図せずエラーが発生することも珍しくありません。そのため、WAFを有効にした後にサイトの動作確認を行い、問題が出ればログ閲覧や一時的なルール緩和などで調整する必要があります。
また、共有サーバーでは PHPバージョンやメモリ上限（memory_limit）、最大アップロードサイズ などを自由に変更できないことがあります。これらの制限はプラグインの動作やサイトの速度にも影響するため、管理画面やコントロールパネルで現状を確認し、必要に応じて .htaccess を利用した範囲で調整すると良いでしょう。
- WAF：必ず有効化し、競合がないか確認
- PHP設定：メモリや実行時間などの上限をチェック
- htaccess：許可された範囲で最適化（圧縮・キャッシュなど）
このように、共有サーバー側の保護機能とWordPress側の設定をバランスよく使うことで、攻撃に強い運用環境を作ることができます。
どのタイミングで上位プラン・VPSを検討すべきか
共有サーバーはコストが低く、導入も簡単ですが、運用が進むにつれて性能や設定の自由度に限界を感じる場面が増えてきます。特に以下のような状態が見え始めたら、上位プランやVPSへの移行を検討するタイミングです。
まず、アクセス増加による503/504エラーの頻発です。
これはサーバー側のCPU・メモリが不足しているサインで、共有環境では他サイトの負荷が原因の場合もあります。自サイトが成長している証拠でもありますが、表示遅延やエラーが続くと機会損失につながるため、安定性を優先したほうが良い状態です。
次に、プラグイン導入の制限が気になり始めたときです。
高機能なキャッシュプラグインや画像変換処理などは、共有サーバーではCPU負荷の観点から利用を制限されていることがあります。運用に必要な機能を十分に使えない状況が続くと、サイト改善の幅が狭まり、結果的に成長を妨げます。
さらに、PHP設定やWAF、cronなどの制御を柔軟に行いたい場合も移行の目安です。共有環境では細かい設定に制限があるため、サイト規模が大きくなるほど「もっと自由に管理したい」というケースが増えていきます。
移行は手間に見えますが、長期的には安定性・速度・機能拡張のすべてが向上します。特に成長期のサイトであれば、早めの決断が大きなメリットになります。共有サーバーにストレスを感じ始めたら、移行先のプランを比較し、少し余裕のある環境へステップアップすることを検討してみてください。
まとめ
共有サーバーでもWordPressを安全かつ安定して運用できますが、そのためには特有の制限とリスクを理解し、基本的な対策を丁寧に行うことが欠かせません。
特に、ファイル権限の適切な設定・不要ファイルの削除・PHPとWordPressの更新管理・ログイン防御・バックアップの自動化・WAF設定の確認といった要素は、どれか一つでも欠けると弱点になり得ます。
共有環境は便利な反面、他ユーザーの影響を受けやすい構造のため、日頃のメンテナンスが運用の安定性を大きく左右します。
まずは今回紹介した基本対策から実践し、必要に応じて上位プランやVPSへの移行も視野に入れながら、自サイトに最適な運用体制を整えていきましょう。
コメントを残す