感谢您的反馈！
-
用户反馈
用户反馈
网络异常，请重新提交！
重新提交
普通的加密模式下，整段内容会被整体加密，密文就不再具备被模糊查询的功能。考虑到某些字段存在模糊查询的求，我们的SDK可以提供一种高级的加密模式，加密后的密文仍然可以支持模糊查询功能。这里我们对这种模式做简要介绍，以便ISV在确定方案的时候做出选择。
在普通加密方式下，我们在数据库检索该加密数据的时候必须用全文匹配。如姓名：“张大铁”，用普通方式加密后成为“DQ21aTz/oe9qT2Xje1tTcddQ”，在数据库查询时，如果希望获取关于”张大铁”的记录，则对应筛选条件就是筛选出加密姓名为”“DQ21aTz/oe9qT2Xje1tTcddQ”的记录。然而，如果我们想检索姓名中含有“大铁”的人的记录，原本可以用数据库模糊查询(如SQL的like 语句)方式获取，现在加密后就无法满足这样的要求了。
现在，我们的加密产品中最大程度的尝试满足这种需求。我们有一个允许模糊查询的加密模式，仍然允许ISV对记录进行模糊查询。
密文检索的功能实现是根据4位英文字符（半角），2个中文字符（全角）为一个检索条件。将一个字段拆分为多个，
比如：taobao123
使用4个字符为一组的加密方式。
第一组 taob ，第二组aoba ，第三组obao ，第四组 bao1 … 依次类推
如果需要检索 所有包含 检索条件4个字符的数据 比如：aoba ，加密字符后通过key like “%partial%” 查库。
因为密文检索开启后 密文长度会膨胀几倍以上，如果没有强需求建议不开启。
但是使用这种方式也有一定代价：
• 支持模糊查询加密方式，产出的密文比较长；
• 支持的模糊查询子句长度必须大于等于4个英文/数字，或者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位查询记录，phone 类型 只支持4位检索条件)
请您根据自己的应用场景确认每个字段的加密方案。
注：请您根据您的业务仔细审查、选择。一旦加密开始之后，再更改成本就较高了。
根据您每个字段的使用加密方案，加密长度可能不同。据此修改RDS的长度：
|
|
精确查询(场景1,2) |
模糊查询(场景3) |
| nick/ receiver_name |
varchar(32+字符长度*4) |
varchar(32+字符长度*8) |
| 其他字段 |
varchar(32+字符长度*4) |
varchar(32+字符长度*8) |
|
|
场景4 |
模糊查询(场景5) |
| phone |
varchar(16+(号码长度-8)+(24)) |
varchar(20+(字符长度*4)) |
密文实例：
| 场景 |
字段 |
明文 |
|
| 普通方式 |
nick/ receiver_name
|
taobaoTEST |
~CKoqAl2hWzh54uBFv9Suug==~1~ |
| 支持模糊查询方式 |
nick/ receiver_name
|
taobaoTEST |
~CKoqAl2hWzh54uBFv9Suug==~ weroiHKLphWWioZ32nkndkWEfjhwiensdfwWKHrw~1~ |
|
|
|
|
|
| 普通方式 |
phone |
13834566786 |
$138$SuR++h6AtlSj8Z59W2W9EQ==$1$ |
| 支持模糊查询方式 |
phone |
13834566786 |
$SuR++h6AtlSj8Z59W2W9EQ==$Zut6yIQxS3DclSj/Z5YdwH9EQ2x$1$ |
不同场景下的代码修改方案: 将会在代码开发方案中展示。