1. 場景需求

     普通的加密模式下，整段內(nèi)容會被整體加密，密文就不再具備被模糊查詢的功能?？紤]到某些字段存在模糊查詢的求，我們的SDK可以提供一種高級的加密模式，加密后的密文仍然可以支持模糊查詢功能。這里我們對這種模式做簡要介紹，以便ISV在確定方案的時候做出選擇。

      在普通加密方式下，我們在數(shù)據(jù)庫檢索該加密數(shù)據(jù)的時候必須用全文匹配。如姓名：“張大鐵”，用普通方式加密后成為“DQ21aTz/oe9qT2Xje1tTcddQ”，在數(shù)據(jù)庫查詢時，如果希望獲取關(guān)于”張大鐵”的記錄，則對應(yīng)篩選條件就是篩選出加密姓名為”“DQ21aTz/oe9qT2Xje1tTcddQ”的記錄。然而，如果我們想檢索姓名中含有“大鐵”的人的記錄，原本可以用數(shù)據(jù)庫模糊查詢(如SQL的like 語句)方式獲取，現(xiàn)在加密后就無法滿足這樣的要求了。

      現(xiàn)在，我們的加密產(chǎn)品中最大程度的嘗試滿足這種需求。我們有一個允許模糊查詢的加密模式，仍然允許ISV對記錄進(jìn)行模糊查詢。

但是使用這種方式也有一定代價：

? 支持模糊查詢加密方式，產(chǎn)出的密文比較長；

? 支持的模糊查詢子句長度必須大于等于4個英文/數(shù)字，或者2個漢字。不支持過短的查詢(出于安全考慮)；

? 返回的結(jié)果列表中有可能有多余的結(jié)果，需要增加篩選的邏輯：對記錄先解密，再篩選；

      本產(chǎn)品允許對每一個字段都獨立設(shè)置這個字段的加密模式。請您根據(jù)自己的應(yīng)用場景確認(rèn)每個字段的加密方案。請您根據(jù)您的業(yè)務(wù)仔細(xì)審查、選擇。一旦加密開始之后，再更改成本就較高了。

 2. 方案介紹

2.1普通方式：

1)只適用于手機(jī)號之外的其他字段：在SQL語句中以(key = “value”)的形式會出現(xiàn)在where從句中，或者不存在于where從句中。

2)對手機(jī)號字段：在SQL語句的where從句中出現(xiàn)(key like “%前3位”)的前三位模糊查詢。(注釋：即模糊查詢手機(jī)號碼前3位)

2.2支持模糊查詢的方式:

1)在SQL語句的where從句中出現(xiàn)(key like “%partial%”)的全文任意字串模糊搜索部分。（只適用于手機(jī)號之外的其他字段：）

2)僅對手機(jī)號字段：在SQL語句的where從句中出現(xiàn)(key like “%后4位”)的后四位模糊查詢。(注釋：即通過手機(jī)號碼后4位查詢記錄，不支持少于4位的模糊查詢)

請您根據(jù)自己的應(yīng)用場景確認(rèn)每個字段的加密方案。

 注：請您根據(jù)您的業(yè)務(wù)仔細(xì)審查、選擇。一旦加密開始之后，再更改成本就較高了。

 根據(jù)您每個字段的使用加密方案，加密長度可能不同。據(jù)此修改RDS的長度：

密文實例：

不同場景下的代碼修改方案: 將會在代碼開發(fā)方案中展示。

FAQ

• 關(guān)于此文檔暫時還沒有FAQ