amazon-web-services - AWS S3 上传完整性

Question

我正在使用 S3 备份对我的业务至关重要的大型文件。我能否确信这些文件在上传后已通过完整性验证且完好无损？

有很多关于可伸缩性和可用性的文档，但我找不到任何关于完整性和/或校验和的信息。

Answer 1

当上传到 S3 时，有一个可选的请求 header (我认为它不是是可选的，但我跑题了)，Content-MD5。如果您将此值设置为请求正文的 MD5 哈希的 base64 编码，S3 将在不匹配的情况下完全拒绝您的上传，从而防止上传损坏的数据。

ETag header 将设置为对象的十六进制编码 MD5 哈希值，用于单部分上传(某些类型的服务器端加密除外)。

对于分段上传，Content-MD5 header 设置为相同的值，但对于每个部分。

当 S3 将分段上传的各个部分合并到最终对象中时，ETag header 设置为每个分段的串联二进制编码(原始字节)MD5 哈希的十六进制编码 MD5 哈希部分，加上 - 加上部分的数量。

当您要求 S3 执行合并分段上传的各个部分的最后一步时，您必须将其在原始部分上传期间提供给您的 ETag 还给它，这应该确保 S3 正在合并的内容是你认为它正在结合的东西。不幸的是，有一个 API 请求，你可以向 S3 询问你上传的部分，一些懒惰的开发人员只会向 S3 询问这个列表，然后立即将它发回，这是 documentarion 警告的，但是嘿，它“似乎去工作，”对吧？

超过 5GB 的对象需要分段上传，超过 5MB 的上传可选。

如果使用得当，这些功能可以保证上传完好无损。

如果您使用的是 Signature Version 4，它在较早的地区也是可选的，那么还有一个额外的完整性机制，而这个机制不是可选的(如果您实际上使用的是 V4):上传必须有一个请求 header x-amz-content-sha256，设置为负载的十六进制编码的 SHA-256 哈希值，如果此处也存在不匹配，请求将被拒绝。

我的看法:由于其中一些功能是可选的，除非您审核它们的代码，否则您不能相信任何工具都能正确地执行此操作。

我不信任任何人使用我的数据，因此为了我自己的目的，我编写了自己的实用程序，内部称为“pedantic uploader”，它不使用 SDK 并直接与 REST API 对话。它计算文件的 sha256 并将其添加为 x-amz-meta-... 元数据，以便可以将其与对象一起获取以进行比较。当我上传压缩文件 (gzip/bzip2/xz) 时，我将压缩文件和未压缩文件的 sha 存储在元数据中，并将压缩文件和未压缩文件的大小以八位字节的形式存储在元数据中。

请注意，Content-MD5 和 x-amz-content-sha256 是请求 header 。它们不会随下载返回。如果您想将此信息保存在对象元数据中，如我在此处所述。

在 EC2 中，您可以轻松下载对象而无需将其实际保存到磁盘，只是为了验证其完整性。如果 EC2 实例与存储桶位于同一区域，则如果您使用具有公共(public) IPv4 或 IPv6 地址的实例、NAT 实例、S3 VPC 端点或通过 IPv6 导出网关，则无需支付数据传输费用. (如果您通过 NAT 网关访问基于 IPv4 的 S3，您将需要为 NAT 网关数据吞吐量付费)。显然有一些方法可以自动执行此操作，但是手动操作，如果您在控制台中选择对象，选择下载，右键单击并复制生成的 URL，然后执行以下操作:

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

只需将来自控制台的 URL 包裹在单个 ' 引号中，因为它将被预签名并且将在查询字符串中包含 &，这是您不想要的要解释的 shell。