1. 字段级加密概述

1.1 一个真实的困境

几年前，我接手过一个金融项目的数据安全改造。

客户要求：「所有用户数据必须加密存储。」

团队的第一反应很简单——把整个数据库表加密不就好了？

锁住数据当然好。但代价呢？

查询速度直接掉了 80%。模糊搜索彻底失效。索引全部作废。连最基本的「按手机号查找用户」都变成全表扫描。

这就是典型的「全表加密」或「整库加密」带来的问题——

你把所有数据都锁进一个保险柜，结果连自己人想看一眼都得翻半天。

那有没有更好的办法？

有。就是我今天要跟你聊的——字段级加密。

1.2 什么是字段级加密

说白了，字段级加密就是——只加密最核心的敏感字段。

其他的普通字段，该怎么存就怎么存。

我举个例子你就明白了：

-- 传统的全表加密思路
CREATE TABLE users (
    id          INT,        -- 加密
    name        VARCHAR,    -- 加密
    phone       VARCHAR,    -- 加密
    email       VARCHAR,    -- 加密
    address     TEXT,       -- 加密
    avatar_url  VARCHAR,    -- 加密
    created_at  TIMESTAMP   -- 加密
);

-- 字段级加密的思路
CREATE TABLE users (
    id          INT,        -- 明文
    name        VARCHAR,    -- 明文
    phone       VARCHAR,    -- 加密 ← 只保护这个
    email       VARCHAR,    -- 加密 ← 和这个
    address     TEXT,       -- 明文
    avatar_url  VARCHAR,    -- 明文
    created_at  TIMESTAMP   -- 明文
);

看出区别了吗？

字段级加密就好比给每个字段配上独立的保险柜。

只保最重要的，其他的照常使用。

1.3 为什么需要字段级加密

我个人习惯把原因归纳为三类：

1. 合规驱动
   • GDPR、CCPA、《个人信息保护法》都要求对个人敏感信息做「专门保护」。
   • 你不能说「我把整个库加密了就算达标」——监管要的是精准保护。
2. 性能与可用性平衡
   • 全表加密下，你连个 COUNT 都跑不动。
   • 字段级加密只影响被保护的字段，其他查询照常走索引。
3. 最小权限原则
   • 不同的角色看到不同的字段。
   • 客服能看到用户名，但不能看到信用卡号。
   • 管理员能查后台日志，但不能解密用户隐私。

1.4 字段级加密 vs 其他加密方案

我整理了一个对比表，方便你快速理解差异：

你看，字段级加密不是要替代其他加密方案，而是补充——

TLS 管「在路上」，磁盘加密管「在盘上」，字段级加密管「在用的时候」。

1.5 常见应用场景

我挑几个最典型的说说：

• 金融行业：信用卡号、银行卡号、交易流水。我只加密卡号，不加密交易时间、金额这些辅助字段，这样统计报表还能正常跑。
• 医疗行业：患者姓名、身份证号、诊断详情。医生查房需要看到病历，但不能明文展示敏感信息。
• 电商平台：收货地址、手机号、支付信息。客服只能看到订单号，看不到客户的完整地址。
• SaaS 多租户系统：不同租户的敏感字段用不同的密钥加密。一个租户密钥泄露不会影响其他租户。

1.6 本章知识结构图

1.7 需要留个心眼

嗯，这里要注意——字段级加密不是万能的。

它解决的是「加密与可用性」这对矛盾，但不是银弹。

• 加密字段依然无法做范围查询（除非用保序加密，那又是另一回事）
• 密钥管理复杂度会随着字段数量增加
• 应用层改造工作量不低

但话说回来——

在真正需要保护敏感数据的场景里，字段级加密依然是目前最务实、最灵活的方案。

我个人习惯这样总结：