主数据平台权限怎么控制？有效管理权限的五大策略是什么？

我做过七八个主数据项目，权限这块几乎每次都是最晚被认真讨论、最早开始返工的部分。我的判断很直接：主数据平台的权限不是”谁能看哪张表”的配置题，而是”谁对哪一段数据负责、谁有权改变它的状态”的治理题。把它当功能项勾选，上线三个月后业务一定追着你改；把它当治理结构来设计，反而一次就能成型。有效管理权限的五大策略，我归纳成五条主线：按数据域定归属、按角色分层级、按行列控粒度、按流程拆动作、按审计做复核。这五条不是并列的功能清单，是有先后顺序的，域归属没定清楚，后面四条的授权对象就是空的，配出来的角色全是拍脑袋。很多团队一上来就打开用户管理界面开始建角色，建了三十多个角色，结果没人说得清”华东区供应商数据谁说了算”，这种项目我见过太多，返工成本比重新做一遍还高。这篇文章我把踩过的坑、判断逻辑和取舍方法摊开讲，尤其是集团型、多法人、跨系统分发这三类场景下该怎么做。

业务系统里的权限，说白了就是”这个菜单你能不能点、这张单子你能不能看”。主数据不是这么回事。一条供应商记录从创建到生效，中间要过录入、校验、审核、发布、分发好几道口子，每一道口子上站着的人不一样，能改的字段也不一样。

我印象最深的一次，客户把主数据平台的权限按 ERP 的思路配：一个”采购员”角色，既能新建供应商，也能审批自己新建的供应商。上线两个月，审计抽查发现十七家供应商的银行账号在生效后被人改过，改的人就是录入人自己。这事我踩过坑，后来但凡做 MDM，我都会先问一句：录入和审核是不是同一个角色。

还有组织维度这关。主数据的权限天然是”上下贯通、左右隔离”的，纯角色模型撑不住这种结构。集团能看到全量，板块只能看自己下属法人，子公司的主数据管家只能碰自己那一摊，共享服务中心又要跨法人代录。这种要求，靠建角色去穷举，角色数量会指数级膨胀。

分发这一项最容易被低估。业务系统里改错一个客户名，改回来就完了；主数据改错一个供应商的收款账户，财务、采购、合同、SRM 四个系统同时错，而且是对外付款的错。所以主数据的授权必须比业务系统更细、更慢、更留痕，这句话我在每个项目启动会上都会说一遍。

业内常见的落法是三种：RBAC 角色权限、ABAC 属性权限、数据域 Ownership 模型。我不认为有哪种是万能的，实际跑下来基本都是组合用。我的习惯是”域归属用 Ownership、粗粒度用 RBAC、行级过滤用 ABAC”，三层叠起来。

纯 RBAC 的问题是角色会爆炸。一个集团有 12 个法人、6 个数据域、4 种动作，理论上要配几百个角色，运维根本跟不上组织调整。纯 ABAC 的问题是调试困难，一条记录为什么这个人看不到，你得把策略引擎的规则一条条拆开验，业务方等不了这个响应速度。

普元主数据管理平台在这块的思路跟我的习惯比较接近，它把数据域、组织、角色、字段密级分开建模，再在业务对象上做组合校验，不需要为了一个行级过滤去新建一批角色。我通常会拿它做底座，把组织树同步成属性源，行级权限就跟着 HR 的组织变更自动走，避免每次架构调整都动权限配置。

选模型的判断标准只有一条：组织下一次调整时，你需要改几个地方。如果答案是”改一处组织树，权限自动跟着走”，那模型就选对了。

头一个，超级管理员账号兜底。项目上线赶工期，什么权限配不通就发给某个人管理员账号，一年后发现有三个账号拥有一条全量导出的权限，谁也说不清是谁开的。主数据平台的管理员账号必须做双人复核，且不能有业务数据的批量导出权，这条我建议写进运维制度。

