全封闭内网的安全上网架构
容器化远程工作区隔离说明

1.1 现状

本单位为全封闭式内网：办公终端、代码库、业务数据全部运行在与互联网物理断开的网络中（即 Air Gap，物理隔离）。这保证了最高等级的数据保密性，但也带来了直接冲突——现代 AI 驱动的开发模式所依赖的一切都在外网：

• 云端大模型 API（Claude、GPT 等）无法调用——数字员工体系的核心引擎接不上；
• 开源生态（GitHub、npm、pip、Docker 镜像源）无法访问——依赖更新、漏洞补丁、新工具都进不来；
• 技术资料检索（文档、Issue、社区）无法进行——排障效率大幅下降。

1.2 为什么不能直接给内网开外网口

矛盾的本质是连通性需求与保密性要求的对撞。任何"让内网终端直接连外网"的做法（哪怕加防火墙、上网行为管理）都存在无法根除的风险：

• 数据外泄通道无法穷尽：只要内网终端与外网之间存在应用层连接，数据就可能通过 HTTPS 加密隧道、DNS 隧道、协议夹带等方式外流，防火墙看不见加密流量的内容；
• 攻击面直接暴露：浏览器漏洞、恶意网页、钓鱼附件、供应链投毒（被污染的 npm/pip 包）会直接在持有内网数据的终端上执行；
• 爆炸半径是整个内网：一台终端失陷即可横向渗透，而全封闭单位的内网通常缺乏纵深防御（因为历史上假设"根本连不进来"）；
• 审计不可行：终端本地行为难以完整留痕，事后无法回答"什么数据、经谁、何时出去了"。

1.3 采取的措施

因此采取的措施是：全单位只有一台服务器可以联网，其余一律不联网。这台联网服务器上部署多套容器（察元AI工舱），上网、访问大模型、使用开源生态的工作全部发生在容器里；内网员工通过浏览器打开容器的云桌面进行操作。人和数据都留在内网，"出去干活"的只是容器。

这个做法不是权宜之计，而是有明确名称、被业界成熟验证的隔离模型——第 02 节给出正式定名。

这套"仅一台服务器联网 + 容器内上网工作 + 人不出内网"的模式，是多层隔离技术的组合。逐层的标准名称如下：

为什么它同时解决了两个方向的问题：传统思路里"防外泄"和"防入侵"是两套工程；协议中断把两者合并了——内网数据从未进入联网环境（无泄可防），外网内容从未以可执行形态进入内网（无毒可入）。剩下的例外通道（剪贴板、文件摆渡）被收敛为有限的、可枚举的、逐容器授权的开关，这正是第 04 节威胁矩阵能够"逐条封堵"的前提。

边界上的三条通道（穷举）

• 通道 ①（内网 ⇄ DMZ）像素流会话：内网终端浏览器 → DMZ 服务器内网口 443 → 容器 Caddy → 云桌面。上行只有键鼠事件与登录凭据，下行只有画面帧。这是员工"上网干活"的唯一日常通道。
• 通道 ②（DMZ → 内网）正向摆渡：唯一允许文件跨界的路径，承载三类对象——代码（git bundle）、依赖快照（供内网离线编译）、制品，走第 05 节的"扫描 → 审批 → 单向导入"流程。
• 通道 ②′（内网 → DMZ）反向摆渡：仅限脱敏后的缺陷单、需求文档等非敏材料，提级审批；这是内网调试结果回流到外网侧修复循环的通道。
• 通道 ③（DMZ → 互联网）白名单代理：容器出网的唯一路径，目的地白名单（模型 API、Git 平台、包管理镜像），全量审计。容器没有默认路由直连外网的能力。

与内部机的同步 · 编译 · 调试闭环

开发发生在 DMZ 容器（那里有大模型和开源生态），但编译、联调、交付必须发生在内网的内部机上——原因有三：涉密联调离不开真实业务数据；DMZ 侧产物按"不可信"原则一律不作为交付物；交付物必须由内网可复现构建产生，供审计追溯。两侧通过摆渡形成一个闭环：

• 两侧 Git 的关系：DMZ 侧 Git 是"外网工作真源"（数字员工 24×7 提交都在这里），内网 Git 是"交付真源"。同步方向单向（bundle 进内网），内网侧可以完整重放和审查每一个提交，永远不反向推送。
• 内网怎么编译得动：内网编译不联网，依赖从哪来是关键。DMZ 侧维护 npm / pip / 容器镜像的缓存仓库，定期导出快照（附 SBOM 依赖清单）经摆渡同步到内网制品库（如 Nexus / Artifactory 离线库）；内网 CI 配置为只允许离线源，缺依赖就等下一班摆渡——宁可慢，不可直连。
• 调试的分工：逻辑级调试（单测、mock 联调）在 DMZ 容器里由 AI 辅助完成，迭代快；数据级调试（真实业务数据、性能、涉密场景）只在内部机上做。内部机上发现的问题不在内网修（内网没有 AI 引擎和外网资料），而是把现象脱敏成缺陷单反向摆渡回 DMZ，让数字员工修完再同步进来。
• 节奏设计：摆渡按固定窗口（如每日 1~2 班）批量执行，内网集成按日构建。这个节拍是刻意的——实时同步等于打通网络连接，隔离就名存实亡。

