?一、前言

近幾年來，無論對互聯網公司還是傳統行業，數據安全一直是企業繞不開的話題。而數據加密是數據安全領域最核心的模塊之一。涉及客戶安全數據或者一些商業性敏感數據，如身份證號、手機號、卡號、客戶號等個人信息按照相關部門規定，都需要進行數據加密。這對安全部門以及業務團隊都帶來了巨大的挑戰。

二、挑戰

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

三、實現原理

3.1 彩虹橋簡單介紹

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

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

中心化部署架構（Proxy模式）

Proxy模式下，加解密實現模塊是在Proxy內部完成，對上層應用完全透明。

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

JDBC模式下，加解密實現模塊是在Rainbow內部完成，對上層應用完全透明。

3.2 核心名稱解釋

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

3.3 加解密整體架構

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

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

-- 業務代碼中的SQLselect phone from t_user where phone = '10086'
-- 經過彩虹橋改寫后實際去數據庫執行的SQLselect phone_cipher as phone from t_user where phone_cipher = 'xxx'

其中phone為邏輯列，phone_cipher為密文列，彩虹橋內部把10086經過加密后，把where條件改成phone_cipher = 'xxx'，這里實際查詢的是密文列，但是整個上層是無感知的，對業務來說這個字段就是phone，實際查詢的數據庫列是phone_cipher。

3.4 加密規則

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

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

3.5 整體解決方案詳解

3.5.1 新上線業務

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

3.5.2 已上線業務改造

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

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

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

步驟2~5主要是新增加密規則，讓彩虹橋實現增量的數據的雙寫（明文列、密文列同時維護），此時查詢還是用的明文列。

舉個例子：

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

-- 更新 --
-- 業務代碼中的SQLupdate t_user set phone = '10000' where id = 1-- 經過彩虹橋改寫后實際去數據庫執行的SQLupdate t_user set phone = '10000', phone_cipher = 'xxx' where id = 1

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

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

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

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

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

舉個例子：

-- 查詢 --
-- 業務代碼中的SQLselect phone from t_user where phone = '10086'
-- 經過彩虹橋改寫后實際去數據庫執行的SQLselect phone_cipher as phone from t_user where phone_cipher = 'xxx'

-- 更新 --
-- 業務代碼中的SQLupdate t_user set phone = '10000' where id = 1
-- 經過彩虹橋改寫后實際去數據庫執行的SQLupdate t_user set phone = '10000', phone_cipher = 'xxx' where id = 1

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

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

舉個例子：

-- 查詢 --
-- 業務代碼中的SQLselect phone from t_user where phone = '10086'
-- 經過彩虹橋改寫后實際去數據庫執行的SQLselect phone_cipher as phone from t_user where phone_cipher = 'xxx'

-- 更新 --
-- 業務代碼中的SQLupdate t_user set phone = '10000' where id = 1
-- 經過彩虹橋改寫后實際去數據庫執行的SQLupdate t_user set phone_cipher = 'xxx' where id = 1

第四階段（步驟15）- 數據層明文列清洗

通過DML語句將明文列數據統一刷成無效數據即可，這里不建議DDL刪列。

3.5.3 離線解密

大數據或風控團隊日常會有一些抽數需求，具體可以分T+1離線抽數、數據實時訂閱2種。均可以通過數據平臺提供相關解密能力，數據平臺內部會調用彩虹橋OpenAPI拿到密鑰以及加解密配置，做解密后往下游投遞。

3.6 不支持項

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

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

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

四、未來規劃

密鑰動態替換

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

加鹽加密

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

五、總結

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