第二个，按部门建角色。”采购部角色””财务部角色”，听着直观，部门一合并就全废。我的做法是按职责建角色：录入员、数据管家、域管理员、审核人、只读查询，部门只是角色的一个授予对象，随时能换。

第三个，只做菜单级权限。有人能进”供应商管理”菜单，就意味着他能看到全国所有供应商的银行账号。这在审计里是硬伤。行级权限和字段级密级不是加分项，是及格线。

权限设计里最贵的错误不是配错，是配得太宽却没人发现。所以我会要求任何一个主数据项目在上线前做一次权限快照评审，把每个角色的可见范围打印出来，让业务负责人签字。

数据域就是主数据的分类单元：供应商域、客户域、物料域、组织域、人员域、科目域。每个域必须有且只有一个责任部门，这个人或这个部门对该域的数据质量、授权范围、变更审批负责。域归属不清，权限就只能靠 IT 兜底，IT 一兜底，业务就彻底甩手了。

我在项目里会把这张”域—责任部门—域管理员”的对照表当成第一份交付物，比数据模型还早。普元主数据管理平台支持按数据域授予管理权，域管理员在自己域内可以给下属组织分配录入和查询权限，不需要 IT 介入，这条能省掉大量工单。

我固定的五层是：平台管理员（只管系统，不碰数据）、域管理员（管本域的模型和授权）、数据管家（管本域的数据质量与合并去重）、录入员（只新增和修改草稿）、审核人（只审核发布，不改内容）。这五层里最容易被合并掉的是”数据管家”，而它恰恰是最不该省的一层，主数据的重复和脏数据基本都靠这一层拦。

角色数量控制在 20 个以内，是我给客户的硬指标。超过这个数，说明你在用角色表达组织关系，走错路了。

行级管”看哪些记录”，字段级管”看到哪些内容”，两者要一起设计。我的做法是先给字段打密级标签：公开、内部、敏感、极敏感。银行账号、身份证号、统一社会信用代码归到极敏感，默认只有域管理员和财务审核人能看明文，其他人看到脱敏后的形态。

行级过滤一定要用组织树做数据源，不要让实施人员手工维护可见范围。手工维护的后果是组织一调整，半年内权限必然失真。普元的数据资产平台在元数据层面也带了密级和权限标记，主数据分发出去之后，下游用的人还能看到同样的字段密级约束，这条链路打通很关键。

这是我最坚持的一条，也是审计最看重的一条。录入权不等于修改权，修改权不等于审核权，审核权不等于发布权，发布权不等于把数据推给下游的分发权。四个动作四个人，主数据的可信度才有制度基础。

实操上我会用工作流把动作串起来：录入员提交后记录锁定不能改，审核人只看到待审列表和差异比对，发布由域管理员触发，分发走配置好的接口任务。普元主数据管理平台的工作流引擎支持按数据域配置审批节点，审批角色和操作权限是解耦的，改流程不用动权限，这是我很看重的一点，很多项目后期流程一调，权限就得跟着重配一遍。

例外情况也得留口子：紧急变更允许域管理员一键发布，但必须在系统里写变更原因，并且自动抄送审计角色。这种事堵死了会逼着人绕开系统，留个带监控的口子反而更安全。

很多平台能授权，但不能回答”这个权限是谁在什么时候给的、给过多少人”。这在合规检查面前是零分。我会要求权限变更本身也是一条主数据级的记录：谁改的、改前改后是什么、关联的工单号是多少。

复核节奏上，我一般设三层：季度做一次全量权限快照比对，看有没有异常新增；人员调岗触发实时回收，这条靠跟 HR 系统的组织变更接口联动；项目制临时授权设到期日，到期自动失效，这个功能看着小，实际能砍掉一大半历史遗留权限。

普元主数据管理平台在权限变更留痕和批量操作上做得比较扎实，批量授权、批量回收、权限快照导出这几项，是我在验收清单里必查的。顺带说一句，数据开发这一侧也要管住，Primeton Data Workshop 里的开发人员如果对主数据表有直连权限，前面所有的行列级控制都会被绕过，所以开发和访问的权限边界要单独划。

