OpenAI 數(shù)據(jù)泄露危機(jī)通告拆解：你的公司該如何預(yù)防下一次“第三方事故”？｜楚學(xué)友

早上七點(diǎn)多，手機(jī)震了一下。

標(biāo)題只有一行：Third-party security incident。

發(fā)件人：OpenAI。

OpenAI 告訴我：出事故了，當(dāng)然不是我們自己系統(tǒng)，是“第三方”。

職業(yè)習(xí)慣，我一邊往下劃，一邊劃重點(diǎn)點(diǎn)評。

第一段寫得很標(biāo)準(zhǔn)：

事件發(fā)生在數(shù)據(jù)分析服務(wù)商 Mixpanel 的系統(tǒng)中，OpenAI 用它做 API 前端的流量分析。攻擊者接觸到了有限的分析數(shù)據(jù)。OpenAI 自己的系統(tǒng)沒有被攻破。

緊接著是一串“沒有”的保證：沒有聊天內(nèi)容，沒有 API 請求本身，沒有密碼、密鑰、支付信息、證件號碼被泄露。

對恐慌的處理，先是否定句。這一步，他們做對了。

再往下，是一句更有力度的話：

After reviewing this incident, OpenAI has terminated its use of Mixpanel. 審查事件之后，終止使用 Mixpanel。

在大部分事故通告里，我們經(jīng)常看到是“正在評估”、“將持續(xù)跟進(jìn)”、“敦促合作伙伴整改”。OpenAI 選擇的是另一條路：不再使用。它在第一時(shí)間把自己的站位從“合作伙伴一方”移到了“用戶一邊”。

反應(yīng)，干脆利落。

但我停下來琢磨了一下的，是時(shí)間線：

11 月 9 日，Mixpanel 遭遇攻擊；

11 月 25 日，OpenAI 拿到涉及自己用戶的數(shù)據(jù)集；

之后 48 小時(shí)內(nèi)的 11 月 27 日，發(fā)出這樣的郵件。

這意味著什么？

意味著在長達(dá)16天的時(shí)間里，終端用戶已經(jīng)暴露在數(shù)據(jù)泄露風(fēng)險(xiǎn)之下，而數(shù)據(jù)的“控制者”并不知道自己掌握的數(shù)據(jù)發(fā)生了什么。

這就是數(shù)字供應(yīng)鏈里最危險(xiǎn)的時(shí)刻：你依賴第三方在做“看門人”，卻在關(guān)鍵時(shí)刻發(fā)現(xiàn)，自己其實(shí)是個(gè)戴著墨鏡的瞎子。

1.

反應(yīng)得當(dāng)，卻暴露了系統(tǒng)問題

如果只看這封郵件本身，它是合格甚至出色的。

首先，行動(dòng)姿態(tài)明確。

終止合作不是唯一選項(xiàng)，卻是最有象征意義的選項(xiàng)。它向所有用戶傳遞了一個(gè)信息：在安全問題上，公司愿意為用戶“砍掉一條手臂”，而不是去幫第三方涂藥、打石膏。

其次，信息優(yōu)先級清晰。先告訴你“什么沒丟”，再說“發(fā)生了什么”，最后才是時(shí)間線和細(xì)節(jié)。這種寫法遵循新聞寫作的倒三角結(jié)構(gòu)，比很多繞圈子的“透明聲明”要實(shí)誠得多。

最后，反應(yīng)時(shí)間在監(jiān)管要求之上。一旦拿到數(shù)據(jù)集，就在 48 小時(shí)內(nèi)通知用戶，這在監(jiān)管要求的時(shí)間框架內(nèi)屬于比較快的反應(yīng)。

在塔勒布的風(fēng)險(xiǎn)語言體系里，這屬于“事后反脆弱”的一部分。事情已經(jīng)發(fā)生，你用多大的力度去回應(yīng)，決定了未來別人怎么看你的信用。

但如果把視角從“事故告知郵件寫得好不好”移到“系統(tǒng)是不是健康”，故事就完全不同了。

