允许公众访问加密文件

Question

公开使用AES-256-GCM加密文件是否足够安全？

我们正在设计一个系统，在该系统中，我们可以安全地授予对来自数千个端点的数百万个文件的访问权限。每个文件使用每个文件唯一的256位密钥使用AES-256-GCM加密。每个文件的名称都是SHA-256哈希的十六进制编码，因此实际上是不可发现的。端点将具有下载后解密文件所需的密钥，所有通信将通过TLS 1.2 +。

我们计划从Azure Blob存储开始将这些文件存储在Azure，AWS和GCP中。在内部，对于允许公众访问这些文件是否安全是有不同意见的。当然，我们将禁止在容器/存储桶上列出，因此，首先有人需要知道文件的确切名称才能下载文件（1 in 2 ^ 256）。如果他们碰巧要下载文件，则需要破解256位密钥来获取内容。我的感觉是这已经足够安全了，但是仍然有一种na的感觉，那就是我们将向公众开放敏感数据（尽管已加密）。

我们非常重视安全性，但是如果我们允许端点直接从云存储中获取文件，而不必通过某种进行身份验证并且具有安全的反向通道访问云存储的中间件，则可以大大提高可伸缩性

还有其他我们需要考虑的设计或建议吗？ 感谢您的帮助。

---

其他信息：

• 文件在上传之前由端点加密，使用256位纯文本哈希（即会聚加密）。这些哈希/密钥保留在端点本身上。
• 文件名为SHA256(SHA256(PlainText))
  • 虽然您可以从理论上使用它来发现是否存在具有特定哈希值的文件，但我们仅存储大小至少为64KiB的文件，因此强行执行发现过程并不现实。
• 使用我们自己的中间件的原因仅仅是因为它与我们现有的模型相匹配，在该模型中，文件存储在中间件后面的本地磁盘上，而不是云存储上。
• 它没有必须公开，但是如果我们不需要添加任何 real 来管理和交换SAS令牌，它将大大简化事情。 em>安全。

Answer 1

如果文件名是纯文本的散列，则此系统很容易问“以下文件是否存在？”如果给定大小的可能文档数量很少，那么我可以SHA-256对所有这些文档进行哈希处理，然后检查是否存在该名称的文件。我不必担心加密步骤。可以通过确保SHA-256文件名是 encrypted 文档的哈希值来解决。这还具有自我认证的优点，并且如果两个文档的内容相同但密钥不同，则可以避免冲突。

您已经在GCM中拥有良好的身份验证。除非通过让访问者在解密之前检查哈希来利用这种冗余身份验证，否则最好使用UUID作为文件名而不是SHA-256。您将获得唯一性，随机性和稀疏性的相同好处，从而降低了计算成本。

决定如何构建此系统很大程度上取决于“数千个端点”的性质。它们是否具有相同的访问权限？要所有文件吗？他们的访问权限会随着时间变化吗？

这很重要，因为您应该将filename + key视为访问令牌，这与通过中间件添加的任何凭据非常相似。如果端点将文件名和密钥存储在一起（这很有可能），那么加密实际上对于访问控制没有多大作用。只是在访问令牌中增加了32个字节。

添加AES-GCM的原因是完整性（验证文件未被修改）以及在静态和传输中的保护。例如，如果有人不小心将存储桶重新配置为允许文件列表，则添加AES-GCM会有所帮助。很好。

所以最后一个问题是添加中间经纪人是否有价值，如果是，那么如何。添加自定义中间件似乎是在不增加太多实际安全性的情况下创建安全性错误的邀请。但是我相信您所描述的所有系统都具有带有共享机密或按端点的凭据的请求身份验证系统。如果它不会对性能产生很大影响，那感觉就像是显而易见的补充。

是否值得一试，对性能的影响取决于它会为您提供多少控制。如果您的端点全部由您控制，并且都共享相同的凭据，那么额外的一层就没什么用。但是，如果他们是第三方，并且您给了每个人自己的证书，那么这是一个很好的工具，可以切断表现不佳（或可能受到损害）的客户。这里的关键是您需要计划如何使用它。仅添加越来越多的层并不能创建更好的安全性。每个图层都需要有一个实际使用的明确目标。

• UUID /加密哈希名称为您提供基本身份验证。 （绝对必要）
• AES-GCM为您提供文件完整性的保证，以及在静止和飞行中的保护。 （可能有用）
• 每个端点身份验证令牌提供控制以拒绝端点。 （但前提是您有撤销访问权限的流程。）
• 自定义中间件提供了添加除云提供商的身份验证之外的其他控件的功能。 （但前提是您要牢记特定的控件。）

Answer 2

您可能会认为它是安全的（至少一段时间），但是它违反了多种安全原则。

1. 分层安全性。
2. 安全性的假设。
3. 跟踪和监视。
4. 密钥管理

我不知道

1. 为什么必须公开？
2. 您为什么不使用称为SAS的共享访问签名。
3. 您如何管理和跟踪密钥？
4. 您有风险分析吗？
5. 您有旋转键的机制吗？
6. 您有B计划吗？

总之，尽管它看起来足够安全，但我不鼓励您这样做。 每种情况都有例外和理由，如果您考虑了所有方面，我将理解。但是我可以肯定这不是最好的选择。
我还会考虑另一种类型的加密，例如混合加密或数字加密。