1、CONTENTS執行摘要101公有云安全發展趨勢分析1022023 年重大云安全事件回顧32.1簡介42.2微軟 AzureActiveDirectory 配置錯誤導致 Bing 服務受到嚴重影響42.3全球范圍 VMwareESXi 服務器遭至勒索軟件攻擊42.4DigitalOcean 存儲桶被公開訪問，印度跨國銀行數百萬數據遭遇泄露52.5約 3TB 托管至 Azure 上的美國內部軍事電子郵件數據遭至泄露52.6阿里云數據庫服務被曝嚴重漏洞“BrokenSesame”52.7勒索軟件團伙 CL0P 利用了 MOVEitCloudSQLi 零日漏洞：受害機構數量逼近 900 家，影響人數

2、超 2000 萬62.8ToyotaConnected 云配置錯誤導致大規模數據泄露長達多年62.9丹麥知名云服務被黑，所有數據丟失62.10微軟研究團隊使用的 AzureBlob 存儲桶意外暴露 38TB 隱私數據7CONTENTS2.11英國政府承包商使用的 S3 存儲桶泄露大量員工敏感數據 72.12小結703云服務配置錯誤的安全風險分析83.1容器鏡像倉庫泄露風險分析93.2源代碼倉庫泄露風險分析153.3存儲桶泄露風險分析193.4小結2504云服務自身的安全風險分析274.1跨租戶劫持風險分析284.2權限配置錯誤風險分析314.3小結3505連接云服務的第三方供應鏈安全風險分析3

3、75.1DevOps 與云計算385.2DevOps 風險分析385.3小結72CONTENTS06總結與展望7307參考文獻761總結與展望執行摘要2023 年，云計算持續迅猛發展，廣泛滲透各行業，隨著應用程序在混合云和多云環境中的部署增加，面向租戶的云上風險也相應提升，如攻擊者可利用互聯網上泄露的憑證信息訪問租戶資產，并通過一系列攻擊手段對租戶資產的安全性構成威脅。再如攻擊者可以利用租戶的云存儲訪問錯誤配置，直接獲取云存儲桶內的敏感信息，以上風險最終會造成數據泄露事件的發生。其次，公有云服務自身也存在漏洞，若云廠商未及時對漏洞進行修復，攻擊者可通過漏洞利用對租戶的云服務發起攻擊，造成不良后

4、果。最后，開發運營一體化（DevOps）使得用戶對應用運營變得更加便捷，但復雜的軟件供應鏈與不必要的服務暴露也帶來了極大的安全風險。本篇報告，綠盟科技星云實驗室基于云安全研究方面的積累對未來云安全發展趨勢進行了簡要分析，總結了 2023 年的十大云安全事件，圍繞十大事件風險根因，聯合創新研究院孵化中心進行了云上風險發現的研究。報告主要內容如下：第一章，我們對未來云安全發展趨勢進行了簡要分析，我們認為面向租戶的云服務配置錯誤、云服務自身漏洞、連接云服務的第三方供應鏈安全是未來公有云安全面臨的主要風險；第二章，我們簡要分析了 2023 年十大典型云安全案例?；跁r下熱點事件分析網絡安全態勢，有助于

5、我們“以史為鑒”，預防潛在同類安全事件發生；第三章，我們分析了云服務配置錯誤可能導致的嚴重后果。如容器鏡像、源代碼倉庫、云存儲桶中可能存儲了用戶關鍵服務的密鑰信息，也可能存儲用戶的隱私數據，這給攻擊者提供了更多的攻擊面，將會導致更多數據泄露事件的發生；第四章，我們對公有云服務自身的安全性進行了分析，如公有云數據庫服務自身的安全性較容易被忽略，且數據庫中存放用戶敏感數據，如賬號信息，個人信息等，因此也成為攻擊者關注的目標之一；第五章，我們分析了用戶在云上部署的開發運營一體化 DevOps 服務的安全性。DevOps流程中，用戶使用大量的第三方服務或者依賴庫，使用的服務鏡像，都有可能存在漏洞，更可

6、能存在敏感數據泄漏的風險。希望通過本報告，各位讀者能了解、發現自己云上資產的暴露面和攻擊面，以防范潛在的攻擊。22023 公有云安全風險分析報告綠盟科技星云實驗室觀點 1：安全左移過程中，自建倉庫的風險應重點關注，研究表明，暴露在互聯網上的超過 10%鏡像倉庫存在鏡像泄露風險，約 16%代碼倉庫存在未授權訪問漏洞，且絕大部分自建倉庫中泄露的鏡像和源代碼存在不同程度的敏感數據泄露風險。如被利用，可能會對數據擁有者造成較大的經濟和名譽損失。觀點 2：綠盟科技統計的 2023 年重大云安全事件中，約四成是因為人為錯誤配置導致的云存儲桶數據泄露，這些事件暴露了用戶使用存儲桶服務時存在訪問控制配置不當和

7、缺乏加密保護等安全問題。觀點 3：SaaS 服務作為一種靈活的云服務模型，涵蓋各種服務類別，不同的服務面臨不同的風險，其中影響較大的風險是租戶間的隔離不夠徹底，進而危害其他云租戶的業務。觀點 4：IaaS 服務通常提供大規模的計算存儲資源，云租戶需要自行搭建服務，其風險主要集中在云租戶自身的操作配置可能不合規，或未采用了最佳安全實踐。觀點 5：近年敏捷開發模式流行，但開發者安全意識缺失，造成大量 DevOps 組件服務暴露在互聯網上，不同程度帶有 N Day 漏洞。這些漏洞可能來自于組件本身，或來自擴展組件功能的第三方插件，其客觀上增加了 DevOps 的攻擊面，特別是數據泄露的風險。公有云安

8、全發展趨勢分析0122023 公有云安全風險分析報告綠盟科技星云實驗室2022 年的網絡空間測繪年報 1 中，我們從對象存儲服務風險、公有云憑證泄露風險、云原生服務泄露風險、源代碼倉庫暴露風險四個角度出發，對云上風險進行了梳理分析。2023 年，我們通過對不斷曝出的云安全事件的觀察，發現這些風險依然存在，并呈現以下趨勢：1.云租戶的錯誤導致數據泄漏事件依然不斷。隨著云上數據泄露事件激增，租戶不恰當配置或暴露服務造成連鎖安全事件的風險突顯，例如 2023 年 5 月，豐田汽車公司外包給 TC公司的部分數據因所屬的云存儲桶配置錯誤而遭到大規模數據泄露 2，這表明未來云安全防護的焦點將從工作負載安全

9、轉向至面向租戶的安全；2.云服務商的錯誤導致未授權訪問和數據泄漏。云服務漏洞導致了一系列未授權訪問和數據泄漏事件，例如 2023 年 1月，Azure Active Directory 服務存在認證繞過漏洞導致 Bing 服務的使用受到嚴重影響 3，同年 4 月，阿里云數據庫服務被曝嚴重漏洞“BrokenSesame”，可導致跨租戶劫持風險 4；3.合作伙伴被攻陷的導致供應鏈安全風險。連接第三方云服務導致的供應鏈安全風險備受關注。隨著敏捷開發趨勢越發明顯，企業云應用管理越發遵循開發運營一體化的理念。由于 DevOps 流程的各個階段涉及眾多組件，且這些組件被暴露在互聯網中，因此攻擊者可通過對組

10、件的脆弱性配置或漏洞進行利用，竊取重要數據并植入惡意腳本，引發供應鏈攻擊。典型事件如 2023 年 5 月，勒索軟件團伙 CL0P 利用了 MOVEit Cloud SQLi 零日漏洞發起供應鏈攻擊，受害機構數量逼近 900 家，影響人數超 2000 萬 5。這成為繼 2020 年Solarwinds 事件后又的有一起重大供應鏈安全事件。隨著云服務的廣泛應用，云安全面臨著日益增大的挑戰。人為錯誤配置是主要的風險來源，無論是云租戶還是云服務商都可能犯錯。此外，連接第三方云服務引發的供應鏈攻擊也備受關注。我們只有深入了解這些云上風險的根本原因，才能更有效地加強云安全防護，使云計算更好地助力產業升級

11、。022023 年重大云安全事件回顧42023 公有云安全風險分析報告綠盟科技星云實驗室2.1 簡介2023 年，云安全領域涌現了一系列重大事件，深刻影響著各行業，未來的挑戰依然嚴峻。本章我們總結了 2023 年十大云安全事件并進行簡單介紹，后續第三章至第五章我們將圍繞這些云安全事件進行深度分析。2.2 微軟 Azure Active Directory 配置錯誤導致 Bing 服務受到嚴重影響2023 年 1 月，Wiz 發現了 Azure Active Directory（AAD）中的一個新攻擊向量，影響Microsoft 的 Bing 服務。該攻擊向量基于常見的 AAD 配置錯誤，使得配

12、置錯誤的應用程序允許未授權的訪問 6。研究人員發現了多個微軟應用程序容易受到這種攻擊的影響，包含 Mag 新聞、CNS API、Power Automate 博客等應用程序，其中一個是用于驅動 Bing 服務的內容管理系統（CMS）。該漏洞能夠導致攻擊者接管該 Bing 服務，修改搜索結果，并有可能導致數百萬 Bing 用戶的Office 365 憑證被竊取。這些憑證進而允許對用戶的私人電子郵件和文件進行訪問。Wiz 將這次攻擊命名為“#BingBang”。該漏洞利用方式十分簡單，甚至無需編寫任何代碼。Wiz已將該問題報送至微軟，相關漏洞也已經得到修復。此外，微軟對AAD功能進行修改，以減少用

13、戶的風險暴露。更詳細的分析請參見研究案例 10:微軟 Azure Active Directory 由于配置錯誤導致 Bing服務受到嚴重影響2.3 全球范圍 VMware ESXi 服務器遭至勒索軟件攻擊2023 年 2 月 3 日左右，法國計算機緊急響應小組(CERT-FR)發出警告，有攻擊者正通過利用一個在 2021 年 3 月就發現的 VMware vCenter Server 遠程代碼執行漏洞（CVE-2021-21974），對全球多地未打補丁的 VMware ESXi 部署新型 ESXiArgs 勒索軟件。ESXiArgs 勒索軟件會對 ESXi 服務器上的配置文件進行加密，可能導

14、致虛擬機(VM)無法使用。據悉，意大利、法國、芬蘭、美國、加拿大等國均遭到攻擊。根據安全大數據公司Censys 檢索披露 7，歐洲和北美已經有千臺服務器遭到破壞。奧地利計算機安全應急響應小組也發出警告，稱“至少有 3762 個系統”受到了影響。意大利電信公司也因為該勒索攻擊出現大規?；ヂ摼W中斷。開源勒索軟件支付跟蹤器 Ransomwhere 跟蹤了四筆總價值52023 年重大云安全事件回顧88,000 美元的贖金。2.4 Digital Ocean 存儲桶被公開訪問，印度跨國銀行數百萬數據遭遇泄露ICICI銀行是一家市值超過760億美元的印度跨國企業，在印度各地有5000多個分支機構，并在全球

15、至少 15 個國家設有分支機構。印度政府將 ICICI 銀行的資產命名為“關鍵信息基礎設施”，對其的任何傷害均會影響國家安全，然而其關鍵數據安全性卻依然得不到保障 8。2023 年 2 月，Cybernews 研究團隊發現 ICICI 銀行因其系統使用了 Digital Ocean 的云存儲服務，但并未正確配置存儲桶的訪問控制權限，導致銀行泄露了 360 萬個敏感文件，其中包含銀行用戶的詳細信息、信用卡號、姓名、護照、出生日期、家庭住址、電話號碼、電子郵件、銀行對賬單、現任員工和求職者簡歷等重要信息，Cybernews 研究團隊立即聯系了 ICICI 銀行和印度計算機應急相應小組（CERT-I

16、N），ICICI 第一時間通過修改訪問權限限制了存儲桶的訪問。更詳細的分析請參見研究案例 7：Digital Ocean 存儲桶公開可訪問，印度跨國銀行數百萬數據遭遇泄露2.5 約 3TB 托管至 Azure 上的美國內部軍事電子郵件數據遭至泄露2023 年 2 月 21 日，美國在線新聞網站 TechCrunch 報道稱，美國國防部的一個服務器泄露了約 3TB 美國軍方內部電子郵件數據 9。該服務器托管在微軟為國防部提供的 Azure政務云上，理論上該政務云與其他網絡是物理隔離的，很可能是由于錯誤配置導致郵件服務暴露在了互聯網中并且允許匿名訪問。2023 年 2 月 8 日，這個郵件服務器被

17、 Shodan 掃描發現。安全研究員 Anurag Sen 發現服務器泄露了大量敏感信息，并向 TechCrunch 提供了泄露線索。該服務器存儲了包括內部軍事以及其他安全部門相關的敏感電子郵件數據，其中涉及美國特種作戰司令部（USSOCOM）往來郵件、聯邦雇員安全許可調查問卷等敏感信息。2.6 阿里云數據庫服務被曝嚴重漏洞“BrokenSesame”2023 年 4 月，Wiz 研究團隊在官方博客 43 中披露了一系列被命名為“BrokenSesame”的阿里云數據庫服務漏洞。該漏洞會導致未授權訪問阿里云租戶的 PostgreSQL 數據庫，并且可以通過在阿里云的數據庫服務上執行供應鏈攻擊，

18、從而完成 RCE10。62023 公有云安全風險分析報告綠盟科技星云實驗室研究人員深入研究了阿里云的兩個主流云服務：ApsaraDB RDS for PostgreSQL 和AnalyticDB for PostgreSQL，其中，ApsaraDB RDS 是一個托管數據庫服務，具備自動監控、備份和災難恢復功能，AnalyticDB for PostgreSQL 是一個托管數據倉庫服務。研究人員發現這兩項服務在云隔離方面存在巨大問題。研究人員旨在識別攻擊者如何繞過云服務商設置的安全邊界，并獲取對其他用戶數據的訪問權限。這是一個影響許多托管服務提供商的重大問題：跨租戶劫持。更詳細的分析請參見研究

