WordPressデータベースの保護方法：強化、暗号化、継続的な保護

すべてのWordPressサイトはデータベース上で動作します。投稿、ユーザー、パスワード、プラグイン設定、顧客の注文などが保存されています。

サーバー上のファイルにはテーマや画像が保存されます。データベースにはそれ以外のすべてが保存されます。

そのため、悪質な攻撃者が最初に狙う場所なのです。

SQLインジェクションは依然として一般的なWordPressの攻撃ベクトルです。攻撃者は、ログインフォーム、検索ボックス、または脆弱なプラグインフィールドを通じて細工された入力を送信し、データベースに不正なコマンドを実行させます。

インジェクションが成功すると、新しい管理者アカウントが作成されたり、訪問者がスパムサイトにリダイレクトされたり、コンテンツに悪意のあるコードが注入されたり、データベース全体が消去されたりする可能性があります。

これらの攻撃のほとんどは、音もなく行われます。注入されたコードや不正な管理者アカウントは、何らかの異常が発生するまで数週間もデータベース内に静かに潜伏している可能性があります。

すべてのプラグインが更新され、二要素認証が有効になり、強力なパスワードが設定されているサイトでも、データベース接続がロックダウンされていなかったために被害に遭ったケースに遭遇したことがあります。

このチュートリアルは、そのためのものです。

データベースを保護するために13のステップを実行します。最初の8つのステップでデータベース自体を強化し、最も一般的な攻撃経路を閉じます。最後の5つのステップで、強化だけでは不十分な場合に備えて、バックアップ、監視、復旧レイヤーをセットアップします。

最終的には、継続的かつプロアクティブなデータベース保護が実施されます。

主なポイントは次のとおりです：

• 13のステップは、データベースの強化（ステップ1〜8）とバックアップ、監視、復旧の設定（ステップ9〜13）の2つのレイヤーをカバーします。強化だけでは侵害後の保護にならないため、両方が必要です。
• 一部のデータベース侵害は、数日から数週間は目に見える症状を示さないため、アクティビティログプラグインによる監視は、セキュリティ強化と同じくらい重要です。
• クラウドストレージにある暗号化されていないバックアップファイルは、データベース全体のコピーです。そのストレージアカウントにアクセスできる人は誰でも、ライブサイトに触れることなくそれを読み取ることができます。ステップ9の暗号化でそのギャップを閉じます。
• ステップ1を開始する前に、サイト全体のフルバックアップを取得してください。いくつかのステップではデータベースに直接変更が加えられ、バックアップなしでは元に戻すのが困難になります。
• ステップ11で、Duplicatorの災害復旧URLをWordPressの外のどこかに保存してください。ダッシュボードが完全にロックアウトされた場合に復旧できる唯一のツールですが、問題が発生する前に保存しておく必要があります。
• トラブルシューティングセクションでは、サイトが応答せず、WordPressダッシュボードが表示されない場合の完全な復旧パスを含む、6つの障害シナリオをカバーしています。

目次

WordPressデータベースとは？

WordPressは、サイトの動的なコンテンツをすべてデータベースに保存します。誰かがあなたのサイトを訪れると、WordPressはデータベースに問い合わせを行い、関連するコンテンツを取得して、その場でページを組み立てます。設定を変更したり、投稿を公開したり、ユーザーを追加したりすると、それはデータベースに入ります。

新規のWordPressインストールでは、12個のコアテーブルが作成されます。最も重要なテーブルには以下が含まれます。

• wp_posts: サイト上のすべての投稿、ページ、リビジョン、カスタム投稿タイプ
• wp_users: すべてのユーザーアカウント、ユーザー名、ハッシュ化されたパスワード
• wp_usermeta: ユーザーの役割、権限、アカウント設定
• wp_options: サイト全体のすべての設定、プラグインの設定、アクティブなテーマのデータ
• wp_comments: すべての訪問者のコメントとそのメタデータ

プラグインやテーマは、WordPressのデフォルトの上に独自のテーブルを追加します。WooCommerceストアは、注文、製品、顧客データのテーブルを追加します。フォームプラグインは、すべての送信データのテーブルを追加します。

WordPressで構築するものが増えるほど、データベースは大きくなります。

WordPressデータベースを保護する必要がある理由

データベースは、すべての悪意のある攻撃者が狙う単一障害点です。盗まれたり破壊されたりする価値のあるものはすべてそこにあります。

SQLインジェクションは依然として一般的な攻撃手法です。ハッカーは、ログインフォーム、検索ボックス、または脆弱なプラグインフィールドを通じて、慎重に作成された入力を送信します。入力が適切にサニタイズされていない場合、データベースはそれをコマンドとして扱い、実行します。

そこから、攻撃者はデータベース全体を読み取ってエクスポートしたり、新しい管理者アカウントを作成したり、投稿に悪意のあるコンテンツを注入したり、すべてを一度に削除したりできます。

wp-config.phpファイルは、もう一つの主要な標的です。これには、データベース名、ユーザー名、パスワードがプレーンテキストで含まれています。そのファイルを入手した攻撃者は、WordPressのログインを必要としません。彼らは直接データベースに接続し、WordPressを完全にバイパスします。

