| 摘要: | 本研究聚焦於零信任架構（Zero Trust Architecture, ZTA）於公有雲無伺服器運算環境下之實作限制與實作時面臨的動態授權需求與靜態權限（Static IAM Policy）的衝突，並以亞馬遜雲端服務（Amazon Web Services, AWS）所提供之無伺服器（Serverless）服務（Lambda）為研究對象。研究初始階段於各 AWS 帳號下建立虛擬私有雲環境（Virtual Private Cloud, VPC），先排除調用所有日誌、稽核等資源與跨服務整合需求，採用 AWS 建議的權限設定、角色隔離與權限邊界控管等策略以符合 ZTA 原則之授權設定，驗證其對於多種雲端授權繞過攻擊，（包括臨時安全憑證重放、Lambda 結束後執行環境中殘留的臨時安全憑證被竊取並濫用、及 HTTP 標頭操控繞過驗證）的防護能力，以證明在完全符合 AWS 官方建議的狀況下，上述三種攻擊手法無法成立。然隨實務營運逐步導入上下游廠商系統整合、第三方服務串接、內部流程互相呼叫與法規遵循等要求，權限設定須開放涵蓋多項角色、資源與服務間之互信與存取設定，進而使得前述三種攻擊手法得以成功。我們的研究結果顯示，這些在動態授權管理、精確權限管理及防禦授權繞過攻擊時所遭遇的資安問題，並非來自設定錯誤，而是現行平台缺乏支援動態授權的能力，以致現行雲端身份授權、資源調用與金鑰設定僅能依賴靜態授權，難以因應 ZTA 所需的動態授權需求，使企業在配合法規時，不得不放寬存取控制條件，允許更多角色或服務存取日誌與稽核資源，例如開放放寬權限以滿足寫入稽核紀錄，進而擴大攻擊面並增加資安風險。;This study investigates the limitations of implementing Zero Trust Architecture (ZTA) in serverless environments on public cloud platforms, using AWS Lambda as the primary case. We constructed a ZTA-compliant baseline environment with minimal permissions, role isolation, and permission boundaries based on AWS recommendations. Three simulated attacks were conducted to test the platform’s resistance to (1) temporary security credential replay, (2) credential persistence due to Lambda execution environment reuse, and (3) source forgery via API Gateway header manipulation.
While all attacks failed under the constrained baseline, real-world operational demands—such as third-party integration, internal automation, and regulatory logging—forced enterprises to loosen role and source constraints. These adjustments enabled previously blocked attacks to succeed, revealing a gap between ZTA principles and practical deployment.
Our findings show that the issue is not misconfiguration, but the lack of platform support for dynamic, context-aware authorization. Existing mechanisms rely heavily on static IAM policies and cannot verify credential context, source legitimacy, or runtime intent. As a result, security enforcement often gives way to integration and compliance needs, exposing enterprises to elevated risk. This highlights the need for improved platform-level support to make ZTA truly viable in serverless cloud architectures. |
