AI代码解释器安全审计：沙箱隔离、数据外带与取证实战

最近我接了一个很有意思的活儿：对某AI代码解释器（内部代号叫 Coworker）做架构审计与安全取证分析。这类服务听起来很玄，说白了就是让AI根据指令写代码、执行代码、读文件、生成图表，很多团队把它当“数字实习生”用。但越方便的东西，越需要警惕——它离数据和系统太近了。这篇文章我不讲PPT式的安全理念，只讲我在审计中怎么拆架构、找弱点、做取证，以及那些常规文档里不会写的坑。适合正在做AI平台安全审计、云安全评估，或者单纯想搞清楚“这类工具到底能不能信”的朋友。

Coworker这类代码解释器的本质，是“临时授予了一个能跑代码的代理”。如果你把它想成一个外包临时工，就能理解我的担忧：你会给一个只干两小时活的人你的数据库密码吗？你会允许它随便访问内网吗？但很多接入方在配置时，因为贪图方便，往往把这些限制都放宽了。审计的目的，就是把这个临时工的权限边界、行为路径和事后追溯能力一条条捋清楚。

1. 审计前先搞明白：代码解释器这种“数字员工”到底在干什么

1.1 Coworker 的真实攻击面从产品定义开始

我做安全审计的习惯是：不看文档，先看功能。Coworker对外提供的能力大概包括这几类：用户上传文件和数据集、AI生成Python或SQL代码、在受控环境中执行、返回结果（图表、CSV、图片等）、以及有限的网络访问（下载依赖、调用外部API）。这些功能叠加在一起，暴露面就不是一个普通Web服务能比的。

攻击面也很直接，主要在四个方向：第一，代码执行本身——如果沙箱隔离失效，代码会直接影响底层系统；第二，文件读写——AI能读用户上传的数据，也能读环境变量、配置文件乃至系统文件；第三，网络外带——代码可以带着数据访问外网，这就是一条天然的泄露通道；第四，提示注入——用户给AI输入的内容可能夹带恶意指令，让AI生成攻击性代码。很多团队只盯着第一点和第二点，忽略了第四点，实际上提示注入是这类服务的入门级风险。

我拿到Coworker的审计任务后，第一件事不是翻源码，而是让产品团队回答一个问题：它到底能做什么，不能做什么？把能力边界画清楚，后面所有分析才有参照物。这里有个实用建议：实物驱动审计，不要被架构图带偏。

1.2 威胁建模：别上来就翻源码

很多朋友一听到“安全审计”就想着找漏洞、打Payload，这是误解。架构审计不是渗透测试，首先要建威胁模型。我给Coworker建模时，把资产分为三类：用户数据（上传的原始文件、生成的结果）、执行环境（容器/沙箱、临时目录、环境变量）、基础设施（宿主机、云账号、内部网络）。角色也分成三类：普通用户、恶意用户、被污染的大模型。

威胁建模的核心不是罗列风险，而是明确“信任假设”。当时我列了几个问题，直接把项目组问住了：沙箱是否与宿主机完全隔离？是否允许代码发起外网请求？不同用户的会话之间能不能互相访问文件？如果模型被提示注入诱导，它能读取当前会话之外的数据吗？这些问题非常重要，因为它们决定了审计的具体路径。

这让我想起日常工作中最常见的误区：很多人默认“AI产品厂商已经把安全做完了”。但实际审计中，问题往往出现在集成层——比如Coworker的默认配置是网络可访问的，而接入方为了下载依赖没有关闭外网权限，于是这个数字员工成了信息窃取通道。威胁建模的价值，就是提前把这些默认假设亮出来，然后逐条验证。

1.3 架构审计与安全取证的差异

标题里把架构审计和安全取证放在一起，容易让人混淆。我明确区分一下：架构审计是“从未来防止问题”，安全取证是“从过去还原事件”。审计的工作重心在配置、逻辑、边界、权限；取证的重心在日志、内存、文件痕迹、时间线。两者共享很多底层能力，但思路不同。