ほとんどのサイト所有者が不意を突かれるのは、これらの侵害がいかに静かであるかということです。不正な管理者アカウントや注入されたコードは、通常、すぐに目に見える問題を引き起こしません。スパムリダイレクトや改ざんされたコンテンツに気づく頃には、攻撃者はすでに数週間もアクセスしていた可能性があります。

だからこそ、セキュリティ強化だけでは不十分なのです。何かをすり抜けた場合に、変更を検出し、クリーンなバックアップから復元する方法も必要です。

開始する前に必要なもの

変更を加える前に、以下のすべてが整っていることを確認してください。特にバックアップ手順をスキップすると、テーブルプレフィックスの変更などの手順で多くの人が苦労しています。リスクを冒す価値はありません。

• ホスティングコントロールパネルへのアクセス。 cPanel、MyKinsta、WP Engineダッシュボード、またはホストが提供するその他のパネルにログインする必要があります。いくつかの手順ではphpMyAdminを使用しますが、これは通常、コントロールパネルの「データベース」セクションの下にあります。
• FTPアクセスまたはファイルマネージャー。サーバー上のファイル、特にwp-config.phpを表示および編集する方法が必要です。ほとんどのホストは、コントロールパネルに直接ファイルマネージャーを提供しています。
• 現在のデータベース認証情報。 wp-config.php を開き、DB_NAME、DB_USER、DB_PASSWORD、DB_HOST の値を見つけます。これらはステップ 3 から 5 で参照します。
• 開始前に取得したサイト全体のバックアップ。 Duplicator のようなバックアッププラグインを使用するか、手動でバックアップを作成します。サイトファイルとデータベースのコピーがあることを確認してください。これらのステップの一部ではデータベースに直接変更が加えられるため、問題が発生した場合に復元できるクリーンなポイントが必要です。
• WordPress 管理者アクセス。 このチュートリアルのいくつかのステップで管理者としてログインする必要があります。

WordPress データベースを保護する方法

攻撃が発生する前に WordPress データベースを保護するための 13 の簡単なステップを紹介します。

最初の 8 つのステップはデータベース自体を強化し、最も一般的な攻撃経路を閉じます。ステップ 9 から 13 は、強化だけでは不十分な場合に保護するバックアップ、監視、および復旧レイヤーをセットアップします。

実行することの概要は次のとおりです。

• ステップ 1: デフォルトの管理者ユーザー名とユーザー ID を変更する。自動化された WordPress 攻撃で最も標的とされる 2 つの認証情報を削除します。
• ステップ 2: デフォルトのデータベーステーブルプレフィックスを変更する。SQL インジェクション スクリプトがターゲットとするように構築されている予測可能な wp_ プレフィックスを置き換えます。
• ステップ 3: 権限を制限した専用データベースユーザーを作成する。WordPress が実際に必要とする 4 つの権限のみにデータベースユーザーを絞り込みます。
• ステップ 4: リモートデータベース接続を無効にする。MySQL の設定レベルでデータベースへの外部アクセスを閉じます。
• ステップ 5: wp-config.php ファイルを保護する。データベース認証情報をプレーン テキストで保存するファイルをロックダウンします。
• ステップ 6: データベース接続に SSL を有効にする。WordPress と MySQL が別々のサーバーで実行されている場合、転送中のデータを暗号化します。
• ステップ 7: Web アプリケーション ファイアウォールを追加する。SQL インジェクションの試みがデータベースに到達する前にフィルタリングします。
• ステップ 8: 廃止されたプラグイン テーブルをクリーンアップする。アンインストールされたプラグインによって残された、データベースを肥大化させ、パッチが適用されていない脆弱性を運ぶ孤立したテーブルを削除します。
• ステップ 9: 暗号化されたバックアップを設定する。 AES-256 暗号化をオンにして、誰かが直接ダウンロードした場合でも、キーなしではバックアップ ファイルを読み取れないようにします。
• ステップ 10: 自動データベース バックアップをスケジュールする。バックアップ ルーチンからヒューマン エラーを排除し、忙しくても常に最新の復元ポイントを確保します。
• ステップ 11: バックアップをオフサイトに保存する。サーバーからコピーを取得し、ホストレベルの侵害で復旧オプションがすべて消去されないようにします。
• ステップ 12: データベースの変更を監視する。不正な管理者アカウントの作成や不正な変更をリアルタイムでキャッチします。
• ステップ 13: データベースの復元をテストする。必要になる前に復旧計画が機能することを確認します。

ステップ1：デフォルトの管理者ユーザー名とユーザーIDを変更する

WordPressはインストール時に、ユーザー名「admin」、ID 1のユーザーを作成します。これら2つの値は、WordPressを標的とするほぼすべての自動化されたブルートフォースおよびSQLインジェクションスクリプトに組み込まれています。これらを変更すると、データベース内の最も予測可能なターゲット2つが削除されます。

データベースに触れることなく、管理者ユーザー名を変更する簡単な方法を以下に示します。

1. WordPressで直接新しい管理者アカウントを作成する
2. その新しいユーザーとしてログインする
3. 元の管理者アカウントを削除する
4. そのコンテンツを新しいアカウントに再割り当てする

データベースで直接変更を行う必要がある場合は、phpMyAdminを使用して次のように行います。

