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

Mistake 8: Putting everything in one VPC or account

The more teams and workloads added to an account or Virtual Private Cloud (VPC), the more likely you are to meet the lowest common denominator. AWS has very generous limits on VPCs and accounts. There's no reason not to isolate workloads and teams into different regions, VPCs, or even accounts. The simplest way to start is to make sure that development, testing, and production are in different accounts.

Mistake 9: Leaving wide open connections

Too many admins enable global permissions to instances. When you use, you are giving every machine everywhere the ability to connect to your AWS resources. “You wouldn't leave the front door to your house open, why do you use” Robel asks.

AWS Security Groups wrap around EC2 instances to permit or deny inbound and outbound traffic. It’s tempting -- and expedient! -- to add broad access rules to security rules. Fight the urge. Give your security groups the narrowest focus possible. Use different AWS security groups as a source or destination to ensure only instances and load balancers in a specific group can communicate with another group.

One-third of the top 30 common AWS configuration mistakes identified by Saviynt involve open ports. Workloads showed open RDP, MySQL, FTP, or telnet ports via Security Groups, and Security Groups showed open RDP and SSH ports. Others were wide open to the internet.

Thanks to high-quality automation tools such as OpsWorks, Chef, Ansible, and Puppet, there’s no reason to allow remote access -- such as SSH or RDP -- to EC2 instances. If an application or OS needs to be patched, it’s better to create a new image and spin up a brand-new instance with the patched applied instead of trying to connect to the instance and applying a patch in place.

If remote access is necessary, a “bastion host,” where users connect to an intermediary EC2 instance, is a safer option. It is easier to manage all remote access connections going to a single host, then restrict what connections are possible between each instance. It’s also possible to lock down the bastion host so that only pre-approved systems are allowed access. Control all remote access in order to reduce your overall risk.

Mistake 10: Skimping on encryption

Many organizations don’t enable encryption in their AWS infrastructures, and the reasons vary from it's too hard to not realizing it was important. Saviynt found that Relational Database Service (RDS) instances were being created with encryption disabled -- a potential data breach waiting to happen. In EC2, there were workloads with unencrypted Elastic Block Storage (EBS).

Data in S3 should be protected, and traffic between EC2 instances should be secured. Implementing encryption incorrectly is equally as bad -- if not worse -- than not having encryption at all, but Amazon actually offers tools to help ease the challenges. Administrators reluctant to enable encryption over concerns of managing keys should let AWS manage those keys. It’s always possible to migrate to the organization’s own public key infrastructure afterward.


Previous Page  1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.