LLM安全设计：在开发每个阶段融入安全考量
随着大型语言模型(LLM)在企业和应用中的日益普及，对强大安全措施的需求变得前所未有的重要。如果未能妥善保护，LLM可能在数据泄露、模型操纵甚至监管合规问题方面构成重大风险。这就是与外部安全公司合作变得至关重要的原因。
在本博客中，我们将探讨公司雇佣安全团队评估和保护其LLM驱动系统时的关键考量因素，以及在LLM开发生命周期不同阶段应执行的具体任务。
阶段0：托管模型（物理与云）
托管模型的选择，无论是物理还是基于云，都会对大型语言模型(LLM)的安全性产生重大影响。每种方法都有其自身必须仔细评估的安全考量因素。
物理安全考量：
物理与数据中心安全 - 在物理基础设施上托管LLM模型会引入诸如未经授权的设施访问、盗窃或关键系统中断等风险。这些威胁不仅源于技术漏洞，还源于人为因素，如社会工程学或尾随进入。为减轻这些风险，应进行物理渗透测试。这包括模拟现实世界的入侵尝试（如冒充或绕过工作人员），以及评估物理屏障、监控系统、访问控制和环境保障措施（如电力和防火）的弹性。
网络安全 - 如果底层网络架构未得到良好保护，本地LLM部署特别容易受到外部网络攻击和内部威胁。配置错误的防火墙、暴露的服务或过于宽松的访问控制可能为利用打开大门。为主动应对这些风险，应进行全面的网络架构审查和安全评估。这包括评估分段、防火墙规则、VPN访问、入侵检测能力和访问控制，以确保LLM环境受到保护，免受外部和内部威胁。
供应链风险 - 本地托管的LLM模型严重依赖硬件组件，如果从未经验证或不可信的供应商采购，可能会引入风险。受损的芯片、恶意固件或被篡改的设备可能破坏整个系统的完整性。为降低此风险，安全团队应执行全面的供应链审查——评估采购实践、验证供应商可信度、物理检查硬件组件并验证固件/软件完整性——以确保基础设施没有嵌入式威胁并遵循安全采购原则。
基于云的托管安全风险：
云配置错误 - 当LLM托管在云中时，安全状况在很大程度上取决于云服务的配置方式。与组织对硬件和网络层拥有完全控制的物理环境不同，云环境引入了抽象——随之而来的是不同的风险集。配置错误的资源，如开放的S3存储桶、过于宽松的IAM角色或未受保护的API端点，可能暴露敏感的训练数据、模型工件或凭据。为解决此问题，安全团队应进行全面的云配置审查。这涉及审计存储权限、身份和访问管理策略、网络安全设置和暴露的端点，以识别和修复可能导致未经授权访问或数据泄露的错误配置。
共享责任模型错位 - 云安全最重要且经常被忽视的方面之一是理解共享责任模型。与组织拥有完整安全堆栈的物理托管相比，云提供商保护基础设施，而客户负责保护其数据、应用程序和配置。对这种分工的误解可能导致未受保护的资产或安全覆盖盲点。安全团队可以通过明确划分责任、制定正确的安全控制集以及实施确保LLM环境所有组件（特别是客户管理的组件）得到适当保护的过程来提供帮助。
内部威胁 - 尽管罕见，但云提供商员工可能滥用特权访问的风险存在。为解决此问题，组织应强制执行强加密和基于角色的访问控制，并实施详细的监控和审计日志记录。安全团队可以通过验证敏感数据在静态和传输过程中是否加密，以及提供商方的任何访问是否透明且被记录来提供协助。
监管合规 - 在云中托管LLM可能基于行业和地理位置（如GDPR、HIPAA等）引入额外的监管要求。安全团队应评估监管义务并设计合规框架，包括数据驻留控制、加密策略、访问审计和违规响应程序。这确保LLM环境符合法律标准和行业最佳实践。
在评估LLM的托管模型时，组织应仔细评估与物理和基于云的方法相关的安全风险和控制。对安全影响以及组织的特定要求和约束的透彻理解对于确定最合适的托管解决方案至关重要。无论使用物理还是云托管模型，以下阶段均适用。
阶段1：数据治理
大型语言模型的质量直接与其训练数据的质量相关。虽然数据治理通常是数据科学和工程工作，但安全风险仍可能出现。从安全角度来看，这是审查数据源可信度并实施控制以保护模型免受投毒、隐私侵犯和偏见输出的关键点。
数据投毒风险 - 在未经验证或对抗性数据上训练可能向LLM引入隐藏漏洞、偏见甚至恶意行为。当使用公共互联网源或社区贡献的数据集时，这一点尤其令人担忧。安全团队应进行架构审查和/或威胁建模以评估数据摄取工作流。这些审查有助于识别恶意行为者可能插入投毒数据的弱点，并确保组织应用数据验证、域白名单和异常内容监控等控制措施。
隐私和合规违规 - 公共数据集通常包含用户生成的内容，这些内容可能包含个人可识别信息(PII)或其他敏感数据，可能导致监管不合规或隐私泄露。安全专业人员应与数据团队密切合作，审查管道的隐私编辑和过滤机制。这涉及验证基于规则和基于分类器的工具是否到位以检测和删除PII，并定期审计这些过程的有效性。
嵌入层投毒 - 即使在标准清理后，对抗性输入仍可能通过嵌入层持续存在——引入模型解释某些内容方式的微妙变化。虽然难以检测，但可以通过研究驱动的对抗性评估或与专注于LLM嵌入行为的红队协调来减轻这种新兴风险。安全应参与有关高风险模型的标记器设计和嵌入鲁棒性的讨论。
阶段2：模型架构
在此阶段，组织正在选择和/或设计将定义LLM如何学习和生成输出的神经架构。大多数现代LLM基于Transformer架构构建。虽然这些架构决策主要是技术性的，但它们带有重大的安全影响。如果未加检查，在模型层引入的漏洞，特别是在开源模型中，可能成为永久性、持续性的威胁。尽管此阶段传统上可能不涉及安全专业人员，但早期纳入他们能够实现对深度嵌入风险的先发制人防御。
后门模型组件 - 如果攻击者在训练期间获得访问权限或修改开源模型，他们可能直接向模型架构引入恶意行为。例如，基于Transformer的模型中的修改解码器层可能被设计为在由某些提示触发时输出特定的后门内容。为减轻此问题，安全团队应进行专注于模型完整性的架构审查。这包括验证训练来源、审查关键模型层的未经授权更改，以及在受控测试提示中检查可疑行为。
模型完整性与开源信任 - 许多组织利用开源模型加速开发。然而，如果这些模型的训练数据、架构或修改历史不透明，它们可能带有信任问题。安全团队应实施模型审查和审计工作流，以在模型部署或进一步微调之前验证来源、训练谱系和任何预先应用的修改。
安全增强架构选择 - 虽然大多数团队专注于准确性或效率，但某些架构选择可以增强安全性。例如，集成异常检测模块或设计模型以支持对抗性训练可以提高对未来攻击的弹性。安全专业人员应在早期设计对话中建议或推荐以安全为重点的架构组件——特别是在高风险或安全关键部署中。
阶段3：规模化训练
当LLM进行规模化训练时，如果安全团队之前进行了彻底的架构审查和威胁建模，他们需要做的事情就不多了。他们应专注于确保训练过程本身的安全和稳定：
- 审查训练基础设施的安全性 - 评估为保护训练环境免受未经授权访问或中断而实施的物理、网络和访问控制。
阶段4：评估
在评估阶段，使用基准数据集评估LLM的性能，以衡量其在不同任务中的知识、推理和准确性。常见基准包括Hellaswag（常识推理）、MMLU（领域特定知识）和TruthfulQA（真实性和误解抵抗）。虽然这些工具对于衡量一般性能很有用，但它们也为安全风险引入了独特的攻击面。在此阶段，安全专业人员主要专注于确保评估实践可靠、无污染且不受操纵。
评估污染 - 攻击者可能尝试通过将基准问题（例如来自Hellaswag或MMLU）插入模型的预训练语料库来操纵评估过程。如果未被检测到，这可能显著夸大基准分数并给出模型质量的错误印象。安全团队应与ML工程师合作实施基准污染检测——验证在训练期间没有评估数据被泄露或记忆。
评估者和基准的信任 - 并非所有基准都是平等的，有些可能缺乏严谨性或透明度。依赖构建不良或过于狭窄的基准可能导致误导性的性能指标。安全专业人员应帮助审查评估工具和数据集，确保它们来自可靠来源、维护良好并与组织的目标和风险承受能力保持一致。
评估过程完整性 - 如果未得到适当保护，评估脚本、数据集和评分逻辑可能被篡改。安全团队应审查评估基础设施，确保访问受限、版本控制到位，并且结果可重现和可审计，以保持对结果的信任。
阶段5：后期改进
随着LLM超越其基础训练成熟，团队通常通过微调、检索增强生成(RAG)和提示工程来增强它，以提高性能、引入领域专业知识或集成实时知识。虽然这些改进释放了强大能力，但它们也创造了新的安全顾虑——特别是在涉及敏感数据或策略执行时。在此阶段，安全团队的角色是评估这些技术的实施方式，并确保访问控制、响应处理和道德保障在此过程中不受损害。
微调风险 - 在没有适当防护措施的情况下对敏感或专有数据微调模型可能无意中向最终用户暴露机密信息。例如，在没有聊天级访问控制的情况下对内部政府报告或客户记录微调模型可能导致未经授权的披露。安全团队应审查微调数据集，并确保在模型输出上强制执行访问控制边界，特别是在模型部署在多用户环境中时。
RAG集成配置错误 - RAG（检索增强生成）通过从自定义知识库检索上下文扩展LLM的知识，但如果在检索层未实施访问控制，敏感数据可能被泄露。例如，如果RAG系统不加选择地检索文档，一个用户可能能够访问另一个用户的财务数据。安全团队应评估RAG实施的访问控制执行、文档范围和检索内容的可审计性。
微调后的RAI（负责任AI）发现 - 虽然微调可以加强模型安全性，但它也可能使检测不良行为或策略违规变得更加困难，特别是如果模型学会了微妙地避免检测。安全专业人员应与RAI团队合作测试对抗性提示绕过和边缘案例安全违规，即使在已为对齐进行微调的模型上。
提示工程攻击面 - 设计不良的提示或系统指令可能导致意外的模型行为或创建提示注入漏洞，特别是在模型集成到应用程序中时。虽然提示工程通常被视为低风险技术，但安全团队应审查系统提示和应用程序级提示构建，以确保它们对对抗性输入具有弹性并且不覆盖关键安全行为。
阶段6：API集成
在生命周期的此点，LLM从被动聊天机器人转变为可以通过API与现实世界应用程序和服务交互的主动系统组件。无论是重置密码、检索内部数据还是处理用户请求，API集成引入了显著的新能力——以及相应的风险。从安全角度来看，这是传统API安全原则与LLM特定关注点（如提示注入、间接执行和意图操纵）融合的阶段。随着LLM驱动的应用程序开始代表用户做出决策和行动，这成为进攻性测试最关键阶段之一。
认证和授权问题 - 随着LLM开始触发API调用，验证只有授权用户才能执行敏感操作至关重要。安全团队应确保强认证（如OAuth、API密钥）和范围权限到位，以便模型不能代表未经授权用户执行特权操作。
提示注入和API滥用 - LLM解释自然语言并根据用户输入决定调用哪个API。攻击者可能尝试操纵提示以触发意外或有害行为。安全团队应测试提示注入漏洞，确保模型不能被欺骗调用错误的API或绕过安全检查。
缺乏输入验证 - 如果传递给API的用户输入未得到适当验证，它们可能导致错误、数据泄露甚至注入攻击。安全团队应确认中间件和API层验证和清理所有输入，无论它来自用户还是LLM。
过度暴露的功能 - API可能暴露比LLM所需更多的功能，增加滥用风险。安全应强制执行最小特权原则，仅给予模型真正需要的端点访问权限。
相关OWASP LLM风险 - 此阶段的许多风险与OWASP顶级风险一致。安全专家应参考该列表作为测试指南。
结论
保护LLM是一个复杂多面的挑战，需要全面、分阶段的方法。通过与经验丰富的安全团队合作，公司可以应对LLM开发和部署的独特安全考量，确保其模型稳健、可靠并符合相关法规和行业标准。通过从一开始就优先考虑安全，组织可以释放LLM的全部潜力，同时保护其数据、系统和声誉。