第2部 日々の運用
第6章 バックアップと事業継続(BCP/DR)
火事、水害、機器の故障、うっかり削除、そしてランサムウェア。何が起きても会社が立ち直れるかは、たった一つの問いに集約されます——「そのデータ、本当に戻せますか?」
🎯 この章で学ぶこと
- なぜバックアップが会社の「最後の砦」なのか
- 3-2-1ルール — 迷ったらこれに従えばよい設計の基本
- ランサムウェアに暗号化されないバックアップの作り方(オフライン/イミュータブル)
- RPO・RTOと復旧訓練 — 「取ってあるつもり」から「戻せる」へ
- クラウド・SaaSのデータも自分で守るという発想(責任共有モデル)
6.1 バックアップは最後の砦
セキュリティ対策には、入口で防ぐもの(ウイルス対策、ファイアウォール)、中で被害を抑えるもの(権限管理、監視)など、いくつもの層があります。しかし、それら全部をすり抜けて最悪の事態が起きたとき——サーバーが壊れた、全ファイルが暗号化された、大事なフォルダを丸ごと消してしまった——最後に会社を救うのはバックアップだけです。ほかの対策が「攻撃を受けないための盾」なら、バックアップは「受けてしまった後で立ち上がるための命綱」です。
とくに近年はランサムウェア(データを勝手に暗号化し、元に戻す代わりに身代金を要求する攻撃)が中小企業を無差別に襲っています。「うちみたいな小さな会社は狙われない」という思い込みは通用しません。攻撃は自動化されており、大企業も町工場も等しく標的です。そして感染してしまったとき、身代金を払うかどうかではなく、まともなバックアップがあるかどうかが会社の生死を分けます。バックアップさえ生きていれば、身代金を払わずに事業を再開できます。逆に言えば、バックアップがなければ——あるいは壊れていれば——会社が傾きます。
ランサムウェアの被害者が身代金を支払っても、データが完全に復号される保証はどこにもありません。復号ツールが不完全だったり、そもそも渡されなかったりします。さらに「一度払う会社」と認識されて再び狙われることも。交渉のテーブルに座らずに済む唯一の方法が、健全なバックアップを持っておくことです。
6.2 3-2-1ルール — 迷ったらこれ
バックアップ設計で世界的に使われている合言葉が「3-2-1ルール」です。難しい理論ではなく、覚えやすい数字の並びに過ぎません。まずはこれを目標にするのが、一人情シスにとって最も現実的な出発点です。
| 数字 | 意味 | なぜそうするのか |
|---|---|---|
| 3 | データは3つのコピーを持つ(本番データ + バックアップ2つ) | 1つが壊れても、まだ2つ残る。冗長性が安心を生む |
| 2 | 2種類の異なる媒体に保存する(例:社内NASと外付けHDD、クラウド) | 同じ種類の機器は同じ原因で同時に壊れやすい。種類を分けると全滅を避けられる |
| 1 | うち1つは離れた場所(オフサイト)またはオフラインに置く | 火事・水害・盗難で社内が全滅しても、社外のコピーが生き残る |
たとえば「①社内のファイルサーバー(本番)、②同じ社内のNASへ毎晩コピー、③クラウドストレージへ毎晩コピー」なら、コピーは合計3つ、媒体はサーバー・NAS・クラウドで複数種類、そして③は社外——3-2-1を満たします。難しく考えず、「もし今この建物が焼けても、どこかにデータが残っているか?」を自問すれば、足りない部分が見えてきます。
多くの中小企業は「社内に1コピーだけ」という状態です。完璧な3-2-1を一度に目指すより、まず社外(オフサイト)のコピーを1つ増やすだけで、リスクは劇的に下がります。クラウドバックアップサービスの契約や、外付けHDDを定期的に自宅・別拠点・貸金庫へ持ち出す運用でも構いません。小さく確実に前進しましょう。
6.3 ランサムウェア対策としてのバックアップ
ここで一つ、見落とされがちで、しかし致命的なポイントがあります。バックアップそのものも攻撃者に狙われるということです。ランサムウェアは賢く、社内ネットワークに侵入すると、まず「つながっているバックアップ」を探して先に暗号化・削除しようとします。人質(本番データ)だけでなく、身代金を払わずに済む切り札(バックアップ)まで潰しに来るのです。
つまり、常時ネットワークにつながっていて、いつでも書き換えられるバックアップは、いざというとき一緒にやられる危険があります。これを防ぐ考え方が2つあります。
| 方式 | 仕組み | 具体例 |
|---|---|---|
| オフライン(エアギャップ) | バックアップを普段はネットワークから物理的に切り離しておく。攻撃者の手が届かない | バックアップ後に外付けHDDを抜いて金庫に保管、LTOテープを保管庫へ、専用回線のみ接続 |
| イミュータブル(変更不能) | 一度書き込んだら一定期間は誰も(管理者ですら)消せない・書き換えられない設定にする | クラウドストレージのオブジェクトロック機能、WORM対応のバックアップ製品 |
「3-2-1ルール」に、この考え方を足したものが最近は「3-2-1-1-0」とも呼ばれます。末尾の「1」が1つはオフラインまたはイミュータブル、「0」が復旧テストでエラーゼロを確認を意味します。専門用語は覚えなくて大丈夫です。要は「攻撃者が絶対に触れないコピーを、最低1つは確保しておく」——これが現代のバックアップの肝です。
バックアップ管理用のアカウントが乗っ取られれば、攻撃者はすべてのコピーを消せます。だからこそバックアップ環境のパスワードは本番と分け、多要素認証(MFA)をかけ、管理権限は最小限に(第3章の最小権限の考え方はここにも効きます)。また、バックアップ先が本番と同じ認証基盤・同じネットワークにぶら下がっていると、一度の侵入で全滅します。バックアップは「本番から隔離してこそ意味がある」と覚えておいてください。暗号や鍵管理をさらに深めたい場合は「入門コース(🐍 Python × セキュリティ)第12章 暗号・ハッシュ・パスワード管理」も参考になります。
6.4 復旧できて初めてバックアップ
一人情シスが最も陥りやすい落とし穴が、「バックアップを取ること」を目的にしてしまうことです。本当の目的は「取ること」ではなく「戻せること」。取っているだけで一度も復旧を試したことがなければ、それは「戻せるかどうか分からないデータの塊」に過ぎません。いざ本番で復旧しようとして初めて「バックアップファイルが壊れていた」「手順が分からない」「復旧に3日かかると判明した」——これでは意味がありません。
RPOとRTO — 2つの「どれだけ」
復旧を考えるとき、2つの物差しがあります。名前は難しそうですが、中身はシンプルな問いです。
| 用語 | 読み解くと | 決め方のイメージ |
|---|---|---|
| RPO(目標復旧時点) | 「どこまで戻ってしまうか」= 最大でどれくらいのデータを失っても許容できるか | 毎晩バックアップなら、最悪その日の日中の作業は失う(RPO=24時間)。1時間ごとなら失うのは最大1時間分 |
| RTO(目標復旧時間) | 「どれだけで復旧するか」= 停止してから復旧までに許される時間 | 基幹システムは半日で戻したい(RTO=半日)、共有フォルダは1〜2日でも耐えられる、など業務の重要度で変える |
この2つは「短くするほどお金と手間がかかる」性質があります。だからすべてを最短にする必要はありません。業務ごとに「ここまでの損失なら耐えられる」という現実的な線を引き、それに見合ったバックアップ頻度と復旧手段を選ぶ——これが一人情シスの腕の見せどころです。受発注システムはRPO・RTOともに短く、社内の資料フォルダはゆるく、とメリハリをつけましょう。
復旧訓練 — 年に一度は必ず試す
どんなに立派なバックアップ設計も、実際に戻してみるまで信用してはいけません。最低でも年に1回、できれば四半期に1回、「バックアップからファイル(やサーバー)を実際に復元してみる」訓練をしましょう。訓練で確認すべきは次の点です。
- バックアップファイルがちゃんと開ける・展開できるか(壊れていないか)
- 手順書だけを見て、自分以外の人でも復旧できるか(属人化していないか — 第1章)
- 復旧にかかった実時間は、想定したRTOに収まっているか
- 復旧したデータの中身が、想定したRPOどおりの新しさか
現場で本当によくあるのが、この落とし穴です。バックアップジョブが半年前からエラーで止まっていたのに誰も気づかなかった/バックアップ先の容量がいっぱいで新しいデータが書けていなかった/バックアップ対象のフォルダ指定が古く、肝心のデータが対象外だった/暗号化してあったが復号パスワードを誰も覚えていなかった——。「毎晩動いているはず」は思い込みです。成功・失敗のログを定期的に確認し、月に一度は目視で中身をチェックする習慣を持ちましょう。バックアップは「設定して終わり」ではなく「見守り続ける運用」です。
6.5 事業継続(BCP/DR)の基本
バックアップは「データを戻す」話ですが、会社が止まらないためには、もう少し広い視点が要ります。それがBCP(事業継続計画)とDR(災害復旧)です。難しく身構える必要はありません。要は「大きなトラブルが起きたとき、会社はどう業務を続けるか・どう立て直すか」をあらかじめ決めておくことです。
一人情シスがBCPで最初に考えるべきは、「何を最優先で復旧するか」の順番です。すべてを同時には戻せません。会社が「これが止まると商売にならない」という業務から順に並べます。
| 優先度 | 例(会社によって異なる) | 考え方 |
|---|---|---|
| 最優先 | 受発注・請求システム、顧客対応に使うメール、決済 | 止まると即、売上と信用に直結する |
| 次点 | 社内の共有ファイル、勤怠、業務アプリ | 数時間〜1日なら代替手段でしのげる |
| 後回し可 | 社内ポータル、過去資料、開発環境 | 復旧が数日遅れても事業は回る |
そして、想定すべきトラブルは3種類です。①災害(地震・火災・水害・停電)、②機器故障(サーバー・HDDの寿命、ネットワーク障害)、③人的ミス・攻撃(誤削除、設定ミス、ランサムウェア)。それぞれに対して「起きたら誰が・何を・どの順で動くか」を1枚の紙にまとめておくだけで、いざというときの混乱がまるで違います。連絡先(経営層、ベンダー、回線業者)、復旧手順の在り処、代替手段——これらをネットが使えない状況でも見られる形(印刷やオフライン)で残しておくのがコツです。
立派なBCP文書を何十ページも作る必要はありません。一人情シスにまず必要なのは、「サーバーが止まった/ランサムに感染した/建物が使えない、そのとき最初の30分に何をするか」を書いた1枚のカードです。連絡順、電源を切るべきか否か、外部支援先の電話番号。これを財布やスマホ、そして紙で持っておく。詳しいインシデントの初動は第10章で扱います。
6.6 クラウド・SaaSのデータも自分で守る
「うちのデータはクラウド(GoogleやMicrosoft、各種SaaS)に置いてあるから、バックアップは向こうがやってくれる」——これは危険な誤解です。ここで理解しておきたいのが「責任共有モデル」という考え方です。
クラウド事業者が責任を持つのは、あくまで「サービスの基盤(サーバーやデータセンター)が壊れないこと」まで。一方、「あなたのデータの中身」——誤って消したファイル、退職者が削除したフォルダ、ランサムウェアで暗号化された同期ファイル、アカウント乗っ取りで消されたメール——これらを守るのは利用者であるあなたの責任である場合がほとんどです。
| 誰の責任か | 内容 |
|---|---|
| クラウド事業者 | データセンターの電源・空調・物理セキュリティ、サーバー機器、サービスの可用性 |
| 利用者(あなた) | アカウントの管理、アクセス権の設定、そしてデータの内容・その消失に対する備え |
具体的な怖い例を挙げます。クラウドの共有ドライブと社内PCが同期していると、PCがランサムウェアに感染したとき、暗号化されたファイルがそのままクラウド側にも同期され、正常なファイルが上書きされてしまうことがあります。「クラウドにあるから安心」どころか、被害がクラウドまで広がるのです。また、SaaSによっては、退職や解約でアカウントを消すと中のデータも消え、後から取り戻せないものもあります。
対策は次の通りです。①各SaaS/クラウドの「ゴミ箱の保持期間」や「バージョン履歴」がどれくらいかを把握する(意外と短いことがあります)。②重要なデータはSaaSの外へ定期的に書き出す(エクスポート)か、SaaS専用のバックアップサービスを使う。③解約・退職の前に必ずデータを退避する。SaaSの棚卸しや設定の落とし穴については、次の第7章で詳しく扱います。
まとめ
- バックアップは会社の「最後の砦」。ランサムウェア時代、戻せるバックアップの有無が生死を分ける
- 迷ったら3-2-1ルール(3コピー・2種類の媒体・1つはオフサイト)。まずは社外コピーを1つ足すことから
- バックアップ自身も攻撃対象。オフラインまたはイミュータブルなコピーを最低1つ、本番から隔離して持つ
- 「取ること」ではなく「戻せること」が目的。RPO・RTOを業務ごとに決め、年1回は必ず復旧訓練を
- クラウド・SaaSのデータも責任共有モデルで自己責任の範囲がある。ゴミ箱・履歴の期間を把握し、外へ退避する
演習(自社の点検)
自社の最も重要なデータ(たとえば受発注や顧客情報)について、いまバックアップのコピーが何個、どんな媒体に、どこにあるかを書き出してください。3-2-1ルールを満たしていますか。足りない要素はどれですか。
考え方
点検の視点は「もしこの建物が今夜焼けたら、明日データは残っているか?」です。多くの会社は「社内に1〜2コピー」で止まっており、欠けているのはたいてい「1(オフサイト/オフライン)」です。まず社外コピーを1つ増やすのが最優先。そのうえで、そのコピーが常時ネットワークにつながっていないか(=ランサムウェアに一緒にやられないか)も確認しましょう。完璧を目指すより、いちばん弱い環を1つ強くする発想で十分です。
直近1年以内に、バックアップから実際にファイルやシステムを「復元してみた」ことはありますか。ない場合、いざ復旧が必要になったとき、手順書だけを見てあなた以外の人が復旧できる状態になっていますか。
考え方
「一度も復元を試していない」なら、それは復旧できる保証のないデータです。点検の視点は「復旧訓練の有無」と「属人化の度合い」の2つ。テスト用の別フォルダにバックアップから1ファイル復元するだけでも、多くの発見(壊れていた/手順が古い/思ったより時間がかかる)があります。加えて、あなたが不在でも誰かが復旧できるよう、手順・パスワードの在り処を安全な形で共有しておく——これは第1章で挙げた属人化リスクへの直接の答えでもあります。
自社が使っているクラウド/SaaS(メール、ファイル共有、業務アプリなど)を1つ選び、「そのサービス上で大事なフォルダを丸ごと削除してしまったら、何日後まで、どうやって取り戻せるか」を調べてください。
考え方
点検の視点は「責任共有モデルのうち、自分の責任範囲を把握しているか」です。多くのSaaSにはゴミ箱や版履歴がありますが、保持期間は30日程度だったり、管理者操作では戻せないケースもあります。調べてみて「思ったより短い」「そもそも戻せない」と分かったら、それが対策すべきギャップです。重要データはSaaSの外へ定期エクスポートするか、専用バックアップの導入を検討しましょう。