Nathan Peck
Nathan Peck
Senior Developer Advocate for Container Services at Amazon Web Services
Nov 22, 2017 6 min read

A quick (opinionated) guide to securing data on AWS now!

The EU General Data Protection Regulation goes into enforcement in May 2018. It applies to “all companies processing the personal data of data subjects residing in the Union, regardless of the company’s location.” Once the GDPR grace period ends the penalties for a breach of data where the organization has been shown to violate basic privacy design concepts can be 4% of annual global turnover or €20 million, whichever is greater. I highly recommend that all companies that deal in customer data take some time to read through the GDPR thoroughly and understand its implications. In addition to serious monetary penalties, if you don’t take responsible steps to keep customer data secure you will look totally inept and lose customer trust when that data does eventually leak. The stakes are high!

Data security on AWS

Virtual Private Cloud

Run your machines inside a private subnet inside an AWS VPC. Very few (if any) of your servers should have public IP addresses. Ideally your EC2 instances have private IP addresses only. The only way to get web traffic to an instance should be through a load balancer that is forwarding traffic to specific ports on specific machines. This greatly reduces your attackable surface area.

Security Groups

Security groups act like a firewall for your instances to limit what ports instances can get traffic on and from what sources they accept traffic from. Instances in a private subnet should only accept traffic from a load balancer, or from other internal instances. If you do choose to run some instances in a public subnet with public IP addresses they should only accept traffic on public service ports, for example only on port 80 (HTTP) and port 443 (HTTPS).

No SSH

AWS has numerous orchestration platforms, such as Elastic Beanstalk, Elastic Container Service, and EC2 Simple Systems Manager. With these tools you can interact with your instances securely without ever needing to SSH to instances. There is no excuse for having your port 22 open to the world. Instead your instances should be provisioned, setup, and operated with hands off automated tooling, and monitored using logs and metrics that are extracted from the machine via tools like AWS CloudWatch logs, and AWS Cloudwatch Metrics. SSH should almost never be necessary to operate an instance.

AWS Relational Database Service Encryption

AWS RDS provides a fully managed relational database platform that both backs up as w[ell as secures your data. You can encrypt your data in transit by enabling SSL for connections between your instances and your RDS database, as well as encrypt your data at rest using encryption keys.

AWS Elastic Block Store volume encryption

Amazon EBS is networked block storage volumes for your instances. You should enable encryption for these volumes if you are self hosting a database and storing private user data on these volumes.

S3 encryption

Sensitive data should be encrypted with a key prior to putting it into AWS S3. You can either let AWS manage the encryption key, or you can manage the encryption client side using a key you provide.

IAM Roles

It is critical to use IAM roles. Each user (or process) that interacts with your account should have its own credentials, and the ability to assume one or more IAM roles. If you have a single credential pair that is being shared by all users of your system you are at risk. Instead each developer or admin should have their own credential pair, each CI/CD process that builds your code should have its own credentials, each instance in your cluster should have its own credentials, and each service that runs on those instances should have its own credentials. Then each user of your AWS resources should be able to use its credentials to assume a role that is limited to only the specific actions and specific resources that particular user needs.

No static credentials

Static credentials are always a security risk. If you have static AWS API credentials committed to your code repository you are doing it wrong, and are very vulnerable. You should be using IAM Roles for instances or if running in Elastic Container Service use IAM roles for tasks to give your running processes unique, short-lived and automatically rotating credentials. For human developers and admins you should also vend them short lived credentials. Some organizations go as far as requiring employees to fetch fresh API credentials each morning when they come into work. Assume that any credential that stays static long enough will be leaked, whether by a hacker, by accident, or even by a disgruntled employee. The only way to limit the impact of credential leaks is for credentials to be nonstatic by default.

AWS Key Management Service

When you have sensitive data to store you should be encrypting it using a key. AWS KMS gives you an easy to use SDK for provisioning keys and using them to encrypt your data. You can control access to the keys using IAM roles, to ensure that only the right users or services can use specific keys to decrypt specific pieces of information.

AWS CloudTrail

AWS CloudTrail continuously monitors and records all the API calls being made on your AWS account, and in combination with giving each user their own credentials it gives you an auditable trail of all the actions taken by each user of your system.

Amazon Macie

Amazon Macie uses machine learning to discover the data that you have in your AWS account, and learn how it is accessed. It can warn you if you have for example a public S3 bucket containing private information, or if access patterns for data change suddenly, indicating that someone may be misusing their access to data.

Amazon Inspector

Amazon Inspector automatically assesses applications for vulnerabilities or deviations from best practices. After performing an assessment, Amazon Inspector produces a detailed list of security findings prioritized by level of severity.

AWS Web Application Firewall

Filter out potentially malicious traffic before it reaches your application using AWS WAF. Using WAF you can create rules that can help protect against common web exploits like SQL injection and cross-site scripting.

Conclusion

AWS has a shared responsibility security model. This means that AWS is responsible for the physical security of the underlying hardware, the security of the virtualization layer, and the security of all their core services, but you are responsible for the security and configuration of what you build on top of AWS. Fortunately AWS also provides you with all the tools you need to build world class secure applications on top of AWS services.