3. 金融合规标准：PCI DSS、GDPR、等保2.0 对加密与审计的要求

3.1 为什么金融行业要盯着这三本标准？

金融数据有多敏感，不用我多说。信用卡号、个人身份、交易记录——随便一个泄露就是几百万的罚款。更麻烦的是，金融机构往往同时受好几部法规管着。

你可能想问：我到底该听谁的？

说实话，这三本标准虽然来自不同地区、不同机构，但它们对加密和审计的要求，核心思路是相通的。把它们的共性抓住，就能用一个方案应对多个合规审查。

3.2 PCI DSS — 支付卡行业的"铁律"

PCI DSS（支付卡行业数据安全标准），说白了就是Visa、MasterCard他们定的一套规矩。你不遵守？那就别想碰信用卡业务。

加密要求

• 静态加密： 持卡人数据（卡号、有效期、CVV）存到数据库里必须加密。我曾经遇到一个客户，把卡号明文丢在MySQL里，还觉得"反正内网安全"——结果PCI DSS审计直接不通过。
• 传输加密： 所有持卡人数据经过公网，必须用TLS 1.2以上。嗯，SSL 3.0和TLS 1.0已经是过去式了，别再用。
• 密钥管理： 加密密钥不能跟数据存在同一台机器上。这是个大坑，后面我会细讲。

审计要求

• 谁、什么时间、做了什么： 所有对持卡人数据的访问，必须记日志。
• 保留12个月： 最近3个月的日志要能随时查，更早的可以归档。
• 日志完整性： 日志不能被篡改。我习惯用WORM（一次写入多次读取）存储来搞定。

-- MySQL审计日志配置示例（满足PCI DSS要求）
INSTALL PLUGIN audit_log SONAME 'audit_log.so';
SET GLOBAL audit_log_policy = 'ALL';
SET GLOBAL audit_log_rotate_on_size = 10485760;  -- 10MB轮转
SET GLOBAL audit_log_rotations = 12;

3.3 GDPR — 个人数据的"保护伞"

GDPR（通用数据保护条例）是欧盟的法规，但只要你处理欧盟公民的数据，不管公司在哪，都得遵守。罚款之高——最高全球营收的4%——让很多美国公司都不敢忽视。

加密要求

• 假名化与匿名化： GDPR没说"你必须加密"，但如果你不加密，数据泄露时就得全额担责。加密了可以减轻处罚。
• 存储与传输加密： 跟PCI DSS类似，但范围更广——任何个人数据（姓名、邮箱、IP地址、生物特征）都受保护。
• 密钥分离： 同样要求密钥管理独立。

审计要求

• 数据处理活动记录（ROPA）： 每个系统都要记录"处理了什么数据、给谁用了、保留多久"。
• 72小时泄露通知： 发现数据泄露后，必须在72小时内通知监管机构。没有审计日志，你连泄露范围都定不了。
• 数据主体访问请求： 用户有权查自己的数据被怎么处理了，审计日志就是证据。

我记得有一家欧洲的金融科技公司，上线前问我："我们不做欧盟业务，还要看GDPR吗？" 我说，你只要有一张欧盟用户的测试数据，就受GDPR管辖。后来他们老老实实加了加密。

3.4 等保2.0 — 中国的合规"基本盘"

等保2.0（网络安全等级保护制度2.0）是中国国家级的强制标准。金融机构通常要求达到第三级或以上。注意，这是合规底线，不是可选项。

加密要求

• 第三级及以上： 要求对重要数据进行加密存储和传输。具体算法必须用国家密码管理局批准的（SM系列，如SM4）。
• 密钥全生命周期管理： 从生成到销毁，每一步都要审计。我曾经在等保三级测评中，被问到"你的密钥轮转周期是多少？有没有自动化？"——答不上来直接扣分。

审计要求

• 安全审计系统： 必须部署独立的审计系统，不能与应用系统共用数据库。
• 日志留存180天： 这是硬性指标。我见过不少公司只留30天，等保测评时被要求整改。
• 审计记录保护： 日志不能被删除或修改，要使用数字签名或区块链等技术保证完整性。

-- 等保2.0 三级加密配置示例（达梦数据库TDE）
CREATE TABLESPACE ts_encrypt
  DATAFILE 'ts_encrypt.dbf'
  ENCRYPTION USING 'SM4'
  DEFAULT STORAGE(ENCRYPT);

3.5 三大标准对比一览

把三本标准放在一起看，差异其实比想象中小。下面这张表我经常在项目启动会上用，帮团队对齐认知。

3.6 对加密与审计的共性要求

上面三本标准，抽掉各自的特例，剩下的就是下面这些"必选项"。你把这些做扎实了，任何合规审查都能扛得住。

加密层面的共性

• 静态加密： 敏感字段存到数据库时，必须加密。列级加密或TDE都可以。
• 传输加密： 内部网络也建议加密。你想想，万一内网被横向渗透了呢？
• 密钥独立管理： 密钥不能跟数据在一起。用HSM或KMS来管。

审计层面的共性

• 完整记录： 谁、何时、从哪、操作了什么、结果如何。一个都不能少。
• 不可篡改： 日志只能追加，不能删除或修改。我习惯用区块链哈希链来做日志完整性校验。
• 独立存储： 日志不能存在被审计的系统里。单独一台日志服务器，或者用云上的日志服务。
• 定期审查： 日志不是存了就完了。每月至少过一次，看看有没有异常模式。

上面这张图，把三本标准对加密和审计的要求串在了一起。你会发现，不管哪个标准，底层都在追求同一件事：数据被加密保护，访问被完整记录。 这也是我们做数据库加密审计系统的核心逻辑。