云工程和安全團隊需要就其云環境的安全性提出一些重要問題，而且他們必須遠遠超出環境是否通過合規性審計。

在你向互聯網添加一個新的端點的幾分鐘內，潛在的攻擊者已經對其進行了掃描并評估了它的可利用性。因此一個云的錯誤配置就會使你的組織成為一個目標，并使你的數據處于危險之中。

假設一個攻擊者發現了這些漏洞之一，并在你的環境中獲得了最初的立足點。這種滲透的爆炸半徑是多少？他們能造成什么樣的損害？

攻擊者有多容易發現關于你的環境和你存儲敏感數據的地方的知識？他們能否利用云資源API密鑰和過于寬松的IAM（身份和訪問管理）設置來破壞你的云控制平面并獲得對其他資源和數據的訪問？他們是否能夠在不被發現的情況下將這些數據提取到自己的云賬戶中，例如通過存儲桶同步命令？

深入調查，你有可能不喜歡你所發現的。迅速采取行動，在黑客利用這些漏洞之前，彌補你的云安全中的這些漏洞。同時也要認識到，云配置的 "漂移 "一直在發生，即使是在使用自動化的CI/CD管道時也是如此，所以你需要保持警惕。今天沒有錯誤配置的云環境，不可能長期保持這種狀態。

云安全就是配置安全

云本質上是一個巨大的可編程計算機，云操作的重點是云資源的配置，包括安全敏感的資源，如IAM、安全組以及數據庫和對象存儲的訪問策略。你需要確保你的云資源的配置在第一天是正確和安全的，并在第二天保持這種狀態。

行業分析師將此稱為云安全態勢管理 (CSPM)。這就是云客戶經常出錯的地方，有時會帶來毀滅性的后果。如果你看到涉及 Amazon Web Services、Microsoft Azure 或 Google Cloud 的數據泄露，則可以確定攻擊是由于云客戶的錯誤而成為可能的。

我們傾向于非常注重避免對單個云資源（例如對象存儲服務（例如，Amazon S3、Azure Blob）和虛擬網絡（例如，AWS VPC、Azure VNet））的錯誤配置，這樣做絕對至關重要。

但同樣重要的是要認識到云安全取決于身份。在云中，許多服務通過 API 調用相互連接，需要 IAM 服務來確保安全，而不是基于 IP 的網絡規則、防火墻等。

例如，從 AWS Lambda 函數到 Amazon S3 存儲桶的連接是使用附加到 Lambda 函數承擔的角色（其服務身份）的策略來完成的。IAM 和類似的服務很復雜且功能豐富，而且很容易為了讓事情正常工作而過度寬容，這意味著過度寬容（而且通常很危險）的 IAM 配置是常態。

Cloud IAM 是新的網絡，但由于云 IAM 服務是通過配置創建和管理的，因此云安全仍然與配置有關，并避免配置錯誤。

云配置錯誤和安全事件

與數據中心相比，云基礎設施的種類要多得多，所有這些資源都是完全可配置的，而且是可配置錯誤的。考慮到所有可用的不同類型的云資源，以及它們可以組合在一起以支持應用程序的方式，配置的可能性實際上是無限的。

在我們 2021 年的調查中，36% 的云專業人士表示，他們的組織在過去一年中遭受了嚴重的云安全漏洞或破壞。并且有多種方式使這些事件成為可能。

???

資料來源：2021 年云安全狀況報告

請記住，在橫向擴展的環境中，對象存儲和 IAM 服務等資源的配置可能會變得極其復雜，而且我們所知道的每一次云泄露都涉及到一系列錯誤配置漏洞。與其僅僅關注單一資源的錯誤配置，還不如徹底了解你的用例并批判性地思考如何在你的環境的完整上下文中保護這些服務。

例如，你可能認為你的 Amazon S3 存儲桶已安全配置，因為啟用了“阻止公共訪問”，此時惡意行為者可能能夠通過在同一環境中利用過度特權的 IAM 資源來訪問其內容。了解你的爆炸半徑風險可能是一個難以解決的問題，但這是一個不容忽視的問題。

云配置錯誤的規模

