大模型的发展呈现出追风逐日般的速度，但与之相伴的安全问题，也是频频被曝光。

正如此前ChatGPT所曝出的案例中，黑客可以利用漏洞给AI植入虚假记忆，在后续回答中出现误导信息。

而且还能植入恶意指令，持续获取用户聊天数据。

即便开启新的对话也是无济于事，简直就是大写的“阴魂不散”：

试想这种对话一旦涉及机密的内容，那带来后果和损失可以说是不敢想象。

可怕，着实是有些可怕。

但反观国内的大模型玩家，却似乎鲜有黑客入侵、数据泄露等安全问题的存在。

为何会如此？

带着这个疑问，我们找到了大模型服务平台火山方舟的团队，在与火山引擎智能算法负责人、火山方舟负责人吴迪做了深入交谈之后，得到了这样的答案：

这是因为火山方舟从Day 1开始就把安全植入基因，把它当作基本的产品功能来实现。

目前我们已经做到了模型和会话等数据全周期都是安全可信的，而且是会话无痕的那种。

一言蔽之，就是你的数据，唯你可见，唯你所用，唯你所有。

那么火山方舟具体又是如何做到的，我们继续往下看。

火山方舟：在我这，会话无痕

传统的数据安全保护方案，已经不能被套用到AI大模型时代。

这就是目前大模型玩家们在安全方面所面临的最根本且真实的难题。

因为传统的私有化部署方案，多数是属于数据不动模型动，这种方法难以跟上云上大模型的快速迭代，且基础算力的单位成本远高于公有云集中调度。

因此，现在更适合的一种方案应当是模型不动数据动，企业需要将数据上传到云中，以此来利用最先进的大模型能力。

如何让用户充分信任云上数据的安全性始终是一个难题。

加之在技术层面上，主流的隐私计算技术也无法满足生产级别性能要求。

例如可用的TEE技术虽然成熟，但保护GPU等异构高算力硬件，是依然在探讨和研究中，无法直接大规模用于生产环境；MPC等多方安全计算技术也很难在大模型的吞吐、延迟与大模型的效果之间取得平衡。

而火山方舟的全周期安全方案，却能直击上述的痛点，并且很好地提供安全保护的能力。

整体来看，这套方案共分为四大维度，分别是：

• 链路全加密
• 数据高保密
• 环境强隔离
• 操作可审计

接下来，我们就把整套方案拆分开来，深入到每个维度来看下火山方舟是如何搞安全的。

链路全加密

在大模型应用中，数据流转的每个环节都可能面临风险，特别是当数据从用户端发送到云端进行处理的时候。

对此，火山方舟平台采用了“双层加密”方案，即在数据传输过程中实施网络层和应用层的双重加密。

首先是在网络层，火山方舟使用了HTTPS协议，这就像给数据通道加上了一层防护罩，让数据在传输过程中被安全封装。

同时，平台还使用了mTLS（Mutual Transport Layer Security，即双向认证传输层安全协议），这可以理解为“双保险”，因为不仅用户会验证方舟平台的身份，方舟平台也会反向验证用户的身份。

这种方式类似于寄送包裹时不仅需要寄件人和收件人的地址验证，快递员还会在每个传送节点核查包裹是否安全抵达目标地址，确保没有被篡改。

这一层安全措施有效防止中间人攻击，即攻击者试图在传输链路中截取或篡改数据的行为。

然而，仅仅依赖网络层加密还不足以保证数据绝对安全，因为如果数据在网络传输中被误导到错误的地址，那么即便是密文也有可能被破解。

因此，火山方舟还增加了应用层的会话加密，进一步确保数据即便落到不正确的接收端，也无法被解密读取。

网络层的加密就像给一个文件加了一层保险盒，而应用层加密就如同再给保险盒上了一把锁，双重保险确保即便有人拦截了这个文件，也无从打开它。

在应用层加密中，每个推理实例都被赋予了一个唯一的身份认证证书，类似于每个人都有自己的身份证号。

用户的数据会使用这个证书的公钥进行加密，而只有当数据抵达拥有对应私钥的火山方舟安全沙箱内，才会被解密。

这一设计如同用户的数据在送达火山方舟之前被打上了独特的印记，只有持有匹配“钥匙”的平台安全环境才能将其解密和使用。

这样一来，平台确保了用户数据在传输中始终处于封闭的“安全通道”中，未经授权的任何人都无法解锁并查看数据。

数据高保密

这一步骤核心在于如何确保数据在平台的传输、使用和存储过程中始终处于极高的保密状态。

