AWS S3上傳完整性

Question

我使用S3來備份對我的業務至關重要的大文件。我可以確信，一旦上傳，這些文件的完整性和完整性驗證？

關於可伸縮性和可用性有很多文檔，但我找不到有關完整性和/或校驗和的任何信息。

Answer 1

您可以在本地執行MD5校驗和，然後根據S3上的對象的MD5校驗和來驗證數據完整性。 Here is a guide

Answer 2

當上傳到S3，還有一個可選的請求頭（這在我看來應該不是可選的，但我離題），Content-MD5。如果您將此值設置爲請求正文的MD5散列的base64編碼，S3將在發生不匹配時徹底拒絕您的上載，從而防止上載損壞的數據。

將ETag標頭設置爲對象的單獨部分上傳（某些類型的服務器端加密除外）的對象的十六進制編碼的MD5哈希。

對於分段上傳，Content-MD5標頭設置爲相同的值，但是對於每個部分。

當S3將多部分上傳的部分組合到最終對象中時，ETag頭部設置爲每個部分的級聯二進制編碼（原始字節）MD5散列的十六進制編碼的MD5散列，加上-加上部件數量。

當您要求S3完成多部分上傳的組合部分的最後一步時，您必須將它在上傳原始部分期間提供給您的ETags還原，這應該可以確保S3是結合是你認爲它合併的結果。不幸的是，您可以向S3詢問有關您上傳的部分的API請求，一些懶惰的開發人員只會要求S3列出此列表，然後將其發回給該文檔部門，但是嘿，它「似乎去工作「，對嗎？

5GB以上的對象需要分段上傳，5MB以上的上傳需要分頁上傳。

正確使用，這些功能保證了完整的上傳。

如果您使用的簽名版本4（在舊版區域中也是可選的）還有一個額外的完整性機制，而且這不是可選的（如果您實際使用V4）：上傳必須有請求標頭x-amz-content-sha256 ，設置爲有效負載的十六進制編碼的SHA-256哈希，如果這裏存在不匹配，請求將被拒絕。

我的看法：由於其中一些功能是可選的，因此除非您審覈其代碼，否則您不能相信任何工具都正確執行此操作。

我不信任任何人使用我的數據，所以出於我自己的目的，我編寫了自己的工具，內部稱爲「迂腐上傳器」，它不使用SDK並直接對REST API說話。它計算文件的sha256並將其作爲x-amz-meta-...元數據添加，以便可以將其與對象一起提取以進行比較。當我上傳壓縮文件（gzip/bzip2/xz）時，我將壓縮和未壓縮的sha存儲在元數據中，並且也將壓縮和未壓縮的大小以字節的形式存儲在元數據中。

請注意，Content-MD5和x-amz-content-sha256是請求標題。它們不會在下載時返回。如果您想將此信息保存在對象元數據中，如我在此處所述。

在EC2中，您可以輕鬆下載一個對象，而無需實際將其保存到磁盤中，以驗證其完整性。如果EC2實例與存儲區位於同一區域，則如果您使用具有公共IPv4或IPv6地址，NAT實例，S3 VPC端點或通過IPv6出口網關的實例，則不會收取數據傳輸費用。 （如果您通過NAT網關訪問S3 over IPv4，您將收取NAT網關數據吞吐量的費用）。顯然有辦法自動執行此，但手動，如果您選擇在控制檯中的對象，選擇下載，右鍵單擊它複製到URL，那麼這樣做：

$ curl -v '<url from console>' | md5sum # or sha256sum etc. 

剛剛從控制檯會將網址在單個'的引號中，因爲它將被預先簽名，並且將在查詢字符串中包含&，您不希望shell解釋該字符串。