根據(jù)云計(jì)算安全聯(lián)盟(CSA)最近發(fā)布的一份調(diào)查報(bào)告,在云計(jì)算面臨的11種最大威脅中,配置錯(cuò)誤和變更控制不足排在第二位,僅次于數(shù)據(jù)泄露。
Capital One公司的數(shù)據(jù)泄漏事件就是一個(gè)很好的例子,該事件導(dǎo)致該公司1.06億張信用卡客戶和申請(qǐng)人的數(shù)據(jù)泄露。網(wǎng)絡(luò)攻擊者利用了開放源Web應(yīng)用程序防火墻(WAF)中的一個(gè)漏洞,該漏洞被用作銀行基于AWS云平臺(tái)操作的一部分。
通過這個(gè)漏洞,網(wǎng)絡(luò)攻擊者可以獲取憑據(jù)以訪問Web應(yīng)用程序防火墻(WAF)以訪問所有資源。不幸的是,Web應(yīng)用程序防火墻(WAF)被賦予了過多的權(quán)限,也就是說,網(wǎng)絡(luò)攻擊者可以訪問任何數(shù)據(jù)桶中的所有文件,并讀取這些文件的內(nèi)容。這使得網(wǎng)絡(luò)攻擊者能夠訪問存儲(chǔ)敏感數(shù)據(jù)的S3存儲(chǔ)桶。
減輕這種身份濫用的最有效方法是執(zhí)行最低特權(quán)原則。在理想情況下,每個(gè)用戶或應(yīng)用程序應(yīng)僅限于所需的確切權(quán)限。
實(shí)施最低特權(quán)的第一步是了解已授予用戶(無論是人員還是機(jī)器)或應(yīng)用程序哪些權(quán)限。下一步是映射所有實(shí)際使用的權(quán)限。兩者之間的比較揭示了權(quán)限差距,從而暴露了應(yīng)保留的權(quán)限和應(yīng)撤銷的權(quán)限。因此必須定期連續(xù)執(zhí)行這一過程,以保持一段時(shí)間內(nèi)的最小特權(quán)。
為了說明這個(gè)過程如何在云平臺(tái)中工作,以主流的AWS云平臺(tái)為例,并且提供可用的細(xì)粒度身份和訪問管理(IAM)系統(tǒng)之一。AWS身份和訪問管理(IAM)是一個(gè)功能強(qiáng)大的工具,它允許管理員安全地配置超過2500個(gè)權(quán)限,以實(shí)現(xiàn)對(duì)給定資源可以執(zhí)行哪些操作的細(xì)粒度進(jìn)行控制。
步驟1:檢查附加政策
第一步是檢查直接附加到用戶的策略。有兩種類型的策略:
•托管策略有兩種類型:由云計(jì)算服務(wù)提供商(CSP)創(chuàng)建和管理的AWS托管策略,以及(組織可以在其AWS帳戶中創(chuàng)建和管理的客戶托管策略。與AWS托管策略相比,客戶托管策略通常提供更精確的控制。
•內(nèi)聯(lián)策略,由AWS客戶創(chuàng)建并嵌入在身份和訪問管理(IAM)標(biāo)識(shí)(用戶、組或角色)中。當(dāng)最初創(chuàng)建或稍后添加身份時(shí),可以將它們嵌入標(biāo)識(shí)中。
步驟2:分析身份和訪問管理(IAM)組
下一步是檢查用戶所屬的每個(gè)身份和訪問管理(IAM)組。這些還具有附加策略,可以間接授予用戶訪問其他資源的權(quán)限。就像用戶本身一樣,組可以附加到托管策略和內(nèi)聯(lián)策略。
步驟3:映射身份和訪問管理(IAM)角色
現(xiàn)在,所有附加到用戶的身份和訪問管理(IAM)角色都需要映射。角色是另一種類型的標(biāo)識(shí),可以使用授予特定權(quán)限的關(guān)聯(lián)策略在組織的AWS帳戶中創(chuàng)建。它類似于身份和訪問管理(IAM)用戶,但其角色可以分配給需要其權(quán)限的任何人,而不是與某個(gè)人唯一關(guān)聯(lián)。角色通常用于授予應(yīng)用程序訪問權(quán)限。
步驟4:調(diào)查基于資源的策略
接下來,這一步驟的重點(diǎn)從用戶策略轉(zhuǎn)移到附加到資源(例如AWS存儲(chǔ)桶)的策略。這些策略可以授予用戶直接對(duì)存儲(chǔ)桶執(zhí)行操作的權(quán)限,而與現(xiàn)有的其他策略(直接和間接)無關(guān)。對(duì)所有AWS資源及其策略(尤其是包含敏感數(shù)據(jù)的策略)進(jìn)行全面審查非常重要。
步驟5:分析訪問控制列表
在策略審查完成之后,分析應(yīng)該移至鏈接到每個(gè)資源的訪問控制列表(ACL)。這些類似于基于資源的策略,并允許控制其他帳戶中的哪些身份可以訪問該資源。由于不能使用訪問控制列表(ACL)來控制同一帳戶中身份的訪問,因此可以跳過與該用戶相同帳戶中擁有的所有資源。
步驟6:查看權(quán)限邊界
在這一步驟中,需要檢查每個(gè)用戶的權(quán)限邊界。這是一項(xiàng)高級(jí)功能,用于定義用戶、組或角色可能具有的最大權(quán)限。換句話說,用戶的權(quán)限邊界基于附加的策略和權(quán)限邊界定義了允許他們執(zhí)行的動(dòng)作。重要的是要注意權(quán)限邊界不會(huì)以相同的方式影響每個(gè)策略。例如,基于資源的策略不受權(quán)限邊界的限制,這些策略中的任何一個(gè)明確拒絕都將覆蓋允許。
步驟7:檢查服務(wù)控制策略
最后,有必要檢查服務(wù)控制策略(SCP)。從概念上講,這些權(quán)限類似于在AWS賬戶中所有身份(即用戶、組和角色)上定義的權(quán)限邊界。服務(wù)控制策略(SCP)在AWS組織級(jí)別定義,并且可以應(yīng)用于特定帳戶。
強(qiáng)制最小權(quán)限訪問
正如人們所看到的,在云中保護(hù)身份和數(shù)據(jù)是一項(xiàng)挑戰(zhàn),隨著組織擴(kuò)展其云計(jì)算足跡而變得越來越復(fù)雜。在許多情況下,用戶和應(yīng)用程序往往會(huì)積累遠(yuǎn)遠(yuǎn)超出其技術(shù)和業(yè)務(wù)要求的權(quán)限,這會(huì)導(dǎo)致權(quán)限差距。
通常,在像AWS云平臺(tái)這樣的復(fù)雜環(huán)境中,確定每個(gè)用戶或應(yīng)用程序所需的精確權(quán)限所需的工作成本高昂,而且無法擴(kuò)展。即使是諸如了解授予單個(gè)用戶的權(quán)限之類的簡(jiǎn)單任務(wù)也可能非常困難。
為了使其中一些流程實(shí)現(xiàn)自動(dòng)化, AWS公司幾年前發(fā)布了一個(gè)名為Policy Simulator的工具,該工具使管理員可以選擇任何AWS實(shí)體(即IAM用戶、組或角色)和服務(wù)類型(例如關(guān)系型數(shù)據(jù)庫(kù)服務(wù)或S3存儲(chǔ)桶),并自動(dòng)評(píng)估特定服務(wù)的用戶權(quán)限。
盡管Policy Simulator是一個(gè)很棒的工具,但并不十分成熟。例如,Policy Simulator不會(huì)檢查用戶可能承擔(dān)的所有角色及其策略(步驟3)。它還不考慮訪問控制列表(ACL)(步驟5)或權(quán)限邊界(步驟6)。在大多數(shù)情況下,組織被迫執(zhí)行人工策略管理或編寫專有腳本。
如人們所見,在云計(jì)算環(huán)境中管理身份和訪問以實(shí)施最低特權(quán)策略非常復(fù)雜,需要大量人工工作,并且成本高昂。由于這門學(xué)科還處于起步階段,因此缺少云平臺(tái)提供商提供的可靠的原生工具。在通常情況下,第三方解決方案正在填補(bǔ)市場(chǎng)空白。
版權(quán)聲明:本文為企業(yè)網(wǎng)D1Net編譯,轉(zhuǎn)載需注明出處為:企業(yè)網(wǎng)D1Net,如果不注明出處,企業(yè)網(wǎng)D1Net將保留追究其法律責(zé)任的權(quán)利。