数据高保密不仅涵盖了对数据存储、加密等方面的多重保护，更以沙箱环境为基础，确保数据即便在平台内部流转时也不会暴露给任何未经授权的用户。

这一保密策略类似于把数据锁进一个“加密金库”中，无论是外界的攻击者还是平台的内部人员都无法直接接触到未加密的原始数据。

对此，火山方舟采取的策略是：

从数据上传之初就以密文形式加密存储，只有当数据进入沙箱内存时才会被解密。

对于模型训练，用户可以通过火山引擎提供的密钥管理服务（KMS）功能，设置自定义密钥对数据进行加密，并将数据存储在用户自己的TOS（对象存储服务）内。

这一环节可视作给数据“穿上盔甲”后再送到平台，即便数据被截获，攻击者也只能看到加密后的“密文”，无法获取数据的真实内容。

然后，在平台内部，数据被分配到安全沙箱中并以密文状态存储，只有在安全沙箱的内存中才能够短暂解密以供训练使用。

通过这一设计，火山方舟平台建立了一个“只有沙箱能读懂数据”的密钥体系，确保数据在离开沙箱后始终以密文状态存在。

这就好比“密钥控制”，即每一组数据都配有一把“加密锁”和“解密钥匙”。

这把钥匙由用户控制，只有用户允许时才能使用。比如当企业客户需要上传训练数据集时，可以事先利用TOS的加密功能对数据进行处理。

然后火山方舟平台将密文数据挂载到安全沙箱环境中，在内存中完成解密后，数据才会被投入训练系统。

此外，火山方舟平台的数据高保密功能还扩展到了精调模型的存储和管理环节。

对于每一个完成精调的模型，平台都会以加密的形式存储在对象存储或云文件系统中，确保只有授权用户能读取和使用。

同时，为了保证模型的高效加载和运行性能，火山方舟平台利用GPU加密库，让模型在加载和运行过程中能够直接在 GPU 上完成解密和加密处理。

这种方式极大地提升了数据流转效率，确保在不牺牲模型推理速度的情况下依然保持数据的高度安全。

在安全沙箱之内，还有一个“任务级隔离”的策略。

在平台上，每个模型任务被划分为独立的“安全隔间”，即使在多租户并发的情况下，用户数据之间也不会互相干扰。

这样的隔离策略让每一个任务都像被锁在自己的“小隔间”中，即便其他租户发生任何安全事件，也不会影响到当前任务的安全性。

环境强隔离

火山方舟的“环境强隔离”方案，不仅涉及到上述我们提到的任务级隔离，更包括了防止数据泄露、确保安全操作、监控内部流量等方面的多层次措施。

环境强隔离的首要任务是让每个模型任务拥有一个独立、隔离的“安全区域”，这一设计类似于给每个任务分配了一个“安全舱”。

在实际操作中，火山方舟为每个任务使用了隔离容器，确保每个任务实例在一个安全且封闭的容器环境中独立运行。

为了达到高安全性，这些容器不仅隔离了彼此的网络流量，还限制了容器内部的操作权限，防止任务间出现横向数据传输，确保不同任务间的数据不会相互干扰。

为了进一步加强任务的隔离性，火山方舟在容器的基础上设计了一层动态网络隔离。

这项技术确保每个任务都拥有独立的、专属的网络策略。

具体而言，当一个任务被创建时，系统会自动生成一套动态的网络配置，适用于该任务的全生命周期；从任务创建到结束，无论任务间是否位于同一云网络环境下，它们之间的网络连接始终被严格隔离。

除此之外，火山方舟还为任务实例部署了容器沙箱技术。容器沙箱技术通过添加多层安全防护，使得容器在隔离性上得到了大幅提升。

此处用到的是一项字节跳动开发的开源技术“VERM Armor”，这项技术为容器提供了一种实时阻断威胁的机制，一旦容器检测到潜在的安全漏洞，就会立即阻止危险行为的继续。

在环境强隔离的设计中，火山方舟还确保了关键数据的“只读存取”功能。任务实例在使用模型和数据时仅具备读取权限，不能对数据进行修改。

此外，火山方舟还部署了可信数据访问代理系统，进一步加强了数据的隔离性和安全性。

系统不仅能确保数据请求的来源和权限检查，还能防止容器中的数据未经授权发送到外部环境。

这一设计就像海关检验程序，每一个进出任务隔间的数据请求都要经过严格审查，任何未经授权的数据传输都会被拦截。

这种多层级的防护策略，使得用户数据即便在任务隔间内部也处于严格的监控之下。

操作可审计

这一步骤的核心在于实现“可验证的安全性”，让所有涉及数据的操作都能被完整记录，并在必要时追溯来源。

操作可审计主要通过“审计日志”功能来实现。

