关键要点
- SOC 2和ISO 27001认证的是贵组织的控制措施,而不是某个工具——切勿声称"Ollama符合SOC 2"或"vLLM已通过ISO 27001认证"。始终将其表述为对审计员将检查的控制措施的准备情况。
- SOC 2依据五项Trust Services Criteria(安全性、可用性、机密性、处理完整性、隐私性)进行评估;ISO 27001依据文档化ISMS(信息安全管理体系)内的Annex A控制项进行评估。
- 推理端点需要访问控制和结构化请求日志——大多数自托管引擎(Ollama、vLLM、TGI)默认都不提供,需要在前面加一层网关。
- 对模型权重及提示词/响应日志进行静态加密(磁盘级加密)和传输加密(TLS)——这与贵组织已经对其他生产数据存储实施的控制措施相同。
- 即使是开放权重模型也需要文档化的供应商风险评估:发布者身份、校验和验证、许可条款以及服务栈中已知的CVE。
- 合规自动化平台(Vanta、Drata、Secureframe)可以自动从云基础设施中提取证据,但自托管推理服务器通常需要自定义集成或手动上传证据。
- 本文不构成法律或合规建议——最终的范围界定和控制决策由您的审计师做出。
这是法律或合规建议吗?
不是——本指南不构成法律或合规建议。 它在技术层面说明了SOC 2或ISO 27001审计员通常检查的控制类别,以及这些类别如何映射到自托管LLM部署上。某项具体控制措施是否满足贵公司的审计要求,取决于审计师的判断、贵组织的风险评估以及您提交的具体范围声明。在安排审计或做出任何合规声明之前,请咨询合格的审计师或合规顾问。
SOC 2 Trust Services Criteria要求什么?
SOC 2依据五项Trust Services Criteria(TSC)评估组织,一旦自托管LLM系统接触生产数据,每一项都适用。 审计员测试的不是模型本身,而是贵组织能否证明该控制措施在审查期内确实存在并有效运行。
| 标准 | 审计员检查内容 | 自托管LLM控制措施 |
|---|---|---|
| 安全性 | 访问控制、日志、漏洞管理 | 推理网关上的RBAC + MFA |
| 可用性 | 正常运行时间、冗余、DR规划 | 多节点服务 + 已测试的备份 |
| 机密性 | 数据分类、最小知情原则 | 权重与日志静态加密 |
| 处理完整性 | 准确性、完整性、及时性 | 版本固定模型 + 输出日志 |
| 隐私性 | 告知、同意、数据最小化 | 文档化的提示词日志保留政策 |
ISO 27001 Annex A要求什么?
ISO 27001认证的是组织的信息安全管理体系(ISMS),Annex A是ISMS所依据的控制项参考清单,而不是直接套用到单一系统上的检查表。 自托管LLM部署与其他资产一样处于ISMS范围内:需要风险评估、在适用性声明(Statement of Applicability)中登记,并有相关控制措施有效运行的证据。
| Annex A领域 | 对应LLM技术栈 |
|---|---|
| A.5 组织管理措施 | 模型发布者的供应商风险审查 |
| A.5.19–22 供应商关系 | 模型来源与许可核查 |
| A.8 技术管理措施 | 端点加固、加密、日志 |
| A.8.16 监控活动 | 推理请求/响应审计日志 |
| A.8.24 密码学 | 传输TLS、静态磁盘加密 |
| A.5.29 业务连续性 | 模型服务事件响应手册 |
推理端点需要哪些访问控制和日志?
审计员希望看到谁用什么凭证在何时调用了模型——而常见的自托管引擎在没有前置网关的情况下都无法满足这一要求。 Ollama默认绑定`127.0.0.1:11434`,没有用户账户体系;vLLM和Hugging Face TGI提供的是没有内置身份验证的OpenAI兼容HTTP API。
在推理引擎前部署API网关(Kong、Envoy或云厂商的API管理层),为每个调用方添加API密钥或OAuth2,并将每次请求的调用方身份、时间戳、模型版本和令牌数记录到SIEM可摄取的系统中。
- 身份验证:网关层的API密钥或OAuth2,绝不使用所有调用方共用的Bearer令牌
- 授权:基于角色的访问——谁可以调用哪个模型,谁可以查看管理/指标端点
- 审计日志字段:调用方身份、时间戳、模型及版本、调用端点、响应状态
- 管理访问:对推理主机拥有shell或配置访问权限的人员必须启用MFA
如何对模型权重和提示词日志进行加密?
模型权重、提示词日志和响应日志需要与审计员对任何其他生产数据存储所期望的相同的静态和传输加密。 权重本身通常不算机密,但推理服务器的磁盘上通常还存有缓存的提示词、微调适配器以及敏感日志。
在推理主机上使用全盘加密(Linux上的LUKS、Windows上的BitLocker、macOS上的FileVault)作为基线。为每次入站API调用在网关处添加TLS终止——即使在VPC内部,也绝不以明文HTTP暴露原始推理端口。
- 静态加密:主机全盘加密,提示词日志数据库使用加密卷
- 传输加密:调用方→网关→推理引擎之间使用TLS,内部不存在明文跳转
- 密钥管理:密钥存储于KMS/vault,按文档化的计划轮换
模型更新的变更管理应该如何进行?
每一次模型版本切换、量化方式变更或系统提示词编辑都是生产变更,需要与代码部署相同的审批留痕。 审计员specifically寻找的是变更在上线前经过审查和批准的证据,而不仅仅是事后存在的更新日志。
- 在部署配置中固定确切的模型工件(校验和,而非可变的"latest"指针)
- 在任何生产模型或系统提示词变更前要求文档化的审批步骤
- 记录每次变更的批准人、时间和原因
- 保留回滚到上一个版本固定工件的路径
如何评估开放权重模型的供应商风险?
"开放权重"不等于"没有供应商"——模型发布者与SaaS供应商一样是供应链参与方,审计员会期望对此有文档化的风险评估。 这是最常被遗漏的控制措施之一:团队往往把下载的GGUF或safetensors文件当作内部资产处理,而实际上它来自组织外部。
- 发布者身份:是Meta、Mistral AI、Alibaba/Qwen、Microsoft等已知组织,还是匿名来源
- 校验和验证:部署前将SHA-256与发布者公布的哈希值进行比对
- 许可审查:商用条款、再分发限制
- 服务栈CVE:追踪llama.cpp、vLLM或TGI中的已知漏洞,而不仅是模型文件本身
模型服务系统的事件响应是什么样的?
模型服务系统存在标准Web应用手册未覆盖的事件类别——模型泄露、通过模型输出本身泄漏数据的提示词注入,以及推理端点被攻破——每一类都需要一条明确的响应路径。
- 触发示例:未授权的权重文件变更、单一凭证下的请求量激增、日志中出现的提示词注入模式
- 遏制步骤:能够在不造成整体系统中断的情况下隔离或下线推理端点
- 证据保全:保留事件期间的原始请求/响应日志,调查期间不进行日志轮转
- 测试频率:每年至少一次桌面演练,并记录日期和参与人员
提示词日志的数据保留政策应涵盖哪些内容?
提示词日志是LLM技术栈产生的风险最高的数据,因为它们通常包含用户会输入到任何其他业务系统的同类敏感内容。 一份书面的保留政策——日志保留多久、谁可以访问、如何删除——是审计员会明确要求查看的控制措施,不能仅从贵公司的通用数据保留政策中推断。
- 保留期限:明确具体的天数/月数,而不是"无限期"
- 访问控制:提示词日志存储拥有独立于常规日志访问的受限访问列表
- 最小化:默认记录元数据;仅在有正当理由且限定时间的情况下记录完整内容
- 删除流程:文档化并尽可能自动化
应如何在网络上对推理服务器进行隔离?
推理服务器应位于自己独立的网络区域,只能通过经过身份验证的网关访问——而不是与普通应用服务器处于同一扁平子网。 这限制了网络中其他服务被攻破时的影响范围,也为审计员提供了一份清晰可查的网络拓扑图。
哪些自托管工具具备审计相关控制措施?
常见的推理引擎都无法提供开箱即用的完整审计轨迹——它们的区别在于需要您自行构建多少,以及平台已经提供了多少。 这是一份准备度比较,不是对这些工具任何一个的合规性声明。
| 工具 | 内置认证/日志 | 所需的额外配置 |
|---|---|---|
| Ollama | 无(绑定localhost) | 反向代理 + 认证 + SIEM导出 |
| vLLM | 仅Prometheus指标 | API网关(OAuth2/密钥) + 审计日志 |
| Hugging Face TGI | 仅Prometheus指标 | 与vLLM相同:网关 + 审计日志 |
| 企业级平台 | 内置RBAC + 审计日志 | 仍需ISMS文档 |
合规自动化平台能帮助自托管LLM吗?
合规自动化平台——Vanta、Drata和Secureframe是最常用的三家——能自动从云基础设施、人力资源系统和身份提供商处提取证据,但自托管的本地推理服务器通常不在它们的默认集成列表中。
如果贵公司在整个组织范围内运行更广泛的SOC 2或ISO 27001项目,并希望对除自托管LLM层之外的一切实现持续监控,可以考虑使用合规自动化平台。
| 平台 | 侧重点 |
|---|---|
| Vanta | 框架覆盖面广,初创公司常用 |
| Drata | 持续控制监控,深度集成 |
| Secureframe | SOC 2 + ISO 27001结合工作流 |
这些平台自动化了贵公司更广泛控制环境的证据收集工作——它们本身并不认证贵公司的自托管LLM基础设施,PromptQuorum目前与这三家均无联盟合作关系(仅为披露的产品链接)。
审计准备中最常见的错误是什么?
大多数自托管LLM审计发现问题,源于把推理服务器当作普通IT控制环境之外的存在,而不是缺少某项根本控制措施。
- 错误: 认为开源工具"可审计"(源代码可见)就等于已经过审计。修正: 自行记录对发布者和服务栈的风险评估——可见性不等于审查。
- 错误: 以"仅内网可访问"为由让推理API在没有网关的情况下暴露。修正: 网络可达性和访问控制是两回事——无论如何都要加上身份验证。
- 错误: 将完整提示词文本记录在与正常运行时间监控相同的访问日志中。修正: 分开存储,对包含内容的日志实施更严格的访问控制和更短的保留期。
- 错误: 把模型版本升级当作没有审批留痕的例行部署处理。修正: 应用与代码部署相同的变更管理审批。
- 错误: 没有针对模型服务特有故障模式(权重篡改、提示词注入)的事件响应计划。修正: 将这些触发条件加入现有IR计划,并至少测试一次。
自托管LLM的审计准备清单是什么?
在审计师现场工作开始前完成以下清单——每一项都对应上文提到的一个控制类别。
- 1将自托管LLM系统纳入ISMS/SOC 2范围声明
Why it matters: 即使每一项技术控制措施都到位,范围内未记录的系统本身也会成为一项发现问题。 - 2将相关的Trust Services Criteria或Annex A控制项对应到实际技术栈
Why it matters: 审计员会依据贵公司提供的映射进行测试——不完整的映射意味着未经测试的漏洞。 - 3在每个推理端点前部署经过身份验证的网关
Why it matters: 消除了最常见的单一发现问题:未经身份验证的模型API。 - 4启用带有调用方身份和时间戳的结构化请求日志
Why it matters: 这是审计员针对安全性标准要求的主要证据。 - 5加密主机磁盘和提示词日志存储;在网关强制启用TLS
Why it matters: 满足机密性标准以及Annex A.8.24密码学控制项。 - 6为模型版本更新编写并遵循变更管理流程
Why it matters: 证明处理完整性,并提供文档化的回滚路径。 - 7为生产中的每个开放权重模型记录供应商风险评估
Why it matters: 弥补最常被遗漏的控制措施——模型本身的供应链风险。 - 8发布提示词/响应日志的保留与删除政策
Why it matters: 当提示词包含个人数据时,这是隐私标准的直接要求。 - 9将推理服务器隔离到独立的网络区域
Why it matters: 限制影响范围,并为审计员提供清晰的网络拓扑图。 - 10编写带有模型特定触发条件的事件响应手册并测试一次
Why it matters: 审计员会核实计划不仅存在,而且经过了演练。
常见问题
本文是法律或合规建议吗?
不是。本指南在技术层面说明了SOC 2或ISO 27001审计员通常检查的控制类别及其在自托管LLM部署上的映射方式。它不能替代合格的审计师或合规顾问——在安排审计或做出任何合规声明之前,请务必咨询专业人士。
使用Ollama、vLLM或Hugging Face TGI能让我们的AI基础设施符合SOC 2吗?
没有任何单一工具能让组织实现合规。合规性是针对贵组织完整控制措施集合的审计结论。Ollama、vLLM和TGI在加上身份验证、日志和加密之后可以支撑技术要求,但作为软件产品,它们都不"符合SOC 2"或"通过ISO 27001认证"。
AI基础设施中SOC 2 Type I和Type II有什么区别?
Type I评估的是控制措施在某一时间点是否设计得当。Type II评估的是这些控制措施在一个审查期(通常为6至12个月)内是否有效运行。对推理端点而言,Type II意味着访问日志、变更管理记录和事件响应证据需要在整个审查期内持续存在,而不只是在审计当天。
开放权重模型没有软件供应商,还需要供应商风险评估吗?
需要。模型发布者(Meta、Mistral AI、Alibaba/Qwen等)与SaaS供应商一样是供应链参与方。文档化的风险评估应涵盖发布者身份、下载权重的校验和验证、许可条款以及加载该模型的服务栈中的已知CVE。
自托管LLM相比云端LLM API能缩小审计范围吗?
它改变的是范围,而不仅仅是缩小范围。自托管消除了云端API产生的第三方数据处理者关系,可以简化审计中的供应商风险部分;但同时,原本由云厂商承担的访问控制、加密、补丁管理和推理服务器本身的日志记录,现在完全由贵组织自己负责。
审计员对推理端点期望看到哪些日志?
至少应包括:调用方身份(API密钥或经过身份验证的用户)、时间戳、调用的模型及版本、端点、响应状态,并导出到一个写入权限受限的日志存储中。完整的提示词/响应内容通常保存在一个独立的、访问控制更严格并有自身保留政策的存储中,而不是混入常规访问日志。
作为审计证据,提示词日志应该保留多久?
没有统一的数字——这取决于贵组织的风险评估和审计师的期望,并需要与适用隐私法下的数据最小化原则相权衡。请以书面形式定义一个具体的保留期限(而非"无限期"),对包含完整提示词内容的日志实施更严格的访问控制,并准备好向审计师说明该期限的合理性。
Vanta、Drata或Secureframe这类平台能监控自托管LLM服务器吗?
它们在为云基础设施、身份提供商和工单系统自动收集证据方面表现良好,但自托管的本地推理服务器通常不在其默认集成列表中。大多数团队要么为该系统构建自定义API集成,要么手动上传证据,同时让平台自动化其余的控制环境。
自托管AI基础设施最常见的单一审计发现问题是什么?
一个没有身份验证、仅以"只能从内网访问"为由自我辩护的推理API。网络可达性和访问控制是两个不同的问题——无论端点在网络中的位置如何,审计员都期望在端点上看到身份验证。
为了更容易实现审计准备,应该选择vLLM/TGI还是企业级推理平台?
vLLM和Hugging Face TGI能提供完全的控制权,但需要您自行构建身份验证、日志和加密层。企业级推理平台通常内置RBAC和审计日志,能减少自定义配置工作——但无论选择哪种方式,您仍需要相应的ISMS文档和供应商风险评估。应根据贵团队更倾向于自建还是购买配置层来选择,而不是把任何一种选项当作合规的捷径。
在哪里可以找到更多资料来源?
- AICPA SOC 2 Trust Services Criteria(aicpa-cima.com) — SOC 2审计所依据的官方Trust Services Criteria框架
- ISO/IEC 27001:2022(iso.org) — 官方标准文本及Annex A控制项参考
- OWASP Top 10 for LLM Applications(owasp.org/www-project-top-10-for-large-language-model-applications) — LLM部署特有的安全风险,包括供应链和提示词注入风险