What Is AWS Cloud Security?

AWS cloud security is a set of protocols and measures designed to keep the Amazon Web Services (AWS) public cloud environment secure from cloud threats. AWS provides a shared responsibility model, a framework that outlines respective responsibilities for cloud service providers and customers. It has incremented its capabilities overtime, but with the increased adoption of multi-cloud or hybrid environments, a new set of cloud security challenges arises.

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

Beyond 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.

Some best practices they share include:

• Encrypt Cloud Data: AWS has its own cloud data encryption options. AES-256 bit encryption is an AWS service-managed key provided for free, with the downside of providing server-side encryption only. AWS Key Management Service is the paid option that allows you to build and encrypt your own infrastructure.
• Create Virtual Private Clouds: When customers create VPCs, they can isolate workloads from one another at the network level. VPCs are helpful security tools that help reduce security exposures.
• Data Backup: Organizations can potentially  have their operations disrupted in the event of a breach. Operational disruptions are drastically mitigated when all the organization’s data has been backed up, and in the event of a disruption, it can be up and running within a short period of time.
• Employ Multi-Factor Authentication: MFA enhances security in a system because it ensures users are who they say they are and limits the number of users who can access and/or modify stored data.
• Have Strong Passwords: Ensure you are following strong password storage best practices to prevent hackers from easily penetrating your network or system.
• Centralize CloudTrail Logs: Centralized logging allows your teams to easily detect suspicious behaviors across AWS services like S3 and RDS.
• Emphasize Identity Access Management: IAM allows your IT department to streamline and control which users have access to how much data in the network.

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 a full robust cloud security strategy. If you want that, you need to go further.

The following are 4 recommendations that go beyond Amazon’s best practices and recommendations.

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

2. 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.

3. Truly Understand the Importance of IAM

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.

4. Leverage a Visibility Service

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.

How CrowdStrike Can Help

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.

If you’re looking for a managed solution, explore CrowdStrike 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.