4、使用基礎設施而不是內置開發安全功能
不要直接將API安全策略編碼到想要保護的API中。這種做法有以下缺點：
（1）違反職責分離；
（2）代碼變得更加複雜、脆弱；
（3）增加額外的維護負擔；
（4）不可能涵蓋完整的API安全策略中要求的所有方面；
（5）不可重用；
（6）對安全團隊不可見。
此外，開發人員可能會提出一種白名單的方法。然而，這些白名單通常範圍過於寬泛，它們的使用或管理對安全團隊一般不可見。
Gartner在《2018年安全與風險管理規劃指南》（2018 Planning Guide for Security and Risk Management）中指出，API網關、WAF和CDN等外部化功能非常適合於實現某些難以實現和維護、效率較低或在應用程序代碼中缺乏靈活性的安全功能。目前，API安全領域中出現了許多創新型的初創公司，包括42Crunch、Elastic Beam和Secful等。
因爲移動客戶端經常被用來調用API，所以攻擊者可以通過對移動應用程序進行反向工程來發現其調用API的方式，從而來定位任何調用API。如果API密鑰被“嵌入”到應用程序中，這種情況下很有可能會導致API泄漏。實際上，在沒有其他形式的身份驗證或客戶端IP限制的情況下，API密鑰不應該單獨用於客戶端身份驗證。
除了API客戶端的身份驗證之外，許多企業還將客戶端綁定到特定的應用程序中或設備上。這種策略可以通過使用應用程序認證解決方案(例如來自Critical Blue的Approov或CA Mobile API網關)，或者使用應用程序屏蔽解決方案來實現。訪問管理的工具和服務使用設備內容來作出訪問決定的能力日益提高，通過使用訪問設備收集的客戶端IP地址、地理位置或其他設備內容，從而提供訪問管理策略。
5、真正開放的API同樣也需要考慮安全性
政府越來越多地使用API來傳遞數據或與服務提供商集成。這些API通常採用“開放數據”API的形式，來替代傳統的以文件形式提供數據集的方式，同時提供實時的數據和信息。人們可能以爲這些API的安全性不重要。但是，使用流量限制是非常重要的，這樣客戶端通過開放API批量下載數據時，不會對其他客戶端造成不利影響，不會增加雲計算的資源消耗。此外，客戶可能被引導通過開發人員門戶註冊API，然後使用API密鑰進行身份驗證；請注意，不能僅僅依賴API密鑰來保障API安全性，因爲攻擊者可以通過對客戶端應用程序進行反向工程以獲取API密鑰。
6、採用持續優化的API安全方法
API安全性不是一次性的項目，需要持續優化，具體步驟參照下圖4。
第一步 發現
（1）確保安全、質量和開發團隊能夠訪問API報告(例如，通過API管理軟件)，從而確保跨團隊的可見性。確定應該如何更新組織的變更管理流程，以便在實現新API或修改現有API時通知相關利益者。
（2）持續清點組織提供的API或正在開發的API。組織從第三方獲得的API同樣應該包括在這個API目錄中，這個API目錄通常由完整的API生命週期管理解決方案來提供。CDN產品可以用來動態地發現API，對web流量(可能包括API流量)具有可見性。
（3）與軟件開發生命週期的集成，特別是應用程序開發生命週期管理，可以預先考慮新API的計劃開發工作，或對現有API的更改，而不是在以後才清點上庫。這對於DevOps和DevSecOps非常重要，這樣在開發API時就可以應用適當的API安全策略。
第二步 監控
（1）測試供應商對API使用中正常和異常行爲的識別能力，特別是針對雲交付的API。
（2）監控組織使用的外部第三方API。這可以通過一些API管理供應商提供的“反向網關”功能來執行，以將策略應用於API使用(而不僅僅是API交付)。
（3）根據監控API可以訪問的數據和應用程序(是否對業務至關重要)及其客戶端使用情況，對API進行分類。
第三步 保護
（1）將安全策略應用於API(例如，使用API網關)，但要避免每個API都有特殊的安全策略。相反，可以根據API的分類來實施可重用的策略。從策略本身提取任何特定的API特徵(例如URL路徑)。
（2）在整個API生命週期中應用API安全性，包括新版本的應用程序安全性測試(AST)。
（3）良好的API安全性還要求在整個應用程序生命週期中進行更改控制。例如，應該只允許某些開發人員對API進行更改，並且在開發過程中，只要API發生更改，就會執行應用程序安全性測試。對API進行無記錄的更改也會對整個系統的可用性和安全性產生嚴重影響(例如，如果API更改，一些保護可能會按照預期停止工作)。
7、使用分佈式實施模型來保護整個體系結構中的API，而不單侷限在某一點
根據慣例，API安全主要關注API客戶端和API本身之間的“南-北”通信。但是，微服務的使用，對微服務之間的“東-西”方向上的安全性提出了要求，即使使用其他API和服務的API，這些API通常不會通端的API網關相互調用。這也從而導致了“微網關”的發展，它可以執行更接近微服務本身的策略。
在圖5中，我們看到，不僅必須對端的API網關應用實施安全性，還必須對微服務架構本身內部的流量應用安全性。還要注意，即使微服務可以通過API調用，它們也可能是事件驅動的。
（未完待續）
未經同意，本文禁止轉載或摘編。