Detect Unauthorized KMS Access

Monitor KMS key usage and get alerted on unauthorized decryption attempts.

Introduction

30 Second Summary

Think about security cameras in a building. They don't stop break-ins, but they let you know the moment someone tries to get in.

In this project, you will build a security monitoring pipeline that detects unauthorized access to your encrypted data and sends you an email alert in real time.

What You'll Build

A detection system using AWS CloudTrail, Amazon CloudWatch, and Amazon SNS that monitors your KMS-encrypted DynamoDB table and alerts you when someone without permission tries to decrypt your data.

By the end of this project, you'll have:

A CloudTrail trail actively recording every KMS API call in your account.
A CloudWatch alarm that detects unauthorized KMS access and triggers an SNS email notification.
A tested, end-to-end security detection pipeline that proves your system catches unauthorized decryption attempts.
Secret Mission: Add a second alarm that detects when your KMS key is scheduled for deletion.

Are there any prerequisites?

This project assumes you have an AWS account with an IAM admin user. Familiarity with AWS KMS and DynamoDB encryption (from the "Encrypt Data with AWS KMS" project or equivalent experience) is helpful but not strictly required.

Set Up Your Encrypted Resources

Before you can detect unauthorized access, you need something worth protecting. In Phase 1 of this series, you encrypted a DynamoDB table with a KMS key and proved that users without key access get blocked. Now you need to recreate that setup as the foundation for your detection pipeline.

This step builds the encrypted environment that will generate the security events you monitor in later steps. You will create a customer managed KMS key, encrypt a DynamoDB table with it, and set up a test user who triggers "access denied" events when they try to view the data.

In this step, get ready to:

Create a customer managed KMS key and encrypt a DynamoDB table with it.
Create a test IAM user with DynamoDB access but no KMS permissions.
Verify that the test user is blocked from viewing encrypted data.

Create a KMS key and encrypted DynamoDB table

A customer managed key gives you full control over who can use the key for encryption and decryption. By restricting key usage to only your admin user, anyone else who tries to decrypt the data gets denied.

In the AWS Management Console search bar, type KMS and select Key Management Service.
Select Customer managed keys in the left sidebar.
Select Create key.
For Key type, select Symmetric.
For Key usage, select Encrypt and decrypt.
Select Next.
In the Alias field, enter nextwork-kms-key.
Add a description like Key for encrypting NextWork DynamoDB table.
Select Next.
On the Define key administrative permissions page, select your IAM Admin user as the key administrator.
Select Next.
On the Define key usage permissions page, select your IAM Admin user as the key user.
Select Next.
Review your settings, then select Finish.

What is a customer managed key?

AWS KMS offers three types of keys: AWS owned, AWS managed, and customer managed. Customer managed keys give you full control over who can administer and use the key through IAM policies.

Since only your admin user has permission to use this key, anyone else who tries to decrypt data encrypted with it will receive an AccessDeniedException. That denial event is exactly what your detection pipeline will catch later.

Now create the DynamoDB table that this key will protect.

In the console search bar, type DynamoDB and select DynamoDB.
Select Create table.
For Table name, enter nextwork-kms-table.
For Partition key, enter id and keep the type as String.
Keep Default settings selected for the table settings.
Select Create table.
Wait for the table status to show Active. This usually takes about 10 seconds.

The table is created with default encryption (an AWS owned key). Now switch it to use your customer managed key.

Select the nextwork-kms-table table name to open its details.
Go to the Additional settings tab.
Under Encryption, select Manage encryption.
Choose Stored in your account, and owned and managed by you.
Select your nextwork-kms-key from the dropdown.
Select Save changes.

Finally, add a test item to the table so there is data to attempt to read.

Select Actions at the top of the table detail page.
Select Create item.
For the id value, enter 1.
Select Create item.
Select Explore items in the left sidebar to confirm your item appears in the table.

Why add an item?

When someone tries to read an item from an encrypted table, DynamoDB calls KMS to decrypt the data. If the reader does not have permission to use the KMS key, that call fails with an AccessDeniedException. Without an item in the table, there is nothing to decrypt and no security event to detect.

Cost awareness

