花十分钟，扫一遍公司有没有裸奔的模型端口

据央视新闻 2026 年 1 月 8 日的报道，国家安全部通报了两类真实泄密案例。

第一类：某单位直接使用开源框架搭建联网大模型，导致内网可被自由访问。

第二类：某开源 AI 工具默认开启公网访问且未设置密码，敏感资料被境外 IP 下载。

请注意这两个案子的共同点：没有一个是员工把资料贴给外面的聊天框。

十家里有八家，管这件事的第一个动作是发一份通知——禁止员工使用外部 AI 工具，禁止上传公司资料。通知发完，这件事就算做过了。而上面那两个案子，一份这样的通知一个都拦不住。因为泄的不是员工带出去的，是外面的人走进来拿的。

一、这是两扇门，锁了一扇不算锁门

先把风险拆成两个方向，很多人从头到尾只想过其中一个。

往外的那扇门：员工把图纸、报价单、客户名单、代码贴进某个外部工具的输入框。资料从里往外走。这扇门有人管，管法也直观——发通知、装管控、限制网络出口。做没做到位另说，但至少所有人都知道有这扇门。

往里的那扇门：你自己在内网起了一个服务，它监听在一个所有人都能连上的地址上，还不需要口令。资料躺在原地没动，是外面的人走进来读走的。这扇门通常没人管，因为它不是「员工行为」，没有一个具体的人可以被写进制度里约束。

国家安全部通报的这两个案子，都在第二扇门上。第一个案子是搭建方式导致内网可被自由访问——注意，这里出问题的是搭建的人，不是使用的人。第二个案子更直接：默认开启公网访问、未设置密码，然后境外 IP 把敏感资料下载走了。

这里要说一句可能不太中听的话：第二扇门的风险，恰恰是被那些最积极、最有动手能力的同事带进来的。发通知禁用外部工具之后，一部分人会转向「那我们自己搭一个」。自己搭一个在安全上不是天然更好，它只是把风险从一个你能看见的地方，搬到了一个你看不见的地方。

二、为什么这类服务默认就是开着的

因为开发时图方便，上线时没人改回来。这句话听起来像句废话，但它的机制值得拆开。

一个跑在内网的服务，起的时候要决定一件事：它监听在什么地址上。选项大致是三种——只允许本机访问、允许同一个内网访问、允许所有地址访问。

开发的时候，第三种最省事。 因为你要在自己的笔记本上测、要让同事帮你看一眼、要在会议室里演示，绑死在本机你就得反复折腾。所以绝大多数教程、绝大多数默认配置、绝大多数「一行命令跑起来」的说明，给的都是最宽松的那一种。这不是谁疏忽，这是工具设计者在「让人能跑起来」和「让人安全地跑起来」之间做的取舍，他们选了前者，因为选后者的话大部分人第一步就卡住了。

同样的道理适用于口令。 试用阶段加一道口令，意味着每次演示都要多解释一句、多输一次。于是它被跳过了，或者被设成了一个所有人都知道的值。

然后是第三个环节：这台机器有没有被映射到公网。 这一步往往是为了一个非常正当的临时需求——老板出差要看、外地的同事要试、给客户演示一次。开的时候是临时的，关的时候没有人记得。

三个环节各自都有合理的理由，合起来就是通报里那个案子：默认开启公网访问，且未设置密码。

再看一个同类问题在互联网侧的公开事故。据 Wiz 安全团队 2026 年 1 月披露，某社区产品的数据库完全裸奔——150 万个 API token、35000 个邮箱地址可读可写。根因是把匿名密钥硬编码在前端，且没有开启行级安全。

这两个数字放在一起可以做一道除法：150 万除以 35000，约等于 43。也就是说，平均每一个邮箱地址背后，挂着 40 多个可用的 token。泄露出去的不是一份名单，是一整套可以直接拿去调用的钥匙。而且是「可读可写」——不只是能看，还能改。

这个案子对你的直接教训只有一句：凡是要发给外部的东西——网页、小程序、H5、客户端——里面不许带任何一把能读写数据的钥匙。 前端的东西等于公开，没有例外，加不加密都一样。

三、十分钟自查：四个问题和一张表

下面这套，不需要你懂技术，但需要你按顺序问完。它的产出是一张表，不是一个结论。

第 1 步。列清单：过去一年里，公司内网上起过哪些跟 AI 有关的服务。

范围要放宽，不要只想「我们部署的那个大模型」。还包括：知识库、向量库、工作流编排工具、生图工具、文档解析工具，以及任何一个某位同事为了试用，在自己电脑或者一台闲置机器上跑起来、后来忘了关的东西。

这一步的关键在于问谁。别只问 IT——IT 往往不知道业务部门自己试了什么。正确做法是挨个部门问一句：你们有没有自己装过、试过、跑过什么 AI 工具，跑在哪台机器上，现在还开着吗。

清单要列到这个颗粒度：服务是什么、谁起的、起在哪台机器上、现在还在不在跑。

第 2 步。逐个确认监听地址：这个服务是只在本机可访问，还是整个内网可访问，还是所有地址都能访问。

