云上LLM数据泄露风险研究系列（二）：基于LLMOps平台的攻击面分析

在上一篇系列文章《云上LLM数据泄露风险研究系列（一）：基于向量数据库的攻击面分析》中，笔者对几款业内常用的向量数据库的暴露面、数据泄露风险进行了介绍，最后给出了一些针对向量数据库数据泄露风险的安全加固措施[1]。本文是云上LLM数据泄露风险研究系列的第二篇文章，主要给读者分析和介绍LLMOps可能带来的LLM数据泄露风险。

大语言模型运维（Large Language Model Operations，LLMOps）是大语言模型（LargeLanguageModel，LLM）应用落地的核心支撑体系，为模型从实验到生产提供全生命周期管理。它通过标准化流程解决模型部署、监控、迭代等关键问题，确保LLM在真实业务场景中的稳定运行和迭代。LLMOps由DevOps演进而来，借鉴了DevOps开发运营一体化的思想，也依赖云计算技术实现。云计算为LLMOps提供了灵活、可扩展的基础设施和服务支持。LLMOps也通过自动化的运营，更好地适应云计算发展趋势下的灵活、弹性的特点。

LLMOps是LLM应用运行的基石，LLMOps的安全风险直接影响LLM应用落地的合规性与可持续性。因此，本文将针对LLMOps平台存在的数据泄露风险进行分析和介绍。

LLMOps是指一系列用于管理大语言模型的运维方法。通过LLMOps，LLM的整个生命周期，从微调到维护都得到管理并实现自动化，从而帮助开发人员和团队部署、监控和维护LLM。如果说LLM是ML模型的一个子集，那么LLMOps同样也是机器学习运维（MachineLearning，MLOps）中适用于大语言模型的一个子集。LLMOps在构建生成式 AI 应用中的作用如图1所示[2][3]：

LLMOps通常包含以下几点核心功能[4]：

• 数据管理：挑选和准备训练数据，以及监控和维护数据质量

• 模型训练和微调：训练和优化LLM以提升其在特定任务上的表现

• 模型部署和维护：在云平台或本地基础设施上部署和管理LLM

• 监控和评估：跟踪LLM性能、找出错误并优化模型

• 安全与合规性：确保LLM运维的安全性和法规遵从性

当前业界较为受欢迎的LLMOps平台有以下5款：MLFlow[5]、CometOPIK[6]、Kubeflow[7]、Zenml[8]、Metaflow[9]。

LLMOps的供应链导致的数据泄露风险的攻击路径如图2所示。LLMOps流水线依赖复杂的供应链（如第三方库、模型、插件等），攻击者能够利用未经验证的依赖链植入恶意代码，导致链路污染，进而引发数据泄露。其中，模型投毒是实施供应链攻击的主要方式之一，攻击者通过在HuggingFace和TensorFlowHub等开源模型社区投递包含恶意代码的模型，即可实施此类攻击[10]。

诸如MLFlow之类的LLMOps工具中，普遍依赖HuggingFace仓库的模型下载接口HuggingFaceTransformers。此外，底层的PyTorch、Tensorflow等机器学习框架更是必不可少。模型投毒攻击正是利用用户代码在加载模型的过程触发恶意代码而执行的。具体而言，当客户AI程序在加载ML模型文件时（如基于PyTorch框架的.pt文件等）时，相关函数会反序列化模型，恶意代码正是在该过程中完成加载、执行[8]。激活的恶意进程能够帮助攻击者进行权限控制、数据窃取等攻击行为。

除模型投毒外，开源包管理工具投毒同样是供应链攻击的常见形式。由于PyPI、NPM等版本管理仓库对恶意代码的审核存在缺陷，攻击者可以通过错误拼写(typo-squatting)等攻击方式发起投毒攻击。在2024年，曾有攻击者通过包名错误拼写方式，以“tensrflwo”来仿冒谷歌开源的tensorflow机器学习框架发起投毒攻击，进行数据窃取[11]。

LLMOps数据基座包含了LLM应用的训练数据、知识库等的存储工具，如向量数据库、OLTP数据库、云存储服务等。而数据基座暴露导致的数据泄露风险，通常体现在底层数据存储工具/服务的不安全配置导致的未授权访问中。在LLMOps实践过程中，数据基座暴露导致数据泄露风险主要集中在云存储的防护缺失和本地存储的防护缺失两个方面。

