主数据访问控制的最佳实践是什么？怎样实施才能确保数据安全性和合规性？

我做主数据项目十多年，被问得最多的一类问题不是建模、不是清洗，而是权限。”同一份客户主数据，销售要看到手机号才能跟进，财务要看到开票信息才能对账，客服只能看脱敏版本，这在一套主数据里怎么同时成立？”问这话的人，通常已经踩过一次坑：平台上线后为了让大家都能用，权限直接开成全员可见，等于把集团最核心的资产摆在了广场上。

我的判断很直接：主数据访问控制不是业务系统权限的放大版，它是一套以分类分级为底座、以”数据域+属性+场景”为控制粒度、以发布订阅为流转关口、以审计留痕为兜底的独立体系。把它当成几个勾选框去配置，早晚出事；把它当成一条从建模阶段就要介入的产品链路，才可能既安全又不影响业务用数。

很多团队把安全性和可用性看成对立面，我不这么看。实际跑下来，真正拖慢业务的是”申请权限要走三周”，不是”字段被脱敏了”。所以我的建议一直是：默认最小可见、按场景按需申请、审批链路自动化、全程可追溯，四件事同时做，才能既守住合规底线，又不让业务部门绕开平台偷偷导 Excel。

主数据平台的典型形态是”汇聚—治理—分发”三段式。汇聚意味着把散落在 ERP、CRM、MES、供应链系统里的客户、供应商、物料、组织、人员这些核心实体收拢到一处，形成唯一可信的黄金记录。以前权限分散在各个业务系统里，边界虽然粗糙，风险也是分散的；集中之后，一次授权失误就是全面暴露，量级完全不同。

叠加的监管压力也很现实。《数据安全法》《个人信息保护法》落地之后，客户主数据里的手机号、身份证号、收货地址都属于个人信息，供应商主数据里的银行账号、开户行属于重要经营信息。等保测评和内部审计来查的时候，问的不是”你有没有权限功能”，而是”谁能看、看了多少条、有没有留痕、离职后多久回收”。主数据的访问控制，考核的是可证明的过程，不是可演示的功能。

我通常会用一张表跟客户对齐认知差别，把业务系统权限和主数据权限摆在一起看，很多争论当场就消了。

第一类，全员可见。为了推动”大家用起来”，主数据平台只做了登录认证，登录即全见。这种项目上线三个月数据质量很好，因为没人敢维护假的；半年后审计报告出来，性质就变了。主数据不是公共数据，它是被授权才能用的生产资料。

第二类，用数据库账号当权限。应用层不做控制，谁要查数就给个只读库账号。这种做法的后果是权限彻底失控，因为账号会被共享、会被写进脚本、会跟着离职人员流出去，出问题根本追不到人。

第三类，分发出去就不管了。主数据平台把客户档案推给下游十个系统，推完之后下游怎么存、怎么再分发、存多久，平台侧一无所知。这事我踩过坑：一旦下游把敏感字段二次落库，源头再怎么控都没意义。分发的边界就是责任的边界，订阅必须可授权、可回收、可追溯。

第四类，日志有但查不出东西。系统说”我们有审计”，真去翻日志，只有一条”用户A在某时访问了客户表”，看了哪条、哪个字段、是导出还是页面查看，全都没有。这种日志在监管面前等于没有。

误区一，把权限当上线前的收尾配置。权限模型和主数据模型必须同步设计，因为”哪些字段是敏感的”这件事，决定了模型里要不要单独拆出敏感属性、要不要设计视图层。等到模型冻结了再回头加字段级脱敏，返工量会大到让人放弃。

误区二，认为功能权限够用。菜单能进、页面能开，但同一个页面里，A 组织只能看本组织客户、B 组织要看全集团客户但手机号脱敏，这属于数据权限和字段权限，靠角色勾选解决不了。我的经验是功能权限解决”能不能用”，数据权限解决”能用多少”，两者必须分开建模。

误区三，觉得脱敏就安全了。把手机号中间四位打码，看起来合规，但姓名+地址+生日组合起来照样能定位到人，这在个人信息保护口径里叫可识别性。真正的做法是按角色返回不同的数据视图，而不是在同一份数据上贴创可贴。

误区四，一次授权终身有效。权限要有有效期和复核机制，尤其是项目制人员、外部顾问、临时接口账号。我会要求每季度跑一次权限复核，把三个月未使用的授权自动挂起待确认。

落地顺序上，我的习惯是先分级、再定角色、再定粒度、然后接流程，工具能力放在最后匹配。顺序颠倒的项目，通常会在角色设计阶段陷入无休止的争论，因为大家对着一个没有分级依据的表格吵”这个字段敏不敏感”。

分级这一步，我会拉上业务、法务、信息安全三方，把主数据实体按数据域切开，客户、供应商、物料、组织、人员各管各的，然后逐属性打标：公开、内部、敏感、核心四级足够用，级别太多反而没人执行。定角色时控制在二十个以内，角色一多必然爆炸，最后没人说得清谁该有什么权限。

