【クラウド法務】Azure Backupは“取っていれば安心”ではない理由― Azure Backup SLA／BCP／データ保護の「技術と責任」を先に揃えないと、監査・取引先説明で詰まる ―

────────────────────────────

はじめに

────────────────────────────

Azure Backupを導入すると、「バックアップは取れている」という安心感が生まれます。実際、設定も分かりやすく、日次・週次のポリシーを作って対象リソースを保護すれば、ダッシュボード上は“守れている”ように見えます。しかし、全国の情シス・IT部門の方から相談を受けていると、よく出てくるのが次の声です。

「バックアップは成功しているのに、いざという時に復旧が間に合わない」「監査で“保持期間と証跡”を求められ、説明資料が作れない」「委託先とMicrosoftと自社の責任が曖昧で、事故時の指揮命令が割れる」

本記事では、「Azure Backupを入れた＝安心」にならない理由を、技術の整理から入り、法務・契約（責任分界／説明責任／証跡）の観点で“実務として崩れない整理方法”をまとめます。

────────────────────────────

1. Azure Backupの“事実整理”（技術構成の全体像）────────────────────────────

まずは「何が起きているか」を、技術として整理します。Azure Backupは、バックアップ対象（VM、ファイル、各種ワークロード等）から取得した復旧ポイントを、ポリシーに基づいてバックアップ保管領域（Vault等）に保存し、必要時に復旧できるようにする仕組みです。

多くの企業での典型構成（テキスト図）

【本番リソース（Azure）】・仮想マシン（業務アプリ）・ディスク／ファイル共有・（必要に応じて）ワークロード系のバックアップ構成　　↓（バックアップ拡張／エージェント／ポリシー）【バックアップ保管（Vault）】・日次／週次／月次などの保持ポリシー・保管の冗長化（同一リージョン内／リージョン冗長など、選択肢がある）・削除保護や保護機能（設定により）　　↓【運用】・失敗アラート、レポート・監視基盤（ログ集約、SIEM等）・運用委託（MSP/SOC）が入るケースも多い

重要なのは、Azure Backupは“バックアップの仕組み”であって、次を自動で完成させるものではない点です。

・業務が止まったときに、どの順番で、どれだけの時間で復旧するか（RTO）・どこまでのデータ損失を許容するか（RPO）・復旧が成功することを、誰が、どの頻度でテストし、証跡として残すか・事故時に誰が指揮し、取引先・監査へ何を根拠に説明するか

ここまでは技術の話。ここからが法務・責任の話です。

────────────────────────────

2. Azure Backupで起きがちな「法務・責任」の落とし穴3選────────────────────────────

Azure Backupは“導入しやすい”ぶん、次のズレが起きやすいです。技術的にはOKでも、説明責任としてNGになりやすい3点を挙げます。

────────────────────────────

落とし穴①：バックアップの成功＝復旧の成功ではない（RPO/RTOが未定義）────────────────────────────

技術的にはOK・バックアップジョブは成功している・復旧ポイントも並んでいる・ダッシュボードは緑

法務・実務的にはNGになりやすい・取引先SLAやBCP上の要求は「何時間で復旧するか」「どこまで戻せるか」・しかし実際には　- 復旧手順が未整備（誰が、どの手順で、どこに戻すか）　- アプリ整合性（DB、キュー、ファイルの順序）を考えていない　- 復旧テストをしていない（成功率が不明）　- 復旧に必要な権限・鍵・ネットワークが揃っていないという状態になりがちです。

結果として「バックアップは取っていたのに、復旧に間に合わない」→ 事故後に“説明不能”になります。

────────────────────────────

落とし穴②：保持期間・削除・保全（リーガルホールド相当）が曖昧で監査に刺さる────────────────────────────

技術的にはOK・保持期間は「とりあえず30日」「とりあえず90日」で設定・コストも抑えられている

法務・監査的にはNGになりやすい・業界要件や契約で「1年〜数年」の証跡保持が必要なことがある・事故・紛争・内部不正の調査では、「当時の状態」を“消さずに保全”する必要が出る・ところが、バックアップは　- 期限で自動削除される- 権限を持つ人（または侵害者）が削除できてしまう- “保全する手順”が決まっていないという状態が残りやすいです。

結果として「必要な期間が残っていない」「保全できない」→ 監査・取引先照会で説明が崩れます。

────────────────────────────

落とし穴③：Microsoft／委託先／自社の責任分界が曖昧で、事故対応が割れる────────────────────────────

技術的にはOK・運用委託（MSP/SOC）が入っている・“監視もしているし大丈夫”という雰囲気

法務・実務的にはNGになりやすい・Azure BackupのSLAやサービス提供範囲が「復旧の完遂」を保証するものではないケースが多い（保証の主語がズレる）・委託先は「監視はするが、復旧作業は別契約」「ログ提出は別メニュー」になっていることがある・社内では「Microsoftが何とかする」「委託先が何とかする」という誤解が混在し、事故時に指揮命令系統が崩れる

結果として・復旧の意思決定が遅れる・取引先・親会社への説明が割れる・“誰が責任者か”の議論が先に始まり、復旧が後回しになる→ これが一番ダメージが大きいです。

────────────────────────────

3. “取っていれば安心”にしないための整理フレーム（3つの軸）────────────────────────────

Azure Backupを安全側に倒すには、技術の細部に入る前に、最低限次の3軸を紙に落とすと崩れません。

────────────────────────────

整理軸①：復旧要件（RPO/RTO）と優先順位を「業務の言葉」で確定する────────────────────────────

