Avoid IAM Policies Granting Unrestricted KMS Access
Why this matters
AWS Key Management Service (KMS) manages encryption keys used to secure data across AWS services. IAM policies that permit full KMS access (e.g., kms:*) can:
Allow decryption of sensitive data
Enable unauthorized key deletion or modification
Undermine data confidentiality and audit integrity
To protect key materials and encrypted resources, access should be limited to specific actions and scoped to necessary use cases.
What this check does
This Auto Check reviews IAM policies in your AWS account and identifies:
Policies that include wildcard permissions like kms:*
Permissions for sensitive KMS operations such as kms:Decrypt, kms:ScheduleKeyDeletion, or kms:DisableKey without proper conditions
Policies attached to users, roles, or groups with broad, unrestricted access
The check fails if any such over-permissive policies are detected.
How to fix it
Refactor IAM policies to align with least privilege and minimize KMS exposure.
From the AWS Console
Open the IAM Console.
Navigate to Policies and search for any with kms:* permissions.
Identify entities the policy is attached to (users, roles, groups).
Detach the policy from all attached entities.
Delete the policy if it is not essential.
Create scoped policies that include only necessary actions, such as:
kms:Encrypt
kms:GenerateDataKey
kms:DescribeKey
Avoid sensitive actions unless explicitly needed (e.g., kms:DeleteAlias, kms:DisableKey)
Using AWS CLI
# List policy attachments
aws iam list-entities-for-policy --policy-arn <policy_arn>
# Detach from user
aws iam detach-user-policy --user-name <user_name> --policy-arn <policy_arn>
# Detach from group
aws iam detach-group-policy --group-name <group_name> --policy-arn <policy_arn>
# Detach from role
aws iam detach-role-policy --role-name <role_name> --policy-arn <policy_arn>
Exceptions
For operational roles that require broader KMS permissions:
Use resource-level restrictions (e.g., Resource: specific key ARN)
Apply conditional access based on request context (e.g., IP range, MFA status)
Consider separating encryption roles from key management roles