Buyer-Managed KMS Keys vs. AWS Managed Encryption | by Teri Radichel | Cloud Safety | Nov, 2022

November 21, 2022

1

ACM.118 Why may you select to make use of a customer-managed key to guard your cloud assets

It is a continuation of my collection on Automating Cybersecurity Metrics.

Code within the final publish robotically stops a VM after deploying it to assist get monetary savings when assets are created earlier than they’re wanted to be used.

This publish supplies a abstract of what has been coated in different posts to reply the next query:

Why would you wish to use a customer-managed key as a substitute of an AWS-managed key?

Making use of encryption in and of itself doesn’t shield your assets. Think about the next:

Who has permission to make use of the encryption key that encrypted the assets. Anybody who has permission to make use of the important thing can decrypt and entry the info. That features anybody who steals the credentials.
Who has permission to alter or grant new permissions to make use of the important thing and entry your encrypted assets.

I began pondering by means of how we’d defend in opposition to these threats on this publish on cloud structure and KMS keys.

One of many advantages of utilizing your personal customer-managed key as a substitute of an AWS-managed secret’s which you can create a key coverage for a customer-managed key to restrict who has permission to encrypt and decrypt knowledge utilizing that key. That limits your threat vs. granting anybody in your account permission to decrypt knowledge encrypted with the default AWS encryption.

To know the advantages of a KMS key coverage you first want to know the distinction between IAM and Useful resource insurance policies.

IAM vs. Belief vs. Useful resource Insurance policies on AWS

The next publish explains the distinction between IAM, Useful resource, and Belief insurance policies on AWS. In a nutshell, IAM Insurance policies grant permission to a consumer to take actions. A useful resource coverage provides entry controls to a useful resource like a KMS key and defines who can entry and take actions on the useful resource. A belief coverage permits a consumer to imagine a job that’s allowed to take actions within the IAM Coverage assigned to that position.

Why would you wish to use each an IAM and a useful resource coverage to restrict entry to make use of a KMS key? You may grant totally different folks permission to alter the IAM and useful resource insurance policies to create separation of duties and a number of layers of safety. Preserve studying for concrete examples of implement segregation of duties in your AWS account. It’s not precisely easy when you get into the weeds of how the totally different insurance policies work collectively and nuances of insurance policies you may create for various AWS providers that may work with KMS keys.

By leveraging separation of duties you may restrict the prospect that one individual makes a mistake and exposes your knowledge. You may as well be certain that a single malicious insider alone can not expose your knowledge. If one individual’s credentials get stolen that won’t be sufficient to entry the info.

IAM Insurance policies assign permissions to a principal

To ensure that a “principal” in AWS to make use of a KMS key to encrypt and decrypt knowledge, an related IAM coverage must grant them permission to take action. (Principals are outlined within the above publish.) The coverage defines the actions they’ll take and the assets on which the consumer can take the actions.

We granted customers permissions to entry the KMS service and particular Keys in IAM Insurance policies all through the collection. We began by making a KMS Administrator position and IAM Coverage.

The KMS administrator has an IAM Coverage that enables the consumer to manage KMS keys however to not use them to encrypt or decrypt knowledge. So even when the KMS administrator grants themself permission to encrypt and decrypt their IAM coverage gained’t permit it. That is helpful you probably have separate IAM and KMS directors.

Useful resource insurance policies grant entry to a useful resource

A KMS key coverage is a useful resource coverage. While you create a buyer managed key on AWS you may affiliate a coverage with it that defines who can take actions on a key.

You can not modify a useful resource coverage on an AWS managed key. From the AWS documentation:

You may view the important thing coverage for an AWS managed key or a buyer managed key, however you may solely change the important thing coverage for a buyer managed key.

Why may you wish to use a KMS key coverage? I began addressing this query within the following publish the place we outline necessities for separation of duties in our AWS account.

How can we meet the above necessities? We will use a mixture of IAM and useful resource insurance policies. With a purpose to stop coverage errors we are able to attempt to create reusable templates and completely take a look at them.

A generic KMS Key CloudFormation template

