Encryption best practices for AWS Key Management Service - AWS Prescriptive Guidance

Encryption best practices for AWS Key Management Service

AWS Key Management Service (AWS KMS) helps you create and control cryptographic keys to help protect your data. AWS KMS integrates with most other AWS services that can encrypt your data. For a complete list, see AWS services integrated with AWS KMS. AWS KMS also integrates with AWS CloudTrail to log use of your KMS keys for auditing, regulatory, and compliance needs.

KMS keys are the primary resource in AWS KMS, and they are logical representations of a cryptographic key. There are three primary types of KMS keys:

  • Customer managed keys are KMS keys that you create.

  • AWS managed keys are KMS keys that AWS services create in your account, on your behalf.

  • AWS owned keys are KMS keys that an AWS service owns and manages, for use in multiple AWS accounts.

For more information about these key types, see Customer keys and AWS keys.

In the AWS Cloud, policies are used to control who can access resources and services. For example, in AWS Identity and Access Management (IAM), identity-based policies define permissions for users, user groups, or roles, and resource-based policies attach to a resource, such as an S3 bucket, and define which principals are allowed access, supported actions, and any other conditions that must be met. Similar to IAM policies, AWS KMS uses key policies to control access to a KMS key. Each KMS key must have a key policy, and each key can have only one key policy. Note the following when defining policies that allow or deny access to KMS keys:

  • You can control the key policy for customer managed keys, but you can't directly control the key policy for AWS managed keys or for AWS owned keys.

  • Key policies allow for granting granular access to AWS KMS API calls within an AWS account. Unless the key policy explicitly allows it, you cannot use IAM policies to allow access to a KMS key. Without permission from the key policy, IAM policies that allow permissions have no effect. For more information, see Allow IAM policies to allow access to the KMS key.

  • You can use an IAM policy to deny access to a customer managed key without corresponding permission from the key policy.

  • When designing key policies and IAM policies for multi-Region keys, consider the following:

    • Key policies are not shared properties of multi-Region keys and are not copied or synchronized among related multi-Region keys.

    • When a multi-Region key is created using the CreateKey and ReplicateKey actions, the default key policy is applied unless a key policy is specified in the request.

    • You can implement condition keys, such as aws:RequestedRegion, to limit permissions to a particular AWS Region.

    • You can use grants to allow permissions to a multi-Region primary key or replica key. However, a single grant cannot be used to allow permissions to multiple KMS keys, even if they are related multi-Region keys.

When using AWS KMS and creating key policies, consider the following encryption best practices and other security best practices:

  • Adhere to the recommendations in the following resources for AWS KMS best practices:

  • In accordance with the separation of duties best practice, maintain separate identities for those who administer keys and those who use them:

    • Administrator roles that create and delete keys should not have the ability to use the key.

    • Some services may only need to encrypt data and should not be granted the ability to decrypt the data using the key.

  • Key policies should always follow a model of least privilege. Do not use kms:* for actions in IAM or key policies because this gives the principal permissions to both administer and use the key.

  • Limit the use of customer managed keys to specific AWS services by using the kms:ViaService condition key within the key policy.

  • If you have a choice between key types, customer managed keys are preferred because they provide the most granular control options, including the following:

  • AWS KMS administrative and modification permissions must be explicitly denied to unapproved principals and AWS KMS modification permissions should not exist in an allow statement for any unauthorized principals. For more information, see Actions, resources, and condition keys for AWS Key Management Service.

  • In order to detect unauthorized usage of KMS keys, in AWS Config, implement the iam-customer-policy-blocked-kms-actions and iam-inline-policy-blocked-kms-actions rules. This prevents principals from using the AWS KMS decryption actions on all resources.

  • Implement service control policies (SCPs) in AWS Organizations to prevent unauthorized users or roles from deleting KMS keys, either directly as a command or through the console. For more information, see Using SCPs as preventative controls (AWS blog post).

  • Log AWS KMS API calls in a CloudTrail log. This records the relevant event attributes, such as what requests were made, the source IP address from which the request was made, and who made the request. For more information, see Logging AWS KMS API calls with AWS CloudTrail.

  • If you use encryption context, it shouldn't contain any sensitive information. CloudTrail stores the encryption context in plaintext JSON files, which can be viewed by anyone with access to the S3 bucket containing the information.

  • When monitoring usage of customer managed keys, configure events to notify you if specific actions are detected, such as key creation, updates to customer managed key policies, or import of key material are detected. It's also recommended that you implement automated responses, such as an AWS Lambda function that disables the key or performs any other incident response actions as dictated by your organizational policies.

  • Multi-Region keys are recommended for specific scenarios, such as compliance, disaster recovery, or backups. The security properties of multi-Region keys are significantly different than single-Region keys. The following recommendations apply when authorizing the creation, management, and use of multi-Region keys:

    • Allow principals to replicate a multi-Region key only into AWS Regions that require them.

    • Give permission for multi-Region keys only to principals who need them and only for tasks that require them.