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.