雖然 UX 是您的應用程式的門面，但 APls 卻是您架構的支柱。 許多企業犯的常見錯誤是將 API 僅視為應用頂層的介面層。 事實上，APl 是您的應用程式和第三方生態系統的連接架構，它們越來越多地分散在混合和多雲架構中。 雖然 APls 面臨著與 Web 應用程式相同的一些風險（即漏洞利用、業務邏輯濫用、設定錯誤），但還有其他重大風險。 這些攻擊包括繞過弱身份驗證和授權控制、不當庫存以及不安全使用第三方APl 的攻擊。 透過複雜的軟體供應鏈和自動化的 Cl/CD 管道所採用的數位業務的速度進一步增加了風險，這可能導致未知、不受監控和不安全的API。 具體來說，這些包括安全團隊未知和/或開發團隊未維護的影子和殭屍 APl。 在本文中，我們將探討全面、完善的 API 安全方法的 6 個原則。
1. 了解您的API 和端點
很有可能即使您嘗試了，也無法完整識別環境中的每個 API 端點。 不幸的是，對於惡意行為者來說，情況可能就不一樣了。只要存在端點，就可能成為破壞關鍵業務功能的途徑。
此外，公開 API 可以讓您接收來自無數客戶、合作夥伴和應用程式的查詢。 這種暴露也會使您的組織面臨風險，因此了解和監控 API 至關重要。 需要考慮多種風險控制措施來保護您的組織免受API 可能暴露的漏洞和潛在威脅，這些漏洞和威脅可能會導致違規和停機。
對於任何防禦者來說，API 發現是保護 API 的第一步，也是關鍵的一步。 雖然不言而喻，但是「你無法保護你看不到的東西」這句話卻是再正確不過了。 擁有完整的API 清單是開發或改善任何API 安全態勢的起點，協助您了解並量化整個 API 威脅面。 它可作為以下內容的基線：
- 能見度：透過對所有可用的API 進行分類，您可以更了解API 威脅情勢，包括漏洞、敏感資料暴露以及未經授權或被遺忘的端點。
- 版本控制：建立庫存有助於版本管理—了解 API 的歷史和不同版本可以幫助您淘汰過時或易受攻擊的版本或正確保護它們。
- 監控：集中的、完整的API 清單使您能夠更好地監控和記錄 API 使用情況，從而更容易檢測和應對可疑活動（異常）和潛在的安全事件- 此外，如果發生事件，清晰的清單可以幫助您做出回應。
- 一致的安全控制和政策：擁有這種可見性（包括完整的 API 清單）可讓您在整個 API 威脅面上有效地實施控制和策略。
2. 在創新與安全之間找到平衡
這是一場經典的戰鬥。 一方面，敢於創新、突破界限、做競爭對手做不到的事是任何成功企業的基石。 但另一方面，保持安全並不總是能與最新的創新相容。
實現平衡的關鍵有三點：
- 為每種類型的API 設計API 治理策略，以便設定適當的安全控制。
- 實作API 安全性策略，無論在何處部署APl，都可以一致執行。
- 適應新出現的威脅、異常行為以及試圖利用AI 利用或濫用APls 的惡意用戶，以減輕安全團隊的負擔。
根據您所在的行業，合規標準會有所不同，有些標準要求比其他標準更嚴格的安全性。 無論如何，至關重要的是，您的API 安全態勢必須足夠強大，以應對一系列威脅載體。
從外部客戶端到內部後端基礎設施，架構的每個部分都必須有自己的保護措施。
3. 在整個開發生命週期中管理風險
API 安全測試不是一次性的事情。 部署之前、部署期間和部署之後的測試至關重要。 將測試融入開發的每個階段，您將獲得更多機會在漏洞發生之前識別弱點和漏洞。 雖然特定於安全的測試工具很棒，但也不要忘記安全用例建模。
安全性需要在應用程式本身的相同連續生命週期中運行，這意味著與CI/CD 管道、服務配置和事件監控生態系統緊密整合。
4. 從後端到最終客戶的分層保護
從外部客戶端到內部後端基礎設施，架構的每個部分都必須有自己的保護措施。
此外，經過驗證的安全實踐仍然適用- 預設拒絕架構、高強度加密和最小特權存取。
在考慮 API 層的保護時，先將API 分成兩類會很有幫助：內部和外部。 由於API 提供者可以與應用程式團隊協調安全措施，因此內部API 的安全性更加直接。 對於外部API，風險計算有所不同。 您可以（並且應該）實作 API 等級的保護，其作用如下：
- 利用即時威脅情報和存取控制機制（例如強化會話令牌）來縮小安全漏洞的機會。
- 建立基線正常和異常交通模式。
- 限制 API 的使用並對任何經批准的聚合器和第三方整合提供精細控制。
在生產層面，API 蔓延產生的大量流量使得必須使用AI 來偵測異常行為和惡意使用者。
5. 擁有正確的策略和工具
就像沒有任何一種食物可以提供我們充分的營養一樣，也沒有任何一種安全控制可以完全保護API。 相反，您需要製定一個策略，將全面的工俱生態系統作為整體應用程式和 API 安全架構的一部分。 其中包括檢測和線上執行，使您能夠控制API 行為、限制不良或惡意活動並阻止敏感資料外洩。
這可能包括多種功能和工具的組合，包括：
- API 閘道
- 應用程式安全測試（SAST 和DAST）
- Web 應用防火牆(WAF)
- 資料遺失防護(DLP)
- 機器人管理
- DDoS 緩解
API 閘道提供強大的庫存和管理功能，但僅提供速率限制等基本安全性，無法阻止複雜的攻擊者。 此外，API 的激增導致了工具的蔓延——包括API 網關的蔓延。
應用程式安全測試始終至關重要，但在開發過程中用於實現強大應用安全性的左移方法需要透過右盾實踐來增強，即在生產中保護API 端點。
Web應用防火牆提供了一個重要的權宜之計，透過簽章來緩解應用程式漏洞。 API 容易受到與其支援的應用程式相同類型的注入攻擊- 試圖執行非預期的命令或存取資料。 但WAF 通常缺乏必要的動態發現功能，無法持續偵測未知（影子或殭屍）API 和問題（包括API 的行為異常和商業邏輯的潛在漏洞）。
敏感資料偵測和資料遺失預防功能透過偵測和屏蔽敏感關鍵資料（包括個人識別資訊(PII) 和財務資訊）來幫助保護API 及其存取和傳輸的資料。 這使得組織可以創建資料保護規則來限製或屏蔽資料傳輸並阻止API 端點完全暴露資料- 有助於防止透過API 洩露資料。
API 的機器人管理不能依賴常用的安全控制，例如多因素身份驗證(MFA) 和 CAPTCHA，因為 API 流量通常是機器對機器的，除了基於API 的系統的使用者介面外，沒有直接的人機互動。
傳統的DDoS 緩解措施著重於網路和容量攻擊，而API 可能受到濫用關鍵業務邏輯的針對性第 7 層攻擊。 最終結果是一樣的——性能下降，甚至可能導致停機。
動態 API 發現、模式執行（積極安全）、存取控制以及基於機器學習的自動異常檢測和保護已成為保護API 的關鍵生態系統功能。 擁有一個或多個精通 API 協議並允許執行正確的 API 行為和建立 API 保護規則的工具非常重要。 組織需要能夠建立專門管理 API 和 API 行為的自訂規則。 這包括允許和拒絕清單控制、速率限制、地理IP 過濾和自訂規則建立以對API 請求採取行動，包括屏蔽敏感資料以及針對特定 API 端點或群組的匹配和請求約束標準。
6. 混合雲端和多雲安全
API 的激增正在導致混合和多雲環境中不可持續的架構蔓延。 同樣，API 蔓延導致了API 網關蔓延，因為許多安全工具無法跨資料中心、私有/公有雲和邊緣等多種架構提供一致的安全性。 整個數位生態系統中API 流量的可見性和控制對於緩解下一個嚴重漏洞以及防止端點分佈在不同的雲端供應商時可能發生的錯誤配置至關重要。
確保API 安全無虞
API 無所不在——在資料中心、在雲端、在邊緣——並且在Web 應用程式、行動應用程式和相關的第三方整合背後相互連接。 無論API 位於何處，都需要受到保護，並且安全性永遠不應休息。 相反，請確保您的策略包含能夠持續保護API 背後的關鍵業務邏輯並始終如一地保護與API 連接的數位結構的解決方案，這樣您就可以簡化營運並充滿信心地進行創新。
文章來源：F5