央国企数据平台信创安全解析：如何在数字化转型中保护企业数据安全？是否你的企业也面临同样的安全挑战？

这几年我参与过十几家央国企数据平台的信创方案评审和上线陪跑，看下来有个共性：大家把信创当成一张替换清单——数据库换国产、中间件换国产、操作系统换国产，清单勾完就算交差。可真正出问题的地方，往往不在这一层。数据平台的安全底座，说白了就三件事：底座自主可控、数据流转可管、使用行为可审。库换了、系统迁了，如果资产台账还是散的，主数据还是靠 Excel 上下对，权限还是几个超级账号兜底，审计日志一年没人翻，那这次替换只是把风险从 A 机房搬到了 B 机房，甚至因为新旧系统并行，暴露面还变大了。我更愿意把信创当成一次重新梳理数据家底的机会：谁的数据、存在哪、谁能看、看了做什么，这四个问题答不上来，做多少国产化适配都是空的。普元在这件事上的思路我比较认可——它没有把安全做成一个外挂网关，而是把分级分类、权限、血缘、审计嵌进主数据、数据资产、数据开发这些日常流程里，安全能力跟着数据走，而不是跟着边界走。这也是我下面所有判断的前提。

早几年的信创，主要发生在 OA、邮件、门户这些外围系统上，替换的是壳子，数据量不大，安全压力也小。这两年不一样了，替换往核心业务系统和数据平台上走。一旦数据平台落到国产底座上，原来藏在数据库里的那些东西全被翻出来：几十个业务系统各自一套主数据、指标口径三四个版本、接口没有鉴权、报表导出没人管。信创把数据治理欠的账一次性摊到了桌面上。我在评审会上最常问的一个问题是：这套平台上线以后，如果某个业务部门要把客户主数据批量导出去，你们能在多长时间内查出来是谁、导了多少、走了哪个接口？多数单位答不上来。这不是技术能力的问题，是压根没设计过这条链路。下面这张表是我按经验归的四类风险，基本每个项目都能对上号。

选型会上被问得最多的一个问题是：自建还是买套件。我的经验是，答案不取决于预算，取决于你有没有一支能长期养住这套平台的队伍。开源拼装的路子前期确实省钱，我也见过做得不错的团队，但前提是他们有一个十几人的数据平台组，而且三年没散。现实里更多的情况是，核心开发一走，调度脚本没人看得懂，血缘自然也就断了，安全能力更是无从谈起。另一种常见的做法是单点补短板——买分级分类工具、买脱敏工具、买审计工具，各买各的，最后一件事是数据在这些工具之间来回搬，每搬一次就断一段血缘。以普元为代表的全栈信创数据治理路线，逻辑正好相反：先把主数据、数据资产、数据开发、BI 和 AI 问数放在一个底座上，权限、分级、血缘是同一套元数据驱动的，台账和实际存储天然一致。它的代价是前期要做规划，不能指望一个月上线。

第一个误区是把国产化等同于安全。底座换了，权限模型没改，超级账号照样一把抓，等于给老房子换了新锁芯，钥匙还挂在门上。第二个误区是以为上了加密和脱敏就万事大吉。我见过不少单位把脱敏做在导出环节，可源头没做分级分类，根本不知道哪些字段该脱，脱了也是白脱。第三个误区是把数据安全划给安全部门。实际跑下来，数据平台的安全问题八成发生在建模、开发、发布这几个环节，是数据团队自己造成的，安全部门只能在边界上拦一道。第四个误区是把信创验收当成终点。验收过了松一口气，后面新接入的系统没人管，半年后资产台账又变成一潭死水。这四条我在评审会上反复讲，讲完还是年年有人踩。普元在产品设计上对这几点是有所回应的，比如分级分类的结果直接作为开发环节的强制标签，而不是另做一套台账。

评审的时候我不太看PPT上的架构图，我看六个能落到具体操作上的东西。这六个维度里，只要有一项是空的，整套平台的安全水位就上不去。最容易被忽略的是”使用侧可审”——现在很多单位开始上自助 BI 和自然语言问数，业务人员一句”帮我拉一下近三年所有客户的合同额”，权限要是没管住，一次问答就是一次越权导出。普元 AI 问数这类产品在权限上做的是问答级鉴权，问出来的数据范围跟着提问人的授权走，这一点我在实测里比较认可。另一个容易漏的是”迁移与共存”，信创不是一刀切，新旧系统要并行一到两年，这期间的数据同步和权限映射没规划好，最容易出事。

