阿里雲、GitLab 與客戶或許都有責任 - 阿里雲程式碼洩露事件評論
版權宣告: 本部落格所有內容除特殊說明外,均系原創,允許轉載,但需註明來源。
過去幾天,關於阿里雲程式碼倉庫許可權設定問題,導致多個大型企業資訊與資料外洩的訊息,引起了開發者社群的不少關注與討論。事情的原委已有很多新聞網站發表,如 InfoQ 新聞: 一個“Internal”牽扯出的程式碼洩露,阿里雲獨家迴應 ,這裡不再贅述。我想討論的是該事件的技術細節以及我個人的看法。
GitLab:不合理的專案設定
我自己並未使用阿里雲效平臺。從各方的評論來看,該平臺應該是在 Gitlab 社群版 基礎上修改而來的,因而繼承了 Gitlab 的許多特性,包括專案初始建立時的許可權設定,也就是引發這次風波的 Internal
選項:
圖中可見,Gitlab 確實提供了 Internal
選項,其說明為“所有登入使用者均可見”。當然,預設選擇還是 Private
。而其他廠商包括 Github 在內提供的只有 Public/Private。Gitlab 之所以這樣設計,可能是以公司內部託管原始碼這種應用作為典型場景,這時面向公司內部公開是可以理解的。但對以原始碼託管作為服務的公有云提供商,這樣的設計就有問題了。從使用者角度理解,所謂 Internal
一般會理解為對公司內部公開,而對雲平臺上的所有使用者完全放開————包括和自己毫無關聯的其他公司,明顯是不合適的,這是把使用者視角和平臺視角混為一談了。不合理的設計應該說是 GitLab 的問題。
從網路資料來看,此問題在兩年前已經有人發現並提出過,參見 Issue: Internal Projects (Public or Private) 。對此 GitLab 官方的反應是,提出了一些改進建議,但並未明確表明態度。仔細研究可發現,專案可見性如果設為 Internal
,後面還是可以在設定中改成僅內部成員可見的,如下:
然而這個選項隱藏比較深,且 GitLab 本身介面也較為複雜,如果不仔細尋找的話,一般恐怕很難知道這個設定。同時,我也查找了一下文件,雖然有所說明,但太過簡略,也沒有針對性的提醒,在一大堆文字中很難注意到。
在此之前,我也在 GitLab 上存放了一些專案,包括 Public/Private 型別,但並未特別注意 Internal
型別。今天我特地用兩個賬號嘗試了一下,發現按照預設設定,在 GitLab 網站上建立的 Internal
專案的確能被其他登入使用者看到,除非手工修改設定之後才會隱藏。
總之,我個人以為 GitLab 作為公有云平臺的確是存在設計問題的。合理的選擇,要麼像 Github 那樣只允許 Public/Private 兩個型別,要麼 Internal
預設只允許組織內部訪問。目前這樣的設計對於多租戶型別的平臺明顯不合理,因而在此事件上,GitLab 應該負有一定的責任。
阿里雲:缺乏安全意識和使用者責任
從目前網友提供的資料來看,阿里雲效平臺是基於 GitLab 社群版,可能自己也未發現這個問題的存在。官方宣告中提到的中英文我反倒認為不太重要,因為合格的開發者應該有基本的英文認知水平。但這並不能撇清阿里自身的責任。GitLab 雖然也有問題,但作為開源程式並無義務為其他公司商用過程中發生的結果承擔責任,這和 Ant Design 開發者有意加入的程式碼不是同一個性質的問題。而阿里既然把別人的開源程式拿來商用,你作為商業平臺的維護者就有義務將產品吃透,並向開發者盡到說明義務。
從結果看,阿里的做法是:
阿里雲方面表示,2018 年 9 月底,阿里雲曾增強對 Internal 許可權的中文註解,並於近日發出全站通知提醒。同時,阿里雲正在逐一通知之前將訪問許可權設為 Internal 的開發者使用者,確保大家正確理解該訪問許可權的含義,並將繼續評估、改進相關產品設計,讓所有開發者有一個更安全、清晰的使用體驗。
也就是說,5個月前他們已經知道了問題,但只是內部修改而未對使用者進行任何提醒,直到這兩天問題爆出才全站通告,那麼早幹什麼去了?為什麼當時沒有意識到這是一個嚴重的安全問題?資訊洩露是最終結果,這背後暴露出的安全意識缺失才是根本。這不能不讓人對阿里雲的可信性產生懷疑。是的,我們都知道阿里有很多牛X的工程師,但我們也明白一個基本的道理,那就是:
安全不僅僅是技術問題。再安全的技術配上沒有安全意識的人,等於沒有安全。
從這個角度講,我認為阿里在該事件中應當承擔主要責任。
開發人員:未仔細閱讀介面說明
前面我批評了 GitLab 和阿里,那麼在阿里雲上託管程式碼的工程師是否就沒有任何責任呢?也不盡然。
我很明白,像 GitLab 這麼複雜的產品,絕大多數開發者不可能通讀所有文件、全方位地瞭解各個方面以後才來部署;像阿里這樣的雲開發商有義務提供一個足夠安全的預設值。但從前面的圖我們也看到了,即便按照預設設定,對於 Internal
的含義也是有說明的:
The project can be accessed by any logged in user.
這不是什麼複雜的語法,我相信有基本英語閱讀能力的開發者應該有能力讀懂這句話的含義,如果只有翻譯成中文介面才能理解的話,那麼這個開發者是否合格確實應該打一個問號。
不過話說回來,網上有一種觀點是開發者閱讀並點選了確認說明他們已經同意分享,再回頭說有安全問題就是賴賬。這個我覺得就有點潑髒水了,沒有哪個腦袋正常的企業開發者會隨便同意把公司內部程式碼拿出去分享給其他你根本不知道的企業的。這些開發者或許缺乏安全意識,或許英文不過關,但你要說他們是自己主動同意分享的,那是沒有可能的事情。
結語
總之,本次事件中幾方其實都有一定責任。事情既已發生,責怪誰已經沒有意義,但希望從這次事件更加明白,安全問題是一個木桶,只要存在一個短板,那麼上下游都難以倖免。我以前也談過一個觀點,就是:
哪怕是私有倉庫,也不應該在裡面儲存任何私密資訊,因為你難以保證分散式環境下每個操作環節都是安全的。
本次事件中的開發者顯然沒有注意這個問題。希望引以為戒吧。