バックアップ実効性の確認|中小企業の復元テストとSCS対応

中小企業のバックアップ実効性確認で最も見落とされるのが基幹システムです。顧客情報・財務データが消えると事業再建は困難になります。★3対応で求められる確認体制を解説します。 セキュリティ資格

「バックアップは取れていますか」と聞くと、多くの会社では「毎日、自動で保存されています」と答えが返ってきます。

ところが、「そのデータを最後に戻したのはいつですか」「元のシステムが使えない状態でも復元できますか」と尋ねると、すぐには分からないことがあります。

バックアップの実効性は、保存処理が成功しているかだけでは判断できません。必要なデータを選び、安全な場所から、事業を再開できる時間内に戻せるかまで確認して、初めて被害時に使えるバックアップになります。

SCS評価制度でも、★3ではバックアップの対象・頻度・保管期間、重要な機密情報の遠隔地保管、リストア手順書が求められます。★4ではさらに、手順書どおり、目標復旧時間内に復元できることの確認まで進みます。

この記事では、制度の項目を説明するだけでなく、中小企業が自社のバックアップをどのように確認し、分からない部分をシステム会社へどう尋ねればよいかを整理します。

  1. バックアップ実効性とは「保存」ではなく「事業に戻せること」
    1. バックアップ成功の通知だけでは分からないこと
    2. データの復元と業務の再開は同じではない
    3. まず確認したい5つの質問
  2. 中小企業でバックアップの盲点になりやすい場所
    1. 基幹システムとファイルサーバー
    2. クラウドサービスのデータ
    3. PCにしか保存されていないデータ
    4. システムを戻すための設定・アカウント・手順
  3. ランサムウェアでバックアップまで使えなくなる理由
    1. 本番環境と同じ認証・ネットワークで管理している
    2. 感染後のデータを上書き保存している
    3. 保存世代と保持期間が足りない
    4. 復元先の安全確認と再構築を想定していない
  4. SCS★3で求められるバックアップ対応
    1. 対象・頻度・保管期間を決める
    2. 重要な機密情報は遠隔地にも保管する
    3. バックアップ対象ごとにリストア手順書を作る
    4. 事業上重要なシステムの目標復旧レベルを決める
  5. 復元テストはSCS★4でどこまで求められるか
    1. ★3と★4の違い
    2. 復元テストで確認する項目
    3. テスト頻度は自社の変更・重要度に合わせる
  6. バックアップの実効性を確認する手順
    1. 1.止まると困る業務から対象を選ぶ
    2. 2.必要な復旧時点と復旧時間を決める
    3. 3.保管場所・世代・アクセス権を確認する
    4. 4.リストア手順を文書化する
    5. 5.影響を抑えた範囲で復元テストを行う
  7. システム会社へ確認する内容
  8. バックアップ実効性の確認表
  9. バックアップ実効性についてよくある質問
    1. バックアップが毎日成功していれば復元テストは不要ですか?
    2. クラウドサービスなら自社のバックアップは不要ですか?
    3. SCS★3でも復元テストが必要ですか?
    4. 遠隔地バックアップとはクラウド保存でもよいですか?
    5. 復元テストで本番環境を止める必要がありますか?
    6. 3-2-1ルールはSCSの必須要件ですか?
  10. まとめ|「取れている」から「戻せる」へ確認を進める

バックアップ実効性とは「保存」ではなく「事業に戻せること」

バックアップの目的は、データを別の場所へコピーすることではありません。障害、誤操作、サイバー攻撃などが起きた後に、必要な業務を再開できる状態へ戻すことです。

保存処理が毎日成功していても、復元先がない、手順が古い、担当者が分からないといった理由で、すぐに業務を再開できない場合があります。

バックアップ成功の通知だけでは分からないこと

管理画面に「成功」と表示されているのは、決められたデータを保存先へコピーできたという意味であることが一般的です。しかし、次の点まで保証しているとは限りません。

  • 事業再開に必要なデータがすべて対象になっているか
  • 必要な時点のデータが残っているか
  • バックアップ自体が破損していないか
  • 元のシステムが使えなくても別の環境へ戻せるか
  • アプリケーション、設定、認証情報も復旧できるか
  • 担当者が手順を理解しているか

