微服務：API網關在API安全中的作用

當從單體應用程序切換到微服務時，來自客戶端的行為不能與以前一樣，單體架構客戶端只有一個入口點到應用程序。

現在，在使用微服務時，客戶端必須處理來自微服務體系結構的所有複雜性，比如從各種服務聚合數據、維護多個端點、客戶端和伺服器之間增加的動態性以及對每個服務進行單獨的身份驗證。

客戶端對微服務的依賴直接使重構服務變得困難。一種直觀的方法是將這些服務隱藏在一個新的服務層後面，並提供針對每個客戶端的APIs。

這個聚合器服務層也稱為API網關，它是解決這個問題的一種常見方法。

基於API網關的微服務體系架構模式

所有來自客戶端的請求首先通過API網關。然後將請求路由到適當的微服務。

典型的API網關包括:

1、安全性(身份驗證和潛在的授權)

2、管理訪問配額和節流

3、緩存(代理語句和緩存)

4、API組成和處理

5、路由(可能是處理)到「內部」API

6、API健康監測(性能監測)

7、版本控制(可能自動化)

API 網關的優勢

1、在單獨一個地方實現

2、簡化了API源代碼本身，因為這些關注點是外部化的

3、提供API的中心和獨特視圖，因此更可能允許一致的策略

API 網關的不足

1、可能的單點故障或瓶頸

2、複雜性風險，因為所有API規則都在一個地方

3、鎖定和遷移的風險可能並不簡單

API 增長創造了機會

要了解APIs的飛速增長，只需看看ProgrammableWeb的統計數據即可，該網站自2005年以來一直在跟蹤公開發布的APIs。當時，只列出了大約100個APIs。今天，有超過10000個公開的APIs。

這種增長正日益支撐著一個依賴於用戶數據寶庫的經濟體。據報道，Salesforce.com每年30億美元的營收中有50%以上是通過其api實現的，而Expedia每年20億美元的營收中有近90%是通過其api實現的。

公司通過以各種方式計量API及其背後的資源獲取API收益。例如，Twitter、Facebook和其他公司提供基於廣告的API，允許基於報告和分析的定向廣告，但廣告代理和其他品牌必須為訪問這些API付費。

API網關在安全性中的角色:Identity and Access

訪問控制是API網關技術的頭號安全驅動程序，它充當各種各樣的管理器，以便組織可以管理誰可以訪問API，並建立關於如何處理數據請求的規則。

訪問控制幾乎總是擴展到建立其他政策，包括對來自某些來源的API調用的費率限制，甚至通過API訪問所有或某些資源的付費要求。

When all traffic is routed through a gateway, IT security experts feel more confident that they have their finger on the pulse of an organization.

API網關的訪問控制功能通常從身份驗證機制開始，以確定任何API調用的實際源。目前，最流行的網關是OAuth，它充當訪問基於web的資源的中介，而不向服務公開密碼，並保留了基於鍵的身份驗證，以供企業承擔丟失數據的風險，因為很難保證密鑰的完全機密性。

Message Security

網關是將所有API事務通過單個通道路由的好方法，用於評估、轉換和保護跨組織的消息。當所有通信都通過網關路由時，IT安全專家就會更有信心掌握組織的信息安全。

API網關可以在內部服務之間引入消息安全性，使內部服務更安全，並在加密的服務之間來回傳遞消息。

忽略適當的身份驗證——即使使用了傳輸層加密(TLS)——也會導致問題。例如，在API請求中有一個有效的行動電話號碼，任何人都可以獲得個人電子郵件地址和設備識別數據。行業標準的強身份驗證和授權機制(如OAuth/OpenIDConnect和TLS)非常重要。

威脅保護

沒有威脅保護，API網關、API及其集成伺服器的本機服務基本上是不安全的。這意味著潛在的黑客、惡意軟體或任何匿名的局外人都可以很容易地嘗試傳播一系列攻擊，比如DDoS或SQL注入。