比如我这次审计Coworker，架构审计阶段重点检查了入口网关到沙箱之间的信任链路；取证阶段则是把一次安全事故（某用户数据疑似被外带）的完整过程重演了一遍。两个阶段对工具的侧重也不一样：审计多用配置扫描、源码走查、权限检查；取证则要依赖日志分析平台、镜像快照、进程行为审计。这篇文章我会把两条线都展开，但请你记住：如果一开始就分不清目标，后面就会被技术细节带着跑，什么都看不出来。

2. 架构审计：从入口到沙箱的信任边界怎么拆

2.1 链路分层与边界清单

Coworker这种服务的标准链路大致是：Web前端/API网关 -> 会话管理 -> 任务调度 -> 沙箱执行环境 -> 依赖仓库、对象存储、外部网络。每两层之间都有一个信任边界，但很多边界只是“逻辑隔离”，不是“安全边界”。我画图时喜欢用实体方框画出每个节点，然后在方框之间标出信任等级。

审计重点往往在三个位置：API网关与后端之间（鉴权是否可靠）、任务调度与沙箱之间（是否传递了不该传的凭据）、沙箱与外部世界之间（网络策略是否失效）。举一个真实审计中发现的问题：任务调度器会把用户的原始文件下载到本地临时目录，再挂载给沙箱。这个临时目录的权限位是默认的 777，意味着同一主机上的其他进程理论上也能读到用户文件。虽然沙箱本身做了隔离，但调度器所在的共享主机没有被纳入隔离范围——这就是边界画错了。

实战中我建议把链路拆成三层看待：用户面（前端、网关、会话）、控制面（调度、任务管理、日志采集）、数据面（文件存储、结果存储、执行环境）。控制面和数据面必须严格分离，这是最常被忽略的原则。

2.2 隔离方案的选型逻辑

沙箱是代码解释器的最后一道防线。现在主流的隔离方案有进程级（比如子进程加限制）、容器级（Docker/Containerd）、微虚机（Firecracker）、独立内核虚拟机。Coworker这类平台常用的是容器加微虚机的组合：轻量级任务用容器，敏感任务用微虚机。选型逻辑很简单：启动速度和隔离强度之间找平衡。

很多团队会踩一个认知陷阱：以为容器就是安全沙箱。容器只是操作系统层面的资源隔离，它共享宿主机内核，一旦内核有漏洞，容器逃逸就是灾难。所以审计时我第一检查项就是：是否用到了真正独立的隔离内核？有没有去掉不必要的 Linux capabilities？有没有阻止 mount、ptrace、胶囊网络这类危险系统调用？一般标准的加固配置会包含这几个参数：

# 示意配置：容器运行参数 --read-only-rootfs --cap-drop ALL --security-opt no-new-privileges --seccomp-profile=/path/to/custom-seccomp.json --cpus 1 --memory 512m

注意，这里的参数是常见加固方式，具体实现要根据产品环境调整。审计时不仅要检查有没有这些参数，还要检查它们是否真的生效。我就见过配置里写了--cap-drop ALL，但运行命令后面又加了一个--privileged，直接把安全配置冲掉了。这种低级问题如果不看运行时状态，纯粹看配置文件根本发现不了。

2.3 数据面和控制面的分离问题

代码解释器常见的架构缺陷，是会话数据和代码执行数据混在一起。什么意思？用户在一个会话里上传了机密文件，然后AI生成代码去读取这个文件。在架构上，如果会话存储和沙箱工作目录共享同一套对象存储，又没有做访问控制，那么一个会话的代码就有可能读到另一个会话的文件。Coworker项目组当时就发现，某个数据目录的桶权限是“所有经过认证的用户都可读”，这意味着用户A只要拿到一个授权Token，就能尝试读取用户B的文件。

这种问题的根源是：数据面的权限模型没有跟随业务模型的“会话”进行细分。修复方式也不复杂，把对象存储的路径带上Session ID，并在接口层做一次显式的拥有者校验；同时保证沙箱内看到的数据只是当前会话所需数据的最小集。审计时我特别喜欢找“共享存储”的痕迹，因为这是最典型的“看似在生产环境，实则裸奔”的地方。