I developed a generic CloudFormation template that will deploy and key and a key coverage for all of the keys in our account. My code additionally comprises deployment scripts and customary capabilities to cut back the traces of code we have to deploy our answer.

Right here’s our place to begin, although the code modifications all through the collection to help further use instances.

I refined the code right here:

The CloudFormation template obtained many modifications in later posts an the present model will be present in GitHub right here.

The associated deployment scripts are within the mother or father folder. Key aliases are in a sibling folder. Widespread capabilities are within the root /Capabilities folder. You’ll want that for this template to work as designed.

Learn all of the posts to know how the code works and any dependencies. I’m not re-explaining all that right here.

Key Aliases for Buyer-Managed Keys

You may identify buyer managed keys. This helps you extra simply establish an encryption key and its objective.

We created KMS Key Aliases on this publish.

KMS and Programs Supervisor Parameter Retailer

AWS Programs Supervisor Parameter Retailer has a restricted useful resource coverage that doesn’t embody entry controls on the time of this writing. I wrote about utilizing KMS with AWS SSM Parameter Retailer right here:

Somebody made an odd touch upon this publish. They stated AWS can not see your encryption key. Okay, however that wasn’t what this publish was about. I revisited the publish and unsure why the individual made that remark. For the file, I by no means stated AWS can see your encryption key or your knowledge.

Nonetheless, anybody who has kms encrypt and decrypt permissions in an IAM coverage with no useful resource restrictions can encrypt and decrypt something encrypted with AWS encryption. In different phrases, somebody has kms.* and useful resource: * in an IAM Coverage they’ll encrypt or decrypt something in your account encrypted with AWS-managed encryption.

In the event you use a customer-managed key and add a useful resource coverage to the important thing limiting who can use it, the individual with full KMS permissions of their IAM Coverage wouldn’t be capable of use the important thing to encrypt or decrypt knowledge with that key.

Parameter Retailer doesn’t provide the identical degree of entry management as AWS Secrets and techniques Supervisor and KMS. The latter two providers provide useful resource insurance policies that let you outline entry restrictions on the assets managed by that service, in addition to IAM coverage restrictions. SSM Parameter Retailer insurance policies don’t provide the identical entry controls. (on the time of this writing — that might change any minute now.)

Right here’s what we’ve proper now per the above documentation:

Parameter Retailer parameters can not at present be shared throughout accounts as you are able to do with Secrets and techniques Supervisor.

KMS and Secrets and techniques Supervisor

A lot of posts within the collection cowl use AWS Secrets and techniques Supervisor with KMS.

You may restrict entry to a KMS key solely when utilizing AWS Secrets and techniques Supervisor in your KMS key coverage:

We later modified that coverage to work with different providers like EC2 and KMS immediately. See the examples on the backside of this publish.

We moved the SSH key saved in SSM Parameter retailer within the above publish to Secrets and techniques Supervisor protected with a KMS key right here:

In the event you learn by means of these posts you may see a few of the detailed variations between AWS SSM Parameter Retailer and AWS Secrets and techniques Supervisor.

You may implement separation of duties utilizing IAM and Useful resource Insurance policies

In the event you leverage IAM and Useful resource Insurance policies you may create separation of duties inside your cloud account to restrict blast radius within the occasion of a safety incident. I clarify blast radius in my e-book on the backside of this publish. I current architectures within the examples beneath that try and create separation of duties to guard encrypted assets in your AWS account.

Instance 1: Creating Automation Credentials With out Exposing Them to Customers

We will overcome some KMS limitations with encrypt and decryption utilizing Secrets and techniques Supervisor useful resource insurance policies. Though we should grant encrypt and decrypt permissions sadly as a result of approach AWS works, in Secrets and techniques Supervisor we are able to use a useful resource coverage to restrict who can get or put a secret.

The above publish additionally leverages the very fact we are able to create a secret in CloudFormation — one thing that you simply can not do the identical approach for the time being with Parameter Retailer (however once more that will change any minute).

Instance 2: Making a Person-Particular Secret

As a case research in segregation of duties for secrets and techniques I began exploring making a user-specific secret that solely a single consumer can entry.

