【進階之路】基於ShardingSphere的線上業務數據脫敏解決方案

由於某種緣由，須要去考慮數據脫敏的問題，可是既不想由於脫敏而影響數據的操做性，又須要對一些敏感信息進行可靠的保護。所以，正好解決了手頭問題的我就開始研究各類脫敏手段、尋求最適合目前現狀的脫敏解決方案。

對於已經上線的業務，如何在不修改業務邏輯、業務SQL的狀況下，透明化、安全低風險地實現無縫進行脫敏改造呢？

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

目前已上線業務，以前一直將明文存儲在數據庫中。由於某些緣由須要對已上線業務進行脫敏整改。爲了解決這個問題，有三個問題須要考慮：

• 一、 如何對大量的歷史數據須要脫敏處理。

• 二、 如何能在不改動業務SQL和邏輯狀況下，將新增數據進行脫敏處理，並存儲到數據庫。

• 3 、如何較爲安全地實現業務系統在明文與密文數據間的遷移。

對靜態業務脫敏有專業的脫敏手段，包括一些脫敏工具、亦或是使用SPL腳本或者存儲過程對存量數據進行脫敏。因此，咱們此次主要研究如何不影響業務邏輯進行增量數據脫敏。

1、數據脫敏的原理

shardingsphere關於脫敏的官方文檔

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

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

2、脫敏的配置

咱們這邊能夠直接用yaml配置來解釋脫敏規則的配置。

一、數據源配置

是指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

二、加密器配置

是指使用什麼加密策略進行加解密。目前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

三、脫敏表配置

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

tables:
        t_user:
          columns:
            passowrd:  #logicColumn
              plainColumn: passowrd  #plainColumn
              cipherColumn: newpassowrd  #cipherColumn
              encryptor: encryptor_aes  #加密器配置

四、查詢屬性的配置

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

props:
      # 打印SQL
      sql.show: true
      check:
        table:
          metadata: true
          # 是否在啓動時檢查分表元數據一致性
          enabled: true
      query:
        with:
          cipher:
            # 選擇使用明文或者密文字段進行查詢，true爲密文
            column: true

當配置好了這些信息後，就能夠完成對數據的加密。

五、脫敏處理過程

如今咱們利用以前作好的配置來進行一次簡單的測試

測試完畢，咱們能夠看出，經過用戶提供的脫敏配置，數據找到了logicColumn，因而對邏輯列及其對應的明文數據進行脫敏處理。能夠看出ShardingSphere將面向用戶的邏輯列與面向底層數據庫的明文列和密文列進行了列名以及數據的脫敏映射轉換。

瞭解了數據新增的邏輯，那麼數據查詢、修改也是類似的原理。同時，查詢的時候也能夠選擇使用明文仍是密文字段進行查詢。

3、新業務與舊業務

一、新業務

若是不涉及到舊業務改造，就能夠免去plainColumn字段，直接使用cipherColumn便可。

二、舊業務

已上線的任務，因爲數據庫存在大量的明文數據，如何對存量數據進行清洗，同時對新數據進行加密，在兩套系統中無縫銜接，纔是咱們要解決的問題。

一、任務遷移前

數據清洗以前，咱們使用我以前的配置的內容，增刪改查繼續使用明文，在數據庫只是新增字段存儲密文數據，在對存量數據進行清洗以前不要擅自行動。

二、任務遷移中

新增的數據已被Encrypt-JDBC將密文存儲到密文列，明文存儲到明文列；歷史數據被業務方自行加密清洗後，將密文也存儲到密文列。也就是說如今的數據庫裏即存放着明文也存放着密文。同時咱們隨時能夠經過配置來更換查詢出的數據是明文仍是密文。

在校驗完系統的可靠性和數據的正確性以前，不要直接刪掉明文數據，以防萬一。

二、任務遷移後

因爲安全審計部門要求，業務系統通常不可能讓數據庫的明文列和密文列永久同步保留，咱們須要在系統穩定後將明文列數據刪除。
以後，咱們的脫敏表配置也能夠進行改動了。（固然，特殊狀況也能夠留下明文數據進行備份，這個就要考慮到實際狀況了）

tables:
        t_user:
          columns:
            passowrd:  #logicColumn
              cipherColumn: newpassowrd  #cipherColumn
              encryptor: encryptor_aes  #加密器配置

4、選擇ShardingSphere進行脫敏處理的理由

• 一、ShardingSphere提供了自動化和透明化數據脫敏過程，咱們無需關注脫敏中間實現細節。
• 2 提供多種內置、第三方(AKS)的脫敏策略，僅需簡單配置便可使用。
• 三、提供脫敏策略API接口，用戶可實現接口，從而使用自定義脫敏策略進行數據脫敏。
• 四、支持切換不一樣的脫敏策略。
• 五、針對已上線業務，可實現明文數據與密文數據同步存儲，並經過配置決定使用明文列仍是密文列進行查詢。可實如今不改變業務查詢SQL前提下，已上線系統對加密先後數據進行安全、透明化遷移。

固然，使用脫敏功能+分庫分表功能，部分特殊SQL不支持，官方也提供了SQL規範供以查詢規範地址

你們好，我是練習java兩年半時間的南橘，下面是個人微信，須要以前的導圖或者想互相交流經驗的小夥伴能夠一塊兒互相交流哦。