?一、前言

近幾年來，無論對(duì)互聯(lián)網(wǎng)公司還是傳統(tǒng)行業(yè)，數(shù)據(jù)安全一直是企業(yè)繞不開的話題。而數(shù)據(jù)加密是數(shù)據(jù)安全領(lǐng)域最核心的模塊之一。涉及客戶安全數(shù)據(jù)或者一些商業(yè)性敏感數(shù)據(jù)，如身份證號(hào)、手機(jī)號(hào)、卡號(hào)、客戶號(hào)等個(gè)人信息按照相關(guān)部門規(guī)定，都需要進(jìn)行數(shù)據(jù)加密。這對(duì)安全部門以及業(yè)務(wù)團(tuán)隊(duì)都帶來了巨大的挑戰(zhàn)。

二、挑戰(zhàn)

在真實(shí)業(yè)務(wù)場(chǎng)景中，相關(guān)業(yè)務(wù)開發(fā)團(tuán)隊(duì)則往往需要針對(duì)公司安全部門需求，自行實(shí)行并維護(hù)一套加解密系統(tǒng)， 如加解密SDK、或加解密服務(wù)提供的OpenAPI。然而真正實(shí)施過程中會(huì)發(fā)現(xiàn)有很多讓人頭疼的問題，如業(yè)務(wù)代碼入侵嚴(yán)重，已上線的業(yè)務(wù)改造成本大，風(fēng)險(xiǎn)高等等。而彩虹橋針對(duì)這些痛點(diǎn)，提供了一套完整的透明化解決方案，實(shí)現(xiàn)了業(yè)務(wù)代碼0入侵，安全低風(fēng)險(xiǎn)地?zé)o縫進(jìn)行加密改造。下面我們就來剖析一下整個(gè)方案的實(shí)現(xiàn)原理。

三、實(shí)現(xiàn)原理

3.1 彩虹橋簡(jiǎn)單介紹

主要針對(duì)不熟悉彩虹橋的同學(xué)，這里做一下簡(jiǎn)單介紹。彩虹橋用一句話概括就是基于Apache ShardingSphere二次開發(fā)的透明化數(shù)據(jù)庫中間件，通過數(shù)據(jù)分片、讀寫分離、影子庫、加解密等能力對(duì)原有數(shù)據(jù)庫進(jìn)行增強(qiáng)。目前得物內(nèi)部主要采用的中心化部署架構(gòu)和非中心化部署2種方式。

想進(jìn)一步了解彩虹橋的同學(xué)，可以參考我之前寫的一篇文章：得物數(shù)據(jù)庫中間件平臺(tái)“彩虹橋”演進(jìn)之路

中心化部署架構(gòu)（Proxy模式）

Proxy模式下，加解密實(shí)現(xiàn)模塊是在Proxy內(nèi)部完成，對(duì)上層應(yīng)用完全透明。

• 去中心化部署（JDBC模式）

JDBC模式下，加解密實(shí)現(xiàn)模塊是在Rainbow內(nèi)部完成，對(duì)上層應(yīng)用完全透明。

3.2 核心名稱解釋

在了解原理之前我們先來認(rèn)識(shí)幾個(gè)基本概念：

3.3 加解密整體架構(gòu)

整個(gè)過程對(duì)上游業(yè)務(wù)應(yīng)用完全透明化，主要就是通過彩虹橋的內(nèi)核模塊對(duì)SQL進(jìn)行解析，然后根據(jù)加解密規(guī)則找出需要加密的字段和所使用的加解密算法對(duì)目標(biāo)字段進(jìn)行加解密處理后，再將SQL改成于底層DB交互的SQL。彩虹橋會(huì)將用戶請(qǐng)求的明文進(jìn)行加密后存儲(chǔ)到底層數(shù)據(jù)庫，并在用戶查詢時(shí)將密文從數(shù)據(jù)庫中取出進(jìn)行解密后返回給上游。通過屏蔽對(duì)數(shù)據(jù)的加密處理，使用戶無需感知解析 SQL、數(shù)據(jù)加密、數(shù)據(jù)解密的處理過程，就像在使用普通數(shù)據(jù)一樣使用加密數(shù)據(jù)。

聽起來有點(diǎn)抽象，下面舉個(gè)例子就比較好理解了。

-- 業(yè)務(wù)代碼中的SQLselect phone from t_user where phone = '10086'
-- 經(jīng)過彩虹橋改寫后實(shí)際去數(shù)據(jù)庫執(zhí)行的SQLselect phone_cipher as phone from t_user where phone_cipher = 'xxx'

其中phone為邏輯列，phone_cipher為密文列，彩虹橋內(nèi)部把10086經(jīng)過加密后，把where條件改成phone_cipher = 'xxx'，這里實(shí)際查詢的是密文列，但是整個(gè)上層是無感知的，對(duì)業(yè)務(wù)來說這個(gè)字段就是phone，實(shí)際查詢的數(shù)據(jù)庫列是phone_cipher。

