システム構築・運用やAWS構築など企業のDXを支援する日本オープンシステムズ「お知らせ」ページ

企業を狙うサイバー攻撃が増えるなか、ウイルス対策ソフトやEDR、メールセキュリティなど、攻撃を防いだり早期に発見したりするための対策を進めている企業も多いと思います。

 

一方で、どれだけ対策を行っても、すべての攻撃を完全に防げるとは限りません。

ランサムウェアなどの攻撃によって業務データやシステムが利用できなくなった場合には、

「どのデータが影響を受けているのか」
「バックアップから安全に復旧できるのか」
「どのくらいの時間で業務を再開できるのか」

といった判断が必要になります。

 

バックアップを取得していても、バックアップデータまで暗号化されていたり、必要なデータが保存されていなかったり、復元に想定以上の時間がかかったりすることがあります。

そのため、サイバー攻撃への備えでは、侵入を防ぐ対策だけでなく、攻撃を受けた後に、安全な状態まで戻して業務を再開できるかという視点も重要です。

 

この記事では、BCP対策としてデータバックアップを見直す際に確認したいポイントと、サイバー攻撃を受けてから業務を再開するまでの考え方を紹介します。

目次

1. サイバー攻撃は「防ぐ」だけでなく「復旧」まで考える
2. サイバー攻撃を受けると何が起きるのか
3. バックアップを取っているだけでは十分ではない
4. サイバー攻撃からの復旧で整理したいポイント
5. 安全に業務を再開するまでの流れ
6. 定期的な復旧テストが重要
7. 自社のバックアップ環境を見直す進め方
8. バックアップ製品を選ぶときの視点
9. JOPSが支援できること
10. まとめ

サイバー攻撃は「防ぐ」だけでなく「復旧」まで考える

サイバー攻撃への対策というと、攻撃者の侵入を防ぐことや、不審な動きを早く検知することに目が向きがちです。

 

もちろん、ファイアウォール、ウイルス対策ソフト、EDR、メールセキュリティ、アクセス制御などによって、攻撃を防止・検知することは重要です。

しかし、新しい攻撃手法や、正規のID・パスワードを悪用する攻撃、人の操作ミスを狙った攻撃など、すべての脅威を事前に防ぐことは簡単ではありません。

万が一、攻撃を受けてしまった場合には、被害を受けた端末やシステムを切り離し、安全性を確認したうえで、データやシステムを復旧する必要があります。

 

その際に重要になるのが、バックアップです。

ただし、バックアップの目的は、単にデータのコピーを残すことではありません。

必要なデータやシステムを、安全な状態へ戻し、業務を再開できるようにすることが本来の目的です。

BCP対策としてのバックアップ

BCP（事業継続計画）は、災害や事故などの緊急事態が発生した場合でも、重要な業務を継続したり、できるだけ早く再開したりするための計画です。

 

地震や水害、停電などの自然災害だけでなく、システム障害、機器故障、操作ミス、サイバー攻撃も、業務を停止させる原因になります。

そのため、現在のBCP対策では、

• 重要な業務は何か
• 業務に必要なデータやシステムは何か
• どの程度の停止時間なら許容できるか
• どの時点のデータまで戻す必要があるか
• 誰が復旧作業を行うか

まで整理しておく必要があります。

バックアップは、こうした事業継続を支えるための対策の一つです。

サイバー攻撃を受けると何が起きるのか

ランサムウェアなどのサイバー攻撃を受けると、単に一部のファイルが使えなくなるだけではありません。

業務システムやファイルサーバー、社員のパソコン、クラウド上のデータなど、複数の環境に影響が広がる可能性があります。

業務データやシステムを利用できなくなる

業務に必要なデータが暗号化されたり、システムが停止したりすると、次のような業務を行えなくなる可能性があります。

• 受発注や請求処理
• 顧客情報や契約情報の確認
• 生産・在庫・出荷の管理
• 社内外とのメール連絡
• ファイルや図面の閲覧
• 勤怠や給与に関する処理

影響を受けた範囲によっては、一部の部署だけでなく、会社全体の業務が止まることもあります。

バックアップまで被害を受けることがある

本番データとバックアップデータが同じサーバーやネットワーク内に保存されている場合、サイバー攻撃によって両方が暗号化・削除される可能性があります。

また、バックアップ環境へアクセスできる管理者アカウントが不正利用されると、保存していた復旧用データまで消されることがあります。

 

バックアップを取得しているだけでなく、バックアップ自体を攻撃から守れる構成になっているかを確認することが重要です。

被害の範囲をすぐに判断できない

