Privacy by Design
Privacy by Design (GDPR)
1）這是什麼以及為什麼
Privacy by Design （PbD）是從一開始就將隱私嵌入產品中的原則：業務需求、體系結構、代碼、流程和操作。用GDPR來說，這表現為「通過設計和默認方式隱私」（最小化費用，默認設置-最大限度地私有化，透明度和問責制）。
PbD的目標：- 最大限度地減少個人數據的收集和處理（PD）。
- 確保合法性、透明度、正確性、目標和時限的限制。
- 降低風險（技術和法律），簡化審核和合規性。
2）GDPR的角色，法律框架和原則
2.1個角色
控制器（Controller）：定義處理目標/工具。
處理器（Processor）：根據DPA合同代表控制器處理PDn。
數據主體（Data Subject）：與PDn相關的物理。
DPO（數據保護官）：按需獨立監控和咨詢。
2.2法律依據（選擇和記錄）
同意，條約，合法利益，法律義務，重要利益，公共任務。對於每個人，都是目的，數據，保留，召回的可能性（供同意）。
2.3處理原則（第5條）
合法性、公正性、透明度
目的限制
最小化數據
精確度
存儲限制
完整性和隱私
問責制（問責制）-證明合規性的能力。
3） SDLC中的PbD過程（參考框架）
1.啟動：制定處理目標和法律依據，指定所有者數據和DPO點。
2.數據映射（Data Mapping）- 字段源 信任模型 在哪裏流向誰讀取 存儲 期限。
3.風險評估/DPIA：LINDDUN隱私威脅模型，影響評估，減少措施。
4.體系結構解決方案：選擇最小化，別名，加密，分區方案。
5.UX/同意/通知要求：可理解的文本,granular consent,默認設置。
6.實施：私有默認、安全遙測、無機密編寫/PII。
7.驗證：隱私測試，靜態分析，私有單元測試，DPIA協議。
8.運營：DSAR過程，撤消和刪除，事件監控，供應商咆哮。
9.定期修訂：當目標/技術發生變化時，re-DPIA。
4） PbD工程模式
4.1最小化和分解
僅收集必要的字段；應用漸進式專業。
將標識符和內容分開：分別存儲通信密鑰（token/reference）。
4.2別名和匿名
別名：分別存儲真實標識符；工作層看到令牌。
匿名：使用k-匿名，l-diversity，t-closeness；對於分析-差異隱私（ε-預算）。
4.3訪問控制和角色劃分
PoLP，ABAC/RBAC，職責範圍，管理人員和分析師的單獨輪廓。
那些。措施：mTLS，SSO/OIDC，scoped令牌，訪問PDn的臨時憑據。
4.4加密和隔離
In Transit: TLS 1.3/mTLS;At Rest: AEAD/Envelope + KMS/HSM.
租戶/dataset的單獨鑰匙；「遺忘權」的加密刪除。
4.5回避和刪除
TTL按領域/目標明確的政策；piplines中的自動陷阱；「雙相」刪除（邏輯→物理）。
對於後援-分開鑰匙和短窗口存儲個人狙擊手。
4.6私人遙測和成像
默認情況下為PII；與鹽一起使用令牌/哈希。
Prodewser上的敏感場掩蓋/令牌化。
4.7 UX隱私和同意
按類別（分析，營銷，個性化）分列的Granular consent。
「私人違約」：一切都不關鍵-關閉，直到他們同意。
清晰的「撤消同意」選項,並在新使用時發出即時通知。
5）DPIA和LINDDUN（簡稱）
DPIA（數據保護影響評估）：高風險（大規模監測，評估，新技術）是必需的。它包括處理描述，需求/比例性，風險評估，減少措施。
LINDDUN угрозы: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance.針對每個威脅-對策（最小化，別名，DP，透明度，同意管理，審計）。
6）跨境轉移
找出供應商的存儲/訪問位置。
使用SCC（標準合同條款）並進行傳輸影響評估。
技術人員：端到端加密,客戶端加密,特別敏感的數據,遠程訪問限制。
7）供應商和處理器（供應商管理）
DPA/嵌套處理器，技術和組織措施，子處理器-控制。
定期的評論和審計；檢查權；退出/遷移計劃（data export）。
8）數據主體權利（DSAR）
訪問、修補、刪除、限制、可移植性、異議,不是AADM（分析/自動化）對象。
SLA和自動化：查詢跟蹤，身份證明，響應日誌。
產品中的技術嗡嗡聲：按標識快速搜索和導出；級聯刪除。
9）自動化解決方案和分析（第22條）
如果「重大影響」的決定是由自動機做出的-確保人幹預的權利，可解釋，特征透明。
日誌路徑和模型轉換；上訴機制。
10）處理安全（第32條）和事件（第33/34條）
面向風險的措施：加密，完整性，可持續性，恢復計劃（RTO/RPO）。
PDn事件：檢測過程 三重評估 風險評估 通知監管機構72小時（需要）和受試者（如果風險很高）。
單獨的花花公子，DPO/律師聯系人列表，通知模板。
11）隱私和ML/分析
數據管理集：數據線、許可證/基礎、同意。
技術：差分私有性，聯合學習，安全進化，最小化拳頭。
攻擊防禦：membership/model inversion-定期泄漏評估、ε 設置、噪音/clip。
合成數據-僅對缺乏角色恢復進行驗證。
12）建築方案（模式）
12.1「雙環」ID體系結構
路徑A （PDS-個人數據商店）：真實標識數據（RID）,訪問-嚴格限制,密鑰/加密/審計。
電路B（運營）：帶有令牌的業務數據；通過令牌經紀人與限額和審計進行通信。
12.2個同意總線（同意服務）
集中服務,存儲同意版本和歷史記錄。
SDK：「can_use（類別，purpose）」-即時決定；一切都是合乎邏輯的。
12.3轉義策略作為代碼
YAML配置：實體→字段→ TTL →到期時操作（匿名/刪除/搶占）。
調度程序執行工作,報告由DPO提供。
13）迷你食譜
「默認最小化」偽代碼：
def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }
analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push
GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)14）文件和問責制
ROPA（處理活動記錄）是操作註冊表：目的，法律依據，數據/主體類別，傳輸，保留時間，措施。
政策：隱私,cookies,產品中的信息通知（以易懂的語言）。
員工培訓和年度評論。
15）經常出錯
收集「以防萬一」並存儲「永遠」。
同意是唯一的依據，盡管契約/合法利益是適當的。
「空白」cookie橫幅沒有真正的開關。
缺乏數據映射和DSAR準備不足。
帶有PII的徽標，無保護的備份，RID和操作數據的混合。
沒有供應商控制和跨境傳輸。
16）支票單
在推出fici/產品之前：- 確定處理目的和法律依據；ROPA更新。
- 已完成數據映射和DPIA（如有必要）。
- 實現最小化、別名化、加密（路徑/靜止）。
- 同意是顆粒狀的，具有可理解的UX；違約是私有的。
- 將轉義策略設置為代碼；已驗證刪除/匿名。
- Logi/遙測-無PII；已啟用掩碼。
- 準備了DSAR hooks和出口。
- 進行了團隊培訓並批準了DPO。
- 每季度審查請願書和法律依據。
- 處理器/子處理器的定期審核。
- 事件監測和通知準備≤ 72時。
- 在過程/技術變化時修訂DPIA。
- 合規工件存儲（DPIA、ROPA、測試報告）。
17) FAQ
問：是否有可能完全擺脫同意？
答：有時-是的（合同/法律義務/合法利益），但前提是嚴格要求並評估利益平衡。市場營銷和非批判性分析-通常需要同意。
問： 別名是否足夠?
答：不，這些仍然是個人數據。要退出GDPR領域，需要可靠的匿名（可驗證無法重新識別）。
問： 如何使用ML和個性化?
答：盡量減少fici，使用DP/federated方法，制定解決方案，確保個人幹預和拒絕特征分析的權利。
問：商業和隱私沖突怎麼辦？
答：重新設計收集（漸進式配置）,切換到單元/合成,重新評估法律依據,提供無跟蹤選項。
- 「秘密管理」
- 「At Rest加密」
- 「In Transit加密」
- 「審核和不變日誌」
- "；請求的簽字和核實"；
- 「密鑰管理和旋轉」