那么造成這種風險的主要原因是什么?由于數據規模巨大，因此在云中管理身份及其權限極具挑戰性。它不僅僅是人們的用戶身份，還包括設備、應用程序和服務。由于這種復雜性，許多組織都會出錯。
隨著時間的推移，這個問題變得越來越嚴重，因為很多組織在沒有建立有效分配和管理權限的能力的情況下擴展了他們的云計算規模。因此，用戶和應用程序往往會積累遠遠超出技術和業務要求的權限，從而造成較大的權限差距。
例如，美國國防部的一個軍事數據庫于2017年對外泄露，這個數據庫是美國中央司令部(CENTCOM)和太平洋司令部(PACOM)從社交媒體、新聞網站、論壇和其他公開網站上搜集的18億條以上互聯網帖子，而美國國防部這兩個統一作戰司令部負責美國在中東地區、亞洲和南太平洋地區的軍事行動，它配置了三個AWS S3云存儲桶，允許任何經過AWS全球認證的用戶瀏覽和下載內容，而這種類型的AWS帳戶可以通過免費注冊獲得。
關注權限
為了減輕與濫用云中身份有關的風險，組織正在嘗試實施最小特權原則。在理想情況下，應將每個用戶或應用程序限制為所需的確切權限。
從理論上講，這個過程應該很簡單。第一步是了解已為給定用戶或應用程序分配了哪些權限。接下來，應該對實際使用的那些權限進行清點。兩者的比較揭示了權限差距，即應保留哪些權限以及應修改或刪除哪些權限。
這可以通過幾種方式來完成。認為過多的權限可以刪除或監視并發出警報。通過不斷地重新檢查環境并刪除未使用的權限，組織可以隨著時間的推移在云中獲得最少的特權。
但是，在復雜的云計算環境中確定每個應用程序所需的精確權限所需的工作可能既費力又昂貴。
了解身份和訪問管理(IAM)控件
以全球最流行的AWS云平臺為例，該平臺提供了可用的最精細身份和訪問管理(IAM)系統之一。AWS IAM是一個功能強大的工具，使管理員可以安全地配置對AWS云計算資源的訪問。身份和訪問管理(IAM)控件擁有2,500多個權限(并且還在不斷增加)，它使用戶可以對在AWS云平臺中的給定資源上執行哪些操作進行細粒度控制。
毫不奇怪，這種控制程度為開發人員和DevOps團隊帶來了相同(可能有人說更高)的復雜程度。
在AWS云平臺中，其角色作為機器身份。需要授予特定于應用程序的權限，并將訪問策略附加到相關角色。這些可以是由云計算服務提供商(CSP)創建的托管策略，也可以是由AWS云平臺客戶創建的內聯策略。
擔任角色
可以被分配多個訪問策略或為多個應用程序服務的角色，使“最小權限”的旅程更具挑戰性。
以下有幾種情況說明了這一點。
(1)單個應用程序–單一角色：應用程序使用具有不同托管和內聯策略的角色，授予訪問Amazon ElastiCache、RDS、DynamoDB和S3服務的特權。如何知道實際使用了哪些權限?一旦完成，如何正確確定角色的大小?是否用內聯策略替換托管策略?是否編輯現有的內聯策略?是否制定自己的新政策?
(2)兩個應用程序–單一角色：兩個不同的應用程序共享同一角色。假設這個角色具有對Amazon ElastiCache、RDS、DynamoDB和S3服務的訪問權限。但是，當第一個應用程序使用RDS和ElastiCache服務時，第二個應用程序使用ElastiCache、DynamoDB和S3。因此，要獲得最小權限，正確的操作將是角色拆分，而不是簡單地調整角色大小。在這種情況下，作為第二步，將在角色拆分之后進行角色權限調整。
(3)當應用程序使用的角色沒有任何敏感權限，但該角色具有承擔其他更高特權角色的權限時，就會發生角色鏈接。如果權限更高的角色有權訪問Amazon ElastiCache、RDS、DynamoDB和S3等各種服務，那么如何知道原始應用程序實際上正在使用哪些服務?以及如何在不中斷其他可能同時使用第二個更高權限角色的應用程序的情況下限制應用程序的權限?
一種稱為Access Advisor的AWS工具允許管理員調查給定角色訪問的服務列表，并驗證其使用方式。但是，只依靠Access Advisor并不能解決訪問權限與解決許多策略決策所需的各個資源之間的問題。為此，有必要深入了解CloudTrail日志以及計算管理基礎設施。
云中的最小權限
最后需要記住，只涉及原生AWS IAM訪問控制。將訪問權限映射到資源時，還需要考慮幾個其他問題，其中包括間接訪問或應用程序級別的訪問。
正如人們所看到的，對于許多組織而言，在云中強制實施最小權限以最小化導致數據泄露或服務中斷的訪問風險可能是不可行的。通過使用軟件來自動化監視、評估和對所有身份(用戶、設備、應用程序等)的訪問權限進行調整正確大小的新技術正在彌合這種治理鴻溝，以消除風險。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號