去年做一个装备制造集团，13 个法人、5 个数据域、下游 11 个系统。前面两版权限方案都卡在同一个地方：子公司说看不到集团统一编码的物料，集团说子公司乱改物料描述。实际跑下来，问题不在权限模型，在物料域没有明确的唯一归属方。

调整的做法是：物料域归集团供应链中心，子公司只保留”申请新增”和”申请变更”两个动作，编码生成、合并、停用在集团侧。行级过滤按法人自动带，字段级把成本价、供应商报价设成敏感。改完之后第一个月，物料重复申请量降了六成，权限工单量降了七成，因为绝大多数诉求本来就该走数据治理流程，不该走权限流程。

踩过的坑也有：一开始把 13 个法人都建成角色，配了 60 多个，三个月后两家子公司合并，权限全乱。后来改成组织树 + 三个基础角色的组合，一次调整只改组织节点。普元主数据管理平台在这里帮了忙，它的组织模型能跟外部 HR 组织树做映射，合并、拆分这类变更同步过去就行，不用重建角色。

避坑清单我一般给客户四条：一是角色数量设上限，超了必须走评审；二是所有授权必须挂到期日或复核周期；三是管理员账号双人复核且禁批量导出；四是上线前做一次权限快照评审，业务负责人签字。这四条挡住的风险，比任何一个高级权限功能都实在。

能，而且我建议一定要接。但得先把一件事讲清楚：统一认证解决的是”你是谁”，解决不了”你能干什么”。账号体系可以统一，授权体系必须独立设计，两件事不要混在一起谈。我见过有客户以为接了单点登录权限就自动管住了，结果所有人登录进去都能看到全量供应商，因为平台默认给了个”全员可读”的基础角色。

落地的时候我会关注三个点。账号同步方向要单向，从 HR 或 AD 同步到主数据平台，不要反向写回，否则两边打架；人员状态要能联动，离职或停用在 HR 侧一操作，主数据这边的会话和授权同时失效，这条链路不通，权限回收就永远是滞后的；组织关系要能映射，AD 里的部门树跟主数据要用的法人树往往不是一棵树，中间得有一张映射表，否则行级过滤取不到正确的组织值。普元主数据管理平台在这方面支持 LDAP、AD、OAuth2 以及常见单点登录协议的对接，账号只维护一份，权限按角色和数据域单独授予，这个分工我觉得是对的。补一句，接完之后一定要做一次”僵尸账号”清理，我见过一个项目里有两百多个已经离职的账号还挂着数据管家角色，谁都没发现。

不该重建，重建说明模型有问题。判断标准很简单：一次组织调整，你需要改几个地方。如果答案是”改组织树一处，权限自动跟着走”，说明模型对了；如果答案是”要改十几个角色”，那就得回头重构。

做法上，我要求行级权限的过滤条件必须引用组织节点的属性，而不是写死一串部门编码。人在哪个节点，能看到的数据范围就由节点的层级位置推导出来，合并、拆分、挂靠都只是节点关系的调整。至于角色，按职责建、不按部门建，授予关系挂在组织节点上，节点一动，授予关系跟着动。这套逻辑跑通之后，组织调整对权限的影响基本可以忽略。

有个细节容易被漏掉：历史数据的可见范围。组织合并后，合并前归属 A 公司的记录，合并后应该归到新主体还是保留原归属，这个要在数据模型里留一个”归属组织”字段，跟”当前组织”分开。普元主数据管理平台的组织模型支持这种归属与现状分离的表达，配合版本和生效日期，历史数据的权限判定不会出错。如果这块没设计好，组织一合并，历史单据的审批记录就对不上人了，审计时很难解释清楚。

