レンタルサーバーのセキュリティ対策は、WAFを有効にしただけでは完了しません。サーバー会社が基盤を管理していても、WordPressの更新・管理アカウント・バックアップの復元確認は契約者側に残るからです。基本になるのは、管理アカウントの保護、ソフトウェアの更新、バックアップです。WAFとHTTPSは、それぞれ違う危険を減らすために組み合わせます。

このチェックリストは、新しい製品を次々に追加するためのものではありません。自社で管理する範囲を整理し、攻撃や誤操作が起きたときに影響を止め、復旧できる状態を作るために使います。

最初に守る対象と担当を決める

一般的な共用レンタルサーバーでは、事業者がデータセンターやネットワークとサーバーOSを運用します。管理なしのVPSではOS管理も利用者側になるため、同じ分担ではありません。契約プランによってWAFやバックアップの範囲も変わります。

制作会社へ保守を依頼している場合も、どこまで契約に含まれるかで対応は変わります。WordPressの更新が保守に含まれていなければ、サーバー会社と制作会社のどちらにも更新されない状態になり得ます。新しい対策を買う前に、既存の保守範囲で足りる部分もあります。

管理アカウントを共用しない

不正ログイン対策には、使い回さない強いパスワードと多要素認証が基本になります。複数人で使う場合は、対応するサービスで個別アカウントを発行すると、操作した人を追いやすくなります。担当交代時に、その人だけのアクセスを止められる利点もあります。

パスワードはサーバー・ドメイン・WordPressで使い回さず、パスワードマネージャーで生成・保管します。固定の文字数だけを合格条件にすると、長くても再利用されたパスワードを見逃します。利用できる管理画面では多要素認証を有効にし、復旧コードの保管者も決めておきます。WordPress公式のセキュリティガイドも、強固なパスワードに加え、二段階認証を加える考え方を示しています。

WordPressは更新と削除をセットで行う

WordPress本体・テーマ・プラグインは、既知の脆弱性を残さないために更新します。公開側の表示に問題がないことは、安全である根拠にはなりません。ただし、本番環境でいきなり複数の更新を重ねると、表示崩れが起きたときに原因を分けられません。事前バックアップを取得し、可能ならテスト環境で確認してから、対象を分けて反映します。

不要なプラグインやテーマは、無効化したまま放置せず削除を検討します。ただし、使用中の子テーマが依存する親テーマなどは残す必要があります。更新対象を減らすと、管理担当者がリリース情報を追いやすくなります。導入目的を説明できないプラグインが残っている場合は、セキュリティプラグインを追加する前に整理する方が効果的です。

HTTPSとWAFの役割を分ける

HTTPSは、閲覧者のブラウザとサーバー間の通信を暗号化します。WordPress自体の脆弱性や、盗まれた管理者パスワードによる不正操作を防ぐ機能ではありません。無料SSLを有効にした後は、HTTPからHTTPSへの転送と証明書の自動更新が機能しているかを確認します。

WAFは、Webサイトへのリクエストを規則に照らして検査する層です。有効にする判断はしやすい一方で、WordPressの更新の代わりにはなりません。有効化後は、問い合わせフォーム・ログイン・ファイル送信などを実際に操作します。正常な通信が止まるときは、WAF全体を無効にするのではなく、サーバー会社へ検知ログと発生時刻を伝えます。

バックアップは復元で確かめる

「14日分の自動バックアップがある」という情報だけでは、復旧できるか判断できません。まず、Webファイル・データベース・メールのどこまでが対象かを確認します。次に、自分で復元できるか、費用や申請が必要かを調べます。フォームやサイト更新の頻度によっては、一日前へ戻すことで失われるデータもあります。

サーバー内の自動バックアップだけに依存せず、必要なデータは別の保管先にも残します。最初の復元確認は障害時に行わず、テスト環境で実施します。復元所要時間と担当者が分かれば、保持日数の比較から実際の復旧計画へ進めます。

接続方法は公式マニュアルに合わせる

ファイルを更新する場合は、サーバーが対応していればSFTPを使います。従来のFTPと異なり、認証情報と転送内容が暗号化されます。制作会社には共用のマスターアカウントを渡さず、公開先と権限を限定できる接続情報を用意します。

WordPress管理画面のIP制限は有効な場面があります。ただし、固定IPがない会社やVPN・CDN・プロキシーを使う構成では、正常な担当者も締め出す可能性があります。

ネットで見つけた.htaccessをそのまま追加せず、利用中のサーバー公式手順に従います。Apacheの現行ドキュメントはRequire ipを使う例を示しています。旧来のAllow・Deny・Orderによる方法は非推奨です。

異常時は記録を残して影響を止める

改ざん・不明な管理者・意図しない転送を見つけたら、すぐに上書きして痕跡を消さないようにします。発見時刻・対象URL・表示内容・直前の変更・ログイン履歴を記録します。その後、サーバー会社と保守担当へ連絡します。被害範囲が分からない間は、該当サイトを公開環境から切り離す判断も必要です。

清浄なバックアップへ戻しただけでは、侵入経路が残ります。不要なアカウントやファイルを除き、更新を適用した後に、関連する認証情報を変更します。ドメインやメールにも同じパスワードが使われていたなら、サイトだけで対応を終えず、影響範囲を広げて確認します。

対策の抜けを確認するチェックリスト

次の項目は、基本対策の抜けを確認するための一覧です。WordPressを使っていないサイトなど、該当しない項目まで追加する必要はありません。重大な脆弱性への対応は、定期点検の日を待たずに行います。

チェックが付いた数だけで安全性は決まりません。たとえば多要素認証は不正ログイン、更新は既知の脆弱性、バックアップはデータ消失への備えです。それぞれの役割が違うため、一つの機能でほかを代用できないことが、この一覧のポイントです。