第3章数据存储安全

数据存储安全：敏感数据识别、加密算法选择与密钥管理

聊到支付系统的数据存储安全，我脑子里第一个蹦出来的画面，是几年前一次内部审计。当时我们扫描数据库，发现一张日志表里明晃晃地躺着用户的完整银行卡号。嗯，那个场景，至今想起来后背都发凉。

数据存储安全，说白了就三件事：知道哪些数据要保护、用什么算法保护、怎么管好钥匙。咱们一个一个拆开讲。

一、敏感数据识别：先搞清楚你要保护什么

很多人一上来就谈加密算法，我个人习惯是反过来的——先做数据分类。你连哪些字段是敏感的都搞不清楚，加密再强也是白搭。

支付系统里，敏感数据通常分这么几类：

个人身份信息（PII）：姓名、身份证号、手机号、邮箱
金融账户信息：银行卡号、CVV、有效期、支付密码
交易敏感数据：订单金额、商户密钥、Token
认证凭证：登录密码、API Key、签名密钥

我在项目中遇到过最典型的坑，是开发同学把用户手机号直接写进了业务日志。为什么？因为日志框架默认打印了请求参数。所以光靠代码审查是不够的，你得有自动化扫描工具。

我的建议：建一个敏感数据清单，每季度更新一次。配合静态代码扫描（比如用DLP工具），在CI/CD流水线里自动拦截。别等到上线了才发现。

二、加密算法选择：为什么我偏爱AES-256-GCM

加密算法选型，我踩过不少坑。早期用过AES-256-CBC，后来发现它有个致命问题——不提供完整性校验。攻击者可以篡改密文，解密后得到乱码，但系统不一定能发现。

所以现在，只要涉及支付数据的存储加密，我首选AES-256-GCM。为什么？

认证加密：同时提供机密性和完整性，防止篡改
256位密钥：暴力破解基本不可能，量子计算机来了也得头疼
GCM模式：支持并行计算，性能比CBC好不少
内置Nonce：每次加密用不同的初始化向量，避免相同明文产生相同密文

你想想看，支付数据一旦被篡改，后果是什么？用户账户余额对不上，那可就出大事了。GCM模式自带的消息认证码（MAC），就是用来防这个的。

下面是一个简单的Java实现示例：

import javax.crypto.Cipher;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.security.SecureRandom;
import java.util.Base64;

public class PaymentDataEncryptor {
    private static final int GCM_IV_LENGTH = 12; // 96 bits
    private static final int GCM_TAG_LENGTH = 16; // 128 bits

    public static String encrypt(String plaintext, byte[] key) throws Exception {
        byte[] iv = new byte[GCM_IV_LENGTH];
        SecureRandom random = new SecureRandom();
        random.nextBytes(iv);

        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        GCMParameterSpec spec = new GCMParameterSpec(GCM_TAG_LENGTH * 8, iv);
        SecretKeySpec keySpec = new SecretKeySpec(key, "AES");

        cipher.init(Cipher.ENCRYPT_MODE, keySpec, spec);
        byte[] ciphertext = cipher.doFinal(plaintext.getBytes("UTF-8"));

        // 将IV和密文拼接存储
        byte[] combined = new byte[iv.length + ciphertext.length];
        System.arraycopy(iv, 0, combined, 0, iv.length);
        System.arraycopy(ciphertext, 0, combined, iv.length, ciphertext.length);

        return Base64.getEncoder().encodeToString(combined);
    }
}

注意：千万不要自己实现加密算法！我曾经见过一个团队自己写了个XOR加密，觉得「没人能猜到」。结果上线第二天就被安全团队叫停了。用标准库，别折腾。

三、密钥管理方案：钥匙比锁更重要

加密算法选得再好，密钥泄露了，一切归零。密钥管理是数据存储安全里最容易被忽视、也最致命的一环。

我建议采用分层密钥管理方案：

层级	名称	用途	存储位置
L1	主密钥（Master Key）	加密下级密钥	HSM或密钥管理服务（KMS）
L2	数据加密密钥（DEK）	加密具体数据字段	数据库，但用主密钥加密后存储
L3	字段级密钥	每个敏感字段独立密钥	内存中临时生成，用完即销毁

这样做的好处是：即使数据库被拖走，攻击者拿到的也是加密后的DEK。没有主密钥，他解不开。而主密钥放在HSM里，物理隔离，想偷都难。

我曾经在项目中遇到一个情况：开发为了方便，把密钥硬编码在配置文件里，还提交到了Git仓库。嗯，那个仓库是公开的。你猜后来发生了什么？

  避坑指南：密钥轮换周期建议设为90天。别等到泄露了才换。另外，密钥的访问权限要最小化——只有加密/解密服务本身能接触到密钥，业务应用只调用API。

四、数据库加密：不止是TDE

数据库加密，很多人第一反应是透明数据加密（TDE）。但TDE有个问题——它只加密磁盘文件，数据库内存里的数据是明文的。如果攻击者直接查询数据库，数据照样暴露。

所以我更推荐字段级加密，也就是在应用层加密敏感字段，再存入数据库。这样即使DBA有权限，看到的也是一堆乱码。

下面是一个典型的字段级加密流程：

应用收到用户银行卡号
调用加密服务，用DEK加密该字段
将密文存入数据库的对应列
查询时，应用层解密后返回给用户

这里有个性能问题——加密后的字段无法直接做模糊查询。我的解决方案是：对需要查询的字段（比如手机号后四位），单独存一个哈希值，用于精确匹配。

小技巧：对于信用卡号，可以只加密前6位和后4位之间的中间部分。前6位是发卡行标识，后4位用于用户确认，中间部分才是真正需要保护的。这样既安全，又不影响业务展示。

知识体系总览

下面这张图，是我自己总结的数据存储安全核心逻辑。你看一眼，基本就明白整个体系怎么串起来的：

你看，整个链路是串起来的。数据识别是起点，加密算法是工具，密钥管理是命门，数据库加密是最终落地。任何一个环节出问题，整个安全体系就形同虚设。

最后说一句：安全不是一锤子买卖。上线之后，定期做渗透测试、密钥轮换、日志审计，一个都不能少。我见过太多系统上线时安全做得漂亮，半年后因为没人维护，密钥过期了都不知道。

嗯，数据存储安全，说到底就是「把该藏的藏好，把钥匙管牢」。做到这两点，你的支付系统就稳了一大半。

📚 课程目录

数据存储安全：敏感数据识别、加密算法选择与密钥管理

一、敏感数据识别：先搞清楚你要保护什么

二、加密算法选择：为什么我偏爱AES-256-GCM

三、密钥管理方案：钥匙比锁更重要

四、数据库加密：不止是TDE

知识体系总览