第4章用户授权与角色管理

4、用户授权与角色管理：RBAC模型与细粒度权限设计

权限管理这件事，说白了就是「谁可以干什么」。我在早期做HMI项目时，吃过一次大亏——操作员误点了系统配置页面，把整个产线的报警阈值改了。嗯，从那以后，我对权限设计就特别较真。

今天咱们聊聊RBAC模型、细粒度权限设计，还有权限继承与冲突怎么解决。这些都是实战中绕不开的硬骨头。

4.1 RBAC模型：工业HMI的权限基石

RBAC，全称是Role-Based Access Control。你想想看，如果每个用户都要单独配置权限，100个操作员就得配100次，累不累？RBAC的思路很简单：把权限赋给角色，再把角色赋给用户。

我在项目中习惯这样设计角色层级：

角色	典型用户	核心权限
操作员	产线工人	监视、启动/停止、确认报警
工艺工程师	工艺调试人员	修改配方、调整参数
维护工程师	设备维护人员	强制输出、固件升级
管理员	系统管理员	用户管理、审计日志、系统配置

为什么要这样分？因为工业现场有个铁律：权限越少，事故越少。操作员只需要看到当前画面，能按启动停止就够了。给他看到配方编辑界面，反而是安全隐患。

核心原则：最小权限原则

每个用户只拥有完成其工作所必需的最小权限集。多一个权限，就多一分风险。

4.2 细粒度权限设计：只读/操作/管理三级体系

光有角色还不够。同一个角色下，不同操作也需要区分。我个人习惯把权限粒度分成三级：

只读（Read）：只能看，不能改。适合报表查看、历史趋势回放。
操作（Operate）：可以执行控制指令。比如启动电机、调节阀门开度。
管理（Manage）：可以修改配置、添加用户、更改权限。这是最高权限。

举个例子。一个工艺工程师，他需要修改配方参数（管理级），但不需要添加新用户（管理级中的子集）。所以细粒度设计要精确到「页面-控件-操作」三级。

我在代码里通常这样实现：

// 权限枚举定义
enum PermissionLevel {
    NONE = 0,
    READ = 1,
    OPERATE = 2,
    MANAGE = 3
}

// 权限检查函数
bool CheckPermission(User user, string pageName, string controlName, PermissionLevel requiredLevel) {
    // 获取用户角色
    Role role = GetUserRole(user);
    // 获取该角色在指定控件上的权限
    PermissionLevel actualLevel = GetPermission(role, pageName, controlName);
    // 比较
    return actualLevel >= requiredLevel;
}

你可能会问：为什么不用布尔值？因为工业场景下，权限是连续的。只读是1，操作是2，管理是3。这样比较起来特别方便。

实战小技巧：

我建议在HMI的每个控件初始化时，都调用一次权限检查。不要等到用户点击了才检查——那样用户体验很差。提前把不可用的控件置灰或隐藏，操作员一看就知道哪些不能碰。

4.3 权限继承与冲突解决

权限继承，说白了就是「上级角色拥有下级角色的所有权限」。比如管理员角色继承工程师角色，工程师角色继承操作员角色。这样设计的好处是：你只需要定义差异权限，不用重复配置。

但问题来了——冲突怎么办？

我曾经遇到一个真实案例：某个用户同时属于「操作员」和「维护工程师」两个角色。操作员角色对「参数修改」页面是只读权限，维护工程师角色对该页面是管理权限。那这个用户到底能干什么？

解决冲突，我一般用两种策略：

最大权限优先：取所有角色中的最高权限。适合需要灵活操作的场景。
最小权限优先：取所有角色中的最低权限。适合安全要求极高的场景。

工业HMI我强烈建议用最小权限优先。为什么？因为安全第一。如果一个用户同时有只读和管理权限，让他只能读，最多是打电话找管理员。如果让他能管理，万一误操作，后果可能很严重。

注意：

权限继承要小心「循环继承」。比如角色A继承角色B，角色B又继承角色A，这会导致死循环。我一般在设计阶段就用有向无环图（DAG）来建模角色继承关系，从根源上避免这个问题。

4.4 实战中的权限设计清单

嗯，这里我总结了一份清单，每次做新项目我都会对照检查：

是否定义了至少3个角色层级？（操作员/工程师/管理员）
每个页面的每个控件是否都分配了权限等级？
权限检查是在控件初始化时执行，还是在点击时执行？
用户同时属于多个角色时，冲突策略是否明确？
是否有权限变更的审计日志？
默认权限是否设置为「拒绝」？

最后说一句：权限设计不是一次性的工作。随着产线改造、人员变动，权限配置也需要持续维护。我建议每半年做一次权限审计，把那些「僵尸账号」和「过度授权」清理掉。