AWS Shared Responsibility Model
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.
Give the Least Privilege Possible
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.