2.4 配置审计：默认配置能撑住吗

架构不只是在图纸上，最终都体现在配置里。我一般从几个维度核对Coworker的配置是否安全：并发限制、临时文件系统大小、执行超时时间、网络出站白名单、文件访问权限、日志保留周期。这些配置项单独拎出来都不起眼，但组合在一起决定攻击者能不能利用这个平台。

拿网络出站策略来说，一个安全的默认值应该是“拒绝所有出站流量”，然后按需放行到特定域名或IP段。但真实的AI产品为了用户体验，经常是“放行所有公网流量”。这个设计一旦遇到恶意代码，就是数据外带的天然通道。我在多个类似项目里反复强调一个问题：不要在默认配置里给用户“顺畅的访问体验”，要让用户为每一个外网请求显式申请白名单。哪怕被迫降低一些便利性，也好过数据泄露后再打补丁。

再看几个容易忽略的配置：临时文件系统（tmpfs）如果挂载得过大，代码执行环境就能撑爆内存；执行超时时间如果不设置，攻击者可以长期维持一个高CPU占用任务；日志保留周期如果太短，出事时根本没有证据可查。这些都是我在审计清单里必须逐项打勾的。

3. 安全取证分析：从日志和镜像中重建“案发经过”

3.1 日志源有哪些，哪里最容易丢证据

一次完整取证的基础是日志，但Coworker这类分布式系统的日志往往散落在很多地方。按来源分，我通常关注四类：网关/API请求日志（谁在什么时候调了什么接口）、任务执行日志（代码在沙箱里输出了什么）、沙箱监控日志（进程启动、系统调用、网络连接）、文件操作审计日志（谁读了哪个文件，有没有下载）。最后一类最容易被忽略，但恰恰是取证时最有用的证据。

当时审计中发现的最大日志缺陷是：默认只记录了“用户上传了文件”和“AI生成了结果”，没有记录“沙箱内具体执行了哪些命令”“进程访问了哪些网络地址”。这意味着一旦代码外带数据，你只能看到一个模糊回调，根本没法定位到具体命令。这个问题的根本原因是开发者把日志当成调试工具，而不是审计工具。

我建议有条件的团队在沙箱内额外启用auditd或者等效的内核审计组件，捕获文件读取、网络连接、进程执行等行为。如果担心性能，可以只对带有敏感数据标记的会话开启全量审计，普通会话保持默认级别。这个思路在取证时非常关键，因为它能帮你在事件发生后重建完整的执行时间线。

3.2 事件时间线重构：把碎片拼起来

安全取证的日常，是把看似无关的日志碎片拼成完整故事。举个来自我审计工作流的例子：某天监控告警显示，一个Coworker任务在短时间内向一个未知IP发送了数据包。直接看API日志，你只会看到“用户上传了一个文件”和“任务正常完成”。这时候取证就要开始拼接了。

第一步定位Session ID；第二步从请求日志中关联到具体用户和IP；第三步从沙箱监控日志中找到该Session对应的进程树；第四步从文件审计日志里看这个进程读取过哪些文件；第五步从网络日志里找到外联行为。最终拼出的时间线可能长这样：

这个过程看起来简单，实际操作时最怕两个问题：一是各系统服务器时间不同步，导致事件顺序错乱；二是日志字段缺失，没法通过Trace ID串联。所以我在审计中强烈建议：所有组件统一使用同一时间源，并且把请求ID、Session ID、进程ID这些关联字段写进每一条日志。这是能让取证效率翻倍的基础设施投资。

3.3 沙箱快照与内存转储的取证价值

代码执行环境的痕迹，往往比文件日志更可靠。因为攻击者可以清理文件、伪造日志，但操作系统层面的执行痕迹很难彻底擦除。审计Coworker时，我尤其看重沙箱快照和内存转储这两个取证手段。

沙箱快照的含义是：对每次执行任务的工作目录和运行环境做一次性快照，任务结束后保留一段时间。这样如果事后发现某个任务涉及恶意行为，你可以直接回到那个时间点，查看当时沙箱里到底有什么文件、装了什么依赖、残留了哪些临时脚本。我建议快照至少保留30天，而不仅仅是任务结束就删除。

