加密服務設計

爲何要作加密服務，最近GDPR對我的數據查的很嚴，若是違反規定，罰款是很大的，大部分開發的同窗是沒太多安全意識的，說不定哪天由於系統漏洞致使數據被泄露出去了。

爲了不繫統漏洞致使敏感數據被泄露，須要對源頭即數據庫的數據進行加密，加密以後即便因系統漏洞致使被脫庫，泄露的也是加密數據，不是用戶的真實數據。

加密範圍很大，包括數據庫、緩存、其它存儲中間件，還有傳輸過程，爲了簡化問題，咱們今天只講數據庫字段存取的加密。

另外爲了簡化問題，咱們今天所講方案都是基於如下的用戶表設計：
字段 類型 說明
id int 主鍵
name varchar(50) 用戶名稱
mobile varchar(50) 手機

回到正題，若是要設計一個加密服務，你們會怎麼設計呢？
任何一個系統的設計都必需要代入業務場景中，咱們從用例開始分析具體的業務場景：

用例分2類：
一類是針對業務系統的，每一個業務系統的需求就是加密和解密。

數據庫字段在其上的操做有：查詢，添加、更新、刪除，對於加密服務來講，須要加密指定的字段，而且能夠對其進行解密；另外針對加密字段還能夠查詢，這個是一個難點，下面再講。

對於系統管理員，也就是安全的同窗來講須要管理哪些應用在加密，即須要頒發密鑰後，應用才能夠加密；另外出於安全考慮，還須要按期變動應用密鑰。

另外一個就是解密的受權管理，即應用A加了密以後，不是全部應用均可以解密的，須要管理加密方和解密方的受權關係。

加密算法選擇

由於還要解密，能夠選擇強度比較高的對稱加密算法，如AES256等，這裏不專門講加密算法，有興趣的同窗能夠百度下。

數據的存放格式設計

關鍵的問題來了，加密後的數據怎麼存， 直接用加密算法，如AES256加密後存放到數據庫字段就好了嗎？

 實際的場景是加密方可能有多個，即加密的內容，多是應用A，也多是應用B加密的，系統上要能區別出來；

 另外就是密鑰的變動，應用A的密鑰會變，不一樣時期多是不同的，一個表的數據可能由多個密鑰加密的，即上面的用戶表，可能第一行的mobile是由id爲1的密鑰加密的，而第二行是由id爲2的密鑰加密的，這2種狀況都須要能被解密出來 。

因此加密字段不只要存放加密後的內容，還要存放一些元信息：哪一個應用加密的，哪一個密鑰加密的。

相關表設計
應用表

字段 類型 說明
id int 主鍵
name varchar(50) 應用名稱

應用密鑰表

字段 類型 說明
id int
自增主鍵
app_id int 應用id
key varchar(64) 密鑰
version varchar(4) 版本號
algrithom varchar(64) 加密算法

加密內容格式，咱們建議要包含上面信息，便可以把應用密鑰表的id和加密後的內容存放一塊兒，如：密鑰id + ^ + 加密內容。 

 解密時，先解析獲得密鑰表的id和加密內容，根據id獲得密鑰，而後進行解密，這樣每次變動密鑰以後，歷史數據不受影響。

加密字段查詢

一個字段加密以後，還要根據其查詢，這樣的場景應該仍是很多的，像用戶表的手機號。

咱們首先說下問題在哪裏，在某個時間密鑰換了，即user表的mobile可能被N個密鑰加密，即總共2行數據，可能第一行是用密鑰A加密的，第二行倒是用密鑰B加密的，先將原文加密去查詢的話，用哪一個密鑰呢？

這裏的問題是，由一個輸入得不到一個肯定的輸出，因此咱們的問題就是如何由一個肯定的輸入在任什麼時候間獲得不變的輸出。

一、等值查詢
  最簡單的方案就是加字段，即在user表再加個mobile_hash字段，這裏存放將mobile字段hash後的值，hash算法能夠選md5或sha256，這樣在任什麼時候候由輸入能夠獲得一個肯定的輸出；但這裏有個風險，md5算法可能碰撞，根據HASH查詢出來以後可能不是輸入的手機號，業務上須要解密下是否是和原文相等。

  固然也能夠不加字段，能夠將hash後的值存放到mobile的前面，每次查詢用like進行左前綴匹配。


 二、須要作like查詢
      這裏方案比較複雜，也比較燒腦，有一篇論文講的比較詳細，有興趣的同窗能夠看下：https://www.jiamisoft.com/blog/5961-kuaisuchaxunshujukujiami.html 。