SCS評価制度のバックアップ・事業継続計画（BCP）要件：3-2-1ルールとランサムウェア対応

1. SCS評価制度がバックアップ・BCPを要件とする理由

SCS評価制度（経済産業省主導・IPA運用、2026年度末ごろ開始予定）においてバックアップと事業継続計画（BCP）が重要要件として位置づけられているのは、ランサムウェア攻撃をはじめとするサイバーインシデントが「事業継続」を直接脅かすリスクに発展するためです。

2024年以降も国内でランサムウェア被害が相次いでいます。製造業・医療機関・地方自治体等での被害事例では、復旧に数週間〜数ヶ月を要するケースが報告されており、その多くで「バックアップが存在したが復旧できなかった」「バックアップも暗号化されていた」という状況が確認されています。

サプライチェーンの観点では、取引先企業がランサムウェアによる事業停止状態に陥ることで、製品供給・サービス提供が停止し、取引元の企業にも深刻な影響が波及します。SCS評価制度は、サプライチェーン全体の事業継続性を確保するため、バックアップとBCPを評価要件に組み込んでいます。

バックアップ・BCP関連の主要概念

RTO（Recovery Time Objective）：システム復旧目標時間。インシデント発生からどのくらいの時間でシステムを復旧させるかの目標値。
RPO（Recovery Point Objective）：データ復旧目標時点。どの時点のデータまで復旧させるかの目標値（バックアップの頻度と直結）。
BCP（Business Continuity Plan）：事業継続計画。インシデント発生時に事業を継続・早期復旧させるための計画。
BCM（Business Continuity Management）：事業継続マネジメント。BCPの策定・維持・改善を継続的に管理する仕組み。
ISO 22301：事業継続マネジメントシステムの国際規格。BCM体制の国際的な基準。
WORM（Write Once Read Many）：一度書き込んだデータを変更・削除できない記録方式。イミュータブルバックアップの技術基盤。

2. ★3必須：定期バックアップとリストアテスト

SCS評価制度★3では、定期的なバックアップの実施と、バックアップからの復旧（リストア）テストが基本要件として含まれます。

★3のバックアップ要件（概要）

定期バックアップの実施：重要データ・業務システムのバックアップを定期的（日次または週次以上）に実施すること。バックアップスケジュールを文書化し、実施記録を保管すること。
バックアップの保管：バックアップデータを本番データと同一の場所（同一ストレージ）のみに保管しないこと。少なくとも1つのコピーを物理的に分離した場所または別のサービスに保管することが求められます。
バックアップ失敗アラート：バックアップの失敗・異常を検知し、担当者に通知する仕組みを整備すること。
リストアテストの実施：バックアップからの復旧が実際に可能であることを確認するリストアテストを定期的に実施すること。★3では年1回以上のリストアテストが目安です。
リストアテスト記録の保管：リストアテストの実施日・対象データ・結果（成功/失敗・復旧時間）を記録として保管すること。

「バックアップがある」だけでは不十分です。「バックアップから実際に復旧できること」を定期的に確認していることが評価の対象となります。テストなしのバックアップは、インシデント発生時に「バックアップが取れていると思っていたが実際には使えなかった」という最悪のシナリオにつながります。

3. ★4必須：オフラインバックアップ・オフサイト保管

★4では★3の要件に加え、ランサムウェア攻撃に対して特に有効なオフラインバックアップまたはイミュータブルクラウドストレージへの保管が求められます。

★4のバックアップ追加要件（概要）

オフラインバックアップまたはイミュータブルクラウドストレージ：ランサムウェア攻撃時のバックアップ暗号化・削除リスクに対応するため、本番ネットワークから切り離したオフラインバックアップ（エアギャップバックアップ）または変更・削除が不可能なイミュータブルクラウドストレージへの保管が必要。
オフサイト保管の確実な実施：本番データとは物理的に異なる場所（別のデータセンター・遠隔地・クラウドの別リージョン）にバックアップを保管すること。
バックアップ保護のアクセス制御：バックアップデータへのアクセスは最小権限の原則に基づき制限すること。バックアップシステムへのログインにはMFAを適用することが推奨されます。
定期的なリストアテスト：★4では四半期ごと以上のリストアテストが推奨されます。
復旧時間・復旧目標（RTO/RPO）の設定と検証：重要業務システムごとのRTO・RPOを設定し、リストアテストによって目標達成可能かを検証すること。

