仅仅将你的本地安全控制迁移到一个全新的云环境是不够的。即使是拥有多年经验的云组织也很脆弱。

随着企业将云服务的使用范围扩大到包括关键业务应用程序和数据，安全漏洞的风险成为了一个C级问题。轻率地将专为内部基础设施和安全控制设计的内部系统迁移到完全不同的云架构，常常是因为没有完全理解云安全的特性、控制、网络设计和用户责任，这将后患无穷。即使像Capital One这样的组织，拥有多年AWS经验、对云技术细微差别有深刻理解的公司，也可能被黑客利用，很明显，每个云用户都需要加倍努力保护自己的安全。值得庆幸的是，有一个像云安全联盟(CSA)这样的组织致力于通过开发策略、建议和威胁研究来提高云环境的安全性。

“作为DEF CON黑客大会的公共化版本，Black Hat 事件已经成为大多数安全厂商和研究人员必须停止的活动。和大多数安全会议一样，会议上也充斥着关于此前未知的软件漏洞的可怕声明、新的攻击方法以及黑客技术的创造性演示。不幸的是，与大多数安全事件一样，黑帽内容的优势描述的是威胁和漏洞，而不是对策和软件修复。CSA遵循脚本使用该事件发布关于云威胁的新报告，但是使用另一份报告进行反击，该报告详细描述了通过将安全性集成到软件开发和IT操作中来改进组织的安全状况的结构改进。”

首先，找出威胁

正如Capital One事件所展示的那样，使用云基础设施和应用程序开辟了新的网络攻击途径，同时通过在云提供商和用户之间分担安全策略的责任，使应用程序和数据安全的责任复杂化。上周的专栏关注的是职责划分，而CSA的一份新报告强调了云计算引入的新威胁载体。

CSA顶级威胁工作组定期发布其对企业云用户面临的最重要安全问题的评估。随着时间的推移，该小组发现传统上对核心基础设施的威胁如拒绝服务攻击或针对硬件和操作系统的漏洞都被云提供商有效的保护起来了，而软件堆栈中更高层次的问题是云用户的责任。CSA发布的一份关于云计算最大威胁的报告指出，

“调查中得分较高的新项目更加细致入微，表明消费者对云的理解已经成熟。这些问题本质上是特定于云的，因此表明了消费者正在积极考虑云迁移的技术前景。这些主题涉及潜在的控制平面弱点、元结构和应用程序结构故障以及有限的云可见性。这一新的重点明显不同于以往更常见的威胁、风险和漏洞(即数据丢失、拒绝服务)，这些在以前的顶级威胁报告中表现得更为突出。”

该工作组使用微软STRIDE威胁模型，分析了六个威胁类别中每个问题的范围和重要性，并将其归纳为19个最突出的云安全威胁。其结果就是该组织所称的“惊人的11个”，按重要性排列如下。

1. 数据泄露，例如Capital One事件，其中“敏感、受保护或机密信息被未经授权的个人发布、查看、窃取或使用”。

2. 错误配置和不充分的变更控制是由设置错误导致的，这些错误使云资源容易受到恶意活动的攻击。”

3.缺乏云安全体系结构和策略，导致IT部门不理解自己在云安全中的角色，或者不小心将现有的内部应用程序迁移到云基础设施，而没有使其适应新的安全环境。

4. 不充分理解云身份和访问管理(IAM)服务和控制以及不充分地保护云凭据，例如频繁地旋转加密密钥、密码和证书，从而导致身份、凭据、访问和密钥管理不足。

