确实，您是对的，任何有权访问服务器的人都可以获得纯文本密钥。

从根本上说，您的应用程序需要能够获得纯文本密钥——因此任何完全破坏应用程序的攻击也将能够获得纯文本密钥。但这不是 KMS 的用途。

KMS 用于密钥管理，特别是密钥的管理、生成、加密和解密。AWS 确实有一个秘密管理器来管理秘密，虽然所有密钥都应该是秘密的，但并非所有秘密都是密钥。

您可以使用 KMS 来：

1. 生成客户主密钥 (CMK)。CMK 在 KMS 中非常特殊，因为它们永远无法以纯文本形式检索。KMS 只能使用 CMK 为您加密/解密明文，但它永远不会泄露 CMK 本身。KMS 将可以使用 CMK 加密/解密的数据量限制在每个请求 4kB 以下。
2. 生成数据密钥 (DK)。DK 可以是任意长度的密钥。当您生成 DK 时，KMS 将为您提供使用特定 CMK（在请求期间指定）加密的纯文本密钥和加密密钥。
3. 管理 CMK。通过允许您控制谁有权使用 CMK、列出一个账户下 KMS 中的所有 CMK 等。
4. 轮换 CMK。默认情况下，所有 CMK 每年轮换一次，但 AWS 永远不会删除 CMK。删除 CMK 是一个繁琐的过程，并且有充分的理由，丢失 CMK 可能会对您的 AWS 资源产生严重影响。
5. 禁用 CMK。如果需要，您可以禁用 CMK，使其无法再使用，并且任何由它加密的 DK 将不再可用。

区分 CMK（永远不会以明文形式显示）和 DK（以明文和加密形式显示）非常重要。CMK 是用于加密另一个密钥的密钥，而 DK 是用于加密数据的密钥。清楚了这个概念，让我们继续前进。

KMS 有什么用？

KMS 可以以安全的方式生成密钥。OWASP 建议使用硬件模块而不是软件来生成密钥，而符合FIPS140-2 的 KMS 可以做到这一点。如果您在软件上手动生成密钥，那不是最好的方法。

此外，大规模生成密钥并非易事。在某些用例中，为每个唯一的消息/事务生成不同的密钥很重要，KMS 提供了一个 API 来精确地做到这一点。

KMS 还将该密钥保密。对称密钥加密的一个困难在于将密钥保密，因此拥有像 KMS 这样的服务，它永远不会公开 CMK，这使得管理变得更简单。

最后，KMS 有助于归档密钥。默认情况下，KMS 永久保留所有 CMK，即使您轮换密钥，您仍然可以在 KMS 中解密旧 DK——只要您没有明确删除旧 CMK。

它对你有什么帮助？

在您的用例中，破坏服务器的攻击者仍然可以访问他们需要的任何内容。所以 KMS 并没有解决这个特定的威胁。

但这将允许您限制仅从相关 EC2 服务器对 KMS 的调用。因此，例如，如果您不小心将包含敏感数据的文件备份到 S3 存储桶中，这将有所帮助，因为数据将被加密，并且在不访问 KMS 上的 CMK 的情况下无法解密。

但是，这可能不是它的主要用例。

KMS 的用例

如果您想要加密备份之类的东西，KMS 非常棒。你在哪里：

1. 备份数据
2. 获取 KMS 为您生成 DK
3. 使用 DK 加密备份，并丢弃纯文本。
4. 将带有加密 DK 的备份数据存储在某处（可能不安全）

当你想恢复时，你只需反转这个过程：

1. 您下载备份，检索加密的 DK
2. 使用 KMS 解密 DK
3. 使用解密后的DK解密数据
4. 访问您的备份！

在此用例中，加密数据存储在根本无法访问 KMS 的服务器上，并且您使用 KMS 来管理密钥。

试用 Secrets Manager

回到您的用例，我可以推荐 AWS Secrets Manager。这是一个更简单的 API，它会被调用并只返回有问题的密钥——这样你的密钥即使以加密形式也不会存储在盒子上。

您的代码将调用 API，获取密钥，完成工作并结束。如果您需要更换密钥，您可以在 Secrets Manager 中集中更改它，然后继续。

Secrets Manager 比 KMS 便宜，并且可以说更易于使用。

如果您的服务器位于 EC2 中，您可以使用 IAM 为该服务器创建一个角色并允许它访问 KMS，而无需在服务器上拥有 AWS 访问密钥。

http://docs.aws.amazon.com/kms/latest/developerguide/control-access.html