Daniel Mastrorillo
Daniel Mastrorillo

Reputation: 161

AWS - Are security groups enough or is there a need for private and public subnets?

Let's suppose I have a web server which is an EC2 instance and an RDS.

The EC2 instance communicates with the RDS.

For security, I could have this set up behind an Application Load Balancer and use security groups to only allow inbound traffic through the ALB. The ALB will communicate with the internet only through HTTPS.

Internally I could set up a security group that accepts only incoming traffic from the security group of the ALB. I would attach this security group to the EC2 instance. I could then have another security group that allows incoming traffic only from the EC2 instance. This security group would be attached to the RDS.

The security group of the EC2 instance would allow outbound traffic over HTTPS for the purpose of updates, downloading packages, etc.

From my (limited) understanding of how this setup would work, communication with the RDS would have to happen strictly from the EC2 instance and inbound communication to the EC2 instance would have to happen strictly from the ALB which is configured to accept only requests through SSL.

In terms of security, is this setup safe?

What risks are there from running a set up like this?

What benefits, if any, are there from configuring private and public subsets like is shown here?

Upvotes: 3

Views: 1340

Answers (2)

John Rotenstein
John Rotenstein

Reputation: 269101

It all depends upon your risk appetite.

Additional layers of security make things safer, but they also make things more difficult to use -- just look at airport security, applying for a new passport or using a NAT Gateway to obtain Internet access.

By putting resources in a private subnet, there is an additional layer of security. It can be reassuring knowing that resources in a private subnet cannot be accidentally made public by a mis-configuration of a security group (but can be made public by a mis-configuration of the subnets!).

Network security people are familiar with traditional methods of security by using public/private subnets, and don't have the luxury having having Security Groups in a traditional network. Therefore, they are more 'comfortable' using the old-style security methods together with modern Security Groups.

So, if you feel comfortable with putting your resources in a public subnet and using Security Groups to restrict them, then that is up to you. You can further protect resources if you do not give public IP addresses to private resources, which will further protect them from access.

At the very least, set your database to Publicly Accessible = No.

Upvotes: 7

Jay
Jay

Reputation: 335

Here are some of the best practices I could think of -

  1. Have a 3 tier enterprise architecture with 1 public subnet, 1 private subnet and 1 for database. Only public subnet has direct internet connectivity, rest of them have a NAT gateway
  2. Do not keep your RDS (DBs) in public subnet. It's not good to publicly expose your DB (even if you have SGs)
  3. Implement ACLs as well along with SG for allow and deny statements. ACLs operate at a subnet level

For an enterprise grade you surely need more security depending on the architecture

Upvotes: 3

Related Questions