バックアップ設計の出発点は、設定画面ではなく業務要件です。

最低限決めること・対象システムごとのRTO（何時間で復旧すべきか）・対象システムごとのRPO（どこまで戻れればよいか）・復旧優先順位（どれから戻すか）・依存関係（ID基盤、DNS、ネットワーク、鍵管理、監視など）

ポイント・RTO/RPOは「情シスの希望」ではなく、取引先SLA・BCP・事業継続要件とセットで決める・“復旧できる”は、手順と権限とテストが揃って初めて言える

成果物（最小）・バックアップ対象一覧（重要度・優先度・RTO/RPO）・復旧手順書（誰が、どの順番で、どこへ復旧するか）・復旧テスト計画と実施記録（証跡）

────────────────────────────

整理軸②：バックアップデータのガバナンス（保持・削除・保全・権限）────────────────────────────

“バックアップ”は、実は最重要データの塊です。ここが弱いと、事故時に最後の砦が壊れます。

最低限決めること・保持期間（契約・規制・監査要件と整合）・削除権限（誰が削除できるか、削除手順、二重承認の要否）・保全（リーガルホールド相当）の運用（削除停止、凍結、隔離、保全指示のルート）・暗号化・鍵管理（鍵の責任者、退職時の引継ぎ、委託先が触れる範囲）・バックアップが侵害される前提の対策（特権分離、MFA、運用分離）

成果物（最小）・保持／削除／保全の運用ルール・特権アクセス（削除・設定変更）の統制ルール・監査で出す証跡（誰がいつ削除・変更したか等）の一覧

────────────────────────────

整理軸③：責任分界（Microsoft／自社／委託先）を“事故対応タスク”で固定する────────────────────────────

「誰の責任か」をレイヤーで議論すると揉めます。事故対応で必要な“タスク”に分解して決めるのが実務的です。

最低限決めるタスク・バックアップポリシー設計（頻度、保持、対象）・監視（失敗検知、アラート）・復旧（実行担当、承認者、切戻し判断）・ログ・証跡提出（監査・取引先照会に出す責任）・保全（削除停止、隔離、抽出者記録）・委託先が絡む場合の再委託（国外含む）と監督責任

委託先がいるなら、契約で固めるべき最低ライン・一次通知（検知から何分以内、どのチャネル）・復旧支援の範囲（どこまでやる／やらない）・ログ提出義務（期限・形式・保全協力）・特権アクセス（削除・設定変更）の統制（期限、承認、操作ログ）

────────────────────────────

4. ケーススタディ（匿名化）：製造業A社の「バックアップはあるのに復旧できない」────────────────────────────

実際に近い形で起きがちな例です（匿名化しています）。

・業種：製造業・拠点：国内＋海外・構成：Azure上に業務システム（VM＋ストレージ）、運用は一部委託・導入：Azure Backupで日次バックアップを取得（ジョブは成功）

事故（想定）・ランサムウェア/誤操作/障害のいずれかで業務停止・復旧しようとしたが、次で詰まる　- 復旧の順序が決まっていない（DB、アプリ、ファイルの整合）- 復旧に必要な権限が委託先側にあり、夜間に動けない- 保持期間が短く「必要な時点」が残っていない- 取引先に「復旧見込み」を説明する根拠（手順・テスト記録）がない

整理して改善したこと（実務）・システムごとにRTO/RPOと優先順位を確定・復旧手順を作り、定期的に復旧テストを実施して証跡化・バックアップ削除・変更の特権を分離し、二重承認と記録を導入・委託契約に「復旧支援」「ログ提出」「保全協力」を明記・監査用の“証跡パック”（復旧テスト記録、設定変更記録等）を定義

結果として「バックアップはある」から一段進んで、「復旧できることを説明できる」状態に近づきました。

────────────────────────────5. Azure Backupを導入済み企業が、今すぐ確認しておきたいチェックリスト────────────────────────────

□ バックアップ対象ごとにRTO/RPOと復旧優先順位が決まっている

□ 復旧手順書があり、担当者・承認者・切戻し判断が決まっている

□ 復旧テストを定期的に実施し、成功/失敗の記録（証跡）が残っている

□ 保持期間が、契約・監査・規制要件と整合している

□ 事故時にバックアップを“保全”する手順（削除停止・隔離）がある

□ バックアップの削除・ポリシー変更の権限は分離され、操作ログが残る

□ 委託先が絡む場合、復旧支援の範囲とログ提出義務が契約で決まっている

□ 取引先から「BCP」「データ保護」「SLA」を聞かれても、根拠資料で説明できる

「すべて自信を持ってYESと言える企業は、全国的に見てもまだ多くありません。」

────────────────────────────

6. 全国からのご相談について

────────────────────────────

山崎行政書士事務所では、Azure Backup／BCP／データ保護の技術構成と、契約・規程・監査対応をセットで整理する「クラウド法務支援」を行っています。

・Azure Backupを入れたが、RTO/RPOと復旧手順が社内説明できていない・運用委託先との責任分界（復旧・ログ提出・保全協力）を固めたい・監査・取引先照会に耐える“証跡パック”を作りたい・バックアップ削除・例外運用・特権アクセスの統制を整えたい

といったお悩みがあれば、オンライン（全国対応）にて初回のご相談を承っております。お問い合わせの際に「Azure Backupの記事を見た」と書いていただけるとスムーズです。

────────────────────────────

※本記事は一般的な情報提供です。実際の設計・責任分界は、対象サービス、冗長化構成、委託範囲、取引先要件により変わります。────────────────────────────