ランサムウェアのバックアップ攻撃への警戒

近年のランサムウェア攻撃では、感染後72時間以内にバックアップを暗号化・削除しようとするケースが増加しています。攻撃者はバックアップシステムの管理コンソール・バックアップエージェントを標的にし、バックアップデータを破壊することで「身代金を払わなければ復旧できない状況」を意図的に作り出します。

対策のポイントは「バックアップを本番ネットワークから切り離す（オフライン/エアギャップ）」または「バックアップデータを変更・削除不可能な状態にする（イミュータブル）」ことです。

4. 3-2-1バックアップルールの実践

3-2-1バックアップルールは、バックアップ戦略の業界標準として広く知られているベストプラクティスです。

3-2-1ルールの定義

3（3つのコピー）：オリジナルデータ＋バックアップコピー2つの計3つのコピーを持つ。1つのバックアップが失敗・破損しても、別のバックアップから復旧できる状態を確保する。
2（2種類のメディア）：バックアップコピーを異なる種類のメディア・ストレージに保管する。例：内部ディスク＋クラウドストレージ、ディスク＋テープなど。同一メディアへの保管は、メディア障害で全て失うリスクがある。
1（1つはオフサイト）：少なくとも1つのバックアップコピーを物理的に異なる場所（別のオフィス・遠隔地のデータセンター・クラウド）に保管する。火災・水害・地震等の物理的な災害時にも復旧できる状態を確保する。

3-2-1ルールの実践例

コピー	保管場所	メディア/方式	目的
コピー1（本番）	本番サーバー/端末	内蔵HDD/SSD	日常業務での利用
コピー2（ローカルバックアップ）	同一オフィス内のNAS・外付けHDD	NAS/外付けHDD	迅速なリストア（オフィス内での即時復旧）
コピー3（オフサイトバックアップ）	クラウドストレージ（別リージョン）または遠隔地	クラウドストレージ	災害時・大規模インシデント時の復旧

5. ランサムウェア対策の3-2-1-1-0ルール

ランサムウェア攻撃によるバックアップ削除リスクへの対応策として、3-2-1ルールを強化した3-2-1-1-0ルールが業界標準として普及しつつあります。

3-2-1-1-0ルールとは

3-2-1ルールの3コピー・2メディア・1オフサイトに加えて、2つの要素を追加したルールです。

追加の「1」：1つはオフライン（エアギャップ）保管：バックアップの少なくとも1つを、本番ネットワークから完全に切り離した状態（エアギャップ）で保管する。ネットワーク経由ではアクセス・変更・削除ができない状態にすることで、ランサムウェアがバックアップを破壊できなくなる。物理的な媒体（テープ・外付けHDD）を取り外して保管するか、ネットワーク接続のない専用環境に保管する。
「0」：0エラー（定期的なリストアテストで確認）：バックアップのエラーをゼロに保つこと。定期的なリストアテストを実施し、バックアップから実際に復旧できることを確認すること。「バックアップがある」だけでは不十分で、「使えるバックアップがある」ことを継続的に検証することが重要。

3-2-1ルールと3-2-1-1-0ルールの比較

要素	3-2-1ルール	3-2-1-1-0ルール（ランサムウェア対策強化版）
コピー数	3つ	3つ
メディア種類	2種類	2種類
オフサイト保管	1つ	1つ
オフライン/エアギャップ保管	なし	1つ（追加要素）
リストアテスト	推奨	必須（0エラーの確認）
SCS対応	★3の基本要件をカバー	★4のランサムウェア対策要件を満たす

6. イミュータブルバックアップ（WORM）の実装

イミュータブルバックアップとは、保存後の一定期間、変更・削除が不可能なバックアップのことです。WORM（Write Once Read Many）技術を使用して実装されます。ランサムウェアが管理者権限を取得してもバックアップを削除・暗号化できないため、復旧の砦として機能します。

イミュータブルバックアップの仕組み

イミュータブルバックアップでは、データを書き込んだ後の一定期間（保持期間）中は、管理者を含む全てのユーザーからのデータ変更・削除要求を拒否します。保持期間を経過した後にのみ、正規の手順で削除・変更が可能になります。この仕組みにより、ランサムウェアによる暗号化・削除攻撃から保護されます。