API是企業與世界進行數字化連接的門戶。不幸的是，有些惡意用戶的目標是通過注入意外的命令或表達式來刪除、刪除、更新甚至創建api可用的任意數據來訪問後端系統。

例如，在2014年10月，Drupal宣布了一個SQL注入漏洞，允許攻擊者訪問資料庫、代碼和文件目錄。攻擊非常嚴重，攻擊者可能從客戶的網站上複製了所有數據。注入威脅有多種類型，但最常見的是SQL注入、RegExInjection和XML注入。不止一次，我們看到api在沒有威脅保護的情況下運行——這並不罕見。

日誌記錄

許多API開發人員對所有成功請求使用200，對所有失敗使用404，對某些內部伺服器錯誤使用500，在某些極端情況下，在詳細的堆棧跟蹤之上，在正文中使用200，並帶有失敗消息。當堆棧跟蹤以包名、類名、框架名、版本、伺服器名和SQL查詢的形式揭示底層設計或體系結構實現時，它可能成為惡意用戶的信息泄漏。

返回一個「平衡的」錯誤對象是一個很好的實踐，它具有正確的HTTP狀態代碼、最少的必需錯誤消息，並且在錯誤條件下沒有堆棧跟蹤。這將改進錯誤處理並保護API實現細節不受攻擊者的攻擊。

API網關可用於將後端錯誤消息轉換為標準化消息，使所有錯誤消息看起來相似;這也消除了後端代碼結構的暴露。

白名單和Whitelist-Allowable方法

考慮到IP地址級別的API流量，應該有一個已知的設備、伺服器、網路和客戶機IP地址列表。根據網路的緊密程度，這個列表的大小會有所不同。

rest式服務通常允許多個方法訪問該實體上的不同操作的給定URL。例如，GET請求可能讀取實體，而PUT將更新現有實體，POST將創建新實體，DELETE將刪除現有實體。

對於服務來說，適當地限制允許的謂詞是很重要的，這樣只有允許的謂詞才能工作，而所有其他的謂詞將返回適當的響應代碼(例如，a403 Forbidden)。

數據輸入驗證

利用鬆散的輸入驗證，黑客可以找到系統中的漏洞。使用現有的輸入，攻擊者將探索接受或拒絕的內容，並將可能的內容推送到API中，直到他們找到一種方法，破壞系統的完整性。

消息大小限制

有消息大小限制機制是合理額，如果你100%確定你不會收到大的消息(例如，超過2MB)，為什麼不過濾掉呢?

SQL 注入攻擊

SQL注入保護允許您阻止可能導致SQL注入攻擊的請求。

JSON 攻擊

JavaScript Object Notation (JSON)容易受到內容級攻擊。這種攻擊試圖使用巨大的JSON文件來壓倒解析器，並最終導致服務崩潰。

XML威脅保護

對XML應用程序的惡意攻擊通常涉及大量的遞歸有效負載、XPath/XSLT或SQL注入和CData，以壓倒解析器並最終導致服務崩潰。

更多相關信息請訪問這裡.

限速

需要對所有API用戶進行身份驗證，以及對所有API調用的日誌記錄允許API提供者限制所有API用戶的使用率。許多API網關允許您對任何一個API資源可以進行的API調用的數量設置上限，以指定秒、分鐘、天或其他相關約束的消耗量。

開發源碼的API 網關:

以下是一些值得一看的產品:

Tyk

WSO2 API Manager

Kong Community Edition

結論

在談到API安全性時，我們必須明白，安全性是公司、組織、機構和政府機構考慮向其API基礎設施投入更多資源的首要問題，也是那些正在加大現有努力的公司的首要問題。與此同時，就現有API供應商在API基礎設施方面的投資而言，這也是最欠缺的領域。許多公司都將API作為自己的產品來構建，部署web、移動、物聯網和其他應用程序，但很少在開發過程中的每一步都停下來適當地保護東西，但是API網關是解決您將面臨的許多安全問題的最流行和最有效的解決方案之一。

請關注公眾號:程序你好

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！