This kata shows how to review which AWS IAM principals can administer, decrypt, or encrypt data with KMS encryption keys, then verify they need it using the k9 Resource Access Summary.
Reviewing encryption key administration and decryption capabilities is a critical AWS access and compliance improvement step. You can control access to your data with KMS encryption keys, but only if your security policies do what you think.
Let’s see who can administer keys or decrypt data:
- Open the latest k9 resource access audit spreadsheet from the S3 bucket containing your reports.
- Go to the Resource Access Summaries worksheet.
- Enable filtering for the columns in the worksheet
- Filter the Service Name to: KMS, the Key Management Service
- Filter the ‘Access Capability’ to
administer-resourceto see who can configure keys andread-datato see who can decrypt data
You should now have a list of principals that looks like:
These are the IAM users and roles who can:
- administer your existing encryption keys
- execute decryption operations using those keys
The example above shows access to both:
- Customer Managed CMKs:
alias/k9-testenv-testkey-8fa0501eandalias/k9-cdk-integration-test - AWS Managed CMKs:
alias/aws/rds
You cannot configure resource policies for AWS Managed CMKs, so you should expect any principal with an Identity policy that allows use of KMS without a resource condition to have access to those keys.
Access to Customer Managed Keys is far more configurable. Customer Managed CMKs should be used to encrypt important data.
If you’d also like to see who can create new keys, follow Kata 4 and review which principals have the ability to administer KMS without a qualifying resource (Resource Arn is blank).
Review Questions
Ask these questions during your review:
Q. Is all important data encrypted by a Customer Managed encryption key? Which data sources rely on AWS Managed Keys for encryption?
It’s difficult to scale effective access controls to the default AWS Managed Keys because of the proliferation of resource wildcards in Identity policies. You can address that by:
- migrating to Customer Managed CMKs for each data domain
- reducing unintended access by cleaning up Identity policies or configuring Permissions or Session boundary policies
Q. Should these principals have have access to these Customer Managed keys? In this environment?
Only the intended principals should have the ability to decrypt data with a key protecting a data domain or reconfigure one. But excess KMS permissions are frequently granted via Identity policies that grant access to KMS APIs without limiting that access to specific key resources.
Contact k9 Support ([email protected]) if you have questions, feedback, or would like assistance.
Recent Comments