ホスティングコントロールパネルからphpMyAdminにログインし、左側のサイドバーからWordPressデータベースを選択して、SQLタブをクリックします。次のクエリを1つずつ実行します。

UPDATE wp_users SET user_login = 'yournewname' WHERE user_login = 'admin';

UPDATE wp_users SET ID = 101 WHERE ID = 1;

UPDATE wp_posts SET post_author = 101 WHERE post_author = 1;

UPDATE wp_usermeta SET user_id = 101 WHERE user_id = 1;

4つのクエリすべてが必要です。ユーザーIDはwp_users、wp_posts、wp_usermetaに表示されるため、最初のテーブルのみを更新すると、他の2つのテーブルに壊れた参照が残ります。

何かを実行する前に1つの警告：最初に完全なバックアップを取得してください。直接SQLクエリのタイプミスは、バックアップがないと元に戻すのが難しい方法でサイトを壊す可能性があります。

私はこれにDuplicatorを使用するのが好きです。初心者向けのバックアッププリセットがあり、データベースまたはサイト全体のクイックコピーを取得できます。

Duplicatorは、私が試したすべてのバックアッププラグインの中で最高の復元ツールを持っています。このチュートリアルで後ほど、それらがどのように機能するかを確認できます！

変更が機能したことを確認するには、WordPressからログアウトし、新しいユーザー名で再度ログインします。ダッシュボードは以前と同じようにロードされるはずです。

ステップ2：デフォルトのデータベーステーブルプレフィックスを変更する

WordPressはデフォルトで、すべてのデータベーステーブルにwp_プレフィックスを付けます。WordPressを標的とするSQLインジェクションスクリプトは、これを基に構築されています。

プレフィックスを予測不可能なものに変更しても、それだけでは洗練された攻撃者を阻止することはできませんが、自動化されたツールが最初のパスでヒットするターゲットのプールからサイトを削除します。

これを行うには、セキュリティプラグインを使用する方法（ほとんどのユーザーに推奨）またはphpMyAdminを使用して手動で変更を行う方法の2つの方法があります。

プラグイン方法（推奨）

プラグイン方法は、シリアライズされたデータを自動的に処理するため、初心者にとってより安全な選択肢です。一部のプラグインオプションテーブルは、プレフィックスをシリアライズされたPHPデータ内に格納しており、生のSQL検索および置換は、注意深く処理されない場合、そのデータを破損させる可能性があります。

All-In-One Securityには、組み込みの保護機能を持つデータベースプレフィックスツールが含まれています。

選択したプラグインをインストールし、そのデータベースツールセクションに移動して、そこからプレフィックスの変更を実行します。プラグインはwp-config.phpを更新し、すべてのテーブルの名前を変更し、シリアライズされたデータ参照を1回のパスで処理します。

手動方法

データベーステーブルプレフィックスを手動で変更したい場合は、次の手順に従ってください。

まず、FTPまたはファイルマネージャーを介してwp-config.phpを開き、$table_prefix行を新しいプレフィックスに更新します。文字、数字、アンダースコアのみを使用してください：

$table_prefix = 'site82_';

次に、phpMyAdminにログインし、WordPressデータベースを選択して、SQLタブを開きます。データベース内のすべてのテーブルに対してRENAME TABLEクエリを実行します：

RENAME TABLE wp_posts TO site82_posts;

RENAME TABLE wp_users TO site82_users;

Repeat this for all 12 core tables and any tables added by plugins.

次に、option_name列に古いプレフィックスを参照する行が含まれているwp_optionsテーブルを更新します。

UPDATE site82_options SET option_name = REPLACE(option_name, 'wp_', 'site82_') WHERE option_name LIKE 'wp_%';

最後に、同じ理由でwp_usermetaテーブルを更新します。

UPDATE site82_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'site82_') WHERE meta_key LIKE 'wp_%';

これらのクエリを実行した後、アクティブなプラグインを確認してください。一部のプラグインは、独自のデータ行にプレフィックスを格納しており、それらも更新する必要があります。何か問題が発生した場合は、変更前のバックアップが、動作状態に戻るための最も簡単な方法です。

すべてが正常に機能したことを確認するには、サイトのホームページにアクセスし、ログアウトしてからWordPressダッシュボードに再度ログインしてください。どちらも以前とまったく同じように機能するはずです。

ステップ3：権限を制限した専用データベースユーザーを作成する

WordPressがインストールされると、ほとんどのホスティング設定では、データベース全体に対して完全な管理者アクセス権を持つデータベースユーザーが作成されます。通常、WordPressの実行に必要なのは、SELECT、INSERT、UPDATE、DELETEの4つの基本的な権限のみです。それ以上の権限は、追加のリスクを生み出す可能性があります。

攻撃者がプラグインの脆弱性を悪用してデータベース認証情報にアクセスした場合、権限の制限は、データを読み取られるのとデータベース全体を削除されるのとの違いとなります。

これには2つのアプローチがあります。既存のデータベースユーザーの権限を制限するか、WordPressに必要な権限のみを持つ新しい専用ユーザーを作成します。

phpMyAdminを介した権限の制限

