ビジネス クリティカルな BLOB データを書き込み 1 回、読み取り複数回 (WORM) の状態で保存する

Azure Blob StorageのImmutable storageは、ビジネスクリティカルなデータをWORM(一度書き、複数回読む)状態に保存できます。 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 の不変ストレージにより、どのユーザーも、データを変更したり、削除したりできなくなります。アカウント管理特権を持つユーザーですらです。

• 法的保留:ブロブの不変保存は、訴訟やビジネス利用に不可欠な機密情報を、保留解除までの間、改ざん防止状態に保存できます。 この機能は、法的なユース ケースのみに限定されず、イベント トリガーや会社のポリシーに基づいたデータの保護が必要な、イベント ベースのホールドまたはエンタープライズ ロックとして考えることもできます。

規制に対するコンプライアンス

Microsoft は、記録管理と情報ガバナンスに特化した大手の独立系評価会社である Cohasset Associates を保有して、金融サービス業界に固有の要件に対して、BLOB の不変ストレージとそのコンプライアンスを評価しました。 Cohasset では、不変ストレージが、BLOB を WORM 状態に維持するために使用する場合、CFTC Rule 1.31(c)-(d)、FINRA Rule 4511、および SEC Rule 17a-4(f) の関連ストレージ要件を満たしていることを実証しました。 この一連のルールは金融機関のレコード保有期間に対する最も規範的なガイダンスを世界中に示すものであるため、Microsoft ではこれらのルールを対象としました。

Cohasset レポートは Microsoft サービス Trust Center で入手できます。 Azure トラスト センターでは、コンプライアンス関連の Microsoft の認定資格に関する詳しい情報を確認できます。 WORM 不変性コンプライアンスに関する構成証明のレターを Microsoft に要求するには、 Azure サポートにお問い合わせください。

時間ベースの保持ポリシー

時間ベースの保持ポリシーでは、指定された期間、BLOB データを WORM 形式で保存します。 時間ベースの保持ポリシーを設定すると、クライアントはブロブを作成・読み取ることができますが、それらを修正・削除することはできません。 保持期間が終了した後は、ブロブを削除できますが、上書きはできません。

Scope

以下の範囲で時間ベースの保持ポリシーを設定できます:

• バージョンレベルのWORMポリシー:アカウント、コンテナ、またはバージョンレベルで時間ベースの保持ポリシーを設定します(アカウントでバージョン設定を有効にする必要があります)。 アカウントレベルやコンテナレベルで設定すると、それぞれのアカウントやコンテナ内のすべてのブロブがポリシーを引き継ぎます。 コンテナに法的な保留がある場合、同じコンテナに対してバージョンレベルのWORMを作成することはできません。 この制限は、法的保留によってバージョンの生成が妨げられているため存在します。
• コンテナーレベルの WORM ポリシー: コンテナー レベルで構成された時間ベースのアイテム保持ポリシーは、そのコンテナー内のすべての BLOB に適用されます。 個々のブロブに独自の不変性ポリシーを設定することはできません。

時間ベースのポリシーの保持間隔

時間ベースのアイテム保持ポリシーの最短保持間隔は 1 日で、最長間隔は 146,000 日 (400 年) です。 時間ベースのアイテム保持ポリシーを構成すると、影響を受けるオブジェクトは、有効な保持期間中、不変状態のままになります。 オブジェクトの有効な保持期間は、BLOB の作成時刻とユーザーが指定した保持間隔の差になります。 ポリシーの保持期間は延長できるため、不変ストレージでは、ユーザー指定の保持間隔の最新の値が、有効な保持期間の計算に使用されます。

たとえば、ユーザーが、保持間隔が 5 年の時間ベースの保持ポリシーを作成するとします。 そのコンテナー内の既存の BLOB testblob1 は 1 年前に作成されました。したがって、testblob1 の有効な保持期間は 4 年です。 新しい BLOB である testblob2 がコンテナーにアップロードされると、testblob2 の有効な保持期間は作成時点から 5 年になります。

