関連するソリューション
セキュリティサービス
セキュリティ製品
サイバー・セキュリティ・ソリューション部
テクニカルスペシャリスト
青山 武志
初めての講師、初めての執筆
先日、人生で初めてセミナー講師を務めさせていただきました。テーマは「企業を守る最新セキュリティ対策と実践的バックアップ運用」。普段は現場でのセキュリティ運用の支援や技術的な対応が中心の私にとって、90分間の講演は大きな挑戦でした。準備段階では「何をテーマにしよう」「専門用語をどう噛み砕くか」「自社サービスの宣伝を中心にせず、マーケティング感を前面に出さないようにするには」など悩みも尽きませんでしたが、当日は多くの方にご参加いただき、緊張もしましたが、楽しい一日を過ごせました。
さて、今回のコラムも、実はこれが初めての執筆です。講師として話した内容から一部流用しつつ、改めて文章として整理することで、自分自身の理解も深めつつ、皆様に共有できればと思います。
なぜ今バックアップが重要なのか
2025年現在、サイバーインシデントの件数は高止まりしており、新しい攻撃手法が次々と登場しています。令和7年3月13日に公表された警察庁の調査によると、バックアップを取得していた企業のうち、インシデント発生後に実際に復旧できたのはわずか23%でした。
復旧できなかった原因は様々ですが、理由の多くは「バックアップも暗号化されたことによるもの」となっていました。
警察庁 令和6年におけるサイバー空間をめぐる脅威の情勢等について(令和7年3月13日) p,45図引用
https://www.npa.go.jp/publications/statistics/cybersecurity/data/R6/R06_cyber_jousei.pdf
これは、9月に発表された「令和7年上半期におけるサイバー空間をめぐる脅威の情勢等について」でも触れられており、攻撃者は復旧対応の妨害として、ログやバックアップの削除も行ってくると、継続してバックアップの重要性が語られています。
つまり、「取っているつもり」ではなく、「復旧できる状態」にあるか、「取って満足していないか」が問われています。
中小企業が直面する課題
サイバー攻撃は新しい攻撃手法が次々と登場しています。それらの攻撃に対抗するように、企業の防御体制は常にアップデートを求められ、新しい技術や概念、製品が数多く出てきています。バックアップの領域だけ見ても、「イミュータブルバックアップ」や3-2-1ルールを発展させた「3-2-2ルール」や「4-3-2ルール」、「エアギャップバックアップ」など、様々な概念が現れ、それに対応した製品も数多く販売されています。
そこは理解しているが実際にどうすればよいのか、というお悩み事は数多くあると思います。
イミュータブルバックアップ：一度保存したデータを変更・削除できないようにする、不変（immutable）なバックアップ方法
3-2-1ルール：3つのデータコピーを保持し、2種類の異なるメディアに保存し、そのうちの1つをオフサイト（遠隔地）に保管する。保管場所や種別を増やしたのが4-3-2ルールなど。
簡単に挙げられるものとしては、以下のような点でしょうか。
- 予算が限られている（高額なソリューションは導入が困難）
- 専任のセキュリティ担当者がいない
- 納期が短く、即対応が求められる
- 運用負荷を極力減らしたい
- 論理的隔離（ルータ等）への不安
こうした状況では、バッチで回していたバックアップ運用を、導入した製品でのオペレーションに変えたり、クラウド＋イミュータブルストレージ＋自動リストアといった理想的な環境を構築するのは難しく、創意工夫による現場対応が求められるケースが多いです。
詳細は割愛しますが、先日の講演ではこれらの対策の内「エアギャップバックアップ」に焦点を当てて、いかに隔離された環境を作り出すかをサブテーマに、バックアップ前後でのLANケーブルの結線/抜線を許容できる範囲で自動化しようという、私がちょっと面白いと感じた事例を含めて紹介してきました。
RPOとRTO
今回のコラムでは、そこに触れるとかなり深くなりすぎるテーマであるRPO/RTOについても少しだけ語ってみたいと思います。RPO/RTOとは
- RPO（Recovery Point Objective）
「どこまで過去に遡ってデータを復元できるか」という指標です。例えばRPOが1時間なら、障害時には直近1時間分のデータは失われていても事業に支障がないという意味になります。 - RTO（Recovery Time Objective）
「障害発生からどのくらいの時間以内に復旧できるか」を示します。RTOが2時間なら、停止したサービスやシステムを2時間以内に動かさなければならないという目標です。 - RLO（Recovery Level Objective）
「どのレベルまで業務を回復させるか」を定める目標です。RLOは、完全復旧を目指すのではなく、「災害発生から48時間以内に通常業務の70％を回復」「主要商品ラインだけは稼働」など、限られたリソースと時間内で“最低限事業を継続できる状態”を明確化することが目的です。
RPO/RTO決定時のポイントと難しさ
- ビジネス影響度の正確な評価
どの業務が止まると、どの程度の損害が発生するかの具体的な把握が不可欠ですが、数値化は難しく、関係者間での認識統一に時間がかかります。 - コストと要件の折り合い
高度な復旧体制は高コストになりやすいため、現実的な予算内でどこまで妥協できるかを検討することが求められます。 - 将来予測の不確実性
事業拡大や新規システム導入でバックアップ要件が変わる可能性があり、柔軟な見直し体制を作る必要があります。 - 技術的制約や運用体制の整備
希望値を設定しても、それを実現可能にする技術や専門人材が不足しがちで、現実とのギャップ調整に工数がかかります。
決定時の課題と工夫
- RPO・RTO・RLOともに業務理解の深さが求められ、関係者間の認識共有や合意形成に時間と労力がかかることが多いです。
- RLOは特に機能の優先度の見極めが難しく、経営判断や顧客要求とのすり合わせが必要です。
- 技術的制約や復旧コスト、人的リソースとのバランスを取りながら、定期的に見直すことが重要です。
- RLOを明確にすることで、緊急時の対応がより効率化され、被害最小化に貢献します。
恐らく、特にコストと要件の折り合いをつけるのに苦労する会社が多いのではないでしょうか？
船頭多くして船山に登るではないですが、要望として聞いてしまうと際限なく要望が出てきてしまうため、このあたりは何を優先するかをIT-BCPと同じスキームで考えて、経営層を巻き込んで決めていく必要があると思います。場合によってはコンサル会社等のような外部から言ってもらうというのも一つの手かと思います。同じこと言ってるのに・・・という思いはぐっとこらえて。
復旧テストのすすめ
さて、様々な社内調整を経て、バックアップの基準やルールも決めて、「誰が」「いつ」「どこに」バックアップを取るかを明文化し、インシデント時の対応フローも簡易なものを作成し運用に乗せることができました。その取得したバックアップはリストアで正しく使えますか？
バックアップは「取っている」だけでは不十分です。実際に復旧できるかどうかを確認する復旧テストが不可欠です。
- ファイル単位のリストアテスト：重要な業務ファイルを削除または移動し、バックアップから復元して内容が一致しているか確認。
- 仮想環境でのシステム復旧テスト：VirtualBoxやHyper-Vなどを使い、システムバックアップを仮想環境に復元して動作確認。
- ランサムウェア想定テスト：疑似的な暗号化ファイルを作成し、バックアップから復元できるかを確認（実際のマルウェアは使用しない）。
- 復旧時間の計測（RTOテスト）：業務再開までにかかる時間を計測し、RTOの設定と改善に活用。
- 社内共有と記録：テスト結果を簡単なレポートにまとめて社内で共有し、改善サイクルを回す。
バックアップとBCPの関係
バックアップの目的とは、企業の重要データを保護し、障害・攻撃・災害などの非常時において、業務を迅速かつ確実に再開できる状態を維持することであり、事業継続計画（BCP）の中核要素です。災害や障害時に業務を継続するためには、経営層の関与とトップダウンの推進が不可欠です。定期的な見直しとプロセスの改善を通じて、企業の信頼性とレジリエンスを高めることができます。
伝えることの大切さと、バックアップの本質
初めての講師、初めての執筆。どちらも緊張と不安の連続でしたが、終えてみると「伝えることの大切さ」を実感しました。バックアップは、企業の命綱です。「取っている」だけで満足せず、「復旧できる」ことを前提に、運用を見直してみてください。
それでは、また次回お会いしましょう！ 次回はOSINTかSIEMルールか、ちょっとラフな感じでBLUE TEAMアナリストあたりをテーマにしてみようかと思っています。
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。
