為什麼要採用應用和API 安全整合策略

為解決保護應用程式、API 和基礎設施（為兩者提供支援）安全挑戰的一種方法是部署多種解決方案：Bot 和詐欺防禦、DDoS 防護、應用安全和API 安全。

顯而易見的一點是，應用程式和API 安全變得越發專業化。 API 不再只是基於URI 的應用程式入口。 API 已經發生演變，成為了一種有自身安全需求的獨立實體。

這些安全需求大多與API 互動的性質有關。換言之，API 需要依照事務授權。這點與應用明顯不同，應用通常按會話進行授權。

API 的互動率也較高，伴隨一些其他特點，致使保護API 這件事面臨一些獨特挑戰。

 App/應用API
報文格式流暢度/Message format fluencyHTML、JSON、XMLProtoBuf、JSON、GraphQL、binary/二進位、XML、data formats/資料格式
互動/Interactions靜態/Static，變化不頻繁/infrequent change動態/Dynamic，頻繁變化/frequent change
資料/Data結構型/Structured、事務型/transactional非結構型/Un/structured、串流/streaming 和事務型/transactional
使用者/User人類/Human軟體/Software、人類/human
使用者代理程式/User-agent瀏覽器/Browsers、應用程式/apps軟體/Software、裝置/device、腳本/scripts、應用程式/apps、瀏覽器/browsers
身份驗證/AuthenticationSession-based按事務（更像零信任）/Transaction-based(more ZT like)
協議流暢度/Protocol fluencyHTTP/S、QUICgRPC、WebSocket、HTTP/S、QUIC
應用和API 的比較，展現了因為哪些不同之處而造成了安全需求差異。

儘管如此，應用程式和API 也存在著共同的安全風險，在實施安全解決方案時也需要對這些風險加以考慮。例如，最近更新的2023 年十大API 安全風險清單就明確提及了一組與應用程式共有的次要風險類別：

  • 身份驗證/授權控制弱
  • 配置錯誤
  • 商業邏輯濫用（撞庫攻擊或帳號接管）
  • 服務端請求偽造(SSRF)

除了這些風險外，還有大量針對可用性的攻擊，也就是應用程式和API 都會遇到的DDoS 攻擊，因為它們通常都依賴TCP 和HTTP，而這兩者都會受到各種旨在破壞存取和可用性的攻擊。

為解決保護應用程式、API 和基礎設施（為兩者提供支援）安全挑戰的一種方法是部署多種解決方案：Bot 和詐欺防禦、DDoS 防護、應用安全和API 安全。這種做法固然能解決安全挑戰，但也帶來了營運挑戰，使許多安全相關任務變得更加複雜，例如策略變更管理和應對威脅（同時影響應用程式和API）。複雜性不僅會阻礙安全性，同時也會限制速度。

根據我們的年度研究，及時應對新出現的威脅是採用安全即服務的首要驅動因素。每個解決方案都需要修復、更新或部署新策略來緩解新出現的威脅，這種做法不僅耗時，同時也增加了配置錯誤或失誤的幾率。因此，緩解威脅的時間會隨著複雜性的增加而延長，特別是當企業在多個環境（混合IT）中運作並利用每個環境的安全解決方案時。使用數學公式來計算時間是線性還是指數成長其實毫無意義，原因在於時間的延長對應對迫在眉睫的威脅本身就是一種最大的阻礙。

因此，更妥善的一種方法是將解決方案結合起來，從而共享營運和安全管理，獲得專門應對威脅的功能，同時允許採用特定的安全策略來處理應用和API 特有的協定和有效負載。

這就需要製定應用程式和API 安全整合策略，在分享通用功能的同時，可以提高應用程式或API 的粒度和專業性。究其根本，Bot 對資料品質、交付成本及對應用程式和API 風險狀況帶來的影響會成為一類問題。 DDoS 也是如此。為解決相同的問題而部署雙倍數量的服務，在所有衡量標準中都不能稱之為高效率。

無論是從營運層面，或是從經濟和架構層面來看，採用應用程式和API 安全整合策略都不失為一項明智之舉。

了解詳情：F5

標籤