从 Capital One 数据泄漏事件看 AWS 安全

Capital One 是谁?

美国资产排名前 10 的综合性银行,靠信用卡业务起家,据最近的财报显示,其信用卡收入超过中国信用卡发行量前三的工商银行、建设银行和招商银行的收入之和。由于其大胆采用新技术,如开源技术、DevOps、微服务、人工智能等技术,在美国独树一帜。从 2014 年开启上云计划,逐步关闭自建数据中心,将所有生产业务迁移至 AWS,也是美国第一家将自己核心业务上云的主流银行,是 AWS 的金融业的标杆客户。

然而最近发生的一起数据泄漏事件,让这家科技银行比较麻烦。

发生了什么?

有人在 Github 页面发现了 Capital One 的敏感数据,报告给了 Capital One,后者发现事情很严重,立即报告给了 FBI,很快非法获取 Capital One 用户数据的嫌疑犯被逮捕。

据 Capital One 的官方声明#1,有近 1亿 信用卡用户隐私数据被泄漏。消息一出,媒体炸锅了,也惊动了美国国会,致信要求解释。

由于 Capital One 的业务均部署在 AWS 上,而且嫌疑人曾经还在亚马逊工作过,自然也免不了被追责,各种猜测都出来了,AWS 又一次面临考验。

不过很快,Capital One 就查明原因,并非常有担当地澄清,此事跟云(AWS)没有什么关系 (原文:“vulnerability is not specific to the cloud”)#2。 AWS向媒体的申明#3 也指出:

AWS was not compromised in any way and functioned as designed. The perpetrator gained access through a misconfiguration of the web application and not the underlying cloud-based infrastructure.
AWS 没有以任何方式受到入侵,一切按设计运行。犯罪者通过错误配置Web应用程序而不是云基础架构获得访问权限。

从西雅图地区法院公布的调查结果#4 和第三方的安全公司分析的情况#5 也印证了这个说法。简单地总结一下就是 Capital One 部署了一个开源的 WAF 服务器,因为 WAF 软件的错误配置,导致这台 WAF 服务器被入侵,而关键致命失误是,这台服务器并没有遵循最基本的安全实践,应该放置在单独的隔离区域,竟然被授予非常高权限的 IAM 角色,以至于这台服务器能够直接获得访问存储在 S3 的机密数据的权限,导致数据泄漏。

事件的影响

Capital One 的用户隐私数据泄漏事件再一次激起了美国公众和政府关于大公司的数据隐私保护的担忧。美国国会参议员 Ron Wyden 针对该事件的吐槽比较反应大家的心声。

一家几十亿美金的公司因为低级的网络安全 (Cybersecurity 101)问题,导致上亿美国人信息被盗取。如果 CEO 不承担后果,是不会对美国人隐私上心的。

他曾经在国会发了一个提案,要求大企业(年收入超过 10亿美金,或者拥有超过 5000万用户)每年向政府提交关于如何保护用户隐私和安全的报告,如果有违背,将负责的 CEO 送上监狱 20 年。美国试图通过立法重罚来降低民众隐私受到侵犯的事件。

简单来讲,企业安全应该领导责任制,出现问题领导担责。对于企业负责人来讲,数据隐私保护和系统安全不再是一个 IT 问题,而是一个严肃的法律问题。

我们从中学到了什么?

通过追溯几个比较了解事件调查过程的博客,我从中发现了几个细节,对于企业安全团队来讲,有助于我们避免类似事情发展。

第一,开启云上的黑匣子。

以往类似的安全事件要么最终也不知道数据是如何泄漏的,要么耗时数月调查才能下结论。而这次事件原因调查相当快,几乎在事件爆发的同时就找到根本原因并及时修复了相关漏洞。

原因是 Capital One 开启了 AWS CloudTrail 服务,迅速通过操作日志定位到问题,及时发现数据泄漏的源头,及能够做到及时精准地修复漏洞。

AWS CloudTrail 相当于飞机的黑匣子,这个服务开启后会自动记录对 AWS 资源的所有操作,能在任何安全事件发生的第一时间找到原因。

如果是在传统数据中心,要想实现全部操作事件能够中心化记录并及时查询和审计,是非常难的一件事件。因为任何事件系统一变更,很难保证日志收集功能联动更新。而在 AWS 环境内,只要启用了 CloudTrail,AWS 体系内任何新增的服务都会自动加入操作日志收集审计。

第二,尽可能使用 AWS 原生托管服务

Capital One 使用了开源 WAF 而没有使用 AWS 原生的 WAF 服务。这个开源的 WAF 是 ModSecurity,作为安全模块嵌入NGINX 或者 Apache Server中使用。据目前已经有的信息来看,暂时不知道是利用了 ModSecurity 的哪个缺陷导致黑客攻陷该服务器,黑客可以利用该缺陷远程执行相关命令,并以该服务器为跳板,下载相关文件。是一种典型的SSRF ( Server-Side Request Forgery,服务器端请求伪造) 攻击,由于没有做好网络的隔离,和合适的权限分配,导致请求直达存储敏感数据的存储服务。

