クラウドとオンプレミスのワークロードをクラウドにバックアップする

Azure Backup では、インフラストラクチャのデプロイと管理を必要としないシンプルで安全かつコスト効率に優れたソリューションを通じて、Azure のデータ資産を包括的に保護します。 これは、さまざまなワークロードに対応した Azure の組み込みデータ保護ソリューションです。 これにより、クラウドで実行されているミッション クリティカルなワークロードを保護し、常にバックアップ資産全体にわたって大規模にバックアップを使用および管理できるようになります。

対象ユーザー

この記事の主な対象読者は、Azure の組み込みデータ保護テクノロジの機能や Azure Backup について学習し、デプロイを効率的に保護するソリューションを実装したいと考えている IT 管理者やアプリケーション管理者、および大規模企業や中小企業の実装者を対象としています。 この記事は、Azure のコア テクノロジとデータ保護の概念について熟知しており、バックアップ ソリューションの使用経験があることを前提としています。 この記事で説明されているガイダンスは、確立されたパターンを使用して Azure でのバックアップ ソリューションの設計を容易にし、既知の落とし穴を回避できるようにするものです。

この記事の構成

Azure 上でインフラストラクチャとアプリケーションの保護を開始するのは簡単ですが、基になる Azure リソースが正しく設定され、最適に使用されていることを確認すると、価値実現までの時間を短縮できます。 この記事では、Azure Backup のデプロイを最適に構成するための設計上の考慮事項とガイダンスの概要について説明します。 コア コンポーネント (Recovery Services コンテナー、バックアップ ポリシーなど) と概念 (ガバナンスなど)、および詳細な製品ドキュメントへのリンクを使用してそれらやそれらの機能を評価する方法について詳しく見ていきます。

作業開始

サブスクリプションの設計戦略

クラウド導入プロセス全体の明確なロードマップを確保するほか、組織の所有権、請求権、管理能力に応じて、クラウド デプロイのサブスクリプション設計とアカウント構造を計画する必要があります。 コンテナーのスコープがサブスクリプションに設定されているため、サブスクリプションの設計はコンテナーの設計に大きく影響します。 さまざまなサブスクリプションの設計戦略とそれを使用するときのガイダンスについては、こちらをご覧ください。

バックアップ要件を文書化する

Azure Backup を開始するには、ご自身のバックアップの必要性を計画します。 完全なバックアップ戦略について考えていく際に、ご自身で確認する必要がある検討事項をいくつか次に示します。

保護が必要なワークロードの種類

コンテナーを設計するには、一元化/分散化された操作モードが必要かどうかを確認します。

必要なバックアップの細分性

アプリケーションやクラッシュの整合性を確保するかどうか、ログのバックアップを行うかどうかを決めます。

コンプライアンス要件

セキュリティ標準や個別のアクセス境界を適用する必要があるかどうかを確認します。

必要な RPO、RTO

バックアップの頻度と復元速度を決めます。

データ所在地の制限

必要なデータ持続性に対するストレージの冗長性を決めます。

必要なバックアップ データ保持期間

バックアップされたデータをストレージに保持する期間を決めます。

アーキテクチャ

ワークロード

Azure Backup では、さまざまなワークロード (オンプレミスとクラウド) のデータ保護が可能になります。 これは、Azure の安全で信頼性の高い組み込みのデータ保護メカニズムです。 管理のオーバーヘッドを発生させることなく、複数のワークロードにシームレスに保護を拡大できます。 これを有効にする自動化チャネルも複数あります (PowerShell、CLI、Azure Resource Manager テンプレート、REST API などを使用)。

• スケーラブルで永続的な、セキュリティで保護されたストレージ: Azure Backup では、組み込みのセキュリティおよび高可用性機能を備えた信頼性の高い BLOB ストレージを使用します。 バックアップ データとして、LRS、GRS、または RA-GRS ストレージを選択できます。

• ワークロードのネイティブ統合: Azure Backup では、エージェントのデプロイ、新しいスクリプトの作成、ストレージのプロビジョニングを行うための自動化やインフラストラクチャの管理を必要とせずに、Azure ワークロード (VM、SAP HANA、Azure VM 内の SQL、Azure Files など) とのネイティブ統合を実現します。

サポートされるシナリオについて詳しくは、こちらをご覧ください。

データ プレーン

• ストレージの自動管理: Azure Backup では、バックアップ データのストレージ アカウントのプロビジョニングと管理を自動化することで、バックアップ データの増加に伴って規模を拡大できるようにします。

• 悪意のある削除からの保護: バックアップの論理的な削除によって、バックアップの誤削除や悪意のある削除の企てから保護します。 削除されたバックアップ データは 14 日間無料で保存され、この状態から復旧することができます。

• セキュリティで保護された暗号化バックアップ: Azure Backup を使用すると、Azure ロールベースのアクセス制御 (Axure RBAC) や暗号化などの Azure プラットフォームの組み込みのセキュリティ機能を活用して、バックアップ データを安全な方法で確実に格納できます。

• バックアップ データのライフサイクル管理: Azure Backup では、保持ポリシーに準拠するように古いバックアップ データを自動的にクリーンアップします。 オペレーション ストレージからコンテナー ストレージにデータを階層化することもできます。

• 保護された重要な操作: Azure Backup のマルチユーザー承認 (MUA) を使用すると、Recovery Services コンテナーに対する重要な操作に保護レイヤーを追加できます。

管理プレーン

• アクセスの制御:コンテナー (Recovery Services コンテナーと Backup ボールト) により、管理機能が提供されます。これには、Azure portal、バックアップ センター、コンテナー ダッシュボード、SDK、CLI のほか、REST API でもアクセスすることができます。 これは Azure ロールベースのアクセス制御 (Azure RBAC) の境界でもあり、バックアップへのアクセスを、承認されたバックアップ管理者のみに制限するオプションが提供されます。

