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:

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:

We will discuss ways to prevent these security risks in your application layer in Episode 3 on April 11th.

Security Detection

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:

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.