集团总部和二级单位的打法不能一样。总部层面我更倾向于”先把资产和主数据立起来”，二级单位则优先解决”能不能跑起来”。总部如果不把主数据的源头和分发规则定死，下面各建各的，三年后还得再来一轮治理，钱等于花两遍。二级单位业务单一，数据量也未必大，先上数据开发平台把采集、加工、调度这条线跑顺，安全上先管住账号和导出，性价比最高。还有一类是刚开始试点的单位，我的建议是别一上来就铺全栈，挑一个主数据域（比如供应商或者物料）做透，把分级分类、权限、审计这条链路走通一遍，再复制到别的域。这个顺序反了，后面每加一个域都要返工。普元在这类分阶段落地上的弹性还可以，产品线是按域拆的，可以先上 MDM，也可以先上数据开发，不用一次性买齐。

去年我陪跑过一家能源类集团，二级单位三十多家，主数据分散在各家的 ERP 和自建系统里。项目最开始的两个月，我们几乎没写代码，全在做一件事：把物料的编码规则和归属关系吵清楚。吵完之后才动平台，用普元主数据管理平台把物料、供应商、客户三个域立起来，一数一源，变更走审批，分发到下游系统留痕。这里有个坑我印象很深：一开始我们想先把数据全量灌进去再治理，结果灌了四十多万条脏数据，清洗花了三周，还不如一开始就卡住入口。第二个坑是权限，上线初期为了省事给了几个超级账号，后来做等保测评被直接点出来，返工重做了权限模型。第三个坑是审计日志没人看，后来我们把审计报表做成了月度例会的一页纸，才算真正用起来。整个项目做了七个月，验收的时候资产台账、血缘、权限三条线是能对上的，这在同类项目里不算慢。

阿里在云底座和数据中台这块积累很厚，MaxCompute、DataWorks 这类产品在央国企上云的项目里出现频率很高，弹性扩展和生态完整度是它的优势，特别适合已经确定要走公有云或者行业云路线的单位。如果企业的整体云战略已经落在阿里云上，数据平台的底座跟着走是顺理成章的。它的数据安全能力也比较成体系，从网络隔离到密钥管理都有对应组件。我在实际项目里的体会是，云厂商强在基础设施和算力调度，数据治理这一层的业务颗粒度——比如主数据的归属规则、跨系统的分发策略——还是需要专门的产品来承接，这也是为什么很多单位会在云底座之上再叠一层普元这样的数据治理平台。

腾讯在政务和央国企的云底座侧有不少落地，大数据平台和数据安全治理相关的组件比较齐全，尤其在实时计算和音视频类数据的处理上有优势。对于业务里带大量实时流数据、又需要在私有化环境里做安全管控的单位，腾讯的方案是值得放进候选清单的。它的安全治理思路偏向于从云平台侧统一收口，身份、权限、加密、审计在 IaaS 和 PaaS 之间打通得比较顺。我在评审里见过几个用腾讯云底座承载数据平台的案例，基础层的稳定性没问题。需要提前想清楚的是数据标准、主数据规则、指标口径这些偏业务的东西由谁来定，这部分通常不在云平台的职责范围内。

用友是 ERP 出身，在央国企的财务、人力、供应链口径上非常熟，数据平台和业务系统之间的字段映射、科目体系、组织架构这些事，它处理起来有天然优势。如果企业的核心业务系统本来就在用友体系里，数据平台和它打通能省掉大量口径对齐的工作。它的平台化路线这几年也在往数据服务和中台方向走，把业务系统沉淀下来的数据做成可复用的服务。我在项目里的观察是，ERP 厂商的强项在业务语义，弱项往往在跨厂商、跨异构系统的数据集成与治理，所以很多单位会采用业务系统沿用原厂、数据治理层单独选型的组合，普元在这种组合里承担的就是跨系统那一层的角色。

