Apache ShardingSphere數據脫敏全解決方案詳解(上)

做者介紹

潘娟，京東數科高級DBA，主要負責京東數科數據庫中間件開發、數據庫運維自動化平臺開發、生產數據庫運維工做。屢次參與京東6.1八、11.11等大促活動的護航工做。曾負責京東數科數據庫自動化平臺設計與開發項目，現專一於Apache ShardingSphere分佈式數據庫中間件開發。樂於在數據庫、自動化、分佈式、中間件等相關領域進行學習和探索。

1、背景

安全控制一直是治理的重要環節，數據脫敏屬於安全控制的範疇。對互聯網公司、傳統行業來講，數據安全一直是極爲重視和敏感的話題。數據脫敏是指對某些敏感信息經過脫敏規則進行數據的變形，實現敏感隱私數據的可靠保護。涉及客戶安全數據或者一些商業性敏感數據，如身份證號、手機號、卡號、客戶號等我的信息按照相關部門規定，都須要進行數據脫敏。

在真實業務場景中，相關業務開發團隊則每每須要針對公司安所有門需求，自行實行並維護一套加解密系統，而當脫敏場景發生改變時，自行維護的脫敏系統每每又面臨着重構或修改風險。此外，對於已經上線的業務，如何在不修改業務邏輯、業務SQL的狀況下，透明化、安全低風險地實現無縫進行脫敏改造呢？

Apache ShardingSphere根據業界對脫敏的需求及業務改造痛點，提供了一套完整、安全、透明化、低改形成本的數據脫敏整合解決方案。

2、前序

Apache ShardingSphere是一套開源的分佈式數據庫中間件解決方案組成的生態圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（規劃中）這3款相互獨立，卻又可以混合部署配合使用的產品組成。它們均可以提供標準化的數據分片、分佈式事務和分佈式治理功能，可適用於如Java同構、異構語言、容器、雲原生等各類多樣化的應用場景。

數據脫敏模塊屬於ShardingSphere分佈式治理這一核心功能下的子功能模塊。它經過對用戶輸入的SQL進行解析，並依據用戶提供的脫敏配置對SQL進行改寫，從而實現對原文數據進行加密，並將原文數據(可選)及密文數據同時存儲到底層數據庫。在用戶查詢數據時，它又從數據庫中取出密文數據，並對其解密，最終將解密後的原始數據返回給用戶。Apache ShardingSphere分佈式數據庫中間件自動化&透明化了數據脫敏過程，讓用戶無需關注數據脫敏的實現細節，像使用普通數據那樣使用脫敏數據。此外，不管是已在線業務進行脫敏改造，仍是新上線業務使用脫敏功能，ShardingSphere均可以提供一套相對完善的解決方案。

3、需求場景分析

對於數據脫敏的需求，在現實的業務場景中通常分爲兩種狀況：

新業務上線，安所有門規定需將涉及用戶敏感信息，例如銀行、手機號碼等進行加密後存儲到數據庫，在使用的時候再進行解密處理。由於是全新系統，於是沒有存量數據清洗問題，因此實現相對簡單。

已上線業務，以前一直將明文存儲在數據庫中。相關部門忽然須要對已上線業務進行脫敏整改。這種場景通常須要處理三個問題：

    a) 歷史數據須要如何進行脫敏處理，即洗數。

    b) 如何能在不改動業務SQL和邏輯狀況下，將新增數據進行脫敏處理，並存儲到數據庫；在使用時，再進行解密取出。

    c) 如何較爲安全、無縫、透明化地實現業務系統在明文與密文數據間的遷移。

4、脫敏流程詳解

總體架構

ShardingSphere提供的Encrypt-JDBC和業務代碼部署在一塊兒。業務方需面向Encrypt-JDBC進行JDBC編程。因爲Encrypt-JDBC實現全部JDBC標準接口，業務代碼無需作額外改造便可兼容使用。此時，業務代碼全部與數據庫的交互行爲交由Encrypt-JDBC負責。業務只需提供脫敏規則便可。做爲業務代碼與底層數據庫中間的橋樑，Encrypt-JDBC即可攔截用戶行爲，並在改造行爲後與數據庫交互。

Encrypt-JDBC將用戶發起的SQL進行攔截，並經過SQL語法解析器進行解析、理解SQL行爲，再依據用戶傳入的脫敏規則，找出須要脫敏的字段和所使用的加解密器對目標字段進行加解密處理後，再與底層數據庫進行交互。ShardingSphere會將用戶請求的明文進行加密後存儲到底層數據庫；並在用戶查詢時，將密文從數據庫中取出進行解密後返回給終端用戶。ShardingSphere經過屏蔽對數據的脫敏處理，使用戶無需感知解析SQL、數據加密、數據解密的處理過程，就像在使用普通數據同樣使用脫敏數據。

