こんにちは、かつコーチです。
情報漏えいやランサムウェアの被害が相次いで報じられる中、「バックアップは取っているから大丈夫」と考えている方も多いかもしれません。
しかし、「バックアップを取っている」ことと「実際に復元できる」ことは別の話です。今回はこの点を整理します。
よくある落とし穴
落とし穴①：バックアップが本番環境と同じ権限で消せる
本番サーバーを操作できるアカウントが、そのままバックアップの削除までできてしまう構成になっていないでしょうか。
この場合、本番環境への侵入を許してしまうと、バックアップごと消される可能性があります。
バックアップの保管場所・削除権限は、本番環境の操作権限とは分けて管理するのが基本です。
落とし穴②：バックアップが同一サーバー内にしかない
同じサーバー・同じストレージ上にバックアップを置いている場合、サーバー障害や侵害が起きた際に、バックアップごと失われるリスクがあります。
別のサーバー、別のクラウドリージョン、あるいはオフライン（切り離された）媒体への保管も検討しましょう。
落とし穴③：バックアップ処理が失敗していることに気づいていない
cron等で自動化されたバックアップ処理が、実は数週間前からエラーで止まっていた、というケースは珍しくありません。
「バックアップジョブを設定した」だけで終わらせず、成功・失敗の通知を受け取る仕組みまでセットで用意しておく必要があります。
実際に復元テストをしてみる
バックアップの信頼性を確かめる唯一の方法は、実際に復元してサービスが動くことを確認することです。
手順の一例
- 本番とは別の検証用サーバー・環境を用意する
- 直近のバックアップから、データベース・ファイルを復元する
- アプリケーションを起動し、主要な機能（ログイン、データ参照、決済等）が問題なく動くか確認する
- 復元にかかった時間を記録する（障害発生時の見積もりに使える）
- 確認結果（復元できた日付・かかった時間・問題点）を記録に残す
この復元テストを、年1回ではなく、定期的に（たとえば四半期ごとなど）実施できる体制を作っておくと安心です。
バックアップ保護の基本原則
英国のNCSC（National Cyber Security Centre）は、ランサムウェアに耐えるバックアップの原則として、バックアップ環境へのアクセスを限定し、本番環境から隔離できる構成を示しています。
具体的には、次のような点が挙げられます。
- バックアップ用のアカウントと、本番運用のアカウントを分離する
- バックアップデータへの書き込み・削除権限を、必要最小限の担当者のみに絞る
- 可能であれば、一定期間変更・削除できない「イミュータブル」なバックアップを併用する
まとめ
- 「バックアップを取っている」と「復元できる」は別物。定期的な復元テストが欠かせない
- 本番環境と同じ権限でバックアップを削除できる構成、同一サーバー内にしかない保管、失敗に気づけない運用は特に危険
- 復元テストでは、かかった時間と結果を必ず記録に残す
- バックアップ用アカウントの分離や、イミュータブルなバックアップの活用も検討する
今回のシリーズでは、AIエージェントによる自動攻撃の動向から、Docker APIの設定、そしてバックアップの復元確認まで紹介してきました。この機会に、自分が関わっているサービスの現状を一度点検してみてください。
コメント