微隔离：好还是不好？

更细粒度的控制是个好东西，但说的总比做的容易

[[173987]]

RedSeal首席技术官 麦克·罗伊德

虚拟数据中心事务繁杂。在安全上，我们听过各种版本的“微隔离”。这个术语源于VMware，但被其他多个领域借用，有些为其做了引申。

[[173988]]

大家都知道隔离是什么。每个企业都会将网络至少分隔为外网和内网。大多数公司都想要某种程度上的内部隔离，但太多的光说不练——除非审计迫在眉睫。很多网络对审计员关注的资产做了一定的隔离，比如患者记录和信用卡信息。确实有企业高出安全复杂性曲线，对业务有严格的区域划分，并对跨区域访问有一定程度的监管。但这些一般都是大型复杂企业，因而每个区域也往往很大。

简单算一下就知道，要跟踪N个区域，考虑的必然是N*(N-1)个关系。这是指数级上升的数字。即便员工充裕的团队也难以应付单一网络中的十几个主要分区。听起来似乎不多，但任意两个网络隔离之间的开放访问，很容易就会超过50万对通信。全面审计其中一个隔离就已经是超人般的壮举了。

但如今，牵引IT战车的战马又多了两匹：虚拟数据中心和软件定义网络。二者提供更多的隔离，更细的控制，大幅减少IT团队工作量(不同市场营销团队承诺的工作负载减少量不尽相同，就看你选择相信哪家了)。听起来真是太棒了，谁不想要超精细的控制呢?再没人相信“仅边界”模式就能搞定安全了。那么，更多的控制必然更好，对吗?但实际上，如果你仅仅将此技术甩到现有堆栈上而没有扩展计划，也是没什么卵用的。

如果你以难以搞定的复杂管理任务做为开端，简单拆分成更小的任务，分发到更多的地方，那很快，你就会疯狂分裂到生无可恋。

真的没什么希望了吗?当然不!问题出在规模上。在快速发展的基础设施里，更多的隔离，会给已经疲于应付的人类团队制造更多的麻烦。但这正好是计算机非常擅长处理的那类问题。关键就在于认清：你得从实现中将目标(允许在网络中出现的东西)剥离出来，无论你的实现是遗留防火墙，还是管理虚拟工作负载策略的新鲜GUI。

现实世界中，这不是个非此即彼的问题，而是二者兼具的问题。因为你不得不在更宽广的网络中协调你的虚拟工作负载防护。全网必然不是软件定义的，它会非常顽固地驻扎在你面前，绕不过，推不开。

也就是说，如果你能描述清楚你的网络职能，你就能赢得漂亮。把你的目标从具体实现中分割出来吧。比如说，在各业务单元区间关系中用通用术语将意图记录下来。然后，你就能用自动化软件来检查是否确实符合该网络被设置的原本职能了。计算机不会累，它们只是不太清楚你的公司或你的对手，因而写不出适合你的具体规则。

相信软件能搞清公司企业的运作方式，或者希望软件能迷惑对手，是不现实的。既然软件都不能通过图灵测试，区区一个算法又怎能理解作为现代恶意软件支柱的社会工程呢?

微隔离不是个坏东西。这就像是询问水是不是个坏东西一样。用对了，是生命之源;肆虐了，便是死亡使者。在这个问题上，学会游泳可不是找出最新万能安全产品这么简单的事儿，而是要弄清你整体基础设施协同运作机制，知晓它是否在满足业务需求的同时又没有暴露过多的攻击界面。