?一、前言

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

二、挑戰(zhàn)

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

三、實現(xiàn)原理

3.1 彩虹橋簡單介紹

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

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

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

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

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

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

3.2 核心名稱解釋

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

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

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

聽起來有點抽象，下面舉個例子就比較好理解了。

-- 業(yè)務(wù)代碼中的SQLselect phone from t_user where phone = '10086'
-- 經(jīng)過彩虹橋改寫后實際去數(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'，這里實際查詢的是密文列，但是整個上層是無感知的，對業(yè)務(wù)來說這個字段就是phone，實際查詢的數(shù)據(jù)庫列是phone_cipher。

3.4 加密規(guī)則

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

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

3.5 整體解決方案詳解

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

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

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

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

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

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

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

舉個例子：

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

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

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

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

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

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

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

舉個例子：

-- 查詢 --
-- 業(yè)務(wù)代碼中的SQLselect phone from t_user where phone = '10086'
-- 經(jīng)過彩虹橋改寫后實際去數(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ù)據(jù)庫執(zhí)行的SQLupdate t_user set phone = '10000', phone_cipher = 'xxx' where id = 1

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

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

舉個例子：

-- 查詢 --
-- 業(yè)務(wù)代碼中的SQLselect phone from t_user where phone = '10086'
-- 經(jīng)過彩虹橋改寫后實際去數(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ù)據(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)隊日常會有一些抽數(shù)需求，具體可以分T+1離線抽數(shù)、數(shù)據(jù)實時訂閱2種。均可以通過數(shù)據(jù)平臺提供相關(guān)解密能力，數(shù)據(jù)平臺內(nèi)部會調(diào)用彩虹橋OpenAPI拿到密鑰以及加解密配置，做解密后往下游投遞。

3.6 不支持項

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

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

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

四、未來規(guī)劃

密鑰動態(tài)替換

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

加鹽加密

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

五、總結(jié)

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