implementing-data-minimization-architecture

数据最小化架构的实现

概述

数据最小化是 GDPR 第 5(1)(c) 条中的一项核心原则，要求个人数据应当“充分、相关，且仅限于实现处理目的所必需的范围”。第 25(1) 条要求控制者实施适当的技术和组织措施，例如假名化，以有效落实数据保护原则，并在处理过程中纳入必要的保障措施。

欧洲数据保护委员会（EDPB）关于第 25 条“设计与默认的数据保护”的《指南 4/2019》明确指出，数据最小化涉及四个维度：收集的数据量、处理范围、存储期限以及数据的可访问性。ENISA 于 2019 年发布的假名化技术报告为大规模实施这些要求提供了技术基础。

数据最小化架构层

第 1 层：收集最小化

在数据进入后端系统之前，于采集时减少数据。

技术：

技术	描述	GDPR 依据	实施复杂度
架构强制校验	拒绝未明确列入声明用途所需范围的字段	第 5(1)(c) 条、第 25(1) 条	低
客户端筛选	在传输前，由客户端 SDK 移除不必要的字段	第 5(1)(c) 条	中
渐进式收集	仅在启用特定功能时请求其他字段	第 5(1)(c) 条、序言 39	中
用途控制表单	仅显示与所选服务层级相关的表单字段	第 5(1)(b) 条、第 25(2) 条	低

Prism Data Systems AG 实施方案： Prism Data Systems AG 部署了 API 网关验证层，按端点强制执行严格的字段允许列表。客户注册端点 /api/v2/customers 仅接受：email、display_name、country_code 和 consent_references[]。date_of_birth、phone_number 和 billing_address 等字段仅在客户启用计费模块时收集，从而实现与用途激活相关联的渐进式收集。

第 2 层：处理最小化

在计算过程中降低数据的可识别性。

假名化（第 4(5) 条）

第 4(5) 条将假名化定义为“以这样的方式处理个人数据，使得在不使用额外信息的情况下，个人数据无法再归属于特定数据主体；前提是此类额外信息单独保存，并受到技术和组织措施的保护。”

ENISA 假名化技术（2019 年报告）：

技术	可逆性	冲突风险	适用场景
基于计数器的映射	可通过查找表还原	无	客户 ID、交易参考编号
使用密钥的 HMAC-SHA256	可通过密钥还原	可忽略不计（256 位）	需要重新识别的跨系统关联
保持格式的加密（FF1/FF3-1）	可通过密钥还原	无	保持格式约束的结构化数据（信用卡号、SSN）
使用保管库的令牌化	可通过访问保管库还原	无	支付卡数据（符合 PCI DSS）
带盐值轮换的密钥哈希	轮换后在计算上不可逆	低	无需纵向跟踪的会话级分析

Prism Data Systems AG 实施方案： Prism Data Systems AG 在所有分析流水线中使用 HMAC-SHA256 假名化。在事务数据库与分析数据仓库之间的边界处，对客户标识符进行假名化。HMAC 密钥存储在由安全运营团队管理的硬件安全模块（HSM）中，并按照 ENISA 建议的控制措施，与分析基础设施在物理和逻辑上隔离。

匿名化（序言 26）

序言 26 指出，数据保护原则不适用于匿名信息，即“与已识别或可识别的自然人无关的信息，或以数据主体不再可识别或无法识别的方式处理为匿名的信息”。第 29 条工作组关于匿名化技术的第 05/2014 号意见（WP216）确立了三项风险标准：

1. 单独识别——隔离出可识别某个人的记录的能力
2. 可关联性——关联两条与同一人有关的记录的能力
3. 推断——根据其他属性推断某个属性值的能力

匿名化技术：

技术	单独识别	可关联性	推断	数据效用
k-匿名（k=5）	已缓解	部分缓解	未缓解	高
l-多样性（l=3）	已缓解	已缓解	部分缓解	中高
t-接近性（t=0.15）	已缓解	已缓解	已缓解	中
差分隐私（epsilon=1.0）	已缓解	已缓解	已缓解	可配置
数据聚合（最小组数=11）	已缓解	已缓解	部分缓解	中低

第 3 层：存储最小化

限制静态存储的可识别数据量。

