📚 课程目录第2章食品MES数据权限模型设计基础

2. 食品MES数据权限模型设计基础

在食品MES中，权限模型不是“谁能登录系统”这么简单，它要回答三个层次的问题：谁能做哪个操作（功能权限）、能对哪些数据做（数据权限）、能看到数据里的哪些字段（字段权限）。本节围绕RBAC、ABAC、PBAC三种主流模型展开对比，并结合食品生产场景给出角色划分、权限粒度设计与继承冲突解决的可落地方法。

一、三种权限模型的本质差异

RBAC（基于角色的访问控制）以“角色”为授权中心：用户被赋予角色，角色被赋予权限，权限再落到具体资源与操作上。它的优点是结构清晰、易审计、易批量维护，适合岗位职责相对稳定的场景。缺点是当权限需要随“批次、产线、班次、数据状态”动态变化时，单纯靠角色会膨胀出大量角色组合。

ABAC（基于属性的访问控制）以“属性”为判断依据，主体属性（岗位、部门、班次）、资源属性（产线、产品类别、批次状态）、环境属性（时间、地点、终端）共同参与策略计算。它表达力强，能写出“质检员只能审核自己负责产线的、状态为待审核的批次记录”这类精细规则，但策略数量多、调试与审计成本高。

PBAC（基于策略的访问控制）可以理解为ABAC的工程化演进：把授权决策统一收敛到策略引擎，策略以“主体+资源+动作+条件”的规则形式集中管理，支持策略组合、优先级与冲突裁决。它更适合多工厂、多产线、监管要求高的食品MES，但对策略治理能力要求最高。

工程上常见的做法是混合模型：以RBAC承载岗位职责骨架，用ABAC/PBAC补充数据范围与状态条件。例如“质检员”是角色，但“只能审核本产线、状态为待审核、且未超时的批次”则由策略条件表达。这样既保留角色可读性，又避免角色爆炸。

二、食品生产场景中的角色划分

角色划分应遵循“岗位职责+最小权限+职责分离”三原则。食品MES中典型角色及权限边界如下：

角色	核心职责	功能权限示例	数据范围
操作工	执行工单、投料、报工	工单执行、投料记录、报工提交	本班组、本班次、本工位
班组长	派工、复核、异常上报	派工调整、报工复核、异常单创建	本产线、本班组全部工单
质检员	取样、检验、放行判定	检验录入、判定、不合格处置	授权产线、待检/待审批次
工艺工程师	工艺参数维护、偏差分析	工艺路线维护、参数上下限配置	授权产品族、历史批次
审计员	审计追踪核查、合规取证	审计日志查询、导出、只读追溯	全厂只读，不可修改业务数据

需要特别强调职责分离（SoD）：报工与复核不能由同一人完成，检验录入与放行判定应分离，工艺参数修改与生产执行应分离。审计员必须只读，且其查询行为本身也要被记录，形成“审计的审计”。

三、权限粒度设计：功能、数据、字段三层

功能权限回答“能不能点这个按钮、调这个接口”，通常以“资源:动作”形式定义，如 workorder:execute、inspection:approve、auditlog:export。设计时要区分“菜单可见”与“操作可执行”，避免只隐藏菜单而接口仍可调用。

数据权限回答“能操作哪些数据行”，常见范围包括：本人、本班组、本产线、本工厂、授权产品族、全部。实现上通常在查询层注入范围条件，例如给工单查询追加 line_id IN (授权产线集合) 与 shift = 当前班次。数据权限必须与功能权限同时校验，否则会出现“有按钮但越权改他人数据”。

字段权限回答“同一行数据里哪些字段可见/可改”。食品场景中典型敏感字段包括：配方比例、关键工艺参数（杀菌温度、时间）、供应商批号、成本单价、检验原始值。字段权限可分“可见、可编辑、脱敏可见”三档，例如操作工可见工艺参数但不可改，供应商批号对操作工脱敏显示为后四位。

# 权限判定伪代码（示例）
def check(user, action, resource, field=None):
    # 1. 功能权限
    if not rbac.has_permission(user.roles, resource.type, action):
        return DENY
    # 2. 数据权限（策略条件）
    if not policy.match(user, resource, action):
        return DENY
    # 3. 字段权限
    if field and not field_policy.allow(user, resource, field, action):
        return DENY
    return ALLOW

四、权限继承与冲突解决策略

权限继承通常沿三条线展开：角色继承（班组长继承操作工基础权限）、组织继承（工厂→车间→产线→班组逐级下放）、资源继承（产品族→产品→批次）。继承能显著减少重复配置，但必须明确“继承是默认允许还是默认收紧”。建议对功能权限采用“向上继承、向下叠加”，对数据权限采用“取交集”，防止上级角色意外获得过宽数据范围。

冲突不可避免，关键是规则先行、结果可解释。推荐采用以下优先级顺序：

显式拒绝优先：任何一条拒绝策略命中即拒绝，避免“权限叠加导致越权”。
职责分离优先：SoD冲突时强制拒绝，并提示冲突角色对。
更具体策略优先：资源范围更小、条件更多的策略优先于宽泛策略。
时间与状态优先：如批次已放行后，操作工对该批次的修改权限自动失效。
默认拒绝：无任何策略命中时拒绝，符合最小权限原则。

落地建议：为每条策略记录“策略编号、适用角色、资源范围、条件、优先级、生效时间、责任人”，并在权限变更时自动写入审计日志。这样当审计员追问“为什么张三能改这条记录”时，系统能给出唯一、可复现的判定链路，而不是靠人工回忆配置过程。

综上，食品MES权限设计的合理路径是：用RBAC搭骨架、用ABAC/PBAC补动态条件，按功能—数据—字段三层细化粒度，用“显式拒绝优先+职责分离+默认拒绝”解决继承冲突，并让每一次授权决策都可追溯。这套组合既能满足生产现场的效率要求，也能经得起食品安全审计的检验。