AWS LightsailのWordPressを移行！PHPの脆弱性対策とハマったポイント
こんにちは！はるぱかパパです！
今回は、このブログを運用している AWS LightsailのWordPress環境を移行したお話です。
きっかけは、PHPの脆弱性への対応。
これまでAWS LightsailのBitnami版WordPressを利用していましたが、セキュリティ対策を進めるため、新しいLightsail版WordPressの環境へ移行することにしました。
移行自体は無事に完了しましたが、データベースの復元やSSL証明書の設定、Jetpackのアクセス統計など、いくつかつまずいたポイントもありました。
備忘録も兼ねて、今回の作業内容を紹介します！
目次
- PHPの脆弱性対策が必要に！
- Bitnami版からLightsail版WordPressへ移行
- SSL証明書の設定でエラー発生！
- Jetpackのアクセス統計が引き継がれない！
- 移行後の動作確認
- ただし、PHP 8.2系も将来的には課題に
- まとめ：WordPressの移行はバックアップとDNS設定が重要！
PHPの脆弱性対策が必要に！
WordPressはPHPで動作しているため、WordPress本体やプラグインだけでなく、PHP自体のセキュリティ対策も重要です。
これまで利用していたLightsailのBitnami版WordPressでは、PHPの脆弱性への対応が必要になっていました。
AWSの公式ドキュメントでも、PHPの脆弱性への対応方法が案内されています。
そこで今回は、従来のBitnami版WordPressから、新しいLightsail版WordPressへ移行することにしました。
Bitnami版からLightsail版WordPressへ移行
今回実施したのは、既存のWordPress環境をそのままアップデートするのではなく、新しいインスタンスを作成して、ブログのデータを移行する方法です。
大まかな作業の流れは以下のとおりです。
- 旧WordPress環境のバックアップ
- 新しいLightsailインスタンスの作成
- WordPressのデータを復元
- 静的IPアドレスの付け替え
- ドメインとSSL証明書の設定
- HTTPS対応と動作確認
AWS公式にも移行手順が公開されているので、こちらを参考に進めました。
AWS公式：BitnamiからLightsailブループリントへの移行
① まずは旧WordPressをバックアップ
移行作業で一番重要なのがバックアップです。
今回は、WordPressのエクスポート機能に加えて、データベースとファイルも個別にバックアップしました。
WordPressのエクスポート
WordPressの管理画面から「ツール」→「エクスポート」を選択し、投稿や固定ページなどのデータを保存します。
データベースのバックアップ
MySQLのデータをエクスポートして保存します。
WordPressの記事や各種設定などはデータベースに格納されているため、こちらも重要です。
画像やプラグインなどのバックアップ
wp-content ディレクトリもバックアップしました。
ここにはアップロードした画像やテーマ、プラグインなどが保存されています。
WordPressのエクスポート機能だけでは、サイト全体を完全に復元できるわけではないので注意が必要です。
② 新しいLightsailインスタンスを作成
続いて、AWS Lightsailの管理画面から新しいWordPressインスタンスを作成します。
今回は従来のBitnami版ではなく、Lightsail版のWordPressブループリントを選択しました。
この時点では旧インスタンスを停止せず、新旧の環境を並行して用意しておきます。
新しい環境で問題なくWordPressが動作することを確認してから切り替えれば、万が一トラブルが発生しても元の環境に戻しやすくなります。
③ WordPressのデータを復元
新しいインスタンスが作成できたら、バックアップしたデータを復元します。
今回はWordPressのインポート機能に加え、MySQLのデータと wp-content のファイルも移行しました。
データベースの復元では、新しい環境のデータベース設定を確認し、バックアップしたSQLファイルをインポートします。
ただし、WordPressのインポートとデータベース全体の復元は、対象となるデータが重複することがあります。
一般的には、データベース全体を復元する方法か、WordPressのインポート機能を利用する方法のどちらかを中心に進めるのがわかりやすいと思います。
今回は環境の違いもあったため、設定やファイルの整合性を確認しながら作業しました。
特に、テーマやプラグイン、画像ファイルが正常に引き継がれているかは重要な確認ポイントです。
④ 静的IPアドレスを新しいインスタンスへ移行
データの復元が完了したら、公開先を新しいインスタンスに切り替えます。
AWS Lightsailでは静的IPアドレスを利用できるため、今回は旧インスタンスから静的IPアドレスをデタッチし、新しいインスタンスにアタッチしました。
これなら、既存のIPv4アドレスを引き継げるので、DNS設定の変更を最小限に抑えられます。
ただし、切り替えのタイミングによっては一時的にサイトへアクセスできなくなる可能性があります。
アクセスの少ない時間帯に作業するのがよさそうです。
SSL証明書の設定でエラー発生！
今回、少しハマったのがSSL/TLS証明書の設定です。
新しいWordPress環境でHTTPS対応を進めようとしたところ、次のようなエラーが表示されました。
DNS records do not match instance IPs.
Did not find IPv6 match for 1 domain(s).
どうやら、ドメインのDNS設定と新しいインスタンスのIPv6アドレスが一致していないことが原因のようです。
Route 53にAAAAレコードを追加
今回はAWS Route 53でドメインを管理しているため、DNS設定を確認しました。
IPv4アドレスに対応するAレコードは設定していましたが、新しいインスタンスのIPv6アドレスに対応するAAAAレコードが不足していました。
そこで、ルートドメインとwww用にAAAAレコードを追加しました。
| 項目 | 設定内容 |
|---|---|
| レコードタイプ | AAAA |
| レコード名 | ルートドメイン、www |
| 値 | 新しいLightsailインスタンスのIPv6アドレス |
| TTL | 300秒 |
なお、AAAAレコードは、インスタンスでIPv6が有効になっており、そのアドレスでWebサイトへ正常にアクセスできることを確認してから設定する必要があります。
DNSの変更が反映されるまで少し待ってから再度SSL証明書の設定を実行すると、無事に進めることができました！
WordPress側もHTTPSに統一
SSL証明書の設定が完了したら、WordPress内のURLもHTTPSに統一します。
WordPressの管理画面でサイトURLを確認するとともに、データベース内に残っているHTTPのURLも必要に応じて置き換えました。
この作業にはWordPressの管理ツール「WP-CLI」の検索・置換機能が便利です。
ただし、データベース内のURLを一括変更するため、必ずバックアップを取得し、事前に変更対象を確認してから実行する必要があります。
最後にWebサーバーを再起動し、HTTPSで正常にアクセスできることを確認しました。
無事にセットアップ完了しました！
HTTPSの設定は正しいのに「保護されていない通信」！？
実は、SSL証明書の設定が完了したあとにも、もうひとつつまずいたポイントがありました。
サーバー側のHTTPS設定は正しくできているはずなのに、ブラウザでブログを開くと、なぜか**「保護されていない通信」と表示される**のです。
「えっ、まだ設定が間違っているの？」
と思い、SSL証明書やWordPressの設定を確認しましたが、特に問題は見当たりません。
ブラウザのキャッシュや閲覧履歴を削除してみても改善せず……。
いろいろ試した結果、PCを再起動したところ、無事に保護された接続として表示されるようになりました！
どうやらブラウザやPC側に古い接続情報などが残っていた可能性がありそうです。
ただし、再起動によって解消した正確な原因までは特定できていません。
HTTPSの設定が正しいのにブラウザの表示が変わらない場合は、PCの再起動を試してみるのもひとつの方法ですね。
もちろん、再起動しても改善しない場合は、証明書の有効性や対象ドメイン、混在コンテンツなども確認する必要があります。
今回は無事に鍵マーク相当の保護表示が確認できて、ひと安心でした！
Jetpackのアクセス統計が引き継がれない！
WordPressの移行後、もうひとつ気になったのがJetpackです。
このブログでは、アクセス状況の確認にJetpackのアクセス統計機能を利用していました。
ところが、新しいWordPress環境に移行したところ、これまでのアクセス履歴がうまく引き継がれていませんでした。
記事や画像などは正常に移行できているのに、Jetpackの統計情報は別のようです。
Jetpackのアクセス統計はWordPress.com側のサイト情報とも関連しているため、単純にWordPressのデータを移行しただけでは、正しく引き継がれない場合があるようです。
ただ、よく考えてみると、このブログ（harupk.com）自体、ここしばらく更新が滞っていたんですよね……。
過去のアクセス履歴が引き継がれなかったのは少し残念ですが、今回はあまり気にしないことにしました（笑）。
せっかくサーバー環境も新しくなったことですし、これを機にブログの更新頻度ももう少し上げていきたいと思います！
心機一転、また少しずつ記事を増やしていきたいですね。
移行後の動作確認
インスタンスの切り替えが終わったら、WordPressが正常に動作しているか確認します。
今回は、トップページだけでなく、個別記事や管理画面なども確認しました。
特に気をつけたいのが、次のポイントです。
- 記事や固定ページが正しく表示されるか
- 画像が正常に表示されるか
- テーマやプラグインが動作しているか
- 管理画面にログインできるか
- HTTPSでアクセスできるか
- HTTPからHTTPSへのリダイレクトが機能しているか
- Jetpackなど外部サービスとの連携に問題がないか
また、PHPのバージョンやWordPressのサイトヘルスも確認しておきます。
新しい環境に移行したからといって、すべてのセキュリティ対策が完了するわけではありません。
OSやPHP、WordPress本体、プラグインなどの更新も引き続き必要です。
ただし、PHP 8.2系も将来的には課題に
今回の移行でひとまずPHPの脆弱性対応を進めることができましたが、気になる点もあります。
それは、今回利用したLightsailのWordPress用Linuxアプリ環境のPHPが8.2系であることです。
PHP 8.2の公式セキュリティサポートは2026年12月31日までとなっています。
つまり、今回移行した環境も、この先ずっと安心して利用できるわけではありません。
もちろん、ディストリビューションや提供元によっては独自にセキュリティ修正がバックポートされる場合もありますが、長期的には新しいPHPへ移行できる環境を考えておきたいところです。
次はAmazon Linux 2023かUbuntu？
そこで将来的には、WordPress専用のアプリケーションイメージではなく、OSから自分で構築する方法も検討しています。
候補は次の2つです。
Amazon Linux 2023
AWSが提供するLinuxディストリビューションです。
AWSとの親和性が高く、OSのサポート期間やパッケージ管理を考慮しながら環境を構築できるのが魅力です。
Ubuntu
情報量が多く、WordPressやPHPの環境構築に関するドキュメントも豊富です。
長期サポート版（LTS）を利用すれば、安定した運用も期待できます。
どちらも自分でWebサーバーやPHP、データベースなどを構築・管理する必要がありますが、その分、PHPのバージョン管理などの自由度が高くなります。
一方で、セキュリティ更新や運用管理の手間が増えるのはデメリットですね。
次回はこうした点も考慮して、より長期的に運用しやすい環境にしたいと思います。
まとめ：WordPressの移行はバックアップとDNS設定が重要！
今回は、PHPの脆弱性対策をきっかけに、AWS LightsailのWordPress環境をBitnami版からLightsail版へ移行しました。
データのバックアップと復元、静的IPアドレスの付け替えまでは比較的スムーズでしたが、SSL証明書の設定ではIPv6のDNSレコードが必要になり、少し苦戦しました。
さらに、HTTPSの設定が正しいのにブラウザでは保護されていないと表示されたり、Jetpackのアクセス統計が引き継がれなかったりと、細かいトラブルもありました。
それでも、PCの再起動でHTTPSの表示は正常になり、Jetpackの統計も以前から更新が止まっていたので、今回は深追いしないことに。
何より、ブログの記事や画像などを無事に移行できたので、ひと安心です！
WordPressは手軽にブログを運用できる一方で、サーバーのセキュリティ対策やPHPのサポート期限など、定期的なメンテナンスも欠かせません。
今回の移行はひとまず完了しましたが、将来的にはAmazon Linux 2023やUbuntuへの移行も検討していきたいと思います。
同じようにAWS LightsailでWordPressを運用している方の参考になればうれしいです！
それでは、また！