Azure Blob Storage 实现用户间逻辑隔离的最佳方案

核心概念划分建议 #

针对你场景里的三类存储核心概念，推荐按如下规则使用：

• 存储账户（Storage Account）：无特殊需求（比如跨区域独立容灾、不同性能层级隔离）的前提下，全业务共用一个存储账户即可。服务到服务认证直接给你的微服务分配该存储账户的「存储Blob数据贡献者」Azure AD角色即可，无需硬编码存储账户密钥，安全性更高。
• 容器（Container）：不推荐按单个用户/单个实体维度拆分容器，后续运维管理成本极高。建议仅拆分2个顶层容器：
  • public-assets：设为公共读权限，专门存储头像类所有用户均可访问的公开资产
  • private-resources：设为完全私有权限，存储所有用户私有资源，不同归属的资源用路径前缀区分即可，比如private-resources/tenant/{企业ID}/、private-resources/user/{用户ID}/，后续拓展性更强
• Blob：即具体的文件对象，上传时按业务规则拼接存储路径即可，可在文件名前拼接UUID避免重名冲突。

私有Blob下载权限校验方案评估 #

你当前的设计方案完全可行，是生产环境的主流实现方式，仅需要注意几个细节优化：

1. 上传阶段写入Blob元数据的逻辑正确，除了entity_id、user_id，如果有企业级权限校验需求，还可以同步写入tenant_id（企业ID）、permission_tag等自定义字段，后续权限校验时可直接读取Blob元数据判断，无需额外查询业务数据库，性能更高。注意Azure Blob的元数据键会自动转为小写，上传时需统一命名规范，避免大小写不匹配的问题。
2. 下载流程可完全按你的现有思路落地，具体执行逻辑参考：

用户点击业务侧下载URL → 请求转发至下载服务 → 调用AuthService校验登录态，未登录直接跳转前端登录页 → 登录态校验通过后，根据URL携带的资源标识查询对应Blob的元数据 → 匹配当前用户的权限范围（是否为资源所属用户、是否为同企业授权成员、是否为平台管理员） → 权限校验通过后返回资源内容或临时访问链接。

权限校验通过后的资源返回可以根据你的业务场景二选一：

• 生成有效期10~30分钟的SAS（共享访问签名）临时Blob访问链接，引导用户跳转下载：无需你的下载服务代理流量，节省带宽成本，临时链接过期后自动失效，安全性有保障，更适合大文件下载场景
• 由下载服务直接代理拉取Blob内容返回给用户：不会暴露Blob的原始存储地址，安全性更高，适合小体积、高涉密性的资源场景

补充优化建议 #

• 对外暴露的下载URL不要直接使用Blob原始存储地址，用你自有业务域名+资源ID的形式，比如https://your-domain.com/download/{resource_id}，在服务内部做资源ID到Blob路径的映射，避免暴露存储层的结构信息。
• 如果你的权限规则比较复杂（比如同企业下分多角色权限、动态权限调整），可以不用把所有权限规则存在Blob元数据里，元数据仅存储核心归属字段，权限校验时关联业务库的权限表判断即可，灵活度更高。

内容的提问来源于stack exchange，提问作者user12003867