カテゴリー別アーカイブ: ガイダンス

クラウドサービスにおけるバックアップの責任分担と復旧可能性　～　IDCフロンティアのセキュリティ事故とAWSの契約条件を踏まえた考察

コメントをどうぞ

2026年10月11日
ガイダンスWGリーダー　諸角昌宏

背景

2026年10月、IDCフロンティアが提供するクラウドサービス「IDCFクラウド」において、ランサムウェアによる被害が発生し、一部の顧客の仮想マシンやデータの利用に影響が生じた。この事故は、クラウドサービスにおけるデータ保護やバックアップのあり方、特にクラウドサービスプロバイダ（CSP）とクラウドサービスカスタマ（CSC）の責任分担について、改めて考える契機となる。

クラウドサービスでは、一般に責任共有モデルに基づき、CSPとCSCがそれぞれの責任を負う。しかし、バックアップについては、「クラウドに保存したデータはCSCが自らバックアップしなければならない」という理解がある一方、CSPがバックアップ機能を提供し、その取得・保存・復元処理を実施するサービスも存在する。このため、CSPが提供するバックアップ機能を利用している場合にも、CSCが独立したバックアップを取得する必要があるのか、また、バックアップの取得・保存・復元に関して、CSPとCSCはそれぞれどのような責任を負うのかという点を整理する必要がある。

本ブログでは、IDCフロンティアの事故を検討の契機として、ISO/IEC 27017における責任分担の考え方、IDCフロンティアおよびAWSの公開資料、データ耐久性とバックアップの違いなどを整理し、CSCがバックアップをどのように確保すべきかを考察する。

なお、本ブログは、IDCフロンティアの事故原因、同社のセキュリティ対策の適否、契約違反の有無、法的責任の所在を判断するものではない。事故に関する記述は公開情報に基づくものであり、今後の調査結果によって変更される可能性がある。

注）本ブログでは、ISO/IEC 27017で用いられている用語に従い、クラウドサービスプロバイダを「CSP（Cloud Service Provider）」、クラウドサービスカスタマを「CSC（Cloud Service Customer）」と表記する。なお、契約条件や公表資料からの引用については、原文の表記を維持する。

要旨

CSCが、必ず自らバックアップを取得しなければならないとは言い切れない。CSCは必要なデータ保護要件を定義し、それが満たされるように確保・確認する責任を負う。一方、バックアップ取得・保持・復元の実行は、契約と設定に応じてCSPが担い得る。IDCフロンティアの事故では、複数ゾーンの顧客データの取り出し・復元が困難とされた点が重大であるが、独立した有料バックアップサービスの保存データが失われたか、契約どおりに復元できたかは現時点では未確定である。

1．基本概念：責任と作業の区別

「CSCにバックアップ確保責任がある」ことは「CSCが独自の別システムを構築してバックアップを実行する義務がある」ことと同義ではない。また、CSPにバックアップ処理を委ねても、CSCによる要件定義・契約評価・設定確認の責任が当然に消滅するわけではない。整理すると以下の表になる。

区分意味典型的な担当
要求事項の定義・確保責任保護対象、RPO、RTO、保存期間、攻撃耐性を定め、充足を確認CSC
取得・保存の実施責任設定された計画に基づきバックアップを取得・保持契約・サービス仕様に応じてCSPまたはCSCが実施
バックアップの保護責任削除・改ざん・権限侵害からの保護契約・サービス仕様に応じてCSPとCSCが分担
復旧と検証復元手順、定期試験、代替環境への復旧契約・設定による分担

2.　ISO/IEC 27017の要件

ISO/IEC 27017では、CSCに対して以下の2点を要求している（なお、ここの記述はISO/IEC 27017の手引きの記載内容を意訳したものである）：

  1. CSPがバックアップ機能を提供している場合、CSCはその仕様を要求することが望ましい。CSCはその仕様が自らの要求事項を満たすことを検証する。
  2. CSPのバックアップ機能がCSCの要求事項を満たさない場合、CSCがバックアップ機能の導入に責任を負う。