Your customer managed KMS key costs $1 per month. The DynamoDB table falls within the free tier. You will schedule the key for deletion in the cleanup section to stop charges.

Create a test user without KMS access

To trigger a real security event, you need a user who has permission to use DynamoDB but not the KMS key. When this user tries to read the encrypted table, the denied decryption attempt is what your pipeline will detect.

In the console search bar, type IAM and select IAM.
Select Users in the left sidebar.
Select Create user.
For User name, enter nextwork-kms-user.
Check the box for Provide user access to the AWS Management Console.
Uncheck Users must create a new password at next sign-in.
Select Next.
Choose Attach policies directly.
Search for and select AmazonDynamoDBFullAccess.
Select Next.
Select Create user.
Download the .csv file with the login credentials. Keep this tab open.

Why no KMS permissions?

The AmazonDynamoDBFullAccess policy grants full access to DynamoDB operations. However, to actually read encrypted data, the user also needs permission to call Decrypt on the KMS key.

Without that KMS permission, the user's request to read table items fails. This creates the exact security event your pipeline will detect in Step 3.

Verify encryption is working

Now test that the encryption block is working by logging in as the test user and attempting to read the table. You should see an access denied error, which proves the KMS key is protecting your data.

On the nextwork-kms-user user page, copy the Console sign-in URL.
Open a new incognito/private browser window.
Paste the console sign-in URL and press Enter.
Log in using the username nextwork-kms-user and the password from your downloaded .csv file.
In the console search bar, type DynamoDB and select DynamoDB.
Select Explore items in the left sidebar.
Select nextwork-kms-table.

You should see an access denied error. This confirms that encryption is blocking the test user from viewing your data.

Not seeing an access denied error?

If you can see the table items, the encryption may not have been applied correctly. Go back to your admin window, open the table's Additional settings tab, and confirm that the encryption shows your nextwork-kms-key as the encryption key.

Also confirm you are logged into the incognito window as nextwork-kms-user and not your admin user. Check the username in the top-right corner of the console.

Still stuck? Help me troubleshoot why my test user can still view encrypted DynamoDB items.

Keep the incognito window open. You will use it again in Step 4 to trigger security events.

Your encrypted environment is ready. You have a KMS key protecting a DynamoDB table, and a test user who generates "access denied" events when they try to peek at the data. Next up, you will set up the security camera that records these events.

Create a CloudTrail Trail with CloudWatch Logs

Your encrypted data is protected, but protection alone is not enough. You also need to know when someone tries to break in.

In this step, you will set up AWS CloudTrail to record every API call in your account and send those recordings to CloudWatch Logs for analysis. Think of CloudTrail as a security camera that watches everything happening in your AWS account.

In this step, get ready to:

Create a CloudTrail trail that records management events.
Configure event logging to include KMS operations.
Verify the trail is active and sending logs to CloudWatch Logs.

Create a CloudTrail trail

CloudTrail needs a place to store its recordings and a way to forward them for real-time analysis. You will create a trail that stores logs in an S3 bucket and forwards them to a CloudWatch Logs log group.

Switch back to your IAM Admin user window (not the incognito window).
In the AWS console search bar, type CloudTrail and select the service.
Select Trails in the left sidebar.
Select Create trail.
For Trail name, enter nextwork-security-trail.
Under Storage location, choose Create new S3 bucket. Keep the auto-generated bucket name.
Under Log file SSE-KMS encryption, choose Enabled.
Choose New for the KMS key option.
Enter the alias nextwork-trail-key. This creates a new KMS key that encrypts your audit logs themselves.
Under CloudWatch Logs, check Enabled.
For Log group, choose New. Keep the default log group name (it starts with aws-cloudtrail-logs-).
For IAM Role, choose New. Keep the default role name.
Select Next.

Why encrypt the audit logs?

Your CloudTrail logs contain a detailed record of every API call in your account. If an attacker gained access to these logs, they could learn exactly how your security is configured. Encrypting the logs with a separate KMS key ensures they stay protected even if the S3 bucket is compromised.

Why send logs to CloudWatch Logs?

CloudTrail stores logs as files in S3. On their own, these files are just archives you would have to download and search manually.

