Mastering AWS KMS Security for Cross-Account Access

Overview

In the AWS ecosystem, data encryption is a fundamental layer of defense, and AWS Key Management Service (KMS) is the engine that powers it. KMS manages the cryptographic keys that protect your most sensitive data across services like Amazon S3, EBS, and RDS. While isolating resources is standard practice, modern cloud operations often require sharing these keys across different AWS accounts for legitimate business purposes like centralized logging, disaster recovery, or third-party integrations.

This practice, known as cross-account access, introduces significant risk if not managed with precision. The core problem arises from misconfigured KMS Key Policies, which can unintentionally grant external, untrusted AWS accounts the ability to access and decrypt your sensitive data. Such misconfigurations represent a hidden security vulnerability and a source of operational risk that can undermine your entire data protection strategy.

Why It Matters for FinOps

From a FinOps perspective, poorly managed KMS access is more than a technical error; it’s a direct threat to business value. A breach stemming from an exposed key can lead to catastrophic financial penalties from non-compliance with regulations like PCI DSS or HIPAA. The cost of remediation, potential ransomware payments, and permanent data loss from malicious key deletion can have a lasting impact on revenue.

Beyond direct costs, this issue introduces significant risk and operational drag. Uncontrolled cross-account permissions violate core governance principles, leading to failed audits and severe reputational damage. Without proactive guardrails, engineering teams can unknowingly create security vulnerabilities, leaving the organization to manage the resulting technical debt and business risk. Effective FinOps requires treating cryptographic key access with the same rigor as budget management.

What Counts as “Idle” in This Article

For the purposes of this article, we define "unauthorized cross-account access" as any permission granted in an AWS KMS Key Policy to an external AWS account that is not on a formally approved organizational allowlist. This represents a form of waste—a risky, unnecessary permission that provides no business value.

Common signals of this misconfiguration include:

• Key policies containing wildcard principals (*) without strict conditional logic.
• Permissions granted to AWS accounts belonging to former vendors, partners, or decommissioned projects.
• The presence of external account IDs in a policy that lack any clear business justification or documentation.
• A complete absence of AWS CloudTrail logs showing any legitimate use of the key by the permitted external account.

Common Scenarios

Understanding legitimate use cases is key to identifying and eliminating unauthorized access.

Scenario 1

A common architecture involves a central security account that aggregates AWS CloudTrail logs from multiple spoke accounts. For this to work, the KMS key used to encrypt the logs in the spoke accounts must have a policy that explicitly grants encryption permissions to the central security account’s ID. Any other external account ID in that policy would be considered a high-risk finding.

Scenario 2

Integrating a third-party SaaS analytics platform often requires the vendor’s AWS account to read data from your encrypted S3 buckets. This necessitates adding the vendor’s specific AWS Account ID to the relevant KMS Key Policy. This scenario is inherently risky and demands a lifecycle management process to ensure the permission is removed immediately upon contract termination.

Scenario 3

Organizations often replicate encrypted data, such as Amazon EBS snapshots or RDS backups, to a dedicated disaster recovery (DR) account. The KMS key in the production account must grant permissions to the DR account to enable the re-encryption process. The key policy should be restricted to only the designated DR account and nothing more.

Risks and Trade-offs

The primary risk of misconfigured KMS access is the loss of data confidentiality. If an unauthorized external account gains access, it can decrypt your most sensitive information, rendering your encryption controls useless. Beyond data theft, a malicious actor could disable or schedule the deletion of a key, triggering an immediate and widespread outage for all applications that depend on it.

This creates a critical trade-off for cloud teams. Security and FinOps leaders may hesitate to remove a suspicious cross-account permission for fear of breaking a critical but undocumented production workflow. This "don’t break prod" dilemma underscores the need for careful auditing and impact analysis before remediation, reinforcing the value of establishing clear ownership and documentation from the start.

Recommended Guardrails

To manage KMS cross-account access effectively, organizations should implement a set of preventative guardrails:

• Policy: Establish a formal, written policy that defines the process for requesting, approving, and reviewing all cross-account KMS access. Maintain a central allowlist of all trusted AWS accounts.
• Tagging Strategy: Enforce a consistent tagging standard for all Customer Managed Keys (CMKs). Tags should identify the key’s owner, the cost center, and the business justification for any cross-account access (e.g., cross-account-purpose: vendor-analytics-tool).
• Ownership: Assign a clear owner to every CMK. This individual or team is responsible for periodically reviewing the key’s policy and attesting to the continued need for any external access.
• Approval Flow: Integrate KMS policy changes into an Infrastructure as Code (IaC) pipeline. Require a formal review and approval for any modification that adds a new external principal to a key policy.
• Budgets and Alerts: Use services like AWS Config to create rules that automatically detect and send alerts whenever a KMS Key Policy is modified to include an unknown or non-allowlisted external account.

Provider Notes

AWS

In AWS, access to KMS keys is governed by a dual-permission model. First, the resource-based Key Policy attached to the key itself must explicitly grant permissions to an external account’s principal (such as the account root or a specific IAM role). This policy acts as the primary gatekeeper.

Second, an identity-based IAM Policy within that external account must also grant its users or roles the corresponding permissions to use the key. Both are required for access to succeed. For a deep dive into how these policies interact, refer to the official documentation on allowing users in other accounts to use a KMS key and the fundamentals of KMS key policies.

Binadox Operational Playbook

Binadox Insight: Misconfigured KMS Key Policies are a silent but significant source of risk. They often represent forgotten trust relationships with old vendors or test accounts, creating a direct path for data exfiltration that bypasses many other security controls.

Binadox Checklist:

• Inventory all Customer Managed Keys (CMKs) across your AWS environment.
• Audit the Key Policy for each CMK, identifying all external AWS account principals.
• Create and maintain an allowlist of trusted AWS accounts for legitimate cross-account access.
• Remediate non-compliant keys by removing unauthorized principals from their policies after impact analysis.
• Implement automated monitoring to detect and alert on unauthorized changes to Key Policies.

Binadox KPIs to Track:

• Percentage of CMKs with non-compliant cross-account policies.
• Mean Time to Remediate (MTTR) for a newly detected KMS misconfiguration.
• Number of unique external AWS accounts permitted in key policies, trended over time.
• Percentage of CMKs with clearly defined owners and business justification tags.

Binadox Common Pitfalls:

• Using wildcard principals (*) in key policies without strict condition clauses.
• Forgetting to revoke a vendor’s account access after a contract has ended.
• Failing to document the business justification for each cross-account permission, leading to remediation paralysis.
• Breaking a production workflow by removing a permission without proper impact analysis.

Conclusion

AWS KMS cross-account access is a powerful and necessary feature for modern cloud architectures, but it demands rigorous governance. Leaving key policies unmanaged is equivalent to leaving a door to your most valuable data unlocked.

By shifting from a reactive cleanup approach to a proactive governance model, organizations can mitigate significant financial and operational risks. Implementing clear policies, leveraging automation for detection, and establishing unambiguous ownership are essential steps to secure your data, maintain compliance, and optimize your cloud operations in AWS.