First we regarded on the IAM Insurance policies required to create the key and get the key.

I began pondering how we’d go about implementing segregation of duties right here however this wasn’t fairly sufficient.

We checked out KMS encryption and MFA for the Developer consumer accessing the key right here:

In these publish we checked out how we’d create a separate consumer or position to handle the key insurance policies. We already had an IAM administrator to handle IAM insurance policies an a KMS administrator to handle Key Insurance policies.

Lastly, we refined our insurance policies to create a state of affairs the place we’ve employed separation of duties in such a approach that it will take a three-party collusion to acquire unauthorized entry to a secret. No ensures as I’m not by means of testing, however hopefully it demonstrates the idea.

We granted a consumer entry within the console to entry a secret so we may implement MFA with a user-specific coverage.

In the event you learn by means of all of the posts you can see that there are limitations with MFA enforcement relying on what kind of credentials are in use to carry out an motion. The AWS documentation on situation insurance policies is a bit deceptive. So we ended up with a user-specific coverage and console entry for the second (till hopefully a few of the above points are resolved by AWS doubtlessly.)

I didn’t spend an excessive amount of longer on this as a result of I additionally plan to maneuver issues into separate accounts which can make issues simpler. Extra on that later.

Instance 3: Auto-generated passwords for Console Entry

I explored auto-generating and storing passwords for console entry.

This one got here with some challenges that make it not a great answer because of AWS limitations. I’d revisit this later and put this secret in Parameter Retailer as I plan to maneuver IAM to it’s personal account. Nobody in one other account may entry the secrets and techniques within the IAM account and the IAM customers won’t be able to login to the AWS console in different accounts. I must implement and take a look at that to confirm it really works as I feel it should.

Instance 4: Creating an EC2 occasion solely sure folks can begin

We created an EC2 occasion with the most recent Linux AMI.

We added an Encryption Key.

We granted the consumer entry to make use of the important thing in a key coverage. With out that permission they can’t begin an encrypted EC2 occasion. So one approach to solely permit sure customers to start out an EC2 occasion is to restrict entry to who can use the encryption key.

After all that isn’t the one approach to prohibit entry however it will probably assist you to when designing separation of duties in your AWS account.

In the event you solely verify the field to encrypt your EC2 occasion with the AWS-managed key, then anybody within the account with generic KMS encrypt and decrypt permissions can begin the occasion and entry the info.

Management Key Rotation with Buyer-Managed Keys

The opposite factor you are able to do with a buyer managed key which you can’t do with a KMS managed secret’s management your key rotation coverage.

AWS KMS robotically rotates AWS managed keys yearly (roughly 12 months). You can not allow or disable key rotation for AWS managed keys.

Quotas

AWS-managed encryption keys don’t depend in opposition to your KMS quotas.

Cross-Account Entry

You may grant cross-account entry to a customer-managed key.

That is one thing I’ve undoubtedly discovered helpful prior to now and can be exploring extra all through this publish.

Regional Entry Limits with Buyer Managed KMS keys

You may restrict which keys a key could also be utilized in or use keys in cross-region situations with KMS customer-managed keys.

You’ll have extra granular management of precisely the place a secret’s in use. This can be helpful for organizations making an attempt to adjust to GDPR. If a KMS key can’t be used exterior of a area then that may assist restrict knowledge migrating to a area in AWS the place it mustn’t exist. It’s actually not the one management you will want however it might assist.

Hopefully that provides you some concepts about why you may wish to use a customer-managed key with a customized key coverage on AWS.

Within the subsequent publish I’ll summarize a few of the variations we’ve uncovered thus far between Secrets and techniques Supervisor and SSM Parameter Retailer.

Observe for updates.

Teri Radichel

In the event you favored this story please clap and observe:

******************************************************************

Medium: Teri Radichel or Electronic mail Checklist: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers through LinkedIn: Teri Radichel or IANS Analysis

******************************************************************

All of the posts on this collection:

____________________________________________

Writer:

Cybersecurity for Executives within the Age of Cloud on Amazon