如果 AWS 原生 WAF 服务能够很好的防止此类风险,基于 AWS 的安全责任模型,托管服务的安全由 AWS 负责,如果遇到安全风险,AWS 会第一时间主动修复,而完全无需要用户参与。而自己构建的服务,需要自己负责。

对于安全基础不扎实,或者安全实践能力不够强的团队,尽量减少在云上重复造轮子,是一个比较好的安全实践。

第三,二次加密进一步保护隐私数据

从法院发布的调查报告#4 可以看到一个重要的细节,尽管包含用户信用卡数据的文件泄漏了,但一些关键的信息,包含信用卡卡号,是被二次加密存储了的。此举避免了用户信用卡被盗刷的可能。这是 Capital One 在此次事件中让受影响的用户感到一丝宽慰的地方。

AWS 的安全观

据说 Amazon 姐夫贝索斯,唯一坚持每周跟 AWS 高管团队开会的议题便是安全。

不难理解,安全是 AWS 的立命之本。打江山容易,守江山难。对于姐夫来讲,天下云的江山一半是他的,现在应该最关心的并不是如何取胜,而是如何让自己系统更加安全,堡垒不容易被攻破。

AWS 的安全观中最重要的一个逻辑是把安全分为 2 大领域:

  • Of Cloud:云基础设施及所有 AWS 发布的云服务的安全,由 AWS 负责。
  • In Cloud:在云上客户自己构建的应用或服务的安全,由客户自己负责。AWS 只负责提供详尽的安全工具,但需要客户自己学会如何使用。

对于第一类安全,用户不需要担心,AWS有先进的设计理念,严密的流程,持续不断的改进来保证云的安全。

对于第二类安全,由于 AWS 用户是 100% 拥有自己的数据和应用,因此需要自己对这类安全负责,重点要关注如何充分利用 AWS 的已有的安全服务来增强应用和系统的安全。市场上能提供安全服务和工具的公司太多了,AWS 安全系统和服务到底有什么优势或者差异性,让用户能够完全放心依赖 AWS 的安全能力?

第一,AWS 安全服务是完备的。

你可以不依靠任何第三方安全服务,完全使用 AWS 的安全服务,就能打造出一个无限接近 100% 安全的系统。

AWS 推出了从权限管理、数据安全、网络安全、合规、监控、审计等等几十个安全服务,形成一个完整的安全闭环。传统的安全公司一般会专注于某一个领域做安全工具,因此市场上成百上千家安全公司,每家公司所采用的原则和方法均有所区别,导致市场非常高的学习成本,这也是为什么安全问题一直没有解决的一个很重要原因。

第二,AWS 安全是可编排和可复制的。

传统上我们认为安全是一个无边界的专家问题,像律师一样,只能靠雇佣一群内外部的安全专家,才能够保证自己系统的安全。但是在 AWS 上,安全是一个有限的可遍历的编程问题。AWS 会给你一个确定性的集合,比如每一个 AWS 服务均有一个安全的检查清单(Checklist),比如 #6 #7,当然如果每次新服务上线都需要安全工程师逐一审计这些安全检查清单也是非常不现实的,得益于 AWS 的 Infrastructure as Code 设计原则,利用 AWS CloudFormation 编排服务可以将所有的安全检查都可以比较优雅地编排到你的 DevOps 或者线上业务变更流程中去。

通过合理的安全服务编排,将安全开发和检查完全自动化,极大减少人工安全操作,能无死角地保证公司的每一项安全或者合规性要求都能得到执行,而不影响开发和运维的效率。

第三,AWS 安全是可证明的。

这又是一项 AWS 在安全领域的重要创新,被称为 Provable Security #8。相比第二项所说的,通过自动化编排对安全清单做自动应用或审计,AWS 新设计这套安全系统,可以对所有的安全配置做推理分析。因为往往很多时候安全是隐形的,不是一个是或非的选项,尤其是大量 Policy 代码去定义一套应用的安全逻辑时,这个时候想通过 Checklist 检查安全显然有点力不从心了,通过对系统的权限的 Policy 代码分析和推理,判断出是否有安全风险。有点类似于传统编程领域的代码缺陷分析。

总之,AWS 的安全服务组合的完整性,结合系统的安全自动化机制,和大量的 AWS 云上最佳安全实践,组合起来的综合安全能力是世界上任何一家独立的专业的安全公司所不能匹敌的。

AWS 的最高标准

AWS 虽然无法要求其客户学习 AWS 安全服务,也无法强制要求客户遵循 AWS 最佳安全实践。但对于其生态圈内的合作伙伴,尤其针对AWS 核心级合作伙伴,以及获得AWS MSP 认证过的伙伴光环有云,是有强制性要求的。AWS 要求他的合作伙伴在安全事务上“坚持最高标准”,并且对合作伙伴做定期的安全审计,确保光环有云在服务客户的过程中,严格遵循 AWS 安全规范。

光环有云为客户提供基于 AWS 全生命周期的云安全管理服务,包括安全咨询、安全审计、安全规范建立和实施等服务。在过去4 年,光环有云积累了 100 个多大型企业云上安全保障案例经验,其中包括三星、宝马、西门子、马来西亚石油等 10 多家世界 500 强客户。如果您有安全的需求,通过微信或电话随时与我们联系。