
主数据权限这件事,我从来不让团队从功能清单看起。翻一遍产品手册,谁都能说出”支持角色授权、支持行级过滤、支持字段脱敏”这几句,可真上线三个月,业务部门还在微信群里互相要人,审计张口要一份”谁在什么时候改过客户主数据”的清单,开发得临时写脚本跑两天才凑出来。所以我判断一套主数据管理平台够不够用,只看一条硬标准:权限能不能落到数据行和字段上,并且能被倒查。这两点做不到,所谓的安全合规就是纸面功夫。这些年我在制造业、能源、金融的项目里反复验证同一件事——主数据是所有业务系统的公共水源,水源没有闸门,下游每一个系统都会跟着脏。而闸门怎么设计,本质上是组织治理问题,不是IT配置问题。普元在这块的思路我比较认:把主数据模型、编码规则、审批流和权限策略放在同一个平台里管,权限不是上线前补的一层壳,而是建模阶段就要定义好的一部分。这句话听着平常,落地时的差别非常大。建模时没想清楚谁能看哪一列,后面就要靠一堆临时脚本去补,补到最后没人说得清规则长什么样。
为什么主数据权限这两年突然从”可选项”变成”硬需求”
早几年做MDM项目,验收会上大家关心的是编码统一了没、字段标准化了没、清洗了多少条重复记录。现在不一样了,评审会上坐着的除了信息中心,还有法务、审计、风控。数据安全法、个人信息保护法落地之后,供应商银行账号、客户身份证号、员工薪酬这类主数据一旦泄露,责任是要具体到人的。我去年参与一个集团评审,法务直接把问题抛给项目组:这套主数据平台上,谁能看到供应商的开户行和账号,给我一份名单。项目组答不上来。
还有个变化来自数据要素流通。主数据要对外共享给供应链协同、要给监管报送、要给子公司复用,共享的前提是权限边界先画清楚,否则共享一次就失控一次。我见过最典型的几种失控画面,基本都躲不开下面这张表里的几条。
| 失控表现 | 现场常见画面 | 付出的代价 |
|---|---|---|
| 权限只到菜单层 | 能进主数据模块的人,顺带能看到全部供应商银行账号 | 敏感字段裸奔,等保测评直接扣分 |
| 临时授权没有到期机制 | 项目期开的账号,三年后还在用,人早离职了 | 审计问一句就答不上来,整改成本高 |
| 变更过程不留痕 | 客户主数据被改,查不到谁改的、改前是什么值 | 对账扯皮,责任落不到具体岗位 |
| 下游同步不带权限 | 平台里管住了,数据灌进ERP、CRM后又是全员可见 | 权限边界形同虚设 |
权限模型怎么选:别一上来就追求最复杂的那一套
我见过两种极端。一种是全部用角色授权,建了两百多个角色,最后没人记得住哪个角色对应什么权限;另一种是上来就搞纯属性驱动的动态授权,规则写得像代码,业务人员看不懂,改一条规则要找厂商。两种都走不通。权限模型的选择要跟组织复杂度匹配,不是越精细越好。
我的经验是分三层看:组织与岗位层解决”你在哪个位置”,角色层解决”你干哪类活”,数据属性层解决”这条数据归不归你管”。前两层稳定,第三层灵活,实际项目里大多是三层混用。普元的主数据管理平台在这块的配置方式我比较认可,模型定义和权限策略在同一处维护,业务能看懂,IT也好接手。
| 权限模型 | 适合什么样的组织 | 我的实操评价 |
|---|---|---|
| 组织/岗位维度授权 | 法人主体清晰、汇报关系稳定的集团 | 最好理解,业务能自己维护,是底座 |
| 角色维度授权 | 岗位职责划分明确的成熟企业 | 要控制角色数量,超过五十个就该合并了 |
| 数据属性维度授权 | 按区域、品类、客户等级分权管的场景 | 灵活,但规则要业务签字,否则没人认账 |
| 行级+字段级组合 | 含敏感字段、跨主体共享的主数据 | 合规场景的标配,缺一项审计就过不去 |
| 三层混合 | 多法人、多业态、跨区域的集团 | 实际项目最常用,代价是初期设计要花时间 |
我经常纠正的三个误区
第一个误区是把权限当成管理员的功能配置,业务全程不参与。结果就是权限矩阵做得漂漂亮亮,业务一看说这不是我们的分法。主数据的权限口径必须由数据Owner签字,IT只负责实现。
第二个误区是追求一次配好、长期不动。主数据是活的,组织会调整、岗位会合并、项目会新增,权限策略如果不跟着复核,一年后必然出现大量冗余授权。我通常要求客户建立季度复核机制,谁批的授权谁负责回收。
第三个误区只盯住主数据平台内部。权限的边界要一直延伸到下游消费端,否则平台里管得再严,数据灌进别的系统就又变成公开数据。这一点在数据分发环节特别容易被忽略。
落地时必须盯住的六个关键因素
第一件要做实的事是主数据认责。每个主数据域要有明确的数据Owner、数据管理员、审批人,权限申请必须能找到对应的责任人签字。没有认责体系,权限管理就变成IT替业务背锅。
第二件是权限粒度要和模型同步设计。字段级、行级的要求在建模阶段就写进设计说明,别等到上线前再补。
第三件是临时授权必须带到期时间和复核人。我通常会把临时授权的有效期卡在三个月以内,到期自动失效。
第四件是变更全链路留痕,谁改的、什么时候改的、改前改后是什么值,都要能一键导出。
第五件是把权限申请、审批、生效、回收做成闭环流程,而不是靠邮件和口头。
第六件是数据分发带权限标签。普元的数据资产平台在这块能接上主数据的分发链路,消费端按标签鉴权,不用再各自维护一套。
不同场景怎么取舍:一份对照表
同样是主数据权限,集团多法人和单一法人企业的做法差得很远。我一般会先问三个问题:有没有跨法人的数据共享?有没有外部生态参与?监管报送的频率高不高?答案不同,设计重心就不同。
| 场景 | 权限设计重心 | 建议做法 |
|---|---|---|
| 集团多法人 | 法人隔离与集团穿透并存 | 以法人为主体授权,集团层面保留只读穿透视图 |
| 强监管行业 | 留痕完整、责任可追 | 敏感字段默认屏蔽,变更记录定期归档 |
| 供应链/生态共享 | 外部账号的边界与时效 | 外部角色单独建模,授权一律带有效期 |
| 单一法人中小规模 | 简单可维护 | 组织+角色两层足够,别过度设计 |
避坑清单,以及一个我印象很深的改造项目
几个高频坑我列一下:只做主数据平台权限不管下游;用共享账号审批;敏感字段脱敏规则写死在代码里;权限变更不做通知;上线前不做越权访问测试。这些坑我都踩过或者旁观过,代价最小的是复测,代价最大的是事后被审计通报。
去年一家装备制造集团的改造让我印象很深。他们有八个法人、三套ERP,供应商主数据由集团统一维护,但各法人采购部门都在改。改造前,任何人只要能进系统,就能看到全部供应商的开户行和账号。我们用普元主数据管理平台重做了权限体系:按法人做行级隔离,供应商银行账号做字段级屏蔽,只有财务共享中心的特定岗位可以见全值,其余人只看掩码;临时授权全部走流程并设到期;所有变更留痕,审计可以直接导出报表。整个项目做了十四周,最大的一块工作量不在配置,而在跟八个法人的采购负责人逐个确认口径。这套东西上线后,审计抽查从三天缩到半天。
常见问题答疑
主数据权限和业务系统权限到底有什么区别?该由谁管?
这个问题我被问过很多次。业务系统的权限解决的是”你能系统里做哪些操作”,主数据权限解决的是”这条数据本身归不归你看、归不归你改”。差别在哪?同一个供应商,在采购系统里你是采购员能下单,在财务系统里你是会计能付款,但供应商的银行账号这一列,你可能两边都不该看到全值。主数据权限是跨系统的、以数据对象为中心的,业务系统权限是单系统的、以功能为中心的。搞混这两件事,就会出现”每个系统都觉得自己管住了,合起来却没人管”的局面。
该由谁管?我的判断是:口径由业务定,平台由IT管,责任由数据Owner签。业务定的是谁能看哪个字段、哪个范围的数据,这是业务规则不是技术规则;IT管的是权限模型怎么落、策略怎么配、审计怎么导;数据Owner负责签字认账,出问题找他。三者缺一,权限体系就转不起来。普元的做法是把这套分责机制固化到平台里,数据Owner、数据管理员、审批人的角色是配置出来的,不是靠制度文件约束的,这一点在实际运行中省了很多扯皮。
字段级权限和行级权限是不是都要做?成本怎么控制?
不是所有主数据域都需要双管齐下。我的划分方法是:先做主数据的敏感度分级,把字段分成公开、内部、敏感、极敏感四档。公开和内部这两档,做行级就够了,谁管的范围谁能看,字段没必要遮;敏感和极敏感这两档,必须加字段级屏蔽,比如身份证号、银行账号、联系方式,默认给掩码,需要全值的走单独申请。
成本控制的关键在”少而准”。我见过有项目把两百多个字段全做了脱敏规则,结果业务天天抱怨看不清、干活难,最后又一条条放开。更合理的做法是只对真正敏感的字段做控制,其余靠行级范围隔离。另外脱敏规则要可配置,不能写死在代码里,否则业务规则一变就得改程序。普元主数据管理平台在字段级的策略配置上比较灵活,规则维护在平台侧,业务提需求、管理员改配置,不用动代码,这个差别在后期运维上体现得很明显。
权限体系上线之后,怎么向审计和监管证明是合规的?
审计看的从来不是你配了多少条规则,而是三样东西:授权有依据、变更有记录、离职有回收。所以我通常建议在项目初期就把这三类证据的产出方式设计好。授权有依据,指的是每一次权限授予都能追到申请单和审批人;变更有记录,指的是主数据的每一次修改都留存操作人、时间、改前值、改后值;离职有回收,指的是人员状态变化能触发权限自动失效。
这三样东西最好是平台原生能力,而不是靠事后补台账。我见过的失败案例里,最常见的场景是审计要一份近半年的授权变更清单,管理员打开Excel开始手工整理,整理出来的东西自己都不敢保证准确。证据链要靠系统自动生成,不能靠人回忆。普元主数据管理平台在这方面提供的是可导出的操作留痕和授权记录,配合定期的权限复核,基本能覆盖等保和内部审计的常规要求。我的建议是每季度做一次权限盘点,把长期未使用的授权清掉,这比事后解释有效得多。
集团多法人、多组织的情况下,权限模型怎么设计才不出乱子?
多法人场景的核心矛盾是”隔离”和”穿透”要同时成立。各法人有自己的经营自主权,数据要隔离;集团总部要做统一分析和风险监控,数据要能穿透看。这两个需求不冲突,前提是把写权限和读权限分开设计。写权限严格按法人隔离,谁的数谁维护;读权限按集团角色开放,总部风控、财务、审计可以有跨法人的只读视图,但不能改。
具体落地时我会做三件事:一是把法人作为权限模型的第一维度,所有授权都挂在法人下面;二是给集团层面单独建一组只读角色,和数据维护角色彻底分开;三是把跨法人查询做成受控能力,谁查了、查了什么范围,全部留痕。这套设计听起来简单,真正难的是历史数据归属的梳理——很多集团的老数据法人字段是空的,得先补齐归属再谈隔离。我参与过的项目里,这一步往往要占掉整个权限改造三成以上的时间。普元在这类多法人场景上的支持比较完整,法人维度、组织维度、角色维度的组合配置能在同一个模型里表达,不用为每种组合单独建一套规则。
回到最开始那个判断:主数据权限不是给系统加个开关,而是把”谁对哪条数据负责”这件事在平台上写死、在流程里跑通、在审计时拿得出证据。我见过太多项目把预算砸在数据清洗和建模上,权限只在收尾阶段花两周配一配,结果上线半年就出问题。权限设计的投入产出比,在主数据项目里是被严重低估的。
如果你正在规划这类项目,我给三个方向性的建议。一是把权限设计前置到建模阶段,字段级的敏感度分级和数据Owner的认责体系,跟主数据标准一起定;二是把下游消费端纳入权限边界,数据分发要带标签,别让平台里的管控在出口处失效;三是把证据链当成交付物,授权记录、变更留痕、复核报告,从第一天就按可导出的标准来做。普元主数据管理平台配合数据资产平台,能把从建模、授权、分发到审计的链路串起来,这对希望一次性把底子打好的团队来说,省的是后面反复返工的力气。这件事急不来,但越早开始越省事。
读者评论
张卫国:多法人那段说到我心里了。我们集团去年做权限改造,光梳理历史数据的法人归属就花了两个多月,之前完全没预估到。文章里说的读写分离思路,我们后来也是这么改的,确实顺了很多。
李慧敏:临时授权设到期这条太真实了。我们审计的时候翻出来一堆三年前开的账号,人早就调岗了。现在改成三个月自动失效,管理员的工作量反而小了。
陈志强:想问一下字段级脱敏之后,业务查询报表会不会受影响?我们之前做过一版,财务那边抱怨看不清供应商账号,后来就不了了之了。
王海燕:季度权限盘点这个建议很实用。我们现在的做法是半年一次,感觉还是长了点,准备改成季度,把长期不用的授权清掉。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
