WordPressのバックアップには、wp-config.php のデータベースのパスワードや認証用のキー、会員のメールアドレスやパスワードハッシュ、問い合わせ内容などが含まれます。バックアップを外部に置くなら、暗号化してから送り、鍵と保存先の権限を分けて管理するのが基本です。この記事では、何から守るのかの整理、age や GPG を使った暗号化の手順、鍵の保管、保存先の権限設定、運用時の注意点を説明します。
何から守るのかを整理する
バックアップの暗号化と一口に言っても、守る場面はいくつかあります。
- 保存中のデータ：クラウドストレージや外付けディスクに置いたファイルが、設定ミスでの公開、認証情報の漏えい、ディスクの紛失などで第三者に読まれる
- 転送中のデータ：保存先へ送る途中で盗み見られる
- バックアップそのものの改ざん・削除：本番サーバーが乗っ取られ、バックアップも消されたり暗号化されたりする
転送中のデータは、SFTP や HTTPS で送れば通信路の暗号化で守られます。保存先の暗号化機能（クラウドストレージのサーバー側暗号化など）も有効ですが、これは事業者側で鍵を管理する方式が多く、アカウントの認証情報を盗まれた場合には平文で読み出せてしまいます。そのため、送る前に手元で暗号化しておく「クライアント側の暗号化」を基本にし、保存先の暗号化はその上に重ねる、と考えると整理しやすくなります。
3つ目の改ざん・削除は暗号化では防げません。後半で説明する、保存先の権限の分け方で対策します。
公開鍵方式で暗号化する（age）
おすすめは、公開鍵で暗号化する方式です。サーバーには暗号化用の公開鍵だけを置き、復号に使う秘密鍵はサーバーの外で保管します。こうすると、本番サーバーが乗っ取られても、過去のバックアップを復号されずに済みます。パスフレーズ方式では、自動実行のためにパスフレーズをサーバー上に置く必要があり、その利点が失われます。
age は、ファイル暗号化に絞ったシンプルなツールで、多くのディストリビューションでパッケージとして入れられます。鍵の作成は、サーバーではなく管理用の手元のPCで行います。
# 手元のPCで鍵を作る（key.txt が秘密鍵。表示される age1... が公開鍵）
age-keygen -o key.txtサーバー側では、公開鍵だけを指定して暗号化します。
#!/bin/bash
set -euo pipefail
umask 077
STAMP=$(date +%Y%m%d-%H%M)
RECIPIENT="age1examplepublickeyreplacewithyourown"
mysqldump --defaults-extra-file=/root/.wp-backup.cnf \
--single-transaction --quick wordpress \
| gzip \
| age -r "$RECIPIENT" -o "/srv/backup/db-$STAMP.sql.gz.age"暗号化されたデータはほとんど圧縮できないため、圧縮は暗号化の前に行います。umask 077 は、作られるファイルを所有者だけが読める権限にするための指定です。
復号は秘密鍵がある手元で行います。
age -d -i key.txt -o db.sql.gz db-20261018-0315.sql.gz.ageGPG を使う場合
GnuPG（GPG）でも同じ考え方で暗号化できます。すでに GPG の鍵を運用している組織では、こちらのほうが馴染みやすいでしょう。手元で作った鍵ペアのうち、公開鍵だけをサーバーに取り込んで使います。
# サーバーに公開鍵を取り込む
gpg --import backup-pubkey.asc
# 公開鍵で暗号化
gpg --batch --yes --encrypt --recipient backup@example.com \
--output db.sql.gz.gpg db.sql.gz取り込んだだけの公開鍵は「信頼されていない鍵」として扱われ、--batch では暗号化が止まることがあります。取り込み後に gpg --edit-key で信頼度を設定するなど、鍵の信頼の扱いを決めておく必要があります。挙動は GnuPG のバージョンによって違うため、手元の環境で確認してください（2026年10月現在）。
openssl enc でも暗号化はできますが、鍵の導出方法などのオプションを正しく指定しないと弱い設定になりやすく、改ざん検知の仕組みもありません。特別な理由がなければ、age や GPG、あるいは暗号化の機能を持つ restic（常に暗号化）や BorgBackup（リポジトリ作成時に暗号化方式を選ぶ）のようなバックアップツールを使うほうが安全です。
鍵の管理
暗号化の強さは、鍵の扱い方で決まります。鍵をなくせばバックアップは二度と戻せず、鍵が漏れれば暗号化の意味がなくなります。
- 秘密鍵はバックアップと別の場所に置く：バックアップと同じストレージに秘密鍵を置くと、両方が一度に漏れます。
- 秘密鍵のコピーを2か所以上に持つ：パスワード管理ツールと、オフラインの保管（暗号化したUSBメモリや紙への印刷など）のように、片方が失われても残るようにします。
- 誰が鍵にアクセスできるかを決める：担当者が1人しかいないと、その人が不在のときに復元できません。逆に、関係者全員が持っていると漏えいの経路が増えます。
- 鍵を変えるときは古い鍵も残す：鍵を新しくしても、古い鍵で暗号化した過去の世代を復号するには古い秘密鍵が要ります。保持期間が終わるまで破棄しないでください。
パスフレーズ方式をやむを得ず使う場合も、スクリプトに直接書かず、所有者だけが読める別ファイルに置き、ログやコマンド履歴に残らないようにします。コマンドラインの引数に渡したパスフレーズは、同じサーバーの他のユーザーからプロセス一覧で見えることがあります。
保存先の権限を分ける
暗号化しても、本番サーバーの権限でバックアップを削除できるなら、乗っ取りの際に消されてしまいます。保存先の認証情報は、次のように絞ります。
- 本番サーバーには書き込みだけを許可する：オブジェクトストレージなら、アップロードはできても削除や上書きはできない権限にします。
- 削除できない期間を設ける：S3 のオブジェクトロックやバージョニングのように、一定期間は消せない仕組みを使えるなら有効にします。設定内容や対応状況はサービスごとに違うので、各事業者のドキュメントを確認してください。
- 保存先ごとに認証情報を分ける：1つの漏えいで、すべての保存先に触られないようにします。
- バックアップサーバーから取りに行く：自前のバックアップサーバーがあるなら、本番から送るのではなく、バックアップサーバーが本番から取得する形にすると、本番からバックアップ先に手が届かなくなります。
サーバー内に残るバックアップに注意する
見落とされやすいのが、本番サーバー内に残る一時ファイルや、プラグインが作るバックアップです。公開ディレクトリの中に置かれたバックアップは、ファイル名を推測されるとブラウザからダウンロードされるおそれがあります。
- バックアップの作業ディレクトリは、公開ディレクトリの外に置く
- プラグインの保存先が
wp-content配下にある場合、外部ストレージに送ったあとにサーバー内のコピーを残さない設定にする、またはWebからのアクセスを拒否する .htaccessによる保護は Apache でしか効かず、Nginx では別途locationで拒否する必要がある
プラグインが保存先に置く .htaccess や index.html に頼っている場合、Nginx の環境では保護されていないことがあります。実際にブラウザからファイルの URL にアクセスし、拒否されることを確認してください。
個人情報としての扱い
会員情報や注文情報を含むバックアップは、個人情報を保存している場所の1つです。プライバシーポリシーで定めた保存期間を過ぎたデータが、古いバックアップの中に何年も残っていないかを確認し、保持期間をポリシーと矛盾しない長さにします。退会者のデータ削除の求めに応じた場合でも、バックアップからはすぐには消えないことが多いため、その扱いをどう説明するかも整理しておくと安心です。
定期的に復号を試す
暗号化したバックアップで起こりがちなのが、「鍵の場所が分からない」「鍵はあるが復号の手順を誰も知らない」という事態です。数か月に1回は、保管している秘密鍵を使って実際に復号し、展開して中身が読めることを確認してください。手順を文書にしておけば、担当者が変わっても復元できます。
まとめ
- 外部に置くバックアップは、送る前に手元で暗号化する。保存先の暗号化はその上に重ねる
- 公開鍵方式（age や GPG）なら、サーバーに復号の鍵を置かずに済む
- 圧縮は暗号化の前に行い、作業ファイルは所有者だけが読める権限で作る
- 秘密鍵はバックアップと別の場所に、2か所以上で保管する。古い鍵も保持期間中は残す
- 本番からは書き込みだけを許可し、削除できない仕組みと定期的な復号テストで備える