I'm in the process of replacing an old proprietary encryption procedure with AWS KMS and would love some feedback on my architecture. My main goal is to implement a high-integrity KMS encryption solution that emphasizes observability while preventing unauthorized access to data, especially in a scenario where there's some DevOps platform access that's outsourced. Here's my setup so far:
- I've created a dedicated KMS account for both lower and higher environments.
- No human access to AWS accounts, to keep things secure.
- Our CI/CD pipeline publishes new keys through an approval workflow in GitHub.
- The baseline key policy allows key actions only for a break glass role, key grants are managed through CI/CD, and we restrict access to only authorized accounts.
- Key grants are monitored by a Cloud Custodian instance against an approved list of service roles.
- We use Service Control Policies (SCPs) to limit high-privilege actions, preventing backdoor access to the decrypt functions.
- Cross-account IAM roles are tightly scoped to ensure they only bind to the specific execution service ARNs.
With this setup, I think engineering teams can manage things fairly independently with minimal governance, but we will still automate auditing and compliance monitoring on all Service linked IAM roles to ensure only approved services can decrypt the data.
Is there anything crucial that I might have overlooked?
2 Answers
Overall, looks good! Just keep an eye on KMS rate limits; a lot of requests might hit you hard. Consider using bucket keys for efficiency. Also, think about adding conditions in your policies to restrict access, like aws:CalledVia or aws:SourceOrgId for better security management. Check the AWS documentation for a full list of condition keys.
Your setup seems solid! Just a few things to consider: When you mention "dedicated KMS accounts for lower and higher environments," are you centralizing the encryption keys in separate AWS accounts? I personally think application teams should manage their KMS keys within their own accounts to streamline troubleshooting and access management.
Also, setting guardrails around the types of encryption allowed is essential. Are teams limited to using AWS Managed Keys, or are you okay with AWS Owned keys too? It’s important to consider what types of Customer Managed Keys (CMKs) you'll permit. Also, think about blocking grants that allow child grants to tighten security further.
Lastly, I agree with using SCPs for IAM governance. Look into Resource Control Policies (RCPs) as well; they could really help in establishing strong data perimeters for your KMS setup. Overall, it sounds like you're on a really good path!
Thanks for your detailed insights! We're definitely going with centralized KMS accounts since we need the security team to have sole control. It's a tricky political situation here, so this extra governance layer helps a lot. We're also planning to visualize grants for the app teams using dashboards to improve self-service. Your points about the guardrails are super helpful as well!
Great points! It's been an ongoing concern to balance centralized control with allowing app teams proper visibility.
Thanks for the tip on bucket keys! I'll definitely look into that!