API 安全是現代應用程式開發的根本，尤其在使用雲端服務和伺服器less 架構時更顯重要。本文將探討如何利用 AWS IAM 等存取管理服務實作細粒度授權，確保服務間安全通訊，並強化軟體供應鏈安全。同時，也將深入剖析伺服器less 應用程式常見的安全風險，例如伺服器端請求偽造（SSRF）、拒絕服務（DoS）和拒絕錢包（DoW）攻擊，並提供相應的緩解措施。最後，文章將介紹如何運用 STRIDE 框架進行威脅建模，識別潛在的攻擊向量，並制定更全面的安全策略，以保護您的應用程式和資料安全。
保障 API 安全：防止未經授權的存取
API 的安全性對於保護整個應用程式和相關資源至關重要。未經授權的存取可能導致嚴重的安全漏洞，尤其是在使用 AWS Lambda 函式、S3 儲存桶或 DynamoDB 表等整合資源時。為了防止這些風險，以下幾點是必須考慮的：
存取管理服務的重要性
利用存取管理服務（如 AWS IAM）來實施適當的細粒度驗證和授權機制，對於保護 API 閘道至關重要。這有助於確保只有授權的實體才能存取您的 API 和相關資源。
服務之間的安全通訊
在服務之間的通訊中，使用 AWS IAM 來進行身份驗證和授權是非常重要的。這確保了服務之間的通訊是安全的，並且只有授權的服務才能相互互動。
軟體和資料完整性風險
軟體和資料完整性風險是指第三方程式碼中的漏洞或漏洞利用對軟體應用程式構成的風險。隨著應用程式依賴項被捆綁和與 Lambda 函式程式碼一起執行，它們被授予與您的業務邏輯相同的許可。
保障軟體供應鏈安全
為了減輕這些風險，自動化依賴項升級和實施其他控制措施來保障軟體供應鏈安全是非常重要的。此外，移除未使用的依賴項也有助於減少風險。
安全日誌和監控的重要性
攻擊者通常依賴於缺乏監控和及時回應來實作其目標而不被檢測到。沒有日誌和監控，違規行為無法被檢測或分析。因此，實施有效的安全日誌和監控機制對於快速檢測和回應安全事件至關重要。
圖表翻譯：
flowchart TD
A[攻擊者] -->|利用漏洞|> B[未經授權的存取]
B -->|導致|> C[安全漏洞]
C -->|需要|> D[安全日誌和監控]
D -->|實施|> E[及時回應]
內容解密：
上述流程圖描述了攻擊者如何利用漏洞獲得未經授權的存取，從而導致安全漏洞。為了防止這種情況，實施安全日誌和監控機制以便及時檢測和回應安全事件至關重要。這包括使用存取管理服務、保障軟體供應鏈安全以及實施有效的安全日誌和監控機制。
瞭解伺服器less應用程式的安全風險
伺服器less應用程式提供了許多優點，包括成本效益、可擴充套件性和簡單性。然而，與任何技術一樣，伺服器less應用程式也存在一些安全風險。瞭解這些風險對於保護您的應用程式和資料至關重要。
伺服器端請求偽造（SSRF）
伺服器端請求偽造（SSRF）是一種安全風險，涉及攻擊者操縱伺服器端請求，以便存取敏感資料或執行未經授權的動作。在AWS中，這主要關注的是EC2例項上的Web伺服器漏洞。2019年Capital One資料洩露事件就是一個嚴重的SSRF攻擊例子。
緩解措施
- 使用API Gateway和Lambda等伺服器less應用程式可以降低SSRF攻擊的風險。
- 避免在客戶端輸入中接受URL，始終清除傳入請求負載，並且永遠不要將原始HTTP回應傳回給客戶端。
拒絕服務（DoS）攻擊
拒絕服務（DoS）攻擊是一種常見的攻擊，攻擊者透過不斷傳送假請求來破壞API的正常運作。公共API將始終面臨DoS攻擊的風險。您的任務不是完全防止這些攻擊，而是使其難以執行，以至於單獨的威懾就足以保護資源。防火牆、速率限制和資源節流警示（例如Lambda、DynamoDB）都是防止DoS攻擊的關鍵措施。
拒絕錢包（DoW）攻擊
拒絕錢包（DoW）攻擊是伺服器less應用程式中的一種特殊攻擊，由於其按使用付費的定價模型和高可擴充套件性而受到影響。DoW攻擊旨在不斷執行資源，以積累高昂的使用費用，從而對業務造成嚴重的財務損害。
緩解措施
- 設定預算警示可以幫助確保您在DoW攻擊升級之前收到警告。請參閱第9章以瞭解更多詳細資訊。
監控和記錄
監控和記錄是保護伺服器less應用程式安全的關鍵組成部分。啟用API Gateway執行和存取日誌可以幫助您檢測和回應可疑活動。CloudTrail監控可以幫助您識別和報告異常行為。
緩解措施
- 啟用API Gateway執行和存取日誌。
- 使用CloudTrail監控來識別和報告異常行為。
透過瞭解這些安全風險並採取緩解措施，您可以幫助保護您的伺服器less應用程式和資料免受攻擊。下一步，我們將探索如何使用威脅建模過程將這些安全風險對映到您的應用程式中。
瞭解伺服器無法攻擊的威脅模型
在設計伺服器無法攻擊應用程式的全面安全策略之前，瞭解攻擊向量和建模潛在威脅至關重要。這可以透過識別玄貓、需要保護的資產以及內部和外部威脅來完成。
什麼是威脅模型？
威脅模型是一個過程，幫助團隊透過討論和協作來識別攻擊向量、威脅和緩解措施。它支援從左到右（或甚至從左開始）的安全方法，其中安全性主要由開發、建構和操作應用程式的團隊擁有，並且在整個軟體開發生命週期中被視為主要關注點。
STRIDE 框架
STRIDE是一個為威脅模型過程新增結構的框架。STRIDE是一個縮寫，描述了六個威脅類別：
- Spoofing：偽裝成其他人或東西
- Tampering：修改磁碟、記憶體、網路或其他地方的資料
- Repudiation：聲稱自己沒有對某一行動負責
- Information disclosure：獲得未經授權的資訊
- Denial of service：破壞或過度消耗有限資源
- Elevation of privilege：提高許可權或存取級別
內容解密：
STRIDE 框架提供了一種系統化的方法來識別和分類別威脅。透過使用此框架，開發人員可以更好地瞭解其應用程式的潛在風險和弱點，並採取措施來緩解它們。
圖表翻譯：
graph LR
A[STRIDE] --> B[Spoofing]
A --> C[Tampering]
A --> D[Repudiation]
A --> E[Information disclosure]
A --> F[Denial of service]
A --> G[Elevation of privilege]
圖表說明：
此圖表顯示了STRIDE框架的六個威脅類別。每個類別代表了一種不同的攻擊向量，開發人員需要了解和緩解這些風險，以確保其應用程式的安全性。
API 安全已成為雲端原生應用開發的根本。深入剖析 API 閘道、Lambda 函式以及資料儲存服務的整合方式，可以發現，保障軟體供應鏈安全、實施最小許可權原則及深度監控是構建安全防線的關鍵。技術堆疊的各層級協同運作中體現，縱深防禦策略的價值日益凸顯。
多維比較分析顯示，相較於傳統應用程式，伺服器less 架構在降低 SSRF 攻擊風險的同時，也面臨 DoS 和 DoW 等新型攻擊的挑戰。實務落地分析指出，開發者除了要善用 IAM、WAF 等安全服務外，更需關注成本管控與預算警示機制，才能有效降低 DoW 攻擊帶來的財務損失。技術限制深析表明，單純依賴技術手段並不足以確保 API 安全，安全文化建設和團隊安全意識的提升同樣重要。
展望未來，隨著 AI 技術的發展，自動化威脅偵測和回應將成為主流趨勢。技術演進預測顯示，根據機器學習的入侵檢測系統和安全資訊與事件管理（SIEM）平臺將扮演更重要的角色。融合趨勢洞察指出，DevSecOps 理念的深入實踐，將進一步推動安全左移，使安全融入軟體開發的每個環節。
玄貓認為，API 安全並非一蹴可及，而是需要持續投入和精進的過程。技術團隊應著重於建立全面的安全策略，並將 STRIDE 等威脅模型框架融入開發流程，才能有效防禦日益複雜的攻擊，確保 API 的安全性和穩定性。
