AWS Public Sector Blog
Episode 2: Securing your app’s infrastructure
(Part 2 of 5)
Created in conjunction with a five-part Twitch mini series (March 28 – April 25), these weekly blog posts provide resources and guidance to support the 60-minute live videos. To sign up and learn more about the series, click here.
A post by Yuriko Horvath, Sr. Solutions Architect, Amazon Web Services
Before a developer can commit their first line of code, they must think about the security of their application. With a move toward a DevSecOps culture, security is not solely the job of the security team – in the same way that infrastructure and deployment are not the sole responsibilities of the operations team. Developers should partake in both operations and security, as they know their own application best.
This blog outlines a framework for thinking about security for your app’s infrastructure and how AWS’ product features can address those concerns.
Key Questions to Ask
Beginning in the whiteboarding phase, security should be top of mind. This affects the servers hosting your application, any related data stores, databases, or other infrastructure. When thinking through your application’s security, you should ask these questions:
- Am I using security in transit for every path in my infrastructure?
- Am I using security at rest everywhere I’m storing data?
- Am I preventing security exploits proactively?
- Am I able to detect a security exploit and respond with the right information?
Let’s review why the above questions are important for application developers.
Security in Transit
Your application data may flow inside or out of your network, such as to the internet. In either case, your app can be exposed to potential bad actors listening to network traffic to find and exploit your data. Encrypting internet traffic through HTTPS, SSL, and TLS lets your customer know that your application is verified and protected from a bad actor who might attempt to imitate your application. It also assures your customer that any information bad actors send to your application won’t be successfully intercepted. Other security protocols, such as SFTP, SCP, and SSH, can also be used when sending files or logging into a server remotely.
On AWS, certain patterns and products exist to help you design your infrastructure for security in transit, including:
- SSL Termination at the Application Load Balancer, Elastic Load Balancer, Network Load Balancer, and API Gateway level
- Encryption between your Load Balancers and API Gateway to your back-end servers
- TLS encryption, which is available for all services
- SSL when connecting to Amazon RDS
- Using bastion hosts in a public subnet to allow SSH access to all other servers in private subnets
- Using Systems Manager for shell access to all servers, instead of direct SSH access or bastion hosts
Security at Rest
Encrypting all stored data related to your application is important, especially in the case of an internal network user becoming a bad actor, or a bad actor gaining network access (e.g., through a stolen computer with open access to your application’s infrastructure). Whether you have data stored on your servers, databases, file servers, object stores, or elsewhere, your data should be encrypted.
Encryption keys are random strings used in encryption and decryption algorithms. AWS customers have the option to use an AWS-managed customer master key (CMK) or manage and set policies for their own keys using AWS KMS, including key rotation and access. Enabling encryption on your data stores and choosing your key type is required as part of the shared-responsibility model. This list shows AWS storage services where encryption with KMS is supported, inclusive of EBS volumes, Amazon RDS, and S3. To encrypt your own data before storing, AWS CloudHSM enables you to integrate and manage your own keys.
As application development security patterns continually evolve, application secrets, passwords, and API keys don’t need to be stored redundantly throughout your application. AWS provides the following:
- Using AWS Secrets Manager to provide application access to and rotate API keys, database credentials, and other secrets
- Using Parameter Store to provide application access to third-party API keys, database credentials, and other secrets to EC2 instances or ECS
- Using environment variables in Lambda to pass secret information to the function
Security Exploits Prevention
When your application is up and running there are common security exploits (e.g. OWASP’s top ten) that can be used to degrade the performance of your application, compromise the functionality, or destroy data. Untrusted network traffic, distributed denial of service (DDOS) attacks, and other common web application security exploits should be prevented before reaching your application layer.
The following services help prevent and mitigate security attacks to your application’s infrastructure, before they reach your back-end servers:
- Using AWS Shield as protection against DDOS attacks
- Using Web Application Firewall (WAF) or AWS Marketplace partner firewall solutions to prevent common security exploits against your application
- Using Security Groups to control access what network traffic, protocols, and ports are accepted by your application’s backend servers
- Using Amazon Inspector or AWS Marketplace partner vulnerability assessment solutions to inspect your back-end servers.
We will discuss ways to prevent these security risks in your application layer in Episode 3 on April 11th.
Even with these precautions and mechanisms in place, you still need to be vigilant about detecting and responding to potential security attacks while your application is up and running. Logging and looking for changes in usage patterns at all levels of your application and infrastructure is key.
The below can help with logging and detection:
- Creating a CloudTrail log file in S3 for a history of all API calls to AWS for your account or organization
- Enabling AWS Config to record all changes to your AWS resources, (refer to this discussion in Episode 1)
- Enabling access logs to specific resources in your application’s infrastructure, such as S3 buckets, Elastic Load Balancers, Application Load Balancers, Amazon Redshift, and Amazon RDS
- Enabling VPC Flow Logs to see network flows and usage
- Enabling Amazon GuardDuty to monitor threat detection by looking for unusual activity in CloudTrail, VPC Flow Logs, and DNS Logs
- Centralizing all logs from your account or organization into Elastic Search, layered with Kibana as a data visualization tool
Upfront security setup for your application’s infrastructure makes you proactive in security prevention. With every change to an application’s infrastructure, developers should ask: How am I taking care of security in transit? How am I taking care of security at rest? How am I preventing security attacks? Would I be able to detect and respond to a security attack? For additional measures, consider conducting a Well Architected Review of your application, as well as reading through other security best practices and use cases on our AWS Security Blog.
If you missed “Episode 1: Getting Started With Secure App Dev,” you can read it here.
The next blog in our five-part series will be “Episode 3: Building Secure Code” blog post. Stay tuned.
Subscribe to the AWS Public Sector Blog newsletter to get the latest in AWS tools, solutions, and innovations from the public sector delivered to your inbox, or contact us.