Lab 3: Security

© 2023 Amazon Web Services, Inc. or its affiliates. All rights reserved. This work may not be reproduced or redistributed, in whole or in part, without prior written permission from Amazon Web Services, Inc. Commercial copying, lending, or selling is prohibited. All trademarks are the property of their owners.

Note: Do not include any personal, identifying, or confidential information into the lab environment. Information entered may be visible to others.

Corrections, feedback, or other questions? Contact us at AWS Training and Certification.

Objectives

In this hands-on activity, you learn about the Enable traceability design principle. You also learn how to use cloud-native controls like AWS CloudTrail, security groups, and AWS Systems Manager to secure the cloud architecture.

Information about the security pillar design principles can be found in the AWS documentation.

After completing this lab, you will be able to:

Apply granular logging.
Improve granular control of communication.
Improve granular network-based controls.
Evaluate detailed logging capabilities.

PREREQUISITES

This lab requires:

Use of a personal computer or laptop with Wi-Fi. The lab is not accessible using an iPad or tablet device, but you can use these devices to access the student guide.
Access to the administrator account on your local the computer.
Access to an internet browser, such as Chrome or Firefox.

ICON KEY

Various icons are used throughout this lab to call attention to different types of instructions and notes. The following list explains the purpose for each icon:

Expected output: A sample output that you can use to verify the output of a command or edited file.
Note: A hint, tip, or important guidance.
Additional information: Where to find more information.
CAUTION: Information of special interest or importance (not so important to cause problems with the equipment or data if you miss it, but it could result in the need to repeat certain steps).

DURATION

This lab requires 60 minutes to complete.

SCENARIO

The security pillar encompasses the ability to protect data, systems, and assets to take advantage of cloud technologies to improve your security. Security is our top priority. According to the AWS Well-Architected Framework Review, you should implement some cloud-native controls to prevent and detect security issues.

Modify the architecture provided in the lab to enable granular logging of API calls made to the environment and secure network traffic by narrowing the scope of traffic allowed by security groups and network access control lists (network ACLs).

ARCHITECTURE

The architecture of the infrastructure you deploy by the end of the lab is diagrammed below:

drawing

The architecture is an Amazon VPC containing 2 Availability Zones. There are 6 total subnets in the environment, with each Availability Zone having 3 of the subnets. The subnets are labelled and divided per Availability Zone as such: 1 public subnet, 1 private subnet, and 1 db private subnet. Each of the private subnets is part of an Amazon EC2 Auto Scaling group and contains 1 web server each. Each of the db private subnets contain 1 Amazon RDS instance each. Internet traffic flows into an internet gateway, to an Application Load Balancer residing in the public subnets, then to the Amazon EC2 Auto Scaling group in the private subnets, and finally to the Amazon RDS primary instance in the db private subnet. Supporting management, automation & monitoring services for the environment are: Amazon CloudWatch, AWS CloudTrail, AWS CloudFormation, AWS Config, and AWS Systems Manager.

Start lab

To launch the lab, at the top of the page, choose Start lab.

You must wait for the provisioned AWS services to be ready before you can continue.

To open the lab, choose Open Console.

You are automatically signed in to the AWS Management Console in a new web browser tab.

Do not change the Region unless instructed.

Error: You must first sign out

If you see the message, You must first log out before logging into a different AWS account:

Choose the click here link.
Close your Amazon Web Services Sign In web browser tab and return to your initial lab page.
Choose Open Console again.

Error: Choosing Start Lab has no effect

In some cases, certain pop-up or script blocker web browser extensions might prevent the Start Lab button from working as intended. If you experience an issue starting the lab:

Add the lab domain name to your pop-up or script blocker’s allow list or turn it off.
Refresh the page and try again.

Task 1: Enable Granular Logging

Disjointed security tooling was identified at the on-premises environment. There is a lack of insight into what is going on in the environment. There is difficulty managing change control and permissions, which led to risks becoming problems. Set up monitoring with AWS Config and AWS CloudTrail. This helps you have more complete insight into who is doing what in the environment, what changes are being made, and notification when problems arise.

AWS CloudTrail is a service that provides governance, compliance, operational auditing, and risk auditing of your Amazon Web Services (AWS) account. With AWS CloudTrail, you can log, continuously monitor, and retain account activity related to actions across your AWS infrastructure.

For the given architecture, you want to apply detailed, holistic logging and network-based security monitoring. You want to save these logs to a new Amazon Simple Storage Service (Amazon S3) bucket for future evaluation.