• ポリシー管理: 各コンテナー内の Azure Backup ポリシーでは、バックアップをトリガーすべきタイミングやバックアップを保持する必要がある期間を定義します。 また、これらのポリシーを管理して、複数の項目に適用することもできます。

• 監視とレポート: Azure Backup は Log Analytics と統合されており、Workbooks を使用してレポートを表示する機能も提供します。

• スナップショット管理: Azure Backup では、一部の Azure ネイティブ ワークロード (VM と Azure Files) のスナップショットを取得して管理し、それらのスナップショットからの高速復元を可能にします。 このオプションを使用すると、元のストレージにデータを回復する時間を大幅に短縮できます。

コンテナーに関する考慮事項

Azure Backup では、コンテナー (Recovery Services コンテナーと Backup ボールト) を使用して、バックアップを調整、管理し、バックアップ データを格納しています。 有効なコンテナー設計によって、組織はビジネスの優先順位が維持されるように Azure のバックアップ資産を整理および管理するための構造を確立できます。 コンテナーを作成する場合は、次のガイドラインを考慮してください。

1 つまたは複数のコンテナー

1 つのコンテナーまたは複数のコンテナーを使用して、ご自身のバックアップを整理および管理するには、次のガイドラインをご覧ください。

• 複数のリージョンのリソースをグローバルに保護する: 北米、ヨーロッパ、アジアでグローバルに事業を展開していて、リソースが米国東部、英国西部、東アジアにデプロイされている場合。 Azure Backup 要件の 1 つとして、コンテナーは、バックアップするリソースと同じリージョンに配置する必要があります。 したがって、ご自身のリソースを保護するには、リージョンごとに 1 つ、合計 3 つのコンテナーを作成する必要があります。

• さまざまな事業単位や部署にわたるリソースを保護する: ご自身の事業が 3 つの個別の事業単位 (BU) ごとに運営されており、それぞれの事業単位に 5 つの部門 (財務、営業、人事、研究開発、マーケティング) があるとします。 ビジネス ニーズによって、各部門が独自のバックアップや復元を管理しアクセスすること、そして、それぞれが自分の部門の使用状況やコストを追跡できることが求められる場合があります。 こうしたシナリオでは、BU の部門ごとに 1 つのコンテナーを作成することをお勧めします。 これにより、組織全体で 15 のコンテナーが作成されます。

• さまざまなワークロードを保護する: さまざまな種類のワークロード (150 個の VM、40 個の SQL データベース、70 個の PostgreSQL データベースなど) を保護する場合は、ワークロードの種類ごとに個別のコンテナーを作成することをお勧めします (この例では、VM、SQL データベース、PostgreSQL データベース、それぞれのワークロードに対して 1 つ、つまり 3 つのコンテナーを作成する必要があります)。 これにより、(Azure ロールベースのアクセス制御 - Azure RBAC を使用して) 直接の利害関係者にアクセスを付与し、ユーザーのアクセス境界を分離できるようになります。

• 複数の環境内で実行されているリソースを保護する: 運用環境、非運用環境、開発者環境など、複数の環境で作業する必要がある場合は、それぞれ個別にコンテナーを作成することをお勧めします。

• 多数 (1000 個以上) の Azure VM を保護する: バックアップする VM が 1,500 個あるとします。 Azure Backup では、1 つのコンテナーに 1,000 個の Azure VM しかバックアップできません。 このシナリオでは、2 つの異なるコンテナーを作成し、それぞれのコンテナーに 1000 個と 500 個の VM としてリソースを配布するか、上限を考慮して任意の組み合わせで配布できます。

• 多数 (2,000 個以上) の多様なワークロードを保護する: 大規模なバックアップを管理しながら、Azure VM と、その Azure VM で実行されている SQL や SAP HANA データベースなどの他のワークロードを保護します。 たとえば、1,300 個の Azure VM と 2,500 個の SQL データベースを保護するとします。 コンテナーの制限により、各コンテナーには 2,000 個のワークロードをバックアップできます (VM 数は 1,000 個に制限されています)。 したがって、数字的には 1 つのコンテナーに 2,000 個のワークロード (1000 VM + 1000 SQL データベース) をバックアップし、別のコンテナーに 1,800 個のワークロード (300 VM + 1,500 SQL データベース) を保存できます。

  ただし、アクセス境界を定義できず、ワークロードが互いに切り離されないため、この種類の分離はお勧めしません。 このため、ワークロードを正しく配布するには、4 つのコンテナー、つまり VM をバックアップする 2 つのコンテナー (1000 VM + 300 VM) と、SQL データベースをバックアップする他の 2 つのコンテナー (2000 データベース + 500 データベース) を作成します。

• これは次の方法で管理できます。

  • バックアップ センターを使用すると、1 つのウィンドウですべてのバックアップ タスクを管理できます。 こちらを参照してください。
  • コンテナー間で一貫したポリシーが必要な場合は、Azure Policy を使用して、複数のコンテナーにバックアップ ポリシーを伝達できます。 'deployifnotexists' 効果を使用して複数のコンテナーにバックアップ ポリシーを伝達するカスタムの Azure Policy 定義を作成できます。 この Azure Policy 定義を特定のスコープ (サブスクリプションまたは RG) に割り当てることもでき、それによって Azure Policy 割り当てのスコープ内にあるすべての Recovery Services コンテナーに "バックアップ ポリシー" リソースがデプロイされます。 バックアップ ポリシーの設定 (バックアップ頻度、保有期間など) は、Azure Policy 割り当てのパラメーターとしてユーザーが指定する必要があります。

