6.3 设计与运维最佳实践

6.3 设计与运维最佳实践

本节摘要：PETs 怎么设计才好？怎么运维才稳？本节总结隐私设计原则、PETs 架构模式、运维治理最佳实践——把 PETs 从技术变工程。

一、隐私设计原则

隐私设计（Privacy by Design, PbD） 是 GDPR 核心要求——从设计就考虑隐私。七大原则（Cavoukian）：

1. 主动而非被动：主动预判隐私风险，不等问题出再补。
2. 隐私为默认：默认设置最隐私，用户要主动选才放宽。
3. 隐私嵌入设计：隐私是设计核心，不是附加。
4. 正功能而非零和：隐私和功能双赢，不牺牲一方。
5. 端到端安全：全生命周期保护，不只传输/存储。
6. 可见透明：设计透明，可审计。
7. 尊重用户隐私：以用户隐私为中心。

PETs 是 PbD 的技术实现——HE/MPC/DP/FL 从设计就保护隐私。

二、PETs 架构模式

1. 数据最小化架构

• 只收集必要数据，能用 PETs 不收集原始就不收集。
• 如联邦学习替代集中训练——不收集原始数据，只收模型更新。
• 如差分隐私发布替代原始发布——只发布加噪统计。

2. 分层保护架构

• 多层保护，各层独立——数据层（HE/FL）+ 传输层（安全聚合/MPC）+ 输出层（DP）。
• 一层被破，其他层仍保护。

3. 信任最小化架构

• 信任假设最小化——能用不信任假设的技术就不用信任假设强的。
• 如不信任云用 HE/MPC，能信任硬件用 TEE（性能换信任）。
• 多方协议用门限（t-of-n），容忍 t 方串通。

4. 可审计架构

• 所有操作可审计——密钥访问、协议执行、隐私预算消耗。
• 日志不可篡改（用区块链/可信日志）。

5. 可恢复架构

• 密钥泄露可恢复——密钥轮换、前向安全。
• 节点故障可继续——容错协议、数据冗余。

6. 性能分层架构

• 关键路径用快技术（TEE/DP），非关键用慢技术（HE/MPC）。
• 离线/在线分离——重计算离线，在线快。

三、设计流程

1. 隐私影响评估（DPIA）

• 项目早期评估隐私风险。
• 确定保护目标、威胁模型、PETs 选型。

2. 威胁建模

• 明确防谁、防什么、在什么假设下（1.3 节）。
• 用 STRIDE/LINDDUN 等方法系统建模。

3. PETs 选型

• 按威胁模型和性能预算选（1.2 节分类）。
• 优先成熟技术，慎用前沿。

4. 原型验证

• 小规模原型验证性能和隐私。
• 不要直接上生产。

5. 安全审计

• 密码学审计、电路审计、侧信道测试。
• 第三方审计（如 NCC Group 审计 ZKP 电路）。

6. 合规审查

• DPO 审查合规性，确认满足 GDPR/PIPL 等。
• 文档化隐私保证和参数。

7. 渐进部署

• 小范围试点 → 扩展 → 全量。
• 每阶段监控和调整。

四、运维治理

1. 隐私治理框架

• 设数据保护官（DPO）、隐私工程团队。
• 隐私治理委员会——跨部门决策。

2. 密钥治理

• 密钥管理策略——生成、分发、存储、轮换、撤销。
• HSM/TEE 保护主密钥，访问审计。
• 多方协议密钥用秘密共享分权。

3. 隐私预算治理

• DP 总预算设定、分配、监控。
• 预算耗尽则停查询，不超限。
• 定期审计预算消耗。

4. 协议治理

• MPC/FL 协议版本管理——升级兼容性。
• 参与方管理——准入、退出、信誉。
• 恶意方检测和剔除。

5. 监控告警

• 性能监控（延迟/吞吐/异常）。
• 隐私监控（预算/协议异常）。
• 安全监控（密钥访问/侧信道）。
• 合规监控（审计日志/权利响应）。

6. 事件响应

• 隐私事件响应计划——密钥泄露、协议被攻破、数据泄露。
• 演练——定期模拟事件，验证响应。
• 通报——按法规向监管和用户通报。

7. 持续改进

• 定期回顾——隐私保证、性能、合规。
• 跟踪新技术——PETs 进展快，评估新方案。
• 用户反馈——隐私体验，改进透明度。

五、团队和能力

PETs 工程需要跨领域能力：

1. 密码学：理解 HE/MPC/ZKP/DP 原理，能选型和调参。
2. 分布式系统：MPC/FL 多方协调，容错，网络。
3. 安全工程：密钥管理、侧信道防护、安全审计。
4. 合规：GDPR/PIPL 等法规，DPO 协作。
5. 性能工程：GPU/ASIC 加速，性能调优。
6. ML（如做隐私 ML）：模型训练、DP-SGD、联邦学习。

