文章总结： 本文详细介绍了AI安全平台如何落地等保三级合规，包括身份认证、访问控制、审计日志等九大控制项的代码实现，以及国密算法SM2/SM3/SM4的全链路应用。核心是POC沙箱的四层纵深防护：AST静态分析、关键字黑名单、Docker容器隔离和运行时守卫，确保执行AI生成的攻击代码时安全可控。还涵盖前端XSS防护、安全基线自检、配置加密等实践，并总结出失败关闭、纵深防御、密钥外部化等可操作原则。最后指出AI平台特有的合规挑战：模型输出安全性和数据流向可控性。 综合评分： 95 文章分类： 安全建设,解决方案,应用安全,数据安全,云安全

合规不是口号：等保三级落地与 POC 沙箱的安全设计

河北镌远 河北镌远

河北镌远网络科技有限公司

2026年7月9日 15:00 河北

在小说阅读器读本章

去阅读

这是一个充满张力的命题：一个专门用来生成漏洞验证代码（POC）、研究攻击绕过手法的平台，它本身的安全性必须做到极致。因为它处理的是最敏感的漏洞信息、运行的是最危险的攻击代码——如果平台自身被攻破，或者 AI 生成的恶意代码逃逸出沙箱，后果不堪设想。所以这一篇，我们专门来讲「安全平台自己的安全」：等保三级合规如何落到代码，国密算法如何贯穿全链路，以及那个核心中的核心——POC 执行沙箱。

一、等保三级：从「文档要求」到「代码现实」

等保三级（网络安全等级保护第三级）是国内信息系统安全的重要合规基线，对身份认证、数据加密、访问控制、审计日志等都有明确要求。但合规最大的难点，从来不是「知道要求是什么」，而是「把要求真正落到每一行代码里」。平台把等保三级拆解成九大可落地的控制项，逐一在代码层面实现。

图 1：等保三级合规九大控制项的代码级落地

身份认证与会话管理

平台基于 Sa-Token 框架实现认证，并按等保三级要求做了强化：会话超时强制设为 30 分钟、禁止并发登录（同一账号不能多处同时在线）、登录失败达到阈值后锁定账号。会话 Cookie 设置了 Secure、HttpOnly、SameSite 属性，登录后重新生成会话 ID，退出时彻底销毁会话。这些配置看似琐碎，却是防止会话劫持、撞库攻击的基本功。

  application.yml · Sa-Token 会话配置

sa-token:

  timeout: 1800            # 会话超时 30 分钟

  activity-timeout: 1800   # 30 分钟无操作过期

  is-concurrent: false     # 禁止并发登录（等保三级）

访问控制：注解驱动的细粒度权限

平台用 @SaCheckPermission 注解实现接口级的细粒度权限控制。比如新增 POC 需要 ai:poc:add 权限、导出需要 ai:poc:export 权限。在一次安全加固中（对应迭代记录 Phase 1），平台为 VerifyController 的 13 个端点、WorkflowController 的 14 个端点补齐了权限注解——这类「补齐每一个端点的权限校验」的工作枯燥但极其重要，任何一个遗漏的端点都可能成为越权访问的入口。

审计日志：365 天的留存底线

等保三级对审计日志的留存有硬性要求。平台用 logback 的 SizeAndTimeBasedRollingPolicy 实现日志轮转，并区分了不同级别的留存策略：普通信息日志（sys-info）保留 30 天，而 审计日志（sys-audit）保留 365 天。每个日志文件最大 100MB，自动按天和大小双重轮转，既满足合规留存，又避免单个文件无限膨胀。

二、国密算法：自主可控的密码体系

在合规体系中，密码算法的「自主可控」是重中之重。平台全面采用国密算法（SM2/SM3/SM4），构建了一套覆盖传输、签名、校验的完整密码体系。

图 2：国密算法 SM2/SM3/SM4 的全链路应用

SM4：前后端通信的对称加密

