Essential Steps for Securing Your AWS Environment
Master Your AWS Security with These Top 10 Cloud-Protecting Practices.
Published Feb 19, 2024
Tip 1: Implement a Multi-Account Architecture
Tip 2: Design a Custom VPC Configuration
Tip 3: Prioritize Patch Management
Tip 4: Optimize Authentication with Single Sign-On
Tip 5: Secure the Root Account
Tip 6: Manage Permissions Effectively
Tip 7: Enhance Remote Access Security
Tip 9: Protect Web Applications with WAF
Today, I want to dive into a topic that’s been buzzing around lately: security in AWS environments. As we kick off the year with new intentions and goals, it’s crucial to ensure that our AWS setups are fortified against potential threats. So, let’s delve into some fundamental steps you can take to bolster security within your AWS infrastructure.
A lot of customers have been talking about security recently. It’s the start of the year, new intentions means they want to get involved with different standards, etc. But the first place to start is with some basic foundations in security or as I call it, Well-Architected Security.
Start with the basic foundations of security before you go big. Otherwise, you’re going to find there’s a lot of work to do later.
Let’s go through my top 10 steps for securing your AWS Environment
So the first step that I would take with security is to separate those workloads, have a multi-account architecture. This sounds complicated, but it’s not. All we’re looking for is a couple of AWS accounts, one for your production environment that nobody touches, except for when you push your deployments into production and then have another account for playing around in, like a sandbox or development account. It doesn’t have to be anything big. And don’t forget you don’t actually pay for an AWS account unless you put something in an account. All accounts are free until you start using them. So having that dev account there is great.
What this means is, if you make mistakes in the development account with data or your application, you’re not going to impact that production workload.
So as far as the multi-account architecture is concerned, you’ve got a production account, you’ve got a development account and what you’ve got next is a management account. This account sits above the other two in the organization and creates a consolidated billing account, so you only get one bill. So that’s nice and convenient as well.
But ultimately you’ve separated those workloads out and you’re looking after your data security.
Have an audit account because when you go for those security standards, they’re going to look for an audit trail, they’re going to look for logging, and they’re going to look for how you query that as well. What’s an audit account? An audit account is something where you consolidate all your cloud trails into one single place from each of those accounts.
So think big, long-term. You’ve only got a production account and a playground account right now. But what if in three years time you’ve actually got an account in London? An account in the US? You’ve got multiple accounts for different tenancies. You want to consolidate all that logging into one place because if you have an incident, you want to make sure you can get to that information quickly and easily. And also it means you’ve protected that log file as well, because if you do have an incident, nobody can erase those cloud trials from your production account.
My second tip is all about your network design. Don’t just dive in playing with that default VPC configuration that’s been given to you within your account because at the end of the day, it looks great to get you started, but you don’t want to be using a public subnet all the time.
Create yourself, your own custom VPC configuration and also create it to have three layers of security to it;
- In the first layer, have a public subnet. Just put your load balances there for anything that needs to be exposed to the Internet. Or maybe you’ve got a reverse proxy or a VPN server.
- The second layer to your VPC is going to be a private subnet. I’d put all my compute workloads here like Lambda Functions, EC2 instances and Fargate tasks as well. That way, you’ve separated your compute workload from the Internet, make sure you’ve got a NAT Gateway, so those resources can get out to the Internet for their updates. But ultimately, the only way into these workloads should be via the load balancer.
- And then, lastly, the third tier. This is the secure tier. Or, as I like to call it, the data’s tier. I put all my Managed AWS services here that look after my data. RDS, EFS, FSX, etc. And it keeps that data secure. Why is it secure? Well, first of all, there’s no Internet gateway or NAT Gateway. There’s also a network access control list (NACL) across the bottom of this as well, which then means you’re blocking that from the public subnet.
So the only way to get to your data is through the compute layer. So the flow of data starts off at the Internet, goes to a load balancer, then comes into your compute layer and then goes into your data layer if that data request is needed. But there’s no way anything entering or compromising your public subnet should be able to get to your data.
Patch management! If you’ve got EC2 instances, then make sure you patch them. There’s nothing worse than an exposed EC2 Instance on the Internet. You want to make sure you patch those against any Common vulnerabilities and Exploits (CVEs). Whilst we all know about Microsoft patch Tuesdays, don’t forget your Linux hosts as well. You can use AWS Systems Manager, Maintenance Windows and Patch Manager to automate these on a regular basis.
Now, let’s talk about how you log in to AWS. The main recommendation at the moment from AWS is to use a single sign on provider. AWS provides a single sign-on provider in the form of IAM Identity Centre. Now, this is great because this means you consolidate all the logins for those multiple accounts that we just created as part of my first Step, into one place.It also means you can federate that off to your favorite identity provider as well, such as Google, Azure AD or whatever it might be as this is a primary feature of IAM Identity Center.
What makes SSO so secure though? IAM Identity Center makes sure that you are using temporary credentials at all times. You log in with your preferred identity provider, and then it gives you a fresh new AWS token in the background so you can access all the AWS resources and expires them at approximately 8 to 12 hours, depending on what you’ve configured. This is great. This means there’s no static credentials lying around nothing that can get leaked. And it even provides you with things like IAM access keys for CLI access.
If you’ve got IAM User Access Keys set up for service accounts, then make sure you rotate those every 90 days. This is to make sure we reduce the potential of an attack. You can create a scheduled process for this, a business process, that is designed to have someone rotate those keys and then apply them to the service as well. But make sure you remember to do this every 90 days.
This next one is all about the root account. If your root account is still in use, if you’re still logging in with that magic email address that Amazon let you register with, get rid of it. You should be setting a strong password, a hardware MFA token and locking it away with a safe. The root account has privileges that could damage your business and it’s too risky to allow it to be compromised.
Make sure that the root account has not got IAM User Access Keys attached to it either because these are stored in plain text and can be assumed from anywhere so make sure there’s no access keys.
Make sure you’ve got MFA enabled not just on your root account, but also across your organization as well.
It’s always important to make sure you know who’s got access to what in your environment. I often find that sometimes the AWS Managed IAM Roles/Permission Sets can actually give away too much in terms of permissions. We want our developers to do things. We want them to be productive, but sometimes you might now want them to have access to Amazon SageMaker or other services that might be expensive to play with when not properly educated. So look at those permissions. Look at what people have and then make sure you create custom roles and permission sets for your staff. Also, make sure you’re checking them regularly as well. What if somebody’s moved roles? Do they need those permissions?
Service Control Policies (SCP) can also allow for controlling different permissions at an organizational level and making sure you know who has access to what. You can still maintain the access that they need if they need administrative access to the account, but from a service control policy at an organizational level, you can then limit services and regions. You can also enforce compliance too.
When you’re remotely accessing your EC2 instances. Try not to use SSH or RDP. Keep these protocols closed away from the world. Instead, use AWS Systems Manager, Session Manager. This service allows you to log on directly to the EC2 instance from inside the AWS Management Console and get your favorite bash prompt or PowerShell prompt. If you’re a Windows user and you want to use the Windows Interface, you could also use AWS Systems Manager, Fleet Manager instead to get a remote desktop.
Using these two features of Systems Manager you can close off port 22, you can close off port 3389 and access the EC2s through the console. From a compliance perspective, this also means that you’re logging access to that EC2 instance against AWS CloudTrail with the username creating accountability.
If you want to track what’s going on on the command line from the Session Manager, you can log those commands to CloudWatch Logs as well. Just make sure you rotate those logs regularly so they don’t get too big.
Make sure you’ve got AWS GuardDuty enabled. GuardDuty is a lifesaver when it comes to not knowing what’s going on in your account. I always tell a story about this.
THis was during my tenure in a previous role, I’ve seen this with a real account in real time where GuardDuty alerted us to an issue. And what it’s alerting us to is something that we can’t see in our usual regions or environments. It alerted us to a cluster of EC2 Instances being launched in another region. Now, as a customer, I was working in Sydney. Why would I be bothered about any other region? But GuardDuty told me that somebody had compromised our accounts by the usage of leaked IAM credentials, and we were able to stop the launch of resources in the wrong region at that time, saving us a lot of money and saving us our security reputation
Look into AWS Security Hub! Security Hub is a service that consolidates all the other security services within AWS into a single pane of glass view. GuardDuty can send alerts to Security Hub alongside other services and then show you remediation items as you go along, giving you traffic light reports and even a percentage score of your security position. It works with many frameworks, so you’d be able to tune it to exactly what your frameworks might be
Application protection with a Web Application Firewall (WAF). If you’ve not got a WAF, you’re very possibly opening yourself up to all sorts of risk. A WAF can be tuned to your run time or hosted operating systems. It can protect you against the top 10 threats on the Internet at the time or against botnets. You can also create custom rules such as whitelists or block lists to be able to control the traffic coming in.
Final tip for security today is encryption. Encrypt everything! As Werner Vogels would say;
“Dance like nobody’s watching and encrypt like everybody is”
Make sure you encrypt those EBS volumes on creation. Setup your account so that every volume is encrypted by default. Use custom KMS keys, if possible. Make sure S3 buckets and RDS instances are encrypted as well. Every service should have an option for encryption. Use it. Don’t lose it (your data).
Securing your AWS environment is an ongoing process that requires diligence and proactive measures. By implementing these essential steps, you can fortify your infrastructure against potential threats and mitigate security risks effectively. Remember, prioritizing security is key to maintaining the integrity and resilience of your AWS environment.