Photo by Deleece Cook on Unsplash

Layered security in AWS — Introduction

Success to a good cloud platform is based on solid security foundation that it is built upon. Securing a cloud environment is a vast domain. Broadly we can break the AWS security posture in four areas.

Account Level Security — SCP, whitelist whether an AWS Service can be consumed in a account(s).

Service Level Security — Whitelisted Service APIs that can be consumed by a BAU principal. How service can interact with each other i.e. Service linked role.

Resource Level Security — What resource of whitelisted services can be used. resource/bucket/queue policy etc.

Application Level Security — Privilege given to application that is inside the resource can be some code running inside EC2 or a container or a application inside Beanstalk or EMR.

Let us walk through a simple example to demonstrate how we can build a layered security architecture. In our example we have an EC2 that will be reading and writing to an S3 bucket.

At the outset it looks very simple and straightforward. Lest look the same from an AWS security constructs point of view.

In the above image I have added labels to security related objects. We will discuss it one by one.

1. Instance Role (IAM)— This role is is assigned to the EC2 instance. This role contains all the access that the instance needs. Here it has access to S3 and KMS. Now the important thing that need to be highlighted that since this role is for EC2 we should restrict its use to within VPC or via endpoints. This ensures that if some how anyone gets hold of the EC2 credentials from lets say instance metadata and try to use it outside of VPC then that will be denied. To do so we add following policy to the role.

Note: I have added viaService condition in KMS policy statement, this is to make sure s3 is able to call KMS. If KMS is being called by S3 service itself at that time the request won’t go through endpoint (its a S3 service calling KMS both are not bounded in VPC).

2. KMS Policy (resource policy)— Its a good practice to separate responsibility by moving KMS key creation to a separate account and then delegate access to the target account for consumption. KMS key policy delegates key usage to the account and in turn to the IAM role that the instance is using. This way the key has a different lifecycle control(creation and deletion access is in KMS key account ) and can be taken care by separately. Usage is delegated and on on need basis.

3. S3 VPC endpoint & Endpoint Policy— This is being used by EC2 instance in private subnet. This ensures traffic never leave AWS network. Policy on the endpoint ensures that EC2 can only read and write from S3 bucket using the same accounts access point.

4. VPC Access points — This ensures that buckets are only accessed if the request is coming from VPC as we have created the access point with Network Access Type set to VPC. One thing interesting in this is, access point contains region and account id. This is useful as in S3 bucket ARN we don’t get Account Id so it becomes a slight challenging in restricting access from buckets in specific account.

5. Bucket Policy — This policy locks down the bucket access to a specific VPC. This ensures that no resource outside of VPC can access contents of the bucket.

0. SCP — Yes you read it correct I mentioned it as zero. This is coz the SCP allows us to control the boundary or context under which the resources like Access points, S3 bucket and other resources are created.

This was a very basic example where we put in place security mechanism at resource, service and account level. Also we only discussed Policy level controls network level security will be discussed in another post.

Happy Security!!