これらはCSPによるバックアップ機能の提供を想定し、機能が提供されないあるいは機能が要求事項を満たさない場合のCSCの責任を明確化している。一方、「CSPが機能を提供すればCSPが全責任を負う」と結論することはできない。機能の有無、実際の有効化・取得、保存・復元条件、契約上の役割分担を確認する必要がある。

3．クラウドバックアップの技術要件

クラウドバックアップの技術的な要件は以下のようになる。

観点検証ポイント
保護対象仮想ディスクだけでなく、アプリケーション、データベース、設定、鍵、復元に必要なメタデータを含んでいるか
独立性本番とは別の障害領域、管理権限、可能なら別アカウント・別拠点に分離されているか
耐改ざん性イミュータブル保管、削除防止、保持期間、特権ID侵害時の防御があるか
復旧可能性実際に復元できるか、整合性・RPO・RTOを満たすか、定期試験があるか
責任と透明性バックアップ機能の仕様、除外範囲、前提設定、障害時の制約がCSCに明示されているか

したがって、スナップショットは迅速な復旧に有効だが、管理基盤の侵害から独立していなければ、ランサムウェアに対する十分な復旧手段とは限らない。保存先の物理的分離と、削除・改ざん権限の分離は別の要件である。

4．IDCフロンティアの公開仕様・契約条件

IDCフロンティアの公開情報には、標準IaaSで顧客の責任の下にバックアップ等を行う旨のサービス提供条件がある。また、スナップショット機能と、別拠点のストレージを利用する「IDCFクラウド バックアップ」を区別して提供している。公開FAQでは、スナップショットにはランサムウェア対策がない一方、バックアップサービスにはイミュータブルストレージがあると説明している。

このため、標準IaaSでの顧客のバックアップ確保責任は確認できるが、バックアップサービスを別途契約・設定していた顧客に対するCSPの個別の履行責任は、サービス仕様書・約款・個別契約を併せて検討しなければならない。

なお、IDCフロンティアの契約には、顧客データの消失などによる損害について、同社が賠償責任を負わない旨の免責条項がある。しかし、免責条項が存在するからといって、すべての事故について同社が責任を免れるとは限らない。実際に免責が認められるかどうかは、事故原因、同社の過失の有無や程度、適用される契約条件などによって判断される。特に、故意または重大な過失があった場合には、免責条項の効力が制限される可能性がある。

5．AWSの契約・サービスとの比較

AWS Customer Agreement 第2.3条（Your Security and Backup）は、顧客がサービスを適切に設定・利用し、アカウントと顧客コンテンツの保護・バックアップのため適切な措置を講じる責任を定めている。AWS Backupでは顧客がバックアップ計画・対象等を設定し、AWSがマネージドサービスとして取得・保存・復元機能を提供する。Vault Lock、クロスアカウント・クロスリージョンコピー、復元テスト等の機能もある。

論点IDCフロンティアAWS
標準IaaSのバックアップ確保責任原則として顧客原則として顧客
CSP提供のバックアップスナップショット、別拠点バックアップEBSスナップショット、AWS Backup等
保護機能別拠点・イミュータブル機能（サービス別）Vault Lock等（構成・サービス別）
CSPのサービス履行責任個別仕様・約款の検証が必要契約・サービス条件の検証が必要

AWSであっても顧客による適切な設定や復元試験は重要であり、AWSの機能があること自体は、いかなる事故でもデータが失われないという保証ではない。

6．IDCフロンティア事故：確認事項と未解明事項

公開情報から確認されている事項

2026年10月のランサムウェア事故に関し、IDCフロンティアは、東日本リージョン1の4ゾーンで仮想サーバーに障害が発生し、当該環境に保存されたCSCのデータの取り出し・復元が困難との見通しを示した。また、CSCが保持するバックアップから、別環境へ復元するよう案内した。

本事象は、単なるサービス停止にとどまらず、本番環境からのデータ回収や復旧が困難となり、CSCの事業継続やデータ保護に重大な影響を及ぼし得ることを示している。ただし、この事実のみをもって、CSPの契約上の義務違反やバックアップサービスの不備を断定することはできない。

未解明であり、断定してはならない事項

