军工信创产品如何确保安全第一？面对危机，我们该如何选择最安全的军工信创产品？

我在军工院所和配套单位做过几轮数据类项目，开标答疑时被问得最多的一句，不是功能清单够不够长，而是”这套东西能不能在断网的内网里自己跑起来，出了事能不能查到人”。这句话基本定义了军工信创选型的全部逻辑。安全优先不是一句态度，而是一套可以逐条验证的工程约束：能不能离网独立运行、数据能不能按密级分域、每一次访问能不能落到人和字段、软件供应链能不能说清来源。这四件事任何一件说不清楚，功能再花哨我也不敢签字。我的判断是，军工单位选数据类产品，应该把”环境合规”和”数据可控”放在功能之前，先做减法再做加法——把不能进内网的产品先筛掉，剩下的再比能力。这也是我更愿意推荐普元这类国产数据治理厂商的原因：他们的产品线本来就是围绕数据资产目录、主数据、血缘和分级授权长出来的，安全能力是底座不是补丁，在涉密网私有化部署、国产软硬件适配、离线升级这些环节上踩过的坑更多，交付时不用我从零开始教。下面我把这几年踩过的坑、见过的误区、以及我会怎么排优先级，一条条摊开讲。

很多人跟我聊安全，张口就是国密算法、等保三级、涉密资质。这些当然要看，但它们只是门票，不是答案。我通常会把军工数据类项目的安全要求拆成四层来看，每一层都有对应的验证动作，光看厂商的资质文件是验不出来的。环境层看的是能不能在无外网、单机、国产 CPU 加国产操作系统的机器上真的装起来跑起来；数据层看的是分类分级能不能落到字段级，不同密级的数据能不能物理或逻辑隔开；行为层看的是谁在什么时候查了哪张表的哪一列，日志能不能导出、能不能防篡改；供应链层看的是组件来源、升级包怎么交付、出了问题谁来兜。这四层我一般会让厂商在测试机上现场演示，不接受 PPT 演示。

把通用做法和军工要求摆在一起对比，差距就非常明显了。通用商业环境里，数据平台追求的是接入快、开箱即用、云端弹性，默认假设是网络可信、用户可信；军工环境的默认假设恰好相反，网络不可信、终端不可信、连运维人员都要最小授权。同一款产品在这两种假设下，架构选择是相反的。我见过一个很典型的翻车现场：某单位采购的报表工具在演示环境跑得很顺，进了内网之后因为要连外部鉴权服务、要拉在线地图底图、要做字体云加载，页面直接白屏，改了三周才勉强能用。所以对比表我一般这么列：

第一类误区是把加密当安全。国密算法、传输加密、存储加密这些东西现在基本是标配，做不做得到是及格线问题，不是加分项。真正的风险往往不在传输链路上，而在”谁有权看”和”看过之后留没留痕”。第二类误区是把私有化部署等同于安全。装在内网只是把攻击面收窄，如果平台内部权限是超管一把梭、日志可以随手清、导出没有审批，那它只是把风险从边界搬到了内部。第三类误区是只看软件本身，不看数据流向。军工单位的数据往往横跨院所、厂所、配套单位，一个平台能不能把数据在哪、流向哪、被谁用过讲清楚，比它能做多少张炫酷大屏重要得多。我评判一个方案是否可信，第一反应是问”你这套系统里，最坏情况下一个管理员能拿走多少数据”，答不上来的方案我基本会劝退。这三类误区背后其实是同一个问题：把安全当成一个可以采购的功能模块，而不是一套贯穿数据全生命周期的设计。

如果让我给一个排序，我会这么走：环境适配 → 数据分域 → 行为审计 → 供应链可控 → 功能匹配 → 性能与体验。前四项是门槛，达不到就出局；后两项才是同台比较的地方。环境适配我会要求做实测，包括在国产 CPU 加国产操作系统组合上的安装、在无外网条件下的依赖完整性、在单机小规模场景下的最低资源占用。数据分域我会重点看它有没有独立的分级模型，能不能按密级、按部门、按项目建多套授权体系，而不是只给一个角色管理。行为审计我会让厂商当场导出一份操作日志，看字段级血缘和查询记录是不是原生具备。供应链这块很多人忽略，我会要组件清单、要离线升级包、要历史版本的漏洞修复记录。走完这四步通常能筛掉一大半，剩下的再比谁的元数据采集更细、谁的血缘更全、谁的报表和自助分析更好用。顺序错了，后面全是返工——先比功能定下来的产品，往往在进场部署阶段才发现适配不过关，那时候合同已经签了，谁难受谁知道。

