低代码平台安全性不容忽视，2026年国企选型必须要知道的6个问题

我在等保测评机构待了6年。

2021年，我们接的低代码平台测评只有3个；

2023年，这个数字变成了40多个。不是低代码突然变安全了，是选低代码的国企变多了。

而安全问题是上了规模之后才会被真正看见的。

01 一个真实的故事

2019年，我参与一家央企的数字化选型项目。信息安全部准备了一份详细的需求清单：等保三级、数据加密、审计日志、数据本地化，一条不落。

我问他：你们现在用的那套系统，安全报告在吗？

他说，在，老系统安全没问题，用了很多年。

我把安全报告调出来一看：等保三级证书两年前就过期了，测评机构提的整改建议一条都没落实。

他愣住了：证书过期这事，我们真不知道。

这不是个案。这家央企的困惑非常有代表性。

选新系统时认真审视安全性，但对自己正在用的系统，从来没有真正查过底。低代码平台选型也是一样：招标书上写得漂亮，上线之后才发现有些问题根本不是证书能覆盖的。

今天不聊招标文件里的标准答案。我来拆几个真正容易踩坑的地方。

都是选型阶段问不出来的。

02 第一道坑：你的数据，到底存在哪

选型时供应商的标准答案是："支持私有化部署，数据在客户自己的服务器上。"

但"私有化部署"至少有三种情况：

第一种是完全私有化。平台整套安装在客户机房，数据库、中间件、应用服务器全在客户网络内，供应商运维人员远程维护，全程不碰业务数据。这是数据主权的最严格定义。

第二种是混合部署。核心业务数据存在客户侧，但平台的元数据、运维日志会同步到供应商云端做分析。我见过一家省级国企，"私有部署"了两年，直到一次安全审计才发现：每天凌晨2点，运维日志自动上传到供应商服务器，供应商技术人员可以随时调取。

第三种是假私有化。服务器在客户机房，但底层数据库用的是供应商的云数据库实例，网络打通，数据物理上在供应商的云服务商那里。这种模式在中小规模私有化项目里相当普遍，甲方以为是私有化，实际控制权在乙方手里。

怎么区分？最直接的办法：问供应商要数据流向图，看数据从产生到存储到备份的完整路径上，有没有经过供应商控制的云端节点。这个要求不过分，任何正经做过安全设计的供应商都能提供。

03 第二道坑：权限体系的上限在哪

"我们支持完整的权限管理，可以按角色、按部门、按字段配置。"

这句话在所有低代码平台宣传材料里都能看到。

2021年，一家地方城商行上线了一套低代码平台做信贷业务流程。信息安全部上线前做了完整的权限规划：客户经理只能看自己的客户，支行行长看本支行的，审批岗看所有待审的。配置文档写了三十多页。

上线三个月后，审计部门做了一次渗透测试，发现了一个致命漏洞：一个支行行长账号，竟然能查到全行所有个人客户的征信查询记录。

问题在哪？低代码平台的权限体系通常分两层：第一层是应用级菜单和页面权限，这一层通常没问题；第二层是数据级字段权限和行级权限，这一层各个平台实现差异极大。

有些平台的数据权限是在前端做的过滤。用户看不见其他人的数据，但数据库里其实都有，技术人员换个接口参数就能查到。前端过滤对普通用户有效，对有技术背景的人形同虚设。

真正安全的权限，必须在后端数据库层做隔离。数据从数据库取出来之前就按权限过滤掉，应用层根本碰不到不该看的数据。

怎么测？

直接调API接口，用低权限账号尝试访问高权限数据，看后端有没有做真正的隔离。不要测界面，要测接口。

04 第三道坑：审计日志，到底记了什么？

等保要求里明确写着"记录用户的关键操作行为"。但"关键操作"谁来定义？登录算，退出算不算？查询算不算？导出算不算？

我见过最敷衍的审计日志，只记了谁登录了系统、谁退出了系统。数据导出、报表下载、权限变更，一条没记。

也见过做得非常细的。一家中字头央企的ERP系统，每次数据导出都记录：谁在什么时间从哪个IP地址导出了哪张表、导出了多少条记录、导出的文件哈希值是多少。想抵赖，门都没有。

对于低代码平台，审计日志至少要覆盖：登录和登出的时间、IP地址、设备信息；数据的新增、修改、删除操作，包括操作前后的数据快照；权限变更记录，尤其是管理员给普通用户提权的操作；报表导出和批量操作记录。

