隱私保護技術和規範——學習筆記(一)

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

Posted on May 30, 2017