TASK 1.1: SET UP AWS CLOUDTRAIL

In this task, you use AWS CloudTrail to create a trail to log all read/write events. This will record every API call made to the lab’s AWS environment.

At the top of the AWS Management Console, in the search bar, search for and choose .

Note: You might receive warning message(s) on your console with text like one of the following:

“The option to create an organization trail is not available for this AWS account. Learn more com.amazonaws.services.organizations.model.AccessDeniedException: You do not have permissions to access this resource. (Service: AWSOrganizations; Status Code: 400; Error Code: AccessDeniedException; Request ID: 0080f181-3022-4e69-af49-9d76a5dabd85; Proxy: null)”.,
“Failed to get CloudTrail events”
“Failed to get Insight events”.

You can safely ignore these warnings and continue with the next step.

In the navigation menu at the left of the page, choose Dashboard.

The browser displays the AWS CloudTrail Dashboard page.

Choose Create trail.

The browser displays the Choose trail attributes page.

Note: If you receive an a warning message on your console with text like:

You do not have permissions to perform this action. An administrator for your account might need to add permissions to the policy that grants you access to CloudTrail.

You can safely ignore these warnings and continue with the next step.

On the Choose trail attributes page, in the General details section:

For Trail name, input

.
For Storage location, select Create new S3 bucket.
For Trail log bucket and folder, input

.

Note: For this lab, you save AWS CloudTrail logs to a new Amazon S3 bucket for future evaluation, referred to as the trail log bucket in the console. Give this bucket a unique name, such as,

. Amazon S3 buckets must have unique names, and the names must be Domain Name System (DNS) compliant. For this lab, to make a unique bucket name, append your name followed by a few random numbers at the end of the bucket name. Bucket names can only contain lower case letters, numbers, “-“, and “.”). A valid bucket name would be like this: cloudsecurity-demo-bucket-johndoe123.
For Log file SSE-KMS encryption, clear the checkbox for Enabled.
Keep all other parameters at their default settings.

Choose Next.

The browser displays the Choose log events page.

On the Choose log events page, in the Events section:

For Event type, select the checkbox next to Management events.

Keep all other parameters at their default settings.

Choose Next.

The browser displays the Review and create page.

Review your selections for accuracy.
Choose Create trail.

Note: You might receive an error like this: You don’t have adequate permissions in Amazon S3 to perform this operation. Learn more. If so, check that the trail log bucket that you are creating follows the naming convention like this: cloudsecurity-demo-bucket-YOURNAME

The browser displays the Trails page.

A list of available trails, including the new one, is displayed. You review the API calls recorded in the AWS CloudTrail log later in the lab.

You have created a new trail for your AWS environment.

TASK 1.2: SET UP AWS CONFIG

In this task, you set up the service AWS Config to be used as a change management tool for resources in the environment.

At the top of the AWS Management Console, in the search bar, search for and choose

.
Choose Get started.

Note: If the option is not available, you can access the configuration by choosing Settings in the navigation menu at the left of the page.

The browser displays the Settings page.

On the Settings page, in the General settings section:

For Resource types to record, confirm Record all resources supported in this region is selected.
Select the checkbox next to Include global resources (e.g., AWS IAM resources).

You store AWS Config data for this lab in a central Amazon S3 bucket.

Next, you create a second new Amazon S3 bucket. Use the default name provided to ensure that it is unique.

Note: It is possible to use the previously created Amazon S3 bucket for this. But permissions on the bucket would have to be updated to allow communication with the AWS Config service, which is beyond the scope of this lab.

On the Settings page, in the Delivery method section:

For Amazon S3 bucket, confirm that Create a bucket is selected.

Keep all other parameters at their default settings.
Choose Next.

The browser displays the Rules page.

No configuration is needed on this page.

Choose Next.

The browser displays the Review page.

Review the configuration for accuracy.
Choose Confirm.

The AWS Config dashboard is displayed.

Note: If prompted, you can close the Welcome to AWS Config pop-up window.

Congratulations! In this task, you have set up both AWS CloudTrail and AWS Config services to provide more centralized logging and monitoring of actions occurring in your AWS environment.

Task 2: Improve Granular Control of Communication

In this task, you review and improve upon granular control of network communication between workloads in the cloud.

At the top of the AWS Management Console, in the search bar, search for and choose

.
In the navigation menu at the left of the page, under Network & Security, choose Security Groups.