未解明の論点評価に必要な証拠
4ゾーンに被害が及んだ経路侵入経路、共通管理プレーン、特権ID、ゾーン間の権限・障害分離
スナップショットの被害実際の削除・暗号化・メタデータ破壊の有無と範囲
別拠点バックアップの健全性バックアップデータの保存状況、保護設定、復元ログ
有料バックアップ利用顧客の復元実績契約・設定状況、RPO/RTO、復元成功率・所要時間
責任分担と契約履行事故当時の適用約款、サービス仕様書、個別契約、保証・免責条件

なお、攻撃者が主張した破壊件数や容量は、事業者が裏付けた確定事実とは扱わない。また、4ゾーンに影響が出たことだけから、テナント分離の破綻やバックアップ基盤の共通障害を断定することはできない。

まとめ

  1. 「CSCは自らバックアップを取得しなければならない」との一律の表現は不正確である。
  2. 「CSCが必要なバックアップを確保・確認する責任を負う」は一般的なIaaS契約と整合する。
  3. CSPが提供するバックアップ機能がCSCの要求事項を満たし、適切に契約・設定され、バックアップの取得・保存・復元が可能であれば、CSCが別途、独立したバックアップを取得することは必ずしも必要ではない。
  4. この場合、CSCは必要なバックアップの要件を定め、実際に復元できることを確認する責任を負い、CSPは契約に従ってバックアップサービスを提供する責任を負う。また、CSPには、バックアップサービスの提供に加えて、クラウド基盤そのものを適切に保護する責任もある。

IDCフロンティアについては、4ゾーンの本番データが復元困難となったこと自体が重大である。一方、CSPが提供した独立バックアップが契約どおり機能しなかったと断定するには、バックアップ利用顧客の復元実績と事故時点の適用契約の確認が不可欠である。

8．クラウドサービスカスタマへのバックアップ推奨事項

基本原則：CSPのバックアップ機能がCSCの要求事項を満たし、適切に契約・設定され、必要なバックアップが実際に取得・保持され、復元可能であることが検証されているなら、CSCが独立したバックアップを必ず追加する必要はない。これは「独立したバックアップは不要」という一般論ではなく、リスク評価に基づく条件付きの判断である。

CSCは、バックアップ処理を自ら実施することと、必要なデータ保護・復旧能力を確保する責任を区別する。CSPに実施を委ねる場合でも、要件定義、契約・設定確認、復元可能性の検証は必要である。

推奨する確認事項

以下の確認事項は、CSCが独立したバックアップを取得することを前提とするものではなく、CSPが提供するバックアップ機能によってCSCの要求事項を満たせるかを確認するためのものである。要求事項が満たされ、残余リスクも許容できる場合には、CSCが独立したバックアップを追加することは必須ではない。

  • 保護対象：仮想マシン、ディスク、データベース、設定、暗号鍵、認証情報など、復旧に必要な要素を漏れなく特定する。
  • 復旧目標：許容データ損失（RPO）、目標復旧時間（RTO）、保存期間、世代数、データ整合性を明確にする。
  • 契約・仕様：CSPが取得・保持・保護・復元のどこまでを担うか、除外事項、SLA、免責、障害時の支援を確認する。
  • 設定・運用：バックアップ対象の割当て、スケジュール、保持設定、失敗通知、アクセス権限を点検する。
  • 攻撃耐性：本番環境との管理権限の分離、削除・改ざん防止（イミュータビリティ）、別拠点・別アカウント等の必要性をリスクに応じて評価する。
  • 復元検証：バックアップの存在確認だけでなく、定期的な復元試験でデータ整合性、復元時間、代替環境への復旧を検証する。
  • 残余リスク：CSPの管理基盤への不正アクセス、リージョン全体の障害、契約終了時のデータ移行、特定事業者への依存などのリスクを評価する。その結果、CSPが提供するバックアップ機能だけではCSCの要求事項を満たせない場合や、追加の保護が必要と判断される場合には、CSPから独立したバックアップの導入を検討する。

独立した追加バックアップの要否を判断する基準

追加が必須とは限らない例：CSP提供機能で必要なRPO・RTO、保持、改ざん防止、管理権限分離、復元試験が満たされ、想定脅威に対する残余リスクを組織が受容できる場合。

