Don*_*gII 5 encryption amazon-s3 amazon-web-services
我有一个应用程序将用于处理一些高度敏感的文档。
目的是通过我的应用程序将这些文档上传到 S3。这些文档也只能由我的应用程序根据需要检索。
正如我所读到的，S3 提供服务器端加密 (SSE)，其中数据分别在上传/下载时透明地加密和解密。
既然如此，这似乎是我对 S3 存储桶进行的任何错误配置，或者如果我的 AWS 凭证遭到泄露，攻击者就可以访问我在 S3 中的所有敏感数据。我知道我应该确保不会错误配置 S3 并保护我的凭据，但我也知道事情会发生。
基本上，据我所知，服务器端加密实际上是一个“勾选框”类型的选项，允许您说您有静态加密，但不能保护您免受最常见的 S3 数据泄漏（存储桶配置错误和信用受到损害）。
言归正传，客户端加密似乎是我的最佳选择。也就是说，我还没有读到很多关于在整个数据生命周期中管理用于在客户端加密数据的密钥的好选择。
我的问题是
Erm*_*ary 10
总而言之：
\nCSE 实际上是在 S3 中存储数据的最安全的方式，前提是您可以保证密钥的安全。
\n使用 CSE，与 SSE 不同，亚马逊本身可以保证永远无法访问私钥，并且无法随时查看/共享您的数据，例如当被迫通过传票时。
\n出于教育目的，理论上最安全的方法是 CSE + SSE-KMS 的 2 层组合加密。这应该只在极端情况下使用，但它最终是在 S3 中存储数据的最安全的方式。
\nCSE + SSE-S3 也不会造成任何损害，因为 SSE-S3 是免费的。
\n更深入的解释：
\n\n\n我对服务器端加密的理解正确吗？
\n
是的，服务器端加密 (SSE) 允许您进行静态加密。
\n但是，使用 SSE 并不一定意味着您无法免受存储桶配置错误或信用受损的影响。
\nSSE 有 3 种类型。
\n它们都有一个共同点，即数据的加密和解密均由 AWS 管理：
\n\xe2\x9c\x85 防止物理访问\n
\n\xe2\x9d\x8c 防止存储桶配置错误\n
\n\xe2\x9d\x8c 防止凭证泄露\n
\n\xe2\x9d\x8c AWS 无法在任何情况下查看您的数据
SSE-S3 至少可以确保，如果有人从 AWS 数据中心盗取了存有您数据的硬盘，您的数据将被加密。
\n任何有权s3:GetObject访问您的对象的 IAM 委托人都能够以未加密的方式读取您的对象，因此，如果有权访问该对象的 AWS 凭证被泄露，任何恶意行为者都将能够访问您文件的解密版本。
使用 SSE-S3 意味着 - 是的，如果您的存储桶配置错误或凭据泄露，恶意行为者就可以访问您未加密的数据。
\n但它并不能保护你。
\n在实践中，更重要的是允许 AWS 遵守安全合规性认证并防止滥用 Amazon 的内部网络和/或物理 S3 基础设施的人员安全（尽管这种情况可能极为罕见）。
\n使用 SSE-S3 的成本为 \xc2\xa30.00，任何加密都比没有好。
\n\xe2\x9c\x85 防止物理访问\n
\n\xe2\x9c\x85 防止存储桶配置错误\n
\n\xe2\x9d\x8c 防止凭证泄露\n
\n\xe2\x9d\x8c AWS 无法在任何情况下查看您的数据
借助 SSE-KMS，您可以获得额外的保护层（KMS 密钥），以防您有一天早上醒来并随机决定向全世界开放您的存储桶。
\n它要求任何想要读取或写入对象的恶意行为者都能够访问该对象和密钥。您必须错误配置您的 S3 权限和 KMS 密钥权限才能意外授予访问权限，而不仅仅是 S3 权限（如 SSE-S3 的情况）。
\n此选项虽然不是免费的，但可以防止存储桶配置错误，但不能防止信用受到损害。
\n您的存储桶可以开放，但任何无法访问 KMS 密钥的人都将获得加密的乱码。
\n仅供参考：AWS KMS 的设计目的是确保任何人（包括 AWS 员工）都无法从服务中检索您的明文密钥。
\n\xe2\x9c\x85 防止物理访问\n
\n\xe2\x9c\x85 防止存储桶配置错误\n
\n\xe2\x9c\x85 防止凭证泄露\n
\n\xe2\x9d\x93 AWS 无法在任何情况下查看您的数据1
SSE-C 可防止存储桶配置错误和 AWS 信用受损。
\n您管理自己的密钥，S3 管理加密和解密过程。您确实需要提供加密密钥作为请求的一部分，但您不需要编写任何代码来执行对象加密或解密。
\n在这种情况下，除了您之外，没有人拥有解锁文件的密钥。
\n您的存储桶可以向任何人开放，并且您的凭据可能会被泄露，以便任何人都能够获取对象。但如果你是唯一拥有解锁文件所需密钥的人，那么任何人都只能得到加密的乱码。
\n虽然此 SSE 选项可以保护您免受存储桶错误配置和信用受损的影响，但您现在还负责保护您的信用、存储桶和密钥（这可以说是一个更大的攻击向量）。
\n1从技术上讲，当您将密钥发送给 Amazon 时，Amazon 在某个时刻可以访问您的密钥，但根据文档，Amazon S3 不会存储您提供的加密密钥。显然，S3 源代码不是开源的，我们不能 100% 保证这一点。如果 AWS 撒谎，我会感到非常惊讶，因为这会影响他们的声誉，但为了正确起见，我会将其标记为不确定。
\n\n\n客户端是我最安全的选择吗？
\n
\xe2\x9c\x85 防止物理访问\n
\n\xe2\x9c\x85 防止存储桶配置错误\n
\n\xe2\x9c\x85 防止凭证泄露\n
\n\xe2\x9c\x85 AWS 无法在任何情况下查看您的数据
对于 S3 存储，客户端加密 (CSE) 比 SSE 更“安全”，因为您可以管理一切。您可以管理加密过程、加密密钥和相关工具，而不是由 AWS 来管理。
\n您在将对象上传到 S3 之前对其进行加密，并且在从 S3 下载对象之后对其进行解密。S3 不知道您如何执行此操作，并且仅存储您的文件。
\n使用 CSE 时，您是最薄弱（或最强）的环节，但就数据安全而言，CSE 比 SSE 更安全。
\n\n\n使用客户端加密时，您建议使用哪些策略/工具来管理密钥？
\n
这是一个非常广泛的问题，但对于 S3 CSE，您有2 个选择：
\n选择哪个选项取决于您对 AWS 的信任程度。
\n使用哪种方法的答案取决于您文件的敏感性以及您对 AWS 的信任程度和/或您保证密钥安全的能力。
\n| 归档时间： |
|
| 查看次数： |
1602 次 |
| 最近记录： |