ランサムウェア対策のバックアップ|本番環境と一緒に消されないための確認ポイント

By • 2026-10-27 • CloudOps

「バックアップは毎日取得しています」。その回答に、もう一つ確認したいことがあります。
そのバックアップを削除できるのは、誰でしょうか。

取得に成功した記録だけでは、攻撃を受けたときにデータを残せるかは分かりません。警察庁は、ランサムウェアによってバックアップデータも暗号化される事例を紹介し、ネットワークから切り離すなどの備えを推奨しています。
(警察庁:ランサムウェア被害防止対策)

この記事では、Webサービスや業務システムの管理担当者に向けて、バックアップの保存先、削除権限、保持設定の確認方法を整理します。まず、止まると業務に支障が出るシステムを一つ選び、現在の設定と照らし合わせて読んでください。

別の場所に保存していても、同じ権限で消せないか

バックアップの一覧画面を開いたら、保存先に加えて、その画面を操作しているアカウントの権限を確認します。

たとえば、本番サーバとバックアップを別の保存先に置いていても、本番の管理用アカウントで両方を削除できる構成なら、保存先の分離と削除権限の分離は一致していません。見るべき点は、「どこに置いたか」と「どの権限で操作できるか」の両方です。

保存先と権限を分けて確認する図。上段は一つの管理権限から本番とバックアップの両方を削除できる構成。下段は本番の管理権限とバックアップの削除・保持設定の管理権限を分ける設計例

図1:保存先だけでなく、管理権限の届く範囲を確認する。下段は設計の考え方を示す例で、特定の製品設定や保護の保証ではありません。画像を開くと拡大できます。

確認する操作は、バックアップの削除だけではありません。保存期間を短くする操作や、削除を防ぐ設定を解除する操作も対象にします。普段使う管理アカウントのほかに、バックアップ処理が使う認証情報、権限を切り替える仕組み、委託先の管理権限も確認してください。

クラウドの場合も、別リージョンへのコピーと、管理権限の分離は別の確認事項です。別アカウントへコピーする構成でも、本番側からコピー先の管理権限を使えるかを確認します。

「コピーできる」と「削除できる」を分けて考える

バックアップを作る処理には、保存先へ書き込むための権限が必要です。一方、過去のバックアップを削除したり、保護設定を変えたりする権限まで、同じ認証情報に持たせる必要があるかは確認できます。

最初から仕組みを入れ替えるのではなく、利用中の製品やサービスで、取得・コピー・削除・設定変更をどこまで分けられるかを調べます。必要な権限は製品によって異なるため、一律の設定で済ませず、提供元の手順と実際の処理を照合します。

AWS Backupには、別のAWSアカウントへバックアップをコピーする機能があります。ただし、利用条件や対応するリソース、暗号化キーの扱いを確認する必要があります。別アカウントに保存したという事実だけで、削除への保護まで確認済みにはできません。
(AWS:アカウント間のバックアップコピー)

委託先に確認する場合も、「バックアップはありますか」だけでは判断材料が足りません。「本番の管理権限で、保存済みのバックアップを削除できますか。保持設定も変更できますか」と、操作を指定して確認します。

削除を防ぐ設定は、解除できる条件まで見る

保存済みデータの変更や削除を一定期間制限する仕組みは、イミュータブルバックアップなどと呼ばれます。利用するときは、機能名だけでなく、誰が制限を解除できるか、何日間保持されるかを確認してください。

たとえばAWS Backup Vault Lockには、十分な権限があればロックを解除できるガバナンスモードと、猶予期間の終了後はロックを解除できないコンプライアンスモードがあります。後者では、保持期間が終わるまでバックアップを削除できず、保存費用も発生します。
(AWS:Backup Vault Lock)

「長く残せば安心」と期間だけを延ばさず、何日前のデータまで戻す必要があるか、保存容量と費用はどの程度かを確認します。解除できない設定は、本番へ適用する前に検証環境で動作と保持条件を確かめます。

また、バックアップの暗号化と削除防止は別の機能です。暗号化してあることだけを根拠に、削除できないとは判断しないでください。

残したデータを使って戻せるか

削除への備えを確認したら、復元に使うアカウントと手順も確認します。本番用のアカウントを停止した場合に、誰がバックアップを取り出し、別の環境へ復元するのかをたどってください。

復元テストでは、処理が完了した記録に加え、必要なデータを読めるか、アプリケーションを動かすための設定やファイルがそろっているかを確認します。暗号化キーを使う構成では、そのキーを利用できることも確認対象です。

実際に侵害されたシステムを復旧する場合は、通常の復元テストとは手順が異なります。JPCERT/CCは、ネットワークへ戻す前に、マルウェアや不正な設定などが排除されていることを確認するよう案内しています。復元しただけで安全を確認したことにはなりません。
(JPCERT/CC:侵入型ランサムウェア攻撃を受けたら読むFAQ)

バックアップは、窃取された情報の流出を防ぐ対策の代わりにもなりません。ここで扱うのは、復旧に使うデータを残し、利用できる状態を確かめるための備えです。

一つのシステムで、確認結果を残す

設定を調べた結果は、次の表にまとめられます。分からない欄は「未確認」とし、調べる相手や設定画面を記録してください。本番データの削除操作で試す必要はありません。まず設定と手順を確認し、実動作の検証は対象を限定した検証環境で行います。

確認すること 残す情報
どこに保存されているか 対象データ、保存先、コピーの成功記録
誰が削除・設定変更できるか アカウントや役割、削除権限、保護を解除できる条件
いつまで残るか 保持期間、保存世代、設定を変更できる権限
本番と切り離して復元できるか 復元担当、利用する権限・キー、テスト日、動作確認の結果

この確認で、保存先は分かるが削除権限が分からないなら、先に権限を調べます。削除は制限できていても復元記録がなければ、復元テストを計画します。バックアップ製品を追加する前に、今の構成で確認できていない点を明らかにしてください。

バックアップ構成の確認・見直しについて相談する

バックアップの保存先や管理権限が分からない、委託先から取得成功の報告は受けているが保護設定を確認できていない、といった場合は、現在の構成と困っている点をお知らせください。

CloudOpsでは、対象環境に応じて、構成確認、設定の見直し、復元検証の支援について、対応可否・範囲・費用を個別に確認します。ご相談時は、対象システム、利用中のクラウドやバックアップ製品、現在の管理担当を分かる範囲でご記載ください。

バックアップ構成の確認・見直しについて相談する

参考資料

情報確認日:2026年10月27日。製品の対応範囲や設定条件は、利用時に提供元の最新資料をご確認ください。

You Might Also Like