Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

10 AWS security blunders and how to avoid them

Fahmida Y. Rashid | Nov. 4, 2016
Amazon Web Services is easy to work with -- but can easily compromise your environment with a single mistake

CloudTrail provides invaluable log data, maintaining a history of all AWS API calls, including the identity of the API caller, the time of the call, the caller’s source IP address, the request parameters, and the response elements returned by the AWS service. As such, CloudTrail can be used for security analysis, resource management, change tracking, and compliance audits.

Saviynt’s analysis found that CloudTrail was often deleted, and log validation was often disabled from individual instances.

Administrators cannot retroactively turn on CloudTrail. If you don’t turn it on, you’ll be blind to the activity of your virtual instances during the course of any future investigations. Some decisions need to be made in order to enable CloudTrail, such as where and how to store logs, but the time spent to make sure CloudTrail is set up correctly will be well worth it.

“Do it first before you need it,” says John Robel, a principle solutions architect for

Mistake 3: Giving away too many privileges

Access keys and user access control are integral to AWS security. It may be tempting to give developers administrator rights to handle certain tasks, but you shouldn’t. Not everyone needs to be an admin, and there’s no reason why policies can’t handle most situations. Saviynt’s research found that 35 percent of privileged users in AWS have full access to a wide variety of services, including the ability to bring down the whole customer AWS environment. Another common mistake is leaving high-privilege AWS accounts turned on for terminated users, Saviynt found.

Administrators often fail to set up thorough policies for a variety of user scenarios, instead choosing to make them so broad that they lose their effectiveness. Applying policies and roles to restrict access reduces your attack surface, as it eliminates the possibility of the entire AWS environment being compromised because a key was exposed, account credentials were stolen, or someone on your team made a configuration error.

“If you find yourself giving complete access to a service to someone, stop,” says Nunnikhoven. “Policies should include the least amount of permissions to get a job done.”

Mistake 4: Having powerful users and broad roles

AWS Identity and Access Management (IAM) is critical for securing AWS deployments, says Nunnikhoven. The service -- which is free -- makes it fairly straightforward to set up new identities, users, and roles, and to assign premade policies or to customize granular permissions. You should use the service to assign a role to an EC2 instance, then a policy to that role. This grants the EC2 instance all of the permissions in the policy with no need to store credentials locally on the instance. Users with lower levels of access are able to execute specific (and approved!) tasks in the EC2 instance without needing to be granted higher levels of access.


Previous Page  1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.