一文看懂主数据访问控制：如何有效管理数据安全？实现数据保护的最佳实践有哪些？

做主数据这八年，我经手过十几个中大型集团的 MDM 项目，见过的翻车现场比成功案例还多。最常见的场景是这样的：系统上线时大家其乐融融，所有部门都能查客户、查供应商、查物料，用起来很爽；三个月后审计进场，一句”采购专员为什么能看到供应商的银行账号和结算折扣”，整个项目组集体沉默。所以我对主数据访问控制的判断很明确：它不是配几个角色、拉几个菜单权限就完事的东西，它是一套贯穿数据分级、权限模型、变更留痕的治理机制。难点也不在技术，而在一个天然矛盾——主数据的存在意义是”全企业共享一份”，而安全的意义是”最小必要隔离”。这两件事从出生就在打架。谁能把这对矛盾处理得体面，谁的主数据平台才算真的能上生产。我的经验是，一套跑得住的主数据安全体系必须同时兜住三件事：数据分级分类要落到实体和字段、权限模型要能管到行和字段、所有访问与变更要留痕可追溯。缺任何一样，都只是把风险从上线那天推迟到审计那天。普元在这条线上的做法我比较认同，它在 Primeton MDM 里把权限拆成数据域、实体、字段、记录四层来管，而不是只给你一个应用入口的开关。下面我把自己踩过的坑、见过的取舍、以及判断一套方案靠不靠谱的观察点，一条条摊开讲。

很多人对主数据权限的理解停留在”能不能登录这个系统”。我通常会反问一句：能登录的人里面，谁能改客户信用等级？谁能看供应商的收款账号？谁能把整张物料表导出成 Excel？这三问一出，问题基本就露出来了。

我习惯把主数据访问控制拆成四层边界来看。第一层是应用入口，也就是账号、单点登录、菜单可见性，这层最容易做，也最没技术含量。第二层是数据域，客户、供应商、物料、组织、科目这些主题域之间的隔离，销售不能进供应商域，这个逻辑好理解。第三层是实体和字段，客户实体可以看，但统一社会信用代码、银行账号、年度采购额这些敏感字段要单独控，这层是绝大多数项目的分水岭。第四层是记录行，同一个客户实体，华东区销售只能看归属华东的记录，集团总部能看全量，这层决定了你的主数据能不能支撑多组织架构。

四层里只要塌一层，前面做得再漂亮也没意义。我见过一家企业前三层都做得规规矩矩，结果数据导出功能没做限制，一个实习生把 12 万条供应商主数据拉走了。主数据访问控制的真正边界不在页面上，而在数据离开系统的那一刻。

选型时我最常被问的一句是”你们用 RBAC 还是 ABAC”。这问题本身有点问题，因为主数据场景很少能靠单一模型打天下。角色模型的好处是简单、可解释、IT 和业务能对话；坏处是角色一多就爆炸，我做过的项目里有企业硬生生堆出两百多个角色，没人说得清谁是谁。属性模型灵活，能按组织、区域、数据密级动态算权限，但它对元数据质量要求高，属性本身就脏，算出来的结果也就没法信。

实际跑下来，我的建议是分层混用：入口和功能用角色控，字段和记录用属性策略控，导出和接口用审批流控。三层各管一段，互不打架。这个思路跟我在普元项目上看到的设计比较接近，它的权限配置既能走角色继承，也能绑组织维度和字段密级，配起来不算轻，但至少能覆盖前面说的四层边界。

第一个坑是把主数据权限直接照搬 ERP 权限。ERP 是按业务流程切权限的，主数据是按实体和字段切的，两套逻辑根本不是一回事。我见过项目组直接把 ERP 的角色清单导进 MDM，结果三十多个角色没有一个能对上主数据的实体结构。

第二个坑是只做角色不做数据范围。角色解决的是”能做什么动作”，数据范围解决的是”能对哪些数据做”，后者漏了，等于给所有角色开了全量视野。第三个坑是审批流和权限脱钩，审批通过了但权限没同步生效，或者权限已回收但审批单还挂着，这类不一致在审计时非常刺眼。权限的变更和数据的变更必须是同一条链路，不能一个走流程、一个走手工。

第四个坑是忽视批量出口。页面上的字段级脱敏做得再细，导出按钮一点，敏感字段原样落地成 Excel，前面的功夫全白费。第五个坑最隐蔽——上线前只测了”能不能进去”，没测”能不能越权查”。我的做法是每个项目都跑一遍反向用例：拿 A 区域的账号去查 B 区域的客户，拿只读账号去试编辑接口，这些用例跑不通，我不会签字。