真正的問題不在 48 小時(shí)，而在前面的16天。

那16 天里，相關(guān)數(shù)據(jù)已經(jīng)處于風(fēng)險(xiǎn)之中，攻擊者有機(jī)會(huì)接觸這些數(shù)據(jù)，而數(shù)據(jù)的“控制者”對具體影響范圍卻幾乎沒有可見性。

這不是一封郵件可以靠“透明”“道歉”覆蓋過去的。

貝克在《風(fēng)險(xiǎn)社會(huì)》中說，現(xiàn)代社會(huì)的特征，是“制造風(fēng)險(xiǎn)的系統(tǒng)，卻又對風(fēng)險(xiǎn)失去控制”。

數(shù)字供應(yīng)鏈就是這樣的系統(tǒng)。你越是分包、拆解、上云、外包，就越容易在自己看不見的地方積累風(fēng)險(xiǎn)。

這次 OpenAI 的表現(xiàn)，像是一位反應(yīng)極快的司機(jī)。在得知前面發(fā)生事故之后，立刻踩了剎車。但抬頭一看，原來前面的擋風(fēng)玻璃上一直蒙著一層霧，他根本看不清剛才開過了什么路。

2.

“第三方”三個(gè)字，為什么讓人不安

郵件開頭的第一句是：透明度至關(guān)重要。緊接著，第二句就把事件框定為“發(fā)生在 Mixpanel 的系統(tǒng)中”。

Mixpanel 可以簡單理解為一塊“網(wǎng)站和 App 的行為黑板”，專門記錄和分析用戶是怎么使用產(chǎn)品的。它不是聊天機(jī)器人，也不是存放數(shù)據(jù)庫的地方，不負(fù)責(zé)算模型結(jié)果，而是記錄“怎么用”。比如用戶什么時(shí)候打開了哪個(gè)頁面、點(diǎn)了哪些按鈕、停留多久、來自哪里、用什么設(shè)備和瀏覽器等。

這些數(shù)據(jù)主要是給產(chǎn)品和運(yùn)營團(tuán)隊(duì)用的：產(chǎn)品經(jīng)理看哪些功能有人用、哪些入口沒人點(diǎn)，要不要改版；運(yùn)營看活動(dòng)有沒有帶來轉(zhuǎn)化、用戶在哪一步流失；管理層則通過整體趨勢判斷產(chǎn)品方向。

本質(zhì)上 Mixpanel 是一套“用戶行為分析工具”，幫公司看清，用戶究竟是怎么用我們的產(chǎn)品的。

在 OpenAI 中，Mixpanel 大致是給 API 前端和相關(guān)界面做“流量體檢”的工具，用來看每天多少人訪問哪些頁面、點(diǎn)擊了哪些操作、在哪一步退出，從而優(yōu)化產(chǎn)品體驗(yàn)。

按 OpenAI 在這封郵件中的披露，它接觸的主要是行為數(shù)據(jù)，而不是你和模型的具體對話內(nèi)容，也不會(huì)拿到你的 API 請求正文、密鑰、密碼、支付信息等。因此，這次被稱為“第三方分析服務(wù)”的安全事件，而不是“聊天內(nèi)容泄露事件”。

這是典型的法律語言：清晰劃定邊界，告訴你“問題不在我們的系統(tǒng)”。

但對普通用戶來說，這種開頭，總是帶著一點(diǎn)點(diǎn)防御性的味道。

傳播學(xué)里有個(gè)概念，叫“責(zé)任歸因框架”。

最好的危機(jī)聲明，永遠(yuǎn)從“對你意味著什么”開始，而不是從“這是不是我的錯(cuò)”開始。

真正的透明，是先承認(rèn)影響，再解釋責(zé)任結(jié)構(gòu)歸屬。而不是反過來。

網(wǎng)絡(luò)應(yīng)用中的第三方有很多，說白了就是除了你正在用的OpenAI本身之外，背后還接著一大串別的服務(wù)。只要你在一個(gè)界面上輸入信息，就幾乎不可能只經(jīng)過一家公司的服務(wù)器。