攻撃を受けた後は、単に最新のバックアップを戻せばよいとは限りません。

 

攻撃者が侵入してから発見されるまでに時間がかかっていた場合、直近のバックアップにも、不正なプログラムや設定変更が含まれている可能性があります。

安全性を確認せずに復元すると、攻撃を受けた状態まで戻してしまい、再び被害が発生するおそれがあります。

そのため、

• いつ侵入された可能性があるのか
• どのシステムが影響を受けたのか
• どの時点のバックアップなら安全なのか

を確認したうえで復旧する必要があります。

業務再開までに時間がかかる

バックアップが残っていても、データ量やネットワーク環境、復旧手順によっては、復元に長い時間がかかることがあります。

また、サーバー本体やネットワーク機器も被害を受けている場合は、復元先となる環境を準備してからデータを戻さなければなりません。

 

担当者が復旧手順を把握していない、必要なアカウント情報が分からない、外部ベンダーへの連絡方法が整理されていないといった理由で、作業が止まることもあります。

バックアップを取っているだけでは十分ではない

「毎日バックアップを取っているから大丈夫」と考えていても、実際に復旧できる状態とは限りません。

サイバー攻撃からの復旧を考える場合は、取得状況だけでなく、保存方法や復元方法まで確認する必要があります。

正常にバックアップできているか

バックアップの設定があっても、次のような理由で正常に取得できていない場合があります。

• 保存先の容量が不足している
• 通信エラーが発生している
• 対象となるサーバーや端末が停止している
• 新しく追加したシステムが対象に含まれていない
• エラー通知が担当者に届いていない
• 担当者が通知を確認できていない

管理画面上で設定が存在することと、必要なデータが正常に保存されていることは同じではありません。

取得結果やエラーの有無を、継続的に確認できる運用が必要です。

必要なデータが対象に含まれているか

企業内のデータは、社内サーバーだけに保存されているとは限りません。

現在は、次のような場所に分散していることがあります。

• ファイルサーバー
• 業務システムのデータベース
• 社員のパソコン
• 仮想サーバー
• クラウド上のサーバー
• Microsoft 365などのクラウドサービス
• 各部門が個別に契約しているサービス
• 工場や拠点に設置されたシステム

一部のサーバーだけをバックアップしていても、業務再開に必要なデータがほかの環境に残っていれば、十分に復旧できません。

まずは、どの業務で、どのデータとシステムを利用しているのかを整理する必要があります。

攻撃前の状態まで戻せるか

バックアップを一世代だけ保存している場合、そのバックアップに問題が含まれていると、安全な状態へ戻せないことがあります。

攻撃が発生した時期を正確に特定できないケースもあるため、複数の時点のバックアップを一定期間保存しておくことが重要です。

 

たとえば、

• 前日
• 数日前
• 1週間前
• 1か月前

など、複数の復旧ポイントを持っていれば、影響を受ける前の状態を選びやすくなります。

ただし、保存する世代数を増やすほど必要な容量やコストも増えます。業務の重要度や、攻撃に気づくまでの期間を踏まえて考える必要があります。

バックアップが本番環境から分離されているか

バックアップデータが本番環境から常にアクセスできる状態にあると、攻撃の影響が及ぶ可能性があります。

対策としては、

• 別のサーバーやストレージへ保存する
• 別拠点へ保存する
• クラウドへ保存する
• 通常時は本番環境から切り離す
• 一定期間、変更や削除ができない状態で保存する

といった方法があります。

どれか一つを選べばよいわけではなく、重要なデータについては複数の方法を組み合わせることが有効です。

実際に復元できるか

バックアップ処理が「成功」と表示されていても、実際にデータやシステムを元に戻せるとは限りません。

データが破損していたり、復旧に必要な設定やアプリケーションが不足していたりする可能性があります。

 

そのため、定期的に復元を試し、

• データを開けるか
• システムが正常に起動するか
• 利用者がログインできるか
• 関連システムと接続できるか
• 想定した時間内に復旧できるか

まで確認する必要があります。

サイバー攻撃からの復旧で整理したいポイント

バックアップ環境を見直す際は、製品の機能を先に比較するのではなく、自社がどのような状態まで、どのくらいの時間で戻る必要があるのかを整理します。

 

これらは、それぞれ「RPO（目標復旧時点）」「RTO（目標復旧時間）」と呼ばれる考え方です。あわせて、何を復旧するのか、バックアップをどこに・何世代保存するのか、誰が復旧を担当するのかも確認します。

何を復旧する必要があるか

まずは、業務を再開するために必要なデータやシステムを洗い出します。

