01. 聊 啥 關註“一猿小講”的都知道，我們之前分享過應用架構、應用監控、日誌歸集以及程式員日常內心的那些小揪揪，幾乎成了小講、雜談的一畝三分地。 說實話，挺神奇，我也不知道每次會給大家帶來什麼驚喜。 今天的分享也不例外，你們肯定也意想不到，今天我分享的主題居然是：矛與盾，如何做好系統之盾；說人話 ...
01. 聊 啥
關註“一猿小講”的都知道，我們之前分享過應用架構、應用監控、日誌歸集以及程式員日常內心的那些小揪揪，幾乎成了小講、雜談的一畝三分地。
說實話，挺神奇，我也不知道每次會給大家帶來什麼驚喜。
今天的分享也不例外，你們肯定也意想不到，今天我分享的主題居然是：矛與盾，如何做好系統之盾；說人話，也就是“聊聊安全架構模型”。
吃個核桃，坐穩，扶好，我們開始。
02. 聊 開
一個應用架構的設計肯定離不了安全模塊，離開了安全模塊設計，相當於系統在裸奔，尤其是金融系統。
站在用戶的角度。當我們打開 APP 時，點擊購買按鈕時，頁面會提示購買成功 or 購買失敗。站在用戶的角度，功能體驗就是這麼簡單。大道至簡，簡單就是美。
站在系統的角度。司空見慣，我們認為 APP 就是終端，當用戶點擊購買按鈕時，會請求接入層（也認為是安全層），接入層會記錄用戶關鍵行為，然後轉發業務報文請求業務系統進行業務處理。
如上圖所示，把系統劃分為終端 APP、接入層、業務系統。生產上這麼跑的肯定不在少數。
但是有沒有考慮過，終端 APP 發過來的報文可信性是較低的，如果報文發生惡意篡改該怎麼辦？
我們會想到可以針對通訊報文采用 RSA 加密。但是如果只有報文的 RSA 加密，那麼所有請求的加密規則都是一樣的，所以考慮到雙保險，那不妨每次請求的時候動態生成 AES Key，先把報文采用動態生成的 AES Key 進行 AES 加密，然後把 AES Key 採用 RSA 加密傳輸。此時的架構如下圖所示。
此時會存在一個問題，如果模擬發起報文的時候，敏感欄位（手機號、姓名、身份證等）發生篡改，是不是會張冠李戴、不可思議？
考慮到前面的設計，那麼不妨再針對敏感欄位，再進行一道 RSA 加密。此時的架構設計確變成瞭如下（著重關註紅色部分）。
到此步，架構設計上肯定比裸奔的系統，安全性提高不少，攻擊的門檻也提高了。
但是聰明的你們，有沒有發現通訊證書、敏感欄位證書（也就是 RSA 公鑰）都是預置在 APP 服務中，那麼是否可以設計出一個密鑰管理的模塊，這樣可以針對證書提供拉取，也可以隨時設置證書過期、下線等操作。
那麼此時的架構設計變成了什麼樣子呢？（著重關註下圖紅色部分變化）。
如果跟著我的思路，走到這一步的你們，肯定會發現如下兩點：
接入層，需要採用 RSA 解密報文加密的 AES Key；
業務系統，需要採用 RSA 解密報文中的敏感欄位；
那麼這樣設計，會引起證書的私鑰分散、且不容易管理。不過如上圖所示，既然有了密鑰管理的系統，那麼不妨把解密的動作，都統一交給密鑰管理系統。
這樣一來，接入層、業務系統就無需關心密鑰相關的事情，大概率的提高了系統之間的可信性。
那麼此時的架構又變成了什麼樣子呢？（著重關註下圖紅色部分變化）。
03. 聊畢
道高一尺魔高一丈，系統安全就像矛與盾，有矛就有盾，在鑄造好盾的前提下，也提倡大家都做一個有職業操守的程式員。
結合個人的理解與實際應用，到這安全架構模型也聊個八九不離十啦，不知道聰明的你們 get 到了多少？
寄語寫最後：技不壓身，學比不學強，養成學習的習慣，請不要站在原地。
