云控制台全公司共用一个账号？权限没管好，出事都查不到人

上云的第一步通常是买服务器，第二步是登录控制台。问题往往出在第二步：主账号和密码在老板、技术、外包之间传来传去，谁都有一份。用起来是方便了，但一旦出事，谁也说不清是谁做的。

一、共用一个账号，到底有什么问题

• 没有追溯能力：操作日志里只有「主账号」一个身份，删了数据库、改了安全组、开了端口，都查不到具体的人；
• 权限过大：主账号拥有全部权限，一个误操作就可能清空资源，运维新人也不例外；
• 离职与外包风险：人员离开后密码还在对方手里，改密码又会牵动所有使用者；
• 无法满足合规要求：等保测评、客户安全审核，都会看账号分权与操作审计这两项。

二、正确的做法：主账号锁起来，日常用子账号

主流云平台都提供子账号（或称 RAM 用户、IAM 用户）体系。基本思路是：

主账号只做两件事——管理账单和创建子账号，平时不用于日常运维，并开启多因素认证（MFA）。

每个使用者一个子账号，实名到人，包括技术、运维、财务、外包人员。谁操作，日志里就记谁。

按角色分组授权，而不是按人逐个点权限。常见分组如：只读查看、运维操作、财务账单、开发部署。新员工入职归入对应组即可。

三、最小权限怎么落地

「最小权限」听起来抽象，实际可以这么做：

• 默认不给权限，需要什么开什么，而不是先给管理员再慢慢收；
• 高危操作单独管控：删除实例、释放数据库、修改安全组、开放公网端口，这几类操作只授予少数人；
• 生产与测试隔离：给开发和测试的权限不覆盖生产环境，避免调试时误伤；
• 设置权限有效期：临时项目、外包协作，用到期自动失效的授权，比事后手动回收可靠。

四、操作审计别等到出事才开

云平台一般都有操作审计或 ActionTrail 类服务，记录谁在什么时间、从哪个 IP、对哪个资源做了什么操作。这项服务通常按量计费、成本很低，但价值极高。

开启后建议做三件事：把日志投递到独立的存储位置，避免被人一并删除；设置高危操作告警，比如删除数据库、关闭审计、修改安全组；定期抽查，重点看非工作时间的操作和权限变更记录。

五、离职与外包交接的固定动作

人走权限不清，是最常见的漏洞。建议固定成清单：停用子账号 → 回收访问密钥 → 更换其掌握的密码与证书 → 核查其创建的资源 → 检查是否留有后门账号或定时任务。外包团队结束后同样执行一遍。

六、成本上的一个提醒

分权之后，账单也会更清楚。给不同项目打上标签，费用按项目、部门归集，月底就能看出钱花在哪。权限治理和成本治理，其实是同一件事的两面。

写在最后

云上的安全，很大一部分不是技术问题，而是身份与权限的管理问题。花半天时间把主账号锁起来、把子账号建起来、把审计开起来，收益远高于事后补救。名牌商务网提供企业上云的架构与安全配置咨询，帮企业把这套基础规则建好。