所有前后端之间的敏感数据传输，都用SM4-CBC 模式加密。具体来说，所有 POST/PUT 请求的请求体都需要先用 SM4 加密、再 Base64 编码后传输，响应同理需要解密。前端在 gwxyWeb 的请求拦截器里完成加解密，后端则有对应的解密过滤器。密钥和 IV 都通过环境变量注入，支持定期轮换，绝不硬编码在代码里。

SM2：数字签名与身份认证

SM2 作为非对称算法，用于数字签名和身份认证。这里有一个体现安全态度的设计细节（对应迭代记录 Phase 1 第 25 条）：当 SM2 签名所需的密钥缺失时，平台会 直接抛异常拒绝启动，而不是「静默降级」成不签名运行。这个选择很关键——很多系统为了「可用性」会在密钥缺失时悄悄关闭安全功能，结果是安全形同虚设却无人察觉。平台宁可启动失败，也不带病运行。

SM3：完整性校验

SM3 哈希算法用于数据完整性校验和数字签名，替代了存在安全隐患的 MD5、SHA-1。三种国密算法各司其职，共同构成了符合 GM/T 标准、通过密评三级的密码基础设施。

安全设计的一条铁律：缺失安全配置时，应当「失败关闭（Fail-Closed）」而非「失败开放（Fail-Open）」。平台在 SM2 密钥缺失时拒绝启动，正是这条铁律的忠实践行。

三、POC 沙箱：让攻击代码「插翅难逃」

现在我们来到这一篇、乃至整个平台最核心的安全设计——POC 执行沙箱。回顾一下场景：大模型会生成 Python 编写的 POC 脚本，这些脚本本质上是「攻击代码」，需要真实执行才能完成验证。但「执行 AI 生成的攻击代码」这件事本身充满风险——万一模型被诱导生成了恶意代码（反弹 shell、删除文件、横向移动）怎么办？沙箱就是回答这个问题的答案。

平台的沙箱不是单一的「一道墙」，而是多层纵深防护——即使某一层被突破，后面还有层层防线。我们自上而下看这四层。

图 3：POC 执行沙箱的四层纵深防护体系

第一层：AST 静态分析

在代码运行之前，先做静态检查。平台用 AST（抽象语法树）解析 POC 代码，检查其中是否包含危险操作——比如 eval、exec 这类动态执行函数，或者 import sys 这类可能被用来注入恶意行为的导入。一旦发现危险结构，直接拒绝执行，代码连运行的机会都没有。这是成本最低、最早拦截的一道防线。

第二层：关键字黑名单

AST 之后，再做一层关键字黑名单过滤。针对那些 AST 难以覆盖、或者以字符串形式隐藏的危险操作，用黑名单兜底：反弹 shell 相关的（http.server、socketserver、pty.spawn）、数据破坏相关的（rm -rf、mkfs）等等，命中即拒绝。

工程细节：在一次沙箱加固中（迭代记录 Phase 1 第 24 条），平台移除了 socket、threading 的白名单，修复了 import 检测的正则表达式，并移除了一处 import sys 注入。安全加固从来不是一劳永逸，而是持续地堵住每一个新发现的缝隙。

第三层：Docker 容器隔离

通过了静态检查的代码，会被放进一个Docker 容器 里隔离执行。容器对资源做了严格限制：限制 CPU、限制内存、网络隔离（无外网访问）、文件系统只读。这意味着即使代码绕过了前两层、真的开始运行，它也被困在一个资源受限、无法联网、无法写入宿主机文件的「笼子」里，能造成的破坏被压缩到极小。

第四层：运行时守卫

最后一层是运行时的动态守护。平台为 POC 执行设置了 可配置的超时（不同漏洞类型可以有不同的超时时间），超时后强制终止进程。更进一步，针对「进程被杀但子进程残留」的僵尸进程问题（迭代记录 Phase 4 第 37 条），平台用 Java 的 ProcessHandle API + destroyForcibly() 做了强制清理，确保不留下任何残留进程。执行过程中的所有输出，还会通过实时回调推送给前端（SSE），并完整记录到日志文件，做到可审计、可追溯。

  PocExecutionServiceImpl.java · 运行时守卫

