AWS is a very secure ecosystem, but they can’t guarantee that what you do in the cloud is going to be secure. That responsibility is left up to you, although AWS will try to nudge you in the right direction.
This guide covers what you should do from the AWS Console to make your network and account more secure. In addition to everything here, you’ll need to make sure your own applications running on your EC2 servers (or otherwise) are themselves secure. For example, enabling HTTPS on a web server, or keeping your dependencies and programs up to date.
Use Two Factor Authentication For Your AWS Account
Your main AWS account controls all your AWS resources; if someone were to gain access to it, they’d have complete control over your resources, and could delete everything. You’ll want to make sure your login method isn’t just a simple password that could be stolen.
AWS offers a few multi-factor authentication methods. The easiest to use is Virtual MFA device, which uses apps like Google Authenticator and Authy to turn your phone into a virtual key fob. AWS also supports hardware keys from YubiKEy and Gemalto, but those cost money. Alternatively, you can use SMS, but only for administrative users you add, not your root account.
Click on your account name in the top menu bar, and select “My Security Credentials.”
Under “Multi-factor Authentication,” click “Activate MFA.”
Select “Virtual MFA Device,” and open your authenticator app on your phone.
AWS will show you a QR code that you should scan with your authenticator app to link the two together. Then you can begin entering codes; AWS will ask for two consecutive codes, so you’ll have to wait 30 seconds between them. Click “Assign MFA” when you’re done.
Now when you sign out, you’ll be asked for a code from your phone when you log back in.
If you’re setting up a physical key fob, you’ll just have to plug it in to link it, and then plug it in every time you want to sign in.
Close Your Firewalls
Whenever you create a new EC2 instance, you’ll be asked to choose a security group or make a new one. This security group is a firewall, and defines which ports will be open. By default, AWS opens port 22 (for SSH) for all IPs coming in, and allows all traffic going out.
This means anyone can attempt to authenticate over SSH, which isn’t a huge issue (since AWS uses SSH keys by default), but it’s good practice to limit most traffic to your IP unless it has a reason to be open to the world.
Click on “Security Groups” in the sidebar of the EC2 Management Console, select the group your instance uses, select “Inbound,” and click “Edit.” Alternatively, you can access this security group from the Instances panel by clicking on it under the “Security groups” property.
From here, you can edit the rules for this security group. Outbound is usually fine to leave open, but inbound should be left as closed as possible. Click on the SSH rule and switch the source from “Anywhere” to “My IP,” which should close it off.
You don’t have to worry about your IP changing and locking you out, since you can always reset it from the AWS console.
If you have multiple instances talking to each other, such as a database server that connects to an API server, you should secure the connection between them by only allowing secured traffic between the two instances. Nobody else should be able to talk to the database except the API server, with the exception of your IP address for management purposes.
You don’t have to specify individual IP addresses manually, since AWS will let you allow traffic to all devices assigned a specific security group. If you have multiple database servers, you could give them all the “database” security group, and allow your API server to talk to anything with the that security group. You can also allow everything in a specific subnet, which requires you to use AWS’s VPC.
Set Up IAM Users
AWS Identity and Access Management (IAM) users are a way to allow access to your account without giving out full permissions. If you have multiple people accessing your AWS resources, you should give them access through an IAM user. You should never give out access to your root account.
IAM users aren’t just for other people though; if you have code that needs to access your AWS account, you should allow access through an IAM user. Some AWS services will make use of IAM users to act on resources in your account.
AWS also recommends using an IAM user with administrator permission for all of your normal tasks. This way, you can lock away your root account credentials and only use it when it’s absolutely necessary, mostly for account maintenance.
IAM users can be assigned very specific permissions, so you can be sure that in the event one of them is compromised, it won’t affect your entire infrastructure. You can also assign these permissions to role groups, and assign roles to users.
You can create new IAM users through the IAM Management Console. They’ll be given a randomly generated password, which they’ll be forced to change on first login. You should apply an IAM Password Policy to make sure these passwords are secure.
Perform Regular Security Audits
You should periodically review your security to make sure there’s nothing you missed. AWS provides a very thorough checklist for this exact purpose.
This checklist has you delete old resources that are not in use anymore and review your security policies for different services. The main sources of insecurity are changes in how you use AWS, like if you’ve started using a new service, stopped using an old one, or have had people leave. In each case, you should review your access policies.
If you’re not using AWS for an organizational account, it’s probably not necessary to go down this entire checklist, but you should still make a good habit of looking over your security policies every once in a while.
