你的SOC盯着员工，却没盯着供应商

第三方参与的数据泄露事件占比在一年内从15%翻倍到30%——这是Verizon《2025年数据泄露调查报告》记录以来最大的单年变化。一次供应链层面的入侵平均成本高达491万美元，需要267天才能被发现和控制，是IBM追踪的所有入侵路径中生命周期最长的一种。在菲律宾，过去一年中所有因第三方而遭受数据泄露的企业，无一例外都是通过供应商账户被攻破的，而不是对自身边界的直接攻击。

制造业目前是全球被攻击最多的行业，占亚太地区网络攻击总量的40%。我们在泰国接触的大多数制造企业都部署了SIEM、建立了SOC，对自己的员工和终端有合理的检测覆盖。但几乎没有一家企业设置过这样一条规则：当某设备供应商的VPN账户在凌晨2点从一个从未连接过的国家登录时触发告警。

这不是采购流程的问题，而是检测能力的缺口——因为SOC工具生来是为了监控员工，而不是监控组织发放给所有非员工人员的账户。

为什么这是结构性盲点，而不是疏忽

典型的SOC基线是围绕员工行为构建的：这个用户通常在早8点到晚7点之间从曼谷登录，访问这三个系统，从不触碰财务服务器。偏离这条基线就会产生告警。

供应商和外包人员账户不适用这套模型，原因有三个结构性因素：

它们本质上是不规律的。 供应商的支持工程师可能一个季度才登录一次来更新固件，时间取决于他所在时区，网络也是他当时恰好使用的任何网络。没有稳定的基线可供偏离——这意味着大多数行为检测要么直接忽略这些账户，要么产生大量噪音，导致分析师习惯性地忽略这些告警。

它们在身份层是隐形的。 大多数组织为供应商账户设置的方式和员工账户一模一样——同一个AD组、同一套命名规则，有时供应商多名员工甚至共用同一个登录凭据。身份系统里没有任何标识能区分"这是一个有时限、有限定范围访问权限的第三方"和"这是我们自己的工程师"。

没有人负责账号回收。 Bitsight 2026年的研究发现，只有三分之一的组织能够持续监控其所有第三方关系，大多数依赖周期性评估，中间留下数月的可见性空白。供应商合同到期，发票停止支付，但十八个月前发放的VPN凭据仍在悄悄工作，因为没有任何一个团队对关闭它负责。

在等保2.0框架下，三级及以上系统对身份鉴别和完整的访问审计日志有明确的技术要求，未被追踪的供应商账户直接构成合规缺口，尤其是在工控系统（OT）相关场景下，等保对供应链和外部接入方的安全监测要求更为具体。同时，《数据安全法》和PIPL要求企业能够证明谁在何时以何种方式访问了数据——如果连供应商账户本身都无法被识别追踪，这一举证责任就无从谈起。对于处理跨境数据的场景，"数据不出境"的合规要求也意味着必须清楚知道哪些账户在从哪里访问哪些数据。

这与我们此前讨论过的身份债务问题同根同源——没有集中所有者的账户，最终会变成没人记得要删除的账户——只是供应商账户还带来额外的风险：企业对该凭据在供应商一侧如何保存和使用，控制力要弱得多。

两个攻击面，同一个根本原因

IT供应商：MSP与SaaS集成路径

托管服务提供商、计费平台、SaaS集成通常持有对核心系统拥有广泛权限的常设凭据或API密钥。一旦某个供应商被攻破，攻击者继承的是合法且已被信任的访问权限——不需要钓鱼，不需要漏洞利用，甚至不会触发看起来像入侵的告警，因为技术上这还不算入侵。

OT供应商：设备维护路径

我们在工厂车间安全那篇文章中更详细地讨论过这种模式，但这里值得重申：工业领域远程访问风险的很大一部分，来自直接部署在OT网段上的VPN集中器，使用的是设备供应商多年前设置、此后从未轮换过的凭据。这条路径完全绕开了IT/OT边界，因为它最初是作为合法的维护通道搭建的,而不是攻击路径——直到它被当作攻击路径使用。

两个攻击面共享同一个根本性失败：这些访问是真实的、被授权的，却完全没有被当作一个独立的风险类别来追踪。

flowchart TD
  A["供应商/外包账户"] --> B["按员工账户方式开通"]
  A --> C["没有限时的访问范围"]
  A --> D["没有专属风险等级"]
  B --> E["混入正常认证日志"]
  C --> F["合同结束后访问权限仍然存在"]
  D --> G["没有关联规则区别对待"]
  E --> H["SOC看到的是有效登录，而非风险事件"]
  F --> H
  G --> H
  H --> I["267天后才被发现，如果能发现的话"]

真正能补上这个缺口的做法

监控供应商访问不是把监控员工的做法简单放大，而是要把第三方身份从头到尾当作一个独立类别来处理。

