Azure Backup：ネイティブ機能の枠を超えて、完全なカバレッジを目指して

誰も想定していなかった Entra ID の問題

昨年、あるお客様から、予期していなかった問題について連絡がありました。そのチームの誰かが、40 の内部サービスが依存していた Entra ID アプリの登録を削除してしまったのです。数分以内に、それらのサービスは正常に動作しなくなりました。彼らは Azure バックアップからアプリの登録を復元しようと試みました。 

AzureのバックアップにはEntra IDは含まれていません。マイクロソフトは長年にわたり、ドキュメントでこの点を明確にしています。しかし、そのお客様はそれを読んでいませんでした。ほとんどのチームも同様です。何が失われたのかを理解した頃には、すでに2日間を費やし、各チームに散在する構成ファイルから手作業でアプリ登録を再構築していたのです。 

その電話が、私のAzureの保護に対する考え方を形作りました。マイクロソフトが提供するネイティブサービスは、有用な基本機能です。しかし、それらは完全な保護ではなく、そのギャップは、ほとんどのチームがデフォルトでカバーされていると想定している部分にあるのです。 

Azureのネイティブサービスが対応できない範囲

マイクロソフトはいくつかのネイティブ保護サービスを提供しており、それらはそれぞれの役割を十分に果たしています。Azure BackupはVMレベルのスナップショットとファイルレベルの復旧を処理します。Azure Site Recoveryはフェイルオーバーのオーケストレーションを処理します。Azure SQLには、ポイントインタイム復旧機能を備えた自動バックアップがあります。 Azure Blob Storageには、バージョン管理と不変性オプションがあります。多くのワークロードにとって、これらは適切な出発点となります。

実際に復旧が必要になった際に最も重要となる5つの具体的な箇所で、そのギャップが明らかになります。

複雑なワークロード全体にわたるアプリケーションの一貫性です。ネイティブのVMスナップショットは、通常、クラッシュ一貫性を備えています。 多層ワークロード、SAP HANA、または独自のクワイエス要件を持つアプリケーションのアプリケーション認識型バックアップを行うには、ファイルシステムとアプリケーションが適切にクワイエスされることを保証する、アプリケーション前後のフレームワークが必要です。単にカーネルがたまたまある状態でスナップショットを撮るだけでは不十分です。

SaaSの対応範囲。 Azureネイティブのバックアップでは、Microsoft 365やEntra IDは対象外です。マイクロソフト社自身も、これらのテナントレベルのオブジェクトの保持および復旧は顧客の責任であると明示しています。Entra IDのアプリ登録を失ったり、SharePointサイトを削除したりした場合、マイクロソフト社はその操作を適用しますが、マイクロソフト社自身による復旧手段は提供されません。 

テナント間およびサブスクリプション間の復旧。ネイティブサービスは、単一のAzureサブスクリプション内でのみ機能します。別のサブスクリプションやテナントへの復旧、あるいはオンプレミスへの復旧は、運用上、本来あるべきよりも困難です。特に、インシデント発生時にソース環境が信頼できない状況では、その困難さが際立ちます。 

大規模なポリシー管理。数百台の仮想マシンが複数のリソースグループやサブスクリプションにまたがると、バックアップポリシーを手動で割り当てることは、徐々にカバー範囲の隙間が生じる原因となります。見落とされたワークロードこそが、攻撃者や不注意な管理者によって最終的に破壊されてしまう対象となります。

想定外のシナリオにおけるコストの予測可能性。 アウトバウンド通信料、保存期間ティアの移行、およびリージョン間でネイティブ サービスを実行する際の隠れたコストは、まさに重要なデータを復旧する必要がある月という、最悪のタイミングで予期せぬ出費として襲いかかる可能性があります。

ネイティブ機能を超えるということは、ネイティブ機能を放棄することを意味するわけではありません。それは、ネイティブのプリミティブを基盤として扱い、その上にカバレッジ、一貫性、および運用上のスケーラビリティを追加することを意味します。 