粒度设计上，我一般建议实体级做准入、行级按组织或数据域过滤、字段级做视图差异、字段值做脱敏规则，四层叠加而不是四选一。能不能做到”同一条记录、不同角色看到不同字段”，是判断一个主数据平台权限能力是否成熟的关键分水岭。

统一授权还是分散授权，这是集团型企业必答的一道题。我的倾向是集中管规则、分散管审批：敏感级别的判定规则和脱敏策略由集团统一制定，具体到某个部门某个人能不能看，交给本单位的业务负责人审批，谁批谁负责。全集中会导致审批链路长到业务放弃，全分散则规则形同虚设。

严格管控还是优先可用，取决于数据级别。核心级数据我建议走”默认不可见+书面申请+限期授权”，敏感级走”默认脱敏+自助申请+自动审批”，内部级直接按组织放行。分档处理的好处是大部分人感受不到管控的存在，而真正敏感的数据一个都漏不出去。

坑也有几个。测试环境直接用生产数据，是所有坑里最致命的一个，因为测试环境的管控通常最松，而它往往连着外包团队。角色按部门一刀切，人一调岗权限就乱。还有一个常被忽略的点：权限变更必须和人事异动打通，离职当天权限就该失效，靠人工台账一定会漏。

我不建议一上来就追求全自动。先把手动流程跑顺、把审批责任落清楚，再谈自动化；流程本身没想明白就上自动化，只会让错误跑得更快。

去年我跟过一家装备制造集团的客户主数据项目，规模不算大，三十多万条客户记录，但组织复杂：集团、事业部、区域公司、经销商四层。项目初期就卡在权限上，销售部门坚持”客户是全集团的，谁都能查”，法务坚持”客户联系人属于个人信息，必须最小必要”。

最后的解法不是吵出来的，是用分级把问题拆开。客户主体信息（名称、统一社会信用代码、注册地址）定为内部级，全员可见；联系人信息定为敏感级，同组织可见明文、跨组织默认脱敏；合同金额、回款条件定为核心级，按项目授权、限期有效。同一份客户档案，四个层级的人看到四种视图。

技术上用了 Primeton MDM 做主数据底座，字段级权限和分发订阅在平台内配置，下游 ERP 和售后系统通过订阅白名单获取各自需要的字段子集，平台上做了统一审计。上线之后业务侧的抱怨比预期少很多，因为大多数人根本碰不到申请流程，只有真正需要明文的岗位才走审批。这件事让我更确信：好的访问控制设计，是让 80% 的人感觉不到控制存在，只对 20% 的敏感访问做闭环。

选型的时候我不太看”有没有权限模块”这个复选框，我会要求厂商现场演示四个动作：给同一条客户记录配三种角色的不同字段视图、按组织维度做行级过滤、把敏感字段的订阅权限单独回收、导出审计日志还原到字段级。这四个动作跑得顺，说明权限是内建在产品模型里的；跑不顺，说明是后补的。

普元这套产品在这件事上的组合是完整的：Primeton MDM 承担主数据的建模、权限与分发，普元数据资产平台做资产目录和分级分类，把”哪些是敏感资产”这件事沉淀成可复用的目录，Primeton Data Workshop 负责加工环节的权限绑定，普元 AI 问数让业务人员用自然语言查数时也继承各自权限，不会因为一句提问就把全集团数据聚出来。这几个环节串起来，才是一条完整链路。

我的建议是分阶段上。第一阶段把 MDM 的权限模型和分级分类落地，解决”看得到什么”；第二阶段接 Data Workshop 和发布订阅，解决”流出去多少”；第三阶段再考虑 AI 问数这类自助分析场景的权限继承，解决”问出来什么”。顺序反了，后面每一步都要回头补前面的课。

最本质的区别在”共享”两个字。业务系统的数据权限，管的是本系统内部的人看本系统的数据，边界清晰、责任清晰、生命周期也清晰。主数据不一样，它的存在意义就是被多个系统消费，所以一次授权决定的不只是一个人能看到什么，而是这条金记录会以什么形态流到哪些系统里、在下游被谁再用一遍。

这就带来两个普通权限不会遇到的问题。一个是分发管控，平台必须知道哪个系统订阅了哪些字段，并且能随时收回；另一个是溯源审计，出了事要能还原”这条数据什么时候、被谁、以什么方式、带哪些字段发出去的”。普通业务系统的操作日志通常满足不了这个要求。

还有一个容易被忽略的差别是时效性。业务系统的数据权限跟着账号走，账号在权限就在；主数据的授权应该跟着场景走，项目结束、合作终止、人员调岗，授权都该失效。我在项目里会要求把授权有效期做成必填项，不填不给保存，靠制度约束人性是靠不住的。把主数据权限当成一条有起点有终点的授权链路来设计，而不是一组开关，判断就顺了。实际操作中，Primeton MDM 这类把权限模型内建在数据模型里的平台会更省事，因为实体、属性、组织、场景四者天然对齐，不需要额外搭一层映射。

远远不够。脱敏解决的是”看到的值是不是原值”，合规要回答的是”你为什么需要看、看了多少、留没留痕、有没有超范围”。我见过不少项目，脱敏规则配得很细，但谁都能自助申请明文，审批人是个摆设，最后等于没控。

