你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
使用处于一次写入、多次读取 (WORM) 状态的不可变存储来存储业务关键 Blob 数据
Azure Blob 存储的不可变存储使用户能够以 WORM（一次写入，多次读取）状态存储业务关键的数据。 在 WORM 状态下，在用户指定的间隔内无法修改或删除数据。 为 Blob 数据配置不可变性策略可以防范数据被覆盖和删除。
Azure Blob 存储的不可变存储支持两种类型的不可变性策略：
基于时间的保留策略：使用基于时间的保留策略，用户可以设置策略以按指定的间隔持续时间存储数据。 设置基于时间的保留策略后，可以创建和读取对象，但不能修改或删除对象。 保留期过后，可以删除但不能覆盖对象。
法定保留策略：在显式清除法定保留之前，该法定保留会一直存储不可变数据。 设置法定保留后，可以创建和读取对象，但不能修改或删除对象。
可以同时设置这些策略。 例如，用户可以同时具有基于时间的保留策略和相同级别的法定保留集。 要成功写入，必须启用版本控制，或者对数据没有法定保留或基于时间的保留策略。 要成功删除，数据上还不能存在法定保留或基于时间的保留策略。
下图显示了基于时间的保留策略和法定保留在有效时如何防止写入操作和删除操作。
不可变存储之下存在两个功能：容器级 WORM 和版本级 WORM。 容器级 WORM 仅允许在容器级别设置策略，而版本级 WORM 则允许在帐户、容器或版本级别设置策略。
关于 Blob 的不可变存储
不可变存储可以帮助医疗保健组织、金融机构和相关行业（尤其是经纪人-经销商组织）安全存储数据。 不可变存储可以在任何方案中用于防止修改或删除关键数据。
典型的应用程序包含：
法规遵从：Azure Blob 存储的不可变存储可帮助组织达到 SEC 17a-4(f)、CFTC 1.31(d)、FINRA 和其他法规要求。
安全的文档保留：Blob 的不可变存储确保任何用户（甚至包括拥有帐户管理特权的用户）都无法修改或删除数据。
法定保留：Blob 的不可变存储允许用户以防篡改状态存储对诉讼或业务用途至关重要的敏感信息，在删除法定保留之前，可将其持续存储所需的任意时间。 此功能并不仅限于法律用例，而是还可将其视为基于事件的保留或企业锁定机制，其中基于事件触发器或企业策略保护数据的需求则是必需的。
法规符合性
Microsoft 一直在与一家领先的独立评估机构 Cohasset Associates 保持合作。该机构专业从事记录管理和信息治理，可以评估 Blob 不可变存储及其是否符合金融服务行业的相关要求。 经 Cohasset 验证，在用于以 WORM 状态保留 Blob 时，不可变存储符合 CFTC 规则 1.31(c)-(d)、FINRA 规则 4511 和 SEC 规则 17a-4(f) 的相关存储要求。 Microsoft 以这一套规则为目标，因为这些规则代表了全球最规范的金融机构记录保留准则。
Microsoft 服务信任中心已提供 Cohasset 的报告。 Azure 信任中心包含有关 Microsoft 合规认证的详细信息。 若要向 Microsoft 请求有关 WORM 不可变性合规性的证明信，请联系 Azure 支持部门。
基于时间的保留策略
基于时间的保留策略会在指定的间隔内以 WORM 格式存储 Blob 数据。 设置基于时间的保留策略后，客户端可以创建和读取 Blob，但无法修改或删除 Blob。 保留间隔过期后，可以删除 Blob，但无法覆盖 Blob。
范围
可在以下任一范围配置基于时间的保留策略：
- 版本级 WORM 策略：可以在帐户、容器或版本级别配置基于时间的保留策略。 如果它是在帐户或容器级别配置的，则由相应帐户或容器中的所有 Blob 继承它。 如果容器存在法定保留，则无法为同一容器创建版本级 WORM。 这是因为版本由于法定保留而无法生成。
- 容器级 WORM 策略：在容器级配置的基于时间的保留策略将应用于该容器中的所有 Blob。 无法为单个 Blob 配置其自己的不可变策略。
基于时间的策略的保留间隔
基于时间的保留策略的保留间隔最小为 1 天，最大为 146,000 天（400 年）。 在配置基于时间的保留策略时，受影响对象将在有效保留期内保持不可变状态。 对象的有效保留期是 Blob 创建时间和用户指定的保留间隔之差。 由于策略的保留间隔可以延长，不可变存储使用用户指定的保留间隔的最新值来计算有效保留期。
例如，假设用户创建了一个基于时间的保留策略，将保留时间间隔设置为五年。 一年前，在该容器中创建了现有的 Blob testblob1，因此，testblob1 的有效保留期为四年 。 将新 Blob testblob2 上传到容器时，testblob2 的有效保留期为其创建时间开始算起的五年 。
已锁定策略与已解锁策略
首次配置基于时间的保留策略时，将出于测试目的解锁该策略。 完成测试后，可以锁定该策略，以便其完全符合 SEC 17a-4(f) 和其他法规合规性。
已锁定策略和已解锁策略都可以防止删除和覆盖。 但是，可以通过缩短或延长保留期来修改已解锁的策略。 还可以删除已解锁的策略。 无法删除已锁定的基于时间的保留策略。 可以延长但不能缩短保留期。 在容器级别定义的已锁定策略的整个生命周期内，最多可以延长有效保留期五次。 针对 Blob 版本配置的策略的有效期延长次数没有限制。
重要
根据 SEC 17a-4(f) 和其他法规符合性要求，基于时间的保留策略必须处于锁定状态才能确保 Blob 既兼容又不可变（不可写入和删除）。 Microsoft 建议将策略锁定合理的时间，通常不到 24 小时。 虽然已解锁状态提供不可变性保护，但不建议将已解锁状态用于除短期测试以外的其他目的。
保留策略审核日志记录
每个启用了基于时间的保留策略的容器都会提供策略审核日志。 审核日志包含已锁定基于时间的保留策略的最多七个基于时间的保留命令。 锁定策略后，通常会启动日志记录。 日志条目包括用户 ID、命令类型、时间戳和保留间隔。 根据 SEC 17a-4(f) 法规准则，审核日志将会在策略生存期内保留。
Azure 活动日志提供有关所有管理服务活动的更全面日志。 Azure 资源日志保留有关数据操作的信息。 由用户负责根据法规要求或其他要求永久存储这些日志。
不会审核对版本级基于时间的保留策略所做的更改。
法定保留
法定保留是一种临时不可变策略，可用于法律调查目的或常规保护策略。 在显式清除保留之前，法定保留会使用一次写入、多次读取 (WORM) 格式存储 Blob 数据。 法定保留生效时，Blob 可以创建和读取，但不能修改或删除。 如果数据必须保持为 WORM 状态的时间是未知的，请使用法定保留。
范围
可在以下任一范围配置法定保留策略：
版本级 WORM 策略：可以在单个 Blob 版本级别上配置法定保留，以实现对敏感数据的精细化管理。
容器级 WORM 策略：在容器级配置的法定保留适用于该容器中的所有 Blob。 无法为单个 Blob 配置其自己的不可变策略。
标记
容器级法定保留必须与一个或多个用作标识符字符串的用户定义的字母数字标记相关联。 例如，标记可以包含事例 ID 或事件名称。
审核日志
每个具有有效法定保留的容器都提供一个策略审核日志。 该日志包含用户 ID、命令类型、时间戳和法定保留标记。 根据 SEC 17a-4(f) 法规准则，审核日志将会在策略生存期内保留。
Azure 活动日志提供有关所有管理服务活动的更全面日志。 Azure 资源日志保留有关数据操作的信息。 由用户负责根据法规要求或其他要求永久存储这些日志。
不会审核对版本级别法定保留所做的更改。
不可变存储功能选项
下表显示了容器级 WORM 与版本级 WORM 之间差异的明细：
| 类别 | 容器级 WORM | 版本级 WORM |
|---|---|---|
| 策略粒度级别 | 只能在容器级别配置策略。 上传到容器中的每个对象都将继承不可变策略集。 | 可以在帐户、容器或 Blob 级别配置策略。 如果在帐户级别设置策略，则上传到该帐户的所有 Blob 将继承该策略。 容器会遵循相同的逻辑。 如果策略在多个级别设置，优先级顺序将始终为 Blob -> 容器 -> 帐户。 |
| 可用的策略类型 | 可以在容器级别设置两种不同类型的策略：基于时间的保留策略和法定保留。 | 在帐户和容器级别，只能设置基于时间的保留策略。 在 Blob 级别，可以设置基于时间的保留策略和法定保留。 |
| 功能依赖关系 | 使用此功能不需要其他功能作为必备条件或要求。 | 版本控制是使用此功能的先决条件。 |
| 为现有帐户/容器启用 | 可以随时为现有容器启用此功能。 | 根据粒度级别，可能无法为所有现有帐户/容器启用此功能。 |
| 帐户/容器删除 | 在容器上锁定基于时间的保留策略后，仅当容器为空时，才能删除容器。 | 在帐户或容器级别启用版本级 WORM 后，仅当其为空时，才能删除它们。 |
| 支持 Azure Data Lake Storage（启用了分层命名空间的存储帐户） | 具有分层命名空间的帐户支持容器级 WORM 策略。 | 具有分层命名空间的帐户尚不支持版本级 WORM 策略。 |
要了解有关容器级 WORM 的详细信息，请参阅容器级 WORM 策略。 要了解有关版本级 WORM 的详细信息，请访问版本级 WORM 策略。
容器级与版本级 WORM
下表可帮助你确定要使用的 WORM 策略类型。
| 条件 | 容器级 WORM 用法 | 版本级 WORM 用法 |
|---|---|---|
| 数据组织 | 你想要为可按容器分类的特定数据集设置策略。 该容器中的所有数据需要在同一时间段内保持 WORM 状态。 | 不能按保持期将对象分组。 所有 blob 必须根据该 blob 的方案以单独的保留时间存储，或者用户具有混合工作负载，因此一些数据组可以聚集到容器中，而其他 blob 则不能。 可能还需要在同一帐户中设置容器级策略和 Blob 级策略。 |
| 需要不可变策略的数据量 | 无需为每个帐户设置超过 10,000 个容器的策略。 | 你想要针对所有数据或可以按帐户划分的大量数据设置策略。 你知道，如果使用容器级 WORM，则必须超过 10,000 个容器限制。 |
| 对启用版本控制感兴趣 | 你不想启用版本控制是因为成本问题，或是因为工作负载会产生大量的额外版本需要处理。 | 你要么想要使用版本控制，要么不介意使用它。 你知道，如果它们不支持版本控制，你会无法将对不可变 Blob 的编辑或覆盖作为单独的版本。 |
| 存储位置（Blob 存储与 Data Lake Storage） | 你的工作负载完全侧重于 Azure Data Lake Storage。 你目前没有兴趣或计划切换为使用未启用分层命名空间功能的帐户。 | 你的工作负载位于未启用分层命名空间功能的帐户中的 Blob 存储上，现在可以使用版本级 WORM，或者你愿意等待版本控制可供启用了分层命名空间的帐户使用 (Azure Data Lake Storage)。 |
访问层级
所有 Blob 访问层都支持不可变存储。 可以使用“设置 Blob 层”操作更改 Blob 的访问层。 有关详细信息，请参阅 Blob 数据的访问层。
冗余配置
所有冗余配置都支持不可变存储。 有关冗余配置的详细信息，请参阅 Azure 存储冗余。
建议的 Blob 类型
Microsoft 建议配置主要用于块 Blob 和追加 Blob 的不可变性策略。 不建议为存储活动虚拟机 VHD 磁盘的页 Blob 配置不可变策略，因为这会阻止对磁盘的写入，或者如果启用了版本控制，则每个写入都会存储为新版本。 Microsoft 建议在锁定任何基于时间的策略之前，全面查看文档并测试你的方案。
使用 Blob 软删除的不可变存储
为存储帐户配置 Blob 软删除后，软删除将应用于该帐户中的所有 Blob，而不管是否有法定保留或基于时间的保留策略生效。 Microsoft 建议在应用任何不可变性策略之前启用软删除，以提供额外的保护。
如果先启用 Blob 软删除，然后再配置不可变性策略，则在软删除保留策略过期后，将会永久删除已软删除的所有 Blob。 软删除的 Blob 在软删除保留期内可还原。 尚未软删除的 Blob 或版本受不可变性策略的保护，只能在基于时间的保留策略已过期或法定保留被移除之后才能将其软删除。
使用 Blob 清单来跟踪不可变性策略
Azure 存储 Blob 清单提供存储帐户中的容器以及这些容器中的 Blob、快照和 Blob 版本的概述。 可以使用 Blob 清单报告来了解 Blob 和容器的属性，包括是否为资源配置了不可变性策略。
启用 Blob 库存后，Azure 存储每天会生成库存报告。 该报表概述了有关业务和符合性要求的数据。
有关 Blob 清单的详细信息，请参阅 Azure 存储 Blob 清单。
注意
如果对帐户启用了版本级不可变性支持，或者对清单策略中定义的目标容器启用了版本级不可变性支持，则无法在该帐户中配置该清单策略。
大规模配置策略
可以使用存储任务，根据定义的一组条件，在多个存储帐户之间大规模配置不可变性策略。 存储任务是 Azure 存储操作中可用的资源；一个无服务器框架，可用于跨多个存储帐户对数百万个对象执行常见数据操作。 要了解详细信息，请参阅“什么是 Azure 存储操作？”
定价
使用不可变存储不会产生额外的容量费用。 不可变数据的定价方式与可变数据的定价方式相同。 如果使用版本级 WORM，费用可能更高，因为你已启用版本控制，并且存储额外版本会产生相关的成本。 有关详细信息，请查看版本控制定价策略。 有关 Azure Blob 存储的定价详细信息，请参阅 Azure 存储定价页。
创建、修改或删除针对 Blob 版本的基于时间的保留策略或法定保留会产生写入事务费用。
如果未能支付帐单，并且帐户中已有一个基于时间的保留策略生效，则根据你与 Microsoft 签订的合同条款和条件的规定，将适用正常的数据保留策略。 有关一般信息，请参阅 Microsoft 数据管理。
功能支持
此功能与时间点还原和上次访问跟踪不兼容。 此功能与客户管理的计划外故障转移兼容，但上次同步时间后对不可变策略所做的任何更改（例如锁定基于时间的保留策略、扩展保留策略等）将不会同步到次要区域。 故障转移完成后，可以重新设置对次要区域的更改，以确保其符合不可变性要求。 对它们启用了网络文件系统 (NFS) 3.0 协议或启用了 SSH 文件传输协议 (SFTP) 的帐户不支持不可变性策略。
某些工作负载（如 SQL Server 备份到 URL）可创建 blob，然后将其添加到其中。 如果容器具有活动的基于时间的保留策略或法定保留，则此模式不会成功。 有关更多详细信息，请参阅允许受保护的追加 blob 写入。
有关详细信息，请参阅 Azure 存储帐户中的 Blob 存储功能支持。