• 組織のフットプリントが増加するにつれ、次のような理由により、サブスクリプション間でワークロードを移動することが必要になる場合があります。バックアップ ポリシー別の配置、コンテナーの統合、コスト削減のための低い冗長性に基づいたトレードオフ (GRS から LRS への移行) です。 Azure Backup では、Recovery Services コンテナーを Azure のサブスクリプション間で移動することも、同じサブスクリプション内の別のリソース グループに移動することもできます。 こちらを参照してください。

既定の設定を確認する

コンテナーでバックアップを構成する前に、要件に合わせて [ストレージ レプリケーションの種類] と [セキュリティ設定] の既定の設定を確認してください。

• 既定では、 [ストレージ レプリケーションの種類] は geo 冗長 (GRS) に設定されています。 バックアップを構成すると、変更オプションは無効になります。 設定を確認および変更するには、こちらの手順に従ってください。

  • non-prod、dev など、重要ではないワークロードは、LRS ストレージ レプリケーションに適しています。

  • ゾーン冗長ストレージ (ZRS) は、高いデータ持続性とデータ所在地に適したストレージ オプションです。

  • geo 冗長ストレージ (GRS) は、ミッション クリティカルなワークロード、たとえば運用環境で実行されているワークロードにお勧めします。これにより、リージョン全体で障害が発生した場合や、プライマリ リージョンを復旧できない災害が発生した場合に、データが完全に失われるのを防ぎ、データが保護されます。

• [論理的な削除] は、誤削除や悪意のある削除からバックアップ データを保護するために、新しく作成されたコンテナーでは既定で [有効] になっています。 設定を確認および変更するには、こちらの手順に従ってください。

• [リージョンをまたがる復元] では、Azure VM をセカンダリ リージョン (Azure のペアになっているリージョン) に復元できます。 このオプションを使用すると、監査またはコンプライアンスの要件を満たす訓練や、プライマリ リージョンで障害が発生した場合に VM またはそのディスクを復元する訓練を実施できます。 CRR は、任意の GRS コンテナーのオプトイン機能です。 こちらを参照してください。

• コンテナーの設計を終了する前に、コンテナーのサポート マトリックスを確認して、設計の選択肢に影響を与えたり、選択肢を制限したりする可能性のある要因を理解します。

バックアップ ポリシーに関する考慮事項

Azure バックアップ ポリシーには、次の 2 つのコンポーネントがあります。スケジュール (バックアップを作成するタイミング) と 保有期間 (バックアップを保持する期間) です。 このポリシーは、バックアップされるデータの種類、RTO/RPO の要件、運用または規制コンプライアンスのニーズ、ワークロードの種類 (VM、データベース、ファイルなど) に基づいて定義できます。 詳細情報

バックアップ ポリシーを作成する場合は、次のガイドラインを考慮してください。

スケジュールに関する考慮事項

バックアップ ポリシーのスケジュールを設定するときは、次の点を考慮してください。

• ミッション クリティカルなリソースについては、最も頻繁に利用できる自動バックアップが毎日行われるようにスケジュールし、RPO を小さくしてみます。 詳細情報

  拡張機能を使用して 1 日に複数回 Azure VM のバックアップを作成する必要がある場合は、次のセクションの回避策をご覧ください。

• スケジュールの開始時刻、頻度、リテンション期間の設定を同じにする必要があるリソースについては、1 つのバックアップ ポリシーに基づいてグループ化します。

• スケジュールされたバックアップ開始時刻を、ピーク時以外の運用環境アプリケーション時間内にすることをお勧めします。 たとえば、毎日の自動バックアップは、リソースの使用率が高い日中ではなく、夜間 (午前 2 時から 3 時頃) に行われるようにスケジュールすることをお勧めします。

• バックアップ トラフィックを分散するために、異なる VM を 1 日の異なる時間にバックアップすることをお勧めします。 たとえば、500 個の VM を同じリテンション期間の設定でバックアップするには、5 つの異なるポリシーを作成し、それぞれ 100 個の VM に関連付けて、数時間の間隔でスケジュールを設定することをお勧めします。

保有期間に関する考慮事項

• 短期保有には "毎日" を使用できます。 "毎週"、"毎月"、または "毎年" のバックアップ ポイントに対するデータ保持は、長期保有と呼ばれます。

• 長期保有:

  • 計画済み (コンプライアンス要件) - 現在の時刻から数年後もデータが必要であることが事前にわかっている場合は、長期保有を使用します。 Azure Backup は、スナップショットと Standard 層に加えて、アーカイブ層での長期保有ポイントのバックアップをサポートしています。 アーカイブ層とリテンション期間の構成でサポートされているワークロードについて詳しくは、こちらをご覧ください。
  • 計画外 (オンデマンド要件) - 事前にわからない場合は、特定のカスタム保有期間設定でオンデマンドを使用します (これらのカスタム保有期間設定は、ポリシー設定の影響を受けません)。

• カスタム保有期間によるオンデマンド バックアップ - バックアップ ポリシーでスケジュールされていないバックアップを作成する必要がある場合は、オンデマンド バックアップを使用できます。 これは、スケジュールされたバックアップに適合しないバックアップや、きめ細かいバックアップ (スケジュールされたバックアップでは 1 日に 1 回のバックアップしか許可されていないため、1 日に複数回行われる IaaS VM のバックアップなど) を作成する場合に役立つことがあります。 スケジュールされたポリシーで定義されている保有期間ポリシーは、オンデマンド バックアップには適用されないことに注意してください。

バックアップ ポリシーを最適化する