5. 通过网络钓鱼攻击或窃取凭证劫持帐户(见#4)。

6. 内部威胁，指某人滥用其对云资源的授权访问，恶意或无意地破坏系统或暴露敏感数据以破坏操作。这些威胁可能来自现任或前任雇员、承包商或可信任的业务伙伴。

7. 不安全的接口和API，其中配置或设计不良的API允许攻击者滥用应用程序或访问数据。正如该报告所详细描述的，面向公众的云系统的接口不断受到攻击，而且，正如Capital One所发现的，它常常是攻击者访问其他内部漏洞的门户。

8. “弱控制平面”就是没有经过深思熟虑的云策略的一个例子，这种策略导致没有充分理解云管理、安全控制和数据流，以及不恰当地使现有流程适应明显不同的环境。

9. 元结构和应用程序结构的失败是由云提供商对API和其他管理接口的弱实现造成的。根据CSA的报告,

元结构被认为是CSP/客户界线，也称为基线。为了提高客户对云的可见性，csp经常公开或允许API与水线上的安全进程进行交互。不成熟的csp常常不确定如何使api对客户可用，以及在多大程度上可用。例如，允许客户检索日志或审计系统访问的api可能包含高度敏感的信息。

虽然不在基线上，但是用于启动服务器端请求伪造(SSRF)的AWS元数据服务是元结构失败的一个例子。

10. 当不完全了解组织内的云使用情况，从而忽略安全问题时，就会出现有限的云使用可视性。当以下两种情况发生时:(a)员工未经IT授权使用云应用程序和/或资源，即影子IT，或(b)授权的内部人员滥用其访问权限(#6)就会出现上述的结果。

11. 滥用和恶意使用云服务，攻击者使用云服务来托管恶意软件或发起攻击，隐藏在云提供商域名的合法性背后。来自云基础设施的威胁通常包括恶意软件存储和传播、DDoS攻击、电子邮件垃圾邮件和钓鱼活动以及自动点击欺诈。

作为CSA的CEO和创始人，Jim Reavis在一次采访中指出，这些安全问题影响着所有类型的云服务，包括SaaS，而不仅仅是像AWS这样的基础设施，

这份报告非常值得一读，因为它详细描述了每种威胁的业务影响和真实世界的例子，以及针对每种威胁的特定云控制(来自CSA的CCM分类)。一份配套文件分析了9起新闻事件，显示了威胁的来源、分类、技术和商业影响，以及本可以阻止或减轻攻击的CCM控制。例如，下面是Zynga数据泄露的总结图表。

将安全性嵌入到应用程序基础结构生命周期中

CSA还发布了一份前瞻性的咨询报告，重点关注通过将安全性集成到应用程序生命周期中来防止云入侵。devsecops的六大支柱建立在DevOps结构和许多组织用于加速软件开发和云部署的实践之上。这篇论文认为，

通过现代集成安全范例(例如DevSecOps)将现有的安全集成到开发和操作流程中，从而将安全性直接放到DevOps中，从而大大提高了结果。目标是减少复杂性的开发和发布软件，确保只有熟悉和信任的组件和服务，使软件开发团队与安全资源(包括自动和人工)直接集成到他们的开发方法中，使用安全可靠的开发环境，最终交付每个设计的最终产品，并且只提供设计时所具有的功能。

该报告来自CSA的DevSecOps工作组，该工作组将自己描述为致力于创建一个透明和全面的管理方法，该方法将开发、安全和操作功能协同地结合到一个内聚的软件生命周期中。该报告定义了DevSecOps的基本特征，进一步推动了CSA的自反安全性策略。后者是一个流程框架，它以一种不增加流程开销并支持对新的和不断变化的威胁做出敏捷响应的方式，在整个组织中集成了安全性。

 根据报告，DevSecOps的六个要素是：

1. 消除竖井式安全组织并使安全成为业务目标不可或缺的集体责任。当CSO(云安全官)领导这项工作时，每个人，无论是业务经理还是IT操作的软件开发人员，都将安全视为他们工作的一部分。

2. 利用集体责任，鼓励泛组织共享关于潜在威胁、系统异常、最佳实践和流程或软件改进信息的协作和集成。

3.务实的实现还试图打破组织竖井，这些竖井通常会创建一个由不兼容的开发工具和利基(niche)组成的大杂烩，指向那些不能很好地协同工作(如果有的话)的产品，并最终创建新的安全漏洞。相反，组织应该选择广泛应用且高度可集成的开发和管理平台。

4. 桥接法规遵循和开发解决了内部安全需求和外部法规遵循规则之间的不匹配，而这些规则常常不一致。要弥补这一差距，需要确定适当的安全控制，将它们转换成代码和流程，这些代码和流程可以合并到软件和操作中，并最终将它们自动化为可重复的操作。

5. 自动化通过用程序控制的配方取代手工操作和容易出错的过程，提高了安全操作的可重复性和速度效率。

6. 估量、监控、报告和行动（MMRA）力求通过定量地度量应用程序和基础设施对安全策略和标准的遵从性，从而消除安全性方面的缺陷，并提高总体覆盖率。

总结

CSA在促进云安全以及建立一套企业在迁移到云基础设施时可以使用的指导方针和审计标准方面发挥了宝贵的作用。它在识别云安全威胁方面的工作虽然有用，但并没有就云用户应该如何应对这些威胁提供明确的方向。从奥迪和控制矩阵将每个威胁映射到相关控制是一个良好的开端，就像CSA的深度报告中的事件案例研究一样，但仍然需要企业自己开发解决方案。希望跟踪威胁报告可以提供预防步骤和示例，这些步骤和示例可以应用于流行的云平台。

DevSecOps同样是模糊和抽象的，但至少提供了企业可以将其集成到IT、软件开发和DevOps组织中以提高云安全性的原则。虽然合并后的术语为已经非常丰富的术语领域添加了不必要的术语，但是必须将安全性融入软件和基础设施部署生命周期的所有部分的概念是无可置疑的。遗憾的是，这也不是什么新鲜事。

在安全问题上，IT似乎决心证明这条公理:“不学习历史的人注定要重蹈覆辙。”不过，随着企业迁移到云基础设施，不安全系统的风险达到天文数字的高度，组织是最终能够吸取教训的。

版权声明：

凡本网内容请注明来源：T媒体（http://www.cniteyes.com）”的所有原创作品，版权均属于易信视界（北京）信息科技有限公司所有，未经本网书面授权，不得转载、摘编或以其它方式使用上述作品。

本网书面授权使用作品的，应在授权范围内使用，并按双方协议注明作品来源。违反上述声明者，易信视界（北京）信息科技有限公司将追究其相关法律责任。