AWS Cloud Security
Beyond Best Practices

Request Demo

We’ve all been there. You need to protect an AWS cloud infrastructure, so what do you do? You go into their security best practices docs, follow their instructions, and forget about it. But what happens when you need to go further than that? Or when their recommendations don’t apply to your case?

In this article, we’ll expand on their suggestions and explain why sometimes it’s not enough to blindly follow Amazon’s recommended security best practices.

Best Practices – What They Don’t Tell You

We’ve been in this situation, and we know there are plenty of resources available on security best practices. However, they usually always cover the same points, and they are usually focused on the initial steps of protecting cloud infrastructure.

Among other things, they tell us to set up the simple things, like IAM users and roles and MFA; they warn you about the need for strong passwords and encrypting them (with KMS, for instance). These pieces of advice work and are useful at first. But they don’t tend to scale easily, and they definitely don’t provide us with full, robust security. If you want that, you need to go further.

Watch Out for Confused Deputy

The confused deputy problem is a security issue where a non-authorized entity can utilize another, more privileged entity to access your resources inside your AWS account. This only happens in cases where we have to authorize a third party to access our resources, but this practice has become commonplace in the world of cloud computing and SaaS.

If you don’t watch out for this, you could end up giving unrestricted access to your infrastructure to a malicious actor. To defend against this, use AWS’ external ID property when defining roles. The external ID is just a field (think of it like a password) that any entity must provide when assuming a given role.

However, this should not be taken lightly since there are many ways to brute force this field. When defined, it should have a secure, hard-to-guess password, and it should be sent in an encrypted way for your third-party vendor to keep. To harden your security even more, you can rotate these external IDs once in a while.

Keep Your Policies Simple, Small, and Scalable

You know AWS uses policies to grant or prevent access of principals to resources. This is how you should define who gets access to what, according to AWS. But if you’re going to keep scaling, you should definitely have a plan to maintain your policies in the long run. This means keeping policies simple and to the point.

For example, if you need to grant access to a certain service, like AWS Lambda, you could have a custom policy that does just that, and nothing more. This way, you can prevent unwanted interactions between users and services. It’s better to apply multiple policies to accomplish an action than to apply a single policy that does multiple things since the latter entails policies that are harder to read, maintain, and scale.

Why lean into IAM Groups Rather than Users or Roles?

On this topic, it’s worth mentioning that you shouldn’t be applying policies directly to users or roles, but rather using IAM groups to do it. This way, you can write multiple policies that apply to various subsets of your account’s users, like developers, sysadmins, testers, QA engineers, etc.

After writing those policies, you can assign them to groups, separating them by responsibilities, or by role within your company. The benefit here is that you can write one set of policies and apply them all at once. And if you need further granularity for a certain employee, you can then add one of your very simple policies to that specific user and add those permissions.

Otherwise, if you need to modify a set of users (developers, for instance), you only need to modify their group policies, which will modify all of that group’s user policies in a single blow.

Why leverage a Visibility Service Like AWS Systems Manager?

AWS Systems Manager is a security and visibility service that functions as the center of all your AWS assets and workflows, giving you a centralized user interface to freely explore your infrastructure. This lets you check out and patch vulnerabilities, as well as benefit from a single store for your entire environment to manage your applications’ configuration data.

Using this service, you can create groups of resources across different AWS services, and then view aggregated data by resource group. You can then respond to insights and automate operational actions across these resource groups.

AWS Systems Manager has additional capabilities in the form of smaller services, like Incident Manager and Change Manager. The former allows you to create response plans that take effect whenever there are availability, performance, or security issues with your applications or workflows. This way, you can get notifications when any change in your environment creates a security vulnerability that needs to be addressed ASAP. Incident Manager can execute those plans if triggered, notifying first responders via SMS or email, rolling back the breaking changes, and providing useful post-incident metrics.

Change Manager, on the other hand, allows you to simplify the way you make changes to your account’s infrastructure and configuration. It lets you create “change templates” that help avoid unintended results while making changes to certain things (like IAM policies). This is very useful when trying to make sure that no breaking changes make it through the predefined workflow, which, in turn, helps stop security issues before they even happen.

All of this ties really well into a policy-heavy security solution, which is how AWS suggests we do things anyway.

Summary

While not all of these steps may apply to your infrastructure, it’s good to have other ways to protect it without relying on the same five pieces of advice we get from AWS most of the time. Their shared responsibility model, while useful, doesn’t really provide tools to protect our environment—it simply tells us what we should be concerned about protecting.

We already know that we should be encrypting our data and security access keys, and planning our security strategy should be a no-brainer when it comes to working with and maintaining a big cloud infrastructure.

Hopefully, these suggestions will help improve your security, but if you’re looking for a more managed solution, you can always try CrowdStrike’s Falcon for AWS. This service provides end-to-end protection—from the host to the cloud and everywhere in between—while also granting complete visibility into all of your resources, accounts, and instances.