The browser displays the Security Groups page.

Security groups currently in the Amazon Virtual Private Cloud (VPC) are listed.

By using the Security Groups feature of the Amazon Elastic Compute Cloud (Amazon EC2) services, you can define stateful communication rules between services.

Choose the security group with the Security group name of .

You want to define the scope of security group. Allow only for the connections that the database instances are intended to communicate with, and no more.

In this lab, you configure the ingress rules of the security group named wa-database-sg. So only instances using the same security group (self) and the security group named wa-asg-sg (the application instances) are allowed to open connections to instances that are using the security group named wa-database-sg (the database instances).

In the bottom half of the page, select the Inbound rules tab.
Select Edit inbound rules.

The browser displays the Edit inbound rules page.

Choose Delete to remove any existing rule.
Choose Add rule.
Configure a rule as follows:

For Type, select MYSQL/Aurora.
For Source, select Custom.
Select into the search box next to the Source drop-down. Using the search field, choose the Security Group named

.

Choose Add rule.
Configure a rule as follows:

For Type, select MYSQL/Aurora.
For Source, select Custom.
Select into the search box next to the Source drop-down. Using the search field, choose the Security Group named

.

Choose Save rules.

A banner message like the following is displayed at the top of the page: Inbound security group rules successfully modified on security group (sg-0182867f2c1d7c460 | wa-database-sg) .

In the Inbound rules tab, in the Source column, confirm that the only allowed sources are the security groups named wa-ec2-database-sg and wa-asg-sg. This column can be expanded if necessary.
Select the Outbound rules tab.

The existing rule is too broad and would allow outbound communication originating from the database on any port.

Choose Edit outbound rules.

The browser displays the Edit outbound rules page.

Choose Delete to remove the existing rule.
Choose Add rule.
Configure the rule as follows:

For Type, select All traffic.
For Destination, select Custom.
Select into the search box next to the Destination drop-down. Using the search field, choose the Security Group named

.

Choose Save rules.

A banner message like the following is displayed at the top of the page: Outbound security group rules successfully modified on security group (sg-0182867f2c1d7c460 | wa-database-sg) .

Confirm that the allowed Destination of the outbound rule now shows the wa-asg-sg security group that you selected.

The configuration you made means that traffic originating from instances using the wa-database-sg (the database instances) are only allowed to communicate to instances using the security group named wa-asg-sg (the application instances).

Congratulations! In this task, you narrowed the scope of allowed inbound and outbound connections in the security group named wa-database-sg, so that only the intended connections are allowed.

Task 3: Improve Granular Network-Based Controls

In this task, you improve network-based controls by using network ACLs to prevent side-to-side movement in a granular way. You want to explicitly block the Application Load Balancer in your environment from talking directly to the database servers on specific ports.

Security groups are used to define the allowed inbound and outbound traffic for the associated resources in an explicit manner. Security groups work with the connections in stateful manner.

If there is need to define stateless access to your environment, use Network ACLs.

At the top of the AWS Management Console, in the search bar, search for and choose

.
In the navigation menu at the left of the page, under Security, choose Network ACLs.

The browser displays the Network ACLs page.

Choose Create network ACL.

The browser displays the Create network ACL page.

On the Create network ACL page, in the Network ACL settings section:

For Name, input

.
For VPC, select

.
Keep all other parameters at their default settings.

Choose Create network ACL.

The browser displays the Network ACLs page.

A banner message like the following is displayed at the top of the page: You successfully created acl-05bef764a1dd175c7 / LoadBalancerIsolation. .

Select the checkbox next to the load balancer named from the list.
Select the Details tab.
Copy the Network ACL ID value. Save the value in a text editor for future use.
Select Outbound rules tab.
Choose Edit outbound rules.

The browser displays the Edit outbound rules page.

Add three outbound rules.

For each rule, choose Add new rule.

Use the following information to configure per rule:

For Rule number, input

For Type, select All traffic
For Destination, input
For Allow/Deny, select Deny Behavior

For Rule number, input

For Type, select All traffic
For Destination, input
For Allow/Deny, select Deny Behavior

For Rule number, input

For Type, select All traffic
For Destination, input
For Allow/Deny, select Allow Behavior

When you have added all three rules, choose Save changes.

When applied to a subnet, these network ACL rules block network communication that originates within the subnet that is targeting the subnets that host the databases. The network ACLs still allow for outbound access to other IP addresses. Note that network ACLs are evaluated in the order of their rule number, from lowest to highest.

