Back

WordPressサイトを保護する方法

WordPressサイトを保護する方法

WordPressはWeb全体の43%以上を動かしており、地球上で最も標的にされるCMSとなっています。しかし、多くのサイト所有者が誤解している点があります。それは、コアソフトウェアが問題になることは稀だということです。Patchstackのセキュリティ調査によると、WordPressの脆弱性の大部分はプラグインやテーマに起因しており、WordPress本体ではありません。つまり、セキュリティ態勢はサイトの保守と設定方法にほぼ完全に依存しているのです。

本ガイドでは、時代遅れのアドバイスを除き、実際に重要なWordPressセキュリティのベストプラクティスを解説します。

重要なポイント

  • ほぼすべてのWordPress脆弱性はコアではなく、プラグインやテーマに起因します — 定期的に拡張機能を監査し、不要なものを削除しましょう。
  • 強力な認証(一意のパスワード、TOTPベースの2FA、パスキー)は、不正アクセスに対する最も効果的な防御手段です。
  • ファイルエディタの無効化、HTTPSの強制、正しいファイルパーミッションの設定などのサーバーレベルの保護により、攻撃対象領域が劇的に縮小します。
  • 信頼性の高い、テスト済みのバックアップは最後の防衛線です — 復元したことのないバックアップは、信頼できないバックアップです。

なぜ多くのWordPressサイトが侵害されるのか

修正方法に入る前に、実際の攻撃対象領域を理解することが重要です。成功する侵害のほとんどは以下を悪用します:

  • 古いまたは放置されたプラグインとテーマ
  • 脆弱または使い回されたパスワード
  • 誤って設定されたファイルパーミッション
  • サーバーレベルの保護がないホスティング環境

WordPress本体(現在は6.xリリースライン)は専任のセキュリティチームによって積極的にメンテナンスされており、パスワードハッシュにはbcryptを使用し、マイナーセキュリティアップデートは自動的に配信されます。リスクはほぼ常にその周辺のエコシステムにあります。

WordPress強化ガイド:必須事項

すべてを例外なく最新に保つ

脆弱性の開示から実際の悪用までの時間は、数日ではなく数時間であることが多いです。マイナーコアリリースの自動バックグラウンド更新を有効にしましょう。プラグインとテーマについては、最低でも週に1回は更新を確認して適用してください。

さらに重要なのは、インストールされているものを監査することです。すべての非アクティブなプラグインは攻撃対象領域です。使用していない場合は、無効化するだけでなく削除してください。

プラグインをインストールする前に確認すべき項目:

  • 最終更新日(12ヶ月以上更新されていないものは避ける)
  • アクティブインストール数
  • WordPress.orgプラグインリポジトリに掲載されているか
  • セキュリティ問題に言及しているオープンなサポートスレッド

nulled(不正コピー)や海賊版のテーマやプラグインは絶対にインストールしないでください。これらには頻繁にバックドアが含まれています。

すべてのアカウントで強力な認証を使用する

WordPress本体には2要素認証が組み込まれていません。追加するにはプラグインまたは外部IDプロバイダーが必要です。

最新の認証ベストプラクティス:

  • パスフレーズ(4つ以上のランダムな単語)またはBitwarden1Passwordなどのパスワードマネージャーに保存されたランダム生成パスワードを使用する
  • すべての管理者アカウントでTOTPベースの2FA(認証アプリ)を有効にする — SMSベースの2FAは何もないよりは良いですが、より脆弱です
  • スタックがサポートしている場合、フィッシング耐性のあるログインのためにパスキー/WebAuthnの使用を検討する
  • REST APIやサードパーティ統合には、メイン認証情報の代わりにWordPressのApplication Passwordsを使用する

管理者アカウントを共有しないでください。すべてのユーザーは、必要最小限の役割で独自のログインを持つべきです。

基本的なサーバーレベルの保護を適用する

