第1章：GDPR概述与合规要求
1.1 从工程师视角看GDPR
先说个我自己的经历。几年前我参与一个欧洲客户的项目，系统要收集用户的行为日志。客户法务丢过来一份GDPR合规检查表，足足六十多页。我当时心想：不就是改几个checkbox吗？结果上线后第三天，数据保护局(DPA)的质询函就到了——我们没有正确处理数据主体的“被遗忘权”请求。
所以GDPR到底是什么？说白了，它是欧盟2018年生效的一部数据保护法规，全称《通用数据保护条例》。它不只管欧盟企业，只要你处理欧盟居民的个人数据，无论服务器在哪，都适用。我见过不少国内团队觉得“我在中国，不关我事”，结果被罚款了才后悔。
1.2 关键术语：先把这些概念搞懂
做日志系统和水印方案，必须先吃透几个核心概念。我列了个对照表，方便你回头参考。
| 术语 | 解释 | 跟我有什么关系 |
|---|---|---|
| 个人数据 | 可识别自然人的任何信息，比如姓名、IP、设备ID、位置 | 日志里的IP地址算个人数据，要脱敏或加密 |
| 数据控制者 | 决定处理目的和方式的实体（通常是企业） | 你公司就是控制者，你要为日志处理负责 |
| 数据处理者 | 代表控制者处理数据的第三方（比如云服务商） | 使用AWS/阿里云时，你们要签DPA（数据处理协议） |
| 数据主体 | 个人数据所指向的自然人（用户） | 每个日志里的“用户ID”背后都是活人 |
| 数据保护影响评估(DPIA) | 对高风险处理活动的预评估 | 日志系统如果涉及用户行为画像，几乎必做DPIA |
这里面最容易踩坑的是“个人数据”的范围。我曾经遇到一个团队，认为“匿名化后的日志就不算个人数据了”。他们用了简单的哈希，但没做加盐——结果彩虹表轻松反推。这不算真正的匿名化，只能算假名化，GDPR照样管。
1.3 数据主体的权利清单
GDPR给了用户8项权利。作为日志和水印方案的设计者，你必须知道哪几项会直接影响技术实现。我按工程师的思维分了类：
- 知情权(Right to be informed) —— 你要在采集点告诉用户“我在收集什么、为什么、存多久”。日志系统得支持生成清晰的隐私声明。
- 访问权(Right of access) —— 用户有权拿到你存的他所有数据的副本。日志系统得提供按用户ID查询并导出的接口。
- 更正权(Right to rectification) —— 用户说“你日志里我名字拼错了”，你得能更新。
- 删除权(被遗忘权, Right to erasure) —— 用户要求彻底删除。日志系统不能只软删除，得在备份里也清除。
- 限制处理权(Right to restrict processing) —— 用户可以要求“先别分析我的数据”，日志得支持打标暂停处理。
- 数据可携权(Right to data portability) —— 用户要你把数据导成CSV给他，让他带到别的平台。
- 反对权(Right to object) —— 用户反对你用他的数据做直营销或画像。
- 自动化决策相关权利 —— 纯算法决策对用户产生法律影响时，需人工介入。
1.4 合规框架：从原则到落地
GDPR没有规定具体用什么技术，而是提出了7条原则。我把它画成一张结构图，这样你记起来更直观。
你看，这7条原则不是空中楼阁。以“数据最小化”为例，我见过太多日志系统无脑记录所有请求参数，包括用户的GPS坐标、完整电话号码。后来在DPIA中我们被质疑：为什么需要GPS？最后不得不回溯清洗。我自己的做法是：在采集层直接过滤掉非必要字段，而不是等入库后再脱敏。
1.5 合规框架的四个层级
除了原则，GDPR还要求建立完整的组织和技术措施。我把它分解成四个层级，方便你对照检查自己的系统：
- 组织层：指定数据保护官(DPO)，建立数据清单，做DPIA。很多公司连DPO都没任命，这其实是合规第一关。
- 合同层：和所有数据处理者签DPA。嗯，这里要注意——如果你用了第三方日志分析工具（比如Splunk或ELK的托管服务），他们就是数据处理者，必须签DPA。
- 技术层：就是咱们工程师的主场了。包括假名化、加密、访问控制、审计日志、水印溯源。后面的章节我们会一个一个讲透。
- 流程层：数据泄露72小时内通知DPA，处理用户请求的时限，定期演练等等。
1.6 一个典型的违规场景
讲个真实模子（不过改了细节）。某欧洲电商平台，用户提交删除请求后，开发团队在主数据库里删了记录。但他们的日志系统做了多副本归档——当时没考虑到删除请求也要覆盖归档日志。结果几个月后DPA审计，发现日志中依然保留了已删除用户的历史行为数据。罚款：年营业额的2%。
想想看，如果你的日志方案没有考虑“数据主体的权利响应”接口，后果是一样的。所以从第一章开始，我们就要把合规意识嵌入到每一个水印和日志的设计决策里。
1.7 本章关键清单
最后给你一张速查表，以后做系统设计时拿过来对一遍：
| 检查项 | 具体做法 | 水印/日志关联 |
|---|---|---|
| 数据清单 | 列举所有日志中出现的个人数据字段 | 决定哪些字段需要水印/脱敏 |
| 合法依据 | 确认每个日志采集点的法律基础（同意/合同/合法利益） | 用户同意标识需要写入日志元数据 |
| 删除机制 | 支持按用户ID从所有副本（包括归档）删除日志 | 水印系统需同步擦除或覆盖 |
| 访问权接口 | 按用户导出其所有日志条目 | 日志索引需以用户ID为key |
| DPIA | 日志系统上线前必须完成数据保护影响评估 | 水印方案也在DPIA范围内 |
好了，这一章就这么多。记住：GDPR不是束缚，它是帮我们设计更负责任系统的框架。后面的章节，我会手把手教你如何在日志里嵌入水印、如何做可审计的删除、如何设计合规的日志格式。咱们一步一步来。