レンタルサーバーのセキュリティ対策は、WAFを有効にしただけでは完了しません。サーバー会社が基盤を管理していても、WordPressの更新・管理アカウント・バックアップの復元確認は契約者側に残るからです。最初に担当を分け、影響が大きい管理アカウントから確認します。

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

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

サーバー会社は、データセンターやネットワークとサーバー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の更新など、被害の大きさを変える項目から進めます。担当者と次回確認日が決まったとき、チェックリスは初めて継続的な対策になります。