Useful resource, IAM, and Belief Insurance policies on AWS | by Teri Radichel | Cloud Safety | Aug, 2022

August 9, 2022

1

ACM.24 Architecting protection in depth AWS insurance policies.

In our final publish we created the KMS key and a key coverage that defines who can entry and carry out actions with or on that KMS key. We allowed an IAM function to manage our key and we granted a person permission to imagine and use that function for administration.

Whenever you design your AWS insurance policies, it’s essential contemplate the implications of how these insurance policies work collectively. Utilizing totally different insurance policies managed by totally different folks leverages the idea of separation of issues or segregation of duties. That approach if one individual’s credentials get stolen you continue to could possibly forestall an attacker from taking up the entire system.

Utilizing a number of safety controls to guard information is a part of a protection in depth technique. That’s a standard time period in safety which I described in my guide on the backside of this publish in the event you’re not acquainted.

Let’s evaluation the varieties of insurance policies we simply created and contemplate further insurance policies we may have as we full this structure.

Useful resource Insurance policies: The coverage related to our KMS secret is a useful resource coverage. The coverage is related to a useful resource and defines who can entry that useful resource. The useful resource coverage doesn’t give the identities included within the useful resource coverage permission carry out the actions (in different phrases to name the AWS APIs) to take these actions on the useful resource. It solely says that if they’re performing these actions the useful resource will enable it.

IAM Insurance policies: In the event you’ve ever taken certainly one of my cloud safety courses you most likely heard me say that each motion within the cloud is an API name. Whether or not you’re clicking a button, utilizing a CLI, or an SDK, or calling the API straight, the cloud platform (AWS, GCP, or Azure) is more than likely making an API name in your behalf to take some motion within the cloud. IAM Insurance policies provide you with permissions on AWS to make these API calls.

You may learn extra concerning the distinction between useful resource and IAM insurance policies right here:

All of the actions you may tackle AWS for every service ought to be listed right here:

Our key will enable the required roles to take actions with or on it, however we have to create an IAM Coverage for every person or function to permit it to take these actions. As well as the Useful resource Coverage wants to permit the person to entry the useful resource.

Belief Insurance policies (AssumeRolePolicyDocument in CloudFormation): A belief coverage on an AWS IAM function defines who can assume that function. You may require the one who can assume that function to be authenticated with MFA.

You an additionally apply different situations reminiscent of which IP handle the person is coming from and different restrictions utilizing AWS Circumstances. I defined what these are and the way they work right here if you wish to discover about extra concerning the totally different situations you may add to insurance policies on AWS:

I defined the distinction between an IAM Managed Coverage and an IAM Coverage when deploying a coverage utilizing CloudFormation in a previous publish as effectively. It actually has to do with the connection of a coverage to an id. Make sure you deploy the proper sort relying on what kind of relationship you require.

Future insurance policies in our batch job structure

Now we have to contemplate how we are going to implement the insurance policies for the identities which can be allowed to encrypt and decrypt credentials used to start out batch jobs, and the information related to every batch job. We’re most likely going to wish to make use of some S3 buckets so we are going to affiliate useful resource insurance policies with our buckets and permit IAM roles to entry the information in these buckets. Some lambda features will possible be concerned which might want to get hold of permissions by means of an IAM function. AWS Batch will even use IAM roles.

Within the administrator coverage, we allowed the administrator to behave on any key within the account. For our encrypt and decrypt customers we wish to restrict them to utilizing this particular key for credential storage and retrieval associated to a specific batch job to cut back information publicity within the occasion of stolen credentials. That was coated in prior posts the place I used to be pondering by means of the structure and design I want to guard the information.

We are able to limit AWS IAM Insurance policies to particular sources, reminiscent of permitting an id to take actions on a selected KMS key or a selected S3 bucket.

We deployed two roles for encrypting and decrypting the secrets and techniques used to imagine our batch job roles. What permissions do we have to add to every function? By decreasing insurance policies to solely what an id must do and limiting entry to solely the sources the id ought to be utilizing, we scale back the potential injury misplaced or stolen credentials can do. We wish to solely present the permissions required, however first we have to assume by means of what these two roles have to do and entry.

Function: BatchRoleDeployBatchJobCredentials

Run CloudFormation Script to create AWS Secret Key and Entry Key for our IAM person
Run CloudFormation Script to create Secrets and techniques Supervisor Secret
Assign the Encryption Key in our CloudFormation script to the Secret Supervisor Secret and retailer the key

We could create a selected job with particular permissions and a selected function, or we may give our deployment system permission to deploy something in any account. Which do you assume is much less dangerous? Which might be simpler to handle? How can we scale back our overhead whereas sustaining restricted permissions?

Function: RoleTriggerBatchJob

Our function that triggers the batch job wants to have the ability to do the next:

Retrieve a selected Secret from Secrets and techniques Supervisor
Decrypt the key
If we create a single function batch job or lambda perform we are able to restrict its entry to a selected secret and KMS key.
Will this function have entry to all of the credentials to start out a batch job or will we create a separate function and performance for every job?

I’ll cowl a few of these questions in upcoming posts. There’s no single reply however we are able to attempt to assume by means of find out how to forestall entry to information. We will even contemplate how entry to information alone will present restricted worth to an attacker by means of segregation. Moreover, I’ll present you some instruments and methods to assist create a zero-trust coverage.

Teri Radichel

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

Medium: Teri Radichel or E-mail Record: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers through LinkedIn: Teri Radichel or IANS Analysis