phpMyAdminにログインし、上部にある**ユーザーアカウント**をクリックし、リストからWordPressデータベースユーザーを見つけて、**権限の編集**をクリックします。SELECT、INSERT、UPDATE、DELETE以外のすべてをオフにします。下にスクロールして**実行**をクリックして保存します。

SQLを介した新しい専用ユーザーの作成

クリーンなセットアップをご希望の場合は、phpMyAdminの**SQL**タブでこれらのクエリを実行してください。

CREATE USER 'wpuser_secure'@'localhost' IDENTIFIED BY 'StrongPasswordHere';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser_secure'@'localhost';

FLUSH PRIVILEGES;

If you create a new user, update your wp-config.php file with the new credentials:

define('DB_USER', 'wpuser_secure');

define('DB_PASSWORD', 'StrongPasswordHere');

**重要な注意点**：一部のプラグインやWordPressコアのメジャーアップデートでは、インストール中にデータベーステーブルを追加または変更するためにCREATEまたはALTER権限が必要になります。このステップの後でプラグインのインストールが失敗した場合は、一時的にそれらの権限を再付与し、インストールを完了してから再度取り消してください。

同じサーバーで複数のWordPressサイトを実行している場合は、サイトごとに完全に別のデータベースと別のデータベースユーザーを使用してください。1つのサイトが侵害された場合、その分離により、攻撃者が他のサイトに到達するのを防ぐことができます。

権限が正しく設定されていることを確認するには、WordPressで下書き投稿を作成し、保存してから削除してください。これら3つのアクションがすべて成功すれば、データベースユーザーは必要なものだけを持っており、それ以上はありません。

ステップ4：リモートデータベース接続を無効にする

ほとんどのWordPressセットアップでは、WordPressとMySQLは同じサーバーで実行されます。外部IPがデータベースに直接接続できるようにする必要はありません。リモートアクセスをオープンにしたままにすると、攻撃者はインターネット上のどこからでもWordPressをバイパスしてMySQLに認証を試みることができます。

これを閉じる場所は2つあり、両方を確認する必要があります。

MySQL設定

サーバー（VPSまたはクラウドホスティング）を自分で管理している場合は、MySQLの設定ファイルを見つけます。通常、/etc/mysql/mysql.conf.d/mysqld.cnfにあります。bind-address行を探し、それが127.0.0.1に設定されていることを確認してください。

bind-address = 127.0.0.1

0.0.0.0に設定されている場合は、127.0.0.1に変更してMySQLを再起動し、変更を適用してください。

sudo systemctl restart mysql

データベースユーザーのホスト名

MySQLがlocalhostにバインドされていても、WordPressデータベースユーザーがユーザーレベルでもローカル接続に制限されていることを確認する価値はあります。

phpMyAdminでユーザーアカウントをクリックし、WordPressデータベースユーザーを見つけます。ホスト列には、localhostまたは127.0.0.1が表示されるはずです。 %ワイルドカードが表示されている場合、そのユーザーは任意のIPアドレスから接続できます。

%に設定されているユーザーを削除し、ホストをlocalhostとして再作成してください。

DROP USER 'wpuser'@'%';

CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'YourPassword';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser'@'localhost';

FLUSH PRIVILEGES;

共有ホスティングユーザー

共有ホスティングを利用していてMySQL設定ファイルにアクセスできない場合は、代わりにコントロールパネルを確認してください。cPanelでは、データベースセクションのリモートMySQLを探します。

そこにあるIPアドレスをすべて削除してください。これは、ホスティングレベルでリモートアクセスを閉じることと同等です。

リモートアクセスが無効になっていることを確認するには、phpMyAdminのユーザーアカウント画面で、WordPressデータベースユーザーにlocalhostのみが許可されるホストとして表示されているはずです。

ステップ5：wp-config.phpファイルを保護する

wp-config.phpファイルには、データベース名、ユーザー名、パスワード、および認証キーがプレーンテキストで含まれています。攻撃者がこのファイルを読むことができれば、データベースに直接接続するために必要なすべてを手に入れたことになります。これは、WordPressへの攻撃で最初に標的とされるファイルの一つです。

次の3つの保護をすべて組み合わせて適用してください。それぞれが異なる脆弱性を閉じます。

1. ファイルをWebルートの上に移動する

WordPressは、wp-config.phpが所定の場所に見つからない場合、自動的にルートの1つ上のディレクトリを探します。そのため、設定を変更せずにファイルを移動できます。サイトのルートが/public_htmlの場合、wp-config.phpを/home/username/に移動します。FTPまたはホストのファイルマネージャーを使用してこれを行います。

これはほとんどの標準的なホスティング設定で機能しますが、一部のマネージドホスティングプロバイダーはこれを許可していません。ホストがWebルートより上のアクセスを制限している場合は、次の2つの保護に進んでください。

2. .htaccess経由でWebアクセスをブロックする

WordPressのルートディレクトリにある.htaccessファイルに次のルールを追加します。これにより、パスを知っている人がいても、Apacheはファイルへの直接のブラウザリクエストをすべて拒否するように指示されます。

<Files wp-config.php>

order allow,deny

deny from all

</Files>

ホストが新しいApache構成を使用している場合は、代わりにこのバージョンを使用してください。

<Files "wp-config.php">

Require all denied

</Files>

3. ファイルパーミッションを400または440に設定する

