『专题报告』| 《大模型安全密码应用白皮书(2025)》解读:从基础设施到参数防护的安全体系深度研究 · 白皮书解读 从基础设施到参数防护的安全体系 大模型安全密码应用白皮书（2025）解读（二） 聚焦基础设施、训练推理、迭代更新与参数资产保护 ? 2026年5月 · 白皮书解读系列 ▎本周导语在很多大模型项目中，团队最先投入精力的往往是模型效果、业务适配和算力成本。但从公开实践来看，真正决定项目能否长期稳定运行的，往往不是回答质量本身，而是其背后整套基础设施、训练流程、更新机制与资产保护体系是否足够稳健。大模型安全并不是在接口外层加几道拦截规则，也不是仅靠内容审核就能完成的工作。它更像一项系统工程，需要同时回答几个问题：运行环境是否安全，训练与推理是否可信，模型更新是否可控，参数资产是否得到保护，跨组件协同是否存在隐蔽风险。只有把这些问题串起来，组织才可能真正建立起可持续的大模型安全防线。本文将从基础设施安全、可信执行环境、部署模式差异、算法与框架安全、训练推理风险、迭代安全和参数安全几个层面展开，讨论大模型安全体系到底应该如何建设。 一、大模型安全建设，为什么不能只盯应用层 在不少组织的认知中，大模型安全往往被等同于“防止违规回答”“控制输出内容”或“避免接口被滥用”。这些工作当然重要，但它们更像是安全体系的可见部分，而不是全部。真正的大模型风险，往往在应用层之外就已经埋下：依赖组件存在漏洞，训练数据遭遇污染，部署环境权限失衡，模型更新过程缺乏审查，参数资产缺少隔离，这些问题都可能在尚未暴露到最终用户之前，就已经削弱系统的安全基础。因此，安全建设如果只停留在接口层或内容层，往往只能缓解表面症状，难以应对底层结构性风险。更稳妥的做法，是把大模型安全理解为覆盖基础设施层、模型层与应用层的分层治理体系。 从工程视角看，大模型安全建设的第一原则不是“哪里最显眼就先堵哪里”，而是“哪里最基础就先稳哪里”。 二、基础设施安全：先把运行地基打牢 大模型系统通常依赖主机、容器、调度平台、网络访问、存储服务和密钥管理等多种基础设施共同运行。与传统业务系统相比，它对算力资源、数据流转和多组件协同的依赖更强，这也使得基础设施层成为最容易被忽视、却最值得优先加固的部分。 框架安全运行框架的重要性 一个成熟的大模型运行框架，不只是能够把模型部署起来，更要保证网络边界清晰、访问权限受控、日志留痕完整、关键资源调用可追踪。主机环境、容器环境、GPU 调度环境和服务编排体系中的任一环节出现配置失当，都可能成为攻击入口或故障放大点。 风险基础环境中的典型风险 公开实践中较常见的问题包括：容器逃逸、弱口令或过大权限、网络分区不清、训练节点与业务节点混用、日志审计不完整、密钥散落在配置文件或脚本中等。对大模型系统而言，这些问题的风险往往高于普通应用，因为一旦底层失守，攻击者接触到的往往不仅是应用逻辑，还包括训练数据、模型文件和推理接口。 策略基础设施层的防护思路 更稳健的建设思路，是围绕最小权限、环境隔离、统一密钥管理、关键路径审计、网络分域和配置基线治理建立基础规则。换言之，要先让模型运行在一个足够可信的地基之上，再去谈更复杂的模型防护和应用治理。 三、可信执行环境：保护敏感数据与关键计算过程 如果说存储加密保护的是“静态数据”，传输加密保护的是“传输中的数据”，那么可信执行环境和机密计算所回应的，就是长期以来更难解决的“运行中的数据与计算如何被保护”的问题。对于大模型而言，这一点尤为关键，因为训练和推理过程本身往往会直接接触敏感数据、私有知识和高价值参数。在高敏感行业、跨组织协作和受监管场景中，可信执行环境的价值主要体现在两点：一是帮助组织提升对运行态数据的控制能力，二是为“可计算但不可窥探”的场景提供可行路径。从长期趋势看，这类能力与密码技术结合后，将越来越多地成为大模型安全体系中的关键支撑点。 四、不同部署模式下的大模型安全差异 从部署角度看，云端、本地和混合模式各有优劣，也各自伴随不同的安全重点。云端部署的优势在于弹性与规模化，但多租户环境、外部暴露面和权限配置复杂度较高；本地部署更强调边界可控，但并不意味着天然安全，内部运维能力、补丁节奏和权限治理同样会决定其实际风险水平；混合部署最贴近现实业务，却也最容易出现身份体系不统一、数据边界模糊和审计链断裂的问题。因此，部署模式的选择不应只从性能和成本出发，更应结合数据敏感度、业务连续性要求和治理能力进行统筹判断。没有绝对安全的部署方式，只有更匹配场景的安全治理方案。 五、模型内生安全之一：算法与框架安全 在大模型时代，框架和依赖生态本身就是安全边界的一部分。深度学习框架、加速库、推理引擎、第三方插件和依赖组件不仅决定模型能否跑起来，也影响模型是否会在运行过程中暴露额外风险。版本冲突、恶意依赖、组件漏洞和兼容性问题，看似是工程细节，但在生产环境中往往会直接转化为稳定性风险甚至安全漏洞。更可靠的治理方式，是把算法安全与工程治理结合起来：建立依赖基线、明确版本策略、持续进行供应链审查，对核心框架与关键组件进行风险评估与更新控制。换言之，模型安全并不只在参数层，也发生在它所依赖的每一层软件栈中。 六、模型内生安全之二：训练与推理过程的风险 数据投毒 数据投毒会直接污染模型的认知基础，使其在看似正常的输入下产生偏置、错误关联或隐蔽后门。这类风险之所以难防，在于它常常发生在数据进入训练流程之前或之中，一旦进入训练结果，后续识别和修复成本通常较高。 隐私泄露 隐私泄露既可能来自训练数据被模型记忆，也可能发生在推理调用、日志记录、上下文缓存或接口回传过程中。对于政务、金融、医疗等高敏感场景而言，这类风险不仅带来合规压力，更可能破坏用户与组织之间的基本信任。 提示词攻击 提示词攻击是当前最具现实性的风险之一。攻击者不需要掌握底层权限，只需要通过精心构造的输入，就有机会诱导模型越权、绕过限制、泄露内部提示或执行偏离预期的操作。正因为门槛较低，这类攻击更值得在工程层面被持续关注。 模型幻觉与应对思路 模型幻觉并非单纯的准确率问题，而是业务可信问题。在关键行业中，错误内容可能导致误判、误用甚至责任争议。更现实的应对路径，不是期待某一种技术完全解决所有问题，而是通过数据治理、训练约束、推理防护、输出审核和人工复核等多层机制协同控制风险。 七、模型内生安全之三：迭代更新带来的持续风险 大模型不是一次训练完成后就永久稳定的系统。随着增量数据注入、微调任务叠加、领域知识持续更新，新的风险也会不断进入模型迭代链路。增量数据攻击、领域知识误导和错误知识传递，都是在更新过程中容易被低估的问题。因此，组织不能只重视首版模型上线前的安全检查，还应建立面向版本迭代的安全治理机制，包括数据来源审查、更新流程审批、微调结果验证、版本回滚能力和变更审计。只有把“迭代安全”纳入治理体系，大模型安全才不会在持续优化过程中被逐步削弱。 八、模型内生安全之四：参数安全已成为核心战场 在大模型时代，参数既是模型能力的承载体，也是企业知识和工程投入的浓缩结果。参数被窃取，意味着核心能力和商业价值可能被直接带走；参数被篡改，则可能引入更隐蔽的风险，例如输出偏移、行为异常或后门触发。相比普通文件泄露，参数安全问题的影响更深、暴露更晚、修复更难。 如果说数据是大模型的“燃料”，那么参数就是其“发动机”。在企业级场景中，参数保护的重要性，正在快速逼近甚至接近数据保护本身。 因此，参数保护不应被视为附属措施，而应成为高优先级事项。更稳健的实践包括参数加密、访问隔离、完整性校验、密钥联动控制、推理节点权限最小化与关键操作审计等。只有把参数安全提升到资产保护层面，大模型安全体系才算真正闭环。 九、结语 从基础设施到参数防护，大模型安全建设的核心并不是部署几个安全产品，而是建立一套覆盖运行环境、训练推理、版本迭代与核心资产的整体治理体系。对于组织而言，真正值得投入的，不是“哪里出事就修哪里”的被动防守，而是分层建设、持续运营、全生命周期治理的安全能力。未来，大模型工程化能力将越来越依赖安全工程化能力。谁能更早把安全嵌入架构、流程和资产管理之中，谁就更可能把大模型从“可演示”推进到“可长期使用”。 附录：引用参考 1. 《大模型安全密码应用白皮书（2025）》｜ 关注三未信安官方公众号，回复 “白皮书” 获取领取方式2. 生成式人工智能服务管理暂行办法｜https://www.miit.gov.cn/zcfg/qtl/art/2023/art_f4e8f71ae1dc43b0980b962907b7738f.html3. 互联网信息服务深度合成管理规定｜https://www.miit.gov.cn/zcfg/xxtxl/art/2023/art_2f2790829e49443ba20a8a2f6d5b45dc.html4. 标准全文 | GB/T 45654—2025《网络安全技术 生成式人工智能服务安全基本要求》｜https://www.tc260.org.cn/portal/article/1/202506301222325. TC260-003《生成式人工智能服务安全基本要求》｜https://www.tc260.org.cn/upload/2024-03-01/1709282398070082466.pdf6. 人工智能安全治理框架（V1.0）｜https://www.tc260.org.cn/upload/2024-09-09/1725849142029046390.pdf ━━━━━━━━━━━━━━━━━━━━━━━━? 参考资料本文基于公开信息整理，仅供行业研究与交流参考，不构成投资、采购、授信或合作建议。全文引用来源均已在末尾附录中列明（含标题与链接），可自行访问核实。
