はじめに
第31章では、ホームページ公開前の基本セキュリティを確認しました。
でも、セキュリティは公開した日に完成するものではありません。
スタッフが増える。
制作会社が変わる。
Pluginを追加する。
新しい外部サービスと連携する。
WordPressや攻撃方法も変化する。
そのため第42章では、
公開後にセキュリティをどう管理し続けるか
を考えます。
セキュリティはメンテナンス
セキュリティは、
一度設定
↓
終了ではありません。
むしろ、
設定
↓
確認
↓
更新
↓
不要なものを整理
↓
異常を確認
↓
また見直すというメンテナンスです。
WordPress公式も、Core・Theme・Pluginの更新、強い認証、バックアップ、Logging / Monitoringなど複数の継続対策を案内しています。
アカウントとログインを管理する`
ユーザーアカウントを定期的に棚卸しする
公開時には必要だったアカウントも、半年後には不要になっているかもしれません。
たとえば、
- 退職したスタッフ
- 一時的に依頼した制作会社
- テスト用アカウント
- 使われていない管理者
などです。
定期的にUsersを確認し、
今もこの人にこの権限が必要か
を見直します。
管理者を増やしすぎない
管理者は、WordPressの重要な設定を変更できる強い権限です。
記事編集だけならエディターなど別権限で足りる場合があります。
権限は、
信頼している人
=
管理者ではなく、
必要な仕事
=
必要なCapabilityで考えます。
2FAを「設定」ではなく「運用」する
2FAを導入しても、
復旧方法が分からなければ、端末紛失時に自分がログインできなくなることがあります。
そのため、
- 誰に2FAを必須にする？
- どの方法を使う？
- バックアップ コードはどう管理する？
- 端末紛失時はどうする？
まで決めます。
WordPress Coreには通常の管理画面ログイン用2FAが標準搭載されていないため、信頼できるPluginやIDプロバイダーなどを利用します。
管理者など権限の強いアカウントから優先して考えます。
Application Passwordは通常のログイン パスワードとは違う
WordPressにはApplication Passwordという機能があります。
これは、
外部アプリケーションやスクリプトがWordPress APIへ接続するための個別認証情報
です。
通常のブラウザー ログイン用パスワードとは別物です。
Application Passwordは個別に取り消せるため、外部ツールへ自分のメインパスワードを渡さずに済みます。
ただし、不要になった連携認証情報を残し続ける必要はありません。
Users → Profileなどから、
- 何の連携？
- 今も使っている？
- 最後に使われたのはいつ？
- 不要ならRevokeする？
を定期的に確認します。
ログイン Attackを考える
WordPressのログイン画面には、自動化されたパスワード試行が行われることがあります。
対策は一つではありません。
- 強く固有のパスワード
- 2FA
- ログイン試行制限
- WAF
- ホスティング側保護
- Monitoring
などを組み合わせます。
ログイン URLを変更する方法もありますが、それだけをセキュリティの中心にしません。
「入口を分かりにくくする」ことと、
「突破されにくい仕組みを作る」ことは別です。
Xserver側のセキュリティを活用する
XserverにはWordPress向けのセキュリティ設定があります。
国外アクセス制限など、ホスティング側でWordPressへのアクセスを制御する機能があります。
通常利用で問題がない場合、推奨されている防御を理由なく解除しません。
一方で、海外から管理する、外部サービスが接続するなど、利用方法によって影響することがあります。
設定名だけでON / OFFを決めず、
自分の運用と何を守る機能なのか
を確認します。
WAFとは
WAFは、
Web アプリケーション Firewall
の略です。
Web アプリケーションへの不正なRequestを検知・防御する仕組みです。
XserverにもWAF設定があります。
ただし、WAFをONにすれば100%安全になるわけではありません。
また、正しいRequestを誤って止める可能性もあります。
何かの機能が動かなくなったときに、
「とりあえずWAFを全部OFF」
とするのではなく、どの設定と関係しているか確認します。
Plugin・Themeを継続管理する
PluginやThemeは、インストールした瞬間だけ確認すればよいものではありません。
定期的に、
- 更新されている？
- 開発が止まっていない？
- 今も必要？
- WordPressの現在バージョンと合っている？
- 同じ機能のPluginが重複していない？
を確認します。
使っていないPluginは、無効化して残すだけでなく、不要なら削除も検討します。
WordPress公式のHardening ガイダンスでも、Pluginを最新に保ち、使っていないPluginを削除することが推奨されています。
セキュリティPluginは役割を見て選ぶ
セキュリティPluginには、
- ログイン 保護
- 2FA
- Scan
- 通知
- Firewall
- ファイル 変更 Detection
など様々な機能があります。
大切なのは、
「セキュリティPluginを入れたから安心」
ではなく、
何を補っているPluginなのか
を理解することです。
Xserver側ですでに提供されている機能と重複する場合もあります。
機能を増やすほど必ず安全になるわけではありません。
異常のサインを知る
セキュリティ インシデントは、
「サイトが完全に壊れた」
ときだけではありません。
たとえば、
- 知らない管理者がいる
- 覚えのないページが増えている
- 検索結果にSpam ページが出る
- 別サイトへリダイレクトされる
- ファイルが勝手に変更されている
- ホスティングからセキュリティ 通知が来る
なども確認のきっかけです。
普段の状態を知っているから、異常に気づけます。
ホスティングからのメールも確認する
WordPress管理画面だけを見ていると、サーバー側の通知を見逃すことがあります。
ホスティング会社から届く、
- セキュリティ
- 障害
- メンテナンス
- 契約
- ドメイン
などの重要なメールを確認できる状態にしておきます。
管理メールアドレスが古い人のままになっていないかも確認します。
AIやWebで見つけたコードをそのまま入れない
AIへ、
「このWordPressを直すコードを書いて」
と頼むこともできます。
便利ですが、生成されたコードが、
- 今の環境に合う？
- セキュリティ上問題ない？
- 他のPluginとConflictしない？
- 本番サイトで直接試してよい？
は別問題です。
AIが生成したコードも、
外部から入手したコードとして見直し・テストする
と考えます。
これは第48章のAI活用にもつながります。
異常を見つけたら、むやみに触らない
もし、
「Hackされたかもしれない」
と感じたら、
焦ってPluginを大量に削除したり、ファイルを片っ端から書き換えたりしない方がよい場合があります。
まず、
何が起きている？
↓
いつから？
↓
どのページ / アカウント / ファイル？
↓
バックアップはある？
↓
ホスティングの通知は？を確認します。
必要に応じてホスティング会社のサポートやセキュリティに詳しい人へ相談します。
復旧後は、
「元に戻った」
で終わらず、
なぜ起きたのか、入口を塞げたか
まで確認します。
バックアップはセキュリティそのものではない
バックアップは攻撃を防ぐ機能ではありません。
でも、問題が起きたときに復旧できる可能性を高めます。
Xserverでは自動バックアップが提供されていますが、バックアップの詳細は第32章で扱いました。
セキュリティ章では、
バックアップが存在することと、戻し方を把握していること
を定期的に確認します。
スクリーンショットにもセキュリティがある
管理画面のスクリーンショットを保存・共有するときは、個人情報や認証情報が写り込んでいないか確認します。
そのとき、
- ログイン ID
- メールアドレス
- サーバー ID
- API Key
- 確認 コード
- Application Password
- ドメイン管理情報
などを不用意に公開しないようにします。
「説明用画像だから大丈夫」
ではありません。
公開前に画像の中も確認します。
定期セキュリティ チェック
小規模サイトなら、まず次のような確認から始められます。
月ごと
- 更新状況
- 不審な利用者
- ホスティング会社からの通知
- サイトの異常表示
数か月ごと
- 利用者 / 権限棚卸し
- 不要Plugin / Theme
- Application Password
- 2FA運用
- バックアップ / 復元手順
担当者変更時
- アカウント削除・権限変更
- パスワード / 認証情報確認
- 外部サービス連携
- 管理メールアドレス
正確な周期を守ることより、
確認する仕組みがあること
が重要です。
今回のポイント
- セキュリティは公開後も続くメンテナンス
- 利用者 / 権限を定期的に棚卸しする
- 管理者は必要な人だけにする
- 2FAは復旧方法まで含めて運用する
- Application Passwordは外部連携用認証情報として管理する
- ログイン 保護・ホスティング セキュリティ・WAFなどを組み合わせる
- Plugin / Themeはインストール後もメンテナンス状況を確認する
- 異常のサインとホスティング会社からの通知を見逃さない
- AI生成コードも見直し・テストしてから使う
- インシデント後は復旧だけでなく原因と再発防止まで確認する
今回の視点
セキュリティの強さは、
導入したPluginの数では決まりません。
誰が管理者なのか。
何が外部サービスとつながっているのか。
更新されているか。
バックアップから戻せるか。
異常に気づけるか。
こうしたことを、
継続して把握できる状態
が重要です。
第31章では公開前の守りを作りました。
第42章では、その守りを「続けられる運用」に変えました。
セキュリティは設定ではなく、管理です。
Part 7｜公開後に運用・計測・改善する
前へ：第41章「WordPressを安全に更新・メンテナンスしよう」