As per a recent report, approx. 80% of all IT budgets will be committed to cloud apps and solutions within the next year or so. Also, an important insight in this report is that 49% of businesses are delaying their cloud deployment due to a cybersecurity skills gap.
It is especially important for small and medium businesses to take critical measures in securing their digital assets on the cloud. In this article I will cover the most basic but absolutely must have policies to safeguard your Amazon Web Services account.
5 Basic Steps to Secure Login Access to AWS Services:
- Your root AWS account has superhuman powers! It should only be used to login to AWS maybe once or twice a year (if needed) and never be used to manage compute resources directly.
- Enable Multi-Factor Authentication on your root credentials. This is a must! Furthermore, it is quite simple to configure using a virtual interface like Google Authenticator. So do not skip this at any cost. It adds a much needed second layer of protection to your critical assets on the cloud.
- Have a super complex password policy in place. AWS allows you to enforce the complexity in IAM password policy section. I would even advise that for all logins you create on AWS, use a password generation tool like this. No matter how secure you think your birthday, car registration no. or anniversary date it, it can always be hacked. So set non-sensical, non-dictionary based password which have a mix of upper & lower cases, special characters, numbers et. al.
- Within the same IAM policy add a password rotation rule of 15 days. This ensures users are forced to change their passwords periodically and reduces impact of accidental leaks of stale passwords.
- For every business function that would require access to cloud compute resources create a specific IAM role. For example, a ‘Developer’ role for your development team that can have full access to EC2 instances, S3 buckets, Lambda functions etc. but no access to other features such as billing & cost management. Similarly an ‘Accounts’ role that can have access only to invoices and payments methods and no access to compute services. You can then create new IAM users and assign them to these roles. Since all of these users will use the common IAM password policy, common security practices are enforced by default.
Also, assuming most of your web & application servers will be hosted on EC2 instances I would like to highlight a simple but must have process that you could follow to enable access to these instances.
Securing Access to Your EC2 Instances
AWS by default uses key-pairs to allow SSH access to EC2 instances. At the time of launching a fresh EC2 instance you have the option to create a new key-pair or use an already existing one.
It is a fairly common malpractice to generate a new key-pair for every EC2 instance that you create. Some people think this is the best approach to secure your servers. This is a grossly false assumption.
An even bigger malpractice is to share a key-pair file (both public & private keys) amongst a team of developers. PLEASE DO NOT DO THIS! It goes against the very fundamentals of how key-pairs are supposed to provide security in the first place.
Here is a better approach to providing access to your EC2 servers in a more secure fashion:
- Ideally generate & maintain only a single key-pair file at a system admin level. This key-pair file should only be stored by the top level system administrator of your organisation and should NEVER be shared with anyone at all. It will be the sole key-pair used to create & launch any instances across any region within your AWS cloud.
- Ask each of your deployment team members to create a fresh key-pair for themselves on their local machines. This is a fairly straightforward process using tools like OpenSSH. Step by step instructions are available here.
- Ensure you also ask your team members to use a strong passphrase while generating the keys. This adds an additional layer of security in case they accidentally compromise & expose their keys.
- Now for each server you might have one or two developers who would need SSH access to make deployments or other configuration changes. Your system administrator should then allow access to a server only to these specific individuals.
- The way to do this, is to add their public keys to the EC2 instances. Let’s say you want to allow access for a person named John in your dev team and his public key file is named “john.pub”.
cat john.pub | ssh -i root-key-pair.pem email@example.com "cat >> .ssh/authorized_keys"
- “root-key-pair.pem” is your system admins private key file. So the above command would add John’s public key to the specific EC2 instance as an authorized key.
- John will then be able to access the server over SSH simply with
ssh -i john.pem firstname.lastname@example.org
The above approach is more secure and flexible because in the future if you want to revoke access for a specific user to an instance you only need to delete his/her public key from the authorized_keys file on the EC2 server. All other users will continue to enjoy access without problems.
There are of course tons of other things that you can do to further safeguard your cloud infrastructure, but the above ones apply to organisations at all levels: small businesses to enterprises.
You can read more in-depth documentation on Amazon’s recommended best practices here.