安全论证的方法是穷举两个方向的威胁路径，逐条给出封堵机制。凡是技术不可根除的项，明确交给制度（第 07 节），不假装技术已覆盖。

典型场景：数字员工在 DMZ 容器里完成了一个非涉密模块的开发，成果（代码、文档、制品）需要带回内网归档或集成。摆渡是唯一合法路径，流程如下：

• 摆渡对象三类：代码（git bundle）、依赖快照（含 SBOM，供内网制品库离线编译）、制品/文档。三类使用同一条流程，扫描规则按类型区分。
• 频率与批量：摆渡按固定窗口批量执行（如每日一次），不做实时通道——实时性是隔离的天敌。
• 代码摆渡的推荐形态：git bundle（含完整提交历史，便于内网审查每个 commit），而不是裸压缩包。
• 反向摆渡（内网 → DMZ）：仅限脱敏后的需求文档、公开接口定义等非敏材料，需比正向更高级别的审批；涉密内容一律禁止，涉密项目改用内网本地模型（06 节）。

察元AI工舱 现有的权限开关（CLIPBOARD_IN/OUT、FILES_UPLOAD/DOWNLOAD，均为服务端强制：FILES_* 由文件服务在接口层直接返回 403；CLIPBOARD_* 经云桌面引擎配置强制——但 2026-07-16 之前的镜像该开关存在缺陷、实际未生效，见 07 节）恰好是这套隔离模型所需的全部会话层控制。方向约定：IN = 内网终端 → 容器（泄密方向），OUT = 容器 → 内网终端（引入方向）。落地为四套容器模板：

对应的 .env 模板示例（外网开发容器）：

# 察元AI工舱 容器 · 外网开发模板（隔离上网）
LOGIN_USER=emp-zhang
PASSWORD=<每容器独立强口令>
PORT=6911                 # 每容器独立端口，仅向内网口发布

CLIPBOARD_IN=0            # 禁止 内网 → 容器 粘贴（防泄密）
CLIPBOARD_OUT=1           # 允许 容器 → 内网 复制文本（可按需收紧为 0）
FILES_UPLOAD=0            # 禁止上传内网文件
FILES_DOWNLOAD=0          # 禁止会话内下载，成果一律走摆渡

HTTP_PROXY=http://egress-proxy:3128    # 出网唯一路径：白名单代理
HTTPS_PROXY=http://egress-proxy:3128

项目分级：什么放 DMZ，什么留内网

已知缺陷与自检（重要）

2026-07-16 之前发布的镜像中，CLIPBOARD_IN / CLIPBOARD_OUT 两个开关实际未生效：设为 0 时剪贴板仍双向连通。成因是云桌面引擎在启动时会把自身配置文件里的剪贴板默认值（放开）派生成命令行参数、追加在本容器所设参数之后，同名参数后者胜出，于是开关被静默覆盖——它不报错，因此从日志和界面上都看不出来。该缺陷不影响 FILES_UPLOAD / FILES_DOWNLOAD：那两个开关由文件服务在接口层直接返回 403，实现路径完全不同。

修复版镜像已把两个开关改为经引擎官方配置覆盖通道下发，并已实测确认（CLIPBOARD_OUT=0 时取值为 0；单独关闭一个方向时另一方向不受影响）。但无论使用哪个版本，都请按下列命令自检，不要以本文档的承诺为准：

# 在宿主机执行。返回 0 = 该方向已关闭，1 = 仍然开启
docker exec <容器名> sh -c 'DISPLAY=:1 vncconfig -get AcceptCutText'   # 对应 CLIPBOARD_IN（内网 → 容器）
docker exec <容器名> sh -c 'DISPLAY=:1 vncconfig -get SendCutText'     # 对应 CLIPBOARD_OUT（容器 → 内网）

若容器已设 CLIPBOARD_IN=0 而上述命令仍返回 1，则该容器为缺陷版本，粘贴通道实际是敞开的，应升级镜像后重新验证。在升级完成前，涉密场景请以网络层与管理措施兜底，不要依赖该开关。

与《24×7 开发白皮书》的关系

本文档回答"数字员工体系在全封闭单位如何合法合规地接上外网与云端大模型"这一前置问题。白皮书中的调度器、CI 门禁、交叉评审、晨审队列等机制全部部署在 DMZ 侧运转；涉密项目按第 06 节分级留在内网、使用本地模型，两条线在"摆渡 + 分级"处汇合。阅读顺序建议：先本文档（网络与安全基座），再白皮书（开发模式与组织）。