雲端資料外洩事件中，超過 80% 源於設定錯誤而非零日漏洞。本文解析企業最常見的雲端設定錯誤、共同責任模型的誤解，以及如何建立持續的雲端資安治理機制。
Gartner 預測，2025 年 99% 的雲端資安事故責任歸咎於客戶，而非雲端服務供應商。這個驚人的數字背後是一個普遍的誤解：許多企業認為「上了 AWS / Azure 就很安全」，卻忽略了雲端採用「共同責任模型（Shared Responsibility Model）」——雲端供應商負責雲端「基礎設施」的安全，客戶負責在雲端上「運行內容」的安全。
2024 年台灣多起知名企業客戶資料外洩事件，最終調查都指向同一原因：S3 Bucket 設定為公開存取、API 金鑰洩露至 GitHub、或過度寬鬆的 IAM 權限。這些都不是零日漏洞，而是可預防的設定錯誤。
將 S3 Bucket 或 Azure Blob 設定為公開讀取，導致所有人可匿名存取資料。常見原因是開發人員為測試方便臨時開放，卻忘記在上線後關閉。AWS 現提供「Block Public Access」的帳號層級開關，應在所有生產環境帳號上強制啟用。
為了方便而給予 Administrator 權限，或使用 `*:*` 的萬用 IAM Policy。一旦具備此權限的 IAM 金鑰洩露，攻擊者可完全接管整個雲端帳號。應使用 AWS IAM Access Analyzer 定期審查並移除未使用的權限。
開發人員將 AWS Access Key、資料庫密碼、API Token 直接寫入程式碼，並推送至公開或私有 GitHub 倉庫。GitGuardian 統計顯示，每年在 GitHub 上被掃描到的機密超過 1,000 萬個。應使用環境變數、AWS Secrets Manager 或 Azure Key Vault 管理機密。
資料庫的 Security Group 允許 0.0.0.0/0（全球 IP）存取 3306、5432 等資料庫埠，或 SSH（22）和 RDP（3389）直接暴露於公網。應限制資料庫僅允許應用程式伺服器的 IP 存取，管理員存取必須通過 Bastion Host 或 VPN。
未啟用 AWS CloudTrail、Azure Monitor Logs 或 GCP Cloud Audit Logs，導致發生資安事件後無從追查攻擊軌跡和存取範圍。稽核日誌本身也應儲存在獨立的、具防寫保護的儲存空間，防止攻擊者入侵後清除痕跡。
資料庫磁碟（EBS、RDS）、物件儲存（S3）和備份未啟用加密，在雲端供應商內部人員或物理存取的情況下存在洩露風險。現代雲端服務加密幾乎是免費且透明的，應設定為預設啟用。
雲端安全狀態管理（CSPM，Cloud Security Posture Management）工具能持續掃描雲端環境中的設定，比對安全最佳實踐和合規基準（CIS Benchmark、ISO 27001、個資法），並自動化產生修復建議。
許多雲端供應商提供原生的免費 CSPM 功能——AWS Security Hub（整合 GuardDuty）、Azure Security Center、GCP Security Command Center——是企業雲端資安治理的最低基準，應在第一天就啟用，而非等到發生事故再回頭設定。
在新帳號建立之初就植入安全設計，比事後修補更高效。以下是雲端 Landing Zone（登陸區）的安全設計原則：