19、案例 9:阿里云數據庫服務被曝嚴重漏洞“BrokenSesame”2.7 勒索軟件團伙CL0P利用了MOVEit Cloud SQLi零日漏洞：受害機構數量逼近 900 家，影響人數超 2000 萬MOVEit transfer 和 MOVEit Cloud 是 Progress Software 公司生產的托管文件傳輸產品，可對文件進行加密，采用 FTP 或 SFTP 等文件傳輸協議來傳輸數據，提供自動化服務、分析和故障轉移功能，在全球醫療保健行業得到大規模應用。2023 年 5 月 27 日，俄羅斯勒索軟件組織 CL0P 在陣亡將士紀念日 11 當天通過利用 MOVEit transfer

20、 和 MOVEit Cloud 中的零日漏洞（后被披露為 CVE-2023-34362 漏洞）對全球各大企業發起大規模軟件供應鏈攻擊。許多知名企業也受到影響，如殼牌公司、德意志銀行、普華永道、索尼、西門子、BBC、英國航空公司、美國能源部和農業部等。這次大規模攻擊已危及全球超過 900 家私營和公共部門組織，影響人數超過 2000 萬，大約 80%受害者在美國，受影響最大的行業為金融、醫療、教育行業 12。2.8 Toyota Connected 云配置錯誤導致大規模數據泄露長達多年2023 年 5 月 12 日，Toyota Connected Corporation（以下簡稱 TC）宣布，

21、豐田汽車公司外包給 TC 公司的部分數據因云環境設置不正確而遭到泄露。此次數據泄露事件影響約215 萬訂閱豐田服務 T-Connect、G-Link、G-Link Lite 和 G-BOOK 的用戶，泄露的信息包含車輛的位置信息、車輛在上述位置的時間以及車載終端 ID 和車輛識別號 VIN，甚至包含 2016年 11 月 14 日至 2023 年 4 月 4 日期間行車記錄儀拍到的錄像視頻 1314。2.9 丹麥知名云服務被黑，所有數據丟失2023 年 8 月 18 日，丹麥的 CloudNordic/AzeroCloud 云服務托管公司遭到勒索軟件攻擊，黑客關閉了所有系統，包括網站、電子郵件

22、系統、用戶系統、用戶的網站等等。值得注意的是，72023 年重大云安全事件回顧犯罪者曾將贖金定為 6 個比特幣，價值 157,000 美元，但 CloudNordic/AzeroCloud 決定不支付 46。最終這次入侵導致 CloudNordic/AzeroCloud 完全癱瘓，所有用戶的數據丟失，包括備份數據也被抹除，影響了數百家丹麥公司。2.10 微軟研究團隊使用的 Azure Blob 存儲桶意外暴露 38TB隱私數據2023 年 9 月，Wiz 安全團隊公布一起關于 Microsoft AI 研究團隊的數據泄露事件，泄露數據總量達 38TB，泄露數據包括 Microsoft 服務的密

23、碼、密鑰以及 Microsoft 員工的 30,000多條內部 Microsoft Teams 消息 15。這起數據泄露事件的起因是 Microsoft AI 研究團隊在 Github 中開源的一個人工智能模型robust-models-transfer。該模型被存儲在 Azure Blob 中，Microsoft AI 研究團隊同時公開了一個用于下載數據的Azure賬戶共享訪問簽名(SAS)令牌。由于該令牌權限配置錯誤，導致可以通過該令牌對除模型外的 38TB 敏感數據進行讀、寫操作。據悉，該 Azure 賬戶 SAS 令牌于 2020 年 7 月已被公開至 Github 中，并在 2021

24、 年 10月將該令牌的有效期延長至 2051 年 10 月。當前，Microsoft AI 團隊已在 2023 年 8 月替換了存在錯誤配置 SAS 令牌，并完成了該事件潛在影響的調查。更詳細的分析請參見研究案例 8:微軟研究團隊使用的 Azure Blob 存儲桶意外暴露 38TB隱私數據2.11 英國政府承包商使用的 S3 存儲桶泄露大量員工敏感數據2023 年 11 月 15 日，Cybernews 披露英國 MPD FM（之前稱為 Manpower Direct）使用的亞馬遜S3(Simple Storage Service)存儲桶由于錯誤配置泄露了16,000多份包含員工護照、簽證、

25、身份證、駕駛執照等敏感數據文件 16。2.12 小結從上述事件不難看出，云服務配置錯誤、云服務自身漏洞、不安全的供應鏈是導致這些事件的主要原因。其中，由于存儲桶配置錯誤導致的數據泄露事件高達四起，云服務自身漏洞有兩起，供應鏈安全一起，其余則涉及勒索軟件攻擊。本報告的后續章節將圍繞這十大典型云安全事件的風險根因展開，通過案例分析和實際數據為讀者提供一些參考和啟示。03云服務配置錯誤的安全風險分析9云服務配置錯誤的安全風險分析 觀點 1：安全左移過程中，自建倉庫的風險應重點關注，研究表明，暴露在互聯網上的超過 10%鏡像倉庫存在鏡像泄露風險，約 16%代碼倉庫存在未授權訪問漏洞，且絕大部分自建倉庫

26、中泄露的鏡像和源代碼存在不同程度的敏感數據泄露風險。如被利用，可能會對數據擁有者造成較大的經濟和名譽損失。觀點 2：綠盟科技統計的 2023 年重大云安全事件中，約四成是因為人為錯誤配置導致的云存儲桶數據泄露，這些事件暴露了用戶使用存儲桶服務時存在訪問控制配置不當和缺乏加密保護等安全問題。3.1 容器鏡像倉庫泄露風險分析截止 2023 年 11 月，我們對全球暴露的 16661 個主流自建鏡像倉庫進行了研究分析（Harbor 數據占 9042 條，Docker Registry 數據占 7619 條），超過 10%的鏡像倉庫由于錯誤配置（Docker Registry 倉庫占比約 66%，Ha

27、rbor 倉庫占比 34%），其鏡像可被直接拉取，由此泄露的鏡像高達 31000 個。我們對 31000 個泄露的自建倉庫鏡像進行了研究分析，97%的鏡像存在不同程度的敏感信息泄露。泄露的敏感信息中，68%為業務源代碼，這些源碼涉及到政府、醫療、教育、金融、通信等各個行業，6%為口令信息，這些口令涉及數據庫、管理系統、自建倉庫等各種關鍵應用和服務。自建鏡像倉庫泄露通常始于倉庫服務在互聯網上的暴露，如圖 3.1 所示，攻擊者會發現暴露在互聯網中的倉庫，并通過漏洞或錯誤配置進行利用以從倉庫中竊取鏡像，隨后做敏感信息提取，并利用敏感情報再次發起攻擊。102023 公有云安全風險分析報告綠盟科技星云實

28、驗室1231.倉庫掃描2.鏡像竊取3.敏感提取4.攻擊利用圖 3.1 容器自建鏡像倉庫常見攻擊路徑我們發現在自建容器鏡像倉庫中，配置錯誤是導致容器鏡像泄露的主要原因之一，如Harbor 的項目訪問權限 17、Docker Registry 的認證機制 18 等，這些配置項若被錯誤設置為公開訪問權限，則會導致大量鏡像被未授權訪問和拉取。提及 Harbor 倉庫時，不得不提 CVE-2022-46463，這個“漏洞”被誤認為是未授權訪問漏洞，但不久前 Harbor 官方回復這個“漏洞”實際上是一個功能特性，而非真實漏洞。該特性可能會導致設置為“公開”的項目中的鏡像被未授權訪問和拉取。如圖 3.2

29、所示，盡管在 Harbor 項目創建頁面有詳細的說明，但使用者可能會混淆“公開”的定義，并忽略訪問級別相關的文字說明，從而將私有項目的訪問級別配置為“公開”。圖 3.2 Harbor 公開項目特性設置11云服務配置錯誤的安全風險分析默認情況下，由于 Docker Registry 的認證機制不會開啟，因而攻擊者可以直接調用官方提供的 API 接口獲取鏡像倉庫的項目列表和版本信息，進而可獲取鏡像的詳細信息，最終竊取鏡像。接下來，我們將分享若干鏡像倉庫泄露案例，本報告中所有研究工作均在政府主管部門授權指導下進行，相關案例已上報監管部門并已整改。（注：下述研究案例 1-12 包括綠盟科技星云實驗室研

30、究的案例以及互聯網已公開暴露的案例。）研究案例 1：某軟件服務公司 Harbor 鏡像倉庫泄露 1.46TB 敏感鏡像某軟件服務公司的 Harbor 鏡像倉庫暴露在互聯網中，并且該鏡像倉庫由于配置錯誤，可直接獲取鏡像列表，這些鏡像無需登錄便可以直接從互聯網上進行拉取。泄露的鏡像中包含大量的業務源代碼，經敏感識別分析，我們發現其中一個鏡像泄露了該倉庫的管理員賬號和密碼。如圖 3.3 所示，總共約有 1.46TB 的私有鏡像被間接泄露。由于倉庫管理員信息的泄露，造成了雪崩效應，導致了更嚴重的敏感數據泄露事件。圖 3.3 某軟件服務公司泄露的鏡像倉庫研究案例 2：某醫藥 O2O 運營管理公司自建鏡像

31、倉庫泄露全國多省門店、藥品、會員消費等敏感信息某醫藥 O2O 運營管理公司的自建鏡像倉庫由于配置錯誤，導致數百個容器鏡像泄露。如122023 公有云安全風險分析報告綠盟科技星云實驗室圖 3.4 所示，這些泄露的鏡像中包含大量業務源碼、以及賬號密碼等敏感信息。圖 3.4 某醫藥 O2O 運營管理公司泄露的口令信息值得關注的是，鏡像中的配置文件泄露了該公司運營管理平臺的登錄口令，由于該運營平臺直接暴露在互聯網中，因而可被任意進行訪問。如 3.5 所示，該賬號泄露了全國超過 10個省市入駐藥店的運營情況、會員信息、醫藥消費記錄等大量敏感信息。13云服務配置錯誤的安全風險分析圖 3.5 某醫藥 O2O

32、 運營管理公司運營數據泄露如果不法分子獲取了這些敏感信息，他們可以輕松地利用醫藥消費數據對消費者或藥店進行資產畫像，從而實施精準攻擊，造成巨大的社會影響。研究案例 3：多所高校管理系統包括源碼、數據庫、視頻監控口令等大量敏感信息被泄露某校園安全軟件服務公司的自建容器鏡像倉庫泄露多所高校業務系統的源碼，其中多個疑似管理節點的接入賬號口令、視頻監控系統登錄賬號密碼和疑似校園安全事件管理數據庫口令被泄露。如圖 3.6 所示，鏡像中的配置文件泄露了疑似校園安全事件管理數據庫的登錄信息，該數據庫涉及一些教師的賬號信息、班級情況以及安全事件等數據。142023 公有云安全風險分析報告綠盟科技星云實驗室圖

33、3.6 某鏡像泄露的數據庫信息通過進一步研究，我們發現該組織在關聯鏡像中還疑似泄露了如圖 3.7 所示的視頻監控管理系統賬號信息。圖 3.7 某高校業務鏡像疑似泄露視頻監控管理系統賬號信息這些泄露信息如果被攻擊者所掌握，理論上可以控制管理的視頻設備，以及篡改系統數據，這將對學校造成一定的影響。15云服務配置錯誤的安全風險分析期望通過分享這些案例，能提升讀者對鏡像泄露的重視，并加強鏡像安全管理措施。3.2 源代碼倉庫泄露風險分析如 Gitblit、Gogs、Gitea、Gitlab 等主流自建代碼倉庫因為部署便捷、使用方便等優勢，在許多環境中得到廣泛應用。然而，我們發現許多組織對所采用的代碼托管

34、軟件的特性了解并不充分。大量的自建代碼倉庫由于配置錯誤存在未授權訪問的風險，這是攻擊者獲取自建代碼倉庫最低成本的途徑之一。我們對全球暴露的 80578 個主流自建代碼倉庫進行了研究分析（Gitblit 數據占 4114 條，Gogs 數據占 13938 條，Gitea 數據占 24318 條，Gitlab 數據占 38208 條），約 16%的代碼倉庫存在未授權訪問風險（Gitblit 數據占 40%，Gogs 數據占 20%，Gitea 數據占 16%，Gitlab 數據占 11%），超過 150000 個源代碼可被直接拉取。借助敏感識別技術，我們對這些泄露的源代碼項目進行了研究分析，54%

35、的源代碼項目存在不同程度的敏感信息泄露。泄露的敏感信息中，91%為業務源代碼，這些源碼涉及到政府、醫療、教育、金融、通信等各個行業；7%為身份證、銀行號、手機號等其他敏感數據；2%為關鍵口令信息，這些口令涉及數據庫、管理系統、自建倉庫等各種關鍵應用和服務。盡管在過去多幾年里我們一直致力于向大眾提醒“大部分軟件的默認配置是不安全的19”、“大部分的應用是缺乏防護的 1”，但每年仍然有相當數量的泄露事件發生。接下來，我們將分享若干代碼倉庫泄露案例，期望自建代碼倉庫的安全風險能引起更多關注。研究案例 4：某文旅軟件服務商自建代碼倉庫泄露 26 個產品和用戶項目源碼等敏感數據 某組織的 Gitea 代

36、碼倉庫長期暴露在互聯網中，并且由于配置錯誤，無需認證便可以從互聯網上獲取該倉庫的所有項目數據。如圖 3.8 所示，我們從其中的一個“公司年會抽獎”項目配置文件中發現了疑似組織名稱，結合實體分析技術，我們最終確認該代碼倉庫為某文旅軟件服務商所有。162023 公有云安全風險分析報告綠盟科技星云實驗室圖 3.8 某文旅軟件服務商年會抽獎項目配置該倉庫泄露的項目多達 26 個，這些項目幾乎涵蓋了其官網介紹中的所有合作案例。我們選取了某市的一個文旅項目進行敏感分析，除大量業務代碼外，源碼中存在大量的關鍵口令信息，如圖 3.9 所示，其中的幾塊代碼段泄露了互聯網服務器和互聯網數據庫的地址和賬號口令等關鍵

