Secure data with KMS and scale AWS access management

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 Deny any 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 NarrowerKeyPolicy:

The NarrowerKeyPolicy‘s AllowFullAccess statement permits full access by the appA and 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:

The LeastPrivilegePolicy allows 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 DenyEveryoneElse statement.

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 access control mechanism for all AWS data services.

Leverage.

Figure 1: Secure access to entire data domain with KMS resource policy

The Partition Data with Encryption security architecture pattern partitions and controls access to an entire data domain.  This pattern secures data with KMS 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: Decrypt
• 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.

Summary: Secure data with KMS

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.