密文字段检索方案
1. 场景需求
普通的加密模式下，整段内容会被整体加密，密文就不再具备被模糊查询的功能。考虑到某些字段存在模糊查询的求，我们的SDK可以提供一种高级的加密模式，加密后的密文仍然可以支持模糊查询功能。这里我们对这种模式做简要介绍，以便ISV在确定方案的时候做出选择。
在普通加密方式下，我们在数据库检索该加密数据的时候必须用全文匹配。如姓名：“张大铁”，用普通方式加密后成为“DQ21aTz/oe9qT2Xje1tTcddQ”，在数据库查询时，如果希望获取关于”张大铁”的记录，则对应筛选条件就是筛选出加密姓名为”“DQ21aTz/oe9qT2Xje1tTcddQ”的记录。然而，如果我们想检索姓名中含有“大铁”的人的记录，原本可以用数据库模糊查询(如SQL的like 语句)方式获取，现在加密后就无法满足这样的要求了。
现在，我们的加密产品中最大程度的尝试满足这种需求。我们有一个允许模糊查询的加密模式，仍然允许ISV对记录进行模糊查询。
但是使用这种方式也有一定代价：
• 支持模糊查询加密方式，产出的密文比较长；
• 支持的模糊查询子句长度必须大于等于4个英文/数字，或者2个汉字。不支持过短的查询(出于安全考虑)；
• 返回的结果列表中有可能有多余的结果，需要增加筛选的逻辑：对记录先解密，再筛选；
本产品允许对每一个字段都独立设置这个字段的加密模式。请您根据自己的应用场景确认每个字段的加密方案。请您根据您的业务仔细审查、选择。一旦加密开始之后，再更改成本就较高了。
2. 方案介绍
2.1普通方式：
1)只适用于手机号之外的其他字段：在SQL语句中以(key = “value”)的形式会出现在where从句中，或者不存在于where从句中。
2)对手机号字段：在SQL语句的where从句中出现(key like “%前3位”)的前三位模糊查询。(注释：即模糊查询手机号码前3位)
2.2支持模糊查询的方式:
1)在SQL语句的where从句中出现(key like “%partial%”)的全文任意字串模糊搜索部分。（只适用于手机号之外的其他字段：）
2)仅对手机号字段：在SQL语句的where从句中出现(key like “%后4位”)的后四位模糊查询。(注释：即通过手机号码后4位查询记录，不支持少于4位的模糊查询)
请您根据自己的应用场景确认每个字段的加密方案。
注：请您根据您的业务仔细审查、选择。一旦加密开始之后，再更改成本就较高了。
根据您每个字段的使用加密方案，加密长度可能不同。据此修改RDS的长度：
| 精确查询(场景1,2) | 模糊查询(场景3) |
nick/ receiver_name | varchar(32+字符长度*4) | varchar(32+字符长度*8) |
normal (其他场景) | varchar(32+字符长度*4) | varchar(32+字符长度*8) |
| 场景4 | 模糊查询(场景5) |
phone | varchar(16+(号码长度-8)+(24)) | varchar(20+(字符长度*4)) |
密文实例：
场景 | 字段 | 明文 |
|
普通方式 | nick/ receiver_name / normal | taobaoTEST | ~CKoqAl2hWzh54uBFv9Suug==~1~ |
支持模糊查询方式 | nick/ receiver_name / normal | taobaoTEST | ~CKoqAl2hWzh54uBFv9Suug==~ weroiHKLphWWioZ32nkndkWEfjhwiensdfwWKHrw~1~ |
|
|
|
|
普通方式 | phone | 13834566786 | $138$SuR++h6AtlSj8Z59W2W9EQ==$1$ |
支持模糊查询方式 | phone | 13834566786 | $SuR++h6AtlSj8Z59W2W9EQ==$Zut6yIQxS3DclSj/Z5YdwH9EQ2x$1$ |
不同场景下的代码修改方案: 将会在代码开发方案中展示。
FAQ
- 关于此文档暂时还没有FAQ