37、敏感信息。該倉庫中其他項目中還存在大量的類似敏感信息。圖 3.9 某文旅項目泄露的關鍵賬號口令信息我們對部分泄露的敏感信息進行了有效性驗證，發現其中的一部分互聯網資產仍然存活，且沒有得到有效的安全防護。17云服務配置錯誤的安全風險分析研究案例 5：某大數據解決方案服務商自建代碼倉庫泄露大量業務源碼和疑似城市統計數據我們測繪到，某大數據解決方案服務商自建代碼倉庫暴露在互聯網中，如圖 3.10 所示，由于配置錯誤，所有人無需認證便可以直接獲取所有項目信息和源代碼。值得關注的是，該公司為政府、企業提供人口統計、旅游、交通、公共安全等信息化解決方案。圖 3.10 某大數據解決方案服務商自建代碼倉庫泄露

38、該倉庫泄露了前端、后端、APP、數據處理等 9 個項目的源代碼，我們選取了部分項目進行源代碼敏感分析，幾乎每個項目均泄露了不同程度的敏感數據。如圖 3.11 所示，我們在配置文件中發現了某業務系統的后臺數據庫賬號口令信息。該信息二次泄露了大量的疑似城市交通信息以及系統賬號口令信息。182023 公有云安全風險分析報告綠盟科技星云實驗室圖 3.11 某大數據解決方案服務商數據庫信息泄露研究案例 6：某大數據集團下屬科技公司自建代碼倉庫泄露某省國資委、城投、水務等多個敏感項目數據我們發現某科技公司自建代碼倉庫暴露在互聯網中，該公司屬于某省大數據集團下屬企業，其業務涉及多市的信息化重點項目。該倉庫直

39、接泄露了 11 個項目的源代碼，這些項目涉及某省國資委、城投、水務等多個組織。我們對其中的部分項目進行了敏感識別分析，大部分的項目均泄露了不同程度的敏感數據。如圖 3.12 所示，項目中的一個配置文件中泄露了其互聯網數據庫的賬號口令信息，該口令泄露了大量疑似國資委的敏感數據。19云服務配置錯誤的安全風險分析圖 3.12 某大數據集團下屬科技公司數據庫泄露3.3 存儲桶泄露風險分析由于人為錯誤配置，存儲桶數據往往可以被公開訪問，這意味著只要在瀏覽器中輸入了正確的域名，世界上任何人都可以訪問這些數據。這種情況下，存儲桶的數據可能會被惡意攻擊者輕易發現并利用。公開訪問的存儲桶數據可能包含各種敏感信息

40、，例如個人身份信息、金融數據、商業機密等。這些數據泄露不僅會損害個人隱私和商業利益，還可能導致法律訴訟和聲譽損失。在報告的第二章中，我們統計的 2023 年十大云安全事件中四起事件都是和云存儲桶數據泄露直接相關的，這表明云存儲桶的安全性在當前云計算環境中仍然面臨著嚴重的風險和挑戰。在下文，我們將對這些具有共性的重大安全事件進行詳細的研究分析，以深入探討事件的背景、原因、影響以及可能的應對措施。通過對這些事件的深入分析，我們希望能夠從中汲取經驗教訓，加強對云安全的認識，提高對云存儲桶數據泄露等安全威脅的應對能力，以保護用戶的隱私和數據安全。研究案例 7：Digital Ocean 存儲桶公開可訪

41、問，印度跨國銀行數百萬數據遭遇泄露如前文提到，泄露的敏感文件中包含銀行用戶的詳細信息、信用卡號、姓名、護照、出生日期、家庭住址、電話號碼、電子郵件、銀行對賬單、現任員工和求職者簡歷等重要信息，202023 公有云安全風險分析報告綠盟科技星云實驗室如圖 3.13-3.16 所示。圖 3.13 云存儲中泄露文件總數的屏幕截圖圖 3.14 護照泄露截圖21云服務配置錯誤的安全風險分析 圖 3.15 銀行對賬單泄露截圖222023 公有云安全風險分析報告綠盟科技星云實驗室圖 3.16 泄露的填寫 KYC 表格的屏幕截圖 20除此之外，CloudSEK 聯合創始人兼首席執行官 Rahul Sasi 還表

42、示 21，泄露的存儲桶還包含來自其他幾家公司的數據，不僅僅是只有 ICICI 銀行的數據。Spaces 是 Digital Ocean 提供的對象存儲服務，從其官方 API 文檔 22 可以看出，Spaces 對象存儲與 Amazon S3 對象存儲服務兼容，用戶可通過設置 ACL 策略以完成對存儲23云服務配置錯誤的安全風險分析桶的訪問控制，以下是一組公有讀取存儲桶的 ACL 示例：xxxxxxxx http:/ READ xxxx FULL_CONTROL 從上述示例 xml 文件中的 標簽值(FULL_CONTROL)可以看出，該策略賦予了存儲桶的公開訪問權限。ICICI 銀行及其用戶的

43、敏感數據就是因為類似的這種配置錯誤而被發現暴露在可公開訪問的 Digital Ocean 存儲桶中，“公開訪問”也就意味著任何人，無論是否擁有 Digital Ocean 賬號，只要知道文件的 URL，就可以訪問和下載這些文件而無需任何特別的權限和身份認證。Cybernews 的研究人員提到“此類敏感信息可能會損害 ICICI 銀行的聲譽，并可能泄露銀行內部流程的細節，并危及其用戶和員工及其數據的安全?！比缇W絡犯罪分子可以使用被盜取的憑據和個人數據在用戶不知情的情況下以個人的名義開設賬戶，進行轉賬和實施信用卡欺詐，再如網絡犯罪分子可在暗網上出售隱私數據，ICICI 銀行可能成為數據泄露的受害者

44、。242023 公有云安全風險分析報告綠盟科技星云實驗室為防止此類數據泄露，建議企業做到如下幾點：1.為創建的云存儲桶配置合理的訪問權限；2.為用戶提供識別和避免電子郵件、網站、電話的欺詐行為的指導，并時刻敦促用戶向銀行及時報備此類可疑活動；3.若受到隱私泄露情況，應及時更改登錄密鑰，設置強密碼，避免弱密碼被暴破的風險研究案例 8:微軟研究團隊使用的 Azure Blob 存儲桶意外暴露 38TB 隱私數據Azure Blob 存儲桶是由 Microsoft 提供的云對象存儲解決方案，適用于存儲大量的非結構化數據，例如文本、圖像或二進制數據等。Azure 存儲賬戶包含了所有 Azure 存儲數

45、據對象，包括 Blob、文件、隊列和表，同時為 Azure 存儲數據提供了一個唯一的命名空間 23。共享訪問簽名(SAS)令牌是一種簽名 URL，是一種臨時訪問憑證，是 Azure 提供的一種對存儲賬戶中資源進行安全委托訪問的方式。使用 SAS 可以精細控制用戶端訪問 Azure 對象存儲數據的方式，例如：1.客戶端可以訪問哪些資源（Blob 容器、表、隊列或文件共享）；2.SAS 的有效期限。Azure 存儲支持三種類型的共享訪問簽名 SAS：用戶委托 SAS、服務 SAS 和賬戶 SAS。用戶可以通過創建賬戶 SAS 令牌進行 Blob 存儲數據共享，并且能夠設置該令牌的訪問權限和有效時間

46、。在有效時間內，任何人都可以通過賬戶 SAS 令牌的 URL 按照訪問權限訪問相關資源。在此次事件中，Microsoft AI 研究團隊采用了 Azure Blob 存儲和賬戶 SAS 令牌作為模型共享的方式，并在 GitHub 中公開了數據存儲的 SAS 令牌 URL。不幸的是，由于 Microsoft AI研究團隊在生成賬戶 SAS 令牌時設置了不安全的訪問權限，即該令牌具有整個存儲賬戶的訪問權限，如圖 3.17 所示 15，導致用戶不僅可以通過該 SAS 令牌訪問模型，甚至可以訪問存儲賬戶中的額外數據，其中包含了 38TB 的私人文件。除了權限設置過于寬松外，該令牌還被配置為 Blob

47、存儲桶的“完全控制”權限，這意味著惡意用戶可以修改、刪除現有的模型和其他數據，甚至可以進行模型的投毒攻擊。25云服務配置錯誤的安全風險分析圖 3.17 SAS 令牌權限配置錯誤導致此次事件的主要原因是 SAS 令牌權限配置錯誤，歸根到底還是臨時憑證的權限安全問題。因此，在使用云廠商的臨時憑證時應從以下幾個安全方面來考慮：1.應做到對云賬戶下所有臨時憑證的可見與監控，避免“影子”憑證對賬戶、資源造成嚴重危害，如臨時憑證的使用途徑與其具備的權限應嚴格匹配，應避免對臨時憑證進行過度授權。再如臨時憑證的過期時間應嚴格控制，應做到定期更換以避免較長時間的持續授權；2.應避免使用臨時憑證作為數據共享的“鑰

48、匙”；3.應使用憑證掃描工具檢測互聯網互聯網暴露面（APP、網站和 GitHub 存儲庫等）中泄露的云憑證；4.應使用諸如云安全態勢管理（Cloud Security Posture Management，CSPM）等工具來持續監控、審計云賬號下憑證的權限情況3.4 小結本章深入探討了云服務配置錯誤導致的安全風險，特別是自建容器鏡像倉庫、自建代碼倉庫和存儲桶泄露風險。通過具體的研究案例分析，我們發現由于配置錯誤或對云服務安全262023 公有云安全風險分析報告綠盟科技星云實驗室性認識不足等原因，大規模的敏感數據仍然被持續泄露。這些泄露的個人隱私信息、商業機密和關鍵基礎設施等敏感數據很可能對企業

49、聲譽以及國家安全造成嚴重影響。針對這些風險，建議采取以下措施加強云服務的安全性：采取最小化暴露原則，避免不必要的互聯網暴露，確保只有授權用戶才能訪問對應的數據；定期對云服務進行安全審計和配置核查，及時發現并修復潛在的安全漏洞和錯誤配置；訂閱專業的 EASM 服務，監控和保護暴露資產；加強對所選用云應用特性的理解和認識，確保使用云服務的團隊了解如何安全配置和管理云資源，提高團隊成員對數據保護重要性的認識，并定期進行安全培訓；通過采取上述措施，可以有效降低云服務配置錯誤導致的安全風險，確保敏感數據免受泄露，維護企業和用戶的核心利益。04云服務自身的安全風險分析282023 公有云安全風險分析報告綠

50、盟科技星云實驗室 觀點 3：SaaS 服務作為一種靈活的云服務模型，涵蓋各種服務類別，不同的服務面臨不同的風險，其中影響較大的風險是租戶間的隔離不夠徹底，進而危害其他云租戶的業務。觀點 4：IaaS 服務通常提供大規模的計算存儲資源，云租戶需要自行搭建服務，其風險主要集中在云租戶自身的操作配置可能不合規，或未采用了最佳安全實踐。企業可以通過租用公有云資源來存儲和處理數據，與私有云相比，公有云的安全問題更加復雜：1.公有云中的數據可能會面臨更多的泄露風險。相較于原有的 IT 基礎設施，部署在公有云上會擴大攻擊面。攻擊者可以利用各種方式來獲取企業在公有云中存儲的敏感數據。例如，企業的存儲桶配置不當

51、將導致被任意用戶訪問的風險。2.公有云環境面臨跨租戶劫持的風險。由于公有云面向多租戶的特性，企業租賃云服務就會面臨多租戶共享同一云基礎設施的場景，進而會導致跨租戶劫持風險，如攻擊者可以利用漏洞從一個云租戶入手，得手后再攻擊其他租戶，進而影響到其它租戶的業務。3.數據所有權和廠商鎖定風險：公有云服務模型中，租戶數據存儲在云服務商的服務器上，租戶需要明確了解他們在合同中對數據的所有權，并且在云服務商終止服務時，需要知曉如何獲取數據的權限，以此避免由于數據無法遷移或鎖定而導致的依賴性問題。近年來伴隨云計算的興起，針對公有云的攻擊事件層出不窮，本章我們將通過對當下安全事件的原理分析并結合已有的安全研究

52、成果，來介紹其對應的風險。4.1 跨租戶劫持風險分析我們認為，如何打破租戶間的隔離，一直是公有云 SaaS 服務攻擊的重點。由于 SaaS 服務天然為多租戶環境，因此跨租戶劫持成為用戶常面臨的一大風險，跨租戶劫持風險通常指的是在多租戶環境中存在的安全威脅，其中一個租戶可能試圖獲取或篡改另一個租戶的數據或資源。租戶是指在同一云服務或系統中獨立運行的不同組織、用戶或應用程序。接下來，我們將結合 2023 年相關安全事件和已有研究數據，來分析由于租戶間隔離不當29云服務自身的安全風險分析導致的跨租戶劫持風險。研究案例 9:阿里云數據庫服務被曝嚴重漏洞“BrokenSesame”原理簡述1.Analy

53、ticDB for PostgreSQL 容器逃逸漏洞1）容器提權從一個 Postgres 的普通用戶開始，第一步研究人員可通過定時任務提權到數據庫容器的root 權限。容器內有一個每分鐘執行/usr/bin/tsar 的定時任務。圖 4.1 定時任務通過對該二進制文件執行 ldd 命令，可以看到它會從自定義的位置/u01 加載共享庫。而當前用戶 adbpgadmin 對/u01 目錄具有寫權限。研究人員可以通過對此共享庫文件的覆蓋，來讓下次定時任務執行時，以 Root 身份執行這個二進制文件。圖 4.2 鏈接庫鏈接狀態2）容器逃逸302023 公有云安全風險分析報告綠盟科技星云實驗室研究人員

