01
瞭解您的 API 和端點
即使您嘗試,也很有可能無法立即識別環境中的每個 API 端點。 但不幸的是,您可能無法對惡意行為者說同樣的話。 如果端點存在,它就可以被用作入侵途徑。
此外,提供公共 API 還會讓您接收來自無數客戶、合作夥伴和應用程式的查詢。 這也會使您的企業受到攻擊。 為了保護您的企業免受攻擊,防止出現漏洞和詐欺,需要考慮一些風險控制措施。
02
在創新與安全之間找到平衡
這是一場曠日持久的戰鬥。 一方面,任何成功企業的基石都是大膽創新、突破界限、做競爭對手做不到的事情。 但另一方面,保持安全並不總是與最新的創新相匹配。
- 為每種類型的 API 設計 API 治理策略,以便設置適當的安全控制措施。
- 實施在部署 API 的任何地方都能一致執行的 API 安全策略。
- 利用 AI 以應對新出現的威脅、異常行為以及試圖利用或濫用 API 的惡意使用者,從而減少安全團隊的負擔。
根據您所在的行業,合規性標準會有所不同,有些要求相比其他行業而言,安全性需求更為嚴格。 無論如何,API 安全態勢必須足夠強大,能夠面對一連串的威脅載體。
03
在整個開發週期內管控風險
API 安全測試並非一次性試驗。 在部署前、部署期間以及部署後進行測試都至關重要。 您可以通過在開發的每個階段開展測試,獲得更多機會,以在漏洞發生之前發現弱點和漏洞。 雖然特定的安全測試工具十分有效,但切勿忘記安全用例建模。
![1](https://i0.wp.com/www.f5points.com.tw/wp-content/uploads/2024/03/1-scaled.jpg?resize=1290%2C512&ssl=1)
04
從後端到終端客戶的層層保護
從外部客戶端到內部、後端基礎設施,架構的每部分都必須有各自的保護措施。
![API](https://i0.wp.com/www.f5points.com.tw/wp-content/uploads/2024/03/640.jpeg?resize=1080%2C937&ssl=1)
在考慮 API 層的保護問題時,首先將 API 分為 「內部和外部」 這兩類十分有用。 內部 API 的安全更直接,因為 API 提供者可以與應用團隊協調安全措施。 對於外部 API,風險計算有些不同。 但這並不意味著您運氣不佳。 您仍然可以(且應該)實施 API 級別的保護,只需採取下列三項行動:
- 通過即時威脅情報和存取控制機制(例如加固的會話令牌),減少安全漏洞的機會。
- 建立正常和異常的流量模式基線。
- 限制 API 使用,並對任何獲批的聚合商提供精細控制。
在生產層面,來自 API 蔓延的巨大流量使得有必要使用人工智慧來檢測異常行為和惡意使用者。
05
擁有適當的策略和工具
就像沒有一種食物能讓我們獲得充分營養一樣,沒有一種安全工具能完全保護 API。 相反,作為整體安全架構的一部分,您需要制定一項策略,部署全面的工具生態系統。
應考慮的工具包括:
- API 閘道
- 套用安全測試(SAST和 DAST)
- WAF 型
- Bot 管理
此外,API 發現和微分段是重要的生態系統能力。
![2](https://i0.wp.com/www.f5points.com.tw/wp-content/uploads/2024/03/2-scaled.jpg?resize=1290%2C512&ssl=1)
06
將安全性納入開發和部署流水線
您可能已經瞭解到,由於技術、層面、設計和所用 API 的上下文多樣性,API 安全可能變得十分複雜。 不過,有些方法可以減輕這種複雜性。
當您接近 API 安全態勢時,首先退後一步,瞭解一下全域。
安全需要在應用本身的同一連續生命週期中運行,這意味著 要與 CI/CD 流水線、服務預配和事件監控生態系統緊密整合。
此外,經過反覆驗證的安全實踐仍然適用 – 預設拒絕架構、強加密和最低許可權存取。
查看原文:NGINX