AI・IT経営ケース 2026-08-27

ランサムウェアは「情報漏えいがなければ軽症」ではない
シーイーシーのデータセンター障害から考える、止まらないためのIT・BCP

今日は木曜日なので、「セキュリティ事故・ITリスク」を扱います。

今回のポイントは、情報漏えいの有無だけでサイバー事故の重さを判断しないことです。企業活動では、システムが止まること自体が売上、受注、出荷、顧客対応、決済、社内業務へ波及します。

実際のケース

シーイーシーは2026年8月6日、東京第二データセンターで8月5日11時頃に不正アクセスに起因する障害が発生したと公表しました。8月6日の時点でサービスは復旧していました。

8月7日の続報では、この障害がランサムウェア攻撃によるものと確認されました。警察への被害報告、個人情報保護委員会への第一報も行われています。この時点では情報漏えいは確認されず、攻撃対象となった領域は、顧客から預かっているシステムやデータとは別領域だったと説明されています。

さらに8月21日の続報では、ランサムウェアの種別と侵入経路を特定し、その経路は遮断済みと発表しました。影響を受けたサービスは別環境によって復旧済みで、新たなサービス停止や二次被害は確認されていません。一方で、攻撃により暗号化された領域のデータ復元やログ解析、フォレンジック調査は継続しています。また、一時的なサービス停止の影響が発生した顧客には個別連絡を完了したとしています。

ここで大事なのは、公開情報上、顧客データの漏えいは確認されていなくても、実際には「サービス停止」という事業影響が発生したことです。

事実として確認できること

8月5日11時頃、東京第二データセンターで不正アクセスに起因する障害が発生
8月6日時点でサービスは復旧
原因はランサムウェア攻撃と確認
攻撃対象領域は、顧客から預かるシステムやデータとは別領域
情報漏えいは現時点で確認されていない
ランサムウェアの種別と侵入経路は特定済みで、当該経路は遮断済み
影響サービスは別環境で復旧
一時的なサービス停止の影響を受けた顧客が存在

現時点で分からないこと

侵入経路の具体的な技術内容は、セキュリティ上の理由から公表されていません。また、停止した顧客数、各顧客の停止時間、売上や損失への金額影響も公表されていません。

そのため、「特定の設定ミスが原因だった」「この脆弱性から侵入した」などと断定することはできません。

ここで考えてみましょう

問1

自社の基幹システムやEC、受発注、会計、顧客管理を預けている外部事業者がランサムウェア被害を受けた場合、情報漏えいが確認されていなければ「大きな問題ではない」と判断してよいでしょうか。最初に確認すべきことは何でしょうか。

問2

バックアップが取れていれば、同じようなサービス停止には十分備えられているでしょうか。実際に業務を再開するために、バックアップ以外に何が必要でしょうか。

解説

問1の答え

「情報漏えいがない＝影響が小さい」とは判断できません。

サイバー事故では、機密性だけでなく「可用性」、つまり業務を続けられるかが重要です。

たとえば受注システムが止まれば、注文を受けられない。倉庫システムが止まれば出荷できない。会計や決済が止まれば請求・入金確認が遅れる。顧客管理が止まれば問い合わせ対応も遅れます。

したがって最初に確認するべきなのは、「データが漏れたか」だけではなく、次の4点です。

どの業務が止まっているか
何時間・何日までなら耐えられるか
代替手段でどこまで継続できるか
復旧後にデータの欠損・二重処理・取りこぼしが起きないか

今回のケースでは、顧客データ領域と攻撃領域が分かれていた点は被害抑制に有効だったと考えられます。一方で、サービス停止そのものは発生しているため、利用企業側から見れば「自社データが無事か」だけでなく、「自社業務が継続できたか」が経営上の評価軸になります。

問2の答え

バックアップだけでは不十分です。

バックアップは「データを戻す」ための備えですが、事業継続では「別の場所でサービスを動かす」準備まで必要です。

今回、シーイーシーは影響を受けたサービスを別環境で復旧したと公表しています。ここが重要です。

実際の復旧には、少なくとも次の準備が必要です。

代替環境を起動できること
最新データを戻せること
アプリケーションや設定を再現できること
ID・認証・権限を復旧できること
外部サービスやAPI、ネットワーク接続を切り替えられること
DNSや証明書などを切り替えられること
復旧後に正しく動いているか確認する手順があること
誰が復旧判断を行うか決まっていること

つまり、バックアップが「保険証券」だとすれば、実際に事業を再開できるかは「復旧訓練」までできているかで決まります。

企業側で見直したいこと

1. RTOを業務ごとに決める

「いつか復旧すればよい」ではなく、受注は4時間、会計は1日、分析システムは3日など、業務ごとに許容停止時間を決めます。

2. RPOを決める

何時間分のデータなら失っても業務を再構築できるかを決めます。日次バックアップだけで足りる業務と、数分単位で失うと困る業務は分けて考える必要があります。

3. ベンダー任せにしない

外部サービスを使っていても、「障害時はどの環境へ切り替わるのか」「復旧目標は何時間か」「自社は何を準備する必要があるか」を確認します。

4. 代替業務を決めておく

システム停止時に、手作業・Excel・電話・別システムなどで最低限どこまで業務を続けるかを事前に決めておきます。

5. 復旧テストを実施する

バックアップが存在することと、実際に戻せることは別です。復元時間、復元後の動作、データ整合性まで確認して初めてBCPになります。

経営上のポイント

このケースから得られる一番大きな示唆は、セキュリティ対策を「情報を盗まれないための対策」だけで捉えないことです。

企業にとって本当に大きな損失になるのは、

攻撃 → システム停止 → 受注・出荷・請求・顧客対応停止 → 売上減少・顧客離反・復旧コスト増加

という連鎖です。

そのため、セキュリティ投資は「侵入を防ぐ」だけでなく、

侵入されても止めない／止まっても短時間で戻す／戻した後に業務を正常化する

ところまで設計する必要があります。

今回の事例では、被害領域の隔離と別環境での復旧が行われています。利用企業側でも、重要システムについて「このサービスが今日止まったら、何時間後から売上や顧客対応に影響が出るか」を一度整理しておくと、BCPの優先順位が見えやすくなります。

参考情報

シーイーシー「当社データセンターサービスの障害発生のお知らせ（第1報）」2026年8月6日
https://www.cec-ltd.co.jp/news/2026/7371.html

シーイーシー「当社データセンターサービスの障害発生のお知らせ（続報）」2026年8月7日
https://www.cec-ltd.co.jp/news/2026/7372.html

シーイーシー「当社データセンターサービスの障害発生のお知らせ（続報）」2026年8月21日
https://www.cec-ltd.co.jp/news/2026/7378.html