前言
日常開發中少不了和第三方服務進行交互，我們經常會提供對外接口給第三方服務調用，這種接口是直接在公網暴露給第三方的，接口安全性是必須要考慮的，接口總不能在公網上直接裸奔吧。這裏和大家一起總結下公網接口安全性問題。安全措施大體來看主要在兩個方面，一方面就是如何保證數據在傳輸過程中的安全性，另一個方面是數據已經到達服務器端，服務器端如何識別數據，如何不被攻擊；下面具體看看都有哪些安全措施。
數據加密
我們知道數據在傳輸過程中是很容易被抓包的，如果直接通過http協議傳輸，用戶傳輸的數據可以被任何人獲取；所以必須對數據加密，常見的做法對關鍵字段加密比如用戶密碼直接通過md5加密；現在主流的做法是使用https協議，在http和tcp之間添加一層加密層(SSL層)，這一層負責數據的加密和解密。現在主流的加密方式有對稱加密和非對稱加密。
對稱加密：對稱密鑰在加解密過程中使用的密鑰是相同的，常見的對稱加密算法有DES，AES；優點是計算速度快，缺點是在數據傳送前，發送方和接收方必須商定好祕鑰，然後使雙方都能保存好祕鑰，如果一方的祕鑰被泄露，那麼加密信息也就不安全了。
非對稱加密：服務端會生成一對密鑰，私鑰存放在服務器端，公鑰可以發佈給任何人使用；優點就是比起對稱加密更加安全，但是加解密的速度比對稱加密慢太多了；廣泛使用的是RSA算法。兩種方式各有優缺點，而https的實現方式正好是結合了兩種加密方式，整合了雙方的優點，在安全和性能方面都比較好。
數據加簽
數據加簽就是由發送者產生一段無法僞造的數字串，來保證數據在傳輸過程中不被篡改；你可能會問數據如果已經通過https加密了，還有必要進行加簽嗎？數據在傳輸過程中經過加密，理論上就算被抓包，也無法對數據進行篡改；但是我們要知道加密的部分其實只是在外網，現在很多服務在內網中都需要經過很多服務跳轉，比如說微服務中各個服務內部的回調請求，我們是直接走的內網IP,這種回調請求是不走https的，所以這裏的加簽可以防止內網中數據被篡改。數據簽名使用比較多的是md5算法，將需要提交的數據通過某種方式組合和一個字符串，然後通過md5生成一段加密字符串，這段加密字符串就是數據包的簽名，可以看一個簡單的例子：
str：參數1={參數1}&參數2={參數2}&……&參數n={參數n}$key={用戶密鑰};
MD5.encrypt(str);
時間戳機制
數據是很容易被抓包的，經過如上的加密，加簽處理，就算拿到數據也不能看到真實的數據；但是有不法者不關心真實的數據，而是直接拿到抓取的數據包進行惡意請求；這時候可以使用時間戳機制，在每次請求中加入當前的時間，服務器端會拿到當前時間和消息中的時間相減，看看是否在一個固定的時間範圍內比如5分鐘內；這樣惡意請求的數據包是無法更改裏面時間的，所以5分鐘後就視爲非法請求了。
AppId機制
大部分網站基本都需要用戶名和密碼才能登錄，並不是誰都能使用我的網站，這其實也是一種安全機制；對應的對外提供的接口其實也需要這麼一種機制，並不是誰都可以調用，需要使用接口的用戶需要在後臺開通appid，提供給用戶相關的密鑰；在調用的接口中需要提供appid+密鑰，服務器端會進行相關的驗證。
生成一個唯一的AppId，密鑰使用字母、數字等特殊字符隨機生成即可；生成唯一AppId根據實際情況看是否需要全局唯一；但是不管是否全局唯一最好讓生成的Id儘量不要連續的，容易發現規律，常見的有類snowflake方式等。
限流機制
本來就是真實的用戶，並且開通了appid，但是出現頻繁調用接口的情況；這種情況需要給相關appid限流處理，常用的限流算法有令牌桶和漏桶算法；具體的限流機制可以參見這篇文章分佈式服務限流實戰。
黑、白名單機制
如果此appid進行過很多非法操作，或者說專門有一箇中黑系統，經過分析之後直接將此appid列入黑名單，所有請求直接返回錯誤碼；或者我們可以列舉了一個IP白名單，只有在白名單列表中的IP才能訪問我們的接口，具體白名單可以在Nginx配置文件中配置，也可以在服務內部的配置文件中配置，在服務接口邏輯中做白名單匹配。
數據合法性校驗
這個可以說是每個系統都會有的處理機制，只有在數據是合法的情況下才會進行數據處理；每個系統都有自己的驗證規則，當然也可能有一些常規性的規則，比如身份證長度和組成，電話號碼長度和組成等等。
總結
上面這些只是從大體概念上講解接口安全性，能讓大家在設計對外接口的時候考慮這些問題。具體的設計細節，我們還需要結合項目中的實際場景進行設計。最近肺炎比較嚴重，走親戚不方便，還是在家多學習總結，不給醫護人員添亂，加油武漢！