自2022年ChatGPT发布以来，大语言模型（LLM）作为人工智能领域的关键技术趋势，驱动各行业加速推进系统智能化升级。企业积极尝试将LLM集成至自身系统，以期提升效率并优化用户体验。然而，LLM的引入不仅带来技术革新，也伴随显著的安全风险。由于缺乏系统性的安全指导与最佳实践，其潜在威胁尚未得到充分重视。为帮助各行业安全应用LLM技术，云安全联盟大中华区发布《基于大语言模型（LLM）的系统安全：关键授权实践》，依照常见的集成LLM的系统设计模式，提出了一系列最佳实践，并针对每种模式提出了相应的建议、注意事项和常见误区。

《基于大语言模型（LLM）的系统安全：关键授权实践》

本报告从授权的角度，探讨LLM带来的安全风险和应对方案。报告指出，LLM有两个特点：非确定性和缺乏独立控制和数据平面。这两个特点使得系统在集成LLM时面临授权和安全控制的挑战。

LLM的非确定性体现在LLM的输出是不确定的，这意味着，即使提供相同的的输入，集成了LLM的系统也有可能得到不同的输出。这种不确定性以为着我们无法以来LLM的输出来做授权决策的依据。

缺乏独立控制和数据平面体现在模型中，LLM并没有“代码”和“数据”的区分，因此，我们无法对模型权重中包含的信息提供细粒度的访问控制。报告提出了几点原则性的设定，作为后续探讨的基础：

•LLM产生的结果并不可靠

•授权策略的决策点和执行点应始终位于 LLM 之外

•LLM 永远不应负责执行认证检查

•针对LLM的攻击（如越狱和提示注入）始终成立

•应执行最小权限原则和按需访问

基于这些原则，报告从基于LLM的系统的组成部分入手，首先展开说明了LLM带来的相关挑战及注意事项，接下来，报告便从以下常见的基于LLM系统的架构设计模式出发，讨论了相关的最佳实践、注意事项、常见误区以及错误示例。

本报告旨在帮助工程师、架构师以及隐私和安全专业人士理解使用 LLM 构建系统时，与授权相关的独特风险和挑战。它强调了由于 LLM 的特性而需要做出的特殊考虑，并探讨了这些系统可能面临的挑战和常见误区。

如下图所示，通常情况下，基于LLM的系统包括了编排器、向量数据库、LLM缓存、验证器以及代表了系统内现存的各类服务的“内部服务”模块。这些模块承担不同的职责，也具有不同的安全风险。

基于LLM的系统的组成部分

编排器负责协调LLM的输入输出、管理其与其他服务的交互。它具有确定性，能清晰划分访问边界，为授权决策提供依据。向量数据库作为LLM的“外脑”，可补充模型不具备的信息，也可用关系数据库或外部API替代。由于外脑信息敏感，需在检索前进行授权判断。LLM缓存虽能加速查询、节省成本，但可能引发信息泄露或被用于缓存投毒攻击。验证器可验证、筛查甚至重写LLM数据流，是纵深防御体系的一部分，但不能替代严格的输入输出控制。

从基于LLM的系统的组成部分，我们可以直观地看到将LLM集成到系统中所带来独特的安全和控制问题。

因为LLM本质上的概率特性（不确定性），恶意用户的攻击方式也变得多样化。攻击者可以利用LLM的能力绕过传统的访问控制访问敏感信息；或者引导LLM输出危害性或高风险的操作。这些都可能导致严重后果，如完整性受损、数据泄露、违反合规要求等。

提示注入攻击是LLM面临的一大挑战。攻击者通过在用户提示中加入如“忽略先前指令”等内容以直接绕过系统限制，或把恶意指令注入外部数据源，再经RAG等机制输入LLM。由于LLM无法区分“指令”与“数据”，这类攻击风险剧增。尽管LLM API提供“系统”、“用户”等角色以助力开发，但这些角色并无实际安全意义，均作为提示词交由LLM处理。因此，授权控制必须置于LLM外部，同时要验证和管控LLM的所有输出。

通常建议避免使用含敏感信息的数据集进行模型训练或微调。如有必要，可通过RAG获取敏感信息，并通过适当的访问控制确保仅有授权用户能访问。在必须使用敏感数据训练的场景下，应严格限制与模型交互的用户权限以降低风险。

鉴于LLM的特性，它不适合自主做出关键决策。从授权角度看，我们不能依赖LLM处理过的身份信息或访问控制决策。设计基于LLM的系统时，应始终遵循前文提出的五项原则，以确保系统的安全性。

当我们谈起RAG的时候，多数情况下，是使用向量数据库的RAG访问。用户输入的查询信息，被首先送往向量数据库，查找上下文相似的结果，从而实现语义搜索功能。然后相关的上下文和用户的原始查询被一起送给LLM，LLM再根据这些信息生成回应（如下图所示）。由于作为RAG的数据多数是实时甚至敏感的数据，我们并不会希望所有用户都能通过RAG的能力访问这些数据。因此，授权判断是必须的。

检索增强生成流程

