關于零信任究竟是什么，網上的資料已經很多了，在這里我就不再照搬照抄了。不過我們也注意到，“零信任”這個詞除了是一個技術詞匯之外也是一個市場詞匯，被各個安全公司從自己的視角各自解讀，在這個過程中不可避免地會夾帶一些私貨，從而造成一些混亂和誤解，所以我們今天來談談零信任不是什么，也許對于幫助大家更好地理解零信任會起到一些積極的作用。
首先，零信任是一個方法論，它定義了一種安全管理的新的視角。它不是一個產品或者說一個技術。也就是說您買不到一個叫零信任的產品，您只能買到幫您實現零信任的某種要求的產品。
其次，零信任是一個過程，或者說是一個方向。它不是一個靜態的標準，或者說狀態。也就是說，你不能說我們今天來做一個零信任的項目，做過之后我們就擁有了零信任，沒有這種事情。你只能說通過一期項目，我們在一定的范圍內，在一定的水平上，實現了零信任的某些能力。比如說，我們可以說我們能夠在網絡層面實現數據中心流量的全面可視和可控，但是網絡層之上還有應用層，你看到了網絡層面的主體和通信關系，但是你還沒有理解應用層面的服務主體和應用訪問關系。而在應用層之上還有更深層次的業務層面的分析與控制問題。所以說，零信任的建設應該是一個持續的，逐漸深入，逐漸優化的過程，也是一個在安全與業務之間的一個平衡的過程。
最后，零信任是個廣泛適用的方法論，也就是說它可以應用于整個計算架構的各個方面，在每一個細分的環境，每一個具體維度上都可以利用零信任的方式來做管理，而不是說零信任只能像谷歌那樣將之應用于辦公網，面向員工的身份進行管理。我們可以看一下Forrester的這張圖：
大家可以看到，零信任可以作用于人，設備，網絡，工作負載等所有有數據流動的主體上。事實上，相較于辦公網而言，數據中心是更容易實現零信任的場景，也是有著更多核心業務和關鍵數據的地方，因此可以成為我們開展零信任建設的起點。
微隔離在零信任網絡中的地位和價值
現在我們說下微隔離技術。前面我們談到，相較于辦公網而言，數據中心網絡更適合成為零信任建設的起點。那么對于數據中心網絡而言，具體的產品技術是什么呢？這個在業界是有共識的，有兩個技術是當下能夠落地的，一個是SDP，一個就是微隔離。事實上微隔離技術是最早的一種對零信任這個概念的具體技術實現。我們看下Forrester2019年Q4的報告：
報告中的這段開場白大概是這么個意思：零信任是個挺費勁的事情，甲方自己上是沒戲的，你得找到能幫你干這個事的供應商。那如何來評估每天圍在你門口的那么多乙方呢？有這么幾個標準：首先就是要態度端正，你必須讓他指天發誓，他們相信零信任這件事情就是人民群眾大救星，只有零信任才能拯救網絡安全。而且他們必須得有真本事，他們的產品確實能在零信任架構中有一個獨特的價值，而不是來碰瓷的（deliverrealZeroTrustcapabilities），看來掛羊頭賣狗肉這事兒也不光是咱國內的特色。除了態度端正之外，第一條具體的安全能力要求就是支持微隔離!下面的那些個要求就不在本文討論了，就是讓您感覺一下微隔離在零信任技術體系中的地位是什么。
我們再看下同樣在這篇報告里的這個圖：
這是Forrester觀察到的市場上的有效供應商。越靠右邊的戰略越先進，越靠上邊的技術越好。從這張圖可以明顯的看到，就當下而言，技術最好的是illumio，那么illumio是做啥的呢？業內人士都知道，他就是做微隔離的，全球十三只安全獨角獸之一，微隔離市場的扛把子。
通過對Forrester報告的分析，大家不難理解微隔離之于零信任的價值。那么從理論上分析，為啥微隔離這么重要呢。因為微隔離要實現的核心能力就是兩條，數據中心內工作負載之間的流量可視以及訪問控制。大家可以回頭再看看前面那張圖，零信任能力究竟是個啥能力？本質上就是倆能力，一個是看得盡量多，一個是管得盡量細。而恰恰這就是微隔離主要在做的事情。領先的微隔離產品，能夠做在十萬點級別的數據中心內做到容器間流量的識別與訪問控制，甚至能做到基于進程的訪問控制，這個細粒度正是零信任所要求的。
微隔離技術的當下和遠方
作為微隔離技術在國內最為積極的倡導者，也是唯一一家只做微隔離這一件事的廠商，薔薇靈動做了很多的微隔離項目，服務的客戶包括三桶油，五大行，三大運營商，平安、京東等等云計算領域最領先的行業領導者。在這個過程中，一方面我們見證了微隔離技術是如何幫助用戶將一個個高度復雜的虛擬化網絡看清楚、管明白的。另一個方面，我們也深刻地認識到，微隔離這項技術所面臨的挑戰仍然非常的巨大。具體而言，我可以用“多快好省”這四個字來做個概括：
1.多:跟得上用戶計算密度膨脹的腳步
計算密度膨脹這件事情，給我們留下的印象非常深刻。我們的一個客戶剛開始試用我們的產品的時候，他們的體量在四五千點這樣一個級別，而今年他們的計劃是，擴容到2萬點。另一個客戶更夸張，在購買我們產品的時候，他們的規模大概是十萬點，但是今年我們在產品上線的時候，他們告訴我們說，他們剛剛做了戰略決策，全面容器化，目前毛估體量在100萬點左右！
而微隔離這件事情，要回答的是點和點之間的關系問題。從算法復雜度的角度講，他與所管理的點數之間是個n的平方的關系。再考慮到，點和點之間的通信是一個時刻都在發生的事情，而微隔離需要記錄并分析每一次訪問，然后再隨著時間的累積，這個數量級就接近了n的3次方了。這意味著什么呢，如果管理規模擴大一倍，那么對算力的要求會擴大8倍。所以對于大規模網絡的支撐是微隔離最重要的一個技術難點。大家這里一定要注意一個區別，不是說你能夠部署安裝多少點，而是說你能不能把這些點之間的關系完整、準確、實時地分析出來。目前我們可以實現用三臺云主機作為算力，來支撐萬點級別的場景，但是根據Illumio的公開資料，他們要支持一萬五千點的時候，就需要6臺專用的高主頻物理服務器了，大家可以想象百尺竿頭更進一步會有多難。而這個能力，相較于我們用戶計算體量的膨脹速度而言還是不夠。
所以我這里可以給大家一個判斷標準，在過去評估防火墻的最主要指標是吞吐量，包括延遲，每秒新建，并發等等指標。而微隔離技術的核心指標就在于它能夠管理的工作負載的規模。
2.快：跟得上微服務架構飄渺的跑位
正如您看到的，容器在計算密度膨脹這個過程中扮演了非常重要的角色。一個方面，K8S的成熟和便捷，以及對于DEVOPS理念的良好支撐，使得越來越的客戶在快速的擁抱容器。但是，從另一個方面，這也對各種運維技術提出了很嚴峻的挑戰。就微隔離技術而言，一個非常大的挑戰是策略計算速度問題。
微隔離是一種典型的軟件定義安全結構。它的策略是由一個統一的計算平臺來計算的，而且需要根據虛擬化環境的變化，做實時的自適應策略重算。問題就在這個地方，對于私有云環境而言，一個虛機的生命周期很長，從幾周到幾個月乃至幾年都有可能，這個時候對于策略的計算速度其實沒有特別高的要求。但是在K8S的環境下，情況發生了巨大的變化。由于容器的創建和銷毀非常方便，使得容器的生命周期往往非常短，甚至只有幾分鐘。這就對策略計算的速度提出了很嚴格的要求，再加上往往容器環境的體量都非常巨大，就讓這個策略計算的難度更高了。這種酸爽的感覺怎么形容呢，大概就是這么個意思:
給你一麻袋沙子，然后問你每一粒沙子叫啥名？他們之間什么關系？
矮油，沒想到你居然知道。
好吧，現在把袋子在地上摔個五六遍。
然后問你，他們都叫啥名？他們之間什么關系？
你有5秒鐘的時間，5，4，3…
3.好：企業級產品必須具備企業級特性
企業級產品的功能特性，符合冰山模型。我們能夠看得見摸得著的功能大概只占整個產品功能的10%，90%的功能都是水面之下的非功能特性，或者我們稱之為企業級特性。
談到這，我們扯個閑篇，說說80/20這個事。這確實是個神奇的法則，在各個領域似乎都有用。從產品研發的角度看，我們大概只需要用別人20%的工作量，就能實現人家產品80%的功能，事實上這是我們國內過去很長時間大家指導產品研發的原則，先解決有無問題嘛，最重要的就是快，要啥自行車呀，又不是不能過…。但是企業級產品的本質要求恰恰相反，我們必須要投入絕大部分的工作量去解決那剩下的20%，因為就是這20%才是決定一個產品能否真正被部署在核心業務系統的關鍵。
更嚴峻的挑戰是，很多時候你并不知道你缺失的企業級特性是什么，直到你在客戶現場遇到他！比如說我們在實驗室里能夠模擬出幾百點的真實環境，也可以通過流量發生器構造出萬點級別的虛假環境。但是無論如何你造不出一個萬點級別的真實生產環境，就好像你沒辦法在你的實驗室里真實再現出淘寶的全部交易一樣，哪怕只是一秒鐘的交易。所以有很多在大壓力下才會出現的問題，就會被隱藏起來，一直到你的產品在真實的場景上線。這就好像你的頭上一直懸著一把達摩克里斯之劍，讓人始終有一種如坐針氈如履薄冰的感覺。
所以呢，一個方面我們始終投入最大的精力在這個方面，盡全力去提升我們的企業級特性。另一個方面呢，大家在評估微隔離產品的時候，一定要關注他們是否有大規模場景的交付經驗和大規模的現網穩定運轉的案例，要評估他們是否真的能夠支撐你的云計算發展戰略。
4.省：在產品發展的過程中保持克制
最后這一條，既是我們要分享給大家的一個產品設計的指導原則，也算是對我們自己的一個警醒吧。
首先我們要提出一個方法論，那就是“產品研發的不可能三角“，這個方法論是應該我們獨家提出的（當然，本文里的方法論基本都是我們獨家提出的）。什么是不可能三角呢：就是在產品功能的豐富性，產品功能的專業性，以及計算開銷這三者之間，你最多只能選擇兩者。
比如說，你可以選擇產品功能很豐富，計算開銷也比較低，那么你的每一項功能的實現水平勢必比較初級。比如面向中小客戶市場的產品，往往選擇這種產品戰略。
或者，你也可以選擇產品功能很豐富，而且每一項功能的實現水平也很高，那么你勢必需要很多的計算資源。比如我們過去的邊界型安全產品，一個數據中心，只需要兩臺，每臺設備都是4U，兩臺就能裝滿一個機柜。
對于微隔離而言，一個最主要的限制就是計算開銷問題。由于微隔離需要對整個數據中心內部做點到點的訪問控制，所以他的控制點的分布應該是盡可能的廣。正如我們前面說的，我們能做到每一個容器都有一個控制點。但是部署量如此的巨大，就要求你單個控制點的計算開銷必須盡量的小。舉個例子吧，現代一個云計算數據中心的造價，少則兩三個億，多則十幾個億。我們就說兩個億吧，那么如果單控制點計算開銷增長1%，就意味著這個數據中心要多拿出價值200萬的計算資源！
所以，根據不可能三角，我們就必須在功能豐富性與功能的完善性之間做個二選一的選擇，再結合我們前面對微隔離所面臨的技術挑戰的描述，那么其實我們能選擇的路就只有一條，那就是選擇少而精，而不是多而粗。
道理是明顯的，但是要做得到，真還挺考驗人性的。作為一家高科技創業企業，無論是從客戶的要求來說，還是從我們對新技術的偏好來說，我們都有極大的沖動去做更多的安全能力。但這個時候，我們就必須始終牢記我們的產品邊界，始終牢記，我們是要在超大規模生產環境交付的企業級產品！然后就只能看著一個個熱點生生滅滅，看著在不同的風口中，一只只小金豬飛翔天際，看著一只只獨角獸從我們面前飛奔而過，而我們只能撣撣飛揚的塵土，回去再做下一輪的版本迭代。
