亚马逊无法访问AWS RDS中数据加密的KMS中使用的密钥吗？
Isn't the key used in KMS in data encryption in AWS RDS accessible to Amazon?
我是 AWS 新手。正在使用的应用程序和数据库都驻留在 AWS 服务器中。比如，为了保护静态数据，我使用 KMS 服务加密我的数据库。但是应用程序将有权访问密钥，因为应用程序必须访问数据库才能执行操作。那么这是否意味着密钥也驻留在 AWS 服务器中。这不会反过来构成威胁，即 Amazon 可以访问此密钥，或者更确切地说，AWS 的任何其他客户都可以破解此密钥。
我将从您的 post 中首先解决一些问题。从您的标题看来，您在使用 RDS 中的数据库的 EC2 服务器上有应用程序代码。我假设您的 EC2 实例正在使用 EBS 进行存储。
But the application will have access to the key, because the application has to access the database to perform operations.
从技术上讲，EC2 实例将无法访问 RDS 中的底层数据存储。即使您在 KMS 中使用相同的主密钥，也会使用不同的数据密钥来加密 EC2 实例 EBS 卷和 RDS 卷。现在，当然，RDS 实例有一个标准的数据连接，允许使用适当的凭据进行访问，但这不同于说我可以 'grep' 或更改基础数据库 files/content。这只是您用来查询和 return 响应的任何数据库所允许的标准连接。当RDS保存数据到non-volatile内存时，底层存储会被加密
So doesn't it imply that key also resides in AWS servers.
当然，是的。为了让 PaaS（平台即服务）使用加密的底层数据，它需要访问加密密钥才能读取数据。
使用 AWS 就像使用任何东西一样存在风险。您（可能还有您的组织）需要就您愿意承担的风险级别做出明智的决定，并权衡您使用它的目的（以及您公开的数据的敏感性级别）。
关于加密，AWS 有许多不同级别的控制，它允许客户行使。我通常会在下面从松到紧列出它们。当然，你施加的控制越多，你这一边的责任（危险）就越多。
A) AWS 提供的最简单且通常默认的是使用亚马逊托管密钥。这些看起来像 aws/ebs 或 aws/rds。在这种情况下，您使用的是亚马逊创建并完全管理的密钥。但是，由于主密钥是共享的，因此无法审计特定密钥的使用情况。 （当然，对使用它的资源的访问仍然会在服务发布到 CloudTrail 的范围内使用 CloudTrail 进行审核）。对于 KMS，使用信封加密。这意味着尽管 'master' 密钥可能相同，但主密钥只是在加密另一个唯一的加密密钥。例如，使用相同主密钥创建的两个不同 EBS 卷将具有与数据关联的不同底层加密密钥。
B) 接下来，您可以转到 CMK。这是您进入 KMS 并专门创建一个主密钥（客户主密钥）供您使用的地方。每个主密钥都有月费，尽管它可以加密其下的无数底层密钥。如果您使用 amazon created material 创建它，这意味着 AWS 将创建密钥（包括底层 cryto 密钥）。它永远不会让你看到底层的加密密钥，这对你来说可能是一个加号或减号。如果您愿意，可以将其配置为每年自动轮换密钥 material。 CMK 专供您和您的账户使用。默认情况下，它将允许 IAM 策略仅控制对您账户的密钥的访问。它可以是一种有效的纵深防御。例如，如果有人错误地提供了允许 public 访问数据的 S3 存储桶策略，默认情况下，KMS 将只允许授权给 CMK 的经过身份验证的用户访问密钥，并有效地拒绝访问数据桶给 public 用户。这当然假设数据首先被加密。最后，使用该 CMK 的每个操作都将使用 CloudTrail 进行审核。这使您可以检查加密密钥的使用方式和使用位置。以下是 KMS 安全常见问题解答的摘录：
AWS KMS is designed so that no one, including AWS employees, can retrieve your plaintext CMKs from the service. AWS KMS uses hardware security modules (HSMs) that have been validated under FIPS 140-2, or are in the process of being validated, to protect the confidentiality and integrity of your keys. Your keys are stored in these HSMs regardless of whether you use AWS KMS or AWS CloudHSM to create your keys or you import key material into a CMK. Your plaintext CMKs never leave the HSMs, are never written to disk, and are only ever used in the volatile memory of the HSMs for the time needed to perform your requested cryptographic operation. Updates to software on the service hosts and to the AWS KMS HSM firmware is controlled by multi-party access control that is audited and reviewed by an independent group within Amazon and a NIST-certified lab in compliance with FIPS 140-2.
C) 接下来，您可以使用 CMK，但决定不信任亚马逊来创建加密密钥 material。您安全地传输密钥 material，通过一个稍微复杂但必要的过程来确保密钥 material 的完整性和机密性。创建 CMK 时，您创建了一个密钥的 'shell'，该密钥已准备好导入密钥 material。在您这样做之前，密钥不能以任何有理形式使用。
通常，这与亚马逊生成的 CMK 具有相同的 pros/cons。但是，有两个值得注意的例外：1) 恢复——即使 CMK 在整个选定区域的 AWS 上进行了冗余备份，但如果发生长时间的电力事件（或其他一些灾难）并且 AWS 无法访问密钥 material 您提供的，它无法恢复密钥 material。您将需要再次提供密钥 material 以加载到 CMK 中。有一种安全的方法可以做到这一点，但现在您必须小心控制和保护您身边的密钥 material。您安全执行此操作的能力可能对基础数据的安全性产生最大影响。 2) 由于 AWS 假设您控制着密钥 material，它将允许您立即清除 CMK。 B)，由于CMK可以控制几十个、几百个、几千个，甚至是无数个数据元ments，销毁密钥是一场灾难，如果它是一个错误。为了防止这种情况，AWS 不会让您立即删除密钥。相反，它将安排删除密钥并立即暂停使用密钥。在任何情况下，删除都不能超过 7 天。但是，如果您希望能够立即清除 AWS 中包含客户提供的内容的密钥 CMK 背后的加密货币，这是可行的方法。
D) 如果您想进一步控制 AWS 中加密密钥的管理方式，您可以使用 CloudHSM。这实际上是您自己在 AWS 中的专用密钥服务器。然而，你在这里失去了重要的东西。尽管您有很多控制权，但服务很昂贵，而且许多（几乎所有）PaaS 产品不能与 CloudHSM 一起使用（例如：RDS，尽管我认为 Oracle RDS 可以）。我应该指出，这项服务在 KMS 产品中相对较早，特别是在他们对创建的 KMS 密钥做出一些其他保证（如 FIPS 认证）之前。因此，它没有很好地与其他服务集成，并且感觉像是 AWS 产品中的 red-headed step-child。我的印象是这是一个小众应用程序，它并没有受到 AWS 的青睐。这是 'go it alone' 产品。
E) 您可以使用 client-side 加密，而不是使用服务器端加密（AWS 可以访问存储在某处的底层加密密钥）。更少的 AWS 服务支持这一点（我知道的唯一一个是 S3）。这与 C) 类似，因为您需要为所有加密密钥提供安全性，并在需要底层数据访问时提供它们。
F) 完全脱离电网会在它进入 AWS 之前对其进行加密。当然，这会阻止您在 AWS 中使用数据，例如在 EC2 实例或 RDS 实例中，因为 AWS 无法解码或使用数据。
归根结底，您需要决定什么值得冒险，什么不值得。与 on-prem 相比，您的组织如何为您考虑在 AWS 上使用的服务创建安全配置？其成本与 AWS 的 control/compromise 潜力相比如何？这些问题的答案将最终决定 AWS 是否适合您。
我是 AWS 新手。正在使用的应用程序和数据库都驻留在 AWS 服务器中。比如，为了保护静态数据，我使用 KMS 服务加密我的数据库。但是应用程序将有权访问密钥，因为应用程序必须访问数据库才能执行操作。那么这是否意味着密钥也驻留在 AWS 服务器中。这不会反过来构成威胁，即 Amazon 可以访问此密钥，或者更确切地说，AWS 的任何其他客户都可以破解此密钥。
我将从您的 post 中首先解决一些问题。从您的标题看来，您在使用 RDS 中的数据库的 EC2 服务器上有应用程序代码。我假设您的 EC2 实例正在使用 EBS 进行存储。
But the application will have access to the key, because the application has to access the database to perform operations.
从技术上讲，EC2 实例将无法访问 RDS 中的底层数据存储。即使您在 KMS 中使用相同的主密钥，也会使用不同的数据密钥来加密 EC2 实例 EBS 卷和 RDS 卷。现在，当然，RDS 实例有一个标准的数据连接，允许使用适当的凭据进行访问，但这不同于说我可以 'grep' 或更改基础数据库 files/content。这只是您用来查询和 return 响应的任何数据库所允许的标准连接。当RDS保存数据到non-volatile内存时，底层存储会被加密
So doesn't it imply that key also resides in AWS servers.
当然，是的。为了让 PaaS（平台即服务）使用加密的底层数据，它需要访问加密密钥才能读取数据。
使用 AWS 就像使用任何东西一样存在风险。您（可能还有您的组织）需要就您愿意承担的风险级别做出明智的决定，并权衡您使用它的目的（以及您公开的数据的敏感性级别）。
关于加密，AWS 有许多不同级别的控制，它允许客户行使。我通常会在下面从松到紧列出它们。当然，你施加的控制越多，你这一边的责任（危险）就越多。
A) AWS 提供的最简单且通常默认的是使用亚马逊托管密钥。这些看起来像 aws/ebs 或 aws/rds。在这种情况下，您使用的是亚马逊创建并完全管理的密钥。但是，由于主密钥是共享的，因此无法审计特定密钥的使用情况。 （当然，对使用它的资源的访问仍然会在服务发布到 CloudTrail 的范围内使用 CloudTrail 进行审核）。对于 KMS，使用信封加密。这意味着尽管 'master' 密钥可能相同，但主密钥只是在加密另一个唯一的加密密钥。例如，使用相同主密钥创建的两个不同 EBS 卷将具有与数据关联的不同底层加密密钥。
B) 接下来，您可以转到 CMK。这是您进入 KMS 并专门创建一个主密钥（客户主密钥）供您使用的地方。每个主密钥都有月费，尽管它可以加密其下的无数底层密钥。如果您使用 amazon created material 创建它，这意味着 AWS 将创建密钥（包括底层 cryto 密钥）。它永远不会让你看到底层的加密密钥，这对你来说可能是一个加号或减号。如果您愿意，可以将其配置为每年自动轮换密钥 material。 CMK 专供您和您的账户使用。默认情况下，它将允许 IAM 策略仅控制对您账户的密钥的访问。它可以是一种有效的纵深防御。例如，如果有人错误地提供了允许 public 访问数据的 S3 存储桶策略，默认情况下，KMS 将只允许授权给 CMK 的经过身份验证的用户访问密钥，并有效地拒绝访问数据桶给 public 用户。这当然假设数据首先被加密。最后，使用该 CMK 的每个操作都将使用 CloudTrail 进行审核。这使您可以检查加密密钥的使用方式和使用位置。以下是 KMS 安全常见问题解答的摘录：
AWS KMS is designed so that no one, including AWS employees, can retrieve your plaintext CMKs from the service. AWS KMS uses hardware security modules (HSMs) that have been validated under FIPS 140-2, or are in the process of being validated, to protect the confidentiality and integrity of your keys. Your keys are stored in these HSMs regardless of whether you use AWS KMS or AWS CloudHSM to create your keys or you import key material into a CMK. Your plaintext CMKs never leave the HSMs, are never written to disk, and are only ever used in the volatile memory of the HSMs for the time needed to perform your requested cryptographic operation. Updates to software on the service hosts and to the AWS KMS HSM firmware is controlled by multi-party access control that is audited and reviewed by an independent group within Amazon and a NIST-certified lab in compliance with FIPS 140-2.
C) 接下来，您可以使用 CMK，但决定不信任亚马逊来创建加密密钥 material。您安全地传输密钥 material，通过一个稍微复杂但必要的过程来确保密钥 material 的完整性和机密性。创建 CMK 时，您创建了一个密钥的 'shell'，该密钥已准备好导入密钥 material。在您这样做之前，密钥不能以任何有理形式使用。
通常，这与亚马逊生成的 CMK 具有相同的 pros/cons。但是，有两个值得注意的例外：1) 恢复——即使 CMK 在整个选定区域的 AWS 上进行了冗余备份，但如果发生长时间的电力事件（或其他一些灾难）并且 AWS 无法访问密钥 material 您提供的，它无法恢复密钥 material。您将需要再次提供密钥 material 以加载到 CMK 中。有一种安全的方法可以做到这一点，但现在您必须小心控制和保护您身边的密钥 material。您安全执行此操作的能力可能对基础数据的安全性产生最大影响。 2) 由于 AWS 假设您控制着密钥 material，它将允许您立即清除 CMK。 B)，由于CMK可以控制几十个、几百个、几千个，甚至是无数个数据元ments，销毁密钥是一场灾难，如果它是一个错误。为了防止这种情况，AWS 不会让您立即删除密钥。相反，它将安排删除密钥并立即暂停使用密钥。在任何情况下，删除都不能超过 7 天。但是，如果您希望能够立即清除 AWS 中包含客户提供的内容的密钥 CMK 背后的加密货币，这是可行的方法。
D) 如果您想进一步控制 AWS 中加密密钥的管理方式，您可以使用 CloudHSM。这实际上是您自己在 AWS 中的专用密钥服务器。然而，你在这里失去了重要的东西。尽管您有很多控制权，但服务很昂贵，而且许多（几乎所有）PaaS 产品不能与 CloudHSM 一起使用（例如：RDS，尽管我认为 Oracle RDS 可以）。我应该指出，这项服务在 KMS 产品中相对较早，特别是在他们对创建的 KMS 密钥做出一些其他保证（如 FIPS 认证）之前。因此，它没有很好地与其他服务集成，并且感觉像是 AWS 产品中的 red-headed step-child。我的印象是这是一个小众应用程序，它并没有受到 AWS 的青睐。这是 'go it alone' 产品。
E) 您可以使用 client-side 加密，而不是使用服务器端加密（AWS 可以访问存储在某处的底层加密密钥）。更少的 AWS 服务支持这一点（我知道的唯一一个是 S3）。这与 C) 类似，因为您需要为所有加密密钥提供安全性，并在需要底层数据访问时提供它们。
F) 完全脱离电网会在它进入 AWS 之前对其进行加密。当然，这会阻止您在 AWS 中使用数据，例如在 EC2 实例或 RDS 实例中，因为 AWS 无法解码或使用数据。
归根结底，您需要决定什么值得冒险，什么不值得。与 on-prem 相比，您的组织如何为您考虑在 AWS 上使用的服务创建安全配置？其成本与 AWS 的 control/compromise 潜力相比如何？这些问题的答案将最终决定 AWS 是否适合您。