现代公共云环境为世界提供了无数的可能性。亚马逊AWS、微软Azure和谷歌云平台(GCP)等主要云服务不仅拥有强大的解决方案，而且其服务和能力也在不断增加。如今，81%的公司与多家云服务提供商(CSP)合作。采用多云策略的原因各不相同：可能是希望在另一个云平台上创建灾难恢复(DR)，或者通过最合适的云服务来平衡工作负载，也可能是公司合并或获得。无论多云环境如何引入，保护多云平台始终是企业面临的重大挑战。云提供商正争先恐后地填补他们的能力差距，并使他们的产品脱颖而出，以吸引和留住客户。他们的安全服务发展迅速，在不同的安全领域提供强大的安全功能，但安全功能的实现方式各不相同。一些服务可能看起来相似，但细微的差异可能会导致安全问题和错误配置。安全企业在多云部署中将面临哪些挑战？1.不同的供应商引入不同的账户模型。第一个挑战出现在部署之初：每个云提供商都有自己独特的一套账户管理模型。安全公司通常需要将资源与云提供商客户相匹配。为此，他们必须了解要应用的正确权限模型。当使用多个异构CSP时，此任务变得非常具有挑战性。AWS模型基于云账户，账户可以分配给一家公司，允许用户指定计费和政策继承。GCP基于项目。任何GCP资源都必须属于一个项目。项目放在目录中，支持多级目录。Azure是基于订阅的，一个帐户可以包含多个订阅。Azure资源分为资源组，由订阅管理。虽然这些不同的概念是相关的，但存在可能影响安全性的细微差别。了解资源层次结构需要了解要应用的安全模型。2.控制不同平台的安全组IT工程师积累了数十年的专网经验。但是，在物理域控制器(DC)中，它们控制从电缆到应用程序的一切，而在云环境中，亚马逊、微软和谷歌控制物理层并创建在虚拟网络上运行的不同服务。云解决方案使用与DC不同的路由模型，不同的云解决方案使用不同的模型。DC的网络防火墙嵌入到称为安全组(SG)的基础设施中，安全组因SG而异。AWSSG包含入站和出站流量规则，这些规则是充当白名单以允许流量的“允许”规则。用户可以将多个SG连接到每个ElasticComputeCloud(EC2)实例（实际上是一个ElasticNetworkInterface(ENI)），每个安全组的规则被有效聚合以创建一套完整的规则。SG可以应用于不同的实体，包括实例或托管服务，例如负载均衡器。AzureNetworkSecurityGroup(NSG)和GoogleElasticComputeCloud(GCP)SG提供的体验更类似于经典防火墙，有两个允许和拒绝规则列表。规则的顺序很重要：优先级较高的规则控制允许或阻止流量的决定。Azure只允许每个虚拟机一个NSG，但NSG也可以应用于连接虚拟机的子网或网络接口(NIC)。GCP安全组是基于标签的，允许将规则附加到虚拟机等资产。需要在创建网络时考虑到实施正确模型的需要。Azure中规则的优先级设置不正确可能会导致流量被错误地允许。如果AWS中的一个虚拟机被分配了多个安全组，那么原SG拒绝的流量可能会被错误地放行。主要使用AWS的工程师可以修改拒绝优先级规则并阻止对服务的访问（或者，在不应将服务公开到互联网时）。配置安全性需要头脑清晰，总是在不同部署之间切换的IT工程师很容易出错。3.云中虚拟网络的行为模式进一步深入到网络层是不同的。AWSVirtualPrivateCloud(VPC)子网可以是私有的或公共的；连接到Internet网关(IGW)是公开的。只有公有子网允许部署在其上的资源访问互联网。AzureVNet没有私有或公共子网；默认情况下，连接到VNet的资源可以访问Internet。习惯于AWS的工程师依靠AWS来阻止实例访问互联网。但是在Azure上创建DR站点时，工程师必须明确阻止Internet访问。上下文切换问题可能很危险。AWS网络中的另一个问题与网络访问控制(NACL)有关。NACL检测进出子网的流量，运行在子网级别，而SG运行在虚拟机级别（实际上是弹性网络接口层）。NACL是无状态的，这意味着入站流量已经被允许了数百年，它的响应可能不会自动被允许——除非在子网规则中被允许。AWS提供的以下图表说明了跨不同安全层的流量流向。Azure和GCP没有采用NACL的概念，因此从这些平台迁移到AWS的工程师通常不知道为什么SG中明确允许的流量被阻止。一些建议以上示例只是多云解决方案带来的真实体验和挑战的一小部分。成为云平台专家需要花费大量时间，而在多云环境中工作更加困难且容易出错。为降低风险，您可以遵循以下建议：使流程自动化。手动更改容易出错；自动化可以减少出错的可能性。采购跨云系统。在不同的云平台上提供抽象和相似体验的解决方案可以消除上下文切换的问题。采用变更审核机制。【本文为专栏作家“李少鹏”原创文章，转载请通过暗牛（微信♂id：gooann-sectv）获得授权】点此查看作者更多好文
