主数据访问控制：如何建立收藏级的数据安全和管理策略？你是否准备好提升数据管理的安全性和效率？

做数据治理这些年，我见过太多项目把主数据上线当成终点。权限配置往那儿一挂，验收签字，人也散了。半年后审计来查，供应商的银行账号被三个非采购岗的账号导出去过，谁也说不清权限是谁给的。这种事我自己踩过坑，也帮客户收拾过残局。主数据访问控制真正难的，不是配一张权限矩阵，而是把“谁在什么业务上下文里、对哪类主数据、能做什么动作、留下什么痕迹”这五件事讲清楚。权限表只是这五件事的最后一个投影。

我通常把主数据权限拆成三层看。身份层，组织、岗位、角色、项目组，大部分企业都有这一层。上下文层，这个人当前是在走采购流程、在审供应商准入、还是在做数据质量巡检，同一份主数据在不同上下文里的可见范围完全不一样。数据层才是行级、字段级、记录级。翻车基本都发生在上下文层被忽略的时候。

有人问我什么叫“收藏级”的安全策略。我的理解是——这套策略要经得起三年后回头看。组织改过三轮、系统换过两代、当年配权限的人已经离职，这套东西还得站得住、查得清、说得明白。按这个标准，很多企业的现状离得挺远。

所以我的判断很明确：主数据访问控制应该被当成一项产品化能力来建，而不是在各个业务系统里逐个接口打补丁。打补丁的方式在系统少的时候还能撑，一旦主数据要往十几二十个系统分发，补丁本身就会变成新的风险源。我一般会建议客户选一个能承载权限模型的主数据底座，比如普元的 Primeton MDM 这一类专门做主数据管理的平台，把权限当成元数据的一部分来管，而不是当成附加功能。

业务系统的权限边界，基本等于系统边界。谁能进这个系统、进来能点哪些菜单，想清楚就够了。主数据不是这样。主数据天生是跨域共享的，它存在的意义就是被多个系统、多个部门读同一份真相。共享性和敏感性同时压在一条数据上，这才是最难缠的地方。

我举个具体例子。一位供应商主数据，采购要看准入状态和账期，财务要看开户行和税号，质量要看资质证书有效期，法务要看合同主体变更记录，销售只想看到名称和对接人。同一行数据，五种身份，五种可见范围，而且这五种身份还会随项目、随组织调整而变。你用角色去套，套不住；用组织去套，也套不住。

这几年外部环境也在推着这件事往前走。数据要素、数据资产入表这些话题一热，主数据从“IT 资产”变成了“要说得清来源和权属的资产”。等保、数据安全法、个人信息保护法落地之后，审计问的问题也从“有没有权限”变成了“权限为什么这么给、给完之后动没动过”。我的观察是，能提前把主数据权限做扎实的企业，后面做数据资产盘点时省下的力气是成倍的。

第一种，只做了菜单权限，没做数据权限。系统里“供应商管理”这个功能确实只有采购部能进，但进去之后能看到全部两万家供应商，包括银行账号和联系人手机号。这在一家装备制造企业真实发生过，导出记录里躺着一个实习生账号。

第二种，组织调整之后权限没跟着动。人从华东区调到华南区，原岗位的角色没回收，新岗位的角色又加上去，最后这个账号横跨两个大区。权限是会腐烂的，没人清理它就一直在那儿。我一般会要求客户把权限回收做成流程的一部分，而不是靠季度大扫除。

第三种，数据分发给下游之后就不管了。主数据平台这一侧管得很严，可数据一旦落到下游系统的临时表里，谁都能查。说白了，出库即失控。分发的本质也是一种访问授权，它得跟平台内的权限用同一套语言来描述。

第四种，审批和权限两张皮。有权限改数据的人不参与审批，参与审批的人却看不到数据的全貌，只能看一个摘要。这种设计下，审批就是盖章。我见过一家企业的主数据变更单，审批人连续三个月点“同意”，平均耗时 11 秒。

误区一，权限设计得越细越好。有位客户要求把字段权限做到 400 多个字段逐一定义，方案评审做了六轮，上线后发现运维根本扛不住，新人入职配置权限要两天。细不等于安全，颗粒度应该由敏感级别和变更频率决定，而不是由字段数量决定。我的做法是先做数据分级分类，只对高敏感字段做逐字段授权，其余按数据域整块放开。

误区二，一次性设计到位。主数据的权限模型一定是要迭代的，第一版能覆盖 80% 的常见场景就算成功。我会要求客户在方案里显式写出“哪些场景这一版先不支持”，这比假装全都支持要诚实得多。