追加を検討すべき例：CSP提供機能が本番環境と同じ侵害経路に依存する場合、復元試験ができない場合、リージョン全体の喪失やCSP管理基盤の侵害を想定する場合、法令・契約上の独立保管要件がある場合。

IDCフロンティア事故への適用：標準IaaSのバックアップ確保責任と、契約済みバックアップサービスの履行責任を分けて評価する。バックアップサービス利用顧客の復元実績、保存データの健全性、管理権限分離が未公表である限り、サービス自体の失敗も成功も断定しない。

参考：AWS Backupの公式資料では、クラウドサービスカスタマがバックアップ計画と対象リソースを適切に設定し、定期的に復元可能性を検証する責任を負うことが明記されている。一方、バックアップの取得・保持や復元テストの実行については、AWS Backupの自動化機能を利用できる。したがって、カスタマがすべてのバックアップ処理や復元テストを自ら実施する必要はない。ただし、バックアップの対象、保持期間、復旧目標、復元結果などが組織の要求事項を満たしていることを確認する責任はカスタマに残る。
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/rel_backing_up_data_secured_backups_data.html

9．データ耐久性（11ナイン）とバックアップの関係

AWSがAmazon S3 Standardについて公表する99.999999999%（イレブンナイン）は、年間のオブジェクト耐久性に関する設計上の数値である。これはサービスの可用性、バックアップの取得状況、過去の正常な状態への復元可能性、または損害賠償を保証する数値ではない。

耐久性は、保存済みデータがストレージ障害等によって失われにくい性質を指している。一方、バックアップは、誤削除、論理的な破損、悪意ある変更、ランサムウェア攻撃などを想定し、必要な過去時点のデータを保持して復元するための手段である。複数のアベイラビリティゾーン（AZ）にデータを分散して保存していても、誤削除やランサムウェア攻撃によって変更されたデータが他のAZにも反映される場合がある。そのため、複数AZへの冗長配置だけでは、障害や攻撃が発生する前の正常なデータに復元できるとは限らない。

CSCへの推奨事項

CSCは、CSPが公表する耐久性の数値のみを根拠に、バックアップが不要と判断してはならない。データの重要度、誤削除・改ざん・管理権限侵害・リージョン障害等の想定事象、必要な保存世代、RPO・RTOを定義し、提供されるバックアップ機能の保護範囲と復元手段を評価する必要がある。

一方、CSPのバックアップ機能がCSCの要求事項を満たし、適切に契約・設定され、バックアップが実際に取得・保持され、想定する障害・攻撃に対して復元可能であることを検証できる場合、CSCがCSPとは独立したバックアップを必ず追加する必要はない。追加バックアップの要否は、共通管理権限への依存、削除・改ざん耐性、別アカウント・別リージョンでの保管、復元試験の結果、リスク許容度に応じて判断する。

IDCフロンティア事故との関係

今回の事故の評価では、ストレージの耐久性に関する数値と、侵害後に正常なバックアップから復元できるかを混同すべきではない。重要なのは、各バックアップ方式が本番環境や管理プレーンの侵害からどの程度独立し、契約・仕様に沿って復元可能だったかである。事故におけるバックアップデータの実際の被害範囲と復元実績は、公開情報だけでは確定できない。

免責事項

本ブログは、公開時点で入手可能な公表資料、契約条件、技術文書および関連規格に基づき、クラウドサービスにおけるバックアップの責任分担とデータ保護の考え方を整理したものである。

特定のクラウドサービスプロバイダの事故原因、セキュリティ対策の適否、契約違反の有無、法的責任の所在などについて、断定的な評価を行うことを目的とするものではない。

本ブログに記載した事実関係は公開時点の情報に基づいており、今後の調査結果や新たな情報の公表によって変更される可能性がある。また、ISO/IEC規格や各種ガイドラインに関する記述は、筆者による解釈・考察を含むものであり、規格制定機関等の公式見解を示すものではない。

本ブログは一般的な技術情報および制度上の考察を提供するものであり、個別の契約に関する法的助言や、特定のシステムに対するセキュリティ対策の有効性を保証するものではない。具体的な判断にあたっては、適用される契約条件、サービス仕様および組織の要求事項を確認し、必要に応じて専門家に相談すること。

参考資料

以上