Amazon’s Virtual Private Cloud (VPC) is a virtual networking concept that allows AWS resources to communicate with each other over a private virtual network.
Before we begin, it’s essential to understand the AWS Shared Responsibility Model. They differentiate between security in the cloud and of the cloud. While AWS is committed to the security OF the cloud, you are responsible for the security IN the cloud.
I once woke from a sound sleep to a rustling sound while spending the night alone in a hotel room. I freaked out when I realized the source; I had accidentally left the door to the patio open, and a breeze was rustling some papers I had left out. While the hotel had provided security OF my room, I had failed to handle security IN my room correctly. Thankfully nothing had happened, but it was a vivid reminder of my role in my security.
How do you ensure you don’t leave the proverbial door open to your VPC? Let’s discuss four best practices for securing Amazon’s VPCs.
To start with, you should be thinking ahead, don’t build your VPC just for the current moment; instead, think through what it will look like in a year or three. For instance, make sure you are sizing your VPC to handle future growth giving yourself room to grow. Then, plan accordingly, or you may find your environment unable to scale, and essential security services can’t be added. Choose a top-level CIDR range large enough to work for your current and future needs.
This is also an excellent time to consider using Availability Zones (AZs) for high availability. You may not need it yet, but if you could need more subnets, make sure you leave room for them in that top-level CIDR range.
When possible, use multiple VPCs instead of one. For example, development and staging environments should be in separate VPCs from the production environment. Also, separate VPCs should be used when working with multiple clients to ensure their data is isolated unless you have a working multitenant solution.
Following the principle of least privilege, look to minimize access wherever possible. Constantly evaluate the least privilege needed for a resource to do its job.
Begin by not using the default VPC that comes with AWS accounts. The default VPC exposes all resources to the internet by creating public subnets. Unless an AWS resource must be accessed directly from the internet, place it in a private subnet. By configuring the VPC to use private subnets, you ensure the world doesn’t have access.
If you need to access other services outside your VPC, consider using AWS Private Link to connect instead of exposing the whole VPC to the outside world. Private Link allows AWS resources to talk directly with each other across VPCs without needing to enable public access.
If your VPC requires public access, consider using Elastic Load Balancers in the public subnets to act as a security layer between your public presence and your applications. This is a recommended best practice but does have cost implications, so it may not be ideal for proof of concept and sandbox environments—another reason why different environments should be in their own VPC.
“Bake in” your security practices with Infrastructure as Code (IaC). Tools like Amazon’s CloudFormation or a free open-source tool like Terraform allow you to define your infrastructure in code. That way, when the infrastructure is deployed, it is set up precisely to the coded specifications giving consistent environments. With IaC, you can be sure that each deployment is the same instead of wasting time creating security rules for many different bespoke deploys. In addition, IaC allows you to quickly review and improve the infrastructure as well as track changes over time using version control like Git.
However, automated IaC tools only partially address security challenges. In some cases, automation can amplify a security issue. For example, if a setting was changed within the infrastructure as code, that makes all S3 buckets publicly available. On the next deployment, suddenly, all S3 buckets would be exposed.
Over time the size of an organization’s digital footprint expands. That’s a sign of a healthy growing organization, but managing that scale becomes increasingly complex. When cloud resources go from hundreds to thousands or exponentially more, things can easily slip through the cracks.
Remember how I accidentally left the door open all night in my hotel? That was one room for one night. Imagine managing a suite of hotels, and you need to ensure that doesn’t happen. You would put in a security system that monitored all the doors, and if they were left open for too long, then security would be alerted. I found out this exists when I received a call from security for leaving the office door propped open for too long.
According to IBM’s Cost of Data Breach Report, cloud misconfigurations accounted for 15% of all breaches in 2022. That’s where security monitoring tools come in. By monitoring your environment for policy violations, tools like AWS Security Hub, or a free open-source tool like Paladin Cloud can catch misconfigurations of your VPCs and other assets.
Let’s take the Infrastructure as Code example where all S3 buckets were accidentally misconfigured to be publicly accessible. Paladin Cloud’s Deny HTTP Requests to S3 Bucket policy would flag all the exposed S3 assets and provide the information needed to remediate the violation.
By planning ahead, limiting privilege, automating deployments, and monitoring your assets, you can increase the security of your VPCs and no longer worry if you left a door open.
Cloud misconfigurations accounted for 15% of all breaches in 2022
For a deeper dive into this topic: AWS VPC: Security Best Practices.