下一代企业基础设施——混合云的安全性分析
越来越多的用户将服务转移到云服务中，这其中就包括许多大型企业。随着云端提供服务的基础设施越来越好、成熟度越来越高，许多大型企业已开始将核心业务功能转移给下一代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。
越来越多的用户将服务转移到云服务中，这其中就包括许多大型企业。随着云端提供服务的基础设施越来越好、成熟度越来越高，许多大型企业已开始将核心业务功能转移给下一代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之类的替代通信流来获得对组件的访问。
由于本文旨在强调对混合云和容器部署维护的渗透测试。因此在下文，研究人员将深入探讨企业网络和云之间连接的潜在漏洞。 www.wnhack.com
混合云中的安全性:集成内部系统
上面讲述了环境混合云环境中托管可能出现的一些普遍问题，下文，研究人员将更深入的研究如何将内部系统与混合云集成。
根据混合云的定义，它可以连接组织的内部网络和一个或多个云提供商之间的通信通道。虽然每个云提供商都采用不同的方式提供管理访问，通常通过web管理控制台和API，但本文主要关注Amazon AWS。
内容来自无奈安全网