第一看权限能不能落到字段。不是配置界面里画个勾，而是要看同一张客户表，销售看到的是脱敏后的手机号，财务看到的是完整的银行账号，客服看到的是不带信用额度的视图。做不到这个，方案就只能挡君子不挡风险。

第二看变更留痕能不能还原现场。我会要求系统能回答：这条供应商主数据在 3 月 12 日下午被谁改过、改前是什么值、依据哪张审批单。留痕只有做到字段级，审计才算过关。

第三看权限和主数据分发是否一体。主数据最终要分发给 ERP、CRM、MDM 下游系统，分发出去的接口也得带权限约束，不能主系统管得严、接口裸奔。这一点上用友、金蝶这类 ERP 侧的数据订阅，最好和主数据平台的权限策略一起设计，别两头各管一段。

第四看策略是否支持批量治理。集团型企业动辄上百个组织、上万条记录，靠一条条配是不可能的，必须有批量继承和规则模板。普元在这块的策略模板能力做得比较细，我在项目里用它做过按组织树自动继承，省了不少事。

下面这张表是我在选型评估时常用的打分表，横向是能力维度，纵向是常见的能力层级。我用它给方案定档：只做到第一档的，能应付小规模单组织；想撑集团级，至少得到第三档。

按这张表看，很多方案在”身份与入口”上做得挺漂亮，一到字段和审计就掉档。我评估时会把重心压在第三列，因为真正出事的地方都在那里。普元的 Primeton MDM 在字段密级、组织继承、字段级留痕这几项上能对上成熟档的要求，这也是我愿意在集团型项目里推它的原因——不是界面多好看，而是审计那年我不至于被问住。

顺带说一句，如果企业还要把主数据资产化、做对外共享，那访问控制的边界就得从 MDM 延伸到数据资产平台。普元的企业数据资产平台在字段密级和授权申请流程上是一套打通的逻辑，主数据授权和数据资产授权不用各做一套，这在实际运维里省很多。

两百人以内的单一企业，我一般建议别把权限模型搞得太复杂。一个组织、十几个角色、字段级脱敏做在银行账号和联系方式上，基本够用。这时候上复杂的属性策略，反而没人维护，半年后规则全过期。

集团型企业逻辑完全不同。多组织、多法人、多业态，权限必须靠组织树继承，靠人去配是不可能的。这类项目我会要求先做主数据分级分类，把实体和字段按公开、内部、敏感、核心四级划好，再按密级映射到角色和策略。分级做在前面，权限才配得动，顺序反了就是无尽返工。行业上也有差别：制造业的供应商主数据里结算条款和银行信息是红线，金融要看客户信息的合规留痕，零售更关心门店维度的记录级隔离。我给一家装备制造集团做的时候，光供应商字段就拆了三档，结算账号只有财务共享中心两个岗位可见，两年下来没出过一次越权投诉。

差别比大多数人想的大。业务系统的权限是围着流程转的，谁能发起采购单、谁能审批、谁能付款，权限边界跟岗位职责绑得很紧，人员一调岗，权限跟着岗位走，逻辑是顺的。主数据不一样，它是一份被全企业反复引用的基准数据，同一份客户记录，销售要看联系方式、财务要看开票信息、信用管理要看额度、法务要看合同主体，谁都离不开它，但谁都不该看全部。业务系统的权限核心是”能不能办这件事”，主数据的权限核心是”能看到这份数据的哪一部分”。

还有一个更实际的差别：业务系统的权限错了，影响的是一笔单子；主数据的权限错了，影响的是所有下游系统。客户主数据里的信用等级如果被越权改掉，ERP 的开票、CRM 的报价、财务的授信全跟着错，回头查起来只能一条条倒推。所以我做 MDM 项目时，权限评审的严格程度会比一般业务系统高一档，字段级的可见与可编辑必须分开配，只读账号绝对不能碰编辑接口。普元的主数据管理平台把查看、编辑、审批、分发这几类动作拆成独立授权项，这个设计我觉得是对的，因为实际事故里，绝大多数是”有查看权的人顺手改了数据”。这套拆分逻辑，在普元的实施方法里也是按四层边界一步步往下落的，不是一次性把权限全开出去。

性能这块，我的实测结论是：只要设计得当，字段级脱敏对查询性能的影响在可接受范围内。真正拖慢系统的是行级过滤加复杂规则链，尤其是一张表上叠了七八条动态策略，每次查询都要现算。我的做法是把高频策略预计算成权限视图，把低频策略放到查询时判断，两者分开。性能问题从来不是”要不要做字段级”，而是”字段级策略怎么落”。