「バックアップが成功している」と「必要な業務を復旧できる」は、分けて考えたほうがよいでしょう。

データの復元と業務の再開は同じではない

販売管理システムのデータベースを復元できても、利用者がログインできなければ受注処理は再開できません。ファイルサーバーを戻せても、どのデータが攻撃前の安全な状態か判断できなければ、安心して使うのは難しくなります。

業務再開には、データのほかにも次の要素が関係します。

  • サーバー、PC、ネットワーク
  • OSやアプリケーション
  • システム設定とライセンス情報
  • ユーザアカウントとアクセス権
  • 外部サービスとの接続設定
  • 復旧を担当する社内外の連絡先
  • 復旧中に行う代替業務

そのため、バックアップの確認はIT部門だけの作業ではありません。「どの業務を、いつまでに、どの状態へ戻したいか」は、業務部門や経営側も一緒に決める必要があります。

まず確認したい5つの質問

専門的な方式を調べる前に、次の質問へ答えられるか確認してみると、自社の現状が見えやすくなります。

  1. 売上、請求、顧客対応などを再開するために、どのデータが必要か
  2. そのデータのバックアップは、最後にいつ成功したか
  3. 本番環境とは別の場所にも保管されているか
  4. 最後に実際のデータを復元したのはいつか
  5. 復元開始から業務再開まで、どのくらいかかるか

答えられない項目があっても、直ちに対策ができていないとは限りません。システム会社だけが情報を持っている場合もあります。まず「社内で分からないこと」を明らかにすると、確認先を決めやすくなります。

中小企業でバックアップの盲点になりやすい場所

バックアップというと、ファイルサーバーや基幹システムを思い浮かべるかもしれません。しかし、事業を再開するために必要なデータは、複数の場所に分かれていることがあります。

基幹システムとファイルサーバー

販売管理、在庫管理、会計、人事給与などのシステムが止まると、受注、出荷、請求、支払いといった日常業務へ影響します。

ここで確認したいのは、データベースだけではありません。アプリケーション本体、システム設定、帳票、連携プログラムなども、再構築に必要になる場合があります。

古い基幹システムでは、導入時の担当者が退職していたり、保守会社が変わっていたりすることもあります。バックアップの有無とあわせて、現在の復旧担当者や連絡先も確認しておくと安心です。

クラウドサービスのデータ

クラウドサービスを利用しているからといって、自社で確認することがなくなるわけではありません。

サービス事業者がシステム基盤を保護していても、利用者による誤削除、必要な保存世代、保持期間、自社が希望する時点への復元などが、現在の契約でどこまで対応されるかはサービスによって異なります。

次のような点を確認してみるとよいでしょう。

  • 削除したデータを何日間戻せるか
  • 過去の特定時点へ戻せるか
  • 復元は自社で行うのか、事業者へ依頼するのか
  • 復元に追加費用がかかるか
  • 契約終了時にデータを取り出せるか

PCにしか保存されていないデータ

共有サーバーやクラウドをバックアップしていても、従業員のPCにしか存在しない見積書、設計資料、集計ファイルなどがあるかもしれません。

個人のPCへ重要なデータを残さないルールを設ける方法もあれば、PCをバックアップ対象に含める方法もあります。まずは、事業に必要なデータがどこへ保存されているかを確認するところから始まります。

バックアップ対象を洗い出す際は、「IT資産管理台帳の作り方」で整理したシステムやクラウドサービスの一覧を利用できます。

システムを戻すための設定・アカウント・手順

データが残っていても、暗号鍵、管理者アカウント、接続先の設定、ライセンス情報が失われると、復旧作業が進まないことがあります。

バックアップ対象を検討するときは、「データ」だけでなく、「そのデータを使える状態へ戻すために必要なもの」まで確認することが大切です。

ランサムウェアでバックアップまで使えなくなる理由

ランサムウェア対策としてバックアップは有効ですが、保存方法によっては本番データと一緒に暗号化・削除されるおそれがあります。

IPAの「中小企業の情報セキュリティ対策ガイドライン第4.0版」には、VPN機器から侵入され、コンピュータやファイルサーバーがランサムウェアに感染した事例が掲載されています。原因・被害範囲の調査、システム復旧、再発防止などに約2.5億円以上、45人月を要した事例です。

