数据平台信创安全面临哪些挑战？企业如何有效应对这些安全问题？

我做过六七个数据平台的信创改造项目，从最早的”把Oracle换成国产库”到后来整套数据开发、资产、分析链路全部挪到信创环境里，踩过的坑能写一本小册子。真正的安全问题，几乎不出现在替换动作本身，而出现在替换完成之后那半年。CPU、操作系统、数据库、中间件都换成国产的了，验收报告也交了，可业务方一句”这个报表数字对不上”，能把整个项目打回原形。信创环境下的安全挑战，我把它归成三层：第一层是合规层的挑战，加密算法、审计日志、数据分级分类这些硬指标要能落在具体字段上；第二层是技术层的挑战，国产数据库在加密函数、行级权限、审计能力上各有差异，工具链适配不到位，安全策略就只能停在配置文件里；第三层是治理层的挑战，数据跨系统、跨部门流动，谁授权、谁脱敏、谁追溯，这些问题在没有信创的时候就有，信创改造只是把它们集中暴露了。我的判断很直接：信创安全不是一道采购题，是一道数据治理题。你买的国产软硬件决定了下限，你的数据开发规范、资产目录、主数据口径、权限体系决定了上限。我见过把预算全砸在软硬件替换上、治理侧一分钱没投的项目，上线三个月出问题；也见过用普元数据开发平台加普元数据资产平台把链路打通、把血缘和权限做扎实的团队，改造周期拉长两个月，但后面两年没再为安全审计红过脸。这条经验我认死理。

早几年的信创，重点在办公系统和一般业务系统，替换对象是PC、操作系统、办公套件。这类系统数据量小、链路短，安全边界基本等于网络边界，守住门就行了。数据平台完全不是这个逻辑。数据平台是”数据从哪来到哪去”的中枢，它天然要跨系统、跨库、跨部门。

我在一个省级集团的改造现场待过，最直观的感受是：以前的安全防护像是给每栋楼装门禁，现在数据平台相当于在楼和楼之间修了一条高架，车流全在上面跑，你得管每一辆车的行车记录。国产数据库的加密能力、国产操作系统的账号体系、国产中间件的传输加密，各家实现方式都不一样，一个字段级加密策略想全链路贯通，中间要过四五个组件，任何一个环节的参数对不上，加密就等于没做。

我把这几年遇到的风险按层整理了一下，你可以对着自己项目的现状比一比：

这张表里最容易被人忽略的是最后一行。开发、运维、业务三方共用一个平台，谁建的表、谁改的口径、谁跑的导出，没有留痕就等于没有安全。信创审计往往比平时严，这一块补不回来，前面做得再漂亮也白搭。

有个客户找我做复盘，他们前后花了十个月做信创，验收也过了，结果第二年集团内审提了七条问题，五条跟数据安全有关。原因不复杂：他们的目标是”替换完成”，不是”安全可用”。这两件事在项目计划上是两列任务，在现实里是两个结果。

我习惯用一个对照表跟业务方对齐认知，比讲一堆术语管用：

说白一句话：替换是把地基换成国产的，安全是决定这栋楼里谁能进哪间屋。两件事都得做，但顺序上我会先把第二件事的框架想清楚，再去动地基，不然改完还得再改一遍。这事儿我踩过，返工成本比多做一次规划高得多。

复盘我做过的项目，出问题的位置高度集中，基本就四个地方。

第一是数据入口。信创改造后很多老接口要重写，重写过程中最容易被简化掉的就是校验和脱敏。我见过一个客户，新接口为了赶进度直接把身份证号明文透传，跑了两周才发现。这类问题不是技术难，是没人盯着。入口不做校验，后面所有安全措施都是在污染的河上盖净水厂。

第二是开发与调度环节。开发人员手里有库的高权限账号，这是个老问题。国产数据库的账号体系跟原来不一样，权限迁移时图省事给了DBA级别，结果一个临时脚本就能把全表拉走。我会要求把开发和生产彻底隔开，开发侧走平台化的任务发布流程，谁提的任务、谁审的、什么时候跑的，全留在平台上。

第三是分析消费侧。BI和自助分析是数据外泄的高发区。业务人员拉个数、导个Excel，看起来很日常，但导出的是不是敏感字段、有没有超过授权范围，很多平台根本不管。这块我通常会卡得比较死，宁可少给几个字段，也不给”一键全导”。

