バックアップの目的は、保存容量を確保し、毎晩のジョブを成功させることではありません。 サイバー攻撃や障害で通常の環境を信頼できなくなったときに、重要な業務を許容できる時間と状態で再開することです。 しかし実務では、「バックアップは取っている」という回答だけで、復元できるデータ、必要な権限、復旧順序、判断責任が確認されないままになりがちです。

IPAは2026年3月、「中小企業の情報セキュリティ対策ガイドライン」を第4.0版へ改訂し、 最初に取り組む対策を従来の5か条から「バックアップを取ろう！」を加えた6か条へ拡充しました。 背景として、ランサムウェアの影響が情報漏えいにとどまらず、事業活動の停止まで広がっていることを挙げています。

同年6月に最終版となったNIST IR 8374 Rev.1は、ランサムウェア対策をCSF 2.0の GOVERN、IDENTIFY、PROTECT、DETECT、RESPOND、RECOVERの六つの機能で整理しています。 その基本的な実践には、重要サービスの復旧優先順位、隔離されたバックアップ、復元テスト、対応・復旧計画の演習が含まれます。 本記事では、バックアップを「保管」から「実証された復旧能力」へ変える5つの手順を整理します。

具体的な課題：バックアップの成功と事業復旧の成功が分かれている

バックアップ製品の管理画面が緑色でも、業務が再開できるとは限りません。 ランサムウェアは本番データだけでなく、接続されたバックアップ、管理アカウント、仮想基盤、クラウド管理面を狙うことがあります。 復元先が汚染されたままなら、復旧作業そのものが再侵入や再暗号化の経路にもなります。

  • 保存対象が業務単位で分からない：データベースはあるが、設定、暗号鍵、証明書、ソース、ライセンス、手順が欠けている。
  • 本番と同じ管理境界にある：同じ認証基盤、管理者権限、ネットワークからバックアップを変更・削除できる。
  • 復旧順序が決まっていない：顧客向け機能、認証、ネットワーク、監視、外部連携の依存関係を把握していない。
  • 復元テストが技術確認で終わる：ファイルは開けても、件数、取引整合性、業務処理、利用者受入れを確かめていない。
  • 担当者と連絡手段が本番依存：通常のメールやチャットが止まると、判断、連絡、承認が進まない。
バックアップは「あるか」ではなく、「攻撃から守られ、必要な順序で戻せ、業務として受け入れられるか」で評価します。

考え方：復旧力を「守る・戻す・確かめる」の三層で設計する

第一層は守るです。重要なバックアップを本番の障害や侵害から分離し、変更・削除できる権限を絞り、 保持期間と暗号化、監視を決めます。単に別フォルダーへコピーするのではなく、本番環境が侵害された場合にも残る管理境界をつくります。

第二層は戻すです。信頼できる復旧環境、復旧に必要な構成、依存関係、手順、責任者を準備します。 NIST IR 8374 Rev.1は、重要サービスを特定した対応・復旧計画、通常の通信が使えない場合の代替連絡、 安全に隔離した重要データのバックアップと復元テストを基本的な実践に挙げています。

第三層は確かめるです。技術担当者が「復元処理は完了した」と確認するだけでなく、 データの完全性、業務ルール、外部連携、利用者の操作、復旧後の監視まで業務責任者と検証します。 三層のどれかが欠けると、バックアップは保険ではなく未検証の期待になります。

実践手順1：重要業務から復旧目標を決める

最初に、システム一覧ではなく「止まると顧客、売上、安全、法令・契約、社会的責任に影響する業務」を選びます。 業務ごとに、いつまでに再開したいか、どの時点までのデータが必要か、最低限どの機能で暫定運用できるかを決めます。 復旧時間目標や復旧時点目標は、技術部門だけで置かず、事業影響と実現コストを見ながら経営・業務・ITで合意します。

すべてを同時に最高水準で戻そうとすると、費用も手順も複雑になります。 受注、決済、出荷、顧客連絡などの重要な業務フローに沿って、最初に戻すサービス、暫定手段、後から戻す機能を層別化します。

実践手順2：復旧単位と依存関係を一枚にする

重要業務ごとに、アプリケーション、データ、ID・権限、ネットワーク、端末、クラウド設定、監視、外部サービス、 暗号鍵・証明書、手順書、担当者を結びます。データだけを戻しても、認証や名前解決、接続先、設定がなければ業務は動きません。

「何を」「どの世代から」「どこへ」「誰が」「何を確認して」戻すかを復旧単位ごとに書きます。 SaaSや委託サービスは、提供者がどこまで復旧するか、自社がエクスポート・保持すべきデータは何か、復旧時の連絡窓口と証跡を契約・運用の両面で確認します。