内存转储的价值在于它能捕获进程在运行期的数据，比如环境变量、密钥明文、被混淆后解码的字符串。实际操作中，对一个已结束的任务做内存转储通常不现实，所以要在任务运行期间或者准备终止时进行采样。如果你用的是Kubernetes，可以通过kubectl exec进去抓进程内存；如果是微虚机隔离环境，则需要改造调度器，在任务结束前触发一次 dump。这些都是可以落地的工程改造。

3.4 文件痕迹与数据外带分析

文件痕迹分析的核心是寻找“不正常的访问关系”。举个例子：AI生成的数据分析代码通常只会读取数据文件，但如果代码在读取完源文件后，又突然去访问/etc/passwd或者环境变量文件，这就非常值得怀疑。文件审计日志会把这类行为记录下来，你只需要建立白名单：哪些文件是会话任务应该读取的，哪些绝对不应该出现在访问列表里。

数据外带分析还要留意网络流量的特征。经典的“低速外带”不会一下把所有数据发出去，而是模拟正常请求，把数据拆成小块一点点传。这可能表现为：频繁访问不被业务需要的API、每秒少量请求但持续很久、把数据拼接在URL参数里。取证的难点在于分辨正常业务流量与异常行为，这时候需要借助网络连接日志的时间聚合模型，观察单会话的出站流量总量和频率峰值是否超出任务权限范围。

4. 验证隔离强度的常见尝试与防御侧核对清单

4.1 权限逃逸类威胁的测试方法

架构审计中，我不能真的在客户环境里执行逃逸攻击，但可以通过配置审查和模拟验证判断隔离强度。权限逃逸类风险的核心，是沙箱进程是否有可能突破当前隔离边界去访问宿主机资源。防御侧需要核对的点包括：文件系统是否只读；是否启用了no_new_privileges；是否通过 seccomp 阻断危险系统调用；是否移除了包括CAP_SYS_ADMIN在内的所有特权能力。

举个例子，如果某个沙箱配置里仍然保留CAP_DAC_OVERRIDE，那进程就能绕过文件权限读取宿主机文件，这是非常危险的。标准安全的配置应该让沙箱进程对宿主机上的任何资源都没有“root”意义上的控制权。审计时我会用一行命令提取所有运行容器的 capabilities，然后逐个检查：

# 示意命令：查看容器能力 docker inspect --format '{{.Config.Labels}}' <container_id>

真实审计中我还要检查宿主机内核是否设置了kernel.unprivileged_bpf_disabled=1这类参数，防止低权限进程从内核侧发起攻击。如果团队使用的是容器运行时，可以借助漏洞扫描工具对镜像做CVE扫描，但这只是辅助，核心还是配置和系统调用的收敛。

4.2 数据外带路径是否被堵死

我反复提到外带，因为它才是代码解释器最致命的“暗门”。验证路径有没有堵死，要看网络策略而不是看文档。在测试环境里，我通常会让一个测试Session尝试访问几个外部地址：一个公网地址、一个内网地址、一个云元数据地址（如169.254.169.254），然后观察是否被拦截。云元数据地址尤其关键，如果沙箱没隔断这个访问，恶意代码就能拿到临时凭据，进而接管云账号。

正确的做法是把默认出站策略设为拒绝，只放行需要访问的域名，比如安装Python依赖的PyPI、拉取模型的内部镜像仓库。还要在代理层做内容检查，至少记录每个任务的出站域名和流量大小。我在审计里遇到过一个典型问题：放行了pip install的流量，但没做限制，结果攻击者利用pip从恶意服务器下载“依赖包”，实际上是把文件打包传输出去。这种路径很难完全禁止，所以审计结论要写“出站流量需要可审计、可追溯”。

4.3 结果可信性与LLM输出注入

最后一块容易被低估的验证方向，是“代码执行结果是否可信”。Coworker里面，模型描述它做了什么，和沙箱实际执行了什么，并不是永远一致。我见过一些场景，AI在生成代码时因为提示注入，会在代码里加一段额外逻辑，比如读取数据后先发送到一个远程服务器再正常返回结果。如果不校验“代码实际运行的路径”和“模型声称的路径”，这个恶意逻辑很难被发现。

