最近 Clubhouse 有一起「資料外洩」的資安事件，即有 130 萬筆用戶資料在駭客論壇上流通。

而這起事件中最讓人議論紛紛的地方，在於官方並不認為這是屬於「資料外洩」的資安事件。

Clubhouse 130 萬用戶個資「被公開」，算不算「資料外洩」？是否存在資安問題？

這要讓我們先從「資料分類」開始講起。

資料分類（Data Classification）

在做資安時大家都有一個觀念：任何一個資安防禦策略都是一項成本，無論是時間上或是金錢上。在資源有限的狀態下，我們無法把每筆資料都視為「至關重要」 並且無上限地花費預算保護它們。

所以在做資安風險管理時，我們可以適度將資料分成不同等級，依照每個等級的優先權、機密程度，來給予適當的保護措施。

在業界常見資料分類的類別，大致可以分成四種：

  • 公開（Public）：任何開放無敏感的資料，像是每個企業的登陸頁（Landing page）、公開形象網站、公開資訊介紹等等。
  • 內部（Internal）：只在公司內部使用的資料。若該資料外洩僅會對業務產生輕微影響。常見項目像是公司內部政策、內網資訊、軟體系統資訊等等會被分類在此。
  • 機密（Confidential）：只授權特定部門使用的資料。一但外洩將會對企業造成商業損害。如定價、行銷資料、加密金鑰等等。
  • 限制（Restricted）：高度敏感的資料，根據「僅知原則（Need to Know Basis）」，僅在「必須知道時」才授與存取權限。如用戶的個人可識別資訊（PII，Personally identifiable information）、信用卡號等，一但外洩將會造成企業財務上、法律上等損害。

data classification

我們可以依照這四個分類，定義出 0 ~ 3 嚴重等級，0 為公開（Public）、3 為機密（Confidential）。並且根據該等級、現有資源、風險等評估，做出符合該等級的保護措施。

屬於哪個資料類別？

回到新聞內容，Clubhouse 這起事件中這些「被公開」的資料，原本應該被歸類在什麼類別？

我們可以從 Cybernews 新聞中看到：

What was leaked?

The leaked database contains a variety of user-related information from Clubhouse profiles, including:

  • User ID
  • Name
  • Photo URL
  • Username
  • Twitter handle
  • Instagram handle
  • Number of followers
  • Number of people followed by the user
  • Account creation date
  • Invited by user profile name

可以發現被公開的資料中，基本上都是 Clubhouse 使用者的公開資訊，也就是說一般使用者只要使用了 Clubhouse，自然就會將這些資料公開。

對於本身「已經公開」的資料，會有「外洩」的可能嗎？

答案也許可以從 Clubhouse 在 Twitter 上官方的說明得知：

This is misleading and false. Clubhouse has not been breached or hacked. The data referred to is all public profile information from our app, which anyone can access via the app or our API.

Clubhouse 聲明這並未遭駭且並非資料外洩，這些資料皆屬「公開個人資訊（public profile information）」，任何人都可以藉由 App 或 Clubhouse API 來獲得。

既然是公開資料，是不需要被保護的，為什麼仍有許多人表示對 Clubhouse 的處理方式感到不滿？

也許資安問題並不是出在資料，而是「獲取資料的方式」。

資料沒問題，但行為不允許

在上述官方聲明中，使用者「存取 API」這個動作是允許的。但使用機器人、網頁抓取等「API 濫用（API Abuse）」的動作並不被允許。

在 Clubhouse Terms of Service 中有提到：

Intellectual Property Rights

Service Content, Software and Trademarks: … In connection with your use of the Service you will not engage in or use any data mining, robots, scraping or similar data gathering or extraction methods. …

服務條款中其實有聲明使用者不能以機器人、網頁抓取等方式獲取相關資料。

而這次事件，若要獲得大量 130 萬筆用戶資料，則依賴機器人、網頁抓取等「類似的資料獲取方法（similar data gathering or extraction methods）」可能性會非常高。

也就是駭客論壇上流通的資料，極高機率是用不適當的手段獲取的，儘管資料本身並不敏感。

回顧整起事件，的確資料本身是公開的、是不需要特別保護的，但讓一些人感到不滿的地方，也許是 Clubhouse 並沒有採取防禦策略、沒有對「API 濫用」進行預防和修正。

怎麼防止 API 遭到濫用？

「API 濫用」這樣的問題其實在業界很容易被忽視，而一但發生濫用時很容易損害到用戶的權益。

常見的原因是對於 API 的授權過度寬鬆、未限制存取頻率、未主動偵測濫用行為等等所造成。

防止濫用的方法，除了條款上，我們明確制止這樣的行為之外，其實可以從技術面強化和改善 API，降低 API 被濫用的可能性：

  • 請求次數限制（Rate Limit）：正常使用者不可能會高頻率地發送 API 請求，可以藉由設定 API 請求次數、頻率限制來防止程式自動化地資料抓取。
  • API 授權：將 API 設計成需驗證和授權才可使用，使用者需在登入後先取得系統發放的 API Token，才可用來請求 API、獲得服務資訊。並且預設不授權使用者過多的 API 權限，可將更多進階 API 功能設定為驗證後開通。
  • 日誌與偵測：系統其實可以從第二點的 API Token 得知使用者使用 API 的情況，可藉由「去除敏感資料後的 API 請求紀錄」，來偵測是否有高頻率、異常請求、濫用等狀況，並且進行後續反應策略。

上述這三種方法是常見抵禦 API 濫用的策略，可藉由較少的成本來獲得防禦效果。更完整的技術防禦與檢驗，可以參考 OWASP Testing Guide 以及 OWASP ASVS 定義的標準來執行。

借鏡

此事事件在評估後，或許僅能稱上是低度風險，讓官方僅以 Twitter 發文形式解釋。但畢竟處理資安風險除了技術面之外，後續的公關處理也是一個挑戰。

也許對那些不滿的民眾來說，不管是什麼等級的資安事件，還是會希望官方能以一個「積極保護用戶的態度」來面對。

如果在事發時，對用戶發出警告通知、公布採取的防禦策略、事件後續追蹤與報表等，也許都是能讓使用者更放心且信賴的方式。

資安防禦難度很高，要即時反應資安事件也很不容易。這類資料外洩的新聞，希望能警惕我們若是遭遇高風險資安威脅，我們能更積極面對用戶、並且主動採取防禦策略。