ロックされたポリシーとロック解除されたポリシー

時間ベースのアイテム保持ポリシーを初めて構成する場合、ポリシーはテスト目的でロック解除されています。 テストが完了したら、ポリシーをロックすることで、SEC 17a-4(f) およびその他の規制コンプライアンスに完全に準拠できます。

ポリシーは、ロックされていてもロック解除されていても、削除と上書きを防止できます。 ただし、ロック解除されたポリシーは、変更して保持期間を短縮または延長できます。 また、ロック解除されたポリシーは削除することもできます。 時間ベースのロックされた保持ポリシーは削除できません。 保持期間の延長はできますが、短縮はできません。 コンテナー レベルで定義された、ロックされたポリシーの有効期間中に、有効な保持期間を最大で 5 つ、増やすことができます。 BLOB バージョンに対して構成されるポリシーの場合、追加する有効期間の数に制限はありません。

アイテム保持ポリシーの監査ログ

時間ベースのアイテム保持ポリシーが有効になっている各コンテナーでは、ポリシー監査ログが提供されます。 監査ログには、ロックされた時間ベースのアイテム保持ポリシーに対して、最大 7 つの時間ベースのアイテム保持コマンドが含まれています。 通常、ログはポリシーをロックすると開始されます。 ログ エントリには、ユーザー ID、コマンドの種類、タイム スタンプ、および保持間隔が含まれています。 監査ログは、SEC 17a-4(f) 規制ガイドラインに従い、ポリシーの有効期間の間、保持されます。

すべての管理サービス アクティビティのより包括的なログは、Azure アクティビティ ログに表示されます。 Azure リソース ログには、データ操作に関する情報が保持されます。 規制やその他の目的で必要とされる場合があり、これらのログを継続的に保存する責任があります。

バージョンレベルでの時間ベースのアイテム保持ポリシーの変更は監査されません。

訴訟ホールド

法的ホールドは、法的調査の目的や一般的な保護ポリシーのために適用できる一時的な改変防止ポリシーです。 リーガルホールドは、ホールドが明示的にクリアされるまで、ブロブデータを「一度書き込み、多読(WORM)」形式で保存します。 リーガルホールドを設定すると、BLOB を作成して読み取ることができますが、変更や削除はできません。 データを WORM 状態にどれくらい保っておく必要があるかわからない場合には、リーガルホールドを使用します。

Scope

訴訟ホールド ポリシーは、次のいずれかのスコープで構成できます。

• バージョンレベルのWORMポリシー:機密データの細かな管理のために、個々のブロブバージョンレベルで法的ホールドを設定することができます(アカウントでバージョン管理を有効にする必要があります)。

• コンテナー レベルの WORM ポリシー: コンテナー レベルで構成されている訴訟ホールドは、そのコンテナー内のすべての BLOB に適用されます。 個々の BLOB を、独自の不変ポリシーを使用して構成することはできません。

タグ

コンテナレベルの法的保留は、識別子文字列として機能する1つ以上のユーザー定義の英数字タグと関連付ける必要があります。 例えば、タグにはケースIDやイベント名が含まれることがあります。

監査ログ

法的保留が有効な各コンテナーは、ポリシー監査ログを含みます。 ログにはユーザーID、コマンドの種類、タイムスタンプ、法的保留タグが含まれます。 監査ログは、SEC 17a-4(f) 規制ガイドラインに従い、ポリシーの有効期間の間、保持されます。

すべての管理サービス アクティビティのより包括的なログは、Azure アクティビティ ログに表示されます。 Azure リソース ログには、データ操作に関する情報が保持されます。 規制やその他の目的で必要とされる場合があり、これらのログを継続的に保存する責任があります。

訴訟ホールドに対するバージョン レベルでの変更は、監査されません。

