ビジネス クリティカルな BLOB データを書き込み 1 回、読み取り複数回 (WORM) の状態で保存する
Azure Blob Storage に不変ストレージを使うと、ユーザーはビジネスに不可欠なデータを WORM (Write Once, Read Many) 状態で格納できます。 WORM 状態の場合、ユーザーが指定した間隔でデータを変更または削除することはできません。 BLOB データに不変ポリシーを構成することにより、上書きや削除からデータを保護することができます。
Azure Blob Storage の不変ストレージでは、次の 2 種類の不変ポリシーがサポートされています。
時間ベースのアイテム保持ポリシー: 時間ベースのアイテム保持ポリシーを使用すると、ユーザーは指定した間隔でデータを格納するポリシーを設定できます。 時間ベースのアイテム保持ポリシーを設定すると、オブジェクトの作成と読み取りは可能ですが、変更または削除はできません。 保持期間の期限が切れた後はオブジェクトを削除できますが、上書きはできません。
訴訟ホールドポリシー: 訴訟ホールドでは、訴訟ホールドが明示的にクリアされるまで、不変データを格納します。 訴訟ホールドを設定すると、オブジェクトの作成と読み取りは可能ですが、変更または削除はできません。
これらのポリシーは、互いに同時に設定できます。 たとえば、あるユーザーが、時間ベースのアイテム保持ポリシーと訴訟ホールドの両方を同じレベルで同時に設定できます。 書き込みが成功するには、バージョン管理を有効にするか、データに対して訴訟ホールドも時間ベースのアイテム保持ポリシーを設定されていない必要があります。 削除が成功するためにも、データに対して訴訟ホールドおよび時間ベースのアイテム保持ポリシーを設定してはいけません。
次の図は、時間ベースの保持ポリシーと訴訟ホールドが有効になっている間、どのように書き込みと削除操作が防止されるかを示しています。
不変ストレージの傘の下には、コンテナー レベルの WORM とバージョン レベルの WORM という 2 つの機能があります。 コンテナー レベルの WORM では、ポリシーをコンテナー レベルでのみ設定できますが、バージョン レベルの WORM では、アカウント、コンテナー、またはバージョンのレベルでポリシーを設定できます。
BLOB の不変ストレージについて
不変ストレージを使用すると、医療機関、金融機関、および関連する業界 (特に、ブローカー ディーラー組織) は、データを安全に保存できるようになります。 不変ストレージは、重要なデータを変更や削除から保護するためのあらゆるシナリオで使用できます。
一般的な用途は次のとおりです。
法令遵守: Azure Blob Storage の不変ストレージは、組織が SEC 17a-4(f)、CFTC 1.31(d)、FINRA などの規制に準拠するのに役立ちます。
セキュリティ保護されたドキュメント リテンション: BLOB の不変ストレージにより、どのユーザーも、データを変更したり、削除したりできなくなります。アカウント管理特権を持つユーザーですらです。
訴訟ホールド: BLOB の不変ストレージを使用すると、ユーザーは訴訟やビジネス用途に不可欠な機密情報を、ホールドが削除されるまでの必要な期間中、改ざん防止状態で保存できます。 この機能は、法的なユース ケースのみに限定されず、イベント トリガーや会社のポリシーに基づいたデータの保護が必要な、イベント ベースのホールドまたはエンタープライズ ロックとして考えることもできます。
規制に対するコンプライアンス
Microsoft は、記録管理と情報ガバナンスに特化した大手の独立系評価会社である Cohasset Associates を保有して、金融サービス業界に固有の要件に対して、BLOB の不変ストレージとそのコンプライアンスを評価しました。 Cohasset では、不変ストレージが、BLOB を WORM 状態に維持するために使用する場合、CFTC Rule 1.31(c)-(d)、FINRA Rule 4511、および SEC Rule 17a-4(f) の関連ストレージ要件を満たしていることを実証しました。 この一連のルールは金融機関のレコード保有期間に対する最も規範的なガイダンスを世界中に示すものであるため、Microsoft ではこれらのルールを対象としました。
Cohasset レポートは Microsoft Service Trust Center で入手できます。 Azure トラスト センターでは、コンプライアンス関連の Microsoft の認定資格に関する詳しい情報を確認できます。 WORM 不変性コンプライアンスに関する Microsoft からの構成証明の文書を要求するには、Azure サポートにお問い合わせください。
時間ベースの保持ポリシー
時間ベースのアイテム保持ポリシーでは、指定された期間、BLOB データを WORM 形式で保存します。 時間ベースのアイテム保持ポリシーが設定されている場合、クライアントは BLOB の作成と読み取りはできますが、変更または削除はできません。 保持間隔を経過した後は BLOB を削除できますが、上書きはできません。
範囲
時間ベースのアイテム保持ポリシーは、次のスコープで構成できます。
- バージョン レベルの WORM ポリシー: 時間ベースのアイテム保持ポリシーは、アカウント、コンテナー、またはバージョンのレベルで構成できます。 アカウントまたはコンテナーのレベルで構成された場合、それぞれのアカウントまたはコンテナー内のすべての BLOB によって継承されます。
- コンテナーレベルの WORM ポリシー: コンテナー レベルで構成された時間ベースのアイテム保持ポリシーは、そのコンテナー内のすべての BLOB に適用されます。 個々の BLOB を、独自の不変ポリシーを使用して構成することはできません。
時間ベースのポリシーの保持間隔
時間ベースのアイテム保持ポリシーの最短保持間隔は 1 日で、最長間隔は 146,000 日 (400 年) です。 時間ベースのアイテム保持ポリシーを構成すると、影響を受けるオブジェクトは、有効な保持期間中、不変状態のままになります。 オブジェクトの有効な保持期間は、BLOB の作成時刻とユーザーが指定した保持間隔の差になります。 ポリシーの保持期間は延長できるため、不変ストレージでは、ユーザー指定の保持間隔の最新の値が、有効な保持期間の計算に使用されます。
たとえば、ユーザーが、保持間隔が 5 年の時間ベースの保持ポリシーを作成するとします。 そのコンテナー内の既存の BLOB testblob1 は 1 年前に作成されました。したがって、testblob1 の有効な保持期間は 4 年です。 新しい BLOB である testblob2 がコンテナーにアップロードされると、testblob2 の有効な保持期間は作成時点から 5 年になります。
ロックされたポリシーとロック解除されたポリシー
時間ベースのアイテム保持ポリシーを初めて構成する場合、ポリシーはテスト目的でロック解除されています。 テストが完了したら、ポリシーをロックすることで、SEC 17a-4(f) およびその他の規制コンプライアンスに完全に準拠できます。
ポリシーは、ロックされていてもロック解除されていても、削除と上書きを防止できます。 ただし、ロック解除されたポリシーは、変更して保持期間を短縮または延長できます。 また、ロック解除されたポリシーは削除することもできます。 ロックされた時間ベースのアイテム保持ポリシーは、削除できません。 保持期間の延長はできますが、短縮はできません。 コンテナー レベルで定義された、ロックされたポリシーの有効期間中に、有効な保持期間を最大で 5 つ、増やすことができます。 BLOB バージョンに対して構成されるポリシーの場合、追加する有効期間の数に制限はありません。
重要
SEC 17a-4(f) や他の規制を順守するために BLOB を準拠した不変 (書き込みおよび削除禁止) 状態にするには、時間ベースのリテンション ポリシーをロックする必要があります。 Microsoft では、適切な期間 (通常 24 時間未満)、ポリシーをロックすることをお勧めします。 ロック解除の状態では不変性保護が行われますが、短期間のテスト以外の目的でのロック解除状態の使用はお勧めしません。
アイテム保持ポリシーの監査ログ
時間ベースのアイテム保持ポリシーが有効になっている各コンテナーでは、ポリシー監査ログが提供されます。 監査ログには、ロックされた時間ベースのアイテム保持ポリシーに対して、最大 7 つの時間ベースのアイテム保持コマンドが含まれています。 通常、ログはポリシーをロックすると開始されます。 ログ エントリには、ユーザー ID、コマンドの種類、タイム スタンプ、および保持間隔が含まれています。 監査ログは、SEC 17a-4(f) 規制ガイドラインに従い、ポリシーの有効期間の間、保持されます。
すべての管理サービス アクティビティのより包括的なログは、Azure アクティビティ ログに表示されます。 Azure リソース ログには、データ操作に関する情報が保持されます。 規制や他の目的で必要になる可能性のあるログは、ユーザーが永続的に保存する必要があります。
バージョンレベルでの時間ベースのアイテム保持ポリシーの変更は監査されません。
訴訟ホールド
訴訟ホールドは、法的調査の目的または一般的な保護ポリシーのために適用できる一時的な変更防止ポリシーです。 訴訟ホールドでは、ホールドが明示的にクリアされるまで、書き込み 1 回、読み取り複数回 (WORM) 形式で BLOB データが保存されます。 訴訟ホールドを設定すると、BLOB の作成と読み取りは可能ですが、変更や削除はできません。 データを WORM 状態に保つ必要がある期間が不明な場合は、訴訟ホールドを使用します。
範囲
訴訟ホールド ポリシーは、次のいずれかのスコープで構成できます。
バージョン レベルの WORM ポリシー: 機密データをきめ細かく管理するために、個々の BLOB バージョン レベルで訴訟ホールドを構成できます。
コンテナー レベルのWORM ポリシー: コンテナー レベルで構成されている訴訟ホールドは、そのコンテナー内のすべての BLOB に適用されます。 個々の BLOB を、独自の不変ポリシーを使用して構成することはできません。
タグ
コンテナー レベルの訴訟ホールドは、識別子文字列として機能する 1 つ以上のユーザー定義英数字タグに関連付けられている必要があります。 たとえば、タグにはケース ID またはイベント名を含めることができます。
監査ログ
有効な訴訟ホールドを持つ各コンテナーは、ポリシー監査ログを提供します。 ログにはユーザー ID、コマンドの種類、タイム スタンプ、訴訟ホールド タグが含まれます。 監査ログは、SEC 17a-4(f) 規制ガイドラインに従い、ポリシーの有効期間の間、保持されます。
すべての管理サービス アクティビティのより包括的なログは、Azure アクティビティ ログに表示されます。 Azure リソース ログには、データ操作に関する情報が保持されます。 規制や他の目的で必要になる可能性のあるログは、ユーザーが永続的に保存する必要があります。
バージョン レベルでの訴訟ホールドの変更は監査されません。
不変ストレージ機能のオプション
次の表は、コンテナー レベルの WORM とバージョン レベルの WORM の違いの内訳を示しています。
| カテゴリ | コンテナーレベルの WORM | バージョン レベルの WORM |
|---|---|---|
| ポリシーの粒度レベル | ポリシーは、コンテナー レベルでのみ構成できます。 コンテナーにアップロードされる各オブジェクトは、設定された不変ポリシーを継承します。 | ポリシーは、アカウント、コンテナー、または BLOB レベルで構成できます。 ポリシーがアカウント レベルで設定されている場合、そのアカウントにアップロードされるすべての BLOB がポリシーを継承します。 コンテナーも同じロジックに従います。 ポリシーが複数のレベルで設定されている場合、優先順位は常に BLOB -> コンテナー -> アカウントになります。 |
| 使用可能なポリシーの種類 | コンテナー レベルでは、時間ベースの保持ポリシーと訴訟ホールドという 2 種類のポリシーを設定できます。 | アカウントとコンテナーのレベルでは、時間ベースの保持ポリシーのみを設定できます。 BLOB レベルでは、時間ベースの保持ポリシーと訴訟ホールドの両方を設定できます。 |
| 機能の依存関係 | この機能が動作するために、前提条件または要件となるその他の機能はありません。 | バージョン管理は、この機能を使用するための前提条件です。 |
| 既存のアカウント/コンテナーの有効化 | この機能は、既存のコンテナーに対していつでも有効にすることができます。 | 粒度のレベルによっては、この機能がすべての既存のアカウント/コンテナーに対して有効にされない場合があります。 |
| アカウントおよびコンテナーの削除 | 時間ベースの保持ポリシーがコンテナーでロックされると、コンテナーは空の場合にのみ削除できます。 | バージョン レベルの WORM がアカウントまたはコンテナー レベルで有効になると、削除できるのは空の場合のみです。 |
| Azure Data Lake Storage Gen2 のサポート (階層型名前空間が有効なストレージ アカウント) | コンテナー レベルの WORM ポリシーは、階層型名前空間があるアカウントでサポートされています。 | バージョン レベルの WORM ポリシーは、階層型名前空間があるアカウントではまだサポートされていません。 |
コンテナー レベルの WORM の詳細については、「コンテナー レベルの WORM ポリシー」を参照してください。 バージョン レベルの WORM の詳細については、「バージョン レベルの WORM ポリシー」を参照してください。
コンテナー レベルとバージョン レベルの WORM の比較
次の表は、使用する WORM ポリシーの種類を選択するのに役立ちます。
| 基準 | コンテナーレベルの WORM の使用 | バージョン レベルの WORM の使用 |
|---|---|---|
| データの編成 | コンテナーごとに分類できる特定のデータ セットのポリシーを設定する必要があります。 そのコンテナー内のすべてのデータは、同じ期間、WORM 状態に保たれる必要があります。 | 保持期間でオブジェクトをグループ化することはできません。 すべての BLOB は、その BLOB のシナリオに基づいて個別の保持時間で保存する必要があります。または、ユーザーのワークロードが混在しているため、一部のデータ グループをコンテナーにクラスター化できる一方で、他の BLOB はクラスター化できません。 また、同じアカウント内でコンテナー レベルのポリシーと BLOB レベルのポリシーを設定することもできます。 |
| 不変ポリシーを必要とするデータの量 | アカウントあたり 10,000 を超えるコンテナーにポリシーを設定する必要はありません。 | アカウント別に線引できるすべてのデータまたは大量のデータに対してポリシーを設定する必要があります。 コンテナー レベルの WORM を使用すると、10,000 コンテナーの制限を超える必要があることが判明しています。 |
| バージョン管理を有効にすることへの関心 | コストが原因で、またはワークロードによって処理する多数の追加バージョンが作成されるために、バージョン管理を有効にしたくありません。 | バージョン管理を使用する必要があるか、または使用しても特にかまいません。 バージョン管理が有効になっていないと、不変 BLOB に対する編集や上書きを個別のバージョンとして保持することができないことが分かっています。 |
| ストレージの場所 (Blob Storage と Data Lake Storage Gen2) | ワークロードは、Azure Data Lake Storage Gen2 に完全に集中しています。 階層型名前空間機能が有効になっていないアカウントの使用に切り替える、直近の関心も予定もありません。 | ワークロードは、階層型名前空間機能が有効になっていないアカウントの Blob Storage 上にあり、バージョン レベルの WORM を今すぐ使用できます。または、階層型名前空間が有効になっているアカウント (Azure Data Lake Storage Gen2) でバージョン管理が使用できるようになるのを待つ用意があります。 |
アクセス層
すべての BLOB アクセス層は、不変ストレージをサポートしています。 BLOB のアクセス層を変更するには、Set Blob Tier 操作を使用します。 詳細については、「BLOB データ用のアクセス層」を参照してください。
冗長構成
すべての冗長構成は、不変ストレージをサポートします。 冗長構成の詳細については、「Azure Storage の冗長性」を参照してください。
推奨される BLOB の種類
主にブロック BLOB と追加 BLOB に対して不変ポリシーを構成することをお勧めします。 アクティブな仮想マシンの VHD ディスクを保存するページ BLOB の不変ポリシーを構成することは推奨されません。これは、ディスクへの書き込みがブロックされる、あるいはバージョン管理が有効な場合は、各書き込みが新しいバージョンとして保存されるためです。 時間ベースのポリシーをロックする前に、ドキュメントを十分に確認し、シナリオをテストすることをお勧めします。 時間ベースのポリシーをロックする前に、ドキュメントを十分に確認し、シナリオをテストすることをお勧めします。
BLOB の論理的な削除と不変ストレージ
ストレージ アカウントに対して BLOB の論理的な削除が構成されている場合、訴訟ホールドまたは時間ベースのアイテム保持ポリシーが有効になっているかどうかに関係なく、アカウント内のすべての BLOB に適用されます。 不変ポリシーが適用される前に、保護を強化するために論理的な削除を有効にすることをお勧めします。
BLOB の論理的な削除を有効にした後で不変ポリシーを構成した場合、論理的に削除されたすべての BLOB は、論理的な削除のアイテム保持ポリシーの有効期限が切れた時点で完全に削除されます。 論理的に削除された BLOB は、論理的な削除の保持期間中であれば復元できます。 論理的な削除がまだ行われていない BLOB またはバージョンは、不変ポリシーによって保護されており、時間ベースのアイテム保持ポリシーが期限切れになるか、訴訟ホールドが削除されるまで、論理的な削除はできません。
BLOB インベントリを使用して不変ポリシーを追跡する
Azure Storage BLOB インベントリは、ストレージ アカウント内のコンテナーの概要と、その中にある BLOB、スナップショット、および BLOB のバージョンを提供します。 BLOB インベントリ レポートを使用すると、リソースに不変ポリシーが構成されているかどうかなど、BLOB とコンテナーの属性を把握できます。
BLOB インベントリを有効にすると、Azure Storage によってインベントリ レポートが毎日生成されます。 このレポートには、ビジネス要件とコンプライアンス要件に関するデータの概要が示されます。
BLOB インベントリの詳細については、「Azure Storage BLOB インベントリ」を参照してください。
Note
バージョン レベルの不変性のサポートがアカウントで有効な場合、またはインベントリ ポリシーで定義されている宛先コンテナーでバージョン レベルの不変性のサポートが有効な場合、そのアカウントでインベントリ ポリシーを構成することはできません。
価格
不変ストレージを使用するための追加の容量料金はありません。 不変データは、変更可能データと同じ方法で価格が設定されます。 バージョン レベルの WORM を使用している場合は、バージョン管理が有効になっており、保存される追加のバージョンに対してコストが発生するため、請求額が高くなる可能性があります。 詳細については、バージョン管理の価格ポリシーを参照してください。 Azure Blob Storage の価格設定については、Azure Storage の価格に関するページを参照してください。
BLOB バージョンに対する時間ベースのアイテム保持ポリシーまたは訴訟ホールドを作成、変更、または削除すると、書き込みトランザクション料金が発生します。
請求書の支払いに失敗し、アカウントでアクティブな時間ベースのアイテム保持ポリシーが有効になっている場合、Microsoft との契約の条項および条件に従って通常のデータ保持ポリシーが適用されます。 全般的な情報については、「Microsoft でのデータ管理」を参照してください。
機能サポート
この機能は、ポイントインタイム リストアおよび最後のアクセス追跡と互換性がありません。 不変ポリシーは、Network File System (NFS) 3.0 プロトコルまたは SSH ファイル転送プロトコル (SFTP) が有効になっているアカウントではサポートされません。
一部のワークロード (SQL Backup to URL など) では、BLOB が作成され、それに追加されます。 コンテナーにアクティブな時間ベースのアイテム保持ポリシーまたは訴訟ホールドが設定されている場合、このパターンは失敗します。 詳細については、「保護された追加 BLOB の書き込みを許可する」を参照してください。
詳細については、「Azure Storatge アカウントにおける Blob Storage 機能のサポート」をご覧ください。