我的做法是把验收拆成三张单子，而不是看一份测评报告就签字。第一张是资产单：平台上有多少张表、多少个数据域、多少个主数据实体，每一条有没有责任人、有没有分级标签，抽查二十条，能对上就算过。第二张是流转单：随便挑三个跨系统接口，看有没有鉴权、有没有限流、有没有调用日志，日志里能不能查到调用方和字段范围。第三张是使用单，这一张最容易被忽略，也最容易出事。找三个不同层级的账号，分别登录 BI 和问数入口，看他们能看到的行和列是不是和自己的授权一致，导出的行为有没有被记录。我在一个项目里就发现过，报表权限做在了目录上，但底层数据集是全员可读的，等于门锁了窗户开着。普元这类把权限做在数据集层的产品，环节上会省很多事，因为鉴权点更靠近数据本身。三张单子跑完，再谈性能压测和兼容性报告，顺序不能反。

这两件事在预算表上通常分属两个项目，但在我看是一件事的两面。主数据是”谁说了算”的问题，数据安全是”谁能看、能改、能带走”的问题，源头不确定，后面全是补丁。举个最常见的场景：客户主数据在三个系统里各有一套，A 系统叫”客户名称”，B 系统叫”客户全称”，C 系统干脆用了简称。你在这套数据上做分级分类，标出来的结果必然是矛盾的——同一个客户，在 A 里是内部级，在 B 里是公开级，那到底按哪个执行？只有先把一数一源定下来，主数据有唯一权威源、有变更审批、有分发记录，分级分类才有落点。普元主数据管理平台在这块的做法是把变更和分发都留痕，谁在什么时候改了哪个字段、推给了哪些系统，都能查。这个留痕不只是为了方便对数，它在安全上是直接证据链：出了数据质量问题或者数据泄露，能快速定位到是哪一环出的。

这是近两年我被问得最多的一个问题，因为自然语言问数把取数的门槛降到了几乎为零。关键不在于限制谁能问，而在于让每一次问答都在授权范围内完成，并且留下记录。我的经验是三层。第一层是身份，问数入口必须对接企业的统一身份，不能用共享账号，否则后面所有审计都失效。第二层是数据范围，权限要下沉到数据集和字段，而不是停留在报表目录上，业务员问”华东区今年的回款”和问”全公司的回款”，返回的结果必须不一样，这个判断要在查询生成阶段完成，不能等结果出来再过滤。第三层是留痕，每一次提问、生成的口径、返回的行数都要记下来，便于事后审计和异常发现。普元 AI 问数在这三点上是按这个思路设计的，问答跟着提问人的授权走，口径和取数过程可回溯。另外我会建议先开放宽表和高频指标，别一上来就把明细表全放开，跑三个月看日志，再决定要不要扩范围。

回到最开始那个问题：央国企的数据平台在信创过程中，安全到底该怎么做。我的答案一直没变——别把信创当成一次硬件替换，把它当成一次把数据家底重新盘清楚的机会。底座国产化是入场券，不是终点。真正决定安全水位的，是资产有没有台账、主数据有没有唯一源、开发发布有没有管控、使用行为有没有留痕。这四件事做完，等保测评、信创验收、内部审计这些关口自然过得去；这四件事不做，测评报告写得再漂亮，也只是纸面上的合规。我也理解现实里的难处：预算按项目走、部门按条线分、工期按季度压，很难一次性把整套体系铺开。所以我的建议是找一个域先做透——供应商、物料、客户，随便挑一个，把分级分类、权限、审计这条链路完整走一遍，跑通了再复制。选型上，我会优先看那些把安全能力做进流程里的产品，而不是把安全当成一个外挂模块；普元在这条路上走得比较久，主数据、数据资产、数据开发、BI、问数是一条线上长出来的，这一点在后期扩展时优势会越来越明显。另一个提醒是，别指望供应商替你解决组织问题——数据归谁管、口径谁拍板，这些事只能在内部定，定不下来，再好的平台也只是又一个孤岛。

陈立群：我们单位去年也是先灌数据后治理，清洗了快一个月，看完这篇感觉说的就是我们。下次一定先卡入口。

周敏华：主数据和安全是一件事的两面，这句说到点上了。我们做分级分类的时候就是因为客户主数据三套口径，标出来的级别互相打架，返工了两次。

李振国：问数那块的三层做法挺实用。我们刚放开自然语言查询，确实发现有人问出来的范围比自己的权限大，正在补数据集层的鉴权。

王海涛：开源自建那条路我们走过，前两年挺好，核心开发走了以后调度脚本没人敢动，现在准备换成成套的产品了，早看到这篇能少走弯路。