脫敏規則

在詳解整套流程以前，咱們須要先了解下脫敏規則與配置，這是認識整套流程的基礎。脫敏配置主要分爲四部分：數據源配置，加密器配置，脫敏表配置以及查詢屬性配置，其詳情以下圖所示：

數據源配置：是指DataSource的配置。

加密器配置：是指使用什麼加密策略進行加解密。目前ShardingSphere內置了兩種加解密策略：AES/MD5。用戶還能夠經過實現ShardingSphere提供的接口，自行實現一套加解密算法。

脫敏表配置：用於告訴ShardingSphere數據表裏哪一個列用於存儲密文數據（cipherColumn）、哪一個列用於存儲明文數據（plainColumn）以及用戶想使用哪一個列進行SQL編寫（logicColumn）。

查詢屬性的配置：當底層數據庫表裏同時存儲了明文數據、密文數據後，該屬性開關用於決定是直接查詢數據庫表裏的明文數據進行返回，仍是查詢密文數據經過Encrypt-JDBC解密後返回。

如何理解用戶想使用哪一個列進行SQL編寫（logicColumn）？

咱們能夠從Encrypt-JDBC存在的意義來理解。Encrypt-JDBC最終目的是但願屏蔽底層對數據的脫敏處理，也就是說咱們不但願用戶知道數據是如何被加解密的、如何將明文數據存儲到plainColumn，將密文數據存儲到cipherColumn。換句話說，咱們不但願用戶知道plainColumn和cipherColumn的存在和使用。因此，咱們須要給用戶提供一個概念意義上的列，這個列能夠脫離底層數據庫的真實列，它能夠是數據庫表裏的一個真實列，也能夠不是，從而使得用戶能夠隨意改變底層數據庫的plainColumn和cipherColumn的列名。或者刪除plainColumn，選擇永遠再也不存儲明文，只存儲密文。只要用戶的SQL面向這個邏輯列進行編寫，並在脫敏規則裏給出logicColumn和plainColumn、cipherColumn之間正確的映射關係便可。

爲何要這麼作呢？答案在文章後面，即爲了讓已上線的業務能無縫、透明、安全地進行數據脫敏遷移。

脫敏處理過程

舉個栗子，假如數據庫裏有一張表叫作t_user，這張表裏實際有兩個字段pwd_plain，用於存放明文數據、pwd_cipher，用於存放密文數據，同時定義logicColumn爲pwd。那麼，用戶在編寫SQL時應該面向logicColumn進行編寫，即INSERT INTO t_user SET pwd = '123'。ShardingSphere接收到該SQL，經過用戶提供的脫敏配置，發現pwd是logicColumn，因而便對邏輯列及其對應的明文數據進行脫敏處理。能夠看出ShardingSphere將面向用戶的邏輯列與面向底層數據庫的明文列和密文列進行了列名以及數據的脫敏映射轉換。以下圖所示：

這也正是Encrypt-JDBC核心意義所在，即依據用戶提供的脫敏規則，將用戶SQL與底層數據表結構割裂開來，使得用戶的SQL編寫再也不依賴於真實的數據庫表結構。而用戶與底層數據庫之間的銜接、映射、轉換交由ShardingSphere進行處理。爲何咱們要這麼作？仍是那句話：爲了讓已上線的業務能無縫、透明、安全地進行數據脫敏遷移。

爲了讓讀者更清晰瞭解到Encrypt-JDBC的核心處理流程，下方圖片展現了使用Encrypt-JDBC進行增刪改查時，其中的處理流程和轉換邏輯，以下圖所示。

5、寫在最後

Apache ShardingSphere針對新業務上線、舊業務改造分別提供了相應的全套脫敏解決方案。因爲篇幅所限，本次分享僅將實現原理和設計思想進行了解讀。如何將脫敏規則、脫敏處理流程與真實業務場景相結合呢？請期待下週的Apache ShardingSphere數據脫敏全解決方案詳解(下)！

歡迎你們在官網瞭解更多內容，在gitHub關注咱們☺！

官網&gitHub

https://shardingsphere.apache...

https://github.com/apache/inc...

招賢納士

職位信息：

https://mp.weixin.qq.com/s/u3DhzAzVURsA8abUALWcLQ

招聘郵箱：

zhangliang@apache.org

• end •

加羣&

關注公衆號