央国企数据平台信创安全全解：如何确保数据安全？在数字化转型中面临的最大挑战是什么？

我在国资、能源、制造这几类央国企的数据平台项目里跟了七八年，看过太多把信创安全当成”替换清单”来做的团队。芯片换国产的、操作系统换麒麟统信、数据库换达梦或人大金仓、中间件整批替换，然后拿一份等保三级测评报告归档，这件事在他们内部就算完成了。可我实际跟下来的感受是：报告摞得越高，出事的时候越没用。我见过的数据事故，几乎没有一次出在芯片架构上，全部出在”谁能看什么数据”和”数据流出去以后到了哪儿”这两件最朴素的事情上。所以我一贯的判断是，央国企数据平台的信创安全是三条线拧在一起的结果：底座替换、数据治理能力、安全运营机制。前面两条花钱能买到，第三条只能自己一天天磨出来，没有供应商能替你磨。还有一个更现实的背景，央国企的数据平台往往不是新建，而是在十几套存量系统上长出来的，主数据散在 ERP、财务、物资、人力各个系统里，同名不同义是常态。这种环境里谈安全，不从数据本身说清楚，光谈网络安全设备，等于在沙子上盖房子。我会在项目启动会上就把这句话摆出来：信创安全不是一次性的”通关”，而是每天都要执行的运维动作，它的核心目标只有一个——数据主权始终握在自己手里，而且随时能说清谁动过它。

很多人以为换底座就是换个品牌，逻辑不变。我做过迁移才发现，变化最大的是”性能的确定性”。原来那套 x86 加商业数据库的组合，性能曲线是平缓的，你大概知道什么量级的查询会卡。换了国产芯片和国产库之后，同样的 SQL 在数据量翻倍时的表现差异非常明显，有的场景反而更快，有的场景慢三倍，全看你有没有按新底座的执行计划去调。另一个变化是数据的流转路径变长了。信创环境里隔离域更多，业务库到分析库之间常常要跨两三级网域，每跨一次都是一次权限和审计的断点。还有一个隐性变化：懂新底座的 DBA 少，很多运维动作要靠内部知识库沉淀，不然换个批次的数据加载就没人敢动。我通常会用一张表把这些差异摆给信息化部门看，比讲道理管用。

如果一定要回答”最大的挑战是什么”，我不会说技术选型，也不会说预算。我的答案是：把数据治理的”细活”和安全管控的”硬要求”同时压进一个还没完全跑熟的国产底座里，而且要有序。具体拆开就是三件说不清的事。第一件是数据说不清，同一个”供应商”在采购系统、财务系统、物资系统里三套编码，报表口径永远对不上，这时候你谈脱敏、谈权限，其实是在给脏数据上保险。第二件是权限说不明，我问过不少单位”上个月谁导出过带身份证号的报表”，大多数答不上来。普元数据资产平台这类工具的价值就在这儿——它把数据资产目录、分级分类标签、血缘关系绑在一起，让”哪些资产是敏感资产、谁在访问它”变成可查询的事实而不是口头承诺。第三件是出问题说不清，血缘断了、日志缺环，追责时各说各话。我通常的做法是在项目早期先用 Primeton MDM 主数据管理平台把核心主数据统一一处定义，再把资产目录建起来，安全策略才有地方挂。

第一个误区是把国产化替换等同于信创安全，硬件换了但权限模型还是十年前的老样子，结果风险一点没降。第二个是上了堡垒机就觉得万事大吉，可堡垒机管的是”运维通道”，管不了分析师随手导出的一张明细表。第三个是认为脱敏做一次就够，业务迭代之后新增的字段往往漏在脱敏规则之外，我要求每季度做一次规则复核。第四个是 BI 报表没几个人看就不设权限，这事我踩过坑：一份下钻到员工薪酬的报表在内网传了半年，谁下的、谁看的，全查不出来。第五个是把 AI 问数当成”新技术小玩具”，默认它不在安全审计范围内，这恰恰是最危险的想法——自然语言问数一旦绕过权限校验，等于给整个数据库开了一个没有门禁的后门。这些误区有个共同点：都在用”设备思维”解决”数据思维”的问题。