これは、バックアップさえあれば短時間で元どおりになるとは限らないことを示しています。IPAの中小企業向けガイドラインでは、最新版の本編やインシデント対応の手引きを確認できます。

本番環境と同じ認証・ネットワークで管理している

バックアップ装置が本番サーバーから常に接続でき、同じ管理者アカウントで操作できる状態では、攻撃者もバックアップへ到達できる可能性があります。

本番環境とは異なる場所へ保存することに加えて、誰が削除・変更できるのか、通常時にどの経路からアクセスできるのかも確認します。

感染後のデータを上書き保存している

ランサムウェアが侵入してから発見まで時間がかかると、暗号化・改ざんされたデータを正常なバックアップへ上書きしている場合があります。

直近の1世代しか残していないと、安全な時点まで戻れません。どの程度の期間、何世代を残すかは、被害の発見にかかる時間と、失っても許容できるデータ量を踏まえて決めます。

保存世代と保持期間が足りない

毎日バックアップを取っていても、7日分しか残していない場合、2週間前から問題が始まっていたときには安全なデータが残っていないかもしれません。

一方、保存期間を長くすれば、費用や管理対象も増えます。重要な業務ごとに、どの時点まで戻る必要があるかを考えると、保持期間を決めやすくなります。

復元先の安全確認と再構築を想定していない

攻撃を受けたサーバーへそのままデータを戻すと、侵入原因が残った環境で再び被害を受けるおそれがあります。

実際の復旧では、被害範囲の調査、安全な復元時点の選定、サーバーの再構築、脆弱性への対処などが必要になる場合があります。バックアップの復元手順は、「コピーを戻す方法」だけでなく、安全に業務を再開する流れの中で考えます。

ランサムウェアへの備えを全体で確認したい場合は、「中小企業のランサムウェア対策」も参考になります。

SCS★3で求められるバックアップ対応

SCS評価制度の正式な要求事項・評価基準では、バックアップに関する★3の基準が具体的に示されています。

対象・頻度・保管期間を決める

評価基準4-3-4-1では、自社で取り扱うデータについて、次の内容を定めてバックアップを取得します。

  • 何をバックアップするか
  • どの頻度で取得するか
  • どの期間保管するか

例えば「毎日バックアップしている」だけでは、対象と保持期間が分かりません。業務やシステムごとに整理すると、漏れを見つけやすくなります。

重要な機密情報は遠隔地にも保管する

評価基準4-3-4-2では、重要な機密情報について、通常のバックアップに加えて遠隔地バックアップを実施することが★3に含まれています。

遠隔地バックアップは、同じ建物の火災や災害、本番環境と同時に受けるサイバー攻撃などを考慮し、別の場所にもデータを残す考え方です。クラウドを利用する方法も考えられますが、保存先が別であるだけでなく、アクセス権、削除権限、保持期間なども確認する必要があります。

バックアップ対象ごとにリストア手順書を作る

評価基準4-3-4-3では、バックアップ対象ごとのリストア手順書を整備します。

すべてのシステムに同じ復元方法を使えるわけではありません。手順書には、例えば次の内容を記載します。

  • 対象となるシステムとデータ
  • 使用するバックアップと保存場所
  • 復元を判断・承認する人
  • 復元作業を行う人や会社
  • 復元先と作業手順
  • 復元後に確認する内容
  • 問い合わせ先と緊急連絡先

事業上重要なシステムの目標復旧レベルを決める

★3の評価基準7-1-1-1では、事業継続上重要なシステムについて、業務の目標復旧レベルを定め、そこまで回復するための準備を行います。

すべてを一度に完全復旧するのではなく、例えば「受注状況を確認できる」「出荷指示を出せる」「請求データを参照できる」といった、事業を続けるための最低限の状態を考えます。システムが戻るまでの間、人手や電話などで代替できる業務も整理しておくと、対応の選択肢が増えます。

バックアップはSCS★3の一項目であり、認証、資産管理、インシデント対応などとあわせて準備します。制度全体で自社の不足を確認したい場合は、「SCS評価制度の全体像と準備項目」で整理しています。