你以為自己只是在用 OpenAI，其實(shí)你的部分?jǐn)?shù)據(jù)同時(shí)也在經(jīng)過 Mixpanel、Cloudflare、Stripe 等一整條技術(shù)供應(yīng)鏈。一個(gè)看上去簡單的在線服務(wù)，背后是多家供應(yīng)商共同構(gòu)成的風(fēng)險(xiǎn)共同體。

但是從用戶視角看，這一切都被簡化成一個(gè) Logo：OpenAI。這些小白用戶并不知道的名字一旦出現(xiàn)在“安全事件通告”里，自然會(huì)讓人不安。因?yàn)槟銖膩聿恢浪鼈兇嬖凇?/p>

就好像你買了一瓶某大品牌的礦泉水，平時(shí)只認(rèn)得瓶身上的那個(gè)大 Logo，很少有人會(huì)去看背面的細(xì)小字：水源地是誰、灌裝廠是誰、瓶坯和瓶蓋是哪家供應(yīng)商提供的。等到某一天出事，通告里第一次出現(xiàn)一個(gè)你從沒聽說過的“代工廠”或“灌裝企業(yè)”，消費(fèi)者本能會(huì)覺得心里一緊——原來我的水，一直是在這家陌生公司里裝出來的。

數(shù)字產(chǎn)品里的 Mixpanel、Cloudflare、Stripe，也扮演著類似的角色：它們一直在后臺(tái)工作，只是在平時(shí)被大 Logo 遮住了名字，一旦進(jìn)入安全事件的公告，才突然以“第三方”的身份被推到臺(tái)前。

這次事件真正暴露的，是數(shù)字時(shí)代的一個(gè)老問題。企業(yè)可以外包開發(fā)、外包運(yùn)維、外包分析，卻永遠(yuǎn)不能外包掉“對用戶數(shù)據(jù)的最終責(zé)任”。

3.

如何避免自己也發(fā)出那封“第三方事件郵件”

從危機(jī)處理的角度看，OpenAI 這封郵件已經(jīng)算是“寫得不錯(cuò)”的那一類。但如果我們只停在“寫得不錯(cuò)”，而不回頭加以改善，這次事件就被浪費(fèi)了。

如果你是一家大量用云服務(wù)、AI 工具、第三方 SDK 的公司，可以先從下面四件很“接地氣”的事做起。

第一步，先搞清楚是誰在碰你的用戶數(shù)據(jù)，先把賬算清楚。

列一張表。把所有會(huì)碰到用戶數(shù)據(jù)的第三方都寫上去。做數(shù)據(jù)分析的、埋點(diǎn)的、客服系統(tǒng)、消息推送、發(fā)短信發(fā)郵件的、做支付的等等。

每個(gè)第三方都要寫清楚三件事：它看到用戶的哪些信息（比如 IP、郵箱、訪問記錄、訂單號……）；這些數(shù)據(jù)放在哪個(gè)地區(qū)、哪個(gè)機(jī)房；大概會(huì)留存多久。

最后，把這張表做成一頁紙，標(biāo)準(zhǔn)是 CEO 能看懂。

如果有一天出事，CEO拿著這張紙，能在三分鐘內(nèi)看明白“我們的數(shù)據(jù)都去哪兒了”，說明基本合格。如果他一頭霧水，那就還在“黑箱”狀態(tài)。

沒有這張“數(shù)據(jù)地圖”，談不上安全感。

很多公司是到了出事那天，才第一次搞清楚，原來自己有那么多第三方。

第二步，把“時(shí)間要求”寫進(jìn)合同。

出事之后再說“我們會(huì)第一時(shí)間通知您”，其實(shí)已經(jīng)晚了。這句話，應(yīng)該提前寫在和第三方簽的合同里。

在合同里寫清楚一旦第三方懷疑發(fā)生了數(shù)據(jù)問題，必須在多少小時(shí)內(nèi)告訴你（比如 24 小時(shí)內(nèi)）。再過多少小時(shí)，要把受影響的數(shù)據(jù)范圍給到你（比如 48 小時(shí)內(nèi)）。

