在零信任安全(zero trust security)的物理实施环境下，数据流通过一个集中式安全设备传输。零信任安全其实是一种安全模式，在这种模式下，任何用户、接口或应用程序在默认情况下都不“可信”。但由于单一设备需要过滤所有的数据流，零信任安全策略很难灵活地扩展。不过，当工作负载和网络基于虚拟化或云计算时，环境却可以灵活扩展。
在数据中心中，微分隔(micro-segmentation)让零信任安全可以得到大规模地运用，而微分隔是基于虚拟机管理程序的网络覆盖机制的一个副产品。据风险投资公司Battery Ventures的技术研究员、Netflix前云计算架构师Adrian Cockcroft声称，就云服务而言，微分隔常常是固有的。下面看一下各种虚拟化和云计算平台里面的微分隔和零信任安全功能。
VMware NSX
VMware的网络虚拟化平台NSX可以过滤进出虚拟机管理程序的任何数据流。这项功能带来了零信任安全机制。VMware利用NSX的分布式防火墙具有的可扩展性，在不同主机上的虚拟机之间形成零信任安全。还可以在同一个逻辑第2层广播网络上的主机之间建立安全策略。
VMware的方法是抽取物理零信任安全，同时利用基于虚拟机管理程序的网络覆盖系统具有的分布式特性。管理员可以在集成式管理系统中制定规则，这些规则可以跨分布式防火墙设备来执行。结果就是，集中管理的解决方案可以灵活扩展，支持每个虚拟机管理程序为两位数Gbps的数据流。
#p#
亚马逊网络服务(AWS)
在云平台中，客户和第三方产品无法直接访问底层的虚拟机管理程序。这意味着，客户只好依赖通过云API才可以使用的服务，实现零信任安全。
以亚马逊网络服务(AWS)为例，了解公有云与内部网络之间的连接很重要。有三种方式可以访问AWS中运行的实例：公共互联网、基于IPsec的亚马逊虚拟私有云(VPC)和AWS Direct Connect(一种专用的第3层线路，连接至亚马逊设施)。所有连接方案都需要客户端的IP终结，这应该会通过防火墙。亚马逊并不允许用户的第2层数据流可通过Direct Connect或VPC来进行扩展。
基于AWS连接设计，AWS托管的实例与企业内部节点之间本身就有零信任。这样一来，问题就成了AWS内部的实例到实例的数据流会出现什么样的情况?
AWS使用安全组来控制网络对实例的访问。安全组的定义可以非常广泛，也可以非常狭窄。某个实例可能有一个或几个安全组运用在其头上。虽然重点通常放在IP数据流上，但知道VPC网络并不支持广播或多播数据流很重要。所以，根本不需要过滤非IP数据流。
开发人员可以使用AWS管理控制台或AWS API来制定或分配规则。他们还可以将规则运用到入站数据流和出站数据流。默认情况下，所有出站数据流都被允许，而入站数据流被拒绝。这一细粒度功能让IT人员很难排查连接方面的故障，因为单个实例可能属于多个安全组。此外，Windows和Linux存在不同的安全组，这可能会导致安全策略相互冲突或相互重叠。然而，任何零信任安全方案都存在这个情况。
#p#
谷歌计算引擎
谷歌计算引擎网络机制更类似传统网络机制。每个实例被分配给一个默认网络，这就允许同一个网络里面实例到实例的数据流。谷歌提供了一个逻辑防火墙，以阻止网络之间的数据流。为了实现零信任安全，每个实例必须使用本地防火墙或正则表达式(iptables)，或者把每个实例放入到单独的网络。然而，使用本地防火墙和正则表达式可能难以管理，又由于处理器周期将被用于执行规则，这可能会影响虚拟机的性能。
微软Azure
微软Azure的网络机制类似谷歌计算引擎的网络机制。虚拟机被分组到逻辑专用网络。Azure允许端点访问控制列表(ACL)，而ACL可以运用在主机层面。在主机层面处理规则有助于保持本地虚拟机的性能。与谷歌相似，你无法为来自Azure中群组的实例运用规则。因此，在庞大环境下密切跟踪规则可能困难重重。
云服务提供商在零信任安全和微分隔方面有强大可靠的模式。以微软Azure和AWS为例，开发人员可以选择从应用程序里面整合微分隔安全机制。这让开发人员开发出来的应用程序可以灵活扩展，并应对迅速变化的安全态势。
原文标题：Achieving zero trust security in the cloud
