简介
Amazon S3 [1]是由美国云计算巨头亚马逊(Amazon)推出的一种对象存储服务。服务全称为Simple Storage Service,简称S3,其官方介绍[2]如下:
Amazon Simple Storage Service (Amazon S3) 是一项面向 Internet 的存储服务。您可以通过 Amazon S3 随时在 Web 上的任何位置存储和检索的任意大小的数据。您可以通过 AWS 管理控制台这一简单直观的 Web 界面来完成这些任务。
Amazon S3 将数据存储为存储桶中的对象。对象是一个文件或任何描述该文件的可选元数据。要在 Amazon S3 中存储文件,请将文件上传到存储桶。在将文件作为对象上传时,您可以设置对象以及任何元数据的权限。
存储桶是存储对象的容器。您可以有一个或多个存储桶。您可以控制每个存储桶的访问权限,并决定哪些用户可以在存储桶中创建、删除和列出对象。您还可以选择 Amazon S3 将存储桶及其内容存储到的地理区域,并查看存储桶及其对象的访问日志。
在云原生环境中,Amazon S3也得到了应用[3]。然而,这款流行的存储服务,屡屡被曝光数据泄露事件,不胜枚举。笔者按照时间顺序列出了其中的一部分,供大家了解:
发现时间 | 泄露内容 | 泄露规模 | 数据所属者* | 泄露原因 |
---|---|---|---|---|
2017-06-12 | 选民个人信息 | 超过1.98亿条 | Deep Root Analytics(为美国共和党全国委员会服务)[6] | 公开访问 |
2017-09-06 | 互联网监控数据 | 数十亿条 | 美军中央司令部(CENTCOM)和太平洋司令部(PACOM)[7] | 登录访问 |
2017-09-27 | 虚拟机镜像 | 超过100GB | 美国陆军情报与安全司令部(INSCOM)[8] | 公开访问 |
2018-03-14 | 顾客个人信息 | 超过130万条 | MBM Company(珠宝零售商)[9] | 公开访问 |
2018-08-24 | 医疗、个人信息 | 181家机构,超过3000人 | MedCall Advisors(医疗服务提供商)[10] | 公开读写 |
2019-01-16 | 政府敏感文件、个人信息 | 约3TB | 美国俄克拉荷马州安全部门[11] | 公开访问 |
2019-05-13 | 内部商业文件 | 约1TB | Attunity(数据管理公司)[12] | 公开访问 |
2019-12-09 | 公司敏感信息、个人信息 | 超过1000人 | CHS咨询公司(疑似)[13] | 公开访问 |
2019-12-20 | 敏感文件 | 超过343GB | InMotionNow(项目管理软件公司)(疑似)[14] | 公开访问 |
2019-12-24 | 大麻使用者个人信息 | 超过3万人 | THSuite(业务流程管理软件公司)[15] | 公开访问 |
2020-04-23 | 用户个人信息 | 超过700万条 | BHIM(印度电子支付平台)[16] | 公开访问 |
2020-05-24 | 个人信息、敏感图片和聊天记录 | 超过10万人 | 多款约会应用[17] | 公开访问 |
*数据所属者:这里的「所属者」指的是「数据文件」的上传者和创建者,并非法律法规上的所属关系。
由于其数量之多,网络上甚至已经有相关网页,专门收集、列举Amazon S3数据泄露事件[4][5],感兴趣的读者可以进一步了解。
事件分析
从前文给出的表格中,我们可以看到,在选取的12个数据泄露事件中,有10个事件涉及到的S3存储桶是公开访问的。这意味着,只要在浏览器中输入了正确的URL,世界上任何人都可以访问这些数据;另外,有一个事件涉及的存储桶被设置为允许任何AWS登录用户访问,这看起来似乎比公开访问更安全一些,但是事实上,任何人都能够免费注册AWS,因此这样配置的存储桶的安全性并不高;最后,一个医疗数据泄露事件的相关存储桶竟然被设置为了任何人均可读写(按照相关报告的说法,是“Everyone - Full Control”,即任何人可完全控制),这是不可想象的。
那么,一个很自然的问题是,为什么Amazon S3的数据泄露问题会屡曝不止?也许有的朋友会联想到Redis和MongoDB的未授权访问漏洞,Amazon S3数据泄露难道也是源于不安全的默认配置吗?
不是的。我们一起来看一下。笔者使用AWS账户创建一个S3存储桶:
可以看到,在创建过程中,系统有明确的权限配置环节,且默认已经替用户勾选了「组织全部公共访问权限」选项。并且从上图中我们可以看出,决定对存储桶公共访问权限的机制有三种:
- 访问控制列表(ACL);
- 存储桶策略;
- 接入点策略。
在创建完成后,控制台为管理员明确展示了存储桶的访问权限:
我们创建并上传一个文本文件test_s3.txt,内容为“hello,rambo”:
从详细信息中可以获得该资源的URL:
https://rambo.s3-ap-northeast-1.amazonaws.com/test_s3.txt
其中,https://rambo.s3-ap-northeast-1.amazonaws.com
就是笔者存储桶的地址。
我们尝试访问test_s3.txt文件,失败,响应结果为:
<?xml version="1.0" encoding="UTF-8"?>
<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>114606D2DC0BD51E</RequestId>
<HostId>xxxxxxxxxxxxxxxxxxxxxx</HostId>
</Error>
没有问题,在意料之中。直接访问存储桶也是类似的响应内容。
接下来,让我们把这个存储桶设为公开可访问。经过实践,笔者发现,要想达到任何人都可列出存储桶对象的目的,还颇不容易。首先要在「阻止公共访问权限」标签页中取消对「阻止全部公共访问权限」的选中状态,然后进入「访问控制列表」标签页设置「公有访问权限」,允许所有人「列出对象」、「读取存储桶权限」,如下图所示:
每设置一步,都会有风险提示。设置完成后,就可以匿名访问存储桶了:
<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<Name>rambo</Name>
<Prefix></Prefix>
<Marker></Marker>
<MaxKeys>1000</MaxKeys>
<IsTruncated>false</IsTruncated>
<Contents>
<Key>test_s3.txt</Key>
<LastModified>2020-09-08T06:51:58.000Z</LastModified>
<ETag>xxxxxxxxxxxxxxxxxxxxxxxxxxx</ETag>
<Size>13</Size>
<StorageClass>STANDARD</StorageClass>
</Contents>
</ListBucketResult>
然而,此时我们还是不能访问存储桶内文件,我们还需要设置test_s3.txt文件权限。
综合上面的实践过程来看,笔者认为Amazon在安全控制方面做得还是不错的,甚至感觉到煞费苦心。但是为什么还是会不断有数据泄露事件发生呢?
有研究者指出[18],虽然Amazon已经做了不错的安全控制,但是问题的核心在于,有时完全弄清楚某个存储桶的公开程度是不容易的——虽然已经限制了存储桶级别的权限,但是桶内文件的访问权限覆盖了存储桶本身的限制。另外,随着时间的推移,用户添加的访问策略可能会越来越复杂,甚至有时出于特殊需要打开了访问限制,却忘记了关闭。
总之,安全的薄弱点还是在于人。
总结与思考
Amazon S3屡次被曝出数据泄露事件,这是否说明其自身的安全设计存在一定问题?也许。但是,我们也可以看到,Amazon在不断做出改进。例如,它已经为存储桶添加了一个「阻止公共访问权限」的选项,这将直接从全局限制公共访问,大大提升了安全性。
近年来,世界各国都陆续开始重视数据及隐私安全。欧盟推出了通用数据保护条例(GDPR),我国《数据安全法(草案)》也于2020年7月对外发布。在全球信息化程度不断加深的当下,每个人都必须重视数据安全。对于互联网服务的提供者来说,如何合法合规地提供数据相关服务,已经是生产过程中不容忽视的问题;对于互联网服务的使用者来说,如何确保自己的个人数据安全、不被恶意使用,同样是一个愈加复杂但重要的事情。
当然,发展的过程中难免存在阵痛,更何况信息化带给了我们太多便利。因此,遇到问题解决问题才是正确的态度,因噎废食不可取。
参考文献
- https://aws.amazon.com/cn/s3/
- https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/gsg/GetStartedWithS3.html
- https://aws.amazon.com/cn/products/storage/object-storage-for-cloud-native-applications/
- https://businessinsights.bitdefender.com/worst-amazon-breaches
- https://github.com/nagwww/s3-leaks
- https://www.upguard.com/breaches/the-rnc-files
- https://www.upguard.com/breaches/cloud-leak-centcom
- https://www.upguard.com/breaches/cloud-leak-inscom
- https://web.archive.org/web/20180316234057/https://mackeepersecurity.com/post/walmart-jewelry-partner-exposed-millions-customer-details
- https://www.upguard.com/breaches/how-medical-records-and-patient-doctor-recordings-were-exposed
- https://www.upguard.com/breaches/rsync-oklahoma-securities-commission
- https://www.upguard.com/breaches/attunity-data-leak
- https://www.vpnmentor.com/blog/report-chs-leak/
- https://www.vpnmentor.com/blog/report-multiple-firms-breach/
- https://www.vpnmentor.com/blog/report-thsuite-breach/
- https://www.vpnmentor.com/blog/report-csc-bhim-leak/
- https://www.vpnmentor.com/blog/report-dating-apps-leak/
- https://www.helpnetsecurity.com/2019/09/23/s3-bucket-security/