Harbor使用者必讀:安全告警和響應機制
題圖攝於巴塞羅那港
注:微信公眾號不按照時間排序,請關注“亨利筆記”,並加星標以置頂,以免錯過更新。
在生產系統中使用 Harbor 的使用者,需要及時瞭解各種發現的 Harbor 安全漏洞或者問題,並採取必要的反饋、確認和修補措施。本文介紹如何接收安全漏洞的告警通知、如何彙報可能的安全問題,並且採取適當的響應策略。建議使用者收藏本文。
本文節選自《Harbor權威指南》一書。目前噹噹網優惠中,點選下圖直接購買。
Harbor 是首箇中國原創的 CNCF 畢業(Graduated)級別專案,意味著 Harbor 的成熟度已經被大多數使用者接受,在生產環境下有非常多的部署和應用。和所有的軟體專案一樣,Harbor 可能會出現一些安全問題。儘管 Harbor 專案在申請畢業時經過了安全性審計(Security Audit)並且修復了發現的問題,但是作為一個大型開源社群,Harbor 專案制定並採用了安全披露和響應策略,以確保在出現安全方面的問題時,維護者可以快速地處理和響應。
Harbor 的使用者或廠商應當緊密關注 Harbor 的安全公告和安全補丁,及時給所執行的 Harbor 系統升級或安裝補丁程式。如果發現安全問題,則應當及時報告Harbor 安全團隊,以便確認和提供修復補丁。Harbor 的發行商還可以申請加入安全問題通知郵件組。(注:微信公眾號不按照時間排序,請關注“亨利筆記”,並加星標以置頂,以免錯過更新。)
1.支援的版本
Harbor 社群維護著最後釋出的三個次級版本。如最新版本是 2.0.x 時,社群維護的版本是 1.9.x、1.10.x 和 2.0.x,當出現安全問題時,會根據嚴重性和可行性將適用的安全補丁程式移植到這三個版本上。為了獲得安全補丁程式,建議使用者採用在維護範圍內的版本。如果使用者目前執行的版本較舊,則會有潛在的安全風險,而且 Harbor 團隊可能不提供修復方案,因此最好把版本升級。(本文為公眾號:亨利筆記 原創文章)
2.報告安全漏洞的私下披露流程
系統的安全性是使用者最需要關注事情之一,當使用者發現安全漏洞或疑似安全漏洞時,都應私下報告給 Harbor 專案維護者,這樣可以在漏洞修復前最大限度地減少 Harbor 使用者受到的攻擊。維護者將盡快調查漏洞,並在下一個補丁程式(或次要版本)中進行修補。漏洞的資訊可以完全保留在專案內部來處理。
當使用者有下列情形之一時,可以報告漏洞。
◎認為 Harbor 有潛在的安全漏洞。
◎懷疑潛在的漏洞,但不確定它是否會影響 Harbor。
◎知道或懷疑 Harbor 使用的另一個專案有潛在漏洞,如 Docker Distribution、PostgreSQL、Redis、Notary、Clair、Trivy 等。
要報告漏洞或與安全相關的問題,使用者可透過電子郵件向 cncf-harbor-security @ lists. cncf.io 傳送有關漏洞的詳細資訊,該電子郵件會被由維護者組成的 Harbor 安全團隊接收。電子郵件將在3個工作日內得到處理,包括調查該問題的詳細計劃及可以變通的方法。如果發現一個有關 Harbor 的安全漏洞被公開披露,則請立即傳送電子郵件至cncf-harbor-security @ lists. cncf.io 來聯絡 Harbor 的安全團隊。
重要提示:出於對使用者社群的保護,不要在 GitHub 或其他公開媒體上釋出關於安全漏洞的問題。
傳送的電子郵件需提供描述性郵件標題,電子郵件正文中包含以下資訊。
◎ 基本身份資訊,如彙報人的姓名、所屬單位或公司。
◎ 重現此漏洞的詳細步驟(可包括 POC 指令碼,螢幕截圖和抓包資料等)。
◎ 描述此漏洞對 Harbor 的影響及相關的硬體和軟體配置,以便 Harbor 安全團隊可以重現此漏洞。
◎ 如果有可能,則描述漏洞如何影響 Harbor 的使用及對攻擊面的估計。
◎ 列出與 Harbor 一起使用以產生漏洞的其他專案或依賴項。
3.補丁、版本和披露報告
在收到漏洞報告之後,Harbor 安全團隊會對漏洞報告作出響應,流程如下。
(1)安全團隊將調查此漏洞並確定其影響和嚴重性。
(2)如果該問題不被視為漏洞,則安全團隊將提供詳細的拒絕原因。
(3)安全團隊將在3個工作日內與報告人進行聯絡。
(4)如果確認了漏洞及修復時間表,安全團隊則將制定計劃與適當的社群進行溝通,包括確定緩解的步驟,受影響的使用者可以透過這些步驟來保護自己,直到修復程式釋出為止。
(5)安全團隊還將使用 CVSS(Common Vulnerability Scoring System)計算器建立一個CVSS。因為需要快速行動,所以安全團隊並不追求計算出完美的 CVSS。安全問題也可以使用此 CVSS 報告給 MITER 公司,報告的 CVE(Common Vulnerabilities and Exposures)將被設定為私密狀態。
(6)安全團隊將修復漏洞並進行測試,併為推出此修復程式做準備。
(7)安全團隊將透過電子郵件向郵件組 cncf-harbor-distributors-announce @ lists. cncf.io 進行該漏洞的早期披露。該郵件組的成員主要是 Harbor 軟體發行商,可以在漏洞公佈和修復之前做出應急計劃,並且可以提前測試補丁並向 Harbor 團隊提供反饋。
(8)漏洞的公開披露日期將由 Harbor 安全團隊、漏洞提交者和發行商成員協商確定。安全團隊希望在使用者緩解措施或補丁可用的情況下,儘快將漏洞完全公開披露。在尚不完全瞭解漏洞機理和修復方法、解決方案未經過充分測試或者發行商還未協調時,漏洞披露會被適當延遲。漏洞披露的時限是從即刻開始(尤其是已經公開的情況)到幾周內。對於有直接緩解措施的嚴重漏洞,公開披露的時間大約是收到報告起的14個工作日。公開披露的時間點將由Harbor 安全團隊全權負責決定。
(9)當修復方法確認後,安全團隊將在下一個補丁程式或次要版本中修補漏洞,並將該補丁程式移植到所有受支援的早期版本中。釋出修補過的 Harbor 版本後,安全團隊將遵循公開披露流程。
4.公開披露流程
安全團隊透過 GitHub 網站向 Harbor 社群釋出公告。在大多數情況下,安全團隊還會透過 Slack、Twitter、CNCF 郵件組、部落格和其他渠道進行通知,以指導Harbor 使用者瞭解漏洞並獲得修補的版本。安全團隊還將釋出使用者可以採取的緩解措施,直到他們可以將補丁應用於其 Harbor 例項為止。Harbor 的分銷商將自行建立和釋出自己的安全公告。(本文為公眾號:亨利筆記 原創文章)
5.提早接收漏洞資訊的發行商
使用者可透過 cncf-harbor-security @ lists. cncf.io 向Harbor安全團隊報告安全問題,並在公開披露漏洞之前私下討論安全問題和修復方法。
建議 Harbor 的發行商申請加入郵件組 cncf-harbor-distributors- announce @ lists. cncf .io,以獲得早期非公開的漏洞通知,包括緩解步驟和有關安全修補版本等資訊。由於這個郵件組的特殊作用,符合以下要求的發行商才有資格申請加入:
◎成為現行的 Harbor 發行商。
◎Harbor 使用者群體不侷限於發行商內部。
◎有可公開驗證的修復安全問題的記錄。
◎不得成為其他發行商的下游廠商或產品重構者。
◎成為 Harbor 社群的參與者和積極貢獻者。
◎接受禁運政策(Embargo Policy)。
◎有已經在郵件組中的成員擔保申請人的參與資格。
6.禁運政策
在郵件組 cncf-harbor- distributors-announce @ lists. cncf.io 中收到的資訊,除非得到 Harbor 安全團隊的許可,成員不得在任何地方公開、共享或暗示,並且在本組織中只能告知需要知道的人。在商定的公開披露時間之前,需維持這樣的保密狀態。郵件組的成員除為自己發行版的使用者解決問題外,不能出於任何原因使用該資訊。在與解決問題的團隊成員共享郵件組中的資訊之前,必須讓這些團隊成員同意相同的條款,並且把了解該資訊的人員控制在最小的範圍內。(本文為公眾號:亨利筆記 原創文章)
如果成員不慎把資訊洩露到本政策允許的範圍之外,則必須立即將洩漏資訊的內容及洩漏資訊的物件緊急通知 cncf-harbor-security @ lists. cncf.io 郵件組。如果成員持續洩漏資訊並違反禁運策略,則將會被從郵件組中永久刪除。
如果需要申請加入郵件組,則可發郵件到cncf-harbor-security @ lists .cncf.io,在郵件中說明本組織滿足以上描述的“成員資格標準”。禁運政策的條款和條件適用於此郵件組的所有成員,要求加入成員代表已接受了禁運政策的條款。
7.機密性,完整性和可用性
Harbor 安全團隊最關注的問題是損害使用者資料機密性和完整性的漏洞。系統可用性,特別是與 DoS(拒絕服務攻擊)和資源枯竭相關的問題,也屬於嚴重的安全問題。Harbor 安全團隊會認真對待所有報告的漏洞、潛在漏洞和可疑漏洞,並將以緊急和迅速的方式進行調查。
注意:Harbor 的預設設定並不是安全設定。使用者必須在 Harbor 中顯式配置基於角色的訪問控制及其他與資源相關的控制功能,以加固 Harbor 的執行環境。對於使用預設值的安全披露,安全小組將不採取任何行動。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31557890/viewspace-2754930/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 響應式流的核心機制——背壓機制
- 前端必讀:Vue響應式系統大PK前端Vue
- iOS 中的事件傳遞和響應機制 - 原理篇iOS事件
- iOS 中的事件傳遞和響應機制 - 實踐篇iOS事件
- iOS 中的事件傳遞和響應機制 – 實踐篇iOS事件
- 前端必讀:Vue響應式系統大PK(下)前端Vue
- 徹底理解安卓應用無響應機制安卓
- 響應式程式設計機制總結程式設計
- vue2.0與3.0響應式原理機制Vue
- 容器雲平臺監控告警體系(五)—— Prometheus傳送告警機制Prometheus
- JVM探究(一)談談雙親委派機制和沙箱安全機制JVM
- Roguelike機制的原理和應用
- Linux安全機制Linux
- Java安全基礎之Java反射機制和ClassLoader類載入機制Java反射
- 理解Cookie和Session機制,及其安全問題CookieSession
- 細說夜鶯監控系統告警自愈機制
- boost http響應讀取HTTP
- 再讀Handler機制
- 快速失敗機制&失敗安全機制
- 網路安全事件應急響應事件
- Deep Reading | 從0到1再讀注意力機制,此文必收藏!
- 理性遊戲設計應用指南,理解“原子引數”的運作機制和影響!遊戲設計
- 雲監控告警2.0:革新傳統告警機制,引領智慧化監控新時代
- 深度解析Spring AI:請求與響應機制的核心邏輯SpringAI
- 小程式技術科普:執行機制&安全機制
- Android系統安全機制Android
- 應急響應靶機-3
- 應急響應靶機-4
- 學習SpringMVC必知必會(3)~springmvc的請求和響應SpringMVC
- 什麼是應急響應?網路安全應急響應體系的要素!
- Nginx主要應用場景(必讀)Nginx
- 給 SAP BTP 平臺上的 Java 應用增添使用者登入和認證機制Java
- 記一次安全應急響應事件事件
- 薩摩耶雲建立資料安全應急處置機制可靠性和穩定性
- 什麼是應急響應?網路安全應急響應的物件是什麼?物件
- 為什麼需要應急響應?網路安全應急響應需要做什麼?
- 理解響應者和響應鏈如何處理事件事件
- 教你如何強制退出Mac無響應程式Mac