ファイルパーミッションは、サーバー上のどのユーザーがファイルを読み取り、書き込み、または実行できるかを制御します。wp-config.phpを400に設定すると、ファイル所有者のみがそれを読み取ることができます。440に設定すると、サーバーグループにも読み取りアクセスが拡張され、一部のホスティング構成ではこれが必要になります。

ホストのファイルマネージャーで、wp-config.phpを右クリックし、[パーミッションの変更]を選択して、400を入力します。FTP経由では、ほとんどのクライアントでファイルを右クリックしてパーミッションを直接設定できます。

すべての3つの保護が有効になっていることを確認するには、ブラウザでyourdomain.com/wp-config.phpにアクセスしてみてください。403 Forbiddenエラーが表示されるはずです。

ステップ6：データベース接続にSSLを有効にする

WordPressとMySQLが同じサーバーで実行されている場合、それらの間のデータはローカルにとどまり、ネットワークを通過することはありません。しかし、データベースが別のサーバーで実行されている場合（VPSセットアップ、クラウドホスティング、またはマネージド環境で一般的）、そのデータはネットワーク接続を介して移動します。SSLがない場合、ログイン認証情報やセッショントークンを含め、プレーンテキストで移動します。

WordPressとMySQLが同じサーバーにある標準的な共有ホスティングを使用している場合は、この手順をスキップできます。データベースが別個に実行されているマルチサーバーアーキテクチャまたはクラウドセットアップを使用している場合は、スキップしないでください。

まずホスティングプロバイダーに確認する

多くのマネージドホスティングプロバイダーは、データベース接続用のSSLを自動的に処理します。Kinsta、WP Engine、Cloudwaysはすべて、インフラストラクチャレベルで暗号化されたデータベース接続を強制します。手動で変更を加える前に、ホスティングプロバイダーのドキュメントを確認してください。すでにカバーされている可能性があります。

MySQLサーバーでSSLを有効にする

自分でサーバーを管理している場合は、SSL証明書を構成し、暗号化された接続を要求するために、mysqld.cnfファイルに次の行を追加してください。

[mysqld]

ssl-ca = /path/to/ca.pem

ssl-cert = /path/to/server-cert.pem

ssl-key = /path/to/server-key.pem

require_secure_transport = ON

ファイルを保存した後、MySQLを再起動してください。

WordPressにSSLを使用するように指示する

/* That’s all, stop editing! */ という行の上に、次の行をwp-config.phpファイルに追加してください。

define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

これにより、WordPressのデータベース接続は、MySQLに接続する際にSSLを要求するようになります。

SSLがアクティブであることを確認するには、WordPressが次にデータベース接続を行った後にMySQLサーバーのエラーログを確認してください。アプリケーションユーザーに対してSSLがアクティブとしてリストされているはずです。

ステップ7：Webアプリケーションファイアウォールを追加する

前のステップでのデータベースの強化により、攻撃対象領域が大幅に削減されます。しかし、脆弱なプラグインがSQLインジェクションのエントリーポイントになるリスクを排除するものではありません。

Web Application Firewall (WAF)は、サイトの前に配置され、悪意のあるリクエストがWordPressやデータベースに到達する前にフィルタリングします。

データベースセキュリティにとって、WAFの最も重要な役割は、フォーム入力、URLパラメータ、リクエストヘッダー内のSQLインジェクションパターンを認識し、実行前にブロックすることです。また、悪意のあるIPやボットをブロックし、ブルートフォースログイン試行を減らし、疑わしいと思われる場合に確認できるブロックされたリクエストのログを保持します。

ほとんどのWordPressサイトには、次の3つのWAFオプションが適しています。

• Wordfence: WordPressプラグインとして直接インストールされます。無料版には基本的なSQLインジェクション保護を備えたWAFが含まれています。プレミアム版は、リアルタイムの脅威インテリジェンスとより高速なルール更新を追加します。
• Sucuri: プラグインベースのスキャナーとDNSレベルのWAFを提供します。DNSレベルのオプションは、すべてのトラフィックをSucuriのネットワークを経由させてからサーバーに到達させるため、より強力な保護を提供しますが、有料プランが必要です。
• Cloudflare: 基本的な攻撃フィルタリングをカバーする無料版を備えたDNSレベルのWAFです。有料プランは、より詳細なルールとアプリケーションレイヤー攻撃に対するより良いカバレッジを追加します。

セットアップ後にファイアウォールルールを調整する必要がある場合は、本番環境に適用する前に、ステージングサイトのコピーで変更をテストしてください。設定ミスのあるルールは、正当なトラフィックをブロックする可能性があります。お問い合わせフォーム、チェックアウトフロー、管理アクションはすべて一般的な犠牲者です。

WAFは補完的なレイヤーであり、すでに完了した強化手順の代わりになるものではありません。他のすべてをすり抜けたものをキャッチするフィルターと考えてください。

ステップ8：放棄されたプラグインテーブルをクリーンアップする

WordPressでプラグインをアンインストールすると、そのデータベーステーブルは通常そのまま残ります。WordPressはそれらを自動的に削除せず、ほとんどのプラグインは削除時に自分でクリーンアップしません。

