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

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

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

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

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

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

戻すと、バックアップ日以降のファイルが消える場合がある

実行したときに何が起きるかは事業者の実装で違うので、自社の契約先の記述を読む必要があります。これも一例として、エックスサーバーはサーバー領域のWeb・メールデータを復元したときの挙動を次のように書いています。「復元を実行すると、対象のディレクトリ・ファイルはすべてバックアップデータの内容に上書きされます。バックアップデータに存在しない、バックアップ日以降に作成されたファイル・ディレクトリはすべて削除されます」。反対に、既存のファイルを上書きするだけの方式なら、攻撃で後から置かれたファイルは残ります。WordPress公式の侵害時の手引き（外部サイト）も、管理画面からの再インストールは既存のファイルを上書きするだけのことが多く、攻撃では新しいファイルが置かれることが多いとしています。

同社の手順では、復元の対象をドメイン・ディレクトリごとに指定でき、選べるのはWeb領域（public_html の中）、Web用設定ファイル、メール領域です。同社は、新しいサーバーパネルの手順でWeb用設定ファイルを、名前のとおりの設定ファイルだけでなく、対象ドメインの public_html の外にあるデータとしています（旧サーバーパネルの手順では public_html と mail の外）。同社は、バックアップデータのサイズ分の空き容量がないと、復元に失敗する場合があるともしています。

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

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

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

「バックアップを取っている」という認識と、実際に戻せる材料があることは別です。WordPress公式ドキュメントは、典型的なWordPressサイトを完全に復元するには、データベースとファイルの両方のバックアップが必要だとしています。典型的なサイトで片方しかない状態では、戻せる材料が揃っていません。同じ文書は、ファイルとデータベースを1組として扱う（たとえば、ほぼ同じ時期に作る）とよいとしています。別々の手順で戻す場合も、日付をそろえます。

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

ここからは当方の実務上の判断です。この推奨をそのまま満たしていないからといって、復旧を始められないわけではありません。改ざんからの復旧で先に効くのは、個数よりも保管先だと考えています。本番サーバーの中だけに置いたバックアップは、そのサーバーの管理権限を取られた場合、同じ権限で消したり書き換えたりできる位置にあります。保存先が別の権限で守られているなら、この限りではありません。事業者の自動バックアップも、エックスサーバーのようにバックアップ専用のサーバーへコピーする仕組みなら、本番サーバーの中には置かれていません。サーバーパネルのログイン情報まで取られたおそれがあるなら、念のため、自動バックアップのほかに、手元のPCかクラウドストレージに複製が1つでもあるかを、先に確かめてください。

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

サーバー会社の自動バックアップにも、対象から外れるものがあります。エックスサーバーが対象外として挙げているものには、キャッシュ用のディレクトリ配下、デバッグ用の記録ファイル、ホームディレクトリ直下の特定のディレクトリ（/home/サーバーID/Maildir 配下など）があります。同社は、データベースも、テーブル数が1,000を超えるもの、破損などで処理を行えないもの、処理に大きな負荷がかかるか長時間に及ぶものは対象外になるとしています。ファイル数が非常に多い場合など、特殊な事由でごくまれに一部のアカウントを対象外とする場合もあるとしています。同社自身が「データの確実な保全を保証するものではありません」と明記し、利用者側でもバックアップを取ることを勧めています。

範囲の決まり方も事業者によって違います。さくらインターネットのバックアップ＆ステージング（外部サイト）は、「利用開始」を選んでから使う機能で、定期的な自動作成は、予定を設定して使う機能だと同社は説明しています。同社によると、バックアップ数は最大8で、対象はwww直下のWebコンテンツです。同社は、それ以外のコンテンツは対象外で、データベースのスナップショット（その時点の写し）はWordPressを利用している場合のみ使えるとしています。容量とファイル数にも上限があり（1バックアップあたりの容量はレンタルサーバシリーズで60GB、データベースは1GB）、環境によってはすべてをバックアップできない場合があると同社は記載しています。同社は、解約や料金の滞納などで契約サービスが廃止されるとバックアップも削除されるとし、定期的に手元の環境へバックアップを取るよう求めています。

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

