权限问题的根源往往不是技术，而是角色没设计好
很多企业在数据管理上遇到过这样的矛盾：业务同事抱怨查个数要审批三天，IT 部门则担心放开权限后数据到处扩散。两边都有道理，问题通常出在角色体系缺失。没有清晰的角色划分，权限只能按人逐个配置，人一多就失控，最后不是过度开放就是过度收紧。星空在数据管理系统建设中反复验证一个结论：权限治理的起点是岗位职责，而不是系统功能。
角色，是一组职责相近的人所拥有的数据访问集合。设计角色时先问三个问题：这个岗位日常要看哪些数据、看到什么粒度、需要什么操作权限。把答案沉淀成角色模板，人员变动时只换人不换权限，管理成本会明显下降。
按职责分层设计角色
实践中可以把角色分为几层。决策层关注汇总指标与趋势，通常只需要聚合结果，不需要明细；业务执行层需要本业务线的明细数据，用于跟进客户或处理订单；分析支撑层需要跨业务线的数据做关联分析，但应以只读为主；数据管理岗负责元数据、字典和权限配置，权限最特殊，应单独管理并留痕。
- 决策层：聚合指标与趋势，弱化明细
- 业务执行层：本业务线明细，按区域或团队限定
- 分析支撑层：跨线只读，敏感字段脱敏
- 数据管理岗：元数据与权限配置，操作全程记录
星空提醒，角色数量不宜过多，否则维护成本反超收益。一般先覆盖主要岗位，特殊需求通过临时授权解决，而不是不断新增角色。
可见范围要落到行与列
角色确定后，还要明确可见范围。行级控制解决「能看到哪些记录」，比如区域经理只看本区域；列级控制解决「能看到哪些字段」，比如手机号、成本价对多数角色脱敏。星空在项目中发现，很多权限事故不是因为人看到了不该看的表，而是同一张表里的敏感列没有区分对待。
另一个容易被忽略的点是导出与聚合。允许导出明细，等于绕过了列级控制；允许对敏感字段做聚合查询，也可能被反推。权限设计要把这些路径一并考虑，而不是只盯页面上的查询按钮。
用审批与复核让权限保持健康
权限不是配完就结束。星空建议建立两条机制：一是申请审批，临时或超额权限须说明用途和期限，到期自动回收；二是定期复核，按季度或半年由角色负责人确认成员名单与权限范围是否仍然合理。人员转岗和离职是权限残留的高发环节，应与人事流程联动。
把角色、范围、审批、复核四件事串起来，数据权限才能既支撑业务效率，又守住数据资产的边界。星空在数据管理栏目持续讨论这类流程问题，因为权限治理最终考验的是管理细节，而非单纯的系统配置。
