This content is part of the Conference Coverage: Your passport to AWS re:Invent 2016

Four gaffes that can thwart security in AWS

Not understanding basic security concepts or how to use a particular AWS security feature can do more harm than good when securing public cloud data and resources.

Cost and security have been barriers for many businesses looking at public cloud. Instead of opting for an unfamiliar IT environment managed by public cloud providers, enterprises chose to invest in on-premises resources that IT teams could control in-house. But times and attitudes toward public cloud have changed.

Even though public cloud providers like AWS have largely chipped away at those barriers, offering low-cost ways to move resources to the cloud, some security mistakes remain. An inattentive approach to security creates holes that no managed services or security tools can fill.

AWS' suite of security services protects data and resources in the cloud -- as long as enterprise IT can overcome the learning curve associated with using those tools properly. The model of shared security in AWS can be vexing to some, and the host of tools available can further complicate the approach needed to be sure resources are safe. These four particular mistakes developers make with security in AWS are worth keeping an eye on in your cloud operation.

Avoiding shared responsibility

AWS regularly preaches the concept of shared responsibility, but that doesn't mean all of its customers understand it.

On-premises and colocation security configurations involve a different level of hands-on work. IT teams handle most or all of the responsibility of securing data and workloads. So, when a business switches to AWS, some of those IT professionals make the mistake of thinking the cloud provider handles all aspects of security in AWS. This can lead to a scramble after migration to meet and maintain compliance for clients with strict needs.

"From a strategic risk-management perspective, many customers aren't as careful as they should be about vetting their architecture and have an attitude that it is the provider's job to keep them secure," said Jim Reavis, CEO of the Cloud Security Alliance, in an email. "This can manifest itself in many ways, including … [neglecting] fault tolerance and redundancy capabilities, such as with multiple availability zones."

Improperly configured roles and AWS security groups

AWS Identity and Access Management (IAM) controls user access to services and resources. It's a bedrock AWS security tool that integrates with the entire suite of services and tools, but that doesn't mean all developers integrate it correctly.

First, enterprises may fail to follow the policy of least privilege, granting too much access to too many resources.

"[Security groups] should be thought of as firewalls and have a 'deny all except that which is explicitly allowed' philosophy," Reavis said.

Additionally, IT teams will often set up IAM roles and AWS security groups to satisfy organizational demands and then slack on enforcing and updating those access controls. AWS security groups, in particular, can prove difficult to manage -- even when an enterprise commits necessary personnel and resources to handle it. This can lead to vulnerabilities across an entire cloud deployment.

Enterprises need to have an internal framework in place to regularly evaluate security groups and IAM policies.

Inefficient use of logs

AWS' suite of security services protects data and resources in the cloud -- as long as enterprise IT can overcome the learning curve associated with using those tools properly.

Logging tools can often determine when and where a problem occurred as well as which user was involved; many IT teams rely on these tools as a component of security in AWS. But developers leave some logging capabilities on the table.

Amazon CloudWatch Logs collects data from Elastic Compute Cloud instances and AWS CloudTrail events, giving developers insights into everything from application performance to API calls. CloudWatch Logs offers a wealth of information about a cloud deployment, and that information can be pumped into other services to set up custom alerts or trigger AWS Lambda functions in response to potential problems.

Some customers completely pass on CloudTrail, an API-logging service. "CloudTrail is an enormously useful service for logging all AWS API calls," Reavis said. "It can assist in actively troubleshooting a wide variety of security issues and also help in forensics. Many customers do not use it."

Lack of encryption

Data encryption has become a national talking point. End users with any type of smart device can use encryption to protect personal data, which has pushed the technology to the forefront of the political landscape.

While enterprises have similar encryption capabilities at hand through AWS, not all of them use them. AWS customers can turn to the AWS Key Management Service or use built-in encryption capabilities in Simple Storage Service or Elastic Block Store. Developers must carefully approach encryption key creation and management and consider it a separate task from managing the actual data storage.

"Too much information is either not encrypted at all, or not done well," Reavis said. "There are a myriad of options -- some provided by AWS some provided by [third] parties. Some solutions are server side; some encrypt the information on the client side before it enters the cloud," he added.

The takeaway? AWS customers need to think encryption through. "There isn't a one-sizes-fits-all solution," Reavis noted. But separating storage management and encryption key management can better protect AWS workloads.

Next Steps

KMS limited by encryption key replication

Best practices for AWS security start with IT teams

Keep up with security responsibilities in AWS

Dig Deeper on AWS security