3.4 加密規(guī)則

主要是用于告訴彩虹橋哪個(gè)邏輯表里哪個(gè)列用于存儲(chǔ)密文數(shù)據(jù)（密文列）、使用什么算法加解密、哪個(gè)列用于存儲(chǔ)明文數(shù)據(jù)（明文列）以及用戶想使用哪個(gè)列進(jìn)行 SQL 編寫（邏輯列），在結(jié)合上面的例子看，規(guī)則配置就應(yīng)該是這樣的。

這里的明文列可能比較難理解，這里單獨(dú)解釋一下，明文列主要用于在加密數(shù)據(jù)遷移過程中仍舊提供服務(wù)，在洗數(shù)結(jié)束后可以刪除。因?yàn)橐焉暇€業(yè)務(wù)改造前，數(shù)據(jù)庫里面存儲(chǔ)的只有明文，在改造過程前幾個(gè)階段查詢所用列都是明文列。一般來說明文列可以與邏輯列保持一致。

3.5 整體解決方案詳解

3.5.1 新上線業(yè)務(wù)

新上線業(yè)務(wù)由于一切從零開始，不存在歷史數(shù)據(jù)清洗問題，所以相對(duì)簡(jiǎn)單。只需要配置好規(guī)則，數(shù)據(jù)層不需要只需要保留一個(gè)密文列即可。

3.5.2 已上線業(yè)務(wù)改造

已上線業(yè)務(wù)的改造流程相對(duì)復(fù)雜，由于業(yè)務(wù)已經(jīng)在線上運(yùn)行，數(shù)據(jù)庫里必然存有大量明文歷史數(shù)據(jù)。需要解決的問題是如何讓歷史數(shù)據(jù)得以加密清洗、如何讓增量數(shù)據(jù)得以加密處理、如何讓業(yè)務(wù)在新舊兩套數(shù)據(jù)系統(tǒng)之間進(jìn)行無縫、透明化遷移。

下面我們把整套解決方案拆分成幾個(gè)階段來逐個(gè)分析。

第一階段（步驟1~8）- 增量數(shù)據(jù)雙寫（明文列、密文列同時(shí)維護(hù)）、存量數(shù)據(jù)清洗

步驟2~5主要是新增加密規(guī)則，讓彩虹橋?qū)崿F(xiàn)增量的數(shù)據(jù)的雙寫（明文列、密文列同時(shí)維護(hù)），此時(shí)查詢還是用的明文列。

舉個(gè)例子：

-- 查詢 --
-- 業(yè)務(wù)代碼中的SQLselect phone from t_user where phone = '10086'
-- 這個(gè)階段查詢不需要改寫SQLselect phone from t_user where phone = '10086'

-- 更新 --
-- 業(yè)務(wù)代碼中的SQLupdate t_user set phone = '10000' where id = 1-- 經(jīng)過彩虹橋改寫后實(shí)際去數(shù)據(jù)庫執(zhí)行的SQLupdate t_user set phone = '10000', phone_cipher = 'xxx' where id = 1

步驟6~8的存量數(shù)據(jù)清洗主要是借助數(shù)據(jù)平臺(tái)（得物內(nèi)部數(shù)據(jù)同步&訂閱&遷移中間件）完成，由彩虹橋下發(fā)密鑰跟對(duì)應(yīng)的庫表列信息，數(shù)據(jù)平臺(tái)負(fù)責(zé)把彩虹橋規(guī)則生效前的所有歷史數(shù)據(jù)，按照對(duì)應(yīng)加密規(guī)則更新密文列。

update t_user set phone_cipher = 'xxx',modify_time = modify_time where id = 1 and phone = '10086'

這里where條件加上 phone = '10086' 是為了保證更新的時(shí)候，這條數(shù)據(jù)的明文從查詢出來后沒有被其他上游修改過。

第二階段（步驟9~11）- 查明文列切換成查密文列

當(dāng)存量數(shù)據(jù)清洗完成之后，就可以通過開關(guān)控制（這里的開關(guān)的粒度是列級(jí)別）把查明文列切換成查密文列，如果將系統(tǒng)切到密文列進(jìn)行查詢時(shí)，發(fā)現(xiàn)系統(tǒng)報(bào)錯(cuò)，可快速把開關(guān)改回去即可恢復(fù)，整個(gè)過程只對(duì)少量查詢有損，不會(huì)產(chǎn)生臟數(shù)據(jù)。

舉個(gè)例子：

-- 查詢 --
-- 業(yè)務(wù)代碼中的SQLselect phone from t_user where phone = '10086'
-- 經(jīng)過彩虹橋改寫后實(shí)際去數(shù)據(jù)庫執(zhí)行的SQLselect phone_cipher as phone from t_user where phone_cipher = 'xxx'

