# Ensure there are no KMS keys exposed

- Source: https://support.icompaas.com/support/solutions/articles/62000127089-ensure-there-are-no-kms-keys-exposed
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [Security Controls](https://support.icompaas.com/support/solutions/62000065178) › [AWS Services](https://support.icompaas.com/support/solutions/folders/62000097507)
- Last updated: 2026-06-08
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Description:

AWS Key Management Service (KMS) allows administrators to create, delete and control keys that encrypt data stored in AWS database products. KMS makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. AWS KMS is a secure and resilient service that uses hardware security modules(HSMs) that have been validated under FIPS 140-2, or are in the process of being validated, to protect your keys. AWS KMS is integrated with AWS  CloudTrail to provide you with logs of all key usage to help meet your regulatory and compliance needs. In AWS KMS, you must attach resource-based policies to your customer master keys (CMKs). These are called key policies. 

  

Rationale:

KMS keys exposed would negatively affect if an external threat has access to this information.

If AWS KMS keys are shared with all or grant permission to everyone it is bad practice and can lead to sensitive data leakage.

  

Impact:

No KMS exposure gives the least privilege, Decrypt and reduce the possibility for exposure. AWS allows you to separate the usage permissions from administration permissions associated with the key. This technique helps prevent unauthorized users from granting themselves KMS access and also protects their sensitive information.

  

Default Value:

The default policy enables any principal you define, as well as enables the root user in the account to add IAM policies that reference the key

  

Pre Requisites

-   We must have a Customer Management Key
    

  

Remediation:

Test Plan:

1.  Log in to the AWS Management Console and Navigate to the KMS dashboard at 
    

[https://console.aws.amazon.com/kms/](https://console.aws.amazon.com/kms/).

2.  Click on Customer managed keys in the left navigation panel 
    

              },

3.  Click on the KMS master key that you want to examine,
    

4.  Click on key policy
    

5.  Click on Switch to Policy View 
    

6.  Inside the key policy tab of selected aliases verify the policy, If the principal element promotes a certain AWS account means this key is used for a particular IAM user account.
    

7.  If “Principal”: { “AWS”:”\*”} it means the selected AWS KMS key is exposed to everyone on the internet.
    
8.  For auditing of all other listed KMS keys available in your account repeat step 3-4.
    

  

Using AWS CLI:

To get about the key policy 

aws kms get-key-policy \\
    --policy-name <value> \\
    --key-id <value> \\
    --query Policy \\
    --output text > policy.txt

  

Implementation Steps:

1.  Log in to the AWS Management Console and Navigate to the KMS dashboard at 
    

[https://console.aws.amazon.com/kms/](https://console.aws.amazon.com/kms/).

2.  Click on Customer managed keys in the left navigation panel 
    

3.   Click on the KMS master key that you want to modify after the auditing if it exposes 
    

4.  click on Key Policy 
    

5.   In Key policy click on Switch to policy view
    

6.  click on edit.
    

7.  In Key policy, you change the “Principal” if “AWS”:\[ “\*”\] } to give particular IAM users  as per the below example 
    

"Principal": {
                "AWS": \[
                "arn:aws:iam::123456789123:user/user@name",
                "arn:aws:iam::123456789321:user/tester"
                \]
              },

8.   Click on save changes
    

9.   You can add or remove from Key users or Key Administrator  
    

  
  

Using AWS CLI:

This command is used to make changes to key policy

aws kms put-key-policy \\
    --policy-name <value> \\
    --key-id <value> \\
    --policy file://policy.txt

Backout Plan:

Follow the step to disable or Schedule key deletion 

1.  Log in to the AWS Management Console and Navigate to the KMS dashboard at [](https://console.aws.amazon.com/kms/)
    

[https://console.aws.amazon.com/kms/](https://console.aws.amazon.com/kms/).

2.  Click on Customer managed keys in the left navigation panel 
    
3.  Select those Key that you want to make changes
    
4.  Click on Key policy 
    
5.  Click on Switch to policy view
    
6.  Click on Switch to the default view
    

7.  Click on Key actions from this menu list click on Disable  if you want to delete this key then click on Schedule key deletion
    

8.  If you select disable then click on the check box to  confirm that you want to disable the key and then click on disable key button
    

9.  Select the schedule key deletion
    

10.  If you want to delete and go with Schedule key deletion set the waiting period (min 7 days and max 30 days) and then click on the check box to confirm that you want to schedule these keys for deletion after a \_\_ days waiting period. and then click on the Schedule deletion button.
     

  

References:

-   [What is AWS Key Management Service? - AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html)
    
-   [https://d0.awsstatic.com/whitepapers/aws-kms-best-practices.pdf](https://d0.awsstatic.com/whitepapers/aws-kms-best-practices.pdf)
    
-   [https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service)
    
-   [Determining access to an AWS KMS customer master key - AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/determining-access.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.