By forwarding events to CloudWatch Logs, you can create metric filters that scan every incoming event in real time. This is what enables automated alerting in the next step.

Configure event logging

On the Choose log events page, you decide what types of activity the trail records. You need management events (which include KMS operations like Decrypt) turned on.

Under Management events, confirm that both Read and Write events are checked. This captures all KMS operations including Decrypt attempts.
Make sure Exclude AWS KMS events is not checked. The default is to include all AWS KMS events, which is what you want.
Skip Data events and Insights events (these cost extra and are not needed for this project).
Select Next.
Review your settings on the summary page.
Select Create trail.

What does Exclude AWS KMS events mean?

KMS actions like Encrypt, Decrypt, and GenerateDataKey generate a large volume of events in most AWS accounts. Some teams exclude them to reduce noise. For this security monitoring project, you need them included so your alarm can detect unauthorized Decrypt attempts.

Verify the trail is active

After creation, you should see your trail listed on the Trails page.
Confirm the trail shows Logging as its status. When you create a trail via the console, logging is turned on automatically.

What is a multi-region trail?

All trails created using the CloudTrail console are multi-Region trails by default. This means your trail captures API activity across all AWS Regions, not just the one you are currently working in. You do not need to change this setting.

Events take a few minutes to appear

It can take up to 5 minutes for events to start appearing in CloudWatch Logs after the trail is created. This is normal.

Trail not showing Logging status?

Make sure you selected Create trail on the final review page. If the trail appears but shows no status, refresh the page after a moment.

If you see a permissions error, confirm you are signed in as your IAM Admin user (not the test user in the incognito window).

Why isn't my CloudTrail trail logging?

Your security camera is now recording. Next up, you will build the alarm system that watches these recordings and alerts you when something suspicious happens.

Create a Metric Filter and CloudWatch Alarm

Your CloudTrail trail is now recording every API call in your account. The security camera is rolling, but a camera is useless if nobody watches the footage.

In this step, you'll build the automated detection that watches those recordings for suspicious activity. You'll connect Amazon CloudWatch and Amazon SNS to create an alarm pipeline that emails you the moment someone unauthorized tries to access your KMS key.

In this step, get ready to:

Create an SNS topic and email subscription for alert notifications.
Build a CloudWatch metric filter that detects KMS access denied events.
Set up a CloudWatch alarm that triggers when the filter catches suspicious activity.

Create an SNS topic for email notifications

Before you build the alarm, you need somewhere for it to send notifications. An SNS topic acts as a message channel that can forward alerts to your email.

Navigate to Amazon SNS in the AWS console.
Select Topics in the left sidebar.
Select Create topic.
For Type, select Standard.
For Name, enter nextwork-kms-alert.
Select Create topic.

Your topic is created. Now you need to subscribe your email address to it.

Select Create subscription.
For Protocol, select Email.
For Endpoint, enter your email address.
Select Create subscription.
Check your email inbox for a confirmation email from AWS (sent from no-reply@sns.amazonaws.com).
Click the Confirm subscription link in that email.

You must confirm the subscription

If you skip the email confirmation step, you will not receive any alarm notifications later in this project. The subscription stays in a Pending confirmation state until you click the link.

Don't see the confirmation email?

Check your spam or junk folder. The email comes from no-reply@sns.amazonaws.com and may be filtered automatically.

If it still hasn't arrived after a few minutes, go back to your SNS subscription and select Request confirmation to resend it.

Help me troubleshoot my SNS subscription confirmation.

Create a metric filter on the CloudTrail log group

A metric filter is a rule that scans every log entry flowing into a CloudWatch Logs log group. When the entry matches a pattern you define, CloudWatch increments a custom metric.

Navigate to CloudWatch in the AWS console.
In the left sidebar, expand Logs and select Log groups.
Select the log group that was created for your trail (its name starts with aws-cloudtrail-logs-).
Go to the Metric filters tab.
Select Create metric filter.

Now you'll define the pattern that tells CloudWatch what to look for. Paste the following into the Filter pattern field:

{ $.errorCode = "AccessDeniedException" && $.eventSource = "kms.amazonaws.com" }

What does this pattern do?