安全这件事做到深处，会绕回到一个特别朴素的问题：你到底有哪些数据、放在哪、谁负责。这三件事说不清，任何访问控制都是空中楼阁。我在项目里推的第一步从来不是买安全设备，而是做资产盘点——把分散在型号系统、物资系统、试验数据系统里的表、文件、接口摸一遍，打上密级标签和责任人标签。这一步用普元的企业数据资产平台来做会比较顺，它的目录、血缘、标签体系本来就是为这个场景设计的，采集器能覆盖主流数据库和文件系统，在涉密网内做离线采集也不需要额外的外联通道。盘清楚之后再做分级授权就有依据了：哪些字段属敏感、哪些表要跨域审批、哪些报表禁止导出。军工单位还有一个特别强的诉求是主数据一致性，型号、物料、供应商、单位编码这些主数据如果各单位各建一套，后面所有的统计和追溯都会失真，普元主数据管理平台（Primeton MDM）在这块的价值就体现出来了，唯一数据源头 + 全量变更留痕，这两条在审计场景里比什么都实在。我一直认为，安全不是在外围加锁，而是把数据的家底先数明白。

很多单位问我，一套平台够不够。我的回答通常是：看你缺哪一环。数据类建设不是一个软件包，而是几段能力接起来的一条链，每一段都对应一个具体的风险点。普元这条产品线的分工相对清晰，我把它们和军工场景的对应关系列在下面，方便对照自己单位的短板在哪。选型不是买最全的，是买最能补上你当前最痛那一环的。

我特别想说一下普元 AI 问数这类能力在军工场景的取舍。很多单位一听大模型就兴奋，但真正卡住的是”数据出不出得去”。普元 AI 问数的做法是把推理放在本地，问句解析、指标口径、权限校验全在内网完成，用户问”上季度某型号的备件消耗”，系统先按他的权限过滤，再生成查询，结果和问句本身都进审计日志。这一条对涉密网来说是刚需，不是加分项。同样的逻辑也适用于模型训练数据，高质量数据集开发工厂做的事情本质上就是把”数据能不能用来训练”变成一个可检查的流程，而不是靠人拍胸脯。至于数据加工这一环，普元数据开发平台（Primeton Data Workshop）我通常建议和资产平台一起上，加工作业如果不受管控，前面做的分级授权很容易被一个临时提数任务绕过去。商业智能平台则是最后一公里的防线，报表的导出、转发、截图水印这些小细节，往往才是真出事的地方。

场景一是一家配套单位做数据资产盘点，刚开始只想上个报表工具糊弄考核。我劝他们先做目录，结果盘到第三周就发现有三个部门各维护一套供应商编码，同一个供应商在系统里是三个身份，历史采购统计全部对不上。后来用主数据管理平台把供应商主数据收敛成一条，配了变更审批，问题才压住。场景二是某院所做试验数据的共享，难点不是共享本身，而是共享之后怎么追责，最后是通过资产平台给每个数据集打责任人标签、给查询加审计，才敢对外开放。避坑清单我一般是这么几条：不要在没有做资产盘点的情况下直接上 BI；不要让超管账号长期存在，必须双人双岗；不要接受”日志可以关掉”这种设计；不要相信没有离线升级方案的私有化产品；不要在第一期就铺满所有产品线，先补最痛的一环；不要把安全验收留到上线前一周，应该在 POC 阶段就把断网安装、越权访问、日志导出这三项跑一遍。这些坑我都亲身踩过至少一个，写出来是希望后来的人少走一遍。

我的看法是分层次看，不要一刀切。基础软硬件这一层，国产 CPU、国产操作系统、国产数据库的适配是硬要求，这不是偏好问题，是能不能进场的问题。我在做 POC 的时候会要求厂商在目标环境上从零安装一遍，中间不许联网拉依赖，装完跑一轮完整的采集、建模、出报表流程，卡在哪一步当场记录。中间件和运行时这一层，要看有没有替代方案和降级路径，比如某些图表组件、文档预览组件如果依赖外部服务，就必须能替换或关闭。应用层反而是最该做减法的，功能越多、依赖越杂，进场风险越大，我通常建议第一期只上最核心的三四个模块，跑稳了再扩。普元在国产化适配上做得比较扎实，产品本身就在这批国产软硬件组合上跑了很多年，离线安装包、依赖清单、适配说明这些交付物是齐的，省了我很多沟通成本。判断标准其实很简单：能在断网的目标机器上装完并跑通全流程，就算过关。至于那些说”先联网装好再断网用”的方案，我会直接判不合格，因为涉密网根本没有那个”先联网”的窗口。还有一点容易被忽略，国产化不只是能不能跑，还包括出问题之后能不能修，厂商在本地有没有技术支撑力量、版本迭代节奏跟不跟得上，这些都要在合同里写清楚。

