編輯導語：現如今互聯網普及率很高，大家都會在網上的各種平臺進行注冊，這時候有一定的信息泄露風險，所以在前期開發時會設置一些防范策略；本文作者分享了關于搭建API安全預警平臺的方法，我們一起來看一下。

認證服務應用的越來越廣泛，比如：驗證碼等這些都是通過接口能力服務完成；之前負責過的高安全級別的認證平臺在建設的時候，整理了一些安全防范策略。

如下是一些工作的總結：

一般來說，大公司都會有專門負責數據安全的部門或團隊對安全問題進行排查，亦或者有經驗的研發會在開發時考慮到，然后主動提出并解決。

對于某些風險其風控策略還是需要產品經理提出的。

一、為什么要防范風險？

對于用戶：

• 用戶頻繁騷擾：接口被頻繁調用，信息不斷下發到用戶；比如：短信下發類接口（驗證碼、營銷等）。
• 用戶敏感信息被盜：第一種方式：某些數據在未授權的情況下被獲??；第二種方式：代碼泄露后，敏感信息泄露，個人信息、實名信息、賬號密碼等。
• 用戶無法正常訪問：接口被頻繁請求，網絡請求堵塞。
• 用戶訪問數據顯示異常：接口參數遭攻擊者篡改。

對于公司：

• 用戶投訴：用戶的風險問題很容易導致用戶投訴。
• 大量費用：頻繁調用接口導致大量接口請求，刷量導致高額的費用，有些接口的調用還是非常昂貴的。
• 公司業務受損：服務器被攻擊，客戶端會有風險導致癱瘓。
• 服務器資源消耗：大量調用接口及接口傳輸上限，加大服務器性能消耗。

二、風險防范方式

api安全問題主要有數據的傳輸安全問題、數據安全問題、服務器安全問題。

1. 傳輸安全

接口傳輸風險可能會導致接口被隨意調取、傳輸劫持等。

為應對傳輸風險，可以做如下防范：

1）授權訪問（未授權、越權）

• 平臺之間的接口：需要使用一些身份認證機制，比如：APPID或APPKey和APPSecret、token。
• 前后端接口調用：不要全部按前端傳入的次數進行處理，要由后端做二次校驗，嚴格對權限進行控制；后端需要自動二次獲取用戶的相關權限信息。以此減少驗證權限環節存在的缺陷。

2）數據截取被黑：

• 在安全的網絡環境下進行傳輸：內網、專線
• HTTPS都懂的。
• 數據加密，比如敏感信息加密脫敏。

3）傳輸頻次（重放攻擊）

• 一次性token機制，token使用一次后就失效。
• 對接口調用頻率和次數限制：比如驗證碼60s內只能下發一次。

4）DDOS攻擊指：處于不同位置的多個攻擊者同時向一個或數個目標發動攻擊，或者一個攻擊者控制了位于不同位置的多臺機器并利用這些機器對受害者同時實施攻擊。

• 建立IP白名單；
• 流量清洗：將正常流量和惡意流量區分開，正常的流量則回注客戶網站。

5）數據篡改：篡改接口報文內容，再次請求接口。

通過簽名的方法防治數據篡改：請求/響應報文簽名，對應端內進行驗簽。簽名算法有哈希算法、MD5。

2. 數據安全問題

主要是敏感信息泄漏：對于敏感信息需要進行脫敏，且不能依賴前端脫敏，需要由后端對數據進行脫敏。

3. 服務器安全問題：

主要是服務器資源消耗問題：通過接口對大文件處理消耗服務器資源。

• 對上傳的文件大小、格式限制。
• 接口頻率、次數限制。
• 限制接口響應內容大小。

三、產品經理搭建安全預警平臺

為保障平臺和終端用戶的正常運行，可以通過監控預警平臺，對接口管控，防止業務遭受攻擊導致平臺能力短時間資源消耗過高，導致能力故障。

平臺可以通過對如下指標進行監控：接口調用頻率、接口調用準確率。

1. 接口調用頻率和準確率預警

判斷標準假設：

• 假設1：TPS調用頻率可取近7天平均的請求的數量作為正常數量的基準線。
• 假設2：接口每天的調用頻率都是有規律的，可分為：早中晚，早（0點-8點：低頻）、中（8點-18點：高頻）、晚（18點-24點：高頻）
• 假設3：正確率低于某一值時，可直接識別為高危問題：被攻擊，直接將接口停用，對應業務方設為黑名單；正確率在某一區間時，識別為：可能被攻擊，則需預警。

通過如上假設，可判斷出頻率和準確率的數據對應反映的接口調用情況。因此基于如上假設可建設一套預計平臺。

核心功能邏輯：

1）后臺可配置發生預警的限制：

• TPS按基準線的某些倍數/某一定值，則發生預警/接口調用拉黑，可設置拉黑定時器。（拉黑某一時間段）
• 準確率可設置某一百分百，發送預警/接口調用拉黑，可設置拉黑定時器。（拉黑某一時間段）

2）黑白名單：對于某些業務線放入黑名單，則無法使用接口，放入白名單則可無視預警，正常調用。

3）其他基礎數據：

TPS總數、篩選器、可視化插件（餅圖/線形圖）：

2. 通過賬號、IP控制頻率

通過用戶賬號、IP控制頻率，可以控制每分鐘調用次數、每小時調用次數等。根據具體場景確定策略。

本文由 @?liyo龍 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議。