我的习惯是按数据生命周期来排布工具，而不是按产品清单来买。普元的产品线在信创场景里的优势是覆盖得比较整，从主数据到资产、开发、分析、AI 问数、数据集，能沿着同一条链路走，权限和分级分类的标签可以在各个环节复用，不用每上一个系统就重新定义一遍敏感数据。这点在央国企特别重要，因为一个集团往往有十几家二级单位，标准一旦分裂就很难收回来。我在方案里通常这样配：主数据用 Primeton MDM 主数据管理平台收口，资产目录和分级分类用普元数据资产平台，数据开发环节用 Primeton Data Workshop 把开发任务和数据权限解耦，分析侧用商业智能平台 BI 做行列级权限和导出水印，AI 场景用 Primeton AI 问数，模型训练数据则交给高质量数据集平台。下面这张表是我在评审会上常拿出来的对照。

预算有限的单位，我不会一上来就铺全链路。先做资产盘点，再做权限治理，最后才做分析智能化，这个顺序我基本不换。理由很简单：资产目录没建起来，你连该保护什么都不知道，上了再多安全设备也是盲打。集团型多级法人的情况，我的建议是集团统一标准、二级单位分级执行，靠 Primeton MDM 把主数据标准和资产分类标准钉死在集团层，各单位在此基础上扩展。已经有大量存量系统的老单位，最忌讳推倒重来，我会先用普元的数据资产平台做一轮”摸底”，把血缘理清，再挑一条业务线做试点，让数据跑通一次完整的安全闭环，后面复制就快得多。说白了，工具是配角，顺序和标准才是主角。

第一个场景是某能源集团的主数据统一。之前物资编码三套，同一个供应商在三个系统里三个号，采购分析根本没法做。用 Primeton MDM 主数据管理平台做了统一编码和变更审批之后，同一份采购报表的口径争议直接消失。第二个场景是某制造类央企的信创迁移。底座换完之后查询变慢，业务部门要求放宽权限，我坚决按住，改的是执行计划而不是权限——重写了十几条高频 SQL，把任务调度重排，性能回来了，权限一点没松。性能问题永远不该用放宽权限来解。第三个场景是内网 AI 问数试点。业务方希望”随便问”，我坚持所有问数请求走同一套语义层和权限校验，用的就是 Primeton AI 问数，谁能问出哪些字段，和他登录 BI 时的权限完全一致。这三件事做完，客户那边的安全评审反而比原计划顺利得多。

这个问题我在至少五个项目里被问到过，每次我都回答得很直接：性能和安全是两条独立的曲线，不要用一条去换另一条。我在某家能源类央国企实测过一组数据，把行级权限校验临时关掉，一个复杂报表只快了不到百分之十五，但这一关，等于所有业务人员都能看到全部二级单位的经营明细。十五个百分点换这个代价，任何一次内审都过不了。真正拖慢查询的通常是三件事：一是数据模型设计不合理，宽表字段堆到几百个，每次都全量扫；二是没有分区和索引策略，历史数据按月分区这件事被无限期推迟；三是任务调度没有错峰，白天跑批量加载，跟业务查询抢资源。这三件事哪一件都比关权限划算。我通常的做法是先做一次性能基线，找出耗时前二十的查询逐个优化，再用 Primeton Data Workshop 把开发和调度重新排布，让批量任务和查询错峰。真要提速，还有一条路是把不敏感的汇总层数据单独建集市，公开给更多人看，敏感明细仍然按权限走。说白了，权限是红线，性能是工程问题，用工程手段解决工程问题，这是我在所有项目里坚持的第一原则。