• ビジネス要件の変化に応じて、保有期間の延長または短縮が必要になる場合があります。 その場合、次のことが予想されます。

  • リテンション期間が延長された場合、既存の復旧ポイントは、新しいポリシーに従ってマーキングおよび保持されます。
  • 保有期間が短縮された場合、復旧ポイントは、次回のクリーンアップ ジョブで排除対象としてマーキングされて、その後削除されます。
  • 保有期間の最新の規則は、すべての保有ポイント (オンデマンドの保有ポイントを除く) に適用されます。 そのため、保有期間が延長された場合 (100 日間など)、バックアップが作成され、その後に保有期間が短縮されると (100 日間から 7 日間に短縮されるなど)、すべてのバックアップ データは、最後に指定された保有期間 (つまり 7 日間) に従って保持されます。

• Azure Backup により、"バックアップの保護と管理を止める" という柔軟性が得られます。

  • 保護を停止してバックアップ データを保持します。 データ ソース (VM、アプリケーション) を廃止または使用停止にしていても、監査またはコンプライアンスのためにデータを保持する必要がある場合は、このオプションを使用して、今後のすべてのバックアップ ジョブによるデータ ソースの保護を停止し、バックアップ済みの復旧ポイントを保持できます。 その後、VM の保護を復元または再開できます。

  • 保護を停止してバックアップ データを削除します。 このオプションでは、将来のすべてのバックアップ ジョブによる VM の保護を停止し、すべての復元ポイントを削除します。 VM を復元することも、[バックアップの再開] オプションを使用することもできなくなります。

  • (データを保持した状態で停止されたデータ ソースの) 保護を再開した場合は、保持ルールが適用されます。 期限切れの復旧ポイントは、(スケジュールされた時刻に) 削除されます。

• ポリシーの設計を完了する前に、設計の選択に影響する可能性がある次の要因に注意することが重要です。

  • バックアップ ポリシーのスコープはコンテナーです。
  • ポリシーあたりの項目数には制限があります (100 VM など)。 規模を拡大するには、同じスケジュールまたは異なるスケジュールで重複するポリシーを作成します。
  • 特定の復旧ポイントを選択して削除することはできません。
  • スケジュールされたバックアップを完全に無効にして、データ ソースを保護された状態に保つことはできません。 ポリシーを使用して構成できる最も頻度の低いバックアップは、週単位でスケジュールされたバックアップを 1 つ持つことです。 別の方法としては、データを保持して保護を停止し、バックアップを作成するたびに保護を有効にして、オンデマンド バックアップを作成した後で、保護をオフにしますが、バックアップ データは保持します。 こちらを参照してください。

セキュリティに関する考慮事項

バックアップ データを保護し、ビジネスのセキュリティ ニーズを満たせるように、Azure Backup では重要なデータやシステムの意図的な攻撃と悪用に備えて、機密性、整合性、および可用性を保証しています。 Azure Backup ソリューションのセキュリティに関する次のガイドラインを考慮してください。

Azure ロールベースのアクセス制御 (Azure RBAC) を使用した認証と承認

• Azure のロールベースのアクセス制御 (Azure RBAC) を使用すると、アクセスをきめ細かく管理し、チーム内の職務を分離し、それぞれのジョブの実行に必要なアクセス権のみをユーザーに付与することができます。 こちらを参照してください。

• バックアップするワークロードが複数存在し (Azure VM、SQL データベース、PostgreSQL データベースなど)、そのバックアップを管理する利害関係者が複数いる場合、自分が担当するリソースにのみユーザーがアクセスできるように、それぞれの責任を切り離すことが重要です。 Azure のロールベースのアクセス制御 (Azure RBAC) を使用すると、アクセスをきめ細かく管理し、チーム内の職務を分離し、それぞれのジョブの実行に必要な種類のアクセスのみをユーザーに付与することができます。 詳細情報

• また、特定のタスクの実行に必要な最小限のアクセス権を付与することで、職務を分離することもできます。 たとえば、ワークロード監視の担当者は、バックアップ ポリシーを変更したりバックアップ項目を削除したりするためのアクセス権を持つべきではありません。 Azure Backup では、バックアップの管理操作を制御する 3 つの組み込みロールが提供されます。バックアップ共同作成者、バックアップ オペレーター、およびバックアップ リーダーです。 詳細については、ここを参照してください。 Azure VM、SQL/SAP HANA データベース、Azure ファイル共有の各バックアップ操作に必要な最小限の Azure ロールについては、こちらのガイドを参照してください。

• Azure ロールベースのアクセス制御 (Azure RBAC) では、個別の要件に基づいてカスタム ロールを柔軟に構築することもできます。 特定の操作に推奨されるロールの種類がわからない場合は、Azure ロールベースのアクセス制御 (Azure RBAC) によって提供される組み込みロールを使用して、開始することができます。

  次の図は、さまざまな Azure 組み込みロールのしくみについて説明しています。

  

  • 上の図の User2 と User3 はバックアップ閲覧者です。 そのため、付与されているのは、バックアップ監視とバックアップ サービス閲覧のみの権限です。

  • アクセスのスコープは以下のとおりです。

    • User2 がアクセスできるのは Subscription1 のリソースのみ、User3 がアクセスできるのは Subscription2 のリソースのみです。
    • User4 はバックアップ オペレーターです。 バックアップ リーダーの機能に加えて、バックアップの有効化、オンデマンド バックアップのトリガー、復元のトリガーの権限を持ちます。 ただし、このシナリオでは、そのスコープは Subscription2 のみに制限されています。
    • User1 はバックアップ共同作成者です。 コンテナーの作成、バックアップ ポリシーの作成/変更/削除、バックアップ停止の権限と持ち、バックアップ オペレーターの機能を備えています。 ただし、このシナリオでは、そのスコープは Subscription1 のみに制限されています。