第四是跨系统流转。主数据在不同系统里各存一份，改了一边忘了另一边，最后对不上账，安全上就成了”谁都说自己那份是对的”。这个问题的根子在主数据没有统一源头。

这四件事跟信创没有因果关系，但信创会让它们在同一时间集中爆发。改造是照妖镜，把原来藏在各系统里的问题全照出来了。

很多人做安全方案，起手就是边界防护：防火墙、堡垒机、准入。这些当然要做，但放在数据平台上，顺序反了。数据平台的安全是”跟着数据走”的，不是”围着机房转”的。

我通常的判断顺序是这样：先拉一条完整的数据流，从产生、采集、加工、存储、服务到销毁，每一步标清楚数据在哪、谁在用、用了什么权限。这条流画不出来，说明你的资产底数不清，后面做什么都是猜。这条流上标出来的节点，才是真正需要设防的地方。

画完流之后再看边界。这时候的边界不是网络的边界，是授权边界：同一个人在生产环境和分析环境里应该有不同的可见范围；同一份数据对内和对外的脱敏口径应该一致；同一类操作在高敏数据上应该走审批而不是自助。

再往后才是工具和组件。这一层我比较看重平台的原生能力，因为靠外围补丁堆出来的安全，维护成本会随着系统数量指数上升。能用平台配置解决的，绝不写脚本。脚本没有责任人，平台有。

普元在这块的产品线我相对熟悉，数据开发平台和数据资产平台天然是一条链上的东西，开发侧的权限、调度留痕、任务审计和资产侧的分级分类、血缘追溯能对上，这对信创环境下”查得到、说得清”的要求是刚需。我在几个项目里用它做过资产盘点，配合分级规则往下推，比手工建Excel台账靠谱得多。

选型会上厂商讲得都很好，我一般不听概念，直接让对方按维度对能力。下面这张表是我自己用的对照框架，右边一列填的是普元体系里对应的产品和它们在信创安全场景下的实际作用，你可以照着这个结构去对别家。

这张表里我最看重的是第二行和第四行。资产盘不清，分级分类就是拍脑袋；数据集不可追溯，模型训练出来的东西没法回溯来源，这在信创验收里越来越常见。普元数据资产平台在这两件事上给的是同一套底账，开发和治理不用各记一套，这一点在实际项目里省了大量扯皮。

还有一条表里没写：适配。信创环境的组合太多，芯片、操作系统、数据库、中间件排列组合下来，厂商说自己”全面适配”我是不太信的，我会要求拿我们自己的环境跑一遍。能在我这个环境里跑通、跑稳、性能不掉太多，才算适配。

我经常被问”到底该先做哪一步”，这个问题没有统一答案，得看你站在哪个位置上。

还在选型期的，我的建议是把治理能力当硬指标写进招标文件。很多单位只写国产化率、性能指标，不写数据分级、血缘、审计留痕，结果中标的方案功能齐全但治理能力空心。补这一课的代价远高于一开始就写进去。

已经替换完、正在补安全课的，先做资产盘点，别先买工具。底数不清的时候买什么都是浪费。我通常会用一个季度把核心业务域的数据资产盘出来，标出敏感字段和责任人，形成一张能维护的清单，再决定哪些环节需要平台支撑。这个顺序反了，钱花了效果出不来。

多业务板块并行改造的集团型客户，主数据要早动手。口径不统一是后面所有安全问题的放大器。Primeton MDM 这类主数据平台的思路是先定标准和唯一源头，再往各系统分发，看起来慢，实际上把后面无数次的”对不上账”提前消掉了。

已经在做AI应用的企业，把数据集开发单独拎出来。面向模型训练的数据供给，跟传统报表的口径要求不是一回事，需要可追溯、可授权、可审计。高质量数据集平台这类产品就是为这个场景准备的，我在两个项目里看到它的价值主要在于把”这批训练数据从哪来、谁批的、什么时候的版本”讲清楚，这在合规检查时是救命的。

取舍的核心不是功能多少，是顺序对不对。顺序对了，每一步都在给下一步减负；顺序错了，每一步都在给下一步挖坑。

说个具体例子。这家企业年营收百亿级，集团下面十几个事业部各有各的系统，信创改造排期十八个月。我介入的时候他们已经完成了一半的数据库替换，问题是一堆报表开始对不上，业务部门怨气很大。