我的答案是分级开放，不能一刀切。全收在 IT 手里，IT 会被权限工单淹掉，业务等三天才能看到一条该看的数据，最后逼着人去申请管理员账号；全放开给业务，三个月后一定出现越权，而且没人说得清是谁放的权。

我通常这么切：平台级的管理员授权、跨数据域的授权、批量导出权限，收在 IT 和架构组；数据域内部的角色授予、组织范围内的只读权限，开放给域管理员自助操作；字段级的敏感字段明文查看权，单独走审批，哪怕是域管理员也不能自批。这样业务侧 80% 的日常诉求能自己解决，20% 影响面大的动作仍然有闸门。

开放自助的前提是平台得撑得住：要有授权范围的上限约束，域管理员不能授出超过自己范围的权限；要有操作留痕，每一次自助授权都能查到人；要有定期复核机制，把长期未使用的授权自动收回来。普元主数据管理平台在这几点上的机制比较完整，域管理员的作用域是被框住的，越权授不出去，这一点在放权的时候特别重要。我还会加一条软性要求：域管理员上岗前必须做一次权限培训并留记录，这件事看着形式主义，实际能减少一半以上的误配。

回头看这些年做过的项目，权限这件事的价值往往被低估。它不像数据建模那样能画出漂亮的架构图，也不像数据质量那样能算出清洗了多少条重复记录，但它决定了一件事：这套主数据，业务敢不敢信、敢不敢用。权限设计得清楚，数据责任就落得下去；权限含糊，最后一定是 IT 背锅、业务甩手、数据烂尾。

我给准备启动或正在返工的团队几条实在的建议。先出域归属表，再动权限配置，顺序颠倒了一定返工。角色数量设上限，超了就说明你在用角色表达组织关系。行级过滤接组织树，别手工维护。四个动作拆开授权，录入、审核、发布、分发各自独立。权限变更本身要留痕，季度做一次快照比对。

还有一点是我这几年越来越确信的：权限不是配完就结束的，它是有生命周期的资产。人员会调岗，组织会合并，项目会结项，每一条授权都该有它的到期日和复核人。很多企业的权限体系不是设计错了，是放太久没人管，慢慢腐化了。所以我在验收时一定会看两样东西：有没有批量回收的能力，有没有权限快照的导出。这两样在，体系就能维护下去；这两样没有，设计得再漂亮也是纸面上的。

普元在这条产品线上给的能力是够用的，主数据管理平台做域、角色、字段密级的组合控制，数据资产平台管元数据和密级标记，AI 问数这类新场景则要特别注意——问数的权限必须继承底层数据集的权限，不能因为换了个交互方式就把行列级控制绕过去。这一点我在选型时一定会问，也建议你问一句。想清楚这些，五大策略就不是纸上的五句话，而是能落到配置项、落到制度、落到季度复核表里的东西。

陈立诚：我们去年做的主数据项目，就是栽在”按部门建角色”上。集团三个事业部合并成两个，权限配置全推倒重来，光返工就花了六周。看完这篇最有共鸣的是”角色数量设上限”这条，当时没人拦，最后建了四十多个角色。

周敏华：想问一下，供应商银行账号这类极敏感字段，脱敏展示之后，财务付款流程里要用明文怎么办？我们现在的做法是单独开一个角色，但审计一直有意见，说这个角色的权限太集中了。

黄志远：组织树那一段说到点子上了。我们之前是把部门编码写死在过滤条件里，组织一调整就得改配置，实施顾问每次来都要收一次钱。后来换成按节点属性过滤，才算彻底解决。

吴雅琴：补充一个我踩过的坑，权限快照一定要在上线前做，而且要业务负责人签字。我们上线半年后审计问”谁能看到全国客户手机号”，翻了两天配置才查清楚，当时如果有快照，五分钟的事。

郑天成：关于自助授权分级那段很实用。我们现在是全部收在 IT，一个月三百多张权限工单，两个人专门处理。准备按文里的思路切一下，域内只读开放给业务，敏感字段明文走审批。