| 导读 | 由于管理员忘记打开基本的安全控制功能，导致人为错误，是云端数据泄露的主要原因之一。无论你使用的是亚马逊网络服务、微软Azure还是谷歌云平台，请记住本文介绍的这些规则以保护企业的云工作负载。 |
某一天，由于基于云的系统配置错误，又发生了一起数据泄露事件。今年夏天，臭名昭著的Capital One泄露事件就是最突出的一个例子。该泄露事件是由一个配置错误的开源Web应用防火墙(WAF)造成的，这家金融服务公司在其托管在亚马逊网络服务(AWS)上的业务中使用了WAF。
配置错误的WAF显然被允许列出所有AWS数据存储桶中的所有文件，并允许读取每个文件的内容。据安全博客Krebs称，这一错误的配置使得入侵者能够欺骗防火墙，把请求转发到AWS上的一个关键后端资源上。博文解释说，该资源“负责向云服务器分发临时信息，包括从安全服务发送的当前证书，用于访问该服务器可以访问的云中的任何资源”。
此次泄露事件影响了大约1亿美国公民，大约14万个社会保险号码和8万个银行账户号码被盗，最终可能导致Capital One损失高达1.5亿美元。
让我们来看看为什么错误配置仍然是云服务的常见挑战，然后介绍用来降低风险的7种云安全控制举措。
那么，云系统配置错误的问题有多严重呢?Gartner曾经做过估计：到2022年，至少95%的云安全故障都是由客户造成的，原因是错误配置和管理不善。
Gartner称：“挑战不在于云本身的安全性，而在于安全方面的政策和技术，以及对技术的控制。在几乎所有情况下，是用户而不是云提供商未能管理好用于保护企业数据的控件，首席信息官的问题不应该是‘云是否安全?’，而是‘我是否安全地在使用云?’”
有很多因素导致并加剧了配置错误的问题。
在调查的同时，McAfee还检查了数百万云用户和数十亿事件中客户匿名的、汇总的事件数据。数据显示，使用IaaS环境的企业意识到了有错误配置，但更多的是那些没有引起他们注意的错误配置，这之间存在着巨大差距。调查对象表示，他们平均每月能发现37起错误配置事件，但McAfee的客户数据显示，这些企业每月实际发生大约3500起错误配置事件，每年同比增长54%。换句话说，根据McAfee的数据，企业IaaS环境中99%的错误配置都没有被发现。
此外，在不断增长的IaaS市场上，激烈的竞争促使亚马逊、微软和谷歌都在各自的产品中添加了新功能。云安全联盟全球研究副总裁John Yeoh指出：“仅AWS今年就增加了大约1800项功能，而其推出的第一年只有大约28项功能。”因此，对于安全从业人员来说，跟上新特性和功能的快速发展是很大的挑战，而这反过来又会导致错误的配置。Yeoh说：“在复杂的多云环境中，所使用的每一个平台或者服务都应该有相应的专家，以确保采取了适当的安全措施。”
CloudKnox安全公司首席执行官Balaji Parimi指出，此外，云技术最近不断进步，例如，无服务器应用程序和架构、K8s容器化的工作负载和服务，以及越来越多地使用连接各种云服务的应用程序编程接口(API)，等等，如果不采取预防措施，也没有持续监视和调整访问权限，那么，错误配置的可能性会非常高。他补充道，“人们还只是刚刚开始了解这些新的云技术和趋势非常危险的一面。他们往往根据静态角色和有关访问权限的假设，将数十年前的安全方法应用于这些新技术。”
Yeoh指出，关键是：越来越复杂的IT环境使得在整个环境中很难实现简单的安全控制措施，而这些措施有助于发现并防止错误配置问题。
以下介绍的是企业应采用的7种云安全控制举措。
所有云服务都不尽相同，要负的责任也有所不同。软件即服务(SaaS)供应商会确保他们的应用程序受到保护，数据被安全地传输和存储，而IaaS环境并非总是如此。例如，企业应完全负责其AWS弹性计算云(EC2)、亚马逊EBS和亚马逊虚拟私有云(VPC)实例，包括配置操作系统、管理应用程序、保护数据等。
相反，亚马逊维护S3的操作系统和应用程序，而企业负责管理数据、访问控制和身份识别策略。亚马逊提供了为S3数据加密的工具，但这取决于企业在进入和离开服务器时是否启用了保护功能。
应与IaaS供应商仔细核实谁负责每一项云安全控制措施。
企业应控制好谁可以使用他们的云服务。例如，根据Redlock云安全情报(CSI)部门2018年5月的研究，超过一半(51%)的企业意外地暴露了至少一项云存储服务，例如，AWS S3存储驱动器。尽管亚马逊和其他云提供商都警告说，应避免任何有互联网连接的人访问存储驱动器内容。
一般而言，只有负载均衡器和防护主机能够直接出现在互联网上。很多管理员在公共子网中使用0.0.0.0/0，错误地启用了服务器的全局权限。连接完全放开了，每台计算机都能够进行连接。
另一个常见的错误是，允许从互联网直接进行安全(SSH)连接，这意味着任何能找到服务器地址的人都可以绕过防火墙，直接访问数据。2019年，Palo Alto网络公司42威胁研究部在公有云中搜索暴露的服务。在发现的暴露主机和服务中，有32%提供了开放的SSH服务。报告指出：“尽管SSH是最安全的一种协议，但将这项强大的服务暴露给整个互联网还是太危险了。任何错误配置或者存在漏洞/泄漏的证书都可能导致主机被攻破。”
主要云供应商都会提供身份识别和访问控制工具，请使用它们，应知道谁在何时访问了哪些数据。在创建身份识别和访问控制策略时，把最高权限限制在最小范围内，只在需要时临时授予额外权限。尽可能把安全组配置为最窄安全权限，并在可能的情况下使用参考安全组ID。考虑使用CloudKnox之类的工具，这些工具支持企业根据用户活动数据设置访问控制权限。
另一常见的错误是数据没有经过加密便放在了云上。选民信息和敏感的五角大楼文件之所以被泄露，是因为数据没有被加密，未授权方也能够访问服务器。把敏感数据存储在云中而没有对服务器的访问进行适当控制，以便保护数据，这样做是不负责任的，也是危险的。
尽可能控制好加密密钥。虽然可以让云服务供应商提供访问密钥，但保护数据的责任在于企业。
即使云供应商提供了加密工具和管理服务，很多企业实际上并没有使用。加密是一种安全保障措施——即使安全配置失败，数据落入未授权方的手中，他们也不能使用数据。
正如2017年OneLogin泄露事件所展示的，AWS访问密钥被泄露的情况并不少见。这些密钥会出现在公共网站、源代码库、未受保护的K8s仪表板，以及其他一些论坛上。把AWS访问密钥视为最敏感的宝贵资产，教育开发人员避免在公共论坛中泄露此类密钥。
为每一个外部服务创建唯一的密钥，并遵循最小特权原则限制对其访问，确保密钥没有太多的访问权限。密钥如果落在犯罪分子手中，可以用来访问敏感资源和数据。创建IAM角色来分配特殊特权，例如进行API调用。
务必定期轮换密钥，以避免攻击者有时间截获被攻破的密钥，冒充特权用户渗透到云环境中。
不要使用root用户账户，即使是要用于管理任务。使用root用户来创建具有指定权限的新用户。锁定root账户(可以通过添加多重身份验证来实现)，仅用于具体的账户和服务管理任务。对于其他的账户，为用户提供适当的权限。
检查用户账户，查找那些未被使用的账户，并禁用它们。如果没有人使用这些账户，何必给攻击者留下攻击的后门呢。
对于云环境防护，深层防御尤其重要，因为即使一项控制措施失败了，也会有其他安全措施保持应用程序、网络和数据的安全。
MFA在用户名和密码的基础上提供了额外的保护层，使得攻击者很难攻入。应启用MFA，限制对管理控制台、仪表板和特权帐户的访问。
主要云供应商都提供某种级别的日志记录工具，因此一定要启用安全日志记录和监视功能，看看是否有未经授权的访问和其他问题。例如，亚马逊为审查AWS环境提供了CloudTrail，但很多企业并没有使用该服务。当启用后，CloudTrail会记录所有AWS API调用的历史，包括API调用者的身份、调用的时间、调用者的源IP地址、请求参数，以及AWS服务返回的响应数据。它还可以用于变更跟踪、资源管理、安全性分析和合规审查等。
前移方法提倡在开发过程中尽早考虑安全因素，而不是在开发的最后阶段增加安全措施。McAfee的Flaherty说：“企业不仅应该监控IaaS平台上的东西，还应该在平台上线前检查所有进入平台的代码。采用前移方法，能够在潜在的错误配置发展为问题之前进行审核并解决问题。”寻找能够与Jenkins、K8s等其他工具相集成的安全工具，自动审核并更正过程。
不过，Threat Stack公司的首席安全官Sam Bisbee指出，仅有前移方法还不够。Bisbee说：“应该在运行前扫描代码并执行配置检查，但人们往往忘记检查工作负载在投入运行后是否符合要求。如果根据我当时知道的情况，进行了扫描，然后部署我的代码，这样是可以的。但是工作负载会持续运行数月甚至数年，会发现新的漏洞，并且随着时间的推移，代码中的风险也会增加。如果不持续监控，就不会受到保护。”
Bisbee建议，不要像受过培训的很多网络安全专业人员那样，总是去寻找已知的威胁，而是应该努力了解企业完整的基础设施，以及在其上运行的内容。
诚然，在当今日益复杂的多云环境中，这可能是很大的挑战。“但是，要知道某个东西应该是怎样表现的，然后观察它什么时候发生变化，这要比不断地和入侵者进行‘打地鼠游戏’容易得多。如果你非常了解自己的环境，并且知道预期会发生什么，那就能够更有效地检测出错误配置等威胁，并主动补救风险。归根结底，安全在于深度监视，而不是控制。”
原文来自：
本文地址：//q13zd.cn/cloud-security-method.html编辑：王婷，审核员：逄增宝
Linux大全：
Linux系统大全：
