问题描述
我是 AWS 的新手。正在使用的应用程序和数据库都驻留在 AWS 服务器中。比如说，为了保护静态数据，我使用 KMS 服务加密我的数据库。但是应用程序将有权访问密钥，因为应用程序必须访问数据库才能执行操作。所以这并不意味着密钥也驻留在 AWS 服务器中。这不会反过来构成威胁，即亚马逊可以访问此密钥，或者 AWS 的任何其他客户都可以破解此密钥。
解决方法
我将首先从您的帖子中解决一些要素。从您的标题看来，您在使用 RDS 中的数据库的 EC2 服务器上有应用程序代码。我将假设您的 EC2 实例使用 EBS 进行存储。
但是应用程序将可以访问密钥，因为应用程序必须访问数据库才能执行操作。
从技术上讲，EC2 实例将无法访问 RDS 中的底层数据存储。即使您在 KMS 中使用相同的主密钥，也会使用不同的数据密钥来加密 EC2 实例 EBS 卷和 RDS 卷。现在，当然，RDS 实例具有标准数据连接，允许使用适当的凭据进行访问，但这与说我可以“grep”或更改基础数据库文件/内容不同。这只是您用来查询和返回响应的任何数据库所允许的标准连接。当RDS将数据保存到非易失性内存时，底层存储会被加密。
所以这并不意味着密钥也驻留在 AWS 服务器中。
当然，是的。为了让 PaaS（平台即服务）处理加密的底层数据，它需要访问加密密钥来读取数据。
使用 AWS 与其他任何事情一样，存在风险。您（也可能是您的组织）需要就您愿意承担的风险水平做出明智的决定，并权衡您使用它的目的（以及您所公开数据的敏感程度）。
在加密方面，AWS 拥有多种不同级别的控制权，允许客户行使这些控制权。我通常会在下面列出它们，从松到紧。当然，你施加的控制越多，你的责任（危险）就越多。
A) AWS 提供的最简单且通常是默认设置是使用亚马逊托管密钥。这些是看起来像 aws/ebs 或 aws/rds 的那些。在这种情况下，您使用的是 Amazon 创建并完全管理的密钥。但是，由于主密钥是共享的，因此不会对特定密钥的使用进行审核。 （当然，在服务发布到 CloudTrail 的范围内，对使用它的资源的访问仍然使用 CloudTrail 进行审计）。对于 KMS，使用信封加密。这意味着尽管“主”密钥可能相同，但主密钥只是加密另一个唯一的加密密钥。例如，使用相同主密钥创建的两个不同 EBS 卷将具有与数据关联的不同底层加密密钥。
B) 接下来，您可以转移到 CMK。这是您进入 KMS 并专门创建一个主密钥（客户主密钥）供您使用的地方。每个主密钥按月收费，尽管它可以加密其下的无数底层密钥。如果您使用 amazon 创建的材料创建它，这意味着 AWS 将创建密钥（包括底层加密密钥）。它永远不会让您看到底层的加密密钥，这对您来说可能是有利的，也可能是不利的。如果您愿意，可以将其配置为每年自动轮换密钥材料。 CMK 专供您和您的账户使用。默认情况下，它将允许 IAM 策略仅控制对您账户的密钥的访问。它可以是有效的纵深防御。例如，如果有人错误地给出了允许公共访问数据的 S3 存储桶策略，默认情况下，KMS 将只允许授权给 CMK 的已验证用户访问密钥，并有效地拒绝公共访问存储桶中的数据用户。这当然假设数据首先被加密。最后，使用该 CMK 的每个操作都将使用 CloudTrail 进行审计。这使您可以检查加密密钥的使用方式和位置。以下是 KMS 安全常见问题的摘录：
AWS KMS 的设计使包括 AWS 员工在内的任何人都无法从该服务中检索您的明文 CMK。 AWS KMS 使用已根据 FIPS 140-2 验证或正在验证的硬件安全模块 (HSM) 来保护您的密钥的机密性和完整性。无论您是使用 AWS KMS 还是 AWS CloudHSM 创建密钥，还是将密钥材料导入 CMK，您的密钥都存储在这些 HSM 中。您的明文 CMK 永远不会离开 HSM，永远不会写入磁盘，并且只会在执行您请求的加密操作所需的时间内在 HSM 的易失性内存中使用。服务主机上的软件和 AWS KMS HSM 固件的更新由多方访问控制控制，该控制由亚马逊内部的独立小组和 NIST 认证实验室按照 FIPS 140-2 进行审计和审查。
C) 接下来，您可以使用 CMK，但决定不信任 Amazon 来创建加密密钥材料。您可以通过一个稍微复杂但必要的过程安全地传输密钥材料，以确保密钥材料的完整性和机密性。创建 CMK 时，您会创建一个准备好导入密钥材料的密钥的“外壳”。在你这样做之前，密钥不能以任何合理的形式使用。
通常，这与 Amazon 生成的 CMK 具有相同的优点/缺点。但是，有两个值得注意的例外：1) 恢复 - 即使 CMK 在整个选定区域的 AWS 上进行了冗余备份，但如果发生长时间的电力事件（或其他一些灾难）并且 AWS 无法访问您的密钥材料提供，它无法恢复密钥材料。您将需要再次提供密钥材料以加载到 CMK。有一种安全的方法可以做到这一点，但现在您必须小心地控制和保护您身边的密钥材料。您安全地执行此操作的能力可能对基础数据的安全性影响最大。 2) 由于 AWS 假设您正在控制密钥材料，因此它将允许您立即清除 CMK。在 B) 中，由于 CMK 可以控制数十、数百、数千甚至无数的数据元素，如果是错误的，销毁密钥将是一场灾难。为了防止出现这种情况，AWS 永远不会让您立即删除密钥。相反，它会安排要删除的密钥并立即暂停使用该密钥。在任何情况下，删除速度都不能超过 7 天。但是，如果您希望能够使用客户提供的内容立即清除 AWS 密钥 CMK 背后的加密，则不失为一种方法。
D) 如果您想更多地控制在 AWS 中管理加密密钥的方式，您可以使用 CloudHSM。这实际上是您在 AWS 中自己的专用密钥服务器。然而，你在这里失去了重要的东西。尽管您拥有很多控制权，但该服务价格昂贵，而且许多（几乎所有）PaaS 产品都无法与 CloudHSM 配合使用（例如：RDS，尽管我认为 Oracle RDS 可以使用）。我应该注意到，这项服务在 KMS 产品中相对较早，特别是在他们对创建的 KMS 密钥（如 FIPS 认证）做出一些其他保证之前。因此，它没有很好地与其他服务集成，并且在 AWS 产品中看起来像是红头发的继子。我的印象是这是一个小众应用程序，它并没有受到 AWS 的喜爱。这是一个“独自行动”的产品。
E) 您可以使用客户端加密，而不是使用服务器端加密（AWS 可以访问某处存储中的底层加密密钥）。支持这一点的 AWS 服务较少（我知道的唯一一个是 S3）。这类似于 C)，因为您需要为所有加密密钥提供安全性，并在需要底层数据访问时提供它们。
F) 完全脱离网格会在它进入 AWS 之前对其进行加密。当然，这排除了您在 AWS 中使用数据的可能性，例如在 EC2 实例或 RDS 实例中，因为 AWS 无法解码或使用数据。
归根结底，您需要决定什么值得冒险，什么不值得。您的组织如何为您考虑在 AWS 和本地使用的服务创建安全配置？ AWS 方面的成本与控制/妥协的潜力相比如何？这些问题的答案将最终决定 AWS 是否适合您。