微盟「刪庫」程式設計師被判6年，無力償還網貸，酒後感覺生活不如意

還記得那個「刪庫跑路」，憑「一己之力」讓微盟一夜之間市值蒸發超 10 億、300 萬商鋪慘遭癱瘓的程式設計師嗎？

　　不僅如此，伺服器故障時間長達 8 天之久，最終還賠付了商家 1.5 個億。

　　現在，對這位程式設計師、主人公賀某的判決，有了最近的進展：

　　從 2 月 24 日被被羈押，到 8 月 26 日作出6 年有期徒刑的判決。

　　自供酒後因生活不如意、無力償還網貸等個人原因的賀某，為自己的行為付出了代價。

　　刪庫跑路原因：無力償還網貸，酒後生活不如意

　　賀某的「刪庫」行為，判 6 年的依據是什麼呢？

　　8 月 26 日上海市寶山區人民法院刑事判決書（一審）主要內容是這樣說的：

上海市寶山區人民法院認為，賀某違反國家規定，刪除計算機信息系統中存儲的數據，造成特別嚴重的後果，其行為已構成破壞計算機信息系統罪，應當依法追究刑事責任。公訴機關指控的犯罪事實清楚，證據確實充分，罪名成立。

賀某如實供述自己的罪行，認罪認罰，可依法從輕處罰。辯護人的相關意見本院予以採納。依照《中華人民共和國刑法》第二百八十六條第二款、第六十七條第三款、第六十四條、《中華人民共和國刑事訴訟法》第十五條之規定，判決如下：

一、賀某犯破壞計算機信息系統罪，判處有期徒刑六年。（ 刑期從判決執行之日起計算。判決執行以前先行羈押的，羈押一日折抵刑期一日，即自 2020 年 2 月 24 日起至 2026 年 2 月 23 日止。）

二、作案工具筆記本電腦一臺依法沒收。

　　而根據 《刑法》第二百八十六條：

　　違反國家規定，對計算機信息系統功能進行刪除、修改、增加、幹擾，造成計算機信息系統不能正常運行，後果嚴重的，處五年以下有期徒刑或者拘役；後果特別嚴重的，處五年以上有期徒刑。

　　違反國家規定，對計算機信息系統中存儲、處理或者傳輸的數據和應用程式進行刪除、修改、增加的操作，後果嚴重的，依照前款的規定處罰

　　針對賀某的情況，法院認為是「後果特別嚴重」。

　　在通報中，也披露了原因：

2020 年 2 月 23 日 18 時 56 分許，賀某酒後因生活不如意、無力償還網貸等個人原因，在其暫住地上海市寶山區逸仙路 XXX 弄 XXX 號 XXX 室，通過電腦連接公司虛擬專用網絡、登錄公司伺服器後執行刪除任務，將微盟伺服器內數據全部刪除，導致微盟自2020 年 2 月 23 日 19 時起癱瘓，300 餘萬用戶（其中付費用戶 7 萬餘戶）無法正常使用該公司 SaaS 產品，經搶修於 3 月 3 日 9 時恢復運營（故障時間 8 天 14 個小時）。

截至 2020 年 4 月 30 日，造成微盟公司支付恢復數據服務費、商戶賠付費及員工加班報酬等經濟損失共計人民幣 2260 餘萬元。

　　根據判決書，賀某用 4 分鐘時間完成了刪除微盟所有數據的操作，原因是「生活不如意、無力償還網貸等」。

　　給公司造成了 2260 萬元損失，影響 300 萬用戶，這樣的程度在國內實屬罕見，法院認為稱「後果十分嚴重」是適用的，也據此給出了超過 5 年的量刑。

　　但這 2000 多萬元直接損失能夠全面描述這次「刪庫事件」的全部後果嗎？

　　從微盟善後來看，肯定不是。

　　事件回顧：微盟直接虧損 0.87 億元

　　事情從 2 月 23 日晚說起。

　　當時微盟公司的 SaaS 業務突然崩潰，而基於微盟的商家小程序都處於宕機狀態，300 萬家商戶生意基本停擺。

　　第一時間，微盟收到系統監控警報，發現是 SaaS 業務服務出現故障，隨後立即召集相關技術人員進行排查，發現微盟伺服器遭到了嚴重破壞。

　　隨後，微盟和合作方騰訊方面多次放出通知延後修復時間，直至 3 月 3 日早晨才完全恢復運營。

　　事發後僅一天，微盟集團的市值就蒸發超過 10 億港元。

　　事後，微盟又拿出了1. 5 億元的補償方案，賠付在事件中受影響的微盟商家。

　　而且，微盟「倒下」，競爭對手紛紛補位，試圖爭奪突然出現的空檔：

　　從直接損失、市值、善後、用戶流失這幾個方面來看，微盟的確受損嚴重，8 月份公布的上半年財報，也反映出了這一情況。

　　根據微盟財報，2020 年上半年，淨虧損為 5.46 億元，其中包含了香港財務報告準則下可換股債券確認的金融負債公平值變動引起的人民幣 4.96 億元虧損及SaaS 破壞事件的賠付計劃帶來的預計賠付支出的損益影響人民幣0. 87億元。

　　那麼，微盟對數據安全完全沒有防備嗎？為什麼員工在家用筆記本就刪除了所有數據？

　　數據未上雲

　　3 月 2 日，微盟在其官方網站上發布了自願公告《SaaS 業務生產環境和數據恢復》，描述此次事故及修復過程，以及賠付方案和數據安全保障計劃。

　　其中，關於數據安全部分，微盟的反思是：

本次事故雖由員工的不當行為引起，但也暴露出本公司在數據安全管理方面的不足之處。

為此，本公司已邀請外部數據安全專家協助本公司制定和評估數據安全保障計劃，主要覆蓋生產環境和數據權限的分級管理和執行、將數據移轉到騰訊雲資料庫、加強意外事件快速應對能力以及運維人員的法律和職業道德學習等方面。本公司正在逐步落實上述數據安全保障措施，以避免此類事故的再次發生。

　　從之前騰訊雲對外的回應中，可以大概看到微盟被刪的數據不在騰訊雲上，再結合目前數據恢復的速度來看，幾乎可以判定很大概率微盟沒有採用「全上雲」的架構，或者是只有部分數據在雲端。

　　根據量子位之前關於微盟事件相關數據安全問題的介紹，這種數據完全「不上雲」，或只把雲作為虛擬機的「假上雲」方案，對於數據的風險相比「全上雲」會更大。

　　運維人員在「不上雲」和「假上雲」的情況下更容易有機會去執行類似「rm -rf /*」和「fdisk」類型的極端操作。

　　而「全上雲」，雲服務提供商大概率會提供額外備份和更嚴格的身份認證。

　　但同時，也有讀者留言反饋道：

作為雲管理者，全上雲的數據還是能刪光的。任何雲都有初始化手段，全上雲就是把安全交給別人。

　　對於「全上雲」 or 「Not 全上雲」，你怎麼看？

最後，小編想說：我是一名python開發工程師，整理了一套最新的python系統學習教程，想要這些資料的可以關注私信小編「01」即可（免費分享哦）希望能對你有所幫助。