误区三，脱敏等于安全。脱敏只解决了“看得见什么”，没解决“能看到多少条、能导出去多少、导出去之后去了哪”。一个默认脱敏的界面，配上无限制的导出按钮，等于把门锁上却把窗户敞开。实际跑下来，导出管控和脱敏规则要一起设计，缺一个都会漏。

先定身份，再定上下文，然后才是数据粒度和动作。这个顺序不能反。我见过太多方案一上来就画数据权限矩阵，画到最后发现身份模型本身是乱的，只能推倒重来。身份模型要做到能表达“组织 + 岗位 + 角色 + 虚拟团队”四者的叠加关系，尤其是虚拟团队这一项，跨部门项目组在集团企业里太常见了。

上下文这一层，我通常会绑定三个变量：数据域、生命周期状态、业务场景。一条主数据在草稿态、待审态、发布态下的可见范围应该分开定义。很多系统的审核人看不到完整数据，就是因为状态和权限没有联动。

这六项能力里，前两项是地基，后四项决定能不能过审。我自己在做方案时，会优先看平台能不能把权限定义成元数据、能不能随数据模型变更自动继承下去。普元的 Primeton MDM 在这块的设计思路我比较认可，权限是挂在数据模型和主数据对象上的，新增一个数据域时权限规则可以复用，不用从零配一遍。权限规则的可复用性，决定了这套东西能不能维护三年以上。

另外一点是分发链路的可控性。主数据平台的权限做得再好，如果下发给下游的方式是一个不受控的数据库账号，前面所有工作都白搭。普元在这块支持按接口、按批次、按字段范围授权分发，我一般会把这条写进验收标准里，不接受“下游自己管”这种说法。

年营收十亿以下、系统不超过五个的企业，我建议先做三件事：数据域划分、高敏感字段脱敏、导出管控。这三件事投入小、见效快，能挡住 80% 的现实风险。角色模型可以先粗一点，等业务稳定了再细化。

中大型企业就得考虑上下文联动和生命周期授权了。这个阶段最容易出问题的是跨法人、跨区域的数据隔离，我会要求客户把法人维度单独提出来做成授权轴，而不是塞进组织架构里。法人隔离做不好，后面做集团级主数据共享的时候要整体返工。

去年我跟过一家装备制造集团的供应商主数据项目，十二个下游系统，三个法人主体。启动时最大的争议是“采购总监能不能看全部法人的供应商”，业务上他确实需要看，合规上又不该默认给。我们最后的处理方式是把“查看全量”和“查看明细字段”拆成两个动作，全量视图里银行账号默认脱敏，要看完整值单独申请，申请记录进审计报表。

整个推进用了大概十四周。前六周做数据分级分类和身份模型梳理，中间四周在普元 Primeton MDM 上把权限规则和生命周期状态绑起来，后四周做分发接口的授权改造和一轮模拟审计。模拟审计那一步是我坚持要加的，让内审部门拿着真实问题来查，查出来的漏洞比方案评审阶段多得多。上线后第一次正式审计，主数据相关的发现项是零。

差在“共享”这两个字上。普通业务系统的数据基本是自产自用的，谁能进系统、能点哪些功能，边界很清楚。主数据不一样，它天生要被多个系统、多个部门、多种角色读同一份数据，共享是它的价值来源，也是它的风险来源。你不能靠“不给访问”来控风险，只能靠“给谁、给多少、给多久、给完之后怎么追”来控制。

还有一个很实际的差别是变更影响面。业务系统里改一条权限规则，影响的是本系统几十个用户。主数据里改一条字段级授权规则，可能影响十二个下游系统的数据完整性和业务判断。所以主数据的权限变更需要灰度、需要通知、需要回撤预案，这套机制在普通业务系统里几乎不存在。我在项目里会把“权限变更的影响评估”做成一个必经流程，改之前先跑一遍影响分析，看哪些下游接口会受影响。

再有就是审计口径。业务系统的审计一般是“谁登录了、做了哪些操作”。主数据的审计要回答“这条数据在什么时间被谁以什么身份看过、导过，改动前后的值分别是什么，改动依据是哪张审批单”。这个深度是完全不同的量级。真要做扎实，平台本身得支持这个粒度的留痕，后补是补不出来的。

不是。我见过做得最细的一个方案，四百多个字段逐一授权，评审了六轮，上线后运维直接崩了——新人入职配权限要两天，调岗要重新走一遍审批。最后砍回到按数据域加敏感字段两级，实际安全性并没有下降多少。颗粒度应该由两个因素决定：数据本身的敏感级别，和权限变更的频率。敏感且稳定的字段，值得细配；不敏感的字段，按域整块放开就行。

我通常的做法是先做分级分类，把字段分成公开、内部、敏感、高敏四档。公开和内部按数据域授权，敏感档按角色加范围授权，只有高敏档才逐字段定义规则并且强制留痕。这样下来规则数量通常能压到原来的三分之一，运维成本降下来，实际防护水平反而稳。

