微隔离--零信任网络的基础构件

纪念零信任理念诞生10周年

 

零信任是什么、不是什么

 

零信任作为一种安全管理哲学，近年来渐渐有了一统江山之势，包括“产学研用管”在内的整个安全业界基本上在零信任这个问题上达成了共识，不信大家可以看看等级保护2.0的原文，你就会发现，那里处处体现着零信任思想的光芒。

 

关于零信任究竟是什么，网上的资料已经很多了，在这里我就不再照搬照抄了。不过我们也注意到，“零信任”这个词除了是一个技术词汇之外也是一个市场词汇，被各个安全公司从自己的视角各自解读，在这个过程中不可避免地会夹带一些私货，从而造成一些混乱和误解，所以我们今天来谈谈零信任不是什么，也许对于帮助大家更好地理解零信任会起到一些积极的作用。

 

首先，零信任是一个方法论，它定义了一种安全管理的新的视角。它不是一个产品或者说一个技术。也就是说您买不到一个叫零信任的产品，您只能买到帮您实现零信任的某种要求的产品。

 

其次，零信任是一个过程，或者说是一个方向。它不是一个静态的标准，或者说状态。也就是说，你不能说我们今天来做一个零信任的项目，做过之后我们就拥有了零信任，没有这种事情。你只能说通过一期项目，我们在一定的范围内，在一定的水平上，实现了零信任的某些能力。比如说，我们可以说我们能够在网络层面实现数据中心流量的全面可视和可控，但是网络层之上还有应用层，你看到了网络层面的主体和通信关系，但是你还没有理解应用层面的服务主体和应用访问关系。而在应用层之上还有更深层次的业务层面的分析与控制问题。所以说，零信任的建设应该是一个持续的，逐渐深入，逐渐优化的过程，也是一个在安全与业务之间的一个平衡的过程。

 

最后，零信任是个广泛适用的方法论，也就是说它可以应用于整个计算架构的各个方面，在每一个细分的环境，每一个具体维度上都可以利用零信任的方式来做管理，而不是说零信任只能像谷歌那样将之应用于办公网，面向员工的身份进行管理。我们可以看一下Forrester的这张图：

 

大家可以看到，零信任可以作用于人，设备，网络，工作负载等所有有数据流动的主体上。事实上，相较于办公网而言，数据中心是更容易实现零信任的场景，也是有着更多核心业务和关键数据的地方，因此可以成为我们开展零信任建设的起点。

 

微隔离在零信任网络中的地位和价值

 

现在我们说下微隔离技术。前面我们谈到，相较于办公网而言，数据中心网络更适合成为零信任建设的起点。那么对于数据中心网络而言，具体的产品技术是什么呢？这个在业界是有共识的，有两个技术是当下能够落地的，一个是SDP，一个就是微隔离。事实上微隔离技术是最早的一种对零信任这个概念的具体技术实现。我们看下Forrester2019年Q4的报告：

 

报告中的这段开场白大概是这么个意思：零信任是个挺费劲的事情，甲方自己上是没戏的，你得找到能帮你干这个事的供应商。那如何来评估每天围在你门口的那么多乙方呢？有这么几个标准：首先就是要态度端正，你必须让他指天发誓，他们相信零信任这件事情就是人民群众大救星，只有零信任才能拯救网络安全。而且他们必须得有真本事，他们的产品确实能在零信任架构中有一个独特的价值，而不是来碰瓷的（deliver real Zero Trust capabilities），看来挂羊头卖狗肉这事儿也不光是咱国内的特色。除了态度端正之外，第一条具体的安全能力要求就是支持微隔离! 下面的那些个要求就不在本文讨论了，就是让您感觉一下微隔离在零信任技术体系中的地位是什么。

 

我们再看下同样在这篇报告里的这个图：
 

 

这是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万的计算资源！

 

所以，根据不可能三角，我们就必须在功能丰富性与功能的完善性之间做个二选一的选择，再结合我们前面对微隔离所面临的技术挑战的描述，那么其实我们能选择的路就只有一条，那就是选择少而精，而不是多而粗。

 

道理是明显的，但是要做得到，真还挺考验人性的。作为一家高科技创业企业，无论是从客户的要求来说，还是从我们对新技术的偏好来说，我们都有极大的冲动去做更多的安全能力。但这个时候，我们就必须始终牢记我们的产品边界，始终牢记，我们是要在超大规模生产环境交付的企业级产品！然后就只能看着一个个热点生生灭灭，看着在不同的风口中，一只只小金猪飞翔天际，看着一只只独角兽从我们面前飞奔而过，而我们只能掸掸飞扬的尘土，回去再做下一轮的版本迭代。