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 到了多少？
寄語寫最后：技不壓身，學比不學強，養成學習的習慣，請不要站在原地，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/5993.html
標籤：架構設計
上一篇：聊聊應用系統架構的0到1
下一篇：中臺MongoDB應用