// 超时强杀 + 僵尸进程清理

boolean finished = process.waitFor(timeout, TimeUnit.SECONDS);

if (!finished) {

    process.destroyForcibly();           // 强制销毁主进程

    process.descendants()                 // 递归清理所有子进程

           .forEach(ProcessHandle::destroyForcibly);

}

四、前端也是战场：XSS 防护

安全不只在后端。AI 平台会把大量模型生成的内容（POC 代码、分析结论、对话回复）渲染到前端页面，如果直接用 innerHTML 渲染，就给了 XSS（跨站脚本攻击）可乘之机。平台在前端做了对应加固（迭代记录 Phase 1 第 26 条）：用业界标准的 DOMPurify 替换了原本可能被绕过的正则净化，对 Text、AIChat、FilePreviewer 等组件的渲染内容做严格净化。同时，管理端的 API 调用也从原生 fetch 统一换成了带安全策略的框架 requestClient。

五、合规的「自检」能力

做了这么多合规建设，怎么证明它们真的生效了？平台还设计了安全基线自检 能力（SecurityBaselineController），可以对照等保三级的各项要求，自动检查当前系统的配置是否达标——比如加密是否启用、审计是否开启、安全头是否设置。在一次修复中，平台还专门修正了自检逻辑中 @Value 默认值的问题，确保自检结果真实反映系统状态，而不是被错误的默认值误导。

合规的最高境界，是把「检查」也自动化。让系统能持续地自我体检，比依赖一年一次的人工审计要可靠得多。

六、配置加密：连配置文件都不放过

等保合规有一个常被忽视的角落：配置文件里的敏感信息。数据库密码、Redis 密码、各类密钥，如果以明文形式躺在 application.yml 里，一旦配置文件泄露（误提交到代码仓库、服务器被入侵），等于把家门钥匙直接交了出去。平台对此的处理是双管齐下。

其一，敏感配置外部化：所有密码、密钥都不写死在配置文件里，而是通过环境变量注入。配置文件里只保留 ${DB\_PASSWORD} 这样的占位符，真实值在部署时由环境提供。代码仓库里看不到任何一个真实密码。其二，对于必须留在配置里的敏感值，用 Jasypt 做加密，以 ENC(密文) 的形式存储，运行时用主密钥（同样由环境变量注入）解密。加密算法选用了 PBEWithHmacSHA512AndAES_256 这样的强算法。

一条朴素但常被违背的安全准则：代码仓库里永远不应该出现任何一个真实的生产密码。把密钥外部化、把配置加密，是守住这条准则的两道闸门。

七、纵深防御的哲学：假设每一层都会失守

如果要给这一篇提炼一个核心思想，那就是纵深防御（Defense in Depth）。它的精髓不是「造一道坚不可摧的墙」，而是「假设每一道墙都可能被突破，所以要造很多道墙」。这种「悲观」的假设，恰恰是安全设计中最「乐观」的策略。

回看 POC 沙箱的四层防护就是最好的例证：AST 静态分析可能有覆盖不到的写法，那就用关键字黑名单兜底；黑名单可能被新的混淆手法绕过，那就用 Docker 隔离限制破坏范围；容器万一存在逃逸漏洞，还有资源限制、网络隔离、文件只读和运行时超时在层层设防。任何单独一层都不是百分百可靠的，但四层叠加，让「危险代码成功逃逸并造成实质破坏」的概率，被压到了极低。

同样的哲学也贯穿在合规设计里：身份认证防不住的，访问控制再拦一道；访问控制万一被绕过，审计日志还能事后追溯定责；数据传输被截获了，SM4 加密让攻击者拿到的也只是密文。每一层都假设前一层可能失守——这种层层冗余，看似「浪费」，实则是安全的本质。

八、给开发者的安全清单

      把这一篇的实践沉淀成一份可对照的清单，无论你做的是不是安全平台，这些原则都值得参考。