• Recovery Services コンテナーによって使用されるストレージ アカウントは分離されており、悪意のある目的でユーザーがアクセスすることはできません。 アクセスが許可されるのは、復元などの Azure Backup 管理操作だけです。

転送中および保存中のデータの暗号化

暗号化によりお使いのデータが保護され、組織のセキュリティとコンプライアンスのコミットメントを満たすのに役立ちます。

• Azure 内では、Azure ストレージとコンテナー間を転送中のデータは HTTPS によって保護されます。 このデータは、Azure ネットワーク内に残されます。

• バックアップ データは、Microsoft マネージド キーを使用して自動的に暗号化されます。 あるいは、独自のキー (カスタマー マネージド キーとも呼ばれる) を使用することもできます。 また、バックアップに CMK 暗号化を使用しても、追加のコストは発生しません。 ただし、キーが保存されている Azure Key Vault を使用するとコストが発生します。これは、データ セキュリティの強化と引き換えに発生する妥当な支出です。

• Azure Backup では、OS またはデータ ディスクを Azure Disk Encryption (ADE) で暗号化している Azure VM のバックアップと復元をサポートしています。 詳細情報

論理的な削除による意図しない削除からのバックアップ データの保護

コンテナーに保存されているミッション クリティカルなバックアップ データが誤って削除されてしまった経験はあると思います。 悪意のあるアクターが、運用バックアップ項目を削除することもあります。 このようなリソースの再構築にはコストも時間もかかることが多く、重要なデータが損失することもあります。 Azure Backup では、論理的な削除機能により、削除されたリソースを復旧できるようにして、誤った削除や悪意のある削除からデータを保護します。

論理的な削除では、ユーザーが (VM、SQL Server データベース、Azure ファイル共有、SAP HANA データベースの) バックアップを削除した場合、バックアップ データは追加で 14 日間保持されるので、データを失うことなくそのバックアップ項目を回復できます。 バックアップ データが論理的な削除状態にあるこの追加の 14 日間の保有期間中は、コストは発生しません。 詳細情報

マルチユーザー認可 (MUA)

管理者の不正行為によりシステムが危険にさらされた場合、データをどのように保護しますか?

バックアップ データへの特権アクセスを持つ管理者はだれでも、修復不能な破損をシステムに与える可能性があります。 悪意のある管理者は、ビジネスに不可欠なすべてのデータを削除することも、セキュリティ対策をすべて無効にしてシステムをサイバー攻撃にさらすこともできます。

Azure Backup には、このような悪意のある管理者攻撃からユーザーを保護するためのマルチユーザー認可 (MUA) 機能が用意されています。 マルチユーザー認可は、すべての特権的/破壊的操作がセキュリティ管理者の承認を得た後にのみ行われるようにすることで、悪意のある管理者が破壊的な操作 (論理的な削除の無効化) を行うことを防ぎます。

ランサムウェア対策

• バックアップ データに対する操作はすべて、Azure ロールベースのアクセス制御 (Azure RBAC) と MUA で保護できる Recovery-Services コンテナーまたは Backup ボールトを介してのみ実行できるため、悪意のあるアクターが、Azure Backup データに直接アクセスして、暗号化することはできません。

• バックアップ データ上で論理的な削除を有効にすると (既定で有効)、削除されたデータは 14 日間保持されます (無料)。 論理的な削除の無効化は、MUA を使用して保護できます。

• より長いリテンション期間 (週、月、年) を使用して、(ランサムウェアによって暗号化されない) クリーン バックアップが途中で期限 切れにならないようにします。ソース データに対するこうした攻撃を早期に検出し、軽減するための戦略もあります。

疑わしいアクティビティの監視とアラート

他のユーザーがシステムに侵入し、論理的な削除を無効にするなど、悪意を持ってセキュリティ メカニズムをオフにしようとする場合があります。また、バックアップ リソースの削除といった破壊的な操作を試みることもあります。

Azure Backup は、アラートの上にアクション ルールを作成して、優先通知チャネル (メール、ITSM、Webhook、Runbook、sp pn) を介して重要なアラートを送信することで、このようなインシデントに対するセキュリティを提供します。 詳細情報

ハイブリッド バックアップを保護するためのセキュリティ機能

Azure Backup サービスは、Microsoft Azure Recovery Services (MARS) エージェントを使用して、ファイル、フォルダー、およびボリュームまたはシステム状態をオンプレミスのコンピューターから Azure にバックアップおよび復元します。 MARS では、次のようなセキュリティ機能が提供されるようになりました。Azure Backup にアップロードする前に暗号化され、Azure Backup からダウンロードした後に暗号化解除されるようにするためにパスフレーズを使用し、削除されたバックアップ データは削除日から追加で 14 日間保持され、重要な操作 (パスフレーズの変更など) は有効な Azure 資格情報を持つユーザーのみが実行できます。 こちらを参照してください。

ネットワークに関する考慮事項

Azure Backup では、ワークロードのデータを Recovery Services コンテナーに移動する必要があります。 Azure Backup には、バックアップ データの漏洩 (ネットワーク上での中間者攻撃など) を防ぐ機能がいくつか用意されています。 次のガイドラインを考慮してください。

インターネット接続

• Azure VM バックアップ: ストレージと Azure Backup サービス間の必要な通信やデータ転送はすべて Azure ネットワーク内で行われ、仮想ネットワークにアクセスする必要はありません。 そのため、セキュリティで保護されたネットワーク内に配置された Azure VM のバックアップでは、IP や FQDN へのアクセスを許可する必要がありません。

