接阿里云的时候，很多人第一次卡住，往往就卡在鉴权上。请求被拒、签名报错、提示没有权限，这些信息看着五花八门，多数时候落到同一个地方：身份凭证没配对，或者权限没给够。先把基本逻辑理清楚，后面排查会快很多。
鉴权到底在验证什么
鉴权其实包含两件事。认证解决“这个请求是谁发的”，授权解决“它能做哪些操作”。阿里云用访问控制（RAM，Resource Access Management）统一管这两层。每次调用云API，请求里都要带上能证明调用方身份的签名。云端先验签，签名通过后，再去查这个身份对目标操作有没有权限。
所以排查时通常绕不开三样东西，分别是凭证、签名和策略。凭证标明身份，签名保证请求没有被改动，策略划定权限范围。少了哪一个，请求都过不去。
常见的凭证类型怎么选
日常接触到的凭证大致有四种。
- 阿里云账号的AccessKey：主账号下生成的密钥对，权限最大。除了账号本人的管理操作，业务程序里尽量不要用。
- RAM用户的AccessKey：为具体的人或程序单独创建的子身份，日常开发最常用，多数情况下是首选。
- STS临时凭证：由安全令牌服务颁发，有效期可控。跨账号访问、移动端这类不适合放长期密钥的场景，适合用它。
- RAM角色：允许其他服务或账号临时扮演。ECS实例、函数计算这类运行环境里，通常直接绑定角色，代码里不用出现密钥。
选哪种，主要看三个问题：调用方是谁，代码跑在哪里，这份凭证要用多久。能用临时凭证就别用长期密钥，能绑角色就别把密钥写进代码。这条规则听起来简单，但很多事故都是从“先随便写上再说”开始的。
一个订单服务调用OSS失败的案例
某电商团队的订单服务要把导出的对账文件上传到OSS。开发阶段直接用了主账号AccessKey，功能跑通就上线了。三个月后安全审计要求收回主账号密钥，服务突然全部报错，日志里是“Forbidden”，代码却一行没动。
后来的排查顺序是这样的。
- 先确认密钥已经被禁用，这是报错的直接原因。
- 再查凭证来源，发现密钥硬编码在配置文件里，同样的内容分散在四个微服务中。
- 梳理调用链后，为订单服务单独建了一个RAM用户，只附加允许写入指定Bucket的自定义策略。
- 凭证从配置文件挪到环境变量里，后续计划改用RAM角色加STS。
这件事给团队留下的教训很具体：主账号密钥不承担业务调用，权限按最小化授予，密钥也不跟着代码到处复制。鉴权出问题的时候，根子往往在最早那几次的配置习惯上。
签名环节容易踩的坑
阿里云的多数API采用HMAC-SHA1或HMAC-SHA256签名。大致过程是把请求参数按规则排序、编码，再用AccessKey Secret算出摘要。这一步看着机械，出错率却不低，常见问题有四类。
- 参数没有按字典序排序，签名对不上。
- URL编码不规范，空格和特殊字符最容易出问题。
- 服务器时间偏差太大，触发时间戳校验失败。检查一下本机时间同步就能排除。
- 代码里还在用已过期或已禁用的AccessKey。
如果确实要手动拼签名，建议对照官方文档一步步核对。更省事的做法是直接用阿里云官方SDK，签名流程交给SDK处理，人为出错的机会少很多。
用RAM策略收紧权限
RAM策略是JSON格式，核心字段有三个，分别是Effect（允许或拒绝）、Action（操作）和Resource（资源）。下面这段策略只允许向某个Bucket写入对象。
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"oss:PutObject"
],
"Resource": [
"acs:oss:*:*:your-bucket-name/*"
]
}
]
}其中 your-bucket-name 是占位符，换成实际的存储空间名即可。写策略时，Action尽量写到具体操作，通配符能不用就不用，否则很容易给出远超需要的权限。Resource也一样，尽量限定到具体资源。如果还要限制来源IP或生效时间，就在Condition字段里补充条件。
鉴权失败怎么排查
遇到报错，可以按下面的顺序过一遍。
- 凭证本身是否有效，有没有被禁用或过期。
- 该身份是否具备目标操作的权限，可以用策略模拟工具验证一下。
- 签名参数和时间戳是否正确。
- 去操作审计（ActionTrail）里查被拒绝的具体动作，报错信息往往在这里说得最清楚。
排查时先分清是认证失败还是授权失败。前者多半是凭证或签名的问题，后者是策略没配对。两者修法不同，方向搞反了会白忙很久。
小结
阿里云鉴权拆开看，就是凭证、签名、策略三层配合。日常开发里，优先用RAM子账号或角色，策略按实际需要收窄，签名交给官方SDK，出问题时去审计日志里查。习惯建立起来，下次遇到鉴权报错，定位会快很多。
