Azure Backupは、Recovery Services Vaultに保存されたスナップショットベースのバックアップを使用して、VMやワークロードをネイティブに保護します。また、ポリシーベースの保持やクロスリージョンリカバリなど、バックアップと復元の主要なニーズに対応しています。しかし、厳格なRPO/RTO目標、ランサムウェアへの懸念、コンプライアンス要件、またはハイブリッド/マルチクラウド環境を有する企業では、より高度な不変性、ガバナンスの一元化、および大規模なリカバリ機能が必要となる場合があります。重要なのは、単にAzure Backupを有効にするだけでなく、ビジネスおよびセキュリティ要件に沿ったデータ保護戦略を策定することです。
クラウドデータのバックアップは、現代のあらゆるビジネスにとっての優先事項です。しかし、 Fortune 500の企業の95%がそうであるように、お客様がMicrosoft Azureクラウドに依存している場合は、BackupをToDoリストの最優先事項にする必要があります。これには以下のような理由があります。
Azure、特にAzure上の仮想マシン (VM) の徹底的かつ安全なバックアップは、難しい課題となる可能性があります。本Azure VMバックアップガイドは、サードパーティ製のバックアップソリューションを活用して最善の結果を達成する方法に関するベストプラクティスと提案を提供します。Azure VMをバックアップする方法と、Azure全般をバックアップする方法について説明します。
ネイティブのAzure Backupを使用する場合でも、Rubrikのようなサードパーティ製ソリューションを使用する場合でも、Azure VMの基盤となる保護プロセスは同様のパターンに従います。これを理解することで、ポリシー、整合性、およびリカバリオプションに関して、より適切な決定を下せるようになります。
各仮想マシンにAzure VMエージェントがインストールされている必要があります。バックアップジョブがトリガーされると、スナップショット拡張機能は、VMをシャットダウンせずにディスクスナップショットの作成を調整します。Rubrikは、同一のAzureネイティブスナップショットメカニズムを使用します。つまり、バックアップ中もVMのパフォーマンスに影響を与えず、標準のAzure VMエージェント以外のエージェントも不要です。
復元ポイントの品質は、整合性タイプによって異なります。
アプリケーション整合性スナップショットでは、Windowsのボリュームシャドウコピーサービスを使用して、スナップショット作成前にメモリ内のデータをディスクにフラッシュします。これは、データベースやトランザクションワークロードに最適な選択肢であり、Rubrikでは、サポート対象のワークロードに対してデフォルトで使用されます。
ファイルシステム整合性スナップショットでは、スナップショットの作成前にファイルシステムへの書き込みをフラッシュして一時停止します。Linux VMに使用されます。
クラッシュ整合性スナップショットは、メモリをフラッシュせずにディスク状態をキャプチャするものであり、再起動を伴うリカバリを許容できるワークロードに適しています。
初回フルバックアップ後、後続のジョブは増分バックアップとなり、変更されたディスクブロックのみが転送されます。ネイティブのAzure Backupでは、データをより安価な階層に移動する前にホットストレージで30日間の保持が必要となります。一方、Rubrikでは、バックアップデータを最初の復元ポイントからコールドストレージに移動します。大量のAzure VMを保護している組織にとって、このストレージ階層化の違いは、規模が拡大するほど大きなコスト削減をもたらします。
ネイティブのAzure Backupは、妥当な出発点です。Recovery Services Vaultを作成し、スケジュールと保持期間を指定したバックアップポリシーを定義するなど、Azure Backupの設定を行い、VMのバックアップを有効にすれば、あとはAzureが処理します。単一のサブスクリプションで少数のVMを管理する小規模なチームにとっては、多くの場合これで十分です。
エンタープライズ規模では、これらの限界が顕著になります。
Azure Backupの設定では、ポリシーはVaultごと、サブスクリプションごとに設定されます。多数のサブスクリプションに一貫したバックアップ標準を適用するには、かなりの手作業、または複雑なAzure Policyスクリプトの作成が必要となります。
サブスクリプション、クラウド、オンプレミスインフラストラクチャ全体を統合しているビューはありません。ハイブリッド環境を管理するチームは、カバレッジを検証するために、ボルトごとに個別にログインする必要があります。
最初の30日間はホットストレージが必要で、これはコールドストレージの約2倍のコストがかかります。数百台のVMを保護するとなると、コストはすぐに積み重なってしまいます。
脅威検知およびランサムウェアからの復旧機能には限界があります。ネイティブのAzure Backupは、ソフト削除とVaultの不変性を提供しますが、復元前にバックアップデータをスキャンして脅威の兆候を調べることはありません。
復元オプションは時間がかかります。バックアップスナップショットを稼働中のVMとして即時マウントする機能に相当するものはありません。
Rubrik Security Cloudのような専用ソリューションは、こうしたギャップを解消するように設計されています。
Rubrik Security CloudはAzure環境に直接接続してVMを自動検出し、VaultごとのポリシーではなくSLAドメインを通じて保護を適用できるようにします。その結果、ネイティブな手法のような運用オーバーヘッドを伴わずに、サブスクリプションやクラウドを横断して拡張する一元化されたポリシー主導型のバックアップが実現します。
Rubrikは、サービスプリンシパルを使用して、Azure Active Directory内の登録済みアプリケーションを通じてAzureに接続します。これは、サブスクリプションごとに1回限りのセットアップです。
Rubrik Security Cloudコンソールで、「Infrastructure(インフラストラクチャ)」、「Cloud Accounts(クラウドアカウント)」の順に移動します。
Azureを選択し、ガイド付きセットアップに従ってAzure ADテナントにRubrikアプリケーションを登録します。
必要な権限を付与します(保護対象のサブスクリプションに対するContributor権限と、顧客管理キーを使用する場合はKey Vaultアクセス権)。
接続を完了します。Rubrikは、接続されたサブスクリプション内のすべてのAzure VMの検出を直ちに開始します。
接続後、「Workloads(ワークロード)」、「Azure VMs(Azure VM)」の順に移動すると、接続されているサブスクリプション全体で、すべてのVMの完全なインベントリを確認できます。保護されていないVMは、明確にフラグが立てられます。この自動検出により、VMを個別のVaultに登録するという手動プロセスが不要になります。これは、大規模な環境でネイティブのAzure Backupを管理する上で、最も時間のかかる作業の一つです。
Rubrikでは、Vaultごとのバックアップポリシーの代わりにSLAドメインを使用します。SLAドメインは宣言的ポリシーです。目標を指定すると(例:1時間ごとのスナップショットを30日間保持し、月次コピーを7年間アーカイブしてセカンダリリージョンへレプリケートする)、Rubrikがそのドメインに割り当てられたすべてのワークロードに対して実行を管理します。1つのSLAドメインで、Azure VM、オンプレミスサーバー、SQLデータベース、およびSaaSアプリケーションを同時にカバーできます。
Rubrik Security Cloudで、「SLA Domains(SLAドメイン)」に移動し、「Create SLA Domain(SLAドメインを作成)」を選択します。
基本となるバックアップの頻度(毎時、毎日、または毎週)とローカル保持期間を設定します。
障害復旧用に、セカンダリサイトまたはクラウドリージョンへのレプリケーションを設定します。
古い復元ポイントを自動的にコールドストレージに階層化するアーカイブルールを設定します。
SLAドメインを保存します。
Azure VMのインベントリで、保護対象のVM、リソースグループ、またはサブスクリプション全体を選択します。
SLAドメインを割り当てます。保護はSLAドメインのスケジュールに従って直ちに開始されます。
Rubrikは、最初の復元ポイントからコールドストレージに向けてバックアップデータの階層化を開始します。ネイティブのAzure Backupで必要とされる30日間のホットストレージでの保持は行いません。
Rubrikのコンプライアンスダッシュボードは、接続されているすべてのサブスクリプションおよびクラウドプラットフォーム全体にわたり、どのVMがSLAドメイン要件を満たしており、どれが満たせていないかを単一のビューで表示します。個別のAzure Vaultにログインしたり、サブスクリプションごとに個別のクエリを実行したりすることなく、監査担当者向けのコンプライアンスレポートを生成できます。VMがコンプライアンスに準拠しなくなった場合、またはバックアップジョブが失敗した場合、アラートが自動的にトリガーされます。
リカバリ速度は、ネイティブのAzure Backupに対するRubrikの優位性が最も顕著に表れる点です。ネイティブのAzure Backupには、Azure VMリストアを含む、VMの完全な復元、ディスクレベルの復元、ファイルレベルのリカバリという3つの復元パスが用意されています。これらはうまく機能しますが、個々のVaultにアクセスして復元ポイントを選択し、データが完全に転送されてVMが利用可能になるまで待つ必要があります。
Rubrikでは、RTOを大幅に短縮するいくつかの機能が追加されています。
Rubrikのライブマウントは、データの完全な転送を待機することなく、バックアップスナップショットを実行中のAzure VMとして直接マウントします。Rubrikがバックグラウンドで基盤となるデータを移行している間も、ワークロードは数分以内に利用可能になります。これは復旧に要する時間が「時間単位」か「分単位」かという違いであり、インシデント発生時に本番システムがダウンしている状況で重要です。
完全なAzure VM リストアを行うには、Rubrik Security CloudでAzure VMに移動し、スナップショットタイムラインから復元ポイントを選択して、元の場所、新しいVM、別のAzureリージョン、または別のサブスクリプションへの復元を選択します。サブスクリプションの境界を越えて復元する機能は、ネイティブのAzure Backupには備わっておらず、大幅な手作業なしには実現できません。
Rubrikコンソールで任意の復元ポイントのファイルシステムを直接ブラウズし、ディスクのアタッチやスクリプトの実行を行うことなく、個別のファイルやフォルダをダウンロードできます。ネイティブのAzure Backupも同様の機能を提供しますが、ターゲットVM上でマウントスクリプトをダウンロードして実行する必要があります。
Rubrikは復元を実行する前に、バックアップスナップショットをスキャンして既知の脅威の兆候がないかを確認し、最後のクリーンな復元ポイントを特定することで、環境へのマルウェアの再侵入を防ぎます。ネイティブのAzure Backupには同等の機能はありません。日付で復元ポイントを選択することはできますが、そのポイントがクリーンかどうかを確認する手段はありません。
バックアップポリシーをどう定義するかで、目標復旧時点とストレージコストが決まります。2つのアプローチは、スケーリングの方法が根本的に異なります。
ネイティブのAzure Backupでは、各サブスクリプションおよびワークロードに対して個別に設定されるVault単位のポリシーを使用します。標準ポリシーは日次バックアップをサポートしています。拡張ポリシーは、時間単位のバックアップに対応しており、長期の保持のためにVaultアーカイブ層への階層化が可能です。日次、週次、月次、年次の復元ポイントの保持期間は、個別に設定できます。エンタープライズ規模において、多数のサブスクリプション全体で一貫したポリシーを適用するには、新しいVMが適切に登録されるよう、Azure Policyの自動化と継続的なメンテナンスが必要です。
RubrikのSLAドメインモデルは、この複雑さを解消します。1つのSLAドメイン定義で、任意の数のサブスクリプションおよびクラウドプラットフォームにまたがる任意の数のワークロードをカバーできます。新しいVMがプロビジョニングされ、SLAドメインに割り当てられると、追加の設定なしで保護が自動的に開始されます。ポリシーの変更は、ドメイン内のすべてのワークロードに直ちに適用されます。これが、ネイティブのAzure VMバックアッププロセスにはない宣言的モデルであり、Rubrikはエンタープライズ規模で運用上実行できるようにしています。
Azure VMバックアップ は、成長かつ進化しつつあるベストプラクティスのセットの対象です。それらの一部はセキュリティを重視し、バックアップされたデータが攻撃者にとっていかに魅力的なターゲットになり得るかを考えると納得できます。サードパーティ製のバックアップツールの使用も推奨されます。
昔は、データをバックアップするとは、テープに保存し、そのテープを塩鉱山に隠しておくということでした。誰かがトレーラー付きトラックを持ち込まない限り、データは悪意ある攻撃者から十分に隔離されていました。
クラウドは、控えめに言っても異なります。クラウドは、従来のストレージ環境と比較すると広範囲に広がっています。組織には、さまざまな地域やクラウドプラットフォームに広がる複数のアカウントがある場合があります。結果として、データは広範囲の攻撃対象にさらされ、防御するにはより多くのリソースと専門知識が必要になります。(また、共有セキュリティモデルであるため、これらのリソースと専門知識はクラウドプロバイダー側ではなく、お客様側が提供する必要があります)
クラウドにバックアップされたデータも、侵害や流出のリスクがあります。適切に保護しない限り、侵害のリスクにさらされます。他の重要なITシステムと同じレベルのセキュリティの厳格さをAzure上のバックアップに適用することがベストプラクティスです。
これはどう見えますか? 大まかに言うと、Azureバックアップのセキュリティは、クラウドデータ保護 全体像の一部です。クラウドバックアップのセキュリティを確保する際に注意する要因の1つは、資格情報の管理です。盗まれたまたは誤って公開された認証情報は、ランサムウェア攻撃の主な悪用です。MFAを有効にすると、悪意ある攻撃者が不明デバイスからログインできる可能性が減るため、役立ちます。ロールベースのアクセス制御 (RBAC) も、組織の役割に基づきアクセスを制御、アクセス権限の割り当てと取り消しプロセスを簡素化することで役立ちます。
さらに、Azureのすべてのストレージ層でデータの暗号化を強く推奨します。ベストプラクティスは、内蔵型Azure Key Vaultツールを活用して、データ侵害への対策として使用する暗号化キーやその他の秘密を保護することです。
効果的なバックアップと復元には、バックアップジョブの状態を常に認識する必要があります。潜在的な問題(ワークフロー手順の見落とし、停止、サイバー攻撃など)を認識することも必要です。したがって、影響を受けるすべてのシステムを継続的、徹底的に監視することがベストプラクティスです。監視プロセスで問題が検出される場合は、迅速かつ適切な対応が取れるよう、監視後には必要に応じてアラートとレポートを送信する必要があります。
バックアップとリカバリ用にシステムを監視する方法は複数あり、1つのみに限定されません。システムの使用状況とバックアップ ジョブを常に管理するために、Azure Monitorを設定することは理にかなっています。Azure Monitorは、クラウドとオンプレミス環境から監視データを収集、分析、対応する多面的ソリューションです。バックアップとリカバリ関連データを収集し、集約します。Azure Monitorを使用すると、バックアップしたVMとデータの状態に影響する潜在的な問題を瞬時に認識できます。
レポートを確認し、監視データストリームを分析することで、ユーザーの行動を検証できると同時に、進行中の脅威または攻撃を示唆する異常アクティビティを発見できる可能性もあります。たとえば、ランサムウェア攻撃の前には、ユーザーは通常とは異なる場所または営業時間外にログインしている可能性があります。監視ソリューションがこれらの疑わしい信号を素早くキャッチすれば、攻撃を回避または爆発の影響範囲を制限できます。
Azureには独自のバックアップ機能がありますが、サードパーティ製バックアップソリューションの方が好ましい場合があります。Azureの内蔵型バックアップには、いくつかの利点 (ワークロード範囲の広さ、比較的な使い易さ、単一ベンダー関係の簡素化など) がありますが、固有の制限もあります。
Azureなどのネイティブバックアップツールは、ベースラインバックアップの取得を難しくする場合があります。複数のアカウント間にポリシーを設定するのは、運用面が複雑になる可能性があります。これらのツールは、マルチクラウドアーキテクチャの一元管理された可視性が欠ける傾向があり、ポリシーの定義と適用に一貫性がなくなる可能性があります。より高度なレベルでは、ネイティブバックアップツールは、ストレージ階層化が不十分かつ重複排除が非効率的で、他のコスト要因も最適でないため、経済的ではない場合があります。
サードパーティ製バックアップソリューションがこれらのギャップの多くを埋めます。一般的に、複数のAzureアカウントとリージョン、ならびに複数のクラウドとオンプレミスVM間のバックアップの一元管理と広範な可視性が一因となり、総所有コスト (TCO) を低減できます。サードパーティ製ソリューションは、バックアップデータを初日に安いコールドストレージに保存することでTCOを低減します。対照的に、Azure Backupはホットストレージに30日間保存する必要があり、これはコールドストレージの2倍のコストです。
Rubrik Security Cloudなどのサードパーティ製バックアップソリューションには、データ脅威分析やランサムウェア対策となる不変のバックアップなどのセキュリティ機能も含まれます。RubrikのAzureバックアップソリューションは、Azure SQL、Azure VM、Azure NetAppファイルなど、専用バックアップ機能など、Azure環境に明確な利点を提供します。
適切なAzureバックアップベンダーは、Azure VMと関連Microsoftワークロード用の特定の機能を提供するだけでなく、「一元管理画面」管理インターフェイスを通じて複数のクラウドとオンプレミスインフラストラクチャ間で作業できるようにするベンダーです。不変性、ロールベースのアクセス制御 (RBAC)、多要素認証 (MFA)、ランサムウェア検出、エアギャップバックアップ、高速復元、高速RTOとRPOによりバックアップセキュリティを強化する必要があります。総所有コスト (TCO) をできるだけ低く抑えるには、「コールドストレージ」オプションも不可欠です。
適切なAzureバックアップソリューションは、自動化でバックアップ管理をシンプルにする必要があります。ソリューションは、たとえば、Azure VMとマネージドディスクの階層化などのプロセスを自動化できる必要があります。Azure VMの自動検出も、特にソリューションがポリシー駆動型自動化を実現できる場合にプラスになります。例として、リソースグループ内のリソースの自動タグ付けがあります。
さらに、宣言ステートメントを使用してサービスレベル契約 (SLA) を作成できることは、Azureバックアップベンダーにとって大きなプラスです。RubrikのSLAドメイン構造に例示されているように、宣言ステートメントは、SLAを順守する従来の「命令型」モードとは対照的です。バックアップSLAを満たすために管理者が実行する必要がある一連の手順の概要を説明する命令型のアプローチとは異なり、必然的に面倒で非効率なプロセスですが、宣言ステートメントではRTOなどの目標が設定されます。それは、SLAを満たすバックアップをする、「設定して忘れる」方法です。結果的に、コンプライアンスははるかに簡単になります。
Azureで何らかのデータ損失イベントが発生すると、迅速な復旧が絶対に必要です。最適なAzureバックアップベンダーは、最も必要なAzure VMとその他のデータを大規模に選択的に復元できるベンダーです。このように、重要なデータの最速復元が優先され、通常の業務への復帰が迅速化されます。
これは、具体的にはイベントの開始から影響を受けたAzure VMと関連ファイルの回復までに経過する時間である、可能な限り復旧時間目標 (RTO)を実行することを意味します。さらに、ソリューションは可能な限り狭い復旧ポイント目標 (RPO)を実現する必要があります。RPOとは、一連のトランザクションの最新のものなど、停止時にデータが失われるポイントです。効果的なAzureバックアップソリューションは、ほぼゼロ時間のRTOとRPOを提供します。
長期保持とアプリケーションの復元が目標である場合は、アプリケーションモビリティを提供するAzureバックアップベンダーと連携する価値があります。たとえば、VMをAzureからAmazon Web Services (AWS) に移動、またはアプリを開発環境からテスト環境、さらに本番環境に移動する必要がある場合があります。このプロセスには、クラウド間でのデータの迅速な複製が含まれる場合があります。ベンダーはそのプロセスをサポートする必要があります。クラウド全体でシンプル、一元管理が成功に向けて不可欠です。
攻撃者はバックアップされたAzure VMも狙っているのか? 適切なAzureバックアップベンダーは、データ脅威分析機能を提供することで、手遅れになる前に問題を把握する上で役立ちます。データセキュリティには常に警戒が必要です。たとえば、バックアップソリューションは、バックアップされたデータの攻撃の痕跡を継続的にスキャンする必要があります。脅威ハンティング、つまり、特定の脅威を探し、攻撃として現れるのを待たずに検出する機能もあれば良いです。ソリューションが脅威を発見すると、脅威の軽減担当者にアラートを送信する必要があります。
サードパーティ製Azureバックアップソリューションは、理想的には、Microsoft 365などのサービスとしてのソフトウェア (SaaS) アプリケーションをカバーする必要があります。つまり、論理的にエアギャップ化され、アクセス制御されたバックアップと迅速な復元によるSaaSデータの保護を含む、大規模なSaaSデータ保護です。直感的なダッシュボードを備えた一元管理バックアップ/復元管理機能がこの機能の実現に役立ちます。