公開を再開してよいかを見る5つの項目

ここまでを、自社の状況に当てはめる表にします。表で確かめるのは、戻したサイトで公開を再開してよいかです。1行でも「戻すだけでは決まらない」の側に当てはまるなら、戻す作業を進めても公開を再開してよいかは決まりません。5行すべてが「戻して見込みが立つ」の側なら、戻して公開を再開する方向で進められます。選んだ日付に改ざんが含まれていないことと、入口を実際に塞いだことは、戻した後、公開を再開する前に確かめます。上書きだけで戻す方式を使ったなら、戻した後のサイトに、バックアップに存在しないファイルが残っていないかも確かめます。サイトを公開したまま本番の領域へ復元すると、戻した時点で公開が始まるため、確かめる前に公開を止めておくか、別の環境へ戻して確かめます。本番の領域へ戻す前には、いまの状態の写しを別の場所へ取っておきます。戻す方式によってはバックアップ日以降に作られたファイルが消えるため、入口を確かめ直す材料と、その間の業務データを残すためです。

入口の行は、戻した後に同じ状態へ引き戻されないかを見るものです。引き戻されたときに、部分的な駆除で足りるのか作り直しへ寄せるのかは消しても再発する改ざんの判断基準で扱っています。

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

WordPress公式の侵害時の手引きは、バックアップがあれば、復元してそのまま原因の調査に取りかかれるはずだと書いています。同じ手引きは、清掃に進む前に、感染したままの状態の写しも取っておくよう勧めています。作業が大きく失敗したときにも、参照できる材料が残るためです。この手引きは、どこへ戻すかや、公開を止めるかには触れておらず、調べるために別の場所へ戻すことまで書いているわけではありません。

ここからは当方の実務上の判断です。入口が分からないときに断念するのは公開の再開で、調べるために戻すことまで断念する必要はありません。侵害の時期を絞る作業も、材料が揃っているかを確かめる作業も、公開を再開しないまま行えます。戻す場所には次の4つの条件を置きます。戻すバックアップにも改ざんが含まれている可能性があると見て、改ざんされたプログラムが動く前提で決めた条件です。4つを満たさない場所へ戻すと、調べるつもりで被害を広げるおそれがあります。

例にしたエックスサーバーの復元は、本番の領域を上書きする機能です。同社は、バックアップのデータを利用者へ渡す提供（外部サイト）もサーバーパネルから申し込めるとしています。同社によると、提供できるのは、同社が申し込みを確認した時点から14日前まで（一部の旧サーバーのWeb・メールデータは過去7日間）のデータで、同社は保管期限の近いデータは速やかに申し込むよう求めています。別の環境で調べるときは、提供を受けたデータを、次の4つを満たす場所へ置きます。

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

本番と同じ権限で動く場所しか用意できない場合や、外へ出ていく処理を止められない場合は、4つを満たせていません。復元を保留し、サーバー会社か対応できる相手に相談してください。

相談相手に確認すること

「公開を再開してよいかを見る5つの項目」の表のうち、「日付の残り」「材料」「以降の増分」の行を自分では確かめられないときに、サーバー会社や制作会社へ聞く内容です。1つ目は「日付の残り」と「材料」の行（手元の控えは自社で確かめます）、2つ目と3つ目は「材料」の行、4つ目は「以降の増分」の行の手がかりになります。5つ目から7つ目は、戻す作業を始める前に要る条件です。「侵害の時期」と「入口」は、記録の調査で決めます。調査と復旧を外部へ依頼する場合も、同じ項目が見積もりの前提になります（当方の対応範囲は緊急対応にまとめています）。

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