云时代的身份安全：别再靠“密码123456”扛风险了

作者｜Echo_Wish

说句大实话：
在上云这件事上，大多数企业都很兴奋——弹性扩容爽、自动化运维爽、算力便宜爽——唯独“身份安全”这块儿，很多公司兴奋不起来。

为什么？

因为云时代最大的风险不是服务器宕机，也不是带宽不够，而是“谁在访问你的资源，你根本不知道”。
而你不知道的东西，往往是最危险的。

这篇文章，我们就好好聊聊云时代的 身份安全与访问控制（Identity & Access Management，IAM）。我会用通俗的例子、必要的小代码，以及一点点作为老运维的良心经验，带你把这个概念啃透。

一、为什么身份安全在云时代这么关键？

以前在机房时代，安全靠什么？
靠门禁卡、靠物理隔离、靠身后那一堵墙。

但云不是这样的。云像一座“虚拟城市”，所有资源都暴露在 API 之下。
你一个权限没配好，后果可能是这样的：

• S3 桶公开 → 数据被人爬走
• 云主机凭证泄露 → 整个账单被挖矿打爆
• 凭证权限太大 → 一个脚本误删生产环境
• 开发同事离职 → 你忘记注销他的访问凭证

云时代的访问方式变了，风险也成倍放大了。

所以我常说一句话：

上云成功不叫成功，能在云上活下来才叫成功。

而 IAM，就是你在云上活下来的底层基石。

二、身份是什么？不是用户名密码那么简单

我们先厘清一个概念：

身份（Identity）不是“账号”，而是“谁有权访问什么资源”。

在云平台上，常见的身份包括：

• 用户（User）
• 角色（Role）
• 服务账号（Service Account）
• 临时凭证（STS Token）
• 设备身份（比如 IoT）

不同身份在云里扮演不同的角色。

举个例子：

• 你是开发 → 应该能读写 Dev 环境
• 测试是测试 → 不能动生产
• CI/CD 机器人 → 能部署但不能登录服务器
• 数据分析服务 → 能读数据库但不应该能删表

如果把所有人都给 root 权限，那跟把办公室钥匙给全公司一样荒诞。

三、访问控制核心思想：RBAC → ABAC → PBAC

云时代 IAM 的演进，本质上就是一句话：

从“凭感觉授权”走向“可控可解释的授权”。

让我们按顺序讲讲。

1）RBAC —— 角色为主（Role-Based Access Control）

传统方式，最常见：

• 你是 DBA → 你有 DBA 角色
• 你是 SRE → 你有 SRE 角色

简单明了，但问题也明显：

• 角色越配越多
• 权限越配越大
• 最终人人都是 admin

这在云上等于玩火。

2）ABAC —— 属性为主（Attribute-Based Access Control）

云时代更推荐 ABAC：

权限 = 用户属性 + 资源属性 + 请求条件

比如：

• 用户属性：部门=研发
• 资源属性：环境=Dev
• 条件：工作时间 9:00–19:00

这就能实现：

研发只能在工作时间访问开发环境资源。

这才叫“安全策略”，而不是“拍脑袋的权限划分”。

3）PBAC —— 策略为主（Policy-Based Access Control）

现在更先进的是策略控制：

• JSON/ YAML 写策略
• 精准描述可执行动作、资源范围、来源 IP、MFA 要求等

虽然看起来很技术化，但其实并不难。

四、上手示例：写一个最小的 IAM 策略

下面举一个精细控制 S3 桶访问的 AWS IAM policy，示例用 JSON（云厂商差别不大）：

{
   
  "Version": "2012-10-17",
  "Statement": [
    {
   
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::project-dev-data/*",
      "Condition": {
   
        "StringEquals": {
   
          "aws:PrincipalTag/department": "dev"
        }
      }
    }
  ]
}

含义很明确：

• 只允许用户读取 project-dev-data 桶
• 用户必须带有标签 department=dev
• 写操作全部禁止

这就是一个典型的 ABAC。

如果你在企业里能把 70% 的权限改成这种“最小授权策略”，安全能力至少提升 5 倍。

五、再来点实际的：如何给机器（而不是人）做身份？

云时代最危险的不是人，而是 机器：

• CI/CD 脚本
• Lambda / Function
• K8s Pod
• 数据同步程序
• 各种边缘节点

如果还在用“写死 AccessKey”这种上古方式，你离事故只差一个 Git 泄露。

安全方式应该是：

身份 → 角色 → 临时凭证（STS）→ 自动轮转

示例（伪代码）：

import boto3

sts = boto3.client("sts")

creds = sts.assume_role(
    RoleArn="arn:aws:iam::1234567890:role/CIDeployRole",
    RoleSessionName="ci-runner"
)["Credentials"]

print(creds["AccessKeyId"])
print(creds["SecretAccessKey"])
print(creds["SessionToken"])

特点：

• 临时凭证自动过期
• 权限严格隔离
• 日志可追踪到具体服务

这比写死在代码里的 AccessKey 安全十万倍。

六、云时代访问控制的黄金法则（这部分超有价值）

作为一个在运维领域摸爬滚打多年的老兵，我总结了云端 IAM 的“五条铁律”。
每一条都是血泪换来的。

① 默认拒绝，按需授权（Deny by Default）

能不给就不要给，能少给就少给。
“临时授权 + 自动过期”是最理想模式。

② 人机分离（Human ≠ Machine）

人用人类账号
服务用服务账号
千万不要混着来。

③ 分环境隔离（Prod ≠ Dev ≠ Test）

这句话看似简单，但 80% 的企业都栽在这里。

• Dev 权限可以大
• Prod 权限必须小
• Audit（审计）必须独立

④ 所有 API 调用都要可追踪（Audit Logging）

你要知道：

• 谁做了什么
• 在什么时候
• 从什么地方
• 成功还是失败

安全不是“不出事”，而是“出了事能查清楚”。

⑤ 访问需要多因子认证（MFA）

尤其是：

• 控制台访问
• root 账号
• 高风险 API（比如删除资源）

MFA 是上云时代最有效的“杀手级防线”。

七、图例：IAM 架构全景图（便于理解）

看到上图你会发现：

IAM 是整个云平台的“总闸门”。
数据流、服务调用、用户请求、自动化脚本，全都绕不开它。

所以 IAM 搞不好，上云一切白搭。

八、写在最后：身份安全，是云时代的“地基”

我见过不少企业“上云很快，掉坑更快”。

本质原因就是：

没把身份安全当成工程项目来建设。

IAM 不是文档，也不是权限表，它是：

• 组织架构的模型化
• 权限的工程化
• 风险的可视化
• 合规的制度化

云时代的某一天你会突然明白：

没有身份安全，一切云能力都是幻觉。