不幸的是，答案是“视情况而定”。

但首先，我们需要明确 KMS 密钥和 Buckets 是相互独立的，一个 KMS 密钥（称为 CMK）可以绑定到多个 Bucket，一个 Bucket 可以拥有多个 CMK 加密的对象。

其次，由于 KMS 和 S3 之间的紧密集成，我们唯一真正的访问控制是通过密钥授予或 IAM 权限（即，为了在 S3 中获取加密对象，IAM 角色必须具有权限s3:GetObject 和 kms:decrypt）没有获取对象的密钥材料或加密密文并在 AWS 之外执行解密/加密的方法。

现在，哪些因素会使单键或多键策略更适合？

如果您要存储这些数据以供手动检索，则将它们保存在不同的存储桶中非常有意义。桶是免费的，不同的桶可以被不同的桶策略保护，以限制对某些用户/角色的访问。从那里开始，为每个存储桶创建专用 CMK 并不太复杂，从而进一步隔离客户之间的数据。

如果您要存储数据以供多个应用程序访问（每个客户一个），那么为每个客户单独存储桶和 CMK 也是一种不错的方法。通过隔离存储桶和 CMK，您可以将每个客户数据彼此隔离，但更重要的是，还可以保持应用程序隔离。

如果您要存储这些数据以供单个应用程序访问，那么保留多个存储桶会增加开销。根据定义，该应用程序需要访问所有 CMK 和所有存储桶，而对应用程序的妥协将危及所有这些。在这种情况下，我不建议使用多 CMK，因为维护存储桶的额外开销几乎没有带来额外的好处。

除非您的应用程序在登录时向不同的用户授予不同的 IAM 角色。这种情况很少见，因为大多数应用程序都具有应用程序级 IAM 角色，而不是每个用户的 IAM 角色。但是，如果您这样做，则加密一个存储桶使用不同的 KMS 密钥，并为各个 IAM 角色提供密钥授权非常有意义。这是一个相当复杂的领域，如果您的应用程序已经这样做了，您可能不会问这个问题 :)

支持单独密钥的一个论点：假设在未来某个时候，您的应用程序存在某种 SQLInjection 或服务器端请求伪造 (SSRF) 漏洞，该漏洞允许以 CustomerA 身份登录的用户绕过通常的访问控制规则并获取属于给客户 B。

如果所有客户都使用相同的密钥，那么您的应用层服务器将愉快地解密并通过您的 UI 将其返回。但是，如果每个客户都有自己的密钥，那么您的服务器将尝试使用 CustomerA 的密钥解密 CustomerB 的数据并引发解密错误。这将是纵深防守的胜利。

虽然一般来说，使用每个客户的加密密钥并没有多大作用（尤其是如果您将所有密钥存储在同一个地方），但在某些特定情况下它可以节省您的精力。

恕我直言，您应该从成本/收益和风险/缓解方面检查整个事情。

当您将数据存储在非受控存储中时，您将其存储为加密形式。行：

• 风险在于某人（可能是托管服务的工作人员）可以访问数据
• 缓解措施是加密数据
• 成本是在您的服务器上实施加密并维护加密密钥
• 好处是没有密钥就无法读取数据

您现在考虑为每个客户端使用一个密钥。您想要减轻的先前方案未涵盖的风险是什么？有人设法窃取了一把钥匙，但不是所有的钥匙，而它们可能会以相同的方式和相同的地方存储？如果您真的想加强攻击者的任务，您可能需要使用不同的方式来存储和访问密钥，这将代表开发和维护的严重成本。不确定在这里是否值得，除非您发现了不同的风险。

一般来说，当密钥由客户端拥有时，通常会为每个客户端使用不同的密钥。换句话说，当您想要保护客户端数据甚至不受服务器平台管理员的攻击时。它确实具有复杂性成本，但对于高度敏感的数据是必需的。

只是我的建议，但你不应该尝试只使用随机的安全技术，而是真正考虑威胁/风险/缓解......