MES 生产执行系统权限与审计怎么做？角色、数据范围和操作日志实践

权限模型不是功能清单，是生产合规的基石

在 MES 系统中，权限与审计不是后台管理的一个模块，而是贯穿生产执行全流程的控制机制。一次错误的配方修改、一条不该被操作工看到的质量数据、一个未记录的操作撤回，都可能触发批次报废、审计缺陷甚至客户投诉。

从工程角度看，权限设计回答的是“谁能在什么条件下对什么数据做什么”，审计设计回答的是“谁在什么时间对什么数据做了什么，以及变更前后的状态是什么”。两者一体两面，缺一不可。

本文不讨论抽象的 RBAC 理论，而是聚焦 MES 项目中的具体场景：角色如何分层才够用、部门数据范围如何隔离才不串、敏感字段怎么保护才合规、审批流和操作日志应该记录到什么粒度。每个结论都附有适用条件和成本提示。

角色建模：三层结构比扁平设计更抗压

MES 的用户群体远比 ERP 复杂。一条生产线上同时存在操作工、线长、工艺员、质量巡检、设备维护人员，甚至外部审核员。如果只用一个“管理员”和“普通用户”来覆盖，要么权限太松导致数据泄露，要么太紧导致流程卡死。

实践中建议采用三层角色结构：

第一层：功能角色

功能角色定义用户能访问哪些菜单和操作按钮。这是最基础的权限控制，通常对应页面级权限。

常见功能角色包括：

• 操作工：仅可查看当前工单、执行报工、输入过程参数
• 工艺员：可编辑工艺参数、配方版本、BOM 配置
• 质量检验员：可录入检验数据、查看不合格品记录
• 设备管理员：可查看设备状态、录入维护记录
• 生产调度：可创建和调整工单、查看产能看板

功能角色的数量建议控制在 10 个以内。超过 15 个角色时，角色间的权限重叠和边界模糊会显著增加维护成本。每增加一个角色，测试用例数量会呈指数增长。

第二层：数据角色

数据角色控制用户能看到哪些数据行。同样一个“工单查询”页面，操作工只能看到自己当班产线的工单，工艺员能看到所有产线的工单但只能编辑自己负责的工艺路线。

数据角色的核心是“行级权限”，通常通过组织维度（部门、车间、产线）或业务维度（产品类型、工单状态）来实现。这部分在下一节详细展开。

第三层：审批角色

审批角色独立于功能角色和数据角色。一个工艺员可能同时是“配方变更审批人”，但这个审批权限不应该因为工艺员离职而自动转移。审批角色需要独立维护，且通常与流程节点绑定。

三层结构的好处是解耦。当业务部门要求“给质检部新增一个只读账号”时，只需要在功能角色上增加一个“质检只读”角色，数据角色复用现有规则，审批角色不受影响。修改成本低，回归测试范围可控。

适用条件：三层结构适合用户超过 50 人、涉及多个车间或产线的 MES 项目。如果只是单车间、10 人以下的小规模部署，两层结构（功能角色 + 审批角色）也可以，但需要预留扩展接口。

数据范围隔离：部门、车间和产线的权限边界

数据范围隔离是 MES 权限设计中最容易被低估的难点。很多项目初期只考虑了功能角色，上线后才发现操作工能查询到其他产线的工单数据，或者工艺员能看到其他车间的成本信息。

隔离维度选择

根据项目规模，通常选择一到两个维度进行数据隔离：

• 部门维度：适用于集团型 MES，不同工厂之间完全隔离。A 工厂的用户看不到 B 工厂的任何数据。
• 车间维度：适用于中型工厂，同工厂不同车间之间隔离。涂装车间和总装车间的数据互不可见。
• 产线维度：适用于小型工厂或单车间，同车间不同产线之间隔离。产线 A 和产线 B 的数据隔离。

选择原则：隔离粒度越细，权限配置越灵活，但系统复杂度和维护成本也越高。建议从最粗的维度开始，上线后再根据实际需求细化。不要一开始就做到产线级隔离，除非业务上确实需要。

数据范围绑定方式

数据范围通常通过用户与组织单元的关联关系来实现。具体做法：

1. 在用户表中增加一个或多个组织字段，如 department_id、workshop_id、line_id
2. 在业务数据表中记录对应的组织 ID
3. 查询时自动追加过滤条件：WHERE department_id = 当前用户.department_id

这里有一个常见陷阱：如果用户跨多个车间工作（比如质量巡检员），单一组织字段无法满足需求。此时需要引入“用户-组织映射表”，支持一对多关系，并在查询时使用 IN 条件。

实现成本：一对多映射比单字段设计增加约 30% 的开发量，包括权限配置界面、查询改造和性能优化。如果项目中明确存在跨组织用户，不要为了省事采用单字段设计，后期改造成本更高。

数据隔离的边界情况