クラウドでのイミュータブルバックアップ実装例（技術概念）

主要なクラウドプロバイダーでは、イミュータブルストレージ機能が提供されています。特定製品の推薦ではなく技術概念として参考にしてください。

AWS S3 Object Lock：AWSのS3バケットに対してObject Lock機能を有効化することで、オブジェクト（ファイル）の保持期間中の変更・削除を防止します。コンプライアンスモード（管理者でも削除不可）とガバナンスモード（特定権限ユーザーは削除可）の2種類があります。
Azure Immutable Blob Storage：AzureのBlob Storageに対して時間ベースの保持ポリシーを設定することで、保持期間中のデータ変更・削除を防止します。コンプライアンス要件への対応にも活用されています。
Google Cloud Storage オブジェクト保持：Google Cloud StorageのRetention Policyを設定することで、設定期間中のオブジェクト削除を防止します。

イミュータブルバックアップ導入時の考慮点

保持期間の設定：業務要件・コンプライアンス要件・ランサムウェア対策（攻撃検知までの期間を考慮）に基づいて適切な保持期間を設定する。一般的に30日〜90日以上が推奨されます。
ストレージコスト：保持期間中はデータを削除できないため、ストレージ使用量が増加します。コスト試算を事前に行うことが重要です。
アクセス権限の管理：イミュータブルストレージのポリシー設定・変更権限は最小限のユーザーに限定し、MFAを必須とすることを推奨します。
クラウドアカウントの分離：バックアップ用クラウドアカウントを本番環境とは別のアカウントで管理することで、本番環境が侵害されてもバックアップへのアクセスを阻止できます。

7. RTO・RPO目標の設定と検証

バックアップ戦略を設計する上で、RTO（復旧時間目標）とRPO（復旧地点目標）の設定は不可欠です。これらの目標値はバックアップの頻度・保管方式・リストア手順を決定する基準となります。

RTO・RPOの定義

RTO（Recovery Time Objective）：障害・インシデント発生からシステムが復旧するまでの許容時間。「4時間以内にシステムを復旧する」のようにビジネス要件に基づいて設定します。RTOが短いほど、高速なリストア手段（ローカルバックアップからの復旧等）が必要になります。
RPO（Recovery Point Objective）：データ復旧の許容時点（どこまで遡れるか）。「最大1時間前のデータまで許容できる」のようにビジネス要件に基づいて設定します。RPOが短いほど、バックアップ頻度を高くする必要があります（例：1時間ごとのスナップショット等）。

業務クリティカルシステムのRTO/RPO設定例

システム種別	RTO（復旧時間目標）	RPO（復旧地点目標）	推奨バックアップ頻度
基幹業務システム（受注・在庫等）	4〜8時間以内	最大1〜2時間前まで	1時間ごとのスナップショット
会計・経理システム	24時間以内	最大24時間前まで（業務日次）	日次バックアップ
メール・コミュニケーション	4時間以内	最大24時間前まで	日次バックアップ
Webサイト・公開サービス	2〜4時間以内	最大24時間前まで	日次バックアップ
社内ファイルサーバー	8〜24時間以内	最大24時間前まで	日次バックアップ
開発・テスト環境	48〜72時間以内	最大1週間前まで	週次バックアップ

上記の設定例はあくまで参考値です。自社の業種・ビジネスインパクト・コスト制約を総合的に考慮して適切な値を設定し、経営者の承認を得た上で文書化することが重要です。

RTO/RPOの検証

設定したRTO/RPOが実際に達成可能かどうかは、定期的なリストアテストによって検証する必要があります。「設定したRTOは4時間だが、実際のリストアテストでは8時間かかった」という状況を事前に把握し、バックアップ方式の改善やリストア手順の最適化を行うことが重要です。

8. BCP（事業継続計画）との統合

バックアップ戦略は、より広い枠組みである事業継続計画（BCP）の一部として位置づけられます。SCS評価制度では、バックアップの技術的な整備だけでなく、インシデント発生時の事業継続のための組織的な計画・体制が求められます。

BCP策定の主要コンポーネント

