一、先定原则三级权限不是三个账号而是三层控制工控场景的三级划分比较收敛操作员仅监控、启停无修改权工程师可参数修改、配方编辑无系统配置权管理员拥有全权限及用户管理。但要提醒一点角色分级 ≠ 权限分级。真正落地时权限粒度至少要分三层——模块权限菜单级、功能权限按钮级、数据权限范围级数据权限还需从创建者、组织、业务维度做隔离。也就是说同样是工程师A 工程师能不能看 B 产线的配方这是数据级问题光靠角色表解决不了。二、数据模型设计标准 RBAC 五张表用户表users、角色表roles、权限表permissions、用户角色关联表user_roles、角色权限关联表role_permissions角色可支持继承机制子角色自动继承父角色权限通过 parent_id 字段或递归查询实现。工控侧的实体可以简化但权限一定要用编码而不是名称权限实体绑定功能编码如 ParamEdit、PlcDownload、UserManage工控场景用编码更稳定角色预设三类批量分配权限用户绑定角色登录验证后加载权限。密码存储别偷懒敏感字段如密码必须采用强哈希算法如 PBKDF2 或 bcrypt.net加盐存储严禁明文或弱加密。三、校验实现前端防君子后端防小人这是最容易出问题的地方。常见错误是只在界面层做了控制方法内部没校验等于没做。推荐双重控制控件显隐/禁用 功能方法拦截。具体到代码层面主窗体加载时动态构建 MenuStrip 或 ToolStrip依据当前用户权限集合过滤菜单项按钮 Click 事件中调用 PermissionService.HasPermission(“User_Delete”) 做运行时鉴权关键业务方法如删除用户内部再嵌套一次权限校验失败则抛出自定义 InsufficientPermissionException 并给出友好提示。有个开源项目的做法值得参考按钮级别的显示隐藏 服务层二次校验前端防君子后端防小人。另外有个容易忽略的保护项默认保留操作员和管理员角色禁止删除仅允许修改其权限避免误操作导致系统无法登录。四、操作日志字段设计比实现更重要日志的核心价值在于事后能还原现场。建议字段时间、用户、操作类型、操作对象、操作内容具体值、结果成功/失败、IP 地址。关键一点修改类操作必须记录变更前后的值。更完整的表结构可以扩展为记录操作人 ID、操作类型、目标资源、操作时间、IP 地址、客户端主机名、请求参数摘要、执行结果状态码及异常堆栈信息。存储与保留策略存储位置用数据库便于查询保留时长建议至少 1 年超期自动清理并配合定期导出归档。合规口径上重要设备、平台、系统访问和操作日志留存时间不少于 6 个月并需定期离线备份防止篡改——实际项目建议取两者中更严的那个。五、案例分析案例 1多角色共用一台上位机的权限冲突这是产线上很真实的矛盾操作员要一直登录着看生产但工艺员临时来改个参数怎么办比较稳妥的两种方案一是弹窗二次身份校验——操作员保持前台生产登录不退出生产数据绑定操作员 ID工艺员或管理员通过独立弹窗做身份校验通过后临时开放参数编辑权限操作日志记录实际执行人生产数据仍归属当班操作员参数保存后权限自动回收。二是系统级双会话权限委派——上位机分前台生产会话操作员独占与后台管理会话独立子进程子进程与主进程共享数据库及生产工单上下文工艺修改操作单独写入操作人日志。这里的关键设计点是**操作人和数据归属人要分成两个字段**否则审计时会出现参数是工艺员改的但记录显示是操作员的扯皮。案例 2设备状态参与权限判定纯静态 RBAC 在设备异常时会失效。半导体行业的做法是把设备状态纳入校验按岗位-技能-设备三维度设置权限矩阵操作员仅能执行启动、停机等基础操作工程师可调整工艺参数维护人员仅能在设备待机时检修管理人员有审计权限但不能直接操作设备动态适配机制结合设备状态实时校验操作合法性——设备故障时临时向维护人员开放诊断权限故障排除后自动回收若操作人员试图在设备运行中调整关键参数系统立即弹出预警并锁定操作界面同时同步至管理人员终端。审计侧要求也相应提高全维度记录操作人-时间-内容-环境-设备五大要素所有信息带时间戳和唯一标识确保不可篡改权限申请、调整、回收必须留存申请人、审批人、执行人记录。案例 3SQLite 单机场景的加固思路如果项目是单机部署、不想上数据库服务器要注意 SQLite 原生不支持用户认证与 ACL权限管理完全依赖应用层实现。可选的加固路径为每个功能按钮分配 2^n 权限值登录时预加载权限集合至内存通过逻辑与运算动态控制 MenuStrip、ToolStrip 及控件的 Visible/Enabled/ReadOnly 属性关键操作事件需二次校验数据层可选用 SQLCipher 实现 AES-256 透明加密配合 PRAGMA secure_deleteON 防止数据恢复审计侧用独立日志表记录敏感操作时间戳、操作者、SQL 哈希、影响行数并支持定时自动备份与一键恢复。六、几个容易踩的坑事务一致性。新建用户 分配角色 写入日志这类跨表操作要用 TransactionScope 或显式 BeginTransaction 保障 ACID否则容易出现用户建了但角色没绑上的脏数据。权限变更本身也要留痕。设计时应遵循最小权限与职责分离原则并记录权限变更日志以供审计。别把能看和能点混为一谈。权限控制点至少要覆盖菜单可见性没权限就不显示、按钮可用性能看不能点、数据可见范围、参数修改权限。日志只增不改。这是审计的底线要求——日志不能改、不能删且必须存够年限。如果你说明一下是单机还是多机联网、有没有合规审计要求GMP/IATF 之类我可以把表结构和日志字段再具体收敛一版。 
长河君 · 2026/10/3 2:39:48 · 阅读 1.2k 先定原则：三级权限不是“三个账号“，而是三层控制
一、先定原则三级权限不是三个账号而是三层控制工控场景的三级划分比较收敛操作员仅监控、启停无修改权工程师可参数修改、配方编辑无系统配置权管理员拥有全权限及用户管理。但要提醒一点角色分级 ≠ 权限分级。真正落地时权限粒度至少要分三层——模块权限菜单级、功能权限按钮级、数据权限范围级数据权限还需从创建者、组织、业务维度做隔离。也就是说同样是工程师A 工程师能不能看 B 产线的配方这是数据级问题光靠角色表解决不了。二、数据模型设计标准 RBAC 五张表用户表users、角色表roles、权限表permissions、用户角色关联表user_roles、角色权限关联表role_permissions角色可支持继承机制子角色自动继承父角色权限通过 parent_id 字段或递归查询实现。工控侧的实体可以简化但权限一定要用编码而不是名称权限实体绑定功能编码如 ParamEdit、PlcDownload、UserManage工控场景用编码更稳定角色预设三类批量分配权限用户绑定角色登录验证后加载权限。密码存储别偷懒敏感字段如密码必须采用强哈希算法如 PBKDF2 或 bcrypt.net加盐存储严禁明文或弱加密。三、校验实现前端防君子后端防小人这是最容易出问题的地方。常见错误是只在界面层做了控制方法内部没校验等于没做。推荐双重控制控件显隐/禁用 功能方法拦截。具体到代码层面主窗体加载时动态构建 MenuStrip 或 ToolStrip依据当前用户权限集合过滤菜单项按钮 Click 事件中调用 PermissionService.HasPermission(“User_Delete”) 做运行时鉴权关键业务方法如删除用户内部再嵌套一次权限校验失败则抛出自定义 InsufficientPermissionException 并给出友好提示。有个开源项目的做法值得参考按钮级别的显示隐藏 服务层二次校验前端防君子后端防小人。另外有个容易忽略的保护项默认保留操作员和管理员角色禁止删除仅允许修改其权限避免误操作导致系统无法登录。四、操作日志字段设计比实现更重要日志的核心价值在于事后能还原现场。建议字段时间、用户、操作类型、操作对象、操作内容具体值、结果成功/失败、IP 地址。关键一点修改类操作必须记录变更前后的值。更完整的表结构可以扩展为记录操作人 ID、操作类型、目标资源、操作时间、IP 地址、客户端主机名、请求参数摘要、执行结果状态码及异常堆栈信息。存储与保留策略存储位置用数据库便于查询保留时长建议至少 1 年超期自动清理并配合定期导出归档。合规口径上重要设备、平台、系统访问和操作日志留存时间不少于 6 个月并需定期离线备份防止篡改——实际项目建议取两者中更严的那个。五、案例分析案例 1多角色共用一台上位机的权限冲突这是产线上很真实的矛盾操作员要一直登录着看生产但工艺员临时来改个参数怎么办比较稳妥的两种方案一是弹窗二次身份校验——操作员保持前台生产登录不退出生产数据绑定操作员 ID工艺员或管理员通过独立弹窗做身份校验通过后临时开放参数编辑权限操作日志记录实际执行人生产数据仍归属当班操作员参数保存后权限自动回收。二是系统级双会话权限委派——上位机分前台生产会话操作员独占与后台管理会话独立子进程子进程与主进程共享数据库及生产工单上下文工艺修改操作单独写入操作人日志。这里的关键设计点是**操作人和数据归属人要分成两个字段**否则审计时会出现参数是工艺员改的但记录显示是操作员的扯皮。案例 2设备状态参与权限判定纯静态 RBAC 在设备异常时会失效。半导体行业的做法是把设备状态纳入校验按岗位-技能-设备三维度设置权限矩阵操作员仅能执行启动、停机等基础操作工程师可调整工艺参数维护人员仅能在设备待机时检修管理人员有审计权限但不能直接操作设备动态适配机制结合设备状态实时校验操作合法性——设备故障时临时向维护人员开放诊断权限故障排除后自动回收若操作人员试图在设备运行中调整关键参数系统立即弹出预警并锁定操作界面同时同步至管理人员终端。审计侧要求也相应提高全维度记录操作人-时间-内容-环境-设备五大要素所有信息带时间戳和唯一标识确保不可篡改权限申请、调整、回收必须留存申请人、审批人、执行人记录。案例 3SQLite 单机场景的加固思路如果项目是单机部署、不想上数据库服务器要注意 SQLite 原生不支持用户认证与 ACL权限管理完全依赖应用层实现。可选的加固路径为每个功能按钮分配 2^n 权限值登录时预加载权限集合至内存通过逻辑与运算动态控制 MenuStrip、ToolStrip 及控件的 Visible/Enabled/ReadOnly 属性关键操作事件需二次校验数据层可选用 SQLCipher 实现 AES-256 透明加密配合 PRAGMA secure_deleteON 防止数据恢复审计侧用独立日志表记录敏感操作时间戳、操作者、SQL 哈希、影响行数并支持定时自动备份与一键恢复。六、几个容易踩的坑事务一致性。新建用户 分配角色 写入日志这类跨表操作要用 TransactionScope 或显式 BeginTransaction 保障 ACID否则容易出现用户建了但角色没绑上的脏数据。权限变更本身也要留痕。设计时应遵循最小权限与职责分离原则并记录权限变更日志以供审计。别把能看和能点混为一谈。权限控制点至少要覆盖菜单可见性没权限就不显示、按钮可用性能看不能点、数据可见范围、参数修改权限。日志只增不改。这是审计的底线要求——日志不能改、不能删且必须存够年限。如果你说明一下是单机还是多机联网、有没有合规审计要求GMP/IATF 之类我可以把表结构和日志字段再具体收敛一版。