Enterprise architects face a number of challenges when designing application infrastructure for the cloud. One...
of those challenges includes the discomforting fact that they don't control the physical hardware or network. Understanding how to secure resources that are physically out of your control can be tricky, as engineers must map between known, familiar concepts and unknown, abstract implementations.
One fundamental piece to securing a cloud app is understanding how to isolate resources. In an on-premises environment this involves routers, subnets and firewalls. In the cloud, server isolation can seem problematic when operating on shared infrastructure, where the physical location of a particular VM is both unknown and subject to change. The hypervisor provides memory protection from other applications on the server, but that might not be enough for all IT teams. So, how does an enterprise achieve network isolation in AWS, both from other customers and within its own set of VMs? Elastic Compute Cloud (EC2) Security Groups are a key part of the answer.
An EC2 Security Group acts as a combination of a virtual subnet and client-side firewall. Each instance within an EC2 Security Group shares a common security policy; firewall-like rules control traffic among groups. As with firewalls, the default behavior is to deny traffic, with specific rules to allow inbound and outbound connections.
Security Groups are closely related to Amazon Virtual Private Clouds (VPCs), which act as subnets within one's AWS infrastructure. Both provide port-based access controls, as Security Groups are like server-based firewalls, such as Linux iptables, and VPCs are akin to a traditional network-based router or firewall with security policy defined for the entire subnet. The following table highlights the differences between AWS Security Groups and VPCs.
Security Groups control inbound and outbound traffic for individual VMs, and all instances in a group share the same policy; VPC ACLs do the same for network subnets. The two security constructs are orthogonal: EC2 instances in a particular VPC, i.e., that share a common network security policy, can belong to different Security Groups. But if an administrator doesn't specify an EC2 Security Group when instantiating an instance, it is automatically assigned to the default group for the VPC. If the admin hasn't defined any VPCs, AWS creates a default network.
Rules of thumb for an EC2 Security Group
EC2 Security Groups provide a structure within AWS for a baseline VM network security policy and should be considered the first line of defense -- a necessary, but not sufficient security component.
Enterprise AWS deployments should also include one or more VPCs to add a layer to the network security policy.
The following policies are recommended to secure AWS deployments:
- Create separate Security Groups for each application, application tier and admin user group with the policies tuned to the needs of the specific workload or service tier.
- Don't create a separate Security Group for every instance.
- Don't put all instances in the same Security Group. This old "moat-and-castle" firewall policy -- hard on the outside, soft on the inside -- doesn't work now that intrusions use multiple levels of attack and internal probes to plan later assaults.
- Don't rely on the default AWS Security Group for a VPC. By default, AWS only allows inbound traffic from other instances in the default group and all outbound traffic. This may not be what you want.
- Carefully plan network routing and subnet design (VPCs), and use restrictive ACLs between networks. Network ACLs provide granular control over Internet and application protocols, such as GRE, IPSec, ICMP, HTTP, SSL and DNS, as well as traffic restrictions between source/destination IP address ranges. VPC ACLs are independent of, and work in conjunction with, Security Groups. They drop unnecessary and potentially harmful traffic before it reaches an EC2 instance and Security Group policy.
- Use a standard of least privilege when defining ACL rules for the network and instance. Only allow connections, ports and users that are absolutely required.
- Pay particular attention to the outbound Security Group policy. Outbound rules restrict connections to specific addresses, such as Dropbox or Chinese hackers, as well as ports (FTP) that can be used for unauthorized data exfiltration.
- Enable logging everywhere: VPC flow logs, CloudTrail, Amazon Identity and Access Management and so on. Event logs provide the details necessary to troubleshoot problems, spot security vulnerabilities and improve security policies over time.
As with any broad security guidance, each IT organization must ascertain its security profile and define the policy details needed to suit particular applications and usage scenarios. Still, the judicious use of EC2 Security Groups is one pillar of a strong foundation of cloud security policy.
Security policy -- not tools -- protects AWS
How to develop an AWS security policy
Shared security responsibility eliminates scapegoats