時間の経過とともに、これらの孤立したテーブルはデータベースを肥大化させ、隠れたセキュリティリスクを生み出します。既知のSQLインジェクション脆弱性を持つプラグインのテーブルは、プラグイン自体がなくなっても悪用される可能性があります。

孤立したテーブルを特定するには、WP-OptimizeやAdvanced Database Cleanerのようなプラグインを使用してください。どちらもデータベースをスキャンし、現在アクティブなプラグインに対応していないテーブルにフラグを付けます。

1つをインストールし、データベース最適化スキャンを実行し、削除する前に結果を確認してください。

phpMyAdminでテーブルリストを手動で確認することもできます。左側のサイドバーからWordPressデータベースを選択し、テーブルリストを確認します。現在の$table_prefixと一致しないテーブル、または使用しなくなったプラグインの名前が付いたテーブルは、削除候補です。

ただし、最初に新しいデータベースバックアップを作成してください。テーブルを削除することは永続的であり、放棄されたように見える一部のテーブルはまだ積極的に使用されています。

WooCommerce、Gravity FormsやWPFormsのようなフォームプラグイン、およびメンバーシップまたはLMSプラグインに関連付けられたテーブルには特に注意してください。これらは、プラグインがアクティブでなくなった場合でも必要になる可能性のあるトランザクションレコード、フォーム送信、およびユーザーデータを格納していることがよくあります。

削除する前に、各候補テーブルをアクティブなプラグインリストとクロスリファレンスしてください。テーブルが何に属しているかわからない場合は、テーブル名と「WordPress」という単語を検索して、それを生成したプラグインを特定してください。

phpMyAdminで確認済みの孤立したテーブルを削除するには、テーブルを選択し、Operationsをクリックし、下にスクロールしてDrop Tableをクリックします。または、SQLタブから実行します。

DROP TABLE old_plugin_table_name;

クリーンアップがスムーズに進んだことを確認するには、テーブルを削除した後、サイトで簡単な機能テストを実行してください。ホームページを確認し、フォームがあればテストフォームを送信し、ログアウトして再度ログインしてください。

ステップ9：暗号化されたバックアップを設定する

上記の手順は、データベースへの攻撃が成功する可能性を減らします。この手順は、攻撃から抜け出すためのものです。

ほとんどの人はバックアップを災害復旧ツールと考えています。作成方法によっては、セキュリティリスクにもなり得ます。

Google Driveフォルダに置かれた暗号化されていないバックアップファイルは、データベース全体の2番目のコピーです。そのストレージアカウントへのアクセス権を持つ人は誰でも、ライブサイトに触れることなくダウンロードして開き、すべてのユーザーレコード、パスワードハッシュ、および顧客注文を読むことができます。暗号化により、キーなしではそのファイルは役に立たなくなります。

だから私は常にDuplicatorでバックアップを暗号化しています。このプラグインを使用すると、すべてのバックアップでAES-256暗号化を有効にすることができます。

AES-256は、金融機関や政府システムで使用されているのと同じ暗号化標準です。これを有効にすると、パスワードなしではバックアップアーカイブは完全に読み取れなくなり、誰かがストレージアカウントからファイルを直接ダウンロードした場合でも同様です。

保存する前に2つのことを行う必要があります。このパスワードを書き留めて、パスワードマネージャーに保存してください。それを失うと、暗号化されたバックアップは永久にアクセスできなくなります。WordPressの外にコピーを保管してください。

ステップ10：自動データベースバックアップをスケジュールする

暗号化されたバックアップは、問題が発生したときに実際にバックアップがある場合にのみ保護されます。

手動バックアップは、現実にはうまくいきません。大きなアップデートの前、移行の後、または何かがおかしいと感じたときに、バックアップを実行することを思い出します。毎日欠かさず実行することはありません。

そのギャップは、クリーンなロールバックと厄介なロールバックの違いです。攻撃者が不正な管理者アカウントを作成したり、悪意のあるコンテンツを注入したりして、2週間気づかなかった場合、その前に実行したバックアップが必要になります。

毎日のスケジュールは、24時間以内のクリーンな復元ポイントを提供します。手動バックアップの習慣は、最後に実行したものをバックアップとして提供します。

WordPressダッシュボードで、Duplicator Pro » Schedule Backupに移動し、Add Newをクリックします。バックアップスケジュールの名前を付け、テンプレートを選択します。たとえば、データベースバックアップテンプレートを作成できます。

ストレージの場所を選択します。Duplicatorは、ローカルバックアップだけでなく、Duplicator Cloud、Google Drive、Amazon S3、Google Cloudなどの一般的なクラウドストレージもサポートしています。

サイトの活動レベルに基づいて頻度を設定します。

毎日データベースバックアップを実行することは、定期的にコンテンツを公開したり、注文を処理したり、アクティブなユーザーアカウントを持っているサイトに適しています。週に一度は、データベースの変更がまれな静的または低トラフィックのサイトに適しています。

ステップ11：Duplicator Cloudでバックアップをオフサイトに保存する

サイトと同じサーバーに保存されたバックアップは、実際のバックアップではありません。サーバーが侵害されたり、ランサムウェアがファイルを暗号化したり、ホストで壊滅的な障害が発生したりすると、サイトを失ったのと同時にバックアップも失います。

オフサイトストレージは、「すべてを失った」と「20分で復旧した」を分けるものです。