ビジネスインパクト分析（BIA）：業務停止が事業に与える影響を分析し、優先度の高い業務・システムを特定します。RTOとRPOの設定の基礎となります。
インシデント対応手順：ランサムウェア感染・データ破損等のインシデント発生時の初動対応・連絡体制・復旧手順を文書化します。
代替業務手順：主要システムが停止した場合の手動対応・代替システムへの切り替え手順を整備します。
外部連絡先リスト：インシデント発生時に連絡すべき外部機関（JPCERT/CC・警察・保険会社・ITベンダー等）の連絡先を整備します。
復旧優先順位：複数のシステムが同時に影響を受けた場合に、どのシステムから優先的に復旧するかの順位を定めます。

ISO 22301との関係

ISO 22301は事業継続マネジメントシステム（BCMS）の国際規格です。BCPの策定・維持・改善を組織的に行うための枠組みを提供します。SCS評価制度の事業継続要件は、ISO 22301の概念と整合する部分が多くあります。ISO 22301を既に取得・維持している企業は、その延長線上でSCS評価制度のBCP要件への対応を進めることができます。

ISO 22301の取得が目標でない場合でも、ISO 22301が示す「計画（Plan）→実施（Do）→評価（Check）→改善（Act）」のPDCAサイクルで事業継続管理を行うアプローチは、SCS評価制度への対応においても有効な指針となります。

Keyper：バックアップシステムへのMFA適用でアクセス制御を強化

ランサムウェア攻撃者がバックアップシステムの管理コンソールに不正アクセスするリスクを防ぐため、バックアップ管理への強固な認証が不可欠です。Net PeaceのKeyperは、FIDO2対応のMFAでバックアップシステム・管理コンソールへのアクセスを厳格に保護します。SCS評価制度★3/★4のアクセス制御要件にも対応します。

Keyperの詳細を見る無料相談を申し込む

9. リストアテスト・演習の実施方法

「バックアップを取る」ことと「バックアップから実際に復旧できる」ことは別問題です。定期的なリストアテストは、バックアップ戦略の実効性を確認するための最重要プロセスです。

リストアテストの種類と実施頻度

テスト種別	内容	推奨頻度（★3）	推奨頻度（★4）
部分リストアテスト	特定ファイル・フォルダを選択してリストアし、データの整合性・内容を確認	月次	月次
フルシステムリストアテスト	システム全体（OS含む）をバックアップから復旧し、業務アプリの起動・データ確認まで行う	年1回以上	四半期ごと以上
BCP机上演習	ランサムウェア感染を想定したシナリオで、対応手順・役割分担・連絡体制を机上でシミュレーション	年1回以上	半年ごと以上

リストアテストの手順例

テスト計画の策定：リストアするデータの範囲・リストア先（テスト環境）・担当者・目標復旧時間を事前に決定する。
テスト環境の準備：本番環境に影響を与えないテスト環境（仮想マシン・別のPC等）を準備する。
バックアップからのリストア実施：選定したバックアップからデータ・システムをリストアし、開始時刻と終了時刻を記録する。
データ整合性・動作確認：リストアされたデータの内容・業務アプリの動作・主要な機能が正常に動作することを確認する。
復旧時間の計測と評価：実際の復旧時間をRTO目標と比較し、目標達成の可否を評価する。
記録の作成と保管：テスト実施日・対象バックアップ・復旧時間・確認結果・発見された問題点・改善事項を記録として保管する（SCS評価の証跡）。
改善事項の反映：テストで発見された問題点（復旧時間超過・データ欠損・手順の不備等）を改善計画に反映する。

リストアテストでよく発見される問題

バックアップデータが破損していて復旧できない（バックアップ検証プロセスの不備）
復旧手順が古く、現在のシステム構成に合っていない（手順書の更新不足）
リストア作業に必要な情報（暗号化キー・認証情報等）が紛失している
テスト環境のスペックが本番環境と大きく異なり、実際の復旧時間を正確に反映できない
バックアップソフトウェアのライセンスが失効しており、復旧ツールが使えない

10. よくある質問（FAQ）

Q1. クラウドサービス（Microsoft 365・Google Workspace等）のデータはバックアップ不要ですか？