54、拿到數據庫容器 Root 權限后，可通過阿里云站點開啟 SSL 加密功能，這一步驟會創建 SCP 和 SSH 等進程，進而可利用進程注入方式完成容器逃逸至宿主機（Kubernetes Node）。3）供應鏈攻擊由于存在權限配置問題，研究人員控制宿主機（Kubernetes Node）后可以通過對注冊表進行寫操作，覆蓋其他用戶的容器/鏡像，完成供應鏈攻擊。2.ApsaraDB RDS for PostgreSQL 命令注入漏洞1）容器逃逸 4445阿里云提供了一個驗證 PostgreSQL 是否可以正常升級的功能，來幫助用戶避免數據庫損壞。針對此功能，研究人員發現其存在命令注入漏洞，可以在負責此

55、功能的容器中執行任意代碼。隨后利用 core_pattern 來進行容器逃逸。2）供應鏈攻擊研究人員發現在控制宿主機（Kubernetes Node）后，此服務的私有容器注冊表存儲庫和用于 AnalyticDB 的相同，可以使用 AnalyticDB 的憑證完成對 ApsaraDB RDS 的供應鏈攻擊。事件分析當設計具有多個容器的服務時，確切地定義他們如何協同工作是至關重要的。研究人員在對阿里云的 ApsaraDB RDS 和 AnalyticDB 進行的深入研究中，發現了一些關鍵的安全漏洞，這些漏洞暴露了多租戶環境中可能存在的風險，以下是風險描述及建議：1）Linux 容器之間的隔離不充分

56、在 ApsaraDB 和 AnalyticDB 這兩項服務中，數據庫容器與 Kubernetes Pod 中的其他業務容器共享不同的 Linux 命名空間。由于共享 PID 命名空間，使得容器能夠訪問業務容器和文件系統中的其他進程。另外，該漏洞的嚴重性還包括可使惡意攻擊者橫向移動到業務容器。建議：利用容器隔離技術確保容器之間相互獨立運行，避免了應用程序或服務之間的沖突和干擾，從而提高安全性、資源利用率和可管理性。2）容器逃逸風險高在 ApsaraDB RDS 的案例研究中，我們發現由于 Kubernetes 節點托管多個用戶數據庫的31云服務自身的安全風險分析特性，如果攻擊者成功執行了容器逃逸

57、，就能夠訪問其他租戶的數據。建議：在 Pod 中使用最小特權的容器，避免賦予容器過多的權限。使用 SecurityContext 25 配置來限制容器的權限，例如限制特權模式、能力和掛載的文件系統等；采用 gVisor1或 Kata 安全容器2來緩解容器逃逸。3）Kubernetes 權限配置過高在 ApsaraDB 和 AnalyticDB 這兩項服務中，由于 Kubernetes 集群是多租戶的，如果Kubernetes 服務賬號（Service Account）權限過高，則可以訪問其他租戶的資源。建議：使用最小權限原則，如使用基于角色的訪問控制（Role-based access con

58、trol，RBAC）技術限制集群資源的訪問權限。4.2 權限配置錯誤風險分析權限配置問題通常是因為賦予了云租戶過大的權限造成的，使得惡意用戶可以超越當前限制，獲取到高危權限，并利用 SaaS 服務的產品特性對宿主機產生影響。該問題主要體現在云服務廠商對用戶的權限限制不當和對 SaaS 服務的產品特性限制不當等 26。為了讓讀者對權限配置錯誤導致的風險有更清晰的理解，下面我們將通過三個具體案例分析說明。研究案例 10:微軟 Azure Active Directory 由于配置錯誤導致 Bing 服務受到嚴重影響Microsoft 在 Azure 中提供了自己的單點登錄（SSO）服務，即 AAD

59、（Azure Active Directory），它是在 Azure App Services 或 Azure Functions 中創建的應用程序中最常見的身份驗證機制。AAD 提供不同類型的帳戶訪問：單租戶、多租戶、個人帳戶或以上兩者的組合。單租戶應用程序只允許來自相同租戶的用戶為該應用程序發放 OAuth 令牌。另一方面，多租戶應用程序允許任何 Azure 租戶為它們發放 OAuth 令牌。因此，應用程序開發人員必須在其代碼中檢查令牌，并決定哪個用戶應該被允許登錄。研究人員掃描了 Azure App Services 和 Azure Functions 以查找暴露的端點，并在其中發現了一

60、個典型的“責任共擔”47 混淆案例。如圖 4.3 所示，為 Azure 的一個 APP Functions的示例 AAD 配置。這些托管服務允許用戶通過點擊按鈕添加身份驗證功能，對于應用程序所有者來說，這是一個理所當然的過程。然而，該服務僅確保了令牌的有效性。對于應用程序1 https:/gvisor.dev/docs/2 https:/katacontainers.io/docs/322023 公有云安全風險分析報告綠盟科技星云實驗室所有者來說，無法通過 OAuth 聲明驗證用戶的身份，并相應地分配訪問權限。圖 4.3 Azure AAD 配置 對于單租戶身份驗證，影響僅限于應用程序的租戶-

61、來自相同租戶的所有用戶都可以連接到該應用程序。但對于多租戶應用程序，暴露的范圍就廣泛得多-沒有進行適當的驗證，任何 Azure 用戶都能夠登錄到該應用程序。研究人員掃描的所有多租戶應用程序中，有 25%存在認證繞過漏洞。以“Bing 問答”應用程序為例，微軟的錯誤配置使其最關鍵的應用程序暴露給了互聯網上的任何人。研究案例 11：某云服務商 A 數據庫服務 RDS PostgreSQL 由于權限配置錯誤導致宿主機受到命令執行風險錯誤的權限定義導致非超級用戶獲取了 schema pg_catalog 下創建函數的權限（在PostgreSQL 數據庫中，pg_catalog 是一個系統模式（syst

62、em schema），用于存儲有關數據庫內部結構和元數據的信息）。在創建 PostgreSQL 插件時，執行插件的 SQL 的用戶角色會獲得超級用戶權限。通過利用函數調用的優先級特性，攻擊者執行自定義的函數，嵌入提權SQL 語句，最終成為數據庫超級用戶。如圖 4.4 所示，整個流程分為三步：33云服務自身的安全風險分析1.我們在申請到數據庫服務后，發現初始用戶在系統 schema pg_catalog 下具備創建函數的權限；2.我們調研了數據庫擴展支持情況，發現部分擴展存在使用 pg_catalog 模式下系統函數的情況；3.我們隨后利用 PostgreSQL 函數優先級設定，構造特定系統函數

63、并嵌入提權邏輯，在安裝擴展后即可提升為超級用戶。讀取用戶權限查看數據庫可用擴展查看原始sql確定待嵌入函數構造提權邏輯并創建pg_catalog下特定函數惡意用戶數據庫用戶權限表數據庫擴展擴展權限超級用戶1253647創建圖 4.4 某云服務商 A 風險發現圖研究案例 12：某云服務商 B 數據庫服務 RDS PostgreSQL 由于權限配置錯誤導致宿主機受到命令執行風險錯誤的權限定義允許非超級用戶在 schema pg_catalog 下創建并替換函數。攻擊者能夠通過服務器日志，確定超級用戶在日常運維中會執行的函數。一旦確定目標函數，攻擊者可以替換該函數并嵌入提權 SQL 語句。當該函數下

64、次被調用后，攻擊者即可成為數據庫超級用戶。如圖 4.5 所示，整個流程分為三步：342023 公有云安全風險分析報告綠盟科技星云實驗室1.我們在申請到數據庫服務后，發現在初始用戶在系統 schema pg_catalog 下具備創建修改函數的權限；2.我們審計系統日志后發現存在超級用戶使用特定系統函數的情況；3.我們替換該系統函數并嵌入提權邏輯，隨后等待一段時間即可提升為超級用戶。讀取用戶權限查看服務器日志查看日志確定待嵌入函數提權邏輯嵌入函數惡意用戶數據庫用戶權限表服務器日志數據庫函數表權限超級用戶1253647等待圖 4.5 某云服務商 B 風險發現圖我們在成為超級用戶后，發現若數據庫實例

65、被禁用 program 特性（允許數據庫的特定用戶在 PostgreSQL 環境中執行任意代碼），可利用 PostgreSQL 特權用戶調用 C 函數特性，創建數據庫 C 類型函數，從而獲取到命令執行操作，如圖 4.6-4.7 所示：圖 4.6 公有云 B 宿主機命令執行35云服務自身的安全風險分析圖 4.7 公有云 B 宿主機命令執行數據庫越權問題說明當前數據庫用戶權限機制可能存在漏洞。在多租戶共享數據庫服務的情況下，云租戶無法限制特定用戶的讀取和使用權限，進而產生越權風險。此外，以上案例表明云服務商需要加強對宿主機的安全措施，包括網絡隔離和權限分割，防止惡意云租戶利用宿主機作為跳板，跨租戶

66、劫持其它云租戶服務或深入核心生產業務。4.3 小結云安全實踐在很多方面與傳統的 IT 和網絡安全實踐相似，但是存在一些重要差異。與傳統的 IT 安全不同的是：云安全通常由共同責任模型控制，即云服務商負責管理底層基礎架構（例如，云存儲服務、云計算服務、云網絡服務）的安全，云租戶則負責管理虛擬機管理程序之上的所有內容（例如訪客操作系統、用戶、應用程序，數據）的安全。攻擊者可能嘗試利用如 Puppet、Chef 和 Ansible 等基礎設施即代碼(Infrastructure as Code，IaC)工具來發起攻擊和中斷服務，因而云租戶必須制定各種安全措施，以保護基于云的應用程序和數據并降低安全風

67、險。Gartner 認為云安全是需要考慮的，但是更多的不是一味地評估云數據中心是否安全，而是到底如何安全使用云，即企業應該把重心放在自身如何進行應用的構建，從而運用云的最佳實踐，并逐步完善云安全管理能力 27。用戶在使用公有云各類服務時應對這些風險保持警惕，與云服務商建立強有力的合作關系，并采取適當的安全措施來確保其數據和業務的安全性。企業業務系統上云不是一蹴而就的，也不是一帆風順的。建議首先要對數據進行分類，Gartner 認為數據可以分為以下四類：公共數據、內部數據、機密數據、合規數據。公共數據，比如公司網站上的數據，是可以在公共平臺上發布的;內部數據，就是內部使用的數據，如電話號碼簿;機

68、密數據，比如未發布的財務報表、未來合并或并購的數據等;362023 公有云安全風險分析報告綠盟科技星云實驗室合規數據，即與合規相關的數據。在上云過程中，建議從前兩個數據開始，以驗證上云過程是否可以，并在此過程中逐步構建自己的上云能力，然后逐步完善云安全管理能力。最后，云安全相對傳統安全進行了顛覆，但并不是完全排他。首先，不是所有的應用都會上云，原有的一些安全舉措仍然有效;其次，上云后建議打開云原生的安全管控能力，包括對工作負載安全或者對用戶訪問行為分析，云上提供的數據相對很全面;最后，如果采用的是多云或混合云的部署模式，建議考慮使用第三方工具把云安全管理起來。05連接云服務的第三方供應鏈安全風

69、險分析382023 公有云安全風險分析報告綠盟科技星云實驗室 觀點 5：近年敏捷開發模式流行，但開發者安全意識缺失，造成大量 DevOps 組件服務暴露在互聯網上，不同程度帶有 N Day 漏洞。這些漏洞可能來自于組件本身，或來自擴展組件功能的第三方插件，其客觀上增加了 DevOps 的攻擊面，特別是數據泄露的風險。5.1 DevOps 與云計算云計算敏捷、彈性的特性促使企業紛紛上云，這使得云應用自身的開發、部署也逐漸遵循開發運營一體化（DevOps）的原則。一方面云計算為 DevOps 提供了靈活、可擴展的基礎設施和服務支持。另一方面，DevOps 也通過自動化的持續集成、持續部署，更好地適

70、應云計算的快速、靈活和彈性的特點，加速了云計算的落地與實踐。因此，云計算與 DevOps兩者相輔相成，密不可分。5.2 DevOps 風險分析近年來件供應鏈安全事件層出不窮，如 2021 年的 Codecov 供應鏈攻擊事件。該事件直接導致近 3 萬用戶的隱私數據泄漏。Codecov 是一款國外軟件審計平臺，該平臺被部署在云上作為 CI/CD 工作流中的一環。攻擊者利用 Codecov 鏡像 Dockerfile 中的錯誤配置提取Bash Uploader 腳本（用戶可通過該腳本上傳測試數據）中的訪問憑證，進而通過該憑證修改用戶的 Bash Uploader 腳本 28，在長達 1000 多行

71、的 Bash Uploader 腳本中添加如下兩行代碼 29：圖 5.1 Bash Uploader 腳本中注入的惡意代碼上述代碼會將 CI 過程中所有的環境變量發送至第三方服務器，這些環境變量中可能包含 Git 訪問憑證、API Key 等敏感信息和密鑰，攻擊者可以通過這些憑證訪問更多的服務、數據和應用程序代碼。不難看出云服務的第三方供應鏈安全風險是極大的。DevOps 通常涉及八個階段：計劃、編碼、測試、構建、發布、部署、運營及監控，每個階段均會涉及大量組件，這些敏感數據往往會成為巨大的攻擊杠桿。一旦讓攻擊者有機可趁，可能會進一步導致云計算環境的數據泄露、服務中斷、供應鏈安全等風險，從而危

72、及系統的可用性、機密性和完整性。39連接云服務的第三方供應鏈安全風險分析圖 5.2 CI/CD 管道示意圖為了更深入了解 DevOps 風險，我們從數據流的角度將 DevOps 流程中各個階段產生的風險進行了匯總，主要分為以下幾部分：CI/CD 管道接入源碼倉庫的風險通常情況下，CI/CD 工具根據用戶自定義的管道流程，在開發者進行 git push/pull 等操作時觸發接入源碼倉庫，在接入過程中由于源碼倉庫自身提供多種接入方式，進而擴大了風險面，圖 5.3 展示了 Gitlab 提供的幾種訪問途徑：圖 5.3 源碼倉庫訪問途徑可以看出除了常規的源碼訪問（push/pull/merge re

73、quest 等）、Web 訪問以及 API 訪問，Gitlab 還提供 Webhook 訪問。在第三方開發團隊對源碼倉庫進行 push/pull 操作時，若未對源碼倉庫接入進行有效認證，則可能會導致本地代碼在 CI/CD 以外的環境中運行，進而造成402023 公有云安全風險分析報告綠盟科技星云實驗室源碼泄露的風險。引入第三方開源組件的風險關于引入第三方開源組件的風險，通常包含以下四部分內容：開源組件自身漏洞導致的風險:許多開源組件自身存在漏洞，不同風險級別的漏洞會導致 CI/CD 環境面臨不同程度風險，例如若開源組件存在 RCE 漏洞，攻擊者則可能利用該漏洞獲取 CI/CD 管道中的環境變量

74、，進而獲取 Gitlab 或 Github 的有效訪問憑證，最終接管整個源碼倉庫，造成巨大安全風險。不安全的開源組件管理導致的風險:在 CI/CD 管道中，我們通常會引入第三方開源組件對項目依賴項進行構建管理。例如 Java 項目中，通常會引入 Maven 倉庫，若我們的項目直接從 Maven 中央倉庫進行拉取，我們就無法確定是否引入了含有漏洞的組件，進而可能導致組件漏洞被攻擊者利用的風險。攻擊者為開源組件添加后門程序導致的風險:若攻擊者擁有訪問開源組件倉庫的權限，進而可以通過為開源組件添加惡意后門程序，以重新對外發布的形式，引發大規模供應鏈攻擊的風險。若用戶的項目源碼中引入了含有后門的開源組

75、件，攻擊者則有可能利用該漏洞對CI/CD 環境進行探測，進而導致整個環境淪陷的風險。構建階段的風險構建階段，CI/CD 管道通常會引入插件對源碼以及第三方開源組件代碼進行構建。這類插件實際上也運行在 CI/CD 環境中，對于開發者而言，插件是不受信任的，含有漏洞的插件可能被攻擊者利用進而訪問到 CI/CD 管道中產生的數據，并將數據傳送至第三方服務器。上述提到的 Codecov 供應鏈事件中，受害者下載了攻擊者精心注入惡意代碼的文件，導致 CI/CD 中的環境變量泄露，攻擊者可以利用這些環境變量竊取受害者隱私數據，造成巨大影響。測試階段的風險自動化測試是 CI/CD 管道中必經的一環，自動化測

76、試常包含集成測試、單元測試、安全測試這幾類流程，CI/CD 工具會調用測試插件（可能來自 CI/CD 環境外部或內部）進行測試，例如 Gitlab 的 CI/CD 管道默認支持引入開源代碼審計工具 bundler-audit、gemnasium 等。這些開源工具是否可信是我們需要關注的重點，如測試階段產生的流量是在 CI/CD 環境內部還是外部，若是外部將不受 DevOps 實施者的控制，可能進而會導致測試流量被代理到第三方服務器的風險，再如當測試階段完成后，測試結果最終存儲在哪里，若存儲在外部，也會41連接云服務的第三方供應鏈安全風險分析導致數據泄露的風險。此外，風險漏洞管理也十分關鍵，如當

77、 Gitlab 進行鏡像掃描后產生了一系列待修復的漏洞，誰擁有什么權限訪問這些漏洞很重要，若管理員分配了錯誤的權限，則可能導致未授權訪問的風險，這里的未授權訪問主要針對的是第三方團隊的開發人員。打包和分發階段的風險經歷測試階段后，CI/CD 管道會評估最新的測試結果，一旦測試通過會將軟件進行打包以及后續的分發。此處以微服務架構的項目舉例，打包階段時，各個微服務通過 Dockerfile文件進行鏡像構建，并進行簽名后將鏡像上傳至倉庫。分發部署階段時，Kubernetes 會從鏡像倉庫中拉取最新版本的鏡像以完成后續部署。以上過程中可能會產生一定的風險，主要包括以下兩方面：鏡像自身內容引發的風險:若

78、業務鏡像依賴的基礎鏡像含有漏洞，可能導致攻擊者利用已知漏洞對服務自身或其他微服務發起攻擊，若鏡像中的應用代碼含有漏洞，也將會導致被攻擊者利用的可能。鏡像分發過程引發的風險:由于 CI/CD 與 Kubernetes 可能不在同一環境，因而可能導致攻擊者在分發過程中趁虛而入，利用鏡像來源的不確定性（惡意鏡像簽名）對鏡像的傳輸過程進行劫持，并替換成惡意鏡像，亦或是對鏡像倉庫直接發起攻擊，造成巨大影響。鑒于上述提出的 DevOps 流程各階段風險，我們對相關組件服務的暴露面和攻擊面進行了統計和分析。在測繪到 21 萬多個不同 DevOps 組件服務中，約有 45%存在 N Day 漏洞，約有 23%

79、存在不同程度的未授權訪問情況，如未授權訪問代碼、鏡像、組件后臺等。漏洞與不安全配置加上極低的利用成本，使得互聯網中暴露的 DevOps 組件服務存在嚴重的安全風險。我 們 研 究 的 DevOps 組 件 包 括 Confluence1、Gitlab2、Harbor3、Sonarqube4、Jenkins5、Docker6、Kubernetes7及 Prometheus8，涵蓋 DevOps 流程的 8 個階段，下面逐一對其進行介紹。1 https:/ https:/ https:/goharbor.io/4 https:/ https:/www.jenkins.io/6 https:/ ht

80、tps:/kubernetes.io/8 https:/kubernetes.io/422023 公有云安全風險分析報告綠盟科技星云實驗室5.2.1 ConfluenceConfluence 是一款由 Atlassian 公司開發的協作與文檔管理工具，主要用于團隊協作、知識共享和文檔編寫。由于 Confluence 與其他 Atlassian 產品（如 Jira、Bitbucket）無縫集成，因此形成了一個全面的協作和開發生態系統，使得 Confluence 在整個軟件開發生命周期中得到廣泛應用。在 DevOps 計劃階段，Confluence 作為信息中心，幫助團隊收集、整理和共享與項目相關

81、的文檔、設計文稿、技術規范等信息，確保所有相關方了解項目狀態和進展，減少信息斷層，提高交付質量。5.2.1.1 組件暴露面分析我們對 2023 年全球互聯網暴露的 21150 個 Confluence 服務進行了測繪，并對結果進行統計、分析。下面從地區、歸屬組織、端口及版本分布情況分別進行介紹。圖 5.4 展示了暴露 Confluence 服務數量的 Top 10 地區，前三的地區分別是美國、日本和德國，暴露數量占測繪總量的 40%。其中美國暴露資產數量排名首位，暴露的Confluence 服務達到 5062 個，占比約 23%。50621732172412981077101695894393

82、59270100020003000400050006000美國日本德國法國南非韓國加拿大印度新加坡 愛爾蘭服務數量（個）地區圖 5.4 暴露 Confluence 服務地區分布情況圖 5.5 展示了暴露的 Confluence 服務歸屬組織的 Top 5。在能夠測繪到歸屬組織的Confluence 服務中，占比位居首位的是亞馬遜（Amazon），約 78%；第二位是光環新網（Guanghuan Xinwang Digital），約 2%；第三位是西云數據（NWCDcloud），約 1%。43連接云服務的第三方供應鏈安全風險分析78%2%1%1%1%17%AmazonGuanghuan Xinw

83、ang DigitalNWCDcloudM247ITLOther圖 5.5 暴露 Confluence 服務歸屬組織分布情況如圖 5.6 所示，我們測繪了全球 21150 個暴露端口的 Confluence 服務，并記錄了 Top 10。其中，暴露數量前三的端口分別是 443、8089 和 8200，占比 2%。其中 443 端口暴露量最多，共計 280 個，占比約 1%。28016410891888684837672050100150200250300443809082008009300144499998020872333服務數量（個）端口圖 5.6 暴露 Confluence 服務端口分布

84、情況同時，我們還對 Confluence 服務的版本情況進行了統計，共 21150 個，圖 5.7 展示了Top 10 版本。其中，暴露數量前三的版本分別是 7.13.0、7.17.4 和 7.19.17，占比 98%。其中 7.13.0 版本 Confluence 暴露量最多，共計 18518 個，占比約 87%。截至報告撰寫時，Confluence 最新版本為 8.7.2。442023 公有云安全風險分析報告綠盟科技星云實驗室185182290111622320171286020004000600080001000012000140001600018000200007.13.07.17.4

85、 7.19.178.5.48.5.38.7.18.6.17.19.168.6.27.13.4服務數量（個）版本圖 5.7 暴露 Confluence 服務版本分布情況5.2.1.2 組件攻擊面分析與影響首先，我們發現互聯網暴露的 21150 個 Confluence 服務中，約有 99%均不同程度存在N Day 漏洞。我們僅對影響暴露 Confluence 服務的 Top10 漏洞（Top10 的選擇標準為影響暴露 Confluence 服務數量）進行統計、分析。如圖 5.8 所示，我們發現有 CVE-2023-22503（信息泄露）20855 個，CVE-2023-22522（代碼執行）17

86、282 個，CVE-2023-22518（代碼執行）17090 個，CVE-2023-22504（認證繞過）17031 個及 CVE-2023-22508（代碼執行）17021 個。其中，每個資產可能命中多條 CVE。由于篇幅原因，其余漏洞情況不展開描述?？梢钥闯雠琶?Top 5 的漏洞均為 2023 年被曝出的，且 Top10 漏洞中代碼、命令執行類漏洞占比最高，約占 58%。這類漏洞將直接影響 Confluence 運行的宿主機，容易造成服務中斷或者信息泄露等安全問題。2085517282 17090 17031 17021372621181305000100001500020000250

87、00服務數量（個）漏洞圖 5.8 暴露 Confluence 服務漏洞分布情況45連接云服務的第三方供應鏈安全風險分析此外，我們還對 Confluence 覆蓋 CVSS 3.0 評分 7.5 以上的漏洞版本進行了統計分析。具體見表格 5-1：表 5-1 Confluence 版本漏洞統計分析版本CVE 數量CVE ID7.13.0，7.17.4，7.13.43CVE-2023-22508，CVE-2023-22522，CVE-2023-225187.19.17，8.5.4，7.19.16，8.6.21CVE-2023-225228.5.33CVE-2023-22522，CVE-2023-22

88、527，CVE-2023-225188.6.12CVE-2023-22522，CVE-2023-22518同時，我們匯總了近年來與 Confluence 相關的安全事件,可以看出平均每年都有安全事件被曝出：2021年，某黑客組織利用Confluence CVE-2021-26084 未授權OGNL（對象導航圖語言）代碼注入漏洞入侵了 Jenkins 項目開發團隊服務器，并植入了挖礦工具 30?？赡軐е路召Y源被大量占用、性能下降，影響正常業務運行，甚至服務中斷。2022 年，瑞士網絡威脅情報公司 Prodaft 發現，AvosLocker 勒索組織利用 Confluence CVE-2022-

89、26134 未授權 OGNL 代碼注入漏洞對暴露在互聯網上的未打補丁的 Confluence進行勒索攻擊 31。勒索攻擊會使得計算機系統將無法正常使用，直至受害者交納巨額贖金。2023 年 11 月，工信部網絡安全威脅和漏洞信息共享平臺監測發現，黑客組織在使用Confluence CVE-2023-22518 身份認證繞過漏洞及 Cerber 勒索病毒新變種實施勒索攻擊32。勒索攻擊會使得計算機系統將無法正常使用，直至受害者交納巨額贖金。5.2.1.3 組件風險緩解措施1.及時將 Confluence 及 Confluence 插件升級至安全版本；2.啟用強密碼策略及多因素認證機制；3.增設訪

90、問 IP 白名單；4.啟用審計日志，記錄關鍵操作和事件，以進行審計和檢測潛在的安全問題；5.定期培訓 Confluence 使用人員的安全意識，防止社工；5.2.2 GitlabGitlab 是一個基于 Git 版本控制系統的開源代碼托管平臺，支持 Git 版本控制系統，使團隊能夠方便存儲、追蹤和管理源代碼。Gitlab 強大的 CI/CD 功能使其成為一些團隊和組織的462023 公有云安全風險分析報告綠盟科技星云實驗室首選，它能夠自動化構建、測試和部署流程，提高開發效率。在 DevOps 編碼階段，Gitlab 為 DevOps 流程提供了高效的代碼管理、版本控制和協同開發的解決方案，有助

91、于團隊更加順暢地進行軟件開發工作。5.2.2.1 組件暴露面分析我們對 2023 年全球互聯網暴露的 41441 個 Gitlab 服務進行了測繪，并對結果進行統計、分析。下面從地區、歸屬組織、端口及版本分部情況分別進行介紹。如圖 5.9 所示，暴露數量前三的地區分別是中國、美國和德國，暴露數量約占測繪總量的 55%。其中中國暴露量排名首位，暴露的 Gitlab 服務達到 11559 個，占比約 27%。1155957245631308119221290101589788280602000400060008000100001200014000中國美國德國俄羅斯法國英國新加坡日本荷蘭韓國服務數量

92、（個）地區圖 5.9 暴露 Gitlab 服務地區分布情況圖 5.10 展示了暴露的 Gitlab 服務歸屬組織測繪情況，在能夠測繪到歸屬組織的 Gitlab服務中，占比位居首位的是阿里云（Alibaba），約 10%；第二位是亞馬遜（Amazon），約10%；第三位是 Hetzner Online GmbH，約 6%。47連接云服務的第三方供應鏈安全風險分析10%10%6%5%4%65%AlibabaAmazonHetzner Online GmbHTencentChinanetOther圖 5.10 暴露 Gitlab 服務歸屬組織分布情況如圖 5.11 所示，我們測繪了全球 41441

93、個暴露端口的 Gitlab 服務，并記錄了分布情況。其中，暴露數量前三的端口分別是 443、80 和 8090，占比 80%。其中 443 端口暴露量最多，共計 24733 個，占比約 59%。247337535118366261560546141936530005000100001500020000250003000044380809980908888808084438000908081服務數量（個）端口圖 5.11 暴露 Gitlab 服務端口分布情況同時，我們還對 Gitlab 服務的版本情況進行了統計，共 32160 個，圖 5.12 展示了其分布情況。其中，暴露數量前三的版本分別是

94、16.7.3、14.8.4 和 16.6.5，占比 33%。其中16.7.3 版本 Gitlab 暴露量最多，共計 9003 個，占比約 27%。截至報告撰寫時，Gitlab 最新版本為 16.8。482023 公有云安全風險分析報告綠盟科技星云實驗室9003884842581575557545530520492010002000300040005000600070008000900010000服務數量（個）版本圖 5.12 暴露 Gitlab 服務版本分布情況5.2.2.2 組件攻擊面分析與影響我們發現互聯網暴露的 Gitlab 服務中，約有 77%均不同程度存在 N Day 漏洞。我們僅對

95、影響暴露 Gitlab 服務的 2023 年 Top10 漏洞進行統計、分析。如圖 5.13 所示，我們發現 CVE-2023-3424（拒絕服務）16528 個，CVE-2023-0756（認證繞過）15300 個，CVE-2023-1708（命令執行）14873 個，CVE-2023-2199（拒絕服務）14701 個，CVE-2023-0121（拒絕服務）14392 個，CVE-2023-1733（拒絕服務）13157 個，CVE-2023-0518（拒絕服務）9083 個，CVE-2023-2132（拒絕服務）4487 個，CVE-2023-7028（任意用戶密碼重置）4321 個及

96、CVE-2023-0805（認證繞過）4234 個。由于篇幅原因，其余漏洞情況不展開描述。其中，每個資產可能命中多條 CVE。Top10 漏洞中拒絕服務類漏洞占比最高，約占65.1%。拒絕服務漏洞將直接導致 Gitlab 無法提供正常服務，導致 DevOps 中斷，嚴重影響軟件、服務的發布與迭代。49連接云服務的第三方供應鏈安全風險分析1652815300148731470114392131579083448743214234020004000600080001000012000140001600018000服務數量（個）漏洞圖 5.13 暴露 Gitlab 服務漏洞分布情況同時，我們匯總了近

97、年來與 Gitlab 相關的安全事件。雖然近些年沒有被曝出重大安全事件，但 Gitlab 平均每年被曝出的漏洞數量卻不少，2022、2023 年分別曝出 164、131 個漏洞：2021 年 11 月，微步情報局利用蜜罐捕獲到 GitLab 未授權遠程命令執行漏洞（CVE-2021-22205）在野利用，攻擊成功后攻擊者會植入挖礦木馬進行挖礦。該漏洞無需進行身份驗證即可進利用，危害極大 33。2021 年 11 月，GoogleCloud 發現攻擊者利用 GitLab 漏洞（CVE-2021-22205），通過受漏洞影響的資產發起超過 1 Tbps 的 DDoS 攻擊。這些被黑客控制的 Git

98、lab 服務器是僵尸網絡的一部分，該僵尸網絡由“數千個受感染的 GitLab 實例”組成 34。5.2.2.3 組件風險緩解措施1.及時將 Gitlab 升級至安全版本；2.啟用強密碼策略及多因素認證機制；3.對用戶、群組的項目訪問權限進行嚴格控制，如增設訪問 IP 白名單；4.及時對倉庫中的源代碼進行審計，預防代碼投毒事件；5.增加對 Gitlab 操作日志的監控；5.2.3 HarborHarbor是一個開源的容器鏡像存儲和分發解決方案，旨在幫助組織更好地管理容器鏡像。502023 公有云安全風險分析報告綠盟科技星云實驗室作為容器鏡像倉庫，Harbor 提供了安全、可靠的存儲，同時支持訪問

99、控制、漏洞掃描和復制等功能，為企業級應用的構建、共享和交付提供了便利。在 DevOps 構建階段，Harbor 能夠提供可靠的鏡像管理和安全保障，推動了持續集成和交付的順利進行。5.2.3.1 組件暴露面分析我們對 2023 年全球互聯網暴露的 7417 個 Harbor 服務進行了測繪，并對結果進行統計、分析。下面從地區、歸屬組織、端口及版本分布情況分別進行介紹。如圖 5.14 所示，Harbor 服務暴露數量前三的地區分別是中國、美國和德國，暴露數量約占測繪數據的 74%。其中中國暴露數量排名首位，達到 3985 個，占比約 53%。3985103349024424315114588858

100、2050010001500200025003000350040004500中國美國德國韓國新加坡法國俄羅斯加拿大日本英國服務數量（個）地區圖 5.14 暴露 Harbor 服務地區分布情況圖 5.15 展示了暴露的 Harbor 服務歸屬組織測繪情況，在能夠測繪到歸屬組織的服務中，位居首位的是阿里云（Alibaba），占比約 19%；第二位是亞馬遜（Amazon），占比約12%；第三位是騰訊（Tencent），占比約 9%。51連接云服務的第三方供應鏈安全風險分析19%12%9%4%4%52%AlibabaAmazonTencentChinanetHuaweiOther圖 5.15 暴露 Ha

101、rbor 服務歸屬組織分布情況如圖 5.16 所示，我們測繪了全球 7417 個暴露端口的 Harbor 服務，并記錄了分布情況。其中，暴露數量前三的端口分別是 443、80 和 8443，約占 75%。其中 443 端口暴露量最多，共計 4197 個，占比約 56%，進而我們可以看出被暴露的 Harbor 服務多數采用了 HTTPS 證書，用戶的安全意識在逐步增強。41971114310246241167105947365050010001500200025003000350040004500443808443300025000808088889443809081服務數量（個）端口圖 5.1

102、6 暴露 Harbor 服務端口分布情況同時，我們還對 Harbor 服務的版本情況進行了統計，共 4780 個，圖 5.17 展示了其分布情況。其中，暴露數量前三的版本分別是 2.8.2、2.9.1 和 2.9.0，約占 14%。其中 2.8.2 版522023 公有云安全風險分析報告綠盟科技星云實驗室本Harbor暴露量最多，共計269個，約占5%。截至報告撰寫時，Harbor的最新版本為2.10.0。2692501921851781551471361341320501001502002503002.8.22.9.12.9.02.7.02.5.32.10.02.4.12.7.12.7.32

103、.6.0服務數量（個）版本圖 5.17 暴露 Harbor 服務版本分布情況5.2.3.2 組件攻擊面分析與影響我們發現互聯網暴露的 Harbor 服務中，約有 55%均不同程度存在 N Day 漏洞。我們對影響暴露 Harbor 服務的 Top10 漏洞進行統計、分析。如圖 5.18 所示，我們共發現 CVE-2023-20902（未授權訪問）2438 個，CVE-2022-46463（認證繞過）2309 個，CVE-2020-13788（服務端請求偽造）663 個，CVE-2019-19030（未授權訪問）472 個，CVE-2020-13794（信息泄露）407 個，CVE-2019-1

104、9023（權限提升）178 個，CVE-2019-19025（跨站請求偽造）178 個，CVE-2019-19026（SQL 注入）178 個，CVE-2019-19029（SQL 注入漏洞）178 個及 CVE-2019-16097（未授權訪問）117 個。由于篇幅原因，其余漏洞情況不展開描述。其中，每個資產可能命中多條 CVE。在 Top10 漏洞中未授權訪問類漏洞占比最高，約占 42%。53連接云服務的第三方供應鏈安全風險分析24382309663472407178178178178117050010001500200025003000服務數量（個）漏洞圖 5.18 暴露 Harbor

105、服務漏洞分布情況此外，我們還對 Harbor 服務 Top10 版本的 CVSS 3.0 評分 7.5 以上的漏洞覆蓋情況進行了統計分析。詳見表 5-2：表 5-2 Harbor 版本漏洞統計分析版本CVE 數量CVE ID2.5.3，2.4.11CVE-2022-464635.2.3.3 組件風險緩解措施1.根據官方補丁版本及時對 Harbor 版本進行更新2.根據官方提供的緩解措施進行臨時緩解，Harbor 相關的漏洞緩解措施可參考官方Github 的 Security advisories 版面 355.2.4 SonarQubeSonarQube 是一個開源的代碼質量管理平臺，在全球范

106、圍內有龐大的開發者社區。SonarQube 專注于靜態代碼分析，幫助團隊檢測和解決代碼質量問題。SonarQube 在國內外企業和組織中被廣泛使用，用于持續集成和持續交付（CI/CD）流水線中的代碼質量管理。在 DevOps 測試階段，SonarQube 能夠對代碼執行靜態分析，識別潛在的缺陷、漏洞，提前發現問題，減少后期的維護成本。此外，SonarQube 提供實時的代碼質量反饋，開發者能夠及時了解代碼的健康狀況，并在測試階段進行迭代改進。5.2.4.1 組件暴露面分析我們對 2023 年全球互聯網暴露的 11781 個 SonarQube 服務進行了測繪，并對結果進542023 公有云安全

107、風險分析報告綠盟科技星云實驗室行統計、分析。下面從地區、歸屬組織、端口及版本分布情況分別進行介紹。如圖 5.19 所示，SonarQube 服務暴露數量前三的地區分別是美國、德國和愛爾蘭，暴露數量約占測繪數據的 63%。其中美國暴露數量排名首位，達到 5755 個，占比約 48%。5755103673872653939438533431819201000200030004000500060007000服務數量（個）地區圖 5.19 暴露 SonarQube 服務地區分布情況圖 5.20 展示了暴露的 SonarQube 服務歸屬組織測繪情況，在能夠測繪到歸屬組織的服務中，位居首位的是亞馬遜（A

108、mazon），占比約 58%；第二位是微軟（Mircrosoft），占比約 12%；第三位是谷歌（Google），占比約 6%。58%12%6%3%2%19%AmazonMircrosoftGoogleDigitaloceanHetzner Online GmbHOther圖 5.20 暴露 SonarQube 服務歸屬組織分布情況如圖 5.21 所示，我們測繪了全球 11781 個暴露端口的 SonarQube 服務，并記錄了分布情況。其中，暴露數量前三的端口分別是 443、9000 和 80，暴露數量約占測繪數據的55連接云服務的第三方供應鏈安全風險分析95%。其中 443 端口暴露量最多

109、，共計 5264 個，占比約 44%。5264351324478377292320171701000200030004000500060004439000808080909084439009800094439999服務數量（個）端口圖 5.21 暴露 SonarQube 服務端口分布情況同時，我們還對 SonarQube 服務的版本情況進行了統計，共 542 個，圖 5.22 展示了其分布情況。其中，暴露數量前三的版本分別是 7.9.1、8.5.1 和 7.6，占比約 15%。其中 7.9.1、8.5.1 版本 SonarQube 暴露量最多，均為 29 個，占比約 5%。截至報告撰寫時，So

110、narQube最新版本為 10.3.0。29292525232322191715051015202530357.9.18.5.17.67.87.57.78.37.9.38.28.4.2服務數量（個）版本圖 5.22 暴露 SonarQube 服務版本分布情況5.2.4.2 組件攻擊面分析與影響562023 公有云安全風險分析報告綠盟科技星云實驗室由于近幾年 SonarQube 并未曝出新漏洞，因此我們發現互聯網暴露的 11781 個SonarQube 服務中，僅有 1.2%存在 N Day 漏洞。我們對其四個歷史漏洞進行統計、分析。如圖 5.23 所示，我們共發現 CVE-2019-17579

111、（跨站腳本攻擊）136 個，CVE-2018-19413（信息泄露）55 個，CVE-2020-27986（未授權訪問）15 個及 CVE-2020-28002（未授權訪問）15 個。能夠測繪到存在漏洞的 SonarQube 服務約占暴露總資產的 1%。其中，每個資產可能命中多條 CVE。136551515020406080100120140160CVE-2019-17579CVE-2018-19413CVE-2020-27986CVE-2020-28002服務數量（個）漏洞圖 5.23 暴露 SonarQube 服務版本分布情況此外，我們還對 SonarQube 服務 Top10 版本的 C

112、VSS 3.0 評分 7.5 以上的漏洞覆蓋情況進行了統計分析。詳見表 5-3：表 5-3 SonarQube 版本漏洞統計分析版本CVE 數量CVE ID8.4.21CVE-2020-279865.2.4.2 組件風險緩解措施57連接云服務的第三方供應鏈安全風險分析1.將 SonarQube 升級至安全版本；2.參考官網給出的安全實踐進行加固 36；5.2.5 JenkinsJenkins 是一款開源的自動化服務器，用于構建、測試和部署軟件項目。它通過提供易于配置的插件和可擴展性，實現了持續集成和持續交付（CI/CD）。Jenkins開源社區十分活躍，來自全球的開發者在貢獻插件、腳本和解決方

113、案，幫助其他用戶更好地利用 Jenkins 進行自動化。在 DevOps 發布階段，Jenkins 通過集成版本控制系統和構建工具來實現自動化將應用程序部署到目標環境中。此外，Jenkins 還支持并行部署、藍綠部署等策略，幫助團隊更靈活地進行發布管理。5.2.5.1 組件暴露面分析我們對2023年全球互聯網暴露的63579個Jenkins服務進行了測繪，并對結果進行統計、分析。下面從地區、歸屬組織、端口及版本分布情況分別進行介紹。如圖 5.24 所示，Jenkins 服務暴露數量前三的地區分別是美國、中國和德國，暴露數量約占測繪數據的 60%。其中美國暴露數量排名首位，達到 21745 個，

114、占比約 34%。2174512248463344312662262819831676155811770500010000150002000025000美國中國德國印度新加坡韓國愛爾蘭英國法國日本服務數量（個）地區圖 5.24 暴露 Jenkins 服務地區分布情況圖5.25展示了暴露的Jenkins服務歸屬組織測繪情況，在能夠測繪到歸屬組織的服務中，位居首位的是亞馬遜（Amazon），占比約 41%；第二位是阿里云（Alibaba），占比約 9%；582023 公有云安全風險分析報告綠盟科技星云實驗室第三位是 Digitalocean，占比約 5%。41%9%5%5%3%37%AmazonAl

115、ibabaDigitaloceanTencentMircrosoftOther圖 5.25 暴露 Jenkins 服務歸屬組織分布情況如圖 5.26 所示，我們測繪了全球 63579 個暴露端口的 Jenkins 服務，并記錄了分布情況。其中，暴露數量前三的端口分別是 8080、443 和 80，暴露數量約占測繪數據的 87%。其中8080 端口暴露量最多，共計 34210 個，占比約 53%。34210150406126135397096567035129524705000100001500020000250003000035000400008080443809090809088888443

116、800090009080服務數量（個）端口圖 5.26 暴露 Jenkins 服務地區分布情況同時，我們還對 Jenkins 服務的版本情況進行了統計，共 39407 個，圖 5.27 展示了其分布情況。其中，暴露數量前三的版本分別是 2.426.2、2.426.1 和 2.414.3，占比約 18%。59連接云服務的第三方供應鏈安全風險分析其中 2.426.2 版本 Jenkins 服務暴露量最多，共計 3444 個，占比約 8%。截至報告撰寫時，Jenkins 最新版本為 2.443。34442075168714941200112710099278067840500100015002000

117、25003000350040002.426.2 2.426.1 2.414.3 2.387.1 2.414.2 2.346.3 2.414.1 2.401.3 2.401.2 2.401.1服務數量（個）版本圖 5.27 暴露 Jenkins 服務版本分布情況5.2.5.2 組件攻擊面分析我們發現互聯網暴露的63579個Jenkins服務中，約有39%均不同程度存在N Day漏洞。我們僅對影響暴露 Jenkins 服務的 Top10 漏洞進行統計、分析。如圖 5.28 所示，我們共發現CVE-2023-35141（跨站請求偽造）25360個、CVE-2023-27899（遠程代碼執行）2480

118、0個、CVE-2023-27900（拒絕服務）24800 個、CVE-2023-27901（拒絕服務）24800 個、CVE-2023-27902（信息泄露）24800 個、CVE-2023-27903（信息泄露）24800 個、CVE-2023-27904（信息泄露）24800 個、CVE-2023-27898（跨站腳本攻擊）18504 個、CVE-2022-34174（認證繞過）16847 個及 CVE-2018-15664（拒絕服務）13541 個。在 Top10 漏洞中信息泄露類漏洞占比最高，約占 33.3%。由于篇幅原因，其余漏洞情況不展開描述。此外，2.4xx.xx 及以下版本的

119、Jenkins 服務，可能會存在多個漏洞。602023 公有云安全風險分析報告綠盟科技星云實驗室2529023271 23271 23271 23271 23271 232711735216012 15805050001000015000200002500030000服務數量（個）漏洞圖 5.28 暴露服務漏洞分布情況此外，我們還對 Jenkins 服務 Top10 版本的 CVSS 3.0 評分 7.5 以上的漏洞覆蓋情況進行了統計分析。具體見表格 5-4：表 5-4 Jenkins 版本漏洞統計分析版本CVE 數量CVE ID2.387.13CVE-2023-35141，CVE-2023-

120、27900，CVE-2023-279012.346.36CVE-2023-35141，CVE-2023-27900，CVE-2023-27901，CVE-2022-2048，CVE-2022-34175，CVE-2022-341745.2.5.3 組件風險緩解措施1.升級 Jenkins 及其插件至最安全版本;2.為用戶和插件分配適當的權限，遵循最小權限原則；3.管理和保護 Jenkins 中使用的密鑰，包括限制密鑰文件的訪問權限，定期更換密鑰等；4.關注 Jenkins 日志審計，監控異常行為；5.2.6 DockerDocker 是一個開源容器化平臺，允許用戶將應用程序及其依賴項打包成一個

121、獨立的、可移植的容器，確保應用在不同環境中運行的一致性。Docker 社區中擁有龐大的用戶和開發者社群，技術愛好者和企業開發團隊使用 Docker 來簡化開發、測試和部署流程。許多國內61連接云服務的第三方供應鏈安全風險分析外知名互聯網企業，在其生產環境中廣泛使用 Docker 來實現業務的容器化和部署。各大云廠商也都提供了對 Docker 容器的原生支持。在 DevOps 部署階段，Docker 提供了應用環境隔離，確保應用運行的兼容性問題。其次，Docker 容器可以在秒級別內啟動，快速部署和擴展應用，有助于實現敏捷的交付流程。5.2.6.1 組件暴露面分析我們對 2023 年全球互聯網暴

122、露的 338 個 Docker Remote API 服務的 2375 端口進行了測繪，并將結果進行了統計。下面從地區、歸屬組織、版本分布三個維度分別進行介紹。如圖 5.29 所示，Docker Remote API 服務全球暴露數量前三的地區分別是中國、美國和德國，暴露數量占測繪數據的 71%。其中中國暴露數量排名首位，達到 170 個，占比約50%。17063109776655020406080100120140160180中國美國德國英國俄羅斯 新加坡法國巴西加拿大印度服務數量地區圖 5.29 暴露 Docker Reomte API 服務地區分布情況圖 5.30 展示了暴露的 Dock

123、er Remote API 服務歸屬組織測繪情況，在能夠測繪到歸屬組織的服務中，位居首位的是阿里云（Alibaba），占比約 18%；第二位是騰訊（Tencent），占比約 12%；第三位是亞馬遜（Amazon），占比約 8%。622023 公有云安全風險分析報告綠盟科技星云實驗室18%12%8%7%6%49%AlibabaTencentAmazonDigitaloceanChinanetOther圖 5.30 暴露 Docker Reomte API 服務歸屬組織分布情況同時，我們還對 Docker Remote API 服務的版本情況進行了統計，能夠測繪到版本的共110 個服務，圖 5.3

124、1 展示了其分布情況。其中，暴露數量前三的版本分別是 24.0.7、1.13.1和 20.10.5+dfsg1，占比約 47%。其中 24.0.7 版本 Docker 資產暴露量最多，共計 27 個，占比約 24%。截至報告撰寫時，Docker 最新版本為 25.0.2。2713126555332051015202530服務數量版本圖 5.31 暴露 Docker Reomte API 服務版本分布情況5.2.6.2 組件攻擊面分析針對于上述暴露的 Docker Remote API 服務，我們從組件脆弱性配置和漏洞兩方面進行63連接云服務的第三方供應鏈安全風險分析了分析。脆弱性配置分析Doc

125、ker Remote API 服務端口主要為 2375、2376 端口，這兩個端口為 Docker 的 TCP Socket 端口，在版本較新的 Docker 中，Docker 守護進程默認不會監聽 TCP Socket。用戶可通過配置文件來設置 Docker 守護進程開啟對 TCP Socket 的監聽，默認監聽端口通常為2375。然而，默認情況下對 Docker 守護進程 TCP Socket 的訪問是無加密且無認證的。因此，任何網絡可達的訪問者均可通過該 TCP Socket 來對 Docker 守護進程下發命令。2376 端口用于與 Docker 守護進程進行 TLS 通信，因此需要配

126、置證書才可實現通信加密，默認不開啟。若開放了 2375，2376（未配置證書）端口，以下命令能夠列出 IP 為 192.168.1.99 的主機上的所有活動容器：docker-H tcp:/192.168.1.99:2375 psdocker-H tcp:/192.168.1.99:2376 ps顯而易見，攻擊者也能夠通過這樣的 TCP Socket 對目標主機上的 Docker 守護進程下發命令，從而實現對目標主機的控制?？刂品绞脚c通過Unix Socket的控制類似，只是需要通過-H tcp:/參數來設置目標地址和端口。典型事件例如，2020 年，國外 TeamTNT 組織團伙利用Dock

127、er 容器 API 未授權訪問對 Docker 主機發起攻擊活動，植入挖礦木馬，并通過安裝定時任務進行持久化、SSH 復用連接進行橫向移動感染更多服務器，進而導致業務系統崩潰 37；漏洞分析如圖 5.32 所示，我們共發現 CVE-2021-21284（路徑穿越）26 個、CVE-2020-27534（路徑穿越）22 個、CVE-2019-5736（遠程代碼執行）17 個、CVE-2019-14271（容器逃逸）17 個、CVE-2019-13139（命令注入）17 個、CVE-2020-14300（遠程代碼執行）13 個及 CVE-2018-15664（權限提升）4 個。從中我們可以看出權限

128、提升類漏洞占比最高，此外，能夠測繪到存在漏洞的 Docker 資產約占暴露總資產的 7%。642023 公有云安全風險分析報告綠盟科技星云實驗室2622171717134051015202530服務數量漏洞圖 5.32 暴露 Docker Reomte API 服務漏洞分布情況此外，我們還對 Docker Remote API 服務 Top10 版本的 CVSS 3.0 評分 7.5 以上的漏洞覆蓋情況進行了統計分析。具體見表格 5-5：表 5-5 Docker 版本漏洞統計分析版本CVE 數量CVE ID1.13.12CVE-2019-5736，CVE-2019-142715.2.6.3 組

129、件風險緩解措施1.使用 Docker 時將 2375 端口監聽在內網 IP 地址，避免直接暴露在互聯網中，使用Docker 的 TLS 端口(2376)并為其配置證書；2.使用 CIS Docker Benchmark 最佳實踐 38；3.根據官方通告及時升級版本，更新補??；5.2.7 KubernetesKubernetes 是一個開源的容器編排平臺，用于自動化、部署、擴展和管理容器化應用。它提供了一個強大的容器編排系統，簡化了應用的部署和運維。國內外多個大型云服務商也均提供了原生 Kubernetes 托管服務，使用戶能夠輕松地在云上部署和管理 Kubernetes 集群。在 DevOps

130、 運營階段，Kubernetes 提供了靈活的部署策略，允許團隊實現滾動更新、藍綠部署等高級部署模式，降低了系統的停機時間和風險。Kubernetes 還能夠自動進行負載65連接云服務的第三方供應鏈安全風險分析均衡、故障恢復和水平擴展等方，提高了應用的可用性和穩定性。5.2.7.1 組件暴露面分析我們對 2023 年全球互聯網暴露的 29860 個 Kubernets API Server 服務默認 SSL 端口6443 進行測繪，并將結果進行了統計。與我們在 2018 年發布的容器安全技術報告39中的測繪數據相比，2023 年互聯網中暴露的 Kubernets API Server 服務的

131、5 年增長率約為132.8%。下面從地區分布、歸屬組織、版本分布三個維度分別進行介紹。如圖 5.33 所示，暴露數量前三的地區分別是中國、美國和德國，暴露數量約占測繪數據的 70%。其中中國暴露資產數量排名首位，暴露的 Kubernets API Server 服務達到 10968個，占比約 36%。109685337479011101049774690502435424020004000600080001000012000中國美國德國俄羅斯 愛爾蘭法國英國新加坡 加拿大芬蘭服務數量（個）地區圖 5.33 暴露 Kubernets API Server 服務地區分布情況圖 5.34 展示了對暴

132、露的 Kubernets API Server 服務歸屬組織測繪情況，在能夠測繪到歸屬組織的服務中，位居首位的是阿里云（Alibaba），占比約 19%；第二位是 Hetzner Online GmbH，占比約 12%；第三位是 Oracle，占比約 7%。662023 公有云安全風險分析報告綠盟科技星云實驗室19%12%7%7%3%52%AlibabaHetzner Online GmbHOracleAmazonMicrosoftOther圖 5.34 暴露 Kubernets API Server 服務端口分布情況同時，我們還對 Kubernets API Server 服務的版本情況進行

133、了統計，共 12424 個，圖 5.35展示了其分布情況。其中，暴露數量前三的版本分別是 1.20.11、1.22.15 和 1.21.1，占比約21%。其中 1.20.11 版本 Kubernets API Server 服務暴露量最多，共計 1028 個，占比約 8%。截至報告撰寫時時，Kubernets API Server 最新版本為 1.29.1。10288088007977805694724333663050200400600800100012001.20.11 1.22.15 1.21.11.18.8 1.21.14 1.22.31.20.4 1.20.15 1.16.9 1.2

134、2.10服務數量（個）版本圖 5.35 暴露 Kubernets API Server 服務版本分布情況5.2.7.2 組件攻擊面分析針對于上述暴露的 Kubernets API Server 服務，我們對其脆弱性配置和漏洞兩方面進行67連接云服務的第三方供應鏈安全風險分析了分析。脆弱性配置分析熟悉 Kubernetes 的讀者都知道 API Server 組件在 8080 和 6443 兩個端口上提供服務，其中，8080 端口提供的是沒有 TLS 加密的 HTTP 服務，且所有到達該端口的請求將繞過所有認證和授權模塊（但是仍然會被準入控制模塊處理）。保留該端口主要是為了方便測試以及集群初啟動

135、。然而在生產環境開放 8080 端口，即使綁定本地環回地址（Localhost）也是很危險的。如果將該端口暴露在互聯網上，那么任何網絡可達的攻擊者都能夠通過該端口直接與 API Server 交互，進而控制整個集群。如用戶可以通過以下操作開啟外部對 API Server 的未授權訪問：在 Kubernetes 主節點的 kube-apiserver.yaml 文件中將-insecure-port=0 配置項修改為-insecure-port=8080在 Kubernetes 主節點的 kube-apiserver.yaml 文件中修改-insecure-bind-address 配置項值為 0

136、.0.0.0漏洞分析如圖 5.36 所示，我們共發現 CVE-2022-3172（服務端請求偽造）10610 個，CVE-2022-3162（信息泄露）9757 個，CVE-2021-25741（任意文件讀）5105 個，CVE-2021-25735（認證繞過）3661 個，CVE-2018-1002105（權限提升）3123 個，CVE-2020-8558（認證繞過）1583 個，CVE-2020-8559（權限提升）1500 個，CVE-2019-11252（信息泄露）1416 個，CVE-2020-8554（中間人攻擊）978 個及 CVE-2019-11253（拒絕服務）669 個。在

