账号集体"发疯"
第三方接入成了最短的那块板
从"外挂服务被攻破"说起：一次讲透企业该怎么管住授权出去的那把钥匙
盘点 · 收权 · 查出口 · 断链 · 写进合同
同一天，两个品牌账号接连"失态"：有企业微信账号向用户发出涉黄链接，企业微信官方回应称系某第三方外挂软件服务被攻破所致；耐克微信客服账号也向用户发出"异常消息"，耐克随后致歉，警方已介入调查。
图片
这两件事放在一起看，指向的是同一个结构：出事的不是平台本身，而是企业自己授权出去的那个"第三方"。平台没被攻破，被攻破的是挂在平台旁边、拿着你企业身份凭据的那家服务商。而它一旦失守，发出的每一条消息，署名都是你。
图片
很多企业在这件事上有一种错觉：供应商我审过、合同我签过、等保我做过，安全就算闭环了。可边界早就变了——你审了供应商，但没管住它的权限边界。风险已经从"自己的系统"转移到了"授权的第三方"。
这篇写给信息化负责人、IT 管理者和业务部门主管。不讲概念，只给动作：怎么盘点、怎么收权、怎么查数据出口、出事之后 30 分钟怎么断链、以及怎么把"第三方出事"提前写进合同。文末附可直接复制的盘点表、权限对照表和应急时间线。
图片
01｜一天之内，两个品牌账号同时"发疯"
先把事实摆清楚，不加戏。
事件一：企业微信账号发出涉黄链接
有用户反映收到来自企业微信账号推送的涉黄链接。企业微信官方给出的回应是：系某第三方外挂软件服务被攻破所致。注意这个措辞——不是"企业微信被攻破"，是"外挂软件服务被攻破"。
事件二：耐克微信客服账号发出"异常消息"
耐克微信客服账号向用户发出异常消息，耐克方面致歉，并表示警方已介入调查。具体原因尚无公开结论，通常这类情况会往"账号凭据泄露""第三方运营工具被入侵""内部人员违规操作"几个方向排查。
同一天，两个品牌，同一种症状：账号是企业的，行为不是企业的。
背后的共同结构值得警惕。企业出于客服、营销、SCRM、工单、考勤、审批、数据同步等需求，把企业 IM（企业微信、钉钉、飞书）开放给了大量第三方应用。这些应用一旦接入，通常会获得几类能力：以企业或员工身份发送消息、读取通讯录与组织架构、代持身份调用接口、接收消息回调并落库。这些能力在设计上叫"业务需要"，在使用上就是一把能代表你说话的钥匙。
关键认知：企业账号发疯，本质不是"账号被盗"，而是"授权被滥用"。盗号是点上的事故，授权失控是面上的结构性风险。前者抓一次就完，后者不治理，下次换个服务商照样再犯。
02｜到底发生了什么：被攻破的不是企微，是你授权的第三方
把技术链条拆开看，攻击者的目标从来不是那个聊天窗口，而是"能代表企业发消息的凭据"。
① 授权：一次点击，长期有效
常见的接入形态有几种：官方应用市场的第三方应用、服务商代开发或代运营的自建应用、企业自己开发的内部应用，以及不走官方接口、直接跑在客户端上的外挂软件。前三者后台有记录可查，最后一种常常游离在台账之外，恰恰最危险。
② 凭据：令牌就是身份
授权之后，服务商侧会持有 access_token、应用密钥、回调配置之类的凭据。谁拿到它，谁就能以这个企业的名义调接口、发消息、拉通讯录。令牌本身通常有有效期，但很多企业授权一次之后就再没看过。
③ 能力：拿到的不止是"发消息"
第三方接入企业 IM 后通常可获得：消息发送（外部客户群、内部群、单聊）、通讯录与组织架构读取、身份代持（以某员工身份发言）、消息回调（把会话内容同步到自己服务器）、素材与文件读写。这几项叠加，等于把企业的"嘴"和"通讯录"同时交了出去。
④ 失守：被打的是服务商侧
官方回应里的"第三方外挂软件服务被攻破"，指的就是这一层：攻击者打的是服务商的服务器、运维账号或凭据存储，不是平台。服务商一旦失守，攻击者手上拿的不是"一个账号"，而是它服务过的所有企业客户的成批凭据——这就是"集体发疯"的由来。
一句话概括：平台守住了自己的门，你却给第三方配了一把你没登记过的钥匙。门再结实也没用。
03｜为什么第三方接入是最短的那块板
木桶效应在这里非常具体。企业花钱做的防火墙、终端管控、等保测评，覆盖的都是"自己的系统"；而第三方接入这条线，往往同时踩中五个坑。
图片
① 攻击面转移：你加固的地方，攻击者不去了
攻击者是理性的。正面硬攻一个平台或一家有专职安全团队的企业，成本高、暴露快；转而攻击一家几十人的 SaaS 服务商，投入产出比高得多。你的安全水位越高，攻击者越倾向于绕道你的供应商。这不是假设，是近年供应链攻击最常见的路径。
② 信任链传导：它出事，署名是你
第三方以你的企业身份发消息，用户看到的是你的名字、你的头像、你的官方认证。信任是单向传导的：它建立的信任归你，它制造的伤害也归你。道歉的是品牌方，被约谈的是品牌方，丢客户的是品牌方。服务商可能只损失一份合同。
③ 权限默认过宽：授权页从来都是"全选"
为了"一次接好、后面不加"，业务部门和供应商通常默认勾选全部权限：通讯录全量、全员可发、消息全量回调。真正用到的可能只有其中两项。多出来的权限不产生任何业务价值，只会在出事时放大爆炸半径。
④ 审计盲区：你看不到它做了什么
平台后台通常只记录"应用已授权"，很少提供"该应用上周发了多少条消息、读了哪些部门"的细粒度日志。没有日志就没有追溯；没有追溯，事故复盘只能停在"我们也不清楚"。
⑤ 退出无清理：合同结束了，权限还开着
项目验收、供应商更换、部门解散之后，应用没人删、令牌没吊销、回调地址还指向对方服务器。这类"僵尸授权"多数企业都有一批，平时无声无息，出事时最难解释。
❌ 常见误区：把"供应商资质审核"当成"接入安全"
营业执照、等保备案、ISO27001 证书，证明的是"这家公司整体还行"，不能证明"这次接入给的权限是必要的、且被持续监管的"。资质审核是一次性的，权限治理是持续性的。两者不是一回事，别互相替代。
04｜四查法：盘点你现在到底接了多少第三方
别急着谈治理，先做盘点。多数企业的真实情况比想象中乱：IT 装过一批，业务部门自己装过一批，前任同事装过一批，谁也没记账。下面四步，一个下午能跑完，产出一张表。
图片
第一查 · 查后台授权清单
✅ 操作步骤
• 企业微信：管理后台 → 应用管理 → 自建 / 第三方应用，逐个核对；再看「授权管理」，把已授权的应用、小程序、第三方服务全列出来。
• 钉钉、飞书：同样在开放平台后台的「应用管理 / 授权管理」里导出。别只查一个平台，企业里三套并存很常见。
• 重点单独查「通讯录同步」「消息存档 / 会话内容存档」这两类开关，它们权限最大，也最容易被忽略。
• 输出：一张表，字段至少包含应用名、供应商、接入时间、申请人、用途、授权范围、可见范围、状态。
第二查 · 查凭据与密钥
• 逐个应用查 CorpID、Secret、Token、EncodingAESKey、API Key 的保管位置：在谁手上、存在哪台服务器、有没有写进代码或配置文件、有没有上传到公网代码仓库。
• 查最后一次轮换时间。超过 12 个月没换过的，直接进整改清单。
• 查密钥是否共用：多个应用、多个环境（生产 / 测试）共用一个 Secret，是最典型的单点风险，见第 07 节。
第三查 · 查外挂与非官方客户端
这次事故的主角就是"外挂"。这类工具不在官方应用市场、不在后台授权列表里，只在员工电脑上运行。
• 发一份全员自查：是否在使用任何非官方提供的群发、聚客、自动回复、多开、消息备份工具。
• 在终端管控或 EDR 里检索常见进程名与安装目录，重点看客服、销售、市场岗位。
• 定一条红线写进《终端与账号使用规范》：凡是非官方渠道获取、需要在本地输入企业账号的第三方工具，一律禁用。
第四查 · 查数据出口
• 查每个应用的回调 URL / 数据同步目标地址：你的客户手机号、会话记录往哪个域名发。
• 在出口防火墙或上网行为管理里，看有没有非常规域名的高频外联，尤其是客服坐席网段。
• 问供应商要数据落地位置说明与删除接口。答不上来的，直接判定为高风险。
产出物：第三方接入盘点表（可直接复制使用）
字段
要填什么
高风险信号
应用 / 供应商
后台显示名 + 实际供应商主体全称
供应商与签约主体不一致
接入方式
官方应用 / 自建代开发 / 本地外挂
本地外挂、非市场来源
申请人 / 部门
谁提的需求、谁在用
无人认领、申请人已离职
业务用途
一句话说清它干什么
说不清用途、用途已消失
授权范围
通讯录 / 发消息 / 消息存档 / 身份代持
开通消息存档、全量通讯录
可见范围
全员 / 指定部门 / 指定成员
默认"全公司"
凭据与轮换
密钥保管位置、上次轮换日期
超 12 个月未轮换、多应用共用
数据出口
回调域名、同步字段、落地地区
含手机号 / 身份证、境外落地
合同与条款
有无安全条款、通报时限、审计权
无安全条款、无事件通报义务
处置结论
保留 / 收权 / 观察 / 下线
——
这张表的价值不在"填完"，在于让人认领。找不到业务归属的应用，默认按下线处理；确实要保留的，由部门负责人签字背书。
05｜授权范围：从"能用"到"只给最小必要"
盘完之后就开始收权。原则只有一条：按功能给，不按便利给；按人给，不按公司给。下面这张对照表可以直接拿去和供应商谈判。
能力项
常见默认（过宽）
建议收敛到
通讯录读取
全公司组织架构 + 手机号
仅业务相关部门；手机号按需脱敏
消息发送
全员可发、任意群可发
仅指定应用、指定成员、指定外部群
身份代持
可模拟任意员工发言
仅限服务号 / 指定客服账号，不开员工代持
消息存档 / 回调
全量会话内容同步到供应商
只在监管必需时开；优先落自有服务器
素材与文件
全量读写
只读 + 限定目录，禁止长期留存
IP 白名单
不限制
绑定供应商出口 IP 段，变更需报备
管理员权限
给超级管理员账号
单独建"接口专用账号"，仅赋所需角色
收权谈判话术（可直接发给供应商）
「我们正在做第三方接入权限梳理，需要把贵方应用的授权范围收敛到最小必要。请于 X 日前提供：① 实际调用的 API 清单；② 每个接口需要的权限项；③ 数据落地地址与留存周期；④ 密钥轮换与事件通报机制。未提供说明的权限项，我们将在后台统一关闭。」
这段话的关键在最后一句：举证责任在供应商。让对方证明"为什么需要"，而不是你证明"为什么不需要"。
⚠️ 收权时的现实阻力，提前想好怎么接
• 供应商说"关了就用不了" → 要求它明确列出哪个功能受影响，落到书面；多数时候它说不出来。
• 业务部门说"别影响我干活" → 先关权限观察一周，用事实说话；确有影响再单项恢复并走审批。
• 供应商失联或小团队 → 这本身就是信号。连安全问卷都没人回的服务商，不配持有你的消息发送权。
06｜数据出口：你的客户名单到底去了哪里
权限问题管的是"能做什麼"，数据出口问题管的是"拿到了什么、带去了哪里"。后者更隐蔽，也更难在事后证明清白。
第一步 · 画一张数据流图，只画四个格子
对每个第三方应用，用一页纸画出：数据从哪来 → 传了哪些字段 → 落在哪台服务器（哪个域名、哪个地区）→ 谁能看、留多久、怎么删。
判据很简单：凡是画到第三步开始含糊的，就是风险点。常见的高敏字段包括手机号、身份证号、微信号、会话内容、订单金额、客户标签。
注意"二次流转"：供应商自己的服务器之外，它有没有再用第三方云、第三方标注团队、境外 CDN。这条链你不问，它就不会说。
第二步 · 区分"必要传输"和"顺手带走"
• 必要传输：发一条客服消息，需要收件人 ID 和消息体。这是业务成立的前提。
• 顺手带走：同步整个通讯录、全量会话存档、客户手机号明文、员工位置与打卡记录。这跟它提供的功能无关。
判断方法：把该应用的功能一句话写出来，看这个字段在不在句子里。不在，就是要砍掉的字段。
第三步 · 出口侧的三个硬动作
① 字段脱敏：手机号、身份证等对外传输一律中间四位打星；确需明文的走单独审批 + 单独接口 + 全量留痕。
② 出口白名单：在防火墙上只允许应用访问已登记的回调域名，新增域名必须走变更流程。这一步能挡住大部分"悄悄换地方存"。
③ 留存期限与删除回执：合同里写明留存周期（通常按业务必需最短期限），到期自动删除，并要求供应商提供可验证的删除回执，而不是口头承诺。
给老板的一句话版本
客户名单离开公司的那一刻，公司就不再拥有它了——你拥有的只是"对方承诺会保管好"。所以能不外传的就不外传，能脱敏的就脱敏，能少给一家就少给一家。这三件事的成本，远低于一次数据泄露的代价。
07｜账号复用与单点风险：一个凭据串起所有系统
"集体发疯"之所以是集体的，根源在复用。一个凭据打通多个客户、多个应用、多个环境，攻破一次，全线开花。
复用形态一：一个密钥全公司通用
图省事，所有自建应用共用一个 CorpSecret，甚至生产环境和测试环境也共用。后果是：任何一个应用出问题，全部受牵连；想吊销时发现"一吊销全瘫"，于是干脆不吊销。
复用形态二：服务商持有多家企业的凭据
这是 SaaS 的商业模式决定的，无法避免，但可以约束：要求它按客户做凭据隔离存储、分租户加密、独立密钥，并在合同里写明"不得跨客户混用凭据与数据"。
复用形态三：员工账号被多个工具共享
客服岗位上常见"一个工号多人用""账号密码贴在工位上"。这类账号一旦被外部工具绑定，行为就完全不可归因——出事时你连是谁发的都查不出来。
可直接照做的四条隔离规则
① 一应用一密钥：任何应用不得复用他方 Secret，测试环境单独申请。
② 一系统一账号：接口调用统一使用"接口专用账号"，禁止使用个人账号或超级管理员账号做对接。
③ 密钥集中托管：放进企业密码保险箱或 KMS，禁止硬编码、禁止放聊天群、禁止提交代码仓库。
④ 定期轮换 + 吊销演练：至少每 12 个月轮换一次；每年做一次"假设这家服务商失守"的吊销演练，确认你知道在哪儿关、关了会影响什么。
最后一条最容易被跳过，也最该做。没演练过的应急预案，等于没有应急预案。真出事的那天，你没时间翻文档找开关在哪。
08｜应急断链：出事之后 30 分钟内该做什么
账号发出不该发的内容，第一目标不是"查清真相"，是止损。真相可以查三天，消息传播只要三分钟。下面这份时间线可以直接抄进你们的《安全事件应急预案》。
图片
时间
动作
责任人
0—5 分钟
停用涉事应用 / 吊销其令牌与 Secret；若为外挂，立即在终端管控侧下发禁用策略
IT 值班 + 安全负责人
5—10 分钟
截图、录屏、导出后台日志与消息记录，先固化证据再清理；同步联系平台方报备
IT + 法务
10—20 分钟
排查同服务商、同凭据、同 IP 段的其他应用，一并隔离；通知业务部门暂停相关外发动作
IT + 业务部门
20—30 分钟
向管理层通报；启动对外话术准备（客服口径、公告模板），指定唯一对外发言人
品牌 / 公关 + 管理层
2 小时内
书面通知供应商要求说明；评估是否涉及个人信息泄露、是否触发监管报告义务
法务 + 合规
24 小时内
发布致歉与说明（参考本次事件中品牌方的做法）；必要时报警并配合调查
管理层 + 法务
7 个工作日内
完成复盘：根因、影响面、整改项、责任归属，输出报告并更新台账
安全负责人
❌ 出事时最常见的三个错误动作
• 先删记录再查：一紧张就把聊天记录、日志清掉，等于自毁证据。正确顺序是先固化、后清理。
• 只改密码不吊销令牌：改管理员密码没用，第三方拿的是令牌。必须吊销应用凭据本身。
• 各部门各自对外解释：客服说"系统故障"，销售说"账号被盗"，官方说"第三方问题"——口径打架比事故本身更伤品牌。指定唯一发言人，其余一律转交。
对外说明模板（改写自常见品牌致歉口径）
「近日，我们注意到我司官方账号向部分用户发送了异常信息。经初步核查，该情况与第三方服务异常有关。我们已第一时间中止相关服务、终止授权并开展全面排查，同时已向平台方报备并向公安机关报案。给各位用户带来的困扰，我们深表歉意。后续进展我们将及时公布。」
要点：承认事实、给出已采取的具体动作、说明已启动外部程序、不甩锅也不过度揽责。不要说"绝无可能""用户误解"，也不要在技术原因未查清前下结论。
09｜合同与责任切割：把"第三方出事"提前写进条款
事故之后能不能追偿、能不能拿到通报、能不能要求配合调查，全看当初那几行字。下面这些条款措辞可以直接交给法务改写成正式条文。
① 安全事件通报时限（最该写死的一条）
条款参考措辞：
「乙方在发现或应当发现任何可能影响甲方数据安全、账号安全或服务连续性的安全事件后，应在 X 小时内以书面方式通知甲方，通知内容应包括：事件发现时间、影响范围、初步原因、已采取的处置措施及后续计划。乙方未按期通知导致损失扩大的，就扩大部分承担赔偿责任。」
谈判要点：小时数比"及时"有用。写"及时"，等于没写。
② 权限与数据边界
条款参考措辞：
「乙方仅得在为实现本协议约定功能所必需的范围内访问、处理甲方数据，不得超范围采集、不得用于自身产品训练、不得向任何第三方转让或共享。乙方处理个人信息应遵守《个人信息保护法》相关规定，并对甲方履行个人信息处理者的义务提供必要协助。」
谈判要点：把"不得用于模型训练"单独写进去。这一条现在很多供应商会含糊回避，回避就是默认要用。
③ 审计权与配合义务
条款参考措辞：
「甲方有权每年不少于 一次，对乙方与本服务相关的安全措施、数据存储与访问日志进行审计或委托第三方审计；发生安全事件时，甲方有权不受次数限制进行专项调查，乙方应予配合并在 X 个工作日内提供相关日志与说明。」
谈判要点：同时要求它提供年度第三方安全测评报告（等保测评、渗透测试报告等），这是最低成本的持续监督手段。
④ 责任边界与赔偿
条款参考措辞：
「因乙方系统被入侵、乙方人员违规操作或乙方安全措施不足，导致甲方账号被用于发送违法或不当信息的，乙方应承担由此给甲方造成的直接损失，包括但不限于监管处罚、用户索赔、应急处置及公关费用。赔偿上限不低于本协议年度服务费的 N 倍。」
谈判要点：很多合同把赔偿上限写成"不超过已支付服务费"——一年几千块的服务费，对应的是可能几十万的 brand 损失。这个上限必须谈，而且是签约前谈，出事后再谈没人理你。
⑤ 退出与数据销毁
条款参考措辞：
「本协议终止后 X 个工作日内，乙方应删除全部甲方数据及其副本（含备份），并向甲方出具书面销毁确认；同时甲方有权注销相关应用授权与凭据，乙方应予配合。」
谈判要点：要求可验证的销毁——书面确认 + 删除接口 + 必要时允许抽查。口头承诺无意义。
现实提醒：小供应商不接受这些条款怎么办
那就分级管理：涉及消息发送、通讯录、客户数据的应用，必须是"能签这些条款"的供应商；签不了的，只让它做不接触数据的轻量功能，或者干脆不用。用条款筛供应商，比事后追责有效得多。
10｜分角色行动清单：IT管理者 / 业务部门 / 老板
同一件事，三个角色要做的不是同一件事。权责分清，才推得动。
IT 管理者：把"看不见的"变成"看得见的"
• 两周内完成第 04 节的四查，产出《第三方接入台账》，明确每个应用的业务归属人。
• 建立接入审批流程：任何新应用上线前必须过"权限必要性评审 + 安全条款检查"两关，禁止先斩后奏。
• 建一条季度复核机制：每季度拉一次台账，清僵尸应用、轮换密钥、核对数据出口。
• 把"禁止使用非官方外挂工具"写进《终端与账号使用规范》，并做一次全员宣贯与自查。
• 每年做一次断链演练：假设最大的那家服务商失守，走一遍第 08 节的时间线，记下每步耗时。
业务部门：别为了省事，把权限一次性给满
• 提需求时只写功能，不写权限："我要一个能群发通知的工具"，而不是"我要通讯录全量权限"。
• 认领自己部门引入的应用，说不清用途的就申请下线。你签的认领，就是你背的责任。
• 涉及客户数据的，先问一句"这些数据存在哪、谁能看到、什么时候删"，把答案交给 IT 备案。
• 发现账号异常（发出非本部门内容、收到用户投诉）→ 5 分钟内报 IT，不要自己先删记录。
老板 / 管理层：决定这件事能不能推得动
• 给一句话授权："第三方接入权限，宁可影响一点效率，也要收回来。"没有这句话，IT 推不动任何收权动作。
• 要求供应商安全条款成为采购合同的必备项，而不是可选项；法务与 IT 联合把关。
• 把"第三方接入治理"纳入年度安全预算与考核，别只在出事后给资源。
• 出事时只做两件事：批准断链、指定唯一对外发言人。剩下的交给流程。
11｜速记清单：本周就能做完的 12 件事
☐ 按顺序做，前 6 项一周内可完成
☐ 1. 导出企微 / 钉钉 / 飞书的全部应用与授权清单
☐ 2. 单独核对「通讯录同步」「消息存档」两类高危开关
☐ 3. 全员自查：有没有在用非官方的群发 / 聚客 / 多开外挂
☐ 4. 逐个应用登记回调域名与同步字段，出口防火墙加白名单
☐ 5. 无业务归属、申请人已离职的应用，直接下线
☐ 6. 权限收敛：可见范围从"全公司"改到"指定部门 / 成员"
☐ 7. 密钥轮换：超 12 个月未换的，全部换掉并入库托管
☐ 8. 接口账号分离：禁用个人账号与超管账号做系统对接
☐ 9. 对外传输的手机号、身份证统一脱敏
☐ 10. 向核心供应商发出安全问卷，要求列出实际调用的 API 与权限项
☐ 11. 新合同加入：通报时限、审计权、不得用于训练、赔偿上限、销毁确认
☐ 12. 做一次断链演练，把第 08 节的时间线走一遍并计时
你审了供应商，
但没管住它的权限边界。
账号发疯的那一天，被攻破的从来不是平台，
而是你点过"同意授权"、此后从未再看的那一次点击。
安全风险已经搬家了，你的治理方式也得跟着搬。
📡 关于 AIIT 数字工坊
AIIT 数字工坊，面向信息化从业者与企业 IT 管理者，讲清 AI 与 IT 的落地方法。每日更新 AI 板块 / IT 板块 / 电脑 DIY 行情 / AI 早报，围绕 ERP、财务、供应链、办公协同、信息安全等真实业务场景，持续输出可落地、可复用的实操方案。
关注「AIIT 数字工坊」公众号，第一时间获取 AI+ERP / AI+办公 / AI+安全 实战内容。
也欢迎访问 fjitw.com，对接 IT 资源、商家入驻与技术服务。