📚 课程目录第1章权限策略基础

1. 权限策略基础：什么是权限策略、策略的构成要素与类型

各位同学好，我是老张。今天咱们开始这门《权限策略动态调整实战演练》的第一章。说实话，我做了十几年安全架构，见过太多因为权限策略没搞明白而翻车的案例。有一次在金融客户现场，就因为一条策略的 condition 写错了，导致整个生产环境的数据库访问全部被拒绝——嗯，那个周末我是在机房度过的。

所以这一章，咱们把地基打牢。你想想看，如果连策略的构成要素都说不清楚，后面谈动态调整就是空中楼阁。

1.1 什么是权限策略

权限策略，说白了就是一套规则。它告诉系统：谁在什么条件下可以对什么资源执行什么操作。

我习惯用一个生活化的比喻来解释：

你家小区门禁卡 → 这是身份凭证
你只能刷开自己那栋楼的门 → 这是资源范围
晚上 11 点后刷卡会报警 → 这是条件限制
你可以开门，但不能拆门 → 这是动作约束

权限策略就是把这些要素写成机器能理解的规则。在云原生环境里，它通常是一段 JSON 或 YAML 格式的声明式配置。

核心观点：权限策略不是「能不能」的问题，而是「在什么情况下能」的问题。动态调整的本质，就是让这个「情况」随着业务状态实时变化。

1.2 策略的四个构成要素

任何一个完整的权限策略，都跑不出这四个要素。我管它叫「权限四件套」：

要素	英文	一句话解释	我踩过的坑
主体	Principal	谁要访问？用户、角色、服务账号	曾经把 service account 当 human user 配策略，审计对不上
资源	Resource	要访问什么？文件、API、数据库表	资源路径写错一个斜杠，权限直接失效
动作	Action	允许做什么？读、写、删除、执行	给了 delete 权限没给 list，运维同学骂了我三天
条件	Condition	什么时候可以？IP 段、时间、MFA 状态	条件写太死，老板出差连不上 VPN 直接打我电话

来看一个真实的 AWS IAM 策略示例，我稍微简化了一下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/DevOpsRole"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::production-bucket/config/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/16"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

你看，这个策略的意思是：DevOps 角色只能在公司内网且开启了 MFA 的情况下，读取 production-bucket 下 config 目录里的文件。每个要素都清清楚楚。

我的习惯：写策略时先画个四象限表格，把 Principal、Resource、Action、Condition 填进去，再转成 JSON。这样不容易漏东西。

1.3 策略类型：基于角色 vs 基于属性

搞清楚了要素，咱们聊聊策略的类型。目前主流就两种：RBAC（基于角色的访问控制）和ABAC（基于属性的访问控制）。

1.3.1 基于角色（RBAC）

RBAC 是最经典的模式。你给用户分配一个角色，角色绑定一组权限。比如：

「管理员」角色 → 所有资源的读写权限
「开发者」角色 → 代码仓库的读写 + 生产环境的只读
「审计员」角色 → 所有资源的只读权限

它的好处是简单直观。我在 2015 年给一家电商公司做权限体系时，就用 RBAC 搞定了 200 多个内部系统的权限管理。但后来问题来了——业务方说：「能不能让市场部的人在工作时间才能访问客户数据？」

RBAC 解决这个问题很笨重：你得新建一个「市场部日间角色」，再重新分配用户。角色数量会爆炸式增长。

1.3.2 基于属性（ABAC）

ABAC 就灵活多了。它不依赖固定的角色，而是根据主体属性、资源属性、环境属性动态计算权限。

举个例子：

# 伪代码逻辑
if (user.department == "market" 
    and resource.type == "customer_data" 
    and environment.time between "09:00" and "18:00" 
    and environment.weekday in ["Monday","Tuesday","Wednesday","Thursday","Friday"]) 
then allow

你看，不需要新建角色，只需要改一条策略条件。这就是 ABAC 的魅力。

对比维度	RBAC	ABAC
管理复杂度	低，角色数量可控时很香	中高，属性设计需要提前规划
灵活性	差，新增场景常需要新建角色	强，改条件即可适配新场景
审计可读性	好，一看角色名就知道权限范围	中等，需要理解属性上下文
动态调整能力	弱，角色变更需要重新绑定	强，条件可以实时生效
典型场景	内部管理系统、传统企业应用	云原生、微服务、多租户环境

我曾经踩过的坑：在一家 SaaS 公司，我一开始全用 RBAC，结果半年后角色数量从 15 个膨胀到 87 个。后来迁移到 ABAC，但属性设计没做好，导致策略评估性能下降 40%。所以我的建议是：小团队用 RBAC，大规模多租户场景用 ABAC，但一定要先做好属性建模。

1.4 知识体系总览

为了让你对本章内容有个整体印象，我画了一张结构图。它把权限策略的核心脉络串起来了：

这张图把咱们这章讲的内容串起来了。从上到下看：策略定义 → 四要素 → 两种类型 → 各自特点。你把它记在脑子里，后面讲动态调整的时候，所有的变化都落在这四个要素上。

1.5 小结

这一章咱们干了三件事：

搞清楚了权限策略是什么——就是一套「谁在什么条件下能对什么资源做什么」的规则
拆解了四个构成要素——主体、资源、动作、条件，一个都不能少
对比了两种策略类型——RBAC 简单但僵化，ABAC 灵活但需要好的属性设计

我个人建议，刚接触权限的同学先从 RBAC 入手，把四要素写熟练了。等遇到「同一个角色在不同环境下权限不同」的需求时，再引入 ABAC 也不迟。我在项目里见过太多人一上来就搞 ABAC，结果属性定义得一塌糊涂，最后连审计都看不懂策略在允许什么。