透過嚴謹的 ISO 27001 審核，本可避免一場全球資料外洩事故

布拉德法比尼

DQS 網絡安全產品經理兼 ISO 27001、ISO 9001 審核員

5月 11 , 2026

我們近期注意到一起資料外洩事件：高達 6400 萬人的個人資訊，透過某個使用的第三方系統外洩給未獲授權的用戶。所幸，發現此安全漏洞的人士秉持道德操守，向受影響的公司通報了他們所發現的漏洞。

背景

某家全球性企業使用第三方 AI 聊天機器人來管理其招聘流程的早期階段，以收集求職者的詳細資料（包括個人資料與履歷），隨後讓他們進入初篩測驗。

儘管求職者使用單一登入（SSO），但網站上仍保留了一個連結，供第三方供應商用戶點擊並使用用戶名稱與密碼進行登入。這是為了讓供應商能夠存取測試餐廳而留下的後門。然而，這個後門卻透過簡單的用戶名稱與密碼組合遭到破解。一旦取得未獲授權的存取權限，攻擊者便能存取該測試環境中的所有求職者資料。

在隨意瀏覽了一番後，他們發現了對系統 API 的調用，該 API 用於儲存求職者的個人資料以及與 AI 對話機器人的聊天記錄。該 API 內部的 API 間接物件參照（Insecure Direct Object Reference, IDOR）漏洞，允許他們透過篡改求職者 ID 參數，來列舉並遍歷系統中的所有求職者，無論這些求職者當初是向哪個職缺申請。

預防措施

該供應商過去（且至今）均已獲得 ISO 27001 與 SOC 2 標準認證。

那麼……承包商本可以（也應該）如何預防導致此次外洩的漏洞呢？在聚焦於此處所列之 ISO/IEC 27001:2022 控制措施的嚴謹審核協助下，本可揪出圍繞這些措施的某些活動與鬆散程序，從而確保資訊安全。

選擇具備深厚行業經驗之合格審核員的知識型認證機構，將能協助企業識別管理系統與程序中的弱點，並提供機會提升所部署之緩解與管控措施的穩健性，以限制甚或理想中完全防止系統發生資料外洩。

對於涉事組織與供應商而言，關鍵漏洞可歸納為以下幾大類：

cisis12-certification-dqs-man taps on laptop on which abstract 3d data protection images can be seen

應用程式存取不安全

儘管求職者和餐廳用戶管理申請人的存取是透過提供安全性的 SSO 進行，但仍存在一個使用簡單用戶名稱與密碼的供應商存取後門。此外，所使用的不安全用戶名稱與密碼竟然是「123456」。據報這是在 2018 年系統建置時留下來的遺留設定。

可用於預防此類情況的控制措施包括：

5.16 – 身分管理（Identity Management）：身分應在其整個生命週期中進行管理，包括在不再需要時進行停用與移除。除非基於業務或營運原因，否則用戶憑證不應在人員之間共用。
5.17 – 驗證資訊（Authentication Information）：在可能的情況下，應使用強密碼或密碼短語。不應使用常用密碼或遭外洩的用戶名稱。產品中應內建驗證機制，且密碼儲存公用程式應設定為僅允許使用強密碼。
8.31 – 開發、測試和生產環境的分隔（Separation of development, test and production environments）：測試環境與生產環境應予隔離，如此方能移除、匿名化或刪除任何敏感資料。
8.33 – 測試資訊（Test information）：若用於測試，敏感資料應予以移除或遮罩，並在測試完成後正確刪除測試所使用的資料。

iso27002-changes-dqs-a code of letters and numbers

API 不安全（Insecure API）

該 API 允許對其發出的調用返回結果，卻未對調用者是否具有存取所請求資料的授權進行任何檢查。雖然在初始用戶驗證後，該 API 被用於系統內部的核心存取，因而推測其執行過驗證，但我們並未確認在檢索記錄時是否有進行授權檢查，以確認發出 API 調用的用戶是否擁有該記錄的存取權限。

安全的 API 設計亦應具備某種速率限制（Rate limiting）或檢查機制，以偵測是否有人正試圖利用間接物件參照漏洞。

能緩解或偵測此類漏洞的具體控制措施為：

8.26 – 應用程式安全需求（Application Security Requirements）：在建置 API 之前確定並記錄其安全需求，以便將這些需求內建於產品和環境中。
8.27 – 安全系統架構與工程原則（Secure system architecture and engineering principles）：確保 API 架構安全，並將安全需求納入解決方案的架構考量中。
8.16 – 監控活動（Monitoring activities）：監控 API 上的活動，藉此識別並發出警報，以防有人正試圖以顯示惡意意圖的方式使用 API（例如循環遍歷身分）。

supplier-audits-dqs-two businessmen shaking hands

供應鏈管理

作為一個組織，您需對所有資料負起全責，包括您的組織從用戶那裡收集的個人身分資訊（PII）。這涵蓋任何在由您的供應商擁有和管理的系統中所收集與儲存的資料。作為與第三方供應商合作的一部分，應評估安全考量，例如檢查認證或其他審核，以建立對其將能確保資料安全的信心。這亦可包括審查其系統安全性的權利，而此點應透過合約予以約定。

在正式上線新的系統建置後，應對其支援需求與存取要求進行檢討與監控。

用於管理供應鏈的控制措施包括：

5.20 – 在供應商協議中處理資訊安全（Addressing information security within supplier agreements）：最初，應將資料安全納入與供應商的協議中，以明確界定供應商處理資料的責任。這為後續的控制措施奠定了基礎。
5.21 – 管理資通訊（ICT）供應鏈中的資訊安全（Managing information security in the ICT supply chain）：組織應要求供應商提供描述其產品中安全功能的資訊，並透過實施驗證產品是否符合安全需求的監控程序，來確保供應商軟體的安全性。
5.22 – 供應商服務的監控審查與變更管理（Monitoring review and change management of supplier services）：組織應監控並審查對供應商服務與產品的變更，包括識別安全漏洞以及這些漏洞的管理方式。