This pattern uses CloudWatch Logs JSON filter syntax to match log entries where two conditions are both true.

The $.errorCode = "AccessDeniedException" part catches any API call that was denied. The $.eventSource = "kms.amazonaws.com" part narrows it to KMS operations only. Together, they detect anyone who tried to use a KMS key and was blocked.

Select Next.
For Filter name, enter KMSAccessDeniedFilter.
For Metric namespace, enter NextWorkSecurity.
For Metric name, enter KMSAccessDeniedCount.
For Metric value, enter 1.
For Default value, enter 0.
Select Next.
Review your settings and select Create metric filter.

Metric filters are not retroactive

Your filter only publishes data points for events that happen after it was created. It will not scan historical logs that already exist in the log group. This is why you'll generate fresh access denied events in the next step to test it.

Create a CloudWatch alarm

Now you'll create the alarm that watches the custom metric and sends you an email when it detects a non-zero value.

Back on the Metric filters tab, select the checkbox next to KMSAccessDeniedFilter.
Select Create alarm.

This opens the CloudWatch alarm creation wizard. Configure the metric and conditions:

Under Specify metric and conditions, set Statistic to Sum.
Set Period to 1 minute.
Under Conditions, set Threshold type to Static.
Set the threshold to Greater/Equal than 1.
Expand Additional configuration.
Set Datapoints to alarm to 1 out of 1.
Set Missing data treatment to Treat missing data as not breaching.
Select Next.

Why treat missing data as not breaching?

If CloudTrail hasn't delivered any new log events in a given minute, the metric has no data points. Treating missing data as "not breaching" means the alarm stays quiet during idle periods. Without this setting, the alarm could fire false alerts when there's simply no activity.

Now configure who gets notified when the alarm fires:

Under Notification, set Alarm state trigger to In alarm.
Select the SNS topic nextwork-kms-alert.
Select Next.

Finally, name your alarm:

For Alarm name, enter KMSUnauthorizedAccessAlarm.
For Alarm description, enter Alerts when someone without KMS permissions attempts to decrypt data.
Select Next.
Review your settings and select Create alarm.

You should see your new alarm listed with a state of Insufficient data. This is normal. The alarm hasn't received any metric data points yet because no KMS access denied events have occurred since you created the filter.

What is the Insufficient data state?

CloudWatch alarms have three states: OK (metric is below threshold), In alarm (metric breached threshold), and Insufficient data (not enough data points yet). Since your metric filter is brand new and no matching events have occurred, the alarm starts in Insufficient data.

Don't see your alarm listed?

Make sure you selected the checkbox next to KMSAccessDeniedFilter before clicking Create alarm. If you skipped that step, navigate to CloudWatch then Alarms in the left sidebar to check if the alarm was created.

Help me find my CloudWatch alarm.

Your detection pipeline is wired up and ready to go. Next, you'll trigger an unauthorized access event and watch the entire pipeline fire from end to end.

Test Your Security Detection Pipeline

You have built the full detection system. CloudTrail is recording events, CloudWatch is watching for suspicious patterns, and SNS is ready to send you an email.

Now it is time to prove the whole pipeline works end-to-end. You will trigger a real unauthorized access attempt as the test user, then verify that the alarm fires and an email lands in your inbox.

In this step, get ready to:

Generate unauthorized KMS access events using your test user.
Verify the events appear in CloudTrail Event history.
Confirm the alarm transitions to In alarm and you receive an email notification.

Generate an unauthorized access event

Your test user (nextwork-kms-user) has DynamoDB access but no KMS permissions. When this user tries to view items in the encrypted table, AWS generates an AccessDeniedException event that CloudTrail records.

Switch to the incognito window where you are logged in as nextwork-kms-user.
Navigate to DynamoDB in the AWS console.
Select Explore items in the left sidebar.
Select nextwork-kms-table.
Confirm you see an access denied error. This is the unauthorized decryption attempt that your pipeline will detect.
Refresh the page 2-3 more times to generate multiple events. Each page load creates a separate log entry in CloudTrail.

Why generate multiple events?

A single event is enough to trigger the alarm, but generating multiple events makes them easier to find in CloudTrail Event history. It also confirms that the metric filter counts each attempt individually.

