隱私保護技術和規範——學習筆記（一）

平時，當我們談論和鑽研網絡隱私的時候，我們通常是從用戶/消費者的角度來進行的（比如怎樣防止自己的個人信息被網絡的另一端悄悄地竊取）。然鵝，我們也應該從產品的角度來談論網絡隱私，好的產品應該是能充分尊重用戶提交過來的個人信息，並自律地處理之。筆者有幸學習到一系列 產品的隱私設計規範和技術，趕緊與社區們分享。用戶/消費者們瞭解、掌握這些知識，也有利於對產品設計/開發者進行監督，及時維護自己的權益。After all，用戶應該對自己的電腦/手機/設備 享用完全的自主權。

概念：

“隱私”：

1. 物理隱私：主要指個人有自己單獨的物理空間，並有拒絕他人進入的自由。
2. 信息隱私：個人控制、編輯、管理和刪除關於自己的信息的能力；並有決定如何與他人溝通自己信息的自由。

個人信息：

身份可以（或已被）識別的自然人（即“數據主體”）相關的信息。包括但不限於：

姓名，身份證件號碼，地理位置，生理、精神、經濟、文化、社會等特質因素；還包括電郵地址、電話號碼、指紋、IP、社保號碼、宗教、婚姻狀態等信息。

敏感個人信息（EU定義）

族羣、政治立場、宗教信仰、工會成員、基因/生物信息、健康/性狀況、性取向。

國內一些廠商還把這些信息歸入“個人信息”：

銀行帳號、身份證號、護照號碼、密碼等。

個人信息的風險級別：

高影響性個人信息： （泄漏用戶個人信息）會導致 違法，對公司的運營、財務和聲譽產生嚴重影響。

中影響性個人信息： 對公司產生不利影響，對數據主體有較大不利影響（如通信地址、年齡等）。

低影響性個人信息： 對公司的影響可控（如帳號ID、性別等）。

與數據相關的角色：

1. 數據控制者： 能確定個人數據處理的目的、手段的主體。
2. 數據處理者：代表數據控制者處理個人信息的主體。
3. 設備提供者：提供搭載數據的載體的設備。

同意的類型：

1. 明示同意（Opt-in consent)：數據主體必須主動且明確操作（才許可某項動作）：例如，一個空着的勾選框、鏈接、按鈕。
2. 默認同意（Opt-out consent）：數據主體必須主動取消或拒絕（否則某動作默認執行）：一個已經勾選的框 或 按鈕。

匿名化和假名化：

1. 假名化（Pseudonymization，也稱化名)：個人信息中包含的 身份信息 可以被假名替代。兩個屬性：（1）和假名相關的其他屬性不足以識別出這些屬性關聯的數據主體； （2）除假名分配者外，隱私相關方（如 數據控制者）在有限努力下無法根據假名逆推出數據主體。

2. 匿名化（Anonymization)：對個人信息數據進行不可逆改變的過程。處理後將無法直接或間接識別出數據主體，或者識別需要不合理地耗費大量時間、成本和精力。

Note: 假名化後個人數據和數據主體之間的關聯度會降低，但假名化後的數據仍爲個人信息，需要遵從個人信息處理原則進行處理。（而匿名化後的數據不再是個人數據）

---

隱私保護七原則（ref. EU GDPR ）

1. 合法、正當、透明
2. 有限制的（收集/使用數據的）目的
3. 最小化數據：儘可能匿名化和/化名
4. 準確性：數據及時更新
5. 存儲期限最小化：沒有再使用必要的數據，須及時刪除
6. 整體性和保密性
7. 問責/信度（accountability）：對用戶負責，能對外展示遵從上述原則

---

隱私設計原則

個人信息生命週期:

1. 告知數據主體 （如何寫《隱私政策/聲明》）

2. 數據主體選擇 和 同意/授權
   • 系統/應用 配置變更/升級、下載等屬於修改用戶隱私空間的行爲，須提供同意和取消選項；
   • 默認關閉下載功能；
   • 沒有UI的產品，不允許提供下載軟件功能，OTA升級包除外；
   • 不升級則無法正常使用的產品，仍要給用戶提示，可以只提供用戶同意之選項；
   • 獲得用戶授權後也須向用戶提供撤銷或修改授權的途徑；
   • 爲了履行政府授予的數據控制任務等法律允許的情況除外（如 司法協助調查）
   • 數據控制者應記錄： 用戶ID，同意的時間，獲得同意的方法，用戶所同意其數據的使用目的……
   • 非直接收集的個人數據（例如從第三方批量導入的數據），應儘量告知用戶（數據如何獲得的等）；
   • 使用明示同意機制；
   • 用戶註冊場景：“二次明示同意”（the double opt-in procedure)：用戶完成註冊後，服務提供者發送確認郵件，用戶點擊確認，纔算完成授權。
   • 對數據控制者、設備提供者從系統傳出的包含個人信息的錯誤報告/日誌的，須向用戶請求同意。
   • Cookie的情況：1）用於用戶行爲分析（如 營銷、推廣、調查），須用戶同意；2）爲用戶提供基本服務的，無須用戶同意。

