網路資安威脅
最常導致資安事件的雲端組態設定錯誤
在疫情期間,雲端加速了企業機構的數位轉型。雲端的可靠性與彈性,讓企業得以在這段艱困時期能加速轉型至遠距上班模式。然而,急就章地導入雲端很容易因為疏失或對雲端服務組態設定了解不夠而導致錯誤,也就是一般常說的組態設定錯誤。企業理所當然必須小心防範雲端內部各種複雜的資安威脅[AC(T1] ,但企業同時也應留意一些單純的組態設定錯誤,因為它們最終也可能讓營運關鍵系統和資產設備意外暴露在風險中。
組態設定錯誤看似單純且可避免,但卻是目前雲端環境最常見的一項風險。事實上,有 65% 至 70% 的雲端資安挑戰都是因為組態設定錯誤而引起。雲端包含了各式各樣的設定、政策、資產,以及環環相扣的服務和資源,這使得雲端變成一個非常複雜的環境,不但難以理解透徹,也不容易正確設定。一些因為遠距上班需求而被迫迅速移轉至雲端的企業更是如此。不幸的是,當企業太快導入新的技術卻沒有完全掌握其複雜性時,組態設定錯誤就在所難免。
由於組態設定錯誤有可能成為駭客攻擊利用的途徑,因此很可能導致嚴重後果,這也是近年許多大型資安事件背後的元凶。2018 和 2019 年間,因雲端組態設定錯誤而引起的資安事件造成了將近 5 兆美元的企業損失。2020 年,全球化妝品品牌 Estee Lauder (雅詩蘭黛) 外洩了 4.4 億筆資料,其中包含了使用者電子郵件地址,以及稽核、錯誤、CMS、中介軟體、生產線等記錄檔,全都只因為某個資料庫未正確設定密碼所致。2020 年,成人網站 CAM4 意外洩漏了108.8 億筆資料,其中包含了使用者的個人身分識別資訊 (PII)、付款記錄以及密碼雜湊碼,同樣也是因為某個 Elastic Search 資料庫未設定安全防護所引起。
組態設定錯誤一直是企業機構和政府機關發生重大財務及聲譽損失的主因之一。所以,任何採用雲端的企業機構都務必對這些常見的組態設定錯誤有所認識,才能加以防範,以免遭駭客利用造成更大損失。趨勢科技從 Trend Micro Cloud One™ – Conformity 在 2020 年 6 月 30 日至 2021 年 6 月 29 日一整年間所蒐集到的資料當中分別整理出 Amazon Web Services (AWS) 和 Microsoft Azure 最常違反 Cloud Conformity 組態設定規則的 10 項服務。
組態設定錯誤發生率最高的 10 項 AWS 服務
趨勢科技整理出 Cloud Conformity 檢查執行次數最多的 10 個 AWS 服務 (參見圖 1),這些是 Cloud Conformity 客戶對其基礎架構或資源的組態設定執行 Cloud Conformity 規則掃描的數據。一個雲端服務很可能會定期掃描多條 Cloud Conformity 規則來檢查其漏洞和風險,掃描時會檢查這些規則是否被落實。每一條 Cloud Conformity 規則都會產生一筆檢查的結果,檢查時會判斷這些規則是否正確落實。請注意,檢查的數量與組態設定錯誤的嚴重程度或某個服務的風險程度無關。Cloud Conformity 使用者可選擇對其基礎架構和資源同時執行少數幾項或是很多項檢查。
接著,我們再計算每條規則對應的組態設定錯誤發生率 (參見圖 2),也就是掃描時發現這些規則未正確被落實的比例。值得注意的一點是,組態設定錯誤本身並不會讓應用程式變得不安全,但會讓駭客有機會駭入雲端環境對企業機構造成危害。雲端服務通常很安全,雲端服務供應商 (CSP) 會善盡其應共同分擔的資安義務,採取最高標準來設計、建置、並不斷檢討其基礎架構。但如果客戶未妥善設定雲端資源和服務,那就會造成組態設定錯誤,進而影響雲端應用程式的品質。
在所有組態設定錯誤檢查規則當中,嚴重性最高且發生率高達 100% 的是「AWS CloudTrail configuration changes」(AWS CloudTrail 組態設定變更),這是 Cloud Conformity 針對 AWS CloudTrail 服務設計的一條規則。AWS CloudTrail 可讓使用者定期登入並監控帳號中有關執行 AWS 基礎架構相關動作的活動。並提供一項功能可讓使用者查看 AWS 帳號活動的歷史記錄,提供一種更簡單、更有效率的資安稽核、資源變更追蹤與疑難排解方式。如果這項功能未啟用,系統就不會監控並記錄組態設定變更,這樣使用者就無法得知某個動作是誰做的、何時發生,以及影響到哪些資源。
至於 Amazon EBS 服務,其最常犯的高嚴重性組態設定錯誤檢查規則是「App-tier EBS encrypted (應用程式層 EBS 加密),其發生率也是 100%。當此功能未啟用時,與應用程式層 EC2 執行個體連結的 AWS EBS 磁卷所儲存的資料就會暴露在外,包括磁卷上保存的資料、磁碟輸入和輸出作業,以及從該磁卷所做的快照。
除此之外,「enable Amazon S3 block public access for AWS accounts」(啟用 AWS 帳號對 Amazon S3 區塊儲存的公開存取) 是 Amazon Simple Storage Service (S3) 最常犯的組態設定錯誤檢查規則,其嚴重性分類為「非常高」,組態設定錯誤發生率 68.97%。這項功能可讓儲存貯體 (bucket) 持有人有效率地設定一些控管來管制其 Amazon S3 資料的公開存取。當此功能未啟用時,只需很簡單的組態設定錯誤就可能讓 Amazon S3 儲存貯體的資料暴露在外,讓人公開存取,進而導致資料外洩。
為了防範潛在的組態設定錯誤和資安風險,Amazon 為用戶提供了一整套的最佳實務建議,也就是 AWS Well-Architected 架構,以及一些預防性的資安最佳實務原則與監控與稽核指導原則來維護 Amazon S3 儲存貯體的安全。但即使這些資料唾手可得且說明詳盡,但使用者仍可能因為沒有真正落實而讓 Amazon S3 儲存貯體暴露在外,變成可公開存取。
近年來,我們不斷看到企業機構因 Amazon S3 儲存貯體組態設定錯誤而受到重挫。今年,美國有數十個都會區的民眾因政府的資訊管理軟體中有 86 個 Amazon S3 儲存貯體未受到妥善保護而外洩了超過 160 萬個檔案。
AWS 中最常發生的組態設定錯誤
在這份排行榜中有兩條規則,也就是「AWS AMI encryption」(AWS AMI 加密) 和「EBS encrypted」(EBS 加密) 是屬於高嚴重性組態設定錯誤檢查規則,其對應的組態設定錯誤在所有 Cloud Conformity 用戶當中的發生率兩者都是 70.06%。這些規則可協助企業確實遵守支付卡產業資料安全標準 (PCI DSS)、健康保險可攜性與責任法案 (HIPAA)、通用資料保護法 (GDPR)、澳洲金融監理局 (APRA)、新加坡金管局 (MAS) 以及 美國國家標準與技術局 (NIST) 800-53 (Rev. 4) 等的法規標準。
這兩項高嚴重性的組態設定錯誤都跟儲存 (bucket 或 blob) 的組態設定錯誤、加密以及確保機敏資料不會公開曝光有關,因為這些問題可能導致資料外洩、營運中斷及巨額的罰鍰。曾有一家通路管理軟體服務廠商就是因為這樣而外洩了 1,000 萬個檔案,其中包含旅遊業客戶的個人身分識別資訊 (PII) 與金融資料。
組態設定錯誤發生率最高的 10 項 Microsoft Azure 服務
Azure Advisor 服務是排行榜第一名,Cloud Conformity 檢查的執行次數高達 94,095 次,組態設定錯誤發生率高達 100%。其次是 Azure Activity Log,這是一個用來「提供訂閱層次事件詳細資訊」的 Azure 工具,其組態設定發生率為 97.56% (在 33,416 次檢查當中發現 32,602 次)。使用者應定期查看 Azure Activity Log,因為它可提供組態設定變更相關的資料,準確地蒐集和分析 Azure Activity Log 資料可讓使用者密切注意系統是否出現一些潛在的惡意活動。
在這項 Azure 服務中,排名最高的組態設定錯誤檢查規則都跟 PostgreSQL 全託管式資料庫服務 (Database-as-a-Service) 平台有關。「Create alert for ‘delete PostgreSQL database’ events」(針對 PostgreSQL 資料庫刪除事件產生警示) 與「create alert for ‘create/update PostgreSQL database’ events」(針對 PostgreSQL 資料庫建立/更新事件產生警示) 這兩條規則的組態設定錯誤發生率為 99.10%。PostgreSQL 資料庫如果設定不當卻放著不管,就有可能會被駭客用於虛擬加密貨幣挖礦攻擊,例如 2020 年發現的 PGMiner 殭屍網路就是一個例子。
組態設定錯誤發生率第三高的是Azure Virtual Machines (VM) 隨選運算資源,發生率 61.49% (在 257,599 次檢查當中發現 158,406 次)。在 Azure VM 檢查規則當中,組態設定錯誤發生率高達 100% 的規則有「install approved extensions only」(僅安裝獲得許可的延伸功能) 及「enable automatic OS upgrades」(啟用作業系統自動升級)。在 Azure 環境中使用含有漏洞的延伸功能,很可能讓駭客提升自己的權限或執行遠端攻擊。最近,駭客利用許多 Azure VM 管理延伸功能所採用的 Open Management Infrastructure (OMI) 開放管理基礎架構框架的 Azure OMIGOD 漏洞來發動攻擊。Microsoft 隨後已針對含有漏洞的延伸功能釋出延伸功能更新。
Azure Storage Account 是一項彙整所有 Azure 儲存體物件的服務,其組態設定錯誤發生率為 60.75% (在 504,421 次檢查當中發現 306,433 次)。近來資料外洩事件猖獗,且代價高昂,企業必須盡可能確保其儲存體帳號的安全。今年,組態設定不當的 Azure 儲存體帳號意外洩漏了數以百萬計的檔案,其中包含了各種機敏資訊,如:醫療記錄、個人資訊、合約、發票等。緊接著排在 Azure 儲存體帳號之後的是 Azure App Service,其組態設定錯誤發生率為 55.53% (在 70,521 次檢查當中發現 37,748 次)。
Azure 中最常發生的組態設定錯誤
根據資料顯示,就組態設定錯誤發生率來看,排行最高的 Microsoft Azure 組態設定錯誤檢查規則是「check for Azure Advisor recommendations (檢查 Azure Advisor 建議事項),其發生率為 100%,在所有 94,095 次檢查當中每次都發現組態設定錯誤。這條規則的嚴重性隨 Azure Advisor 的嚴重性評等而定,此工具專門協助使用者提升其資源的成本效益、效能、穩定性及安全性,提供詳細的資源組態設定分析與用量監測數據。使用者若未經常查看 Azure Advisor 的建議事項,就無法掌握其雲端環境可能已經遭駭客攻擊的狀況。Azure Advisor 可與 Azure Security Center 整合,能標記一些像虛擬加密貨幣挖礦與暴力登入之類的攻擊,好讓使用者加以防範與矯正。
緊接著排名第二的組態設定檢查規則是「enable immutable blob storage」(啟用不可修改的 blob 儲存體),這是一個高嚴重性的儲存 (bucket/blob) 組態設定錯誤,發生率 99.79%,在所有客戶當中發生 177,852 次。「不可修改的 blob 儲存體」能讓使用者儲存一些單次寫入、多次讀取 (WORM) 的營運關鍵資料,這樣基本上能防止資料在使用者指定的期間之內遭到修改或刪除。而且由於勒索病毒攻擊手法日趨精密 (例如使用雙重勒索手法的現代化勒索病毒),這道額外的防護能確保營運關鍵資料的安全,在一定的期間之內防止資料被任何使用者 (如駭客) 修改或刪除。
除了「enable immutable blob storage」之外,在這份 10 大排行榜中還有四個高嚴重性的組態設定錯誤,分別是:
Azure 組態設定檢查規則 | 組態設定錯誤類別 |
Enable just-in-time access for virtual machines (啟用虛擬機器 Just-In-Time 存取) | 身分與存取管理 (IAM) 組態設定錯誤、可攻擊的服務開放連接埠 |
Enable encryption for boot disk volume (啟用開機磁卷加密) | 儲存 (bucket/blob) 組態設定錯誤、資料加密問題 |
Use Bring Your Own Key (BYOK) for storage account encryption (使用自備金鑰來進行儲存帳號加密) | 資料加密問題 |
Use BYOK for disk volumes encryption (使用自備金鑰來進行磁卷加密) | 儲存 (bucket/blob) 組態設定錯誤、資料加密問題 |
當 Azure VM 組態設定不當時,駭客很可能會發動分散式阻斷服務 (DDoS) 和暴力登入攻擊。[ICC(T2]
另一條常犯的 Microsoft Azure 組態設定錯誤檢查規則是「disable anonymous access to blob containers」(停用 blob 容器的匿名存取),發現次數為 83,587 次,發生率 35.02%。值得注意的是,匿名存取的功能並非預設啟用,但如果使用者為了資料分享的方便而啟用此功能的話,任何人就都能讀取容器及 blob 內的資料。為了避免資料外洩,Microsoft 建議停用匿名存取,僅在特定應用情境需要時才將它啟用。此外,該公司也建議使用者透過 Azure Metrics Explorer 來追蹤儲存體帳號所收到的任何匿名請求。
虛擬加密貨幣挖礦攻擊會占用受害系統的運算資源,是駭客入侵 Azure 環境經常採用的方式。去年曾經發生機器學習所使用的 Azure Kubernetes 叢集因組態設定不當而被駭客入侵並植入虛擬加密貨幣挖礦程式的事件。今年稍早,趨勢科技也曾經指出專門攻擊雲端與容器環境的 TeamTNT 駭客集團入侵了數千個 Kubernetes 叢集來挖礦。今年,駭客又更上層樓,大剌剌地將挖礦行為隱藏在正常作業當中:他們使用以官方 Docker Hub 帳號執行合法容器映像的 TensorFlow Pod 來執行惡意程式碼以及挖礦作業。
除了非法的虛擬加密貨幣挖礦之外,駭客今年也使用一個經過高度加密編碼、名為「Siloscape」的惡意程式在組態設定不當的 Kubernetes 叢集上執行惡意容器並竊取關鍵資料。
避免錯誤:企業如何防範雲端內的組態設定錯誤?
雖然雲端服務供應商 (CSP) 通常都能妥善保護其雲端服務的基礎架構, 但使用者務必了解自己可能造成或忽略了一些可能傷害自己的組態設定錯誤。一些看似單純的組態設定錯誤卻很可能帶來一些災難,例如資料外洩或勒索病毒攻擊,不幸的是這種強況還屢見不鮮。
很重要的是,企業是要了解雲端並非是一套內建安全防護的環境,因此務必知道自己該扮演什麼角色來保障其雲端環境的安全。
以下是一些防範組態設定錯誤的資安建議:
- 僅提供最低限度的存取權限。使用者僅應獲得其工作上所必要的存取權限,這一般稱為「最低授權原則」。唯有真正需要的人員才能被授予系統管理 (root) 權限。一旦具備系統管理權限的使用者帳號被駭客入侵,駭客就有可能入侵整個網路。因此,限制擁有系統管理權限的人員數量,自然可有效降低駭客入侵的風險。
- 履行共同分擔的資安責任。共同分擔資安責任的架構強調雲端服務供應商與使用者之間須共同分擔責任。當使用者了 解自己該承擔的營運責任時,組態設定錯誤的風險就能降低。例如,有些 VM 或執行個體會內建一些雲端服務供應商提供的部署服務。使用者若用到這些服務,就必須了解自己必須負起監控、維護、修正其組態設定的責任以確保安全並符合法規。AWS 和 Microsoft Azure 都提供了一些文件來向使用者說明其共同分擔資安責任的架構。
- 教育及訓練團隊成員。團隊成員必須了解自己在資安方面的責任,從發掘不安全的作業方式到盡速回報資安問題,每一位成員都應接受一些教育訓練來了解該注意哪些威脅與組態設定錯誤。AWS 使用者若擔心組態設定錯誤的問題,可加入 AWS Partner Network 來取得資安相關的支援,包括:工具、諮詢、訓練以及託管式服務。
- 制定並實施資安政策、標準及程序。企業應制定並實施有效而詳盡的資安政策、標準及程序,來降低組態設定錯誤的風險。企業應制定並嚴格落實開放原始碼元件使用方式、遠端存取、密碼建立與管理、加密與解密、資料庫等政策。
原文出處:The Most Common Cloud Misconfigurations That Could Lead to Security Breaches