実践手順3：バックアップを本番の侵害から分離する

重要データは、複数の故障・侵害シナリオで同時に失われないよう配置します。 オフライン、イミュータブル、別アカウント・別テナントなどの手段を組み合わせ、 本番管理者が侵害されても全世代を削除できない権限設計にします。バックアップ管理操作にも強い認証、最小権限、監査ログ、異常検知を適用します。

CISAの#StopRansomware Guideも、重要データのオフラインかつ暗号化されたバックアップと、 災害復旧シナリオでの可用性・完全性の定期確認を推奨しています。 ただし、分離方法はデータ量、復旧時間、クラウド・オンプレミス構成、運用体制によって異なります。 製品機能だけでなく、権限と運用を含めて設計します。

実践手順4：クリーンな環境で復元し、業務として受け入れる

復元テストは本番へ直接戻すのではなく、隔離した検証環境で行います。 復元元の世代を選び、マルウェアや不正変更の兆候を確認し、信頼できるOS・設定・ツールから復旧します。 攻撃の侵入経路や残存影響を把握しないまま急いで本番へ戻すと、再侵入や証拠の損失につながるおそれがあります。

技術検証では、復元時間、エラー、ファイル・データベースの整合性、鍵と証明書、外部連携、監視を確認します。 業務検証では、取引件数、残高や在庫、承認状態、顧客表示、帳票、暫定運用からのデータ統合を確認します。 合否条件と承認者を事前に決め、結果を証跡として残します。

実践手順5：演習と変更管理で復旧能力を更新する

四半期・半期など自社に適した周期で、技術復元テストと業務を含む机上・実動演習を組み合わせます。 通常のメールやID基盤が使えない想定、担当者不在、委託先との連絡、復旧順序の競合、最新バックアップの破損など、 現実的な条件を一つずつ加えます。演習は失敗を避ける場ではなく、実際の事故より安全に弱点を見つける場です。

復元に要した時間、目標時点との差、成功した世代、手順の曖昧さ、必要な権限取得時間、業務受入れ結果を記録します。 システム、データ構造、ID、クラウド設定、委託先、組織体制が変わったら、変更管理の完了条件にバックアップと復旧手順の更新を含めます。 NIST SP 1339もOT環境について、バックアップを変更管理へ組み込み、定期作成、テスト、復旧演習での見直しを示しています。

注意点：バックアップだけでランサムウェア対策は完結しない

  • 情報流出は巻き戻せない：バックアップは暗号化されたデータの復旧には役立つが、既に持ち出された情報を回収するものではない。
  • 原因を残したまま戻さない：侵入経路、認証情報、脆弱性、不正設定、永続化の有無を調べ、封じ込めと復旧を連携する。
  • バックアップ管理者を過大権限にしない：本番・バックアップ・鍵・監査ログを一人の同じ権限で操作できる状態を避ける。
  • 復旧時間を製品性能だけで約束しない：調査、判断、回線、データ量、依存サービス、業務検証を含む実測で確認する。
  • OTや医療・安全関連設備をITと同じ手順で戻さない：安全性、設備停止、ベンダー条件、現場確認を優先し、専門責任者と計画する。
  • 法令・契約上の判断を一般資料だけで決めない：通知、保存、証拠保全、個人情報、業界固有要件は関係部門と必要に応じた専門家へ確認する。

まとめ

バックアップを事業復旧へ変えるには、重要業務から目標を決め、データと構成・ID・外部連携の依存関係を整理し、 本番の侵害から分離して守る必要があります。そのうえで、クリーンな環境への復元と業務受入れを実測し、 演習と変更管理で更新し続けます。

最初の一歩は、最重要の業務を一つ選び、最新のバックアップから隔離環境へ実際に戻すことです。 復元時間、欠けた構成、必要だった権限、業務確認の結果を一枚に記録すると、「取得済み」と「復旧可能」の差が見えます。 その差を小さくする継続的な運用が、ランサムウェアだけでなく障害や誤操作にも耐える復旧力になります。

参考にした公式資料

本記事は公開されている公式資料をもとに、一般的なセキュリティと事業復旧の考え方を整理したものです。 個別組織の規制適合性、事故対応、証拠保全、契約、個人情報保護その他の法律上・専門上の助言を行うものではありません。 公式資料は2026年8月13日時点で確認しています。実際のバックアップ方式、復旧目標、連絡・通知、演習範囲は、 自社の業務影響、システム構成、契約、規制、安全要件、リスク許容度を踏まえて判断してください。

FW

WRITTEN BYFourthWall Consulting Teamテクノロジーと経営の両面から、企業変革を支援しています。

← 技術ブログ一覧へ戻る