一、前言
近幾年來，無論對網際網路公司還是傳統行業，資料安全一直是企業繞不開的話題。而資料加密是資料安全領域最核心的子產品之一。涉及客戶安全資料或者一些商業性敏感資料，如身份證号、手機号、卡号、客戶号等個人資訊按照相關部門規定，都需要進行資料加密。這對安全部門以及業務團隊都帶來了巨大的挑戰。
二、挑戰
在真實業務場景中，相關業務開發團隊則往往需要針對公司安全部門需求，自行實行并維護一套加解密系統， 如加解密SDK、或加解密服務提供的OpenAPI。然而真正實施過程中會發現有很多讓人頭疼的問題，如業務代碼入侵嚴重，已上線的業務改造成本大，風險高等等。而彩虹橋針對這些痛點，提供了一套完整的透明化解決方案，實作了業務代碼0入侵，安全低風險地無縫進行加密改造。下面我們就來剖析一下整個方案的實作原理。
三、實作原理
3.1 彩虹橋簡單介紹
主要針對不熟悉彩虹橋的同學，這裡做一下簡單介紹。彩虹橋用一句話概括就是基于Apache ShardingSphere二次開發的透明化資料庫中間件，通過資料分片、讀寫分離、影子庫、加解密等能力對原有資料庫進行增強。目前得物内部主要采用的中心化部署架構和非中心化部署2種方式。
想進一步了解彩虹橋的同學，可以參考我之前寫的一篇文章：得物資料庫中間件平台“彩虹橋”演進之路
- 中心化部署架構（Proxy模式）
Proxy模式下，加解密實作子產品是在Proxy内部完成，對上層應用完全透明。
- 去中心化部署（JDBC模式）
JDBC模式下，加解密實作子產品是在Rainbow内部完成，對上層應用完全透明。
3.2 核心名稱解釋
在了解原理之前我們先來認識幾個基本概念：
| 名詞 | 解釋 |
| 邏輯列 | 用于計算加解密列的邏輯名稱，是業務代碼中定義的SQL對應的列名稱。 |
| 密文列 | 用于存儲加密後的資料，是DB中實際存在的真實列名 |
| 明文列 | 存儲明文的列，用于在加密資料遷移過程中仍舊提供服務，在洗數結束後可以删除。 |
3.3 加解密整體架構
整個過程對上遊業務應用完全透明化，主要就是通過彩虹橋的核心子產品對SQL進行解析，然後根據加解密規則找出需要加密的字段和所使用的加解密算法對目标字段進行加解密處理後，再将SQL改成于底層DB互動的SQL。彩虹橋會将使用者請求的明文進行加密後存儲到底層資料庫，并在使用者查詢時将密文從資料庫中取出進行解密後傳回給上遊。通過屏蔽對資料的加密處理，使使用者無需感覺解析 SQL、資料加密、資料解密的處理過程，就像在使用普通資料一樣使用加密資料。
聽起來有點抽象，下面舉個例子就比較好了解了。
-- 業務代碼中的SQL
select phone from t_user where phone = '10086'
-- 經過彩虹橋改寫後實際去資料庫執行的SQL
select 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主要是新增加密規則，讓彩虹橋實作增量的資料的雙寫（明文列、密文列同時維護），此時查詢還是用的明文列。
舉個例子：
-- 查詢 --
-- 業務代碼中的SQL
select phone from t_user where phone = '10086'
-- 這個階段查詢不需要改寫SQL
select phone from t_user where phone = '10086' -- 更新 --
-- 業務代碼中的SQL
update t_user set phone = '10000' where id = 1
-- 經過彩虹橋改寫後實際去資料庫執行的SQL
update 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）- 查明文列切換成查密文列
當存量資料清洗完成之後，就可以通過開關控制（這裡的開關的粒度是列級别）把查明文列切換成查密文列，如果将系統切到密文列進行查詢時，發現系統報錯，可快速把開關改回去即可恢複，整個過程隻對少量查詢有損，不會産生髒資料。
舉個例子：
-- 查詢 --
-- 業務代碼中的SQL
select phone from t_user where phone = '10086'
-- 經過彩虹橋改寫後實際去資料庫執行的SQL
select phone_cipher as phone from t_user where phone_cipher = 'xxx' -- 更新 --
-- 業務代碼中的SQL
update t_user set phone = '10000' where id = 1
-- 經過彩虹橋改寫後實際去資料庫執行的SQL
update t_user set phone = '10000', phone_cipher = 'xxx' where id = 1 - 第三階段（步驟12~14）- 停止寫明文列，隻寫密文列
當把讀切換到密文列運作一段時間穩定後，就可以通過配置來停止明文列的維護，這時候讀寫都是走的密文列了。
舉個例子：
-- 查詢 --
-- 業務代碼中的SQL
select phone from t_user where phone = '10086'
-- 經過彩虹橋改寫後實際去資料庫執行的SQL
select phone_cipher as phone from t_user where phone_cipher = 'xxx' -- 更新 --
-- 業務代碼中的SQL
update t_user set phone = '10000' where id = 1
-- 經過彩虹橋改寫後實際去資料庫執行的SQL
update 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 前提下，已上線系統對加密前後資料進行安全、透明化遷移。無論是業務改造成本還是密鑰安全性上都具備優勢。
作者:新一
來源:微信公衆号:得物技術
出處:https://mp.weixin.qq.com/s/OMKKwhXvpvirZOLgDmUYgg