第三方数据风险治理
📋 总体概括
高盛与Man Group自身网络未被攻破,但客户税务与财务数据经安永支持税务服务的平台泄露。这起事件揭示了金融机构数据外包中的责任不对称:品牌方承担信任成本,供应商持有技术风险。本文拆解数据流转链、专业服务机构的安全洼地问题,以及第三方风险治理的补课方向。
📄 正文
银行自己的网络一寸没丢,客户的税单和财务数据却照样流出去了。这一次,出事的不是高盛,也不是Man Group,而是替它们做税务服务的安永(EY)的一个平台。据金融时报报道的客户通知内容,EY已就一起数据泄露事件向客户发出警告,涉及高盛财富管理部门与Man Group客户的个人及财务信息。
这不是又一条可以划走的泄露快讯。它精准地戳中了金融行业过去十年扩张最快、防御却最薄的一块:数据离开了你的机房,但责任没有离开你。
🧾 税单,比账单更值钱
先还原事件本身。
按照EY向客户发出的通知,以及金融时报的报道,此次事件涉及的是一个支持EY税务服务的平台,而不是高盛或Man Group自身的网络系统。泄露的内容是这两家机构客户的个人信息与财务信息——也就是围绕税务申报形成的敏感数据集合。
换句话说:高盛的财富管理客户、Man Group的客户,出于税务合规的目的,其相关数据被提交到了EY一侧的系统里。这个系统被攻破了,数据流出去了。
| 角色 | 在本事件中的位置 | 典型义务 |
|---|---|---|
| 高盛、Man Group | 数据委托方,将客户税务相关数据交由EY处理 | 供应商尽调、合同约束、事件协同披露 |
| 安永 税务平台 | 数据的直接持有与处理方 | 技术防护、事件通知、配合处置 |
| 最终客户 | 数据主体,信息被泄露 | 接收通知、防范后续钓鱼与欺诈 |
为什么说税务数据特别值钱?因为在安全圈里有个共识性的判断:一份完整的税务档案,几乎等于一个人的财务画像。姓名、证件信息、收入、资产结构、账户脉络,全在一张表里。对攻击者而言,这比一张单纯的信用卡号有用得多——它是身份盗用、定向钓鱼、精准诈骗的“完美原料”。
一个知道自己持有多少资产、在哪家机构、做了什么税务安排的客户,是最容易被“客服来电”骗到的那批人。泄露的后果不会在第一时间以盗刷的形式出现,而是会在未来几个月里,以一通通报得上你全名的电话的形式出现。
这就是为什么这次事件的严重性,不能因为“银行自己没被黑”而打折。
🏦 最大的悖论:银行没被黑,客户照样遭殃
想象一个场景:一位高盛财富管理的高净值客户,某天接到一通电话,对方能准确说出他的资产结构、他的税务安排,甚至他上一次申报的细节。他不会怀疑这是诈骗——因为对方太“懂”他了。
这通电话的数据源头,可能就来自这次EY平台的泄露。
把数据流转链用文字写出来,问题就一目了然:
高盛财富管理、Man Group →(税务服务外包)→ EY税务平台 →(存储、处理客户税务与财务数据)→ 平台被攻破 → 数据泄露
三家机构,一条链路:客户出于税务服务需要,数据经由金融机构流向专业服务供应商;供应商的平台成了整条链路上唯一被打穿的节点。攻击者不需要去啃堡垒,只需要找到堡垒之外那个运送粮草的车队。
这里存在一个行业里长期没能解决的结构性问题:责任与风险的不对称。
- 技术风险发生在供应商一侧——平台是EY的,防御体系是EY的,漏洞也是EY的;
- 但信任成本发生在品牌方一侧——客户签的是高盛的合同,托付的是对高盛的信任。数据从高盛流向EY,风险却最终以“高盛客户数据泄露”的面目出现在公众视野里。
在安全圈里常被提起的一个判断是:如今的攻击面盘点,早就不能只画自己家的网络拓扑了,你必须把所有“数据去过哪里”也画进去。金融机构十年来的合规建设,把自家核心系统垒成了堡垒;但数据外发的每一根管道,都可能还是毛坯房。
这次事件给所有金融机构提了个醒:你的安全水位,不是由你最强的系统决定的,而是由你数据流向的、防御最弱的那一端决定的。
📊 会计师事务所:最容易被忽视的数据洼地
第二层问题更值得产业层面的追问:为什么偏偏是会计师事务所的平台?
逻辑其实很直白。审计、税务、咨询这条业务线,决定了大型会计师事务所天然是全市场税务与财务数据密度最高的机构之一。它们服务的不只是一家银行,而是横跨金融、制造、科技的大量头部客户。每一家客户,都会把最核心的财务数据和人员数据交给它。
但安全投入是另一回事。
银行的攻防体系,是在金融监管的直接约束下、以核心系统不可用为最高风险假设建立起来的——安全预算、红蓝军对抗、7×24监测,都是按金融级标准配置的。而专业服务机构的业务本质是“交付报告和方案”,历史上它的风险管理重心在独立性、执业质量与法律合规上,攻防能力从来不是它的主赛道。
把这两件事放进一张二维表,行业格局就出来了:
| 机构类型 | 数据集中度 | 攻防成熟度 | 风险定位 |
|---|---|---|---|
| 大型云厂商 | 高 | 高 | 重数据、高防护 |
| 银行核心系统 | 高 | 高 | 重数据、高防护 |
| 市场数据供应商 | 中 | 中 | 中等风险带 |
| IT外包服务商 | 中 | 低 | 渐进式风险带 |
| 法务咨询机构 | 中高 | 低 | 偏洼地 |
| 会计师事务所税务平台 | 高 | 低 | 重数据、低防护——“数据洼地” |
最下面那一行——数据集中度最高、攻防成熟度偏低——就是“数据洼地”。会计师事务所的税务平台,恰恰站在这里。
这不是对某一家机构的苛责,而是一个产业分工演化过程中的系统性错配:过去二十年的业务外包,把数据送到了专业服务机构手里;但过去二十年的安全建设,没有同步跟着数据一起外包到位。
而且,这不是假设出来的风险,而是已经被反复验证过的攻击路径。
- 2017年,德勤(Deloitte)——四大会计师事务所之一——被曝其全球电子邮件平台遭入侵,攻击者可能访问了客户的邮件、附件与敏感信息,事件波及范围至今未完全公开;
- 2021年,Accellion文件传输产品漏洞波及大量法律事务所、会计师事务所及专业服务机构,多家机构的客户金融与法律文件被窃取并被用于勒索;
- 2023年初,ION Markets——为大量对冲基金提供交易后处理服务的第三方平台——遭勒索软件攻击,数百家金融机构的客户交易流程被迫切回手工操作;
- 2023年,英国外包巨头Capita发生数据泄露,波及包括养老金服务商在内的多家金融机构客户的个人数据。
可以看到一个清晰的规律:每一次“侧门”被打穿,攻击者瞄准的都是同一种结构性弱点——数据高度集中、但安全成熟度与金融机构不匹配的专业服务供应商。 EY这次的事件,只是这个清单上新添的一条。
对攻击者来说,这类机构的价值正在被重新定价。攻击高盛要面对金融级防御,攻击一家服务了无数高盛客户的第三方平台,性价比显然高得多。这次事件之后,可以预期会有更多攻击组织把“专业服务供应商”列入高价值目标清单——因为这是进入大批金融机构客户数据的侧门,而且是不常上锁的那种。
监管层早已看清了这一点。欧盟《数字运营韧性法案》(DORA)自2025年1月起正式适用,首次将ICT第三方服务供应商纳入金融机构运营韧性的直接监管框架;美国方面,OCC、美联储与FDIC于2023年联合发布的第三方关系管理最终指引,明确要求银行对供应商的数据安全承担全生命周期管理责任;纽约州NYDFS Part 500网络安全规则的新一轮修订,也把覆盖范围延伸到了与持牌机构有数据往来的第三方。换句话说,“数据在你那里,责任算我的”这套老逻辑,正在被监管逐条废除——不管数据物理上存在谁的机房,监管的追责链条都从委托方开始。
🛡️ 补课方向:合同里的数据条款该重写了
那么,产业层面该怎么修?这次事件给出的不是一道单选题,而是一整套待办事项。
痛点一:供应商尽调流于形式——“填个问卷就算审过了”
过去绝大多数金融机构的供应商尽调,靠的是让供应商填一份自评问卷、附一份SOC 2或ISO 27001证书复印件。问题是:证书证明的是“某个时间点的管理框架存在”,不是“当前攻防水位达标”。德勤被黑那年,它的各类合规认证一样不缺。
解法:把尽调从“纸面审查”升级为“持续验证”。 对高数据集中度的供应商,应在合同中明确写入渗透测试权、现场评估权、关键系统架构审计权;有条件的机构应要求供应商接入实时安全评级或持续监测服务,把“年度一次的问卷”变成“全天候的信号”。对税务、审计这类数据处理商,尽调标准应直接对齐金融级,而不是按普通办公用品供应商处理。
痛点二:合同条款只约定“保密”,不约定“出事怎么办”
大量外包合同的措辞停留在“乙方应妥善保管甲方数据”这一层面——没有加密标准、没有事件通知时限、没有数据副本要求、没有终止后的数据销毁验证。一旦出事,委托方连“我到底被泄了什么、泄了多少、加密了没有”都问不清楚,因为它在合同里根本没有知情权。欧盟GDPR第28条和第33条其实已经给出了底线模板——处理者须在知悉泄露后“Without undue delay”通知控制者——但很多金融服务外包合同依然没有把这些义务转化为可执行的条款。
解法:把数据条款当成事故预案来写。 合同中必须明确:数据加密与访问控制的最低标准;安全事件的通知时限(建议48小时以内、含初步影响评估);委托方在事件处置中的指挥权与对外披露协同义务;年度数据副本与销毁证明要求;以及量化可执行的经济责任条款。一句话——如果这份合同的条款不够你出事后用来打官司,那它在出事前也不够用来防事故。
痛点三:数据外发无边界,“能交出去的都交出去了”
委托税务服务时,很多机构图省事,把客户全量数据一次性丢给供应商——远超服务实际需要的范围。数据给得越多,供应商侧的“弹药库”越大,一旦被打穿,损失呈整仓引爆。
解法:最小化、分域、可回收。 严格执行数据最小化原则,只传输本次服务必需的字段;对高净值客户的税务数据,考虑引入脱敏、假名化或密态计算,让供应商“用得上数据、看不到原文”;为外发数据建立台账——什么数据、哪批数据、存在供应商哪里、何时到期——并约定定期清理机制。你无法保护你不记得自己交出去过的数据。
痛点四:事件演练只演自己,“第三方挂了我们怎么办”从没演过
绝大多数金融机构的应急演练剧本里,主角永远是自家核心系统。供应链事故——供应商平台被打穿、通知义务在对方手里、客户在问你要答案——几乎从不上演。ION事件中,数百家机构被迫切回手工流程,反应速度的差异,就是平时有没有演练过的差异。
解法:把第三方事故写进演练剧本。 至少每年一次,模拟“核心税务数据供应商发生泄露”场景:委托方如何在供应商不配合或响应迟缓的情况下完成影响评估?如何在监管时限内(例如NYDFS要求的72小时、GDPR要求的72小时)完成上报?如何起草给客户的通报、部署反钓鱼拦截?谁对外发言、以谁的名义?演练出的每一个空白,都应该是下一版合同要补的条款。
📌 写在最后
EY这次泄露,表面上是一起供应商安全事件,实质上是一张写给整个金融业的体检报告:过去二十年,我们把数据外包出去了,却一直默认安全也跟着一起外包了出去——而它从来没有。
对高盛和Man Group来说,接下来要回答的问题很具体:还有哪些客户数据在哪些第三方手里?那些合同里的数据条款,出事时真的够用吗?
对每一家把客户数据交给别人的机构来说,这个问题同样成立。
因为堡垒从来没被攻破,不代表堡垒里的东西没有丢——粮草车被劫的那天,挨骂的永远是城主。
本文由本站 AI 辅助聚合生成,原始来源如下: