云計算安全的新階段：云上風險發現與治理

一、云計算發展的新階段

當前，云計算已經成為新型基礎設施的關鍵支撐技術。在疫情期間，推動了大量遠程辦公、政務防疫、百姓生活等SaaS應用和移動應用。要回答云計算未來數年的發展，則需要回顧云計算在過去的發展。需要注意到，云計算在國內發展總體可分為三個階段。

第一階段主要是在2018年以前，主流的云計算場景多是虛擬化與私有云，部署在用戶的內部環境中，基本上是將物理服務器替換為虛擬機。此類云計算應用可以理解為傳統應用的虛擬化移植。

第二階段主要在2018年至今，隨著新型基礎設施的快速發展，如5G、邊緣計算和工業互聯網等，容器技術的輕量、彈性等特性得到了重視，成為替代虛擬化的云計算重要支撐技術。同時，企業開發團隊大量使用敏捷開發和開發運營一體化（DevOps）的模式，云原生（Cloud Native）技術棧已經廣泛應用于各類云計算基礎設施中，形成了龐大的云計算生態系統，其中微服務、無服務器等成為首選的開發運營模式。此類云計算應用可以理解為云計算的重心從基礎設施轉向了敏捷開發與云化應用交付本身。

第三階段主要在2020年往后，隨著后疫情時代移動辦公、應用云化產生的深遠影響，部署在公有云的應用將成為主流。邊緣側安全接入（Secure Service Edge，SSE），管道側的SDWAN，加上云端SaaS服務，會成為未來云計算的主流。公有云上豐富的云化應用和開放接口服務，將為大量第三方應用提供各類能力。

然而，公有云和SaaS服務的暴露面較私有網絡中的云服務更大，其產生的攻擊面和安全風險不容小視。

二、云計算安全從合規趨向于實戰對抗

從驅動力的角度看，云計算安全也在發生巨大的變化。當前云計算安全建設的驅動力主要是合規性要求。其中最大的動力是滿足等級保護2.0標準中云計算安全的要求，以及相關主管機構所頒布的云計算安全條例，這期間的云計算安全主要是各類安全能力的建設。

然而能力建設只是過程，并非目標。事實上，安全的本質是對抗，安全能力的運營，抵御各類威脅，才是云安全的最終目標。云計算已經得到了廣泛應用，可預見國家支持的威脅、大型攻防對抗活動，以及各種網絡犯罪會瞄準部署在云計算平臺之上的各類服務。

按照攻擊鏈的理論，攻擊者通常會先收集各類軟件版本和脆弱性的信息，構造相應的工具。因而，聚焦云計算的攻擊者會收集互聯網上暴露的云服務，進而發現其脆弱性并加以利用。

從暴露面和攻擊面的角度看，無論是云計算平臺，還是云計算應用都可能存在被攻擊者所利用的脆弱性。主要有如下原因：

1) 在DevOps中，開發團隊大量使用第三方開源軟件或軟件庫，或使用公開的容器鏡像，以提升其開發效率，但這些開源軟件或容器鏡像可能存在安全漏洞或遭到惡意污染，那么由這些鏡像啟動的服務，或使用了這些軟件的服務，都存在安全風險。

2) 傳統的單體應用中，核心應用會直接讀寫數據庫、消息隊列，而公有云應用多采用讀寫公有云提供的存儲服務或消息隊列服務，以實現彈性或按需擴展，而這些原本內部的服務如今暴露在互聯網上，任何人都可從互聯網上發現這些服務。事實上，如果運維團隊沒有對這些服務做安全的配置，攻擊者則可以直接或間接進行攻擊。

3) 很多開發者出于方便也會選擇自己在互聯網上搭建服務，但這些服務如果沒有合理配置，也會存在安全風險。

4) 很多大型機構有自己的研發團隊開發軟件，或委托第三方機構進行開發，無論是企業自己的員工，還是第三方企業的員工，都可能無意識地在互聯網上部署或存放敏感代碼或數據，導致出現安全風險。

三、云計算服務對外暴露的風險

云計算平臺和應用均可能對外暴露，這些服務存在被攻擊者發現并利用的風險。有些云計算應用本身是對外提供服務的，但如存在配置錯誤或憑證失竊，則容易被攻擊者攻擊；而有些云計算應用和系統本不應對外提供服務，但部署者無意識的錯誤導致對外暴露。下面將介紹若干已發現云服務暴露導致的風險。

1、存儲桶服務暴露與用戶錯誤配置導致數據泄露

主流公有云服務商都提供了對象存儲服務，如某公有云服務商提供了S3存儲桶服務，用于存儲用戶應用所需的文件、目錄或數據，提升了應用的彈性能力，簡化了用戶部署系統的難度，例如用戶可以在混合云環境中通過S3服務快速部署自己的Web站點[1]。

然而，由于有相當數量的用戶缺乏安全意識，沒有對存放的S3存儲桶添加訪問憑證，或使用弱口令賬戶，或將憑證存儲在互聯網公開位置（如下面我們提到的代碼倉庫），因而缺乏足夠的認證授權和訪問控制機制保護存儲桶。咨詢公司Gartner曾斷言，到2022年，至少95%的云安全事故是因為用戶的錯誤導致的[2]，而其中大部分是因為配置錯誤導致的。

2、代碼倉庫暴露導致網站被攻破

從安全左移的角度看，代碼倉庫是介于開發階段與運營階段之間的重要邊界，然而由于安全意識薄弱，或大企業軟件供應鏈存在不可控的第三方參與，容易出現安全風險，最典型的是其系統所用的源代碼倉庫暴露在互聯網上。一旦攻擊者獲取這些源代碼，一方面可以分析程序的控制流與業務，找到脆弱處加以利用；另一方面可以發現代碼中存在的硬編碼憑證，進而訪問后臺系統、數據庫等重要服務，堂而皇之地進入內部網絡，或橫向移動，或竊取數據。

我們在測繪時發現了有一些倉庫存在著類似未授權訪問的問題，除了源代碼泄露可能造成的危險外，代碼中還有許多敏感信息。如圖1中的代碼倉庫的代碼中出現“姓名”、“證書編號”、“身份證”之類的個人隱私數據，盡管是測試代碼，但也說明了這種現象是存在的。即便開發者在新版本中將敏感信息刪除，但git倉庫具有歷史版本的信息，攻擊者有可能檢查歷史版本去尋找，從而發現潛在的信息或憑證。總之，代碼倉庫暴露的巨大風險不可不察。

圖1 代碼倉庫中存在的個人信息

3、容器平臺暴露導致計算資源被控制

通過對全網的Docker管理服務的2375端口進行檢索，我們發現該段時間暴露在互聯網上的2375端口地址達337個。暴露主機的分布情況如圖3所示，主機暴露數據覆蓋多達29個國家，這個數據一方面說明了Docker已得到廣泛的應用，但另一方面也說明了用戶對于Docker的使用并不規范，進行了非常危險的配置。

針對這337個服務的IP地址，對地理區域進行統計可以看出，在全球范圍內，互聯網上暴露的Docker服務主要分布于中國、美國以及德國，其中中國有197個IP地址以52%位居第一，美國有65個IP地址以17%位居第二，德國有19個IP以7%位居第三。

圖2 在互聯網上暴露的Docker服務的地理分布

前述暴露的337個Docker服務IP，我們對其域名服務分布情況進行了統計，其中不乏某些知名公有云廠商的IP地址，如圖4所示。

圖3 在互聯網上暴露的Docker服務的公有云IP分布

我們也分析了Kubernetes的服務暴露情況，對全網的6443端口（Kubernetes的API Server默認SSL端口）進行掃描分析，發現這段時間暴露在互聯網上的Kubernetes服務達12803個。圖5顯示了Kubernetes服務暴露分布情況。其中美國以4886個暴露的服務占比38%位居第一，中國以2582個暴露的服務占比20%位居第二，德國以1423個暴露的服務占比11%位居第三。國內互聯網上暴露的Kubernetes服務主機主要存在于北京、浙江以及廣東等省市，其中的幾百個甚至都沒有設置登錄密碼，一旦被惡意操作，后果將不堪設想。 

圖4 在互聯網上暴露的Kubernetes服務的地理分布

四、云上攻擊面管理

從監管部門的角度，對云上風險進行治理，有助于確保重要數據和關鍵數據不外泄、重要基礎設施（包括政府站點服務、智能網聯車、工業互聯網等）正常運行不造成社會危害，以及避免各類伴生網絡攻擊和地緣政治沖突，是非常必要的。但云上安全治理在未來一段時間內，涉及到云上資產與風險測繪、梳理云上資產歸屬，以及相關的治理體系和技術建設，將是一個較為長期、體系化的過程。

從機構的角度，對自身相關的云上風險進行管理和緩解，則是非常必要和可行的。Gartner在云安全框架中將配置和管理面的安全統稱為云安全態勢管理（Security Posture Management， CSPM） [5]，其中最重要的是各類云服務對外暴露的管理面服務是否存在錯誤配置或弱訪問憑證等風險。如果再把數據面服務暴露的風險防護加上，即云上的整體暴露的攻擊面進行管理，Gartner又把這部分安全技術合稱為外部攻擊面管理（External Attack Surface Management， EASM)[4]，并將該技術列入了2022年安全與風險管理趨勢中，可見其重要程度，而外部攻擊面管理，主要就是持續測繪互聯網上各類資產與服務的暴露面，分析其面臨的攻擊面，特別是在攻擊者利用之前，及時發現并緩解潛在的風險。

五、總結

隨著后疫情時代的到來，云化戰略成為各大機構獲得商業成功的必經之路。而云計算趨勢本身所帶來的開發、運營模式變化，在帶來機會的同時，也存在巨大的風險。只有對云化趨勢有足夠的技術洞察，在軟件棧、運營體系上云后，發現并管理暴露的攻擊面，持續進行治理和緩解風險，才能更好地防止各類安全事件或數據泄露，保證云上業務的安全性。