開放平臺如何設計安全的對外接口
[提前聲明]
文章由作者:張耀峯 結合自己生產中的使用經驗整理,最終形成簡單易懂的文章
寫作不易,轉載請註明,謝謝!
大數據代碼案例地址: https://github.com/Mydreamandreality/sparkResearch
場景
開放平臺需要提供對外的接口，保障數據安全和客戶真實性
- 1、傳輸的數據加密
- 2、客戶端的身份鑑別
- 3、簽名機制防止數據被篡改
- 4、時間戳機制
- 5、限流、降權機制
- 6、黑名單
通過以上的設計，可以構建出一個基本的安全架構
詳細設計
- 1、傳輸的數據加密
如果大家使用過wireshark或者fiddler之類的抓包工具，就知道數據在傳輸的過程中是很容易被抓包的，如果我們使用http協議來傳輸我們的數據，就跟裸奔是一樣的，明文數據全部暴露在了外面，所以成熟的解決方案是應該使用HTTPS協議傳輸，在我們的http層和tcp層增加SSL加密層，對傳輸數據進行加解密，甚至一些不需要明文處理的數據，可以直接通過hash+鹽或者其它不可逆的算法來對數據進行傳輸，驗證只需要對比hash值即可
這裏的不可逆也不是絕對的，一般來講只能提高逆向的難度，比如彩虹表攻擊，舉個栗子: 一個密文你需要十年的時間才能逆向出來明文，對於防護方來說，這是可以接受的，所以在傳統的安全對抗中，我們不能完全的低檔攻擊方，那這個時候換個思路，你可以攻破我，但你最少需要十年的時間
彩虹表攻擊:
彩虹表是一個用於加密散列函數逆運算的預先計算好的表, 爲破解密碼的散列值（或稱哈希值、微縮圖、摘要、指紋、哈希密文）而準備
- 2、客戶端鑑權
我們隨便找一個開放平臺，在調用開放平臺接口之前都需要先登錄，然後再申請Appid和AppSerect，Appid的作用就是標識不同的租戶，AppSerect是傳輸中實現加密功能的密鑰，通過Appid和AppSerect生成對應的access_token傳輸給開放平臺，開放平臺服務端進行相關的驗證，例如：驗證該用戶是否是黑名單用戶，是否有權限使用該接口等等
釘釘開放平臺中的做法是需要appid和appserect請求生成access_token，這個value由釘釘直接寫入到租戶業務系統的數據庫中，租戶請求需要攜帶access_token，有效時長爲二十分鐘，過期需要租戶重新請求新的token
- 3、簽名機制防止數據篡改
外網有https，其實數據是沒必要再次簽名的，但是我們要考慮到數據傳輸不只是經過外網，還有內網，在內網傳輸這個過程中的安全保障就需要簽名機制
之前和釘釘合作開發的時候，是我們提供接口給釘釘客戶端使用，所以需要我們用appid來申請公鑰，釘釘用本次申請的公鑰所對應的私鑰對數據做數字簽名，我們接收到請求後用公鑰進行驗籤
- 4、時間戳機制
這樣設想一下，我們的數據傳輸都是密文，也有數字簽名來保障數據安全性，但是我抓到你的包後，我不管你的傳輸內容是什麼，我可以直接複用本次請求，來拿到你的響應內容，所以我們需要額外的增加時間戳機制，來驗證本次的請求是否爲過期請求
時間戳機制可以和數字簽名配合使用，例如在請求中增加RequestTimestamp字段，增加數字簽名防止篡改，服務端收到租戶的請求後公鑰驗籤，進行時間戳的驗證，如果該請求是當前時間五分鐘之前的，則拒絕訪問
- 5、限流、降權
訪問我們的平臺是需要用appid換取access_token的，這一步就可以過濾掉非正常用戶的請求，但如果是正常用戶，在一段時間內出現了頻繁調用接口的行爲，也需要做降權或者限流的策略
使用令牌桶算法或者藉助Redis來實現限流算法，針對同一appid的限流
- 6、黑名單
如果正常用戶產生了觸發閾值的非法操作（比如:每分鐘5次的惡意請求），此時我們應該增加黑名單機制，把該租戶的appid加入至黑名單，下次請求直接拒絕，返回業務拒絕碼