在云存储的防护缺失方面，如Metaflow、ZenML等LLMOps平台都支持在AWS中的实践，且数据源支持AWS S3存储服务。如果开发人员在使用S3作为数据源，且设置了不安全的S3访问控制策略时如"s3:ListBucket"等时，攻击者可通过爬虫的方式来获取AWS S3中的敏感训练数据集。而在数据库的暴露风险方面。向量数据库，OLTP数据库等都可能作为LLM的训练数据集或知识库，而在文章[1]中提到了，多个向量数据库和OLTP数据库默认存在未授权访问漏洞。攻击者能够通过进一步结合OSINT方法，利用数据库的未授权访问漏洞来窃取其中的敏感数据。

开源LLMOps平台容易在身份验证和授权机制上的缺陷，导致越权访问、数据泄露或权限控制等安全问题。

身份验证导致的安全风险主要体现在多个LLMOps平台在Web管理端或者RestfulAPI存在的未授权访问漏洞中（如MLFlow管理端的未授权访问漏洞）。攻击者可以通过OSINT的方式，发现这类互联网中暴露的LLMOps资产，再通过未授权访问漏洞进行数据窃取，权限控制等攻击行为。

而权限滥用的安全风险主要体现Kubernetes集群以及云服务的过度授权。Kubeflow是一个基于Kubernetes的AI/ML生命周期管理工具。而Kubernetes RBAC的安全风险主要源于权限分配过宽或配置不当，例如将高权限的ClusterRole（如cluster-admin）错误绑定到普通用户或服务账户，导致攻击者通过容器逃逸或恶意Pod窃取凭据后直接获得集群控制权；此外，默认未限制的ServiceAccount权限、跨命名空间的RoleBinding误用以及通配符规则可能导致横向权限扩散或敏感资源（如Secrets、PVC）泄露。另一方面，越来越多LLMOps支持云化部署及其他云服务的使用，在云服务使用过程中IAM的权限配置错误也会导致一些安全风险。以AWS为例，AWS IAM授权错误的安全风险主要表现为因策略（Policy）过度宽松或配置失误导致权限扩散，例如为角色附加包含通配符（如"Action":"s3:*"）的策略，使攻击者可利用被劫持的EC2实例角色，进一步非法窃取AWS S3存储桶中的敏感数据。

LLMOps中的针对容器和运行时的攻击路径如图3所示。LLMOps过程中必然涉及到容器、集群方式的落地和部署问题，这就可能涉及容器化与运行时的安全风险。此外，LLMOps的过程涉及多阶段、多工具、多云之间的任务编排，期间容易引入新的风险。

容器和集群环境，在LLM技术发展的过程中得到了大规模应用。首先，许多开源LLMOps平台支持容器、集群等部署方式。诸如Kubeflow类的LLMOps工具更是依赖容器和集群技术的实现。此外，越来越多的LLM服务同样会采用容器、集群的部署方式，来实现大规模弹性扩缩容的特性。因此，传统的容器、集群安全问题会被攻击者利用于此。例如，借助容器逃逸漏洞，攻击者能够从LLMOps业务容器逃离到宿主机中，并进一步横向移动到其他节点中，导致集群沦陷的风险，甚至能够控制整个LLMOps编排链路，进而引发数据窃取、挖矿、勒索等安全问题。

而LLMOps在运行过程中，多阶段、多工具、多云之间的编排过程中存在的安全问题同样不能被忽视，主要体现在以下几个方面：

• 跨阶段数据泄露风险：如训练数据在采集、预处理、微调、推理阶段因加密中断或权限失控而暴露

• 工具链集成脆弱性：不同工具间API密钥暴露、日志敏感信息残留或开源工具供应链漏洞

• 多云环境攻击面扩张：跨云数据传输未强制TLS、IAM策略不一致导致横向渗透、第三方服务配置错误引发模型/数据暴露

• 生命周期权限管理复杂性：过度特权账号、临时凭证滥用、缺乏统一审计跟踪

这些隐患可能引发模型逆向攻击、数据泄露或合规违规等系统性风险。

模型的部署和适用通常位于LLMOps流水线的最上游，开发者通过会通过API、对话机器人等方式对外暴露LLM服务，供用户适用。对于这种暴露的LLM服务，攻击者通常可能利用LLM模型自身的安全问题来实施数据窃取。

由模型自身安全问题引发的攻击通常分为两类：越狱攻击和提示词注入。越狱攻击是通过使用提示词，欺骗AI系统忽略内置的安全规则，从而绕过其设置；提示词注入则是向大模型提供一组指令，比如让它窃取数据或操控简历，这些指令可能隐藏在外部数据源中。

