RPO と RTO：次のランサムウェアの前に定義する

ランサムウェアがサーバーを暗号化するその日、業務のどこまでを、どれだけの時間で復旧できるのかを、その場でリアルタイムに知りたい人は誰もいません。この2つの答えには名前があります。RPO と RTO です。これらは、事前に――落ち着いて、机の上で――あなたが定義する数値であるか、さもなければ最悪のタイミングでインシデントがあなたの代わりに決めてしまう数値です。

本稿では、この2つの概念を回りくどい言い回しなしに説明し、今なお有効なバックアップのルール（3-2-1）を示し、そして CT-e の発行も貨物の追跡も一日たりとも止められない運送会社が、なぜこれを特有の視点で考える必要があるのかを解説します。あなたが事前に読んでおきたかったと思うであろう、明快な定義です。

RPO（Recovery Point Objective、目標復旧時点）とは、あなたの業務が許容できるデータ損失の最大量を、時間で測ったものです。RPO が1時間であれば、復元後に直近1時間分の作業を失っている可能性があり――それは許容範囲だ、という意味になります。RPO が24時間であれば、昨日の朝の状態に戻ることになります。

実務上、RPO はどれくらいの頻度でバックアップを取るかを規定します。1日1回のバックアップで RPO 15分を実現することはできません――計算が合わないのです。RPO が小さいほど、バックアップは頻繁に（そして高価に）なります。

定義を前に進める問いは直接的です。最後のバックアップ以降にシステムへ入力されたものをすべて失ったら、それはいくらの損失になるか？ 発行済みで未保存の CT-e であれば、コストは入力のやり直しと税務上の不整合のリスクです。積載明細であれば、トラックに何が積まれたのかが分からなくなることです。

RTO（Recovery Time Objective、目標復旧時間）とは、復元が完了しシステムが再び動き出すまで、あなたの業務が停止に耐えられる最大の時間です。RTO が4時間であれば、インシデントから業務が再稼働するまでに4時間の猶予があり――それより1分でも超えることは許されません。

RTO はファイルを書き戻す時間だけではありません。時計全体、すなわち問題の検知、侵害された範囲の隔離、クリーンなバックアップの発見、復元、完全性の検証、そして再起動までを含みます。コピー時間だけを計測している人は、検証と再起動が想定より長くかかることを手遅れになってから知ることになります。

ここでの問いはお金の話です。1時間の停止はいくらのコストか？ 運送会社にとって、停止時間とは配送の遅延、SLA 違約金、伝票のないままキューに並ぶトラック、そして電話をかけてくる顧客です。この1時間あたりのコストこそが、より速い復旧への投資を正当化するか否かを決めるのです。

よく混同されます。区別する簡単な方法はこうです。

• RPO は過去を見る――過去のどれだけのデータ損失を許容するか。
• RTO は未来を見る――今から先、どれだけの時間の停止を許容するか。

あるシステムは、RPO は優秀だが RTO は最悪ということがあり得ます。ほとんど何も失わないが、再起動に3日かかる、という具合です。あるいはその逆で、20分で再起動するが、戻った先は先週の状態だった、ということも。両者は、システムごとに、揃って筋が通っている必要があります。税務基幹システム（ERP）は厳しい RPO と RTO を要求します。ソースから再構築できる BI のデータウェアハウスであれば、より余裕のある数値に耐えられます。

RPO と RTO は、復元できる本物のバックアップがあって初めて成り立ちます。今なおこれを整理するルールが 3-2-1 です。

• 3つのデータのコピー（オリジナルに加えて2つ）。
• 2種類の異なるメディアまたは技術（両方を同じサーバーの同じディスクに置かない）。
• 1つのサイト外コピー――オフラインまたはイミュータブル（変更不可）で、ランサムウェアが到達も削除もできないもの。

最も崩れやすいのが「1」です。同じサーバー上に置かれたバックアップや、ネットワークにマウントされた NAS 上のバックアップは、攻撃当日にほかのものと一緒に暗号化されます。現代のランサムウェアは、身代金を強要するために、まずバックアップを探して破壊します。だからこそ、サイト外コピーはイミュータブル（write-once、誰も上書きできない）であるか、真に切断されている必要があるのです。この「1」がなければ、ルール全体があなたを救いません。

これはインシデントの後で最も痛みを伴う言葉です。毎日実行され、ファイルを生成し、ダッシュボードに緑のマークを付ける――しかし一度も復元されたことのない――バックアップのルーティンは、保証ではなく思い込みです。ファイルが破損していたこと、正しいデータベースが欠けていたこと、あるいは復元が計画の3倍の時間を要することを、多くの人が攻撃当日に初めて知るのです。

バックアップは、あなたが本当に復元をテストし、隔離された環境で、時間を計測して初めて、本物のバックアップになります。このテストは、あなたの RTO が現実的か、そして RPO が設定した頻度と一致するかを、信仰ではなく事実で答えてくれます。具体的な推奨は、四半期ごとに文書化された復元テストを実施し、システムに大きな変更を加えるたびに実施することです。

運送会社には「数日」の RTO という贅沢はありません。ERP がなければ CT-e も MDF-e も発行できず――トラックは税務書類なしに構内から出られません。追跡がなければ、車両の位置も輸送中の貨物の可視性も失います。停止する1時間ごとが、SLA 違約金、配送の遅延、鳴りやまぬ電話に変わります。

実務でこれをどう考えるか。

• システムを重要度で分ける。税務発行と追跡（SASCAR、Autotrac、Omnilink）は数時間の RTO と低い RPO を要求します。BI レポートはより余裕があります。
• RPO に合致するバックアップ頻度。伝票の損失を最大1時間までしか許容できないなら、税務データベースのバックアップを日次にすることはできません。
• イミュータブルでサイト外の1つのコピー――ERP を捕らえるランサムウェアが、そのバックアップに到達できないように。
• 時間を計測した復元テストで、4時間で本当に書類の発行を再開できるかを知る。

目的はシンプルです。データの人質事件を、数日の停止ではなく数時間の不便で済ませること――そして身代金の支払いが机の上の唯一の選択肢になることが決してないようにすることです。それは後付けの継ぎ接ぎではなく、設計によるプライバシーと継続性です。