每当用户的数据在平台内被访问、传输、处理或删除时，系统会自动生成详细的操作记录。

这些日志如同“监控录像”，详细记录了操作的时间、操作人、操作内容和操作结果。

就好比“数据使用的完整痕迹”，用户可以像检查银行账单一样审查自己的数据是否在未经授权的情况下被访问或操作。

这种设计不仅提升了数据的安全性，还增强了用户对平台的信任。

此外，火山方舟的审计日志设计遵循“透明可信”的理念。

用户可通过方舟控制台随时查看自己的数据操作日志，了解自己的数据在平台上的流转情况。

火山方舟还提供了多重验证机制，用户可以将平台的操作日志与自己系统的操作记录相对比，以确保数据处理的真实、准确性。

这种交叉验证机制类似于“多重备份验证”，让用户更放心地监控数据安全。

同时，火山方舟的审计日志不仅记录了标准操作，还能够标记异常操作并自动触发警报。

如果出现越权访问或操作不当的情况，系统中的监控指标会立即发生变化。

这一设计如同银行的“风险预警系统”，任何可疑操作都会在第一时间被标记，用户能清晰看到平台在安全保护上的责任与能力。

总而言之，在火山平台这里，数据所到之处，处处都是安全措施。

不仅要“Don’t be evil”，更要“Can’t be evil”

在与吴迪的交流过程中，他还特别提及了内部每隔几天便会上演“火山方舟与蓝军攻防”的安全机制。

这个机制不仅是火山方舟对内部系统进行严格检验的方式，更是确保平台始终处于最佳防御状态的一项重要实践。

通过这种攻防演练，火山方舟团队能够模拟真实的攻击环境，检测安全系统的稳健性，及时发现和修补潜在漏洞。

这种演练源自军队训练，蓝军模拟攻击，火山方舟防守阻止。

蓝军由专业内部团队组成，模拟密码破解、权限提升、数据窃取等网络攻击，尝试突破平台防护。火山方舟则负责监测、识别并阻止这些入侵，采取实时监控、迅速响应和修复漏洞等措施。

这种演练包括日常、小型和大型攻防演练。小型演练每月或每两月一次，大型演练每季度或半年一次，通常联合外部白帽团队进行，以模拟更复杂的攻击场景。

吴迪指出，这种机制帮助团队不断发现并修复安全隐患，提升应对真实攻击的能力。

并且已成为火山方舟安全体系的重要组成部分，不仅提高了团队的安全意识和技术水平，也让用户感受到平台在安全保障上的持续努力。

在谈到众多环节中哪个才是最重要的，在吴迪认为，内部人员的操作是安全风险的一个重要根源。

而这也正是我们刚才提到的，火山方舟引入了可信代理和堡垒机的双重管理机制的原因所在，可以确保所有运维人员的操作都经过严格的权限申请并全程录屏。

吴迪还提出，火山方舟的安全理念正在从“Don’t be evil”向“Can’t be evil”演进。

所谓“Don’t be evil”意味着平台通过可验证的安全审计结合加密隔离等技术，确保除了用户之外的任何一方，包括平台内部人员，如果违反数据安全策略，都能够被第一时间发现并追责。

而“Can’t be evil”则意味着平台将通过进一步的技术手段，使得恶意行为从根本上不可实施，这包括可信度量技术、以及泌态计算等技术的应用，能够主动减少攻击面，并且提升用户数据隐私保护级别。。

并且火山方舟的安全能力，是从第一天就开始建设，像钢筋水泥一样浇筑在产品里，而不是先盖好房子又装修。从下面这张图的时间线中便可一目了然：

展望未来，吴迪认为生成式AI技术的发展速度极为迅猛，这也给安全防护带来了前所未有的挑战。

特别是在多模态生成式AI应用场景中，例如视频、音频等多种输入与输出模式下，如何在技术复杂性不断增加的情况下维持高标准的安全性，是未来的重大挑战之一。

他表示，火山方舟将继续探索加密硬件技术、跨行业联合安全方案等新兴技术，以确保在技术快速发展和用户体验之间实现最佳平衡。

而在我们问及吴迪，在搞安全的过程中，是否有令他印象深刻的故事时，他这样回答道：

我们没有故事，要有故事就成事故了。

总而言之，纵观火山方舟的整体安全互信方案，是已经做到了“科技道路千万条，安全第一条”。

参考链接：

[1]https://www.youtube.com/watch?v=zb0q5AW5ns8&t=3s

[2]https://mp.weixin.qq.com/s/dLY3gH165TbdP4KqTXHXjw

文章来自于“量子位”，作者“金磊”。