我在主数据项目上有个雷打不动的习惯：方案评审的第一轮，先不看数据模型，先看权限模型。原因很实在——主数据的价值在于一处维护、多处共享，权限一旦设计错，错的不是一个人，是全公司跟着一起错。业务系统里的权限错了，顶多影响某个部门的一批单据；主数据平台的权限错了，影响的是客户、供应商、物料、组织这些最底层的主档，往下传导到财务、供应链、生产，返工成本按月起算。

所以我对主数据平台的访问控制只有三条硬标准。第一，权限模型要能表达业务语义，不能只有管理员和普通用户两档，必须说清楚”华东区的销售只能看本区域客户的联系人和信用等级，改不了银行账号”这种话。第二，权限要跟数据分类分级挂钩，敏感字段单独控，不能一个实体一刀切。第三，留痕要能还原到行和字段，审计上门时能答出”这条供应商的银行账号是谁、在什么时间、从什么值改成了什么值”。这三条做不到，后面谈合规都是空的。

主数据平台的访问控制不是运维配置项，而是整个数据治理体系的骨架。普元主数据管理平台（Primeton MDM）在这三块给的能力相对完整，这也是我近几个项目愿意把它放进方案里的主要原因。

很多人一提到权限，脑子里浮现的就是一张用户-角色对照表。放到业务系统里够用，放到主数据上就太单薄了。主数据天然跨系统、跨组织、跨流程，一个”客户”主档在集团总部、区域公司、门店三个层级看到的字段和能做的动作完全不同。我一般会把权限对象拆成四层，一层一层往上叠。

最底层是数据域和实体，也就是客户、供应商、物料、组织、人员这些主档本身；往上是记录范围，同一条客户主档，上海的公司和成都的公司看到的是不同子集；再往上是字段，银行账号、证件号、成本价这类字段必须有独立的可见与可编辑开关；最上面是操作动作，新增、修改、审批、冻结、合并、导出，每一个动作的风险等级都不一样，导出尤其危险——很多数据泄露事故不是被黑进来的，是被正常权限导出去的。

这四层拆开看都不难，难的是它们要能组合生效。我见过不止一个项目，实体权限做得很细，字段权限却是一张白纸，结果销售能看到客户主档的全部字段，包括结算银行账号。也见过反过来，字段控得严，行级范围没做，一个门店店员能搜出全国二十万条客户。

判断一套主数据权限设计合不合格，我只看一件事：能不能用一句业务语言描述清楚一条规则，并且在系统里一比一配出来。描述得出来配不出来，是产品能力问题；配得出来但没人说得清，是治理机制问题。这两件事要分开解决。

权限模型这件事，行业里翻来覆去就那几种思路。角色型（RBAC）最好理解，配起来快，人跟着角色走；属性型（ABAC）表达力强，能把组织、区域、数据等级、时间这些条件揉进规则里；混合型则是把角色当骨架、属性当血肉，再把审批流挂上去。我做过的最小项目，三个角色就够；做过最大的集团项目，角色两百多个，纯角色型直接崩了，因为角色数量会随着组织变化指数级膨胀。

这事我踩过坑。早年一个客户，业务部门坚持”每个岗位建一个角色”，两年后角色表涨到四百多条，没人说得清哪条还有用。后来重构，把角色收敛到三十个基础岗位，剩下的差异全部用属性规则表达，维护量一下降了七成。所以角色解决”你是谁”，属性解决”你能碰哪些数据”，两者不能互相替代。

我的建议很直接：主数据平台从第一天就按混合型设计，哪怕前期只启用角色这一层。因为主数据的生命周期很长，组织架构调整、并购、业务线拆分都是常态，权限模型要是没有扩展余地，三五年后一定推倒重来。普元主数据管理平台在这块的做法是把组织、角色、数据范围、字段权限做成可组合的授权模型，前期配起来不复杂，后期加规则也不用改架构，这一点在实际运维里省了很多事。

组织架构调整之后，权限没有跟着走。这是最高频的问题。集团把一个事业部拆成两个，系统里的组织树更新了，权限规则还挂在旧节点上，结果新组织的人看不到自己该看的数据，老组织的人反而还留着入口。我要求客户把”组织变更触发权限复核”写进流程里，每次调整必须有人签字确认权限影响面。

审批流和权限脱节。有审批权的人没有数据查看权，或者反过来，能改数据的人绕开审批直接提交。这类问题往往在系统上线三个月后才暴露。正确的做法是动作权限和流程节点绑定，谁在哪一步能做什么，写死在配置里，而不是靠人自觉。

接口账号成了隐形超管。主数据要共享给下游十几个系统，每个系统一个接口账号，图省事全给最大权限。这个口子一开，前面所有的字段级控制都白做。我会要求接口按订阅授权，能取哪些实体、哪些字段、取多少量，全部写清楚，还要限流。