Duplicator Cloudは、最も簡単なWordPressバックアップストレージオプションです。WordPressバックアップのために構築され、Duplicator Proに直接統合されており、API認証は必要ありません。

別のオプションをご希望の場合は、Duplicator ProはGoogle Drive、Amazon S3、Dropbox、OneDrive、およびCloudflare R2、Backblaze B2、DigitalOcean SpacesなどのS3互換ストレージプロバイダーもサポートしています。

ストレージを接続したら、バックアップスケジュールを編集し、実行後にコピーを接続されたストレージプロバイダーに自動的に送信するように設定します。

ホストに少なくとも1つのコピーを、オフサイトのクラウドストレージに1つのコピーを保管してください。重要なサイトや顧客データを扱うサイトの場合は、ローカルにダウンロードした3番目のコピーを追加することで、保護層がさらに強化されます。

復元が必要な場合、Duplicator Pro はアーカイブをサーバーに再ダウンロードすることなく、接続されているクラウドストレージから直接取得できます。

Duplicator Pro » Backups に移動します。クラウドバックアップを見つけて Restore をクリックします。これは手動ダウンロードよりも高速で、ローカルのバックアップコピーが失われた場合でも機能します。

wp-admin ダッシュボードにアクセスできない場合でも、クラウドバックアップを復元できます。Duplicator Cloud ダッシュボードを使用すると、部分的なデータベースバックアップであっても、あらゆるバックアップをリモートで即座にロールバックできます！

ステップ12：アクティビティログでデータベースの変更を監視する

攻撃者がデータベースへのアクセス権を取得した後に行う最も一般的な操作は、不正な管理者アカウントを作成することです。これにより、元の侵入口が閉じられてクリーンアップされた後でも、サイトへの永続的なアクセス手段が確保されます。

監視がない場合、そのアカウントは数週間静かに潜伏する可能性があります。アクティビティログプラグインを使用すると、作成された瞬間に検出されます。

アクティビティログ は、タイムスタンプと IP アドレスとともに、WordPress サイト上のすべての操作を記録します。ユーザーのログイン、新しいアカウントの作成、ロールの変更、設定の変更を簡単に追跡できます。

データベースのセキュリティにとって最も重要なイベントは、あなたが作成していない新しいユーザー、低レベルのアカウントが突然管理者権限を取得するロール昇格、および見慣れない IP アドレスからのログイン試行です。

アクティビティログは Duplicator Elite に無料で含まれています。プランが有効になったら、プラグインをダウンロードして WordPress にインストールしてください。すぐに追跡が開始されます。

ログを定期的に次の 3 つの点について確認してください。

1. 認識できない新しいユーザーアカウント。
2. あなたの操作なしでロールが変更された既存のユーザー。
3. チームの場所と一致しない IP アドレスからのログイン。

これらは、アクティブな侵害、または数日または数週間前に発生した侵害を示している可能性があります。

アクティビティログを使用すると、ユーザー、アクションタイプ、または日付範囲でログをフィルタリングし、結果をエクスポートできます。これは、通常の監査とインシデント対応の両方に役立ちます。インシデント対応では、不正な変更がいつ発生したかを正確に特定する必要があります。

ステップ13：データベースの復元をテストする

ほとんどの人は、迅速な復旧が必要な最もプレッシャーのかかる状況で、バックアップが壊れていることを発見します。テストは数分しかかかりません。アクティブなインシデント中に復元が失敗すると、はるかに多くのコストがかかります。

Duplicator Pro のワンクリックステージング機能を使用すると、ライブサイトに影響を与えることなく、別のステージング URL にバックアップを復元できます。Duplicator Pro » Staging で、新しいステージングサイトを作成します。

最近のフルサイトバックアップをブループリントとして選択します。ステージングサイトとライブサイトを区別するために、一意の管理者カラースキームを選択します。

Duplicator がステージングサイトの作成を完了すると、ライブサイトの完全なレプリカが作成されます。これは、テスト復元を実行するための効果的なテストグラウンドになります。

Duplicator の Import Backups ページにバックアップをアップロードします。復元が完了したら、ステージングサイトを確認してください。

ホームページを確認し、WordPressダッシュボードにログインして、いくつかの投稿を開き、プラグインの設定が正しく表示されていることを確認してください。何か不足していたり壊れていたりしても、実際の復旧中に見つけるのではなく、今見つけることができます。

復元テストが成功したことを確認するには、ステージングサイトがバックアップ日からすべてのコンテンツ、ユーザー、設定をそのまま保持した状態でクリーンに読み込まれる必要があります。

データベースセキュリティの問題のトラブルシューティング

各ステップを注意深く実行しても、問題が発生する可能性があります。ここでは、最も一般的な障害点と、それらを乗り越える方法を説明します。

テーブルプレフィックスを変更した後にサイトが真っ白になる

表示される内容: テーブルプレフィックスを変更した直後に、白い画面または一般的なPHPエラーが表示されます。

発生理由: 最も一般的な原因は、テーブル参照の欠落です。一部のプラグインは、オプションテーブルまたはユーザーメタテーブル内のシリアライズされたPHPデータ内に古いプレフィックスを格納しています。生のSQLクエリでテーブル名を更新しても、これらの内部参照が見逃された場合、WordPressは探しているものを見つけることができません。

