腾讯云 CAM 权限管理：把子账号、策略和密钥都收到最小
正文
我先说个反常识的结论：CAM 里最危险的操作，往往是"为了省事给子账号加了个全权限策略"。很多团队分不清 CAM 用户、用户组和角色，干脆给每个开发者都发一套全权限密钥，图个不折腾。等到某个密钥被提交进代码仓库、或者离职员工的账号还在跑脚本，才发现权限管理从来没做过。腾讯云 CAM（访问管理，Cloud Access Management）权限管理的核心，就是把"谁能对哪些资源做什么、在什么条件下"讲清楚。
CAM 用户、用户组、角色：三者分工别再混着用
先厘清关系。主账号是开户时那个身份，拥有全部权限、承担付费和实名责任，它的密钥就是最高危凭证，能不用就绝不用。CAM 子账号是在主账号下创建的独立身份，用来给人或系统分配操作权限。很多人把用户组和角色当成近义词，其实定位完全不同：用户是人和长期程序的身份，有独立的登录名和密钥；用户组是权限的集合，把同一岗位的人放进一个组统一挂策略，改一处全组生效；角色是可被扮演的身份，主要解决跨账号访问、云服务授权和临时访问，本身没有永久密钥，靠 STS 下发临时凭证。
这三个概念对应三种管理思路：用户解决"身份是谁"，用户组解决"批量授权"，角色解决"临时借用身份"。一个常见误区是给每个人都建一个独立用户、各自挂一堆策略，人一多就乱成一锅粥；正确做法是先按岗位建组，新员工进组即获得该岗位权限，离岗退组即回收，干净利落。
我用一张表把边界摆清楚，这张表基本是我给客户做权限设计时的第一张图。
身份类型 是否持有独立凭证 典型场景 权限绑定方式
主账号 是（根凭证，最高危） 账户所有者，仅做管理和付费 天然全权限，无法被限制
子用户 是（可登录可发密钥） 长期在岗的员工或运维 直接关联策略或加入用户组
用户组 否（是成员集合） 按岗位批量授权 组内成员继承组策略
角色 是（可被扮演，无永久密钥） 跨账号、服务授权、临时访问 权限策略加信任策略共同决定
临时密钥 是（短期自动失效） 程序、持续集成流水线、临时运维 由 STS 下发，继承角色权限
看这张表要记住一句话：能给人就别给密钥，能用角色就别建常驻用户。 需要自动化跑在云上的场景，优先用角色的临时凭证，而不是给机器发一对永久密钥。这既是安全要求，也是运维省心的做法——毕竟永久密钥一旦散落，你连它躺在哪台机器上都说不清。
策略语法结构与条件限制：最小权限到底怎么写
CAM 策略是一段 JSON，结构其实不复杂：顶层是 version 和 statement，每条 statement 里用 effect 决定允许还是拒绝，用 action 描述操作，用 resource 描述资源范围，可选地用 condition 加限制条件。一条典型的允许查看实例的策略，写出来大概是 {"version":"2.0","statement":[{"effect":"allow","action":["cvm:DescribeInstances"],"resource":["*"]}]}。
写策略最容易翻车的地方有三个。第一是 action 用通配符，写成 cvm:* 甚至 *:*，等于把权限全开，最小权限就无从谈起，应该精确到具体接口，比如 cvm:DescribeInstances、cvm:RebootInstances。第二是 resource 用 *，资源应该尽量收窄到具体资源标识，比如 qcs::cvm:ap-guangzhou:uin/账号ID:instance/ins-xxxx，而不是一把梭全资源。第三是忽略 condition，条件限制是收口的关键，比如用 ip_equal 限定只允许公司出口 IP 调用，或用标签条件、时间条件进一步约束。
关于拒绝和允许的优先级，也要弄明白：显式拒绝优先于允许。也就是说，哪怕某条策略把某个接口放行了，只要另一条策略显式拒绝了它，最终结果就是拒绝。这个机制很适合拿来兜底，比如给一个宽泛的允许策略配一条"禁止操作生产环境标签资源"的拒绝策略，用拒绝兜住容易被误开的边界。
另一个常被混用的概念是预设策略和自定义策略。预设策略是腾讯云预先写好的通用权限模板，开箱即用，适合快速起步；自定义策略是你按业务场景自己拼的，颗粒度更细、边界更准。我的习惯是先从预设策略里挑一个最接近的作为起点，再通过自定义策略逐步收窄，而不是从零手写，也不是一直用预设不细化。因为预设策略通常比较宽，直接长期使用，等于把"方便"当成了"安全"。
我的经验是，策略千万不要一次写太复杂，"先给最小集合、报错了再按需补"比"先给全权限、回头再收"要安全得多。后者几乎永远收不回来——因为业务跑起来了，没人愿意再动权限。真要给某个岗位一组权限，做成多条小策略分别挂载，比堆成一条巨型策略更容易审计，也更容易在出事时精确定位是哪条放得太松。
访问密钥轮换与泄漏处置：AK/SK 是最高危资产
访问密钥由 SecretId 和 SecretKey 组成，简称 AK/SK。它一旦泄漏，攻击者不需要用户名密码、不需要二次验证，拿着密钥就能以你的身份调用接口，甚至创建新的资源来挖矿或窃取数据。AK/SK 泄露出事的速度，通常比你发现的速度快得多。
轮换的规范做法是：建立固定轮换周期，按季度或按团队节奏主动换，而不是等出事；轮换采用"先建新、再切换、后禁用、最后删除"的顺序，避免切换瞬间业务中断；密钥管理避免硬编码，用环境变量、配置中心或专门的密钥管理服务承载，绝不写进代码仓库。密钥从生成的那一刻起就该被人负责，建议给每个密钥标注用途和使用人，一旦要轮换，你能立刻知道它牵连哪些系统。
真出了泄漏，处置顺序一步都不能乱。先立刻在 CAM 控制台禁用该密钥，注意是禁用不是删除，先禁用可以边止血边排查；再通过操作审计翻这段时间的调用记录，看有没有异常来源或异常接口；然后排查有没有被新建的实例、密钥、策略等后门资源；最后修复泄漏源，清理仓库历史、撤换流水线变量，再生成新密钥替换。这里有个细节很多人会漏：光删除泄漏的那把密钥不够。如果攻击者已经用旧密钥创建了新的密钥或角色，你删掉入口，人家照样有备用通道。所以排查后门这一步必须做，它决定了你是治好了病，还是只压住了症状。
临时密钥与主账号保护：把根凭证关进保险箱
临时密钥是 CAM 里最被低估的能力。它由 AssumeRole 等接口下发，有明确的有效期，到期自动失效，权限继承自被扮演的角色。给程序、流水线、临时运维用它，就等于给访问加了个自动过期，泄漏窗口被大幅压缩。相比发永久 AK/SK，临时密钥才是云原生时代的正确姿势——你需要做的只是把角色的权限策略写准，剩下的交给有效期去兜底。临时密钥通常还有一个会话名和超时上限，把超时设短一点，能让"凭证躺在日志里"的风险进一步降低。
至于主账号，它没有权限边界、能被拿来重置一切，所以保护措施要单独做一套。给主账号开启多因素认证，登录密码和动态口令双重校验；主账号不创建、不使用访问密钥，日常运维全部走子账号或角色；开启登录保护和操作保护，敏感操作二次确认；绑定独立的告警邮箱和手机号，任何登录和密钥操作都留痕。我服务客户时看到过太多图方便直接用主账号密钥的团队，平时没事，出事就是账号级灾难。主账号的使用原则只有一条：平时当它不存在。 这句话听起来极端，但它是无数真实事故换来的。
最小权限落地的顺序：从盘点到收敛
最后给一个可执行的落地顺序，别一上来就改策略，容易把业务改挂。第一步是盘点，列出所有子账号、用户组、角色，标出哪些还在用、哪些是僵尸身份。第二步是梳理，把每个人当前实际用到的接口从操作审计里捞出来，作为最小权限的事实依据，而不是凭印象拍脑袋。第三步是收敛，按岗位建用户组，把宽泛策略替换成精确到 action 和 resource 的策略。第四步是收尾，清理长期不用的密钥，给程序换临时密钥，给主账号上多因素认证并停用其密钥。第五步是常态，把密钥轮换和权限复核变成周期任务，而不是一次性运动。
顺序背后的逻辑是先看清、再收紧、后固化。跳过盘点直接收权限，往往是把还在用的能力误删，最后只能退回全权限，反而更糟。这一点我踩过：早年给一个客户的运维子账号收紧 cvm:* 时没先摸清脚本用了哪些接口，改完当晚自动扩容就失败了，只能连夜回滚。从那以后，我坚持所有权限调整都先出一份操作审计清单再动手。
FAQ
Q：CAM 用户组和角色到底有什么区别？
A：用户组是人的集合加权限模板，解决按岗位批量授权；角色是可被扮演的身份，解决跨账号访问、云服务授权和临时访问，本身没有永久密钥。简单说，用户组管谁和你一类，角色管谁可以临时代替你做事。
Q：腾讯云子账号一定要发访问密钥吗？
A：不一定，能用控制台登录加角色授权就够谁用谁登录。只有程序化调用接口的自动化场景才需要密钥，而且优先用角色的临时密钥，而不是永久 AK/SK。
Q：访问密钥泄漏了，先删除还是先禁用？
A：先禁用。禁用能立刻止血，同时保留后续排查的线索；确认真实泄漏并且修复完成后，再删除并生成新密钥替换。删除是最后一步，不是第一步。
**Q：策略里的 resource 写成 * 有什么风险？**
A：意味着这条权限作用到全账号所有同类资源，一旦 action 也放宽，子账号就可能越权操作不属于它的机器。最小权限要求把 resource 收窄到具体资源标识，并按需拆分成多条策略。
Q：主账号密钥能不用就不用，那自动化怎么办？
A：用角色加 STS 临时密钥。给服务或流水线创建一个角色，授予刚好够用的权限，让它按需 AssumeRole 获取短期凭证。这样既满足自动化，又不用把根凭证散落各处。
结语
腾讯云 CAM 权限管理不是一次配置，而是一个持续收敛的过程。建议你这周就做三件事：把主账号的多因素认证打开并停用它的访问密钥、把还在用宽泛策略的子账号列出来、给程序化的密钥排一个轮换周期。权限这件事，平时多花十分钟，出事后能省下十天。需要从零搭建多账号体系的话，也可以找腾讯云代理做一次权限体检，比自己摸着石头过河快得多。