必要です。Microsoft 365やGoogle Workspaceはサービスの可用性（システムが動作し続けること）は保証していますが、誤削除・ランサムウェア・内部不正によるデータ消失からの復旧は限定的な保護しか提供していません（例：Microsoft 365のごみ箱は93日間、Googleドライブのごみ箱は30日間）。SCS評価制度の要件を満たすためには、クラウドサービスのデータについても、別途バックアップソリューション（サードパーティの専用クラウドバックアップサービス等）による定期バックアップと長期保存が必要です。

Q2. ランサムウェア感染後、バックアップからの復旧にどのくらい時間がかかりますか？

復旧時間はシステムの複雑さ・バックアップデータ量・バックアップ方式・リストア手順の整備状況によって大きく異なります。小規模な中小企業のファイルサーバー復旧で数時間〜1日、中規模の基幹業務システムで数日〜1週間以上かかるケースがあります。復旧時間を把握するための定期的なリストアテストを実施し、実際の復旧時間とRTO目標のギャップを把握しておくことが重要です。

Q3. バックアップシステム自体へのアクセスはMFAで保護する必要がありますか？

はい、強く推奨します。ランサムウェア攻撃者がバックアップ管理コンソールに不正アクセスし、バックアップを削除・暗号化する手口が増加しています。バックアップ管理システムへのログインにはMFAを適用し、管理アクセス可能なユーザーを最小限に制限することが★3/★4の要件でも求められます。Net PeaceのKeyperは、バックアップシステムを含む各種システムへのFIDO2対応MFA適用を支援します。

Q4. テープバックアップとクラウドバックアップはどちらが良いですか？

どちらも一長一短があります。テープバックアップは物理的なエアギャップ（ネットワーク切り離し）が確実で、大容量データを低コストで長期保存できますが、リストア時間が長く、物理的な管理が必要です。クラウドバックアップはリストアの利便性が高く、地理的な冗長性を確保しやすいですが、リストア時のネットワーク帯域・コスト・接続性に依存します。3-2-1-1-0ルールの観点では、クラウドバックアップ（オフサイト）とオフラインバックアップ（テープ・取り外し可能なメディア）の組み合わせが推奨されます。

Q5. バックアップのコスト目安はどのくらいですか？

バックアップのコストは、データ量・保持期間・バックアップ頻度・使用するサービスによって大きく異なります。クラウドストレージの費用は一般的にGBあたり月数円〜十数円程度（ストレージ種別により異なる）ですが、転送・リストア・API呼び出しの費用も考慮が必要です。バックアップソリューションのライセンス費用、運用工数も含めてトータルコストを試算することを推奨します。IT導入補助金（最新情報はhttps://it-hojo.jp/で確認）の活用でコストを軽減できる場合があります。

11. まとめ

SCS評価制度のバックアップ・BCP要件の要点をまとめます。

★3のバックアップ要件：定期バックアップ・バックアップ失敗アラート・年1回以上のリストアテスト・記録保管が基本要件。
★4の追加要件：オフラインバックアップまたはイミュータブルクラウドストレージへの保管・四半期ごとのリストアテスト・RTO/RPO目標の設定と検証。
3-2-1ルール：3コピー・2種類メディア・1オフサイトのバックアップ配置。★3の基本要件をカバー。
3-2-1-1-0ルール：上記に加え、1オフライン（エアギャップ）・0エラー（リストアテスト確認）でランサムウェア対策を強化。★4要件に対応。
イミュータブルバックアップ：WORM技術でバックアップデータを変更・削除不可にする。AWS S3 Object Lock・Azure Immutable Blob Storage等で実装可能。
RTO/RPO：業務クリティカルシステムごとにRTO・RPO目標を設定し、リストアテストで検証すること。
BCP統合：バックアップは事業継続計画の一部。ISO 22301の枠組みと整合したBCP策定が推奨。
バックアップへのMFA適用：バックアップ管理コンソールへのアクセスにMFAを適用し、ランサムウェアによるバックアップ削除を防止。

ランサムウェアの脅威が高まる現在、「使えるバックアップ」の確保はSCS評価制度への対応においても、事業継続においても最重要の対策です。3-2-1-1-0ルールとイミュータブルバックアップの組み合わせで、ランサムウェアに強いバックアップ体制を今から整備することをお勧めします。最新のSCS評価制度情報はIPA公式ページでご確認ください。