★3・★4の正式な区分は、IPA「SCS評価制度 要求事項・評価基準」で確認できます。

復元テストはSCS★4でどこまで求められるか

復元テストについては、★3と★4を分けて理解しておく必要があります。

★3と★4の違い

確認内容★3★4
対象・頻度・保管期間を定めて取得する対象対象
重要な機密情報を遠隔地にもバックアップする対象対象
対象ごとのリストア手順書を整備する対象対象
事業上重要なシステムの目標復旧レベルと準備を整える対象対象
手順書どおり、目標復旧時間内に復元できることを確認する★3の明文基準ではない対象

★3では、バックアップの取り方と戻し方を決めるところまでが明記されています。★4では、決めた手順で目標時間内に戻せることの確認まで進みます。

ただし、★3を目指す企業でも、実際の被害に備えるなら復元テストには意味があります。制度上の最低条件を満たすことと、事業を守るためにどこまで確かめるかは、分けて判断するとよいでしょう。

復元テストで確認する項目

復元テストでは、ファイルが開けるかだけでなく、次の点を確認します。

  • 必要なバックアップを選べるか
  • 手順書だけで担当者が作業できるか
  • 復元したデータが破損していないか
  • アプリケーションから利用できるか
  • 権限やアカウントが正しく戻るか
  • 復元にどのくらい時間がかかるか
  • 復元後に業務部門が利用確認できるか

本番環境を止めず、テスト用の場所へ一部データを戻す方法もあります。どの範囲で安全に試せるかは、システム会社へ相談できます。

テスト頻度は自社の変更・重要度に合わせる

SCSの★3基準には、すべての企業に共通する復元テストの頻度は示されていません。年1回などの数字を一律に当てはめるより、システムの重要度と変更状況を踏まえて決めます。

少なくとも、次のような変更があったときは、手順や復元可否を見直す機会になります。

  • システムやバックアップ製品を変更した
  • 保存先や契約プランを変更した
  • サーバーやネットワーク構成を変更した
  • 担当者や保守会社が変わった
  • 重要な機能やデータを追加した
  • 復元に失敗した、または手順どおり進まなかった

バックアップの実効性を確認する手順

自社のバックアップを見直すときは、製品や保存方式から入るより、止まると困る業務から考えると整理しやすくなります。

1.止まると困る業務から対象を選ぶ

受注、出荷、請求、顧客対応、製造など、停止した場合の影響が大きい業務を選びます。その業務に必要なシステム、データ、設定、外部サービスをたどると、優先すべきバックアップ対象が見えてきます。

2.必要な復旧時点と復旧時間を決める

どの時点のデータまで戻せればよいか、どのくらいの時間で業務を再開したいかを考えます。

1日分の受注データを失っても再入力できる会社と、数分間のデータ消失でも大きな影響が出る会社では、必要な取得頻度が異なります。IT担当者だけで決めず、業務側が許容できる範囲を伝えることが大切です。

3.保管場所・世代・アクセス権を確認する

対象ごとに、どこへ、何世代、何日分を保存しているか確認します。重要な機密情報については、遠隔地バックアップの有無も見ます。

あわせて、バックアップを削除・変更できるアカウント、通常時の接続状態、本番環境と認証情報を共有していないかも確認すると、ランサムウェアへの耐性を判断しやすくなります。

複数の媒体へコピーし、異なる場所にも保管する「3-2-1ルール」は代表的な考え方の一つですが、SCSの明文要件そのものではありません。自社のリスクと費用に合わせ、具体的な保存方法を選びます。

4.リストア手順を文書化する

現在の担当者が頭の中で理解しているだけでは、休暇・退職・被災などで対応できない場合があります。実際の作業者と連絡先を含め、対象ごとに手順を残します。

システム会社が復元を担当する場合も、「連絡すれば対応してくれる」で終わらせず、受付時間、必要な情報、復元開始までの時間、追加費用を確認しておくと安心です。

5.影響を抑えた範囲で復元テストを行う

いきなり本番システム全体を止める必要はありません。一部データをテスト環境へ戻す、予備機で起動する、手順を机上で確認するといった方法から始められます。

テストで問題が見つかるのは失敗ではありません。実際の事故前に、手順の不足や想定時間との差を見つけられたということです。結果を記録し、次の手順書や契約見直しへ反映します。

