当前位置：首页 > news >正文

敏感数据加密和模糊匹配

news 2025/5/17 10:04:14

银行等金融机构在处理敏感数据（如身份证号、银行卡号、手机号、客户姓名等）时，有非常严格的合规要求和高安全需求，通常会综合使用多种加密/脱敏/加密查询技术来保障数据安全，同时兼顾性能和查询能力。

下面分为 加密存储方案 和 加密后的查询策略（尤其是模糊匹配） 两部分详细说明：

一、银行对敏感数据的加密存储常见方案

1. 对称加密（如 AES）

用途：存储身份证号、银行卡号、手机号等。
特点：
- 加解密速度快，适合大批量数据。
- 使用统一密钥或密钥管理系统（KMS）进行集中密钥管理。

例子：

AES.encrypt("6222021234567890", secretKey);

2. 不可逆哈希（如 SHA-256）

用途：存储登录密码、身份校验标识（如设备指纹）。
特点：
- 无法解密，只能比对。
- 一般使用加盐（salt）处理，防止彩虹表攻击。

3. 数据脱敏（masking）

用途：展示时隐藏部分信息，非加密，但提升信息安全。

如：

原数据：6222021234567890
脱敏显示：6222********7890

4. 同态加密（部分银行实验性使用）

可以在加密数据上执行计算，但极慢。
多用于高安全分析系统、联邦学习、反洗钱等场景。

5. 专业加密库 + HSM（硬件安全模块）/KMS

银行核心系统会把密钥托管在 HSM 硬件模块 中，禁止明文泄露密钥。
应用只能通过 API 调用加密服务。

二、加密后的查询方式（含模糊匹配）

常规加密（如 AES）不能直接支持模糊查询（like ‘%xxx%’），这是核心挑战！

1. 精确匹配的解决方式

使用加密数据做精确匹配是 可行的，前提是加密算法是确定性加密（deterministic encryption）：
```
SELECT * FROM customer WHERE phone_enc = AES_ENCRYPT('13888888888', key);
```

2. 模糊查询的解决方案

方案一：加密前建索引字段

拆分数据，建立明文索引字段用于模糊匹配，敏感字段仍加密。
例子：

phone_plain phone_enc
1388888 AES(“13888888888”)
查询：
```
SELECT * FROM customer WHERE phone_plain LIKE '138%';
```

phone_plain	phone_enc
1388888	AES(“13888888888”)

方案二：搜索专用字段（如 hash 前缀）

对敏感字段提取关键字或前缀，单独存储。
查询时比对前缀或特征，减少暴力解密。

方案三：ES（Elasticsearch）做脱敏搜索索引

明文或部分脱敏字段构建专用的搜索引擎索引。
实现模糊查询、拼音匹配、同义词等。
存储结构仍为加密，搜索返回 ID，再从数据库取密文数据解密。

方案四：局部加密 / 结构化加密

对银行卡、手机号做部分加密（如中间几位），支持前/后模糊匹配。
```
phone_masked = CONCAT(SUBSTR(phone, 1, 3), '****', SUBSTR(phone, 8, 4))
```

方案五：使用模糊匹配安全方案（FFX 模式）

Format Preserving Encryption（格式保持加密）如 FPE/FFX：
- 加密结果仍是数字或固定格式，可用 LIKE 查询。
- 示例：Visa 卡号 4567-****-8910 加密后仍为数字串，可搜索前缀。

例如：FPE 加密“6222021234567890” → “6513984838291883”，仍可做前缀模糊匹配。

三、银行实际部署的组合策略

类型	使用情况	应用场景
AES 加密	常用	数据库存储、服务接口数据加解密
FPE 加密	部分使用	卡号、手机号保留结构后支持模糊匹配
哈希 + 加盐	常用	密码、设备指纹、身份校验标识
脱敏字段	常用	明文存字段前缀用于查询、日志展示等
HSM / KMS	必备	加密服务集中管理、密钥生命周期管理
ES 辅助搜索	常用	名字、地址、模糊匹配、拼音等场景

四、建议做法（实际开发中）

存储设计：

CREATE TABLE customer_info (id BIGINT PRIMARY KEY,name_enc VARBINARY(256),name_search VARCHAR(64), -- 脱敏字段或前缀phone_enc VARBINARY(256),phone_prefix VARCHAR(10), -- 支持 like "138%"...
)