改ざんの後、そのバックアップに戻してよいか

最初に決まっていないといけないのは、どの時点に戻すか

バックアップは日付ごとに複数あります。戻す作業そのものより先に決めなければならないのは、そのうちどれを選ぶかです。改ざんが入り込んだ後の日付を選ぶと、改ざんされたファイルごと書き戻すことになります。

選ぶには、いつ侵害されたかのおおよその時期が要ります。発見した日が侵入の日とは限らないため、時期を絞らないまま「いちばん新しいもの」を選ぶと、侵入後の日付を選んでいないことを確かめられません。侵入の時期を絞る手がかりと、その手がかりが残らない条件はレンタルサーバーで侵入経路を特定できない理由にまとめています。

選べる日付には期限があります。何日分を残すかは契約している事業者の仕様で決まるため、自社の契約を確認してください。以下は一例です。エックスサーバーの自動バックアップは、サーバー領域のWeb・メールデータとMySQLデータベース（サイトの投稿や設定を保管する仕組み）を1日1回コピーし、それぞれ過去14日分を保持します。全プランの標準機能で追加費用はかかりませんが、一部の旧サーバーではWeb・メールデータの保持が過去7日分です。メンテナンスや障害のときには、処理が一時的に止まることもあります。

つまり、発見が遅れるほど、侵害される前の状態を含む日付が保持期間の外へ出ていく可能性があります。戻せる期間は無期限ではありません。

戻すと、バックアップ日以降のものが消える

復元は、いまの状態に不足分を足す作業ではありません。実行したときに何が起きるかは事業者の実装で違うので、自社の契約先の記述を読む必要があります。これも一例として、エックスサーバーはサーバー領域のWeb・メールデータを復元したときの挙動を次のように書いています。「復元を実行すると、対象のディレクトリ・ファイルはすべてバックアップデータの内容に上書きされます。バックアップデータに存在しない、バックアップ日以降に作成されたファイル・ディレクトリはすべて削除されます」。

復元の対象はドメイン・ディレクトリごとに指定できます。選べるのはWeb領域、Web用設定ファイル、メール領域です。実行にはバックアップデータのサイズ分の空き容量も要ります。

ここで注意が必要なのは、いま引いた記述がWeb・メールデータの復元についてのものだという点です。データベースの復元は別の手順で、同社のデータベース自動バックアップからの復元（外部サイト）には復元できる期間が過去14日分であることと、復元の単位がデータベースであることは書かれていますが、戻したときに現在のデータがどう扱われるかは書かれていません。書かれていないことは、何も起きない根拠にはなりません。ここで読者ができるのは、実行前に確認することまでです。

この差は実務で効きます。10日前の状態に戻すとき、その後に増えた画像のようなファイルはWeb領域の話として上の記述が当てはまります。一方、その間に追加した投稿や、フォームの送信内容をデータベースに保存している場合のその記録は、データベース側にあります。扱いを確認しないと判断できません。

戻す材料は、ファイルとデータベースの両方が要る

「バックアップを取っている」という認識と、実際に戻せる材料があることは別です。WordPress公式ドキュメントは、典型的なWordPressサイトを完全に復元するには、データベースとファイルの両方のバックアップが必要としています。片方しかない状態は、戻せる材料が揃っていません。

同じ文書は、少なくとも直近3〜5個のバックアップを保持し、そのコピーをホスティングサーバー、クラウドストレージ、手元のPCなど異なる場所に保管するよう推奨しています。自動バックアップについては、処理が機能していることを確認するために、時々別途手動でバックアップを取ることを強く推奨しています。

この推奨をそのまま満たしていないからといって、復旧を始められないわけではありません。ここからは当方の実務上の判断です。改ざんからの復旧で先に効くのは、個数よりも保管先だと考えています。本番サーバーの中だけに置いたバックアップは、そのサーバーの管理権限を取られた場合、同じ権限で消したり書き換えたりできる位置にあります。保存先が別の権限で守られているなら、この限りではありません。手元のPCかクラウドストレージに複製が1つでもあるかを、先に確かめてください。

自動バックアップの対象範囲は、事業者ごとに違う

サーバー会社の自動バックアップにも、対象から外れるものがあります。エックスサーバーが例として挙げているのは、キャッシュ用のディレクトリ配下、デバッグ用の記録ファイル、メール保管用のディレクトリです。データベースも、テーブル数が1,000を超えるものや、破損や高負荷により処理を行えないものは対象から外れます。ファイル数が非常に多い場合など、特殊な事由でアカウント単位の対象外になることもあります。同社自身が「データの確実な保全を保証するものではありません」と明記し、利用者側でもバックアップを取ることを勧めています。

