AWS KMS Security: Key Management Monitoring and Best Practices

Why KMS Security Is Often Overlooked

AWS Key Management Service sits at the foundation of most AWS security architectures. EBS volumes, S3 objects, RDS databases, Secrets Manager secrets, and dozens of other AWS services use KMS to encrypt data at rest. Despite this centrality, KMS security monitoring is frequently an afterthought.

The failure mode is predictable: teams invest heavily in IAM policies controlling who can create or delete KMS keys, but pay little attention to monitoring how those keys are actually used. An attacker who has compromised credentials with KMS decrypt permissions can exfiltrate encrypted data without triggering any common alerting rules — unless you're specifically watching for it.

This guide covers both the configuration best practices for KMS and the monitoring patterns that detect when keys are being misused.

KMS Key Types and Their Security Implications

Understanding KMS security requires understanding the different key types, because their security models differ significantly.

AWS Managed Keys

AWS managed keys (aliases like aws/s3, aws/ebs) are created and managed automatically by AWS services. You don't control the key policy, but AWS applies a default policy that restricts usage to the service that owns the key. These are secure for most purposes, but you have limited visibility into key usage — CloudTrail logs the calls, but you can't customize the key policy.

Customer Managed Keys (CMKs)

CMKs are keys you create and control. You define the key policy, can attach grants, and have full CloudTrail visibility. CMKs are required when you need to control who can use a key, enable key rotation on your schedule, or share key access across accounts. The security responsibility is yours.

AWS CloudHSM Keys

CloudHSM-backed keys are stored in dedicated hardware security modules that you control. They provide the highest assurance level and are required for some regulatory frameworks. They're significantly more expensive and complex than standard KMS keys.

The KMS Key Policy: Your Primary Access Control

Every CMK has a key policy, and this is the primary mechanism controlling who can use the key. Unlike IAM policies, a key policy is required — if a principal isn't in the key policy, they cannot use the key, regardless of IAM permissions. This "default deny" model is more secure than most AWS resource policies.

Key Policy Mistakes to Avoid

The most common key policy mistake is the catch-all:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
  "Action": "kms:*",
  "Resource": "*"
}

This grants the account root full access to the key, which means any IAM principal in the account with the right permissions can use it. It's functionally equivalent to no key policy at all. The correct pattern is to list specific IAM roles and users with the minimum permissions they need.

Separating Administration from Usage

Key policies should separate administrators (who can manage the key lifecycle: create, rotate, delete) from users (who can encrypt and decrypt data). A well-structured policy has:

• An admin statement: specific IAM roles with kms:Create*, kms:Describe*, kms:Enable*, kms:List*, kms:Put*, kms:Update*, kms:Revoke*, kms:Disable*, kms:Get*, kms:Delete*, kms:ScheduleKeyDeletion, kms:CancelKeyDeletion
• A usage statement: application roles with kms:Encrypt, kms:Decrypt, kms:ReEncrypt*, kms:GenerateDataKey*, kms:DescribeKey

Enabling Automatic Key Rotation

For symmetric CMKs, AWS supports automatic annual key rotation. When rotation is enabled, KMS generates new key material each year, but keeps the old material to decrypt data encrypted before the rotation. The key ID and ARN remain the same — the change is transparent to applications.

Enabling rotation is a best practice recommended by NIST, PCI DSS, and most compliance frameworks. The AWS CLI command:

aws kms enable-key-rotation --key-id <key-id>

You can verify rotation status with:

aws kms get-key-rotation-status --key-id <key-id>

Consider running this check across all CMKs in your account with a Config rule or a periodic Lambda to ensure rotation is consistently enabled.

Monitoring KMS with CloudTrail

Every KMS API call — encryption, decryption, key creation, policy modification — is logged to CloudTrail. This makes KMS one of the most auditable AWS services, but extracting signal from the noise requires knowing what to look for.

High-Priority KMS Events to Alert On

• DisableKey — A key was disabled, potentially causing application failures or hiding data
• ScheduleKeyDeletion — A key is scheduled for deletion; once deleted, encrypted data is permanently inaccessible
• PutKeyPolicy — The key policy was modified; could be privilege escalation
• CreateGrant — A grant was created, potentially allowing cross-account key usage
• kms:Decrypt by unexpected principals — Anomalous decryption patterns can indicate credential compromise

For CloudTrail alerting setup, see our CloudTrail alerting guide.

