前言
最近有個專案需要對外提供一個介面，提供公網域名進行訪問，而且介面和交易訂單有關，所以安全性很重要；這里整理了一下常用的一些安全措施以及具體如何去實作，
安全措施
個人覺得安全措施大體來看主要在兩個方面，一方面就是如何保證資料在傳輸程序中的安全性，另一個方面是資料已經到達服務器端，服務器端如何識別資料，如何不被攻擊；下面具體看看都有哪些安全措施，
1.資料加密
我們知道資料在傳輸程序中是很容易被抓包的，如果直接傳輸比如通過 http 協議，那么用戶傳輸的資料可以被任何人獲取；所以必須對資料加密，常見的做法對關鍵欄位加密比如用戶密碼直接通過 md5 加密；現在主流的做法是使用 https 協議，在 http 和 tcp 之間添加一層加密層(SSL 層)，這一層負責資料的加密和解密；
2.資料加簽
資料加簽就是由發送者產生一段無法偽造的一段數字串，來保證資料在傳輸程序中不被篡改；你可能會問資料如果已經通過 https 加密了，還有必要進行加簽嗎？資料在傳輸程序中經過加密，理論上就算被抓包，也無法對資料進行篡改；但是我們要知道加密的部分其實只是在外網，現在很多服務在內網中都需要經過很多服務跳轉，所以這里的加簽可以防止內網中資料被篡改；
3.時間戳機制
資料是很容易被抓包的，但是經過如上的加密，加簽處理，就算拿到資料也不能看到真實的資料；但是有不法者不關心真實的資料，而是直接拿到抓取的資料包進行惡意請求；這時候可以使用時間戳機制，在每次請求中加入當前的時間，服務器端會拿到當前時間和訊息中的時間相減，看看是否在一個固定的時間范圍內比如 5 分鐘內；這樣惡意請求的資料包是無法更改里面時間的，所以 5 分鐘后就視為非法請求了；
4.AppId 機制
大部分網站基本都需要用戶名和密碼才能登錄，并不是誰來能使用我的網站，這其實也是一種安全機制；對應的對外提供的介面其實也需要這么一種機制，并不是誰都可以呼叫，需要使用介面的用戶需要在后臺開通 appid，提供給用戶相關的密鑰；在呼叫的介面中需要提供 appid+密鑰，服務器端會進行相關的驗證；
5.限流機制
本來就是真實的用戶，并且開通了 appid，但是出現頻繁呼叫介面的情況；這種情況需要給相關 appid 限流處理，常用的限流演算法有令牌桶和漏桶演算法；
6.黑名單機制
如果此 appid 進行過很多非法操作，或者說專門有一個中黑系統，經過分析之后直接將此 appid 列入黑名單，所有請求直接回傳錯誤碼；
7.資料合法性校驗
這個可以說是每個系統都會有的處理機制，只有在資料是合法的情況下才會進行資料處理；每個系統都有自己的驗證規則，當然也可能有一些常規性的規則，比如身份證長度和組成，電話號碼長度和組成等等；
如何實作
以上大體介紹了一下常用的一些介面安全措施，當然可能還有其他我不知道的方式，希望大家補充，下面看看以上這些方法措施，具體如何實作；
1.資料加密
現在主流的加密方式有對稱加密和非對稱加密；
對稱加密：對稱密鑰在加密和解密的程序中使用的密鑰是相同的，常見的對稱加密演算法有 DES，AES；優點是計算速度快，缺點是在資料傳送前，發送方和接收方必須商定好秘鑰，然后使雙方都能保存好秘鑰，如果一方的秘鑰被泄露，那么加密資訊也就不安全了；
非對稱加密：服務端會生成一對密鑰，私鑰存放在服務器端，公鑰可以發布給任何人使用；優點就是比起對稱加密更加安全，但是加解密的速度比對稱加密慢太多了；廣泛使用的是 RSA 演算法；
兩種方式各有優缺點，而 https 的實作方式正好是結合了兩種加密方式，整合了雙方的優點，在安全和性能方面都比較好；
對稱加密和非對稱加密代碼實作，jdk 提供了相關的工具類可以直接使用，此處不過多介紹；
2.資料加簽
資料簽名使用比較多的是 md5 演算法，將需要提交的資料通過某種方式組合和一個字串，然后通過 md5 生成一段加密字串，這段加密字串就是資料包的簽名，可以看一個簡單的例子：
str：引數1={引數1}&引數2={引數2}&……&引數n={引數n}$key={用戶密鑰};
MD5.encrypt(str);
注意最后的用戶密鑰，客戶端和服務端都有一份，這樣會更加安全；
3.時間戳機制
解密后的資料，經過簽名認證后，我們拿到資料包中的客戶端時間戳欄位，然后用服務器當前時間去減客戶端時間，看結果是否在一個區間內；
4.AppId 機制
生成一個唯一的 AppId 即可，密鑰使用字母、數字等特殊字符隨機生成即可；生成唯一 AppId 根據實際情況看是否需要全域唯一；但是不管是否全域唯一最好讓生成的 Id 有如下屬性：
? 趨勢遞增：這樣在保存資料庫的時候，使用索引性能更好；
? 資訊安全：盡量不要連續的，容易發現規律；
? 關于全域唯一 Id 生成的方式常見的有類 snowflake 方式等；
5.限流機制
常用的限流演算法包括：令牌桶限流，漏桶限流，計數器限流；
1.令牌桶限流 令牌桶演算法的原理是系統以一定速率向桶中放入令牌，填滿了就丟棄令牌；請求來時會先從桶中取出令牌，如果能取到令牌，則可以繼續完成請求，否則等待或者拒絕服務；令牌桶允許一定程度突發流量，只要有令牌就可以處理，支持一次拿多個令牌；
2.漏桶限流 漏桶演算法的原理是按照固定常量速率流出請求，流入請求速率任意，當請求數超過桶的容量時，新的請求等待或者拒絕服務；可以看出漏桶演算法可以強制限制資料的傳輸速度；
3.計數器限流 計數器是一種比較簡單粗暴的演算法，主要用來限制總并發數，比如資料庫連接池、執行緒池、秒殺的并發數；計數器限流只要一定時間內的總請求數超過設定的閥值則進行限流；
具體基于以上演算法如何實作，Guava 提供了 RateLimiter 工具類基于基于令牌桶演算法：
RateLimiter rateLimiter = RateLimiter.create(5);
以上代碼表示一秒鐘只允許處理五個并發請求，以上方式只能用在單應用的請求限流，不能進行全域限流；這個時候就需要分布式限流，可以基于 redis+lua 來實作；
6.黑名單機制
如何為什么中黑我們這邊不討論，我們可以給每個用戶設定一個狀態比如包括：初始化狀態，正常狀態，中黑狀態，關閉狀態等等；或者我們直接通過分布式配置中心，直接保存黑名單串列，每次檢查是否在串列中即可；
7.資料合法性校驗
合法性校驗包括：常規性校驗以及業務校驗；
常規性校驗：包括簽名校驗，必填校驗，長度校驗，型別校驗，格式校驗等；
業務校驗：根據實際業務而定，比如訂單金額不能小于 0 等；
總結
本文大致列舉了幾種常見的安全措施機制包括：資料加密、資料加簽、時間戳機制、AppId 機制、限流機制、黑名單機制以及資料合法性校驗；不過設計出了介面，也需要保持對介面的監控，才能更加保證介面的安全性，市面上有很多開源的API網關工具，我用的是Eolinker，國產的，功能也比較完善，
官網：www.eolinker.com
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/245078.html
標籤：其他