AWS Cloud Security Best Practices

Amazon Web Services, or AWS, has long been the most popular public cloud platform. But it has also expanded significantly over the past decade by rolling out a variety of new services (like managed container and Kubernetes services), which have added complexity to AWS cloud security.

At the same time, the widespread adoption of hybrid cloud and multicloud architectures means that businesses that use AWS may face new cloud security challenges that did not exist when they ran everything in a single-cloud AWS environment.

As a result of this dynamic , AWS security practices that worked in the past are no longer necessarily sufficient on their own to address all AWS security requirements. With that challenge in mind, this article walks through the fundamentals of modern AWS security and suggests AWS cloud security best practices to follow for securing workloads that run on AWS, including container- and Kubernetes-based applications.

AWS Shared Responsibility Model

The first step in planning for AWS security is understanding the AWS shared responsibility model. Like other major public clouds, AWS uses a shared security concept to distinguish between security risks that AWS manages and those that it expects customers to address.

AWS’s official definition of its shared responsibility model is less detailed than that of other major public clouds. It boils down to the concept that “AWS is responsible for protecting the infrastructure that runs all of the services offered in the AWS Cloud,” while customers secure everything else.

In practice, AWS shared responsibility is virtually identical to the models embraced by other public clouds, despite the fact that AWS doesn’t spell out the nuances to the same extent. Basically, customers simply need to remember that AWS secures all cloud infrastructure that customers can’t directly access or configure, and customers secure everything else. This is true even in the case of AWS managed services, like Elastic Kubernetes Service, or EKS, where AWS secures the cluster infrastructure, but customers have to secure the Kubernetes environment and any applications they deploy on it.

AWS Cloud Security Best Practices

After you understand the AWS shared responsibility model, the next step is to apply AWS security best practices that secure those aspects of your AWS environment for which you are responsible.

How to Secure AWS Cloud Environments

In most respects, the fundamental best practices for AWS cloud security are not different from the security practices that you’d apply in any type of cloud environment. They include:

• Use cloud IAM: Using the AWS Identity and Access Management (IAM) framework, customers should configure granular access controls that restrict access privileges for each user and service running in an AWS environment to the least necessary. For example, to limit access to an AWS S3 storage bucket to a specific range of IP addresses, you could define an IAM policy such as:

{
  "Version": "2012-10-17",
  "Id": "S3PolicyId1",
  "Statement": [
    {
      "Sid": "IPAllow",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
	       "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
         "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Condition": {
	 "NotIpAddress": {"aws:SourceIp": "54.240.143.0/24"}
      }
    }
  ]
}Code language: JSON / JSON with Comments (json)

Customers can also use CSPM security tools to detect misconfigurations in IAM policies that create weak cloud security posture.

• Use cloud VPCs: Customers can configure isolated environments for their workloads using Amazon Virtual Private Cloud, or VPC. By creating a VPC, customers isolate workloads from one another (and, depending on how the VPC is configured, from the public Internet) at the network level. Although you don’t have to use a VPC if you use AWS, VPCs are a useful tool for reducing security exposures.
• Manage cloud accounts wisely: There is no limit to the number of cloud resources you can deploy using a single AWS account. However, it’s a best practice to create separate accounts for separate users or business units in order to isolate unrelated workloads at the account level. The downside of using multiple accounts is that they are harder to manage, but services like AWS Landing Zone can help with this challenge.
• Encrypt cloud data: In addition to securing cloud data stored in services like AWS S3 using access controls, customers should enable default server-side encryption. Additionally, they should enforce client-side encryption to protect cloud data in transit.
• Know where sensitive data lives: In large-scale cloud environments, it’s easy to lose track of where sensitive data (such as data that contains personally identifiable information) is stored. Tagging AWS resources can help address this risk by helping teams label sensitive workloads. Amazon also provides an automated service, called Macie, that can identify sensitive information stored on the AWS cloud.
• Inspect cloud activity logs: Apply detection mechanisms to AWS CloudTrail logs, to detect risky behavior across various AWS services such as S3, IAM and RDS.

