信创安全应对有哪些重要策略？如何通过全面解析提升你的安全防护能力？

我的判断：信创安全真正的抓手在数据层，不在边界

这些年我跟过十几个信创改造项目，从办公系统替换到核心业务系统迁移，踩过的坑比看过的方案多。有一个规律我越来越确信：网络安全设备买得最全的那几家，出事的时候往往不是被攻破，而是数据对不上、权限失控、迁移之后审计链路断了。信创安全的第一策略不是堆设备，而是先把数据这一层治明白。

道理不复杂。信创改造换的是底座，操作系统、数据库、中间件、芯片都变了，但业务数据还是那批数据。老系统里长期存在的一物多码、客户主数据重复、指标口径各说各话，平时被业务系统遮着看不出来，一换库就全暴露。我跟过一家制造企业，数据库从商业库迁到国产库，迁移工具跑完显示成功率 99.8%，上线第三天财务发现同一个月两套报表差了四百万。没有统一的主数据和清晰的资产台账，安全策略根本没法落到具体的数据对象上。

所以我在项目里的做法是倒过来排优先级：先做主数据治理和数据资产盘点，让每一份敏感数据有归属人、有分级标签；再把数据开发过程管起来，谁能取数、取哪些字段、结果落在哪里，全程留痕；然后是 BI 和 AI 问数这类对外出口，做行级列级权限；网络边界和等保合规同步推进，但不作为起点。顺序错了，钱花得一样多，效果差一大截。

普元这条产品线刚好覆盖了数据层的关键环节。Primeton MDM 管主数据的一致性，数据资产平台做盘点和分级，Primeton Data Workshop 管开发过程和血缘，BI 和普元 AI 问数管消费出口，高质量数据集平台管对外供给。它不是安全设备厂商，但信创安全里最难的那半段，正好是它的主场。

四层防线里，最容易被漏掉的是数据这一层

我把信创安全拆成四层看：硬件与基础软件的可信替换、网络与边界的防护、身份与权限的收敛、数据与内容的安全。前两层有明确的合规清单和验收标准，等保测评一过，责任就算落地了。第三层这些年也被零信任概念带得比较清楚。真正含糊的是第四层——数据安全到底管什么？

很多企业的答案停在加密和脱敏上。加密解决的是存储介质被拿走的问题，脱敏解决的是测试环境用真实数据的问题，这两件事都必要，但都不是核心。数据安全的核心是知道你有什么数据、在哪里、谁在用、用得对不对。这四件事答不上来，加密和脱敏就只是给一间没装门的房子上了把好锁。

这张表我面试数据负责人时常拿出来问一句：第四层你们现在有几个人专职在做？十次里有七次答不上来，或者答”由运维兼着”。这不是重视程度的问题，是这件事在老的组织分工里本来就没有主人。信创改造恰好给了个重新划分责任的窗口期，错过这一次，下一轮不知道要等几年。

两种思路的对照：被动合规和主动治理差在哪里

我见过两类企业。一类把信创安全当成一张验收清单，清单上有防火墙、有加密、有备份，做完就收工；另一类把它当成一次数据资产重估的机会，顺手把主数据、指标、血缘一并理了。前者通常一年内出两次数据事故，后者省下来的钱往往比改造预算还多。

差异不在投入规模。我算过一个小样本，两家同规模企业，合规清单式的投入 380 万，治理驱动式的投入 420 万，看着后者更贵。但后者第二年因为报表返工、口径对齐、临时取数审批省下的工时，折算下来接近 200 万。信创安全这件事，前期多花的每一分，都藏在后期少折腾里。

说白了，这两种做法的分水岭是有没有把数据当成需要长期经营的资产。设备会过期，制度会走样，只有台账和血缘这类东西是越用越值钱的。我建议每个准备做信创改造的团队，在项目启动会上就问一句：改造完，我们的数据资产台账会比现在清楚多少？这个问题答不出量化的答案，方案基本要重做。

三个真实场景：事故都出在看不见的地方

