心境の変化がありました。以前「SiteGuardでWordPressのセキュリティ対策をした話」という記事で、いくつかの対策を有効化しつつ「ログインURL変更機能だけはあえて有効化しなかった」と書きました。あれから少し時間が経ち、状況が変わったので、当時見送っていた設定を見直して、結局オンにすることにしました。その顛末です。
🎥 この記事の内容は動画でも解説しています。
見送っていた理由が、今は当てはまらなくなった
状況が変わりました。以前ログインURL変更を保留していたのは、将来使うかもしれない機能を先に潰したくなかったからでした。今回あわせて見直したXML-RPCの無効化とREST APIの制限も、同じ理由で保留していた項目です。ただ、Jetpackを使う予定がないこと、REST APIに依存する機能を今のところ追加する予定がないことがはっきりしてきたので、保留しておく理由がなくなりました。判断は状況が変われば変わっていい、というだけの話です。
設定を見直したら、地味な罠に気づいた
ちょっとした罠がありました。設定画面を確認していて気づいたのですが、ログインURL変更の項目には、以前入力したはずのカスタムURLの値がそのまま残っていました。てっきり有効になっているものだと思っていたのですが、よく見ると肝心の有効化のチェックは外れたままでした。値が保存されていることと、機能が実際に効いていることは別問題だったわけです。設定画面を流し見しただけでは気づきにくい、地味だけれど典型的な見落としでした。
XML-RPCとREST APIを無効化・制限
対応は3つです。ログインURL変更とあわせて、XML-RPCの無効化とREST APIの制限も有効にしました。REST APIについては、お問い合わせフォームで使っているプラグインなど一部の機能を除外リストに指定できるようになっていたので、そこは既存の設定のまま活かしています。
確認はこの3点です。設定を反映したあとは、実際にサイトへアクセスして動作を確認しました。地道な作業です。xmlrpc.phpへのアクセスがブロックされているか、REST APIの制限が効いているか、そして除外リストに指定した機能(お問い合わせフォームなど)がちゃんと動き続けているか。この3点を確認してから完了とすることにしています。
それでもオンにしなかったもの
ここはあえて据え置きです。一方で、管理画面へのアクセスを許可したIPアドレスだけに制限する機能は、今回もオフのままにしました。理由は単純で、外出先や別のネットワークから作業することがあるため、許可するIPアドレスを都度更新しないと自分自身が管理画面に入れなくなってしまうからです。しかも、うっかりロックアウトされてしまうと、サーバーの管理画面やFTPから直接設定を戻す必要が出てきます。
まとめ
結論はこうです。セキュリティ対策は、選べる項目を全部オンにするのが必ずしも正解とは限らないと思っています。今回のように、保留していた理由が状況の変化でなくなったタイミングで見直す。逆に、便利さや復旧のしやすさとのバランスで、あえてオフのままにしておく判断もある。どちらも、自分がどんな環境・頻度でサイトを触っているかと照らし合わせて決めるものだと、あらためて感じた作業でした。
この記事が参考になったら、応援クリックをお願いします