字段级加密架构：

                    ┌────────────────────────┐
                    │   Application Layer    │
                    │  (plaintext in memory) │
                    └──────────┬─────────────┘
                               │
                    ┌──────────▼─────────────┐
                    │  Encryption Service    │
                    │  AES-256-GCM per field │
                    │  Key: KMS / HSM        │
                    └──────────┬─────────────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                    │
 ┌────────▼───────┐  ┌────────▼───────┐  ┌────────▼───────┐
 │  email (enc)   │  │  name (enc)    │  │  country (clr) │
 │  DEK-email-v3  │  │  DEK-name-v3   │  │  (not PII)     │
 └────────────────┘  └────────────────┘  └────────────────┘

每个个人身份信息字段都使用专用的数据加密密钥（DEK）加密，并由 AWS KMS 或 Azure Key Vault 中的密钥加密密钥（KEK）包装。这样可以实现选择性解密：针对 country 的分析查询无需解密 email 或 name。

Prism Data Systems AG 的实现： Prism Data Systems AG 将所有数据库列分为四个敏感度级别：

级别	分类	加密	访问控制	字段示例
T1	直接标识符	AES-256-GCM，字段级	有业务理由的指定人员	email、full_name、national_id
T2	准标识符	AES-256-GCM，字段级	基于角色，记录日志	date_of_birth、postal_code、job_title
T3	敏感属性	AES-256-GCM，字段级	限定用途，双重审批	health_data、financial_score
T4	非识别信息	传输加密（TLS 1.3）	标准 RBAC	country_code、language_preference

第 4 层：访问最小化

限制可访问可识别数据的人员和系统。

数据掩码模式：

模式	描述	使用场景
静态掩码	在非生产数据库中不可逆地替换个人身份信息	开发和 QA 环境
动态掩码	在查询时根据请求者的角色应用掩码规则	客户支持仪表板
实时掩码	掩码处理微服务之间传输的数据	无需完整个人身份信息的服务间 API 调用
令牌化视图	返回令牌而非原始值的数据库视图	报告层、第三方集成

Prism Data Systems AG 的实现： 默认情况下，Prism Data Systems AG 的客户支持 Agent 会看到动态掩码的数据：电子邮件显示为 m***[email protected]，电话号码显示为 ***-***-4892。只有升级级别的 Agent 才能申请查看未掩码的数据；申请需要提供工单编号，会记录在审计跟踪中，并在 30 分钟后自动失效。

数据最小化评估矩阵

在批准新的处理活动或系统设计之前，使用此矩阵，根据最小化要求评估每个数据字段。

评估标准	问题	评分
必要性	是否需要此字段才能实现所述目的？	0 = 否，1 = 部分需要，2 = 是
比例性	能否通过识别性更低的替代方案实现相同结果？	0 = 能（使用替代方案），1 = 部分能，2 = 不存在替代方案
聚合潜力	能否在不损失所需效用的情况下聚合或泛化此字段？	0 = 可完全聚合，1 = 可部分聚合，2 = 必须保持粒度
假名化可行性	能否针对该处理目的对此字段进行假名化？	0 = 易于假名化，1 = 需要投入一定精力，2 = 不可行
时间范围	除当前交易外，是否还需要此字段？	0 = 不需要（使用后删除），1 = 短期保留，2 = 需要长期保留
访问范围	有多少种角色需要访问原始值？	0 = 无（屏蔽/加密），1 = 角色有限，2 = 需要广泛访问

评分说明：

• 0-4：优先考虑删除、聚合或假名化
• 5-8：应用屏蔽、字段级加密和访问控制
• 9-12：有充分理由保留，并采取全面的技术保障措施和文档记录

Prism Data Systems AG 的实施： 部署任何新的微服务之前，Prism Data Systems AG 的数据架构审查委员会都要求对每个个人数据字段完成最小化评估。评分低于 5 的字段必须在服务通过 CI/CD 流水线中的隐私审核关卡之前删除或假名化。

关键监管参考

• GDPR 第 4(5) 条 — 假名化的定义
• GDPR 第 5(1)(c) 条 — 数据最小化原则
• GDPR 第 25(1) 条 — 通过设计实现数据保护
• GDPR 第 25(2) 条 — 默认数据保护
• GDPR 第 32(1)(a) 条 — 将假名化和加密作为安全措施
• GDPR 序言第 26 条 — 匿名信息的范围
• GDPR 序言第 78 条 — 适当的技术和组织措施
• EDPB《第 4/2019 号关于根据第 25 条通过设计和默认实现数据保护的指南》
• ENISA 报告：《假名化技术与最佳实践》（2019 年 11 月）
• 第 29 条工作组关于匿名化技术的第 05/2014 号意见（WP216）