第28章数据安全与合规

第28章：数据安全与合规：数据加密、访问控制、数据脱敏、GDPR/CCPA合规、审计日志

数据安全，说白了就是数据架构师的底线。

我见过太多团队，ETL跑得飞起，报表做得漂亮，结果一个数据泄露，全公司股价跌了20%。嗯，这可不是危言耸听。今天咱们聊聊数据安全与合规，这五个关键词：加密、访问控制、脱敏、合规、审计日志。每一个都是硬骨头，但必须啃下来。

28.1 数据加密：不只是加个密那么简单

数据加密分两种：传输中加密和存储中加密。我个人习惯，只要数据离开服务器，就必须加密。

28.1.1 传输中加密

说白了就是TLS/SSL。ETL过程中，数据从源系统拉到目标系统，中间经过网络。如果不加密，等于裸奔。

核心原则：所有数据通道必须启用TLS 1.2以上版本。别用SSL 3.0，那玩意儿早被攻破了。

# 示例：使用Python的requests库启用TLS
import requests
from requests.packages.urllib3.exceptions import InsecureRequestWarning

# 关闭警告（仅用于测试，生产环境不要这样干）
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

# 正确的做法：验证证书
response = requests.get('https://api.example.com/data', verify=True)

28.1.2 存储中加密

数据到了目标系统，比如数据仓库，也得加密。我建议使用列级加密，而不是整表加密。为什么？因为性能。你想想看，如果整张表都加密，每次查询都要解密，那速度能快吗？

我的经验：在项目中，我们只对敏感字段加密，比如身份证号、信用卡号。其他字段保持明文，这样查询效率高，安全也达标。

-- 示例：在PostgreSQL中使用pgcrypto进行列级加密
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- 加密存储
INSERT INTO users (id, name, ssn)
VALUES (1, '张三', pgp_sym_encrypt('123-45-6789', 'encryption_key'));

-- 解密查询
SELECT id, name, pgp_sym_decrypt(ssn, 'encryption_key') AS ssn
FROM users;

28.2 访问控制：谁可以碰数据？

访问控制，说白了就是「谁可以看什么」。我见过最离谱的案例：一个实习生居然有生产库的DBA权限。嗯，这不出事才怪。

28.2.1 最小权限原则

每个用户、每个服务账号，只给它们完成工作所需的最小权限。我曾经在项目中遇到一个坑：ETL作业使用了一个超级管理员账号，结果一次误操作，把整个表删了。从那以后，我强制要求所有ETL作业使用只读账号，写操作单独授权。

28.2.2 角色分离

开发、测试、生产环境，权限必须分开。开发人员不能碰生产数据，这是铁律。

角色	开发环境	测试环境	生产环境
数据工程师	读写	只读	无权限
数据分析师	只读	只读	只读（脱敏后）
DBA	读写	读写	读写（需审批）

28.3 数据脱敏：让敏感数据「隐身」

数据脱敏，说白了就是把真实数据变成假数据，但保持数据特征不变。比如身份证号，脱敏后还是18位，但不再是真实的号码。

28.3.1 静态脱敏 vs 动态脱敏

静态脱敏：一次性处理，生成脱敏后的副本。适合测试环境。
动态脱敏：实时处理，用户查询时自动脱敏。适合生产环境。

注意：动态脱敏会影响查询性能。我建议对高频查询使用静态脱敏，低频查询使用动态脱敏。

-- 示例：使用SQL进行动态脱敏（MySQL）
SELECT 
    id,
    CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) AS masked_phone,
    CONCAT(LEFT(id_card, 3), '***********', RIGHT(id_card, 4)) AS masked_id_card
FROM users;

28.4 GDPR/CCPA合规：别惹上法律麻烦

GDPR和CCPA，这两个法规是数据合规的「紧箍咒」。我刚开始接触时也觉得头大，但后来发现，核心就几点：

用户知情权：你得告诉用户，你收集了什么数据，用来干嘛。
用户删除权：用户要求删除数据，你必须照做。
数据可移植性：用户要带走数据，你得给。

核心原则：在ETL流程中，必须记录每个数据字段的「用途」和「来源」。一旦用户要求删除，你能快速定位并清除。

-- 示例：在数据表中添加合规字段
CREATE TABLE user_data (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100),
    consent_flag BOOLEAN DEFAULT FALSE,  -- 用户是否同意
    data_retention_days INT DEFAULT 365, -- 数据保留天数
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 删除过期数据（GDPR要求）
DELETE FROM user_data
WHERE created_at < NOW() - INTERVAL '365 days'
AND consent_flag = FALSE;

28.5 审计日志：谁在什么时候做了什么

审计日志，说白了就是「黑匣子」。出了问题，查日志就知道是谁干的。我建议所有数据操作都要记录日志，包括：谁、什么时间、什么操作、操作了什么数据。

28.5.1 日志内容

用户ID
操作时间
操作类型（SELECT/INSERT/UPDATE/DELETE）
操作对象（表名、字段名）
操作结果（成功/失败）
IP地址

我的习惯：审计日志不要存在业务数据库里，单独建一个日志库。为什么？因为业务库一旦被删，日志也跟着没了，那还查个啥？

-- 示例：创建审计日志表
CREATE TABLE audit_log (
    log_id BIGSERIAL PRIMARY KEY,
    user_id INT,
    operation_type VARCHAR(10),
    table_name VARCHAR(100),
    record_id INT,
    old_value JSONB,
    new_value JSONB,
    ip_address INET,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 插入审计日志
INSERT INTO audit_log (user_id, operation_type, table_name, record_id, old_value, new_value, ip_address)
VALUES (1, 'UPDATE', 'users', 123, '{"email": "old@example.com"}', '{"email": "new@example.com"}', '192.168.1.100');

28.6 知识体系图

下面这张图，是我自己总结的数据安全与合规知识体系。你想想看，把这五个点串起来，就是一个完整的安全闭环。

好了，这一章的内容就这些。数据安全不是一蹴而就的事，需要持续投入。记住：安全是设计出来的，不是事后补的。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录