隱私與資安
這是「風險、智慧財產與合規」的第四課。本課要先把一件最常被混為一談的事分開:隱私問的是「你到底該不該持有這筆資料、憑什麼持有」,資安問的是「你已經持有的東西,守不守得住」。
這兩個問題的答案彼此獨立。一個加密完善、權限嚴格、從未被入侵的系統,如果裡面塞滿了你當初沒有任何正當理由收集、也早就不再需要的個人資料,那它仍然是一次隱私失敗——只是還沒有人發現而已。反過來,一家只收集必要資料的公司,若把資料放在一個共用密碼的雲端硬碟,那是一次資安失敗,隱私原則做得再好也擋不住。
美國國家標準與技術研究院(NIST)在《網路安全框架 2.0》裡把這件事講得很清楚:資安與隱私是各自獨立的學科,只是目標在某些情況下重疊;資料外洩確實會造成隱私損害,但隱私風險也可能透過與資安事件完全無關的方式產生(fact,見資料來源)。同一機構的《隱私框架》進一步指出,資料處理本身就可能對個人造成問題,範圍從尊嚴層面的傷害(例如難堪、汙名)到更具體的損害(例如歧視、經濟損失或人身傷害)(fact,見資料來源)。換句話說,不必有人入侵,光是「你決定拿這些資料去做某件事」,就足以造成傷害。
全課沿用「風險、智慧財產與合規」共用的教學公司「宏茂科技」,一家做消費端 App 的小型軟體公司,幣別為元。所有金額、比率與資料類別都是為教學建構的 example,不是任何真實公司的資料,也不是任何地區的法定標準。
本課要回答四個問題。
第一,哪些資料我根本不該持有?多數小公司的預設是「先存起來,說不定以後用得到」。本課會證明這個預設在算術上是虧的。
第二,我到底持有什麼?這聽起來像廢話,但絕大多數公司答不出來。沒有清單,就沒有辦法保護、沒有辦法刪除、也沒有辦法在事件發生時判斷影響範圍。
第三,以我的規模,應該買哪些控制?資安產品的市場是為大型企業設計的,一家十五人的公司照單全收會破產,什麼都不做又會出事。判準必須是算出來的。
第四,真的外洩了怎麼辦?事件當下的每一個小時都很貴,而事前沒有寫下來的流程,事發時不會憑空出現。
完成標準是四個可檢查的動作:讀者能產出一份六欄的資料盤點;能指出盤點中至少一類「可以整批刪掉」的資料,並算出刪除它使期望損失下降多少;能列出一份與自己規模相稱的控制清單,每一項都附上年成本與預估效果;能寫出一份一頁的資料外洩應變流程,指明誰在什麼時間做什麼。
先定義本課反覆使用的詞。個人資料(personal data) 依經濟合作暨發展組織(OECD)《隱私準則》的定義,是指與一個已識別或可識別的個人有關的任何資訊(fact,見資料來源);請注意「可識別」三個字——裝置識別碼、精確定位軌跡、交易紀錄常常在單獨看似匿名的情況下,合併後就足以指向特定個人。資料盤點(data inventory) 是一份列出公司持有哪些個人資料、為什麼持有、放在哪裡、誰能存取、保存多久、分享給誰的清單。資料最小化(data minimisation) 是只收集與保存達成特定目的所必需的資料。保存期限(retention period) 是一類資料從產生到被刪除之間允許存在的時間。最小權限(least privilege) 是每個帳號只擁有完成其工作所必需的最小存取範圍。多因素驗證(multi-factor authentication,MFA) 是登入時除了密碼之外,還要求第二種獨立憑證。受託處理者(processor) 是代替你處理個人資料的外部廠商,例如你的雲端主機、客服系統或電子報寄送服務;次受託處理者(sub-processor) 則是你的廠商再委外的對象。網路釣魚(phishing) 是偽裝成可信任來源、誘使人交出憑證或執行動作的攻擊。攻擊面(attack surface) 是所有可能被攻擊者利用的入口總和。事件回應(incident response) 是偵測到事件後的一整套處置程序。
隱私是設計紀律,資安是控制系統
Section titled “隱私是設計紀律,資安是控制系統”把兩者分開之後,處理方式也不同。
隱私問題主要在設計階段解決。當你決定新功能要不要多問一個欄位、要不要記錄使用者的位置、日誌要不要保留使用者 ID 的時候,你就已經決定了未來三年的隱私風險。這些決定幾乎不花錢,也幾乎無法事後撤銷——資料一旦收進來、備份出去、餵給第三方分析服務,你就再也不確定它有幾份副本。
資安問題主要在營運階段解決。它是一套持續運作的控制:權限要定期複核、系統要持續修補、備份要反覆測試、日誌要有人看。它像刷牙,不是像蓋房子;停下來三個月,前面兩年的成果就開始失效。
NIST 的兩份框架剛好對應這個分工。《隱私框架》的五個功能是 Identify-P(辨識)、Govern-P(治理)、Control-P(控制)、Communicate-P(溝通)、Protect-P(保護),用來管理資料處理本身產生的隱私風險;《網路安全框架 2.0》的六個功能是 GOVERN、IDENTIFY、PROTECT、DETECT、RESPOND、RECOVER,用來管理資安風險(fact,見資料來源)。兩者的交集是「與資安相關的隱私事件」,也就是一般所說的資料外洩。值得注意的是,NIST 明說《網路安全框架》描述的是期望達成的結果,不規定要怎麼達成,而且刻意保持與部門、國家、技術無關(fact,見資料來源)。這正是本課的立場:可以教的是問題與算術,不能教的是任何單一地區的法定義務。
七個跨制度重複出現的隱私原則
Section titled “七個跨制度重複出現的隱私原則”OECD 於 1980 年 9 月 23 日通過、2013 年 7 月 11 日修訂的《隱私準則》列出八項「國內適用基本原則」:收集限制、資料品質、目的特定、使用限制、安全維護、公開、個人參與、當責(fact,見資料來源)。這份文件被廣泛視為後續各國制度的共同基礎;OECD 自己的說明也指出,各國常把它當成自身框架的基石(fact)。但請注意一個關鍵限制:OECD 明白把這些準則定位為最低標準,各國可以再加上額外措施(fact)。所以下面這些原則可以當成設計問題來用,不能當成任何地區的法律義務清單。
以下把它們整理成小公司可以直接問自己的七個問題。
一、目的限制(purpose limitation)——我收這筆資料是為了做什麼? 對應 OECD 的目的特定與使用限制原則:目的應於收集時(最遲不晚於收集時)即被特定,之後的使用限於該目的或與之不相牴觸的目的(fact)。設計問題是:如果我現在把這個欄位的用途寫在一句話裡,這句話會不會讓使用者覺得被騙?如果會,問題出在功能設計,不出在文案。
二、資料最小化——沒有這個欄位,功能還能不能運作? OECD 的收集限制原則要求收集應有限度,並以合法且公正的方式取得(fact)。實務上最好用的檢驗是:把這個欄位刪掉,跑一次主要流程,如果跑得完,這個欄位就不是必要的。
三、正確性(accuracy)——資料錯了會怎樣? OECD 的資料品質原則要求個人資料應與使用目的相關,並在必要範圍內正確、完整、保持最新(fact)。這一項常被忽略,但它的傷害很具體:一筆錯誤的地址、錯誤的信用註記或錯誤的合併帳號,會讓一個真實的人承受不屬於他的後果。
四、保存限制(storage limitation)——這筆資料什麼時候該被刪掉? 這是本課的重點,下一節與 ## 逐步推導 會完整處理。要注意的是,OECD 的八項原則並沒有一條叫「保存限制」;它是從「資料應與目的相關、使用限於目的」推導出來的實務結論(inference)——目的達成之後,繼續持有就失去了理由。許多後續制度把它獨立成一條,但條文形式與具體年限並不一致。
五、安全維護(security safeguards)——被拿走會怎樣? OECD 要求個人資料應受合理的安全維護措施保護,以防止遺失或未經授權的存取、破壞、使用、修改或揭露(fact)。「合理」兩個字是刻意的:它隨資料敏感度、公司規模與可得技術而變動,沒有一份全球通用的清單。
六、透明(transparency)——使用者查得到嗎? OECD 的公開原則要求對個人資料的做法與政策採取普遍公開的方針,並讓人可以確認資料的存在與性質、主要用途,以及資料控制者的身分與通常所在地(fact)。個人參與原則則賦予個人確認、取得、要求說明拒絕理由,以及在挑戰成功時要求刪除、更正、補充或修正的權利(fact)。但請務必注意:這些權利的具體範圍、行使方式與回覆期限在各地並不相同,OECD 文本本身沒有規定任何天數。
七、當責(accountability)——誰負責,怎麼證明? OECD 的當責原則要求資料控制者對落實上述原則的措施負責(fact)。2013 年修訂新增的「實施當責」一節更具體:資料控制者應有一套隱私管理計畫,涵蓋其控制下的所有個人資料、依營運的結構與規模量身訂做、以隱私風險評估為基礎提供適當保障、整合進治理結構並建立內部監督機制、包含回應詢問與事件的計畫,並依持續監控與定期評估更新;而且應能在主管機關要求時展示這套計畫(fact)。這一段幾乎就是一份小公司的隱私工作清單。
這七個問題到哪裡為止是通用的?到「問題本身」為止。具體的合法事由清單、個人權利的內容與期限、通報義務的觸發門檻與天數、跨境傳輸的合法機制,全部不是全球通用的,必須逐地查核,請見 隱私與數位服務的地區差異。
資料盤點:你無法保護沒有列出來的東西
Section titled “資料盤點:你無法保護沒有列出來的東西”NIST《隱私框架》把「盤點資料被處理的各種情境」列為 Identify-P 功能的基礎活動,並說明這類活動是有效運用整個框架的前提(fact,見資料來源)。理由很直接:後面每一個動作都需要這份清單。
- 要判斷該刪什麼,需要知道有什麼。
- 要回答使用者「你們有我哪些資料」,需要知道有什麼。
- 要在外洩後兩小時內判斷影響範圍,需要知道有什麼。
- 要決定買哪個控制,需要知道最貴的那堆資料放在哪裡。
一份可用的盤點有六欄:資料類別(例如電子郵件、裝置識別碼、付款卡末四碼)、目的(一句話,寫不出來就是不該留)、位置(哪個資料庫、哪個雲端服務、哪台筆電、哪個試算表)、存取者(哪些角色、幾個人)、保存期限(明確的天數或條件)、分享對象(哪些受託處理者)。
宏茂科技的盤點(教學 example):
| 資料類別 | 目的 | 位置 | 存取者 | 保存期限 | 分享對象 |
|---|---|---|---|---|---|
| 帳號電子郵件 | 登入與服務通知 | 主資料庫 | 工程 3 人、客服 2 人 | 帳號存續期間 | 電子報服務商 |
| 付款卡末四碼與授權碼 | 對帳與退款 | 金流商系統 | 財務 1 人 | 交易後 5 年 | 金流商 |
| 應用程式使用日誌(含使用者 ID) | 除錯與異常偵測 | 日誌服務 | 工程 3 人 | 未設定 | 日誌服務商 |
| 客服對話紀錄 | 客訴處理 | 客服 SaaS | 客服 2 人、主管 1 人 | 未設定 | 客服系統商 |
| 舊 KYC 身分證件影像 | 已於 2024 年停用的實名功能 | 物件儲存的舊 bucket | 工程 3 人(全體) | 未設定 | 無 |
這張表一畫出來,問題立刻浮現:三類資料的保存期限是「未設定」,而最敏感的那一類——身分證件影像——服務的目的已經不存在了,卻仍然被全體工程人員可讀地放在物件儲存裡。這不是入侵造成的,是設計與紀律造成的。它同時違反目的限制(目的已消滅)、最小化(不需要)與最小權限(三個人都能讀)。
畫這張表沒有技術門檻,也不需要買任何產品。它需要的只是有人被指定去做,並且被要求交出結果——這正是 流程、單一負責人與品質關卡所說的單一負責人與完成定義。要實際完成一份,請做 風險與智財稽核。
最小化為什麼是本課最有用的一句話
Section titled “最小化為什麼是本課最有用的一句話”風險登錄與處理建立的算式是:
期望損失 = 可能性 × 影響金額
大多數資安投資改變的是可能性:MFA 讓帳號被盜的機率下降,修補讓已知漏洞被利用的機率下降,教育訓練讓有人點下釣魚連結的機率下降。這些都有用,但它們都有一個共同的天花板:再怎麼降低,可能性不會變成零。攻擊者只需要成功一次,你需要每次都成功。
刪除資料不一樣。你沒有持有的資料不可能被外洩。刪掉一整類資料,改變的是式子右邊那一項——影響金額,而且是確定性地改變,不依賴任何控制持續有效。這是本課最有價值的一個洞見,## 逐步推導 會把數字完整算出來。
這也解釋了為什麼「保存政策」在小公司通常是投資報酬率最高的隱私與資安工作:它一次性地降低了未來每一次事件的規模,而且不需要持續付費給任何廠商。同樣重要的是它降低的是尾端——風險登錄與處理已經說明,期望值是風險中立的,而現金有限的公司不是。把可能致命的 20,000,000 元 事件變成 15,000,000 元 事件,在期望值上只值 250,000 元/年,在「公司會不會活下來」上的意義卻大得多。
與規模相稱的資安控制
Section titled “與規模相稱的資安控制”小公司的資安不是大公司資安的縮小版,而是一組不同的優先順序。以下每一項都可以由一家十到二十人的公司在數週內完成,並且對應 NIST《網路安全框架 2.0》PROTECT 功能所涵蓋的結果類別——身分管理、驗證與存取控制、意識與訓練、資料安全、平台安全與技術基礎設施韌性(fact,見資料來源)。
存取控制與最小權限。 列出所有系統,逐一檢查誰有存取權、需不需要。宏茂科技的舊 bucket 三個工程師都能讀,是因為權限是照「職稱」給的,不是照「工作需要」給的。實務做法是每季複核一次,把清單印出來逐行簽名——這是幾乎零成本、效果最大的一項。
多因素驗證。 對電子信箱、雲端主機控制台、原始碼倉庫、金流後台與網域管理帳號強制啟用。這五個是攻擊者的主要目標,因為攻破其中任一個都能連鎖取得其他。密碼會外洩、會重複使用、會被釣走;第二因素讓單靠密碼的攻擊直接失效。
修補與版本管理。 建立一份「我們在用什麼」的清單(作業系統、資料庫、框架、函式庫、SaaS),並訂出更新節奏。多數實際發生的入侵利用的是已知且已有修補程式的漏洞,不是新發現的攻擊手法。
備份與「經過測試的還原」。 這一項要特別強調:未經測試的備份不是控制,只是一個信念。備份工作跑成功、檔案大小看起來正常,都不證明你能還原。唯一的證明是真的還原一次,並確認資料完整、時間點正確、還原耗時可以接受。這件事至少每季做一次,並記錄「開始時間、完成時間、驗證方式、由誰執行」。## 逐步推導 會算出測試還原的年度價值。
日誌。 沒有日誌,你在事件發生後無法回答最重要的兩個問題:對方進來多久了、拿走了什麼。要求是:關鍵系統的登入、權限變更與大量資料匯出必須留下紀錄,紀錄要存在攻擊者無法輕易刪除的地方,而且要有人定期看。無人查看的日誌只在事後有用。
傳輸中與靜態加密。 對外連線使用 TLS 是今天的基本要求;資料庫與備份的靜態加密多數雲端服務只要勾選即可。要誠實說明它的邊界:靜態加密防的是「儲存媒體或備份檔被整個拿走」,防不了「有效帳號被盜用後合法讀取」。而後者才是實務上更常見的外洩途徑。這就是為什麼 ## 常見誤解 要處理「有加密就安全了」。
廠商與受託處理者風險。 你的資料在別人的系統裡,風險不會因為換了主體而消失。NIST《網路安全框架 2.0》在 2.0 版特別強化了治理與供應鏈兩個主題,並把供應鏈風險管理列為關鍵(fact,見資料來源);《隱私框架》也指出,當資料處理生態系跨越國界時,透過正式協議(例如合約)落實隱私要求特別重要(fact)。實務上的最低要求是:知道每一家廠商、知道他們拿到哪些資料、在合約裡寫明處理範圍與再委外規則,並在他們出事時能被通知。相關的合約條款設計見 合約與內部控制。
人是控制系統的一部分
Section titled “人是控制系統的一部分”技術控制擋不住一個把憑證交出去的人。
網路釣魚是最常見的入口,而它成功的原因不是收信人愚蠢,是攻擊者利用了正常工作情境:一封看似來自執行長、要求緊急處理付款的信;一封看似來自雲端服務商、要求重新登入的通知。有效的防禦有三層:技術上(阻擋外部寄件者偽裝內部網域、對所有信箱啟用 MFA)、流程上(付款與帳號變更必須經過第二管道口頭確認,這一點在 合約與內部控制的職責分離原則裡有完整說明)、文化上(回報可疑信件的人不會被責備,因為責備會讓下一個人選擇沉默)。
社交工程的範圍更廣:假冒求職者索取內部資訊、假冒客戶要求變更帳戶、假冒廠商要求更新收款帳號。共同的防線是同一條:涉及金錢或存取權的變更,一律用一個獨立管道確認。
離職是一次資安事件。 這句話值得單獨寫下來。離職當天必須完成的動作是一張清單:停用所有帳號(包含 SaaS,這些最常被遺漏,因為它們不在 IT 的清單上)、撤銷 API 金鑰與個人存取憑證、更換共用密碼、回收裝置、確認公司資料不在個人裝置或個人雲端硬碟上。做不到「當天」的公司,等於在每一次人員異動時把攻擊面開著。這件事的權責歸屬與交接紀律,在 外包、擴張與危機有更完整的討論。
資料外洩的事件回應
Section titled “資料外洩的事件回應”事件回應的目標不是「不出事」,是出事時損失可控。NIST《網路安全框架 2.0》把 RESPOND 定義為「針對偵測到的資安事件採取行動」,涵蓋事件管理、分析、緩解、報告與溝通;RECOVER 則是「使受事件影響的資產與營運回復」(fact,見資料來源)。六個步驟必須事前寫好,因為事發當下沒有人有心情設計流程。
一、控制(contain)。 先阻止繼續擴大:撤銷可疑憑證、隔離受影響系統、暫停可疑的資料匯出。這一步要快,而且要有人有權在半夜做決定——事前指定,不要事發時開會。
二、評估範圍(assess scope)。 哪些資料類別、多少筆、哪些人、什麼時間區間。這一步的速度完全取決於你有沒有資料盤點與日誌。有盤點的公司在幾小時內能給出範圍,沒有的公司要花幾週,而在多數制度下,你的通報義務不會因為你查得慢而延後起算。
三、保全證據(preserve evidence)。 在急著「清乾淨」之前先保存日誌、系統映像與時間軸。這是本步驟最違反直覺的地方:工程師的本能是立刻重建系統,而重建會抹掉你之後需要用來回答監理機關、保險公司與客戶的證據。
四、依適用義務通報(notify)。 這裡本課刻意不給任何天數。OECD《隱私準則》的當責一節僅要求資料控制者在發生重大影響個人資料的安全事件時,「於適當情形下」通知隱私執法機關或其他相關機關,而在該事件可能對資料主體造成不利影響時,通知受影響的資料主體(fact)——它沒有規定任何期限。真實的通報門檻、對象、格式與期限完全由當地制度決定,差異很大,必須事前查好並寫進你的流程,見 隱私與數位服務的地區差異。事前查好的意思是:在平時就把「我們適用哪一部法、要通報給誰、幾小時內、用什麼表格」寫在流程文件的第一頁。
五、修復(remediate)。 修掉根本原因,不只是這一次的症狀。如果入口是一組沒有 MFA 的管理員帳號,修復是「所有管理員帳號啟用 MFA」,不是「把那一組密碼改掉」。
六、檢討(review)。 事後寫一份不歸咎個人的檢討:時間軸、根本原因、偵測花了多久(這通常是最難看的數字)、哪些控制有效、哪些沒有、要改什麼。事件當責案例呈現的正是責任不明時,事件處理如何在每個人都很努力的情況下延誤——那個案例的教訓在資料外洩情境中只會更嚴重,因為外洩有外部時鐘在跑。
失敗替代方案
Section titled “失敗替代方案”失敗替代方案一:先買一套資安產品,把客戶的資安問卷答完。
宏茂科技拿到一份企業客戶的採購問卷,四十題,其中十二題是「貴公司是否具備……」。業務希望這週就簽約。最快的路徑看起來是:買一套端點防護與一套弱點掃描,把那十二題從「否」變成「是」。
它在當下看起來完全合理,理由有三個,而且三個都是真的。第一,那些控制本身確實有價值,不是假的。第二,它直接解除了一筆訂單的阻礙,效益立即可見可算。第三,問卷是客戶給的,照著答等於照著業界標準走,決策者不必自己判斷。
它失效的假設是「控制清單可以取代對自身資料的理解」。實際發生的是:問卷從來沒有問過「你們持有哪些個人資料、放在哪裡」,所以那個放著舊 KYC 身分證件影像、全體工程師可讀的舊 bucket,在四十題裡一次也沒有出現。公司買了兩套產品、通過了問卷、簽了約,而風險最高的那一堆資料完全沒有被碰到。更糟的是,通過問卷產生了一種已經處理完畢的感覺,讓真正的盤點被推遲了兩年。
預警訊號有三個:資安預算的第一筆支出是產品而不是盤點;沒有人能在會議上說出公司持有哪幾類個人資料;以及決策的觸發事件是外部要求(問卷、稽核、客戶催促)而不是內部評估。任何一項成立,就該先停下來畫那張六欄表。
失敗替代方案二:把別人的隱私政策抄一份貼上去。
這是 抄襲合規範本案例呈現的失敗。它看起來合理的理由同樣真實:網站需要一份隱私政策才能上架、被抄的公司規模更大顯然更懂、而且抄一份的成本是零。
它失效的假設是「隱私政策是一份文件」。隱私政策其實是一份關於你實際做法的陳述。抄來的政策描述的是別人的資料流:別人收集的欄位、別人的保存期限、別人的第三方名單、別人適用的制度與主管機關。當它與你的實際做法不一致時,你同時得到兩個問題——你對使用者做了不實陳述,而且你自己的實際做法仍然沒有被檢視過。抄來的文件也常常直接寫著錯誤的管轄地與錯誤的聯絡窗口。
正確的順序永遠是:先做盤點,再依盤點寫政策。政策是盤點的輸出,不是輸入。這個順序也適用於權利鏈的建立——乾淨的權利鏈案例呈現的是同一個機制在智慧財產上的版本:文件之所以有效,是因為它記載的事實為真,而不是因為它的措辭漂亮。同樣的觀念在 智慧財產有完整展開。
預警訊號:政策裡出現你沒有在用的服務名稱;政策提到的資料類別你的盤點裡沒有(或反過來);沒有任何人能說出這份政策是誰寫的、根據什麼寫的。
以下全部使用宏茂科技的教學數字,幣別為元。假設:沿用 風險登錄與處理的風險登錄,客戶資料外洩的年度可能性為 5%、影響金額為 20,000,000 元,因此期望損失為 0.05 × 20,000,000 = 1,000,000 元/年;「可能性」指一年內至少發生一次的機率;「影響金額」指單次事件的全部成本現值;各控制的效果彼此獨立,不互相抵銷;一次性支出以三年直線攤提;所有機率與金額都是為教學設定的 example,不是任何真實公司或產業的統計值。
第一步:把影響金額拆開
Section titled “第一步:把影響金額拆開”期望損失只有在影響金額可以被拆解時才有辦法被管理。宏茂科技把 20,000,000 元 拆成五項:
| 影響組成 | 金額 |
|---|---|
| 事件處理、鑑識與外部技術支援 | 2,000,000 |
| 通知作業與額外客服量能 | 1,500,000 |
| 法律程序與主管機關往來 | 4,000,000 |
| 客戶流失與商譽損失 | 7,500,000 |
| 舊 KYC 身分證件影像相關的額外處理與賠償 | 5,000,000 |
| 合計 | 20,000,000 |
驗算:2,000,000 + 1,500,000 + 4,000,000 + 7,500,000 + 5,000,000 = 20,000,000 元 ✓。
最後一列值得盯著看:全部影響金額的四分之一,來自一個已經停用兩年的功能所留下的資料。這一列不會出現在任何資安產品的儀表板上,只會出現在資料盤點裡。
第二步:刪掉一整類資料,看式子的哪一項改變
Section titled “第二步:刪掉一整類資料,看式子的哪一項改變”宏茂科技執行一項保存政策變更:刪除舊 KYC 身分證件影像的全部副本(含備份),並為其餘三類「未設定」的資料訂出保存期限。
刪除之後,可能性沒有改變——攻擊者入侵的難度完全一樣,帳號一樣可能被盜,漏洞一樣可能被利用。改變的是影響金額:
新影響金額 = 20,000,000 − 5,000,000 = 15,000,000 元
新期望損失 = 0.05 × 15,000,000 = 750,000 元/年
期望損失下降 = 1,000,000 − 750,000 = 250,000 元/年
交叉檢核:換一個算法,下降金額應等於可能性乘以被移除的影響,0.05 × 5,000,000 = 250,000 元/年,與上式一致 ✓。單位檢查:(無單位機率) × (元) = 元/年,其中「/年」來自可能性被定義為年度機率,正確。
這就是本課最重要的一句話的算術形式:刪除資料減少的是期望損失中的影響項,不是可能性項。它的性質與其他控制不同——它不會失效、不需要續約、不依賴任何人每天做對事情。
第三步:比較兩個候選控制
Section titled “第三步:比較兩個候選控制”沿用 風險登錄與處理的方法:淨效益 = 期望損失下降 − 控制年成本。兩個候選控制都從同一個基準(可能性 5%、影響 20,000,000 元、期望損失 1,000,000 元/年)出發,這樣才可比較。
控制 A(降低可能性):全面身分與存取強化。 對信箱、雲端控制台、原始碼倉庫、金流後台與網域管理強制 MFA,導入集中身分管理,並建立每月修補節奏。估計年成本 200,000 元(工具授權加上內部工時),估計把可能性從 5% 降到 2%。
期望損失下降 = (0.05 − 0.02) × 20,000,000 = 0.03 × 20,000,000 = 600,000 元/年
淨效益 = 600,000 − 200,000 = 400,000 元/年
控制 B(降低影響):資料保存政策。 即第二步的刪除作業,加上為其餘資料類別建立自動化的保存期限機制。一次性工程成本 120,000 元,以三年攤提為 120,000 ÷ 3 = 40,000 元/年;持續維運(每季複核、處理刪除請求)60,000 元/年。
控制年成本 = 40,000 + 60,000 = 100,000 元/年
期望損失下降 = 0.05 × (20,000,000 − 15,000,000) = 250,000 元/年
淨效益 = 250,000 − 100,000 = 150,000 元/年
單看期望值,控制 A 勝出:400,000 元/年 對 150,000 元/年。若只能做一件事,期望值指向 A。
但期望值不是全部。 做完 A 之後,事件真的發生時的損失仍然是 20,000,000 元——而宏茂科技的年營收與淨值都遠低於這個數字,這是一次會結束公司的事件。做完 B 之後,最壞情況是 15,000,000 元。風險登錄與處理已經證明期望值是風險中立的,而現金有限的公司不是;這正是為什麼移轉(保險)與避免要作為獨立的處理方式存在。B 縮小的是尾端,這件事在期望值算式裡看不到。相關的保險與移轉判斷見 保險、執照與專業協助。
第四步:兩個都做,並注意效果不是相加的
Section titled “第四步:兩個都做,並注意效果不是相加的”同時執行 A 與 B:可能性 2%、影響金額 15,000,000 元。
合併後期望損失 = 0.02 × 15,000,000 = 300,000 元/年
合併期望損失下降 = 1,000,000 − 300,000 = 700,000 元/年
合併年成本 = 200,000 + 100,000 = 300,000 元/年
合併淨效益 = 700,000 − 300,000 = 400,000 元/年
注意這裡的陷阱:兩個控制各自的下降是 600,000 與 250,000,相加是 850,000,但合併實際只有 700,000。差額 150,000 元/年 是重疊的部分,因為兩者是相乘關係而不是相加關係:
重疊 = (0.05 − 0.02) × (20,000,000 − 15,000,000) = 0.03 × 5,000,000 = 150,000 元/年
驗算:850,000 − 150,000 = 700,000 ✓ 與直接計算一致。把多個控制的效益直接相加,會系統性高估,而且控制愈多高估愈嚴重。這是資安提案裡最常見的算術錯誤。
再看增量:已經做了 A 之後再加上 B,期望損失從 400,000(0.02 × 20,000,000)降到 300,000,只降 100,000 元/年,而 B 的成本正好是 100,000 元/年。在期望值上,增量淨效益是零。
那還要不要做 B?要,而且理由必須誠實地說出來:不是因為期望值,是因為它把可能致命的最壞情況從 20,000,000 元 降到 15,000,000 元。這與 風險登錄與處理裡「一個淨效益為 −150,000 元 的控制,公司仍可能該買」是同一個判斷,只是這裡的增量淨效益是 0 而不是負數,所以更容易決定。把這個理由寫下來——沒有寫下來的理由,會在下一次預算緊縮時被當成浪費砍掉。
第五步:把「未經測試的備份」算成數字
Section titled “第五步:把「未經測試的備份」算成數字”這是一個獨立的教學情境,用來說明為什麼「有備份」不等於「有控制」。假設:勒索軟體或誤刪造成主資料庫無法使用的年度可能性為 3%;若還原成功,影響金額為 1,000,000 元(停機與人工處理);若還原失敗,影響金額為 12,000,000 元(資料重建、客戶流失與合約違約);還原成功機率為 p。
期望影響 = p × 1,000,000 + (1 − p) × 12,000,000
未測試的備份。 備份工作每天回報成功,但從未實際還原過。假設還原成功機率 p = 0.5(這個數字是教學設定,用來代表「你其實不知道」):
期望影響 = 0.5 × 1,000,000 + 0.5 × 12,000,000 = 500,000 + 6,000,000 = 6,500,000 元
期望損失 = 0.03 × 6,500,000 = 195,000 元/年
每季測試還原。 每季完整還原一次到隔離環境並驗證資料,把成功機率提高到 p = 0.95:
期望影響 = 0.95 × 1,000,000 + 0.05 × 12,000,000 = 950,000 + 600,000 = 1,550,000 元
期望損失 = 0.03 × 1,550,000 = 46,500 元/年
期望損失下降 = 195,000 − 46,500 = 148,500 元/年
交叉檢核:下降應等於可能性乘以機率變動乘以兩種結果的差,0.03 × (0.95 − 0.5) × (12,000,000 − 1,000,000) = 0.03 × 0.45 × 11,000,000 = 148,500 元/年 ✓。
測試成本:每季一次、每次約兩人日,加上隔離環境費用,估計 60,000 元/年。
淨效益 = 148,500 − 60,000 = 88,500 元/年
注意這項控制沒有讓備份變好。 備份的內容一個位元都沒有改變。改變的只有「你知道它能用」這件事——而在期望損失的算式裡,「你知道」值 88,500 元/年。這就是為什麼「未經測試的備份是一個信念,不是一個控制」不是修辭而是算術。要完整練習這一整條計算鏈,請完成 風險與智財稽核。
「我們公司太小,不會被攻擊。」 這個信念假設攻擊者是先選定目標再尋找方法的。實際上大量攻擊是自動化且不分對象的:掃描整個網際網路找出未修補的服務、用外洩的密碼組合去試每一個登入頁、把釣魚信寄給能買到的每一份名單。這些程序不知道你的公司多大,成本也幾乎不隨目標數量增加。更關鍵的是,即使被攻擊的機率真的較低,小公司的影響往往更致命——宏茂科技的 20,000,000 元 事件對大型企業是一筆費用,對它是結束。在期望損失算式裡,可能性較低完全可能被影響較高抵銷還有餘。這個誤解在什麼條件下部分成立?當你完全沒有持有他人資料、沒有可被勒索的營運系統、也沒有可被冒用的品牌時,暴露確實較低——但那也表示你不需要這一課。
「有加密就安全了。」 加密防的是特定的威脅:資料在傳輸中被竊聽,或儲存媒體、備份檔被整個取走。它防不了最常見的外洩途徑——攻擊者取得了一組有效帳號,然後以完全合法的方式讀取資料。對系統而言那不是入侵,是登入;資料會被正常解密後交出去。加密也防不了權限設定錯誤、防不了內部人員濫用、防不了受託處理者出事。所以加密是必要的、便宜的,但它處理的是清單上的一項,不是整份清單。這個誤解在什麼條件下部分成立?在裝置遺失、硬碟報廢與備份媒體外流的情境中,加密確實接近完整的答案。
「隱私政策抄一份就好。」 隱私政策不是文件,是關於你實際做法的陳述。抄來的政策描述的是別人的資料類別、保存期限、第三方名單與適用制度;當它與你的實際做法不符時,你同時得到兩個問題——對使用者的不實陳述,以及自己的做法從未被檢視。它還常常寫著錯誤的管轄地與失效的聯絡窗口。抄襲合規範本案例完整呈現了這個失敗。正確順序是先盤點、後寫政策:政策是盤點的輸出。
「資料越多越好。」 這個信念來自一個真實的觀察——資料確實可能帶來分析與產品價值。但它忽略了資料同時是負債。每多留一類資料,你就多了保存成本、多了保護義務、多了盤點與回應個人請求的工作量,而且在期望損失算式裡直接推高了影響金額。宏茂科技的舊 KYC 影像貢獻了 5,000,000 元 的影響,也就是 250,000 元/年 的期望損失,換來的價值是零,因為那個功能兩年前就停用了。正確的判準是逐類問:這一類資料在未來十二個月會被用來做哪一個具體決定?答不出來就設一個保存期限。這個誤解在什麼條件下部分成立?當資料確實驅動一個已經在運作的決策、而且你已經算過它的期望損失代價時,多留是合理的——但那是算出來的結論,不是預設。
「有備份就不會遺失資料。」 備份工作回報成功,證明的是「複製動作執行完畢」,不是「這份資料可以還原成一個能用的系統」。實際上常見的失敗包括:備份的是錯誤的資料庫、備份被同一組被盜憑證加密或刪除、還原程序沒有人會操作、還原耗時遠超過可接受停機時間、以及還原後才發現缺少某個設定檔。本課第五步算出,把還原成功機率從假設的 0.5 提高到 0.95,期望損失下降 148,500 元/年,而備份內容一個位元都沒改變。未經測試的備份是一個信念,不是一個控制。
「這是工程師的事。」 本課涵蓋的決定裡,真正重要的幾乎都不是技術決定:要不要收這個欄位、資料留多久、誰有權存取、外洩時誰有權在半夜關閉服務、要通報誰。這些是產品與經營決定,工程師沒有權限也不該獨自承擔。把它整包丟給技術人員的公司,通常會得到一堆技術控制與一個從未被畫出來的資料盤點。負責人必須是一個有決策權的人,見 職責歸屬。
「通過了客戶的資安問卷,就代表我們沒問題。」 問卷檢查的是控制清單,不是你的資料現況。它幾乎不會問「你們持有哪些個人資料、放在哪裡、留多久」,所以最危險的那一堆資料可以完整地通過每一題。更麻煩的是通過本身會製造安全感,讓真正的盤點被延後。問卷的正確用途是當成外部提醒——把每一題對照你自己的盤點,看它漏問了什麼。
- 用本課的六欄格式(資料類別、目的、位置、存取者、保存期限、分享對象)畫出資料盤點,涵蓋所有資料庫、SaaS、試算表、物件儲存與員工個人裝置。完成條件是這份表存在、有日期、有一位具名負責人。
- 逐列檢查「目的」欄。任何一列寫不出一句具體用途的,標記為刪除候選。
- 逐列檢查「保存期限」欄。出現「未設定」「永久」或空白的,全部視為未完成,必須訂出天數或明確的觸發條件。
- 找出盤點中最敏感的那一列(身分證件、健康、金融、精確位置、未成年人資料),確認它現在是否仍有正在運作的目的。沒有的,排定整批刪除,含備份副本。
- 對每一個刪除候選,用
期望損失下降 = 可能性 × 被移除的影響金額算出年度價值,寫下你採用的可能性與影響假設。 - 列出所有可以存取個人資料的帳號,逐一確認是否為工作所必需;不必需的立即移除。把清單印出來由負責人逐行簽名並留存日期。
- 對信箱、雲端控制台、原始碼倉庫、金流後台與網域管理五類帳號,確認全部啟用多因素驗證,並記錄檢查日期。
- 建立軟體與服務清單,訂出修補節奏,並記錄每次套用更新的日期與版本。
- 執行一次完整的還原測試:從備份還原到隔離環境、驗證資料完整性與時間點、記錄開始時間、完成時間、驗證方式與執行人。排定每季重做。
- 確認關鍵系統的登入、權限變更與大量資料匯出都有日誌,日誌存放在攻擊者難以刪除的位置,並指定一個人每月查看一次異常。
- 列出所有受託處理者與次受託處理者,寫下各自拿到哪些資料類別,並確認合約中有處理範圍、再委外規則與事件通知條款。
- 寫出一頁的資料外洩應變流程,明列六個步驟(控制、評估範圍、保全證據、通報、修復、檢討)、每一步的負責人姓名與可聯絡電話,以及事前查好的通報對象與期限。把它印出來,因為事發時系統可能無法存取。
- 建立離職檢查表:停用全部帳號(含 SaaS)、撤銷 API 金鑰、更換共用密碼、回收裝置、確認資料不留在個人裝置。完成條件是離職當天完成並由負責人簽署。
- 為付款與帳號變更建立第二管道口頭確認規則,並在下一次演練中實際測試一次。
- 每半年重做一次盤點,並比對上一版的差異;新增的資料類別必須說明目的與保存期限才能留下。
本課的算術與機制在任何地方都成立:期望損失等於可能性乘以影響金額、刪除資料改變的是影響項而非可能性項、多個控制的效益相乘而非相加、未經測試的還原不構成控制、以及事件回應的六個步驟順序。這些是結構性質,不依賴任何國家的法律,可以直接套用。
但隱私與資安一旦落到法律義務上,制度差異極大,不是全球通用。以下這些項目必須逐地查核(as-of 2026-07-31),本課刻意不提供答案:
「個人資料」的定義範圍。 OECD 的定義是「與一個已識別或可識別的個人有關的任何資訊」(fact,見資料來源),但各地在裝置識別碼、IP 位址、去識別化資料、公開資料與法人聯絡資訊是否納入上,做法並不一致。
處理個人資料的合法事由。 各制度對「你憑什麼可以處理這筆資料」的答案結構不同:有的採列舉的合法事由清單,有的以同意為主軸,有的依資料類別分別規定。不要假設任何一份清單可以跨地區沿用。
個人權利的內容與回應期限。 OECD 的個人參與原則賦予個人確認、取得、要求說明拒絕理由與挑戰資料的權利(fact),但具體有哪些權利、如何驗證申請人身分、多久內必須回覆、可否收費,各地規定不同,而且會修改。
外洩通報的觸發門檻、對象與期限。 這是差異最大也最容易出錯的一項。OECD 文本只要求在重大事件時「於適當情形下」通知主管機關,並在可能造成不利影響時通知受影響個人,沒有規定任何天數(fact)。實際的小時數或天數、要不要通報、通報給哪一個機關、是否須同時通知個人,完全由當地制度決定。把任何一個數字當成通則寫進流程,是本課最不希望發生的事。
跨境傳輸。 你用的雲端服務把資料放在哪一國,可能直接觸發額外義務。合法的跨境機制有哪些、需要什麼文件、是否須事前核准,各地差異極大。OECD 準則本身的立場是資料控制者對其控制下的個人資料負責,不論資料位於何處(fact),但這只是責任歸屬原則,不是任何地區的合法機制清單。
特種或敏感資料的額外要求。 健康、生物特徵、金融、未成年人與宗教/政治相關資料,多數制度都有更嚴格的規定,而「哪些算敏感」本身就因地而異。
強制性的資安要求與產業規範。 金融、醫療、電信、關鍵基礎設施等產業通常有法定的技術與紀錄保存要求,那是義務而非管理選擇。
罰則與法律責任。 本課完全不討論罰款金額、責任上限或個人求償途徑,因為這些數字在各地不同且經常修改。
上述任何一項的具體條文、門檻與期限,請對照 隱私與數位服務的地區差異查核 jurisdiction 與 as-of 日期,並就個案尋求當地合格的法律與資安專業協助。特別提醒:資料外洩發生後才第一次查這些問題,時間成本極高,因為多數制度的時鐘在你「知悉」的那一刻就開始跑。本課出現的所有金額、機率與比率都是教學 example,不是任何地區的法定標準。
把上述設計問題往前推到功能設計階段,就是 隱私設計的核心:在寫下第一個資料欄位之前就決定要不要收、留多久、誰能看,而不是在上線兩年後才回頭補救。與外部廠商的權責劃分見 合約與內部控制,風險移轉與保險的判斷見 保險、執照與專業協助,事件當下的指揮與溝通紀律見 外包、擴張與危機。
Recommendation of the Council concerning Guidelines Governing the Protection of Privacy and Transborder Flows of Personal Data(OECD/LEGAL/0188,accessed 2026-07-31;該文件記載於 1980 年 9 月 23 日由 OECD 理事會通過、2013 年 7 月 11 日修訂)支持本課數項主張。第一,Part One 第 1 段的定義:「個人資料」指與一個已識別或可識別的個人有關的任何資訊;「資料控制者」指依國內法有權決定個人資料內容與使用的一方(fact)。第二,Part Two 列出八項國內適用基本原則——收集限制(第 7 段)、資料品質(第 8 段)、目的特定(第 9 段)、使用限制(第 10 段)、安全維護(第 11 段)、公開(第 12 段)、個人參與(第 13 段)、當責(第 14 段)(fact)。本課把它們重組為七個設計問題,並加入「保存限制」——請注意保存限制不是 OECD 的八項原則之一,而是作者從「資料應與目的相關」與「使用限於所特定的目的」推導出的實務結論(inference)。第三,Part Three 第 15 段的實施當責要求(隱私管理計畫的六項內容、可展示性,以及重大安全事件的通知),其中通知條款的措辭是「於適當情形下」通知主管機關、在可能造成不利影響時通知資料主體,該文本未規定任何期限(fact)——本課「地區差異」一節不列出任何通報天數,依據即在此。第四,該文件的背景說明指出這些準則是最早達成國際共識的一組隱私原則,並被各國廣泛作為自身框架的基礎,同時明確定位為最低標準,各國可補充額外措施(fact)。這一點直接支持本課的核心立場:原則可以跨地區教,義務不行。
The NIST Cybersecurity Framework (CSF) 2.0(NIST CSWP 29,accessed 2026-07-31,該文件標示日期 2024-02-26)支持三項主張。第一,本課開場的隱私與資安分工:該文件第 5.2 節寫明資安與隱私是各自獨立的學科、目標在某些情況下重疊,資安風險管理對於處理個人資料機密性、完整性與可用性喪失所引發的隱私風險是必要的,但隱私風險也可能因與資安事件無關的方式而產生(fact);同節並說明資料處理可能使個人遭遇的問題,範圍從尊嚴層面的影響到歧視、經濟損失或人身傷害等更具體的損害(fact)。第二,六項核心功能 GOVERN、IDENTIFY、PROTECT、DETECT、RESPOND、RECOVER 及其定義,其中 PROTECT 涵蓋身分管理、驗證與存取控制、意識與訓練、資料安全、平台安全與技術基礎設施韌性;RESPOND 為「針對偵測到的資安事件採取行動」;RECOVER 為「使受資安事件影響的資產與營運回復」(fact)。本課的控制清單與事件回應六步驟即依這些結果類別在小公司規模上的具體化(inference)。第三,該文件說明 2.0 版特別強化治理與供應鏈兩個主題(fact),支持本課把受託處理者風險列為必要項目。需要說明的是,該框架明白表示自己描述的是期望達成的結果,不規定如何達成,且刻意保持與部門、國家、技術無關(fact)——本課因此不把任何具體產品或設定當成必要條件。
NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0(accessed 2026-07-31,該文件標示日期 2020-01-16)支持兩項主張。第一,資料盤點是基礎工作:該文件第 2.1 節說明 Identify-P 功能的活動「對於有效運用隱私框架而言是基礎性的」,並把「盤點資料被處理的各種情境」列為其中的首要活動(fact)。本課的六欄盤點是這項要求在小公司規模的具體化(inference),欄位設計為作者所擬。第二,隱私風險的四種回應方式:緩解、移轉或分擔、避免、接受(fact)。這與 風險登錄與處理所教的降低、移轉、避免、接受四種處理方式在結構上一致,顯示同一套風險語言可以同時用在營運風險與隱私風險上——本課因此直接沿用該課的期望損失算式。該文件同時指出,隱私風險評估有助於區分隱私風險與合規風險:即使完全符合適用法規,資料處理仍可能對個人造成問題(fact),這正是本課開場「一個完全安全、完全合規的系統仍可能是隱私失敗」的依據。該文件並聲明其內容不具法律效力、不拘束任何人(fact),本課引用它僅作為方法論,不作為任何地區法律內容的依據。
三份來源都不涵蓋宏茂科技的任何數字。本課全部的可能性、影響金額、控制成本、還原成功機率與資料類別都是為教學建構的 example;其中的計算為作者依題設所作的算術推導(inference),可以逐步複驗,但不代表任何真實公司的實際數據,也不構成任何地區的法律、資安或保險建議。
有一項來源查證失敗,在此誠實記錄:作者曾嘗試以 https://www.oecd.org 網域下的隱私框架頁面與 https://www.iso.org/standard/27001 取得 ISO/IEC 27001 的官方說明,兩者皆回傳 HTTP 403,無法確認頁面內容。因此本課不引用 ISO/IEC 27001 的任何具體條文或控制編號,OECD 準則的內容則改以 OECD 法律文書資料庫的官方 PDF(OECD/LEGAL/0188)查證,該連結已列於上方。