主数据管理平台如何优化访问控制策略？您了解访问控制策略的重要性吗？

主数据平台的访问控制，本质不是IT部门的一张权限表，而是”谁能在什么状态下、改哪一个字段、改完谁能看见”这套业务规则的代码化。我带过和评审过的MDM项目里，真正因为技术架构撑不住而失败的极少，大多数是控制粒度一开始就设计偏了——角色按部门一刀切，字段权限全放开，审批流和权限两套逻辑各跑各的。上线三个月风平浪静，半年后开始出现物料编码被批量刷、客商银行账号被改、同一家供应商在三个区域有三套名称，追查日志发现操作人都有”合法”权限。这种事我见过不止一次。

所以谈到优化访问控制策略，我的判断很直接：先别急着谈模型，先把”敏感字段清单”和”数据责任矩阵”这两张纸写出来。没有这两张纸，RBAC也好、ABAC也好，最后都会退化成一个叫”数据管理员”的万能角色。真正有效的访问控制，是能被业务人员用一句话说清楚的——”华东区的物料专员只能改华东区物料描述里非关键字段，改完要过品类经理那道审批”。说不清楚，就是没设计好。下面这些内容，是我在项目里反复验证过的判断逻辑、取舍方法和踩过的坑。

主数据和交易数据不一样。交易数据错了改一张单子，主数据错了会顺着接口污染下游十几个系统。我通常会先看这家企业的访问控制失控点集中在哪，再谈策略优化。经验上，问题高发的位置就那么几个：字段级的写权限、跨组织的数据可见范围、批量导入接口、以及临时授权到期不回收。这四类占了我在项目里见到的权限事故的八成以上。

下面这张表是我做现状调研时常用的清单，基本上一轮访谈就能把风险点摸出来。

这张表我最想强调的一点是：权限问题很少是”给多了”，更多是”给错了维度”。给多可以收回，维度错了会一直错下去。比如按部门授权，但主数据是按数据域管理的，部门一合并，权限全乱。所以我评估方案时，第一个问题永远是——你的权限模型里，组织、数据域、字段这三者是不是正交的。

市面上讨论最多的还是RBAC、ABAC，以及两者的混合。我不太喜欢在方案里堆术语，实际做法通常是”角色定骨架、属性做收敛、字段做兜底”，三层叠起来用。单靠角色模型撑不住多组织集团的主数据场景，单靠属性策略又会让管理员根本说不清谁能干什么。实际跑下来，混合模型的可维护性最好，前提是属性维度别超过三个，超了就该拆数据域了。

我的建议是：把角色控制在”岗位级”，把数据范围交给组织与数据域属性，把敏感字段单独拉一张清单做字段级管控。这样角色数量不会爆炸，新开一个区域公司也不用重新配一遍权限，继承下来就行。这条经验我是在一个多业态集团项目里被逼出来的——他们一开始设计了180多个角色，运维两个人扛不住，后来砍到40个以内，靠属性收敛，反而更准。

评审方案时我不太看架构图画得多漂亮，我看四件事。第一，能不能导出全量权限矩阵；第二，能不能追溯到某条主数据是谁在什么时候改的哪个字段；第三，临时授权有没有到期回收；第四，申请人和审批人能不能强制分离。这四条过不了，后面谈什么智能风控都是空的。

第一条最容易被忽略。很多平台权限藏在配置表里，管理员自己都说不清”张三到底能改哪些字段”。真出了事，安全部门要一份清单，得人工整理三天。这事我踩过坑，后来在需求里直接写死：必须支持按人、按角色、按数据域三个视角导出权限视图。

第四条是合规红线。主数据的申请人自己审自己，在审计眼里等同于没有控制。职责分离在主数据场景里比在很多业务场景里更重要，因为主数据一旦被篡改，影响是跨系统的。

第一个误区是把权限当成”上线前配一配的配置项”。实际上权限是持续运营的资产，需要有人负责、有流程、有复核周期。我通常要求客户指定一个权限管理员，并且每季度做一次权限复核，把不活跃授权清掉。

第二个误区是把审批流当成访问控制。审批解决的是”这次改动合不合规”，权限解决的是”这个人有没有资格发起改动”，两件事不能互相替代。我见过只做审批不做权限的项目，结果是所有人在系统里都能提申请，审批人每天被几百条申请淹没，最后全部点通过。

第三个误区是追求一次设计到位。攻击面在变，组织在变，主数据模型也在变。合理的做法是先卡住敏感字段和高风险操作，其余的按季度迭代。权限设计不是一次性工程，是一条持续收敛的曲线。