Verify the event in CloudTrail

Before waiting for the alarm, you can confirm that CloudTrail actually captured the unauthorized access attempts. This is your proof that the "security camera" recorded the event.

Switch back to your IAM Admin user window (not the incognito window).
Navigate to CloudTrail in the AWS console.
Select Event history in the left navigation pane.
You may see a default filter set to Read only = false. Clear this filter by clicking the X next to it. You need to see Read events because Decrypt is a read operation.
In the Lookup attributes dropdown, choose Event source.
Enter kms.amazonaws.com in the filter value field.
Look for recent Decrypt events in the results list. You should see entries with an error code of AccessDeniedException from your test user.
Select one of the Decrypt events to view its details. Note the key fields: userIdentity shows who tried to access the key, eventName shows what they tried to do, and errorCode confirms it was denied.

What do these event fields mean?

Every CloudTrail event is a structured JSON record. The userIdentity field identifies who made the request (in this case, nextwork-kms-user). The eventName field shows the API action attempted (Decrypt). The errorCode field shows the result (AccessDeniedException).

Your metric filter pattern matches on errorCode and eventSource. When CloudTrail delivers this event to CloudWatch Logs, the filter detects the match and increments the KMSAccessDeniedCount metric.

Not seeing Decrypt events?

Make sure you cleared the default Read only = false filter. Decrypt is a Read event, so it is hidden by this default filter.

CloudTrail events can take up to 5 minutes to appear in Event history. If you do not see the events yet, wait a few minutes and refresh the page.

Help me find my Decrypt events in CloudTrail Event history.

Verify your alarm fired

The final step is confirming that the alarm detected the unauthorized access and sent you an email. CloudTrail event delivery to CloudWatch Logs can take up to 15 minutes, so you may need to wait.

Wait 5-10 minutes for the CloudTrail logs to flow through to CloudWatch Logs and for the metric filter to process them.
Navigate to CloudWatch in the AWS console.
In the left navigation pane, select Alarms, then All alarms.
Check if KMSUnauthorizedAccessAlarm has moved to the In alarm state. Alarms in the ALARM state appear in red in the console.
Check your email inbox. You should have received a notification from AWS Notifications saying the alarm state changed to ALARM.

What does the email contain?

The SNS notification email includes the alarm name, the new state (ALARM), the reason for the state change, and a timestamp. This is the same information a security operations team would use to begin investigating an incident.

Alarm still in Insufficient data or OK state?

CloudTrail event delivery to CloudWatch Logs typically takes around 5 minutes but can take up to 15 minutes. Wait a few more minutes and refresh the CloudWatch Alarms page.

If the alarm still has not triggered after 15 minutes, go back to the incognito window and try accessing the DynamoDB table a few more times. Then wait another 5-10 minutes.

Also verify that the metric filter is attached to the correct log group. In CloudWatch, go to Logs then Log groups, select your CloudTrail log group, and check the Metric filters tab.

Help me troubleshoot why my CloudWatch alarm has not fired.

You just validated a complete security detection pipeline. An unauthorized user tried to access encrypted data, CloudTrail recorded the attempt, CloudWatch detected the suspicious pattern, and SNS notified you by email.

Secret mission

Detect KMS Key Deletion Attempts

Your detection pipeline catches unauthorized access. But what about something even more dangerous? If someone schedules your KMS key for deletion, all data encrypted with that key becomes permanently unrecoverable. Can you add a second alarm to catch this threat before it's too late?

Clean Up Your Resources

This project uses two KMS keys that cost $1/month each. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

Your two KMS keys (nextwork-kms-key and nextwork-trail-key) cost $1/month each. That is $2/month total if left running. All other resources in this project fall under the AWS free tier.

Resources you used:

2 KMS keys (nextwork-kms-key and nextwork-trail-key). $1/month each.
1 DynamoDB table (nextwork-kms-table). Free tier.
1 CloudTrail trail (nextwork-security-trail). Free (first copy of management events).
1 S3 bucket (auto-named CloudTrail log bucket). Minimal storage cost.
1 CloudWatch Logs log group with 2 metric filters and 2 alarms. Free tier.
1 SNS topic (nextwork-kms-alert) with email subscription. Free.
1 IAM user (nextwork-kms-user). Free.
1 CloudTrail IAM role (auto-created for CloudWatch Logs delivery). Free.