完全な Azure 保護がカバーすべき範囲

「Azure専用に設計」が実際に意味すること

ベンダーはこのフレーズを好んで使います。 マーケティングとアーキテクチャを区別する4つの具体的な検証基準があります。

AzureネイティブのVMレベルスナップショット。バックアップサービスは、ベンダー側が上乗せしたスナップショットではなく、Azureのネイティブスナップショットメカニズムを使用すべきであり、そうすることで本番環境への影響をほぼゼロに抑えることができます。

Microsoft Entra IDによる認証。 認証はEntra IDを経由し、既存のRBACを継承します。別のユーザーデータベースを使用する場合、同期を維持するために並行するインフラストラクチャが必要となります。

Azure Marketplaceでの提供とAzureの課金。 サブスクリプションはマーケットプレイスを経由し、既存のAzure契約に基づいて課金されます。別途の調達や請求関係にはなりません。

マルチテナント対応のためのリソースグループ認識機能。異なるチームや事業部門は、それぞれ異なるリソースグループに配置されます。サービスは、その構造を自動的に検出して尊重し、各チームが自チームのリソースのみを可視化できるようにする必要があります。 

基本的なバックアップと運用グレードのバックアップを区別する要素

バックアップの展開は簡単な部分です。数十台の新しいVMが追加され、少なくとも1回の組織再編を経た2年後も保護機能が正常に動作し続けるかどうかを決定づける機能は、機能的なものではなく、運用上のものです。 特に重要なのは、以下の4つの機能です。

カスタムアプリケーション一貫性フレームワーク。標準的なAzure VMスナップショットは一般的なアプリケーションに対応しています。SAP HANA、カスタムアプリケーション、または多層ワークロードの場合、アプリケーション前処理および後処理のフレームワークにより、バックアップに向けてファイルシステムやアプリケーションをどのように準備すべきかを定義できます。 これがなければ、バックアップ自体は存在しても、復旧プロセスは脆弱なものになってしまいます。

タグに基づく自動ポリシー割り当て。SLAに合わせてポリシーを一度定義すれば、プロビジョニング時に割り当てられたタグに基づいて自動的に適用されます。「production-tier-1」というタグが付けられたワークロードにはTier-1ポリシーが適用され、「dev」というタグが付けられたワークロードには開発用ポリシーが適用されます。 タグが付けられていないワークロードには、デフォルトのセーフティネットポリシーが適用されます。最大限のカバー範囲と、最小限の管理負担を実現します。

きめ細かな復旧。復旧時には、ファイル、フォルダー、VM、vDisk、またはアプリケーション全体といったレベルで復元対象を選択し、復元先も元の場所、代替VM、別のリソースグループ、別のサブスクリプション、別のリージョンから選択できる必要があります。 このきめ細かさは、元の環境を信頼できない侵害シナリオにおいて最も重要になります。

既存の運用スタックへの Webhook による通知。重要なバックアップイベントは、チームがすでに使用しているツール（Slack、Microsoft Teams、ServiceNow）に通知されます。誰も監視していない別のコンソールではありません。 保護の失敗に関するリアルタイムのアラートは、問題を早期に発見できるか、復元中に発見してしまうかの分かれ目となります。

Azure Government および規制対象のワークロード

連邦政府機関、防衛関連企業、および規制対象業界には、標準的な Azure バックアップを超える要件があります。 特に重要な機能は3つあります。

Azure Government Cloudのサポートです。保護機能は、商用Azureだけでなく、Azure Government内でも動作する必要があります。米国の連邦政府のお客様の場合、これには、集中型データセンター、エッジサイト、遠隔地、およびモバイルインフラストラクチャから、オンプレミスデータをアーカイブまたはプライマリバックアップとしてAzure Government Blob Storageにバックアップすることが含まれます。 