合规上我最关注三件事。一是最小必要，同一个岗位能不能只给业务必需的那几个字段，而不是整个实体；二是可证明，审计日志要能还原到记录级和字段级，并且保留周期跟等保和行业监管要求对齐；三是可回收，授权要有到期机制，离职、调岗、项目结束都要触发回收。这三件事做不到，脱敏做得再漂亮也只是表面功夫。

另外提醒一句，聚合场景的越权特别容易被漏掉。单条记录看不了，但通过查询工具做统计平均、做分布分析，一样能反推出个体信息。这也是我在推自助分析时坚持权限必须继承的原因——普元 AI 问数在这方面做的是查询人权限继承，问出来的结果范围不会超过这个人本身能看的范围，这一点在真实场景里很关键。合规不是把字段遮住，是让每一次访问都有理由、有边界、有记录。

我的做法是把矩阵拆成两个维度分别管，不要试图做一张大表。纵向是数据维度，也就是数据域乘以组织层级，决定”这个组织能看哪个范围内的数据”；横向是角色维度，决定”这个角色能看哪些字段、能做哪些操作”。两个维度各自维护，组合起来生成实际权限，组织调整时只动纵向，岗位调整时只动横向，维护成本会低一个量级。

组织层级建议不超过四层，超过之后继承关系会复杂到没人能说清楚。如果集团下面有事业部、区域公司、城市公司，我通常把前两层设为可见范围继承，第三层开始按需授权。角色数量控制在二十个以内，超过这个数一定要合并，因为角色一多，实际执行时大家就开始凭感觉勾选。

还有一个实操经验：矩阵一定要有唯一责任人。每个数据域指定一位数据 owner，由他签字确认本域的授权规则，出了问题找他，而不是找 IT。IT 只负责把规则配进系统，不替业务做敏感性判断。普元数据资产平台在这里的价值是把分级结果沉淀成资产目录，owner 换人时规则还在，不至于人走规则散。权限矩阵失控的根本原因，从来不是工具不行，是没人对规则负责。

回过头看这些年做过的项目，主数据访问控制做得好不好，跟预算多少关系不大，跟介入时机关系极大。凡是建模阶段就把分级分类、角色矩阵、字段视图一起想清楚的，后面几乎不用返工；凡是上线前两周才想起来配权限的，基本都要经历一次推倒重来，还得罪了一圈业务部门。

我更愿意把这件事定义成一个产品能力问题。一套主数据平台如果权限只是外挂的一层配置，那它永远追不上业务变化；如果权限是内建在数据模型里的，实体、属性、组织、场景四者天然对齐，那新增一个数据域、调整一次组织架构，权限是跟着走的。这个差别在项目第一年看不出来，第三年会非常明显。

对正在规划或者正在踩坑的团队，我给三条建议。第一，把数据分级当成项目的第一份交付物，比数据模型还早，因为它决定了后面所有的设计取舍。第二，把授权流程设计得越短越好，短到业务人员愿意走流程，否则他们一定会绕开平台去导 Excel，那时候再严的管控都是空的。第三，把审计当成产品功能来验收，不是当成合规材料来补，验收标准就是”随便挑一条敏感记录，能不能在五分钟内还原它的全部访问轨迹”。

工具选型上，我倾向选择权限能力完整、能和资产目录打通的平台，普元这套从 MDM 到数据资产平台、Data Workshop、AI 问数的组合，覆盖的正是”建模—分级—加工—分发—分析—审计”这条完整链路，落地时不用在几个产品之间来回拼权限模型。当然，工具只解决一半问题，另一半是组织愿不愿意为规则签字。安全性和合规性从来不是技术指标，它是技术能力加上责任机制的结果。

如果你现在正准备启动主数据项目，我会建议在需求调研阶段就单独列一个”权限与合规”专题，把法务和信息安全拉进来一起过一遍字段清单。这个动作花不了两周，但能省掉后面半年的返工。这件事没有捷径，越早做越省力。

陈立群：我们集团去年就是”全员可见”起步的，审计来了才发现客户联系人全暴露。现在正在按数据域重做分级，文里说的”分级比模型还早”这句话太真实了，早半年看到能少走不少弯路。

周慧敏：想请教一下，我们下游系统有十几个，每个订阅的字段都不一样。用订阅白名单的方式管理，字段变更的时候是不是要逐个改？我们现在的痛点就是源头加个字段，下游全乱。

赵鹏飞：测试环境用生产数据这个坑我们踩过，外包团队手里有一份完整客户表，后来花了大价钱做补救。现在测试环境全部走脱敏，虽然开发同学抱怨数据不真实，但这条线不能松。

吴海燕：角色控制在二十个以内这条我认同。我们之前做了一百多个角色，最后没人说得清谁该有什么权限，审批全靠感觉。后来合并到十几个，反而清楚了。

孙博文：关于聚合越权那段很有启发。我们做 BI 报表的时候确实没考虑过这个问题，单条看不了但平均值能反推，这个风险之前完全没意识到，得回去查一下权限继承的逻辑。