3. 數據收集： B/S 系統中，禁止使用GET方式提交個人數據（應用POST），避免被緩存，被記錄到每個GET請求的URL。

4. 數據使用和存儲：
   • 須進行匿名、假名等不可逆的去個人化（immutable depersonalize)；
   • 加密
   • 必要時恢復數據
   • 安全性評估
   • 默認開啓有利於隱私的設置
   • 口令不可明文存儲；在不需要還原口令的場景，必須使用不可逆的加密算法
   • 高影響性個人數據不可以明文形式出現在 系統日誌、警告、編碼、cookies裏面
   • 產品設計時應進行 訪問控制策略設計（ACS）：1）訪問個人數據須有認證機制（authentication）；2）只能訪問完成任務所需的數據；3）必要時可以撤回（revoke）權限
   • 禁止存儲信用卡 CVV
   • 數據存儲的分離原則：通過物理和邏輯手段隔離數據
   • 對銀行卡的查詢操作 應有記錄日誌
   • 避免在日誌中打印個人信息
5. 數據展示/共享給第三方：
   • 應與合作方訂立數據使用和保密協議。
   • 第三方必須以請求授權的方式獲得個人數據。
   • 使用安全傳輸通道（HTTPS：AES128位或以上，禁止RC4和DES加密），加密後傳輸。（但header中包含的IP、MAC等不在該規則內）
   • 不同應用間共用個人數據，須獲得用戶同意。
   • 修改、刪除個人數據時，須獲得用戶同意。
   • 涉及個人數據的接口，須提供認證、權限控制機制，app調用個人數據接口時，須得到user確認。（包括：IMSI 讀取、呼叫記錄、錄音、拍照、短信等的接口）。
   • 一般有兩類機制：1) 權限控制：需要app向用戶申請；2) 認證：用在管理不同的設備、用戶、會話等，如管理哪些PC可以連接手機的哪些app）
   • 禁止在終端提供監聽功能，或預留後門（通話模塊的通話錄音功能在海外發貨的版本必須徹底刪除)。
   • 終端雲業務必須提供修改其註冊信息的功能。
   • 通話模塊在通話過程中，禁止同時打開錄音機。
   • 推送內容（含廣告）的功能，須符合當地政策、法律和規範；並應有流量控制機制。
   • 嚴格限制收集、訪問、使用未成年人的個人數據；必須採用額外機制，保證可以獲取/驗證其家長的同意（錯誤做法：通過某些機會（如贈送禮品）誘導兒童填寫自己的個人信息，作爲商業牟利手段）

6. 數據遷移（含跨境）： （當地法律法規的遵從）

7. 數據主體對自己的數據的權限：
   • 使用過程中產生的數據，須提供管理（增刪改查）功能，用戶應對自己的數據有增刪查改的權限。
   • 《隱私政策》發生變化時，須告知用戶查看並獲得同意。
   • 如果產品允許提供拍照靜音功能，必須提供該選項，默認不勾選（即拍照有聲音）（日本韓國要求銷售的產品嚴禁拍照靜音功能，即必須拍照必須有聲音）
   • 安全敏感APP必須支持卸載（遠程控制、遠程管理、文件共享等屬於“安全敏感”類）

---

數據脫敏（假名化/匿名化）方法/方案：

（後續還會更詳細介紹）

——匿名化： 方法 描述 優勢 劣勢 建議
掩碼 | 替換爲 ** 等 | 長度不變 | 風險較高，信息持有者易識別 | 針對字符串
截斷 | 丟屬性值後幾位 | 保留部分屬性信息 | 同上 | 針對字符串
加噪 | 增加隨機值 | 無法還原 | 數據失真，不能同時使用 | 允許失真的數值型 易重新識別 日期偏移取整 | 在偏移基礎上取整， | 保護數據的時間分佈密度 | 風險高，易推理 | 針對日期型字段 捨棄精度 置換/shuffling | 把表中某字段各記錄隨機打亂 | 無法還原 | 不能單獨使用 | 需要保留求和/均值等的數據

——假名化： 方法 描述 優勢 劣勢 建議
偏移/variances | 加一個固定值 | 可以還原；支持計算處理 | 風險高，可推理 | 需計算處理的字段
置換/permutation| 將原始值映射爲一個新值| 如有轉換表則可還原 | 轉換表須放在安全區域 | 需數據還原的場景
枚舉 | 映射爲一個新值 且保留 | 支持排序處理 | 風險高 排序仍然暴露 | 需數據排序的場景
排序 加密 | 通過密鑰加密 | 數據無損失 可解密還原 | 風險較高 不算匿名化 可解密 | 需數據還原的場景
哈希 | 使用加鹽 密鑰 Hash函數| 數據長度固定 計算速度快 通常無法還原 | 風險較高 易被破解 | 數據不需還原的場景
進行轉換
標誌化 | 用加密 索引 函數 隨機數 | 無損失 可還原 | 風險較高 需建立ID與Token的轉換關係 | 用於ID卡號轉換
生成算法替換ID號

(待續，見本學習筆記-2）