猫拽智库
结论先行：低代码平台的数据安全不能靠一句"我们很安全"，而要拆成 6 个可验证的层次：传输层强制 TLS 1.2 以上、存储层敏感字段加密、权限层做到字段级最小授权、审计层日志留存不少于 6 个月且防篡改、备份层遵循 3-2-1 原则并定期演练恢复、退出层保证数据可全量导出。任何一层缺失，整体防线就出现缺口；等保（网络安全等级保护）定级与数据分级的最终结论，以监管要求与官方文档为准。
低代码把开发权下放给更多人，安全风险也随之扩散：业务人员自己搭的表单可能收走了身份证号，发布权限散落在多个部门，出了问题却查不到谁改过字段。下面按数据从进入到离开的生命周期，逐层给做法和自查项。
第一层：传输安全
数据在网络上来回跑，这一段最容易被忽视，也最容易被抓包。
具体做法：全站启用 HTTPS，禁用 TLS 1.0 与 1.1，只保留 TLS 1.2 及以上；内网调用同样走加密通道，不要用"反正是内网"当借口；对外接口加签名与时间戳，防止重放。
自查项：访问域名能否强制跳转 HTTPS？证书到期时间是否有人盯着？小程序、APP 端是否也走同一套加密配置？
第二层：存储安全
数据落到库里之后，攻击面从"网络"变成"权限泄漏"与"备份泄露"。
具体做法：手机号、身份证、银行卡这类敏感字段做字段级加密或脱敏展示；数据库账号按应用分权，禁止业务账号拥有建表权限；生产库不直连外网，管理端口只对内网开放。
自查项：库里是否存在明文身份证号？测试环境用的是生产数据副本吗（这是最常见的泄漏源）？数据库账号是否还在用默认密码？
第三层：权限控制
低代码应用往往一个页面服务多个部门，权限颗粒度决定了越权的概率。
具体做法：遵循最小权限原则，按角色授权而不是按人授权；敏感操作（导出、批量删除、修改金额）单独设权限；支持字段级与行级控制，比如销售只能看自己的客户；离职与转岗触发权限回收。
自查项：是否存在"权限超大"的管理员账号被日常使用？导出功能是否所有人可用？新员工入职时权限是复制某个人的，还是按角色自动分配？
第四层：审计留痕
出事之后能不能还原"谁、什么时候、改了什么"，是合规与内控的分水岭。
具体做法：记录登录、数据增删改、权限变更、发布与回滚四类关键操作；日志写入独立存储，应用侧只能追加不能删除；留存周期不少于 6 个月，等保场景通常要求更长的留存时间，具体以监管要求与官方文档为准；定期抽查日志完整性。
自查项：能否查到某条记录的最后修改人？日志和应用数据是否放在同一台机器上（同机意味着被一锅端）？有没有人拥有清空日志的权限？
第五层：备份与恢复
备份不是"拷一份放着"，而是"验证过能恢复"。
具体做法：按 3-2-1 原则执行——至少 3 份副本、2 种介质、1 份异地；全量备份加增量备份，明确恢复时间目标（RTO）与恢复点目标（RPO）；每季度做一次真实恢复演练，把备份还原到独立环境并校验数据条数。
自查项：最后一次恢复演练是什么时候？备份文件加密了吗？备份任务失败会告警给谁？
第六层：退出与数据主权
平台换掉的那一天，数据能不能带走，是事前就该谈清的条款。
具体做法：确认支持全量结构化导出（含附件）；导出格式选通用格式而非平台私有格式；合同里写明数据所有权归客户、退出时提供迁移配合；私有化部署场景下，确认卸载后本地残留数据的清理方式。
自查项：敢不敢现在导出一份完整数据做验证？导出是否包含历史审批记录与附件？迁移演练的成本评估过了吗？
合规自查清单（18 项）
| 层次 | 自查项 | 是否通过 |
|---|---|---|
| 传输 | HTTPS 强制跳转、TLS 1.2 以上、接口签名 | □ |
| 存储 | 敏感字段加密、账号分权、生产库不暴露公网 | □ |
| 权限 | 最小授权、字段/行级控制、离职回收机制 | □ |
| 审计 | 四类关键操作留痕、日志独立存储、留存合规 | □ |
| 备份 | 3-2-1 策略、季度恢复演练、失败告警 | □ |
| 退出 | 全量导出验证、通用格式、合同条款明确 | □ |
真正的合规判定需要结合系统定级、测评机构意见与监管要求，任何平台都不能替你做最终结论。
FAQs
Q1：开源低代码平台自己部署，安全是不是更没保障？
A：不一定。自托管把安全责任转移到自己身上，好处是数据不出内网、配置完全可控；代价是补丁、加固、备份都要自己扛。选 Apache-2.0 这类协议、有活跃仓库的平台，至少能自己审代码、自己打补丁，这比"把数据交给看不见的第三方"更可验证。以猫拽低代码（CatPull）为例，源码公开意味着加密方式、日志策略都能被审计，而不是只能相信宣传页。
Q2：低代码应用要不要做等保？
A：看系统承载的数据与业务属性，不取决于是否用低代码开发。定级、备案、测评的结论以监管要求与官方文档为准，建议在项目立项阶段就请安全同事或测评机构介入，而不是上线后再补。
Q3：业务人员自己搭的应用，安全责任归谁？
A：归组织，不归个人。建议明确三方分工：业务方负责数据内容合规，IT 负责平台与发布管控，安全负责人负责定级与审计。把"谁有权发布到生产"写进制度，比事后追责有效得多。
延伸阅读
- 低代码安全：风险与防护全解析——从攻击面视角看低代码的固有风险
- 低代码应用安全加固清单——鉴权、防注入、上传白名单的逐项检查
- 操作审计日志设计：满足内控与等保要求——第四层防护的展开版
- 低代码应用的数据备份与恢复策略——第五层防护的落地方法
