Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

AWS Security Controls
SECURITY SHELF

AWS Security Controls 

In traditional IT environments, servers are grouped by function and placed on separate VLANs. It is common to place VPN termination, administrator access, web servers, application servers, and database servers on separate subnets and use firewalls or advanced routers to provide isolation and access control.

Many security practitioners view this approach as a reference architecture for all IT deployments, but this subnet-level approach has never been ideal. For example, it does not prevent lateral attack movement. Firewalls with multiple network interfaces are available, but it is not feasible to place each server on its own interface. A better approach would be to control communication between each individual server. AWS provides this functionality for free.

For those less familiar with AWS, a brief overview is in order. AWS customers create a Virtual Private Cloud (VPC). Within each VPC the customer creates subnets. EC2 Instances (virtual machines) connect to one or more subnets. Three isolation layers exist within the VPC:

First, each VPC has a configurable routing table. To reach the Internet, instances must have a public IP attached and be located on a subnet with an Internet gateway specified in the routing table. VPN-only subnets can be created by routing traffic to a virtual private gateway. It is therefore possible at the routing level to enable or prevent Internet communications.

The second isolation layer is the network Access Control List (ACL). By default, all subnets within the VPC are able to communicate with each other. ACLs can be customized. ACLs are stateless, and therefore not as sophisticated as modern Stateful Packet Inspection (SPI) firewalls. However, they are a good additional layer to help mitigate accidental or unapproved changes to instance-level Security Groups.

The third, and most powerful layer, is the AWS Security Group (SG). Each SG can contain one or more inbound or outbound rule. Similar to other firewall rules, SG rules include source or destination, protocol, and port. Up to five SGs can be assigned to each network interface on an instance. In practice this provides per-instance (virtual machine) security at the network layer that is easier to manage. For example, one security group may define rules for administrator access via SSH or RDP. A second security group might contain rules to facilitate communication with a backup server, and a third security group may contain rules specific to the server’s role.

For small AWS deployments, it may be acceptable to place all instances on the same subnet and rely solely upon SGs to provide isolation between each instance. From a practical perspective, this provides stronger controls than those traditionally achieved with a firewall.

Larger AWS deployments, or those with higher security requirements, should combine a logical zoning approach with routing table customization, network ACLs, and SGs. The following should be considered:

  1. Create an Internet connectivity subnet with an Internet route. All instances that require direct Internet connectivity should be located on this subnet. (If higher availability is required, two Internet connectivity subnets in different AWS Availability Zones may be required.)
  2. Place an outbound HTTP/HTTPS/FTP proxy in the Internet Connectivity subnet that uses whitelisting to control egress traffic. A micro or small instance with the open source Squid proxy works well. The proxy is used to allow instances to retrieve operating system and application updates as required. The AWS NAT gateway is not recommended due to the lack of egress controls.
  3. Create an administration subnet for jump servers or other remote access solutions used by administrators. With the potential exception of very small deployments, or organizations with existing secure admin networks, administrators should not be permitted to connect directly to instances using RDP or SSH from outside AWS.
  4. Create a separate subnet for shared services such as domain controllers, log aggregation, and backup servers.
  5. Create additional subnets as required, grouping instances by function and sensitivity. For example, multiple databases with similar types of data can be placed on the same subnet, but it may be appropriate to use separate subnets for data to which PCI or similar regulations apply.
  6. Configure VPC routing tables to allow proper routing across subnets, but ensure that an Internet gateway is only present on the Internet connectivity subnet.
  7. Employ network ACLs to limit communication to approved protocols between subnets.
  8. Use SGs to limit network connectivity to each instance, specifying the source of the network traffic and protocol. For example, connectivity to a database service should be restricted to the individual instances that require access. RDP or SSH access should be restricted to authorized instances in the Administration subnet.
  9. Use AWS Identity and Access Management (IAM) groups to enforce a separation of duties where applicable. For example, system administrators or developers may be allowed to configure SGs, but not routing tables or ACLs.
  10. AWS can be configured to write audit and SG logs to S3. This functionality should be enabled and logs sent to a log aggregation system.
  11. The AWS API can be used to automate tasks such as SG administration and review.

It occasionally makes sense to deploy a virtual firewall appliance in AWS as an edge device. However, deploying firewall products to mediate traffic between AWS subnets generally adds very little security value and is not cost justifiable. It also introduces single points of failure. If additional security controls are required, primary consideration should be given to deploying endpoint protection with host-based intrusion detection functionally instead of duplicating AWS security controls.

Have a security question you’d like answered in a future column? Email eric.jacksch@iticonline.ca

Related posts