たとえば、次のようなものです。

• 業務システム
• データベース
• ファイルサーバー
• メール
• クラウドストレージ
• サーバーや端末の設定
• アプリケーション
• ネットワーク設定
• 利用者や権限に関する情報
• 復旧に必要な手順書

すべてのデータを同じ条件で保護する必要はありません。

停止した場合の影響が大きい業務から、優先順位をつけることが大切です。

どの時点まで戻す必要があるか

復旧時には、どの時点のデータまで戻せればよいかを決めます。

この考え方は、一般的に「RPO（目標復旧時点）」と呼ばれます。

たとえば、1日分のデータを失っても業務上対応できる場合は、1日ごとのバックアップでも対応できるかもしれません。

 

一方で、注文や決済などの情報が頻繁に更新されるシステムでは、数時間、あるいはそれより短い間隔でデータを保存する必要があります。

バックアップの頻度は、単に多ければよいのではなく、どの程度のデータ損失まで許容できるかから考えます。

どのくらいの時間で業務を再開する必要があるか

復旧までに許容できる時間は、一般的に「RTO（目標復旧時間）」と呼ばれます。

たとえば、

• 数時間以内に再開する必要がある業務
• 翌営業日までに戻ればよい業務
• 数日停止しても代替手段で対応できる業務

では、必要な仕組みが異なります。

短時間で復旧するためには、復元処理の速さだけでなく、復旧先のサーバーやネットワーク、担当者の体制なども整えておく必要があります。

どこに保存するか

バックアップ先を考える際は、本番環境と同時に被害を受けないことが重要です。

 

保存先の候補には、

• 社内の別ストレージ
• 別拠点のデータセンター
• クラウドストレージ
• オフラインで保管する媒体

などがあります。

複数の場所や異なる方式で保存することで、一つの環境が被害を受けても、別のバックアップから復旧できる可能性が高まります。

何世代、どのくらいの期間保存するか

攻撃を受けてから発見するまでに時間がかかる場合、直近のバックアップだけでは安全な復旧ポイントを確保できないことがあります。

そのため、複数世代を一定期間保存することが重要です。

 

保存期間を考える際は、

• 攻撃や異常に気づくまでの想定期間
• 法令や社内規定による保存期間
• データの更新頻度
• 保存容量とコスト
• 復旧時に選択できる範囲

を確認します。

誰が復旧するのか

サイバー攻撃が発生した際は、通常のシステム障害とは異なる判断が必要になることがあります。

事前に、次の点を決めておくことが重要です。

• 誰が攻撃の可能性を判断するか
• 誰がシステム停止や隔離を指示するか
• 誰が復旧開始を判断するか
• 誰がバックアップを操作するか
• 外部の専門家やベンダーへ誰が連絡するか
• 経営層や利用部門へ誰が報告するか
• 担当者が不在の場合に誰が代わるか

製品を導入するだけでなく、役割と連絡体制まで決めておくことで、緊急時の混乱を減らせます。

安全に業務を再開するまでの流れ

サイバー攻撃を受けた場合、バックアップからデータを戻す前に、影響範囲や安全性を確認する必要があります。

一般的には、次のような流れで対応します。

1. 攻撃を検知し、影響範囲を確認する

まず、不審な端末、サーバー、アカウント、通信などを確認します。

どの環境が影響を受けているか分からない状態で復旧を始めると、復元したシステムが再び攻撃を受ける可能性があります。

2. 感染した環境を隔離する

被害の拡大を防ぐため、影響を受けた端末やサーバーをネットワークから切り離します。

状況によっては、特定のアカウントを停止したり、外部との通信を遮断したりする対応も必要です。

3. 復旧に使えるバックアップを確認する

複数の復旧ポイントから、攻撃の影響を受けていない可能性が高いものを選びます。

取得日時だけでなく、バックアップデータに不審なファイルや設定が含まれていないかを確認することも重要です。

4. 安全な環境へ復元する

影響を受けた環境へそのまま戻すのではなく、必要に応じて初期化した端末や、新たに準備したサーバーなど、安全性を確認した環境へ復元します。

5. システムやアカウントの安全性を確認する

データを戻した後は、

• 不審なプログラムが残っていないか
• 修正すべき脆弱性がないか
• 不正なアカウントや権限が追加されていないか
• パスワードや認証情報を変更したか
• 外部との不審な通信が発生していないか

を確認します。

6. 優先度の高い業務から段階的に再開する

すべての業務を一斉に再開するのではなく、影響が大きい業務から優先的に戻します。