-- 更新 --
-- 業(yè)務(wù)代碼中的SQLupdate t_user set phone = '10000' where id = 1
-- 經(jīng)過彩虹橋改寫后實(shí)際去數(shù)據(jù)庫執(zhí)行的SQLupdate t_user set phone = '10000', phone_cipher = 'xxx' where id = 1

第三階段（步驟12~14）- 停止寫明文列，只寫密文列

當(dāng)把讀切換到密文列運(yùn)行一段時(shí)間穩(wěn)定后，就可以通過配置來停止明文列的維護(hù)，這時(shí)候讀寫都是走的密文列了。

舉個(gè)例子：

-- 查詢 --
-- 業(yè)務(wù)代碼中的SQLselect phone from t_user where phone = '10086'
-- 經(jīng)過彩虹橋改寫后實(shí)際去數(shù)據(jù)庫執(zhí)行的SQLselect phone_cipher as phone from t_user where phone_cipher = 'xxx'

-- 更新 --
-- 業(yè)務(wù)代碼中的SQLupdate t_user set phone = '10000' where id = 1
-- 經(jīng)過彩虹橋改寫后實(shí)際去數(shù)據(jù)庫執(zhí)行的SQLupdate t_user set phone_cipher = 'xxx' where id = 1

第四階段（步驟15）- 數(shù)據(jù)層明文列清洗

通過DML語句將明文列數(shù)據(jù)統(tǒng)一刷成無效數(shù)據(jù)即可，這里不建議DDL刪列。

3.5.3 離線解密

大數(shù)據(jù)或風(fēng)控團(tuán)隊(duì)日常會(huì)有一些抽數(shù)需求，具體可以分T+1離線抽數(shù)、數(shù)據(jù)實(shí)時(shí)訂閱2種。均可以通過數(shù)據(jù)平臺(tái)提供相關(guān)解密能力，數(shù)據(jù)平臺(tái)內(nèi)部會(huì)調(diào)用彩虹橋OpenAPI拿到密鑰以及加解密配置，做解密后往下游投遞。

3.6 不支持項(xiàng)

加密字段無法支持查詢不區(qū)分大小寫功能；

加密字段無法支持比較操作，如：大于、小于、ORDER BY、BETWEEN、LIKE 等；

加密字段無法支持計(jì)算操作，如：AVG、SUM 以及計(jì)算表達(dá)式。

四、未來規(guī)劃

密鑰動(dòng)態(tài)替換

數(shù)據(jù)加密是為了防止脫庫時(shí)一些敏感字段泄露，那如果密鑰泄露了，即使做了加密也是徒勞。所以密鑰支持動(dòng)態(tài)替換，整個(gè)數(shù)據(jù)安全等級(jí)會(huì)更上一層樓。具體的實(shí)現(xiàn)方式其實(shí)也比較簡(jiǎn)單，就是在密文中嵌入版本號(hào)信息，解密的時(shí)候根據(jù)版本號(hào)去匹配對(duì)應(yīng)的密鑰即可，同步清洗老版本的密文列即可。

加鹽加密

常規(guī)的加密算法，同一個(gè)明文加密后的密文是一樣的，這樣很容易被撞庫。如果我們?cè)诩用艿臅r(shí)候加上某個(gè)變動(dòng)種子（加鹽加密），這樣加密后的密文就非常隨機(jī)了，很難通過撞庫來破解。進(jìn)一步提升了安全等級(jí)。

五、總結(jié)

數(shù)據(jù)安全是一個(gè)非常嚴(yán)肅的話題，一旦出現(xiàn)數(shù)據(jù)泄露，特別是涉及敏感信息，對(duì)客戶和公司都可能造成不可估量的損失，所以數(shù)據(jù)加密的必要性不言而喻。對(duì)比傳統(tǒng)的加解密方案，彩虹橋這種方案優(yōu)勢(shì)非常明顯，首先是自動(dòng)化 & 透明化數(shù)據(jù)加密過程，用戶無需關(guān)注加密中間實(shí)現(xiàn)細(xì)節(jié)，只需要配置自己需要加密的列，還有彩虹橋內(nèi)置多種加密算法（MD5/AES/RC4等）可配置，并且可根據(jù)實(shí)際需要自定義加密算法進(jìn)行數(shù)據(jù)加密。特別是大部分場(chǎng)景都是針對(duì)已上線業(yè)務(wù)的改造，在改造過程中彩虹橋可實(shí)現(xiàn)明文數(shù)據(jù)與密文數(shù)據(jù)同步存儲(chǔ)，并通過配置決定使用明文列還是密文列進(jìn)行查詢，可實(shí)現(xiàn)在不改變業(yè)務(wù)查詢 SQL 前提下，已上線系統(tǒng)對(duì)加密前后數(shù)據(jù)進(jìn)行安全、透明化遷移。無論是業(yè)務(wù)改造成本還是密鑰安全性上都具備優(yōu)勢(shì)。