データ保護の概要
Azure Storage は、Blob Storage と Azure Data Lake Storage のデータ保護を提供して、削除または上書きされたデータを回復する必要があるシナリオに対処できるようにします。 データを侵害する可能性があるインシデントが発生する前にデータを最適に保護する方法を検討することが重要です。 このガイドを使用すると、シナリオで必要なデータ保護機能とその実装方法を事前に決定できます。 削除または上書きされたデータを回復する必要がある場合、この概要には、シナリオに基づく対処方法についてのガイダンスも記載されています。
Azure Storage のドキュメントでは、データ保護とは、ストレージ アカウントとその中のデータが削除または変更されないようにしたり、削除または変更されたデータを復元したりするための戦略を指します。 また Azure Storage には、ハードウェアの問題や自然災害によるサービスの停止からデータを保護するための複数のレベルの冗長性など、ディザスター リカバリーのオプションも用意されています。 カスタマー マネージド (計画外) フェールオーバーは、プライマリ リージョンが使用できなくなった場合にセカンダリ リージョンにフェールオーバーできるようにするもう 1 つのディザスター リカバリー オプションです。 サービスの停止からデータを保護する方法の詳細については、「ディザスター リカバリー」を参照してください。
基本的なデータ保護に関する推奨事項
ストレージ アカウントとそれに含まれるデータの基本的なデータ保護の対象範囲を検討している場合は、最初に次の手順を実行することをお勧めします。
- Azure Resource Manager ロックをストレージ アカウントで構成して、アカウントが削除または構成変更されないようにします。 詳細情報
- ストレージ アカウントに対してコンテナーの論理的な削除を有効にして、削除されたコンテナーとその内容を回復します。 詳細情報
- BLOB の状態を定期的に保存します。
これらのオプションのほか、他のシナリオ用のデータ保護オプションについては、次のセクションで詳しく説明します。
これらの機能に関連するコストの概要については、「コストに関する考慮事項の概要」を参照してください。
データ保護オプションの概要
次の表は、一般的なデータ保護のシナリオに対して Azure Storage で使用できるオプションをまとめたものです。 状況に応じたシナリオを選択して、使用可能なオプションの詳細を確認してください。 階層型名前空間が有効になっているストレージ アカウントでは、現時点では一部の機能が利用できません。
| シナリオ | データ保護オプション | 推奨事項 | 保護の利点 | Data Lake Storage で使用可能か |
|---|---|---|---|---|
| ストレージ アカウントの削除または変更を防止します。 | Azure Resource Manager ロック 詳細情報 |
ストレージ アカウントが削除されないように、Azure Resource Manager ロックを使用してすべてのストレージ アカウントをロックします。 | ストレージ アカウントが削除または構成変更されないようにします。 アカウントのコンテナーまたは BLOB は削除または上書きから保護されません。 |
はい |
| 制御対象の期間中、BLOB のバージョンの削除を防止します。 | BLOB バージョンの不変ポリシー 詳細情報 |
たとえば、法律または規制コンプライアンス要件を満たすために、ビジネス クリティカルなドキュメントを保護するように個別の BLOB のバージョンの不変ポリシーを設定します。 | BLOB のバージョンが削除されたり、そのメタデータが上書きされたりしないように保護します。 上書き操作を行うと、新しいバージョンが作成されます。 少なくとも 1 つのコンテナーでバージョンレベルの不変性が有効になっている場合は、ストレージ アカウントも削除されないよう保護されます。 コンテナーに少なくとも 1 つの BLOB が存在する場合、コンテナーの削除は失敗します。 |
いいえ |
| 制御対象の期間中、コンテナーとその BLOB の削除または変更を防止します。 | コンテナーでの不変ポリシー 詳細情報 |
たとえば、法律または規制コンプライアンス要件を満たすために、ビジネス クリティカルなドキュメントを保護するようにコンテナーの不変ポリシーを設定します。 | コンテナーとその BLOB をすべての削除と上書きから保護します。 訴訟ホールドまたはロックされた時間ベースの保有ポリシーが有効になっている場合、ストレージ アカウントも削除から保護されます。 不変ポリシーが設定されていないコンテナーは、削除から保護されません。 |
はい |
| 指定された期間中、削除されたコンテナーを復元します。 | コンテナーの論理的な削除 詳細情報 |
すべてのストレージ アカウントに対してコンテナーの論理的な削除を有効にします。最小保有期間は 7 日間です。 BLOB のバージョン管理と BLOB の論理的な削除をコンテナーの論理的な削除と共に有効にして、コンテナー内の個々の BLOB を保護します。 異なる保有期間を必要とするコンテナーを別のストレージ アカウントに格納します。 |
保管期間中は、削除されたコンテナーとその内容を復元できます。 コンテナー レベルの操作 (コンテナーの削除など) のみを復元できます。 コンテナーの論理的な削除で、コンテナー内の個々の BLOB はその BLOB が削除されている場合は復元できません。 |
はい |
| BLOB が上書きされたときに、以前のバージョンでのその状態を自動的に保存します。 | BLOB バージョン管理 詳細情報 |
BLOB データを最適に保護する必要があるストレージ アカウントについては、コンテナーの論理的な削除と BLOB の論理的な削除と共に、BLOB のバージョン管理を有効にします。 コストを制限するために、バージョン管理を必要としない BLOB データを別のアカウントに格納します。 |
BLOB のあらゆる書き込み操作で、新しいバージョンを作成します。 現在のバージョンが削除または上書きされた場合、以前のバージョンから現在のバージョンの BLOB を復元できます。 | いいえ |
| 指定された期間中、削除された BLOB または BLOB バージョンを復元します。 | BLOB の論理的な削除 詳細情報 |
すべてのストレージ アカウントに対して BLOB の論理的な削除を有効にします。最小保有期間は 7 日間です。 BLOB データの保護を最適化するために、BLOB のバージョン管理とコンテナーの論理的な削除を BLOB の論理的な削除と共に有効にします。 異なる保有期間を必要とする BLOB を別のストレージ アカウントに格納します。 |
保有期間中、削除された BLOB または BLOB バージョンを復元できます。 | はい |
| 一連のブロック BLOB を以前の時点に復元します。 | ポイントインタイム リストア 詳細情報 |
ポイントタイム リストアを使用して以前の状態に戻すには、コンテナーを削除するのではなく、個々のブロック BLOB を削除するようにアプリケーションを設計します。 | 一連のブロック BLOB を過去の特定の時点の状態に戻すことができます。 ブロック BLOB に対して実行された操作のみが元に戻されます。 コンテナー、ページ BLOB、または追加 BLOB に対して実行された操作は元に戻されません。 |
いいえ |
| 指定された時点での BLOB の状態を手動で保存します。 | BLOB スナップショット 詳細情報 |
コストまたはその他の考慮事項により、バージョン管理がシナリオに適していない場合、またはストレージ アカウントの階層型名前空間が有効になっている場合、BLOB のバージョン管理の代替として推奨されます。 | BLOB が上書きされた場合、BLOB をスナップショットから復元できます。 BLOB が削除された場合は、スナップショットも削除されます。 | はい。プレビュー段階 |
| BLOB を削除または上書きできますが、データは定期的に 2 つ目のストレージ アカウントにコピーされます。 | Azure BLOB 保管済みバックアップ 詳細情報 |
コンテナー化されたバックアップが、直接アクセスできない Microsoft テナントにバックアップされたデータのオフサイト コピーを作成できるようにします | 重要なコンテナーの選択的バックアップを提供し、ソース ストレージ アカウントとは異なるストレージ アカウントに個々のコンテナーを復元できるようにします | いいえ 2 つ目のアカウントにデータをコピーするための roll-your-own ソリューション AzCopy と Azure Data Factory がサポートされています。 オブジェクトのレプリケーションはサポートされません。 |
リソースの種類別のデータ保護
次の表は、保護対象のリソースに応じて Azure Storage のデータ保護オプションをまとめたものです。
| データ保護オプション | アカウントの削除を防止 | コンテナーの削除を防止 | オブジェクトの削除を防止 | オブジェクトの上書きを防止 |
|---|---|---|---|---|
| Azure BLOB 保管済みバックアップ |
いいえ | イエス | イエス | はい |
| Azure Resource Manager ロック | はい | 不可1 | いいえ | いいえ |
| BLOB バージョンの不変ポリシー | はい2 | ○3 | はい | はい4 |
| コンテナーでの不変ポリシー | ○5 | はい | イエス | はい |
| コンテナーの論理的な削除 | いいえ | 有効 | いいえ | いいえ |
| BLOB バージョン管理6 | いいえ | 番号 | イエス | はい |
| BLOB の論理的な削除 | いいえ | 番号 | イエス | はい |
| ポイントインタイム リストア6 | いいえ | 番号 | イエス | はい |
| BLOB スナップショット | いいえ | いいえ | 番号 | はい |
| 2 つ目のアカウントにデータをコピーするための独自ソリューション7 | いいえ | イエス | イエス | はい |
1 Azure Resource Manager ロックでは、コンテナーを削除から保護しません。
2 バージョン レベルの不変ストレージが有効になっているコンテナーが少なくとも 1 つある場合、ストレージ アカウントの削除は失敗します。
3 ポリシーがロックまたはロック解除されているかどうかに関係なく、コンテナーに少なくとも 1 つの BLOB が存在する場合、コンテナーの削除は失敗します。
4 BLOB の現在のバージョンの内容を上書きすると、新しいバージョンが作成されます。 不変ポリシーは、バージョンのメタデータが上書きされないように保護します。
5 訴訟ホールドまたはロックされた時間ベースの保有ポリシーがコンテナーのスコープで有効になっているとき、ストレージ アカウントも削除から保護されます。
6 現在、Data Lake Storage ワークロードではサポートされていません。
7 AzCopy と Azure Data Factory は、Blob Storage と Data Lake Storage の両方のワークロードでサポートされているオプションです。 オブジェクト レプリケーションは、Blob Storage ワークロードでのみサポートされています。
削除または上書きされたデータの回復
上書きまたは削除されたデータを回復する必要がある場合の対処方法は、有効にしたデータ保護オプションと影響を受けたリソースによって異なります。 次の表では、データを回復するために実行できるアクションについて説明します。
| 削除または上書きされたリソース | 使用可能な復旧アクション | 復旧の要件 |
|---|---|---|
| ストレージ アカウント | 削除済みストレージ アカウントの回復を試みる 詳細情報 |
ストレージ アカウントは、最初は Azure Resource Manager デプロイ モデルを使用して作成され、過去 14 日以内に削除された。 元のアカウントが削除されて以来、同じ名前の新しいストレージ アカウントが作成されていない。 |
| コンテナー | 論理的に削除されたコンテナーとその内容を回復する 詳細情報 |
コンテナーの論理的な削除が有効になっており、コンテナーの論理的な削除の保有期間がまだ過ぎていない。 |
| コンテナーと BLOB | 2 つ目のストレージ アカウントからデータを復元する | すべてのコンテナーと BLOB の操作が効果的に 2 つ目のストレージ アカウントにレプリケートされている。 |
| BLOB (任意の型) | 以前のバージョンから BLOB を復元する1 詳細情報 |
BLOB のバージョン管理が有効になっており、BLOB に 1 つ以上の以前のバージョンがある。 |
| BLOB (任意の型) | 論理的に削除された BLOB を回復する 詳細情報 |
BLOB の論理的な削除が有効になっており、論理的な削除の保有期間が過ぎていない。 |
| BLOB (任意の型) | スナップショットから BLOB を復元する 詳細情報 |
BLOB に 1 つ以上のスナップショットがある。 |
| ブロック BLOB のセット | ブロック BLOB のセットを以前の時点の状態に復旧する1 詳細情報 |
ポイントインタイム リストアが有効になっており、復元ポイントが保有期間内にある。 ストレージ アカウントが侵害されておらず、破損もしていない。 |
| BLOB バージョン | 論理的に削除されたバージョンを回復する1 詳細情報 |
BLOB の論理的な削除が有効になっており、論理的な削除の保有期間が過ぎていない。 |
1 現在、Data Lake Storage ワークロードではサポートされていません。
コストに関する考慮事項の概要
次の表は、このガイドで説明されているさまざまなデータ保護オプションのコストに関する考慮事項をまとめたものです。
| データ保護オプション | コストに関する考慮事項 |
|---|---|
| ストレージ アカウントに対する Azure Resource Manager ロック | ストレージ アカウントでのロックの構成は無料。 |
| BLOB バージョンの不変ポリシー | コンテナーでバージョンレベルの不変性のサポートを有効するために費用はかかりません。 BLOB バージョンに対する時間ベースのアイテム保持ポリシーまたは訴訟ホールドを作成、変更、または削除すると、書き込みトランザクション料金が発生します。 |
| コンテナーでの不変ポリシー | コンテナーでの不変ポリシーの構成は無料。 |
| コンテナーの論理的な削除 | ストレージ アカウントに対するコンテナーの論理的な削除の有効化は無料。 論理的に削除されたコンテナー内のデータは、論理的に削除されたコンテナーが完全に削除されるまで、アクティブなデータと同じレートで課金されます。 |
| BLOB バージョン管理 | ストレージ アカウントに対する BLOB バージョン管理の有効化は無料。 BLOB バージョン管理を有効にすると、アカウント内の BLOB に対するすべての書き込みまたは削除操作によって新しいバージョンが作成されるため、容量コストが増加する可能性があります。 BLOB バージョンは、一意のブロックまたはページに基づいて課金されます。 そのため、ベース BLOB が特定のバージョンから逸脱するほど、コストが増加します。 BLOB または BLOB バージョンの層を変更すると、課金に影響する場合があります。 詳細については、「価格と課金」を参照してください。 コストを管理するには、必要に応じて、ライフサイクル管理を使用して古いバージョンを削除します。 詳細については、「Azure Blob Storage アクセス層の自動化によるコストの最適化」を参照してください。 |
| BLOB の論理的な削除 | ストレージ アカウントに対する BLOB の論理的な削除の有効化は無料。 論理的に削除された BLOB 内のデータは、論理的に削除された BLOB が完全に削除されるまで、アクティブなデータと同じレートで課金されます。 |
| ポイントインタイム リストア | ストレージ アカウントに対するポイントインタイム リストアの有効化は無料。ただし、ポイントインタイム リストアを有効にすると、BLOB バージョン管理、論理的な削除、および変更フィードも有効になり、それぞれによって他の料金が発生する可能性があります。 復元操作を実行するときにポイントインタイム リストアに対して課金されます。 復元操作のコストは、復元されるデータの量によって異なります。 詳細については、「価格と課金」を参照してください。 |
| BLOB のスナップショット | スナップショット内のデータは、一意のブロックまたはページに基づいて課金されます。 そのため、ベース BLOB がスナップショットから逸脱するほど、コストが増加します。 BLOB またはスナップショットの層を変更すると、課金に影響する場合があります。 詳細については、「価格と課金」を参照してください。 コストを管理するには、必要に応じて、ライフサイクル管理を使用して古いスナップショットを削除します。 詳細については、「Azure Blob Storage アクセス層の自動化によるコストの最適化」を参照してください。 |
| 保管済みバックアップ | コンテナー化されたバックアップの場合、バックアップされるソース アカウントで、バックアップ ストレージ料金またはインスタンス料金と、(オブジェクト レプリケーションに関連する) ソース側のコストが発生します。 「価格」を参照してください。 |
| 2 つ目のストレージ アカウントにデータをコピーする | 2 つ目のストレージ アカウントでデータを維持すると、容量とトランザクションのコストが発生します。 2 つ目のストレージ アカウントがソース アカウントとは異なるリージョンにある場合、その 2 つ目のアカウントへのデータのコピーにより、さらにエグレス料金が発生します。 |
障害復旧
Azure Storage では、計画されたイベントや計画外のイベント (一時的なハードウェア障害、ネットワークの停止や停電、大規模な自然災害など) から保護するため、常にデータの複数のコピーが維持されます。 冗長性を確保することで、障害が発生した場合でも、ストレージ アカウントが可用性と耐久性に関する目標を確実に達成できます。 高可用性を実現するようにストレージ アカウントを構成する方法の詳細については、「Azure Storage の冗長性」を参照してください。
ストレージ アカウントが geo 冗長用に構成されている場合、データ センターの障害時にプライマリからセカンダリ リージョンへの計画外フェールオーバーを開始することができます。 詳細については、「ディザスター リカバリーの計画とフェールオーバー」を参照してください。
カスタマー マネージド フェールオーバーでは現在、階層型名前空間が有効になっているストレージ アカウントがサポートされていますが、まだプレビュー状態です。 詳細については、「ディザスター リカバリーの計画とフェールオーバー」を参照してください。