Using Security Groups to Partition Applications
Security groups are used to control access to EC2 instances. Because AWS uses flat Layer 3 networking, any instance within a user account can communicate with any other instance — unlike many corporate IT networks, which are partitioned via VLANs so that many virtual machines can communicate only with other virtual machines residing on their VLAN. In that particularcorporate world, communication with other virtual machines must pass through a router or a gateway server that has two network interfaces and can pass traffic back and forth.
The reason many organizations choose to implement this type of arrangementis to prevent inappropriate access to computing resources. In particular, most organizations consider it important to prevent outside access to servers providing data access, so they allow public network traffic to application web servers but prevent public network traffic to database servers. The web servers and database servers reside on different virtual local-area networks (VLANs), and traffic between them must flow over a router or a gateway server.
For a host of reasons, AWS doesn’t provide this kind of VLAN capability —check out Chapter 6 for the specifics. For now, though, the challenge is what you can do to improve network traffic security.
A common technique is to use multiple security groups to partition traffic. Suppose that you have a three-tier application, along the lines of the one shown in Figure 7-4: The Web tier offers web access to the web servers, the Business Logic tier runs a Java application, and the Data tier manages data in a MySQL database. Your goal is to prevent public access to the Business Logic tier and the Database tier, and to ensure that the only way outside traffic can interact with those two tiers is via the established routes of the application itself. How would you accomplish that task?
HTTP traffic operates on Port 80. In this example, assume that the Java application accepts traffic on Port 4555 and that MySQL accepts traffic on Port 3306. Look at the steps you’d use to define how security groups can implement application partitioning:
1. Define a security group that’s open to TCP traffic on Port 80. Name it WebTierSecurityGroup.
2. Define a security group that’s open to traffic on Port 4555.Name it BusinessLogicSecurityGroup. Configure this security group to receive traffic from any instance that is a member of the WebTierSecurityGroup.
3. Define a security group that’s open to traffic on Port 3306.Name it DatabaseSecurityGroup. Configure this security groupto receive traffic from any instance that is a member of the BusinessLogicSecurityGroup.
4. When launching a server in the Web tier, attach WebTierSecurityGroup to it. This step ensures that the server can accept public HTTP traffic from the Internet.
5. When launching a server in the Business Logic tier, attach the BusinessLogicSecurityGroup. Because this security group has been configuredto accept traffic from instances in the WebTierSecurityGroup, it can send and receive traffic from the web instances in the application without being exposed to port 80 traffic.
6. When you launch a server in the Data tier, attach DatabaseSecurityGroup to it.
Because the DatabaseSecurityGroup was configured to accept traffic from any instance that is a member of the BusinessLogicSecurityGroup, any Data tier instance will be able to communicate with instances in the Business Logic tier. Note that by not having made the DatabaseSecurityGroup accept traffic from the WebTierSecurityGroup, these instances aren’t accessible from the public Internet, even though they have a public IP address; any attempt to send HTTP traffic to one ofthese instances is rejected because it doesn’t have that port open.
As you can see from this arrangement, no web traffic from outside AWS can access the database server without going through the Web and Business Logic tiers. Often referred to as defense in depth, in this type of partitioning, asecurity attack has to successfully penetrate several layers to obtain accessto critical resources. Simplified example to illustrate the concept of using security groups to partition applications. For actual production use, you’d almost certainly have a dedicated security group for Port 22 (SSH) access that would be IP-traffic delimited to allow Port 22 traffic only from your corporate offices; this strategy would prevent malicious attacks from other traffic sources.
Another activity that would be more complex in real life is running several versions of an application: a development version where new code is being worked on, a testing version for quality assurance, and a production version for customers to interact with. You then subdivide the security groups and have Development, Test, and Production versions for each tier and attach the appropriate security group to the version you’re running. For example, you’d use DevWebTierSecurityGroup, BusinessLogicSecurityGroup, and DevDatabaseSecurityGroup so that only development traffic would access these instances and, in particular, no development traffic can access production instances.
Using security groups to partition applications is an excellent approach to increasing application security, and I highly recommend it. It can significantly increase the security of your applications. It’s not perfect, however.
Another, much more direct method of attacking instances in the Data tier exists: a direct attack against the public IP address that every instance in AWS carries. That’s quite a shortcoming, isn’t it? Fortunately, you can address this vulnerability, by using the AWS service Virtual Private Cloud (VPC), For now, beaware that security group partitioning, though important, doesn’t offer perfect protection of your applications.
Security group scope
Security groups are scoped regionally, so you need appropriate security groups in every region in which you plan to operate applications.
Security group cost
Hey, security groups are a bargain — they’re free! Go ahead — use as manyas you like.
