In order to implement strong security tailored for the public cloud and better lock down databases, organizations need to understand network access in the cloud.
This starts with the concept of the Virtual Private Cloud (VPC). It’s what AWS is built on and other Cloud Providers, including Azure and Google, have similar models. A VPC is used in the public cloud to provide an organization with private computing space.
Within the VPC are:
- Internet or VPN gateways that connect the resources within the VPC to the rest of the world
- Subnet(s), which is a range of IP addresses
- Routing tables to move traffic around the VPC
- Stateless firewalls called Network Access Control Lists (NACLs)
- Host-based stateful firewalls called Security Groups
Accessing Resources Outside An Amazon VPC
When these concepts are understood, audits can be carried out for things such as how an application is deployed, is it being done securely, and are the right packets filtered out so only the right traffic can get to the application.
The two most important concepts to understand about network security in a VPC are NACLs and Security Groups. Let’s break them down further.
Network Access Control Lists (NACLs)
NACLs act as virtual firewalls, controlling traffic in and out of one or more subnets. They’re assigned to an entire VPC and subnet. The same NACL can be assigned to many subnets, but a subnet can have only one NACL.
NACLs are stateless, which essentially means incoming and outgoing traffic is submitted to the same rule. If an incoming rule is modified, the changes will not be applied to the outgoing rule. Rules are evaluated numerically, in order, from the smallest number to the largest. NACLs can contain rules that prevent specified IP addresses from connecting to the VPC.
Since the first rule that matches what the traffic looks like is used, an organization could end up with ineffective rules. Put another way, earlier rules can override rules later on. For example, if a deny is put at 200 and someone inadvertently puts the wrong rule at 150 — the traffic that was supposed to be blocked at 200 will come through at 150. Additionally, infrastructure as a code means a NACL can be reconfigured accidentally using one click.
It can be difficult to appropriately open up and restrict NACLs because they’re stateless. Understanding how these rules are evaluated is a must in order to set up NACLs right.
Security groups are host based. A Security Group acts as a firewall, controlling traffic in and out of virtual computing environments (aka instances). Organizations can create a security rule and assign it to an interface on a resource such as a Database as a Service or EC2 instance. Security Groups handle both inbound and outbound rules. Instances can have multiple Security Groups.
They’re stateful, meaning organizations don’t have to worry about the complexity of responses. If traffic comes in on one port and goes out another port, it will flow through without issue. The rules are cumulative; all rules are evaluated before traffic is allowed. If modifications are applied to an incoming rule, they are automatically applied to the outgoing rule.
However, if the wrong Security Group is assigned to an instance in a VPC, that instance can be reached from where it shouldn’t be — it can be used as a jump host to talk to or attack other resources within the VPC. Attackers only need one weak point. Beware of incorrectly assigning Security Groups and allowing publicly accessible resources.
When to Use Which One
Generally speaking, NACLs are used less than Security Groups, but there are times to use both so it’s important to weigh when to use one versus the other while keeping in mind that the more security layers you have, the better off you’ll be.
For example, when working with many instances it can make more sense to use NACLs to manage firewalls than Security Groups because Security Groups have to be manually assigned to each instance whereas NACLs are associated on the subnet level, so any instance in the subnet will follow NACLs rules.
Becoming intimately familiar with how the networking works is a basic skill that’s needed to ensure you can properly lock down resources in the public cloud.
SecureCloudDB includes a number of security policy rules derived from AWS, the Center for Internet Security (CIS) and global security leaders that are checked against database configurations for VPC, public access, network encryption and more. This tooling combined with Database Activity Monitoring decreases an organization's attack surface by helping to reduce human error and detect anomalous activity. See what it can do for your organization today with a demo or free trial.
This article includes excerpts taken from the webinar “Public Cloud Database Security: Using Others Mistakes To Stop Attacks in Their Tracks”. Access the replay on demand here.