論理的な削除、バックアップ、バージョン管理、不変ストレージなど、データ セキュリティの脅威から保護するための適切な方法を選択して構成する
Azure Storage には、Blob Storage と Azure Data Lake Storage Gen2 に対する包括的なデータ保護が用意されており、削除または上書きされたデータを回復する必要があるシナリオに備えるのに役立ちます。 データ保護は、セキュリティ戦略の重要な要素であり、侵害を想定し、セキュリティ インシデントから確実に復旧できるようにすることで、ゼロ トラストの原則に沿っています。 悪意のあるアクター、偶発的な削除、運用エラーなど、データを侵害する可能性のあるインシデントが発生する前に、データを最適に保護する方法を検討することが重要です。
基本的なデータ保護に関する推奨事項
ストレージ アカウントとそれに含まれるデータの基本的なデータ保護の対象範囲を検討している場合は、最初に次の手順を実行することをお勧めします。
- 削除または構成の変更からアカウントを保護するために、ストレージ アカウントに対して Azure Resource Manager ロックを構成します。 これにより、ストレージ アカウント全体が誤って削除されたり、承認されていない削除を防ぐことができます。
- ストレージ アカウントのコンテナーの論理的な削除を有効にして、削除されたコンテナーとその内容を回復します。 これにより、コンテナーの誤削除に対するセーフティ ネットが提供されます。
-
BLOB の状態を一定の間隔で保存します。
- Blob Storage ワークロードの場合は、BLOB のバージョン管理を有効にして、BLOB が上書きされるたびにデータの状態を自動的に保存します。
- Azure Data Lake Storage ワークロードの場合は、手動スナップショットを作成して、特定の時点のデータの状態を保存します。
データ保護オプションの概要
次の表は、一般的なデータ保護のシナリオに対して 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 Storage オブジェクトのレプリケーション、または AzCopy や Azure Data Factory のようなツールを使用して、2 つ目のアカウントにデータをコピーするための独自ソリューション。 | 予期しない意図的なアクションや予測できないシナリオに対する安心のための保護として推奨されます。 エグレス料金が発生しないように、プライマリ アカウントと同じリージョンに 2 つ目のストレージ アカウントを作成します。 |
プライマリ アカウントが何らかの方法で侵害された場合、2 つ目のストレージ アカウントからデータを復元できます。 | AzCopy と Azure Data Factory がサポートされています。 オブジェクトのレプリケーションはサポートされません。 |
リソースの種類別のデータ保護
次の表は、保護対象のリソースに応じて Azure Storage のデータ保護オプションをまとめたものです。
| データ保護オプション | アカウントを削除から保護します | コンテナーを削除から保護します | オブジェクトを削除から保護します | 上書きからオブジェクトを保護します |
|---|---|---|---|---|
| Azure Resource Manager のロック | はい | いいえ | いいえ | いいえ |
| BLOB バージョンの不変性ポリシー | はい | はい | はい | はい |
| コンテナーの不変性ポリシー | はい | はい | はい | はい |
| コンテナーの論理的な削除 | いいえ | はい | いいえ | いいえ |
| BLOB バージョン管理 | いいえ | いいえ | はい | はい |
| BLOB の論理的な削除 | いいえ | いいえ | はい | はい |
| ポイントインタイム リストア | いいえ | いいえ | はい | はい |
| BLOB スナップショット | いいえ | いいえ | いいえ | はい |
| 2 つ目のアカウントにデータをコピーするための独自ソリューション | いいえ | はい | はい | はい |
Azure Storage でのデータ保護の微妙な違いを理解すると、セキュリティとコンプライアンスの両方にとって重要な運用上の分析情報と制限がいくつか明らかになります。
- Azure Resource Manager ロックは、コンテナーを削除から保護せず、ストレージ アカウント自体のみを保護します。
- バージョン レベルの不変ストレージが有効になっているコンテナーが少なくとも 1 つ存在する場合、ストレージ アカウントの削除は失敗し、アカウントの誤削除に対する保護が提供されます。
- 不変ポリシーがロックされているかロック解除されているかに関係なく、コンテナーに少なくとも 1 つの BLOB が存在する場合、コンテナーの削除は失敗します。
- BLOB の現在のバージョンの内容を上書きすると、新しいバージョンが作成されます。 不変ポリシーは、バージョンのメタデータが上書きされないように保護し、データの整合性を確保します。
- 訴訟ホールドまたはロックされた時間ベースの保有ポリシーがコンテナーのスコープで有効になっているとき、ストレージ アカウントも削除から保護され、コンプライアンス保護を実現できます。
- 現在、Data Lake Storage ワークロードではサポートされていません (BLOB のバージョン管理とポイントインタイム リストアに適用されます)。
- AzCopy と Azure Data Factory は、Blob Storage と Data Lake Storage の両方のワークロードでサポートされているオプションです。 オブジェクト レプリケーションは、Blob Storage ワークロードでのみサポートされています。
削除または上書きされたデータの回復
上書きまたは削除されたデータを回復する必要がある場合の対処方法は、有効にしたデータ保護オプションと影響を受けたリソースによって異なります。 次の表では、データを回復するために実行できるアクションについて説明します。
| 削除されたリソースまたは上書きされたリソース | 考えられる復旧アクション | 復旧の要件 |
|---|---|---|
| ストレージ アカウント | 削除済みストレージ アカウントの回復を試みる |
ストレージ アカウントは、最初は Azure Resource Manager デプロイ モデルを使用して作成され、過去 14 日以内に削除された。 元のアカウントが削除されて以来、同じ名前の新しいストレージ アカウントが作成されていない。 |
| コンテナー | 論理的に削除されたコンテナーとその内容を回復する |
コンテナーの論理的な削除が有効になっており、コンテナーの論理的な削除の保有期間がまだ過ぎていない。 |
| コンテナーと BLOB | 2 つ目のストレージ アカウントからデータを復元する | すべてのコンテナーと BLOB の操作が効果的に 2 つ目のストレージ アカウントにレプリケートされている。 |
| BLOB (任意の型) | 以前のバージョンから BLOB を復元する |
BLOB のバージョン管理が有効になっており、BLOB に 1 つ以上の以前のバージョンがある。 |
| BLOB (任意の型) | 論理的に削除された BLOB を回復する |
BLOB の論理的な削除が有効になっており、論理的な削除の保有期間が過ぎていない。 |
| BLOB (任意の型) | スナップショットから BLOB を復元する |
BLOB に 1 つ以上のスナップショットがある。 |
| ブロック BLOB のセット | ブロック BLOB のセットを以前の時点の状態に復旧する |
ポイントインタイム リストアが有効になっており、復元ポイントが保有期間内にある。 ストレージ アカウントが侵害されておらず、破損もしていない。 |
| BLOB バージョン | 論理的に削除されたバージョンを回復する |
BLOB の論理的な削除が有効になっている |
コストに関する考慮事項の概要
| データ保護オプション | コストに関する考慮事項 |
|---|---|
| ストレージ アカウントに対する 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 では、計画されたイベントや計画外のイベント (一時的なハードウェア障害、ネットワークの停止や停電、大規模な自然災害など) から保護するため、常にデータの複数のコピーが維持されます。 冗長性を確保することで、障害が発生した場合でも、ストレージ アカウントが可用性と耐久性に関する目標を確実に達成できます。
データ センターで障害が発生し、ストレージ アカウントが 2 つの地理的リージョン (geo 冗長) にわたって冗長になっている場合は、プライマリ リージョンからセカンダリ リージョンにアカウントをフェールオーバーするオプションがあります。 この機能は、ビジネス継続性とディザスター リカバリーの計画に不可欠です。
Important
現在、階層型名前空間が有効になっているストレージ アカウントでは、カスタマー マネージド フェールオーバーはサポートされていません。
データ保護を実装するためのベスト プラクティス
Azure Storage のデータ保護を実装する場合は、次の推奨事項を考慮してください。
- 多層防御を実装する: 複数の保護メカニズムを一緒に使用します。 たとえば、BLOB のバージョン管理、論理的な削除、不変ポリシーを組み合わせて、さまざまな種類のデータ損失に対する包括的な保護を実現します。
- 定期的なテスト: データ復旧手順を定期的にテストして、想定どおりに動作し、チームが復旧プロセスに精通していることを確認します。
- 保有期間の計画: コンプライアンス要件に基づいて適切な保持期間を設定しますが、論理的に削除されたデータとバージョンの保持に関連するストレージ コストも考慮します。
- コンプライアンスに不変ポリシーを使用する: 規制対象の業界では、WORM (Write Once, Read Many) コンプライアンス要件を満たすために、コンテナーまたは BLOB バージョンに不変ポリシーを実装します。
- 保護の状態を監視する: Azure Monitor と Azure Policy を使用して、データ保護機能が有効になっているストレージ アカウントを追跡し、保護戦略のギャップを特定します。
- 戦略を文書化する: 有効になっている機能、保持期間、回復手順など、データ保護構成の明確なドキュメントを保持します。
- コストと保護を考慮する: 包括的なデータ保護は重要ですが、保護レベルとストレージ コストのバランスを取ります。 ライフサイクル管理ポリシーを使用して、要件に基づいて古いバージョンとスナップショットを自動的に削除します。
- 重要なデータの geo 冗長性: ビジネス クリティカルなデータの場合は、geo 冗長ストレージ (GRS または GZRS) を使用して、リージョン全体が使用できなくなった場合でもデータの可用性を確保します。
- バックアップ ソリューションとの組み合わせ: 追加の保護のために、Azure Backup for Azure Files または追加の回復オプションと長期的なリテンション期間を提供するサードパーティのバックアップ ソリューションの使用を検討してください。