Dashboard Permission
集团型企业经营驾驶舱权限怎么设计
摘要：集团型企业经营驾驶舱的权限设计不能只停留在菜单显隐，还要把组织层级、租户边界、角色权限、行级权限、列级权限、敏感字段、导出分享和审计日志放在同一套规则中验证。只要集团、区域、分子公司、项目或客户之间的数据范围不同，就应提前设计数据隔离和反向测试。
集团权限的核心问题是：同一个页面、同一个指标、同一个查询条件下，不同身份应该看到什么范围，不能看到什么范围，以及越权请求是否会被拒绝并留下证据。
先确定组织层级和租户边界
集团型项目常见的问题，是一开始只按“管理员、领导、普通用户”划分角色，后续才发现集团总部、区域公司、分公司、部门、项目、客户和外部协作方看到的数据范围并不一样。权限设计应先画清组织树，再确定哪些边界属于租户隔离，哪些边界属于同一租户内的数据范围过滤。
| 层级或对象 | 常见权限问题 | 设计时要确认 |
|---|---|---|
| 集团总部 | 能否看全集团汇总和全部明细。 | 总部角色是否有跨组织下钻权限，敏感字段是否仍需脱敏。 |
| 区域或事业部 | 能否看同级区域、下级单位和历史划转数据。 | 组织归属按当前组织、发生时组织还是项目归属计算。 |
| 分子公司或部门 | 是否只能看本单位经营、项目、人员或客户数据。 | 组织编码、部门树和数据源中的责任部门是否一致。 |
| 项目或客户 | 项目成员、客户经理和外部协作方能看哪些信息。 | 项目成员关系、客户归属、合同范围和临时授权期限。 |
| 固定展示终端 | 展厅、会议室或指挥中心是否自动登录。 | 是否使用低权限专用账号，是否限制导出、后台和明细页面。 |
页面权限、数据权限、操作权限要分开
能进入经营驾驶舱页面，不代表可以查看所有组织的数据；能查看汇总指标，也不代表可以下钻到客户、合同、人员或设备明细；能筛选分析，也不代表可以导出或分享。权限矩阵至少要分成页面、数据、操作和审计四类，不应只用一个角色字段概括全部规则。
常见做法是：页面权限决定用户能看到哪些菜单和模块；数据权限决定接口和查询层返回哪些记录；操作权限决定是否可以导出、配置、编辑、发布或管理账号；审计规则记录关键访问、越权拒绝、导出、配置变更和权限变更。
行级权限和列级权限如何落地
行级权限解决“能看哪些记录”，例如只能看本区域客户、本项目设备或本部门指标。列级权限解决“能看哪些字段”，例如合同金额、手机号、身份证号、供应商账号、精确位置和人员评价。集团驾驶舱中，两类权限经常同时出现。
权限过滤应在后端、查询层、BI语义层或数据服务中执行，前端只负责展示已经授权的数据。否则用户可能通过修改请求参数、调用接口、导出文件或查看缓存拿到不应访问的数据。对智能问数、Text-to-SQL和报表导出，也要使用同一套数据权限规则。
多租户场景常见的五类串数据风险
多租户不一定等于每个租户独立数据库，但必须保证租户之间不会串数据。选型时可以根据隔离等级、成本、数据量、恢复目标和运维能力，在独立数据库、独立 schema、共享表加租户字段等方式之间选择。
- 列表和统计接口缺少租户或组织过滤，导致返回其他单位数据。
- 缓存键没有包含租户、组织或角色，导致看到上一位用户的结果。
- 导出、截图、分享链接和消息推送没有复用权限规则。
- 后台配置项、字典、阈值或指标口径被不同租户误共用。
- 日志、备份、测试数据和临时脚本暴露了其他组织的敏感内容。
审计日志要记录能复盘的事实
审计日志不是把所有页面浏览都无限保存，而是记录关键行为能否被复盘。建议至少记录账号登录、权限变更、数据导出、配置发布、敏感字段访问、越权拒绝、失败重试和管理员操作。日志字段应包括操作者、时间、对象、动作、结果、来源地址、组织范围和关联工单或版本。
日志本身也需要权限。不能让普通用户下载全量日志，也不应在日志中保存明文密码、令牌、个人敏感信息或完整客户资料。涉及合规要求时，应由建设方安全团队或专业机构确认日志范围、保存期限和脱敏方式。
验收时用反向测试，不只测管理员
权限验收容易只看管理员演示是否正常。更可靠的方法是准备高权限、普通权限、低权限、失效账号、临时授权和固定终端账号，分别验证同一页面、同一接口、同一导出和同一智能问数问题的结果差异。
| 测试项 | 检查目的 | 合格表现 |
|---|---|---|
| 跨组织访问 | 验证行级权限是否生效。 | 低权限账号不能通过改参数查看其他组织明细。 |
| 敏感字段 | 验证列级权限和脱敏规则。 | 无权角色看不到明文手机号、证件号、账号或财务敏感字段。 |
| 导出与分享 | 验证数据离开页面后仍受控。 | 导出字段、分享链接和截图流程符合授权范围。 |
| 智能问数 | 验证语义层和Text-to-SQL复用权限。 | 同一问题在不同角色下返回不同授权范围，越权问题被拒绝。 |
| 组织调整 | 验证权限回收和历史数据规则。 | 调岗、离职、项目结束后旧权限不再可用。 |
和项目团队沟通前准备什么
建议先准备组织层级、角色清单、核心页面清单、指标和数据源清单、敏感字段清单、固定终端使用场景、导出分享规则、审计日志要求和反向测试账号。没有这些材料，也可以从首期最重要的一个驾驶舱场景开始，先把核心角色和数据边界写清楚。
可配合数据大屏角色权限、多租户与审计验收矩阵逐项记录，也可继续阅读数据大屏权限、安全与审计怎么做，把权限设计拆成可验收的页面、数据、操作和日志条目。
常见问题
集团权限和普通角色权限有什么区别？
普通角色权限通常回答能不能进入页面和执行操作，集团权限还要回答用户属于哪个组织层级、能看哪些分子公司、区域、部门、项目或客户，以及汇总和明细能否互相下钻。
多租户是否一定要独立数据库？
不一定。可以按租户独立数据库、独立 schema、共享表加租户字段等方式实现，选择取决于隔离要求、数据规模、成本、运维复杂度和恢复目标。
只做数据大屏需要多租户吗？
如果不同组织、客户、区域或项目看到的数据范围不同，即使页面只展示，也应按租户或组织边界设计数据隔离和权限过滤。
行级权限在前端控制可以吗？
不建议。前端隐藏筛选项或按钮不能替代后端、查询层或数据服务中的权限过滤，接口和导出也应使用同一套规则。
权限矩阵能替代等保测评吗？
不能。权限矩阵用于项目设计和验收沟通，不替代等级保护、个人信息保护、行业监管或专业安全评估。
组织调整后如何维护权限？
组织、岗位、区域、项目和外部协作关系变化后，应同步更新组织树、角色规则、数据范围、临时授权和审计记录，并用反向测试复核旧权限是否回收。