システム会社へ確認する内容

バックアップの方式や復元方法を、自社だけで判断する必要はありません。現在のシステム会社や保守会社へ、次のように確認すると情報を整理しやすくなります。

当社のバックアップについて、対象データ、取得頻度、保持期間、保管場所、遠隔地保管の有無、復元手順、最後に復元を確認した日、想定する復旧時間をご提示ください。未確認の項目があれば、確認方法と費用も教えてください。

回答を受け取ったら、次の点を見てみましょう。

  • 「バックアップ一式」ではなく、対象が具体的に分かるか
  • 自動処理の成功確認と、実際の復元確認が区別されているか
  • 障害時の連絡先と対応時間が分かるか
  • 復元作業が保守契約に含まれるか
  • テストを依頼する場合の停止時間と費用が分かるか

バックアップ実効性の確認表

現在の資産台帳やシステム一覧へ、次の項目を追加すると、バックアップの状態を一か所で確認できます。

業務・システム守るデータ取得頻度保持期間保管場所遠隔地リストア手順最終復元確認日想定復旧時間担当者
例:販売管理受注・出荷・請求データ毎日30日社内+別拠点ありあり未確認未確認情報システム担当

最初からすべて埋める必要はありません。「未確認」と書けた項目が、次に担当者やシステム会社へ聞く内容になります。

復旧時の連絡や初動もあわせて確認する場合は、「中小企業のインシデント対応手順」へ進むと、バックアップを使う前後の流れを整理できます。

バックアップ実効性についてよくある質問

バックアップが毎日成功していれば復元テストは不要ですか?

保存処理の成功だけでは、データの破損、手順の不足、復元時間までは分かりません。SCS★3では復元テストが明文の基準ではありませんが、実際の被害に備えるなら、一部データやテスト環境を使って復元を確認する価値があります。

クラウドサービスなら自社のバックアップは不要ですか?

サービスによって異なります。事業者が基盤を保護していても、誤削除から戻せる期間、保存世代、復元方法、契約終了時のデータ取得が自社の希望を満たすとは限りません。現在の契約内容を確認して判断します。

SCS★3でも復元テストが必要ですか?

★3で明記されているのは、対象・頻度・保管期間、重要な機密情報の遠隔地バックアップ、リストア手順書などです。手順書どおり、目標復旧時間内に復元できることの確認は★4です。ただし、★3を目指す企業が自主的に復元テストを行うことには、実務上の意味があります。

遠隔地バックアップとはクラウド保存でもよいですか?

クラウドは遠隔地保管の選択肢になります。ただし、保存先が離れているだけでなく、本番環境と同時に削除・暗号化されないか、アクセス権、保持期間、復元方法を含めて確認する必要があります。

復元テストで本番環境を止める必要がありますか?

必ずしも本番環境全体を止める必要はありません。テスト用の保存先へ一部データを復元する、予備機で確認する、机上で手順を確認するといった方法があります。システムへの影響と確認したい内容を保守会社へ伝え、方法を相談するとよいでしょう。

3-2-1ルールはSCSの必須要件ですか?

3-2-1ルールはバックアップを守る代表的な考え方ですが、SCSの明文要件としてその名称や構成が指定されているわけではありません。★3では、重要な機密情報の遠隔地バックアップが明記されています。

まとめ|「取れている」から「戻せる」へ確認を進める

バックアップ実効性を確かめる出発点は、特別な製品の導入ではありません。止まると困る業務を選び、必要なデータ、保存先、保持期間、復元手順、想定する復旧時間を確認することです。

★3では、バックアップの取り方と戻し方を決めるところまでが具体的に求められます。★4では、手順書どおり、目標復旧時間内に戻せることの確認まで進みます。

自社で分からない項目は、「未確認」としてシステム会社へ尋ねれば構いません。何が分からないかが見えれば、設定で済むのか、契約変更や復元テストが必要なのかを判断しやすくなります。

バックアップ以外の対策も含めて優先順位を見直す場合は、「セキュリティ対策は何から始めるか」を参考に、事業への影響が大きいところから整理してみてください。

コメント

タイトルとURLをコピーしました