● 失败关闭：安全配置缺失时，宁可拒绝启动，也不要静默降级成不安全的运行状态。

● 纵深防御：不依赖任何单一防线，假设每一层都可能失守，用多层冗余把风险压到最低。

● 密钥外部化：代码和配置文件里永远不出现真实密码，一律通过环境变量注入。

● 最小权限：每个接口都加权限校验，每个容器都限制资源，能不给的权限就不给。

● 可审计：关键操作全程记日志，审计日志长期留存，让任何行为都可追溯。

● 自动自检：把合规检查也自动化，让系统能持续地自我体检，而不是依赖一次性的人工审计。

九、结语

      这一篇，我们走进了 AI 安全平台「自身安全」的内核：等保三级的九大控制项被逐一落到代码——从会话管理到细粒度权限、从审计留存到安全头部；国密 SM2/SM3/SM4 构建起自主可控、失败关闭的密码体系；而四层纵深的 POC 沙箱，则让「执行 AI 生成的攻击代码」这件危险的事，变得安全可控。

一个深刻的体会是：安全平台对自身的要求，必须比它服务的对象更高。它处理最敏感的数据、运行最危险的代码，所以它必须把「纵深防御」「失败关闭」「持续加固」这些原则，刻进每一层设计里。下一篇，也是连载的收官篇，我们会回到工程性能的主线，聊聊Java 21 虚拟线程与异步编程——在「高并发 + 长耗时」的 AI 场景下，平台是如何用现代 Java 的新特性，扛住成百上千并发的。

▍附：当 AI 遇上合规，多出来的两道考题

      传统系统的合规，业界已经有成熟的方法论。但「AI 平台」的合规，比传统系统多出了两道独特的考题，这是我们在这个项目里体会很深、也认为值得专门提出来的地方。

第一道考题：AI 生成内容的安全性。 传统系统处理的是「用户输入」，而 AI 系统还要处理「模型输出」。模型输出是不可控的——它可能生成危险代码、可能泄露训练数据、可能被诱导说出不该说的话。平台的输入安全守卫管住了「输入端」，而 POC 沙箱、前端 DOMPurify 净化管住了「输出端」。在 AI 时代，「输出」和「输入」一样，都是必须严防死守的攻击面——这是传统安全模型里没有的新维度。

第二道考题：数据流向的可控性。 AI 推理需要把数据喂给模型，如果用的是外部 API，敏感数据就流出了边界。平台坚持本地部署模型（通过 Ollama），让所有漏洞信息、内网资产数据全程不出内网，从根上杜绝了数据外泄的可能。对于处理敏感数据的行业（金融、政务、能源、安全），「模型在哪里推理」这个看似技术性的选择，其实是一道合规的红线。

AI 合规 = 传统合规 + 模型输出安全 + 数据流向可控。前者有章可循，后两者是 AI 时代的新课题，也是每一个严肃的 AI 平台无法回避的责任。

把这两道新考题和传统的等保九项放在一起看，你就能理解为什么这个平台要在安全上投入如此之多——因为它不只是一个普通的业务系统，而是一个「处理最敏感数据、运行最危险代码、还要驾驭不可控 AI 输出」的三重高危系统。对它而言，安全不是锦上添花的功能，而是生存的前提。这份对自身安全的极致要求，恰恰是它有资格去为别人做安全的底气所在。

免责声明：因传播、利用本公众号“河北镌远网络科技有限公司”所提供信息而产生的任何直接或间接后果及损失，均由使用者本人自行承担，本公众号及作者不承担任何责任。本公众号所发表内容中，凡注明来源的，版权归原出处所有；无法查证版权或未注明出处的，均来自网络并系转载，转载旨在传递更多信息，版权归原作者所有。若存在侵权情况，请联系小编，我们将第一时间删除处理。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：河北镌远网络科技有限公司 河北镌远 河北镌远《合规不是口号：等保三级落地与 POC 沙箱的安全设计》