很多人第一次用阿里云，是为了上线一个小网站或者跑个测试接口。流程走完，控制台里多出一对字符串，AccessKey ID 和 AccessKey Secret，也就是常说的阿里云密匙。拿到它的人，就能以你的身份调接口、开实例、读写存储。东西不起眼，管不好却容易出事。
这篇文章不讲理论，只说日常怎么把阿里云密匙用稳、管好，顺带聊两个真实场景里的问题。
先看清密匙属于谁
阿里云账号分两类身份。主账号拥有全部权限，子用户和角色则由访问控制（RAM）管理。很多人图省事，直接拿主账号的 AccessKey 写进程序，这是最该避免的做法。主账号密匙一旦泄露，整个账户等于拱手让人，权限没有边界，操作也很难追溯到具体是谁做的。
更稳的做法是：主账号尽量不生成长期密匙，日常操作交给 RAM 用户。每个人、每个系统用各自的身份，权限只给够用的部分。
案例一：一次提交带来的夜间挖矿
下面的场景经过了简化，但这类事故并不少见。某个小团队的后端工程师在本地调试时，把带 AccessKey 的配置文件一起提交进了代码仓库，而仓库恰好是公开的。第二天早上，有人发现账单不对，凌晨有几十台按量付费的服务器被批量创建，全在跑挖矿程序。
复盘下来，问题出在三个地方。密匙直接写在代码里，没有走环境变量或密钥服务。用的是高权限账号，没有做最小授权。还有就是没设费用告警，异常消费涨到几千元才被发现。
密匙最怕的未必是黑客有多厉害，而是它出现在了不该出现的地方。
从源头收紧，具体怎么做
代码里不留密匙
不管用 Java、Python 还是 Node.js，源码里都不该出现硬编码的 AccessKey。可以用环境变量注入，或者使用阿里云官方支持的凭证方式，让程序运行时再去取。确实要用配置文件的话，记得写进 .gitignore，只放在本地或部署环境里。
提交前也可以用扫描工具检查仓库里有没有类似密钥的字符串。这类工具不少是开源的，接入 CI 不麻烦，比一次泄露的损失便宜得多。
权限只给够用的
给 RAM 用户授权时，按“只给需要的”来做。比如一个只负责读取 OSS 文件的服务，就不该有创建 ECS 实例的权限。策略可以细到某个资源或某类操作。写得越细，出问题时影响范围越小。
实际中比较常见的是按用途拆分身份，开发、测试、生产各用一套，互不影响。生产环境的密匙尤其不要和开发共用。
定期轮换，用完就停
密匙不能一劳永逸。可以给每个 AccessKey 定一个轮换周期，比如三个月或半年。轮换时先创建新密匙，等业务切过去、确认没问题，再禁用旧的，最后删除。这样即使旧密匙已经外泄，停用后也会失效。
已经离职的同事、不再使用的项目，对应的密匙要及时禁用。不少安全事件，源头就是一个被忘掉的旧密匙一直有效。
开启多因素认证和操作审计
主账号和高权限的 RAM 用户建议开启多因素认证。密码被猜到，也还多一道门槛。再开通操作审计，记录谁、什么时间、用哪个密匙、做了什么操作。出问题时，有日志才好定位。
费用上也要设预算和告警阈值。哪怕只是简单的消费提醒，也能在异常刚开始的时候就收到通知，而不是月底看账单。
案例二：用临时凭证替代长期密匙
另一个团队的调整值得参考。他们原来给自动化脚本配的是长期有效的 AccessKey，脚本跑在好几台机器上，密匙散落各处，很难管。后来改成临时安全令牌（STS），脚本通过角色扮演拿到只有几十分钟有效期的凭证。即使凭证被打印进了日志，过期后也用不了。
这个思路的重点是减少长期有效的凭证数量。对大多数自动化场景来说，临时凭证更稳妥。
写在最后
阿里云密匙本身不复杂，难的是习惯。主账号密匙锁起来，用 RAM 管人，用环境变量或凭证服务管程序，定期轮换，开审计和告警。这几件事做到，大部分常见风险就能挡在门外。如果你手上还有一对写在配置文件里的主账号密匙，今天就可以去检查一下。