有些数据天然需要跨组织共享，比如质量标准、设备编码、物料主数据。这些数据的数据范围应该设置为“全局可见”或“按角色可见”，不受用户组织字段限制。设计时需要在底层数据表上增加一个 is_global 标记，或者在查询逻辑中做白名单处理。

忽略这个边界会导致一个常见问题：工艺员在 A 车间无法引用 B 车间的标准工艺参数，只能手动复制，反而增加了数据不一致风险。

敏感字段保护：哪些数据需要加密或脱敏

MES 中并非所有字段都需要高强度保护，但以下几类数据必须特殊处理：

• 配方参数：涉及核心工艺配方，修改可能导致批次报废
• 质量检验数据：特别是涉及客户要求的 Cpk 值和缺陷记录
• 设备校准证书编号：涉及合规审计
• 操作员账号和密码：基础安全要求

保护策略

根据字段的敏感程度，采用不同保护级别：

**第一级：显示脱敏**
适用于操作工查看配方时，配方名称可见但具体参数值显示为“***”。操作工只看到配方编号和版本号，无法获取完整配方内容。脱敏在 API 层实现，不修改数据库存储。

**第二级：加密存储**
适用于设备校准证书编号、供应商代码等需要存储但日常查询频率低的字段。采用 AES-256 加密，密钥独立管理。查询时只有拥有解密权限的角色才能看到明文。

**第三级：完全隔离**
适用于核心配方文件、客户特殊要求文档等。这些数据不应存储在 MES 的业务表中，而是存储在独立的文件服务器或文档管理系统中，MES 只存储文件索引和访问令牌。用户通过 MES 跳转到文档系统时，需要二次鉴权。

选择提示：加密存储会增加查询延迟，特别是需要模糊搜索的场景。如果业务上必须对加密字段进行搜索，考虑使用搜索加密技术（如可搜索加密），或者将搜索字段单独存储为哈希值。这些技术实现成本较高，建议在项目初期评估业务需求，必要时放弃加密字段的搜索功能，改为精确匹配。

审批流设计：变更前的最后一道门

MES 中的审批流不是简单的“提交-通过-拒绝”三步走，而是与生产流程紧密结合的控制节点。

必须设置审批的关键节点

• 配方版本变更：从草案到生效，必须经过工艺主管和质量管理双重审批
• 工单计划外修改：如临时更换物料或调整数量，需要生产调度确认
• 不合格品处理：返工、降级或报废，需要质量、生产和工艺三方会签
• 设备参数调整：超出标准范围时，需要设备工程师审批

审批流设计原则

1. **审批节点不可跳过**：系统层面强制校验，不能通过管理员账号绕过。如果确实需要紧急放行，应使用“紧急审批”流程，并记录原因和审批人。
2. **审批人可委派但不可删除**：当审批人请假时，可以临时委派给其他人，但委派记录必须留痕。不要提供“跳过”功能。
3. **审批意见必须填写**：拒绝时必须填写原因，通过时建议填写备注。这不仅是合规要求，也是后期追溯的依据。
4. **审批超时处理**：设置审批超时时间（通常 2-8 小时），超时后自动升级到上级审批人。这个功能在制药和食品行业尤为重要，因为生产不能长时间等待审批。

审批流的技术实现

建议采用工作流引擎（如 Activiti、Camunda 或自研轻量级引擎）来实现审批流，而不是在业务代码中硬编码审批逻辑。工作流引擎的好处是审批流可以动态调整，业务部门可以在界面上拖拽配置，无需修改代码。

但工作流引擎也有成本：引入一个成熟的引擎需要至少 2-3 周的集成和测试时间，后续版本升级也可能带来兼容性问题。如果项目审批节点少于 5 个且变更频率极低，硬编码审批逻辑反而更可控。

操作日志审计：记录什么、怎么存、查多久

审计日志是 MES 合规的核心证据。GMP、IATF 16949 等标准都明确要求对关键操作进行审计追踪。

必须记录的操作类型

• 数据创建、修改、删除：包括工单、配方、质量记录、设备参数
• 审批操作：提交、通过、拒绝、委派
• 系统配置变更：角色权限分配、数据范围调整、审批流修改
• 用户登录和登出：记录 IP、设备、时间
• 敏感字段查询：谁在什么时间查看了加密字段的明文

日志记录粒度

不是所有操作都需要记录变更前后的完整数据。根据操作的风险等级区分：

• 高风险操作（配方修改、审批通过）：记录变更前和变更后的完整数据
• 中风险操作（工单状态变更）：记录变更前和变更后的状态值
• 低风险操作（普通查询）：只记录操作时间和操作人，不记录查询内容

如果一个页面上同时包含高、中、低风险操作，建议统一按高风险级别记录，避免因粒度不一致导致审计人员质疑记录完整性。

日志存储策略