• Azure VM 上の SAP HANA データベース、Azure VM 上の SQL Server データベース: Azure Backup サービス、Azure Storage、Microsoft Entra ID への接続が必要です。 これは、プライベート エンドポイントを使用するか、必要なパブリック IP アドレスまたは FQDN へのアクセスを許可することによって実現できます。 必要な Azure サービスへの適切な接続を許可しないと、データベースの検出、バックアップの構成、バックアップの実行、データの復元などの操作の失敗につながる可能性があります。 NSG タグ、Azure Firewall、HTTP プロキシを使用しているときのネットワークの完全なガイダンスについては、これらの SQL と SAP HANA の記事をご覧ください。

• ハイブリッド: MARS (Microsoft Azure Recovery Services) エージェントでは、すべての重要な操作 (インストール、構成、バックアップ、復元) にネットワーク アクセスが必要です。 MARS エージェントは、パブリック ピアリング (古い回線で使用可能) と Microsoft ピアリングを使用して Azure ExpressRoute 経由で、プライベート エンドポイントを使用して、または適切なアクセス制御によるプロキシ/ファイアウォール経由で、Azure Backup サービスに接続できます。

安全なアクセスのためのプライベート エンドポイント

重要なデータは Azure Backup を使って保護されていますが、リソースがパブリック インターネットからアクセスできることは、やはり望ましくありません。 特に、銀行や金融機関の場合は、High Business Impact (HBI) データを保護するための厳しいコンプライアンスおよびセキュリティ要件があります。 医療業界にも、厳格なコンプライアンス規則があります。

こうしたニーズすべてに対応するために、Azure プライベート エンドポイントを使用します。これは、Azure Private Link を使用するサービスにプライベートかつ安全に接続するためのネットワーク インターフェイスです。 プライベート エンドポイントを使用することをお勧めします。これにより、お使いの仮想ネットワークから、Azure Backup または Azure Storage の IP と FQDN を許可リストに追加しなくても、安全にバックアップと復元を行うことができます。

仮想ネットワーク内で Azure Backup のプライベート エンドポイントを作成して使用する方法について詳しくは、こちらをご覧ください。

• プライベート エンドポイントは、コンテナーに対して有効にした場合、Azure VM、MARS エージェント、DPM/MABS のバックアップにおける SQL および SAP HANA ワークロードのバックアップと復元にのみ使用されます。 コンテナーは、他のワークロードのバックアップにも使用できます (ただし、プライベート エンドポイントは必要ありません)。 SQL および SAP HANA ワークロードのバックアップと、MARS エージェントと DPM/MABS サーバーを使用したバックアップに加えて、プライベート エンドポイントは Azure VM バックアップの場合にファイルの復旧を実行する場合にも使用されます。 こちらを参照してください。

• 現在、Microsoft Entra ID はプライベート エンドポイントをサポートしていません。 したがって、Microsoft Entra ID に必要な IP と FQDN には、Azure VM でのデータベースのバックアップおよび MARS エージェントを使用したバックアップを実行するときに、セキュリティで保護されたネットワークからの発信アクセスが許可される必要があります。 また、必要に応じて、NSG タグと Azure Firewall タグを使用して、Microsoft Entra ID へのアクセスを許可することもできます。 前提条件の詳細についてはこちらを参照してください。

ガバナンスに関する考慮事項

Azure におけるガバナンスは、主に Azure Policy と Azure Cost Management で実装されます。 Azure Policy を使用すると、ポリシーの定義を作成、割り当て、および管理して、お使いのリソースに規則を適用できます。 この機能によって、リソースを継続的に企業の標準に準拠させることができます。 Azure Cost Management では、クラウドの使用状況と、Azure リソースおよび他のクラウド プロバイダーに対する支出を追跡することができます。 また、Azure Price Calculator や Azure Advisor などのツールは、コスト管理プロセスで重要な役割を果たします。

新しくプロビジョニングされたバックアップ インフラストラクチャを Azure Policy を使用して大規模に自動構成する

• 新しいインフラストラクチャがプロビジョニングされ、新しい VM が作成されたら必ず、バックアップ管理者は、それを確実に保護する必要があります。 VM が 1 つまたは 2 つの場合、バックアップは簡単に構成できます。 しかし、数百、数千もの VM を大規模に構成する必要がある場合は複雑になります。 バックアップの構成プロセスを簡略化するために、Azure Backup には、バックアップ資産を管理するための組み込みの Azure ポリシー セットが用意されています。

• ポリシーを使用して VM でのバックアップを自動的に有効にする (中央バックアップ チーム モデル): アプリケーション チーム間のバックアップを管理する中央バックアップ チームが組織にある場合は、このポリシーを使用して、VM と同じサブスクリプションと場所にある既存の中央 Recovery Services コンテナーへのバックアップを構成できます。 特定のタグを含む VM をポリシー スコープに含めたり、スコープから除外したりできます。 詳細については、こちらを参照してください。

• ポリシーを使用して VM でのバックアップを自動的に有効にする (バックアップがアプリケーション チームに所有される場合): アプリケーションを専用のリソース グループに整理し、同じコンテナーでバックアップする場合は、このポリシーを使用してこのアクションを自動的に管理します。 特定のタグを含む VM をポリシー スコープに含めたり、スコープから除外したりできます。 詳細については、こちらを参照してください。

• 監視ポリシー: リソースのバックアップ レポートを生成するには、新しいコンテナーを作成するときに診断設定を有効にします。 多くの場合、コンテナーごとに手動で診断設定を追加することは面倒な作業です。 そこで、Azure の組み込みポリシーを利用して、Log Analytics を宛先として、各サブスクリプションやリソース グループのすべてのコンテナーに対して、診断の設定を大規模に構成することができます。

• 監査専用ポリシー: Azure Backup には、バックアップ構成がない VM を特定する監査専用ポリシーも用意されています。

Azure Backup のコストに関する考慮事項