云計算錯誤配置漏洞與應用程序和操作系統漏洞不同，因為它們在你修復后還會不斷出現。你可能已經在你的開發管道中進行了控制，以確保開發人員不會將已知的應用程序或操作系統漏洞部署到生產中。一旦這些部署得到保障，一般來說問題就解決了。

云的錯誤配置是不同的。同樣的錯誤配置漏洞一次又一次地出現，這是司空見慣的。允許不受限制的SSH訪問的安全組規則（如22號端口的0.0.0.0/0）只是日常發生的那種錯誤配置的一個例子，往往是在批準的部署管道之外。我們使用這個例子是因為大多數工程師都熟悉它（并且很可能在他們職業生涯的某個階段犯過這種惡劣的行為）。

因為云基礎設施非常靈活，我們可以使用API隨意改變它，所以我們傾向于經常這樣做。這是一件好事，因為我們在不斷創新和改進我們的應用程序，需要修改我們的基礎設施來支持這種創新。但是，如果你沒有防范沿途的錯誤配置，預計會有大量的錯誤配置被引入你的環境。一半的云計算工程和安全團隊每天要處理50起以上的錯誤配置事件。

???

資料來源：2021 年云安全狀況報告

為什么會發生云配置錯誤

如果我們成功地使用了云，那么我們的云環境唯一不變的就是變化，因為這意味著我們正在快速創新并不斷改進我們的應用程序。

但每一次變化都伴隨著風險。

根據Gartner的數據，到2023年，至少有99%的云安全故障將是客戶的錯?？紤]到云的錯誤配置是云安全故障發生的原因，而錯誤配置100%是人為錯誤的結果，這1%似乎是一個對沖。

但是，為什么云計算工程師會經常犯這樣的關鍵錯誤呢？

缺乏對云安全和政策的認識是過去一年中報告的云錯誤配置的首要原因之一。把你所有的合規規則和內部安全政策匯編在一起，你可能有一個像《戰爭與和平》一樣厚的卷宗。沒有人能夠記住所有這些，我們也不應該期望他們能夠記住。

因此，我們需要控制措施來防止錯誤配置。但是，31%的人說他們的組織缺乏足夠的控制和監督來防止云計算的錯誤配置。

部分原因是有太多的API和云界面讓團隊無法有效管理。使用多個云平臺（45%的受訪者稱）只會使問題更加嚴重，因為每個平臺都有自己的資源類型、配置屬性、需要管理的接口、政策和控制。你的團隊需要有效解決所有使用中的云平臺的專業知識。

如果團隊采用了云服務提供商的本地安全工具，而該工具在多云環境中并不適用，那么多云安全挑戰就更加復雜。

???

資料來源：2021 年云安全狀況報告

七項戰略建議

由于云安全主要涉及在錯誤配置錯誤被黑客利用之前對其進行預防、檢測和修復，因此從基礎架構即代碼 (IaC) 到開發生命周期的每個階段都需要部署有效的基于策略的自動化。 CI/CD 到運行時。

下面我列出了來自云專業人士的七項建議來實現這一目標。

1. 建立對環境的可見性。

云安全是關于你的云的知識，并拒絕你的對手訪問該知識。如果你不了解云環境的完整狀態，包括每個資源、配置和關系，那么你正在招致嚴重的風險?？缭破脚_建立并保持對云環境的全面可見性，并持續評估每次更改的安全影響，包括潛在的爆炸半徑風險。

你不僅會獲得更好的安全態勢，還會使你的開發人員能夠更快地行動，合規專業人士會感謝你提供的主動審計證據。

2. 盡可能使用基礎設施即代碼。

除了少數例外，你沒有理由構建和修改基礎架構之外的任何云基礎架構，即代碼和自動化 CI/CD 管道，尤其是對于任何新事物。使用 IaC 不僅為云操作帶來了效率、規模和可預測性，還提供了一種檢查云基礎設施預部署安全性的機制。當開發人員使用 IaC 時，你可以為他們提供在部署之前檢查其基礎架構安全性所需的工具。

如果你正在運行多云環境，那么像Terraform這樣被廣泛采用的開源 IaC 工具可能是你最好的選擇。云服務提供商提供的 IaC 產品是免費的，如果你不需要多云支持，則值得考慮。