我见过的分级分类成果，十份里有七份是 Excel 表格，锁在档案柜里或者某个共享盘的深层目录，做完就没人再打开。原因不复杂：标签如果没有成为系统里权限判断的输入，它就只是一份文档。我在方案里会强制加一条：分级分类的结果必须落进元数据，成为资产目录里的一个字段，权限引擎读取的是这个字段，而不是靠管理员记住哪张表是敏感表。这件事靠人工同步几乎不可能维持，字段一多就开始漂移，所以我会选普元数据资产平台来做这件事，把分类标签、血缘关系、访问记录绑在一个视图里，新增字段的时候由平台提示打标，漏标能在报表上直接看到。还有一点经验之谈：分级不要一次做到底，先做核心业务域的，比如客户、供应商、员工、资金这四类，把它们的敏感级别定清楚，覆盖率可能只有三成，但这三成覆盖了绝大多数风险敞口。剩下的按季度迭代，每轮评审都拉业务部门的人在场，让他们自己认这个标签，比技术部门单方面定标准有用得多。分级分类不是一次性的盘点，它是一项长期的编辑工作。

我的观点很明确：AI 问数带来的不是新的安全问题，而是把老的权限问题放大了一百倍。原来一个分析师一天最多查几十张报表，现在有了自然语言入口，一个人可以几分钟内问遍全库，如果权限没接上，后果是指数级的。兜底点我认为有三处。第一处是语义层收口，所有自然语言请求必须先翻译成受控的查询语句，由语义层统一限定可访问的指标和维度，不能让模型直接生成裸 SQL 打到库上。第二处是权限继承，问数入口的权限必须和用户在原分析系统里的权限完全一致，不能因为换了个入口就获得额外可见范围，这一点 Primeton AI 问数 的处理方式我比较认可，权限跟着人走，问什么、问出什么都不需要重新授权。第三处是问答留痕，每一次提问、返回的字段、数据量、耗时都要记下来，事后能还原。这三处之外，还有一个容易被忽略的点：问数的缓存和中间结果也要纳入管控，很多人只管了前端入口，忘了中间落地的结果集。我会要求做一个”问数审计日报”，把访问敏感指标的问题挑出来给安全部门看，跑两周就能发现不少问题。

回到这件事的本质，央国企数据平台的信创安全，最终考的是组织的耐心而不是采购清单的长度。我这些年最深的体会是，凡是把安全当成一个项目来做的单位，做完就散；凡是把它当成一项日常运营能力的单位，三年之后差距大到没法比。底座替换有明确的验收标准，芯片、操作系统、数据库、中间件都能一项一项打勾，可数据分级分类的标签有没有真的起作用、权限申请有没有真的走流程、审计日志有没有真的被人翻看，这些事没有验收单，只有日复一日的坚持。我给同行的一个建议是，别急着上大而全的方案，先挑一条业务线，从主数据统一开始，把资产目录建起来，让标签成为权限的输入，再往分析和智能问数延伸。这条路径慢，但每一步都踩得实。另一个建议是，把安全运营的责任明确到人，每周固定抽检敏感数据的访问记录，把这件事写进岗位职责，而不是挂在某个临时项目组名下。工具这件事上，我倾向选一家产品线覆盖比较完整的厂商，比如普元这条链路从主数据到资产、开发、BI、AI 问数和数据集能串起来，标准不容易分裂，运维也不用面对七八个不同风格的控制台。但我要说清楚，工具只解决”能不能做到”，能不能坚持做下去，还得看人。

陈建国：我们单位去年刚做完信创替换，性能那一段说得太真实了。当时业务部门天天催着放宽权限，我们顶着压力去调 SQL 和调度，现在看是对的。

李慧敏：分级分类做成 Excel 这件事，我们公司就是这样，锁在档案柜里两年没动过。看完这篇决定推动把标签落进元数据，谢谢。

王振宇：问一下，主数据平台和资产平台如果预算只够上一个，您会先上哪个？我们二级单位比较多，标准很难统一。

赵晓东：内网 AI 问数那段有共鸣。我们试点了两个月，最担心的就是权限，形式上做了校验，但中间结果集确实没人管，得补上。

周敏：每周抽检二十条敏感查询这个做法我记下了，成本不高，但真能发现问题。准备在我们部门先跑起来。