Azure Backup サービスは、コストを効果的に管理しながら、BCDR (事業継続とディザスター リカバリー) ビジネス要件を満たす柔軟性を備えています。 次のガイドラインを考慮してください。

• 料金計算ツールを使用すると、さまざまな手段を調整してコストを評価および最適化することができます。 詳細情報

• バックアップ ポリシーを最適化します。

  • ワークロード アーキタイプ (ミッション クリティカル、重要ではない、など) に基づいてスケジュールとリテンション期間の設定を最適化します。
  • インスタント復元のリテンション期間の設定を最適化します。
  • Azure Backup 内のワークロード別にサポートされているバックアップの種類 (完全、増分、ログ、差分) を取りながら、要件に合った適切なバックアップの種類を選択します。

• ディスクの選択的なバックアップによるバックアップ ストレージ コストの削減: ディスクの除外機能により、効果的かつコスト効率に優れた方法で重要なデータを選択的にバックアップできます。 たとえば、VM に接続されている一部のディスクをバックアップする必要がないときは、1 つのディスクのみをバックアップすることができます。 これは、バックアップ ソリューションが複数ある場合にも役立ちます。 たとえば、ワークロードのバックアップ ソリューション (Azure VM バックアップでは SQL Server データベース) を使用してデータベースまたはデータをバックアップするには、選択したディスクに対して Azure VM レベルのバックアップを使用します。

• インスタント復元機能による復元の高速化と RTO を最小化: Azure Backup は、Azure VM のスナップショットを取り、ディスクと共に保存することで、復旧ポイントの作成を促進し、復元操作を高速化します。 これはインスタント復元と呼ばれます。 この機能では、復元時間を削減して、これらのスナップショットから復元操作を行うことができます。 それにより、コンテナーからデータを変換して元の場所にコピーするために必要な時間が削減されます。 したがって、この期間に取得されたスナップショットについては、ストレージ コストが発生します。 Azure Backup のインスタント復元機能について詳しくは、こちらをご覧ください。

• 適切なレプリケーションの種類の選択: 既定では、Azure Backup コンテナーの [ストレージ レプリケーションの種類] は geo 冗長 (GRS) に設定されています。 項目の保護を開始した後、このオプションを変更することはできません。 geo 冗長ストレージ (GRS) は、ローカル冗長ストレージ (LRS) よりもデータの持続性レベルが高いため、リージョンをまたがる復元の使用を選択でき、コストは高くなります。 低コストと高いデータ持続性とのトレードオフを確認し、ご自身のシナリオに最も適したオプションを選択します。 詳細情報

• 長期保有 (LTR) 用のアーカイブ層を選択してコストを削減: ほとんどアクセスしない古いバックアップ データを、コンプライアンス上の理由から長期間 (たとえば 99 年) 保存しなければならないというシナリオについて考えてみます。 このような膨大なデータを Standard 層に保存するとコストがかかり、経済的ではありません。 ストレージ コストを最適化するために、Azure Backup にはアーカイブ層が用意されています。これはバックアップ データの長期保有 (LTR) のために特別に設計されたアクセス層です。

• VM 内で実行されているワークロードと VM 自体の両方を保護している場合は、この二重保護が必要かどうかを確認してください。

監視とアラートに関する考慮事項

バックアップ ユーザーまたは管理者は、すべてのバックアップ ソリューションを監視し、重要なシナリオについて通知を受け取ることができます。 このセクションでは、Azure Backup サービスによって提供される監視と通知の機能について詳しく説明します。

モニター

• Azure Backup には、バックアップの構成、バックアップ、復元、バックアップの削除などの操作のために、組み込みのジョブ監視が用意されています。 これはコンテナーを対象としており、1 つのコンテナーの監視に最適です。 こちらを参照してください。

• 操作アクティビティを大規模に監視する必要がある場合は、バックアップ エクスプローラーによってバックアップ資産全体の集約ビューが提供され、詳細なドリルダウン分析やトラブルシューティングが可能になります。 これは、単一の一元化された場所を提供する組み込み型の Azure Monitor ブックであり、テナント、場所、サブスクリプション、リソース グループ、コンテナーにわたる Azure 上のバックアップ資産全体で操作アクティビティを監視するのに役立ちます。 こちらを参照してください。

  • これを使用すると、バックアップ用に構成されていないリソースを特定し、増大する資産に含まれている重要なデータの保護を欠かさずに実行できるようになります。
  • ダッシュボードには、過去 7 日間 (最長) の操作アクティビティが表示されます。 このデータを保持する必要がある場合は、Excel ファイルとしてエクスポートして保持することができます。
  • Azure Lighthouse を使用している場合は、複数のテナントの情報を表示して、境界のない監視を有効にすることができます。

• 長期間にわたる操作アクティビティを保持して表示する必要がある場合は、レポートを使用します。 バックアップ管理者が一般的に求めるものは、長期間にわたるデータに基づいてバックアップに関する分析情報を得ることです。 このようなソリューションのユース ケースには、次のようなものがあります。

  • 使用されるクラウド ストレージの割り当てと予測。
  • バックアップおよび復元の監査。
  • さまざまな細分性レベルで主要な傾向を特定する。

• さらに、次の点も考慮する必要があります。

  • データ (ジョブ、ポリシーなど) を Log Analytics ワークスペースに送信できます。 これにより、Azure Monitor ログの機能が有効になり、データを Azure Monitor で収集されたその他の監視データと関連付けたり、複数の Azure サブスクリプションおよびテナントのログ エントリを 1 か所に統合して、まとめて分析できるようにしたり、ログ クエリを使用して複雑な分析を実行したり、ログ エントリに関する詳細な分析情報を取得したりすることができます。 こちらを参照してください。
  • Azure イベント ハブにデータを送信して、サードパーティの SIEM (セキュリティ情報イベント管理) やその他のログ分析ソリューションなど、Azure の外部にエントリを送信できます。 こちらを参照してください。
  • 監査、静的分析、またはバックアップのためにログ データを 90 日より長く保持する場合は、Azure Storage アカウントにデータを送信できます。 90 日以内でイベントを保持する必要があるだけの場合は、ストレージ アカウントへのアーカイブを設定する必要はありません (アクティビティ ログのイベントは Azure プラットフォームに 90 日間保持されるため)。 詳細情報。