Detecting Anomalous Decryption

The most valuable monitoring pattern for KMS is detecting anomalous decryption — specifically, decrypt calls from principals that don't normally make them, or at volumes that don't match normal application behavior.

A CloudWatch Logs Insights query for unusual Decrypt calls:

fields @timestamp, userIdentity.arn, requestParameters.keyId, responseElements.plaintext
| filter eventName = "Decrypt"
| stats count(*) as decryptCount by userIdentity.arn, requestParameters.keyId
| sort decryptCount desc

Run this query over a 24-hour window and compare to your baseline. A spike in decrypt calls from an unusual principal is a strong indicator of credential compromise or data exfiltration. See our guide on CloudTrail log analysis for more query patterns.

Cross-Account KMS Access

KMS supports cross-account key sharing via key policies and grants. While legitimate for some architectures, unexpected cross-account KMS access is a red flag. Monitor for Decrypt calls where the userIdentity.accountId differs from the key's account. See our cross-account access monitoring guide for the broader pattern.

AWS Config Rules for KMS

AWS Config includes managed rules specifically for KMS:

• cmk-backing-key-rotation-enabled — Checks that automatic rotation is enabled for all CMKs
• kms-cmk-not-scheduled-for-deletion — Alerts when a key is scheduled for deletion

Both rules are low-cost and high-value. Enable them as part of your standard Config rule set. Our guide to essential AWS Config rules covers how to set up these and other critical checks.

KMS and GuardDuty

GuardDuty includes KMS-specific findings in its threat detection. The most relevant:

• UnauthorizedAccess:IAMUser/MaliciousIPCaller — KMS API calls from known malicious IPs
• CredentialAccess:IAMUser/AnomalousBehavior — Anomalous patterns in KMS usage consistent with credential compromise

Enable GuardDuty and ensure KMS-related findings are included in your alerting workflow. See our GuardDuty findings guide for interpretation guidance.

Secrets Manager vs. KMS: Understanding the Relationship

AWS Secrets Manager uses KMS to encrypt secrets at rest. When you store a secret in Secrets Manager, you specify a KMS key (or use the default AWS managed key). Understanding this relationship matters for security: if your Secrets Manager secrets are encrypted with a CMK, compromising that key or its key policy is equivalent to compromising every secret it protects. See our guide to AWS Secrets Manager for the full security model.

Multi-Region Keys

KMS Multi-Region Keys allow you to replicate a key across AWS regions while maintaining the same key material. This is useful for disaster recovery and multi-region applications. Security implications:

• Data encrypted in one region can be decrypted in another without re-encryption
• Key policy changes must be applied to each regional replica separately
• CloudTrail logs are regional — you need multi-region trails to monitor all usage

For most small teams, single-region keys are sufficient and simpler to manage. Multi-region keys add operational complexity that's only justified when you have active multi-region workloads.

Key Deletion: The Point of No Return

KMS key deletion is irreversible. Once a key is deleted, any data encrypted with that key is permanently inaccessible unless you have a backup of the key material (which is only possible for keys you imported). AWS enforces a 7-30 day waiting period before deletion to provide a recovery window.

Best practices for key deletion:

• Alert immediately when ScheduleKeyDeletion is called — this is almost always an emergency
• Keep an inventory of what each key encrypts before deletion
• Re-encrypt data to a new key before deleting the old one
• Use CancelKeyDeletion if a deletion was scheduled in error

The Config rule kms-cmk-not-scheduled-for-deletion gives you an automatic alert when this happens.

FAQ

Should I use AWS managed keys or customer managed keys?

AWS managed keys are fine for most workloads when you don't need to control key access or rotation schedules. Use CMKs when you need to: restrict which principals can use the key, enable audit logging per-key, share keys across accounts, or meet compliance requirements that mandate customer control of encryption keys.

How do I audit KMS key policies across all keys in my account?

Use the AWS CLI: aws kms list-keys | jq -r '.Keys[].KeyId' | xargs -I{} aws kms get-key-policy --key-id {} --policy-name default. For automated monitoring, use a Config custom rule or Lambda that periodically checks key policies against your baseline.

What's the risk of not enabling key rotation?

Without rotation, if your key material is ever compromised, all data encrypted with it is exposed. Annual rotation limits the blast radius: only data encrypted in the last year is at risk from a stolen key. Most compliance frameworks require rotation, and it's a free feature for symmetric CMKs.