| 由於管理員忘記打開基本的安全控制功能，導致人爲錯誤，是雲端數據泄露的主要原因之一。無論你使用的是亞馬遜網絡服務、微軟Azure還是谷歌雲平臺，請記住本文介紹的這些規則以保護企業的雲工作負載。 |
某一天，由於基於雲的系統配置錯誤，又發生了一起數據泄露事件。今年夏天，臭名昭著的Capital One泄露事件就是最突出的一個例子。該泄露事件是由一個配置錯誤的開源Web應用防火牆(WAF)造成的，這家金融服務公司在其託管在亞馬遜網絡服務(AWS)上的業務中使用了WAF。
配置錯誤的WAF顯然被允許列出所有AWS數據存儲桶中的所有文件，並允許讀取每個文件的內容。據安全博客Krebs稱，這一錯誤的配置使得入侵者能夠欺騙防火牆，把請求轉發到AWS上的一個關鍵後端資源上。博文解釋說，該資源“負責向雲服務器分發臨時信息，包括從安全服務發送的當前證書，用於訪問該服務器可以訪問的雲中的任何資源”。
此次泄露事件影響了大約1億美國公民，大約14萬個社會保險號碼和8萬個銀行賬戶號碼被盜，最終可能導致Capital One損失高達1.5億美元。
讓我們來看看爲什麼錯誤配置仍然是雲服務的常見挑戰，然後介紹用來降低風險的7種雲安全控制舉措。
錯誤配置很嚴重，而且可能會越來越糟
那麼，雲系統配置錯誤的問題有多嚴重呢?Gartner曾經做過估計：到2022年，至少95%的雲安全故障都是由客戶造成的，原因是錯誤配置和管理不善。
Gartner稱：“挑戰不在於雲本身的安全性，而在於安全方面的政策和技術，以及對技術的控制。在幾乎所有情況下，是用戶而不是雲提供商未能管理好用於保護企業數據的控件，首席信息官的問題不應該是‘雲是否安全?’，而是‘我是否安全地在使用雲?’”
有很多因素導致並加劇了配置錯誤的問題。
- 誤解和假設。人們常常認爲是由雲服務供應商負責雲環境的安全，不完全是這樣。亞馬遜、微軟和谷歌等基礎設施即服務(IaaS)提供商負責其物理數據中心和運行虛擬機的服務器硬件的安全。客戶則負責保護其虛擬機和應用程序的安全。雲供應商提供了安全服務和工具來保證客戶工作負載的安全，而實際是由客戶的管理員去實施必要的防護措施。如果客戶不能保護他們自己的網絡、用戶和應用程序，雲供應商提供再多的安全防禦措施也是徒勞。
- 常識與現實的脫節。2019年9月，McAfee公司對11個國家1000家企業進行的調查發現，在IaaS環境中發生了很多泄露事件，這些事件不同於人們熟悉的“惡意軟件滲透”方法。在大多數情況下，這類泄露事件“是對雲環境配置錯誤所留下的數據進行的機會性攻擊。”
在調查的同時，McAfee還檢查了數百萬雲用戶和數十億事件中客戶匿名的、彙總的事件數據。數據顯示，使用IaaS環境的企業意識到了有錯誤配置，但更多的是那些沒有引起他們注意的錯誤配置，這之間存在着巨大差距。調查對象表示，他們平均每月能發現37起錯誤配置事件，但McAfee的客戶數據顯示，這些企業每月實際發生大約3500起錯誤配置事件，每年同比增長54%。換句話說，根據McAfee的數據，企業IaaS環境中99%的錯誤配置都沒有被發現。
- 有很多工具能夠發現並利用配置錯誤的雲服務。據賽門鐵克2019年的《互聯網威脅報告》，2018年，AWS S3存儲桶成爲很多企業的致命弱點，7000多萬條記錄因配置不當而被盜或者泄露。潛在的攻擊者可以利用大量的工具，發現互聯網上配置錯誤的雲資源。除非企業採取措施來適當地保護他們的雲資源，比如按照亞馬遜的建議來保護S3存儲桶，否則他們將很容易受到攻擊。
- 越來越複雜的企業IT環境。McAfee指出，企業越來越多地採用多雲環境，再加上對企業所有正在使用的雲服務缺乏全面的認識，這加劇了配置錯誤的問題。在最近的研究中，76%的企業報告稱採用了多雲環境，但一項對客戶數據的檢查發現，實際上這些環境中有92%是多雲的，每年同比增長18%。
- 雖然多雲環境具有優勢，但在監管、管理和控制方面非常複雜。McAfee的產品營銷總監Dan Flaherty評論說：“負責IaaS平臺數據安全的安全從業人員一直非常忙碌，他們沒有一種自動化的方法來監視並自動糾正所有云服務中的錯誤配置。”
此外，在不斷增長的IaaS市場上，激烈的競爭促使亞馬遜、微軟和谷歌都在各自的產品中添加了新功能。雲安全聯盟全球研究副總裁John Yeoh指出：“僅AWS今年就增加了大約1800項功能，而其推出的第一年只有大約28項功能。”因此，對於安全從業人員來說，跟上新特性和功能的快速發展是很大的挑戰，而這反過來又會導致錯誤的配置。Yeoh說：“在複雜的多雲環境中，所使用的每一個平臺或者服務都應該有相應的專家，以確保採取了適當的安全措施。”
CloudKnox安全公司首席執行官Balaji Parimi指出，此外，雲技術最近不斷進步，例如，無服務器應用程序和架構、K8s容器化的工作負載和服務，以及越來越多地使用連接各種雲服務的應用程序編程接口(API)，等等，如果不採取預防措施，也沒有持續監視和調整訪問權限，那麼，錯誤配置的可能性會非常高。他補充道，“人們還只是剛剛開始瞭解這些新的雲技術和趨勢非常危險的一面。他們往往根據靜態角色和有關訪問權限的假設，將數十年前的安全方法應用於這些新技術。”
Yeoh指出，關鍵是：越來越複雜的IT環境使得在整個環境中很難實現簡單的安全控制措施，而這些措施有助於發現並防止錯誤配置問題。
以下介紹的是企業應採用的7種雲安全控制舉措。
明瞭你要負責什麼
所有云服務都不盡相同，要負的責任也有所不同。軟件即服務(SaaS)供應商會確保他們的應用程序受到保護，數據被安全地傳輸和存儲，而IaaS環境並非總是如此。例如，企業應完全負責其AWS彈性計算雲(EC2)、亞馬遜EBS和亞馬遜虛擬私有云(VPC)實例，包括配置操作系統、管理應用程序、保護數據等。
相反，亞馬遜維護S3的操作系統和應用程序，而企業負責管理數據、訪問控制和身份識別策略。亞馬遜提供了爲S3數據加密的工具，但這取決於企業在進入和離開服務器時是否啓用了保護功能。
應與IaaS供應商仔細覈實誰負責每一項雲安全控制措施。
控制誰有權訪問
企業應控制好誰可以使用他們的雲服務。例如，根據Redlock雲安全情報(CSI)部門2018年5月的研究，超過一半(51%)的企業意外地暴露了至少一項雲存儲服務，例如，AWS S3存儲驅動器。儘管亞馬遜和其他雲提供商都警告說，應避免任何有互聯網連接的人訪問存儲驅動器內容。
一般而言，只有負載均衡器和防護主機能夠直接出現在互聯網上。很多管理員在公共子網中使用0.0.0.0/0，錯誤地啓用了服務器的全局權限。連接完全放開了，每臺計算機都能夠進行連接。
另一個常見的錯誤是，允許從互聯網直接進行安全Shell(SSH)連接，這意味着任何能找到服務器地址的人都可以繞過防火牆，直接訪問數據。2019年，Palo Alto網絡公司42威脅研究部在公有云中搜索暴露的服務。在發現的暴露主機和服務中，有32%提供了開放的SSH服務。報告指出：“儘管SSH是最安全的一種協議，但將這項強大的服務暴露給整個互聯網還是太危險了。任何錯誤配置或者存在漏洞/泄漏的證書都可能導致主機被攻破。”
主要雲供應商都會提供身份識別和訪問控制工具，請使用它們，應知道誰在何時訪問了哪些數據。在創建身份識別和訪問控制策略時，把最高權限限制在最小範圍內，只在需要時臨時授予額外權限。儘可能把安全組配置爲最窄安全權限，並在可能的情況下使用參考安全組ID。考慮使用CloudKnox之類的工具，這些工具支持企業根據用戶活動數據設置訪問控制權限。
保護數據
另一常見的錯誤是數據沒有經過加密便放在了雲上。選民信息和敏感的五角大樓文件之所以被泄露，是因爲數據沒有被加密，未授權方也能夠訪問服務器。把敏感數據存儲在雲中而沒有對服務器的訪問進行適當控制，以便保護數據，這樣做是不負責任的，也是危險的。
儘可能控制好加密密鑰。雖然可以讓雲服務供應商提供訪問密鑰，但保護數據的責任在於企業。
即使雲供應商提供了加密工具和管理服務，很多企業實際上並沒有使用。加密是一種安全保障措施——即使安全配置失敗，數據落入未授權方的手中，他們也不能使用數據。
保護證書
正如2017年OneLogin泄露事件所展示的，AWS訪問密鑰被泄露的情況並不少見。這些密鑰會出現在公共網站、源代碼庫、未受保護的K8s儀表板，以及其他一些論壇上。把AWS訪問密鑰視爲最敏感的寶貴資產，教育開發人員避免在公共論壇中泄露此類密鑰。
爲每一個外部服務創建唯一的密鑰，並遵循最小特權原則限制對其訪問，確保密鑰沒有太多的訪問權限。密鑰如果落在犯罪分子手中，可以用來訪問敏感資源和數據。創建IAM角色來分配特殊特權，例如進行API調用。
務必定期輪換密鑰，以避免攻擊者有時間截獲被攻破的密鑰，冒充特權用戶滲透到雲環境中。
不要使用root用戶賬戶，即使是要用於管理任務。使用root用戶來創建具有指定權限的新用戶。鎖定root賬戶(可以通過添加多重身份驗證來實現)，僅用於具體的賬戶和服務管理任務。對於其他的賬戶，爲用戶提供適當的權限。
檢查用戶賬戶，查找那些未被使用的賬戶，並禁用它們。如果沒有人使用這些賬戶，何必給攻擊者留下攻擊的後門呢。
保證環境安全仍然很重要
對於雲環境防護，深層防禦尤其重要，因爲即使一項控制措施失敗了，也會有其他安全措施保持應用程序、網絡和數據的安全。
MFA在用戶名和密碼的基礎上提供了額外的保護層，使得攻擊者很難攻入。應啓用MFA，限制對管理控制檯、儀表板和特權帳戶的訪問。
深度監視
主要雲供應商都提供某種級別的日誌記錄工具，因此一定要啓用安全日誌記錄和監視功能，看看是否有未經授權的訪問和其他問題。例如，亞馬遜爲審查AWS環境提供了CloudTrail，但很多企業並沒有使用該服務。當啓用後，CloudTrail會記錄所有AWS API調用的歷史，包括API調用者的身份、調用的時間、調用者的源IP地址、請求參數，以及AWS服務返回的響應數據。它還可以用於變更跟蹤、資源管理、安全性分析和合規審查等。
採用前移方法以保證安全
前移方法提倡在開發過程中儘早考慮安全因素，而不是在開發的最後階段增加安全措施。McAfee的Flaherty說：“企業不僅應該監控IaaS平臺上的東西，還應該在平臺上線前檢查所有進入平臺的代碼。採用前移方法，能夠在潛在的錯誤配置發展爲問題之前進行審覈並解決問題。”尋找能夠與Jenkins、K8s等其他工具相集成的安全工具，自動審覈並更正過程。
不過，Threat Stack公司的首席安全官Sam Bisbee指出，僅有前移方法還不夠。Bisbee說：“應該在運行前掃描代碼並執行配置檢查，但人們往往忘記檢查工作負載在投入運行後是否符合要求。如果根據我當時知道的情況，進行了掃描，然後部署我的代碼，這樣是可以的。但是工作負載會持續運行數月甚至數年，會發現新的漏洞，並且隨着時間的推移，代碼中的風險也會增加。如果不持續監控，就不會受到保護。”
瞭解企業的基礎設施
Bisbee建議，不要像受過培訓的很多網絡安全專業人員那樣，總是去尋找已知的威脅，而是應該努力瞭解企業完整的基礎設施，以及在其上運行的內容。
誠然，在當今日益複雜的多雲環境中，這可能是很大的挑戰。“但是，要知道某個東西應該是怎樣表現的，然後觀察它什麼時候發生變化，這要比不斷地和入侵者進行‘打地鼠遊戲’容易得多。如果你非常瞭解自己的環境，並且知道預期會發生什麼，那就能夠更有效地檢測出錯誤配置等威脅，並主動補救風險。歸根結底，安全在於深度監視，而不是控制。”