The browser displays the Network ACLs page.

A banner message like the following is displayed at the top of the page: You have successfully updated outbound rules for acl-05bef764a1dd175c7 / LoadBalancerIsolation.

Caution: When you create a subnet, each subnet has a default network ACLs that has rules to Allow All communication in both directions. However, when you create a new network ACL rule, a Deny All rule is applied in both directions.

After Saving the new outbound network ACL rules, you need to allow access to that subnet from the internet.

Recreating the All Traffic Allow rule for Inbound Rules is necessary.

Select the Inbound rules tab.
Choose Edit inbound rules.

The browser displays the Edit inbound rules page

Choose Add new rule.
Configure the rule as follows:

For Rule number, input
For Type, select All traffic
For Source, input
For Allow/Deny, select Allow Behavior

Choose Save changes.

The browser displays the Network ACLs page.

A banner message like the following is displayed at the top of the page: You have successfully updated inbound rules for acl-05bef764a1dd175c7 / LoadBalancerIsolation.

Select the Subnet associations tab.
Choose Edit subnet associations.
Select the checkbox next to the

subnet.
Select the checkbox next to the

subnet.
Choose Save changes.

The browser displays the Network ACLs page.

A banner message like the following is displayed at the top of the page: You have successfully updated subnet associations for acl-0a44182f71dd800e6 / LoadBalancerIsolation.

Now confirm that the application is working after these changes.

Copy the ApplicationUrl value to the left of these instructions, and paste the URL in a new browser tab to access the application.

The browser displays the application web page.

Using network ACLs, you have effectively ensured that the Application Load Balancer, which is exposed to the internet, cannot communicate with or compromise the database servers directly.

Congratulations! In this task, you created and configured network ACLs that deny communication directly between the Application Load Balancer and the database instances.

Task 4: Evaluate Detailed Logging Capabilities

You made several configuration changes to the network. These kinds of changes might be difficult to track on-premises. However, using AWS CloudTrail, which was set up in prior tasks, all the different actions that took place throughout the lab have been recorded.

TASK 4.1: EXAMINE THE AWS CLOUDTRAIL LOGS

In this task, you examine some of the AWS CloudTrail logs.

At the top of the AWS Management Console, in the search bar, search for and choose .

The browser displays the AWS CloudTrail Dashboard page.

The dashboard shows recent events, but you want to review the specific API calls that you made throughout this lab.

In the navigation menu at the left of the page, choose Trails.

The browser displays the Trails page.

Select the link for the trail named . This is the name of the trail that you created earlier.

The browser displays the All-API-Commands-across-all-Regions details page.

In the General details section, locate the Trail log location.

This link indicates the Amazon S3 bucket where the logs for this trail are stored.

Choose the link for the Amazon S3 bucket, which has a name beginning like, .

The Amazon S3 console opens and shows the trail log bucket, at the top level of the directory for the log files.

Select the link.

There is folder for each Region where a log was recorded. The hierarchy of the Amazon S3 bucket navigation at this level is bucket-name/AWSLogs/account-id/CloudTrail/region-name.

Choose the folder for the AWS Region where you want to review log files. For example, choose us-west-2/.
Navigate the bucket folder structure to the year, the month, and the day where you want to review AWS CloudTrail logs of activity in that Region.

The hierarchy of the Amazon S3 bucket navigation at the individual log level is bucket-name/AWSLogs/account-id/CloudTrail/region-name/year/month/day.

For each day, there are several log files. The names of the files begin with your AWS account ID, and end with the extension .gz. For example, if your account ID is 123456789012, the files are named like this: 123456789012_CloudTrail_us-east-2_20190610T1255abcdeEXAMPLE.json.gz.

To review these files, you can download them, uncompress them, and then review them using a plain-text editor or a JSON file viewer. Some browsers also support opening .gz and JSON files directly.

To open and view a file, do the following:

Select the checkbox next to the most recent file in the list.
Choose the Download option, and save the file locally.
The downloaded log file can be uncompressed and viewed with a text editor.

AWS CloudTrail logs events for every AWS service that experienced activity in that AWS Region at the time that event occurred. In other words, events for different AWS services are mixed, based solely on time.

To learn more about what a specific service logs with CloudTrail, including examples of log file entries, review the documentation for the list of supported services for CloudTrail, and read the CloudTrail integration topic for that service. You can also learn more about the content and structure of CloudTrail log files by reviewing the CloudTrail log event reference.

