Best Practices for Securing Your Private Network in the Cloud
A private network is where your business logic lives, including your data and your customer’s data in the form of servers, disks, databases. For this reason it is of utmost importance to secure your private network accordingly. This goal can be achieved using subnets, firewalls, private endpoints, in-transit encryption, and logs.
A VPC, or virtual private cloud, is AWS’ version of a private network. A VPC is usually composed of a number of subnets, all in the cloud. To safeguard it, there are a number of techniques you can utilize — but the most fundamental involves breaking your VPC down into a suitable number of subnets. There are a few reasons to do this:
You want public subnets: Resources hosted in a public subnet are addressable from the internet, and can reach out to the internet. This is the way it should be for some resources, such as load balancers, bastion hosts, NAT gateways and sometimes web servers.
You also want private subnets: Resources placed in a private subnet are not addressable from the internet and cannot reach out to the internet without the intermediation of other devices. A private subnet is where sensitive resources such as app servers and databases should be. Placing these in a public subnet would pose an easily avoidable security risk.
You want subnets in different data centers: This is both for security and reliability, as resources in these subnets will be physically separated.
Here's an overview of some of the other key tactics for securing your private network.
Security Groups
Another important technique to protect your private network involves ensuring security groups are in place and correctly set up. Security groups are software firewalls that can be associated with servers – typically EC2 instances and database servers – and will allow traffic based on rules you define.
With a security group, you specify inbound and outbound rules based on protocols, type of traffic (e.g. SSH or HTTPS), port numbers, and trusted IPs. A crucial feature of security groups is that all inbound traffic is denied by default, the whitelist approach. You’d have to explicitly allow traffic, which adds to the security.
Network Access Control List
A Network Access Control List (NACL) is another form of firewall. One that can be applied to subnets, as opposed to security groups which apply to individual servers. The purpose of a NACL is to give you control over traffic that crosses the boundaries of subnets. Associating a NACL with each subnet is also a recommended security measure.
Similar to security groups, NACLs also work by means of inbound/ outbound rules. One essential and powerful difference though is that NACLs are capable of explicitly denying specific IPs, ports, protocols and types of traffic, which a security group can’t do. This feature is quite handy for keeping known threats out.
Oftentimes, servers and other devices placed in a VPC need to access other AWS services. Problem is, the endpoints for said services are public endpoints, fitting for a public cloud. Therefore traffic from the VPC would have to go through the public internet, exposing it to potential threats.
VPC Endpoints
The solution is to use VPC endpoints, another recommended security measure. VPC endpoints provide in-VPC, private IPs for a plethora of AWS services. Thus traffic from/to the VPC and AWS services does not have to venture into the public internet. A services that support VPC endpoints include S3, Dynamo DB, RDS, Aurora, SNS, SQS, IoT Core, KMS, and CloudWatch. For most of these services, the VPC endpoint is provided via integration with AWS PrivateLink.
Transport Layer Security (TLS) is a prevalent data exchange protocol and the de facto standard to encrypt in-transit data. It’s what puts the “S” (for secure) in HTTPS. Communication between internet clients and AWS public endpoints (e.g. an application load balancer) is encrypted by default using TLS.
Encrypting Internal Traffic
For most applications this is sufficient. But depending on the strictness of your application, regulatory demands or criticality of data breaches, you may also elect to encrypt internal traffic – traffic between private IPs in your VPC. This strategy is most useful and most commonly employed to encrypt traffic between a load balancer and its underlying EC2 virtual machines.
Other possible uses include traffic between EC2 machines and database servers, between CloudFront distributions and internal resources, also between API Gateways and internal resources. The AWS Certificate Manager can be of great help here, centralizing and simplifying the provisioning, renewal and deployment of TLS certificates.
Flow Logs
Using VPC flow logs is another tactic for protecting private networks. Flow logs make it possible to log inbound and outbound traffic at every level of a VPC: the entire network, subnets, or individual components. It’s important to emphasize that flow logs do not record the actual contents of communication, only metadata. These logs can be stored in S3 or CloudWatch, and should be protected from deletion or alteration.
DDoS
These days, a relatively common attack is the DDoS, or Distributed Denial of Service attack. The goal of a DDoS is simple: flood a server with millions of malicious requests initiated by hacker-controlled bots so that legitimate requests can’t go through and clients effectively go un-serviced.
It’s good practice to protect your internet-facing servers specifically against DDoS attacks. There are a few different types of DDoS attacks, and two services that can assist in preventing them. The first is the AWS WAF (Web Application Firewall), and the second is the AWS Shield. The WAF and the Shield are complementary services, each one targeting different layers of the OSI communication model. The WAF will additionally protect against other common attacks that exploit vulnerabilities in your application’s code.
The Takeaway
So this is it – an overview of the main methods to secure a private network. Even though implementing these methods can’t guarantee 100% protection – nothing can – they will vastly improve your odds of remaining safe from digital bad actors. If you missed earlier installments in our Securing the Cloud with AWS series, read part 1 and part 2.
Reference: https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html