如何防止 Blob 容器被删除？

Question

创建和删除 Blob 数据都很容易。有多种方法可以防止意外数据丢失，例如：

• 资源锁可防止存储帐户被意外删除
• Azure RBAC 用于限制对帐户/密钥的访问。
• 软删除可从意外的 blob 删除中恢复。

这已经是一个很好的包了，但感觉还有一个薄弱环节。AFAIK，blob 容器缺乏帐户/blob 的安全性。

考虑到容器是用于 blob 枚举和批量删除的良好单位，但这很糟糕。

如何防止容器意外/恶意删除并降低数据丢失的风险？

我考虑过的..

想法1：将所有数据的副本同步到另一个存储帐户 - 但这会带来同步复杂性（增量副本？）和显着的成本增加。

想法 2：锁定密钥并迫使每个人都在仔细范围内的 SAS 密钥上工作，但这对于数十个 SAS 令牌及其续订来说很麻烦，+有时实际上需要并授权删除容器。感觉复杂到足以打破。无论如何，我更喜欢安全。

想法 3：以某种方式撤消删除？根据删除容器文档，容器数据不会立即消失：

删除容器操作将指定的容器标记为删除。该容器及其中包含的任何 blob 稍后都会在垃圾收集期间删除。

不过，没有关于存储帐户垃圾收集何时/如何工作，或者容器数据是否/如何/多长时间可以恢复的信息。

我错过了什么更好的选择吗？

Answer 1

更新：

• DO为容器启用软删除保护

这类似于 Blob 级别的保护，并允许从意外删除中恢复。作为需要采取的额外措施，下面的原始答案仍然具有相关性。

没有单一的灵丹妙药..回顾一下可以做什么：

预防措施

• 请应用存储帐户级别保护（资源锁）。
• 请仅将帐户/容器删除权限限制为真正需要的调用者。
• 请务必将容器标记为“Leased for infinity”。

尽可能将托管服务身份与 RBAC 结合使用，或者使用 SAS（和访问策略）委派具有有限权限的访问权限。这首先减少了可能发生意外/恶意删除的参与者和场景。

租约不能防止恶意删除，但更清楚地声明“不删除”意图，并且需要采取额外的步骤来删除租约行为，例如附加一层“您确定吗？”问题。

恢复措施

AFAIK, no built-in recovery tools exists when entire container is already deleted.

• DO implement periodic backup solution for disaster recovery.
• CONSIDER contacting Azure support immediately, if you have no own backup.

Like with all backup solutions, do backup to locations of different security contexts and/or offline to avoid losing backups as well in the same incident. A few blob container backup implementation tips:

• Azure Data Factory Copy activity can be configured copy only new files.
• Azcopy sync can also do incremental copying.

If you have no backup to restore from, then the container may still be recoverable by MS (if you are lucky and fast enough). According to Delete Container documentation the container data is not gone immediately:

The Delete Container operation marks the specified container for deletion. The container and any blobs contained within it are later deleted during garbage collection.