AWS - Basic Security Considerations

Often the default Security rules in AWS allow highest level of access and this is undesirable in production system. Principle of Least access is the recommended security approach for any secure system. 

This article explains how we can apply some specific Security rules to various resources in AWS.

Access to EC2 instances

---

Do not provide SSH access to EC2 instances in public subnet, which are exposed to outside world. Rather, create a separate EC2 instance which will act like a Bastion server. Let us call the security group associated with this Bastion server as ‘BastionSG’. 

The ‘BastionSG’ should have a security group which will allow a specific IP or a range of IP in corporate network via SSH for allowing inbound access.

Expose SSH from all EC2 instances only from the Bastion server by providing the ‘BastionSG’ as the source Security Group.

Access to VPC

---

By default, a VPC will have a NACL(Network Access control) which allows traffic to all. We can create a custom NACL which will restrict traffic.

For example following diagram shows a custom NACL which allows only a range of IPs for SSH access.

EC2 instance to another EC2 instance

---

When one EC2 instance communicates with another, we can use Security Groups to restrict access. Security Groups act like firewall to the EC2 instances and will control how is the service accessed? (Source IP, Port, Destination port). We can specify the source as an IP, range of IP or another Security Group.

Let us say from EC2 instance we deploy an application and on the another EC2 instance, we deploy a PostGres Database. Now the application EC2 instance will need to connect to the EC2 instance having PostGres.

We can create a security group for the application EC2 instance and create another Security Group for associating with the PostGres EC2 instance. The source for the PostGres EC2 instance should be the application instance Security Group as shown in below diagram.

EC2 instance to other AWS services

---

IAM roles could be used to trust entities while communicating between services.

Let us say from EC2 instance, we are communicating to a SQS queue. Instead of saving the SQS access keys onto the EC2 instance, it is better to create an IAM role specific to this communication. 

Also, if we have one EC2 instance which will read from the queue and one EC2 instance which will write to the queue, we can create two IAM roles to achieve this and attach them to each of the EC2 instances respectively.
We can create an IAM role EC2ToSQS Read which will allow the EC2 instance to read from the SQS queue. Note that we need to create a Custom policy to get fine grained control over this access. The default policies allow sqs:* which allow all operations on SQS (The only differentiation is admin or read only).

We can follow below steps to create and associate IAM Roles:

Create IAM Role:

1. Create an IAM role ‘EC2ToSQSRead’
2. Select EC2 as the Service.
3. Save the IAM role. We will come back to this role after creating the policy.

Create Policy:

• Create a policy
• Choose ‘SQS’ as the Service.
• Since we are interested in reading from the queue, let us chose ‘ReceiveMessage’ access level.
• Chose ‘Specific’ in the resources and Add an ARN for finer control. Here default is ‘arn:aws:sqs:::’ which again allows access to all accounts.  We can provide which account, Region, queue it is allowed to access

The policy json would like the below:

Now we can go back to the IAM role and attach the above policy to it. This IAM role could be attached to the EC2 instance.

Similarly, we can create another policy/role for SQS Write access and attach it to another EC2 instance.