いくつかの設定変更により、攻撃対象領域を大幅に削減できます:

  • ファイルエディタを無効化して、管理者アカウントが侵害された場合のコード実行を防ぐ(wp-config.phpに設定):
    define( 'DISALLOW_FILE_EDIT', true );
  • サーバー設定でアクセスを制限し、公開アクセスできないようにすることで**wp-config.phpを保護**する
  • 正しいファイルパーミッションを設定:ディレクトリは755、ファイルは644
  • ファイル転送時には平文FTPの代わりにSFTPまたはSSHを使用する
  • HTTPSを強制する — すべてのWordPressサイトは有効なTLS証明書を持ち、HTTPをHTTPSにリダイレクトすべきです

Webアプリケーションファイアウォールとレート制限を追加する

WAFは悪意のあるトラフィックがWordPressに到達する前にフィルタリングします。これは3つのレベルで実装できます:

  1. CDN/プロキシレベルCloudflareなどのサービスは、ボット管理を備えたWAFとDDoS保護を提供します
  2. サーバーレベル — ApacheまたはNginxのModSecurity
  3. プラグインレベルWordfenceSucuriなどのセキュリティプラグインは、アプリケーション層のファイアウォールルールとログインレート制限を追加します

ログイン試行のレート制限は不可欠です。wp-login.phpに対するブルートフォース攻撃は絶え間なく自動化されています。

XML-RPCに関する注意: 依存関係を理解せずにXML-RPCを一律に無効化しないでください。一部のプラグインやモバイルアプリはこれに依存しています。使用していない場合、ブロックすることは妥当ですが、脆弱な.htaccessルールではなくサーバーレベルで行ってください。

確実にバックアップし、復元をテストする

テストしたことのないバックアップはバックアップではありません。3-2-1ルールを使用してください:3つのコピー、2つの異なるメディアタイプ、1つはオフサイト。バックアップを自動化し、定期的に復元が実際に機能することを確認してください。

WordPressサイトを保護する:クイックリファレンスチェックリスト

  • WordPress本体、プラグイン、テーマが最新である
  • 未使用のプラグインとテーマが削除されている
  • すべての管理者アカウントが強力で一意のパスワードを使用している
  • すべての管理者ユーザーで2FAが有効になっている
  • wp-config.phpDISALLOW_FILE_EDITが設定されている
  • ファイルパーミッションが正しく設定されている(755/644)
  • サイト全体でHTTPSが強制されている
  • WAFとログインレート制限がアクティブである
  • 自動バックアップが定期的に実行され、復元がテストされている
  • ユーザーロールが最小権限の原則に従っている

結論

WordPressサイトの保護は、特殊な強化トリックよりも、一貫したメンテナンス規律の問題です。ソフトウェアを最新に保ち、適切な認証を使用し、サーバーレベルの保護を適用し、定期的にバックアップしてください。ほとんどの攻撃は、WordPress自体が失敗したからではなく、これらの基本事項のいずれかがスキップされたために成功しています。

よくある質問

いいえ。WordPress本体は専任のセキュリティチームによって積極的にメンテナンスされており、マイナーセキュリティアップデートは自動的に受信されます。脆弱性の大部分はサードパーティのプラグインやテーマに起因しており、コアソフトウェアではありません。拡張機能を監査し更新し続けることが、WordPress自体を心配するよりもはるかに重要です。

はい。wp-login.phpに対するブルートフォース攻撃や認証情報詰め込み攻撃は絶え間なく自動化されています。強力なパスワードだけでは不十分です。なぜなら、パスワードは漏洩したり再利用されたりする可能性があるからです。認証アプリによるTOTPベースの2FAは、ほとんどの不正ログイン試行を阻止する第2の層を追加します。

セットアップによります。XML-RPCは一部のプラグインやWordPressモバイルアプリがまだ使用しているレガシーAPIです。サイト上で何もこれに依存していない場合、無効化することで攻撃対象領域が減少します。より簡単にバイパスされる可能性のあるhtaccessルールではなく、サーバーレベルでブロックしてください。

頻度はコンテンツの変更頻度によります。アクティブなサイトの場合、毎日の自動バックアップが妥当なベースラインです。頻度よりも重要なのは、定期的に復元をテストすることです。3-2-1ルールに従ってください:3つのコピー、2つの異なるストレージタイプ、1つはオフサイトに保存。

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay