譯者 | 陳峻

審校 | 重樓

2019 年，美國第一資本投資國際集團（Capital One）曾遭受了數(shù)據(jù)泄露安全事件，并導(dǎo)致了超過上億名客戶的個人數(shù)據(jù)被泄露。據(jù)調(diào)查，此次攻擊并未涉及到復(fù)雜的社會工程或多種黑客工具的使用。攻擊者只是從配置錯誤的 Web 應(yīng)用防火墻 （WAF） 開始，逐步訪問到了 Amazon S3 的內(nèi)部實例。那么，其背后的原因是什么呢？IAM 角色設(shè)置得過于寬松，沒有嚴(yán)格遵守需知（need-to-know）的訪問權(quán)限，使得攻擊者能夠?qū)?/span>其權(quán)限從相對較小的訪問點，升級到主要的數(shù)據(jù)資產(chǎn)處。

無獨有偶，2023 年，豐田也披露了一起涉及到客戶的個人信息數(shù)據(jù)庫與數(shù)據(jù)資源泄露的事件。究其根本問題，在限制較少的非生產(chǎn)環(huán)境中，IAM 策略授予了過于廣泛的訪問權(quán)限。而這些權(quán)限并未得到檢查，以至于讓敏感的資源被暴露在公眾面前。這些寬松的策略背后有著統(tǒng)一的基本邏輯：“他們認為非生產(chǎn)環(huán)境的風(fēng)險較低”。

可見，當(dāng)數(shù)據(jù)泄露和那些與權(quán)限相關(guān)的安全事件不斷發(fā)生時，其背后往往與沒能正確處理訪問控制相關(guān)聯(lián)。因此，我們有必要重新審視那些違規(guī)行為，并重點考慮過于寬松的身份和訪問管理（IAM）策略所帶來的后果，即使在那些看似不太可能受到攻擊的環(huán)境中，也是如此。

阻力最小的途徑

業(yè)界著名的DevOps 工程師 Mat Duggan曾說：“由于云端的 IAM 系統(tǒng)在設(shè)計上相當(dāng)復(fù)雜，因此安全性設(shè)置對于大多數(shù)用戶來說，是一場艱苦的戰(zhàn)斗。越來越多的攻擊者會利用帶有高風(fēng)險的錯誤配置，作為最容易實施的攻擊手段。而由于設(shè)置嚴(yán)格的 IAM 權(quán)限既耗時、又具有挑戰(zhàn)性，因此云端服務(wù)風(fēng)險環(huán)生，權(quán)限攻擊頻繁地發(fā)生”。

假設(shè)我們在 AWS 中有一個云應(yīng)用，其中包含了多項需要獨特的權(quán)限，才能訪問到不同的 AWS 資源服務(wù)，例如：用于存儲的 S3、用于數(shù)據(jù)庫的 DynamoDB 、以及用于消息收發(fā)的 SQS。那么，值得推薦的一種方法是：創(chuàng)建針對每一項服務(wù)所量身定制的自定義 IAM 角色，并確保個人用戶、應(yīng)用程序或系統(tǒng)僅具有執(zhí)行其任務(wù)所需的基本訪問權(quán)限，從而通過以下方式降低安全風(fēng)險：

• 默認最小訪問權(quán)限：僅為每個用戶角色或應(yīng)用程序授予基本的權(quán)限。據(jù)此，即便是在非生產(chǎn)環(huán)境中，也能避免過于寬泛的訪問權(quán)限。
• 動態(tài)權(quán)限：隨著角色和要求的變化，定期審查和調(diào)整權(quán)限，以保持角色僅通過最低、必要的權(quán)限訪問相應(yīng)的資源。
• 撤銷訪問權(quán)限：在不再需要訪問權(quán)限時刪除權(quán)限，以防止隨著時間的推移，出現(xiàn)“權(quán)限蠕變（permission creep）”的現(xiàn)象。

可見，在發(fā)生數(shù)據(jù)泄露時，授予最低訪問權(quán)限的最大好處，便是降低了泄露的嚴(yán)重性。在幾乎沒有任何權(quán)限的情況下，即使攻擊者可以在函數(shù)層面上，找到某種方法讓 Lambda 調(diào)用代碼，那么執(zhí)行代碼的能力所能造成的損害也是非常有限的，而且還能最大限度地減少違規(guī)所帶來的影響。

讓我們來看看較為復(fù)雜的實踐層面。由于實施最低權(quán)限要求按需提供應(yīng)用程序的需求規(guī)范，以及每個互連資源背后的層次結(jié)構(gòu)和上下文的詳細信息，因此開發(fā)人員很少能確切地知道每個服務(wù)具體需要哪些權(quán)限。例如，要在 S3 存儲桶上執(zhí)行讀取時，我們還需要列出 S3 存儲桶內(nèi)容的相關(guān)權(quán)限。