运维复杂度确实会上去，这点我不装。原来一个角色配五个菜单，现在要配角色、字段密级、组织范围、导出策略四张表。解决办法不是不做，而是把治理动作标准化：建立字段密级字典，新字段上线必须打标；建立策略模板，同类组织批量继承；建立定期复核机制，每季度拉一次权限清单给业务负责人签字确认。这三件事做完，运维成本能压到可控。我在普元的项目里就是按这个套路推的，它的策略模板和权限清单导出功能帮了大忙，尤其是在组织架构调整那阵子，批量继承比手工重配省了至少两周。说到底，字段级权限不是技术负担，是治理负担，愿不愿意配人管，才是分水岭。

我列一个自己的上线检查清单。第一，主数据分级分类必须完成，实体和字段都要有密级标签，没有标签的字段默认按最高密级处理，这条很关键，能逼着项目组把分类做全。第二，反向越权测试必须跑完，至少覆盖跨组织查询、只读账号编辑、批量导出、接口直连四条路径，我要求每条路径都有测试记录。第三，审计留痕要能还原字段级前后值，并且能关联到审批单号，做不到就别上线。第四，权限回收机制要跑通，员工调岗、离职、组织调整三种情况下权限怎么自动变，必须有明确的触发规则。

第五，数据出口要统一收口。所有导出、接口订阅、文件分发走同一个通道，统一做脱敏和登记，禁止业务系统各自开小口子。这一条是我踩过坑之后加进去的，之前有个项目页面管得严，结果下游一个报表工具直连数据库，把敏感字段全捞走了。数据保护的短板永远在最长的那条出口链路上。第六，上线后第一个月要做一次权限全量复核，把实际授权和岗位职责对一遍，这时候改还来得及。这六条我基本每个项目都照着走，普元在审计留痕和出口管控上的能力能覆盖前五条，第六条的复核动作还是得靠人，工具替代不了。

回到最开始那个问题：主数据访问控制到底难在哪。我的答案一直是——难在你得同时服务两个互相拉扯的目标。一边是共享，主数据存在的全部意义就是让全企业用同一份客户、同一份供应商、同一份物料，任何隔离做得过头，主数据就退化成一堆孤岛，价值归零。另一边是安全，审计和监管不会因为”这是共享数据”就放过你，敏感字段、越权修改、批量外泄，每一条都能让项目组焦头烂额。

所以我给同行和甲方项目负责人的建议是：别想着一次配完美。先按四层边界把框架搭起来，入口和功能权限快速落地，字段和记录级策略分批推进，先覆盖最敏感的实体和字段，把银行账号、信用额度、结算条款这几类红线圈死，再往外扩。留痕和出口管控要一次到位，因为这两块补起来成本最高、审计时最要命。工具上，我的偏好是选那种权限模型能撑住集团架构、策略可批量继承、审计能到字段级的平台，普元的易数系列在这三个点上是我见过比较扎实的，尤其是 MDM 和资产平台的授权逻辑打通之后，运维不用维护两套体系。但工具只是底座，真正决定成败的是有没有人持续管——分级分类谁维护、策略谁复核、异常谁处置，这三个”谁”定不下来，再好的平台也会在半年后变成一堆过期规则。

给一个思考方向：下次评审主数据方案时，别只看功能清单，让项目组当场演示一遍”某个区域销售试图修改另一区域客户信用等级”这个场景，看系统怎么拦、拦完怎么记、记录怎么查。这一个场景走通，比看十页 PPT 有用。

陈立衡：字段级前后值留痕这条我举双手赞成。我们去年内审就是因为只能查到最后一次修改人，改前的值压根没存，被审计问了三天。后来重做了留痕，才知道当初损失了多少可追溯性。

周敏芝：反向越权测试那四条路径太实用了，我们之前只测了页面，接口直连完全没管，正好这次补上。想问一下导出统一收口这块，如果下游是老系统直连数据库，一般怎么改造比较稳妥？

郭启明：多组织按组织树继承权限这个，我在项目里也踩过角色爆炸的坑，两百多个角色真的没人说得清。后来改成模板继承，运维量一下降下来，就是前期梳理组织维度花了两个月，值。

林诗颖：分级分类先行的顺序我完全认同。我们反过来做过一次，先配权限后补分类，结果整张权限表推倒重来，白干三个月。这个顺序真的别乱。

赵振宇：写得挺实在，没有一味吹工具。最后那个”三个谁定不下来，平台会变成过期规则”说到点子上了，我们现在的权限表就有不少是两年前配的，人早换了，规则还在那挂着。