2. 管理驾驶舱权限体系总览
管理驾驶舱的权限体系，本质上要同时回答四个问题：谁在用（角色）、能做什么（操作权限）、能看多少（数据可见性）、用什么机制把这些约束稳定地表达出来（权限模型）。这四层不是并列的四个清单，而是从“人”到“数据”逐层收敛的一条约束链：角色决定权限集合，权限集合决定可执行动作，数据可见性决定同一动作下能落到哪些行、哪些列、哪些指标，权限模型则决定这套约束如何被系统化地存储、计算和校验。
一、角色定义：从“岗位”到“权限载体”
角色不是组织架构图上的岗位名称，而是权限的载体。一个可落地的角色定义，至少包含四个要素：角色标识、职责范围、默认权限集合、数据范围。例如在零售集团的驾驶舱中，可以定义如下角色（示例，非实测数据）：
| 角色标识 | 职责范围 | 默认操作权限 | 默认数据范围 |
|---|---|---|---|
| exec_group | 集团高管 | 查看、导出、订阅 | 全集团、全品牌、全区域 |
| region_mgr | 大区负责人 | 查看、导出、下钻 | 本大区及其下属门店 |
| store_mgr | 门店店长 | 查看、下钻 | 本门店 |
| analyst | 数据分析师 | 查看、下钻、导出、建临时看板 | 按项目授权，可跨区域 |
| auditor | 审计/风控 | 查看、导出、查看操作日志 | 全集团只读 |
角色定义的关键原则是“最小权限 + 职责分离”。例如 analyst 可以建临时看板，但不应拥有修改正式指标口径的权限；auditor 可以看全量数据，但不应拥有导出之外的写权限。角色一旦定义，就应作为权限分配的唯一入口，避免直接给个人账号授权，否则后续人员变动会导致权限残留。
二、权限粒度：从“页面级”到“字段级”
权限粒度决定了控制的精细程度。驾驶舱中常见的粒度由粗到细可分为五层：
- 系统级：能否登录驾驶舱、能否访问某个驾驶舱应用。
- 页面/看板级：能否打开“销售总览”“库存健康度”等具体看板。
- 组件级：能否看到某个图表、某个指标卡、某个筛选器。
- 行级：同一张表里，只能看到自己权限范围内的行，如本大区、本门店。
- 列级/字段级：同一行里，某些敏感字段（如毛利率、客单价、会员手机号）对部分角色不可见或脱敏。
粒度不是越细越好。粒度过粗会导致“要么全看、要么全不看”，粒度过细会带来维护成本爆炸。实践中常用的折中是：页面级 + 行级 + 关键字段列级。例如门店店长能打开“销售总览”页面，行级限定为本门店，列级隐藏“毛利率”和“会员手机号”。
三、数据可见性层级：从“全量”到“脱敏”
数据可见性层级描述的是同一份数据在不同角色眼中的呈现形态。可以把它理解为一条从“原始明细”到“聚合汇总”再到“脱敏/隐藏”的阶梯：
- 明细可见：能看到订单级、会员级原始记录，通常只给审计和少数分析师。
- 聚合可见：只能看到按日、按门店、按品类汇总后的结果，店长和区域经理多属此类。
- 脱敏可见：字段存在但被掩码，如手机号显示为
138****5678，用于需要识别但不需要完整信息的场景。 - 隐藏不可见：字段或行完全不返回，前端不渲染，后端也不下发。
这里有一个容易踩的坑：前端隐藏不等于权限控制。如果后端仍然把全量数据下发给浏览器，只是用 CSS 或条件渲染藏起来，那么懂技术的用户依然可以通过接口拿到数据。正确的做法是：行级和列级过滤必须在数据服务层完成，前端只负责展示已过滤后的结果。
四、典型权限模型：RBAC、ABAC 与混合模型
驾驶舱权限体系最常用的三种模型是：
- RBAC（基于角色的访问控制）：用户 → 角色 → 权限。结构简单、易审计，适合岗位边界清晰的场景。缺点是难以表达“同一角色在不同区域看到不同数据”这类动态条件。
- ABAC（基于属性的访问控制）：根据用户属性、资源属性、环境属性动态判断。例如“当用户所属大区 = 数据所属大区，且访问时间在工作时间内，允许查看”。灵活但策略复杂，排查成本高。
- RBAC + 数据范围规则（混合模型）：用 RBAC 管操作权限，用独立的数据范围规则管行级/列级可见性。这是驾驶舱场景中最常见、也最容易落地的组合。
下面这张图展示了混合权限模型下，一个请求从“用户发起”到“数据返回”的完整校验链路，以及各层权限在链路中的位置：
这张图的关键信息是：角色解析和操作权限校验发生在请求入口，数据范围过滤必须发生在数据服务层。前端只拿到过滤后的结果，审计日志则贯穿全链路。很多权限事故的根因，就是把数据范围过滤放在了前端或报表工具层，导致接口层仍然暴露全量数据。
五、落地时的三个判断点
在真正配置权限体系时，可以用三个问题快速判断设计是否合理：
- 角色是否可枚举：如果角色数量超过 20 个且边界模糊，说明角色定义过细，应考虑合并或引入数据范围规则来替代部分角色。
- 数据范围是否可声明：行级和列级规则应能用结构化条件表达，例如
region_id IN (用户所属大区)，而不是靠人工维护一张张白名单。 - 越权是否可发现：审计日志中应能还原“某用户在某时间看到了哪些本不该看到的数据”，否则权限体系只是“看起来有”，无法验证。
总结来看，管理驾驶舱权限体系的核心不是“把功能藏起来”，而是让正确的人在正确的范围内看到正确的数据，并且这个过程可审计、可复现、可维护。角色定义解决“谁”，权限粒度解决“做什么”，数据可见性解决“看多少”，权限模型解决“怎么稳定地表达”。四者对齐，驾驶舱才真正具备可治理的权限基础。