你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Blob 存储中 Azure 角色分配条件的安全注意事项
若要使用 Azure 基于特性的访问控制 (Azure ABAC) 来全面保护资源，还必须保护 Azure 角色分配条件中使用的特性。 例如，如果条件基于文件路径，则你应该注意到，如果主体拥有不受限制的权限，可以重命名文件路径，则访问权限可能会遭到恶意利用。
本文介绍应在角色分配条件中考虑到的安全注意事项。
重要
Azure 基于属性的访问控制 (Azure ABAC) 已正式发布 (GA)，用于使用标准和高级存储帐户性能层中的 request、resource、environment 和 principal 属性控制对 Azure Blob 存储、Azure Data Lake Storage Gen2 和 Azure 队列的访问。 目前，“容器元数据”资源属性和“列出 blob 操作的所含内容”请求属性处于预览状态。 有关 Azure 存储 ABAC 的完整功能状态信息，请参阅 Azure 存储中条件功能的状态。
有关 beta 版本、预览版或尚未正式发布的版本的 Azure 功能所适用的法律条款，请参阅 Microsoft Azure 预览版的补充使用条款。
其他授权机制的使用
仅当使用 Azure RBAC 进行授权时才评估角色分配条件。 如果允许使用备用授权方法进行访问，则可以绕过这些条件：
同理，在采用分层命名空间 (HNS) 的存储帐户中使用访问控制列表 (ACL) 授予访问权限时，将不会评估条件。
可以通过针对存储帐户禁用共享密钥授权，来防止发生共享密钥、帐户级 SAS 和服务级 SAS 授权。 由于用户委托 SAS 依赖于 Azure RBAC，因此，在使用此授权方法时会评估角色分配条件。
保护在条件中使用的存储特性
Blob 路径
使用 Blob 路径作为条件的 特性时，还应该防止用户在使用采用分层命名空间的帐户时通过重命名 Blob 来获取文件访问权限。 例如，如果你要创建一个基于 Blob 路径的条件，则还应限制用户访问以下操作：
| 操作 | 描述 |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action |
此操作允许客户使用“路径创建”API 重命名文件。 |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action |
此操作允许访问各种文件系统和路径操作。 |
Blob 索引标记
Blob 索引标记用作存储中条件的自由格式特性。 如果使用这些标记创建任何访问条件，则还必须保护标记本身。 具体而言，Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction 允许用户修改存储对象的标记。 可以限制此操作，以防止用户通过操控标记键或值来获取对未经授权的对象的访问权限。
此外，如果在条件中使用了 Blob 索引标记，则在通过单独的操作更新数据和关联的索引标记的情况下，数据可能会易受攻击。 可以对 Blob 写入操作使用 @Request 条件来要求在同一更新操作中设置索引标记。 这种方法有助于从数据写入存储的那一刻起就开始保护数据。
复制的 Blob 上的标记
默认情况下，在使用复制 Blob API 或其任何变体时，Blob 索引标记不会从源 Blob 复制到目标。 若要在复制时保留 Blob 的访问权限范围，还应该复制标记。
快照上的标记
无法修改 Blob 快照上的标记。 因此，必须在创建快照之前更新 Blob 上的标记。 如果修改某个基本 Blob 上的标记，则此 Blob 的快照上的标记会继续采用以前的值。
如果在创建快照之后修改某个基本 Blob 上的标记，则该基本 Blob 和快照的访问权限范围可能不同。
Blob 版本上的标记
通过放置 Blob、放置块列表或复制 Blob API 创建 Blob 版本时，不会复制 Blob 索引标记。 可以通过这些 API 的头指定标记。
可以在当前基本 Blob 和每个 Blob 版本上单独设置标记。 修改基本 Blob 上的标记时，不会更新以前版本上的标记。 如果你要使用标记更改某个 Blob 及其所有版本的访问权限范围，必须更新每个版本上的标记。
版本与快照的查询和筛选限制
使用标记查询和筛选容器中的 Blob 时，响应中只会包含基本 Blob。 不会包含具有所请求的键和值的 Blob 版本或快照。
角色和权限
如果对 Azure 内置角色使用角色分配条件，应仔细检查该角色向主体授予的所有权限。
继承的角色分配
可为管理组、订阅、资源组、存储帐户或容器配置角色分配，并在每个级别按此顺序继承这些角色分配。 Azure RBAC 采用累加模型，因此，有效权限是每个级别的角色分配的总和。 如果通过多个角色分配为某个主体分配了相同的权限，则会在每个级别根据每个分配单独评估使用该权限执行的操作的访问权限。
由于条件是作为角色分配中的条件实现的，因此任何无条件角色分配都可能允许用户绕过该条件。 假设你将“存储 Blob 数据参与者”角色分配给了订阅中的某个存储帐户的用户，但只将某个条件添加到了该存储帐户的分配。 结果就是，用户可以在订阅级别通过角色分配不受限制地访问该存储帐户。
因此，应该针对资源层次结构中的所有角色分配一致地应用条件。
其他注意事项
写入 Blob 的条件操作
许多写入 Blob 的操作需要 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write 或 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action 权限。 存储 Blob 数据所有者和存储 Blob 数据参与者等内置角色会向安全主体授予这两种权限。
在这些角色上定义角色分配条件时，应该对这两种权限使用相同的条件，以确保对写入操作实施一致的访问限制。
“复制 Blob”和“从 URL 复制 Blob”的行为
对于复制 Blob 和从 URL 复制 Blob 操作，只会针对目标 Blob 评估使用 Blob 路径作为 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write 操作及其子操作中的特性的 @Request 条件。
对于源 Blob 上的条件，将评估 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read 操作上的 @Resource 条件。