云服权限管理：别让一个误操作毁了整台服务器

公司刚上完新项目，小李兴冲冲地给开发配了云服务器的 root 权限，想着“方便调试”。结果第二天早上，数据库没了——开发同事手一滑，rm -rf /data 执行在了生产环境。这种事听起来离谱，但在实际运维中并不少见。

权限不是越宽越好

很多人觉得，给个管理员权限图省事，反正都是自己人。可问题是，权限越大，出事的概率就越高。一个普通用户误删文件，顶多影响自己；但要是拥有 sudo 权限的人执行了错误命令，整个系统都可能瘫痪。

正确的做法是按需分配。开发只需要部署代码和查看日志？那就只开放对应目录的读写权限，外加重启服务的 sudo 白名单。测试人员要连数据库？单独开个只读账号，限制 IP 段访问。

用 IAM 管理角色，而不是直接给密码

主流云平台（比如阿里云、AWS）都提供 IAM（Identity and Access Management）功能。与其把账号密码到处发，不如创建角色和策略。

举个例子，在 AWS 上你可以定义一个叫 Dev-S3-Access 的策略，只允许访问特定的 S3 存储桶：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::project-data-bucket",
        "arn:aws:s3:::project-data-bucket/*"
      ]
    }
  ]
}

然后把这个策略绑定到开发人员的 IAM 用户上。他能干啥、不能干啥，清清楚楚，改配置也是一键生效。

定期审计，别等出事才翻记录

权限不是一设了之。员工离职、岗位变动、项目下线，对应的权限都得及时调整。建议每个月跑一次权限审查脚本，列出所有拥有 admin 权限的账号，挨个确认是否仍有必要。

阿里云的操作审计（ActionTrail）、AWS 的 CloudTrail 都能查到谁在什么时候执行了什么操作。某天发现某个长期不用的子账号突然调用了删除 RDS 实例的接口，就得立刻警惕了。

最小权限 + 分段验证 = 安全底线

有个团队的做法值得参考：所有高危操作（如删库、关机、改安全组）必须通过审批流程，由另一个有权限的人二次确认。他们用内部工单系统对接云 API，提交申请后自动锁住操作窗口，审批通过才临时提权，5分钟后自动降权。

听起来麻烦？可比起恢复备份花掉的三小时和客户投诉，这点流程根本不值一提。

云服权限管理的核心不是“管人”，而是“防误+控险”。设置合理策略，比事后追责更有意义。