gri*_*639 1 security encryption amazon-web-services amazon-rds amazon-kms
我是 AWS 新手。使用的应用程序和数据库都驻留在AWS服务器中。比如说，为了保护静态数据，我使用 KMS 服务加密我的数据库。但应用程序将有权访问密钥，因为应用程序必须访问数据库才能执行操作。那么这是否意味着密钥也驻留在 AWS 服务器中。这是否会反过来造成亚马逊可以访问此密钥或者 AWS 的任何其他客户可以破解此密钥的威胁。
我将首先从您的帖子中讨论一些内容。从您的标题来看，您在使用 RDS 中的数据库的 EC2 服务器上有应用程序代码。我假设您的 EC2 实例使用 EBS 进行存储。
但应用程序将有权访问密钥，因为应用程序必须访问数据库才能执行操作。
从技术上讲，EC2 实例将无权访问 RDS 中的底层数据存储。即使您在 KMS 中使用相同的主密钥，也会使用不同的数据密钥来加密 EC2 实例 EBS 卷和 RDS 卷。当然，现在 RDS 实例具有标准数据连接，允许使用适当的凭据进行访问，但这与我可以“grep”或更改底层数据库文件/内容不同。这只是您用来查询并返回响应的任何数据库所允许的标准连接。当RDS将数据保存到非易失性内存时，底层存储将被加密。
那么这是否意味着密钥也驻留在 AWS 服务器中。
绝对没错。为了让 PaaS（平台即服务）能够处理加密的底层数据，它需要访问加密密钥来读取数据。
与其他事物一样，使用 AWS 也是有风险的。您（可能还有您的组织）需要就您愿意承担的风险级别做出明智的决定，并权衡您使用它的目的（以及您所公开的数据的敏感度级别）。
在加密方面，AWS 允许客户行使多种不同级别的控制权。我一般会在下面从松到紧列出它们。当然，你施加的控制越多，你这边的责任（危险）就越多。
答）AWS 提供的最简单且通常默认的方式是使用亚马逊托管密钥。这些看起来像 aws/ebs 或 aws/rds。在这种情况下，您使用的是 Amazon 创建并完全管理的密钥。但是，由于主密钥是共享的，因此不会对特定密钥的使用进行审核。（当然，在服务发布到 CloudTrail 的范围内，对使用它的资源的访问仍会通过 CloudTrail 进行审核）。对于 KMS，使用信封加密。这意味着虽然“主”密钥可能相同，但主密钥只是加密另一个唯一的加密密钥。例如，使用相同主密钥创建的两个不同的 EBS 卷将具有与数据关联的不同底层加密密钥。
B) 接下来，您可以转向 CMK。您可以在此处进入 KMS 并专门创建一个主密钥（客户主密钥）供您使用。每个主密钥按月收费，尽管它可以加密其下的无数底层密钥。如果您使用亚马逊创建的材料创建它，这意味着 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 固件的更新由多方访问控制控制，该控制由 Amazon 内的独立小组和 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 是否适合您。