最佳实践是通过在相关向量存储或数据库中引入文档级安全，并在检索点强制执行访问控制来实现最小特权原则。

•文档会标记元数据，用于标识哪些角色或属性有权访问它们。

•元数据与文档及其相关嵌入内容一起存储。

•根据元数据，查询可以根据用户的授权级别来过滤文档。

•当编排器代表用户发起搜索时，首先需要验证用户的角色。

•在用户角色中的任何相关查询过滤器，以定制搜索结果，仅包含用户有权查看的记录。

然而，并非所有向量数据库都具备行级或文档级的ACL，而且从数据源中提取的原始ACL可能会随时间在源与向量数据库之间产生偏差。这两点容易出现的误区。

当回答查询需要结构化数据时，RAG可以通过关系数据库来获取数据。编排器可以通过与任何其他系统组件在与数据库交互之前验证授权属性的相同方式执行带有权限检查的查询。这是一个多阶段流程: 第一个提示的目的是生成适当的SQL查询；第二个提示则是要回答的初始问题与从数据库检索得到的上下文。在这种场景下，作为最佳实践，特别需要注意的是：

•使用参数化查询，避免SQL注入攻击的发生。

•LLM只生成SQL语句的部分内容。

•应用最小权限，限定查询格式，限制查询速率。

•完整的日志记录和异常告警。

相应的，在没有任何验证以确保正确性的情况下运行SQL查询，不使用参数化查询，或者缺乏适当的过滤机制都是常见的错误示例。

除了数据库，LLM可以与一系列API集成，以执行操作和/或从数据存储中检索数据。与API交互时，授权自然至关重要：一方面，调用API的用户必须经过身份验证和鉴权；另一方面，API的输出结果必须经过过滤，仅包含最终用户有权查看的数据。报告推荐了以下要点，作为最佳实践：

•身份信息应该从编排组件直接传递给API，避免通过LLM中转。

•授权操作应该尽可能接近数据访问的地方。

•使用安全API网关进行清理和验证，确保详细记录所有API调用。

•基于访问控制模型（如RBAC/ABAC），实施最小特权原则。

相应的，这种情况下，最常见的误区便是依靠LLM将身份信息传达给后端API。由于LLM的不确定性，无法保证后端API收到的身份信息与真实的用户相同。这可能导致未经授权的数据访问和操作，从而引发数据泄露。依赖可能导致间接提示注入攻击的外部数据源，以及未经验证的API调用，同样是常见的错误示例。

AI编写连贯且可工作代码的能力不断增强，这成为基于LLM的系统的新的用例。人们期望在工作过程中，LLM能在运行时编写代码，然后动态执行以解决特定问题。然而，与之相伴的安全风险也无法忽视。

由于LLM并不会自主地对代码进行安全审计，而且即使安全审计也无法完全排除代码可能存在的问题或漏洞。因此，报告认为，许多常见的安全实践可以应用于这一场景，包括但不限于对高风险进程进行沙箱隔离、遵循最小特权原则以及生成和使用审计日志。此外，报告特别提出了通过使用自定义解释器在语言本身中限制授权使用的方法。包括了：

•通过自定义受限解释器限制语言的执行能力

•防止利用

•恶意代码检测

•有限的访问和权限

•避免授予写权限或修改数据的访问权限

•人工参与

AI智能体借助LLM理解环境并执行任务，将用户请求拆解成子任务，选择工具并调用系统资源完成任务。其关键组件有记忆系统（含短期和长期记忆）、知识库、工具集成/插件，以及任务分解和规划能力。

为确保安全，需对编排器进行授权检查，对知识库实施访问控制，并对插件进行沙箱隔离。目前，基于LLM的自主智能体系统及访问控制仍在发展中，需深入理解交互点和信任边界以设计合理的访问控制措施。

LLM的爆发式发展，让基于LLM的系统的安全性问题变得严峻。哪怕整个系统只有一小部分功能使用了LLM，它依然能带来意向不到的安全风险。报告中或多或少的提到，LLM带来的安全风险很大程度是由于其自身特性的导致的，而且，这些问题目前依然无解。我们当然不能因噎废食，放弃LLM这个强大的工具。因此，做好相应的安全规划和防护是每一位从业者都要时刻谨记的。

报告中有一句话：“LLM的表现就如同一个非常聪明但过于自信、容易被愚弄，没有街头智慧的青少年一样”。这句话非常形象，也从另一个角度诠释如何应对LLM带来的安全风险的方法论。

通俗地说，应对LLM为系统带来的风险的关键思想是将其视作“不可信的人”——它有能力，但不靠谱。我们在日常工作和生活中，应对这样的伙伴，建立好与之相处的边界几乎是下意识的，而所有进出该边界的信息，我们都会再三核实——这和我们应对LLM的方式如出一辙：审视其能力，确定其边界，明确其权限，最后通过控制策略，实现对其的应用与监管，这就是我们为LLM为系统带来的安全风险的基本步骤。

最后，CSA 大中华区发布的AI安全白皮书和人工智能安全认证专家CAISP相关课程对报告中的内容都有展开与深化，欢迎大家关注、阅读或者参与学习。