Don’t ignore AWS security resources
The AWS cloud was designed and architected with security in mind. It is trusted by some of the world’s biggest brands, who feel they’ve chosen a world class protected infrastructure on which to run their businesses.
Because you’re building your systems on top of AWS, you have to remember that security responsibilities are shared: AWS secures the underlying infrastructure and you must secure anything you build on top of it and the services you use.
This post will cover AWS security practices that are critically important for all users, as well as where you can find more information about compliance and security processes.
Identity and Access Management (IAM)
The first and most important task in AWS security is properly caring for your root account and Identity and Access Management (IAM) users.
Your AWS root account is accessed when you log in using the email address and password you specified when you signed up. This login has full access to all account resources, including billing and the ability to actually close the account.
Because the root account has such frightening power, you are effectively giving up the keys to your whole operation whenever anyone else gets access – whether you knowingly let them in or, through neglect, fail to prevent their unwelcome entry. It is highly advised not to use your root account in day-to-day operations and take advantage of IAM Users instead.
There have been well-documented incidents of AWS root account breaches that directly brought about the permanent demise of entire companies.
Never lose sight of the fact that the root account is critical to your AWS security.
Through IAM, you have complete control over every level of access to AWS services and resources. You should create an IAM user with administrator-level permissions for your day-to-day administrative tasks.
Additionally, if you require multiple users to access your AWS account, you should create individual IAM Users, each with their own unique credentials, and create granular permissions defining who has access to which resources. This allows you to follow the AWS security best-practices of role separation and least privilege. “Least privilege” means allowing all users access to only the very narrowest range of resources that are absolutely necessary, thus reducing your exposure to possible threats.
MultiFactor Authentication (MFA)
While having a strong and secure password for your account and all your users is important, this alone doesn’t provide you with enough protection for the sensitive data and services for which you might be responsible.
AWS MFA adds a second layer of protection, prompting for an authentication code – which is sent to some pre-configured mobile device like a smartphone – on top of your password. This is known as a second authentication factor (something you have: an MFA device) that works alongside your first authenticator factor (something you know: your password).
You can enable MFA for your root account as well as for individual IAM users. AWS supports three types of MFA form factors: virtual MFA (mobile applications), hardware key fobs, and hardware display card devices.
There are businesses that practice strict AWS security policies requiring root accounts to be protected by a hardware token that is secured and locked in a safe.
AWS Security best-practices
These practices should be followed by the administrators of any AWS account: large or small. In general, however, you should remember that traditional security best-practices still apply, and should be applied in all the normal ways. Areas of particular concern include data encryption on the fly and at rest, protection from man-in-the-middle attacks, regularly applying security patches, log collection, and system monitoring.
Since AWS was built and continues to evolve with security in mind, you have many built-in tools at your disposal that will help you, including VPC firewalls, private subnets, serverside data encryption, security logs, AWS CloudTrail, and dedicated AWS connections.