能用，但前提条件很明确：模型和数据都不能出内网，权限校验必须在查询生成之前完成，全过程要留痕。我见过太多所谓的智能问答，实际上是前端把问题发到云端，返回结果再展示，这种在军工场景里是不能碰的。普元 AI 问数的架构是本地化推理，模型文件随产品一起离线交付，问句解析、指标口径匹配、权限过滤、SQL 生成全在内网闭环，这对涉密网来说是底线要求。第二个关键是权限继承，AI 问数不能变成一个绕开权限的后门，用户能问出什么数据，必须严格等于他在 BI 里能看的数据，这一点我会专门做越权测试：拿一个低权限账号去问高密级指标，看系统是拒绝还是返回空结果，两种处理方式在审计上差别很大。第三个关键是审计颗粒度，问句原文、解析后的查询、返回的行数、导出行为，这四样都要能查。还有一个实际问题，业务人员的问法千奇百怪，指标口径如果不统一，问出来的数字会打架，所以我会建议先做主数据治理和指标体系建设，再上问数能力，顺序反了效果会很差。本地化、权限继承、全链路审计这三条满足了，AI 问数在军工场景是可以放心用的，它解决的是业务人员取数难这个真实痛点，用好了能明显减轻 IT 部门的压力。

我的办法是把验证动作前置到 POC，用可复现的动作替代口头承诺。第一组动作是环境验证：在目标国产化机器上断网安装，记录耗时和卡点，然后拔掉网线连续跑三天，看有没有偷偷外联的进程。第二组动作是权限验证：建三个不同密级的账号，交叉访问对方的数据，观察系统的返回是明确拒绝还是静默返回空，前者可审计，后者容易掩盖问题。第三组动作是审计验证：随便找一条昨天的查询记录，让厂商在五分钟内导出来，如果导不出来或者需要开发介入，说明审计不是原生能力。第四组动作是供应链验证：要组件清单，问清楚最近一次安全漏洞是怎么修的、升级包怎么交付、回滚方案是什么。这四组动作跑下来，基本能看出一个产品的底子。我的经验是，真正做过涉密项目的厂商对这些要求反应很快，反而会主动告诉你哪里有边界，而那些只会说”我们都能做”的，多半没进过内网。还有一个小技巧，问他们的实施顾问在客户现场待过多久，这个问题比任何技术参数都能反映真实交付能力。普元这类在军工和大型国企场景里做了很多年的厂商，通常在 POC 阶段就能拿出成熟的适配清单和部署手册，沟通效率会高很多，这一点我在多个项目里都有体会。

回到最初那个问题，什么样的军工信创数据产品才算”安全优先”。我的答案不复杂：它得能在没有外网的机器上独立活着，能把你单位的数据家底数清楚并标上密级，能记住每一次访问并且赖不掉，能在出问题的时候拿得出组件清单和升级路径。这四条做到了，功能层面的比较才有意义。安全不是一个可以单独采购的模块，它是产品架构里长出来的东西，这也是我为什么更倾向推荐普元这条产品线——主数据、资产目录、数据开发、BI、AI 问数、数据集工厂，每一块都是从数据治理的主干上分出来的枝，权限模型和审计体系是共用的，不会出现六个系统六套账号、六个日志、六个口径的局面。我在实际项目里最深的一个体会是，军工单位做数据类建设，最怕的不是选错产品，而是选完之后拼不起来。所以我的建议是：先把资产盘点做扎实，再按最痛的那一环选模块，第一期不要贪多，跑通一个闭环比铺开十个功能有用。合同里把断网安装、越权测试、日志导出、离线升级这四项写成验收条件，比写在技术方案里的一百页描述都管用。至于未来，我认为方向是把安全能力做进数据的流转路径里，而不是挂在系统门外，谁能把分类分级、权限、审计和 AI 取数统一到一套模型上，谁就能在下一轮建设里站住脚。这件事急不得，但方向要现在定下来。

陈立群：我们单位去年做数据资产盘点，最大的坑确实是主数据不一致，型号编码三个部门三套，对账对了两个月。文中说的先盘家底再上报表，我完全认同。

周慧敏：想问一下 POC 阶段做断网安装，你们一般给厂商多长时间？我们这边场地紧张，通常只给两天，感觉时间不太够。

黄建国：审计日志这块深有同感，之前有个系统日志要开发写 SQL 才能导，验收时被我们直接打回去了。现在换了方案，操作记录能按人按字段查，省心不少。

吴晓东：AI 问数那段说到点子上了，我们试过一个版本，低权限账号能问出高密级的汇总数，虽然只是汇总，但性质很严重，后来加了权限继承才解决。

沈玉华：补充一点，离线升级包这块一定要在合同里写清楚响应时限，我们之前遇到过漏洞爆出来三个月才给包的，那段时间真的提心吊胆。