Security Essentials

Security and compliance is a shared responsibility between AWS and the customer. By following this shared model, customers can reduce the operational burden as AWS assumes responsibility for operating, managing, and controlling the components "of the cloud." This leaves customers to focus on building their applications and implementing their services, while assuming responsibility of securing those services "in the cloud." Read more about the Shared Responsibility Model.

When you create an AWS account, you start with what is known as the root user. This is the first AWS user that exists inside your AWS account. AWS recommends that you do not use this account for day-to-day operations as it has full access and control of the account, and should follow the recommended best practices to secure the root user. This involves locking away your root user access keys, using a strong password, enabling AWS multi-factor authentication, and creating an IAM user to access your account. This account can be assigned admin privileges and should be used for all administrative tasks going forward.

Next, you should assign alternate security contacts to your account. The alternate security contact will receive security-related notifications, including notifications from the AWS Trust & Safety team. You can learn more about the importance of setting this contact information early in your account setup in the blog post Update the alternate security contact across your AWS accounts for timely security notifications.

Once you have confirmed your security contacts, you should consider the AWS Regions where your workloads should run, and the Regions where they should not. You can then lock down the unused Regions to ensure no workloads can be run from those Regions. While this helps with cost optimization, it also lends itself to security. How so? By locking down the Regions in which you do not expect to run workloads, you can focus your monitoring efforts on the Regions you actively use.

At this point, you have secured the root user, created one or more IAM users, assigned security contacts, and locked down the Regions in which workloads can run. Next, let's consider how users will interact with AWS resources. There are two primary methods of interaction: the AWS CLI and the AWS Management Console. It's recommended to set up single sign-on for the AWS CLI and the console. See the article Configuring the AWS CLI to use AWS IAM Identity Center (successor to AWS Single Sign-On) for details on how to centrally manage access with AWS IAM Identity Center.

The next step in securing your account is to set up AWS IAM user groups to control access. Rather than control individual users' access by setting policies directly on the user, it is best to create a group, assign the required permissions to it, and then assign users to the group. The users will inherit the permissions of that group. This offers a more scalable way of providing access control to many users. IAM and IAM groups are important to understand because they span across multiple services. IAM is one service that interacts to some degree with all AWS services, so be sure to spend time getting familiar with IAM.

Following these practices from the onset will help to provide secure access to your AWS resources. Next we will discuss how to secure the infrastructure you build on AWS.

The infrastructure you build is often overlooked as it's part of the underlying architecture and not something that's customer facing. However, if the infrastructure fails, the services you provide your customers fail. For this reason, it's imperative that the infrastructure is secured from day one.

As you build out your cloud infrastructure, you will begin by creating an Amazon Virtual Private Cloud (Amazon VPC). This is a virtual network that you define (a default one is created in each Region when you create your account) that allows you to launch resources. A VPC resembles a traditional network as it has a CIDR IP address range assigned to it, and is subdivided by creating subnets. Your subnets can be used to provide isolation for different sets of resources. Subnets can either be public or private. Public subnets have a route to an Internet Gateway, have access to the internet through this gateway, and can be reached from the internet if the relevant access controls allow it. Private subnets have a routing table as well, but do not have a route to an Internet Gateway, so by default cannot reach the internet, and cannot be reached from the internet. To enable resources in a private subnet to access the internet, a NAT gateway is needed. At the subnet level, a network access control list (ACL) allows or denies specific inbound or outbound traffic. You can use the default network ACL for your VPC, or you can create a custom network ACL for your VPC. Network ACLs are numbered lists, processed in top-down order, and are stateless. This means that you will need an inbound and outbound network ACL rule to allow bidirectional traffic.

As you deploy EC2 resources into your VPC, you will associate a security group with them. A security group controls the inbound and outbound traffic that can reach the EC2 resources. Security groups are similar to a firewall, but instead of using just a list or range of IP addresses, they can point to something called a resource reference. A resource reference is a named group that maintains an updated list of IP addresses assigned to each resource in the group. As an example, if you create an autoscaling group to spin up Amazon EC2 instances, each instance is assigned a new IP when it starts up. By adding a security group to these instances, you can grant access to your database server's security group via the EC2 instances' security group ID, and any new EC2 instance launched will have access to the database without needing to add its IP address to the allowed list.

