1. 权限策略入门：从“能不能进”说起
大家好，我是老张。在云平台和系统架构这块摸爬滚打了十几年，今天咱们来聊聊权限策略配置。说实话，这玩意儿看着简单，但坑是真不少。我见过太多团队因为权限没配好，要么数据裸奔，要么业务跑不起来。
权限策略是什么？说白了，就是一套规则。它告诉系统：谁，能对什么东西，做什么操作，在什么条件下可以。你想想看，一个公司的大门，谁可以进，哪个时间段能进，能进到哪一层——这就是最朴素的权限策略。
一句话总结：权限策略 = 主体 + 资源 + 动作 + 环境，四要素缺一不可。
1.1 为什么需要权限策略？
我刚开始做开发那会儿，项目小，就一个管理员账号，所有人共用。后来团队扩张到几十人，问题就来了：测试同学不小心删了生产库的表，运维小哥把配置改错了导致线上崩溃……
为什么会这样？因为没有边界。权限策略的核心价值就三点：
- 安全隔离：每个人只能碰自己该碰的东西。比如前端工程师不需要访问数据库，财务人员不需要看代码仓库。
- 最小权限原则：只给完成任务所需的最小权限。多给一分都是风险。
- 审计追溯：出了问题能查到是谁干的、什么时候干的、干了什么。
我的经验：权限策略不是用来限制业务的，而是用来保护业务的。配置得当，开发效率和安全性能兼得。
1.2 权限策略的核心概念
咱们把权限策略拆开来看，其实就是四个要素。我习惯用一个场景来理解：你（主体）在上班时间（环境），能不能打开财务系统（资源）查看报表（动作）。
1.2.1 主体（Who）
主体就是“谁”要执行操作。可以是用户、角色、服务账号、设备等。我在项目中遇到过最头疼的情况是：一个离职员工的子账号没及时清理，结果被外部攻击者利用，从内部发起了数据窃取。
- 用户：自然人账号，比如张三、李四
- 角色：一组权限的集合，比如管理员、审计员
- 服务账号：应用程序或服务使用的身份，比如备份服务、监控服务
- 组：用户的集合，方便批量管理
1.2.2 资源（What）
资源就是“对什么东西”进行操作。可以是文件、数据库、API接口、服务器、存储桶等。资源通常有层级结构，比如：
- 云存储：项目 > 存储桶 > 对象
- 数据库：实例 > 数据库 > 表 > 行
- 文件系统：目录 > 子目录 > 文件
注意：资源粒度的选择很关键。粒度过粗（比如整个项目），权限太大；粒度过细（比如单行数据），管理成本太高。我曾经见过一个团队把权限配到了数据库的每一行，结果策略数量超过10万条，系统直接卡死。
1.2.3 动作（How）
动作就是“能做什么操作”。常见的动作包括：
| 动作类型 | 示例 | 说明 |
|---|---|---|
| 读取 | Read, Get, List | 查看数据，不修改 |
| 写入 | Write, Create, Update | 新增或修改数据 |
| 删除 | Delete, Remove | 移除数据，风险较高 |
| 管理 | Admin, Manage | 包含所有操作，通常只给管理员 |
嗯，这里要注意：不同系统对动作的命名可能不一样。比如AWS叫“Action”，阿里云叫“Action”，Kubernetes叫“Verb”。但本质都一样——定义允许或拒绝的操作。
1.2.4 环境（Where/When）
环境就是“在什么条件下”允许操作。这是很多人容易忽略的一点。环境条件可以包括：
- 时间：比如只允许工作日上午9点到下午6点操作
- IP地址：比如只允许公司内网访问
- 设备：比如只允许公司配发的笔记本电脑
- 地理位置：比如只允许在中国大陆地区操作
- MFA状态：比如必须开启多因素认证才能执行敏感操作
避坑指南：我曾经给一个金融客户配策略，忘了加IP限制。结果有人从境外登录了管理员账号，差点造成重大损失。从那以后，环境条件我都是必配项。
1.3 四要素的关系
这四个要素不是孤立的，它们组合在一起才构成一条完整的权限策略。我画了一张图，帮你直观理解：
1.4 一个完整的策略示例
光说不练假把式。咱们来看一个真实的权限策略长什么样。以云存储为例，假设我们要允许运维工程师小王在工作时间读取生产环境的日志存储桶：
{
"Version": "2024-01",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"User": "wang.xiaoming"
},
"Action": [
"oss:GetObject",
"oss:ListObjects"
],
"Resource": [
"oss://production-logs/*"
],
"Condition": {
"DateGreaterThan": {
"acs:CurrentTime": "2024-01-01T09:00:00+08:00"
},
"DateLessThan": {
"acs:CurrentTime": "2024-01-01T18:00:00+08:00"
},
"IpAddress": {
"acs:SourceIp": "10.0.0.0/8"
}
}
}
]
}你看，这个策略里四要素全齐了：
- 主体：用户 wang.xiaoming
- 动作：GetObject（读取文件）、ListObjects（列出文件）
- 资源：production-logs 存储桶下的所有文件
- 环境：工作时间（9:00-18:00）+ 内网IP（10.0.0.0/8）
关键点：策略中的 Effect 字段只有两个值：Allow（允许）和 Deny（拒绝）。默认情况下，所有操作都是隐式拒绝的。只有显式允许的操作才能执行。而显式拒绝的优先级高于一切允许——这是安全底线。
1.5 常见误区
我见过太多新手在权限策略上栽跟头，这里列几个最常见的：
- 权限给太大：直接给管理员权限，图省事。结果一个普通员工就能删库跑路。
- 忘了加环境限制：策略里只有主体、资源、动作，没有环境条件。攻击者可以从任何地方发起操作。
- 资源路径写错：少写一个斜杠或者通配符用错，导致权限不生效或者范围过大。
- 忽略隐式拒绝：以为没写Deny就是允许，其实没写Allow就是拒绝。
血的教训：我曾经有个同事，把生产环境的存储桶权限配成了 Resource: "*"，结果整个公司的数据对所有用户开放了。还好发现得早，不然就出大事了。记住：资源范围越小越安全。
1.6 本章小结
好了，咱们把第一章的核心内容捋一捋：
- 权限策略就是一套规则，告诉系统谁能对什么资源做什么操作
- 四个核心要素：主体、资源、动作、环境，一个都不能少
- 默认隐式拒绝，显式允许才能操作，显式拒绝优先级最高
- 最小权限原则是铁律，多一分权限就多一分风险
嗯，这一章算是打地基。后面的章节咱们会深入每种策略类型、实战配置技巧、以及各种云平台的差异。别急，慢慢来，基础打牢了后面才走得稳。