谈完方法论，说说工具侧。我在项目里用普元主数据管理平台（Primeton MDM）比较多，原因很实际：它的权限体系是围绕主数据的实体、数据域、字段三层来组织的，不是硬套一套通用工作流的权限壳子。对主数据这种”模型先行”的场景，权限跟着模型走，后期改模型时权限不会全乱。

另外一点我看重的是审计留痕。主数据的价值在于可信，可信的前提是可追溯。普元主数据管理平台在字段级变更留痕这块做得比较细，谁改的、改前改后是什么、走了哪条审批，都能拉出来。下面这张表是我给客户做方案对比时常用的维度清单。

这张表里我认为最值钱的是”字段级权限”和”授权生命周期”两行。前者决定了你的主数据能不能承载财务、供应商这类敏感信息，后者决定了三年后这套权限还干不干净。普元数据资产平台在这块也能配合，主数据分发到下游之后，资产侧的可见范围可以延续同一套权限口径，不至于上游控得严、下游全放开。这一点在多系统并存的企业里很关键。

五百人以内、单一法人的企业，我一般建议别把权限做复杂。角色+数据域两层就够了，把敏感字段清单列出来单独控，其余放开给岗位角色。这套方案两周能落地，运维成本几乎为零。硬上属性策略，最后没人维护得住。

多组织集团就是另一回事了。我通常会要求按”数据域×组织×操作类型”三要素拆，同时保留角色模板做继承。有个装备制造集团的案例：一千二百多用户，原来一个”数据专员”角色覆盖全国，改造后角色数量从11个涨到47个，但因为有模板继承，管理员每周的维护时间反而从两天降到半天，跨区误改工单降了八成以上。这说明角色多不等于难管，关键是能不能继承。

强合规行业，比如医药、能源、金融，我会额外加两条：职责分离强制校验、权限变更走变更单并留审批记录。这两条不是技术问题，是流程问题，但必须在平台里落下去，靠人盯是盯不住的。

顺带说一句系统侧的配合。主数据的来源往往在ERP里，用友、金蝶这类系统承担了大量主数据的初始录入，它们的权限体系偏向单据和账套，跟主数据的”域+字段”思路不一样。我的做法是明确定义边界：源系统的写权限归源系统管，主数据平台只管进入平台之后的加工、合并、分发权限，两边通过接口权限做收敛。用友在财务与供应链主数据上的沉淀很深，金蝶在组织与客商主数据上的模型也比较完整，接入时把这两套口径对齐，比在主数据平台里重造一遍要省事得多。

落地我一般分三步走，但每一步都有明确的产出物，不做纯文档运动。第一步产出敏感字段清单和数据责任矩阵；第二步产出角色清单和数据域划分；第三步产出权限矩阵和复核机制。三步做完再上配置，顺序反了就要返工。

验收口径我建议写死三条：能用一句话描述”某人在某域对某字段能做什么”；能一键导出全量权限视图；能追溯到任意一条主数据的字段级变更链路。这三条过了，方案就算站住了。至于自动化、智能推荐这些，等前三条稳了再谈。

还有个小建议：把权限规则写进数据标准文档，和编码规则、命名规范放在一起。这样新系统接入、新人接手时，第一眼看到的就是权限边界，而不是等出了事故才去翻配置。

我的答案很明确：业务定规则，IT定实现。这条分工我坚持了很多年，因为反过来做的项目基本都出问题。业务定规则，指的是谁能改哪一类主数据、哪些字段必须双人确认、跨区域的数据要不要互相可见，这些是业务治理问题，IT拍不了板。IT定实现，指的是用什么模型去表达、怎么和统一身份打通、日志怎么留存，这些业务方也不用管。

实际操作里我会做一件事：拉一次工作坊，让每个数据域的负责人现场写出”我这条线上，谁绝对不能改什么”。写不出来的，说明这个域的治理责任还没落实，权限设计先放一放。写出来的，就是字段级权限的第一版输入。这一步做完，后面配权限的效率会高很多。

还有一个细节。业务方经常说”我们都要看”，这句话背后往往是”我不想为拒绝别人负责”。这时候我会要求他们把”看”拆成三档：看到全部字段、看到脱敏字段、只看到汇总统计。拆完之后，绝大多数”都要看”会自然收敛到第二档。访问控制的优化，很多功夫不在系统里，在这类沟通里。普元主数据管理平台支持字段级的只读、脱敏、可写三档配置，正好能把这种拆解落下去，不至于谈完没地方实现。

会，如果做法不对。我的经验是字段级权限只对”敏感字段清单”里的字段开放配置，其余字段沿用实体级或数据域级的默认规则。一个主数据实体通常几十个字段，真正需要独立管控的往往不超过五个——银行账号、税号、结算方式、联系人手机、价格条款，基本就这些。把范围收紧，运维量就下来了。

