【2026年最新】SaaSデータ保護における責任共有モデルとは？企業とクラウド事業者の責任範囲を解
責任共有モデル（Shared Responsibility Model）とは、クラウドサービスのセキュリティとデータ保護に関する責任を、クラウドサービスプロバイダー（CSP）と利用企業の間で明確に分担する運用フレームワークです。
Microsoft 365などのSaaS環境において、Microsoftは物理データセンター、ネットワーク、ホスト、OSといったインフラ基盤（Security of the Cloud）を管理します。一方で、自社データ、ユーザーID、アカウント権限、セキュリティ設定（Security in the Cloud）の管理責任はすべて利用企業側に残ります。
重要ポイント:
「SaaSにデータを移行した＝自社データの保護と復旧に関するすべての責任をMicrosoftへ移転できる」という認識は誤りです。サービスの可用性（SLA）保証と、個別データの復元保証はまったく別の課題です。
クラウド環境における責任分担（オンプレミスからSaaSまで）
管理レイヤーが上がるにつれてクラウド事業者の管理範囲は広がりますが、最上位に位置する「顧客データ」の所有権と保護責任は一貫して利用企業にあります。
クラウド環境における責任分担
| 管理項目 | オンプレミス | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| 顧客データ | 利用企業 | 利用企業 | 利用企業 | 利用企業 |
| ID・ユーザー | 利用企業 | 利用企業 | 利用企業 | 利用企業 |
| 設定 | 利用企業 | 利用企業 | 利用企業 | 利用企業 |
| クライアント端末 | 利用企業 | 利用企業 | 利用企業 | 共有 |
| アプリケーション | 利用企業 | 利用企業 | 共有 | 共有 |
| ネットワーク制御 | 利用企業 | 利用企業 | 共有 | CSP |
| OS | 利用企業 | 利用企業 | CSP | CSP |
| 物理ホスト | 利用企業 | CSP | CSP | CSP |
| 物理ネットワーク | 利用企業 | CSP | CSP | CSP |
| データセンター | 利用企業 | CSP | CSP | CSP |
ポイント：SaaSになっても「顧客データ」の責任がなくなるわけではありません。
「Security of the Cloud」と「Security in the Cloud」の違い
責任共有モデルを実務に落とし込む際は、以下の2つの領域を分離して設計する必要があります。
- Security of the Cloud（クラウド自体の安全管理）:
クラウド事業者が担う領域。物理データセンターのセキュリティ、ハードウェア障害耐性、OSやハイパーバイザーの脆弱性修正、インフラの継続的稼働（SLA）が含まれます。 - Security in the Cloud（クラウド内データの安全管理）:
利用企業が担う領域。アクセス権限管理（MFA導入含む）、データ分類、コンプライアンス要件に沿った保持期間の設定、そしてランサムウェアや人為的ミスに備えたデータバックアップと復旧手続が含まれます。
SaaS標準機能と専用バックアップの違い
Microsoft 365には「ゴミ箱」「バージョン履歴」「保持ポリシー」「Microsoft 365 Backup」などの標準復元機能が用意されていますが、サードパーティ製バックアップとは設計思想が異なります。
| 比較項目 | SaaS標準の復元・保持機能 | 専用SaaSバックアップ (Barracuda CCB) |
|---|---|---|
| 主目的 | サービス内での短期データ一時保持・改ざん防止 | 本番環境から独立したバックアップと迅速な復旧 |
| データ保存場所 | 本番SaaSサービス内（同一テナント/同一信頼境界） | 完全分離された独立クラウド環境（エアギャップ） |
| 保持期間 | 14〜93日（ゴミ箱）/ 1年（M365 Backup） | ポリシーに応じた柔軟な設定・無制限保持が可能 |
| 個別データ復元 | 検索や柔軟な復元に権限設定や複雑な手順が必要 | 直感的なUIからファイル単位・ポイントインタイム復元 |
| ランサムウェア復旧 | 同期型攻撃や管理者権限奪取時に制限あり | イミュータブル（不可変）データとして安全に保持 |
SaaSでデータ損失が発生する4つの代表的な原因
- ユーザーによる誤削除:
単一ファイルの誤消去だけでなく、同期設定ミスや退職者アカウント削除に伴う一括データ損失。 - 退職者・オフボーディングの処理漏れ:
アカウント削除後に過去のメールやOneDrive上の業務ファイルが必要となるケース。 - 内部不正・アカウント侵害:
管理者権限（Microsoft Entra ID）や特権アカウントが乗っ取られ、ゴミ箱を含めてデータが意図的に一括消去されるリスク。 - ランサムウェア攻撃:
ローカル端末で暗号化されたファイルがそのままクラウドストレージへ同期・上書きされるインシデント。
SaaSバックアップ選定で確認すべき5つの基準
- RPO (目標復旧時点): どの時点（何時間前・何日前）のデータまで戻す必要があるか。
- RTO (目標復旧時間): API制限などを考慮し、障害発生から何時間以内に業務再開できるか。
- 保持期間: 業界の法規制やコンプライアンス要件（数年間〜無制限）を満たせるか。
- バックアップデータの保護: イミュータブル（書き換え不能）化、MFA、暗号化により、バックアップ自体が攻撃されないか。
- TCO (総保有コスト): 容量課金（従量制）かユーザーライセンス課金か。データ増加に伴う3〜5年後のコスト変化。
Barracuda Cloud-to-Cloud BackupによるSaaSデータ保護
SaaSの責任共有モデルにおいて、企業側のデータ保護責任を補完するのが Barracuda Cloud-to-Cloud Backup (CCB) です。
- イミュータブルバックアップ:
バックアップデータを改ざん不可の形式で保存し、ランサムウェアや悪意ある管理者権限の乱用から復旧ポイントを保護。 - M365環境からの物理・論理的隔離:
本番環境とは完全に独立したクラウドストレージに保存するため、Microsoft側のインフラ障害やアカウント侵害の影響を受けません。 - ユーザーベースの明確なライセンス構造:
データ容量増加による追加コストが発生しにくいユーザー単位の課金モデルを採用しており、長期的なTCOを低く抑えることが可能です。
SaaSの活用が進む2026年現在、「予防（MFA/アクセス制御）→ 保持（標準ポリシー）→ バックアップ（独立保管）→ 復旧（RTO遵守）」 のサイクルを完結させることが、BCP（事業継続計画）における最優先課題となっています。
よくある質問
SaaSを利用していてもバックアップは必要ですか？
SaaSには標準的な復元・保持機能がありますが、それだけで自社のRPO、RTO、保存期間、コンプライアンス要件を満たせるとは限りません。自社の復旧要件を確認したうえで追加バックアップの必要性を判断することが重要です。
Microsoft 365のデータ保護は誰の責任ですか？
MicrosoftはMicrosoft 365のクラウド基盤を管理しますが、Microsoftの責任共有モデルでは、顧客データ、ID、設定などについて利用企業側にも責任があります。
SaaSバックアップを選ぶ際に重要なポイントは何ですか？
RPO、RTO、保持期間、バックアップデータの保護方法、コストモデルの5つを中心に比較することをおすすめします。
この記事へのコメントはありません。