Probably one of the most pressing concerns on the mind of the Enterprise admin is that of Cloud Security. In the modern datacenter, we design firewalls to protect from intrusion, virus scanners to protect our users, access policies to control the flow of data. We do all of this as second nature. Many companies view the public cloud as some type of modern day gladiatorial arena. The cloud is too wild and they are like Mad Max standing in the proverbial Thunderdome. The good news is that it isn’t all like this.
Security is very important to me. I have read too many articles of Thunderdome cavaliers rushing out to the cloud and cutting corners. My own team sometimes gives me grief over the layer of complexity that I apply to our infrastructure. I will give you that 95% of the infrastructure is for development and testing but why should we relax our stance?
When I look at security in Amazon, I see three major security options. There are others for certain, but these three build the basis for understanding the bulk of the options. We will classify each of these options as Network Security, User Security, and Server Security. Individually, the security options provide good coverage but together, we have something to protect us from the ravaging hordes.
One of the first security options that you have probably run into is the concept of an EC2 (Elastic Cloud Compute) Security Group. A security group is similar to a firewall rule in your VPC (Virtual Private Cloud) that allows the flow of traffic to and from an EC2 instance. The inbound and outbound rules can determine which Network addresses can access which protocols. This all seems pretty standard but there is an interesting twist to Security Groups.
The first twist is that by default, EC2 instances in the same Subnet cannot talk to each other. Well, this is a new one. The EC2 instances are designed to restrict ALL traffic not explicitly opened up by the security group rules. This changes a lot about how we setup systems. Now, a subnet is just a container of Servers and Network address but no longer an open security zone. Every machine is treated as if it is in a DMZ.
The second twist to the AWS Security Groups is that you can open ports in one security group using a second security group as the source address. Let’s pause for a moment on this concept. Originally, I told you that Security Groups allow traffic to and from specific network address based on the rules. The twist is that I can also allow other EC2 instances direct access to specific ports by associating a security group as the source. Let’s use an example.
I have a MySQL database instance running in my VPC and I want it accessible by my Apache web servers. Remember, by default, these instances are not able to talk to each other. Well, they can listen but they act like a five year old with fingers in their ears and just don’t respond. So, I have two Apache servers configured to connect to the MySQL database instance. I will need to enable ports to be opened. There are three ways to do this:
So, why is option 3 better than option 2? In this scenario, I have two apache servers but what happens when I add more? Further to that, what happens when I replace all of the Apache servers with new builds? I don’t want to manually have to configure each of these security group rules every time a new build is pushed. Remember, the cloud is also about speed and flexibility. It doesn’t mean we need to give up security.
Hopefully, this has been helpful. Security in the cloud is definitely something worth learning about and understanding fully. In our next entry, we will start diving into User accounts and Policies.
Learn more about AWS Security Groups by checking out the AWS Security Group Documents.
Other articles in this series