段階的に再開することで、問題が残っていた場合の影響を抑えやすくなります。

7. 原因調査と再発防止を行う

業務再開後は、侵入経路や被害範囲を調査し、必要な対策を行います。

バックアップから復旧できても、原因が残ったままでは同じ被害が再発する可能性があります。

バックアップは復旧を支える重要な仕組みですが、攻撃の検知、隔離、安全確認、再発防止などと組み合わせて考える必要があります。

定期的な復旧テストが重要

実際に攻撃が発生してから初めて復旧を試すと、想定していなかった問題が見つかることがあります。

そのため、平常時から復旧テストを行うことが重要です。

バックアップの成功と復旧の成功は異なる

バックアップの管理画面で「正常終了」と表示されていても、業務を再開できる状態まで戻せるとは限りません。

復旧テストでは、単にファイルを取り出すだけでなく、システムが正常に動作するところまで確認します。

想定した時間内に復旧できるか確認する

実際に復元にかかった時間を測定することで、設定したRTOを満たせるか確認できます。

想定より時間がかかる場合は、

• バックアップ方式
• 保存先
• ネットワーク回線
• 復旧先の環境
• 作業手順
• 担当体制

などを見直します。

手順や連絡体制も確認する

復旧テストは、システムだけでなく人や体制を確認する機会でもあります。

担当者が手順を理解しているか、必要なアカウントへログインできるか、ベンダーへの連絡先が最新かなども確認します。

テスト結果を手順へ反映する

テストで判明した課題は、復旧手順書やBCPへ反映します。

システム構成や担当者は変化するため、一度作成した手順をそのままにせず、定期的に見直すことが大切です。

自社のバックアップ環境を見直す進め方

バックアップ環境を見直す際に、すべてのシステムを一度に変更する必要はありません。

まずは現状を整理し、事業への影響が大きいところから段階的に進めます。

重要な業務とデータを整理する

最初に、自社の主要な業務を洗い出します。

それぞれについて、

• どのシステムを利用しているか
• どのデータが必要か
• 停止するとどのような影響があるか
• 代替手段があるか
• どのくらいで再開する必要があるか

を整理します。

現在のバックアップ状況を一覧にする

次に、システムごとのバックアップ状況を確認します。

確認項目	確認する内容
対象	どのデータやシステムを保存しているか
頻度	どのくらいの間隔で取得しているか
保存先	どこに保存しているか
保存期間	何世代、何日分を残しているか
管理者	誰が設定や結果を確認しているか
復旧方法	どの手順でデータやシステムを戻すか
復旧時間	どのくらいで業務を再開できるか
テスト	最後に復旧を確認したのはいつか

一覧にすることで、保存対象の漏れや、特定の場所へ集中しているバックアップを見つけやすくなります。

サイバー攻撃時の弱点を確認する

現在の環境について、次の点を確認します。

• 本番環境とバックアップが同時に被害を受けないか
• 管理者アカウントが不正利用された場合に削除されないか
• 複数の復旧ポイントを持っているか
• クラウド上のデータも対象になっているか
• 攻撃前の安全な状態を判断できるか
• 実際に復元したことがあるか
• 担当者が不在でも対応できるか

優先度の高い環境から改善する

すべての環境へ高度な対策を行うと、費用や運用負担が大きくなることがあります。

まずは、

• 停止すると事業への影響が大きい
• 現在バックアップされていない
• 本番環境と同時に被害を受ける可能性が高い
• 復旧手順が分からない
• 長期間テストをしていない

といった環境から優先して改善します。

既存のバックアップをすべて置き換えるのではなく、重要なデータだけ保存先を追加する、一部のシステムからクラウドバックアップを始めるなど、段階的に見直す方法もあります。

バックアップ製品を選ぶときの視点

サイバー攻撃からの復旧を考える場合、バックアップ製品は、単にデータを保存できるかだけで選ぶものではありません。

 

必要なシステムやクラウド環境を保護できるか、バックアップ自体を攻撃から守れるか、複数の時点から復旧できるか、想定した時間内に業務を再開できるかを確認する必要があります。

また、取得結果やエラーを継続的に確認し、自社で無理なく運用できることも重要です。

 

こうした要件を踏まえてバックアップ環境を見直す際、候補となる製品の一つが「Acronis」です。

Acronisは、サーバーやパソコン、仮想環境、クラウド上のデータなどを対象に、バックアップの取得から復旧までを支援する製品です。単にデータを保存するだけでなく、サイバー攻撃や障害が発生した際に、必要なデータやシステムをできるだけ早く安全な状態へ戻すための仕組みづくりに活用できます。