这就是通报里第一个案子出问题的那一层——搭建方式导致内网可被自由访问。你要问的话很具体：这个服务，公司里任何一台电脑打开就能用吗？如果答案是「是」，那它至少已经是内网全开。再问一句：从公司外面能不能打开？

第 3 步。逐个确认鉴权：打开这个服务，需不需要账号口令。

这里要连着问两问，第二问比第一问更重要：

• →第一问：需不需要口令。 不需要，直接记红。
• →第二问：如果需要，那个口令是不是安装时的默认值，是不是全公司通用的那一个，是不是已经离职的同事也还知道。 一个所有人都知道的口令，在效果上非常接近没有口令。

第 4 步。确认公网可达性：这台机器有没有被映射到公网。

去看路由器或者云控制台上的映射规则，一条一条对照第 1 步的清单。重点找那些当初为了临时演示、临时远程而开的口子。判断标准很简单：这条规则现在还有人在用吗？说不出具体是谁在用，就该关。

第 5 步。把前四步写成一张四列表，交给一个具名的人。

四列是：服务名称、监听范围（本机 / 内网 / 全网）、是否需要口令（是 / 否 / 默认值）、是否公网可达（是 / 否）。

再加两栏：负责人姓名，和下次复核日期。

这张表的价值不在于第一次填出了什么结果，在于它下个季度还会被重新填一遍。第一次填的时候你大概率会找出几行红的，那部分好处理；真正的价值是，三个月后有人新起了一个服务，这张表能接住它。

四、这件事的病灶：没人负责就等于没做

上面那五步，任何一家公司花十分钟都做得完。但绝大多数公司不会做完，原因不是技术，是这件事天然没有归属。

拆开看：起服务的是业务部门，管网络的是 IT，出了事担责的是老板。试用是分散发生的，收口需要集中处理，中间那一段——「谁负责知道公司现在一共起了几个服务」——没有任何一个岗位的职责说明里写着这句话。

于是就成了这样：IT 说这些不是我们部署的，我们不知道；业务说我们只是试一下，早就不用了；老板以为发过通知就等于管过了。三方都没说谎，三方合起来等于没人管。

我的建议是三条，都很短：

第一，不要设委员会，设一个人。 具名到人，不是「IT 部门负责」。部门负责等于没人负责——出了事你找不到那个应该在三个月前更新这张表的人。这个人不需要是技术专家，他需要的是有权限挨个部门问那句话，以及有义务在到期日把表重新过一遍。

第二，任何人新起一个服务，起之前先在表上加一行。 事前加一行的成本，比事后满公司清扫低一个量级。加行只要一分钟，事后清扫要重新问一遍所有人。

第三——这一条最重要——登记，不是审批。

如果你把它做成审批，结果一定是：大家不报了，服务照起，你的表比现实少一半，而你还以为自己管住了。一张比现实少一半的表，比没有表更危险，因为它给了你虚假的安全感。所以这一栏的规则要写死：加一行不需要任何人批准，只需要写清楚是谁起的、干什么用的。 有问题事后再谈，但先要知道它存在。

至于复核频率，我的看法是按季度就够了，但日期必须写死在表上，写成「每季度复核」是不成立的——没有具体日期的周期任务，等于没有任务。

什么时候不该照这么做

先把代价说清楚，别只讲关不讲代价。

把公网访问关掉，会让远程办公的人真的不方便。 出差的销售、在家的同事、需要临时看一眼结果的老板，原来是打开一个链接就能用，现在要先接进内网才能用。这个不方便是真的，不是「安全意识不够」四个字能盖过去的。

而正确的替代路径是内网访问加明确授权，不是一关了之。 具体说：谁确实需要远程用，就单独给他一条进内网的通道和一个属于他自己的账号，并且把这条授权写在第 5 步那张表上——授权给了谁、什么时候给的、什么时候到期。

为什么必须给替代路径？因为只关不给替代，是拖延，不是解决。真实的结果是：三个月后有人为了赶一个急活，自己又开了一个口子，而这一次没有人知道。你第一次至少还知道那个口子在哪儿，第二次连这个都没有了。

三种情况下，上面这套自查对你无效：

第一，你公司从来没有人在内网起过任何服务，全部用的是外部 SaaS。 那这套对你不成立，你的风险在另一头——账号权限、共享账号、以及离职时有没有真的收回。那是另一张表。

第二，你已经有专职的信息安全岗位，并且有资产台账。 那第 5 步那张表你早就有了，别再单独做一张，直接把 AI 相关的服务并进现有台账，两张表并行的结果一定是两张都不准。

第三，你连第 1 步都问不下去——问了一圈，各部门都说没有，但你自己也不确定。那先别急着往下走第 2 到第 4 步，把第 1 步反复问三遍。这一整套的准确性，完全取决于第 1 步的清单全不全。清单漏了的那个服务，正是最可能出事的那一个，因为它是最没人记得的那一个。

关于「资料真的从往外那扇门走了之后，怎么判断影响范围」，本站另有一篇专门讲。