Full MFA Protection in AWS

Security best practices typically call for some form of multi-factor authentication when accessing sensitive information system, or when accessing systems with elevated privileges (admin level). In most cases, accessing a public cloud provider via WebConsole or API is accessing the system for administrative purposes and requires an extra level of protection than a simple password. AWS Provides the ability to use MFA on it’s systems, but the ability to enforce that across all facets of the AWS API is not a trivial task.

Bucket Policy Example Statements

So I recently posted about AWS S3 Bucket security and all the way AWS makes it easy for your to mess things up. This post contains some example Bucket Policies I like to use for various needs. Bucket Policies are pretty powerful. You can specify specific AWS accounts who can access your bucket. You can apply specific conditions around Source IP or Encryption settings. You can limit the access by object prefix.

Interesting AWS API Calls

For a project at work, I needed to highlight users who have access to IAM Actions that are considered “privileged”. There not being a good record of those, I decided to create one. AWS Interesting API Calls is a yaml file in github that contains a list of high risk calls and some data about them. I’ve also written a python module that can parse the file in various ways.

Securing your S3 Buckets

AWS S3 Bucket security has been in the news a lot recently. Almost 200 million records on US Voters were found on an unsecured S3 bucket owned by a GOP data analytics firm. A third-party vendor to Verizon left 14 million customer records (including SSN partials) publicly readable. Then Dow Jones exposed 2 to 4 million customer records. AWS has responded to this spate of bad press with a several changes to the AWS Console, and most recently took the extra-ordinary step of emailing account owners informing of any publicly readable buckets.

Moving From Wordpress to S3 and Hugo

Anyone who follows my blog (and that’s none of you) would notice I rarely find time to post. Since moving my blog from Linode to AWS EC2 a few years ago I’ve spent way more time patching WordPress than writing in it. MySQL would run out of memory and crash, leaving my blog down for days on end. I never use the bloggy features of Wordpress since the only folks who ever commented were spammers.

Terraform vs Cloudformation

New employer uses Terraform, so I’ve finally had a reason to grok Terraform and what it can do. I’m not convinced it is better than CloudFormation. Here are my thoughts on it. Pros Terraform can manage more than just AWS Resources. Useful if you need to orchestrate across multiple clouds, but I’d fear the dependency issues there. At my ex-job I’d have been very interested in how Terraform could control both AWS and Chef.

What I do to a new AWS Account

When creating a new AWS Account, I typically do the following: Create the CloudTrail Create a Deploy Bucket Create Generic Alert topics for the account and subscribe my email and cell Create a stack to send certain cloudwatch events to a slack channel Configure requireMFA Configure Password & API Key Expiration Warning All of these are done via automation of course

Deploying a CloudFormation Template simply

Deploying Cloudformation templates via the CLI is a complex process that lack repeatability. Typing out long command lines, and then having to execute other commands either before or after the stack runs results in lots of custom scripting. Rather than go down that route, I created a tool that takes a yaml manifest file that allows you to specify all the details around your stack deployment in one data-driven place.

Creating a set of generic SNS Topics

When I’m creating a new AWS account, I find it helpful to have a generic set of SNS topics that ping me and my team if something goes wrong. The following CloudFormation template can be used for that purpose. It requires a few parameters and includes an optional Lambda that will send the alerts to a Slack Channel. Three Topics are created for critical, error and info-level alerts. Critical alerts will send me a text and email, while error only sends an email.

Requiring AWS IAM Users to Enable MFA

When AWS announced Lambda at the 2014 re:Invent, my immediate thought was “Cool, you can now program the cloud itself”. Since then, everyone has jumped on the “serverless” bandwagon for building apps. After this year’s re:Invent I’m inspired to get back to using Lambda to program the cloud.

One of the sessions I attended was on Security Automation. I’ll have more to say on that later. However, it gave me the idea for a setup that would require users to have MFA enabled, or otherwise be blocked from doing anything with their IAM User in the AWS account.