如何評價@左耳朵耗子 的《關於阿里雲經典網路的問題》？
這件事最近在圈內炒的挺熱的，是關於雲廠商網路設計的問題，耗子說自己的本意是呼籲大家使用VPC,，目前，各廠商紛紛出面發聲，也有很多三方評論：你可能配置了假的安全策略，阿里雲這鍋背的不冤！
所以這件事對用戶來說有什麼意義？對廠商來說又意味著什麼？有沒有了下文了？左耳朵耗子原文，如下：http://weibo.com/ttarticle/p/show?id=2309404079841686247162#_0
這個，的確是這樣，好幾年前就這樣了，怎麼今天才有人發現……因為我以前在某國企的某公有雲的時候也是這樣的……
實際上在某公有雲的時候這是個很無奈的選擇，當時的技術本來是高級網路，也就是多租戶物理隔離，但是物理隔離的方式是使用VLAN，要知道VLAN的數量只有4094個（0和4095是保留的），真正能保留給用戶的也就一兩千，而公有雲許多用戶只訂一台機器，如果真的每個用戶給一個隔離網路的話VLAN分分鐘就不夠用了，最後業務那邊想出來的辦法就是一個VLAN放50台虛擬機，一個人訂的都在一個VLAN里，但是可能多個用戶會被放到同一個VLAN裡面去。而且不幸的是連安全組隔離都沒有……
（當時也提供VPC，VPC就是單個用戶獨立VLAN）
實際上安全組這個技術並不安全，它僅僅是通過網橋上加iptables過濾的方式進行3層隔離，但實際上各個虛擬機之間二層仍然是互通的，也就是說各個虛擬機之間可以互相響應ARP，那就是說如果一個人故意將別人的IP配在自己的虛擬機上，即使三層流量收不到，也完全有可能干擾別人的虛擬機的使用。再加一些細緻的ARP過濾規則有可能能改善，但只要不是徹底的物理隔離，實際上就是有隱患的。
在現在這個時代，實際上VXLAN隔離技術已經相當成熟了，沒有以前VLAN數量的問題，而且隔離的成本其實很低廉，如果配合SDN技術的話管理上也非常靈活。我覺得各個公有雲商應該考慮將架構完全遷移到SDN上面去，拋棄以前的經典架構。在SDN結構下面實際上VPC還是非VPC成本是完全一致的。
既然說到SDN，最後強推一波開源控制器VLCPhubo1016/vlcp如果你有一個這樣優秀的控制器，一般來說你只要隨便調一調API虛擬網就通了2.經典網路下，用戶只有在設置安全規則開放過多協議和過大CIDR網段如0.0.0.0/0的情況下才能被訪問；
我勒個去……………………
簡單翻譯一下就是，你家的防盜門只能在你家內部可以被徒手拆掉。
抱歉，門在任何情況下都不能被拆掉！這是門的設計問題！
也就是說，不同賬號之間的虛擬機隔離性，應當是強制性規則，而不是默認規則。所謂強制性規則，就是不可覆蓋，不可撤銷，不可修改的規則。======================================================
事實上如果說耗子爆出來的這個事情還能說是阿里雲的管理不善的話，這個問題下面阿里雲員工的爆料則讓人更加的不寒而慄了……
1、原本是隔離的。
2、後來有用戶要求打通，就提單子打通了。3、後來產品就決定把這個功能讓用戶設置了……這已經不是管理不善的問題了，而是這個公司從頭到尾從上到下沒有半點安全意識，安監合規部門純屬擺設，產品部門不學無術…………
講真，託管在這種雲，明天他一個大客戶有個什麼需求借用一下我的資料庫啊，共用一下負載均衡器啊，用他提供的DNS啊諸如此類……
這種雲服務真真是個笑話…… 可控NMB，鬼知道你家產品經理哪天多個什麼想法…………
13年開始用阿里雲的飄過。當時在內部評估的時候還有測試過用戶隔離的問題。
那時候賬戶間有互聯需求需要報工單。默認賬戶間是隔離的。然而在那段時間是有安全組了的。所以上面某個文裡面把鍋推給開放安全組功能實在是。。。
再過一段時間，賬戶間互聯可以在安全組配置的。但是！！重點是安全組中的配置並不是簡單的0.0.0.0/0 而是要配安全組許可權，即兩邊都配安全組id，然後互通，當時還覺得不錯，慢慢在完善功能嘛。挺好。
所以即便是配置0.0.0.0/0 沒有配安全組互聯也還是安全的。當時的文檔是很清楚的。（現在相關文檔網頁還在不在就不知道了）
所以我就很開心的配內網0.0.0.0/0 （沒那麼弱智開公網0.0.0.0/0） 。
至於嘲諷安全意識的，需要內網全封閉的，只開必要埠的。首先租戶隔離是默認規則，就算是傳統idc機房，會讓別人家的網線插到你家的交換機上么？所以內網默認全通雖然有隱患，但是因為都是內部自家的服務，所以大體上是可控的。而且方便很多
首先經典網路的內網ip是不可預知的，沒辦法配置網段規則。
再者在做資源調度的時候，把業務部署到低負載伺服器上是很常見的做法。這時候因為每個ecs上跑的服務都是動態的，所以安全組就會出現無效配置，比如說A伺服器允許80通信，但是實際上A伺服器沒有開80服務。或者每個ecs一個安全組（你TM在逗我），或者在系統的iptables上做，如果在iptables上做，要你安全組做什麼？如果新增個服務還得關聯一下檢查安全組規則（如果沒有要新增），減少個服務還得判斷下是不是安全組內最後一個服務（刪除規則）。業務再複雜一點根本不具備可管理性。多一個流程，就多一分異常風險。
然後什麼時候安全組配置0.0.0.0/0變成跨賬戶全網通？。
而且完全沒有通知，安全組上也沒有功能變更提示！！！
不吐不快，阿里雲現在是拿2C的運營經驗套在2B上，玩試錯，快速迭代，2C出錯了，用戶罵幾句，隔段時間出個酷炫的東西還能哄回來。雲基礎設施這種出錯就可能要老命的東西。你來給我試錯？網遊玩玩付費測試就算了。拿一堆企業的身家性命陪你玩？
再吐槽幾個：
1、阿里雲絕不承認系統有問題
2、如果有問題，請參照第一條
幾年路過阿里雲典型的坑：
A、因為自身原因，需要做割接，將服務遷移到另外一個賬戶內，問了商務，說可以提工單實現ecs的跨賬戶遷移，ok這很方便，不用重新部署調試，那就做。後來發現財務系統全亂了，一堆發票欠票-_-# 導致我們發票開不出來，財務要瘋了。然後開始扯皮。後來跳槽。爛攤子不知道怎麼處理
B、某次slb丟包嚴重，提工單，工程師只會從知識庫複製黏貼（一貫如此，猜測可能我遇到一個AI工程師或者假工程師）。無奈自己抓包上去要求確認slb本身是否有問題。然後就是等了一天。好了，次日阿里雲工程師來電詢問進度（可能是後端團隊的），我說於幾點幾分ok了，對方說漏了「噢。果然是那個異常的SLB集群造成的」。。。我就xxxx了，異常的居然還在用。
C、海外節點使用阿里雲的郵件推送，某天莫名其妙掛了。發現推送服務埠不通，客服回復：「我們現在因為XXX原因，把25改成80了」。我就XXXX了，這種事情也沒通知。。
至於光纖被農民工挖斷的梗就不提了。。
============
早年還完整地評估過博客園的跳坑指南。到現在基本上沒碰到大的技術坑。幾年用下來，阿里雲技術上的進步有目共睹。但是管理實在太混亂。所以從去年開始就逐步往VPC上遷，盡量適配aws。然後坐等aws國內正式開放。用人來打個比方，技術可以學，經驗可以積累，三觀不正就沒救了。
謝邀，這個問題答起來真的很有壓力o(一︿一+)o！
不吹不黑，自掃門前雪~~~
先轉一個我司對此網路設計問題的官方聲明，我司VPC產品的特性及技術實踐解析可戳：關於VPC，你需要知道的一些事（一）——————租戶隔離是UCloud網路設計基本原則的分割線——————- 租戶隔離是雲網路設計的第一原則
日前，雲網路的租戶隔離成為業界關注的焦點。眾所周知，在公有雲環境下，物理網路是共享的。如果不能做到租戶隔離，則用戶的信息就會被其他用戶嗅探到，無法保證業務和數據安全。
作為國內最早使用SDN的雲計算廠商，UCloud從創業伊始就把租戶隔離作為雲網路設計的第一原則。我們在第一個浙江雲機房中就實現了嚴格的租戶隔離。之後北京、廣東、上海、海外等多個版本的VPC實現中，租戶隔離原則都被嚴格遵循。- 租戶隔離的技術方案
UCloud利用SDN技術搭建Overlay網路，來解決多租戶間隔離的問題。每個用戶會被分配一個獨立的VPCID。只有隸屬於同一用戶帶有相同VPCID的數據包才會被允許互相訪問。來自不同用戶的報文則在SDN轉發器處會被強行終結，從而確保用戶數據不會被其它用戶嗅探到。
Overlay網路隔離方案可以從根本上解決多租戶隔離的痛點，比用安全組方案更佳。第一，Overlay方案通過純後台的控制轉發實現，不需要用戶額外的操作。第二，安全組需要用戶具備一定的網路配置能力。一旦配置失誤，依然無法保證租戶隔離。從2012年至今，UCloud用Overlay網路方案去解決租戶隔離，已經經歷了時間的考驗。在此期間，一些用戶出於自身業務安全考慮，部署了安全程序來檢測其雲主機是否有來自其它用戶的內網訪問。結果證明，在其長時間周期性的安全掃描中，都未發現異常訪問。
以北京二10.9.20.0/24這個內網網段為例，掃描後不會得到其他租戶的伺服器信息。結果如下圖：
- 總結
UCloud的所有可用區網路都是按照VPC架構設計的，租戶之間保持嚴格隔離，用戶的定期掃描也證明了我們租戶隔離方案是安全和有效的。
以上。
下文就是都開始推VPC了，也算是推動了業界的發展。對用戶來說，還是要繼續提高自身的姿勢水平，不要貪方便而輕視了安全問題，江來如果伺服器上有偏差，是要負責滴。
阿里的經典網路痼疾已久。而放任一張大二層網路里的不同用戶互通，指望用戶自己去正確配置安全隔離策略，只能說阿里真是心夠大。
解決這一頑疾需要雙管齊下：1. 提供完善的VPC網路 2.提供經典網路向VPC網路遷移的有效路徑。阿里解決了1，但在2上仍然是放羊狀態，所以阿里和用戶間事實上就變成「你玩你的，我玩我的」，該出問題還得出問題。
AWS的classiclink至少給出了2的一個可行方案。經典網路的缺陷仍然存在， 但在新VPC網路和經典網之間建立一條通路，至少讓新建資源可以在VPC里安全的玩耍，然後指望舊資源在一個較長的生命周期中，逐漸湮沒替代掉。騰訊照搬AWS方案。
UCloud提供了另一個新思路，直接把基礎網路原地升級為VPC。只有一個統一的VPC網路，於是整個世界都清凈了。
註：基礎網路並非經典網路，後台同樣是利用SDN技術做租戶隔離的，只是提供比VPC更簡化些的網路配置。這也是基礎網路能原地升級為VPC的重要原因之一。
沒用過阿里雲伺服器,真的是通的嗎沒做隔離?還好我是AWS的忠實粉絲...沒在aws上測試過,應該是隔離了的...
匿名了，前阿里雲員工
最早期是全封的， 但是是通過強化版的iptables控制的，有點low。但安全是可以得到保障的，用戶無法訪問其他賬號下的機器。他說的聚石塔不能用來做例子，因為這實際是划到同一個賬號下的。只是他們會賣給不同的商家，不同商家是可以互相訪問。後來加了一些限制。
但有的客戶有特殊需求。想2個賬號間打通。這一般需要2個賬號同時提工單。然後2個安全組會互相授權就能實現2賬間的打通。這個期間安全也是可控的。另外除工單外，水平高的客戶會發現API實際提供了這個功能。可以自助操作。也是相對可控的
但後期，不知道產品經理出於什麼考慮，將安全組放到了控制台上來。這樣導致一群小白不看說明直接0.0.0.0.然後導致了這個問題。
至於評價，耗子明顯有誤導讀者的嫌疑。至少請在了解詳細情況下做評論
另外他的文章我很喜歡。
本文作者 ：安全_雲舒
來源：雲舒：租戶隔離科普文，阿里雲經典網路問題續
本條信息，雲舒已經在微博刪除，如果雲舒聯繫我們也就刪了。
昨天微博@左耳朵耗子發表了文章關於阿里雲經典網路的問題，引發了熱議
今天微博@安全-雲舒 來給廣大小白普及知識，原文如下：
我現在搞一個小創業公司，沒多少時間可以浪費。然而沒有辦法，很多事情我不出來說明，就會有錯誤在流傳——而且是耗子等在程序員圈子裡面有較大影響力的人。感覺也很有意思，許多技術人員跟街頭巷尾的大爺大媽沒啥區別，交頭接耳議論紛紛。類似的事情，比如美國大選、收容難民等，微博上議論也頗多，讓我思考了好一陣子，就在想這都是為啥啊（當然，我已經想明白了）？
且說正題。
先說結論：阿里雲不同租戶默認是隔離的，而且從2009年到現在一直如此。
我2009年開始負責彈性計算安全，屬於開拓領土，業務逐漸起來後，鎮守一方。當時，在網路層面，我定下了數條基本法則。這些基本法則凌駕於所有的網路訪問規則之上，用戶不可見、不可修改、不可覆蓋，是類似憲法存在的根本大法。其中第一條就是不同租戶處於不同的安全組，默認互相隔離。第二條是每一個VM發出去的報文宣稱的源MAC地址和源IP地址必須與控制平台分發給它的一致。還有幾條我就不一一透露了，不然要泄露機密——這也是我的痛苦所在，寫這篇文章是在刀尖上跳舞，要把事情說清楚但是又不能透露機密，我個人淺見，耗子寫得東西偏多了。
我的安全哲學是在安全這個專業領域用戶是sb（這裡的sb用戶也包括資深的開發人員在內，區別在於小白知道自己不懂，資深的開發人員則以為自己懂），安全得由我這種專業人士保護。所以可以看見，我設置的策略是不人性化的，是死規矩是一刀切。在安全領域，用戶的資產也得由我說了算。
這是我的道。
不知道大家看過魔獸電影沒有？麥迪文設置一個魔法屏障，保護國王萊恩和洛薩撤退，但是洛薩的兒子沒有及時進入屏障而被殺掉——我做的規則就是這樣的。就算你們是一個公司同一個部門不同員工，只要你們買的雲主機是用各自自己的賬戶買的，那麼你們內網就不可互訪，就算是一家人也不行，就算是親兒子和親爹的也不行。
2014年，我從鎮守雲安全任上調離，去搞安全實驗室，到西域開疆闢土，做了IOT安全研究、黑客溯源以及風控安全產品——淘寶的無驗證碼就是我們當時做的。
2015年，我當初給雲計算定下的幾條基本法則做了一些改動。按說，這個改動應該是考慮了用戶的因素，更柔和，更得耗子等技術方面人員喜歡的——那就是不同安全組默認拒絕，但是允許用戶增加白名單，允許一些安全的訪問，麥迪文的那個屏障，可以臨時允許洛薩的兒子進來。這是linux的理念，信任用戶，讓用戶自己決定自己的東西。比如說root去 rm -rf /，系統照樣執行。
現在問題是，有一些用戶為了方便，設置了允許一切IP訪問自己的安全組，也就是有些吃瓜群眾紛紛表示自己懂安全了發現漏洞了的原因。
我做的法則，鐵血專制，剝奪用戶的權利，即使用戶想自殺也自殺不了，絕對安全，但是用戶被我關在了籠子里——這部分，我也經歷過不少投訴。2015年之後的法則，默認安全，但是用戶有自主權，如果要自殺真的能死掉。
隨著時間的推移，雲計算的成熟，我覺得現在的策略是合適的。默認安全，但是高級用戶可以自己掌控自己，不是很美妙么？所有的好的系統，都應該是這樣子的吧。如果想自己有完全的掌控權，但是又絕對安全，抱歉，做不到。
我相信到這裡，事情應該明確了吧？那麼接下來，我要開始批駁耗子了——你說你一個程序員，好好寫程序，發發編碼方面的雞湯文多好，為什麼為什麼為什麼要一次一次的湊到我面前來呢？嗯？
耗子第一篇文章，這一段話「一台個人機器還好設置，如果你是企業用戶，你的機器多了，那麼，安全組這種設置可能就會是一個惡夢。比如你有100台機器，新增的這一台你就需要讓那100台都知道。或是，你這100台中有一台的IP變了，你需要讓另外99台的安全組都知道。…………省略許多文字…………所以，在這樣的經典網路下，對於你的機器的安全組的管理，完全是沒法管的，因為是靜態的，而還是非常複雜的，所以配置錯誤這種事么，基本上是高概率的。」這一段簡直就是放屁。配置安全組，不需要你去了解那麼多細節，你只需要在web界面上把一個vm拉倒一個組裡面去就好了，組增加、減少vm，所有相關組的策略會自動適配。即使你的vm發生遷移了，組策略也會自動跟隨，部署到新的宿主機上面去。這是一個純自動化的過程。
「一般來說，VPC是通過hack底層的虛擬化系統完成的，也就是說，在Hypervisor層虛擬交換機中實現了一個類似路由器的東西——通過一個用戶自定義的虛擬IP和實際IP的關係做packet forwarding或是overlay的機制等。Anyway，實現細節不重要。」這一段，你tm一個知名技術博主，寫技術科普文章，你跟我說「anyway實現細節不重要」？就算不提細節，你跟我說「VPC是通過hack底層的虛擬化系統完成的」，逗我？不懂就去學啊。
我們首先看看為什麼需要VPC。
首先雲計算VM是講究漂移的，有因為故障發生的漂移，也有因為用戶主動發起的跨區域的漂移。漂移過程中要求保證業務盡量不中斷，則需要保證vm的ip地址、mac地址不變，這就意味著需要一個巨大的二層網路，甚至是跨區域的。而二層網路越大，交換設備的cam表壓力也越大，甚至爆掉，arp之類的廣播風暴也越嚴重，所以要把vm層面的一些東西對物理交換機屏蔽掉，分層處理。
其次，VPC給用戶一種很好的體驗，延續傳統網路時代自己組網自己規劃的那種感覺，當然也可以更靈活的設計自己想要的東西，甚至形成service chain。
現在的VPC一般都是基於VXLAN實現的，VLAN的VLAN ID欄位只有12 bit，最多支持4094個VLAN，這對於海量租戶而言肯定是不夠的，VXLAN則擴展成24bit，能夠支持1600萬個VPC區域，基本夠用了。VXLAN是將原始報文封裝成UDP包，可以很方便的跨域三層網路傳輸二層的內容，能夠讓用戶組建跨地區的VPC。並且，VXLAN將內部VM的MAC地址等信息屏蔽掉了，由VTEP處理，讓交換機專註物理機方面的事情，減輕壓力。
對我而言，最喜歡的是VTEP可以形成service chain。其實現在VXLAN和SDN已經不太能去分得開了，至少我不太能分得開，也許可以基於openflow協議來控制VTEP的行為吧。
在阿里期間，我一直對現有割裂的安全廠商和產品耿耿於懷，大約是2011年我在owasp講過我的安全產品虛擬化思路，將不同廠商的硬體盒子抽象成統一的VM，不同的功能就是不同的image，然後基於SDN或者VXLAN的能力，軟體的方式定義網路結構，將平面的vm變成具有立體結構。這樣，用戶就可以繪製自己的網路拓撲圖，在對應的地方，選擇對應的產品，可能是安全，也可能是負載均衡，然後再選擇供應商，點生成，整個網路就生成好了。這也許就是雲計算安全最後的終局，但是不知道要多少年才能發展得到。
我本來想，國內就由我自己來完成這個壯舉，可惜未能實現，我已離職。人生如夢啊。
不提這些，來說耗子的第二篇文章。
「2013年，我在阿里商家業務部做聚石塔，聚石塔的底層是阿里雲。當時，聚石塔的安全問題很嚴重，有很多商家和買家的業務數據外泄，所以，成立了一個專門負責安全的小組。阿里安全部門也專門派人來強力支持。
當時有一個很大的安全問題是——阿里雲的內網多個租戶居然是通的。」
不知道耗子知道不知道，因為一些我不方便說的原因，聚石塔是由淘寶維護負責的電商雲，其實是屬於同一個租戶的！同一個租戶，當然是互通的啊。我不知道耗子是知道那個原因不說，因為知道我不可能說，還是真不知道——按說你當時也P9，應該知道吧。不說這個，但是至少，聚石塔所有的vm是屬於同一個租戶的，你也不知道么？那你負責聚石塔是怎麼負責的？也是「anyway，細節不重要」？
更多的東西，我就不說了，所有這些，對我現在而言，都沒有意義。如果不離職，我已經P10了，也許不久就要做到P11也就是所謂VP了。
但是那又如何？我現在是默安科技的聯合創始人兼CTO，我他媽已經P14了啊。
因為這麼些鳥事情，浪費了朕一上午的時間。這幾年我基本已經不跟人交流雲計算安全方面的東西了，因為我不知道找誰跟我交流。懂雲的不懂安全，懂安全的不懂雲，都懂的嘛，除了我以及了了數人之外，也就是一些搞跨界的了。
大道難借他人之手，唯有自成，且吃個黃燜雞壓壓驚。
相關閱讀：
@左耳朵耗子：關於阿里雲經典網路的問題
阿里雲資深用戶。
當時也在用安全組快半年多了吧。
感覺做雲產品家也不容易。市場上的運維小白，研發小白太多了。還容易不懂裝懂。
只要設定好條件，是沒有問題的。
IPTABLES原理又怎麼樣？也用了這麼多年了。
用戶自己弄的，就是自己作死啊。你自己機房裡這麼弄。也是一樣的後果。
還有，又看到小白裝逼了。你伺服器自己的防火牆也不開？這個又是什麼情況？？？
還有，被家長管了太多了吧。什麼都要雲廠家幫你們弄好。許可權給你們了。自己調規則去啊。醉了。
牛點的自己調整VPC網路啊。ACL規則我都寫累了。15年開始用阿里雲，那時就發現，不同賬號的實例是不互通的，所以阿里雲默認的安全策略沒什麼問題。後來為了訪問另外一套系統的介面，走內網會快很多，就研究了一下，發現是用iptables實現的，自己改了下配置，就打通了，覺得這個設計更沒什麼問題。管理方面，首先全部內網段封閉，再開放自己需要的ip和埠，很簡單。左耳耗子說的，幾百台伺服器容易出錯，excuse me？難道他都是手工操作？寫個自動化維護的腳本，管理一台和管理一萬台，並沒有太大區別。只要腳本邏輯正確，也不存在容易出錯的問題。業界當然有更好的VXLan之類的方案，但是對一個需求來說，只要夠用就行，不是說什麼高端就要上什麼。推薦看看雲舒那篇反駁的博文，雖然口氣上有點反諷的裝，但是描述的十分準確，而左耳耗子的質疑，現象可能確實存在，但是板子打到阿里雲身上是不正確的，完全是用戶自己的問題。當年xp滿身漏洞，都是質疑用戶不打官方補丁，不裝殺毒，不開防火牆，不改默認管理密碼，沒有安全意識，為什麼就沒人質疑微軟？其實微軟更值得黑，因為它是默認不安全，需要用戶自己維護，而阿里雲反而是默認安全，用戶自己啟用了不安全的方式。至於對個人的評價，我覺得左耳耗子的文章的確寫的很好，很佩服也很喜愛看，但另一方面，覺得他的確沒有實際的項目符合他的層級。不是說他沒做事，而是說他的產出沒有達到p9那麼高的層級。說到層級問題，要再次為阮一峰鳴不平，他的能力和寫文章的水平比左耳耗子還高的多，可能因為老實本分的原因，去阿里的層級只有p6。大概說明在阿里hr隻手遮天的評價體系里，表現力要比技術能力重要的多。
匿名了，非阿里員工，但是也不能得罪左耳朵耗子這種大V，呵呵。
怎麼沒人說，VPC本來就是他在阿里雲應該負責的項目，沒搞成，導致項目delay了！
別說左耳朵耗子好意，他就是不懷好意，阿里雲出點問題，他是追著打，你看AWS出問題，他微博提都不提，博客里還各種跨亞馬遜各種服務可用性8個9之類的，然後不區分業務，談可用性大小本來就是耍流氓。
另外，左耳朵耗子個人技術實力是被阿里雲各種大牛壓著打的。
新人，先說下我的看法。 原文作者有明顯的上綱上線、誤導傾向。 這個問題，借用樓上"門"的比喻，你家裝了個防盜門，結果為了朋友方便，把門鑰匙藏在了門口的鞋墊下（影視劇里常用的橋段），結果有個慣偷，輕車熟路的就」掃描「到了你的鑰匙（都不用撬門了）。
1. 「門在任何情況下都不能被拆掉」
這個結論讓廣大開鎖師傅情何以堪？ 即便是做門的廠商（包括保險箱）設計的時候也會留有退路。
2. 易用性與安全性
這個問題的核心其實是易用性和安全性的衝突。目前由於國內的網路、管控等各方面因素導致傳統企業用戶對上雲還持謹慎態度。所以國內主要雲廠商還存在著大量的個人用戶（自媒體、博客）或初創公司（以研發人員為主）。絕對安全對於這部分用戶來說可能就意味著「超級難用」，試問這類用戶有多少能 hold VPC ？
阿里云為了滿足在 VPC 還沒有出現或普及之前的用戶不同賬戶的互通而實現的這個需求，我覺得也無可厚非。至少我在使用這個功能，打通了我早期幾個免費馬甲申請的免費主機時，我覺得這個功能很棒而且很人性化。
企業用戶有更高的安全性需求，可以通過更複雜的安全規則或者 VPC 來解決。
3. 更好的做法
我覺得，這個問題沒必要上綱上線，上升到什麼行業安全高度。阿里雲目前默認就是租戶隔離的。對於這個功能，建議在操作界面上給出相應的風險提示和最佳實踐說明就行了。
經典網路還是VPC，開發者作何選擇？
近兩天，關於公有雲經典網路與私有網路（VPC）的討論引發技術圈極大關注，事件起因於有開發者將資料庫限制在內網訪問，但由於安全組設置的原因，阿里雲鄰居用戶被黑後，牽連到了自己的業務。為此，開發者@左耳朵耗子發表了《科普一下公有雲網路》，指出阿里雲默認的內網是經典網路，管理複雜，配置錯誤是高概率事件，呼籲大家採用VPC方案(私有網路 VPC - 騰訊雲)，防止重現上述事故。
對比起「談安全色變」，圈內理性探討總歸是好事。這次「經典網路安全爭議」，讓VPC方案迅速為廣大開發者所了解，相信將推動公有雲服務商加速相關網路技術的布局，那麼VPC是什麼呢？接下來是否有必要從經典網路遷移到VPC上？在這裡給大家做個科普：
1、VPC是什麼？
VPC（Virtual Private Cloud）是公有雲上自定義的邏輯隔離網路空間，與用戶在數據中心運行的傳統網路相似，託管在VPC內的是用戶在私有雲上的服務資源，如雲主機、負載均衡、雲資料庫等。用戶可以自定義網段劃分、IP地址和路由策略等，並通過安全組和網路ACL等實現多層安全防護。同時也可以通過VPN或專線連通VPC與用戶的數據中心，靈活部署混合雲。
2、VPC與經典網路的區別
經典網路：公有雲上所有用戶共享公共網路資源池，用戶之間未做邏輯隔離。用戶的內網IP由系統統一分配，相同的內網IP無法分配給不同用戶。
VPC：是在公有雲上為用戶建立一塊邏輯隔離的虛擬網路空間。在VPC內，用戶可以自由定義網段劃分、IP地址和路由策略，安全可提供網路ACL及安全組的訪問控制，因此，VPC有更高的靈活性和安全性。
經典網路和VPC的架構對比圖：
對比可以看到，VPC優勢明顯，通過VPC，用戶可以自由定義網段劃分、IP地址和路由策略；安全方面，VPC可提供網路ACL及安全組的訪問控制，VPC靈活性和安全性更高。可適用於對安全隔離性要求較高的業務、託管多層web應用、彈性混合雲部署等使用場景中，符合金融、政企等行業的強監管、數據安全要求。
3、各家VPC對比
目前，VPC也是各大雲廠商正在力推的網路方案。AWS、阿里雲、騰訊雲等官網對VPC都有詳細的介紹：
總的來說，AWS和騰訊雲的評分最高，能支持彈性網卡、VPN服務、網路ACL等多項服務，很大程度上降低了用戶使用VPC時的技術門檻，讓複雜的VPC配置變得更加簡便、安全、靈活。
同時，從騰訊雲的官網說明看，騰訊雲還支持外網IP直通、子網廣播和組播、專線NAT功能，這些是目前公有雲市場的獨家服務。
4、經典網路用戶如何平滑遷移
以上較多篇幅介紹了VPC的優勢，那麼對於已經在經典網路內有較多雲主機的客戶如何實現經典網路和VPC之間的平滑遷移呢？
AWS（classiclink）和騰訊雲（基礎網路互通）都提供了平滑過渡方案，可以將經典網路內的雲伺服器關聯至指定VPC，使經典網路中的雲伺服器可以與VPC內的雲伺服器、資料庫等雲服務通信。
本次網路事件的爆發或將可能成為網路界的一個轉折點。無論從業內人士的，還是從廠商的產品布局中，可以看到，經典網路引爭議後，VPC被業界推崇，或成為網路市場的主流應用。
我只想知道，AWS 有這樣的問題嗎？
正好最近在做這方面的東西。先說結論，雲計算沒有想像中那麼安全，操作系統往上的東西還得靠自己。左耳朵耗子說的問題應該是全部存在的，做過虛擬化的應該都知道這個問題。廠商迴避估計效果不會很好。另外，我想說，一個把自己的核心業務數據放在雲端的企業，數據丟了如果不反省自己的安全防護問題。那麼，自己建個機房自己搭業務，估計一樣丟。畢竟，不能指望雲計算廠商賣你一個不是很貴的虛擬機，還要專門為你的服務設計安全策略。
公共雲，應該能確保 用戶即使是傻瓜也無法犯 不必要 的錯誤
如果條件可能，是應該為 每個用戶設一台獨立的路由器，無論用戶自己的伺服器怎麼設，外面（其他用戶 及 任意互聯網）的機器均無法訪問用戶內部的機器除非用戶書面格式報表提出正式申請，才按報表開通訪問路徑（任意互聯網 按對外ip訪問；其他用戶按內網訪問）即雲服務商維護路由器，用戶無法操作此路由器路由器配錯了，服務商的鍋；需求單填錯了，才是用戶的鍋；用戶自己再亂配伺服器，都不會導致機器能被同服務商不同用戶的機器訪問了如果全部用硬體路由器太貴太麻煩，那就軟體實現，但要求是一樣的不必要 的錯誤包括：root rm -fr /
如果清空機器必須由服務商進行，則用戶的 root rm -fr / 都自動被識別且禁止下面舉一個需求設想的例子注意下面的 公司A的a31和公司B的b14，它們需要能特殊開通 跨賬號直接按內部方式進行單向訪問未經特殊開通，都無法跨公司按內部方式訪問公共雲的需求設想
├──公司A
│ ├──伺服器組a1
│ │ ├──伺服器a11：資料庫
│ │ │ ├──對外ip：無
│ │ │ ├──內部ip：ip11
│ │ │ ├──對外需求
│ │ │ │ ├──它不訪問外部
│ │ │ │ └──外部不能訪問它
│ │ │ └──內部需求
│ │ │ ├──它不訪問內部
│ │ │ └──內部只能訪問它的 管理埠、資料庫埠
│ │ ├──伺服器a12：redis
│ │ │ ├──對外ip：無
│ │ │ ├──內部ip：ip12
│ │ │ ├──對外需求
│ │ │ │ ├──它不訪問外部
│ │ │ │ └──外部不能訪問
│ │ │ └──內部需求
│ │ │ ├──它不訪問內部
│ │ │ └──內部只能訪問它的 管理埠、redis埠
│ │ ├──伺服器a13：nginx
│ │ │ ├──對外ip：202.96.123.100
│ │ │ ├──內部ip：ip13
│ │ │ ├──對外需求
│ │ │ │ ├──它不訪問外部
│ │ │ │ └──外部只能訪問 它的80、443埠
│ │ │ └──內部需求
│ │ │ ├──它訪問內部 ip14的9000埠
│ │ │ └──內部只能訪問它的 管理埠
│ │ └──伺服器a14：php
│ │ ├──對外ip：無
│ │ ├──內部ip：ip14
│ │ ├──對外需求
│ │ │ ├──它可訪問外部
│ │ │ └──外部不能訪問它
│ │ └──內部需求
│ │ ├──它訪問內部 ip11的資料庫埠，ip21的資料庫埠，ip31的資料庫埠，ip12的redis埠
│ │ └──內部只能訪問它的 管理埠、9000埠
│ ├──伺服器組a2
│ │ └──伺服器a21：資料庫
│ │ ├──對外ip：無
│ │ ├──內部ip：ip21
│ │ ├──對外需求
│ │ │ ├──它不訪問外部
│ │ │ └──外部不能訪問它
│ │ └──內部需求
│ │ ├──它不訪問內部
│ │ └──內部只能訪問它的 管理埠、資料庫埠
│ └──伺服器組a3
│ └──伺服器a31：資料庫
│ ├──對外ip：無
│ ├──內部ip：ip31
│ ├──對外需求
│ │ ├──它不訪問外部
│ │ └──外部不能訪問它，但 公司B的ip14可以訪問它的資料庫埠
│ └──內部需求
│ ├──它不訪問內部
│ └──內部只能訪問它的 管理埠、資料庫埠
├──公司B
│ └──伺服器組b1
│ ├──伺服器b11：資料庫
│ │ ├──對外ip：無
│ │ ├──內部ip：ip11
│ │ ├──對外需求
│ │ │ ├──它不訪問外部
│ │ │ └──外部不能訪問它
│ │ └──內部需求
│ │ ├──它不訪問內部
│ │ └──內部只能訪問它的 管理埠、資料庫埠
│ ├──伺服器b12：redis
│ │ ├──對外ip：無
│ │ ├──內部ip：ip12
│ │ ├──對外需求
│ │ │ ├──它不訪問外部
│ │ │ └──外部不能訪問
│ │ └──內部需求
│ │ ├──它不訪問內部
│ │ └──內部只能訪問它的 管理埠、redis埠
│ ├──伺服器b13：nginx
│ │ ├──對外ip：202.96.123.200
│ │ ├──內部ip：ip13
│ │ ├──對外需求
│ │ │ ├──它不訪問外部
│ │ │ └──外部只能訪問 它的80、443埠
│ │ └──內部需求
│ │ ├──它訪問內部 ip14的9000埠
│ │ └──內部只能訪問它的 管理埠
│ └──伺服器b14：php
│ ├──對外ip：無
│ ├──內部ip：ip14
│ ├──對外需求
│ │ ├──它可訪問外部，以及按內部訪問模式 訪問 公司A的ip31的資料庫埠
│ │ └──外部不能訪問它
│ └──內部需求
│ ├──它訪問內部 ip11的資料庫埠，ip12的redis埠
│ └──內部只能訪問它的 管理埠、9000埠
└──公司C
雖然我開車技術不好，但是我能把你們帶進坑裡
怪不得前幾天老大讓我們把手下阿里雲的機器全部手動上防火牆....
還好手上的機器多是騰訊雲的...
http://mp.weixin.qq.com/s/TQiY3lVoAH4DSjKTQD6yNA對比看一下，感覺耗子不知是有意還是無意在誤導讀者。
這個有什麼好評論的，當時不應該讓耗子來搞VPC項目吧。屬於他的上層領導失職，本來術業有專攻，你看ucloud請了俞圓圓來搞虛擬網和sdn不就做的風生水起。當時奇怪阿里云為什麼不挖aws或azure北美的專門搞虛擬網的高級工程師或負責人來做。
推薦閱讀：
※分散式的一致性hash問題？
※國內優秀的響應式WEB網站有哪些？
※怎麼用dht網路標誌獲得bt種子或磁力鏈接？
※Clojure 適合個人用來做 Web 快速開發么？
※如果打算走網路這條路，考CCNA和CCNP是不是很有必要？