Introduction
Encryption is a critical layer of defense-in-depth in architected security, alongside sound segmentation and boundary design. Segmentation and boundaries reduce reach, access, and blast radius, but it is still possible for malicious actors to reach AWS resources. AWS KMS architecture leverages the AWS native KMS service to manage encryption keys used to protect data stored within AWS services and applications. This works to further protect workloads isolated by segmentation and trust boundaries, where encryption denies attackers from using protected data. However, the keys used to encrypt data are also important resources that require protection and management. Otherwise, malicious actors could acquire the keys and the protected resources. It is also possible to lose keys, making encrypted data unusable.
Similar to all other security safeguards, both passive and active, encryption alone does not secure systems. Instead, encryption makes up one layer of a multilayer architecture, with isolation, governance, identity, monitoring, and remediation to minimize damage from malicious agents. Additionally, many industries that leverage AWS operate in heavily regulated environments, including financial services. They also have strict requirements on the encryption keys themselves, including auditing, compliance, and control. Similar to the management of physical keys and combination locks of physical containers for physical objects, including classified documents. The AWS KMS service provides centralized management of encryption keys and protects key material within dedicated cryptographic infrastructure separate from the workloads that use those keys. The article explores how AWS KMS architecture fits in with the overall security posture.
Understanding AWS KMS Architecture
What Is AWS KMS?
AWS KMS is a managed service for managing cryptographic keys used to encrypt data stored within AWS services and applications. Primarily, it manages secure storage and protection of key material using hardware to isolate it. Alongside this, it provides centralized key creation and lifecycle management. Another aspect of cryptographic key best practice is rotation, and AWS KMS provides automatic and manual key rotation capabilities. Because it is an AWS-native service, it integrates with other AWS services such as S3, EBS, and RDS to encrypt their data. It also provides centralized management of encryption keys across AWS workloads and separates key management from workload resources. Similar to IAM roles, it decouples key management from workloads, establishing a foundation for enterprise encryption and compliance controls.
AWS KMS Architecture Regional Design
KMS keys are legitimate AWS resources, just like all other AWS resources. Therefore, architecture should apply the same principles of resource isolation through segmentation and trust boundaries. Here, regional boundaries provide segmentation, with cryptographic keys scoped to individual AWS Regions. Key material remains scoped to its AWS Region, aligning cryptographic controls with AWS fault isolation boundaries and regional trust boundaries. Therefore, regional cryptographic control is independent of all other regions, enforcing regional compliance and data residency requirements. However, there is a balance between regional isolation and operational flexibility. The architecture achieves this by supporting multi-region keys and controlled replication of key material between Regions.
Hardware Security Modules and Cryptographic Operations
Not only is KMS key material a resource in its own right, but it also warrants additional protection given its critical role. AWS KMS key architecture further isolates KMS keys by assigning them their own dedicated cryptographic infrastructure, i.e., the Hardware Security Module (HSM)-backed architecture. The KMS key material never leaves the HSM, establishing an additional trust boundary through dedicated cryptographic infrastructure. Also, AWS performs all cryptographic operations through AWS KMS with no direct workload access to protected key material. This makes the trust boundary far more stringent than normal. All cryptographic requests are through the KMS API, including the generation of cryptographic keys and data encryption keys. Additional services include data encryption and decryption, as well as digital signing and signature verification.
Why Centralized Key Management Matters
KMS key architecture further strengthens KMS key isolation by managing encryption keys and plaintext data separately. This allows for independent management and decoupling of protected data and encryption keys. Cryptographic resources and protected data have differing governance requirements. Separating them simplifies governance since these resource classes are orthogonal to each other. This enables fine-grained access control over the encryption keys, separate from AWS resources, supporting limited permission sets across all resources. Additionally, architecture can enforce least-privilege access principles since cryptographic access is separate from other resources. This enables centralized governance of cryptographic resources, allowing centralized security controls across AWS workloads. Additionally, this allows for centralized key lifecycle management and consistent key rotation policies.
How Envelope Encryption Works in AWS KMS Architecture
The Challenge of Encrypting Data at Scale
KMS key material is a resource held within the HSM and never leaves it. Direct encryption and decryption of data by KMS key material is done within the HSM and not outside it. This makes encrypting and decrypting all data directly with KMS keys impractical due to several bottlenecks. Even small users still have to encrypt data in the order of gigabytes. Therefore, the HSM capacity will quickly run into limitations performing encryption and decryption operations for even moderate data volumes. There is also latency and overhead associated with transferring data to and from the HSM. Hence, it is imperative to separate key management from data encryption.
Data Encryption Keys and KMS Keys
Data encryption keys (DEK) and KMS Keys enable the separation of key management from data encryption. DEKs are responsible for data encryption and decryption that occurs at AWS resources outside of HSM. However, they also need protection through encryption and are unencrypted only when performing encryption or decryption on protected data. Therefore, they are encrypted and decrypted by KMS keys within the HSM, establishing a hierarchical encryption architecture. This effectively separates data encryption operations by DEKs from key protection implemented by KMS keys. Since only DEKs are encrypted and decrypted within the HSM, this addresses bottlenecks of KMS keys used to directly protect data. This is known as envelope encryption, which separates operational encryption from key governance.
Envelope Encryption Workflow
This workflow establishes the interaction between AWS KMS keys and DEKs in maintaining separation of key management from data encryption. When an AWS workload wants to encrypt data, it sends a Generate Data Key request to AWS KMS. AWS KMS creates a new DEK and returns the plaintext DEK to the requesting service. It also sends the encrypted DEK encrypted by the KMS key. The service encrypts the data using the plaintext DEK and securely disposes of it after encryption. It stores the encrypted DEK alongside the encrypted data.
Whenever the service wants to decrypt the data, it retrieves both the encrypted data and the associated encrypted DEK. It then submits the encrypted DEK to the AWS KMS, which decrypts the DEK using the KMS key material. The plaintext DEK is returned to the requesting service, which uses it to decrypt the data. Upon decryption of the original plaintext data, the service disposes of the plaintext DEK. Therefore, there is no direct workload access to the KMS key material, preserving centralized key governance.
AWS Service Integrations and Performance Benefits
Key AWS data storage services are natively integrated with the AWS KMS service to perform application-layer encryption using DEKs. This includes Amazon S3, Amazon EBS, and Amazon RDS, which can encrypt bulk data outside the HSM using DEKs. These DEKs are protected by HSM through encryption. This significantly reduces dependence on direct KMS cryptographic operations and the number of KMS API calls for bulk data encryption. There are reduced bottlenecks within HSM-backed infrastructure, enabling a scalable encryption architecture for enterprise workloads. It efficiently handles large data values while preserving centralized key governance and consistent encryption controls across AWS services.
AWS Managed Keys vs Customer Managed Keys
AWS KMS Architecture Key Management Spectrum
The AWS KMS service is essential in strengthening trust boundaries, network segmentation, and IAM boundaries, making KMS key management critical. KMS keys serve different purposes, and their management should reflect that, as well as the shared responsibility model for cryptographic controls. The main categories of KMS keys that support this model are AWS-owned, AWS-managed, and Customer-managed keys. They have progressive levels of customer visibility, control, and responsibility. AWS retains ownership and management of AWS-owned keys, the same for AWS-managed keys, but with customer visibility. However, the customer has ownership of governance for customer-managed keys.
AWS-Owned and AWS-Managed Keys
AWS-owned keys are fully managed by AWS and typically used for standard encryption requirements for AWS resources. Encryption and decryption are automatically performed by AWS. Therefore, they are abstracted away from the customer since the customer does not have direct visibility into key management. AWS rarely discloses the resources encrypted by AWS-owned keys, with Amazon S3 Managed Encryption (SSE-S3) one of the few known examples.
AWS-managed keys are also fully managed by AWS, but with customer visibility and limited governance and policy customization. They are convenient for customers wanting low maintenance with reduced administrative burden. Also, they are typically appropriate for many non-regulated workloads.
Customer-Managed Keys and Governance Control
Customers have full ownership of the governance of customer-managed KMS keys along with the administrative burden. However, in highly regulated environments, control of the KMS keys is more important than control of the resources they protect. The customer defines the key policies allowing for fine-grained access control. Significantly, the customer can manage their authorization through IAM integration, allowing for the enforcement of least-privilege access principles. The customer has control of the key lifecycle management, including key creation, disablement, and deletion controls. Through IAM, customers can separate duties between administrators and workloads, decoupling the two activities for better management. The architecture can also enable CloudTrail visibility into cryptographic operations, allowing monitoring of key access and activity. This enables AWS KMS architecture to establish an encryption governance framework.
Why Customer-Managed Keys Matter in Regulated Industries
AWS KMS keys are very much the same as physical keys to locks protecting physical items, including classified documents. Hence, regulatory oversight includes cryptographic controls that protect sensitive data, which require visibility into key usage and access. They are also subject to formal audit requirements and compliance reporting obligations. Regulators also enforce the separation of duties and independent governance of encryption keys. Additionally, they require monitoring of key management activities to ensure traceability of cryptographic operations. Customer-managed KMS keys allow enforcement of organizational security policies as well as risk management, fulfilling regulatory requirements.
Designing Trust Boundaries with AWS KMS
KMS Keys as Security Boundaries
Encryption adds one more layer of security and resource isolation on top of trust boundaries, network segmentation, and identity boundaries. KMS key architecture isolates protected workloads through encryption by encrypting different workloads with different KMS keys. Therefore, it makes encryption a security boundary similar to network segments, trust boundaries, and IAM identity boundaries. This extends identity and resource boundaries into cryptographic boundaries. It also decouples data protection from workload management, allowing independent governance of cryptographic resources. Additionally, KMS key architecture treats KMS keys as protected security resources, physically isolating them using HSM and access authorization policies. Hence, enforcing governance at the cryptographic layer.
Account Isolation and Environment Separation
AWS uses AWS Accounts to implement primary trust boundaries. KMS architecture best practices reinforce these boundaries by maintaining separate keys for each AWS Account. It isolates encryption resources across AWS Accounts and extends account isolation through cryptographic controls. Additionally, KMS architecture makes each AWS account an independent cryptographic governance domain. A common example is the isolation of development, testing, and production environments through dedicated KMS keys for each environment. Each environment has independent key lifecycle management and independent key policies. Different encryption keys reduce lateral movement between environments and the blast radius in the event of a key compromise. Maintaining separate KMS keys per AWS Account aligns with multi-account architectures, AWS Organizations governance models, and Service Control Policy (SCP) guardrails, reinforcing resource isolation principles.
Workload Separation and Least Privilege
KMS key management principles also enforce workload isolation within trust boundaries by maintaining dedicated KMS keys per workload. By cryptographically isolating workloads, dedicated KMS keys prevent compromised workloads from impacting other workloads within the same boundary. By separating sensitive workloads, they establish application-level encryption boundaries, each with its own independent cryptographic governance domain. Additionally, KMS architecture integrates IAM to manage authorization for both workloads and the KMS keys assigned to them. It uses key policy enforcement for fine-grained access controls, reinforcing workload isolation through IAM permission boundaries. Therefore, it aligns encryption boundaries with workload boundaries, reducing lateral movement between workloads and risk of cross-workload access. KMS architecture enforces defense-in-depth cryptographic segmentation, limiting the blast radius from workload compromise.
Cross-Account Access and Controlled Trust
For an enterprise to function, workloads must interact with each other and across trust boundaries, making complete isolation impractical. Therefore, whenever it is necessary to establish explicit trust relationships between AWS accounts, this includes cross-account access to KMS keys. Multi-account architectures commonly use the AssumeRole pattern to control cross-account access between trust boundaries. A similar trust model applies to KMS keys assigned to another AWS account. Cross-account access requires explicit authorization through KMS key policies and IAM permissions before workloads can perform cryptographic operations using those keys. Therefore, KMS architecture applies stricter governance and authorization requirements to cross-account key access than many other AWS resources. It also applies governance and monitoring around cross-account key access to prevent unintended key usage.
Reducing Blast Radius Through Cryptographic Isolation
Even with strong trust boundaries and network segmentation reinforced by IAM identity boundaries, always assume that workloads can reach other workloads. AWS KMS architecture further reinforces AWS workload segmentation by establishing cryptographic trust boundaries. It achieves this by applying separate KMS keys to each workload and applying IAM identity boundaries to these keys. Dedicated KMS keys for each workload reduce the impact of workload compromise. Correspondingly, independent IAM identity boundaries around KMS keys reduce the impact of compromised credentials. This further reduces the blast radius of either compromised workloads or compromised KMS keys.
AWS KMS Authorization Architecture: Key Policies vs IAM Policies
AWS KMS Architecture Two-Layer Authorization Model
KMS keys are AWS resources that support resource-based policies, similar to several other AWS services. However, unlike other AWS resources, KMS key resource policies are mandatory and not optional, no policy, then no access. Because KMS keys are critical to the cryptographic security layer, the KMS key architecture reinforces access control to KMS keys. It manages access to KMS keys using both IAM identity boundaries and KMS key policies. Understanding how identities, roles, policies, and permission boundaries participate in authorization decisions is equally important when designing secure AWS environments. For a deeper discussion, see AWS IAM Architecture: Designing Identity Boundaries at Scale. This creates a two-layer authorization model requiring both IAM permissions and KMS key policies to authorize cryptographic operations. It further separates key ownership from identity management, reinforcing cryptographic trust boundaries.
How AWS Evaluates KMS Permissions
KMS key policies, along with IAM role policies, provide defense-in-depth where AWS must evaluate both before granting access. Because KMS keys are critical to AWS security, their permission evaluation process is more prominent and restrictive than that of many AWS services. KMS key policies have explicit authorization requirements where entities must be granted explicit access, and denial is the default security model. This is combined with IAM role policy evaluation to grant access to the KMS key, ensuring multiple layers of authorization enforcement. This is critical when preventing unintended key usage.
Delegation and Governance Through Key Policies
Given the critical roles of KMS keys in AWS security, it is essential to govern access to these cryptographic resources. This includes using KMS key policies to control resource ownership and authority delegation with fine-grained control over cryptographic operations. These policies should also separate principals according to their administrative and operational duties. They enable independent management of key administrators and key users while restricting both key administration privileges and key usage privileges. This enables the architecture to enforce governance at the cryptographic layer and centralize governance of encryption resources. This allows monitoring and auditing of cryptographic resource access alongside centralized control of those resources.
Common KMS Policy Mistakes
Strong reinforcing policies help strengthen the protection of KMS keys from unauthorized access, but are insufficient due to poor policy implementation. Implementing certain key policies ends up weakening key access safeguards, exposing encrypted resources to potential attacks. Overly permissive key policies grant access to principals who have no need for access, increasing the attack surface for encrypted resources. Wildcard permissions can make it difficult to enforce least-privilege access principles and may unintentionally expand access to cryptographic resources, granting either key or resource access. Another issue is the poor separation of duties, where resource users have administrative privileges or administrators have access to resources. These potentially increase the blast radius from key compromise and weaken cryptographic trust boundaries.
Logging, Monitoring, and Governance for AWS KMS
CloudTrail and Cryptographic Audit Trails
Multi-layer authorization models are critical for protecting KMS keys. However, it is naive to assume that they are never exposed to unauthorized access. KMS architecture must include an observability layer for defense-in-depth to respond to events involving KMS keys. Observability is also needed for auditing their usage and maintaining minimum privileges due to usage-pattern drift. AWS CloudTrail is integrated with AWS KMS and logs encryption, decryption, and GenerateDataKey requests. It also logs key creation and deletion, as well as key policy modifications and administrative events. Furthermore, it provides traceability of cryptographic resource access, supporting security investigations and forensic analysis.
Monitoring KMS Activity with CloudWatch
Monitoring is a key component of observability, providing operational visibility into cryptographic activity and enabling alerting on unusual KMS activity. AWS integrates Amazon CloudWatch with AWS KMS to monitor KMS service metrics and KMS API activity. Additionally, it monitors key usage trends and encryption and decryption activities. It applies threshold-based monitoring to detect abnormal usage patterns and spikes in cryptographic operations. Furthermore, it integrates with incident response systems that respond to any alerts, allowing early detection of potential security issues.
Detecting Threats with GuardDuty and Security Hub
AWS CloudTrail and Amazon CloudWatch are important observability components with limited detection. However, observability requires more rigorous detection and centralized monitoring aggregating logs and metrics. Amazon GuardDuty provides sophisticated threat detection capabilities to detect suspicious AWS KMS activity, unusual key usage patterns, and anomalous cryptographic operations. Additionally, it integrates threat intelligence with KMS observability data to provide continuous security monitoring. Security Hub aggregates security findings that consolidate KMS-related findings. It provides centralized visibility across AWS services and enables cross-service security correlation. Both GuardDuty and Security Hub provide integrated incident response and incident investigation support.
AWS KMS Architecture Governance, Compliance, and Continuous Assurance
Many organizations operate in regulated environments, making governance of KMS keys mandatory since they protect critical resources. They require centralized oversight of AWS KMS activity to satisfy compliance reporting and regulatory audit requirements. Additionally, governance provides continuous assurance of encryption controls by collecting compliance evidence and verifying the effectiveness of cryptographic governance controls. This is achieved by monitoring key lifecycle activity, key creation events, key rotation events, and key disablement and deletion events. Significantly, this also includes changes to KMS key policies and authorizations. Overall, governance enables continuous validation of security architecture.
Common AWS KMS Architecture Design Mistakes
Cryptographic boundaries make a critical layer of the defense-in-depth of AWS resources. However, poor practices can significantly weaken this layer, increasing exposure of resources to hostile attack.
Over-Centralizing KMS Keys
Single KMS keys that protect multiple workloads grant principals access to workloads that they do not need to access. This leads to excessive key reuse, reduces workload isolation, and increases their attack surface area. This also expands the blast radius since there is lateral movement between workloads encrypted by the same key. It also increases governance complexity in managing multiple workloads encrypted by the same key.
Weak Authorization and Policy Boundaries
This increases the vulnerability of KMS keys by granting resource access to principals that do not require access. These include overly permissive key policies that allow principals to perform key operations they do not need to. Significantly, not only do wildcard permissions grant access to unauthorized principals to keys, but there is no way of knowing which principals have access. This significantly increases the attack surfaces and results in poor governance controls.
Excessive Cross-Account Key Access
This acts to significantly undermine trust boundary separation instead of reinforcing it. By implementing broad cross-account permissions, it establishes unnecessary trust relationships. This weakens trust boundary enforcement by providing lateral movement across trust boundaries. This lateral movement expands the blast radius, allowing compromised workloads to attack workloads in other trust boundaries. Another consequence is allowing unauthorized access to shared services, making them vulnerable to attack by malicious actors.
Assuming Encryption Alone Provides Security
This is likely to be the most dangerous architectural mistake to make, where the whole burden of securing the environment falls upon encryption. There is no defense-in-depth provided by fault isolation boundaries and trust boundaries preventing lateral movement of compromised workloads. There is additional dependence upon IAM controls, monitoring, governance, and auditing. Encryption becomes the sole security layer, and any compromise of KMS keys exposes the entire infrastructure to attack by malicious actors.
Conclusion
AWS KMS key architecture is foundational to the overall AWS security architecture. The encryption layer that it establishes serves to reinforce the other security layers and increase the defense-in-depth of the AWS environment. This encryption layer consists of cryptographic trust boundaries that extend trust boundary resource and workload isolation through encryption. This further reduces the blast radius through cryptographic segmentation by assigning different KMS keys to different workloads. Additionally, key management is separated from workload access, separating principals according to their duties, simplifying access management. It also integrates KMS key access with identity and authorization controls and sets up multi-layer access, further protecting KMS keys. KMS key architecture establishes a governance-driven encryption architecture providing consistent protection across AWS workloads.
Encryption governance involves KMS keys that are cryptographic resources and extends beyond encryption enablement. It establishes authorization controls for cryptographic operations and enforces key usage auditing and administrative actions. This also includes monitoring of cryptographic activity. These measures provide continuous assurance of encryption resources by verifying the effectiveness of their security controls. This is achieved by integrating encryption with identity controls, monitoring and detection, and operational governance. Another important aspect of governance is observability, which provides centralized visibility into cryptographic resources. It also enables compliance reporting and collection of audit evidence to satisfy regulatory requirements. AWS KMS key architecture also aligns with enterprise risk management and complements AWS Organizations and SCP governance models. It is an essential pattern within governance-driven cloud security architecture.
Further Learning
Recommended AWS Security Resources
AWS Security learning paths on Pluralsight
AWS Certified Security Specialty Study Guide
Disclosure: Some of the resources recommended in this article contain affiliate links. As an Amazon Associate, AI Cloud Data Pulse earns from qualifying purchases. We may also earn commissions from partners such as Pluralsight when readers purchase products or services through our links. This comes at no additional cost to you and helps support the continued publication of independent cloud security, cloud architecture, and AI education content.
