多云环境下安全面临的概念性及技术性挑战

现代公共云环境给世界提供了无数可能。主流云服务(如：亚马逊AWS、微软Azure和谷歌云平台(GCP))不仅有健壮的解决方案，其服务和功能还在不断增加。

[[244032]]

时至今日，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中明明允许了的流量还会被封堵了。

一些建议

以上例子还只是多云解决方案带给我们的真实体验与挑战当中的一小部分。成为一个云平台的专家就需要很多时间的磨练，在多云环境下工作就更困难更容易出错了。为减小风险，可以遵循以下建议：