137、 Top10漏洞中服務端請求偽造類漏洞占比最高，約占 27.6%。由于篇幅原因，其余漏洞情況不展開描述。能夠測繪到存在漏洞的 Kubernets API Server 服務約占總資產的 38%。682023 公有云安全風險分析報告綠盟科技星云實驗室106109757510536613123158315001416978669020004000600080001000012000服務數量（個）漏洞圖 5.36 暴露 Kubernets API Server 服務漏洞分布情況此外，我們還對 Kubernetes API Server 服務 Top10 版本的 CVSS 3.0 評分 7.5 以上的

138、漏洞覆蓋情況進行了統計分析。具體見表格 5-6：表 5-6 Kubernetes 版本漏洞統計分析版本CVE 數量CVE ID1.20.11，1.21.1，1.22.3，1.20.4，1.20.15，1.22.101CVE-2022-31721.18.8，1.16.92CVE-2022-3172，CVE-2018-10021055.2.7.3 組件風險緩解措施1.根據官方通告及時升級版本，更新補丁，根據官方提供的安全實踐進行加固 40；2.禁止在 Kubernetes API Server 組件的配置文件中修改-insecure-port 啟動參數值為8080，使用默認配置值；3.禁止在 Ku

139、bernetes API Server 組件的配置文件中修改-insecure-bind-address 啟動參數值為 0.0.0.0，使用默認配置值；4.使用 API Server 的安全端口（6443），并為其設置證書；5.使用 CIS Kubernetes Benchmark 最佳實踐 40；5.2.8 PrometheusPrometheus 是一款開源的監控和警報工具，專注于收集和存儲系統和服務的時間69連接云服務的第三方供應鏈安全風險分析序列數據。其支持多維度的數據模型，允許靈活而強大的查詢，具備高度可擴展性。Prometheus 常被用于監控關鍵業務系統和生產環境，確保系統的穩定

140、性和可靠性。此外，Prometheus 擁有龐大的開發者社區，開發者不斷貢獻新的插件、導出器和解決方案，豐富了 Prometheus 的功能和適用場景。在 DevOps 監控階段，Prometheus 能夠定期從部署的業務、中間件等環境中收集各種指標數據，如 CPU 利用率、內存使用率、請求響應時間等，通過多維數據模型，Prometheus 能夠對這些指標進行有針對性的查詢和分析，為運維團隊提供深入的性能洞察。5.2.8.1 組件暴露面分析我們對 2023 年全球互聯網暴露的 37218 個 Prometheus 服務進行了測繪，并對結果進行統計、分析。下面從地區、歸屬組織、端口及版本分布情況

141、分別進行介紹。如圖 5.37 所示，Prometheus 服務暴露數量前三的地區分別是美國、中國和德國，暴露數量占測繪數據的 53%。其中美國暴露數量排名首位，達到 9733 個，占比約 26%。97335844435918751755155813561253971859020004000600080001000012000美國中國德國巴西法國俄羅斯印度新加坡英國荷蘭服務數量（個）地區圖 5.37 暴露服務地區分布情況圖 5.38 展示了暴露的 Prometheus 服務歸屬組織測繪情況，在能夠測繪到歸屬組織的服務中，位居首位的是亞馬遜（Amazon），占比約 20%；第二位是 Hetzner

142、 Online GmbH，占比約 7%；第三位是 Digitalocean，占比約 5%。702023 公有云安全風險分析報告綠盟科技星云實驗室20%7%5%5%3%60%AmazonHetzner Online GmbHDigitaloceanAlibabaTencentOther圖 5.38 暴露 Prometheus 服務歸屬組織分布情況圖 5.39 所示，我們測繪了全球 37218 個暴露端口的 Prometheus 服務，并記錄了分布情況。其中，暴露數量前三的端口分別是 9090、80 和 443，占比約 93.9%。由于 9090 是Prometheus 默認端口，因此 9090

143、端口暴露量最多，共計 32343 個，占比約 86.9%。323431992639391343188181173123770500010000150002000025000300003500090908044380809091300039092910199999080服務數量（個）端口圖 5.39 暴露服務端口分布情況同時，我們還對 Prometheus 服務的版本情況進行了統計，共 26177 個，圖 5.40 展示了其分布情況。其中，暴露數量前三的版本分別是 2.48.1、2.27.1 和 2.46.0，占比約 18%。其中 2.48.1 版本 Prometheus 暴露量最多，共計 20

144、11 個，占比約 7%。截至報告撰寫時，Prometheus 最新版本為 2.49.1。71連接云服務的第三方供應鏈安全風險分析2011176410691047103610021000885859785050010001500200025002.48.12.27.12.46.02.47.22.48.02.43.02.45.02.44.02.42.02.47.0服務數量（個）版本圖 5.40 暴露服務版本分布情況5.2.8.2 組件攻擊面分析針對于上述暴露的 Prometheus 服務，我們對其脆弱性配置和漏洞兩方面進行了分析。脆弱性配置分析通過查看文檔 41,Prometheus 的 2.24

145、.0 版本之前，Prometheus 未內置認證授權等安全機制，導致只要用戶對外暴露 Prometheus 的 9090 端口，那么任何人都可以對 Prometheus Dashboard 進 行 未 授 權 訪 問。雖 然 Prometheus 在 2.24.0 版 本 后 針 對Dashboard 引入了 TLS 及 Basic 認證方式，但由于引入時間較晚，許多企業及組織已在云上部署了 Prometheus，且未及時啟用官方提供的認證機制，從而導致大量暴露在互聯網Prometheus 服務仍存在未授權訪問風險。圖 5.41 2.24.0 以前版本未支持 TLS 認證在測繪出的 26177

146、 個 Promethues 版本中，我們發現 2.24.0 前的版本約占總數的 5%，這意味著 5%被暴露在互連網上的 Promethues 資產仍然可被攻擊者未授權訪問。722023 公有云安全風險分析報告綠盟科技星云實驗室漏洞分析由于 Prometheus 歷史漏洞較少，除三方工具、插件外與 Prometheus 自身相關的漏洞僅有 CVE-2019-3826（跨站腳本攻擊）與 CVE-2021-29622（URL 重定向）。其中，我們僅測繪到有 1425 個暴露的 Prometheus 服務存在 CVE-2021-29622，占比約 3%。5.2.8.3 組件風險緩解措施1.升級 Pro

147、metheus 版本為最新版本，及時更新插件至安全版本；2.升級 Prometheus Dashboard 使用認證機制，如 Prometheus 提供的 Basic 認證，使用 TLS 保證數據傳輸安全;3.禁止將用戶名密碼等敏感信息以明文形式寫入 Prometheus 的配置文件中;5.3 小結本章中，我們對 DevOps 中的常用組件從地區、歸屬組織、端口、版本及漏洞五個維度進行了暴露面和風險面的分析，并給出了相應的安全加固措施。通過分析我們發現，互聯網中的 DevOps 組件的暴露數量較為龐大，更有一定比例的暴露組件存在易利用、威脅大的風險。DevOps 倡導的持續集成和持續部署與云計

148、算所倡導的敏捷、彈性、自動化不謀而合。DevOps 作為連接云的重要“供應鏈”，它的任一環節的風險都可能給上游的云計算環境造成服務中斷、數據泄露、投毒、勒索攻擊等安全事件。因此，DevOps 組件的風險不容小覷，DevOps 的安全實踐變得極其重要。用戶應遵循相關等保要求，按照最佳實踐進行組件配置，來減少組件的暴露面，降低組件的攻擊面。06總結與展望742023 公有云安全風險分析報告綠盟科技星云實驗室云計算技術棧被廣泛應用的同時也帶來了極大的安全風險，報告全文我們基于云安全研究積累針對公有云服務配置錯誤、云服務自身脆弱性配置或漏洞以及云服務的第三方供應鏈軟件三方面進行了總結分析：1)針對公有

149、云配置風險，我們延續了 2022 年在源代碼倉庫以及存儲桶泄露上的研究工作，有了一些新的發現，并針對研究案例進行了解讀。同時，我們通過測繪技術發現由于“公開屬性”的設置，互聯網上暴露了大量的容器鏡像倉庫，容器鏡像中存放大量業務代碼、配置文件等敏感信息，我們對其資產暴露面以及風險面進行了分析，并通過研究案例進行了解讀。2)針對公有云服務自身風險，我們基于現有在 IAM、數據庫等公有云服務的研究積累，發現了公有云廠商存在的一些問題，并協助云廠商進行了應急響應，具體通過研究案例進行了解讀。3)針對連接云服務的第三方供應鏈安全風險，我們從開發運營一體化的角度進行了分析，涉及數十種在云上暴露的組件類型。

150、研究內容包括資產暴露面和資產攻擊面分析，并給出組件的影響和緩解措施，值得注意的是，這些組件之間存在關聯性的。例如，開發階段涉及的組件如果含有脆弱性配置或漏洞，可能會影響到運營階段涉及的組件。因此，在實現 DevOps 流程時，應遵循“安全左移”的原則，即在起始階段就將風險降至最低，以避免風險擴大。未來，我們認為云安全防護重心將轉向身份和管理為核心的 CIEM 和 CSPM，在云計算基礎設施安全領域，以往產業界主要聚焦在云工作保護平臺（Cloud Workload Protection Platform，CWPP），即關注云主機或容器層面的工作負載，檢測并防護相應的威脅事件。然而，2023 年發

151、生的一系列重大安全事件，大多涉及身份、管理和暴露面，而非工作負載。例如：2023 年 5 月，Toyota Connected 云配置錯誤導致大規模數據泄露長達多年 1314，主要原因是 Toyota Connected 未對其使用的云存儲服務進行正確的訪問控制；2023 年 9月，微軟 AI 研究團隊在 GitHub 上意外暴露了 38TB 隱私數據 15，主要原因是 SAS 令牌權限配置錯誤導致 Azure 的 Blob 存儲服務可被未授權訪問；2023 年 11 月，英國政府承包商 MPD FM 的敏感數據泄露 48,主要原因是其使用的 Amazon S3 存儲桶服務被錯誤地配置了訪問權

152、限，導致敏感數據可被任意進行未授權訪問。事實上，早在 2018 年，Gartner 首次提出了云安全態勢管理（Cloud Security Posture Management，CSPM）49，通過事前預防、及時檢測云基礎設施風險，持續管理 IaaS75總結與展望和 PaaS 的安全態勢。如今隨著企業上云成為主流趨勢，CSPM 的功能也在不斷豐富迭代，目前 CSPM 工具不僅包含云配置管理，還包括數據安全態勢管理（Data Security Protection Management，DSPM）、云上身份特權管理（Cloud Infrastructure Entitlement Managem

153、ent,CIEM）等新的能力 50，可應對前述針對身份和數據的威脅。CSPM 與 CWPP 的關注點不同，前者更注重于租戶層面的安全，如某企業 AK/SK 遭泄露，攻擊者可未授權訪問該企業購買的云存儲、VPC、云數據庫、Kubernetes 集群等眾多云服務中，并通過不同攻擊路徑竊取敏感數據，這也是近年云安全事件頻發的主要原因之一。通過 CSPM，企業可感知到自身的云服務、服務間的拓撲關系、服務所對應訪問權限，以及針對這些云服務的可能攻擊路徑，再組合相應的檢測、響應能力，可有效解決云租戶層面的安全問題。IDC 預測，到 2024 年，23%的組織將利用 AI 技術賦能云原生應用保護平 臺（Cl

154、oud Native Application Protection Platforms，CNAPP）和 CSPM51。其 中，CSPM 會更聚焦于自動化和智能化，通過 AI 算法提升對云安全錯誤配置自動識別能力，從而降低風險利用。行文至此，希望讀者在閱讀完本報告后，可以更好地理解公有云安全風險，意識到上云風險的復雜性，并采取相關措施保護云上業務的安全。07參考文獻77參考文獻1 綠盟科技2022 網絡空間測繪報告 云上風險測繪篇2 https:/company.toyotaconnected.co.jp/news/press/2023/0512/3 https:/ 4 https:/ 5 ht

155、tps:/ 6 https:/www.wiz.io/blog/bingbang 7 https:/ https:/ https:/ https:/www.wiz.io/blog/brokensesame-accidental-write-permissions-to-private-registry-allowed-potential-r 11 https:/en.wikipedia.org/wiki/Memorial_Day 12 https:/ 13 https:/company.toyotaconnected.co.jp/news/press/2023/0512/14 https:/co

156、mpany.toyotaconnected.co.jp/news/press/2023/0531/15 https:/www.wiz.io/blog/38-terabytes-of-private-data-accidentally-exposed-by-microsoft-ai-researchers 16 https:/ https:/goharbor.io/docs/2.0.0/working-with-projects/project-configuration/18 https:/distribution.github.io/distribution/about/deploying/

157、19 https:/ https:/ https:/ https:/ 23 https:/ https:/www.wiz.io/blog/bingbang 25 https:/kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/26 https:/www.postgresql.org/docs/current/role-attributes.html 27 https:/ 28 https:/ 782023 公有云安全風險分析報告綠盟科技星云實驗室29 https:/ 30 https:/ http:/

158、 https:/ https:/ https:/therecord.media/gitlab-servers-are-being-exploited-in-ddos-attacks-in-excess-of-1-tbps35 https:/ https:/ https:/ 38 https:/www.cisecurity.org/benchmark/docker 39 https:/ 40 https:/www.cisecurity.org/benchmark/kubernetes 41 https:/ 42 https:/ 43 https:/www.wiz.io/blog/brokense

159、same-accidental-write-permissions-to-private-registry-allowed-potential-r44 https:/ 45 https:/ https:/mandarinian.news/%E8%AD%A6%E7%A4%BA%E6%95%85%E4%BA%8B%EF%BC%9A%E4%B8%A4%E5%AE%B6%E4%B8%B9%E9%BA%A6%E6%89%98%E7%AE%A1%E5%85%AC%E5%8F%B8%E4%B8%A2%E5%A4%B1%E6%89%80%E6%9C%89%E5%AE%A2%E6%88%B7%E6%95%B0%E6%8D%AE%E7%9A%84/47 https:/ 48 https:/ 49 https:/ 50 https:/ 51 https:/