また、複数の環境をまとめて管理しやすいため、バックアップ対象が分散している企業や、運用負担を抑えながら復旧体制を整えたい企業にも適しています。

 

Acronisでどのような環境を保護できるのか、サイバー攻撃からの復旧にどのように役立つのかについては、製品紹介記事で詳しく紹介します。

 

製品紹介：サイバー攻撃や障害からのデータ復旧を支援する「Acronis」

JOPSが支援できること

バックアップ環境を見直す際は、製品の選定だけでなく、現在の環境や業務の優先順位、復旧後の運用まで含めて考える必要があります。

 

当社では、お客様の既存環境や課題を踏まえながら、

• 重要な業務やデータの整理
• 現在のバックアップ対象・頻度・保存先の確認
• サイバー攻撃時に想定されるリスクの整理
• RPO・RTOの検討
• オンプレミスやクラウドを含むバックアップ環境の設計
• Acronisをはじめとする製品の選定・導入
• 既存のバックアップ環境を活かした段階的な見直し
• 復旧手順や社内体制の整備
• 復旧テスト
• 導入後の運用支援

など、お客様の状況に応じたご提案が可能です。

すべてのシステムを一度に見直すのではなく、事業への影響が大きいシステムや、現在十分に保護できていないデータから段階的に対策を進めることもできます。

まとめ

サイバー攻撃への備えでは、侵入を防ぐ対策だけでなく、攻撃を受けた後に業務を再開できる準備も重要です。

 

バックアップを取得していても、

• 必要なデータが保存されていない
• バックアップまで攻撃の影響を受ける
• 安全な復旧ポイントを選べない
• 復元に想定以上の時間がかかる
• 復旧手順や担当者が決まっていない

といった状態では、十分なBCP対策とはいえません。

 

まずは、

• 何を復旧する必要があるか
• どの時点まで戻す必要があるか
• どのくらいの時間で業務を再開するか
• どこへ、何世代保存するか
• 誰が復旧作業を行うか
• 実際に復旧できることを確認しているか

を整理することが重要です。

そのうえで、自社の業務やシステム環境に合わせて、バックアップの対象、保存先、取得頻度、保存期間、復旧方法を見直します。

 

BCP対策として大切なのは、「バックアップがあるか」ではなく、「サイバー攻撃を受けたときに、安全な状態へ必要な時間内に戻し、業務を再開できるか」を確認することです。

 

関連リンク

サイバー攻撃からの復旧に備えるには、バックアップ製品を導入するだけでなく、現在のシステム環境や重要なデータ、復旧の優先順位、導入後の運用体制まで整理することが重要です。

自社のバックアップ環境やセキュリティ対策を見直したい方は、以下のページもあわせてご覧ください。

製品紹介

• サイバー攻撃や障害からのデータ復旧を支援する「Acronis」
  サーバーやパソコン、仮想環境、クラウド上のデータなどを保護するAcronisについて、主な機能や特徴、サイバー攻撃や障害発生時の復旧にどのように活用できるかを紹介しています。
• 自己学習型AIでセキュリティ監視を支援する「Darktrace」
  ネットワーク、メール、ID・アカウント、クラウドなどの普段の利用状況をAIが学習し、「いつもと違う動き」を検知するDarktraceの特徴や仕組みを紹介しています。

ソリューション

• サイバーセキュリティサービス「JCSS（JOPS Cyber Security Service）」
  セキュリティ診断や各種テスト、標的型攻撃メール訓練、セキュリティ対策コンサルティングなどを通じて、企業のセキュリティ課題を幅広く支援します。

関連記事

サイバー攻撃への備えでは、被害を防ぐ対策と、被害を受けた後に業務を復旧するための対策をあわせて考えることが重要です。

自社のセキュリティ対策や導入の進め方を検討する際は、以下の記事もご覧ください。

• セキュリティ監視のEDR・NDR・XDRとは？それぞれの監視対象と役割を整理
  端末、ネットワーク、メール、クラウドなどの異常をどのように監視するのか、EDR・NDR・XDRの違いと、自社に必要な監視範囲を考えるポイントを紹介しています。
• ITの相談先を選ぶときに確認したい4つのポイント
  バックアップ環境やセキュリティ対策を外部へ相談する際に、技術力だけでなく、課題整理や導入後の支援まで含めて確認したいポイントを紹介しています。
• DXやAI活用の前に、なぜフィジビリティスタディやPoCが重要なのか
  新しい製品や仕組みを本格導入する前に、既存環境との相性や運用方法、期待する効果を小さく検証する考え方を紹介しています。