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