Twitch Episode 1: Getting Started With Secure App Dev: Job 0

(PART 1 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.

Security is job zero at Amazon Web Services (AWS). What should that mean to you as a new user of the AWS Cloud? How does it translate to a regulated environment, such as healthcare, government, education, or financial services? Securing your AWS account is the first place to start.

How you set up your account depends on your organization. It’s possible your account was created for you by your central IT organization, using AWS Control Tower or AWS Organizations. If that’s the case, some of the below may have already been done for you. The following can serve as a helpful check as you get started.

Step 1: Secure Your Root Identity (and Don’t Use It)

Let’s define some terms before you begin:

• AWS Account – This is the top-level container for the formal relationship with AWS. It is associated with (1) the owner’s email address and password, (2) control over resources created under its umbrella, and (3) payment for AWS activity related to those resources. An AWS account is permissioned for any task involving its AWS account resources. This contrasts with the privileges of a “user,” which is an entity contained within the account.
• User – Often referred to as an “IAM account,” this is a person or application within an AWS account that needs to make API calls to AWS products. Each user has a unique name within the AWS account and a set of security credentials not shared with other users. These credentials are separate from the AWS account’s security credentials. Each user is associated with one AWS account only.

When you create an account, your login credentials are set at the account level by default – also known as an AWS account root user. First, lock your root. This link will give you a list of IAM best practices, including not logging into your root more than necessary. Second, create an administrative user (another IAM best practice) as explained here.

You will now be logged in as an admin user – and not as a root user.

Step 2: Key Secrets and Keeping Them Secret

It’s important to put some guardrails in place to help keep your keys secret. AWS has a project that prevents you from committing passwords and other sensitive information to a git repository. Since we’re all human and make mistakes, it’s best to proactively set risk-mitigation mechanisms. Once you’ve gotten the git webhooks set up, you are less likely to commit passwords and keys. The next item to address is ensuring you’re not hard-coding passwords and keys (yes, it’s tempting). Instead, you can create Roles in IAM.

What does this do for you? It allows you to give resources specific permissions by attaching the role directly to the resource. This can be done programmatically in the AWS CLI or in the console. Using AWS Secrets Manager helps with fine-grained permissions, audibility, and rotation – all baked in.

Why should you care? You don’t have to put your password or key anywhere in the application. If your EC2 instance or Lambda function has a role attached to it that allows PUT access to S3, it doesn’t need a key and a secret key to PUT objects into S3. Doing this in advance is better than trying to clean up a leak afterwards. For example, AWS Lambda has environment variables where you can store your sensitive access. It makes iterating through versions of your function easier. But what about passwords or keys as an environment variable? Lambda encrypts these using the AWS Key Management Service (KMS), while handling the decryption transparently for your code.

Step 3: Central logging

Let’s say you’ve deployed an application, people are using it, but a few users have started complaining about long load times. Now, you or your DevOps expert must dive into a dozen different logs across your stack to find out the source of the issue. Alternatively, you could have proactively set up centralized logging. CloudWatch Agent lets you ship all of your logs to Amazon CloudWatch. For example, you went to the trouble to set up an ELK stack ahead of time. Now, instead of tracing errors through several different logs across your app’s systems, you can dig in to one location, saving time and effort.

Step 4: Track Your Changes

As a developer, you cannot manage what you do not measure. Compliance is about eliminating the guesswork, and “probably” doesn’t cut it with auditors – even if the probability is above 90%. Fortunately, there is AWS Config. AWS Config helps track resource inventory and changes to that inventory.

Why should you care? AWS Config and AWS Config Rules can keep you in a compliant state with whatever compliance framework you target. Need an example? You write your bit of an application, commit it, and it sails through the CI/CD pipeline (with automated testing.) It works just fine, until it doesn’t. Wouldn’t it be awesome to know what changed in the environment that might be related? AWS Config can do that. It’s useful for security analysis, auditing, and compliance, but for someone in a DevOps org, knowing what changed and when can save you critical time.

Once you’ve secured your AWS account, it’s time to secure your application’s infrastructure – before you write any code. Keep an eye out for episode two of this series. Sign up for reminders here.

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.