要求對方出事時(shí)要給你足夠的日志和樣本，這樣你才能自己核查，也才能給用戶一個(gè)交代。

對那些“掌握你大量用戶信息”的關(guān)鍵服務(wù)商，每年至少做一次桌面演練。假設(shè)他們今天出事，你們公司從技術(shù)、法務(wù)到客服，各自要做什么。

不要只指望對方“講良心”，要把時(shí)間和責(zé)任寫進(jìn)合同，這才算真的有制度。

第三步，給每個(gè)第三方都準(zhǔn)備一個(gè)“急停按鈕”。

很多公司以為“下線第三方”是一句口號，真到了生產(chǎn)環(huán)境才發(fā)現(xiàn)要做的事情不少。要改代碼、要發(fā)版、要測試，動(dòng)輒幾天。

更穩(wěn)妥的做法是：

系統(tǒng)設(shè)計(jì)上一開始就預(yù)留“開關(guān)”。每一個(gè)外部服務(wù)，都可以通過配置一下子關(guān)掉，而不是等下一次更新上線。

一出事，就能在幾小時(shí)內(nèi)讓它從生產(chǎn)環(huán)境里“消失”。

平時(shí)使用就克制一點(diǎn)，能不用真實(shí)姓名、身份證號、完整郵箱，就不要給；能用脫敏、匯總的數(shù)據(jù)完成統(tǒng)計(jì)，就不要把一整份原始數(shù)據(jù)交出去。

定期檢查所有接入的 SDK，看看它到底在采集什么，有沒有超出一開始承諾的范圍。

平時(shí)給出去的越少，出事時(shí)需要解釋的就越少。

第四步，把那封“道歉信”，提前寫好。

數(shù)據(jù)泄露的通知信，不應(yīng)該在事故當(dāng)天臨時(shí)拼出來。

它應(yīng)該是應(yīng)急預(yù)案里，事先寫好、定期拿出來修改的一份模板。這也是我提供的預(yù)案服務(wù)。

一封像樣的“第三方數(shù)據(jù)事件通知”，起碼要講清四件事：

先講影響?；卮鹩脩糇铌P(guān)心的問題。錢安全嗎？賬號安全嗎？身份信息安全嗎？

再講事實(shí)。什么時(shí)候發(fā)現(xiàn)的？哪個(gè)系統(tǒng)出問題了？大概是什么類型的數(shù)據(jù)？目前確認(rèn)的影響到哪里為止？

然后是行動(dòng)。你已經(jīng)做了什么（比如關(guān)掉某個(gè)第三方、重置密鑰、限制登錄等）；接下來還會(huì)做什么，有沒有下一步的排查計(jì)劃。

最后講邊界。后面會(huì)在哪些時(shí)間節(jié)點(diǎn)給更新？哪些結(jié)論要等調(diào)查結(jié)束才能說清楚？

在這四件事情講清楚之后，再說“我們很重視安全”或“非常抱歉”，這些話才不會(huì)顯得空洞。

馬可·奧勒留在《沉思錄》里說過：傷害你的不是事情本身，而是你對事情的看法。

放到今天的數(shù)據(jù)世界里，可以說，很多時(shí)候，真正傷害信任的，不是那次黑客攻擊本身，而是企業(yè)在事后的表現(xiàn)：

• 事發(fā)很久才發(fā)現(xiàn)，說明平時(shí)“看不見”；

• 說了半天說不清楚，說明平時(shí)“沒有數(shù)”；

• 承諾很多，動(dòng)作很少，說明真正“做不到”。

OpenAI 這次事件，反應(yīng)勉強(qiáng)可以打 A-，供應(yīng)鏈可見性大概只有 B-。

它提醒我們，你可以把工作外包給別人，但你沒有辦法把風(fēng)險(xiǎn)外包給別人。

真正的解決之道，不是寫出一封漂亮的危機(jī)郵件，而是讓這封郵件出現(xiàn)的概率，一次又一次被壓低。

The End

繼續(xù)推薦我的書

還有我的課