[[179464]]

很多企業(yè)正在試圖保護員工使用的各種云應用和服務中的用戶賬戶，這樣做是因為：攻擊者越來越多地通過釣魚攻擊和路過式下載等方式獲取云賬戶和登錄憑證，以試圖獲取對企業(yè)IT環(huán)境的訪問權限。雖然企業(yè)已經(jīng)非常注意保護用戶賬戶，但一旦根級和管理級賬戶被泄露，企業(yè)可能面臨非常嚴重的后果。

例如，考慮一下Code Spaces的情況，其亞馬遜云計算服務(AWS)管理門戶在2014年遭到攻擊。在攻擊者獲得訪問權限后，該公司的整個基礎設施被暴露，這最終導致該公司倒閉。那么，企業(yè)應該如何保護與其環(huán)境相關的特權賬戶以及部署強大特權用戶管理呢?

在大多數(shù)基礎設施即服務(IaaS)云中，主要有幾種形式的管理或根級訪問。在默認情況下，IaaS環(huán)境要求創(chuàng)建用戶賬戶作為初始管理員，該賬戶通常是通過用戶名或電子郵件以及密碼來進行身份驗證。這個初始管理員可配置環(huán)境，并創(chuàng)建新用戶和組。用戶目錄(例如微軟的Active Directory)也可鏈接到云訪問，從而基于內(nèi)部角色向很多管理員提供云訪問。很多IaaS系統(tǒng)鏡像或模板還包含具有特權的默認用戶賬戶。在AWS機器鏡像中，此用戶是“ec2-user”。

基本特權用戶管理概念

首先，企業(yè)需要重新審視特權用戶管理的核心概念，這包括職責分離和最低權限訪問模型。很多云服務提供商包含內(nèi)置身份和訪問管理工具，允許為每個用戶和組創(chuàng)建不同的政策。這允許安全團隊幫助設計特權政策，讓管理員只能執(zhí)行其角色絕對需要的操作。

對于不支持細粒度角色和特權模型的云服務提供商，可通過使用身份即服務提供來實現(xiàn)，提供商可在內(nèi)部憑證存儲和云服務提供商環(huán)境之間傳輸身份信息，同時作為單點登錄門戶。

此外，企業(yè)應該對所有云環(huán)境的特權用戶訪問強制性使用多因素身份驗證，這可能會阻止對Code Spaces控制臺的初始攻擊。很多提供商提供多種不同形式的多因素訪問，包括終端上的證書、多因素提供商的硬和軟令牌以及短信代碼--這些代碼不夠安全，但仍然比什么都沒有要強。

理想情況下，擁有管理器權限的用戶將使用受批準的多因素方法來訪問管理控制臺，以及所有類型云環(huán)境中的敏感資產(chǎn)和服務。對于大多數(shù)企業(yè)，軟令牌和證書被證明是特權用戶管理中最可行和最安全的選擇。

最后，控制管理和根級訪問的關鍵方面是通過管理和監(jiān)控密鑰來執(zhí)行。大多數(shù)管理員賬號(特別是那些內(nèi)置到默認系統(tǒng)鏡像的賬戶，例如亞馬遜的ec2-user)需要使用私鑰進行訪問。這些密鑰通常在創(chuàng)建用戶時生成，或者可獨立生成，并且必須受到嚴格控制以防止對任何賬戶的非法訪問，特別是管理員或根級用戶。

作為特權用戶管理的一部分，安全和運營團隊應該確保密鑰在內(nèi)部以及云中受到安全保護，理想情況下，密鑰應該放在硬件安全模塊或者其他專用于控制加密密鑰的高度安全平臺中。當開發(fā)人員需要整合密鑰到其部署管道時，應該利用工具來保護這些敏感信息，例如Ansible Vault或者Chef加密數(shù)據(jù)包。

為了確保這些特權賬戶不會被濫用，安全團隊應該收集和監(jiān)控云環(huán)境中可用的日志，以及使用AWS Cloudtrail等內(nèi)置工具或者商業(yè)日志和事件監(jiān)控工具及服務。