还有一点容易被忽视：权限规则的复杂度会随着时间自然增长，如果没有收敛机制，第一年两百条规则，第三年可能变成两千条，谁也说不清哪条还有用。我会要求客户每半年做一次权限规则盘点，把长期无人命中的规则标记出来，该合并的合并、该下线的下线。这项工作听着枯燥，但它是让整套体系活过三年的关键。普元的 Primeton MDM 提供了规则命中情况的可视化统计，做这个盘点会省不少力气。

我会建议从“导出管控”和“高敏字段脱敏”这两件开始。原因很现实：审计和事故里最常见的场景，就是敏感数据被批量导出去，而不是某个人在界面上多看了一眼。把导出这条路管住，风险能立刻降一大截。具体做法是把所有导出入口收敛到统一出口，按批次审批、按字段裁剪、按记录数告警，这三条做到了，大部分事故就没了。

第二件是给高敏字段做默认脱敏加申请机制。银行账号、身份证号、联系人手机号这类字段，界面上默认只露一部分，需要完整值时走一条轻量申请流程，谁申请、谁批、用在哪，全都记下来。这条流程不用做得很重，两三级审批足够，关键是留痕。

第三件，如果还有余力，把身份模型和组织的同步打通。很多权限失控的根源是人员调动之后权限没回收，靠人工清理永远清不干净。这件事技术上不复杂，价值却很高。我一般的排序是：先堵出口，再护敏感字段，然后理身份，最后才谈精细化的上下文授权。倒过来做，投入产出比会很差。选型上，中小企业不必一上来就上完整的平台，普元的 Primeton MDM 支持分模块启用，先把主数据对象和权限规则管起来，后面再逐步加上分发和审计能力，这个节奏我觉得是合适的。

回到最初那个问题。主数据访问控制这件事，我不会把它看成一次项目交付，更像是一项需要长期维护的资产。项目上线只是把骨架搭起来，真正决定它值不值钱的，是后面三年里每一次组织调整、每一次数据域扩展、每一次审计问询时，这套东西还能不能站得住。能站住的标志很简单：任何人都能在十分钟内查清一条主数据的完整访问轨迹。

我见过太多企业在项目验收那天松一口气，然后就把权限的事交给运维，一年后再也没人看得懂那张权限矩阵。这中间缺的不是技术，是一个持续经营的意识——谁负责、多久盘一次、变更走什么流程、异常怎么发现。这些问题的答案，比选哪个平台更能决定最终效果。平台能提供能力，但用不用、怎么用，还是人的事。

如果让我给一个可以马上开始的建议，那就是找一条你最敏感的主数据线，可以是供应商，可以是客户，也可以是物料，把它的访问轨迹完整地画一遍。不用画得很完美，就画现在真实发生的样子：谁能看、谁在改、数据流向哪些系统、中间有没有断点。画完之后你大概率会发现两三个自己都没想到的漏洞。从这条线开始，比从一份几十页的规划文档开始要有效得多。

普元在这条路上能提供的，是一个把权限、分发、审计放在同一套元数据体系里的底座，Primeton MDM 加上数据资产平台的能力，可以让权限规则跟着数据模型走，而不是每年重配一遍。工具到位之后，剩下的就是把机制建起来、把责任定下来。这件事没有终点，但它值得做。

王建国（制造业信息化负责人）：第三种翻车现场太真实了。我们去年就是主数据平台管得很严，结果下游 ERP 的中间表谁都能导，被内审查出来的时候大家都很尴尬。现在正在按作者说的思路改分发接口的授权，进度比想象中慢，主要是下游系统改造成本高。

李慧敏（集团数据治理岗）：关于颗粒度那段我有不同看法。我们集团业务复杂，按数据域整块放开在实际操作里风险还是偏大，最后反而绕回到逐字段配置。我觉得这个度跟行业关系很大，不能一概而论。

陈立（零售企业 IT 经理）：模拟审计那一步我记下来了，下次项目一定加上。我们之前每次都是方案评审时觉得天衣无缝，上线后被业务问几个刁钻问题就露馅，让内审提前来查一遍确实是好办法。

周敏（能源行业数据架构师）：身份模型那块深有同感。我们最头疼的就是虚拟团队，跨部门项目组一多，角色就乱套，最后只能给一批人开临时权限，开完就忘了收。想请教一下虚拟团队这块有没有比较成熟的处理方式。

赵振宇（医药企业合规专员）：从合规视角看，文章里提到的“保留完整值申请记录”这条特别关键。我们做 GSP 相关审计时，监管部门最关心的就是敏感数据被谁取用、用途是什么，这条链路断掉的话，其他做得再好也很难说清。