譯者 | 陳峻
審校 | 重樓
2019 年，美國第一資本投資國際集團（Capital One）曾遭受了數據泄露安全事件，并導致了超過上億名客戶的個人數據被泄露。據調查，此次攻擊并未涉及到復雜的社會工程或多種黑客工具的使用。攻擊者只是從配置錯誤的 Web 應用防火墻 （WAF） 開始，逐步訪問到了 Amazon S3 的內部實例。那么，其背后的原因是什么呢？IAM 角色設置得過于寬松，沒有嚴格遵守需知（need-to-know）的訪問權限，使得攻擊者能夠將其權限從相對較小的訪問點，升級到主要的數據資產處。
無獨有偶，2023 年，豐田也披露了一起涉及到客戶的個人信息數據庫與數據資源泄露的事件。究其根本問題，在限制較少的非生產環境中，IAM 策略授予了過于廣泛的訪問權限。而這些權限并未得到檢查，以至于讓敏感的資源被暴露在公眾面前。這些寬松的策略背后有著統一的基本邏輯：“他們認為非生產環境的風險較低”。
可見，當數據泄露和那些與權限相關的安全事件不斷發生時，其背后往往與沒能正確處理訪問控制相關聯。因此，我們有必要重新審視那些違規行為，并重點考慮過于寬松的身份和訪問管理（IAM）策略所帶來的后果，即使在那些看似不太可能受到攻擊的環境中，也是如此。
阻力最小的途徑
業界著名的DevOps 工程師 Mat Duggan曾說：“由于云端的 IAM 系統在設計上相當復雜，因此安全性設置對于大多數用戶來說，是一場艱苦的戰斗。越來越多的攻擊者會利用帶有高風險的錯誤配置，作為最容易實施的攻擊手段。而由于設置嚴格的 IAM 權限既耗時、又具有挑戰性，因此云端服務風險環生，權限攻擊頻繁地發生”。
假設我們在 AWS 中有一個云應用，其中包含了多項需要獨特的權限，才能訪問到不同的 AWS 資源服務，例如：用于存儲的 S3、用于數據庫的 DynamoDB 、以及用于消息收發的 SQS。那么，值得推薦的一種方法是：創建針對每一項服務所量身定制的自定義 IAM 角色，并確保個人用戶、應用程序或系統僅具有執行其任務所需的基本訪問權限，從而通過以下方式降低安全風險：
- 默認最小訪問權限：僅為每個用戶角色或應用程序授予基本的權限。據此，即便是在非生產環境中，也能避免過于寬泛的訪問權限。
- 動態權限：隨著角色和要求的變化，定期審查和調整權限，以保持角色僅通過最低、必要的權限訪問相應的資源。
- 撤銷訪問權限：在不再需要訪問權限時刪除權限，以防止隨著時間的推移，出現“權限蠕變（permission creep）”的現象。
可見，在發生數據泄露時，授予最低訪問權限的最大好處，便是降低了泄露的嚴重性。在幾乎沒有任何權限的情況下，即使攻擊者可以在函數層面上，找到某種方法讓 Lambda 調用代碼，那么執行代碼的能力所能造成的損害也是非常有限的，而且還能最大限度地減少違規所帶來的影響。
讓我們來看看較為復雜的實踐層面。由于實施最低權限要求按需提供應用程序的需求規范，以及每個互連資源背后的層次結構和上下文的詳細信息，因此開發人員很少能確切地知道每個服務具體需要哪些權限。例如，要在 S3 存儲桶上執行讀取時，我們還需要列出 S3 存儲桶內容的相關權限。
要弄清楚這一切，往往需要反復試驗、檢查日志、更新角色、以及在每次發生缺少權限錯誤時，按需進行重新部署。此外，某些服務可能需要間接的權限。例如，如果服務 A 與服務 B 進行交互，那么服務 A 就可能需要訪問服務 B 所依賴的資源相關權限。因此，在快速交付的壓力下，阻力最小的一種途徑便是授予廣泛訪問權限，并注明會在稍后的某個時候，調整或收緊訪問權限。不過，在很多時候，實際情況并非如此。這可能會導致整個“鏈條”中的權限范圍變得更廣，從而也就更難以“純凈”地隔離訪問了。
僅僅被動是不夠的
其實，上面介紹的是一些被動的權限管理理論。在實踐中，我們往往需要通過工具來掃描應用中的各種不合理配置。例如，AWS的 IAM 訪問分析器和 Google Cloud 的 IAM 推薦器等工具，對于識別存在風險的權限、以及潛在越權行為等方面非常實用。不過，如果我們僅僅依賴此類工具作為主要防線，則可能會產生一種虛假的安全感。
目前，大多數權限檢查工具旨在分析某個時間點的權限態勢，也就是說，它們通常是在權限已經分配到位后，再進行標記和追溯。這種被動的方法意味著，不合理的配置只有在引起了問題之后才會得到解決，如果掃描的頻率不夠頻繁，那么中間的空檔期就留給了攻擊足夠的時間。
而且，此類工具只標記了那些顯著的、過于廣泛的權限，但是缺乏了評估更細微的配置、以及確定所需的絕對最低訪問級別的上下文。例如，IAM 訪問分析器可以標記 S3 存儲桶中那些可以被公開訪問等問題。雖然將發現的問題標記為待整改的能力無可厚非，但是該工具缺乏了對已授予的權限，是否真的符合應用程序的實際使用需求的深入理解。也就是說，在上述例子中，如果我們能夠提供正確的上下文，那么我們有了如下能力：
- 將更具敏感性的操作（如PutObject 或DeleteObject ）限制到特定的用戶或角色上。
- 限制針對那些與可信源相匹配的特定 IP 段的訪問。
- 通過在存儲桶策略中設置條件，僅允許在特定時間訪問，從而適當地限制了對外暴露的時段。
默認最低權限
根據上述思路，我們可以重新思考實現方式。讓我們來看下面兩段非常簡單的代碼，它們都公開了一個 API，其中包含一個用于從 Cloud Storage 存儲桶返回預簽名 URL的路由。
左圖的例子使用的是 FastAPI 框架，而右邊的例子使用的是 Nitric 框架。這兩個函數是等效的，它們將返回一個預簽名的 URL 來下載文件。其主要區別在于 Nitric 示例包含了一個附加聲明，指示函數將如何使用存儲桶：.allow(“read”)。該聲明的意圖是在兩個資源之間生成關系層級所需的上下文。沒有它，處理程序將無權訪問到存儲桶。
雖然該方法非常簡單，但是它代表了我們在訪問控制思路上的轉變。通過允許開發人員在聲明部分直接指定他們對于資源的預期用途，便可以清楚地表明其希望應用能夠利用基礎架構做些什么。這種與聲明的融合簡化了上下文的管理，畢竟開發人員無需在腦海中映射整個系統。相反，在部署時，我們已有了每個應用所需權限的準確記錄。
更進一步，我們還可以生成JSON，以及可視化的此類關系圖。
最后，如果你想查看實際的效果，請參閱 Nitric 的快速入門指南鏈接--https://nitric.io/docs/get-started/quickstart。該指南將引導你設置項目、創建新的技術棧，并生成基礎架構即代碼（如 Pulumi 或 Terraform），并在默認情況下為你的應用授予最低權限。
譯者介紹
陳峻（Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗。
原文標題：How IAM Missteps Cause Data Breaches，作者：Rak Siva
