现代公共云环境给世界提供了无数可能。主流云服务(如：亚马逊aws、微软azure和谷歌云平台(gcp))不仅有健壮的解决方案，其服务和功能还在不断增加。
时至今日，81的公司企业与多家云服务提供商(csp)合作。
采用多云战略的原因各不相同：可能是想在另一个云平台上创建灾难恢复(dr)，或者按最适宜的云服务来平衡工作负载，也可能是公司并购的产物。无论多云环境是如何引入的，保护多云平台的安全始终是摆在公司企业面前的一大挑战。
云供应商争先恐后地补齐自己的功能短板，并努力在产品上出新出彩，以求吸引并留住客户。他们的安全服务发展很快，能跨不同安全领域提供强大的安全功能，但安全功能的实现方式却多种多样。有些服务可能看起来差不多，但细微的差异也能导致安全问题和配置错误。
多云部署中安全公司会面临哪些挑战呢?
1. 不同供应商引入不同账户模式
第一个挑战就出现在部署之初：每个云供应商都有自己的一套独特的账户管理模式。安全公司常需将资源匹配给云供应商的客户。为此，他们必须理解需应用的正确权限模式。使用多个异构csp的情况下，此项任务就颇具挑战性了。
aws模式基于云账户，可以将账户分配给某个公司，让用户来指定的计费和策略继承。
gcp基于项目。任何gcp资源都必须属于某个项目。项目放置在目录中，支持多级目录。
azure基于订阅，一个账户可以包含多个订阅。azure资源被分组为资源组，按订阅管理。
虽然这些不同的概念相互关联，但还是存在可以影响到安全的细微差别。要理解资源层级，就需知道该应用哪种安全模型。
2. 控制不同平台上的安全组
it工程师积累了数十年的私有网络经验。但虽然实体域控制器(dc)中他们控制从电缆到应用的一切东西，在云环境下，却是亚马逊、微软和谷歌控制着物理层，并创建了运行在虚拟网络上的不同服务。云解决方案使用的路由模型不同于dc所用的，不同云解决方案使用的模型也各不相同。dc的网络防火墙嵌入到基础设施即安全组(sg)里，而sg之间各有不同。
aws sg 包含入站和出站流量规则，都是些“允许”规则，作为白名单起到流量放行作用。用户可以将多个sg接入每个弹性计算云(ec2)实例(实际上是弹性网络接口(eni))，每个安全组的规则被有效聚合，创建出一整套规则。sg可被应用到不同实体，包括实例或负载平衡器之类的托管服务。
azure网络安全组(nsg)和谷歌弹性计算云(gcp) sg 提供的体验更近似经典防火墙，拥有允许和禁止两张规则列表。规则的顺序很重要：高优先级规则控制着流量是允许还是禁止的决策权。azure只允许一台虚拟机有一个nsg，而nsg也可应用到连接虚拟机的子网或网络接口(nic)上。gcp安全组基于标签，允许将规则附加到虚拟机之类资产上。
创建网络时需得考虑到实现正确模型的需求。azure中规则优先级设置错误，可能导致流量被误允许。aws中的虚拟机若被指派了多个安全组，原始sg拒绝掉的流量就有可能被误允许。主要与aws打交道的工程师可以修改拒绝优先规则并阻止对服务的访问(或者，在不应该暴露服务的情况下将其暴露到互联网上)。配置安全需要清醒的头脑，总在不同部署中间切换的it工程师就很容易出错。
3. 云中虚拟网络的行为模式不同
进一步深入到网络层。aws虚拟专用云(vpc)子网可以是私有的，也可以是公共的;连接互联网网关(igw)就是公共的。只有公共子网允许自身部署的资源访问互联网。azure vnet 没有私有或公共子网;连接vnet的资源默认可以访问互联网。习惯了aws的工程师依赖aws来阻止实例访问互联网。但在azure上创建dr站点时，工程师就得显式阻止互联网访问了。上下文切换问题可能是有危险的。
aws组网中的另一个问题与网络访问控制(nacl)有关。nacl检测流量出入子网情况，运行在子网层级，而sg运行在虚拟机层级(实际上是弹性网络接口层)。nacl是无状态的，也就是说几百年入站流量被允许了，其响应也未必就自动允许——除非子网规则中显示允许。aws提供的下列图表阐明了跨不同安全层的流量流。
azure和gcp不采用nacl的概念，于是从这些平台迁移到aws的工程师常常搞不清楚为什么sg中明明允许了的流量还会被封堵了。