1. 在开通账户时就打上供应商标签，而不是出事之后。 每一个供应商、外包人员和集成账户都需要一个可区分的身份属性——目录中专用的OU、命名规则，或专属于第三方的SSO组。没有这一步，下游任何检测规则都无法对供应商访问区别对待，因为SIEM从一开始就不知道哪些账户是供应商。

2. 围绕供应商风险等级构建关联规则，而不是通用的异常基线。 与其试图为一年只登录两次的账户学习出"正常"模式，不如直接写明确规则：供应商账户在预先批准的维护窗口之外的任何访问，默认判定为高严重级别；供应商账户访问超出其文档记录范围的系统，默认判定为高严重级别。

3. 从源头对访问进行限时管理。 最有效的方案是架构层面的，而不是检测层面的：供应商VPN和远程支持凭据应默认自动过期，除非为正在进行的维护窗口显式延期。

4. 将打了供应商标签的告警导入独立的处置流程（playbook）。 一旦账户被标记，SOAR层就可以应用不同的升级路径——供应商账户异常默认应转交人工处理，而不是自动关闭，因为这类事件量少但潜在影响范围大。这与适用于告警疲劳的先做辅助分诊、再考虑自动关闭原则是同一套逻辑，只是应用在一个漏报代价远高于误报代价的类别上。

5. 让账号回收成为排定日程的复核，而不是一种期望。 在创建时就把每个供应商账户与合同结束日期绑定，并对任何找不到对应有效合同的供应商凭据设置自动90天复核。

flowchart TD
  A["供应商入驻"] --> B["身份打标：供应商OU + 范围 + 到期时间"]
  B --> C["定义访问窗口"]
  C --> D["关联规则：窗口外访问 = 高严重级别"]
  D --> E["SOAR：供应商告警转人工，不自动关闭"]
  E --> F["合同结束"]
  F --> G["排定日程的账号回收复核"]
  G --> H["在源头吊销凭据"]

simpliSOC如何处理供应商访问

simpliSOC的检测层基于Wazuh，案件管理使用DFIR-IRIS，自动化使用Shuffle——与我们其他SOC部署使用的是同一套技术栈。将其扩展以覆盖供应商访问不需要新工具，只需要一套不同的规则：

供应商和外包账户在身份层（AD OU或SSO组）被打标，使Wazuh的关联规则能够对其应用与普通员工基线不同的严重级别基线
针对每个供应商合同明确编写访问窗口规则——任何在约定维护窗口之外的认证事件都会被标记为高严重级别，无论源IP信誉如何
Shuffle的playbook将打了供应商标签的告警直接路由给分析师，并预先附上合同和范围上下文，而不是并入通用的自动分诊队列
涉及供应商账户的IRIS案件被单独打标，使季度复核能够直接提取所有与供应商相关的事件，而无需在通用案件日志中翻找

这些做法并不能替代采购或GRC团队在签约前本就应该做的供应商风险评估。它填补的是评估阶段与供应商实际获得实时访问权限之后SOC所能看到的内容之间的缺口——根据Verizon的数据，如今近三分之一的数据泄露正是从这里开始的。

想知道你现在的SOC对供应商访问的可见程度如何吗？
联系simpliSOC团队 → hello@simplico.net

常见问题

供应商风险难道不是采购部门的问题，而不是SOC的问题吗？
两者都是。签约前的供应商风险评估（财务稳健性、安全态势、认证情况）是采购和GRC部门的职能。合同签署之后发生的事情——该供应商的实际访问是否被监控、限定范围并按计划回收——则是SOC的职能。

我们大量使用带API集成的SaaS工具，即使没有现场供应商，这个道理也适用吗？
适用，而且可能更适用。一个权限范围很广的API密钥，其风险本质上与供应商VPN账户相同——都是常设的、被授权的访问，且不符合正常用户行为基线。

我们该如何摸清目前到底有多少供应商访问权限？
先做审计，而不是先买工具：提取所有未绑定在职员工的AD/SSO账户、所有有效的API密钥、以及所有VPN凭据，逐一与有效合同进行比对。找不到对应合同的账户,通常是最值得优先关闭的。

OT供应商访问和IT供应商访问的处理方式有区别吗？
原则完全一致——打标、限定范围、限时、异常时告警——但OT供应商访问的风险更高，因为被攻破的设备供应商凭据可以直接触及生产系统。关于如何将检测能力扩展到OT网段本身，请参阅我们的工厂车间安全文章。

这会拖慢正常的供应商支持请求吗？
不会，前提是访问窗口是提前批准的，而不是临时申请的。大多数实施限时供应商访问的组织,会将维护窗口作为支持合同的一部分提前排定，因此需要时访问权限自然存在，不需要时自然不存在。

我们规模较小，在建立完整SOC之前做这件事值得吗？
值得，而且越早做越容易。在入驻时给供应商身份打标、设置到期时间，几乎不需要任何成本。反而是在积累了多年、从未打标的供应商账户之上再做补救，要困难得多。

相关服务