例如，人們在將新端點添加到互聯網幾分鐘之后，網絡攻擊者就可能會對其進行掃描并評估其可利用性。單一的云配置錯誤可能會使企業的數據面臨風險。
假設網絡攻擊者發現其中一個漏洞并在其運營環境中獲得立足點，那么將具有什么樣的破壞性?能造成什么樣的損害?網絡攻擊者發現有關運營環境以及存儲敏感數據位置的技術有多容易?他們能否利用云資源API密鑰和過于寬松的IAM(身份和訪問管理)設置來破壞企業的云控制平臺，并獲得對其他資源和數據的訪問權限?他們是否能夠在不被檢測的情況下將這些數據提取到自己的云帳戶中，例如使用存儲桶同步命令?
如果深入研究的話，會發現自己的云配置有很多漏洞，而在黑客利用這些漏洞之前，需要迅速采取行動修補云安全中的這些漏洞。并且還要認識到云配置“漂移”一直在發生，即使使用自動化持續集成(CI)/持續交付(CD)管道也是如此，因此需要保持警惕。
云安全就是配置安全
云計算本質上是一臺巨大的可編程計算機，云計算操作的重點是云計算資源的配置，包括IAM等安全敏感資源、安全組、數據庫和對象存儲的訪問策略等。企業需要確保云計算資源的配置在第一天就是正確和安全的，并且在以后仍保持這種狀態。
行業分析人士稱之為云安全態勢管理。而這正是云計算客戶經常出錯的地方，有時會帶來毀滅性的后果。如果看到涉及AWS、微軟Azure或谷歌云的數據泄露，可以肯定的是，這些網絡攻擊是由于云計算用戶自己的錯誤而發生的。
人們往往非常注重避免對單個云資源的錯誤配置，例如對象存儲服務(如Amazon S3、Azure Blob)和虛擬網絡(如AWS VPC、Azure VNet)，這樣做絕對至關重要。
但認識到云安全取決于身份也很重要。在云中，許多服務通過API調用相互連接，需要IAM服務來實現安全性，而不是基于IP的網絡規則、防火墻等。
例如，從AWS Lambda函數到Amazon S3存儲桶的連接是使用附加到Lambda函數承擔的角色(其服務身份)的策略來完成的。IAM和類似的服務很復雜且功能豐富，而且很容易為了讓事情正常工作而過于寬容，這意味著過度寬容IAM配置是常態，而這通常是危險的。
Cloud IAM是新的網絡，但由于Cloud IAM服務是通過配置創建和管理的，所以云安全仍然與如何避免錯誤配置有關。
云配置錯誤和安全事件
與數據中心相比，云計算基礎設施的種類要多得多，所有這些資源都是完全可配置的。考慮到可用的不同類型的云資源，以及它們可以組合在一起以支持應用程序的方式，云配置的方式實際上是無限的。
在調研機構2021年的調查中，36%的云計算專業人士表示，他們所在的企業在過去一年中遭受了嚴重的云安全漏洞或網絡攻擊，這些事件有多種發生的方式。
需要記住的是，對象存儲和IAM服務等資源的配置在橫向擴展的運行環境中可能會變得極其復雜，而且人們知道每一次云泄露都涉及一系列錯誤配置漏洞。與其只關注單一資源的錯誤配置，還不如徹底了解其用例，并批判性地思考如何在運營環境的完整場景中保護這些服務。
例如，人們可能認為Amazon S3存儲桶已經安全配置，因為啟用了“阻止公共訪問”，此時惡意行為者可能能夠通過在同一環境中利用過度特權的IAM資源來訪問其內容。了解其破壞程序的風險可能是一個難以解決的問題，但這是一個不容忽視的問題。
云配置錯誤的規模
云配置錯誤漏洞與應用程序和操作系統漏洞的不同之處在于，即使修復了它們，也會不斷出現。企業可能在開發管道中設置了控制措施，以確保開發人員不會將已知的應用程序或操作系統漏洞部署到生產環境中。一旦這些部署得到保護，這通常是一個已解決的問題。
云配置錯誤是不同的，而同樣的錯誤配置漏洞反復出現也是司空見慣的。允許不受限制的SSH訪問的安全組規則(例如端口22上的0.0.0.0/0)只是日常發生的錯誤配置的一個示例，通常在批準的部署管道之外。而使用這個例子是因為大多數工程師都熟悉它(并且很可能在他們職業生涯的某個階段做出這種令人震驚的行為)。
因為云計算基礎設施非常靈活，可以使用API隨意更改它，所以傾向于這樣做。這是一件好事，因為一直在不斷創新和改進應用程序，并且需要修改基礎設施以支持這種創新。但是，如果在這一過程中沒有防范錯誤配置，那么預計會在運營環境中引入大量錯誤配置。一半的云計算工程和安全團隊表示，每天可能要處理50次或更多的錯誤配置事件。
為什么會發生云配置錯誤
如果成功地使用了云計算服務，那么云計算環境唯一不變的就是變化，因為這意味著企業正在快速創新并不斷改進其應用程序。但每一次變化都會帶來風險。
根據調研機構Gartner公司的研究，到2023年，99%以上的云安全故障都是客戶自己犯的錯誤?？紤]到云配置錯誤是云安全故障的一種發生方式，而錯誤配置則完全是人為錯誤的結果。
但為什么云計算工程師如此頻繁地犯下這樣嚴重的錯誤呢?
缺乏對云安全和策略的認識是過去一年報告的云配置錯誤的主要原因之一。如果將所有的合規規則和內部安全策略匯編在一起，其內容可能會像長篇小說那樣多。沒有人能記住這些規則，也不應該期望他們能記住。
因此，需要適當的控制措施來防止配置錯誤。但31%的受訪者表示，他們所在的企業缺乏足夠的控制和監督來防止云配置錯誤。
部分原因是有太多API和云接口供團隊有效管理。使用多個云平臺(45%的受訪者報告)只會加劇問題，因為每個云平臺都有自己的資源類型、配置屬性、管理接口、策略和控制。企業的團隊需要能夠有效解決所有正在使用的云平臺的專業知識。
如果企業的團隊采用了云服務提供商的云原生安全工具，多云安全挑戰會更加復雜，這在多云環境中不起作用。
七條戰略性建議
由于云安全主要涉及在錯誤配置錯誤被黑客利用之前對其進行預防、檢測和修復，因此在開發生命周期的每個階段都需要部署有效的基于策略的自動化，從基礎設施即代碼(IaC)到持續集成(CI)/持續交付(CD)。
以下列出了云計算專業人士為實現這一目標提出的七條建議。
(1)建立對環境的可見性
云安全與企業的數據有關，并拒絕網絡攻擊者和競爭對手獲取這些數據和知識。如果不了解云計算環境的完整狀態，包括每個資源、配置和關系，那么將面臨嚴重的風險。企業需要跨云平臺建立并保持對云計算環境的全面可見性，并持續評估每次更改的安全影響，其中包括潛在的破壞風險。
企業不僅會獲得更好的安全態勢，還要讓其開發人員更快地行動，合規性專業人員也會從企業提供主動審計證據而受益。
(2)盡可能使用基礎設施即代碼
除了少數例外，企業沒有理由構建和修改基礎設施之外的任何云計算基礎設施即代碼(IaC)和自動化持續集成(CI)/持續交付(CD)管道，尤其是對于任何新事物。使用IaC不僅為云計算運營帶來了效率、規模和可預測性，還提供了一種檢查云計算基礎設施預部署安全性的機制。當開發人員使用IaC時，可以為他們提供在部署之前檢查其基礎設施安全性所需的工具。
如果企業正在采用多云，那么像Terraform這樣被廣泛采用的開源IaC工具可能是其最好的選擇。云計算服務提供商(即AWS CloudFormation、Azure資源管理器和谷歌部署云管理器)提供的IaC產品是免費的，如果不需要多云支持，則值得考慮采用這樣的產品。
(3)盡可能使用基于策略的自動化
無論在哪里使用人類語言表達云計算策略，都會在解釋錯誤方面產生差異。適用于企業的云計算環境的每個云安全和法規遵從性策略都應該作為可執行代碼來表達和實施。有了策略即代碼，云安全變得具有確定性。這樣可以有效地管理和實施安全策略，并幫助開發人員在開發過程的早期獲得安全性。
避免使用專有的供應商策略即代碼工具，并選擇開源策略引擎，如Open Policy Agent(OPA)。OPA可以應用于任何可以產生JSON或YAML輸出的東西，這幾乎涵蓋了所有的云用例。
企業可以優先考慮不需要針對IaC和運行云計算基礎設施使用不同工具和策略的解決方案。
(4)使開發人員能夠安全地構建
對于云計算，安全性是一個軟件工程問題，而不是數據分析問題。云安全專業人員需要工程技能并了解整個軟件開發生命周期(SDLC)的工作原理，從開發到持續集成(CI)/持續交付和運行時。開發人員需要工具來幫助他們在軟件開發生命周期(SDLC)的早期獲得安全性。讓安全成為發展的先見之明和密切的伙伴，而不是只關注部署之后事后考慮的問題。
對安全團隊進行云工程實踐培訓，不僅能讓他們更好地掌握防御云計算網絡威脅所需的技能，還能獲得寶貴的技能和經驗，幫助他們在職業生涯方面的發展。企業將提高團隊保留率，并更好地為其企業提供理想的工作場所。
云安全系列課程旨在幫助云計算和安全工程師了解云計算風險，以及如何批判性地思考保護其獨特用例的安全。
(5)鎖定訪問策略
如果企業還沒有正式的訪問和管理云計算環境的策略，那么現在是創建的時候了。使用虛擬專用網絡(VPN)強制與關鍵網絡空間(例如Amazon Virtual PrivateCloud或Azure Virtual Network)進行安全通信。使VPN訪問可用，以便團隊可以訪問企業資源，即使它們位于不太受信任的Wi-Fi網絡上。
工程師傾向于創建新的安全組規則或IP白名單，以便他們可以訪問云中的共享團隊資源。頻繁的審計可以證明虛擬機或其他云計算基礎設施不會面臨額外的風險。監督創建堡壘主機，鎖定源IP范圍，并監控不受限制的SSH訪問。
在AWS、Azure、GCP和其他公有云中，IAM充當一個無處不在的網絡。遵循最少許可原則，并利用Fugue最佳實踐框架等工具來識別合規檢查可能遺漏的漏洞。讓IAM更改成為企業的更改管理流程的一部分，并利用特權身份和會話管理工具。
因此，需要采用“默認拒絕”的心態。
(6)標記所有云資源
在整個云足跡中實施資源標記并建立有效的標記約定。使用標記是幫助企業跟蹤和管理云資源的最佳方式之一，但需要建立標記約定并強制執行。使用人類可讀的資源名稱，并包括每個資源的聯系人、項目名稱和部署日期等。
如果未正確標記云資源，則應將其視為高度可疑并終止。例如Microsoft Azure在云資源標記約定方面有很好的資源。
(7)確定平均修復時間
衡量風險和云安全的有效性就是企業如何確定其立場和目標。最重要的衡量標準是平均修復時間。企業可能不知道當前的安全關鍵云資源配置錯誤的平均修復時間是多少(很少有云客戶會這樣做)，那么應該改變它。為以分鐘為單位的平均修復時間設定目標，如果自動修復對企業的團隊和環境來說并不是一個可行的選擇，需要調整其流程以確保團隊能夠在黑客發現關鍵漏洞之前檢測和修復它們。
展望未來
隨著云計算應用的增長，企業的運營環境的復雜性以及保持其安全的挑戰將會增加。黑客可以使用自動化技術在幾分鐘內識別和利用云錯誤配置，因此首先避免配置錯誤至關重要。通過為企業的開發人員配備基于策略即代碼的自動化工具，將能夠擴展其安全工作以應對這些新挑戰，而無需增加安全人員。而且，企業的數據在云中的移動速度將比在數據中心中的移動速度更快。
版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。
京公網安備 11010502049343號