更重要的一点：审计日志本身能不能被篡改？如果平台管理员能随手把日志清空，那这套审计体系形同虚设。合规要求里的"日志防篡改"，意思是日志要写入只读存储或者用哈希链式结构保证完整性。

05 第四道坑：供应商的人，到底能碰多少东西

这个问题很少有人在选型阶段问过，但上线之后问题会集中爆发。

最干净的模式：供应商人员只接触应用配置层，不碰业务数据，不碰服务器底层。配置文档由客户方保管，供应商按文档操作，完成后客户验收确认。

最混乱的模式：供应商人员掌握服务器root权限，可以直接操作数据库，可以随时登录系统后台，可以看到所有业务数据。有些项目的供应商人员用的是个人账号登录，没有双因素认证。

2022年，我了解到的一个人为数据泄露事件：一家省级电力公司用的低代码平台，供应商技术人员的登录账号是6个人共享的，同一套账号密码，离职交接靠口头，离职后账号也没注销。结果一个离职半年多的员工收到了系统登录通知。他用老密码还能登上系统，这时候他早已不是公司员工。

怎么防？

核心两条：第一，供应商人员的访问权限必须受限，不能是管理员权限；第二，供应商人员的所有操作必须留下可追溯的审计记录。选型时可以要求平台提供"运维堡垒机"功能，所有供应商人员的系统访问必须通过堡垒机，记录全部操作会话，管理员可以随时回放。

06 第五道坑：数据迁移，真的能自己完成吗

很多国企选型时考虑的是"低代码平台能不能接住我们的业务"，但没想过"如果将来要换平台，数据能不能拿得回来"。

低代码平台的数据存储结构通常不是标准的SQL表，而是平台自己定义的元数据模型。同一个"客户"对象，在织信低代码平台里是一套结构，在简道云里是另一套。你的业务数据存在这些平台定义的专有结构里，不是可以直接导出的CSV文件。

这意味着：如果有一天要换平台，数据迁移需要供应商配合，甚至可能要付额外费用。更极端的情况：供应商倒闭或停止服务，数据直接变成孤儿数据。

过去三年，低代码赛道已经死掉了大批中小平台。选型阶段就要问清楚：数据能不能自主导出？导出的格式是什么？不依赖供应商自己能不能完成迁移？

能直接回答"能"的供应商凤毛麟角，但能认真回答"需要我们提供迁移工具，但我们保证工具的完整性和文档可用性"的供应商，至少态度是端正的。

那种说"数据存在我们这里绝对安全、我们公司实力很强不会倒闭"的供应商，反而要格外警惕。他们在回避问题。

07 第六道坑：等保认证，到底覆盖了哪些范围

等保测评是针对特定系统的特定范围做的评估。我见过同一个供应商的两套系统，一套拿了等保三级证书，另一套没拿。不是因为安全性不同，是因为测评范围的边界不同。

更关键的问题是：等保三级证书有效期是两年。证书到期后供应商有没有重新测评？平台做了大版本更新，之前的证书还能不能覆盖新版本？

问供应商要证书的同时，要问这几件事：证书覆盖的是哪个版本的系统？平台做了大版本更新，测评报告有没有补充说明？供应商有没有定期做渗透测试和漏洞扫描，扫描报告愿不愿意给客户看？

如果供应商说"我们有证书，但扫描报告涉及核心技术不方便提供"，这个回答本身就说明问题。正经做安全的供应商巴不得把扫描报告给客户看，而不是藏着掖着。

08 一张评估表

说了这么多，具体怎么判断？我整理了一张表，选型阶段可以直接拿着去问供应商，每一条都要求对方提供对应的说明材料或测试证据。

国企选型低代码平台安全评估表

前三条是安全能力的硬指标，不达标一票否决；后三条是供应商态度和长期服务能力的软指标，可以在合同阶段加条款约束。

09 写在最后

安全这件事，从来不是选出来的，是管出来的。

再安全的平台，如果甲方没有对应的安全管理制度和巡检机制，上线三年之后一样漏洞百出。低代码平台尤其如此，它的灵活配置能力是把双刃剑，业务人员可以快速搭应用，技术人员的管控也容易被绕过。

选型阶段把这六个问题搞清楚，能筛掉市面上至少80%不合格的供应商。但剩下的20%，能不能用好，还是要看甲方自己的安全运营能力。安全选型这事，宁可慢三个月选对，不要快三周选错。