修正方法: 直ちにバックアップを復元してください。これは、これらのデータベースセキュリティ手順を開始する前にバックアップが必須である理由です。

正常な状態に戻ったら、All-In-One Securityのようなプラグインを使用してプレフィックスの変更を行ってください。これらのツールはシリアライズされたデータを自動的に処理し、壊れた参照を残す可能性がはるかに低くなります。

wp-config.phpを編集した後、WordPressがデータベースに接続できない

表示される内容: フロントエンドに「データベース接続確立エラー」というメッセージが表示されるか、白い画面が表示されます。

発生理由: データベース認証情報値のいずれかにタイプミスがあることが最も一般的な原因です。wp-config.phpをサーバーが見つけられない場所に移動することが2番目に一般的な原因です。ファイル権限が制限されすぎている（例: 000）場合も、WordPressがファイルを読み込めなくなる可能性があります。

修正方法: FTPまたはファイルマネージャー経由で接続し、wp-config.phpを直接開きます。DB_NAME、DB_USER、DB_PASSWORD、DB_HOSTがすべて正しく、ホスティングコントロールパネルのものと完全に一致していることを確認してください。ファイルを移動した場合は、WordPressルートの1ディレクトリ上にあり、それより深くはないことを確認してください。権限が変更されている場合は、400または440に設定してください。

データベース権限を制限した後、プラグインが機能しなくなる

表示される内容: ステップ3を完了した後、プラグインでエラーが発生したり、設定の保存に失敗したり、データベース関連の通知が表示されたりします。

発生理由: 一部のプラグインは、独自のデータベーステーブルをインストールまたは更新するためにCREATEまたはALTER権限を必要とします。これらの権限が取り消されると、プラグインは必要な構造変更を行うことができません。

修正方法: phpMyAdmin経由でデータベースユーザーにCREATEおよびALTER権限を一時的に再付与してください。プラグインを更新または再インストールし、セットアップを完了させてから、これらの権限を再度取り消してください。これは、最小権限のデータベース設定を維持する上での通常のプロセスです。

何も機能しない: 完全復旧パス

サイトが応答せず、WordPressダッシュボードがロックされ、通常の手段でアクセスできない場合は、Duplicatorの災害復旧オプションのいずれかを使用してください。

Duplicator Cloudに保存されたバックアップは、リモートで復元できます。追加のトラブルシューティングなしで、サイトをオンラインに戻すことができます。

災害が発生する前に、バックアップをWordPressの復旧ポイントとして設定することもできます。災害復旧URLを安全な場所に保存してください。

サイトが機能しない場合は、このURLをWebブラウザに貼り付けて、手順に従ってください。

災害復旧またはクラウドバックアップを設定していない場合は、ホスティングプロバイダーの緊急サポートラインに連絡してください。ほとんどのマネージドホストは、独自のサーバーレベルのスナップショットを保持しています。リアルタイムでマルウェアが拡散しているアクティブな攻撃を受けているサイトの場合、WordfenceとSucuriはどちらも有料の緊急対応サービスを提供しています。

よくある質問（FAQ）

データベースを強化しました。その状態を維持する方法はこちらです。

これらの手順をすべて実行した場合、データベースは現在実行中の大多数のWordPressサイトよりも優れた状態になっています。

しかし、作業は完了していません。データベースのセキュリティは一度きりの設定ではありません。メンテナンスの実践です。

アクティビティログを毎月レビューし、ご自身の活動と一致しないものがないか確認してください。四半期ごとに復元をテストしてください。ストレージ接続は期限切れになり、暗号化パスワードは紛失し、バックアップが使用可能であることを知る唯一の方法は、それを使用することです。

新しいプラグインをインストールした後は、データベースユーザーの権限を再確認してください。一部のプラグインは、更新中に権限をエスカレートしますが、それをわかりやすくしません。また、新しいホストに移行する場合は、必ずステップ4と5を最初からやり直してください。リモートアクセス設定とファイル権限は、期待どおりに引き継がれない場合があります。

このセットアップを完了したら、データベースのみのバックアップを作成し、強化後のベースラインとして明確にラベル付けしてください。数か月後に侵害を調査する必要が生じた場合、そのベースラインは比較のためのクリーンな参照点を提供します。

150万以上のWordPressプロフェッショナルが、Duplicator Proをバックアップ、移行、ステージング、およびディザスタリカバリに使用しています。これは、AES-256暗号化アーカイブ、Duplicator Cloudオフサイトストレージ、ワンクリック復元、データベースのみのリカバリ、およびWordPress自体がロードされない場合でも復旧できるディザスタリカバリURLの基盤となるツールです。

このチュートリアルがお役に立った場合は、これらのガイドもブックマークする価値があります。

• WordPressデータベースの最適化方法
• 私が自分で実行したWordPressデータベース修復手順（開発者不要）
• WordPressデータベースメンテナンス：毎週、毎月、四半期ごとに行うべきこと
• WordPressは安全か？真実を明らかにします
• ウェブサイトをハッカーから保護する方法（究極のセキュリティガイド）
• ハッキングされたWordPressサイトを復旧する方法（専門家による9つのヒント）