一、权限管理概述：风场监控为什么需要权限管理？
大家好，我是老张。在风电行业摸爬滚打了十几年，今天咱们聊聊权限管理。
说实话，我刚入行那会儿，风场监控系统根本没人在意权限。谁想看就看，谁想改就改。直到有一次——我记得特别清楚，某个值班员误操作，把整个风场的功率曲线参数给改了，导致十几台风机同时报故障。那场面，真是鸡飞狗跳。
从那以后，我深刻意识到：没有权限管理的风场监控，就像敞开大门的变电站，谁都能进来动两下，迟早出事。
1.1 风场监控为什么需要权限管理？
你想想看，一个典型的风场监控平台，每天要处理多少数据？
- 实时功率数据
- 风机运行状态
- SCADA 控制指令
- 运维检修记录
- 财务报表数据
这些数据，有的只能看不能改，有的连看都要审批。说白了，权限管理要解决三个核心问题：
- 谁能访问系统？——身份认证
- 能干什么？——操作授权
- 干了什么？——审计追溯
核心观点：权限管理不是限制人，而是保护系统。保护风机不被误操作，保护数据不被泄露，保护运维人员不被背锅。
1.2 RBAC 模型介绍
RBAC，全称 Role-Based Access Control，基于角色的访问控制。这是目前最主流的权限模型，没有之一。
它的核心思想很简单：用户不直接关联权限，而是通过角色来间接获得权限。
举个例子：
- 你给张三分配了「值班员」角色
- 「值班员」角色拥有「查看实时数据」和「确认告警」的权限
- 那张三登录系统后，就只能看到实时数据，不能修改控制参数
我在项目中遇到过最典型的场景：一个风场有 50 多个运维人员，如果每个人单独配置权限，那简直是噩梦。用了 RBAC 之后，我只定义了 5 个角色——管理员、值班员、检修员、报表员、审计员，所有问题迎刃而解。
我的建议：RBAC 适合 90% 的风场监控场景。如果你刚开始做权限设计，从 RBAC 入手准没错。
1.3 ABAC 模型介绍
ABAC，Attribute-Based Access Control，基于属性的访问控制。这个模型更灵活，但也更复杂。
ABAC 的核心理念是：根据用户、资源、环境的多维属性动态判断权限。
举个例子：
- 用户属性：职位是「检修员」、工龄 5 年
- 资源属性：风机编号是「F01」、状态是「停机检修」
- 环境属性：当前时间是「工作日 9:00-17:00」、IP 地址是「场内网络」
只有当所有属性都满足条件时，才允许操作。比如：只有检修员才能在白天、从场内网络、对停机状态的风机执行检修操作。
避坑指南：我曾经在一个大型风场试点 ABAC，结果策略写得太复杂，运维人员自己都搞不清为什么某些操作被拒绝了。后来我总结了一条经验：ABAC 虽好，但不要滥用。只在需要精细控制的场景使用，比如远程启停、参数修改等高风险操作。
1.4 权限管理的核心三要素
不管用 RBAC 还是 ABAC，权限管理都离不开三个核心要素：用户、角色、权限。
| 要素 | 定义 | 风场监控中的例子 |
|---|---|---|
| 用户 | 系统的操作者，可以是人、设备或第三方系统 | 运维人员张三、SCADA 系统接口、移动巡检 APP |
| 角色 | 一组权限的集合，是用户和权限之间的桥梁 | 值班员、检修员、管理员、审计员 |
| 权限 | 对某个资源执行某个操作的能力 | 查看风机实时数据、修改功率曲线、导出报表 |
这三者的关系，我用一张图来展示：
嗯，这张图很直观。用户、角色、权限三者之间是典型的「多对多」关系。在实际系统中，我们通常用三张数据库表来存储：用户表、角色表、权限表，再加上用户-角色关联表和角色-权限关联表。
总结一下：
- RBAC 是基础，适合大多数场景，简单可靠
- ABAC 是进阶，适合需要精细控制的场景，灵活但复杂
- 三要素 是根基，不管用什么模型，都离不开用户、角色、权限
好了，这一章就聊到这儿。权限管理看似简单，但做不好真的会出大问题。下一章咱们深入讲讲 RBAC 的具体设计，包括角色怎么划分、权限怎么粒度控制，以及我在实际项目中踩过的那些坑。