很多人第一次打开阿里云控制台，都会看到一组 AccessKey ID 和 AccessKey Secret，也就是常说的阿里云秘钥。它等于账号的钥匙，拿到的人能调用云资源、创建实例、下载数据。所以比起密码，它更需要认真对待。
秘钥到底管什么
阿里云秘钥由两部分组成。AccessKey ID 标识身份，AccessKey Secret 用来证明身份，可以理解成用户名和密码。程序调用 OSS、ECS、短信等接口时，都要用这对秘钥签名。
麻烦在于主账号的秘钥权限最大。它一旦泄露，攻击者就能以你的身份做任何操作。阿里云官方也建议，主账号不要长期使用 AccessKey，日常工作改用 RAM 子账号。
一个典型案例
下面是一个虚构的场景，但这类事故并不少见。
某个小团队做电商网站，开发小王为了调试方便，把主账号的 AccessKey 直接写进代码，然后把项目推到了代码仓库。他以为仓库是私有的，其实没有设置访问权限。
两天后，团队收到账单提醒，一周内多出几十台陌生的计算实例，全在跑挖矿程序。对象存储里还有几个客户数据桶被下载过。账单多出好几万元，团队又花了一整个周末排查和回滚。
这件事里其实有三个问题：秘钥写死在代码里，用的是主账号，没有任何用量告警。单独出现一个，可能不会出大事，三个叠在一起，就很难收场了。
正确的做法
1. 日常开发不用主账号秘钥
在 RAM 访问控制里新建子账号，只给它完成工作需要的权限。比如只需要往某个 OSS 桶上传图片，就只授予这个桶的读写权限，别直接勾选 AdministratorAccess 图省事。
2. 秘钥不进代码，也不进仓库
秘钥放在环境变量或密钥管理服务里，代码中只读取变量名。提交前可以用扫描工具过一遍，确认没有误提交的 AccessKey。很多泄露都是提交那一下没注意造成的。
3. 能用临时凭证，就别用长期秘钥
前端、移动端或者一次性任务，可以用 STS 临时安全令牌，设好有效期，过期自动失效。即使凭证被截获，能被利用的时间也很短。
4. 不用的秘钥删掉，怀疑泄露就先禁用
长期闲置的秘钥没必要留着。怀疑泄露时，先在控制台把它设为禁用，再创建新秘钥替换业务里的旧值，最后去操作日志里查有没有陌生的调用记录。顺序别反，先禁用再排查，才能止住损失。
5. 设置费用预算告警，开启操作审计
在费用中心配置预算告警，在操作审计里开启日志投递。账单或日志一有异常，就能第一时间知道，不必等到月底对账才发现。
一份简单的自查清单
- 主账号是否还保留着可用的 AccessKey，能不能删除或禁用
- 代码仓库和配置文件里，是否还能搜到 Secret 字符串
- 每个子账号的权限，是否只覆盖了实际用到的资源
- 费用预算告警和操作审计有没有配置
- 超过半年没换的秘钥，是否已经轮换
小结
阿里云秘钥本身并不复杂，难的是长期保持好习惯。把主账号秘钥收起来，用子账号和临时凭证代替，秘钥不进代码，再加上告警和审计，大部分风险就能挡在门外。
