RSAC 2020如期在舊金山舉行，此次由於疫情影響多家國內廠商未能成行，但國內心繫產業發展的各家廠商還是時時關注著RSA大會的相關動態。綠盟科技專家團還是在得到RSA資料後第一時間進行研究及分析。根據RSA2020大會期間的雲安全高峰論壇（CSA Summit）、雲安全和虛擬化（Cloud Security & Virtualization）、DevSecOps和應用安全（DevSecOps & Application Security）這幾部分主題內容，與君共享以下幾個觀點，詳見下文。
觀點1 ：雲計算成為互聯一切的基礎設施，雲安全也成為了純安全問題
RSA會議首日上午的CSA高峰論壇[1]、下午的創新沙盒競賽，次日上午的Keynote展會已經成為RSA近幾年的標配，也是每年的三大看點。CSA高峰論壇作為“首發陣容”中的“首發隊員”，其影響力可見一斑。而且很有意思的是，每年CSA的影響力越來越大，各種標準、工作組和培訓，應該都讓它掙得缽滿盆滿，覆蓋範圍也從最初的雲計算安全擴展到物聯網安全、軟件定義邊界等交叉領域。可見，雲計算已經成為互聯一切的基礎設施，雲安全聯盟的觸角已然不滿足狹義的公有云和私有云計算安全領域了。
可以說，CSA和安全廠商已經成為了合作伙伴關係，在共同的研究點和產品方向上互為背書，互為推廣。例如，2019年的高峰論壇上幾家做SDWAN安全的廠商在大談軟件定義邊界，也為其在2013年提出的SDP雲清洗捧場。今年OneTrust公司的VP Kevin Kiley在講供應鏈安全就是對供應鏈中的第三方廠商進行安全評估，也就是Gartner近兩年提出的IRM（Integrated Risk Management）中的VRM（Vendor Risk Management）。
為什麼OneTrust會在雲安全的會場談這個話題呢？因為雲計算領域有一個很大的挑戰是，用戶對雲服務商的信任，CSA在前幾年提出了Consensus Assessments Initiative (CAI)[2]，即對用戶讓雲服務商就Cloud Controls Matrix (CCM)標準填寫評估，從而得到第三方雲基礎設施的可靠度。顯然OneTrust的方案也是契合該方向的。可以說雲安全聯盟在商業運作上非常成功，通過與廠商的合作和客戶的培訓，形成了雲安全領域很好的生態體系，共同推進雲計算安全的發展。
另一方面，雲計算既然成為了普適的基礎設施，提供了計算、存儲、網絡、函數等服務，那麼客戶就會將雲計算作為一種內生資源，嵌入在他的基礎設施中，最終形成統一的IT架構。近兩年，多雲（Multi-Cloud）、混合雲（Hybrid Cloud）、SDWAN就比較熱，在這樣的IT環境中提供安全產品、安全服務，就必然要讓前幾年的雲安全產品或方案融入傳統環境，提供統一的功能。可以預見，在未來幾年，安全廠商的安全方案不會再顯示帶有“雲安全”的定語，因為這就是默認選項，即雲安全已經成為純安全問題。
一個發現是今年CSA高峰論壇的話題已覆蓋了網絡檢測響應（NDR）、供應鏈安全、數據洩露響應、CISO視角等各安全細分領域的話題，但上午的議程標題中都沒有出現Cloud一詞。當然細看內容，其實雲安全的理念已經融入其中，甚至可以說，大家無論談安全理念或是安全技術、安全方案，都是面向雲計算環境。例如Extrahop Networks的COO Raja Mukerji在談檢測響應，主張將NDR、EDR、SIEM組合，構建面向公有云的檢測響應機制，實現雲原生的安全。
當然，雖然傳統安全問題會發生在雲計算場景中，但云環境也有其獨特的地方。所以在雲安全和虛擬化（Cloud Security & Virtualization）議題中，如子域名接管[3]的原因在於一些子域名是租用的，管理不當容易被惡意租戶發現並接管；又如好幾個膠片談到暴露面檢查，就是Gartner說的CSPM（Cloud Security Posture Management），本質來看就是傳統的服務（端口）暴露和弱口令（正如現在很多互聯網上脆弱的物聯網設備一樣），轉變成了公有云上的存儲資源暴露和弱口令。所以這些本質來說是傳統安全問題，但公有云計算環境下有新的特點，值的我們重視。
觀點2： 從純合規性要求轉向攻防要求，雲安全轉向實戰場景
前幾年，AWS在各個大會上有獨立議程做AWS安全入門培訓，彼時大部分的客戶對公有云還不太熟悉，一部分是因為公有云服務太多、配置太複雜，另一部分原因是對於攻擊者而言也比較新，相對而言，IaaS和PaaS的雲安全還是以合規性要求居多。
如今，雲計算對於攻擊者而言，開放API、靈活的資源編排，某種角度來說儼然成為了好用的攻擊資源；另外，雲用戶錯誤配置，也給覬覦雲上敏感數據的攻擊者提供了可乘之機。所以無論是數據面安全CWPP（Cloud Workload Protection Platform），還是管理面安全CSPM，各類雲安全廠商也逐步興起。從本屆RSAC雲安議程中的內容來看，跟往屆相比更加偏向於實戰。
例如前面提到的子域名接管攻擊事件，在《Same Thing We Do Every Few Minutes, Pinky – Try to Take Over All Your Subdomains》 及《Break the Top 10 Cloud Attack Killchains》兩張膠片[3,4]中提到，其中《Same Thing We Do Every Few Minutes, Pinky – Try to Take Over All Your Subdomains》是星巴克安全團隊作為受害者的角度闡述，更令人信服。而《Break the Top 10 Cloud Attack Killchains》則更全面，介紹了十種面向雲平臺的攻擊鏈，其中偵查階段大部分是CSPM關注的暴露Token、Bucket等，另一部分則是惡意內部攻擊者，即前面提的供應鏈覆蓋的內容。
當然只有用戶和安全廠商顯然不夠全面，議程中還有一位是來自AWS的Ben Potter，職位是The security leader for Well-Architected,屬於架構師。他在會議中介紹了AWS架構（Well-Architected）中的安全設計，從中可以看出，AWS的安全體系已經覆蓋了事前管理、準備，事中檢測和響應，事後恢復的閉環，其中他還提到使用了金絲雀賬戶，部署了一些誘餌。這說明雲廠商的安全團隊已經不止關注傳統的清理（hygiene）和被動防護的工作，也開始做一些主動防禦的工作。
總體而言，檢測響應已經從傳統企業環境轉向雲計算環境，如《Using Automation for Proactive Cloud Incident Response》及《Untangling SaaS Security in the Enterprise》[5,6]都介紹了雲服務商和用戶如何做檢測響應的經驗，《Untangling SaaS Security in the Enterprise》[6]則是介紹了在線交易的領域如何實現身份和訪問控制（SSO、MFA，RBAC），數據安全（加密、密鑰管理），應用安全（API安全，session管理），日誌和監控（分析，日誌集中），事件響應（告警、IR劇本），在雲計算環境中必須要引入自動化和xDR才能滿足規模化的要求。
作為防守方，一家小公司IMG Security的諮詢師，《Cloud Threat Hunting》[9]介紹了雲環境下的威脅狩獵，案例非常具體，涉及到滲透測試和事件響應。
觀點3：從只談容器安全、Kubernetes安全到雲原生安全，雲原生進入主流
在2019年RSAC的早期廠商展覽中，已經有一兩家公司在做Kubernetes和容器安全，而今年的雲安全和DevSecOps議程中，有兩篇Kubernetes攻防的膠片，還有一篇介紹雲原生安全和Serverless安全，說明這話題已經被主流觀眾所關注，而且關注熱度不斷向上，從容器到編排，再到無服務和雲原生安全。
例如，SANS的培訓師在《Defending Serverless Infrastructure in the Cloud》演講中提到[7]攻擊者入侵了AWS的Lamda函數，通過反向代理獲得無服務的操作系統細節，見下圖。
然後分析瞭如何從外部獲取憑證進入容器，進而收集容器內部更多憑證，橫向移動，建議將函數放在VPC裡面，減少暴露面。
在《Kubernetes Practical Attack and Defense》[8]中，講者是一家安全資訊公司Inguardians的CTO，先介紹了Kubernetes下的攻擊思路，在Master節點攻擊API server等幾個核心組件，在Slave攻擊Kubelet和運行時容器，提供了一個自己開源Kubernetes的滲透測試工具（https://github.com/inguardians/peirates），該工具主頁Demo介紹了獲得暴露的秘密，然後從API-server創建賬號，新建容器，並得到反連Shell。另外還提供了一個測試訓練環境，供學習 （https://www.bustakube.com/）。
從以上幾個膠片的內容可以看出，今年雲計算安全很明顯的轉變，安全傾向於攻防細節，環境則側重於編排系統之上的部分。
觀點4：DevSecOps成為熱點，DevSecOps和雲原生安全不斷融合，創造共同話題
敏捷開發DevOps似乎與雲計算是兩個維度，但“容器-編排”可以支撐敏捷CI/CD的開發模式，而“編排-無服務”的雲原生運營模式可以支撐大規模彈性的應用場景。這套技術棧似乎為全世界絕大多數的開發者所青睞，而容器Kubernetes-Serverless又是雲原生的底層技術，所以隨著敏捷開發本身的安全機制（DevSecOps）不斷髮展，兩種安全視角的融合不斷加深。
今年的雲安全議程中有一些問題的起源，如代碼中的硬編碼Token、代碼倉庫的暴露憑證，都是安全敏捷開發需要關心的內容，而今年的DevSecOps 和應用安全（DevSecOps & Application Security）議程中，則有一篇《Compromising Kubernetes Cluster by Exploiting RBAC Permissions》[10]是專門介紹Kubernetes的訪問控制安全的。
觀點5：人是對抗永遠的主題，人的因素不可忽視
今年大會的主體是Human Element，不可避免的很多膠片中也出現了這個元素，大部分都是簡單涉及，有兩篇則是專門對人的因素進行探討。
如《Hacking Your Security Culture for the Cloud》[11]介紹了在傳統環境和雲環境中不同的思路，在雲環境中做安全應該與雲計算的思路匹配，如安全即代碼，擁抱自動化，此外要避免人為錯誤所造成的影響，組織紅藍對抗。而[12]是出現在敏捷開發的session中的，討論了工作時間、團隊規模和修改他人代碼頻繁度等因素對代碼安全性產生的影響。總之，技術、流程和人是信息安全的三個組成部分，其中人的因素在不斷的提升。如何發揮人的主觀能動性，對於提升安全防護效率至關重要。
總之，雲計算已經成為了連接萬物的普適的基礎設施，雲計算安全已經進入了下半場，如何形成統一的安全體系，如何提升雲計算的真實安全水平，如何提升使用雲計算各種團隊的安全能力，將是接下來雲安全的發展方向。
參考鏈接
[1] https://www.rsaconference.com/usa/agenda/csa-summit-privacy-and-security-in-the-cloud
[2] https://cloudsecurityalliance.org/research/working-groups/consensus-assessments/
[3] Same Thing We Do Every Few Minutes, Pinky – Try to Take Over All Your Subdomains ,RSAC 2020
[4] Break the Top 10 Cloud Attack Killchains, RSAC 2020
[5] Using Automation for Proactive Cloud Incident Response,RSAC 2020
[6] Untangling SaaS Security in the Enterprise, RSAC 2020
[7] Defending Serverless Infrastructure in the Cloud, RSAC 2020
[8] Kubernetes Practical Attack and Defense, RSAC 2020
[9] Cloud Threat Hunting, RSAC 2020
[10] Compromising Kubernetes Cluster by Exploiting RBAC Permissions, RSAC 2020
[11] Hacking Your Security Culture for the Cloud，RSAC 2020
[12] Which Developers and Teams Are More Likely to Write Vulnerable Software,RSAC 2020
閱讀更多 綠盟科技 的文章
