因為某種原因，需要去考慮數據脫敏的問題，但是既不想因為脫敏而影響數據的操作性，又需要對一些敏感信息進行可靠的保護。因此，正好解決了手頭問題的我就開始研究各種脫敏手段、尋求最適合目前現狀的脫敏解決方案。
對於已經上線的業務，如何在不修改業務邏輯、業務SQL的情況下，透明化、安全低風險地實現無縫進行脫敏改造呢？
Apache的ShardingSphere進入了我的視野，Apache ShardingSphere是一套開源的分布式數據庫中間件解決方案組成的生態圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（規划中）這3款相互獨立，卻又能夠混合部署配合使用的產品組成。它們均能夠提供標准化的數據分片、分布式事務和分布式治理功能，可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。
目前已上線業務，之前一直將明文存儲在數據庫中。因為某些原因需要對已上線業務進行脫敏整改。為了解決這個問題，有三個問題需要考慮：
-
1、 如何對大量的歷史數據需要脫敏處理。
-
2、 如何能在不改動業務SQL和邏輯情況下，將新增數據進行脫敏處理，並存儲到數據庫。
-
3 、如何較為安全地實現業務系統在明文與密文數據間的遷移。
對靜態業務脫敏有專業的脫敏手段，包括一些脫敏工具、亦或是使用SPL腳本或者存儲過程對存量數據進行脫敏。所以，我們這次主要研究如何不影響業務邏輯進行增量數據脫敏。
一、數據脫敏的原理
ShardingSphere提供的Encrypt-JDBC和業務代碼部署在一起。業務方需面向Encrypt-JDBC進行JDBC編程。由於Encrypt-JDBC實現所有JDBC標准接口，業務代碼無需做額外改造即可兼容使用。此時，業務代碼所有與數據庫的交互行為交由Encrypt-JDBC負責。業務只需提供脫敏規則即可。作為業務代碼與底層數據庫中間的橋梁，Encrypt-JDBC便可攔截用戶行為，並在改造行為后與數據庫交互。
Encrypt-JDBC將用戶發起的SQL進行攔截，並通過SQL語法解析器進行解析、理解SQL行為，再依據用戶傳入的脫敏規則，找出需要脫敏的字段和所使用的加解密器對目標字段進行加解密處理后，再與底層數據庫進行交互。ShardingSphere會將用戶請求的明文進行加密后存儲到底層數據庫；並在用戶查詢時，將密文從數據庫中取出進行解密后返回給終端用戶。ShardingSphere通過屏蔽對數據的脫敏處理，使用戶無需感知解析SQL、數據加密、數據解密的處理過程，就像在使用普通數據一樣使用脫敏數據。
二、脫敏的配置
我們這邊可以直接用yaml配置來解釋脫敏規則的配置。
1、數據源配置
是指DataSource的配置
spring:
application:
name: sharding-jdbc-examples
main:
allow-bean-definition-overriding: true
shardingsphere:
datasource: #數據源配置
names: ds
ds:
url: jdbc:mysql://127.0.0.1:3306/test1?useSSL=false&useUnicode=true&serverTimezone=UTC
type: com.alibaba.druid.pool.DruidDataSource
username: root
password: root
driver-class-name: com.mysql.cj.jdbc.Driver
2、加密器配置
是指使用什么加密策略進行加解密。目前ShardingSphere內置了兩種加解密策略：AES/MD5。用戶還可以通過實現ShardingSphere提供的接口，自行實現一套加解密算法。
encrypt:
encryptors:
encryptor_aes:
type: aes #加解密器類型，可自定義或選擇內置類型：MD5/AES
props:
aes.key.value: 123456* #屬性配置, 注意：使用AES加密器，需要配置AES加密器的KEY屬性：aes.key.value
qualifiedColumns: t_user.password
3、脫敏表配置
用於告訴ShardingSphere數據表里哪個列用於存儲密文數據（cipherColumn）、哪個列用於存儲明文數據（plainColumn）以及用戶想使用哪個列進行SQL編寫（logicColumn）。
tables:
t_user:
columns:
passowrd: #logicColumn
plainColumn: passowrd #plainColumn
cipherColumn: newpassowrd #cipherColumn
encryptor: encryptor_aes #加密器配置
4、查詢屬性的配置
當底層數據庫表里同時存儲了明文數據、密文數據后，該屬性開關用於決定是直接查詢數據庫表里的明文數據進行返回，還是查詢密文數據通過Encrypt-JDBC解密后返回。
props:
# 打印SQL
sql.show: true
check:
table:
metadata: true
# 是否在啟動時檢查分表元數據一致性
enabled: true
query:
with:
cipher:
# 選擇使用明文或者密文字段進行查詢，true為密文
column: true
當配置好了這些信息后，就可以完成對數據的加密。
5、脫敏處理過程
現在我們利用之前做好的配置來進行一次簡單的測試
測試完畢，我們可以看出，通過用戶提供的脫敏配置，數據找到了logicColumn，於是對邏輯列及其對應的明文數據進行脫敏處理。可以看出ShardingSphere將面向用戶的邏輯列與面向底層數據庫的明文列和密文列進行了列名以及數據的脫敏映射轉換。
了解了數據新增的邏輯，那么數據查詢、修改也是相似的原理。同時，查詢的時候也可以選擇使用明文還是密文字段進行查詢。
三、新業務與舊業務
1、新業務
如果不涉及到舊業務改造，就可以免去plainColumn字段，直接使用cipherColumn即可。
2、舊業務
已上線的任務，由於數據庫存在大量的明文數據，如何對存量數據進行清洗，同時對新數據進行加密，在兩套系統中無縫銜接，才是我們要解決的問題。
1、任務遷移前
數據清洗之前，我們使用我之前的配置的內容，增刪改查繼續使用明文，在數據庫只是新增字段存儲密文數據，在對存量數據進行清洗之前不要擅自行動。
2、任務遷移中
新增的數據已被Encrypt-JDBC將密文存儲到密文列，明文存儲到明文列；歷史數據被業務方自行加密清洗后，將密文也存儲到密文列。也就是說現在的數據庫里即存放着明文也存放着密文。同時我們隨時可以通過配置來更換查詢出的數據是明文還是密文。
在校驗完系統的可靠性和數據的正確性之前，不要直接刪掉明文數據，以防萬一。
2、任務遷移后
由於安全審計部門要求，業務系統一般不可能讓數據庫的明文列和密文列永久同步保留，我們需要在系統穩定后將明文列數據刪除。
之后，我們的脫敏表配置也可以進行改動了。（當然，特殊情況也可以留下明文數據進行備份，這個就要考慮到實際情況了）
tables:
t_user:
columns:
passowrd: #logicColumn
cipherColumn: newpassowrd #cipherColumn
encryptor: encryptor_aes #加密器配置
四、選擇ShardingSphere進行脫敏處理的理由
- 1、ShardingSphere提供了自動化和透明化數據脫敏過程，我們無需關注脫敏中間實現細節。
- 2 提供多種內置、第三方(AKS)的脫敏策略，僅需簡單配置即可使用。
- 3、提供脫敏策略API接口，用戶可實現接口，從而使用自定義脫敏策略進行數據脫敏。
- 4、支持切換不同的脫敏策略。
- 5、針對已上線業務，可實現明文數據與密文數據同步存儲，並通過配置決定使用明文列還是密文列進行查詢。可實現在不改變業務查詢SQL前提下，已上線系統對加密前后數據進行安全、透明化遷移。
當然，使用脫敏功能+分庫分表功能，部分特殊SQL不支持，官方也提供了SQL規范供以查詢規范地址
大家好，我是練習java兩年半時間的南橘，下面是我的微信，需要之前的導圖或者想互相交流經驗的小伙伴可以一起互相交流哦。
微信公眾號，有興趣的小伙伴來關注一下吧~我最新的內容都會在這里發布