範囲の決まり方も事業者によって違います。さくらインターネットのバックアップ＆ステージング（外部サイト）は、バックアップ数が最大8で、対象はwww直下のWebコンテンツです。それ以外のコンテンツは対象外で、データベースのスナップショットはWordPressを利用している場合のみ使えます。1バックアップあたりの容量にも上限があり（レンタルサーバシリーズは60GB、データベースは1GB）、環境によってはすべてをバックアップできない場合があると記載されています。契約サービスが廃止されるとバックアップも削除されるため、定期的に手元へ保存することも求めています。

自社の契約でどこまでが対象なのかは、仕様を読まないと分かりません。バックアップの一覧に日付が並んでいることは、その日付の全体が揃っていることを意味しません。

公開を再開してよいかは、5つで決まる

ここまでを、自社の状況に当てはめる表にします。表が見ているのは、戻したサイトで公開を再開してよいかです。1行でも「戻すだけでは決まらない」の側に当てはまるなら、戻す作業を進めても公開を再開してよいかの結論は出ません。5行すべてが「戻して見込みが立つ」の側なら、復元して公開を再開する条件はそろっています。それでも、前の節で見た対象範囲の穴や、処理が行えなかったデータベースは残ります。事業者は中身の完全性までは保証していません。

入口の行は、戻した後に同じ状態へ引き戻されないかを見るものです。入口のほかに、再び置くための仕組みが残っている場合もあります。部分的な駆除で足りるのか作り直しへ寄せるのかは消しても再発する改ざんの判断基準で扱っています。

調べるための復元は、入口が分からなくても始められる

断念するのは公開の再開であって、調べるための復元ではありません。WordPress公式の侵害時の手引きは、バックアップがあるなら復元してそのまま原因の調査へ進める、と書いています。同じ手引きは、感染したままの状態のコピーも別に取っておくよう勧めています。あとで参照する材料になるためです。侵害の時期を絞る作業も、材料が揃っているかを確かめる作業も、公開へ戻さないまま行えます。

ただし、戻すバックアップに改ざんが含まれている可能性があります。ここからは事業者の仕様ではなく、改ざんされたプログラムが動く前提で置く、当方の実務上の安全条件です。次の4つを満たさない場所へ戻すと、調べるつもりで被害を広げます。

• 本番と権限を分ける：本番と同じFTP・データベース・管理者のパスワードを使わない。共用サーバーの別のサブドメインは、同じアカウントから他のサイトへ書き込めるなら、分けたことになりません。
• 外から見えない状態にする：検索避けではなく、アクセス制限で閉じます。復元した時点で改ざんされたページが公開されると、元の状態に戻したのと同じです。
• 外へ出ていく処理を止める：メール送信、外部への通知、時刻を決めて動く処理を止めます。仕込まれたプログラムが動いても、外へ届かない状態にします。
• 元のバックアップを書き換えない：復元用のコピーを別に取り、元のファイルは残します。復元の失敗と、調査のやり直しの両方に備えます。

本番と同じ権限で動く場所しか用意できないなら、分けられていません。復元を保留し、サーバー会社か対応できる相手に相談してください。

相談相手に確認すること

「公開を再開してよいかは、5つで決まる」の表で「戻すだけでは決まらない」側に当てはまった項目があるとき、または自分では確かめられない項目があるときに、サーバー会社や制作会社へ聞く内容です。回答が揃うと、復元を選ぶかどうかが決められます。調査と復旧を外部へ依頼する場合も、同じ項目が見積もりの前提になります（当方の対応範囲は緊急対応にまとめています）。

• データベースを戻したときの扱い：バックアップ日以降に増えたデータが上書きされるのか、残るのか。口頭だと後で行き違いが起きやすいので、メールなど後から読み返せる形で回答をもらえると確実です。
• 戻す範囲を選べるか：サイト全体か、ディレクトリ単位か。複数サイトを同じ契約で動かしている場合は、他のサイトへ影響が及ばないかもあわせて確認してください。
• いまの状態を先に取っておけるか：改ざんされた状態であっても、戻す前の記録は原因の調査に使えます。復元で消える前に別の場所へ保存できるかを確認してください。
• 復元に必要な空き容量が今あるか：バックアップデータのサイズ分の空きが要ります。足りないまま実行すると、復元が完了しないことがあります。
• 自社のデータベースが対象外の条件に当てはまらないか：テーブル数の上限や、処理に時間がかかるといった条件です。当てはまる場合、そもそもバックアップが取られていない可能性があります。