摘要：著重介紹Kubeedge在安全防護方面的實踐，并介紹OpenSSF在開源軟體安全方面的計劃與目標，
本文分享自華為云社區《KubeEdge在邊緣計算領域的安全防護及洞察》，作者：華為云云原生團隊，
隨著開源軟體安全漏洞持續引起世界各地政府和企業的關注，越來越多的組織、開發人員、研究人員和安全專家投入到開源安全作業中，在各方力量的推動下，開源安全目前已初步形成體系化的生態大網，覆寫了國際化的軟體工程行業標準、安全評估體系、安全工具鏈與整體解決方案等，并逐步撬動整個業界開源軟體安全行業的生態產業鏈，
在2020年Linux基金會與多家硬體和軟體廠商合作創立了開源軟體安全基金會OpenSSF（Open Source Security Foundation），這是一個跨行業的合作組織，匯集了行業領軍企業與機構，涵蓋世界上最重要的軟體供應鏈安全計劃、開源開放的工具鏈、安全指南、培訓等，旨在提高開源軟體（OSS）的安全性，
作為業界首個云原生邊緣計算專案，KubeEdge社區致力于提升KubeEdge在云原生邊緣計算場景下的安全性，將安全視為社區發展的重要指導原則，社區充分結合了業界的開源安全經驗，于2022年7月完成了對KubeEdge專案的安全威脅模型分析，盡管云原生邊緣計算的安全問題備受用戶關注，但業界目前缺乏相關的安全威脅模型分析，這使得用戶難以有效地加固其邊緣系統，因此，KubeEdge社區發布了安全威脅模型及分析白皮書，為用戶和廠商提供了重要的安全實踐指導，下文將著重介紹Kubeedge在安全防護方面的實踐，并介紹OpenSSF在開源軟體安全方面的計劃與目標，
安全防護背景
KubeEdge在邊端云協同領域正在加速布局，已在智慧交通、智慧城市、智慧園區、智慧能源、智慧工廠、智慧銀行、智慧工地、CDN等行業提供一體化的邊端云協同解決方案，隨著越來越多的用戶將KubeEdge專案用于生產環境中，KubeEdge社區把安全問題放在優先地位，并成立Sig- Security 和安全團隊 ，負責KubeEdge的系統安全設計，并快速回應和處理安全漏洞，為了對KubeEdge專案進行更加全面的安全評估，KubeEdge社區聯合ADA LOGICS公司、OSTIF及云原生計算基金會（CNCF）對KubeEdge專案進行安全評估并輸出安全評估報告，分析和總結KubeEdge專案的安全威脅模型及相關安全問題，該評估對KubeEdge專案的安全防護有重要的指導意義，感謝ADA LOGICS公司的專家Adam Korczynski和David Korczynski在該項作業中的巨大貢獻，同時，感謝OSTIF的Amir Montazery和Derek Zimmer以及CNCF基金會，他們對這次評估提供了很大幫助，
對于安全報告中發現的安全問題，KubeEdge社區已根據社區的漏洞處理策略第一時間完成修復，并針對v1.11、v1.10、v1.9三個版本發布了安全補丁，版本號分別為v1.11.1、v1.10.2和v1.9.4，漏洞公告已發布在https://github.com/kubeedge/kubeedge/security/advisories，
接下來將通過解讀KubeEdge威脅模型，為邊緣計算領域提供更多的安全防護經驗，并在開源軟體供應鏈安全加固作業上為更多的開源社區提供參考，
威脅模型分析
KubeEdge的安全審計報告指出，該系統可能受到外部攻擊、內部操作人員的不當操作和供應鏈攻擊等三種潛在攻擊型別的影響，本章節使用STRIDE威脅建模方法，結合安全審計報告對KubeEdge進行了系統的安全分析，包括上述三個方面，目的是幫助開發者和用戶了解系統中的潛在安全威脅、明確風險并列舉出目前KubeEdge社區已有的消級訓制和安全加固建議，
以下人群使用KubeEdge程序中，了解KubeEdge的威脅模型分析和可能的緩解措施將對他們的作業有所幫助：
? KubeEdge的貢獻者：一個通用的威脅模型對KubeEdge貢獻者很有用，他們可以從整體角度考慮并加固他們的系統，
? 部署KubeEdge的組織：對于在集群中使用KubeEdge的組織來說，了解常見的攻擊和可能的弱點是很有用的，這樣他們就可以檢查和評估自己的配置，
? 安全評估員：負責評估KubeEdge及所屬Kubernetes集群的安全性，通過了解該威脅模型，讓安全評估員可以對系統的安全風險進行更加全面的評估，
? KubeEdge的用戶及其開發人員：需要了解KubeEdge的更新和攻擊，以主動避免未來可能發生的安全風險，
外部攻擊分析
根據STRIDE威脅建模方法對KubeEdge潛在的外部攻擊進行分析，對應的資料流圖如下，
如資料流圖所示，當資料流穿越不同的信任級別（區域）時，就存在信任邊界，已在圖中用紅框標出，下面將詳細分析KubeEdge系統架構中的信任邊界（參考自KubeEdge第三方安全報告）、社區已有的消減措施并給出安全加固建議，
威脅一：云端CloudCore組件與EdgeCore組件之間的連接
描述：該威脅涉及邊緣EdgeCore與云端CloudCore之間的連接，在這個資料流中，較低信任級別組件EdgeCore向較高信任級別組件CloudCore發起訪問，由于EdgeCore在系統中擁有獨立的權限級別，攻擊者控制EdgeCore后，不應該能夠對其他邊緣節點造成負面影響，例如通過攻擊和操控CloudCore來攻擊其他節點（該漏洞描述參考自安全評估報告），
影響：攻擊者惡意修改CloudCore與EdgeCore組件之間的請求和應答報文，導致通信程序存在仿冒和篡改的威脅風險，
消減措施：
? CloudCore與EdgeCore之間的通信通過數字簽名證書加密和服務端/客戶端雙向認證的方式保障資訊互動的機密性和完整性，安全加密協議使用TLS 1.2，且指定加密演算法套件白名單，防止客戶端使用不在白名單中的不安全演算法進行通信造成安全風險；
? 證書默認有效期為一年，過期后失效，防止證書被攻擊者利用，用戶基于KubeEdge專案已有的證書輪轉機制，可以實作證書過期自動更換，保障業務連續性，
針對該威脅，我們建議采取以下安全加固措施（見“安全加固建議串列”中的Recommendation ID 1和2），
威脅二：邊緣組件ServiceBus在本機范圍內提供HTTP服務
描述：邊緣組件ServiceBus監聽本地local host埠并在本機范圍內提供HTTP服務，該資料流中，較低信任級別的用戶應用行程向較高信任級別組件ServiceBus發起訪問，如果發起攻擊，不應該使攻擊者能夠將影響范圍擴大到云端控制面（該漏洞描述參考自安全評估報告），
影響：ServiceBus組件收到的資料往往是不受管理面控制的，攻擊者能夠對ServiceBus組件發起惡意報文攻擊，導致通信程序存在仿冒和篡改的威脅風險，ServiceBus組件例外僅影響單個邊緣節點服務故障，不會導致整個KubeEdge系統崩潰，
消減措施：
? ServiceBus組件僅監聽本地local host埠，已限制服務范圍，只允許本機行程訪問，通過對本機用戶訪問權限的限制保障本組件安全；
? 服務端接收客戶端連接時記錄連接訪問的日志，可作為審計日志，可以讓管理員及時發現攻擊的發生，并及時停止ServiceBus服務，阻止攻擊繼續進行；
? ServiceBus服務默認關閉，遵守默認安全的原則，在用戶使用檔案中已明確提示用戶如果開啟該服務，則存在上述風險，
針對該威脅，我們建議采取以下安全加固措施（見“安全加固建議串列”中的Recommendation ID 3、4和5），
威脅三：邊緣端Device通過MQTT Broker連接到EdgeCore
描述：邊緣device設備通過MQTT Broker（集成在EventBus組件中）連接到EdgeCore，該資料流中，較低信任級別的用戶device設備向較高信任級別組件EdgeCore發起訪問（該漏洞描述參考自安全評估報告），
影響：EdgeCore組件收到的資料往往是不受管理面控制的，攻擊者能夠對MQTT Broker發起惡意報文攻擊，存在仿冒和篡改的威脅風險，如果發起攻擊導致EventBus組件例外，例外僅影響單個邊緣節點服務故障，不會導致整個KubeEdge系統崩潰，
消減措施：
? MQTT Broker僅監聽在本機埠，已限制服務范圍，只允許本機行程訪問，通過對本機用戶訪問權限的限制保障本組件安全；同時，EventBus組件可作為客戶端，對接外置第三方MQTT Broker，如果用戶使用第三方MQTT Broker，詳細的消減措施請參考對應第三方MQTT Broker服務提供廠商的安全檔案，
? EventBus僅對MQTT Broker中的特定Topic進行處理，用戶無法通過該通道對EdgeCore任意訪問，
針對該威脅，我們建議采取以下安全加固措施（見“安全加固建議串列”中的Recommendation ID 3、4、5和6），
威脅四：Edged管理和監控Pods及其他K8s資源
描述：Edged管理和監控Pods及其他K8s資源，該資料流中，較低信任級別的應用容器與較高信任級別組件EdgeCore之間進行資料互動，如果主動發起連接時，被惡意服務器攻擊，不應該使攻擊者能夠將影響范圍擴大到云端控制面（該漏洞描述參考自安全評估報告），
影響：如果Edged訪問的CRI插件被攻擊者惡意偽造，則存在CRI插件仿冒和篡改的威脅風險，導致本地業務例外，
消減措施：
? Edged與CRI插件通信時，只在本地訪問受信任路徑，由管理員控制訪問路徑，最小化Unix domain sockets檔案描述符的權限，避免被仿冒者惡意替換，
針對該威脅，我們建議采取以下安全加固措施（見“安全加固建議串列”中的Recommendation ID 3和7），
威脅五：MetaServer在邊緣節點提供HTTP服務
描述：MetaServer作為邊緣“api-server”，對邊緣插件提供HTTP服務，該資料流中，較低信任級別的用戶應用插件向較高信任級別組件MetaServer發起訪問（該漏洞描述參考自安全評估報告），
影響：MetaServer組件收到的資料往往是不受管理面控制的，攻擊者能夠對MetaServer組件發起惡意報文攻擊，導致通信程序存在仿冒和篡改的威脅風險，MetaServer組件例外僅影響單個邊緣節點服務故障，不會導致整個KubeEdge系統崩潰，
消減措施：
? MetaServer組件僅監聽本地local host埠，已限制服務范圍，只允許本機行程訪問，通過對本機用戶訪問權限的限制保障本組件安全；
? MetaServer服務默認關閉，遵守默認安全的原則，在用戶使用檔案中已明確提示用戶如果開啟該服務，則存在上述風險，
針對該威脅，我們建議采取以下安全加固措施（見“安全加固建議串列”中的Recommendation ID 3、4和5），
內部攻擊分析
對于內部管理員或操作人員，可能的風險主要包括管理員或操作人員錯誤操作將惡意軟體部署至集群中、在高風險場景中執行高風險配置等，
消減措施：
? KubeEdge用戶手冊中已提供各個組件的詳細功能描述及配置使用指導檔案 ，指導系統管理員或操作人員正確操作，減少人為誤操作或誤配置導致的安全風險，由于KubeEdge的持續迭代，該檔案也將持續更新并完善，
針對該威脅，我們建議采取以下安全加固措施（見“安全加固建議串列”中的Recommendation ID 3、4、8和9），
供應鏈攻擊分析
攻擊可能發生在典型軟體供應鏈的每一個環節，而且在當今環境中，這些型別的攻擊越來越公開，破壞性和代價高昂，攻擊方向包括源代碼完整性、構建完整性和構建產物的可用性，
消減措施：
? 社區聯合安全公司對KubeEdge軟體供應鏈流程已進行SLSA等級評估，并引入SLSA軟體供應鏈安全評估框架，包括對源代碼、構建流程、依賴庫等進行安全評估，防止針對軟體供應鏈的攻擊，從源頭上保障軟體供應鏈的安全，
值得一提的是，在2023年1月18日發布的v1.13.0版本中，KubeEdge專案已達到SLSA L3等級（包括二進制和容器鏡像構件），成為CNCF社區首個達到SLSA L3等級的專案，并加入Sigstore生態系統，實作更高等級的安全標準，
? KubeEdge倉庫CI/CD流水線中已開啟dependence bot第三方依賴庫檢查功能，及時發現第三方依賴庫的安全漏洞并在KubeEdge版本中同步更新，降低被攻擊的風險；
? KubeEdge security team已具備完整漏洞處理機制，包括漏洞發現、漏洞上報、漏洞分析處理、漏洞披露和發布整個流程，可以及時處理和修復安全漏洞，詳細漏洞處理及披露策略請見https://github.com/kubeedge/community/blob/master/security-team/SECURITY.md，
針對該威脅，我們建議采取以下安全加固措施（見“安全加固建議串列”中的Recommendation ID 10和11），
安全加固建議串列
開源安全洞察
本章節通過對OpenSSF社區的戰略規劃、OpenSSF作業組內容及開放源代碼軟體安全動員10個TOP計劃進行介紹，為相關從業人員、開源生態產業提供參考，
1) OpenSSF介紹
社區作業組
為了更好的提升開源軟體安全，OpenSSF目前已成立了8個作業組，主要負責開源軟體開發最佳實踐、軟體代碼安全、用戶、安全工具鏈、開源專案安全威脅識別、軟體供應鏈完整性、保護關鍵開源專案、漏洞披露，
相關專案
1. OpenSSF最佳實踐徽章（OpenSSF Best Practices Badge Program）
開源軟體開發的最佳實踐目的是提供開源開發者安全相關行業標準、框架、安全指導、課程、開源安全評估體系、包括工具支持開發人員日常開發程序的軟體安全檢測，開源專案可以通過OpenSSF最佳實踐徽章專案進行最佳實踐評估，該專案是自由/開源軟體（FLOSS）專案展示其遵循最佳實踐的一種方式，可以通過使用這個網站來解釋他們如何遵循每個最佳實踐，從而自愿地進行自我認證，認證分為通過、銀、金三個級別，不需要任何費用，該專案是基于核心基礎設施倡議（CII）專案發展而來，
2. 積分卡（Scorecards）
通過Scorecards積分卡專案可以實作自動化地對開源專案相關安全指標進行評估，以加強專案的安全狀況，根據專案的評估結果給出0-10分數，幫助專案maintainer改進專案安全，
3. 安全知識框架（Security Knowledge Framework）
SKF是一個完全開源的Python-Flask / Angular網路應用程式，它使用許多其他的開源專案來訓練你和你的團隊通過設計來構建安全的應用程式，其涵蓋了整個軟體開發生命周期如構建、測驗、需求、設計、代碼開發、度量、培訓等環節，
4. 安全開發指南
提供安全開發、安全評估的詳細指導步驟，以開發者使用視角將上面的專案全部串接起來，已完整覆寫了OpenChain Security Assurance Specification、SLSA、工具如 GitHub's dependabot、GitLab dependency scanning、Scorecards check等，
5. 教育與培訓課程
提供開發人員免費的安全開發課程，完成學習后可以發放證書有效期2年，
6. 軟體構建供應鏈級別（SLSA）
軟體構建的供應鏈級別SLSA由Google貢獻給OpenSSF，是軟體供應鏈完整性的安全標準準則，以幫助企業和開源生態確保軟體開發生命周期的安全，ScoreCards是SLSA度量的工具組成部分，
7. 令牌分發專案
Great Multi-Factor Authentication (MFA) 分發專案，致力于將硬體 MFA 令牌分發給關鍵的 100+開源軟體專案，目標是防止開源軟體開發憑據薄榷訓受損的供應鏈攻擊，
8. 包管理最佳實踐
提供業界主流的構建框架、包管理器的最佳實踐如 maven、gradle、npm、pip、RubyGems，重點介紹其依賴管理、可重復構建、發布、基于包管理的漏洞披露等，
當前檔案還不完善，只重點介紹了npm，其它的包管理器待建設中，
9. C/C++編譯選項
制定 C/C++場景的編譯選項規則，避免潛在的安全風險和被攻擊的風險，當前在范訓階段，
10. 開源社區安全教育SIG
當前在范訓階段，主要致力于提供行業標準的安全軟體開發相關的培訓材料，提供網路和應用程式安全方面的最佳實踐輔導開發人員安全地創建、撰寫、部署和維護軟體，
OpenSSF安全工具鏈
安全領域涉及面廣，規則規范多，開發人員甚至從事資深安全作業的專家人工識別冗余遺漏，安全工具鏈用于快速識別安全風險，使開發人員專注于功能特性開發，
覆寫范圍：涵蓋整個DevSecOps的各環節工具鏈，并支撐開源軟體開發的最佳實踐章節，如：
linters(cleanCode), SAST, SCA, DAST, Fuzzers, Hard Coded Secrets Detectors, and SBOM generators，
提供方：部分來自公司捐贈，部分來自OpenSSF基金會自主規劃，部分在規劃階段待建設，
2) 開源軟體安全動員計劃及目標
2022 年 1 月，美國政府專家、 OSS 基金會、相關企業在白宮舉行會議討論，制定如下三個動員計劃的總體目標：
? 保護 OSS 生產：首先是專注于防止安全缺陷、代碼和開源包漏洞
? 改進漏洞識別和修復：改進缺陷識別程序、漏洞修復
? 縮短補丁回應時間：縮短漏洞披露和修復時間
在2022年5月第二屆開源軟體安全峰會上，Linux基金會、OpenSSF及各行業安全專家，就提高開源軟體安全性計劃達成共識，將集中在以下10個方向進行投資和安全改善，專案投資1.5億美元，分為兩年規劃，
備注：動員計劃和OpenSSF作業組是相輔相成的，其動員計劃的能力會融入到作業組中，
總結
本文通過從外部攻擊面、內部攻擊面及軟體供應鏈三個維度對KubeEdge專案進行安全威脅建模，實作對KubeEdge專案的系統性安全評估，幫助社區maintainer及時發現和修復安全風險，同時，對業界OpenSSF社區開源安全策略及相關專案進行洞察，通過洞察分析可以看出，越來越多的組織、開發人員、研究人員和安全專家將加大投入資源來加強開源安全，并已逐步形成業界開源安全行業的生態產業鏈，在開源安全上占據標準高地可以為后續的商業擴展提供有力地位，KubeEdge社區結合業界安全理念，將能夠推動社區持續鞏固和演進專案的安全，
附錄
相關鏈接
? 社區漏洞處理機制: https://github.com/kubeedge/kubeedge/security/policy
? 安全審計報告: https://github.com/kubeedge/community/tree/master/sig-security/sig-security-audit/KubeEdge-security-audit-2022.pdf
? 社區security advisory鏈接: https://github.com/kubeedge/kubeedge/security/advisories
? KubeEdge威脅模型及安全防護分析（本檔案）: https://github.com/kubeedge/community/tree/master/sig-security/sig-security-audit/KubeEdge-threat-model-and-security-protection-analysis.md
? 社區用戶檔案鏈接: https://kubeedge.io/en/docs
? SLSA軟體供應鏈安全框架: https://slsa.dev/spec/v0.1/#supply-chain-threats
? KubeEdge實作SLSA L3分析: https://kubeedge.io/en/blog/reach-slsa-l3/
? Release版本發布鏈接: https://github.com/kubeedge/kubeedge/releases
? 開源軟體安全動員計劃：https://cta-redirect.hubspot.com/cta/redirect/8112310/3b79d59d-e8d3-4c69-a67b-6b87b325313c
? OpenSSF最佳時間徽章：https ://bestpractices.coreinfrastructure.org/en
? 最佳實踐專案：https://github.com/ossf/wg-best-practices-os-developers
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/552013.html
標籤：其他
上一篇：使用 shell 腳本自動申請進京證 (六環外) —— debug 程序
下一篇：返回列表