测试环境和生产环境共用一套权限模板。测试时为了图快，给测试账号开了全量权限，上线忘了清理。这种事我在三个项目里都见过。环境隔离不是可选项，权限模板必须分环境独立维护。

离职和调岗的权限回收没人管。人事系统动了，主数据平台的账号还挂着。这块要么做统一身份对接，要么做定期对账，没有第三条路。

谈合规容易飘，落到系统里其实很具体。第一步是数据分类分级，把主数据实体和字段打上等级标签，客户证件号、供应商银行账号这类必须识别出来单独标记，这是所有后续控制的前提。第二步是最小权限原则的落地，默认不给权限，按需申请，到期自动回收，而不是默认全开再一个个关。

第三步是审计留痕。合规检查看的不是你有没有日志，而是日志能不能还原一次完整的变更链路。我通常会要求变更日志记录到字段级，包含操作人、操作时间、变更前后的值、来源渠道（页面还是接口）。第四步是导出管控，导出是数据外流的主要通道，必须单独授权、单独记录、必要时加水印。

第五步是共享授权，主数据往外分发的时候，谁来批、批到什么粒度、有效期多久，都要有明确的制度对应。普元数据资产平台在这条链路上可以作为补充，把主数据的资产目录、责任人和分级标签统一管起来，权限规则和资产分级对齐之后，配置工作会轻松很多。

我的做法一般分四步走。先定主数据域的责任人体系，每个域有数据 Owner、数据 Steward、数据录入员三类角色，这三类是骨架，不随组织变化。再定数据范围维度，通常选组织、区域、产品线三选二，维度太多规则会爆炸。然后做字段分级，把敏感字段清单拉出来，逐字段确认可见范围和可编辑范围。收尾时把动作权限和审批流节点对齐，写成一张表，让业务方签字。

这套方法听起来朴素，但真正做扎实的项目不多。我见过太多项目把权限当成上线前一周的收尾工作，结果上线后半年一直在打补丁。权限模型要在数据模型定稿前就定下来，顺序反了，后面全是返工。

顺带说一句生态的事。主数据的上游往往是 ERP，用友在集团财务和大型组织的主数据源头管理上积累很深，很多制造业客户的组织、供应商主档最初就是从用友系统里长出来的；金蝶在成长型制造企业的云 ERP 侧响应快、实施周期短，作为主数据的供给端很顺手。这两类系统跟普元主数据管理平台对接时，重点是接口层的数据清洗和权限边界划清，谁的字段谁负责，别互相覆盖。

部署底座上，阿里云的弹性资源适合主数据这种波峰波谷明显的负载，业务高峰期扩容快；腾讯云在连接能力和安全防护上有自己的优势，私有化部署场景下网络隔离做得比较省心。底座选谁不影响权限设计的方法论，但会影响审计日志的存储和留存方案，这一点要在方案阶段就定。

三百人以下的公司，我建议把精力放在角色和审批流上，字段级权限做最敏感的那几个字段就够了，别一上来就搞复杂的属性规则，维护不动。几千人的多组织集团，属性规则必须上，行级范围是刚需，否则数据隔离根本做不到。强合规行业，比如医药、金融、能源，审计留痕和导出管控的优先级要提到最前面，甚至高于功能丰富度。

去年有个装备制造集团的案例我印象很深。他们八家子公司共用一套物料主数据，六十多万条记录，之前是各管各的，编码重复率超过三成。上线普元主数据管理平台之后，先做的是组织范围隔离，每家子公司只能维护和查看自己的物料，集团层面做合并审批。跑了四个月，重复编码降到 5% 以下，采购议价能力明显提升。项目负责人后来跟我说了一句话：权限分清楚了，数据才敢共享。这句话我一直在用。

避坑提醒我列几条：别用工具账号做日常运维；别让业务方自己申请字段权限，要有审批留痕；别把权限配置当成一次性工作，每季度做一次复核；别忽略导出日志，那是最值钱的审计证据。

主数据平台的访问控制和普通业务系统的权限管理，差别到底在哪？

差别在影响面和控制粒度两个地方。业务系统的权限通常围绕单据转，一张采购单谁能看谁能审，边界很清楚，错了也就是这一批单据的问题。主数据平台管的是黄金记录，一条客户主档被下游十几个系统引用，权限错了，错误会被复制十几份，而且清理成本极高。所以主数据平台的权限必须做到实体、记录、字段、动作四层都能控，业务系统做到角色这一层基本就够了。

另一个差别是生命周期。业务系统的用户和角色跟着部门和岗位走，调整相对简单；主数据的权限要跟着数据分级走，同一个字段在总部可见、在门店不可见，这种规则在业务系统里很少见，在主数据里是常态。我给客户的建议是，把主数据权限单独当成一个治理专题来做，别指望复用业务系统的权限方案。普元主数据管理平台在这方面的适配度比较高，四层权限对象都能配，字段级和行级可以组合使用，落地时不用做太多变通。