Console sign-in and AWS Identity and Access Management (IAM) events are global service events, but are logged in a specific AWS Region. Those files are not accessible in this lab. The following snippet represents an IAM sign-in event that you would find in those logs.

Example:

{
  "eventVersion": "1.05",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AKIAIOSFODNN7EXAMPLE",
    "arn": "arn:aws:iam::123456789012:user/Mary_Major",
    "accountId": "123456789012",
    "userName": "Mary_Major"
  },
  "eventTime": "2019-06-10T17:14:09Z",
  "eventSource": "signin.amazonaws.com",
  "eventName": "ConsoleLogin",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "203.0.113.67",
  "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0",
  "requestParameters": null,
  "responseElements": {
    "ConsoleLogin": "Success"
  },
  "additionalEventData": {
    "LoginTo": "https://console.aws.amazon.com/console/home?state=hashArgs%23&isauthcode=true",
    "MobileVersion": "No",
    "MFAUsed": "No"
  },
  "eventID": "2681fc29-EXAMPLE",
  "eventType": "AwsConsoleSignIn",
  "recipientAccountId": "123456789012"
}

This log file tells you more than just the identity of the IAM user who logged in (Mary Major), the date and time that they logged in, and that the login was successful. You can also learn the IP address that the user logged in from, the operating system and browser software of the computer, and that multi-factor authentication was not used.

Now that you have a trail, you have access to an ongoing record of events and activities in your AWS account. This ongoing record helps you meet accounting and auditing needs for your AWS account. However, there is a lot more that you can do with AWS CloudTrail.

In this task, you navigated to AWS CloudTrail and retrieved one of the trail logs made from API calls during the lab.

TASK 4.2: EXAMINE LOGS OF THE CHANGES MADE WITH AWS CONFIG

In this task, you verify that AWS Config is recording configuration changes made to the AWS environment.

At the top of the AWS Management Console, in the search bar, search for and choose .
In the navigation menu at the left of the page, choose Resources.

The browser displays the Resource Inventory page.

On the Resource Inventory page, in the Resources section:

For Resource type, select .

A list of currently managed ACLs is displayed.

Choose the link in the Resource identifier column that matches the network ACL ID that you copied earlier in this lab when you created the network Access List.

The browser displays the Details pages for the ACL.

Choose Resource Timeline.

The browser displays the Timeline page.

In the resource timeline, you can find the events that occurred when changes were made to the network ACL in the lab.

Expand newest Configuration change event.

The Relationship Change value shows, in JSON format, which subnets were associated with the network ACL in the configuration event.

Examine details of the event and confirm that the subnets were associated with the ACL.

Congratulations! In this task, you verified that AWS Config is recording configuration changes made to the AWS environment by examining a configuration change to one of the ACLs.

Lab Complete

Congratulations! You completed the lab.

You have successfully set up this AWS environment for strong logging with AWS CloudTrail and AWS Config. You also configured granular communication using security groups and network ACLs.

In this lab, you learned to do the following:

Apply granular logging.
Improve granular control of communication.
Improve granular network-based controls.
Evaluate detailed logging capabilities.

End lab

Follow these steps to close the console and end your lab.

Return to the AWS Management Console.
At the upper-right corner of the page, choose AWSLabsUser, and then choose Sign out.
Choose End lab and then confirm that you want to end your lab.

For more information about AWS Training and Certification, see aws.amazon.com/training.

Your feedback is welcome and appreciated.
If you would like to share any feedback, suggestions, or corrections, please provide the details in our AWS Training and Certification Contact Form.

Lab 3: Security

Objectives

PREREQUISITES

ICON KEY

DURATION

SCENARIO

ARCHITECTURE

Start lab

COMMON SIGN-IN ERRORS

Error: You must first sign out

Error: Choosing Start Lab has no effect

Task 1: Enable Granular Logging

TASK 1.1: SET UP AWS CLOUDTRAIL

TASK 1.2: SET UP AWS CONFIG

Task 2: Improve Granular Control of Communication

Task 3: Improve Granular Network-Based Controls

Task 4: Evaluate Detailed Logging Capabilities

TASK 4.1: EXAMINE THE AWS CLOUDTRAIL LOGS

TASK 4.2: EXAMINE LOGS OF THE CHANGES MADE WITH AWS CONFIG

Lab Complete

End lab