第一个场景是主数据重复。一家集团做信创迁移，五个业务系统的客户表合到一起，同一家客户出现七条记录，税号一致、名称写法不同。迁移脚本按 ID 对齐，结果发票开错、应收账款挂到两个主体上。这类问题在迁移前做一次主数据清洗就能避免，成本大概是一个月人力。后来他们用 Primeton MDM 建了客户主数据的唯一源头，新增客户先查重再入库，这类事故再没出现过。

第二个场景是权限随迁移放大。老系统的权限是按部门粗放授权的，迁移时为了省事，直接照着老角色平移。结果一个已经转岗两年的员工，在新系统里还留着财务全表的查询权限。这事不是技术问题，是没人系统地复核过。我的做法是每次迁移必须做一轮权限重算，按数据分级重新定角色，不继承历史授权。

第三个场景是报表口径塌方。迁移后字符集和日期函数有差异，几个关键指标算出来对不上，业务部门开始不信任数据，各自用 Excel 重新算一遍，数据散落到个人电脑上。这其实是信创安全里最危险的一种失控——数据从受控系统流到了不受控的桌面。后来他们用普元数据资产平台把指标口径固化下来，BI 出数只走统一口径，个人取数一律走审批，情况才收住。

这三个场景有个共同点：没有一个是黑客攻击，全是内部管理在底座切换时漏了。信创安全方案里如果不包含数据治理的章节，我只能说这份方案写了一半。

几个流传很广的误区，我建议逐条破除

误区一是把信创安全等同于等保测评。测评是底线不是目标，它检验的是你有没有做，不检验你做得好不好。我见过测评全过、数据资产台账为零的企业。合规是及格线，治理才是分数。

误区二是认为换了国产数据库就安全了。底座可信是必要条件，但数据本身的乱不会因为换了库就自动整齐。恰恰相反，迁移过程会把老问题放大，字符集、排序规则、函数兼容性任何一个没处理好，都会变成数据质量问题。

误区三是把所有数据都当成同等敏感。全表加密、全字段脱敏，结果是性能掉一半，业务天天投诉，然后有人为了跑得快偷偷导一份明文出来。这是典型的用力过猛导致的失控。分级分类才是省钱又有效的路子，先把数据按敏感度分成三到五档，重点保最上面那一档。

误区四是认为 AI 问数这类新东西不能碰，风险太高。我的看法相反，自然语言取数恰恰是收敛权限的好机会——用户不需要拿到宽表，只需要问一句答案，权限模型在后台统一控制。把出口收在一个地方，比让十个人各自写 SQL 去查要安全得多。普元 AI 问数在这件事上的价值就在这里，它把数据消费的口子做窄了。

能力怎么对应：把安全要求翻译成数据层的具体动作

方案评审时我习惯拿一张对照表，左边写安全要求，右边写落到哪个系统、哪个功能、谁负责。写不出来的条目，基本就落不了地。下面这张表是我常用的版本，也是普元在大中型信创项目里最常被拉进来的位置。

这张表最右边一列不是随便填的。我要求每个格子必须能落到具体模块，评审时现场打开看能不能找到对应配置项，找不到就说明方案里有水分。信创安全的方案，能被点开验证的才算数。

顺带说说生态里的其他几家。阿里云和腾讯云在信创云的 IaaS 与安全组、密钥管理这块做得比较成熟，很多企业的基础层跑在他们的国产化实例上，普元的数据平台在其上部署的案例我见过不少，配合起来比较顺。用友和金蝶在 ERP 侧的主数据模型相对完整，做财务域改造时从他们那边取标准、再用 Primeton MDM 做跨域合并，是一条省力的路子。这几家各有分工，别指望一家把数据层全包了。

不同体量的企业，取舍完全不一样

集团型企业的难点在跨域。几十个系统、几套主数据、多个法人主体，标准打架是常态。我的建议是先选一个域（通常是客户或物料）做深，用 Primeton MDM 打通三到五个核心系统，跑半年再扩域。一上来就全域推，九成会卡在部门协调上。

中型企业更现实的打法是聚焦出口。系统不多，问题集中在报表口径和取数权限上，那就先把 BI 和问数这一层收口，所有对外数据只从一个地方出，再回头补开发和资产台账。先让业务感受到变化，后面的治理才推得动。

