根據(jù)云計算安全聯(lián)盟（CSA）最近發(fā)布的一份調查報告，在云計算面臨的11種最大威脅中，配置錯誤和變更控制不足排在第二位，僅次于數(shù)據(jù)泄露。

Capital One公司的數(shù)據(jù)泄漏事件就是一個很好的例子，該事件導致該公司1.06億張信用卡客戶和申請人的數(shù)據(jù)泄露。網(wǎng)絡攻擊者利用了開放源Web應用程序防火墻（WAF）中的一個漏洞，該漏洞被用作銀行基于AWS云平臺操作的一部分。

通過這個漏洞，網(wǎng)絡攻擊者可以獲取憑據(jù)以訪問Web應用程序防火墻（WAF）以訪問所有資源。不幸的是，Web應用程序防火墻（WAF）被賦予了過多的權限，也就是說，網(wǎng)絡攻擊者可以訪問任何數(shù)據(jù)桶中的所有文件，并讀取這些文件的內容。這使得網(wǎng)絡攻擊者能夠訪問存儲敏感數(shù)據(jù)的S3存儲桶。

減輕這種身份濫用的最有效方法是執(zhí)行最低特權原則。在理想情況下，每個用戶或應用程序應僅限于所需的確切權限。

實施最低特權的第一步是了解已授予用戶（無論是人員還是機器）或應用程序哪些權限。下一步是映射所有實際使用的權限。兩者之間的比較揭示了權限差距，從而暴露了應保留的權限和應撤銷的權限。因此必須定期連續(xù)執(zhí)行這一過程，以保持一段時間內的最小特權。

為了說明這個過程如何在云平臺中工作，以主流的AWS云平臺為例，并且提供可用的細粒度身份和訪問管理（IAM）系統(tǒng)之一。AWS身份和訪問管理（IAM）是一個功能強大的工具，它允許管理員安全地配置超過2500個權限，以實現(xiàn)對給定資源可以執(zhí)行哪些操作的細粒度進行控制。

步驟1：檢查附加政策

第一步是檢查直接附加到用戶的策略。有兩種類型的策略：

托管策略有兩種類型：由云計算服務提供商（CSP）創(chuàng)建和管理的AWS托管策略，以及（組織可以在其AWS帳戶中創(chuàng)建和管理的客戶托管策略。與AWS托管策略相比，客戶托管策略通常提供更精確的控制。

內聯(lián)策略，由AWS客戶創(chuàng)建并嵌入在身份和訪問管理（IAM）標識（用戶、組或角色）中。當最初創(chuàng)建或稍后添加身份時，可以將它們嵌入標識中。

步驟2：分析身份和訪問管理（IAM）組

下一步是檢查用戶所屬的每個身份和訪問管理（IAM）組。這些還具有附加策略，可以間接授予用戶訪問其他資源的權限。就像用戶本身一樣，組可以附加到托管策略和內聯(lián)策略。

步驟3：映射身份和訪問管理（IAM）角色

現(xiàn)在，所有附加到用戶的身份和訪問管理（IAM）角色都需要映射。角色是另一種類型的標識，可以使用授予特定權限的關聯(lián)策略在組織的AWS帳戶中創(chuàng)建。它類似于身份和訪問管理（IAM）用戶，但其角色可以分配給需要其權限的任何人，而不是與某個人唯一關聯(lián)。角色通常用于授予應用程序訪問權限。

步驟4：調查基于資源的策略

接下來，這一步驟的重點從用戶策略轉移到附加到資源（例如AWS存儲桶）的策略。這些策略可以授予用戶直接對存儲桶執(zhí)行操作的權限，而與現(xiàn)有的其他策略（直接和間接）無關。對所有AWS資源及其策略（尤其是包含敏感數(shù)據(jù)的策略）進行全面審查非常重要。

步驟5：分析訪問控制列表

在策略審查完成之后，分析應該移至鏈接到每個資源的訪問控制列表（ACL）。這些類似于基于資源的策略，并允許控制其他帳戶中的哪些身份可以訪問該資源。由于不能使用訪問控制列表（ACL）來控制同一帳戶中身份的訪問，因此可以跳過與該用戶相同帳戶中擁有的所有資源。

步驟6：查看權限邊界

在這一步驟中，需要檢查每個用戶的權限邊界。這是一項高級功能，用于定義用戶、組或角色可能具有的最大權限。換句話說，用戶的權限邊界基于附加的策略和權限邊界定義了允許他們執(zhí)行的動作。重要的是要注意權限邊界不會以相同的方式影響每個策略。例如，基于資源的策略不受權限邊界的限制，這些策略中的任何一個明確拒絕都將覆蓋允許。

步驟7：檢查服務控制策略

最后，有必要檢查服務控制策略（SCP）。從概念上講，這些權限類似于在AWS賬戶中所有身份（即用戶、組和角色）上定義的權限邊界。服務控制策略（SCP）在AWS組織級別定義，并且可以應用于特定帳戶。

強制最小權限訪問

正如人們所看到的，在云中保護身份和數(shù)據(jù)是一項挑戰(zhàn)，隨著組織擴展其云計算足跡而變得越來越復雜。在許多情況下，用戶和應用程序往往會積累遠遠超出其技術和業(yè)務要求的權限，這會導致權限差距。

通常，在像AWS云平臺這樣的復雜環(huán)境中，確定每個用戶或應用程序所需的精確權限所需的工作成本高昂，而且無法擴展。即使是諸如了解授予單個用戶的權限之類的簡單任務也可能非常困難。

為了使其中一些流程實現(xiàn)自動化， AWS公司幾年前發(fā)布了一個名為Policy Simulator的工具，該工具使管理員可以選擇任何AWS實體（即IAM用戶、組或角色）和服務類型（例如關系型數(shù)據(jù)庫服務或S3存儲桶），并自動評估特定服務的用戶權限。

盡管Policy Simulator是一個很棒的工具，但并不十分成熟。例如，Policy Simulator不會檢查用戶可能承擔的所有角色及其策略（步驟3）。它還不考慮訪問控制列表（ACL）（步驟5）或權限邊界（步驟6）。在大多數(shù)情況下，組織被迫執(zhí)行人工策略管理或編寫專有腳本。

如人們所見，在云計算環(huán)境中管理身份和訪問以實施最低特權策略非常復雜，需要大量人工工作，并且成本高昂。由于這門學科還處于起步階段，因此缺少云平臺提供商提供的可靠的原生工具。在通常情況下，第三方解決方案正在填補市場空白。