Secure data in AWS with Key Management Service (KMS)
AWS Key Management Service (KMS) is a fully managed encryption API and key vault. KMS exposes encryption operations like encrypt, decrypt, sign, and verify as APIs for use by your applications and by other AWS services. When you encrypt data in AWS data services like S3 or SQS, KMS is the service that safely performs those operations on your behalf. KMS integrates with many AWS services, currently 66. Most engineers’ first encounter with KMS is to satisfy a requirement to encrypt data at rest, but you can take it much further.
This guide explains core KMS concepts and shows how to encrypt your data and scale your data access management uniformly across disparate data services.
Core Concepts & Resources
Encryption keys are the foundational resource of KMS, and are called customer master keys (CMKs). A customer master key resource has data components to support encryption and decryption operations. A CMK also has metadata that identifies the key and a lifecycle to help you manage it.
KMS supports two types of customer master keys:
- AWS managed CMK: a key created automatically by AWS when you first create an encrypted resource in a service such as S3 or SQS. You can track the usage of an AWS managed CMK, but the lifecycle and permissions of the key are managed on your behalf.
- Customer managed CMK: a key created by an AWS customer and used for their specific use case. Customer managed CMKs give you full control over the lifecycle and permissions that determine who can use the key and under which conditions.
Some people are satisfied by encrypting data with an AWS managed CMK. An AWS managed CMK is used when you tell S3 or another data service to encrypt your data, but you don’t specify a key. These keys have key aliases with friendly names like
aws/s3. Indeed this does encrypt your data at rest. This encryption protects your data from such threats as an AWS datacenter employee ripping a drive out of a server and walking out the door. However this may not be the information security threat you should worry about.
What encryption with AWS managed CMKs does not prevent is a person or application with credentials for your account from reading encrypted data using AWS APIs. Since the permissions of the (AWS-managed) key are managed on your behalf, you cannot control what IAM principals within an account have access to use these default keys. All IAM principals have full access to AWS managed CMKs in the account unless denied by IAM.
A customer managed CMK is different. You create customer managed CMKs and control who may use them. This gives you the ability to scope access to data arbitrarily by encrypting that data with a customer managed CMK and configuring the key’s resource access policy to your liking.
KMS Key Resource Policy
KMS key policies look like any other AWS resource access policy. Here is the default key policy applied to a customer managed CMK:
The default key resource policy:
- explicitly allows the AWS account full access to administer and use the key
- implicitly allows any IAM principals permitted to use the KMS API via IAM policies to use the key
- does not
Denyany IAM principals the ability to use the key
This is effectively the same level of access control as an AWS managed key.
Suppose you wanted to narrow this keys usage to only the
appA IAM role and
ci IAM user. You could update the policy to this
AllowFullAccess statement permits full access by the
ci principals. This policy also
Denys access to all other principals. This
DenyEveryoneElsestatement closes off access to incidental access granted implicitly using IAM policies attached to principals in the account.
This policy provides you a step towards least privilege. You may want to refine the policy further. It’s probable that the application does not need to administer the key with the
appA role. You could create a statement that only gives
appA privileges to encrypt and decrypt data. You could also create a statement that allows
ci the ability to administer the key. That key policy could look like one generated by k9 Security’s Terraform module for KMS:
ci to administer the key,
appA to read and write data with the key, and
person1 to administer, read, and write. Everyone else is denied access to use the key by the
Now let’s leverage this knowledge to manage access to data in multiple data stores using encryption key access policy.
Pattern: Partition Data with Encryption
Here’s where access control gets exciting. You can think of KMS resource policy as a composable access control that is usable from any other AWS data service.
KMS provides a composable, scalable, uniform mechanism for controlling access to data across data stores.
Once you learn how to use KMS resource policies effectively, you can use encryption keys and key resource policies as a uniform core access control mechanism for all AWS data services.
Figure 1: Manage access control for entire data domain using KMS
The Partition Data with Encryption security architecture pattern partitions and controls access to an entire data domain by encrypting that domain’s data with a dedicated customer managed KMS encryption key and applying a key resource access policy that is appropriate for the people and applications in that domain. A data domain encompasses the data managed by a single service or collaborating set of microservices such as ‘credit-applications’ or ‘orders’ (c.f. Bounded Context). This pattern centralizes data access control for the domain. It also injects resource access policy capabilities into data services that do not support that directly such as Elastic Block Store and Relational Database Service.
This pattern provides several benefits:
- Manage data access uniformly across disparate data services
- Simplify architecture, development, and audit processes with a consistent access control strategy
- Reduce access policy language knowledge and implementation requirements
- Explicitly controls access to data even when the AWS data service does not support resource policies
How it works
In order for a person or application to read and write data to an AWS data store, their IAM principal must also have access to use the KMS key needed for those operations. This makes customer managed encryption keys a convenient point of access control.
For example, when an IAM user reads encrypted data from S3 using the
s3:GetObject API, the user also needs permission to call
kms:Decrypt with the key used to encrypt the data. In this scenario, the S3 service invokes
kms:Decrypt on the IAM user’s behalf. If the user has permission to call
kms:Decrypt with the required key, then the
s3:GetObject operation can proceed. Without decrypt permissions for the key, the
s3:GetObject will fail.
The KMS API has a small set of actions relevant to reading and writing data via another service:
- Read data:
- Write data:
Encrypt, GenerateDataKey, GenerateDataKeyPair, GenerateDataKeyPairWithoutPlaintext, GenerateDataKeyWithoutPlaintext, ReEncryptFrom, ReEncryptTo
You can control access to an entire data domain by encrypting that data with a dedicated CMK and applying a key policy that both allows and denies access to the key’s read, write, and administration operations.
The Partition Data with Encryption pattern helps you manage and audit access to the data in each domain with a canonical key resource access control policy. The key resource policy clearly identifies who and what kind of access is allowed to the domain’s data. This policy is better positioned to prevent unauthorized access in the domain compared to getting every related data service’s resource policy and every IAM policy correct. Security policies attached to IAM principals can be treated as secondary security controls that enable the authorized access rather than prevent unauthorized access.
AWS’ Key Management Service provides powerful APIs to control access to data across all AWS data services. Use customer managed encryption keys to encrypt data for distinct data domains in your organization so that you can manage access to that data in a uniform, scalable way.
Please contact us with questions or comments. We’d love to discuss AWS security with you.