不変ストレージ機能のオプション

次の表は、コンテナー レベルの WORM とバージョン レベルの WORM の違いの内訳を示しています。

コンテナレベルWORMについて詳しく知りたい方は、「 コンテナレベルWORMポリシー」をご覧ください。 バージョンレベルのWORMについて詳しく知りたい方は、 バージョンレベルのWORMポリシーをご覧ください。

コンテナレベルとバージョンレベルのWORM

次の表は、使用する WORM ポリシーの種類を選択するのに役立ちます。

アクセス層

すべての BLOB アクセス層は、不変ストレージをサポートしています。 Set Blob Tier操作でBlobのアクセス階層を変更できます。 詳細については、「BLOB データ用のアクセス層」を参照してください。

冗長構成

すべての冗長構成は、不変ストレージをサポートします。 冗長構成の詳細については、「Azure Storage の冗長性」を参照してください。

推奨されるブロブの種類

Microsoft は、主にブロック BLOB と追加 BLOB に対して不変ポリシーを設定することをお勧めします。 アクティブな仮想マシンのためにVHDディスクを格納するページブロブに対して不変性ポリシーを設定することは推奨されません。なぜなら、ディスクへの書き込みがブロックされるか、バージョン管理が有効の場合は各書き込みが新しいバージョンとして保存されるからです。 時間ベースのポリシーをロックする前に、ドキュメントを十分に確認し、シナリオをテストすることをお勧めします。

BLOB の論理的な削除と不変ストレージ

ストレージアカウントのブロブソフト削除を設定すると、法的保留や時間ベースの保持ポリシーが適用されているかどうかに関わらず、アカウント内のすべてのブロブに適用されます。 Microsoft は、不変性ポリシーが適用される前に、保護を強化するためにソフト削除を有効にすることを推奨します。

ブロブソフトデリットを有効にしてから不変性ポリシーを設定すると、ソフト削除ポリシーが終了すると、すでにソフト削除したブロブは永久に削除されます。 ソフト削除されたブロブは、ソフト削除の保持期間中に復元できます。 まだソフト削除していないBlobやバージョンは不変性ポリシーで保護されており、時間ベースの保持ポリシーが終了するか法的保留が解除されるまでソフト削除できません。

BLOB インベントリを使用して不変ポリシーを追跡する

Azure Storage BLOB インベントリは、ストレージ アカウント内のコンテナーの概要と、その中にある BLOB、スナップショット、および BLOB のバージョンを提供します。 BLOB インベントリ レポートを使用すると、リソースに不変ポリシーが構成されているかどうかなど、BLOB とコンテナーの属性を把握できます。

BLOB インベントリを有効にすると、Azure Storage によってインベントリ レポートが毎日生成されます。 このレポートには、ビジネス要件とコンプライアンス要件に関するデータの概要が示されます。

BLOB インベントリの詳細については、「Azure Storage BLOB インベントリ」を参照してください。

ポリシーを大規模に構成する

ストレージ タスク を使って、定義した条件に基づいて複数のストレージアカウントで大規模に不変性ポリシーを設定できます。 ストレージ タスクは Azure Storage Actions で利用できるリソースです。これは、複数のストレージ アカウントにまたがる数百万ものオブジェクトに対して一般的なデータ操作を実行するために使用できるサーバーレス フレームワークです。 詳細については、「Azure Storage Actions とは」を参照してください。

価格

不変ストレージを使用するための追加の容量料金はありません。 不変データは、変更可能データと同じ方法で価格が設定されます。 バージョンレベルの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 機能のサポート」をご覧ください。

次のステップ

• データ保護の概要
• 不変 BLOB データに対するコンテナー レベルの WORM ポリシー
• 不変 BLOB データに対するバージョン レベルの WORM ポリシー
• BLOB バージョンに対する不変性ポリシーを構成する
• コンテナーの不変性ポリシーを構成する