Keep everything running

No action needed. Choose this if you plan to continue to Phase 3 of this security series soon.

Your two KMS keys will continue to cost $2/month combined.
All other resources remain in the free tier.
Your detection pipeline stays active and will continue to email you if unauthorized access is detected.

Pause - I'll come back to this later

Disable your KMS keys to prevent usage. You still pay $1/month per key until you schedule them for deletion.

Navigate to KMS in the AWS console. Select Customer managed keys.
Select the checkbox next to nextwork-kms-key. Select Key actions, then Disable.
Repeat for nextwork-trail-key.
Navigate to CloudTrail. Select Trails in the left sidebar. Select nextwork-security-trail. Select Stop logging to stop recording events without deleting the trail.
Close the incognito window where you were logged in as nextwork-kms-user.

Delete - I don't want to use this again

Remove all project resources to avoid any charges. Follow these steps in order.

Delete the DynamoDB table:

Navigate to DynamoDB in the AWS console.
Select Tables in the left sidebar.
Select nextwork-kms-table. Select Delete. Confirm by typing delete and select Delete table.

Schedule deletion of both KMS keys:

Navigate to KMS. Select Customer managed keys.
Select the checkbox next to nextwork-kms-key. Select Key actions, then Schedule key deletion.
Set the waiting period to 7 days. Confirm and select Schedule deletion.
Repeat for nextwork-trail-key.

Why 7 days?

AWS requires a minimum 7-day waiting period before permanently deleting a KMS key. This gives you time to cancel the deletion if you realize you still need it. After 7 days, the key and all data encrypted with it become permanently unrecoverable.

Delete the CloudTrail trail:

Navigate to CloudTrail. Select Trails in the left sidebar.
Select nextwork-security-trail.
At the top of the trail details page, select Delete. Confirm to permanently delete the trail.

Empty and delete the CloudTrail S3 bucket:

Navigate to S3 in the AWS console.
Find the bucket that starts with aws-cloudtrail-logs-. Select it.
Select Empty. Type permanently delete to confirm. Select Empty.
Go back to the bucket list. Select the same bucket, then select Delete. Type the bucket name to confirm. Select Delete bucket.

Delete CloudWatch resources:

Navigate to CloudWatch. Select Alarms in the left sidebar.
Select the checkboxes next to KMSUnauthorizedAccessAlarm and KMSKeyDeletionAlarm. Select Actions, then Delete. Confirm.
In the left sidebar under Logs, select Log groups.
Select the checkbox next to the log group that starts with aws-cloudtrail-logs-. Select Actions, then Delete log group(s). Confirm.

Delete the SNS topic:

Navigate to Amazon SNS. Select Topics in the left sidebar.
Select nextwork-kms-alert. Select Delete. Type delete me to confirm. Select Delete.

Delete IAM resources:

Navigate to IAM. Select Users in the left sidebar.
Select nextwork-kms-user. Select Delete. Type the username to confirm. Select Delete user.
Select Roles in the left sidebar. Search for the CloudTrail role (it starts with CloudTrail_CloudWatchLogs_Role).
Select the role. Select Delete. Type the role name to confirm. Select Delete.
Delete the .csv credentials file from your computer (check your Downloads folder).

Close the incognito window where you were logged in as nextwork-kms-user.

Nice Work!

You just built a complete security detection pipeline on AWS. Your account now has a working system that catches unauthorized access to your encrypted data and alerts you in real time.

You learned how to:

Set up AWS CloudTrail to record every API call in your account and deliver logs to CloudWatch Logs for real-time analysis.
Built a CloudWatch metric filter and alarm that automatically detects KMS access denied events and sends you an email notification through Amazon SNS.
Tested the full security detection pipeline end-to-end by triggering an unauthorized decryption attempt and confirming you received an instant email alert.
Secret Mission: Added a second detection layer for KMS key deletion attempts, protecting against one of the most dangerous actions in AWS.

Ready to quiz yourself?