经过长期的思考与技术预研，他们认为微隔离技术必将作为一项颠覆性技术，成为未来数据中心尤其是云化数据中心东西向网络安全的基石，帮助用户满足等级保护2.0关于内部安全的一系列要求。在蔷薇灵动的第一版商业计划书中就明确将等保2.0列为其首要市场驱动因素，并于2017年年初正式成立公司，开始了产品研发工作。从这个角度来说，中国的微隔离技术就是由等保2.0催生而出的科技创新。

虽然等保2.0的正式发布比他们预计的要晚了一些，但是这也给了蔷薇灵动以足够的时间来磨炼产品，打造标杆。迄今为止，蔷薇灵动已经为海淀区电子政务云，通州区电子政务云，中国移动，中国电信，中国人寿等多家政企客户提供了微隔离产品和服务，部署的环境覆盖了VMware，OpenStack，阿里云，腾讯云，华为云，华三云，天翼云，青云，K8s等各种云计算和虚拟化系统，操作系统覆盖了包括windows的全线服务器版本，所有的主流linux版本以及部分国产化操作系统。

2019年5月10日，等级保护2.0技术标准正式发布，这将成为中国网络安全行业发展历史中的重要里程碑事件，也将成为蔷薇灵动发展历史中的关键节点。

微隔离从高配到标配的转变

以等级保护2.0技术标准正式发布为分水岭，可以把微隔离产品的发展化为两个时期。

在等保2.0以前，微隔离技术属于高配技术，他的核心驱动是两个，一个是零信任的安全管理逻辑，一个是大规模云计算系统的安全运维需求。这时候主要部署微隔离技术的用户包括：

1）大型行业用户

例如央企制造业，金融行业等，这些用户一直以来都极为重视安全，他们的业务系统从来都是按照白名单方式来进行网络策略管理的，但是在云计算时代，过去的技术手段遇到了问题，使得他们开始考虑采纳微隔离技术作为替换性技术来在云计算环境下继续提供白名单的管理能力。

2）大型云计算用户

即使不做白名单，而只是在业务系统间进行隔离，在大规模云计算环境下也变得非常困难，云基础架构提供的安全组，VPC等能力随着体量的增长和变化频度的加快变得极为不可用，此时他们也考虑采用更专业的微隔离技术来在云计算环境，尤其是多云，混合云条件下完成其业务隔离，区域隔离需求。

3）高安全需求用户

随着APT越来越引起重视，以及勒索病毒的泛滥，网络安全管理者越来越重视内部威胁的防御工作。现有的安全技术主要是南北向技术，防御对象是外部攻击，这些技术应用于内部的时候往往有各种不适应，此时，用户会考虑部署微隔离技术来发现内部的威胁，并对网络攻击在内部的横向行走进行防御。

而随着等级保护2.0技术标准正式发布，微隔离技术将从过去的高配变成标配。

关于等级保护2.0对内部安全的要求及其带来的挑战，在我们去年的一篇文章中做了深刻的技术分析，大家可以参考这篇文章： 东西向加白名单！等保2.0挖了个“天坑”

值得再强调一下的地方是，对于内部安全的重视不仅仅是在云环境，而是在全部计算环境，因为这些要求是出现在等级保护的通用安全要求部分。也就是说不管你是不是已经进行了云化或者虚拟化，你都必须要对你的数据中心进行白名单化管理。当然，在非云环境下，除了微隔离，还是有其他手段的，比如说，过去的银行系统就通过部署大量的隔离防火墙来解决这个问题，不过这个开销真不是普通用户能承担的了的。相较而言，更加轻量级的微隔离技术即使在传统环境下也有着更好的可行性。

在等保2.0时代，以下用户和场景应该尽快考虑部署微隔离技术以实现对内网流量的可视化管理与全面可控的策略设计。

1）各级电子政务云

2）企业私有云和数据中心

3）阅批部委部署的数据中心，私有云和行业云

4）各种大数据计算平台

5）政企用户没有部署过内部安全措施的数据中心

微隔离部署方式

微隔离技术要管理的是由数千甚至数万台机器构成的大型计算环境，在部署这一技术时必然有一定的复杂性，通过长期的实践，蔷薇灵动总结出了一套自己的方法论：

第一步，对东西向业务进行学习，绘制云内业务拓扑。

第二步，业务梳理（确认）

这一步，在不同的用户处不太一样，有的用户过去没有完善的资产、业务与配置管理体系，这就需要首先建立起一套业务模型出来。无论如何，在你根本不理解业务的情况下，是不可能进行有效的东西向安全策略设计的。这种情况下，这一步的工作量就变得比较大了，而且往往需要调度多个部门进行协作。不过，既然等保2.0已经来了，这是早晚都要做的一步，用我们的技术已经把工作量缩减了好几个数量级了。

而如果是用户过去就有很好的类似于CMDB的资产与业务管理系统，那么我们就只需要做业务确认即可，因为实际的业务情况可能会与系统中的不一样，或者系统中缺少一些信息。

第三步，策略设计

好的微隔离产品，一定能够根据业务情况自动生成安全策略（当然，好的安全产品一定能看得见业务），否则，如果让用户自己去逐台机器进行配置，那根本就是一场灾难。比如我们的一个客户，有两万台虚拟机，随便一个业务系统就有超复杂的内部业务关系，给张图你们自己体会下（这还不是虚机间关系，只是业务间关系）。

而且策略最好是IP无关的，比如蔷薇灵动可以直接根据虚拟机的业务标签来配置策略。因为IP地址在云内是个非常不稳定的参数，一旦策略是用IP来配置的，那么后面的运维就非常痛苦了。

第四步，自适应运维

好的微隔离产品，一定能够进行自适应的策略运维，也就是当云计算环境发生，迁移，扩容，升级等变化时，系统可以对安全策略进行自适应调整。没有这个能力，策略运维将变得非常困难，甚至是难以完成的。比如我们的另一个客户，每天都有新业务上线，随时都有可能进行业务架构调整，此时如果策略运维不是自动完成的，那么他们的业务交付必将被安全所拖累。

第五步，自动化编排

云计算环境下，一切都是软件定义的，这当然也包括安全。不同的安全产品，需要被进行统一的管理和调度。我们的产品从设计之初就采用了微服务架构，每一个点击，每一个查询背后都有对应的API可以使用，这使得我们可以被整合到云管理系统中，或者被SOC/SIEM等安全管理平台所调用。