对象存储接入时，最容易出现的
权限设计问题，是把“应用可以读
文件”简化成“整个桶设为公开”。这会让业务授权、存储策略和访问入口相互纠缠：页面能显示
文件，却无法说明是谁以什么身份读取；一旦出现越权或泄露，也很难判断该收紧应用规则、桶策略还是 CDN 缓存。可靠的做法是分别定义存储身份的能力与应用用户的业务资格，再用允许和拒绝用例验证两层规则共同生效。
一、授权请求由哪些条件组成
一次对象请求通常包含主体、动作、资源和条件。主体可以是应用服务身份、临时角色或匿名访问者；动作包括读取、写入、列举、删除及版本操作；资源由桶和对象键确定；条件可能涉及来源网络、时间、请求头或签名。存储策略判断这个请求能否触达对象。应用则必须先判断登录用户是否对业务记录有权，例如用户是否属于该组织、文件是否属于该用户、记录是否已撤销或归档。
因此，应用服务身份拥有读取某个前缀的能力，并不表示所有登录用户都应该读取该前缀中的对象。应用应该按业务记录做授权，再以服务身份读取，或在授权通过后签发范围受限的短时地址。反过来，即使用户符合业务规则，如果存储层拒绝服务身份访问，请求仍会失败。可将两者概括为“业务允许且存储允许”，任何一层拒绝都应得到预期结果。
🔎 适用场景与身份拆分
后台服务代理读取适用于需要统一审计、复杂业务判断或隐藏对象地址的场景；浏览器直传适用于大文件上传或希望减轻应用服务器带宽压力的场景。直传不等于让浏览器持有长期密钥：应用后端验证用户、目标前缀和配额后，只发出限定操作、对象键和有效时间的签名请求。上传身份一般仅需写入隔离的暂存前缀，读取身份只需读取发布后的内容，生命周期管理等操作交给独立管理身份。
为不同敏感级别建立清晰的资源边界。例如，公开图片可存放在独立发布前缀，用户上传先进入隔离区，合同和备份保持私有。不要让客户端自由指定任意对象键；服务端生成键并将其绑定到业务记录，可以降低猜测键名、覆盖他人对象和上传内容冒充已发布文件的风险。
🧭 二、桶策略应限制资源范围与动作
桶策略承担稳定的资源边界控制。常见约束包括指定身份仅访问某个前缀、禁止匿名列举、限制上传身份不得删除、禁止在线服务读取备份区。策略审阅时不能只看角色名称，还要展开通配符作用范围，确认它是否包含其他租户、临时文件、历史版本或尚未发布的对象。对象键前缀的命名若缺少租户隔离，策略看似精细，实际仍可能把多个业务主体包含在同一范围内。
可用如下只读示例思路核对实际身份和资源范围；具体命令依赖所用云厂商客户端，避免在终端输出长期凭据：
cloud-cli identity show
cloud-cli object head --bucket example-bucket --key test/object.bin
示例中的桶名和对象键应替换为测试环境的虚构或非敏感值。命令输出可以帮助确认当前主体以及对象是否可见，但不能单独证明完整策略正确；还要查看审计事件和其他主体的拒绝结果。
📊 拒绝规则与匿名访问
匿名访问测试至少包括桶列举和已知对象读取。关闭列举并不自动关闭对象读取；对象键不可猜也不等于有效授权。若策略采用允许列表，检查是否有其他宽泛允许规则覆盖预期限制。跨账号调用还需分别确认调用方身份策略与资源侧策略是否都允许，不能因为某一侧显示“允许”就推断请求必然成功。
核心判断：桶策略说明某个身份能对哪些对象执行什么动作；应用授权说明当前用户是否有权获得这个业务对象。两项判断都要成立。
✅ 三、按证据定位拒绝与越权
收到 403 或签名错误时，先取一条可复现请求，记录主体、动作、对象键、时间、请求来源、应用请求标识及签名使用的请求头。检查服务是否拿到了预期身份，凭据是否过期，系统时间是否偏移，签名是否覆盖了客户端实际发送的头字段。然后依序核对身份策略、桶策略、对象级权限、网络入口限制和应用业务授权。对象不存在与无权读取有时会出现相近响应，所以应使用已知存在的无敏感测试对象做对照。
意外成功则从低权限主体出发，尝试读取其他用户对象、列举前缀、覆盖对象、删除对象和访问历史版本。关注响应是否来自 CDN 或浏览器缓存；缓存命中可能掩盖源站权限已经收紧，或者让撤销访问后的内容继续可见。公开与私有内容最好采用不同域名、路径或缓存规则，并分别验证。
诊断指标包括拒绝率按身份与动作的分布、匿名请求数量、签名地址使用时长、被拒对象前缀、跨租户访问尝试，以及策略变更与请求结果的时间关联。仅观察应用端 2xx 比例无法识别缓存响应或越权读取；日志至少应能关联应用用户、服务主体、对象键、结果和请求标识，敏感字段则应避免写入日志。
📌 四、建立可复现的验收矩阵
按主体和动作列出预期结果，测试用例至少覆盖匿名、普通用户、跨租户用户、上传身份、读取身份和管理身份。每种身份分别验证读取、写入、列举、覆盖、删除及版本读取中实际使用的动作。不要只验证“业务主流程成功”：权限验收必须同时包含应成功和应失败的请求。
- 准备一个无敏感测试对象，并写明它所属的用户或租户、对象键与预期访问者。
- 以允许主体执行规定动作，再以匿名和低权限主体执行相同请求及跨范围请求。
- 检查审计记录中的身份、动作、资源、来源、结果和关联标识。
- 等待签名地址过期后重试；验证它只对指定对象和操作有效。
- 发布策略后复测应用代理、浏览器直传、CDN 访问和源站路径，并保存策略版本与结果。
验收结果应能回答：哪个主体可以做什么、对象范围是什么、拒绝请求留下什么证据、策略调整后哪些路径必须回归。若密钥曾进入代码、构建产物或日志，需按凭据管理流程处置并确认旧凭据失效；不要通过扩大公开范围来消除错误。最终的权限设计应让正常业务可用、越权访问失败、请求身份可追踪，并且长期凭据不出现在客户端。