取证时，比较可靠的做法是引入“产物哈希校验”机制。具体流程如下：沙箱执行结束后，对生成的文件计算SHA-256哈希，同时保留代码内容的哈希；审计时比对执行日志中的代码哈希和最终产物哈希是否匹配。如果有偏好，可以对代码内容做一次动态静态扫描，确认没有隐藏的socket调用或文件外发操作。这个机制相当于给“数字员工”装了一个行为记录仪，虽然不能阻止所有恶意行为，但能让事后审计有据可查。

5. 审计结论怎么写才能被当成有效输入

5.1 证据链比漏洞清单重要

很多安全审计报告写到最后，就变成了一张“漏洞列表”，这在我看来是不够的。架构审计的目的是帮业务方做好取舍，安全取证则要证明“某件事确实发生”。所以报告里光写“存在严重风险”没用，你要拿出一条可复现的证据链。例如“客户文件泄露”这个结论，至少要包含以下内容：泄露的是哪个文件、代码从哪个会话中被读取、执行了哪段Python代码、数据传到了哪个IP、用了什么协议、中间经过了哪一层网络代理。找不到完整证据链时，宁可承认“未完全确认”，也不要猜。

我在Coworker项目里交付的报告结构，按这个顺序组织：审计目标和范围、系统架构及信任边界图、高风险发现（每个发现附带证据日志和时间线）、低风险发现与建议、修复优先级及责任方。这个结构与一般安全报告的差异在于，它把“怎么发现的”放在“要修什么”前面，工程团队拿到后能直接跟进，而不是反复找审计方追问上下文。

5.2 从“发现问题”到“安全基线”

审计的最终产出，最好是一套可以融入开发流程的安全基线，而不是一次性结论。以Coworker为例，针对它的问题我推动建立了几条基线：沙箱内禁止挂载宿主机敏感目录；所有出站流量默认拒绝并经过代理白名单；环境变量必须显式声明，禁止透传全部配置；任务日志必须包含进程级执行记录；敏感会话开启触发式全量审计。这样的基线有可操作、可自动校验的特点，后续每次版本发布都能用它们做回归检查。

另一个建议是建立“配置漂移检测”。很多安全问题是上线时是安全的，几个月后因为某次变更把边界悄悄放开了。例如有人给沙箱临时加了外网权限，之后忘了移除。为了防止这类问题，我建议用IaC方式管理安全配置，并且每两周自动比对线上配置和基线配置，发现漂移直接告警。没有这套机制，一次架构审计的成果很快就会衰减。

5.3 关于审计中的授权与隐私保护

最后必须提醒一点：对代码解释器做审计和取证，很容易涉及到用户上传的真实数据和个人信息。越是在架构中发现安全隐患，越要注意取证数据的合规边界。我操作时有一个原则：优先使用脱敏后的模拟数据集进行验证；如果必须分析真实事件，要获得明确授权，并只在隔离环境内展开，避免取证过程中制造二次泄露。

这也回归到博主身份的安全意识：无论你是甲方还是安全服务方，都不能因为“做安全审计”就无视数据隐私。项目里所有日志、沙箱快照、内存转储文件，都要放进单独的加密存储，并严格控制访问权限。安全审计本身不是目的，在不影响用户权益的前提下提升系统可信度，才是最终的判断标准。

回到个人感受层面，我这次审计Coworker项目最大的体会是：代码解释器这类产品，真正的安全感不来自“模型有多聪明”，而来自“执行环境有多收敛、事后能不能复盘”。很多团队在模型能力和数据分析效果上花了大功夫，却在沙箱隔离、出站限制、日志审计这些“基础设施”上草草了事。希望这个项目的拆解，能帮你避开我自己踩过的那些坑：日志不全导致事件无法定位、配置漂移让安全边界失效、还有只写威胁清单不建安全基线。把这些基础补齐，AI工具才能用得更踏实。