「バックアップ、毎日取ってます」。では、今すぐ復元できますか？
バックアップを「毎日スケジュールを回していること」と捉えている現場は多くあります。しかしバックアップの本質は「取ること」ではなく「必要なときに必要なデータを復元できること」です。バックアップが存在していても、復元に数日かかる・復元できる環境がない・そもそも復元手順を誰も知らない。こうした状態では、バックアップは意味をなしません。
この記事では、バックアップ設計の基本原則・何をどこにどれだけ保存するかの考え方・ランサムウェア対策としての設計・復元テストの重要性を解説します。
インフラセキュリティの基礎的な考え方については「若手インフラエンジニアが最初に身につけるべきセキュリティ知識10選」を先にご覧ください。
バックアップが「取るだけ」で終わってしまう現場のリスク
バックアップを単純な作業として扱っている現場では、以下のような問題がインシデント発生後に発覚します。
| 症状 | 実態 |
|---|---|
| バックアップはあるが復元できない | バックアップデータは存在するが、復元手順が文書化されておらず担当者が異動・退職していて誰も復元方法を知らない |
| 復元に想定外の時間がかかる | バックアップからの復元を一度も試したことがなく、本番インシデント発生時に初めて復元を試みて数日かかることが判明する |
| バックアップもランサムウェアに暗号化されていた | バックアップ先が本番環境と同じネットワーク上にあり、ランサムウェアに感染した際にバックアップデータも同時に暗号化されてしまう |
インシデント発生後に「バックアップがあるから大丈夫」と思っていたら実際には使えなかった。このパターンを防ぐために、バックアップは「取ること」ではなく「戻せること」を設計の中心に置く必要があります。
インシデント発生時の対応フローについては「セキュリティインシデント対応入門」を参照してください。
バックアップ設計を支える3つの原則
バックアップの黄金律「3-2-1ルール」
3-2-1ルール
バックアップ設計の基本原則。「3つのコピーを・2種類の異なるメディアに・1つはオフサイトに保存する」というルール。単一障害点を排除してデータ消失リスクを最小化する。
3-2-1ルールはバックアップ設計の世界標準です。
- 3つのコピー：オリジナル1つ＋バックアップ2つ
- 2種類のメディア：例）内蔵ディスク＋外付けHDD、またはディスク＋テープ
- 1つはオフサイト：クラウドや物理的に離れた場所に1つ保存
3つのコピーが同じ場所・同じメディアにあれば、火災・洪水・ランサムウェアで同時に失うリスクがあります。オフサイトの1コピーが最後の砦になります。
RTO・RPOで「どこまで戻せればいいか」を定義する
バックアップ設計で最初に決めるべきことは「どこまで戻せればいいか」の定義です。これを数値化する2つの指標があります。
RTO（Recovery Time Objective：目標復旧時間）
インシデント発生からシステムが復旧するまでの許容時間。「4時間以内に復旧する」と定義する。RTOが短いほど高コストの設計が必要になる。
RPO（Recovery Point Objective：目標復旧時点）
インシデント発生時に許容できる最大のデータ損失量を時間で表したもの。「最大24時間前のデータまで失っても許容できる」と定義する。RPOが短いほどバックアップ頻度を上げる必要がある。
RTOとRPOはシステムの重要度によって変わります。
| システム重要度 | RTO目標 | RPO目標 | バックアップ頻度の目安 |
|---|---|---|---|
| 基幹業務システム | 4時間以内 | 1時間以内 | 1時間ごと以上 |
| 社内業務システム | 24時間以内 | 24時間以内 | 1日1回 |
| 開発・検証環境 | 72時間以内 | 72時間以内 | 週1回 |
RTOとRPOを定義せずにバックアップを設計すると「なんとなく毎日取っている」状態になり、本番インシデント時に要件を満たせない可能性があります。
フルバックアップ・差分・増分の違いと使い分け
フルバックアップ（Full Backup）
対象データをすべてコピーするバックアップ方式。復元が最もシンプルだが時間とストレージ容量が最も多く必要。
差分バックアップ（Differential Backup）
直前のフルバックアップ以降に変更されたデータのみをコピーする方式。復元にはフルバックアップ＋最新の差分バックアップの2つが必要。
増分バックアップ（Incremental Backup）
直前のバックアップ（フルまたは増分）以降に変更されたデータのみをコピーする方式。最もストレージ効率が良いが、復元にはフルバックアップ＋すべての増分バックアップが必要で時間がかかる。
| 方式 | バックアップ時間 | ストレージ容量 | 復元時間 | 適した用途 |
|---|---|---|---|---|
| フル | 長い | 大きい | 短い | 週次・月次 |
| 差分 | 中程度 | 中程度 | 中程度 | 日次 |
| 増分 | 短い | 小さい | 長い | 頻繁なバックアップ |
実務では「週次フルバックアップ＋日次増分バックアップ」という組み合わせが一般的です。
何を・どこに・どれだけ保存すべきか？
バックアップ対象の選定
すべてのデータを同じ頻度・同じ方式でバックアップする必要はありません。データの重要度に応じて優先順位をつけます。
| 優先度 | 対象データの例 | バックアップ頻度 |
|---|---|---|
| 高 | 顧客データ・財務データ・認証情報 | 1時間〜1日1回 |
| 中 | 業務文書・メールデータ・設定ファイル | 1日1回 |
| 低 | 開発データ・ログファイル・一時ファイル | 週1回〜 |
| 対象外 | OSインストールメディア・公開ソフトウェア | 不要（再取得可能） |
AD環境の設定データ（Active Directoryのシステム状態）は特に重要です。ADが復旧できなければドメイン環境全体が使えなくなります。ADのバックアップについては「Active Directoryとは？」のまとめセクションも参照してください。
オンサイト・オフサイト・クラウドを組み合わせた保存先設計
3-2-1ルールに基づいて保存先を設計します。
- オンサイト（社内）バックアップ：復元速度が速く日常的な復旧に適している。ただし火災・洪水・ランサムウェアで本番環境と同時に失うリスクがある。
- オフサイト（社外）バックアップ：物理的に離れた場所に保存することで、拠点ごとの災害リスクを分散できる。専用回線やVPNで接続した別拠点・データセンターが対象。
- クラウドバックアップ：オフサイトの代替として最も手軽な選択肢。
クラウドバックアップ（Cloud Backup）
データをクラウドストレージに保存するバックアップ方式。物理メディアの管理が不要・地理的な分散が容易・初期コストが低いという特徴がある。ただしインターネット回線速度に依存するため大容量データの復元に時間がかかる場合がある。
保存期間の設計
バックアップデータの保存期間は「いつ時点のデータが必要になるか」で決めます。
| 保存期間 | 用途 |
|---|---|
| 直近7日分 | オペレーションミスからの即時復旧 |
| 過去4週分（週次） | 数週間前の状態への復旧 |
| 過去12ヶ月分（月次） | コンプライアンス・長期保存要件 |
| 年次 | 法的保存義務がある場合 |
ランサムウェア対策としてのバックアップ設計
ランサムウェアはバックアップデータも標的にします。感染した端末からアクセスできるネットワーク上のバックアップは、同時に暗号化されるリスクがあります。
エアギャップ（Air Gap）
バックアップデータを本番ネットワークから物理的または論理的に切り離した状態。ランサムウェアがバックアップに到達できない状態を作ることが目的。
ランサムウェアを意識したバックアップ設計のポイントは以下の通りです。
バックアップをネットワークから切り離す
バックアップ完了後は接続を切断するか、オフラインメディア（テープ・外付けHDD）に保存することで感染リスクを低減できます。
イミュータブルバックアップを活用する
イミュータブルバックアップ（Immutable Backup）
一定期間は変更・削除できない状態でバックアップを保存する仕組み。ランサムウェアや内部不正によるバックアップの改ざん・削除を防ぐ。クラウドストレージのオブジェクトロック機能などで実現できる。
バックアップの認証情報を分離する
バックアップシステムへのアクセス権を本番環境の管理者アカウントと分離します。本番環境が侵害されてもバックアップへのアクセスを防ぐ設計です。最小権限の考え方については「最小権限の原則とは？」を参照してください。
バックアップで最も大切なのは、復元テストの実施です
バックアップ設計で最も見落とされがちで、最も重要なのが復元テストの定期実施です。
「バックアップを取っている」と「バックアップから復元できる」は別のことです。以下のような問題は復元テストをしない限り発覚しません。
- バックアップジョブがエラーで失敗し続けていた
- バックアップデータが破損していて復元できない
- 復元手順が古くなっていて現在の環境に対応していない
- 復元に想定の3倍の時間がかかることが判明する
復元テストの推奨頻度
| テストの種類 | 頻度 | 内容 |
|---|---|---|
| 部分復元テスト | 月1回 | 特定ファイル・フォルダの復元確認 |
| システム復元テスト | 四半期1回 | 検証環境でのシステム全体の復元確認 |
| 実地訓練 | 年1回 | 実際のインシデントを想定した復元演習 |
復元テストの記録は証跡として保管し、復元できることを定期的に証明できる状態にしておくことが重要です。
よくある失敗パターン
根強いのが、バックアップ先を本番サーバーと同じネットワークに接続したままにしてしまうケースです。ランサムウェア感染時にバックアップデータも同時に暗号化されてしまうため、3-2-1ルールに基づいてオフサイト・オフラインのコピーを必ず用意してください。
意外に多いのが、「バックアップジョブは毎日動いている」という認識のまま復元テストを一度もしていなかったというパターンです。ジョブが動いていることと復元できることは別物なので、最低でも四半期に1回は復元テストを実施してください。
そのうえ厄介なのが、RPOを定義していないためにインシデント発生後「どの時点のデータに戻せばいいか」が不明なまま復旧作業が進んでしまうケースです。事前にRPOを定義し、「最大○日前のデータまで失っても業務継続できる」という基準を持っておくことが重要です。
最後に見落とせないのが、バックアップシステムへのアクセス権限が本番の管理者アカウントと同一だったために、本番環境の侵害と同時にバックアップも操作・削除されてしまったケースです。バックアップ専用のアカウントを用意し、権限を分離してください。
バックアップ設計チェックリスト
設計
- [ ] システムごとにRTO・RPOを定義している
- [ ] 3-2-1ルールに基づいてバックアップ先を設計している
- [ ] バックアップ対象データの優先度を定義している
- [ ] 保存期間をRPO・コンプライアンス要件に基づいて設定している
ランサムウェア対策
- [ ] バックアップの少なくとも1つがオフサイト・オフラインに保存されている
- [ ] バックアップシステムの認証情報を本番環境と分離している
- [ ] イミュータブルバックアップの導入を検討・実施している
運用
- [ ] バックアップジョブの成否を毎日確認する仕組みがある
- [ ] 月1回以上の部分復元テストを実施している
- [ ] 四半期1回以上のシステム復元テストを実施している
- [ ] 復元手順書を文書化して最新の状態に保っている
- [ ] バックアップ・復元テストの記録を保管している
「取る」より「戻せる」を軸にバックアップを設計する
バックアップの価値は「取ること」ではなく「インシデント発生時に必要なデータを必要な時間内に復元できること」にあります。
3-2-1ルールでコピーを分散し、RTO/RPOで復旧目標を定義し、ランサムウェアを意識してオフサイトに保管し、復元テストで実効性を確認する。この4つが揃って初めてバックアップは機能します。
今すぐ、管理しているシステムのバックアップから実際にファイルを1つ復元してみてください。復元を試したことがなければ、検証環境でその場で試すのが一番の近道です。「取っているから大丈夫」ではなく「戻せるから大丈夫」と言える状態を、今日中に一つでも増やしましょう。
あわせてご覧ください
コメント