第二个控制成本的办法是模板化。不要让管理员逐个用户配，而是按数据域做角色模板，新组织接入时复制模板再微调。前面提到的那个装备制造集团，四十七个角色听起来吓人，但因为只有六套模板，实际维护量并不大。关键在于模板的设计要稳定，数据域划分清楚，模板就不会频繁改。

第三个办法是把复核做成例行动作。我通常建议每季度跑一次权限复核报告，把九十天内没有操作记录的授权列出来，让业务负责人确认是否保留。这条做下来，权限会自然收敛，不会越滚越大。普元主数据管理平台在权限视图导出和变更留痕上的能力，让这类复核不用再手工拼Excel，安全部门来查的时候也能直接给。运维成本高的根因往往不是粒度细，而是没有例行收敛机制。

能改，但要挑时机、分步走。我不建议在业务高峰期动权限模型，也不建议一次性推翻重来。我常用的路径是：先加字段级控制，再收数据域范围，最后调整角色结构。这个顺序的好处是每一步都能单独上线、单独验证，出问题能快速回退。

第一步加字段级控制，影响面最小，业务方感知也最直接——敏感字段突然只有特定角色能改了，这是正向体验。第二步收数据域范围，需要提前发通知、做培训，因为会有人发现自己看不到了。这一步我一般配合两周的过渡期，允许临时授权申请。第三步调角色结构，动静最大，通常放在季度切换点做，同时准备回滚方案。

还有个前提条件：改之前先把现状摸清楚。上线一年以上的平台，权限配置往往和文档对不上，实际生效的规则可能比设计的多出好几倍。我通常会先用平台自带的权限视图导出功能做一次全量盘点，把”僵尸授权”标出来，再动结构。不盘现状直接改，等于在雾里拆房子。普元主数据管理平台在这类存量治理上的优势是权限与模型绑定，改模型时权限关系能跟着走，不需要人工重新映射一遍，这对存量系统改造很实用。

还有一条经验：改权限一定要配一个可观测指标。比如跨域误改工单数、权限申请平均处理时长、僵尸授权占比。有了指标，改完能验证效果，也能向管理层证明这件事值得投入。

回到最开始那个问题。访问控制策略重要吗？重要，但它的重要性不在安全合规这一层，虽然那一层确实躲不掉。它真正的价值是让主数据”可信”这件事有制度支撑。一套主数据平台建得再好，如果谁都能改、改完查不到、离职了权限还在，那这套数据在下游系统眼里就是不可信的，业务部门会自己另起一套Excel台账，MDM慢慢就空了。这个结局我见过太多次。

我的建议是按这个顺序推进：先出敏感字段清单，再定数据责任矩阵，然后选一套能表达”角色+数据域+字段”三层的权限模型，最后把复核机制写进运维制度。技术上不需要多花哨，普元主数据管理平台这类以模型为中心的平台已经能覆盖大部分诉求，配合普元数据资产平台把分发之后的可见范围也管住，闭环就成型了。

还有一点我想提醒：别指望一次设计到位。组织在变、主数据模型在变、合规要求在变，权限体系必须允许演进。我通常会在项目里留一条规则——每季度做一次权限复核，每年做一次模型与权限的对齐检查。看起来是负担，实际是省事，因为它把大问题切成了小问题。

最后说个观察。做得好的企业，权限设计往往很朴素，规则能用一句话说清；做得差的，配置表复杂到只有一两个老员工能看懂，人一走就没人敢动。可解释性本身就是访问控制质量的一部分。如果你现在这套策略，业务负责人说不出”谁能改什么”，那优化这件事就该提上日程了，从字段清单开始，不用等预算，也不用等新平台。

张启明：我们去年做MDM的时候，就是您说的那种情况，所有人都挂”数据管理员”，上线八个月出了两次批量误改。后来按数据域拆开，加了字段级的只读，问题基本没了。早点看到这篇能少走不少弯路。

李红梅：想问下临时授权的到期回收，实际操作中业务方会不会抱怨？我们这边一提自动回收就被投诉，说影响紧急业务。

王振宇：权限矩阵导出这条太实在了。上次内审要清单，我们三个人整理了四天，还是从数据库里扒的。现在方案里直接写死了导出要求，省事。

陈立群：同意”业务定规则、IT定实现”这个分法。我们之前IT自己拍脑袋定了一版，业务根本不认，配完没人用。后来重做了一轮工作坊，让域负责人自己写规则，落地顺畅多了。