越来越多的用户将服务转移到云服务中，这其中就包括许多大型企业。随着云端提供服务的基础设施越来越好、成熟度越来越高，许多大型企业已开始将核心业务功能转移给下一代IT托管和应用交付，“应用交付”实际上就是指应用交付网络（Application Delivery Networking，简称ADN），它利用相应的网络优化/加速设备，确保用户的业务应用能够快速、安全、可靠地交付给内部员工和外部服务群。不过这对信息安全具有重大影响。如果不加以控制，此举可能会给企业带来无法想象的安全灾难。

本文是思科安全团队进行的一次云端安全研究，重点在于如何改进他们的渗透测试技术来使用混合云解决方案，另外就是解决一些经常碰到混合云相关漏洞。

为什么要使用混合云

混合云（Hybrid Cloud）是近年来云计算的主要模式和发展方向。由于安全和控制原因，企业更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源，在这种情况下混合云被越来越多的采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到了既省钱又安全的目的。

云端托管的功能非常强大，仅举几例：

· 符合SOC2, PCI-DSS Level 1, HIPAA和ISO27001；

· 快速部署(快速部署（CloudFormation，Terraform）；

· 降低成本；

· 增大了可扩展性；

对于信息控制、可扩展性、突发需求，以及故障转移需求来说，混合和匹配私有云和公有云是一件好事情。 最近几年，云计算的发展计划开始围绕整个架构支持方面，围绕混合云，或者是混合、匹配各种云计算模式来展开。有趣的是，并不是说私有云和公有云各自为政，而是私有云和公有云同时协调工作。目前，已经有很多企业都朝着这种集中云(Cloud-Bursting)的架构发展，同时这也是实现利益最大化的关键。

所有这些强大的因素叠加在一起，现在看来已经足够将一般的网站整个转移到云计算，而且还可以将核心系统进行转化。

安全方面有什么安全隐患？

当应用程序部署到云中时，在一个将云基础设施与部署的应用程序分开管理的组织中，开发人员或程序的运维人员通常无法看到底层操作系统的配置。

目前许多组织已经采用了“DevOps”方法和工具集来管理云IT基础设施。DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。DevOps最有趣的地方莫过于它是一种思想上的"反模式"。一般我们认为，一个行业发展越成熟，它的工种划分会越细致。因此在软件业，开发者Dev和运维人员Ops自然而然的被分成两个独立的部门。而DevOps则反其道而行之，它鼓励开发者和运维人员坐在同一间办公室里，并对彼此充分了解。现在存在大量的DevOps工具：CloudFoundry，Docker Swarm或Kubernetes等，这些工具带来了极大的灵活性和快速操作性，但这些工具也被攻击者也广泛了解。

基本的安全前提

云端的每个节点的配置通常是根据相应的标准构建或基于所有可用节点使用的预先存在的配置来定义的。在某些情况下，这种节点的配置可能导致实际中的安全漏洞，其中应用程序组件依赖于未在标准的构建中实现的操作系统级安全控制。不过，云管理工具和内部网络服务的出现也增加了攻击面（本地环回接口，覆盖网络和内部云网络）。

如何进行渗透测试？

进行渗透测试的标准方法和手段是不断在更新的。传统上，渗透测试的评估系统是以IP地址、DNS或NetBIOS名称来命名的。在云环境中，瞬态主机（transient host）可能只存在几周，因此在发布测试报告时，已识别出的漏洞已移至其他的系统。

当然仍然需要漏洞扫描和应用层渗透测试，但是，如果要确定根本原因，必须确定负责的组件，无论是部署的应用程序、共享服务还是云管理工具。例如，在应用程序渗透测试期间， TestContext测试框架可以识别可访问公有云的Kubernetes API服务，该服务可以通过修改对应用程序的请求中的HTTP“主机”头来访问。Kubernetes API是集群系统中的重要组成部分，Kubernetes中各种资源（对象）的数据通过该API接口被提交到后端的持久化存储（etcd）中，Kubernetes集群中的各部件之间通过该API接口实现解耦合，同时Kubernetes集群中一个重要且便捷的管理工具kubectl也是通过访问该API接口实现其强大的管理功能的。

此特定漏洞利用已部署的反向代理中的漏洞，为了解决该问题，必须对部署脚本而不是应用程序代码库进行更改，以确保在未来的迭代中部署反向代理而不存在漏洞。这将要求负责管理云基础架构的人员与应用程序团队密切合作。

如果不考虑完整的渗透测试生命周期，那企业的云端则很容易受到攻击，包括传统的托管或应用交付中没有考虑到的威胁。

因此，全面的渗透测试计划不仅可以提供安全状况的时间点评估，还可以帮助解决以下问题：

1.对于我的云服务提供商，我到底能否100%信任。

2.如何保护我的代码和数据免受来自托管提供商、容器溢出（container breakout）或同一云环境的其他租户的攻击?

3.如果我的某个应用程序受到攻击，攻击者是否能够遍历云并访问云中的其他计算节点、应用程序、资源？

4.攻击者是否能够遍历我企业的内部基础设施？

对于涉及多个利益相关方和第三方而言，定义端到端渗透测试的范围可能很困难。 当网络隔离以及访问或自动化控制阻止对底层系统的实际访问时，就会迫使测试者使用诸如web shell之类的替代通信流来获得对组件的访问。

由于本文旨在强调对混合云和容器部署维护的渗透测试。因此在下文，研究人员将深入探讨企业网络和云之间连接的潜在漏洞。

混合云中的安全性:集成内部系统

上面讲述了环境混合云环境中托管可能出现的一些普遍问题，下文，研究人员将更深入的研究如何将内部系统与混合云集成。

根据混合云的定义，它可以连接组织的内部网络和一个或多个云提供商之间的通信通道。虽然每个云提供商都采用不同的方式提供管理访问，通常通过web管理控制台和API，但本文主要关注Amazon AWS。

对混合云进行渗透测试时要考虑的第一点便是它的网络系统：

1.如何连接企业环境和云环境，以允许企业内部服务和云托管服务之间的双向通信?

2.混合云对可用性和安全性有什么影响?

解决这些问题的通常的方法是用一个IPsec VPN隧道，在企业端有一个硬件VPN集中器，在AWS VPC(虚拟私有云)中有一个Amazon“虚拟私有网关”。然后，两端的IP地址范围都将被明确地用于路由，以便两端的系统不必知道用于发送和接收来自另一方的流量的VPN隧道。

一旦确定并理解了VPN配置，就可以以类似于普通VPN配置检查的方式检查两端的配置。一些企业可能会在VPN上添加另一层，以便在隧道的两边都有一个子网，这会使得两边主机之间的区别更加透明 (单纯的IP地址并不意味着主机所在的位置)。这有时被称为“底层和覆盖（underlay and overlay）”模型，其中每个主机需要一个客户机和一个配置文件来加入覆盖网络。这将为每个主机添加额外的网络接口，这可能会使事情变得复杂并导致漏洞，如果服务在两个接口上意外暴露，只应在一个接口上公开，或者防火墙规则仅针对其中一个接口实现。underlay是传统单层网络，是当前数据中心网络基础转发架构的网络，而overlay是一层逻辑网络，指通过控制协议对边缘的网络设备进行网络构建和扩展。总的来说，underlay网络与overlay网络相互独立而又相互联系。

公有云和私有云之间最安全的链接

除了VPN隧道外，企业可能还希望为混合云使用不同的网络路由。AWS Direct Connect就是一个例子，它允许流量通过专用的Amazon链接从企业的数据中心流向AWS，绕过公有云路由。这通常会减少网络跳数和网络延迟，因此主要是性能优化，但如果不允许数据流过公有云（但在AWS中允许），则可用于满足监管要求。

为了实现这一点，企业必须使用非Amazon数据中心作为其企业主机，而Amazon有直接连接链接。然后，在企业的路由器和亚马逊的路由器之间连接一条直接的光缆，每个设备通过BGP通告其相关的IP地址空间。应检查此BGP配置以确定企业内部网络的哪些部分正在向AWS进行通告，因为这将确定AWS云主机和服务可以访问的内部网络的范围。

如何在公有云中保护内部网络

必须仔细考虑VPN和Direct Connect选项的网络配置，因为它们为第三方云提供商(在本文中是Amazon和VPC中的服务)提供了到企业内部网络的直接链接，无论是虚拟的还是物理的。因此，企业的VPN集中器或直接连接路由器应被视为进入内部网络的入口点，除了路由通告外，还应安装适当的防火墙来控制传入和传出流量。

不应从企业网络（特定管理源除外）或Amazon VPC内访问管理服务，例如启用Direct Connect链接的交换机，路由器和防火墙的管理接口。如果VPC主机遭到攻击，攻击者可能能够访问这些管理服务，对直接连接链路执行中间人攻击或拒绝服务攻击，从而允许他们拦截或阻止双方的所有流量。

来自互联网（公有云）的攻击

许多使用混合云模型的企业正在考虑将公有云作为其私有内部网络的扩展，但同时又不使用它的任何面向互联网的公共组件，例如使用私有云计算资源的同时，不涉及到公有云。但是，由于公共云提供商必须连接到互联网，以支持其他需要面向互联网服务的用户，因此在配置时应该需要小心。VPC不应具有直接入站或出站的互联网访问（例如通过互联网网关），并且EC2实例不应附加公共IP地址。Amazon EC2提供不同的实例类型，以便您可以选择需要的CPU、内存、存储和网络容量来运行您的应用程序。有关更多信息，请参阅实例类型。然而，通过在公有云和企业内部网络之间进行的双向通信，云资源可能会绕过这一限制，通过VPN隧道使用企业端的网关或web代理访问互联网。如果不需要，则应注意限制云资源可访问的企业系统权限。

在不允许互联网接入的云设置中，还需要考虑其他用于渗透和过滤数据的渠道。云DNS设置可能允许DNS隧道，或者如果云DNS请求通过VPN隧道转发到企业DNS服务器，则可以使用企业DNS服务器进行DNS隧道连接。

S3 bucket

目前任何AWS环境都可能会使用S3bucket，它们可以用于存储与应用程序相关的静态内容，或者作为云部署的一部分来存储配置文件、映像和日志。与EC2实例不同，S3 bucket本身可以被外部访问。必须设置限制性的IAM策略，以确保内容不会无意中在公有网上被共享。近年来发生了许多令人震惊的攻击，攻击者利用S3 IAM的弱策略来访问客户数据。在混合云中，如果存储在存储桶中的内容被企业导入并信任，攻击还可能导致企业网络的整体瘫痪。其他类似的非VPC服务包括RDS和公共AMI。依靠第三方AMI构成企业EC2实例的基础，成了另一个必须进行安全评估的威胁向量。

证书

管理AWS资源的入口点的是web控制台，如果不能正确保护web控制台或API凭证和权限，攻击者就可能获得AWS帐户内所有资源和数据的控制权，包括设置进一步访问权限，如果是这样，则最初受损的凭据就会被更改并且权限被锁定。这些凭证和权限如果没有得到适当的审查和删除，则离职员工就可以在离开企业后通过互联网对内部服务的命令和控制进行维护。

共享租赁

最后，默认情况下，使用共享的公有云，则意味要与供应商里的其他客户共享此云端资源。但对于许多企业来说，这是不可取的，但并不是每个企业的云端管理者都知道这是默认配置。他们会误认为拥有自己的VPC，则意味着不会与其他客户共享硬件。这种错误的认知，会让攻击者通过虚拟机监控程序或支持云的虚拟机之间共享的硬件发起攻击，通过共享CPU缓存（Meltdown和Spectre）发起的攻击已被证明是行之有效的了。虽然这些漏洞已经得到了大范围的修补，但鉴于现代cpu提供的功能范围越来越广，存在进一步的漏洞是很有可能的。为了缓解这种未知的风险，可以使用专用的EC2实例，这些实例不与其他AWS客户共享一个虚拟机监控程序，但这需要明确配置，以及额外成本。

即使考虑到以上所有这些威胁，云提供商本身仍然拥有对资源的最终控制权。客户需要意识到这一点，并采取尽可能多的预防措施，以防止云提供商的恶意员工访问自己的数据。这包括尽可能使用加密，特别是对于数据存储(如Amazon EBS块存储和snapshots)和S3 BUCKET。