供应商现在是攻击面
十年来，企业安全团队专注于周边防御：保护网络，保护端点，控制对内部系统的访问。威胁模型假设攻击者会直接试图渗透组织。
根据Obsidian Security的2025年SaaS安全威胁报告，2024年的SaaS泄露数据显示，这一模型已经过时。2024年SaaS泄露激增300%，攻击者不再直接针对组织——他们针对的是那些组织信任其数据的SaaS供应商。
当您的供应商是攻击面时，您自己的网络安全性就变得无关紧要。您通过该供应商处理的客户数据、员工记录和敏感商业信息都在他们的基础设施上，使用他们的密钥可以访问，并在他们的系统被攻破时暴露。
2024年的SaaS泄露数据
2024年SaaS泄露的规模说明了暴露的程度：
Conduent经历了一次泄露，暴露了2590万条记录。Conduent为政府机构和大型企业提供业务流程外包服务——包括福利管理、支付处理和公民服务门户。2590万条记录包括与政府服务互动的个人，他们并不知道他们的信息被第三方供应商持有。
NHS Digital经历了一次影响900万患者的泄露。NHS泄露暴露了通过SaaS供应商基础设施处理的患者数据——患者提供给医疗服务提供者的临床信息，他们没有理由相信这些信息会传输到第三方平台。
这些并不是个例。它们代表了数据暴露的新常态：大规模泄露影响数百万个向他们信任的组织提供数据的个人，而这些组织又将数据传递给那些个人从未知道存在的供应商。
为什么SaaS泄露在结构上是不同的
传统的网络泄露要求攻击者渗透组织的周边，导航内部系统，并提取数据——这是一个多阶段的过程，有多个检测机会。
SaaS泄露的运作方式不同。攻击者一旦攻破SaaS供应商，就可以访问通过该供应商处理信息的每个客户的数据。一次攻击就会同时导致数十或数百个企业客户的客户记录被泄露。
9分钟的泄露窗口——根据Obsidian Security的事件响应数据，指的是在SaaS环境中从初始访问到数据泄露的时间——反映了这种结构差异。一旦进入供应商的基础设施，攻击者会遇到存储在共享环境中的多个组织的数据。攻击面集中价值。
对于与其SaaS供应商签署了符合GDPR的《数据处理协议》的组织来说，泄露并不会消除合规责任。GDPR第82条规定，数据处理者对因其不遵守GDPR义务而导致的泄露承担共同责任。但共同责任需要证明供应商不合规——这是一项复杂的调查，可能需要数月时间，而数据已经在威胁行为者手中。
DPA并不保护数据
GDPR第28条要求组织仅使用提供“足够保证”的处理者，以实施适当的技术和组织措施。《数据处理协议》是这些保证的合同证据。
与HIPAA的BAA一样，DPA处理合同关系。它并没有解决数据在供应商基础设施上发生的技术现实。
在符合GDPR的DPA下运营的SaaS供应商仍然可能：
- 使用供应商控制的密钥对客户数据进行服务器端加密存储
- 在与其他客户共享的多租户环境中处理员工信息
- 保留数据日志、处理记录和超出您协议中规定目的的缓存内容
- 其基础设施被攻破，从而暴露上述所有内容
DPA创建了义务。它并没有创建数据暴露的技术障碍。当攻击者在9分钟内攻破供应商时，DPA并不会减缓他们的速度。
300%的激增是选择效应
SaaS泄露激增300%反映了两种趋势的同时运作。
首先，2024年SaaS平台中的数据绝对量大幅增长。随着越来越多的组织将更多流程转移到基于云的供应商，供应商环境中的数据也成比例增加。供应商基础设施上的更多数据为攻击者提供了更多针对供应商基础设施的动机。
其次，攻击者已经调整了他们的方法，以匹配价值集中。组织现在通过比以往更多的SaaS供应商处理更多敏感数据——客户记录、金融交易、人力资源数据、法律文件、医疗信息。SaaS供应商已成为高价值目标，因为攻破一个供应商可以获得来自多个组织的数据。
300%的数字描述了攻击方向的结构性转变，而不仅仅是一般犯罪活动的上升。
零知识架构作为供应商风险缓解
零知识架构所需的概念转变是简单的：如果您的供应商无法被信任以安全地保存您的数据——不是因为任何特定的失败，而是因为任何供应商都可能被攻破——那么您的数据就不应以可识别的形式到达您的供应商。
在传输到SaaS供应商之前进行零知识匿名化从根本上改变了泄露暴露。当使用零知识处理数据的供应商被攻破时：
- 攻击者访问匿名记录，没有可恢复的客户标识符
- 不需要通知数据主体，因为没有个人数据被暴露
- 不需要进行GDPR第82条共同责任调查
- 不会因泄露而产生监管执法调查
泄露影响的是供应商。它不会影响您的客户数据，因为您的客户数据从未以可恢复的形式存储在供应商的服务器上。
SaaS泄露激增300%改变了供应商风险计算。仅根据安全态势和合同承诺评估供应商的组织，信任他们的供应商不会出现在下一个泄露统计中。零知识架构消除了这种依赖。
来源：