要弄清楚這一切，往往需要反復(fù)試驗、檢查日志、更新角色、以及在每次發(fā)生缺少權(quán)限錯誤時，按需進行重新部署。此外，某些服務(wù)可能需要間接的權(quán)限。例如，如果服務(wù) A 與服務(wù) B 進行交互，那么服務(wù) A 就可能需要訪問服務(wù) B 所依賴的資源相關(guān)權(quán)限。因此，在快速交付的壓力下，阻力最小的一種途徑便是授予廣泛訪問權(quán)限，并注明會在稍后的某個時候，調(diào)整或收緊訪問權(quán)限。不過，在很多時候，實際情況并非如此。這可能會導(dǎo)致整個“鏈條”中的權(quán)限范圍變得更廣，從而也就更難以“純凈”地隔離訪問了。

僅僅被動是不夠的

其實，上面介紹的是一些被動的權(quán)限管理理論。在實踐中，我們往往需要通過工具來掃描應(yīng)用中的各種不合理配置。例如，AWS的 IAM 訪問分析器和 Google Cloud 的 IAM 推薦器等工具，對于識別存在風(fēng)險的權(quán)限、以及潛在越權(quán)行為等方面非常實用。不過，如果我們僅僅依賴此類工具作為主要防線，則可能會產(chǎn)生一種虛假的安全感。

目前，大多數(shù)權(quán)限檢查工具旨在分析某個時間點的權(quán)限態(tài)勢，也就是說，它們通常是在權(quán)限已經(jīng)分配到位后，再進行標(biāo)記和追溯。這種被動的方法意味著，不合理的配置只有在引起了問題之后才會得到解決，如果掃描的頻率不夠頻繁，那么中間的空檔期就留給了攻擊足夠的時間。

而且，此類工具只標(biāo)記了那些顯著的、過于廣泛的權(quán)限，但是缺乏了評估更細微的配置、以及確定所需的絕對最低訪問級別的上下文。例如，IAM 訪問分析器可以標(biāo)記 S3 存儲桶中那些可以被公開訪問等問題。雖然將發(fā)現(xiàn)的問題標(biāo)記為待整改的能力無可厚非，但是該工具缺乏了對已授予的權(quán)限，是否真的符合應(yīng)用程序的實際使用需求的深入理解。也就是說，在上述例子中，如果我們能夠提供正確的上下文，那么我們有了如下能力：

• 將更具敏感性的操作（如PutObject 或DeleteObject ）限制到特定的用戶或角色上。
• 限制針對那些與可信源相匹配的特定 IP 段的訪問。
• 通過在存儲桶策略中設(shè)置條件，僅允許在特定時間訪問，從而適當(dāng)?shù)叵拗屏藢ν獗┞兜臅r段。

默認最低權(quán)限

根據(jù)上述思路，我們可以重新思考實現(xiàn)方式。讓我們來看下面兩段非常簡單的代碼，它們都公開了一個 API，其中包含一個用于從 Cloud Storage 存儲桶返回預(yù)簽名 URL的路由。

左圖的例子使用的是 FastAPI 框架，而右邊的例子使用的是 Nitric 框架。這兩個函數(shù)是等效的，它們將返回一個預(yù)簽名的 URL 來下載文件。其主要區(qū)別在于 Nitric 示例包含了一個附加聲明，指示函數(shù)將如何使用存儲桶：.allow(“read”)。該聲明的意圖是在兩個資源之間生成關(guān)系層級所需的上下文。沒有它，處理程序?qū)o權(quán)訪問到存儲桶。

雖然該方法非常簡單，但是它代表了我們在訪問控制思路上的轉(zhuǎn)變。通過允許開發(fā)人員在聲明部分直接指定他們對于資源的預(yù)期用途，便可以清楚地表明其希望應(yīng)用能夠利用基礎(chǔ)架構(gòu)做些什么。這種與聲明的融合簡化了上下文的管理，畢竟開發(fā)人員無需在腦海中映射整個系統(tǒng)。相反，在部署時，我們已有了每個應(yīng)用所需權(quán)限的準(zhǔn)確記錄。

更進一步，我們還可以生成JSON，以及可視化的此類關(guān)系圖。

最后，如果你想查看實際的效果，請參閱 Nitric 的快速入門指南鏈接--https://nitric.io/docs/get-started/quickstart。該指南將引導(dǎo)你設(shè)置項目、創(chuàng)建新的技術(shù)棧，并生成基礎(chǔ)架構(gòu)即代碼（如 Pulumi 或 Terraform），并在默認情況下為你的應(yīng)用授予最低權(quán)限。

譯者介紹

陳峻（Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項目實施經(jīng)驗，善于對內(nèi)外部資源與風(fēng)險實施管控，專注傳播網(wǎng)絡(luò)與信息安全知識與經(jīng)驗。

原文標(biāo)題：How IAM Missteps Cause Data Breaches，作者：Rak Siva