こんにちは!
クララのマーケティングチームです。
2026年10月、国内のパブリッククラウドの一部リージョンがランサムウェア攻撃を受け、多くの企業・自治体のシステムが停止しました。事業者からは、対象環境のデータは取り出しや復元が困難な見通しであり、復元は利用者自身が保持するバックアップからのみ可能という趣旨の発表がありました。
「クラウドに載せているから大丈夫」「スナップショットを取っているから安心」――そう考えていた担当者の方にとって、見直しのきっかけになった出来事ではないでしょうか。本記事では特定のサービスや製品によらない一般論として、ランサムウェアや大規模障害に備えるバックアップの条件を整理します。
- 今回のクラウド障害で何が起きたのか(事実の整理)
- 「クラウドだから安全」が成り立たない3つの理由
- 数字で見るランサムウェア被害の現状
- BCPに必要な「もう一つの保管場所」の5つの条件
- 今日から確認できるチェックリスト
クララではBCP・DR対策サービスとして北海道データセンターを利用したデータプロテクションプランをご用意しております。ご興味ある方はまず下記リンクよりサービス資料をダウンロードしてみてください。
何が起きたのか:2026年10月のクラウド障害
事業者の公表内容によると、概要は次のとおりです(2026年10月12日時点の公開情報にもとづく)。
- 2026年10月7日未明、東日本リージョン1の一部ゾーンで仮想サーバーが停止し、再起動できない状態に
- 原因は第三者による不正アクセス(ランサムウェア攻撃)。侵入経路は調査中
- 影響を受けたのは、このクラウドを利用する495の企業・自治体
- 対象ゾーンのデータは取り出しや復元が困難な見通しで、復元は利用者自身が保持するバックアップからのみ可能との見解
- 対象環境は別環境での再構築を案内。他リージョンでも、安全確認のため管理コンソールを停止
ここで注目したいのは、障害そのものよりも「データを戻せるかどうかは、利用者側でバックアップを持っていたかで決まった」という点です。これは特定の事業者に限らず、どのクラウドやデータセンターでも起こりうる構図です。
「クラウドだから安全」が成り立たない3つの理由
1. 冗長化(可用性)とバックアップは別物
クラウドの多くは、ストレージの多重化やゾーンをまたぐ冗長構成で、機器の故障に強く作られています。しかし冗長化は「同じデータを同時に複数の場所に持つ」仕組みなので、暗号化や削除といった「正しくない変更」もそのまま複製されます。ランサムウェアや誤操作から守るには、過去の時点に戻れるバックアップが別に必要です。
2. データの保護は利用者の責任範囲
クラウドは「責任共有モデル」で運用されるのが一般的です。基盤(データセンター、物理サーバー、仮想化層など)は事業者が守り、その上に載せるOS・アプリケーション・データの保護は利用者の責任とされるケースが大半です。利用規約やサービス仕様で、事業者がどこまでデータを保全するか(あるいはしないか)を一度確認しておくことをおすすめします。
3. 同じ環境の中にあるバックアップは、一緒にやられうる
スナップショットやバックアップが本番と同じ基盤・同じ管理コンソール・同じ認証情報で扱える場所にある場合、侵入した攻撃者はそれにも手が届きます。警察庁の資料でも、攻撃者がバックアップやログを消去する手口に触れられています(令和7年上半期 サイバー空間をめぐる脅威の情勢等について)。「バックアップがある」ことと「攻撃されても残るバックアップがある」ことは、まったく別の話です。
数字で見るランサムウェア被害の現状
警察庁が2026年9月に公表した令和8年上半期の統計では、ランサムウェア被害の深刻さが改めて示されています。
| 項目 | 令和8年(2026年)上半期 |
|---|---|
| ランサムウェア被害の報告件数 | 123件(半期として統計開始以降最多) |
| 被害に占める中小企業の割合 | 約6割 |
| 復旧に総額1,000万円以上を要した組織 | 約6割 |
| 1か月未満で復旧できた組織 | 5割弱にとどまる |
| 侵入経路 | VPN機器が約5割 |
被害は大企業に限らず、中小企業にも広がっています。また、1か月未満で復旧できた組織は半数に届いていません。「攻撃を完全に防ぐ」ことは難しい前提で、「やられても戻せる」状態を作っておくことが、BCPの観点では欠かせません。
BCPに必要な「もう一つの保管場所」の5つの条件
バックアップの基本としてよく知られているのが「3-2-1ルール」です。近年はランサムウェアを想定して、これを拡張した「3-2-1-1-0ルール」も広く紹介されています。
| 数字 | 意味 |
|---|---|
| 3 | データのコピーを3つ持つ(本番+バックアップ2つ) |
| 2 | 2種類以上の異なる媒体・ストレージに保存する |
| 1 | うち1つは別の場所(オフサイト)に置く |
| 1 | うち1つはオフライン、または変更できない(イミュータブル)状態にする |
| 0 | 復元テストでエラーがゼロであることを確認する |
このルールを踏まえ、「もう一つの保管場所」に求められる条件を5つに整理します。
条件1:本番と「管理の系統」を分ける
場所が離れていても、本番と同じアカウントや管理者権限で消せてしまうなら、攻撃に対しては同じ場所にあるのと変わりません。別アカウント・別の認証情報・別の管理者で運用し、本番環境の侵害がバックアップ側に波及しない構成にします。必要に応じて、別リージョンや別事業者に置くことも選択肢です。
条件2:書き換え・削除ができない状態にする
オブジェクトロックなどのイミュータブル(変更不可)ストレージ、ネットワークから切り離したオフライン媒体、通常時は接続しないエアギャップ構成などで、「保持期間中は管理者でも消せない」コピーを最低1つ確保します。
条件3:十分な世代と保持期間を持つ
ランサムウェアは侵入から暗号化まで時間をかけることがあり、その間に取ったバックアップには、すでに不正な変更やマルウェアが含まれている可能性があります。直近の数世代だけでなく、週次・月次など長めの世代も残し、「感染前のきれいな時点」まで戻れるようにしておきます。
条件4:地理的にも離す
ランサムウェアだけでなく、地震・水害・広域停電といった自然災害にも備えるなら、本番とは災害リスクの異なる地域に保管先を置くことが有効です。サイバー攻撃と自然災害の両方に通用するBCPになります。
条件5:「戻せる」ことを定期的に確かめる
バックアップは、戻せて初めて意味があります。目標復旧時間(RTO)と目標復旧時点(RPO)を決め、実際にリストアして業務が再開できるか、手順書どおりに担当者が動けるかを定期的に確認します。復旧先のサーバーやネットワーク(IPアドレス、DNSなど)をどう用意するかまで決めておくと、有事に慌てずに済みます。
| 条件 | 守れるもの | 具体例 |
|---|---|---|
| 管理の系統を分ける | アカウント侵害の波及 | 別アカウント・別認証・別事業者/別リージョン |
| 変更不可にする | バックアップの暗号化・削除 | イミュータブルストレージ、オフライン媒体 |
| 世代と保持期間 | 潜伏期間中の汚染 | 日次+週次・月次の長期世代 |
| 地理的に離す | 自然災害・広域障害 | 災害リスクの異なる地域に保管 |
| 復元テスト | 「戻せない」事態 | RTO/RPOの設定、定期的なリストア訓練 |
今日から確認できるチェックリスト
自社の状況を、次の項目で点検してみてください。1つでも「わからない」があれば、見直しのタイミングです。
- 重要なシステムのデータについて、本番環境の外にバックアップがあるか
- そのバックアップは、本番と別の認証情報・別の管理者で守られているか
- 削除・書き換えできないコピーが最低1つあるか
- 何世代・何日分さかのぼれるか把握しているか
- 利用中のクラウドの規約で、事業者が保全する範囲を確認したか
- 直近1年以内に、実際にリストアするテストをしたか
- RTO・RPOが決まっていて、経営層と合意できているか
- 有事の連絡体制と復旧手順書があり、担当者が把握しているか
よくある疑問
Q. スナップショットを取っていれば十分ですか?
スナップショットは、誤操作やアップデート失敗から素早く戻すには便利です。ただし本番と同じ基盤・同じ権限で管理されている場合が多く、基盤そのものが攻撃や障害を受けると一緒に使えなくなるおそれがあります。スナップショットとは別に、管理の系統を分けたバックアップを持つのが安全です。
Q. 別リージョンへのレプリケーションがあれば安心ですか?
リアルタイムに近い複製は、データセンター単位の障害には有効です。一方で、暗号化や削除も短時間で複製先に反映されるため、ランサムウェア対策としては不十分です。レプリケーション(すぐ切り替える)とバックアップ(過去に戻る)を組み合わせるのが基本です。
Q. 中小企業でもここまで必要ですか?
統計上、ランサムウェア被害の約6割は中小企業です。すべてを一度に整える必要はありませんが、まずは止まると事業が続かないシステムを特定し、そのデータから「本番外・変更不可・復元テスト済み」の状態にしていくことをおすすめします。
まとめ
今回のクラウド障害は、「クラウドの冗長性は、データの保全を保証しない」ことをはっきり示しました。ランサムウェアの被害は年々増えており、攻撃を完全に防ぐことは困難です。だからこそ、本番環境とは管理の系統も場所も切り離された「もう一つの保管場所」を持ち、そこから実際に戻せることを確かめておくことが、BCPの土台になります。
まずは上のチェックリストで、自社のバックアップが「攻撃されても残るか」「本当に戻せるか」を確認するところから始めてみてください。