• 在线存储：最近 6-12 个月的日志保存在数据库或 Elasticsearch 中，支持实时查询
• 归档存储：超过 12 个月的日志压缩后存储到对象存储（如 S3、MinIO），保留期限根据行业要求设定，通常为 3-5 年，GMP 要求至少 5 年
• 日志不可修改：数据库层面设置日志表只允许 INSERT，不允许 UPDATE 和 DELETE。如果使用 Elasticsearch，索引设置为只读

存储成本估算：一个 200 用户的 MES 系统，每天产生约 1-2 万条操作日志，每条日志约 0.5KB。在线存储 6 个月大约需要 1.5-3GB 空间，归档存储 5 年大约需要 15-30GB。这个量级对现代数据库和存储系统来说负担很小，不需要为了省钱而压缩日志内容。

日志查询与导出

审计日志需要支持按时间范围、操作人、操作类型、业务对象 ID 进行组合查询。导出格式通常要求为 CSV 或 PDF，且导出内容必须包含记录生成时间戳，不能导出后重新计算时间。

一个常见问题：日志查询速度在数据量超过 100 万条后明显下降。解决方案是在日志表上建立合适的索引（时间 + 操作人 + 操作类型复合索引），或者将日志存储到专门的时序数据库（如 TimescaleDB）。

权限审计的自我验证

权限系统本身也需要被审计。定期检查以下内容：

1. 是否存在长期未使用的账号（超过 90 天未登录），建议自动禁用
2. 是否存在权限过大的账号（如普通操作工拥有工艺员权限）
3. 审批流中是否存在“自己审批自己提交”的情况
4. 数据范围配置是否正确，是否存在跨部门访问记录

这些检查可以写成定时任务，每周生成一份权限审计报告，发送给系统管理员和 IT 审计人员。在 SystemDo 参与的一个汽车零部件 MES 项目中，我们通过这个机制发现了一个工艺员账号被误分配了全厂数据范围的问题，避免了潜在的数据泄露风险。

成本与周期估算

以下成本估算基于一个 200 用户、3-5 个车间的 MES 项目，采用定制开发方式：

• 角色权限模块（三层结构）：开发周期 3-4 周，成本约占项目总预算的 10-15%
• 数据范围隔离：开发周期 2-3 周，成本约占 8-10%
• 敏感字段保护：开发周期 1-2 周，成本约占 5-8%
• 审批流引擎集成：开发周期 3-5 周，成本约占 15-20%
• 操作日志审计：开发周期 2-3 周，成本约占 8-10%

总周期约 11-17 周，总成本约占项目预算的 46-63%。这个比例看起来高，但权限与审计是 MES 的骨架，后期修改成本远高于前期投入。如果项目预算紧张，可以优先保证角色权限和操作日志，审批流和数据范围隔离可以在二期实现。

注意：以上估算假设使用成熟的工作流引擎和权限框架，团队有相关经验。如果团队需要从零开发，周期和成本需要增加 50-100%。

风险与避坑

**风险一：权限配置过于灵活**
有些项目允许业务部门在界面上自由创建角色和分配权限，结果三个月后出现了 50 多个角色，权限关系混乱到无法维护。建议限制角色创建权限，只允许系统管理员操作，且每次变更需要审批。

**风险二：审计日志成为性能瓶颈**
如果每条操作都同步写入日志表，高并发场景下可能拖慢主业务流程。解决方案是使用异步写入（消息队列 + 批量写入），日志写入失败不应影响主业务操作。

**风险三：审批流与业务逻辑耦合过紧**
审批流引擎中的节点状态和业务数据状态是两个不同的概念。不要将业务状态直接映射为审批节点状态，否则审批流调整时业务逻辑也要跟着改。保持审批流引擎独立，通过回调接口与业务系统交互。

**风险四：忽略移动端权限**
如果 MES 有移动端（如 PDA 扫码、平板看板），移动端的权限控制必须与 PC 端一致，不能因为移动端界面简化而降低权限要求。移动端通常采用 Token 鉴权，Token 过期时间不宜超过 8 小时。

总结：从设计第一天就考虑权限与审计

MES 的权限与审计不是上线前的补丁，而是系统架构的一部分。在数据库设计阶段就要预留组织字段，在 API 设计阶段就要考虑数据过滤，在前端设计阶段就要规划脱敏显示。等到上线后再反推，改造成本至少是前期设计的 3 倍。

每个项目的业务场景不同，三层角色结构、数据范围隔离粒度、敏感字段保护级别都需要根据实际需求调整。关键是在设计时明确边界：哪些数据需要保护，保护到什么程度，谁负责维护这些规则。把这些决策文档化，比任何技术实现都重要。

如果项目涉及 GMP、IATF 16949 等合规要求，建议在项目启动阶段就引入合规顾问参与权限与审计设计，避免后期返工。合规顾问的投入通常占项目总预算的 5-8%，但可以节省后期 30% 以上的整改成本。