Security group rules are similar to network ACLs because when you create them, you match on port, protocol, and addresses, but they are stateful—you can think of them as being similar to a stateful firewall. When you create an entry to allow a specific type of traffic, you do not need to create a rule to match the return traffic; being stateful, the return traffic will be allowed. To better understand how security groups and ACLs interact, this comparison is useful.

To add an additional layer of infrastructure security, you can deploy the AWS Network Firewall. The Network Firewall is a managed service that deploys protection for your Amazon VPC. It provides more fine-grained protection than security groups, because it can incorporate context from traffic flows, like tracking connections and protocol identification, to enforce policies such as preventing your VPCs from accessing domains using an unauthorized protocol. This is done through the configuration of custom Suricata Rules. For example, you can configure the Network Firewall to protect against malware attacks. Taking this a step further, you can deploy another managed service, AWS Shield Advanced, to protect against DDoS threats.

Customers store a great deal of data in the AWS Cloud. This data contains information that is critical to the operation of an organization. It includes customer data, intellectual property, orders linked directly to revenue, and more. In this section, we share essentials on how to configure data that is stored on AWS as well as data that is transferred over the network to and from AWS.

On AWS, data is stored in Amazon S3, which has several controls to protect data. The article Top 10 security best practices for securing data in Amazon S3 covers the most fundamental techniques. These include blocking public S3 buckets at the organization level, using bucket policies to verify all access granted is restricted and specific, and encrypting and protecting data.

For encryption, AWS Key Management Service (AWS KMS) allows you to create and control keys used to encrypt or digitally sign your data. If you want to encrypt your data on AWS, you have a few options. The first is to use server-side encryption with Amazon S3-managed encryption keys (SSE-S3). Using this method, the encryption happens after the data is sent to AWS using keys that are managed by AWS.

The second option is to encrypt the data once it's in AWS, but rather than using keys that are created and managed by AWS, you can perform server-side encryption with customer master keys (CMKs) that are stored in AWS KMS (SSE-KMS.

The third option for storing encrypted data on AWS is to use client-side encryption. With this approach, the data is encrypted prior to being transferred to AWS.

An example of how both client-side encryption and server-side encryption benefits customers can be seen in the following image.

VPNs can encompass several technologies. The idea behind a VPN is that your data in transit maintains its integrity and can be securely exchanged between two parties. AWS offers multiple technologies that help to keep your data-in-transit secure. One of those is AWS PrivateLink, which provides encrypted, private connectivity between VPCs, AWS services, and your on-premises networks. This is done without exposing your traffic to the public internet. This too could be considered a virtual private network.

However, in most cases, a discussion of VPN revolves around the use of data encryption. Depending on the circumstances, you may need to provide encryption between a client and your AWS cloud resources. This situation would require AWS Client VPN. On the other hand, you might be passing data between your data center or branch office and your AWS resources. You can accomplish this using IPsec tunnels between your on-premises resources and your our Amazon VPCs or AWS Transit Gateway. This secure connectivity is known as Site-to-Site VPN.

Lastly, managing your cloud resources using the AWS Management Console also offers encrypted data-in-transit. While you would not normally refer to connectivity with the console as a VPN, your session uses TLS (Transport Layer Security) encryption. Thus, your configurations are kept confidential as you build your secure architecture. TLS is also used with the AWS API.

AWS offers several managed services to assist in monitoring of your environment, along with self-service options. For example, you can use VPC Flow Logs to log and view network traffic flows, or you can use Amazon CloudWatch to analyze AWS WAF Logs or even to create alarms for EC2 instances. You can learn more about Amazon CloudWatch in this workshop.

Additionally, AWS CloudTrail monitors and records account activity across your AWS infrastructure, giving you control over storage, analysis, and remediation actions. This is essential for creating an administrative audit trail, identifying security incidents, and for troubleshooting operational issues.

Finally, Amazon GuardDuty can be used for threat detection, and even to take it a step further by causing the published findings to initiate auto-remediation actions within your AWS environment.

By addressing each of these operational areas, you will be well on your way to establishing essential security features for your cloud environment.