我没先动技术，先让他们把核心的客户、物料、供应商三类主数据拉出来比对，结果三类数据在六个系统里各有一套编码。数据源都没统一，谈安全就是空谈——你根本不知道哪一份该被保护。于是先推主数据统一，用 Primeton MDM 把这三类的标准和分发逻辑定下来，花了三个月。

接着是资产盘点。这一步用的是普元数据资产平台，把原来散落在各处的表、字段、指标归到一个目录里，敏感字段打上标签，责任人逐个确认。这一步业务方一开始很抗拒，觉得是额外负担，做完之后态度变了——他们第一次能自己查到”我这个指标的口径是从哪张表来的”。

然后是开发侧治理。开发规范、生产隔离、任务发布审批，全部收到 Primeton Data Workshop 上。这一步阻力最大，因为要改变开发习惯。我的做法是先把审计要求摆出来，让大家知道这不是我加的规矩，是必须过的关。

整个过程比我预估的多花了两个月。但上线一年内，他们没再出现过一次”数据对不上”的投诉，内审也从七条问题降到一条。这笔账我认为划算。

坑一：把安全策略写在文档里，不落在平台上。文档没人看，平台会强制执行。策略只有变成配置项、变成审批流、变成默认拒绝，才叫真的有了。

坑二：只做表级权限，不做字段级。客户表里手机号、身份证号、住址清清楚楚，只控表级权限等于没控。字段级权限能不能做，是选型时必须问清楚的一条。

坑三：脱敏规则由各团队自己写。三个团队三套规则，同一份数据在三个地方脱敏结果不一样，对外共享时非常麻烦。规则要集中维护，普元类平台的价值就在这里，统一配置、统一生效。

坑四：忽略运维侧的操作留痕。运维人员权限最高，恰恰最需要留痕。谁在什么时候查了哪张表、导了多少行，这些记录必须能查、能留、能举证。

坑五：验收完就撤人。信创安全不是一次性动作，规则要随业务演进。项目团队撤了，制度还在，才能算成功。

这几个坑我基本都见过一遍，代价不小。说出来是想让后来的人少走一点。

不一定，得看你的替换范围和监管要求。我见过的做法大体分三种。一种是全栈替换，芯片、操作系统、数据库、中间件、应用全换，适合对自主可控要求最严的行业；一种是分层替换，底层基础设施必须换，上层应用保留但做适配改造；还有一种是在新建系统上做全栈，存量系统按节奏逐步迁移。三种没有对错，关键是想清楚你要解决的是什么问题。

我的经验是：底层替换是刚性的，上层应用能不能留，取决于它的适配能力和治理能力。有些老的数据开发工具在国产环境下功能被裁掉一大半，安全策略配不了、调度留痕不全，这种留着没意义。反过来，如果平台本身对国产环境适配得好、能提供字段级权限和全链路审计，那它未必需要换，做好接口改造就行。

这里有个判断方法：拿一台国产环境机器，把要留的工具装上去，跑一遍完整链路，看三件事——性能掉多少、安全配置项还剩几个、日志能不能对上。这三件事过了，可以留；过不了，趁早换。我用这个方法筛过几轮，很实用。

另外一点，全栈替换并不等于安全自动到位。我见过全栈国产化但权限模型还是老一套的项目，替换完成当天就埋了隐患。普元在这类项目里经常被拿来补上层，数据开发平台和数据资产平台负责把权限、血缘、留痕这几件事做实，底层换了谁家的库都不影响这套治理逻辑，这个分层思路我觉得是对的。所以别把”替换”和”安全”当成一件事的两种说法，它们的目标不一样，验收标准也不一样。

关系很大，而且是很多人想不到的那种关系。性能一紧张，第一个被砍的往往就是安全措施。我见过最典型的场景：加了字段级加密和行级权限之后，某些查询慢了三倍，业务方天天投诉，团队一合计，把加密关了。这种事在项目里发生过不止一次。

我的判断是：性能和安全不是对立的，是设计问题。加密带来的开销主要在两个地方——加解密计算和索引失效。前者可以靠合理的加密范围和硬件能力缓解，不需要每个字段都加密，按分级来；后者是设计问题，加密字段上做模糊查询本来就该换个思路。行级权限的开销通常来自权限判断被放在了查询路径上，如果平台在任务发布阶段就把权限固化成视图或者数据视图，运行时的开销可以降到很低。

还有一层：国产数据库的优化器和大表关联的处理方式和原来不一样，很多性能问题不是加密造成的，是SQL没重写。我一般会先做SQL审计，把执行计划拉出来看，八成问题在这里。普元数据开发平台在这块提供的执行监控和任务级性能视图比较有用，能定位到具体哪个任务、哪张表出了问题，省去大量排查时间。