3. 盡可能使用基于策略的自動化。

任何有以人類語言表達的云策略的地方，都會引起解釋和實施錯誤的差異。適用于你的云環境的每項云安全和合規策略都應以可執行代碼的形式表達和執行。使用策略即代碼，云安全變得具有確定性。這樣可以有效地管理和實施安全性，并幫助開發人員在開發過程的早期獲得安全性。

避免將專有供應商策略作為代碼工具，并選擇開源策略引擎，例如Open Policy Agent (OPA)。OPA 可以應用于任何可以生成 JSON 或 YAML 輸出的東西，這幾乎涵蓋了所有云用例。

優先考慮不需要針對 IaC 和運行云基礎架構使用不同工具和策略的解決方案。

4. 使開發人員能夠安全地構建。

對于云，安全性是一個軟件工程問題，而不是數據分析問題。云安全專業人員需要工程技能并了解整個軟件開發生命周期 (SDLC) 的工作原理，從開發到 CI/CD 和運行時。開發人員需要工具來幫助他們在 SDLC 早期獲得安全性。讓安全成為發展的先見之明和密切的伙伴，而不是只關注部署后問題的事后考慮。

對安全團隊進行云工程實踐培訓不僅能讓他們更好地掌握防御現代云威脅所需的技能，而且他們還將獲得寶貴的技能和經驗，以幫助他們推進職業生涯。你將提高團隊保留率并更好地將你的組織定位為理想的工作場所。

5. 鎖定你的訪問策略。

如果你還沒有正式的訪問和管理云環境的策略，那么現在是時候創建一個了。使用虛擬專用網絡 (VPN) 來加強與關鍵網絡空間（例如，亞馬遜虛擬私有云或 Azure 虛擬網絡）的安全通信。使 VPN 訪問可用或需要，以便團隊可以訪問公司資源，即使它們位于不太受信任的 Wi-Fi 網絡上。

工程師傾向于創建新的安全組規則或 IP 白名單，以便他們可以訪問云中的共享團隊資源。頻繁的審計可以證明虛擬機或其他云基礎設施沒有面臨額外的風險。監督創建堡壘主機，鎖定源 IP 范圍，并監控不受限制的 SSH 訪問。

在 AWS、Azure、GCP 和其他公共云中，IAM 充當普遍網絡。遵循最少許可原則，并利用Fugue 最佳實踐框架等工具來識別合規檢查可能遺漏的漏洞。讓 IAM 更改成為你的更改管理流程的一部分，并利用特權身份和會話管理工具。

采用“默認拒絕”的心態。

6. 標記所有云資源。

在整個云足跡中實施資源標簽并建立有效的標簽約定。使用標簽是幫助你跟蹤和管理云資源的最佳方式之一，但你需要建立標簽約定并強制執行。使用人類可讀的資源名稱，并包括每個資源的聯系人、項目名稱和部署日期。

如果云資源未正確標記，則應將其視為高度可疑并終止。

Microsoft Azure在云資源標記約定方面有很好的資源。

7. 確定平均修復時間 (MTTR)。

衡量你的風險和云安全的有效性是你如何確定你的立場和你想去的地方。最重要的衡量標準是你的平均修復時間。你可能不知道你當前的 MTTR 是多少安全關鍵的云資源配置錯誤（很少有云客戶會這樣做），你應該改變它。為以分鐘為單位的 MTTR 設定目標，如果自動修復對你的團隊和環境來說不是一個可行的選項，請調整你的流程以確保你的團隊能夠在黑客發現關鍵漏洞之前檢測和修復它們。

展望未來

隨著云使用的增長，你的環境的復雜性以及保持其安全的挑戰將會增加。黑客正在使用自動化在幾分鐘內識別和利用云錯誤配置，因此首先避免配置錯誤至關重要。通過為你的開發人員配備基于策略即代碼的自動化工具，你將能夠擴展你的安全工作以應對這些新挑戰，而無需擴展安全人員數量。而且，你在云中的移動速度將比在數據中心中的移動速度更快。

原文標題：??7 ways to avoid a cloud misconfiguration attack??

原作者：Josh Stella