「バックアップは取っています」
「クラウドに保存しているので大丈夫です」
「外付けハードディスクにコピーしています」
「会計ソフトにもバックアップ機能があります」
中小企業の現場で、このような説明を聞くことがあります。
しかし、本当に重要なのは、バックアップが「ある」ことではありません。
必要なときに、必要なデータを、必要な時間内に戻せることです。
バックアップを取っているつもりでも、いざ復旧しようとしたら次のような問題が起きることがあります。
「バックアップ対象に重要フォルダが含まれていなかった」
「バックアップファイルが壊れていた」
「退職した担当者しか復元手順を知らなかった」
「復元用パスワードが分からなかった」
「バックアップ先もランサムウェアで暗号化されていた」
「戻せたが、業務で使える状態ではなかった」
この記事では、中小企業がバックアップを「取っている」状態から、実際に戻せることを確認し、記録として残すための復元テスト記録の作り方を整理します。
なお、この記事でいう「復元テスト記録」は、公的制度上の正式名称ではありません。バックアップの実効性を確認し、取引先や社内に説明できるようにするための実務上の記録です。
バックアップは基本対策に入っている
IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」では、「バックアップを取ろう！」が追加され、情報セキュリティ6か条になっています。IPAは、中小企業向けに、経営者が認識し実施すべき指針と、社内で対策を実践するための手順や手法をまとめたガイドラインとして同資料を公開しています。
また、IPAの「5分でできる！情報セキュリティ自社診断」では、重要情報のバックアップを定期的に行うこと、バックアップ媒体をバックアップ時のみパソコンに接続すること、取得方法を決めること、安全な場所に保管すること、そしてバックアップしたデータを戻せるか定期的に確認することが対策例として示されています。
つまり、バックアップ対策は「ファイルをコピーする」だけでは足りません。
公的資料でも、戻せるかどうかの確認まで含めて考える必要があります。
「バックアップがあります」で終わると危険な理由
バックアップがあると思っていても、復旧できないことがあります。
よくある原因は、次のようなものです。
| 原因 | 具体例 |
|---|---|
| 対象漏れ | 顧客管理データは取っていたが、見積書フォルダは対象外だった |
| 頻度不足 | 月1回しか取っておらず、直近3週間分のデータが失われた |
| 世代不足 | 最新バックアップだけを残しており、暗号化後のデータで上書きされていた |
| 接続しっぱなし | 外付けディスクやNASもランサムウェアで暗号化された |
| 手順不明 | 復元方法を知っている担当者が退職していた |
| 認証情報不明 | 復元用パスワード、管理者ID、暗号化キーが分からない |
| 環境不足 | 復元先のPC、サーバ、ソフトウェア、ライセンスが用意できない |
| 業務確認不足 | ファイルは戻せたが、会計ソフトや業務システムで開けなかった |
IPAのガイドライン本編でも、バックアップすべきデータの取得漏れを防ぎ、データ復旧を可能にするため、バックアップの対象・頻度を定め、遠隔地を含めた保管方法やリストア手順書を整備することが示されています。また、複数世代のバックアップや物理的隔離の考え方も説明されています。
「バックアップがあります」という説明だけでは、取引先や社内に対して十分ではありません。
「いつ、何を、どこから、誰が、どの手順で戻せることを確認したか」まで説明できる状態を目指します。
復元テストとは
復元テストとは、バックアップから実際にデータを戻し、業務で使える状態になるかを確認する作業です。
ここでいう「戻せる」とは、単にファイルが存在することではありません。
次のような状態を確認することです。
| 確認項目 | 内容 |
|---|---|
| データが戻る | 必要なファイル、データベース、設定情報が復元できる |
| 内容が正しい | 文字化け、破損、欠落、古すぎるデータがない |
| 権限が戻る | 必要な利用者だけがアクセスできる |
| 業務で使える | 会計ソフト、顧客管理、予約、請求、メール等で利用できる |
| 時間が分かる | 復元に何分・何時間かかるか分かる |
| 手順が分かる | 担当者以外でも手順書に従って作業できる |
| 証跡が残る | 実施日、担当者、対象、結果、改善事項が記録されている |
中小企業では、最初から大規模な災害復旧訓練を行う必要はありません。
まずは、重要なフォルダや業務データを1つ選び、テスト用の場所へ戻してみるところから始めます。
復元テストで確認する3つの目的
復元テストの目的は、主に3つです。
1. 本当に戻せるかを確認する
最初の目的は、バックアップファイルが実際に使えるかを確認することです。
バックアップソフトの画面に「成功」と表示されていても、実際には一部ファイルが失敗していることがあります。
クラウドストレージに保存されていても、権限や同期設定の問題で必要なデータが含まれていない場合があります。
そのため、定期的に復元し、ファイルを開く、システムに読み込む、業務担当者が確認するところまで行います。
2. どれくらい時間がかかるかを確認する
2つ目の目的は、復旧にかかる時間を把握することです。
バックアップがあっても、復旧に3日かかるのか、3時間で済むのかによって、業務への影響は大きく変わります。
例えば、予約システム、会計、給与、EC、受注管理、顧客管理などは、停止時間が長くなるほど顧客対応や売上に影響します。
復元テストでは、復元開始から業務確認完了までの時間を記録します。
3. 手順と担当者を確認する
3つ目の目的は、誰が、どの手順で復旧するかを確認することです。
中小企業では、バックアップ設定を外部保守会社、前任者、特定の社員だけが知っている場合があります。
その人が不在のときに事故が起きると、復旧できない可能性があります。
そのため、復元テストでは、作業者、確認者、承認者、保守会社の連絡先、必要なID・パスワードの保管方法も確認します。
まず決めるべきバックアップ対象
復元テストを始める前に、何を守るかを決める必要があります。
すべてのデータを同じ重要度で扱う必要はありません。
まずは、業務停止時の影響が大きいものから優先します。
| 優先度 | 対象例 | 理由 |
|---|---|---|
| 高 | 顧客情報、受注データ、予約データ、会計データ、給与データ | 業務継続、個人情報、請求、支払に直結する |
| 高 | 契約書、見積書、請求書、納品書 | 取引先対応、証跡、売上回収に必要 |
| 高 | Webサイト、ECサイト、問い合わせフォーム設定 | 顧客接点、売上、信用に影響する |
| 中 | 社内規程、業務マニュアル、手順書 | 復旧後の業務再開に必要 |
| 中 | メール、チャット、議事録 | 顧客対応履歴や判断経緯の確認に必要 |
| 中 | 端末設定、ソフト設定、プリンタ設定 | 復旧時間短縮に役立つ |
| 低 | 公開済みカタログ、公開画像 | 再取得や再作成が比較的容易な場合がある |
ここで重要なのは、情報資産台帳やSaaS・クラウド台帳と連動させることです。
5月前半の記事で整理した「証跡ファイル」「SaaS・クラウド台帳」に、バックアップ対象、保存先、頻度、復元確認日を追加すると管理しやすくなります。
バックアップ頻度と世代を決める
バックアップは、頻度と世代が重要です。
頻度とは、どれくらいの間隔でバックアップを取るかです。
世代とは、何日前、何週間前、何か月前のデータまで戻れるようにするかです。
| 項目 | 考え方 |
|---|---|
| 毎日バックアップ | 顧客情報、予約、会計、受注など、日々変わる重要データ |
| 週次バックアップ | 社内資料、契約書、業務マニュアルなど |
| 月次バックアップ | 長期保管が必要な会計資料、決算資料、規程類など |
| 複数世代 | 暗号化や誤削除に気づくのが遅れた場合に備える |
| 遠隔地保管 | 火災、災害、盗難、機器故障に備える |
| 物理的隔離 | ランサムウェア感染時にバックアップまで巻き込まれにくくする |
IPAのガイドラインでは、世代管理について、複数のタイミングにわたってバックアップを保持し、データが破損や障害によって失われた場合でも特定時点のバックアップに遡って復元できる方法として説明しています。また、物理的隔離について、本番環境から物理的に分離した場所に保存し、災害やサイバー攻撃時にバックアップデータが影響を受けるリスクを低減できる方法として説明しています。
「毎日取っているから安心」ではありません。
毎日、暗号化後のデータで上書きしてしまうと、戻れる過去がなくなります。
そのため、複数世代を残すことが重要です。
クラウドやSaaSもバックアップ確認が必要
クラウドサービスを使っている場合でも、バックアップ確認は必要です。
クラウドに保存しているからといって、自社が必要なタイミングで、必要な形式で、必要なデータを取り出せるとは限りません。
IPAのクラウドサービス安全利用の手引き説明資料では、クラウドサービスのセキュリティはサービス事業者と利用者が役割・責任を分担して維持・向上するものと説明されています。また、バックアップについて、サービス停止やデータの消失・改ざんに備え、重要情報を手元に確保して必要なときに使えるようにしているか、という確認項目が示されています。
SaaSやクラウドでは、次の項目を確認します。
| 確認項目 | 内容 |
|---|---|
| エクスポート可否 | CSV、Excel、PDF、バックアップファイル等で出力できるか |
| 復元可否 | 自社で復元できるか、サポート依頼が必要か |
| 履歴・世代 | 過去の状態へ戻せるか |
| 保存期間 | 削除データや履歴が何日残るか |
| アカウント | 退職者ではなく会社管理者が復元操作できるか |
| 契約プラン | バックアップ機能が無料プランに含まれるか |
| 解約時 | 全データを取り出せるか、形式に互換性があるか |
| 障害時 | サービス停止時の連絡先、SLA、復旧見込みを確認できるか |
同じくIPAの資料では、クラウドサービス利用終了時のデータ確保として、全データの返却、パソコンなどへのダウンロード、データの互換性・移植性、残留データの完全消去などが確認項目として示されています。
クラウドサービスは便利ですが、「クラウド事業者が何とかしてくれる」という前提だけでは危険です。
自社がどのデータを、いつ、どの形式で取り出せるかを台帳に記録しておきましょう。
復元テストの3段階
復元テストは、段階的に行うと続けやすくなります。
レベル1：ファイル単位の復元テスト
最初は、1つのファイルやフォルダを戻すだけで構いません。
| 項目 | 内容 |
|---|---|
| 対象 | 見積書フォルダ、請求書フォルダ、顧客一覧の一部 |
| 方法 | テスト用フォルダへ復元する |
| 確認 | ファイルが開けるか、文字化けがないか、日付が正しいか |
| 頻度 | 月1回または四半期に1回 |
| 記録 | 実施日、担当者、対象、結果、所要時間 |
これは最も始めやすい方法です。
バックアップソフトやクラウドストレージの復元機能を使い、実際に戻せるかを確認します。
レベル2：業務データの復元テスト
次に、業務アプリで使える状態まで確認します。
| 対象 | 確認内容 |
|---|---|
| 会計データ | 会計ソフトで読み込めるか、残高や仕訳が確認できるか |
| 顧客管理 | 顧客一覧、履歴、権限が正しく戻るか |
| 予約システム | 予約一覧、顧客連絡先、変更履歴が確認できるか |
| 給与データ | 給与ソフトで開けるか、対象月のデータが戻るか |
| Webサイト | ファイルだけでなく、データベース、画像、設定が戻るか |
この段階では、IT担当者だけでなく、業務担当者の確認が必要です。
IT担当者が「ファイルは戻りました」と言っても、経理担当者が会計ソフトで開けなければ復旧とはいえません。
復元テスト記録には、業務担当者の確認欄を入れましょう。
レベル3：業務再開を想定した復元訓練
最後は、業務再開を想定した訓練です。
例えば、次のようなシナリオを想定します。
| シナリオ | 確認すること |
|---|---|
| 共有フォルダが使えない | 代替保存先、バックアップからの復元、社内周知 |
| 会計データが消えた | 前日分まで復元し、請求処理を再開できるか |
| 予約システムが停止 | 前回出力した予約一覧で電話対応できるか |
| PCがランサムウェア感染 | 端末を隔離し、別PCで業務を再開できるか |
| クラウドサービス障害 | 手元のエクスポートデータで最低限の業務を続けられるか |
このレベルでは、単にバックアップから戻すだけではなく、連絡網、代替業務、顧客対応、復旧優先順位も確認します。
復元テストでやってはいけないこと
復元テストは、実施方法を誤ると本番データを壊す危険があります。
次の点に注意してください。
| NG対応 | 理由 |
|---|---|
| 本番フォルダへ上書き復元する | 現在のデータを誤って消す可能性がある |
| 本番システムでいきなり復元する | 業務停止やデータ破損につながる可能性がある |
| 権限を広げて復元する | 本来見られない人が個人情報や機密情報を見られる可能性がある |
| 感染疑いの端末で復元する | 復元データが再び暗号化・感染する可能性がある |
| テスト後にデータを放置する | 個人情報や機密情報が不要な場所に残る可能性がある |
| 記録を残さない | 後から本当に確認したか説明できない |
復元テストは、原則としてテスト用フォルダ、検証用PC、検証環境で行います。
個人情報や機密情報を含むデータを使う場合は、復元後の削除、アクセス権、作業記録も残します。
復元テスト記録に入れる項目
復元テストの結果は、証跡として残します。
おすすめの記録項目は次のとおりです。
| 項目 | 記録する内容 |
|---|---|
| 実施日 | テストを行った日 |
| 実施者 | 復元作業を行った人 |
| 確認者 | 業務上の確認を行った人 |
| 対象データ | 顧客管理、会計、共有フォルダ、予約データなど |
| バックアップ取得日時 | いつのバックアップから戻したか |
| 保存先 | 外付け媒体、NAS、クラウド、別拠点など |
| 復元先 | テスト用PC、検証フォルダ、検証環境 |
| 復元手順書 | 参照した手順書の版数 |
| 所要時間 | 復元開始から確認完了まで |
| 復元結果 | 成功、一部成功、失敗 |
| 確認内容 | ファイルが開く、業務ソフトで読み込める、権限が正しいなど |
| 問題点 | 対象漏れ、時間超過、パスワード不明、手順不備など |
| 改善策 | 対象追加、頻度変更、手順書修正、担当者追加など |
| 次回予定 | 次回の復元テスト日 |
| 証跡 | 画面、ログ、チェックリスト、作業メモなど |
記録は、Excel、スプレッドシート、社内チケット、紙のチェックシートのどれでも構いません。
重要なのは、後から見たときに「本当に戻せることを確認した」と分かることです。
復元テスト記録のサンプル
以下は、中小企業向けの簡単な記録例です。
| 項目 | 記録例 |
|---|---|
| 実施日 | 5月26日 |
| 対象データ | 請求書フォルダ、会計データ、顧客一覧 |
| バックアップ取得日時 | 5月25日 23:00 |
| 保存先 | 外付けHDD、クラウドバックアップ |
| 復元先 | 検証用PCのテストフォルダ |
| 実施者 | 総務担当 |
| 確認者 | 経理責任者 |
| 手順書 | バックアップ復元手順書 v1.2 |
| 復元開始 | 10:00 |
| 復元完了 | 10:25 |
| 業務確認完了 | 10:40 |
| 所要時間 | 40分 |
| 結果 | 一部成功 |
| 確認内容 | 請求書ファイルは開けた。会計データは読み込み成功。顧客一覧は3日前のデータだった |
| 問題点 | 顧客一覧のバックアップ頻度が週1回だった |
| 改善策 | 顧客一覧を毎日バックアップ対象に追加 |
| 次回確認 | 6月第1営業日 |
| 証跡 | 復元ログ、確認画面、経理確認メモ |
「一部成功」や「失敗」が出ることは悪いことではありません。
むしろ、事故が起きる前に問題を見つけられたという意味で、復元テストの価値があります。
月次点検チェックリスト
復元テストは、月次点検に組み込むと続けやすくなります。
| No | チェック項目 | 確認 |
|---|---|---|
| 1 | 重要データの一覧は更新されているか | □ |
| 2 | 新しく使い始めたSaaSやクラウドがバックアップ対象に入っているか | □ |
| 3 | バックアップ対象フォルダに漏れがないか | □ |
| 4 | バックアップ頻度は業務上の影響に見合っているか | □ |
| 5 | 複数世代のバックアップが残っているか | □ |
| 6 | バックアップ先が本番環境と分離されているか | □ |
| 7 | 外付け媒体を接続しっぱなしにしていないか | □ |
| 8 | 復元用ID・パスワード・暗号化キーの保管場所が確認できるか | □ |
| 9 | 手順書は現在の環境に合っているか | □ |
| 10 | テスト用の復元先が用意されているか | □ |
| 11 | 実際にファイルまたは業務データを戻して確認したか | □ |
| 12 | 業務担当者が内容を確認したか | □ |
| 13 | 復元時間を記録したか | □ |
| 14 | 問題点と改善策を記録したか | □ |
| 15 | 次回の復元テスト日を決めたか | □ |
月1回すべてを確認するのが難しい場合は、四半期ごとでも構いません。
ただし、顧客情報、会計、給与、予約、受注など、業務停止の影響が大きいものは優先的に確認します。
ランサムウェアを想定した復元確認
ランサムウェア対策では、バックアップの重要性がさらに高まります。
警察庁は、ランサムウェア感染が疑われる場合、感染したパソコン等をネットワークから隔離すること、調査に必要なログ等が消失する場合があるため電源を落とさないことを案内しています。また、感染原因等の調査、ログの適切な保管、脆弱性対策、パスワード変更も示しています。
JPCERT/CCも、ランサムウェア被害からの復旧について、切り離したシステムをネットワークに戻す前に、攻撃者が残したマルウェア、バックドア、不正な設定などが排除されていることを確認する必要があると説明しています。また、ランサムウェアにより暗号化されたファイルは通常復号が困難であり、バックアップが残されていないファイルは復旧が困難であるという前提で対応することが一般的としています。
つまり、ランサムウェア対応では、次の点を復元テストに含める必要があります。
| 確認項目 | 内容 |
|---|---|
| バックアップ先の分離 | 本番環境から切り離されているか |
| 世代管理 | 暗号化前の時点に戻れるか |
| 復元前調査 | 感染原因や侵入経路を確認できるか |
| クリーンな復元先 | 感染していない環境へ復元できるか |
| 再接続判断 | 復元後すぐに本番ネットワークへ戻さない |
| ログ保全 | 復元作業前に調査用ログを保存する |
| パスワード変更 | 侵害された可能性のある認証情報を見直す |
| 業務再開判断 | 技術復旧だけでなく、業務担当者が使えるか確認する |
「バックアップから戻せば終わり」ではありません。
侵入経路が残っていれば、復元後に再び暗号化される可能性があります。
個人データを扱う場合の注意点
顧客情報や従業員情報などの個人データを扱う場合、バックアップの復元可否は個人情報保護法対応にも関係します。
個人情報保護委員会は、漏えい等報告が必要な場合の例として、ランサムウェア等により個人データが暗号化され、復元できなくなった場合を示しています。また、不正の目的をもって行われたおそれがある個人データの漏えい等についても報告対象事態として説明しています。
NCOの「サイバーセキュリティ関係法令Q&Aハンドブック」でも、個人データの毀損について、ランサムウェアによる暗号化が該当し、バックアップからデータを復元できる場合は該当しないという整理が示されています。
そのため、個人データを扱う会社では、次の記録が特に重要です。
| 記録 | 理由 |
|---|---|
| 個人データの保存場所 | 事故時に影響範囲を特定するため |
| バックアップ対象 | どの個人データが保護されているか説明するため |
| 復元テスト結果 | 復元可能性を確認するため |
| 復元にかかる時間 | 業務停止や本人対応への影響を判断するため |
| 復元できなかったデータ | 漏えい等報告・本人通知の要否判断に関わる可能性があるため |
| 証跡 | 事故後に社内、取引先、関係機関へ説明するため |
法的判断は個別事案によって変わりますが、少なくとも「戻せるか確認した記録」は、事故時の説明材料になります。
復元手順書に入れておくこと
復元テストを行うと、手順書の不備が見つかることがあります。
復元手順書には、次の項目を入れておきます。
| 項目 | 内容 |
|---|---|
| 対象データ | 何を復元する手順か |
| 前提条件 | 必要なPC、ソフト、ライセンス、ネットワーク |
| 権限 | 復元できる管理者、承認者 |
| 必要情報 | ID、パスワード、暗号化キー、保管場所 |
| バックアップ保存先 | どこに保存されているか |
| 世代選択 | どの時点のバックアップを使うか |
| 復元先 | 本番ではなく検証先を指定するか |
| 手順 | 具体的な操作手順 |
| 確認方法 | 誰が、何を見て、成功と判断するか |
| 失敗時対応 | 誰に連絡し、どの代替手段を使うか |
| 証跡 | ログ、画面、チェックリストの保存方法 |
| 更新履歴 | 手順書をいつ、誰が更新したか |
手順書は、作った時点で終わりではありません。
復元テストの結果に合わせて更新します。
復元テスト後に改善すること
復元テストで問題が見つかったら、改善策を決めます。
| 問題 | 改善策 |
|---|---|
| 対象漏れがあった | バックアップ対象に追加する |
| 復元に時間がかかりすぎた | 優先順位、回線、保存先、手順を見直す |
| 世代が足りなかった | 保存期間・世代数を増やす |
| バックアップ先が同じネットワークだった | 分離、遠隔地保管、オフライン保管を検討する |
| 手順が古かった | 現在の環境に合わせて更新する |
| 担当者しか分からなかった | 手順書を整備し、代替担当者を決める |
| パスワードが不明だった | 管理方法を見直す |
| SaaSからデータを取り出せなかった | 契約プラン、エクスポート方法、代替手段を確認する |
| 業務担当者が確認していなかった | 復元テストに業務部門の確認欄を追加する |
失敗を責めるのではなく、改善につなげることが大切です。
復元テストは、事故の前に失敗できる貴重な機会です。
取引先に説明できる状態にする
バックアップと復元テストの記録は、取引先への説明にも役立ちます。
取引先からセキュリティチェックシートが届いた場合、次のように説明できます。
「重要データを台帳で管理しています」
「バックアップ対象、頻度、保存先を定めています」
「複数世代のバックアップを保持しています」
「バックアップ先を本番環境と分離しています」
「四半期ごとに復元テストを実施しています」
「復元結果と改善事項を記録しています」
これらは、単なる宣言ではなく、証跡として説明できます。
5月のテーマである「取引先・顧客に説明できる証跡」を考えると、バックアップ復元テスト記録は非常に重要な資料です。
よくある失敗
バックアップ対象を確認していない
バックアップソフトを導入していても、重要なフォルダやSaaSデータが対象に入っていないことがあります。
まず、何をバックアップしているのかを一覧化しましょう。
最新バックアップしか残していない
最新データだけを保存していると、暗号化後や誤削除後のデータで上書きされる可能性があります。
複数世代を残すことが重要です。
外付け媒体を接続しっぱなしにする
外付けHDDやUSBメモリを常時接続していると、ランサムウェア感染時にバックアップまで暗号化される可能性があります。
IPAの自社診断でも、バックアップ媒体はバックアップ時のみパソコンと接続することが対策例として示されています。
クラウドにあるだけで安心する
クラウドサービスでも、停止、消失、改ざん、アカウント侵害、解約時のデータ取得などを考える必要があります。
重要情報を手元に確保し、必要なときに使えるようにする確認が必要です。
復元テストをしていない
バックアップの成否画面だけを見ていても、戻せるかは分かりません。
定期的に復元テストを行い、業務担当者が確認しましょう。
記録を残していない
復元テストを実施していても、記録がなければ取引先や社内に説明しにくくなります。
実施日、対象、結果、所要時間、改善策を残しましょう。
まとめ
バックアップは、「ある」だけでは不十分です。
必要なときに戻せることを確認して初めて、業務継続や事故対応に役立ちます。
中小企業でまず行うべきことは、次の10項目です。
- 重要データを一覧化する
- バックアップ対象、頻度、保存先を決める
- 複数世代のバックアップを残す
- バックアップ先を本番環境と分離する
- SaaSやクラウドのエクスポート方法を確認する
- 復元用ID、パスワード、暗号化キーの管理方法を決める
- 手順書を作成する
- テスト用環境へ実際に復元する
- 業務担当者が使える状態か確認する
- 実施日、結果、所要時間、改善策を記録する
バックアップ対策の目的は、保存することではありません。
業務を止めないこと、顧客情報を守ること、事故時に説明責任を果たすことです。
まずは、請求書フォルダ、会計データ、顧客一覧など、影響が大きいデータを1つ選び、テスト用フォルダへ復元してみましょう。
その結果を記録することが、実効性のあるバックアップ対策の第一歩です。
ライトハウスコンサルタントでは、情報処理安全確保支援士による情報セキュリティに関するコンサルティング、SECURITY ACTION取得サポート、CIOアウトソースサービスなどを行っています。バックアップ設計、復元テスト記録、SaaS・クラウド台帳、インシデント対応体制の整備に不安がある場合は、早めに専門家へ相談することをおすすめします。