警告

不明な問題が原因でバックアップ/復元ジョブが失敗した場合、 エンジニアにデバッグを割り当てるために、障害に関する通知をできるだけ早く受けたいと考えます。 だれかが悪意を持って、バックアップ項目の削除、論理的な削除の無効化といった破壊的な操作を行う場合もあります。このようなインシデントにもアラート メッセージが必要です。

このような重要なアラートを構成し、優先通知チャネル (メール、ITSM、Webhook、Runbook など) にルーティングすることができます。 Azure Backup は、さまざまなアラートや通知要件に対応するために、複数の Azure サービスと統合されています。

• Azure Monitor ログ (Log Analytics): Log Analytics ワークスペースにデータを送信するようにコンテナーを構成し、ワークスペース上でカスタム クエリを記述し、クエリの出力に基づいて生成されるアラートを構成することができます。 クエリの結果はテーブルやグラフ内に表示できます。また、Power BI や Grafana にエクスポートすることもできます (Log Analytics は、後のセクションで説明するレポート/監査機能の重要なコンポーネントでもあります)。

• Azure Monitor アラート: バックアップの失敗、復元の失敗、バックアップ データの削除など、特定の既定のシナリオでは、Azure Backup は既定で、表示されるアラートを Azure Monitor を使用して送信します。ユーザーが Log Analytics ワークスペースを設定する必要はありません。

• Azure Backup には、エラー、警告、および重要な操作に対応した、電子メール経由での組み込みのアラート通知メカニズムが備わっています。 アラートの生成時に通知を受け取る個別のメール アドレスや配布リストを指定できます。 また、それぞれのアラートについて個別に通知を受け取るか、アラートをまとめて 1 時間ごとのダイジェストとして通知を受け取るかを選択することもできます。

  • これらのアラートは、サービスによって定義され、制限付きのシナリオ (バックアップ/復元エラー、データを保持して保護を停止、データを削除して保護を停止など) のサポートを提供します。 こちらを参照してください。
  • 破壊的な操作 (データを削除して保護を停止など) が実行されると、アラートが生成され、Recovery Services コンテナー用に通知が構成されていない場合でも、サブスクリプションの所有者、管理者、共同管理者にメールが送信されます。
  • 一部のワークロードでは、高頻度でエラーが発生することがあります (SQL Server では 15 分ごとなど)。 エラーが発生するたびに生成されるアラートに打ちのめされないようにするために、アラートは統合されます。 こちらを参照してください。
  • 組み込みのアラートはカスタマイズできず、Azure portal で定義されている電子メールに制限されます。

• (成功したジョブのアラートなど) カスタム アラートを作成する必要がある場合は、Log Analytics を使用します。 Azure Monitor では、Log Analytics ワークスペースで独自のアラートを作成できます。 ハイブリッド ワークロード (DPM/MABS) では、データを LA に送信し、LA を使用して、Azure Backup でサポートされているワークロード間で共通のアラートを提供することもできます。

• 組み込みの Recovery Services コンテナーのアクティビティ ログを使用して通知を受け取ることもできます。 ただし、これは制限付きのシナリオをサポートしており、スケジュールされたバックアップなどの操作には適していません。この操作には、アクティビティ ログよりもリソース ログが適しています。 これらの制限事項と、Azure Backup で保護されているすべてのワークロードの大規模な監視とアラートに Log Analytics ワークスペースを使用する方法について詳しくは、こちらの記事をご覧ください。

失敗したバックアップ ジョブの自動再試行

障害エラーや停止シナリオの多くは一時的なもので、適切な Azure ロールベースのアクセス制御 (Azure RBAC) のアクセス許可を設定することで修復できます。または、バックアップまたは復元ジョブを再トリガーできます。 このような障害は簡単に解決できるため、時間をかけて、エンジニアが手動でジョブをトリガーしたり、関連する権限を割り当てたりするのを待つ必要はありません。 そのため、このシナリオをよりスマートに解決するには、失敗したジョブの再試行を自動化します。 これにより、障害からの復旧にかかる時間を最小限に抑えられます。 これを実現するには、Azure Resource Graph (ARG) を介して関連するバックアップ データを取得します。その後、PowerShell/CLI の是正手順と組み合わせます。

ARG と PowerShellを使用して、(コンテナー、サブスクリプション、テナント全体で) 失敗したすべてのジョブ のバックアップを再トリガーする方法については、次のビデオをご覧ください。

優先通知チャネルにアラートをルーティングする

一時的なエラーは修正できますが、永続的なエラーについては、詳細な分析を必要とする可能性があるものがあり、ジョブの再起動が有効なソリューションではないことがあります。 このようなエラーを確実かつ適切に追跡、修正する、独自の監視/チケット メカニズムがある場合があります。 こうしたシナリオを処理するために、アラート上にアクション ルールを作成して、アラートをご自身の優先通知チャネル (メール、ITSM、Webhook、Runbook など) にルーティングできます。

Azure Monitor を利用して、重大なアラートのさまざまな通知メカニズムを構成する方法については、次のビデオをご覧ください。

次のステップ

Azure Backup を使用するための出発点として、次の記事をお読みください。

• Azure Backup の概要
• よく寄せられる質問