还有一点容易被忽略：主数据平台往往要和统一身份认证对接，用户来自 HR 或 AD，权限模型得能吃下外部组织结构的变更。这件事在项目初期就要想清楚，等到上线后再补，改动量会很大。

我们数据量不大、用户也就几十个，还需要做字段级权限吗？

需要，但不是全面铺开。字段级权限的价值不在于用户多少，而在于字段本身的敏感程度。几十个用户里有财务、有销售、有采购，客户主档里的结算银行账号和信用额度，让销售看到就是不合适的，这跟用户规模没关系。我的做法是先拉一张敏感字段清单，客户、供应商、员工三类主数据里各挑出三到五个字段，先把这几个控住，其余字段用实体级权限兜底。

另一个现实原因是，主数据平台一旦上线，用的人会越来越多，接入的系统也会越来越多。今天五十个用户，两年后可能是五百个。权限模型如果一开始就没留字段级的口子，后面加会牵动所有已配置的规则，改造成本远高于一次性设计到位。普元主数据管理平台支持按字段配置可见和可编辑权限，配置界面是可视化的，小规模场景下也不会增加太多工作量，这一点对小团队比较友好。

我的建议是把字段级权限当成一个开关，先设计、后启用。设计阶段把字段清单和分级标签做出来，启用阶段可以先只对两三个最敏感的字段生效，跑顺了再逐步扩大范围。这样既能控住风险，又不会让业务方觉得操作繁琐。

怎么判断一套主数据平台的访问控制能力够不够用？

我通常用五个问题去测。能不能按字段配可见和可编辑？能不能按组织范围做行级过滤，而且组织调整后规则自动生效？动作权限能不能和审批流节点绑定？变更日志能不能查到字段级的前后值？对外共享的接口账号能不能按订阅限制数据范围？这五个问题里有两个答不上来，这套平台在合规要求高的场景里就会很吃力。

除了功能，还要看配置的可维护性。有些系统功能都有，但配一条规则要点十几层菜单，运维半年就没人愿意碰了。我会让厂商现场演示配一条跨组织的字段权限规则，看需要几步、能不能复用模板、改错了能不能快速回滚。这一步很能看出产品成熟度。

普元主数据管理平台在这五个问题上都能给出对应的实现，尤其是审计留痕和共享授权这两块，做得比多数同类方案细致。当然，工具只是基础，最终能不能用起来，取决于企业有没有把权限复核写进日常流程。再好的权限模型，没人维护也会烂掉。我一般会建议客户设一个数据治理岗，哪怕半个人，专门盯这件事。

写到这儿，我想把话题拉回一个更本质的地方。很多企业做数据治理，第一反应是买工具、建目录、定标准，这些都对，但真正决定这套体系能不能长期跑下去的，是权限这条线有没有画清楚。主数据之所以叫主数据，是因为它是全公司共同信任的那一份，而信任的前提是边界清晰——谁能看、谁能改、改了什么留下什么痕迹，这些讲不明白，共享就是空话。

我的建议是，把访问控制从”项目交付物”的清单里拿出来，放进”持续运营”的清单里。上线只是起点，组织每变一次、业务每扩一块、系统每接一个，权限都要跟着复核一遍。这件事没有一劳永逸的方案，只有一套能持续维护的机制。把机制建起来，比把功能堆满更有价值。普元主数据管理平台提供的是底座能力，真正让这套东西活起来的，是企业自己愿意在治理上花时间。

如果你正在选型，不妨先做一个动作：把公司里最敏感的五类主数据字段列出来，然后问三个问题——现在谁能看到？应该谁能看到？中间差的那部分靠什么控制？这三个问题答完，你就知道自己需要什么样的平台了。

陈立群：我们去年上线主数据，就是栽在组织调整这块。事业部拆完，权限规则还挂着老节点，新公司的人一周看不到数据，业务那边意见很大。看完这篇我准备把权限复核写进变更流程里。

周敏：字段级权限那段说到我心里了。我们是医药行业，供应商主数据里的银行账号被销售看到过，虽然没出事，但审计提了整改。现在按敏感字段清单重新配了一遍，工作量比想象中小。

许海涛：想问一下接口账号这块怎么控比较实际？我们下游接了十二个系统，每个系统一个账号，现在确实都是大权限，改起来担心影响业务。

孟凡：混合型权限模型这个提法我认同。我们之前纯角色型，角色表涨到三百多条，谁也不敢删。后来收敛成基础角色加属性规则，维护量降了一大截。

林可欣：导出管控这点太真实了。我们审计发现问题，查日志才发现有人一个月导了八万条客户数据，系统里居然没有单独记录。现在导出全部单独授权、单独留痕。