這其實是一個敏感的問題，責任預計難以鑑定，因為阿里雲是伺服器運營商，這些企業在阿里雲購買伺服器，一般都是自行運維，且購買協議也界定了各自的責任。

而對於安全漏洞等問題，一般都會有免責條款，除非有證據證明是因為阿里雲的工作失責或有意而為之導致的原始碼洩露。

顯然是有責任的！

因為是40家企業出現問題，而不是一家兩家，可以說已經是群體性事件了。如果僅是一家出現洩漏，那可以認為出問題的企業對阿里雲程式碼託管許可權設定存在誤解，或者說看不懂。但現在是40家知名企業，還都是知名企業，這其中更是有很多IT公司或者網際網路公司，難道這些企業的技術團隊都是傻子？不知道許可權目錄是公開的？

顯然是阿里雲自身的設定出現了誤導，其設定的許可權“ internal”，這詞大家都知道是內部的意思，這也就讓那些企業以為該項是內部專案，或者企業內部使用者可檢視。但阿里的這個設定其實針對整個阿里雲，只要是阿里雲的使用者均可看到。顯然阿里在未做更明顯的描述時，就是有責任的。

除了許可權專案設定有誤導外，更嚴重的是阿里客服的麻木，原本可以更早的發現這個問題，從而讓各企業及時補救。因為，在2018年時，就已經有阿里雲的使用者發現了這個問題，並且及時反饋給了阿里雲程式碼託管平臺的客服。

但客服並未意識到自己平臺上的問題，或者說對於阿里雲這個平臺過於自信了（被洗腦了？），不認為是阿里雲自身的問題，並未去聯絡通知這些企業，僅是讓反饋者自己去郵件通知出問題的企業。

所以，在這個事件中阿里雲至少得承擔一半的責任，企業技術團隊再承擔剩下的一半責任。原始碼對於企業是相當重要的資料，雖然選擇了人家的雲服務，但並不是萬事大吉，並不是阿里雲市場份額第一就沒有任何問題了。對於資料還是得安全第一，也不要迷信任何一家雲服務商，該檢查的檢查，該謹慎的謹慎，該仔細的還是的仔細。

有責任！

前面有去了解過，我自己雖然不用阿里雲，但是好奇是因為安全問題還是別的問題。結果似乎是阿里雲程式碼倉庫託管的安全策略與制度的問題。

阿里雲的程式碼託管大概分為三種安全級別：私有，內部，公共。客戶公司的程式碼是否能被阿里內部員工檢視和複製到，暫且保留疑問不去討論。可是居然有四十多家公司在不知道自己租用的倉庫的安全級別的情況下被“公開”了，導致這些公司出現損失。就這點，阿里雲恐怕難辭其咎！

從這個事件也可以看出，阿里雲如何對待客戶公司的資料程式碼。尤其是小公司的資料和程式碼，在阿里雲上能有多大的保障，這是一個巨大的疑問！更別說能否服務好開發者了。

要知道，雲服務的服務物件都是高階技術人員，並非像使用Windows的使用者那樣的心態。如果不能拿出“服務”的心態，反而以“老大”的姿態凌駕於這些小公司，那受難的始終是這些使用這種雲服務的中小企業。大企業（科技銀行等）發展到一定階段必然會建立自己的雲中心，資料和原始碼是企業的最重要資產。可憐小公司就自己多善待自己的資料和程式碼吧，多加一份措施。這樣低階的安全管理措施，實在是讓人汗顏。

從受害企業的角度，如果他們聯合起來向阿里討回公道，恐怕也會比較麻煩，官司恐怕難以取勝！因為這種安全機制雖然很坑人，但他們還是有些準備，還是有給客戶留下選項的。他們在銷售自己的租用服務的時候，已經將很多問題的法律框架設定好，開發者選擇的時候就已經處於被動的境地。真正追究的話，應該很難取證，更難定責。加上小公司跟寡頭是在耗不起，恐怕自己默默承受傷害到可能性更大。

可憐的是很多企業如果核心程式碼洩露，恐怕傷害太大，也許倒掉一批也可能。而且這種錯誤難以挽回！

創業不易，別人不在乎你，自己得在乎！認認真真保護好自己的資料和程式碼吧，不要指望任何雲會像你一樣對待自己。

嚴謹的說，這次事件應該具體情況具體分析。

現在的阿里雲已經把所有功能業務全部拆分細分為各種業務版塊。安全方面基本取消了免費版的威脅提醒與統計。也就是說現在只有你購買開通了企業版安全套餐，才能享有安全方面的技術服務。

既然只有40家企業受到了攻擊。為何不是60家企業呢？如果他們有自己的運維工程師又沒有購買阿里雲的安全服務，在伺服器硬體和系統網路沒有問題的情況下，阿里雲是沒有責任的。