团队组建：核心密码学+分布式+安全，配合规和 ML。培训关键——PETs 复杂，团队要持续学习。

六、最佳实践清单

设计阶段：

• 做 DPIA，定威胁模型。
• 按 PbD 七原则设计。
• 选 PETs 按威胁+性能，优先成熟。
• 原型验证性能和隐私。
• 第三方安全审计。
• DPO 合规审查，文档化。

部署阶段：

• 密钥管理（HSM/秘密共享/轮换）。
• 分层保护（数据/传输/输出）。
• 容错（节点故障/网络分区）。
• 监控（性能/隐私/安全/合规）。
• 渐进部署（试点→扩展）。

运维阶段：

• 隐私预算监控（DP）。
• 协议版本管理（MPC/FL）。
• 参与方管理（准入/退出/信誉）。
• 事件响应计划+演练。
• 定期审计（密钥/协议/合规）。
• 持续改进（新技术/用户反馈）。

透明度：

• 公开隐私保证（如 ε 值）。
• 用户可理解（不堆术语）。
• 审计可追溯（日志不可篡改）。
• 权利响应（用户行使权利）。

七、案例的最佳实践

Google Gboard（FL+DP+安全聚合）：

• PbD：从设计就联邦学习，数据不出手机。
• 分层保护：FL（数据层）+安全聚合（传输层）+DP（输出层）。
• 透明：公开 ε 值和协议。
• 渐进：先小规模试点再扩展。

美国普查 2020（DP）：

• DPIA：评估发布风险。
• DP 选型：用 DP 替代传统去标识。
• 透明：公开 ε（虽争议大）和算法。
• 审计：第三方审计 DP 实现。

Zcash（ZKP）：

• PbD：从设计就 ZKP 保护交易隐私。
• 可信设置：多方仪式管理废料。
• 电路审计：第三方审计 Groth16 电路。
• 升级：从 Sprout 到 Sapling 改进性能和隐私。

⚠️ 常见误读：以为"PETs 设计和普通系统一样"。PETs 要 PbD（隐私为默认）、威胁建模、安全审计、合规审查，比普通系统复杂。运维要隐私预算/协议/参与方治理。

💡 关键直觉：隐私设计 PbD 七原则（主动/默认/嵌入/正功能/端到端/透明/尊重用户），PETs 是技术实现。架构模式——数据最小化（FL/DP 替代集中）、分层保护（数据/传输/输出）、信任最小化（门限 t-of-n）、可审计、可恢复、性能分层。设计流程 DPIA→威胁建模→选型→原型→安全审计→合规审查→渐进部署。运维治理——治理框架（DPO/委员会）、密钥治理（HSM/轮换）、隐私预算（DP 不超限）、协议治理（版本/参与方）、监控告警、事件响应、持续改进。团队跨领域（密码学/分布式/安全/合规/性能/ML）。最佳实践清单覆盖设计/部署/运维/透明。案例 Gboard/普查 2020/Zcash。

温故知新

• 隐私设计 PbD：七原则（主动/默认隐私/嵌入设计/正功能/端到端/透明/尊重用户），PETs 是技术实现。
• 架构模式：数据最小化（FL/DP 替代集中）、分层保护（数据/传输/输出独立）、信任最小化（门限 t-of-n）、可审计（不可篡改日志）、可恢复（密钥轮换/容错）、性能分层（关键快/非关键慢）。
• 设计流程：DPIA（早期评估）→威胁建模（STRIDE/LINDDUN）→PETs 选型（按威胁+性能，优先成熟）→原型验证→安全审计（密码学/电路/侧信道，第三方）→合规审查（DPO，文档化）→渐进部署（试点→扩展）。
• 运维治理：治理框架（DPO/隐私工程团队/委员会）、密钥治理（HSM/秘密共享/轮换/审计）、隐私预算治理（DP 总预算/分配/监控/不超限）、协议治理（版本兼容/参与方准入退出/恶意剔除）、监控告警（性能/隐私/安全/合规）、事件响应（计划/演练/通报）、持续改进（回顾/新技术/用户反馈）。
• 团队能力：密码学、分布式系统、安全工程、合规、性能工程、ML——跨领域，培训关键。
• 最佳实践清单：设计（DPIA/PbD/选型/原型/审计/合规）、部署（密钥/分层/容错/监控/渐进）、运维（预算/协议/参与方/事件/审计/改进）、透明（公开 ε/用户可懂/审计可追溯/权利响应）。
• 案例：Gboard（FL+DP+安全聚合，PbD/分层/透明/渐进）、普查 2020（DP，DPIA/透明/审计）、Zcash（ZKP，PbD/可信设置/电路审计/升级）。