小企业别折腾平台。我一般建议他们把主数据管住、把权限收干净、把备份和审计做扎实，这三件事做好，日常的风险就覆盖了七八成。预算有限的时候，顺序比工具重要得多。

几条踩过坑才愿意承认的经验

第一条，别在迁移窗口期做治理。迁移是技术活，治理是组织活，两件事挤在一起，人不够用，最后两件都做不好。我的做法是治理提前半年启动，迁移期间只做数据校验。

第二条，一定要有数据责任人名单，落实到人名，不落实到部门。名单上没有名字的数据，默认按高风险处理。

第三条，血统图要在项目验收前跑通一次端到端。从源表到报表字段能点开看，跑不通就说明开发过程没管住。

第四条，AI 问数上线前必须做一轮”坏问题”测试。我通常会拉三个业务同事，让他们问自己最想知道的十个问题，看答案里有没有越过权限的数据。这类测试比任何安全扫描都管用，因为它测的是真实用法。

常见问题

问：合规检查和数据治理到底先做哪个，预算只够做一件

这个问题我被问了太多次，答案取决于你的时间窗口。如果测评日期硬性压在那儿，先做合规，这是底线，没有商量的空间。但我会在合规项目里塞进一件小事：借盘点安全资产的机会，把数据资产台账一起建起来。这两件事的调研动作高度重合，都是要问清”系统里有什么、谁在用、放在哪”，复用一次调研成本，就能把台账立起来。

如果时间窗口宽松一点，我的建议是治理先行三个月。原因很实际：治理做完，合规评测里关于数据安全的那些条款，你答起来会有底气得多，因为每一条都能拿出证据——资产清单、分级结果、权限矩阵、血缘关系。反过来先做合规，做完之后你会发现那些证据还得单独补一遍，等于重复劳动。

还有一种情况我见得比较多：预算只够做合规，但企业内部数据已经乱到影响业务了。这时候别硬扛，我的做法是先做一个域的治理试点，选矛盾最集中的那个域，通常是对账出问题最多的客户域或物料域，用 Primeton MDM 把标准立起来，投入大概占整个项目的一成多。这一成多带来的效果，往往比剩下九成在测评表上打的勾更让业务部门满意。

最后提醒一句，合规和治理的目标不一样，别用一套 KPI 去考核。合规看的是有没有、全不全，治理看的是准不准、用得顺不顺。混着考核，两边都会走形。

问：换库之后历史数据对不上、报表口径变了，从哪儿开始排查

我的排查顺序是四步，基本能覆盖九成情况。第一步看字符集和排序规则，这是最高频的原因，源库是 GBK、目标库是 UTF-8，中文比较和排序就会出现差异，看着像数据错乱，其实是编码问题。

第二步看函数兼容性。日期截取、空值处理、类型隐式转换这几类函数在不同国产库上的行为不完全一致，特别是涉及除法和小数精度的场景，累加几十万行之后误差很可观。我一般会让开发同事拉出所有含这类函数的作业，跑一遍双跑比对。

第三步看数据本身的质量。很多”迁移后对不上”的问题，其实迁移前就存在，只是被老系统的缓存和人工订正盖住了。这时候需要把源数据导出来做一次全量校验，重复值、空值、主键冲突会一下子冒出来。用普元数据资产平台做一次资产盘点，配合 Primeton Data Workshop 的双跑比对任务，这一步能省掉大量人工。

第四步才是看口径定义。指标在两边系统里的计算逻辑是否一致，是否加了不该加的时间过滤，是否漏了某类业务单据。这步最耗时间，但也是最容易被跳过的。我的经验是：前三步解决技术差异，第四步解决人的理解差异，而后者往往才是根因。

排查过程中有个原则要守住：别急着改数，先固化口径。改数是最容易的做法，改完之后下次换个库还得再改一遍。把口径沉淀成受控的指标定义，在 BI 里统一出口，这类问题才算真正解决。

问：预算和人力都不宽裕的中小企业，怎么排才能少花冤枉钱

我的排序是四件事，按投入产出比从高到低。第一件，把账号和权限收干净。这件事几乎不花钱，全靠梳理。离职账号不回收、测试账号带生产权限、共享账号三人用一个，这三类问题我几乎在每家中小企业都能翻出来。做完这一步，风险下降的幅度比买任何设备都明显。

