S3存儲桶數據泄露情況研究
一、S3存儲桶概述
存儲桶(Bucket)是對象的載體，可理解為存放對象的“容器”，且該“容器”無容量上限、對象以扁平化結構存放在存儲桶中，無文件夾和目錄的概念，用戶可選擇將對象存放到單個或多個存儲桶中[1]。由于存儲桶具有擴展性高、存儲速度快、訪問權限可自由配置等優勢，如今已納入各大公有云廠商的關鍵基礎設施中。
Amazon作為全球最大的公有云廠商，其所提供的S3存儲桶服務正在被許多租戶所使用。公有云租戶可根據自身業務需求，定制化地租用S3服務并為S3配置合適的訪問權限，供相關人員進行數據存儲與共享。但正是這一款廣受歡迎的對象存儲服務，近年來卻屢屢曝出數據泄露事件。那么，究竟是什么原因引發了S3存儲桶的數據泄露事件呢？S3存儲桶的數據泄露問題如今是否仍然存在呢？本文將對S3存儲桶的數據泄露事件進行分析，并通過實驗進一步驗證說明當下S3存儲桶存在的數據泄露問題。
二、S3存儲桶數據泄露事件
接下來，讓我們坐上時光列車，一起來看一下近幾年發生的S3存儲桶數據泄露事件。如表1所示。
表1 近五年S3存儲桶數據泄露事件示例
在表1所展示的12個數據泄露事件中，可以發現有10個事件涉及到的S3存儲桶是公開訪問的。這意味著，只要在瀏覽器中輸入了正確的域名，世界上任何人都可以訪問這些數據；另外，有一個事件涉及的存儲桶被設置為允許任何AWS登錄用戶訪問，這看起來似乎比公開訪問更安全些，但事實上，任何人都能夠免費注冊AWS，因此這樣配置的存儲桶安全性并不高；最后，一個醫療數據泄露事件的相關存儲桶竟然被設置為任何人均可讀寫，這是不可想象的。
既然大部分的數據泄露事件是由存儲桶被配置為公開訪問導致的，那我們不妨從S3的訪問權限配置機制出發，來看一下S3存儲桶的數據泄露事件是何種原因導致的。
首先從圖1中可以看到，在S3存儲桶創建過程中，系統有明確的權限配置環節，且默認替用戶勾選了“阻止全部公共訪問權限”選項。
接下來，若要將存儲桶設為公開訪問，先要在“阻止公共訪問權限”標簽頁中取消對“阻止公共訪問權限”的選中狀態，然后進入“訪問控制列表”標簽頁設置“公有訪問權限”，允許所有人“列出對象”，“讀取存儲桶權限”。而且每設置一步，都會有風險提示。具體流程如圖2所示。
而且，就算存儲桶被設置為公開訪問，還需要設置存儲桶內文件的權限。由此看來，Amazon在安全控制方面做得還是不錯的，但是為什么還會不斷有數據泄露事件發生呢？
圖1 S3存儲桶訪問權限說明
圖2 開啟存儲桶公共訪問流程示意圖
有研究者指出[2]，雖然Amazon已經做了不錯的安全控制，但問題的核心在于，有時完全弄清楚某個存儲桶的公開程度是不容易的——雖然已經限制了存儲桶級別的權限，但是桶內文件的訪問權限覆蓋了存儲桶本身的限制。另外，隨著時間的推移，用戶添加的訪問策略可能會越來越復雜，甚至有時出于特殊需要打開了訪問限制，卻忘記了關閉。
總之，S3存儲桶數據泄露風險的主要原因是人為錯誤配置導致的某些存儲桶中的某些敏感信息被公開。
三、S3存儲桶訪問測試實驗
通過上一節的介紹，想必大家對S3存儲桶發生的數據泄露事件及其主要原因已經有所了解。那么本節將通過對S3存儲桶進行訪問測試實驗進一步說明S3存儲桶的數據泄露問題。
從前文的信息中我們可以知道，通過輸入正確的訪問域名可以獲取到S3存儲桶中允許被公開訪問的數據，那么構建出正確的訪問域名便是進行訪問測試的第一步。從Amazon官方給出的信息來看，S3存儲桶的一種訪問域名形式為https://.s3..amazonaws.com/[3]。在這種域名形式下，變量主要有三個，分別為存儲桶名bucket-name，存儲桶所在區域region(可省略)以及文件路徑key-name。筆者對幾家公有云廠商存儲桶進行了訪問測試，與S3存儲桶類似，Microsoft Azure的Blob以及阿里云的OSS訪問路徑中的變量也為上述三者。但不同的是，在對AmazonS3存儲桶進行訪問時，若是一級域名正確，則會返回存儲桶內的文件信息，如圖3所示。此后，根據返回的存儲桶內文件信息，將域名進行拼接，則可獲取存儲桶內文件，如圖4所示。此外，當域名中的region信息錯誤時，訪問后還會返回正確的region信息，如圖5所示。
圖3 通過一級域名獲取文件信息示意圖
圖4 拼接文件名獲取可訪問文件示意圖
圖5 填寫錯誤Region后返回正確Region信息示意圖
綜上，Amazon S3存儲桶的訪問域名變量可縮減到一個——存儲桶名(bucket-name)。
既然S3存儲桶的訪問域名變量可縮減到一個，那么訪問域名的生成問題則可以轉化為存儲桶名的構建問題。根據AWS的官方規定，S3存儲桶的bucket-name是由小寫字母、數字、句號(.)以及連字符(-)組成的3-63位的字符串[4]。全部遍歷需要約39^63次，顯然無法實現。那么便需要對存儲桶的命名規律進行分析，以構建合適的bucket-name。
根據創建存儲桶時的命名習慣，可以做出如下推論：
- 對于某組織或企業的存儲桶，一般會以組織或企業名、簡稱或包含上述信息的字符作為bucket-name；
- 對于某組織或企業下的某產品或某項目，一般會以產品名、項目名、產品或項目名與組織名的拼接或包含上述信息的字符作為bucket-name；
- 對于某個人用戶，一般會以個人姓名、昵稱或包含上述信息的字符作為bucket-name。
基于上述推論，筆者對Yago數據集[5]進行了分析處理，提取出與上述推論相關聯的信息，最終篩選整合出7131個字符作為bucket-name進行域名訪問測試。筆者利用了開源項目S3scanner[6]作為測試掃描器，測試過程如圖6所示。
圖6 通過數據分析批量獲取存儲桶域名
經過訪問測試，最終從7131個bucket-name命中到3482個存活存儲桶。在這3482個存活存儲桶中，有268個是可以公開訪問的，其中還有13個的公開訪問權限被設置為FullControl，可公開訪問的存儲桶數量約占訪問測試總次數的3.7%。此次測試只使用了Yago數據集中的一部分字符，其他符合推論條件的字符約有28萬，從比例預估能夠獲得10000個可以公開訪問的存儲桶。
四、S3存儲桶敏感信息發現
正常情況下，存儲桶所有者在給某一文件配置為可以公開獲取的前提是所有者期望其他人去訪問這些信息且其中不包含敏感信息。但實際情況是這樣么？
筆者對已經發現的268個可以公開訪問的存儲桶中的數據進行了統計分析，具體信息如表2所示。
數據類型 |
