第9章 · ProjectVIEW ERP マスターSaaSフレームワーク
事業継続はISO 22301:2019およびNIST SP 800-34に整合しており、データベースのRPOは15分、RTOは4時間、プラットフォーム全体のRTOは8時間、フェイルオーバーは24時間以内にAzureのセカンダリリージョンへ切り替えます。顧客データはジオ冗長ストレージ上に保管され（Azureリージョン2か所に6コピー）、バックアップは整合性テストを実施し、災害復旧訓練は毎月のコンポーネントテストから年1回のセカンダリリージョンへのフェイルオーバーまで実施します。
- 15分データベースRPO
- 4時間 / 8時間データベース / プラットフォーム全体のRTO
- 6コピージオ冗長、Azureリージョン2か所
- 2営業日オンデマンドのデータエクスポート
9.1 概要および目的
本章では、ProviderによるProjectVIEW ERP Platformの提供を規律する事業継続および災害復旧（BCDR）義務を定義します。本章は、バックアップ戦略、レプリケーションアーキテクチャ、フェイルオーバー手順、復旧時間目標、データ冗長化のコミットメント、およびサブスクリプション期間を通じてCustomer Dataの可用性、永続性、復旧可能性を確保する継続計画要件を定めます。
ProviderのBusiness Continuity Management System（BCMS）はISO 22301:2019（Security and Resilience — Business Continuity Management Systems）に整合し、NIST SP 800-34 Rev. 1（Contingency Planning Guide for Federal Information Systems）およびMicrosoft Cloud Enterprise Business Continuity Management（EBCM）Programmeを参照しています。本章は、第3章（Service Level Agreement）で定義された可用性コミットメント、第8章（Information Security & Confidentiality）で説明するインフラセキュリティ管理、ならびに第7章（Data Protection & Privacy）のデータ保護規定を補完します。
各Customer専用のプライベート主権環境には、コンピュート、データベース、ストレージ、ネットワーク各層にわたる多層防御の継続性管理が実装されており、単一障害点によって契約上のRecovery Point Objective（RPO）およびRecovery Time Objective（RTO）を超えるデータ損失や長時間のサービス中断が生じないようにしています。
9.2 範囲
本章が対象とする事項:
- (a) 復旧目標: プラットフォームの全階層に対する、契約上拘束力のあるRPOおよびRTOのコミットメント。
- (b) バックアップ管理: 仮想マシン、データベース、およびアプリケーション成果物のバックアップスケジュール、保持期間、整合性検証、および復元手順。
- (c) データ冗長化およびレプリケーション: Azure Storageのレプリケーションオプション（LRS、ZRS、GRS）、データベースの読み取りレプリカ、およびジオ冗長フェイルオーバーアーキテクチャ。
- (d) 災害復旧: フェイルオーバー手順、セカンダリリージョンの有効化、通信プロトコル、およびサービス復旧ワークフロー。
- (e) 事業継続計画: Business Impact Analysis（BIA）、継続計画の保守、DR訓練スケジュール、およびインシデント後レビュー手順。
- (f) データ所有権および可搬性: Customerのデータ所有権、データエクスポート手段、記録管理義務、およびeディスカバリー支援。
- (g) 役割および責任: 全てのBCDR活動に関するProvider組織とCustomer組織のRACI割り当て。本章は、アプリケーションレベルのセキュリティ管理（第8章参照）、個人データ処理（第7章参照）、または運用サポートワークフロー（第4章参照）を対象としません。
9.3 規格およびフレームワークとの整合
ProviderのBCDRプログラムは、以下の国際的に認知された規格およびフレームワークに整合しています。
| 標準／フレームワーク | 整合の範囲 | 参照 |
|---|---|---|
| ISO 22301:2019 | Business Continuity Management Systems。BCMSの計画、確立、実装、運用、監視、レビュー、維持、継続的改善に関する要求事項。 | https://www.iso.org/standard/75106.html |
| ISO 27031:2011 | Business Continuityのための情報通信技術レディネス（IRBC）の指針。ISO 22301をICTサービスに拡張するもの。 | https://www.iso.org/standard/44374.html |
| NIST SP 800-34 Rev. 1 | 連邦情報システム向けコンティンジェンシープランニングガイド。BIAの方法論、復旧戦略、計画テスト、および保守。 | https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final |
| Azure EBCM Programme | Azureプラットフォームのレジリエンス、可用性ゾーン、ジオ冗長インフラを管理するMicrosoftのEnterprise Business Continuity Managementプログラム。 | https://learn.microsoft.com/en-us/compliance/assurance/assurance-bcdr |
| Azure Well-Architected Framework — Reliability Pillar | レジリエントなクラウドワークロードの設計原則。冗長化、障害分離、自動復旧、優雅な劣化。 | https://learn.microsoft.com/en-us/azure/well-architected/reliability/ |
| ITIL 4 — Service Continuity Management | 障害発生中および発生後に合意済みのサービス継続レベルを確保するIT Service Continuity Management（ITSCM）プラクティス。 | https://www.axelos.com/certifications/itil-service-management |
9.4 復旧目標
以下の契約上拘束力のある復旧目標は、各Customer専用のプライベート主権環境に適用されます。これらの目標は、プラットフォームの各階層について許容可能な最大データ損失（RPO）および許容可能な最大ダウンタイム（RTO）を定義します。
| 復旧指標 | 層 | 目標 | 測定 |
|---|---|---|---|
| Recovery Point Objective（RPO） | データベース階層（SQL Server 2022） | 15分 | 障害発生時点から直近の成功済みバックアップまたはレプリケーションチェックポイントまでの最大データ損失。 |
| Recovery Point Objective（RPO） | 仮想マシン階層 | 24時間 | VMレベルの状態（OS、アプリケーションバイナリ、構成）における最大データ損失。日次スナップショットによりRPO ≦ 24時間を確保します。 |
| Recovery Point Objective（RPO） | ファイル／Blobストレージ階層 | ほぼゼロ（GRS） | Geo-Redundant Storageレプリケーションは、通常条件下でほぼゼロのRPOを実現する非同期のリージョン間レプリケーションを提供します。 |
| Recovery Time Objective（RTO） | データベース階層（SQL Server 2022） | 4時間 | インシデント宣言から、構成済みであれば読み取りレプリカへのフェイルオーバーを含め、復旧したデータベースが利用可能になるまでの最大経過時間。 |
| Recovery Time Objective（RTO） | プラットフォーム全体（エンドツーエンド） | 8時間 | インシデント宣言から、コンピュート、データベース、ネットワーク、アプリケーション検証を含め、プラットフォーム全体が運用可能な状態に戻るまでの最大経過時間。 |
| Recovery Time Objective（RTO） | セカンダリリージョンフェイルオーバー | 24時間 | プライマリリージョンが復旧不能と宣言された場合に、セカンダリAzureリージョンへ完全にフェイルオーバーするまでの最大経過時間。 |
CustomerがEnhanced DR Option（読み取り専用データベースレプリカを備え、最大15分間隔で高頻度レプリケーションを行うセカンダリサーバー）を選択した場合、セカンダリVMが最小限のデータ損失および時間損失でプライマリの役割を引き継ぐため、データベース階層のRTOは1時間に短縮されます。Enhanced DR Optionには、該当するCommercial Contractに定める追加のサブスクリプション料金が適用されます。
Azure SQL Database Business Continuity Overview
9.5 バックアップ管理
Providerは、各Customer専用のプライベート主権環境の全コンポーネントを対象とする包括的なバックアップ体制を維持します。バックアップ運用はAzure BackupおよびSQL Serverのネイティブバックアップ機能を使用して実施されます。
9.5.1 バックアップスケジュールおよび保持
| コンポーネント | バックアップ種別 | 頻度 | 保持期間 | ストレージ冗長化 |
|---|---|---|---|---|
| SQL Server 2022 データベース | データベースフルバックアップ | 毎日 | 7日間（標準）；要請に応じて延長保持可 | Geo-Redundant Storage（GRS） |
| SQL Server 2022 データベース | トランザクションログバックアップ | 15分ごと（Enhanced DR） | 72時間ローリング | Geo-Redundant Storage（GRS） |
| 仮想マシン（Windows Server 2022） | Azure Backup VMスナップショット | 毎日 | 14日間（標準）；Azureポリシーにより最長99年まで設定可能 | Geo-Redundant Storage（GRS） |
| アプリケーション成果物および構成 | Gitリポジトリ（Master + Clientブランチ） | 継続的（各コミット時） | 無期限（完全なバージョン履歴） | Azure DevOpsジオ冗長ストレージ |
| Blob / File Storage | Azure Storageレプリケーション | 継続的（リージョン内で同期） | Customerの保持方針に従う | GRS（2リージョンに6コピー） |
| Azure Key Vaultのシークレットおよびキー | Azure管理のレプリケーション | 継続的 | 無期限（ソフト削除およびパージ保護を有効化） | 既定でジオ冗長 |
Customerの要請に応じ、追加のサブスクリプション料金を条件として、より高頻度のカスタマイズされたバックアップを提供できます。すべてのバックアップ頻度および保持期間は、Commercial Contractに添付される該当のBackup Schedule Addendumに文書化されます。
Azure Backup概要 AzureへのSQL Serverバックアップ
9.5.2 バックアップ整合性検証
Providerは、以下のバックアップ整合性検証手順を実施します。
- (a) 自動チェックサム検証: 各バックアップ処理で暗号学的チェックサム（SHA-256）が生成されます。チェックサムは完了時に自動検証され、バックアップ監査証跡に記録されます。
- (b) 月次復元テスト: 少なくとも各暦月1回、Providerはランダムに選択したデータベースバックアップを分離環境へテスト復元し、データ完全性、参照整合性、およびアプリケーション層の機能を検証します。
- (c) 四半期ごとのフルスタック復元訓練: 少なくとも各暦四半期1回、Providerは完全なプラットフォーム復元（VM＋データベース＋アプリケーション＋構成）を分離環境で実施し、全面的な災害復旧シナリオをシミュレーションします。結果はDR Drill Reportに記録されます。
- (d) バックアップ監視およびアラート: Azure Monitorアラートは、バックアップ失敗、タイムアウト、または整合性チェック失敗が発生した場合、15分以内にProviderのCloud Operationsチームへ通知するよう設定されています。失敗したバックアップには1時間以内に自動再試行が行われます。
9.6 データ冗長化およびレプリケーション
各Customer専用のプライベート主権環境は、Azureの多層データ冗長化アーキテクチャを活用し、ハードウェア障害、施設障害、リージョン災害から保護します。
| レプリケーションオプション | コピー数 | リージョン数 | 耐久性 | 利用ケース |
|---|---|---|---|---|
| Locally Redundant Storage（LRS） | 3コピー | 1リージョン、1施設 | 11ナイン（99.999999999%） | 単一データセンター内の重要でない一時ストレージの既定設定。 |
| Zone-Redundant Storage（ZRS） | 3コピー | 1リージョン、2～3の可用性ゾーン | 12ナイン | リージョン内の単一可用性ゾーン障害に対する保護。アプリケーション構成ストアに使用します。 |
| Geo-Redundant Storage（GRS） | 6コピー | 2リージョン（プライマリ＋セカンダリ、数百km離隔） | 16ナイン | すべてのCustomer Dataの既定設定。自動フェイルオーバー機能を備えたリージョン間耐久性を提供します。 |
| Read-Access Geo-Redundant Storage（RA-GRS） | 6コピー | 2リージョン、セカンダリへの読み取りアクセスあり | 16ナイン | プライマリリージョン障害時に、レプリケートされたデータへ読み取り専用アクセスするため、Customerの選択により利用可能です。 |
既定では、各CustomerのAzure StorageアカウントはGeo-Redundant Storage（GRS）でプロビジョニングされ、Customer Dataの6コピーを維持します。内訳は、プライマリAzureリージョン内に3コピー、地理的にペアとなるセカンダリリージョン内に3コピーです。プライマリリージョンが障害に見舞われた場合、Azure Storageは自動的にセカンダリリージョンへフェイルオーバーし、手動介入なしでデータ耐久性を確保します。
9.6.1 データベースレプリケーション
各Customer環境内のSQL Server 2022データベースは、以下のレプリケーション構成をサポートします。
- (a) 標準構成: 毎日フルバックアップを行い、7日間保持してGRSに保存します。トランザクションログは設定済みスケジュールに従ってバックアップされます（既定：1時間ごと；Enhanced DR：15分ごと）。
- (b) Enhanced DR構成（オプション）: すべてのCustomerデータベースの読み取り専用レプリカを備えたセカンダリSQL Serverインスタンスをプロビジョニングします。高頻度ログシッピング（最大15分間隔）により、ほぼリアルタイムのデータ同期を確保します。プライマリサーバー障害時には、セカンダリサーバーが自動的にプライマリの役割を引き継ぎ、最小限のデータ損失（RPO ≦ 15分）と迅速な復旧（RTO ≦ 1時間）で継続性を提供します。
- (c) データ所在地のコンプライアンス: Customerが書面でリージョン間レプリケーションを明示的に許可しない限り、データレプリケーションはCustomerが選択した地理的リージョン内に限定されます。GDPR第44条およびUAE PDPL第22条の越境移転要件に準拠し、Customerの同意なしに選択された地理的領域外へデータを送信することはできません（第7章、§7.14参照）。
9.7 災害復旧手順
Providerは、プラットフォームの各階層に対する災害復旧手順を文書化して維持します。これらの手順は少なくとも四半期ごとにテストされ、プラットフォームアーキテクチャ、Azureサービス機能、またはCustomer環境構成に重大な変更があった場合には更新されます。
9.7.1 インシデント分類およびエスカレーション
災害復旧イベントは、以下の重大度分類に従って分類されます。
| DR重大度 | 説明 | シナリオ例 | エスカレーション |
|---|---|---|---|
| DR-1: クリティカル | プライマリ環境の完全喪失。コンピュート、データベース、またはネットワークが完全に利用不能。回避策なし。 | Azureリージョン全域の障害；プライマリVMおよびすべてのバックアップが破損；データセンターの壊滅。 | 即時：CTO + Cloud Ops Lead + Customer Account Manager。Customerへ30分以内に通知。 |
| DR-2: 大規模 | 重要階層の部分的喪失。サービスは劣化しているが部分的に機能する、または単一階層の障害で回避策が利用可能。 | プライマリデータベースサーバー障害（読み取りレプリカ利用可）；VM障害（バックアップから復元可）；ストレージアカウントの劣化。 | 1時間以内：Cloud Ops Lead + DBA。Customerへ2時間以内に通知。 |
| DR-3: 中程度 | 中核的なトランザクション処理に影響しない、重要でないコンポーネント障害または性能劣化。 | バックアップジョブの失敗；監視エージェントの停止；セカンダリリージョンのレプリケーション遅延がしきい値を超過。 | 4時間以内：Cloud Opsチーム。Customerへの通知は次回予定のステータス更新時。 |
| DR-4: 軽微 | 調査は必要だが即時のサービス影響はない、予防的アラートまたはニアミス事象。 | 計画メンテナンスに関するAzureのヘルス勧告；自動解消されたストレージ遅延の急増；失敗したDR訓練コンポーネント。 | 記録し調査します。DR-3以上にエスカレートした場合にのみCustomerへ通知します。 |
9.7.2 フェイルオーバー手順
DR-1またはDR-2事象が宣言された場合、以下のフェイルオーバー手順を順次実施します。
| フェーズ | 活動 | 担当者 | 目標所要時間 | 成功基準 |
|---|---|---|---|---|
| 1. 検知 | Azure Monitor / SIEMアラートをCloud Operations当番エンジニアが受信し、確認済みとする。 | Cloud Ops（当番） | < 15分 | アラート確認済み；インシデントチケット作成済み；重大度分類済み。 |
| 2. 評価 | 障害範囲を特定する。影響を受けた階層、データ整合性の状態、読み取りレプリカと最新バックアップの利用可否を確認する。 | Cloud Ops Lead + DBA | < 30分 | 根本原因仮説を文書化；復旧経路を選定。 |
| 3. Customer通知 | 合意済みの通信チャネルを通じて、Customer Account Managerおよび指定されたCustomer連絡先に通知する。 | アカウントマネージャー | < 30分（DR-1） < 2時間（DR-2） | Customerが受領を確認；DR-1ではIncident Bridgeを招集。 |
| 4. データベース復旧 | 読み取りレプリカのフェイルオーバー（Enhanced DR）を有効化するか、最新のデータベースバックアップを代替VMへ復元する。 | DBA + Cloud Ops | < 1時間（Enhanced DR） < 4時間（標準） | データベースが稼働；参照整合性チェック合格；RPO確認済み。 |
| 5. コンピュート復旧 | Azure BackupスナップショットからVMを復元するか、ベースラインイメージから新規VMをプロビジョニングし、最新構成を適用する。 | Cloud Ops | < 4時間 | VM稼働；アプリケーションサービス応答あり；ヘルスチェック合格。 |
| 6. アプリケーション検証 | 自動スモークテストを実行し、中核的なトランザクションワークフロー（ログイン、データ入力、レポート）の手動検証を行う。 | QA / Cloud Ops | < 1時間 | すべての重要経路が合格；データ破損なし。 |
| 7. DNS / ネットワーク切替 | DNSレコードおよび／またはAzure Traffic Managerを更新し、トラフィックを復旧環境へ向ける。SSL/TLS証明書を検証する。 | Cloud Ops | < 30分 | エンドユーザーが接続可能；HTTPS確認済み；遅延はSLA内。 |
| 8. サービス復旧 | サービス復旧を宣言する。SLA計測を再開する。インシデント後監視を開始する（72時間は強化アラート）。 | Cloud Ops Lead | N/A | サービス復旧；SLA指標再開；監視確認済み。 |
| 9. インシデント後レビュー | 5営業日以内にRoot Cause Analysis（RCA）を実施する。Post-Incident Report（PIR）をCustomerへ公開する。 | CTO + Cloud Ops Lead | 5営業日 | PIR提出済み；是正措置を割り当て済み；BCDR計画を更新済み。 |
9.7.3 セカンダリリージョンフェイルオーバー
プライマリAzureリージョンがMicrosoftまたはProviderのCTOにより復旧不能と宣言された場合、Providerは地理的にペアとなるAzureリージョンへ完全なセカンダリリージョンフェイルオーバーを実施します。この手順には以下が含まれます。
- (a) GRSフェイルオーバー開始: Azure Storageは自動的にセカンダリリージョンへフェイルオーバーします。RA-GRSアカウントはレプリケートされたデータへの即時読み取りアクセスを提供します。
- (b) VM再プロビジョニング: 新しい仮想マシンを、最新のAzure Backup vaultからセカンダリリージョンにプロビジョニングします（クロスリージョン復元有効）。
- (c) データベース復元: SQL Serverデータベースは、ジオ冗長バックアップから、またはEnhanced DRがプロビジョニングされている場合は、対のリージョンにあるセカンダリ読み取りレプリカサーバーから復元します。
- (d) DNS再構成: Azure Traffic ManagerまたはDNSレコードを更新し、すべてのCustomerトラフィックをセカンダリリージョンのエンドポイントへルーティングします。
- (e) 検証および宣言: セカンダリリージョンからのサービス復旧を宣言する前に、アプリケーション検証の全スイートを実行します。完全なセカンダリリージョンフェイルオーバーの目標RTOは、プライマリリージョン宣言時点から24時間です。Customerには、合意済みの通信チャネルを通じて、フェイルオーバー手順中少なくとも2時間ごとに最新情報を提供します。
Azure Cross-Region Disaster Recovery
9.8 事業継続計画
9.8.1 Business Impact Analysis（BIA）
Providerは、ProjectVIEW ERP PlatformのBusiness Impact Analysisを維持し、重要な業務プロセスを特定し、それらのプラットフォームコンポーネントへの依存関係をマッピングし、サービス中断の影響を定量化します。BIAは以下のタイミングで見直し、更新します。
- (a) 少なくとも年1回、BCMSのマネジメントレビューサイクルの一環として。
- (b) プラットフォームアーキテクチャ、Azureリージョン構成、またはCustomerの展開トポロジーに重大な変更があった後。
- (c) 既存のBIAに不足があることを示したDR-1またはDR-2のインシデントの後。
BIAは、各Customer環境における復旧目標の調整（RPO/RTO）、バックアップ頻度の決定、およびレプリケーションアーキテクチャ設計に反映されます。
9.8.2 Business Continuity Plan（BCP）
ProviderのBusiness Continuity Planは、障害発生時にプラットフォームサービスを維持または復旧するために必要な手順、役割、通信プロトコル、およびリソース配分を文書化します。BCPには以下が含まれます。
- (a) Crisis Management Team（CMT）の構成: CTO（Incident Commander）、Cloud Operations Lead、DBA Lead、Customer Account Manager、Communications Lead。
- (b) コミュニケーション計画: Customer通知用の事前定義テンプレート（初動アラート、進捗更新、解決通知、PIR配布）、内部エスカレーションマトリクス、およびベンダー連絡先登録簿（Microsoft Azure Support、ドメインレジストラ、SSLプロバイダー）。
- (c) リソースインベントリ: 各Customer環境におけるすべてのAzureリソース（VM、SQLインスタンス、ストレージアカウント、ネットワークコンポーネント、Key Vaultのシークレット）の文書化された一覧。CMDBで維持し、四半期ごとに検証します。
- (d) 代替サイト手順: 事前プロビジョニング済みのインフラストラクチャテンプレート（Azure Resource Manager / Bicep）および自動デプロイメントスクリプトを含む、セカンダリAzureリージョンを有効化するための段階的手順。
- (e) サプライヤー継続性: 重要なサードパーティ依存関係（Microsoft AzureのSLAコミットメント、ドメインレジストラ、認証局）の評価およびそれぞれのコンティンジェンシー対策。
9.8.3 DR訓練プログラム
Providerは、BCDR計画の有効性を検証し、運用準備態勢を確保するため、定期的にDR訓練を実施します。
| 訓練種別 | 頻度 | 範囲 | 参加者 | 成果物 |
|---|---|---|---|---|
| 机上演習 | 四半期ごと | 意思決定、コミュニケーション、エスカレーション手順を検証するため、CMTとともに仮想DRシナリオをウォークスルーします。 | CMT + Customer代表者（任意） | 所見および是正措置を含む机上演習報告書。 |
| コンポーネント復旧テスト | 毎月 | 復旧可能性を確認するため、単一のバックアップコンポーネント（データベース、VM、またはストレージ）を分離環境で復元します。 | Cloud Ops + DBA | 達成RPO/RTOと目標を比較した復旧テストログ。 |
| フルスタックDR訓練 | 年2回 | DR-1事象を想定した分離環境でのエンドツーエンドのプラットフォーム復旧。データベースのフェイルオーバー、VM復元、アプリケーション検証を含みます。 | CMT + QA + DBA + Cloud Ops | 実測RPO/RTO、乖離、および改善措置を含むDR訓練報告書。 |
| セカンダリリージョンフェイルオーバー訓練 | 年1回 | 事前合意したメンテナンスウィンドウ中に、本番トラフィックを振り替えながら、対になるセカンダリAzureリージョンへ完全フェイルオーバーします。 | CMT + Customer + Cloud Ops | 実測RTOおよびCustomer承認を含むリージョンフェイルオーバー報告書。 |
すべての掘削結果は文書化され、最低3年間保管され、書面による請求があった場合、顧客に提供されます。掘削により契約上のRPO/RTO目標からの逸脱が判明した場合、プロバイダーは30暦日以内に是正措置を実施し、是正の確認のために該当する掘削を再実施するものとします。
9.9 顧客データの所有権および移転可能性
顧客は、プラットフォーム内で処理、保存、または生成されるすべての顧客データについて、独占的かつ排他的な所有権を保持します。プロバイダーは、サブスクリプション期間中であるか、その満了または終了後であるかを問わず、いかなる時点においても、顧客データを確認、承認、監視せず、また顧客データに対するいかなる所有権も主張しません。
基盤となるインフラストラクチャ提供者であるMicrosoftは、顧客がAzureに保存するデータの種類を把握しておらず、Azureサービスに入力された顧客情報についてデータ所有権を主張しません。
9.9.1 データのエクスポートおよび移転可能性
プロバイダーは、以下の方法で顧客データをエクスポート可能にするものとします。
- (a) オンデマンドエクスポート: 顧客は、サブスクリプション期間中いつでも、顧客データの全量または一部のエクスポートを請求できます。プロバイダーは、有効な書面による請求を受領後2営業日以内に、機械可読かつ業界標準の形式（合意されたSQLバックアップファイル、CSV、JSON、またはXML）でエクスポートを提供するものとします。
- (b) 終了時エクスポート: 本フレームワークの満了または終了時に、プロバイダーは、Chapter 7, §7.13（終了時のデータ返却）のデータ返却規定に従い、顧客の書面による請求後2営業日以内に、すべての顧客データをエクスポート可能にするものとします。全体のエクスポート期間は、終了の発効日から最低60暦日間維持されるものとします。
- (c) 監査およびコンプライアンス用エクスポート: 顧客は、コンプライアンス目的で監査ログ、アクセスログ、および変更追跡記録の提供を請求できます。このようなエクスポートは、書面による請求後2営業日以内に提供されます。
9.9.2 記録管理
顧客は、適用法令および業界規制に従い、自社の記録保存要件を特定する責任を負います。プロバイダーは、以下により顧客の記録管理義務を支援します。
- (a) 設定可能な保持ポリシー: プラットフォームはアプリケーションレベルで設定可能なデータ保持ルールをサポートし、顧客が記録カテゴリごとに保持期間を定義できるようにします。
- (b) 監査証跡の保全: Azure Storageの保持ポリシーおよびSQL Serverの変更追跡により、すべてのデータ変更について改ざん不可能な監査証跡が提供されます。監査記録は、商業契約で合意された最低期間（標準：7年）保管されます。
- (c) 外部保管用エクスポート: 顧客は、サブスクリプション期間中いつでも、外部保管のためにデータおよび監査報告書をエクスポートできます。プロバイダーは、書面による請求に応じて標準形式での一括エクスポートを支援するものとします。
9.9.3 電子情報開示（e-Discovery）
顧客は、プラットフォームの利用においてe-discovery要件を遵守する責任を負います。プロバイダーは、以下により顧客のe-discovery義務を支援します。
- (a) データ保全保持: 訴訟ホールドまたは規制調査の要件を示す顧客からの書面による請求があった場合、プロバイダーは指定された顧客データに保全保持を設定し、対象データセットに対するすべての自動削除および保持ポリシーの適用を停止します。
- (b) e-discovery用データエクスポート: プロバイダーは、保全保持の請求から2営業日以内に、e-discoveryレビューに適した形式（メタデータおよび監査証跡を含む）で、指定されたデータセットをエクスポートし、提供するものとします。
- (c) 保管連鎖文書: プロバイダーは、すべてのe-discoveryエクスポートについて保管連鎖文書を提供し、エクスポートされたデータの完全性および整合性を証明するものとします。
9.10 Azureプラットフォームのレジリエンス
プロバイダーは、各顧客専用のプライベート・ソブリン環境内で、以下のAzureネイティブなレジリエンス機能を活用します。
- (a) 可用性ゾーン: 顧客が選択したAzureリージョンで利用可能な場合、単一ゾーン障害から保護するため、重要リソース（VM、マネージドディスク、ロードバランサー）は複数の可用性ゾーンに分散配置されます。
- (b) Azure Resource Health: VMの正常性を監視し、リソースが想定どおりに稼働しているかを確認するとともに、既存リソースに影響する既知のAzureプラットフォーム問題を検知します。アラートはAzure Monitor経由でCloud Operationsチームにルーティングされます。
- (c) Azure Backup Vault: リージョンをまたぐ復元機能、ソフト削除保護（14日）、および重要なバックアップ削除操作に対する複数ユーザー承認を備えた一元的なバックアップ管理。
- (d) Azure Resource Locks: 重要インフラコンポーネントの偶発的または悪意ある削除や変更を防ぐため、すべての本番リソースにCanNotDeleteおよびReadOnlyロックが適用されます。
- (e) Azure DDoS Protection: 標準ティアのDDoS保護がすべての顧客仮想ネットワークで有効化され、リアルタイムテレメトリおよび攻撃後レポートを伴う自動攻撃緩和を提供します。
- (f) Azure Key Vault: 暗号化キー、シークレット、および証明書は、ソフト削除とパージ保護を有効にしたAzure Key Vaultに保存され、誤削除が発生した場合でも暗号資材を復旧可能にします。
Azure Availability Zones Overview Azure Resource Health Overview Azure Backup Architecture
9.11 顧客の責務
顧客は、BCDRプログラムを支援するため、以下の責務を認識し、これに同意するものとします。
- (a) 連絡先指定: 顧客は、時間外の緊急連絡先を含め、DR関連コミュニケーションのための権限ある連絡先を少なくとも2名指定し、維持するものとします。連絡先情報は、人員変更があった場合、5営業日以内に更新されるものとします。
- (b) DR訓練参加： お客様は、年次のセカンダリリージョン・フェイルオーバー訓練および四半期ごとの机上演習に参加するため合理的な努力を行い、コミュニケーションの有効性および業務影響の正確性についてフィードバックを提供するものとします。
- (c) 保持ポリシーの明示: 顧客は、オンボーディング時に自社のデータ保持要件を文書で指定し、必要に応じて更新するものとします。プロバイダーは、それに応じてプラットフォームの保持ポリシーを設定するものとします。
- (d) データエクスポートの検証: データエクスポート操作（オンデマンドまたは終了時）の後、顧客は合意された検証期間内に、エクスポートされたデータの完全性および整合性を確認するものとします。検証期間内にデータ完全性に関する異議を申し立てない場合、そのエクスポートを受諾したものとみなされます。
- (e) エンドユーザー継続性計画: 顧客は、エンドユーザーへの連絡、手動プロセスへの代替手段、およびプラットフォームの範囲外にある社内システム依存関係を含む、自社の内部事業継続計画について責任を負います。
9.12 継続的改善
プロバイダーのBCDRプログラムは、ISO 22301:2019で規定されるPlan-Do-Check-Act（PDCA）手法に整合した継続的改善サイクルの対象となります。
- (a) 計画: プラットフォーム、Azureの機能、および顧客要件の変更に基づく、年次BIAレビュー、回復目標の調整、およびBCDR計画の更新。
- (b) 実行: 本章で定義されたバックアップスケジュール、レプリケーション構成、およびDR訓練プログラムの実施。
- (c) 確認: バックアップ成功率、DR訓練結果（測定されたRPO/RTOと目標値の比較）、インシデント後レビュー、および顧客フィードバックの監視。
- (d) 改善: Checkフェーズで特定された是正措置、アーキテクチャ改善、および手順の見直しの実施。すべての改善はBCDR改善登録簿で追跡され、四半期ごとのサービスレビュー会議で報告されます（Chapter 4, §4.10を参照）。
9.13 永久ソフトウェア保証
プロバイダーは、プラットフォームがサブスクリプション期間全体およびその更新期間（以下「保証期間」）にわたり、次のとおりであることを保証します。
- (a) 適合性: 本フレームワークおよび適用される商業契約に記載された仕様、機能、およびサービスレベルに実質的に従って動作すること;
- (b) 不具合是正： お客様が本来の事業目的のためにプラットフォームを使用することを妨げる重大な欠陥がないこと。確認された欠陥は、第3章で定義される適用SLAの応答および解決目標内に、追加費用なしでプロバイダーが是正するものとします。
- (c) バージョンの最新性： 現在サポートおよび保守が提供されている技術スタックを維持すること。プロバイダーは、セクション4.7で定義されるリリースサイクル内に、基盤となるすべてのCOTSコンポーネント（データベースエンジン、アプリケーションフレームワーク、オペレーティングシステム、ミドルウェア）を、ベンダーがサポートするバージョンへ積極的にアップグレードするものとします。
- (d) セキュリティ保守： 保証期間を通じて継続的なセキュリティパッチ適用を受けること。これには、第8章で指定された期限内の重大および高リスクの脆弱性是正を含みます。
- (e) 性能低下の禁止： 本フレームワークで定義されるSLOおよび復旧目標（RPO/RTO）を満たすか、上回る性能特性を維持すること。プロバイダーは、お客様の承認なしに、プラットフォームの性能を実質的に低下させる変更を加えてはなりません。本保証は、生涯保証であり、お客様の有効なサブスクリプション期間と同一範囲で有効です。本保証は失効せず、対象範囲が縮小されることも、別途更新を要することもありません。本保証は第10章に基づくバージョン移行後も存続し、一般提供開始日から後継バージョンにも同等に適用されます。
除外事項： 本保証は、(i) プロバイダーの変更管理プロセス外でお客様がプラットフォームに加えた変更、(ii) その文書に反する方法でのプラットフォームの使用、(iii) プロバイダーが提供または承認していない第三者ソフトウェアまたはハードウェア、または (iv) 不可抗力事象に起因する欠陥を対象としません。
9.14 ソースコード・エスクロー
お客様に長期的な継続性の保証を提供するため、プロバイダーは以下のとおりソースコード・エスクロー契約を維持するものとします。
9.14.1 エスクロー預託
- (a) エスクロー管理者： プロバイダーは、プラットフォームのソースコードを保管するため、信頼できる独立した第三者のエスクロー管理者（以下「エスクロー管理者」）を任命するものとします。エスクロー管理者の名称は、お客様の請求に応じて開示されます。
- (b) 預託内容： エスクロー預託には、(i) プラットフォームの完全なソースコード、(ii) ビルドスクリプトおよびコンパイル手順、(iii) データベーススキーマおよび移行スクリプト、(iv) 第三者依存関係の一覧およびライセンス文書、(v) システムアーキテクチャ文書、ならびに (vi) 有能なソフトウェア専門家がプラットフォームをコンパイル、展開、運用するために十分な導入手順を含めるものとします。
- (c) 更新頻度： エスクロー預託は、各メジャーバージョンリリース（アップグレード）後30日以内に更新し、インクリメンタルリリース（アップデート）については各暦四半期につき少なくとも1回更新するものとします。
- (d) 検証： エスクロー管理者は、完全性およびビルド可能性を確認するため、預託内容について年次検証を実施するものとします。要約検証証明書は、お客様の請求に応じて提供されます。
9.14.2 開示条件
エスクロー管理者は、以下のいずれかの開示条件が発生した場合、エスクローされたソースコードをお客様に開示するものとします。
- (a) 支払不能： プロバイダーが、いずれかの法域において、清算、管理命令、管財、またはこれに類する倒産手続に入ること。
- (b) 事業の停止： プロバイダーが事業、またはその事業の実質的に全部を停止すること。
- (c) 重大な違反： プロバイダーが本フレームワークに対して重大な違反を行い、お客様からの書面通知後60日間にわたり是正されないこと。
- (d) 提供終了： プロバイダーが、商業上合理的な後継製品または移行経路を提供することなく、プラットフォームの提供を恒久的に終了すること。
9.14.3 開示時のお客様の権利
エスクローされたソースコードが開示された場合、お客様には、お客様自身の内部業務目的のためにのみプラットフォームを継続運用する目的で、ソースコードを使用、コンパイル、修正、および展開するための非独占的、譲渡不能、取消不能のライセンスが付与されます。本ライセンスには、ソースコードを再配布、サブライセンス付与、または商業的に利用する権利は含まれません。
9.14.4 費用
エスクロー契約の設定および維持に要する費用は、エスクロー管理者の手数料、預託更新、年次検証を含め、お客様が負担するものとします。プロバイダーは、エスクロー管理者との初期設定を支援し、すべての預託および検証活動に協力するものとしますが、サブスクリプション期間を通じてエスクロー管理者の手数料および関連費用は、お客様が単独で責任を負うものとします。
9.15 役割と責任（RACIマトリクス）
以下のRACIマトリクスは、主要なBCDR活動に関するプロバイダーおよびお客様の役割別責任を割り当てたものです。
| 活動 | CTO | Cloud Ops Lead | DBAリード | アカウントマネージャー | お客様ITリード | お客様CISO |
|---|---|---|---|---|---|---|
| BIAレビューおよび更新 | A | R | C | I | C | C |
| BCP保守 | A | R | C | I | I | I |
| バックアップスケジュール設定 | I | R | R | I | C | I |
| バックアップ整合性検証 | I | R | R | I | I | I |
| DR訓練の計画および実施 | A | R | R | C | C | C |
| DR訓練報告 | A | R | C | R | I | I |
| インシデントの検知および分類 | I | R | R | I | I | I |
| お客様へのインシデント連絡 | I | I | I | R | I | I |
| データベース・フェイルオーバー実行 | I | C | R | I | I | I |
| VM復元実行 | I | R | C | I | I | I |
| セカンダリリージョンへのフェイルオーバー | A | R | R | C | I | I |
| インシデント後レビュー（PIR） | A | R | R | C | C | C |
| データエクスポート対応 | I | R | R | C | R | I |
| eディスカバリーホールド管理 | A | R | R | C | R | C |
| 保持ポリシー設定 | I | C | R | I | R | C |
| BCDR改善追跡 | A | R | C | I | I | I |
| 保証不具合是正 | A | R | R | C | C | I |
| エスクロー預託および更新 | A | R | C | I | I | I |
| エスクロー検証（年次） | I | C | I | I | I | I |
| エスクロー開示判断 | C | I | I | I | R | C |
凡例：R = 実施責任者（活動を実行する） · A = 説明責任者（最終決裁権限を有する） · C = 協議先（決定前に意見を提供する） · I = 報告先（決定後に通知される）。
9.16 プロセス登録簿
以下のプロセス登録簿は、本章で定義されるすべての正式プロセスを一覧化したものです。各プロセスには、一意の識別子、トリガー条件、実施担当者、承認責任者、期待成果、および統括セクションへの参照が割り当てられます。
| プロセスID | プロセス名 | トリガー | 担当者 | 承認者 | 成果 | セクション参照 |
|---|---|---|---|---|---|---|
| P-9.01 | BIAレビュー | 年次の経営レビューサイクルまたは重大なアーキテクチャ変更 | Cloud Ops Lead | CTO | 改訂された影響度評価および復旧優先順位を反映した更新済みBIA文書。 | §9.8.1 |
| P-9.02 | BCP更新 | BIA改訂、インシデント後レビューの所見、またはAzure機能変更 | Cloud Ops Lead | CTO | 更新済み事業継続計画が承認され、CMTに配布済み。 | §9.8.2 |
| P-9.03 | バックアップ設定 | 新規お客様のオンボーディング、環境プロビジョニング、またはバックアップポリシー変更要求 | DBA + Cloud Ops | Cloud Ops Lead | バックアップスケジュール、保持期間、および保存冗長性を設定し、文書化済み。 | §9.5.1 |
| P-9.04 | バックアップ整合性検証 | 各バックアップ処理の完了時、または予定された月次／四半期訓練 | Cloud Ops + DBA | Cloud Ops Lead | チェックサムを検証済み。リストアテストに合格済み。結果はバックアップ監査証跡に記録済み。 | §9.5.2 |
| P-9.05 | バックアップ失敗是正 | バックアップ失敗、タイムアウト、または整合性チェック失敗に対するAzure Monitorアラート | Cloud Ops（当番） | Cloud Ops Lead | 1時間以内に自動再試行。再試行が失敗した場合は手動調査。根本原因を文書化済み。 | §9.5.2 |
| P-9.06 | DRインシデント検知 | サービス中断の可能性を示すAzure Monitor／SIEMアラート | Cloud Ops（当番） | Cloud Ops Lead | アラートは15分以内に確認済み。インシデントチケット作成済み。重大度を分類済み（DR-1からDR-4）。 | §9.7.1 |
| P-9.07 | DRインシデント評価 | DRインシデントが検知され、DR-1またはDR-2に分類済み | Cloud Ops Lead + DBA | CTO | 根本原因仮説を文書化済み。復旧経路を選定済み。DR-1ではCMTを招集済み。 | §9.7.2 |
| P-9.08 | お客様へのDR通知 | DRインシデントがDR-1またはDR-2に分類済み | アカウントマネージャー | Cloud Ops Lead | お客様へ30分以内（DR-1）または2時間以内（DR-2）に通知済み。DR-1ではインシデントブリッジを招集済み。 | §9.7.2 |
| P-9.09 | データベース・フェイルオーバー | データベース層に影響するDR-1またはDR-2インシデント | DBAリード | CTO | データベースが読み取りレプリカ上でオンライン、またはバックアップから復元済み。参照整合性チェック合格済み。 | §9.7.2 |
| P-9.10 | VM復元 | コンピュート層に影響するDR-1またはDR-2インシデント | Cloud Ops | Cloud Ops Lead | VMをAzure Backupスナップショットから復元済み。アプリケーションサービスが応答中。ヘルスチェック合格済み。 | §9.7.2 |
| P-9.11 | アプリケーション検証 | データベースおよび／またはVMの復元完了 | QA / Cloud Ops | Cloud Ops Lead | 自動スモークテストおよび手動検証に合格済み。データ破損は検出されず。 | §9.7.2 |
| P-9.12 | サービス復旧宣言 | すべての復旧フェーズが完了し、検証済み | Cloud Ops Lead | CTO | サービス復旧を宣言済み。SLA時計は再開。72時間は強化監視。 | §9.7.2 |
| P-9.13 | 事後レビュー | DR-1またはDR-2インシデント解決済み | Cloud Ops Lead | CTO | 是正措置およびBCDR計画更新を含むインシデント後報告書（PIR）とRCA。5営業日以内にお客様へ提出済み。 | §9.7.2 |
| P-9.14 | セカンダリリージョンへのフェイルオーバー | プライマリAzureリージョンが復旧不能と宣言済み | Cloud Ops + DBA | CTO | 24時間以内にセカンダリリージョンでプラットフォーム全体が稼働。お客様の承認取得済み。 | §9.7.3 |
| P-9.15 | DR訓練実施 | 予定された訓練（月次／四半期／半年／年次、§9.8.3に従う） | Cloud Ops + DBA + QA | CTO | 訓練完了。RPO/RTOを目標値と比較して測定済み。訓練報告書を公開済み。 | §9.8.3 |
| P-9.16 | データエクスポート対応 | オンデマンドまたは契約終了時のデータエクスポートに関するお客様の書面要求 | Cloud Ops + DBA | アカウントマネージャー | お客様データを合意済み形式で2営業日以内にエクスポート済み。保全連鎖を文書化済み。 | §9.9.1 |
| P-9.17 | eディスカバリーホールド | 訴訟ホールドまたは規制調査を理由とするお客様の書面要求 | DBA + Cloud Ops | CTO | 保全ホールドを適用済み。自動削除を停止済み。影響を受けるデータセットを2営業日以内にエクスポート済み。 | §9.9.3 |
| P-9.18 | BCDR改善追跡 | DR訓練の逸脱、PIRの所見、またはBIAギャップを特定 | Cloud Ops Lead | CTO | 是正措置を30日以内に実施済み。追跡訓練で是正を確認済み。改善登録簿で追跡済み。 | §9.12 |
| P-9.19 | 保証不具合是正 | お客様が確認済みの重大な不具合を報告 | プロバイダー（エンジニアリング） | CTO | SLA目標内で無償是正済み。標準リリースプロセスにより修正を展開済み。 | §9.13, §3 |
| P-9.20 | エスクロー預託更新 | メジャーバージョンリリースまたは四半期リリースサイクル | プロバイダー（エンジニアリング） | CTO | 更新済みソースコード、ビルドスクリプト、スキーマ、文書をエスクロー管理者に預託済み。 | §9.14.1 |
| P-9.21 | エスクロー検証 | 年次検証サイクル | エスクロー管理者 | CTO | 預託の完全性およびビルド可能性を確認する検証証明書。請求に応じてお客様へ写しを提供。 | §9.14.1 |
| P-9.22 | エスクロー開示 | 開示条件が発生（支払不能、停止、重大な違反、提供終了） | エスクロー管理者 | 顧客 | 取消不能ライセンスの下でソースコードをお客様に開示。お客様はプラットフォームをコンパイルおよび運用可能。 | §9.14.2 |
9.17 プロセスフロー図
以下の9段階のライフサイクルは、プロバイダーのBCDRプログラムにおける事業継続および災害復旧管理の一連の流れを示しています。
① BIAおよびリスク評価 → ② BCPおよびDR計画策定 → ③ バックアップおよびレプリケーション
設定
↓
④ 監視および検知 → ⑤ インシデント分類およびエスカレーション → ⑥ フェイルオーバーおよび復旧
実行
↓
⑦ サービス復旧および検証 → ⑧ インシデント後レビューおよびPIR → ⑨ 継続的
改善および訓練プログラム
ステージ① BIAおよびリスク評価： 年次の事業影響分析により、重要プロセスを特定し、プラットフォーム依存関係をマッピングし、中断の影響を定量化します。復旧優先順位とRPO/RTO目標は、BIAの出力に基づいて調整されます（P-9.01）。
ステージ② BCPおよびDR計画策定： 事業継続計画およびDR手順は、BIAの所見に基づいて策定または更新され、CMTの構成、連絡テンプレート、資源一覧、セカンダリリージョン起動手順を組み込みます（P-9.02）。
ステージ③ バックアップおよびレプリケーション設定： 各お客様環境について、バックアップスケジュール、保持ポリシー、およびレプリケーションアーキテクチャ（LRS/ZRS/GRS/RA-GRS）を設定します。選択された場合、拡張DR読み取りレプリカをプロビジョニングします（P-9.03）。
ステージ④ 監視および検知： Azure Monitor、SIEM、およびResource Healthが、すべてのプラットフォームコンポーネントを継続的に監視します。バックアップの完了および整合性は自動で検証され、失敗時にはアラートが発報されます（P-9.04、P-9.05、P-9.06）。
ステージ⑤ インシデント分類およびエスカレーション： 検知されたインシデントは、重大度分類に従って分類（DR-1からDR-4）され、エスカレーションされます。お客様への通知時期は重大度レベルに基づいて発動します（P-9.07、P-9.08）。
ステージ⑥ フェイルオーバーおよび復旧実行： フェイルオーバー手順表に従い、データベース・フェイルオーバー、VM復元、アプリケーション検証を順次実行します。プライマリリージョンが復旧不能なDR-1事象では、セカンダリリージョンへのフェイルオーバーを実施します（P-9.09からP-9.11、P-9.14）。
ステージ⑦ サービス復旧および検証： すべての復旧フェーズの完了時点で、サービス復旧を宣言します。SLA時計は再開し、72時間は強化監視を維持します。DNS／ネットワークの切替は検証されます（P-9.12）。
ステージ⑧ インシデント後レビューおよびPIR： 根本原因分析は5営業日以内に実施します。インシデント後報告書は、是正措置、BCDR計画の更新、教訓を含めてお客様に提出されます（P-9.13）。
ステージ⑨ 継続的改善およびドリル・プログラム: DRドリル（机上演習、コンポーネント、フルスタック、リージョナル）は、予定されたプログラムに従って実施されます。RPO/RTO目標からの逸脱があった場合は、改善登録簿で追跡される是正措置を発動します。PDCAサイクルはステージ①に戻ります（P-9.15、P-9.18）。
