Locked Container-Level WORM で新規Blobの上書きは拒否されたが削除は成功した

Azure Blob Storage の Container-Level WORM（time-based immutability policy）で、想定外の削除挙動を確認しました。

テスト手順は以下です。

• 新しい専用Containerを作成
• そのContainer内に新しいBlockBlob（record A）を作成
• immutabilityPeriodSinceCreationInDays = 1 のContainer-Level immutability policyを作成
• policyをLockedに変更
• READ-ONLYでstate = Lockedを確認
• record Aへのsame-path overwriteを試行
• 約2秒後、同じrecord AにDelete Blobを実行

結果：

• overwriteは期待通り拒否されました ErrorCode: BlobImmutableDueToPolicy
• しかし約2秒後のDelete Blobはexit code 0で成功しました
• Delete時のstdout / stderrはいずれも空でした
• policyはその後も複数回確認しましたが、state = Lockedのままでした

削除後にREAD-ONLYで確認したところ、record Aはcurrent / deleted / versionのいずれにも存在しませんでした。

az storage blob list --include dvi の結果も空でした。

また、Storage Accountでは以下を確認しています。

• Blob versioning: disabled
• Soft delete: disabled
• Legal hold: none

重要な点として、record Aは古い既存Blobではありません。同じテスト実行内で、

Container不存在確認 → 新規Container作成 → record A作成 → 1-day policy作成 → LOCK

の順で作成しています。そのため、record Aが1日の保持期間を既に満了していたとは考えられません。

Azure Portalの不変Blob Storageのガイダンスでは、保持期間内のBlobは削除できず、Locked policyをバイパスするサポートされた方法もないと説明されています。

質問したい点は以下です。

1. なぜ同じBlobに対してoverwriteはBlobImmutableDueToPolicyで拒否された一方、Delete Blobは成功したのでしょうか。
2. このような挙動を説明できる既知仕様・制限・既知問題はありますか。
3. Container-Level WORMの1日保持期間について、Azure側でどのようなeffective retention expiryが計算された可能性がありますか。
4. Microsoft側で調査するために、追加で取得すべきrequest ID、StorageBlobLogs、Activity Logなどがあれば教えてください。

再現ログ、policy JSON、CLI出力、実行時刻、SHA-256付きEvidenceは保存しています。

なお、これは「Azure全体のWORM機能に問題がある」と主張するものではなく、この特定の実行条件で観測した挙動について原因を確認したいという質問です。Azure Blob Storage の Container-Level WORM（time-based immutability policy）で、想定外の削除挙動を確認しました。

テスト手順は以下です。

• 新しい専用Containerを作成
• そのContainer内に新しいBlockBlob（record A）を作成
• immutabilityPeriodSinceCreationInDays = 1 のContainer-Level immutability policyを作成
• policyをLockedに変更
• READ-ONLYでstate = Lockedを確認
• record Aへのsame-path overwriteを試行
• 約2秒後、同じrecord AにDelete Blobを実行

結果：

• overwriteは期待通り拒否されました
  ErrorCode: BlobImmutableDueToPolicy
• しかし約2秒後のDelete Blobはexit code 0で成功しました
• Delete時のstdout / stderrはいずれも空でした
• policyはその後も複数回確認しましたが、state = Lockedのままでした

削除後にREAD-ONLYで確認したところ、record Aはcurrent / deleted / versionのいずれにも存在しませんでした。

az storage blob list --include dvi の結果も空でした。

また、Storage Accountでは以下を確認しています。

• Blob versioning: disabled
• Soft delete: disabled
• Legal hold: none

重要な点として、record Aは古い既存Blobではありません。同じテスト実行内で、

Container不存在確認 → 新規Container作成 → record A作成 → 1-day policy作成 → LOCK

の順で作成しています。そのため、record Aが1日の保持期間を既に満了していたとは考えられません。

Azure Portalの不変Blob Storageのガイダンスでは、保持期間内のBlobは削除できず、Locked policyをバイパスするサポートされた方法もないと説明されています。

質問したい点は以下です。

1. なぜ同じBlobに対してoverwriteはBlobImmutableDueToPolicyで拒否された一方、Delete Blobは成功したのでしょうか。
2. このような挙動を説明できる既知仕様・制限・既知問題はありますか。
3. Container-Level WORMの1日保持期間について、Azure側でどのようなeffective retention expiryが計算された可能性がありますか。
4. Microsoft側で調査するために、追加で取得すべきrequest ID、StorageBlobLogs、Activity Logなどがあれば教えてください。

再現ログ、policy JSON、CLI出力、実行時刻、SHA-256付きEvidenceは保存しています。

なお、これは「Azure全体のWORM機能に問題がある」と主張するものではなく、この特定の実行条件で観測した挙動について原因を確認したいという質問です。