根據(jù)云計算權(quán)威組織云安全聯(lián)盟(CSA)對241位行業(yè)專家的最新調(diào)查，云計算資源配置錯誤是導(dǎo)致組織數(shù)據(jù)泄露的主要原因。

那么造成這種風(fēng)險的主要原因是什么?由于數(shù)據(jù)規(guī)模巨大，因此在云中管理身份及其權(quán)限極具挑戰(zhàn)性。它不僅僅是人們的用戶身份，還包括設(shè)備、應(yīng)用程序和服務(wù)。由于這種復(fù)雜性，許多組織都會出錯。

[[327185]]

隨著時間的推移，這個問題變得越來越嚴(yán)重，因為很多組織在沒有建立有效分配和管理權(quán)限的能力的情況下擴展了他們的云計算規(guī)模。因此，用戶和應(yīng)用程序往往會積累遠(yuǎn)遠(yuǎn)超出技術(shù)和業(yè)務(wù)要求的權(quán)限，從而造成較大的權(quán)限差距。

例如，美國國防部的一個軍事數(shù)據(jù)庫于2017年對外泄露，這個數(shù)據(jù)庫是美國中央司令部(CENTCOM)和太平洋司令部(PACOM)從社交媒體、新聞網(wǎng)站、論壇和其他公開網(wǎng)站上搜集的18億條以上互聯(lián)網(wǎng)帖子，而美國國防部這兩個統(tǒng)一作戰(zhàn)司令部負(fù)責(zé)美國在中東地區(qū)、亞洲和南太平洋地區(qū)的軍事行動，它配置了三個AWS S3云存儲桶，允許任何經(jīng)過AWS全球認(rèn)證的用戶瀏覽和下載內(nèi)容，而這種類型的AWS帳戶可以通過免費注冊獲得。

關(guān)注權(quán)限

為了減輕與濫用云中身份有關(guān)的風(fēng)險，組織正在嘗試實施最小特權(quán)原則。在理想情況下，應(yīng)將每個用戶或應(yīng)用程序限制為所需的確切權(quán)限。

從理論上講，這個過程應(yīng)該很簡單。第一步是了解已為給定用戶或應(yīng)用程序分配了哪些權(quán)限。接下來，應(yīng)該對實際使用的那些權(quán)限進(jìn)行清點。兩者的比較揭示了權(quán)限差距，即應(yīng)保留哪些權(quán)限以及應(yīng)修改或刪除哪些權(quán)限。

這可以通過幾種方式來完成。認(rèn)為過多的權(quán)限可以刪除或監(jiān)視并發(fā)出警報。通過不斷地重新檢查環(huán)境并刪除未使用的權(quán)限，組織可以隨著時間的推移在云中獲得最少的特權(quán)。

但是，在復(fù)雜的云計算環(huán)境中確定每個應(yīng)用程序所需的精確權(quán)限所需的工作可能既費力又昂貴。

了解身份和訪問管理(IAM)控件

以全球最流行的AWS云平臺為例，該平臺提供了可用的最精細(xì)身份和訪問管理(IAM)系統(tǒng)之一。AWS IAM是一個功能強大的工具，使管理員可以安全地配置對AWS云計算資源的訪問。身份和訪問管理(IAM)控件擁有2,500多個權(quán)限(并且還在不斷增加)，它使用戶可以對在AWS云平臺中的給定資源上執(zhí)行哪些操作進(jìn)行細(xì)粒度控制。

毫不奇怪，這種控制程度為開發(fā)人員和DevOps團(tuán)隊帶來了相同(可能有人說更高)的復(fù)雜程度。

在AWS云平臺中，其角色作為機器身份。需要授予特定于應(yīng)用程序的權(quán)限，并將訪問策略附加到相關(guān)角色。這些可以是由云計算服務(wù)提供商(CSP)創(chuàng)建的托管策略，也可以是由AWS云平臺客戶創(chuàng)建的內(nèi)聯(lián)策略。

擔(dān)任角色

可以被分配多個訪問策略或為多個應(yīng)用程序服務(wù)的角色，使“最小權(quán)限”的旅程更具挑戰(zhàn)性。

以下有幾種情況說明了這一點。

(1)單個應(yīng)用程序–單一角色：應(yīng)用程序使用具有不同托管和內(nèi)聯(lián)策略的角色，授予訪問Amazon ElastiCache、RDS、DynamoDB和S3服務(wù)的特權(quán)。如何知道實際使用了哪些權(quán)限?一旦完成，如何正確確定角色的大小?是否用內(nèi)聯(lián)策略替換托管策略?是否編輯現(xiàn)有的內(nèi)聯(lián)策略?是否制定自己的新政策?

(2)兩個應(yīng)用程序–單一角色：兩個不同的應(yīng)用程序共享同一角色。假設(shè)這個角色具有對Amazon ElastiCache、RDS、DynamoDB和S3服務(wù)的訪問權(quán)限。但是，當(dāng)?shù)谝粋€應(yīng)用程序使用RDS和ElastiCache服務(wù)時，第二個應(yīng)用程序使用ElastiCache、DynamoDB和S3。因此，要獲得最小權(quán)限，正確的操作將是角色拆分，而不是簡單地調(diào)整角色大小。在這種情況下，作為第二步，將在角色拆分之后進(jìn)行角色權(quán)限調(diào)整。

(3)當(dāng)應(yīng)用程序使用的角色沒有任何敏感權(quán)限，但該角色具有承擔(dān)其他更高特權(quán)角色的權(quán)限時，就會發(fā)生角色鏈接。如果權(quán)限更高的角色有權(quán)訪問Amazon ElastiCache、RDS、DynamoDB和S3等各種服務(wù)，那么如何知道原始應(yīng)用程序?qū)嶋H上正在使用哪些服務(wù)?以及如何在不中斷其他可能同時使用第二個更高權(quán)限角色的應(yīng)用程序的情況下限制應(yīng)用程序的權(quán)限?

一種稱為Access Advisor的AWS工具允許管理員調(diào)查給定角色訪問的服務(wù)列表，并驗證其使用方式。但是，只依靠Access Advisor并不能解決訪問權(quán)限與解決許多策略決策所需的各個資源之間的問題。為此，有必要深入了解CloudTrail日志以及計算管理基礎(chǔ)設(shè)施。

云中的最小權(quán)限

最后需要記住，只涉及原生AWS IAM訪問控制。將訪問權(quán)限映射到資源時，還需要考慮幾個其他問題，其中包括間接訪問或應(yīng)用程序級別的訪問。

正如人們所看到的，對于許多組織而言，在云中強制實施最小權(quán)限以最小化導(dǎo)致數(shù)據(jù)泄露或服務(wù)中斷的訪問風(fēng)險可能是不可行的。通過使用軟件來自動化監(jiān)視、評估和對所有身份(用戶、設(shè)備、應(yīng)用程序等)的訪問權(quán)限進(jìn)行調(diào)整正確大小的新技術(shù)正在彌合這種治理鴻溝，以消除風(fēng)險。