3. 数据安全与隐私合规的法律法规基线

数据安全与隐私合规不是“有安全意识”就能解决的问题，它首先是一组可被审计、可被追责的法律义务。生产系统一旦上线，数据的采集、传输、存储、使用、共享、删除都会留下痕迹，而这些痕迹正是监管判断企业是否履行义务的依据。本节把 GDPR、个人信息保护法、数据安全法三条主线拆成可映射到工程系统的要求，并给出一份能直接用于生产环境自查的检查清单。

三条法律基线各自管什么

三部法律并非互相替代，而是从不同角度约束同一套数据流。理解它们的差异，才能避免“按 GDPR 做完就以为合规”的误区。

• GDPR（欧盟通用数据保护条例）：以“个人数据”为核心，强调合法性基础、数据主体权利、数据保护影响评估（DPIA）、跨境传输限制、72 小时 breach 通知。它最显著的特点是权利驱动——访问权、更正权、删除权、可携带权、反对自动化决策权，都要求系统具备对应的技术能力。
• 个人信息保护法（PIPL）：同样以个人信息为核心，但增加了“告知—同意”的强绑定、单独同意场景（敏感个人信息、对外提供、公开、处理已公开信息）、个人信息保护负责人、影响评估、境内存储与出境安全评估。它更强调处理目的与最小必要。
• 数据安全法：不限于个人信息，而是覆盖全部数据。核心是数据分类分级、重要数据目录、数据安全风险评估、出口管制与反制。它要求企业回答“我有哪些数据、哪些是重要数据、谁在什么条件下能访问”。

三者的关系可以概括为：数据安全法管“数据本身的安全”，PIPL 管“个人信息处理的合法性”，GDPR 管“欧盟境内个人数据的权利与跨境”。生产系统若同时面向境内外用户，三套义务会叠加，而不是二选一。

把义务翻译成生产系统检查清单

法律条文不会直接告诉你“在 Kafka 里怎么配”。落地时要把每条义务拆成“对象—动作—证据”三要素：对象是哪个数据资产或接口，动作是系统必须执行什么，证据是审计时能拿出什么。下面这份清单按数据生命周期组织，可直接作为上线前自查表使用。

阶段	检查项	可验证证据
采集	是否取得合法基础（同意/合同/法定义务）？敏感信息是否单独同意？	同意记录表：用户 ID、同意版本、时间戳、撤回状态
采集	是否遵循最小必要？字段是否与处理目的白名单一致？	字段—目的映射表、SDK 采集清单
传输	是否全程加密？跨境传输是否有评估或标准合同？	TLS 配置、出境评估报告编号
存储	是否分类分级？重要数据是否单独目录？	数据地图、分级标签、重要数据清单
存储	是否加密与去标识化？密钥是否独立管理？	KMS 密钥轮换记录、脱敏规则
使用	访问是否最小权限？是否有行级/列级控制？	RBAC 策略、审批工单、权限回收记录
共享	对外提供是否单独同意？委托处理是否有协议？	DPA 协议、共享清单、接收方安全评估
删除	是否支持删除权？备份与日志是否同步清除？	删除工单、备份清理记录、删除证明
审计	是否记录数据访问与操作？日志是否防篡改？	审计日志、WORM 存储、告警记录
事件	是否有泄露检测与通知流程？是否在时限内上报？	应急预案、演练记录、通知模板

落地要点：从“有制度”到“有证据”

很多团队制度写得很全，但审计时拿不出证据。合规落地的关键不是再写一份文档，而是让系统在运行中自动产生证据。以下四个要点最容易被忽视，也最影响审计结果。

第一，同意要可追溯、可撤回。同意不是一次弹窗，而是一条带版本号的状态记录。生产系统应保存 user_id、consent_version、purpose_code、granted_at、revoked_at。当用户撤回时，下游处理链路要能感知并停止。示例表结构如下：

CREATE TABLE consent_record (
  user_id        BIGINT      NOT NULL,
  purpose_code   VARCHAR(64) NOT NULL,   -- 如 ads_personalization
  consent_version VARCHAR(16) NOT NULL,
  granted_at     TIMESTAMP   NOT NULL,
  revoked_at     TIMESTAMP   NULL,
  source         VARCHAR(32) NOT NULL,   -- app / web / offline
  PRIMARY KEY (user_id, purpose_code, consent_version)
);

判断是否合规，不是看表存不存在，而是看“撤回后 24 小时内，推荐、营销、画像任务是否真的不再使用该用户数据”。这需要把同意状态接入实时计算或特征平台，而不是只留在业务库里。

第二，分类分级要落到字段级。数据安全法要求分类分级，但“这张表是重要数据”粒度太粗。生产系统应在元数据中给每个字段打标签，例如 pii:true、sensitivity:L3、retention_days:180。标签一旦进入元数据，就能驱动动态脱敏、访问审批和到期删除。示例：

{
  "table": "user_profile",
  "columns": [
    {"name": "phone",   "tags": ["pii", "sensitivity:L3"], "retention_days": 365},
    {"name": "id_card", "tags": ["pii", "sensitive_pi", "sensitivity:L4"], "retention_days": 180},
    {"name": "city",    "tags": ["quasi_id", "sensitivity:L1"], "retention_days": 730}
  ]
}

有了字段级标签，查询引擎可以在 SQL 解析阶段自动改写：非授权用户查询 id_card 时返回掩码值，而不是等数据出库后再人工处理。

第三，数据主体权利要有接口和 SLA。GDPR 要求一个月内响应访问、删除请求，PIPL 也要求及时处理。生产系统应提供内部 API，把“删除某用户全部数据”变成可编排任务：先定位所有存储位置（业务库、数仓、对象存储、日志、备份、缓存），再逐项执行并记录结果。删除不是 DELETE FROM user WHERE id=? 一条语句，而是一张跨系统任务清单。建议为每个数据源登记“删除执行器”，并保留删除证明。

第四，跨境与出境要前置判断。很多团队在数据已经出境后才补评估。正确做法是在数据流设计阶段就标注数据驻留区域：用户数据默认境内存储，确需出境时走安全评估或标准合同，并在网关层做区域路由。生产系统可以用配置中心维护“数据—区域—传输方式”映射，任何新增跨境链路都必须经过合规评审才能上线。

一个可执行的上线前自查流程

把上述要求压缩成一次可操作的自查，建议按以下顺序执行，每步都留下可审计产物：

1. 画数据流图：标出采集点、存储点、共享点、出境点，标注每类数据的法律属性（个人信息/敏感个人信息/重要数据）。
2. 核对合法性基础：逐条数据流确认同意、合同、法定义务或其他依据，缺失的立即补采或停止处理。
3. 检查技术控制：加密、脱敏、访问控制、审计日志是否覆盖全部数据流；用一条真实查询验证脱敏和权限是否生效。
4. 验证权利响应：发起一次访问请求和一次删除请求，记录从受理到完成的耗时与跨系统执行结果。
5. 确认事件流程：模拟一次数据泄露，检查检测、定级、通知、上报是否在时限内完成，并保留演练记录。

完成这五步后，团队得到的不是一份“合规声明”，而是一组可被审计的证据链：数据流图、同意记录、权限策略、删除工单、审计日志、演练报告。这些证据才是生产系统真正意义上的合规基线。