AWS Cloud Security Tips

Beyond the standard cloud security best practices described above, there are a few special security pointers that teams may want to consider when they use AWS:

• Securing legacy cloud workloads: Because AWS is the oldest major public cloud, some businesses have been using it for well over a decade. They may be running some “legacy” cloud workloads (such as containers deployed on ECS, the in-house container orchestration service that AWS launched before adding Kubernetes-based managed container options) that are not necessarily up to speed with modern AWS security practices. If your team has been running on AWS for a number of years, it’s worth assessing the various types of AWS services you use and evaluating whether the configurations you applied when originally setting up those resources still conform to today’s cloud security best practices.
• Using AWS security tools: AWS offers a wider selection of native security tools than most other major public clouds. In addition to standard security monitoring tools like GuardDuty, AWS provides its own CSPM solution as well as Trusted Advisor, a tool that recommends best practices when configuring workloads. Thus, AWS has a particularly large and complex set of native security tools, which teams should consider using as part of their AWS security strategy. At the same time, however, it’s important to understand the limitations of these tools, especially the fact that they mostly support only AWS environments (which means that they don’t work well in multicloud and hybrid cloud architectures). They are also mostly generic security solutions that are not generally designed to address the nuanced security requirements of very specific types of environments, like Kubernetes.
• AWS hybrid cloud security: AWS provides a hybrid cloud framework, called Outposts, that allows customers to run AWS services on servers that exist on-premises or in a private colocation facility. The servers themselves are provided by AWS; however, despite this fact, customers assume responsibility for most of the infrastructure security requirements that would otherwise fall to AWS in the context of AWS-owned infrastructure. The point here is that if you use Outposts to build a hybrid cloud, it’s important to educate yourself about the unique security architecture that AWS uses for Outposts.

AWS Container Security Best Practices

Like other major public clouds, AWS offers several ways to run containerized applications. The primary AWS container services include:

• Elastic Container Service (ECS), a managed container service that is based on an orchestrator that Amazon developed itself.
• Elastic Kubernetes Service (EKS), a managed container service based on Kubernetes.
• Fargate, a service that simplifies the deployment of containers via ECS or EKS, with the tradeoff that users have less control over infrastructure and configuration.
• Lambda, a serverless function service that can run applications packaged as container images.

You can also deploy containers directly on AWS EC2 virtual machines if you are willing to set up and manage both the infrastructure and the container runtime and orchestration layers yourself.

How to Secure AWS Containers

Depending on which service or services you use to deploy containers on AWS, your approach to securing your containers will vary. No matter which service you use, however, a few basic AWS container security best practices apply:

• Scan container images for vulnerabilities. AWS doesn’t scan images for you.
• To the extent possible, scan all configurations associated with your environment – such as Kubernetes deployment and RBAC files and AWS IAM policies – to detect cloud security posture problems.
• Use the tooling available from container orchestration frameworks to help secure your environment and detect breaches. In Kubernetes-based AWS environments, this means using tools like Kubernetes audit logs, RBAC, and security contexts.

It’s also important to understand how the AWS shared responsibility model applies to whichever container services you use. There is a fair amount of nuance and complexity surrounding this topic, especially given that AWS provides multiple ways to use services like EKS (you can manage it through Fargate or directly via EKS), and each approach has different implications for which security responsibilities fall to the customer. The AWS documentation does a good job of explaining these details, so make sure to read up on the AWS security policies specific to the container service you choose.

Managing The Evolving Landscape of AWS Security

As long as AWS remains the dominant cloud computing platform by market share, securing AWS workloads will remain a top-of-mind concern for organizations around the world. And as AWS continues to roll out new types of services and make it easier to integrate them with hybrid and multicloud architectures, AWS security will grow only more complex.

The good news is that, as long as you do your research to understand which security challenges apply to the specific AWS cloud services and configurations you adopt, managing AWS security isn’t hard. The information and tools you need are out there; it’s just a matter of finding the right resources.