A common misconfiguration is to assign access to the complete set of permissions for each AWS item. If the application needs the ability to write files to Amazon S3 and it has full access to S3, it can read, write, and delete every single file in S3 for that account. If the script’s job is to run a quarterly cleanup of unused files, there is no need to have any read permissions, for example. Instead, use the IAM service to give the application write access to one specific bucket in S3. By assigning specific permissions, the application cannot read or delete any files, in or out of that bucket.
“In the event of a breach, the worst that can happen is that more files are written to your account. No data will be lost,” says Nunnkhoven.
Mistake 5: Relying heavily on passwords
The recent wave of data breaches and follow-up attacks with criminals using harvested login credentials to break into other accounts should have made it clear by now: Usernames and passwords aren’t enough. Enforce strong passwords and turn on two-factor authentication to manage AWS instances. For applications, turn on multifactor authentication. AWS provides tools to add in tokens such as a physical card or a smartphone app to turn on multifactor authentication.
“Your data and applications are the lifeblood of your business,” Evident.io’s Robel warns.
Mistake 6: Exposed secrets and keys
It shouldn’t happen as often as it does, but credentials are often found hard-coded into application source code, or configuration files containing keys and passwords are stored in publicly accessible locations. AWS keys have been exposed in public repositories over the years. GitHub now regularly scans public repositories to alert developers about exposed AWS credentials.
Keys should be regularly rotated. Don’t be the administrator who lets too much time pass between rotations. IAM is powerful, but many of its features are frequently ignored. All credentials, passwords, and API Access Keys should be rotated frequently so that in the event of compromise the stolen keys are valid only for a short, fixed time frame, thereby decreasing attacker access to your instances. Administrators should set up policies to regularly expire passwords and prevent password reuse across instances.
“If an attacker is able to steal your keys, they can then access the resources in your account as if they were you. Use roles whenever possible,” Nunnikhoven says.
Mistake 7: Not taking root seriously
It pops up time and again. Admins forget to disable Root API access -- a highly risky practice. No one should be using the AWS root account and associated keys, let alone sharing them across users and applications. Keys to access AWS resources directly should be used sparingly, as the keys need to be tracked, managed, and protected. In cases where root is absolutely necessary, Saviynt found that those accounts often have multifactor authentication disabled. The root account deserves better protection than that.
Sign up for CIO Asia eNewsletters.