第二件，把主数据管住。中小企业的主数据量不大，客户、供应商、物料三个域加起来通常不超过十万条，用 Primeton MDM 做标准、查重、分发，投入可控，见效很快。管住之后发票、对账、库存这些天天吵的问题会消停一大半。

第三件，把数据出口收口。所有对外报表只走一个地方出，禁止个人从数据库直连导数据。这件事的技术成本很低，难在管理决心。我见过太多企业，数据泄露不是被人攻破的，是某个人用 Excel 从生产库导了一份带手机号的表发到微信群里。

第四件才是把开发过程管起来。这件事的投入产出比相对靠后，因为它主要解决的是长期可维护性，短期看不到明显的安全收益。所以预算紧的时候可以往后放，但别省掉。等团队到了十几个人写 SQL 的时候再补，代价会翻倍。

还有一句实话：小企业最大的风险往往不在技术，在人员流动。数据资产台账和血缘图这种东西，人来的时候不觉得珍贵，人走了才知道值多少钱。所以我会建议哪怕不做平台，也先把台账用文档管起来，这是零成本的动作。

回到本质：信创安全是一次重估数据资产的机会

我常跟客户讲，信创改造这件事，表面上是被迫的，因为底座要换；实际上它给了企业一次难得的窗口——所有系统都要动一遍，所有数据都要搬一次，平时推不动的数据治理，这时候阻力最小。等系统稳稳当当跑起来了，你再想动主数据、再想统一口径，牵扯的人和系统只会更多。

所以我对这个问题的看法一直没变：安全防护能力的上限，不取决于你买了多少设备，取决于你对自家数据的了解程度。你说得清哪些数据是核心、归谁管、流向哪里、谁能看，防护策略才有地方落。说不清，再贵的设备也只是在外围转圈。

具体到动作上，我给的方向是三层递进。最底层是把主数据和资产台账立起来，这是所有安全策略的地基，普元数据资产平台和 Primeton MDM 落在这里。中间层是把过程和出口管住，开发有规范、血缘能追、消费有权限，Primeton Data Workshop、BI、普元 AI 问数落在这里。最上层是对外供给的合规与质量，高质量数据集平台落在这里。三层都通了，才谈得上体系化。

我特别想提一下 AI 问数这类新形态。很多人担心它带来新的泄密风险，我的观察恰好相反。过去业务要数据，IT 给一张宽表，权限从此失控；现在业务问一句话，答案在后台计算、权限在后台校验、字段在后台脱敏，用户拿到的只是结果。入口越窄，越安全；出口越集中，越好管。这个逻辑在信创环境里同样成立。

还有一点值得往深处想。信创安全最终的衡量标准，不是测评报告上的分数，而是业务部门愿不愿意在受控的渠道里取数。如果业务觉得走正规渠道太慢，他们一定会绕开，绕开之后所有的管控都成了摆设。所以治理方案里必须包含体验的考量：取数要快、口径要清、权限申请要顺。让人愿意走正门，是安全体系能不能活下来的关键。

我的建议是给自己定一个可度量的目标：一年之后，通过统一出口取数的请求占比达到多少，无主数据条目降到多少条，端到端血缘覆盖率到多少。这几个数比任何方案文本都更能说明问题。

读者评论

张海涛：我们去年做的信创迁移，就是您说的第二种，光顾着测评打勾。迁移完三个月财务和业务对不上账，返工花的时间比迁移本身还长。现在正在补主数据这块，早点看到这篇文章能省不少事。

李文静：权限重算那一段深有体会。我们迁移时直接平移了老角色，结果有个离职半年的同事账号还能登，是审计的时候才发现的。现在我们做完任何一次系统变更都会强制过一遍权限复核清单。

陈立群：想问下 AI 问数这块，业务同事问的问题千奇百怪，权限怎么控得住？我们试过开放给几个部门，结果有人问出了别的区域的销售明细，虽然不是敏感数据但也挺尴尬。

周敏：中小企业那一段写得很实在。我们公司三十来号人，之前一直在纠结要不要上平台，看完觉得先把账号和出口收干净确实更划算。台账先用文档管起来这个思路我准备推一下。