# Security of AWS Key Management Service Cloud security at AWS is the highest priority. As an AWS customer, you benefit from a data center and network architecture that are built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security of the cloud and security in the cloud: + **Security *of* the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. Third-party auditors regularly test and verify the effectiveness of our security as part of the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to AWS Key Management Service (AWS KMS), see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). + **Security *in* the cloud** – Your responsibility is determined by the AWS service that you use. In AWS KMS, in addition to your configuration and use of AWS KMS keys, you are responsible for other factors including the sensitivity of your data, your company’s requirements, and applicable laws and regulations This documentation helps you understand how to apply the shared responsibility model when using AWS Key Management Service. It shows you how to configure AWS KMS to meet your security and compliance objectives. **Topics** + [Data protection](data-protection.md) + [Identity and access management](security-iam.md) + [Logging and monitoring](security-logging-monitoring.md) + [Compliance validation](kms-compliance.md) + [Resilience](disaster-recovery-resiliency.md) + [Infrastructure security](infrastructure-security.md) # Data protection in AWS Key Management Service AWS Key Management Service stores and protects your encryption keys to make them highly available while providing you with strong and flexible access control. **Topics** + [Protecting key material](#encryption-key-mgmt) + [Data encryption](#data-encryption) + [Internetwork traffic privacy](#inter-network-privacy) ## Protecting key material By default, AWS KMS generates and protects the cryptographic key material for KMS keys. In addition, AWS KMS offers options for key material that is created and protected outside of AWS KMS. ### Protecting key material generated in AWS KMS When you create a KMS key, by default, AWS KMS generates and protects the cryptographic material for the KMS key. To safeguard key material for KMS keys, AWS KMS relies on a distributed fleet of [FIPS 140-3 Security Level 3–validated](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4884) hardware security modules (HSMs). Each AWS KMS HSM is a dedicated, standalone hardware appliance designed to provide dedicated cryptographic functions to meet the security and scalability requirements of AWS KMS. (The HSMs that AWS KMS uses in China Regions are certified by [OSCCA](https://www.oscca.gov.cn/) and comply with all pertinent Chinese regulations, but are not validated under the FIPS 140-3 Cryptographic Module Validation Program.) The key material for a KMS key is encrypted by default when it is generated in the HSM. The key material is decrypted only within HSM volatile memory and only for the few milliseconds that it takes to use it in a cryptographic operation. Whenever the key material is not in active use, it is encrypted within the HSM and transferred to [highly durable](https://docs.aws.amazon.com/kms/latest/cryptographic-details/durability-protection.html) (99.999999999%), low-latency persistent storage where it remains separate and isolated from the HSMs. Plaintext key material never leaves the HSM [security boundary](https://docs.aws.amazon.com/kms/latest/cryptographic-details/internal-communication-security.html#hsm-security-boundary); it is never written to disk or persisted in any storage medium. (The only exception is the public key of an asymmetric key pair, which is not secret.) AWS asserts as a fundamental security principle that there is no human interaction with plaintext cryptographic key material of any type in any AWS service. There is no mechanism for anyone, including AWS service operators, to view, access, or export plaintext key material. This principle applies even during catastrophic failures and disaster recovery events. Plaintext customer key material in AWS KMS is used for cryptographic operations within AWS KMS FIPS 140-3 validated HSMs only in response to authorized requests made to the service by the customer or their delegate. For [customer managed keys](concepts.md#customer-mgn-key), the AWS account that creates the key is the sole and non-transferable owner of the key. The owning account has complete and exclusive control over the authorization policies that control access to the key. For AWS managed keys, the AWS account has complete control over the IAM policies that authorize requests to the AWS service. ### Protecting key material generated outside of AWS KMS AWS KMS provides alternatives to key material generated in AWS KMS. [Custom key stores](key-store-overview.md#custom-key-store-overview), an optional AWS KMS feature, let you create KMS keys backed by key material that is generated and used outside of AWS KMS. KMS keys in [AWS CloudHSM key stores](keystore-cloudhsm.md) are backed by keys in AWS CloudHSM hardware security modules that you control. These HSMs are certified at [FIPS 140-2 Security Level 3 or 140-3 Security Level 3](https://docs.aws.amazon.com/cloudhsm/latest/userguide/compliance.html). KMS keys in [external key stores](keystore-external.md) are backed by keys in an external key manager that you control and manage outside of AWS, such as a physical HSM in your private data center. Another optional feature lets you [import the key material](importing-keys.md) for a KMS key. To protect imported key material while it is in transit to AWS KMS, you encrypt the key material using a public key from an RSA key pair generated in an AWS KMS HSM. The imported key material is decrypted in an AWS KMS HSM and re-encrypted under a symmetric key in the HSM. Like all AWS KMS key material, plaintext imported key material never leaves the HSMs unencrypted. However, the customer who provided the key material is responsible for secure use, durability, and maintenance of the key material outside of AWS KMS. ## Data encryption The data in AWS KMS consists of AWS KMS keys and the encryption key material they represent. This key material exists in plaintext only within AWS KMS hardware security modules (HSMs) and only when in use. Otherwise, the key material is encrypted and stored in durable persistent storage. The key material that AWS KMS generates for KMS keys never leaves the boundary of AWS KMS HSMs unencrypted. It is not exported or transmitted in any AWS KMS API operations. The exception is for [multi-Region keys](multi-region-keys-overview.md), where AWS KMS uses a cross-Region replication mechanism to copy the key material for a multi-Region key from an HSM in one AWS Region to an HSM in a different AWS Region. For details, see [Replication process for multi-Region keys](https://docs.aws.amazon.com/kms/latest/cryptographic-details/replicate-key-details.html) in AWS Key Management Service Cryptographic Details. **Topics** + [Encryption at rest](#encryption-at-rest) + [Encryption in transit](#encryption-in-transit) ### Encryption at rest AWS KMS generates key material for AWS KMS keys in [FIPS 140-3 Security Level 3](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4884)–compliant hardware security modules (HSMs). The only exception is China Regions, where the HSMs that AWS KMS uses to generate KMS keys comply with all pertinent Chinese regulations, but are not validated under the FIPS 140-3 Cryptographic Module Validation Program. When not in use, key material is encrypted by an HSM key and written to durable, persistent storage. The key material for KMS keys and the encryption keys that protect the key material never leave the HSMs in plaintext form. Encryption and management of key material for KMS keys is handled entirely by AWS KMS. For more details, see [Working with AWS KMS keys](https://docs.aws.amazon.com/kms/latest/cryptographic-details/kms-keys.html) in AWS Key Management Service Cryptographic Details. ### Encryption in transit Key material that AWS KMS generates for KMS keys is never exported or transmitted in AWS KMS API operations. AWS KMS uses [key identifiers](concepts.md#key-id) to represent the KMS keys in API operations. Similarly, key material for KMS keys in AWS KMS [custom key stores](key-store-overview.md#custom-key-store-overview) is non-exportable and never transmitted in AWS KMS or AWS CloudHSM API operations. However, some AWS KMS API operations return [data keys](data-keys.md). Also, customers can use API operations to [import key material](importing-keys.md) for selected KMS keys. All AWS KMS API calls must be signed and transmitted using Transport Layer Security (TLS). AWS KMS requires TLS 1.2 and recommends TLS 1.3 in all regions. AWS KMS also supports hybrid post-quantum TLS for AWS KMS service endpoints in all regions, except China Regions. AWS KMS does not support hybrid post-quantum TLS for FIPS endpoints in AWS GovCloud (US). Calls to AWS KMS also require a modern cipher suite that supports *perfect forward secrecy*, which means that compromise of any secret, such as a private key, does not also compromise the session key. If you require FIPS 140-3 validated cryptographic modules when accessing AWS through a command line interface or an API, use a FIPS endpoint. To use standard AWS KMS endpoints or AWS KMS FIPS endpoints, clients must support TLS 1.2 or later. For more information about the available FIPS endpoints, see [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/). For a list of AWS KMS FIPS endpoints, see [AWS Key Management Service endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/kms.html) in the AWS General Reference. Communications between AWS KMS service hosts and HSMs are protected using Elliptic Curve Cryptography (ECC) and Advanced Encryption Standard (AES) in an authenticated encryption scheme. For more details, see [Internal communication security](https://docs.aws.amazon.com/kms/latest/cryptographic-details/internal-communication-security.html) in AWS Key Management Service Cryptographic Details. ## Internetwork traffic privacy AWS KMS supports an AWS Management Console and a set of API operations that enable you to create and manage AWS KMS keys and use them in cryptographic operations. AWS KMS supports two network connectivity options from your private network to AWS. + An IPSec VPN connection over the internet + [AWS Direct Connect](https://aws.amazon.com/directconnect/), which links your internal network to an Direct Connect location over a standard Ethernet fiber-optic cable. All AWS KMS API calls must be signed and be transmitted using Transport Layer Security (TLS). The calls also require a modern cipher suite that supports [perfect forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy). Traffic to the hardware security modules (HSMs) that store key material for KMS keys is permitted only from known AWS KMS API hosts over the AWS internal network. To connect directly to AWS KMS from your virtual private cloud (VPC) without sending traffic over the public internet, use VPC endpoints, powered by [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/). For more information, see [Connect to AWS KMS through a VPC endpoint](kms-vpc-endpoint.md). AWS KMS also supports a [hybrid post-quantum key exchange](pqtls.md) option for the Transport Layer Security (TLS) network encryption protocol. You can use this option with TLS when you connect to AWS KMS API endpoints. # Identity and access management for AWS Key Management Service AWS Identity and Access Management (IAM) helps you securely control access to AWS resources. Administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use AWS KMS resources. For more information, see [Using IAM policies with AWS KMS](iam-policies.md). [Key policies](key-policies.md) are the primary mechanism for controlling access to KMS keys in AWS KMS. Every KMS key must have a key policy. You can also use [IAM policies](iam-policies.md) and [grants](grants.md), along with key policies, to control access to your KMS keys. For more information, see [KMS key access and permissions](control-access.md). If you are using an Amazon Virtual Private Cloud (Amazon VPC), you can [create an interface VPC endpoint](kms-vpc-endpoint.md) to AWS KMS powered by [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/). You can also use VPC endpoint policies to determine which principals can access your AWS KMS endpoint, which API calls they can make, and which KMS key they can access. **Topics** + [AWS managed policies for AWS Key Management Service](security-iam-awsmanpol.md) + [Using service-linked roles for AWS KMS](using-service-linked-roles.md) # AWS managed policies for AWS Key Management Service An AWS managed policy is a standalone policy that is created and administered by AWS. AWS managed policies are designed to provide permissions for many common use cases so that you can start assigning permissions to users, groups, and roles. Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [ customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases. You cannot change the permissions defined in AWS managed policies. If AWS updates the permissions defined in an AWS managed policy, the update affects all principal identities (users, groups, and roles) that the policy is attached to. AWS is most likely to update an AWS managed policy when a new AWS service is launched or new API operations become available for existing services. For more information, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. ## AWS managed policy: AWSKeyManagementServicePowerUser You can attach the `AWSKeyManagementServicePowerUser` policy to your IAM identities. You can use the `AWSKeyManagementServicePowerUser` managed policy to give IAM principals in your account the permissions of a power user. Power users can create KMS keys, use and manage the KMS keys they create, and view all KMS keys and IAM identities. Principals who have the `AWSKeyManagementServicePowerUser` managed policy can also get permissions from other sources, including key policies, other IAM policies, and grants. `AWSKeyManagementServicePowerUser` is an AWS managed IAM policy. For more information about AWS managed policies, see [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. **Note** Permissions in this policy that are specific to a KMS key, such as `kms:TagResource` and `kms:GetKeyRotationStatus`, are effective only when the key policy for that KMS key [explicitly allows the AWS account to use IAM policies](key-policy-default.md#key-policy-default-allow-root-enable-iam) to control access to the key. To determine whether a permission is specific to a KMS key, see [AWS KMS permissions](kms-api-permissions-reference.md) and look for a value of **KMS key** in the **Resources** column. This policy gives a power user permissions on any KMS key with a key policy that permits the operation. For cross-account permissions, such as `kms:DescribeKey` and `kms:ListGrants`, this might include KMS keys in untrusted AWS accounts. For details, see [Best practices for IAM policies](iam-policies-best-practices.md) and [Allowing users in other accounts to use a KMS key](key-policy-modifying-external-accounts.md). To determine whether a permission is valid on KMS keys in other accounts, see [AWS KMS permissions](kms-api-permissions-reference.md) and look for a value of **Yes** in the **Cross-account use** column. To allow principals to view the AWS KMS console without errors, the principal needs the [tag:GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) permission, which is not included in the `AWSKeyManagementServicePowerUser` policy. You can allow this permission in a separate IAM policy. The [AWSKeyManagementServicePowerUser](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AWSKeyManagementServicePowerUser) managed IAM policy includes the following permissions. + Allows principals to create KMS keys. Because this process includes setting the key policy, power users can give themselves and others permission to use and manage the KMS keys they create. + Allows principals to create and delete [aliases](kms-alias.md) and [tags](tagging-keys.md) on all KMS keys. Changing a tag or alias can allow or deny permission to use and manage the KMS key. For details, see [ABAC for AWS KMS](abac.md). + Allows principals to get detailed information about all KMS keys, including their key ARN, cryptographic configuration, key policy, aliases, tags, and [rotation status](rotate-keys.md). + Allows principals to list IAM users, groups, and roles. + This policy does not allow principals to use or manage KMS keys that they didn't create. However, they can change aliases and tags on all KMS keys, which might allow or deny them permission to use or manage a KMS key. To view the permissions for this policy, see [AWSKeyManagementServicePowerUser](https://docs.aws.amazon.com//aws-managed-policy/latest/reference/AWSKeyManagementServicePowerUser.html) in the AWS Managed Policy Reference. ## AWS managed policy: AWSServiceRoleForKeyManagementServiceCustomKeyStores You can't attach `AWSServiceRoleForKeyManagementServiceCustomKeyStores` to your IAM entities. This policy is attached to a service-linked role that gives AWS KMS permission to view the AWS CloudHSM clusters associated with your AWS CloudHSM key store and create the network to support a connection between your custom key store and its AWS CloudHSM cluster. For more information, see [Authorizing AWS KMS to manage AWS CloudHSM and Amazon EC2 resources](authorize-kms.md). ## AWS managed policy: AWSServiceRoleForKeyManagementServiceMultiRegionKeys You can't attach `AWSServiceRoleForKeyManagementServiceMultiRegionKeys` to your IAM entities. This policy is attached to a service-linked role that gives AWS KMS permission to synchronize any changes to the key material of a multi-Region primary key to its replica keys. For more information, see [Authorizing AWS KMS to synchronize multi-Region keys](multi-region-auth-slr.md). ## AWS KMS updates to AWS managed policies View details about updates to AWS managed policies for AWS KMS since this service began tracking these changes. For automatic alerts about changes to this page, subscribe to the RSS feed on the AWS KMS [Document history](dochistory.md) page. | Change | Description | Date | | --- | --- | --- | | [AWSKeyManagementServiceMultiRegionKeysServiceRolePolicy](multi-region-auth-slr.md) – Update to existing policy | AWS KMS added a statement ID (`Sid`) field to the managed policy in policy version v2. | November 21, 2024 | | [AWSKeyManagementServiceCustomKeyStoresServiceRolePolicy](authorize-kms.md) – Update to existing policy | AWS KMS added the `ec2:DescribeVpcs`, `ec2:DescribeNetworkAcls`, and `ec2:DescribeNetworkInterfaces` permissions to monitor changes in the VPC that contains your AWS CloudHSM cluster so that AWS KMS can provide clear error messages in the case of failures. | November 10, 2023 | | AWS KMS started tracking changes | AWS KMS started tracking changes for its AWS managed policies. | November 10, 2023 | # Using service-linked roles for AWS KMS AWS Key Management Service uses AWS Identity and Access Management (IAM)[ service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role). A service-linked role is a unique type of IAM role that is linked directly to AWS KMS. Service-linked roles are defined by AWS KMS and include all the permissions that the service requires to call other AWS services on your behalf. A service-linked role makes setting up AWS KMS easier because you don’t have to manually add the necessary permissions. AWS KMS defines the permissions of its service-linked roles, and unless defined otherwise, only AWS KMS can assume its roles. The defined permissions include the trust policy and the permissions policy, and that permissions policy cannot be attached to any other IAM entity. You can delete a service-linked role only after first deleting the related resources. This protects your AWS KMS resources because you can't inadvertently remove permission to access the resources. For information about other services that support service-linked roles, see [AWS Services That Work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) and look for the services that have **Yes **in the **Service-Linked Role** column. Choose a **Yes** with a link to view the service-linked role documentation for that service. To view details about updates to the service-linked roles discussed in this topic, see [AWS KMS updates to AWS managed policies](security-iam-awsmanpol.md#security-iam-awsmanpol-updates). **Topics** + [Authorizing AWS KMS to manage AWS CloudHSM and Amazon EC2 resources](authorize-kms.md) + [Authorizing AWS KMS to synchronize multi-Region keys](multi-region-auth-slr.md) # Authorizing AWS KMS to manage AWS CloudHSM and Amazon EC2 resources To support your AWS CloudHSM key stores, AWS KMS needs permission to get information about your AWS CloudHSM clusters. It also needs permission to create the network infrastructure that connects your AWS CloudHSM key store to its AWS CloudHSM cluster. To get these permissions, AWS KMS creates the **AWSServiceRoleForKeyManagementServiceCustomKeyStores** service-linked role in your AWS account. Users who create AWS CloudHSM key stores must have the `iam:CreateServiceLinkedRole` permission that allows them to create service-linked roles. To view details about updates to the **AWSKeyManagementServiceCustomKeyStoresServiceRolePolicy** managed policy, see [AWS KMS updates to AWS managed policies](security-iam-awsmanpol.md#security-iam-awsmanpol-updates). **Topics** + [About the AWS KMS service-linked role](#about-key-store-slr) + [Create the service-linked role](#create-key-store-slr) + [Edit the service-linked role description](#edit-key-store-slr) + [Delete the service-linked role](#delete-key-store-slr) ## About the AWS KMS service-linked role A [service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) is an IAM role that gives one AWS service permission to call other AWS services on your behalf. It's designed to make it easier for you to use the features of multiple integrated AWS services without having to create and maintain complex IAM policies. For more information, see [Using service-linked roles for AWS KMS](using-service-linked-roles.md). For AWS CloudHSM key stores, AWS KMS creates the **AWSServiceRoleForKeyManagementServiceCustomKeyStores** service-linked role with the **AWSKeyManagementServiceCustomKeyStoresServiceRolePolicy** managed policy. This policy grants the role the following permissions: + [cloudhsm:Describe\$1](https://docs.aws.amazon.com/cloudhsm/latest/APIReference/API_DescribeClusters.html) – detects changes in the AWS CloudHSM cluster that is attached to your custom key store. + [ec2:CreateSecurityGroup](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateSecurityGroup.html) – used when you [connect an AWS CloudHSM key store](connect-keystore.md) to create the security group that enables network traffic flow between AWS KMS and your AWS CloudHSM cluster. + [ec2:AuthorizeSecurityGroupIngress](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AuthorizeSecurityGroupIngress.html) – used when you [connect an AWS CloudHSM key store](connect-keystore.md) to allow network access from AWS KMS into the VPC that contains your AWS CloudHSM cluster. + [ec2:CreateNetworkInterface](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateNetworkInterface.html) – used when you [connect an AWS CloudHSM key store](connect-keystore.md) to create the network interface used for communication between AWS KMS and the AWS CloudHSM cluster. + [ec2:RevokeSecurityGroupEgress](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RevokeSecurityGroupEgress.html) – used when you [connect an AWS CloudHSM key store](connect-keystore.md) to remove all outbound rules from the security group that AWS KMS created. + [ec2:DeleteSecurityGroup](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DeleteSecurityGroup.html) – used when you [disconnect an AWS CloudHSM key store](disconnect-keystore.md) to delete security groups that were created when you connected the AWS CloudHSM key store. + [ec2:DescribeSecurityGroups](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeSecurityGroups.html) – used to monitor changes in the security group that AWS KMS created in the VPC that contains your AWS CloudHSM cluster so that AWS KMS can provide clear error messages in case of failures. + [ec2:DescribeVpcs](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeVpcs.html) – used to monitor changes in the VPC that contains your AWS CloudHSM cluster so that AWS KMS can provide clear error messages in case of failures. + [ec2:DescribeNetworkAcls](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkAcls.html) – used to monitor changes in the network ACLs for the VPC that contains your AWS CloudHSM cluster so that AWS KMS can provide clear error messages in case of failures. + [ec2:DescribeNetworkInterfaces](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeNetworkInterfaces.html) – used to monitor changes in the network interfaces that AWS KMS created in the VPC that contains your AWS CloudHSM cluster so that AWS KMS can provide clear error messages in case of failures. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "cloudhsm:Describe*", "ec2:CreateNetworkInterface", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateSecurityGroup", "ec2:DescribeSecurityGroups", "ec2:RevokeSecurityGroupEgress", "ec2:DeleteSecurityGroup", "ec2:DescribeVpcs", "ec2:DescribeNetworkAcls", "ec2:DescribeNetworkInterfaces" ], "Resource": "*" } ] } ``` ------ Because the **AWSServiceRoleForKeyManagementServiceCustomKeyStores** service-linked role trusts only `cks.kms.amazonaws.com`, only AWS KMS can assume this service-linked role. This role is limited to the operations that AWS KMS needs to view your AWS CloudHSM clusters and to connect an AWS CloudHSM key store to its associated AWS CloudHSM cluster. It does not give AWS KMS any additional permissions. For example, AWS KMS does not have permission to create, manage, or delete your AWS CloudHSM clusters, HSMs, or backups. **Regions** Like the AWS CloudHSM key stores feature, the **AWSServiceRoleForKeyManagementServiceCustomKeyStores** role is supported in all AWS Regions where AWS KMS and AWS CloudHSM are available. For a list of AWS Regions that each service supports, see [AWS Key Management Service Endpoints and Quotas](https://docs.aws.amazon.com/general/latest/gr/kms.html) and [AWS CloudHSM endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/cloudhsm.html) in the *Amazon Web Services General Reference*. For more information about how AWS services use service-linked roles, see [Using service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) in the IAM User Guide. ## Create the service-linked role AWS KMS automatically creates the **AWSServiceRoleForKeyManagementServiceCustomKeyStores** service-linked role in your AWS account when you create an AWS CloudHSM key store, if the role does not already exist. You cannot create or re-create this service-linked role directly. ## Edit the service-linked role description You cannot edit the role name or the policy statements in the **AWSServiceRoleForKeyManagementServiceCustomKeyStores** service-linked role, but you can edit role description. For instructions, see [Editing a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ## Delete the service-linked role AWS KMS does not delete the **AWSServiceRoleForKeyManagementServiceCustomKeyStores** service-linked role from your AWS account even if you have [deleted all of your AWS CloudHSM key stores](delete-keystore.md). Although there is currently no procedure for deleting the **AWSServiceRoleForKeyManagementServiceCustomKeyStores** service-linked role, AWS KMS does not assume this role or use its permissions unless you have active AWS CloudHSM key stores. # Authorizing AWS KMS to synchronize multi-Region keys To support [multi-Region keys](multi-region-keys-auth.md), AWS KMS needs permission to synchronize the [shared properties](multi-region-keys-overview.md#mrk-sync-properties) of a multi-Region primary key with its replica keys. To get these permissions, AWS KMS creates the **AWSServiceRoleForKeyManagementServiceMultiRegionKeys** service-linked role in your AWS account. Users who create multi-Region keys must have the `iam:CreateServiceLinkedRole` permission that allows them to create service-linked roles. You can view the [SynchronizeMultiRegionKey](ct-synchronize-multi-region-key.md) CloudTrail event that records AWS KMS synchronizing shared properties in your AWS CloudTrail logs. To view details about updates to the **AWSKeyManagementServiceMultiRegionKeysServiceRolePolicy** managed policy, see [AWS KMS updates to AWS managed policies](security-iam-awsmanpol.md#security-iam-awsmanpol-updates). **Topics** + [About the service-linked role for multi-Region keys](#about-multi-region-slr) + [Create the service-linked role](#create-mrk-slr) + [Edit the service-linked role description](#edit-mrk-slr) + [Delete the service-linked role](#delete-mrk-slr) ## About the service-linked role for multi-Region keys A [service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) is an IAM role that gives one AWS service permission to call other AWS services on your behalf. It's designed to make it easier for you to use the features of multiple integrated AWS services without having to create and maintain complex IAM policies. For multi-Region keys, AWS KMS creates the **AWSServiceRoleForKeyManagementServiceMultiRegionKeys** service-linked role with the **AWSKeyManagementServiceMultiRegionKeysServiceRolePolicy** managed policy. This policy gives the role the `kms:SynchronizeMultiRegionKey` permission, which allows it to synchronize the shared properties of multi-Region keys. Because the **AWSServiceRoleForKeyManagementServiceMultiRegionKeys** service-linked role trusts only `mrk.kms.amazonaws.com`, only AWS KMS can assume this service-linked role. This role is limited to the operations that AWS KMS needs to synchronize multi-Region shared properties. It does not give AWS KMS any additional permissions. For example, AWS KMS does not have permission to create, replicate, or delete any KMS keys. For more information about how AWS services use service-linked roles, see [Using Service-Linked Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) in the IAM User Guide. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement" : [ { "Sid" : "KMSSynchronizeMultiRegionKey", "Effect" : "Allow", "Action" : [ "kms:SynchronizeMultiRegionKey" ], "Resource" : "*" } ] } ``` ------ ## Create the service-linked role AWS KMS automatically creates the **AWSServiceRoleForKeyManagementServiceMultiRegionKeys** service-linked role in your AWS account when you create a multi-Region key, if the role does not already exist. You cannot create or re-create this service-linked role directly. ## Edit the service-linked role description You cannot edit the role name or the policy statements in the **AWSServiceRoleForKeyManagementServiceMultiRegionKeys** service-linked role, but you can edit the role description. For instructions, see [Editing a Service-Linked Role](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) in the *IAM User Guide*. ## Delete the service-linked role AWS KMS does not delete the **AWSServiceRoleForKeyManagementServiceMultiRegionKeys** service-linked role from your AWS account and you cannot delete it. However, AWS KMS does not assume the **AWSServiceRoleForKeyManagementServiceMultiRegionKeys** role or use any of its permissions unless you have multi-Region keys in your AWS account and Region. # Logging and monitoring in AWS Key Management Service Monitoring is an important part of understanding the availability, state, and usage of your AWS KMS keys in AWS KMS. Monitoring helps maintain the security, reliability, availability, and performance of your AWS solutions. AWS provides several tools for monitoring your KMS keys. **AWS CloudTrail Logs** Every call to an AWS KMS API operation is captured as an event in an AWS CloudTrail log. These logs record all API calls from the AWS KMS console, and calls made by AWS KMS and other AWS services. Cross-account API calls, such as a call to use a KMS key in a different AWS account, are recorded in the CloudTrail logs of both accounts. When troubleshooting or auditing, you can use the log to reconstruct the lifecycle of a KMS key. You can also view its management and use of the KMS key in cryptographic operations. For more information, see [Logging AWS KMS API calls with AWS CloudTrail](logging-using-cloudtrail.md). **Amazon CloudWatch Logs** Monitor, store, and access your log files from AWS CloudTrail and other sources. For more information, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/). For AWS KMS, CloudWatch stores useful information that helps you to prevent problems with your KMS keys and the resources that they protect. For more information, see [Monitor KMS keys with Amazon CloudWatch](monitoring-cloudwatch.md). **Amazon EventBridge** AWS KMS generates EventBridge events when your KMS key is [rotated](rotate-keys.md) or [deleted](deleting-keys.md) or the [imported key material](importing-keys.md) in your KMS key expires. Search for AWS KMS events (API operations) and route them to one or more target functions or streams to capture state information. For more information, see [Monitor KMS keys with Amazon EventBridge](kms-events.md) and the [Amazon EventBridge User Guide](https://docs.aws.amazon.com/eventbridge/latest/userguide/). **Amazon CloudWatch Metrics** You can monitor your KMS keys using CloudWatch metrics, which collects and processes raw data from AWS KMS into performance metrics. The data are recorded in two-week intervals so you can view trends of current and historical information. This helps you to understand how your KMS keys are used and how their use changes over time. For information about using CloudWatch metrics to monitor KMS keys, see [AWS KMS metrics and dimensions](monitoring-cloudwatch.md#kms-metrics). **Amazon CloudWatch Alarms** Watch a single metric change over a time period that you specify. Then perform actions based on the value of the metric relative to a threshold over a number of time periods. For example, you can create a CloudWatch alarm that is triggered when someone tries to use a KMS key that is scheduled to be deleted in a cryptographic operation. This indicates that the KMS key is still being used and probably should not be deleted. For more information, see [Create an alarm that detects use of a KMS key pending deletion](deleting-keys-creating-cloudwatch-alarm.md). **AWS Security Hub CSPM** You can monitor your AWS KMS usage for security industry standards and best practices compliance using AWS Security Hub CSPM. Security Hub CSPM uses security controls to evaluate resource configurations and security standards to help you comply with various compliance frameworks. For more information, see [AWS Key Management Service controls](https://docs.aws.amazon.com/securityhub/latest/userguide/kms-controls.html) in the *AWS Security Hub User Guide*. # Compliance validation for AWS Key Management Service Third-party auditors assess the security and compliance of AWS Key Management Service as part of multiple AWS compliance programs. These include SOC, PCI, FedRAMP, HIPAA, and others. **Topics** + [Compliance and security documents](#compliance-documents) + [Learn more](#compliance-more) ## Compliance and security documents The following compliance and security documents cover AWS KMS. To view them, use [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html). + Cloud Computing Compliance Controls Catalogue (C5) + ISO 27001:2013 Statement of Applicability (SoA) + ISO 27001:2013 Certification + ISO 27017:2015 Statement of Applicability (SoA) + ISO 27017:2015 Certification + ISO 27018:2015 Statement of Applicability (SoA) + ISO 27018:2014 Certification + ISO 9001:2015 Certification + PCI DSS Attestation of Compliance (AOC) and Responsibility Summary + Service Organization Controls (SOC) 1 Report + Service Organization Controls (SOC) 2 Report + Service Organization Controls (SOC) 2 Report For Confidentiality + FedRAMP-High For help using AWS Artifact, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). ## Learn more Your compliance responsibility when using AWS KMS is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. If your use of AWS KMS is subject to compliance with a published standard, AWS provides resources to help: + [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) – This page lists AWS services that are in scope of specific compliance programs. For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). + [Security and Compliance Quick Start Guides](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – These deployment guides discuss architectural considerations and provide steps for deploying security- and compliance-focused baseline environments on AWS. + [AWS Compliance Resources](https://aws.amazon.com/compliance/resources/) – This collection of workbooks and guides might apply to your industry and location. + [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) – This AWS service assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations. + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – This AWS service provides a comprehensive view of your security state within AWS. Security Hub CSPM uses security controls to evaluate your AWS resources and to check your compliance against security industry standards and best practices. For a list of supported services and controls, see [Security Hub CSPM controls reference](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-controls-reference.html). # Resilience in AWS Key Management Service The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. In addition to the AWS global infrastructure, AWS KMS offers several features to help support your data resiliency and backup needs. For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). ## Regional isolation AWS Key Management Service (AWS KMS) is a self-sustaining Regional service that is available in all AWS Regions. The Regionally isolated design of AWS KMS ensures that an availability issue in one AWS Region cannot affect AWS KMS operation in any other Region. AWS KMS is designed to ensure *zero planned downtime*, with all software updates and scaling operations performed seamlessly and imperceptibly. The AWS KMS [Service Level Agreement](https://aws.amazon.com/kms/sla/) (SLA) includes a service commitment of 99.999% for all KMS APIs. To fulfill this commitment, AWS KMS ensures that all data and authorization information required to execute an API request is available on all regional hosts that receive the request. The AWS KMS infrastructure is replicated in at least three Availability Zones (AZs) in each Region. To ensure that multiple host failures do not affect AWS KMS performance, AWS KMS is designed to service customer traffic from any of the AZs in a Region. Changes that you make to the properties or permissions of a KMS key are replicated to all hosts in the Region to ensure that subsequent request can be processed correctly by any host in the Region. Requests for [cryptographic operations](kms-cryptography.md#cryptographic-operations) using your KMS key are forwarded to a fleet of AWS KMS hardware security modules (HSMs), any of which can perform the operation with the KMS key. ## Multi-tenant design The multi-tenant design of AWS KMS enables it to fulfill the 99.999% availability SLA, and to sustain high request rates, while protecting the confidentiality of your keys and data. Multiple integrity-enforcing mechanisms are deployed to ensure that the KMS key that you specified for the cryptographic operation is always the one that is used. The plaintext key material for your KMS keys is protected extensively. The key material is encrypted in the HSM as soon as it is created, and the encrypted key material is immediately moved to secure, low latency storage. The encrypted key is retrieved and decrypted within the HSM just in time for use. The plaintext key remains in HSM memory only for the time needed to complete the cryptographic operation. Then it is re-encrypted in the HSM and the encrypted key is returned to storage. Plaintext key material never leaves the HSMs; it is never written to persistent storage. ## Resilience best practices in AWS KMS To optimize resilience for your AWS KMS resources, consider the following strategies. + To support your backup and disaster recovery strategy, consider *multi-Region keys*, which are KMS keys created in one AWS Region and replicated only to Regions that you specify. With multi-Region keys, you can move encrypted resources between AWS Regions (within the same partition) without ever exposing the plaintext, and decrypt the resource, when needed, in any of its destination Regions. Related multi-Region keys are interoperable because they share the same key material and key ID, but they have independent key policies for high-resolution access control. For details, see [Multi-Region keys in AWS KMS](multi-region-keys-overview.md). + To protect your keys in a multi-tenant service like AWS KMS, be sure to use access controls, including [key policies](key-policies.md) and [IAM policies](iam-policies.md). In addition, you can send your requests to AWS KMS using a *VPC interface endpoint* powered by AWS PrivateLink. When you do, all communication between your Amazon VPC and AWS KMS is conducted entirely within the AWS network using a dedicated AWS KMS endpoint restricted to your VPC. You can further secure these requests by creating an additional authorization layer using [VPC endpoint policies](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#edit-vpc-endpoint-policy). For details, see [Connecting to AWS KMS through a VPC endpoint](kms-vpc-endpoint.md). # Infrastructure security in AWS Key Management Service As a managed service, AWS Key Management Service (AWS KMS) is protected by the AWS global network security procedures that are described in the [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf). To access AWS KMS over the network, you can call the AWS KMS API operations that are described in the [AWS Key Management Service API Reference](https://docs.aws.amazon.com/kms/latest/APIReference/). AWS KMS requires TLS 1.2 and recommends TLS 1.3 in all regions. AWS KMS also supports hybrid post-quantum TLS for AWS KMS service endpoints in all regions, except China Regions. AWS KMS does not support hybrid post-quantum TLS for FIPS endpoints in AWS GovCloud (US). To use [standard AWS KMS endpoints](https://docs.aws.amazon.com/general/latest/gr/kms.html) or [AWS KMS FIPS endpoints](https://docs.aws.amazon.com/general/latest/gr/kms.html), clients must support TLS 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems, such as Java 7 and later, support these modes. Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) to generate temporary security credentials to sign requests. You can call these API operations from any network location, but AWS KMS supports global policy conditions that let you control access to a KMS key based on the source IP address, VPC, and VPC endpoint. You can use these condition keys in key policies and IAM policies. However, these conditions can prevent AWS from using the KMS key on your behalf. For details, see [AWS global condition keys](conditions-aws.md). For example, the following key policy statement allows users who can assume the `KMSTestRole` role to use this AWS KMS key for the specified [cryptographic operations](kms-cryptography.md#cryptographic-operations) unless the source IP address is one of the IP addresses specified in the policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": { "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::111122223333:role/KMSTestRole"}, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "NotIpAddress": { "aws:SourceIp": [ "192.0.2.0/24", "203.0.113.0/24" ] } } } } ``` ------ ## Isolation of Physical Hosts The security of the physical infrastructure that AWS KMS uses is subject to the controls described in the **Physical and Environmental Security** section of the [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf). You can find more detail in compliance reports and third-party audit findings listed in the previous section. AWS KMS is supported by dedicated hardened hardware security modules (HSMs) designed with specific controls to resist physical attacks. The HSMs are physical devices that *do not* have a virtualization layer, such as a hypervisor, that shares the physical device among several logical tenants. The key material for AWS KMS keys is stored only in volatile memory on the HSMs, and only while the KMS key is in use. This memory is erased when the HSM moves out of the operational state, including intended and unintended shutdowns and resets. For detailed information about the operation of AWS KMS HSMs, see [AWS Key Management Service Cryptographic Details](https://docs.aws.amazon.com/kms/latest/cryptographic-details/).