在研究[12]中，研究人员发现了一种全新的提示词攻击手段，能够悄悄指示大模型收集用户的个人信息，包括姓名、身份证号、支付卡信息、电子邮件地址、邮寄地址等，并将其直接发送给攻击者。这种攻击被命名为“Imprompter”，它利用一种算法，将给大模型的提示词转换为一组隐藏的恶意指令。这段提示词看似是一个普通的英语句子，实际上却悄然指示大模型寻找用户输入的个人信息，并将这些信息发送给黑客，最终被转换成一串看似随机的字符。然而，实际上这些看似无意义的字符在背后指示大模型查找用户的个人信息，将其附加到一个URL上，并悄悄发送至由攻击者控制的域名。

针对前文提到的LLMOps平台安全风险，笔者给出以下几点措施对LLMOps平台进行安全加固：

• 建立有效的访问控制机制：开启LLMOps平台自身的认证机制或引入外部的访问控制机制，避免LLMOps平台管理界面和接口的互联网暴露及任意用户的未授权访问。

• 及时进行工具安全更新：及时更新LLMOps平台至安全版本，避免NDay漏洞的利用。

• 增加对LLMOps平台的操作审计：定期对LLMOps平台的操作日志、数据源、编排代码进行审计，及时发现历史异常行为，避免对LLM应用服务的影响。

• 自动化监控及响应：建立自动化监控及响应机制，及时捕捉、响应LLMOps平台发生的异常操作。

• 供应链加固：使用SBOM工具（如Syft）扫描依赖，替换高风险组件。

• 数据加密：对训练/推理数据实施端到端加密，结合TEE（可信执行环境）保护敏感操作。

绿盟科技创新研究院在云上风险发现和数据泄漏领域已经开展了多年的研究。借助Fusion数据泄露侦察平台，我们已监测到数万个云端暴露资产存在未授权访问的情况，包括但不限于自建仓库、公有云对象存储、云盘、OLAP/OLTP数据库、大模型组件，以及各类存储中间件等，具体研究内容可参考包括但不限于DevOps组件，自建仓库、公有云对象存储、云盘、OLAP/OLTP数据库，大模型组件以及各类存储中间件等，具体研究内容可参考《2023公有云安全风险分析报告》[13]，《2024上半年全球云数据泄露风险分析报告》[14]，《全球云上数据泄露风险分析简报》第一期至第五期[15-19]。

Fusion是由绿盟科技创新研究院研发的一款面向数据泄露测绘的创新产品，集探测、识别、泄露数据侦察于一体，针对互联网中暴露的泛云组件进行测绘，识别组件关联的组织机构和组件风险的影响面，实现自动化的资产探测、风险发现、泄露数据分析、责任主体识别、数据泄露侦察全生命周期流程。

Fusion的云上风险事件发现组件具有如下主要特色能力：

资产扫描探测：通过多个分布式节点对目标网段/资产进行分布式扫描探测，同时获取外部平台相关资产进行融合，利用本地指纹知识库，实现目标区域云上资产探测与指纹标记；

资产风险发现：通过分布式任务管理机制对目标资产进行静态版本匹配和动态PoC验证的方式，实现快速获取目标资产的脆弱性暴露情况；

风险资产组织定位：利用网络资产信息定位其所属地区、行业以及责任主体，进而挖掘主体间存在的隐藏供应链关系及相关风险。

资产泄露数据分析：针对不同组件资产的泄露文件，结合大模型相关技术对泄露数据进行分析与挖掘，实现目标资产的敏感信息获取；

当今数字化迅速发展的时代，数据安全问题越来越受到广泛关注。与此同时，随着云计算技术的普及和应用，企业也不可避免面临着云上数据泄露事件的频繁发生，为了提供公众和相关行业对数据安全的认知，我们计划定期发布有关云上数据泄露的分析报告，这些报告将以月报或双月报的形式呈现，内容涵盖最新的云上数据泄露案例分析、趋势洞察、数据保护最佳实践以及专家建议等。

如果读者对本报告有任何意见或疑问，欢迎批评指正。如有合作意向请联系我们（邮箱[email protected]）。

原文始发于微信公众号（绿盟科技研究通讯）：云上LLM数据泄露风险研究系列（二）：基于LLMOps平台的攻击面分析