Working with a variety of AWS clients, both large and small, I have heard a common concern about running their infrastructure on a public cloud. Most companies understand the benefits of running their infrastructure in the cloud such as development agility, pay-as-you-go pricing, and reducing system management overhead. However, they are worried that there is a higher security risk of running their infrastructure on a shared platform. AWS offers a variety of tools and methods to secure your AWS account that will give you the peace of mind about securing your cloud infrastructure. In the past year, my focus was to ensure that clients’ infrastructure is well-architected and secure on AWS. I have identified 5 easy steps to increase your AWS account security posture and significantly reduce the risk of having a major security event.
Don’t use the root account
When creating a brand-new AWS account, you are required to provide an email address as a login. This email address and password combination will allow you to log into your brand new, fresh-looking AWS account and grant you full super-admin privileges to your new account. This is referred to as your “root” login since this account has no restriction on actions that can be taken in the AWS account. Once the account is created, it is strongly, strongly, strongly recommended to not continue using this root account to manage your AWS resources.
You might ask, “What is the proper way of managing AWS resources in the AWS account if logging in with your root account is discouraged?” Great question! Once the account is created and you are logged in, create IAM users for individuals that need to have access to the account. IAM policies allow you to grant the permissions necessary for each user including administrative privileges to those who require it. Alternately, you can use single sign-on (SSO) to access your AWS accounts which leverages credentials from your corporate directory in lieu of IAM user accounts.
There are several immediate security benefits of using IAM user accounts. First, each individual has their own login which prevents team members from sharing credentials. Secondly, since everyone has individual logins, it provides the ability to log each user’s AWS activity in AWS CloudTrail. This enables administrators to quickly identify which account might have been compromised or is behaving suspiciously. Thirdly, in the unlikely event of a major security breach, having a IAM user account compromised is less terrifying than having your root account compromised. Let me explain: for example, let’s say your IAM user credentials were compromised and the bad actor changed the password. This essentially locked you out of your own AWS account. You can still use the root account to gain access to the AWS Account and disable that IAM account. However, if your root account gets compromised, and bad actor locks you out it, there is no method of regaining access to your account without serious AWS intervention. You essentially gave away the keys to your kingdom.
Therefore, it is important to create IAM users (or federated users) and use those accounts to manage your AWS infrastructure instead of the root account. In addition, ensure that you have a strong password for your root account (and your IAM accounts as well) and that the password is stored securely.
Enable Multi-Factor Authentication (MFA) on root
To add an additional layer of security in protecting your root account, it is strongly recommended to enable Multi-Factor Authentication (MFA) on the root account. MFA forces the user to provide a not only a password but also a security token to confirm the user’s identity. Therefore, in the unlikely event that your root credentials get compromised, the bad actor still won’t be able to get into your account because they won’t have access to the security token. Instructions on how to enable MFA on your root account can be found here.
While setting up MFA on root is vitally important, AWS also provides the capability for IAM users to setup MFA on their accounts. Instructions on how to setup MFA on an IAM user account can be found here.
Setup billing alerts
You might ask yourself, “What does billing have to do with securing your AWS account?” However, I noticed that AWS customers who watch their expense more closely, usually have a better security posture and are able to identify threats much faster. This is similar to individuals who check their bank account frequently. They are more likely to detect fraudulent purchases sooner and remediate the issue quickly before significant damage is done.
For AWS customers that have experienced a security breach event, many reported that the breach occurred on Friday evening when everyone was out of office. Many came back the following week to realize that their bill had exponentially skyrocketed over the weekend. Setting up billing alerts would have allowed the proper personnel to be notified immediately of the abnormal activity in the account instead of waiting until Monday morning to find out. Instructions on how to setup billing alerts in your AWS account can be found here.
Of course, in addition to setting up billing alerts, there are other security measures that you can implemented to notify you of suspicious, abnormal activity. However, billing alerts are definitely one method to not only monitor your monthly AWS expenses more closely, but also can be a medium through which abnormal activity can be detected.
Use minimum privilege IAM accounts
Most AWS customers, especially startup companies, want to get started on AWS as quickly as possible. This usually results in neglecting implementation of minimum privilege for the IAM users. Though I would agree that granting everyone admin privileges is easy, it undeniably is a security vulnerability.
Granting everyone admin privileges poses a risk of users accidentally provisioning some AWS resource that might accrue an unnecessarily high charge. For example, AWS provides a service that is called Cloud HSM which is a hardware security module that enables you to manage and store your encryption keys and comply with various compliance standards. Currently, the pricing is an hourly-based rate for using the service. However, previously, in order to provision this hardware security module, there was a $5000 charge up-front. If your business does not require such capabilities but the IAM user has unrestricted privilege, they can accidentally request such a service (especially if they are not aware of the pricing) and cause a significant spike in the bill. Giving IAM users permissions only necessary for their role will reduce the possibility of such “accidental” request from happening. In addition, it also prevents IAM users from accessing unauthorized data such as CloudTrail logs and tampering with or modifying logs. Therefore, ensure that the IAM users have sufficient privilege to conduct work relevant to their role, without grating them excess amount of privilege.
Implementing minimum privilege also minimizes the “blast radius” in the event that those IAM credentials get compromised. For example, if an IAM user’s account got compromised but that IAM user had read-only access to the AWS account, the bad actor would not be able to do much damage compared to if that account had administrative privileges. Therefore, it is important to take the time and implement proper permissions for each user. However, modifying each user’s policies can be cumbersome. That is why I would recommend using IAM Groups that allow you to assign policies to a collection of users. This is a great way to implement minimum privilege while easily managing permissions of all you IAM users even as your business scales.
Ensure that secrets are stored properly
Keeping secrets securely stored has been a struggle since the early days of computing. Today, most people don’t leave sticky notes on their desk with the password written on them. However, some developers still accidentally store credentials insecurely either in their configuration files or elsewhere. Sometimes these secrets (including AWS access key and secret access key) make it to a public Github repository or other publicly accessible locations.
Therefore, establishing a way to manage secrets is important. There are many third-party solutions that are available and AWS itself offers various solutions for storing secrets. One way which is quite common is to put secrets and also any other parameter values into AWS Parameter Store. The application can now make an API call during runtime to retrieve the secret values. This means that they don’t have to be stored with the application code, reducing the risk of their being exposed. Additionally, Parameter Store value can be encrypted with different keys and you can control who and which applications have access to decrypt those secrets using IAM policies.
Summary
Not using the root account, enabling MFA on the root account, setting up billing alerts, using minimum privilege accounts, and storing secrets securely are 5 steps to significantly increasing your security posture on AWS. However, this is not an exhaustive list. There are additional methods, tools, and strategies that can be leveraged to provide automation and secure your AWS infrastructure even more based on your business requirements. 1Strategy works closely with clients to ensure that their existing and future AWS infrastructure is well-architected based on the Well-Architected Framework whitepaper released by AWS. If you have further questions on how we can help increase your AWS account security posture, feel free to schedule a consultation with us or email me directly at pavel@new.1strategy.com.