クラウド効率に優れた重複排除機能を備えた、WORM ベースのランサムウェア対策。WORM ストレージにより、ランサムウェアがバックアップコピーを暗号化することを防ぎます。コスト面での課題は、従来の重複排除アプライアンスが膨大なコンピューティングリソースとメモリを必要とし、クラウド環境ではコストが高くなってしまう点です。 当社はクラウド上に一意のブロックのみを保存するため、ネットワーク、ストレージ、およびコンピューティングリソースを節約できます。復元時にデータの再構築が不要なため、復元パフォーマンスはネットワーク帯域幅のみに制限されます。

FIPS 140 認証および顧客主導のデータ主権。 HYCUは2025年にFIPS 140-3認証を取得し、連邦暗号モジュール規格に準拠しています。顧客データが顧客の管理下から決して外れないというアーキテクチャ上の取り組みと相まって、これはFedRAMP、ITAR、CMMC、または同様の規制枠組みの対象となるあらゆる組織にとって重要な意味を持ちます。 

Azure バックアップに関するよくある質問

Azure にはすでにバックアップ機能が含まれていますか、それとも別のソリューションが必要ですか？

Azure には、多くのシナリオに対応する VM スナップショット、ファイル復元、および DR オーケストレーションを処理するネイティブの保護サービスが含まれています。 ただし、Microsoft 365、Entra ID、および多くのエンタープライズ アプリケーションの一貫性要件は対象外であり、テナント間の復旧や大規模なポリシー管理に関しては制限があります。ほとんどのエンタープライズ環境では、ネイティブ機能に加え、完全なカバレッジを実現するためのサードパーティ製プラットフォームを組み合わせた多層的なアプローチが必要となります。 

Azure バックアップは、Microsoft 365 および Entra ID をどのように扱いますか？

対応していません。Microsoft の責任分担モデルでは、Microsoft 365 データおよび Entra ID オブジェクトの保存と復旧は、お客様側の責任となります。 Exchange メールボックス、SharePoint サイト、OneDrive コンテンツ、Teams データ、および Entra ID のアプリ登録やユーザーのきめ細かな復旧には、それらのワークロード向けに構築されたサードパーティ製プラットフォームが必要です。

常時稼働のインフラストラクチャに費用をかけずに、Azure を DR ターゲットとして使用することはできますか？

はい、可能です。 クラウドネイティブな BaaS を利用すれば、バックアップコピーは低コストで Azure Blob Storage に常時保存されます。コンピューティングリソースと高性能ストレージは、DR シナリオが宣言された場合にのみ消費されます。1 年のほとんどはストレージの料金のみを支払います。ごく稀に災害が発生した日だけ、コンピューティングリソースの料金を支払います。 完全にプロビジョニングされたスタンバイ環境のコストのほんの一部です。

Azure Backupと専用のBaaSプラットフォームの違いは何ですか？

Azure Backupは、Azure内のAzure VM、Azure Files、およびSQLワークロードを保護するためのMicrosoftのネイティブサービスです。 専用の BaaS プラットフォームは、その上に追加機能として、エンタープライズ アプリ全体にわたるアプリケーション一貫性のあるバックアップ、SaaS 対応（Microsoft 365、Entra ID）、サブスクリプションおよびテナントを横断した一元的なポリシー管理、Webhook 統合、およびクロスクラウド DR を提供します。この 2 つは互いに補完し合う関係にあります。 

もし1つだけ行うとしたら

今すぐMicrosoft 365およびEntra IDのカバー範囲を監査してください。 何が、どのツールによってバックアップされているか、また、誤って削除されたアプリ登録、SharePoint サイト、あるいは重要なユーザーを復元するには何が必要かをリストアップしてください。これらのいずれかの答えが「一から再構築する」である場合、冒頭で述べた顧客のようなミスが誰かによって引き起こされる前に、修正すべきギャップが存在します。