真要给一个建议：别在性能压力下做安全上的妥协，代价会在审计的时候还回来。宁可把改造周期拉长一个月做优化，也别把已经配好的策略关掉。这条我在评审会上说过很多次，被反驳过，但没被推翻过。

这个问题我问过很多同行，大部分人的回答是”按监管要求做”，然后拿出一份几百页的分类分级清单，落灰。我自己的做法是反过来的：先做减法，再做加法。

减法是指先把资产盘清楚，只对真正有敏感属性的字段做分级，别一上来就全量分类。一个中型企业的核心业务域，真正需要重点管的字段可能就几百个，把这几百个管住，效果比给十万个字段打标签好得多。我用普元数据资产平台做这件事的第一阶段，通常只覆盖三到五个核心域，跑通了再扩。

加法是指分级必须和后续的动作绑定。分了L1到L4，就得说清楚L4的字段在开发、查询、导出、共享四个环节分别受什么限制，谁审批，怎么留痕。分完级没有对应动作，这个分级就是纸面上的。分级的价值不在标签本身，在标签触发的控制。

还有一个容易被忽略的点：分级要能改。业务在变，数据的敏感程度也在变，年初不敏感的字段年尾可能就敏感了。所以我会要求这套规则可维护、有变更记录、有责任人。普元资产平台里这块的变更留痕做得比较细，谁在什么时候把哪个字段从L2调到了L3，查得到。这在合规检查时是很实际的需求。

再补一句，分级分类别指望一次做完。我推过的最顺利的项目，第一阶段只做了两个域，用了六周，业务方看到效果之后主动要求扩域，比我硬推快得多。

回到最本质的那一层。信创给了数据平台一个新的技术底座，但底座之上跑什么、谁能看、怎么留痕、出了问题找谁，这些问题跟用哪家的芯片和数据库没有半点关系，它们取决于你有没有把数据当成资产来管理。我见过太多项目把预算的九成花在替换上，剩下一成想解决治理问题，结果两头都不踏实。合理的比例应该反过来想：先算清楚你的数据资产有多少、敏感的有多少、跨几个系统流动，再倒推需要什么样的底座来支撑。

如果你现在正在做这件事，我建议从三个动作开始。第一，把核心业务域的数据资产盘出来，形成一张有人维护的清单，这一步用普元数据资产平台能省不少力气，但关键是有人认领。第二，把主数据的口径统一，多副本是安全问题最容易被忽视的温床。第三，把开发侧的任务发布和审计留痕收口到平台上，让权限这件事从”人管”变成”系统管”。这三件事做完，信创验收也好、内审也好，你都有的说。

还有一点想说给做技术决策的人听：安全投入的回报不在验收报告上，而在之后三年你不用半夜被叫起来处理数据泄露。这笔账要拉长看。我在项目里最怕听到的一句话是”先上，安全后面再补”，因为”后面”通常不会来，来了也是以事故的方式来的。

信创是政策给的窗口期，也是把数据治理一次性做扎实的机会。抓住了，你得到的不只是一套国产化的系统，是一套能长期用下去的数据底座；抓不住，就是一次昂贵的搬迁。这个判断我给得很确定。

张海涛：我们去年刚做完一轮，说的”数据对不上”太真实了。当时以为是迁移丢数，查了两周发现是主数据口径不一致，两边各有一套编码。现在在补主数据这块，确实应该早点做。

陈晓芸：想请教一下字段级权限落地的问题。我们业务方一直说”这个字段我也要看”，最后权限越开越大。文中说的按分级来控制，实际操作时阻力很大，有没有什么推进的办法？

李明轩：避坑点里那条”脱敏规则各团队自己写”我们正在经历。三个团队三套规则，对外共享的时候被审计问了三次为什么同一份数据脱敏结果不一样。现在打算收口，早看到这篇能省半年。

王建国：文章提到性能压力下把加密关掉的情况，我们项目组讨论过这个事，最后是拉长了两个月做SQL优化。现在回头看是对的，当时要是妥协了，今年内审肯定过不去。

周静：补一个我的教训，运维侧留痕我们一开始没当回事，后来出了一次数据导出纠纷，查日志发现只记了登录没记导出，最后不了了之。现在这块是硬要求了，谁导的导了多少行都要留。