Forem: Wilklins Nyatteng

Deep Dive into AWS AppSync API Authorization Mechanisms

Wilklins Nyatteng — Thu, 23 Oct 2025 23:44:27 +0000

AWS AppSync provides a robust and flexible set of authorization mechanisms to secure GraphQL APIs. These mechanisms cater to a wide range of use cases—from public APIs to enterprise-grade, fine-grained access control. AppSync supports five distinct authorization types, each with its own strengths, limitations, and ideal use cases. Developers can also combine multiple authorization types to implement layered security models.

1. API Key Authorization
API keys are static credentials used to authenticate requests to an AppSync API. They are best suited for development environments, public-facing APIs, or guest access scenarios where minimal security is acceptable.

Key Characteristics:
Validity Period: API keys can be configured for up to 365 days. On the final day of validity, they can be extended for another 365 days. Once expired, they cannot be renewed—a new key must be generated.
Security Considerations: API keys do not provide identity context. Any client with the key can access the API, making them unsuitable for production environments or sensitive data.
Use Case: Ideal for unauthenticated access, such as read-only public data or early-stage development.

2. AWS Lambda Authorization (Custom Authorizers)
Lambda authorizers offer maximum flexibility by allowing developers to implement custom authentication and authorization logic. This method is suitable for complex scenarios where standard identity providers or IAM policies are insufficient.
Invocation Flow:
When a request is made to the AppSync API, the Lambda function is invoked with the following payload:

{
  "authorizationToken": "AuthTokenExample",
  "requestContext": {
    "apiId": "ApiId39393939",
    "accountId": "1234567890",
    "requestId": "f4081827-1111-4444-5555-5cf4695f339f",
    "queryString": "mutation deletePost {...}",
    "operationName": "deletePost",
    "variables": {}
  }
}

Response Format:
The Lambda function must return a structured response:

{
  "isAuthorized": true,
  "deniedFields": ["Mutation.deletePosts"],
  "resolverContext": {
    "role": "editor"
  },
  "ttlOverride": 900
}

Key Features:

isAuthorized (Required): Boolean flag indicating whether the request is allowed.
deniedFields (Optional): Specific GraphQL fields that are denied, even if isAuthorized is true.
resolverContext (Optional): Custom context passed to resolvers, accessible via $ctx.identity.resolverContext.
ttlOverride (Optional): Overrides the default 5-minute cache TTL for the authorization result.

Use Case:
Perfect for multi-tenant applications, custom token validation, or role-based access control beyond what Cognito or IAM can offer.

3. AWS IAM Authorization
IAM-based authorization leverages AWS's native identity and access management system. It is ideal for server-to-server communication, backend services, or authenticated AWS users.
Mechanism:

Requests are signed using AWS Signature Version 4.
IAM policies define access to specific GraphQL operations using the appsync:GraphQL action.

Example IAM Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["appsync:GraphQL"],
      "Resource": [
        "arn:aws:appsync:us-west-2:123456789012:apis/PostsAPI/types/Query/fields/listPosts",
        "arn:aws:appsync:us-west-2:123456789012:apis/PostsAPI/types/Mutation/fields/createPost"
      ]
    }
  ]
}

Use Case:
Best suited for internal applications, microservices, or AWS-authenticated clients using temporary credentials (e.g., STS tokens).

4. OpenID Connect (OIDC) Authorization
OIDC is an identity layer built on top of OAuth 2.0. AppSync supports OIDC for integrating with third-party identity providers such as Auth0, Okta, or any compliant OIDC provider.
Mechanism:

Clients send requests with an OIDC token.
AppSync validates the token against the OIDC Issuer URL.
Upon successful validation, AppSync extracts user claims from the token.

Configuration Requirements:

Issuer URL (OIDC Provider Domain): Must be publicly accessible and support standard OIDC discovery endpoints.
Token Expiry: Tokens must be short-lived and securely issued.

Use Case:
Ideal for enterprise applications with existing identity infrastructure or federated login systems.

5. Amazon Cognito User Pools
Cognito User Pools are AWS’s managed identity service that supports OIDC and integrates natively with AppSync. It provides user sign-up, sign-in, and group-based access control.

Mechanism:

Users authenticate via Cognito and receive a JWT token.
AppSync validates the token and uses Cognito groups to enforce access control.

Advanced Features:

Group-based Authorization: Define access rules based on user group membership.
Token Claims: Use custom claims to pass additional context to resolvers.

Use Case:
Best for mobile and web applications requiring user authentication, multi-factor authentication, and fine-grained access control.

Combining Authorization Types
AppSync allows multiple authorization modes to be configured simultaneously. This enables developers to support diverse access patterns, such as:

Public access via API Key
Authenticated access via Cognito
Backend access via IAM
Custom logic via Lambda

Example Use Case:
A blogging platform might use:

API Key for public read access to posts.
Cognito for authenticated users to create and edit posts.
Lambda for admin-level moderation logic.
IAM for internal analytics services.

Conclusion
AWS AppSync’s flexible authorization model empowers developers to secure GraphQL APIs using a combination of standard protocols, custom logic, and AWS-native identity services. By understanding the strengths and limitations of each authorization type, teams can design APIs that are both secure and scalable.

Evaluating Network Security With Amazon VPC Network Access Analyzer

Wilklins Nyatteng — Sun, 12 Oct 2025 06:47:00 +0000

Description

Amazon VPC Network Access Analyzer is a security analysis service that helps you improve the security and compliance of your AWS resources. This service analyzes all network traffic within your VPCs to provide you with visibility into traffic flows and detect unintended access. It can also help you identify overly permissive security group rules and network access control lists (ACLs).

In this lab, you will enable Network Access Analyzer and create a scope to analyze network traffic in a VPC.

Learning objectives

Upon completion of this beginner-level lab, you will be able to:

Analyze a Network Access Analyzer finding
Create a Network Access Analyzer scope
Logging In to the Amazon Web Services Console This lab experience involves Amazon Web Services (AWS), and you will use the AWS Management Console to complete the instructions in the following lab steps.

The AWS Management Console is a web control panel for managing all your AWS resources, from EC2 instances to SNS topics. The console enables cloud management for all aspects of the AWS account, including managing security credentials and even setting up new IAM Users.

Introduction

Developers can begin working with Network Access Analyzer using the AWS Management Console, AWS CLI, or AWS SDKs. When you access the Network Access Analyzer service for the first time, AWS creates four default scopes on your behalf. These default scopes can be used to analyze all traffic in your VPCs and subnets.

You can also create network access scopes to analyze specific traffic patterns. For example, you can create a scope to analyze traffic to a specific EC2 instance or subnet. You can also create a scope to analyze traffic from a specific source, such as a security group or IP address.

In this lab step, you will explore a default Network Access Analyzer scope and finding.

Instructions

In the AWS Management Console, in the search bar at the top, enter network manager, and under Features, click the Network Manager result:

In the left navigation pane, click Network Access Analyzer below Security and governance:

Click Get started:

I have created the following default scopes:

AWS-IGW-Egress: Identify egress paths from all Network Interfaces to Internet Gateways.
All-IGW-Ingress: Identify ingress paths from Internet Gateways to all Network Interfaces.
AWS-VPC-Ingress: Identify ingress paths into your VPCs from Internet Gateways, Peering Connections, VPC Service Endpoints, VPN and Transit Gateways.
AWS-VPC-Egress: Identify egress paths to Internet Gateways, Peering Connections, VPC Endpoints, VPN, and Transit Gateways from all of your VPCs.

These default scopes created for you do not rely on any preconfigured resources. The AmazonVPCNetworkAccessAnalyzerFullAccessPolicy, opens in a new tab IAM managed policy grants the necessary permissions to create and analyze these scopes.

Select the All-IGW-Ingress scope, then click Analyze:

While you wait for the analysis to complete, click the arrow icon to expand the Network Access Scope definition:

{
          "NetworkInsightsAccessScopeId": "nis-0ca0d5341e6e92e8f",
          "MatchPaths": [
                    {
                              "Source": {
                                        "ResourceStatement": {
                                                  "ResourceTypes": [
                                                            "AWS::EC2::InternetGateway",
                                                            "AWS::EC2::VPCPeeringConnection",
                                                            "AWS::EC2::VPCEndpointService",
                                                            "AWS::EC2::TransitGatewayAttachment",
                                                            "AWS::EC2::VPNGateway"
                                                  ]
                                        }
                              },
                              "Destination": {
                                        "ResourceStatement": {
                                                  "ResourceTypes": [
                                                            "AWS::EC2::NetworkInterface"
                                                  ]
                                        }
                              }
                    }
          ]
}

The scope definition is a JSON object that specifies the source and destination of the traffic to analyze. In this case, the source is an internet gateway, and the destination is a network interface. Findings that match this scope definition will be displayed in the Findings tab.

The following analysis status will appear when the analysis is complete:

In the Findings table, select the lab-igw to lab-bastion-instance finding:

The traffic flow diagram will appear below the table:

The source of the traffic is the lab-igw internet gateway, and the destination is the elastic network interface associated with the lab-bastion-instance EC2 instance. Rule 100 of the access control list allows all inbound traffic. The SSH traffic is allowed by the inbound lab-bastion-instance security group rule on port 22.

The End section of the diagram also provides details on which VPC the traffic is flowing through and the destination subnet.

Creating a Network Access Analyzer Scope ### Introduction

In this lab step, you will create a network access scope and analyze traffic to the lab-db-instance EC2 instance.

Instructions

Click the Network Access Scopes breadcrumb link to return to the scopes page:

Click Create Network Access Scope:

In the Select Network Access Scope template step, select Empty template, then click Next: In the Select Network Access Scope template step, select Empty template, then click Next:

In the Define Network Access Scope step, enter db-instance-ingress for the Name: In the Define Network Access Scope step, enter db-instance-ingress for the Name:

Network access scopes can include a match condition and an exclude condition.

A match condition specifies the network access patterns that do not meet your requirements. If a finding matches a match condition, it will be reported in the analysis.

An exclude condition specifies the traffic that you want to exclude from the analysis. Exclude conditions can be used to define network access that you consider as trusted. If a finding matches an excluded condition, it will not be reported in the analysis.

Up next, you will create a match condition to analyze all traffic to the lab-db-instance EC2 instance.

Click Add match condition below Match conditions:

A Match findings condition will be added to the scope.

1. Configure the following match condition:
Source: You will not configure a source. This scope will analyze all traffic and sources that can access the lab-db-instance EC2 instance.
Destination:
- Expand the Resources section.
- Resource selection: Select Resource IDs from the drop-down menu
- Resource types: Select EC2 Instances from the drop-down menu
- Resource IDs: Select the lab-db-instance EC2 instance from the drop-down menu

This network access scope will capture any network traffic that is allowed to access the lab-db-instance EC2 instance. In this example, you want to ensure that the only SSH access allowed to the lab-db-instance EC2 instance is from the bastion-security-group.

Click Next.
Click Create Network Access Scope:

You will be redirected to the Network Access Scopes page.

Select the db-instance-ingress scope, then click Analyze:

In this lab step, you created a network access scope and analyzed the traffic to the lab-db-instance EC2 instance.

Addressing Network Access Analyzer Findings ### Introduction

Network access findings are generated by analyzing network traffic in a scope. A finding is a potential path in your network that matches any of the match conditions and does not match any of the exclude conditions defined in the scope. Findings are presented in the Network Access Analyzer console and can be exported for further analysis.

In this lab step, you will review a finding generated by your custom network access scope and address the unintended access to the lab-db-instance EC2 instance.

Instructions

In the Findings table below, select the finding with the lab-default-instance EC2 instance in the Start column:

The diagram above presents the following details:

Start: The finding begins with the ENI that initiated the network traffic. In this case, the ENI is associated with the lab-default-instance EC2 instance.
End: The ENI of the EC2 instance that received the network traffic
The outbound network traffic is allowed by the default-security-group security group and is destined for the lab-db-instance EC2 instance.
The db-security-group allows inbound SSH traffic on port 22 from the 0.0.0.0/0 CIDR block to the lab-db-instance EC2 instance. This public internet access is unintended and should be addressed:

Click the db-security-group ID to expand the access details:

You will notice the db-security-group is allowing SSH traffic from the 0.0.0.0/0 CIDR block.

To remove this unintended access, you will update the db-security-group security group rule to only allow SSH traffic from the bastion-security-group.

To update the security group rule, click the security group ID below Resource ID:

Click Edit inbound rules:

Click Delete next to the only inbound rule defined:

Click Add rule:

Configure the following rule:
Type: Select SSH from the drop-down menu
Source:
- Select Custom from the drop-down menu
- Select the bastion-security-group from the drop-down menu

Click Save rules:

Return to the Network Access Analyzer tab, then click Analyze to re-run the db-instance-ingress analysis:

After the analysis completes, you will notice the Findings table now displays a single finding. This finding indicates that the lab-bastion-instance is the only EC2 instance that has access to the lab-db-instance EC2 instance:

The inbound rule you added to the db-security-group allows SSH traffic from the lab-bastion-instance to the lab-db-instance.

Summary

In this lab step, you reviewed your network access finding and addressed the SSH access issue by updating the db-security-group security group rule.

By completing this lab, you've completed the following tasks:

Created a Network Access Analyzer scope
Evaluated a Network Access Analyzer finding
Updated a security group rule to restrict SSH access to the lab-db-instance EC2 instance

Review and Secure a Lambda Function with an IAM Least Privilege Based Security Policy: CloudTrail and Athena Approach

Wilklins Nyatteng — Sun, 05 Oct 2025 08:26:43 +0000

In this lab scenario, you take on the role of a cloud security engineer, working for a business that has implemented a particular business process in AWS using AWS Lambda. Version one (MVP) of the implementation has proven very successful with customers (in this lab - you actually deploy and set up the Lambda function). Due to the immediate success and demand of the serverless workflow, the company has now decided to review the IAM security policies involved in its operation and uptime of it. It is expected that current IAM permissions may be too broad and too permissive.

As a cloud security engineer, it is your responsibility to perform the review and update existing IAM security permissions assigned to the Lambda function's execution role. Your task is to review the current IAM policies and refine them such that they adhere to the rule of least privilege. To understand exactly what the Lambda function does, and in particular, the specific set of AWS API operations it integrates with, you will set up CloudTrail together with Athena. Additionally, this new setup will support another business requirement - being able to audit all AWS API calls made by the Lambda function for auditing and compliance reasons.

Learning Objectives

Upon completion of this lab, you will be able to:

Configure CloudTrail and Athena together to help you analyze AWS API operations being made within an AWS Account.

Environment before

Environment after

1. **Logging In to the Amazon Web Services Console**

### **Introduction**

This lab experience involves Amazon Web Services (AWS), and you will use the AWS Management Console to complete the instructions in the following lab steps.

Amazon Web Services is available in different regions all over the world, and the console lets you provision resources across multiple regions. You usually choose a region that best suits your business needs to optimize your customer’s experience, but we must use the US West 2for this lab.
The AWS Management Console is a web control panel for managing all your AWS resources, from EC2 instances to SNS topics. The console enables cloud management for all aspects of the AWS account, including managing security credentials and even setting up new IAM Users.

2. **Create CloudTrail Trail**

Introduction

In this lab step, you'll learn how to set up CloudTrail to capture and log a subset of AWS API calls. For this lab scenario which involves a Lambda function (to be deployed) writing out to S3, you'll only need to configure CloudTrail to capture and record Lambda and S3 data plane AWS API calls. Next, to support your security policy analysis, you need complete the CloudTrail set up by establishing a new Athena database table, configured to read over the new CloudTrail logs. Upon completion, you'll be able to use Athena later in the lab to perform SQL queries over the data captured in the new CloudTrail logs.

Instructions

In the AWS Management Console search bar, enter CloudTrail, and click the CloudTrail result under Services:

The CloudTrail management console will load.

You may see blue warning notifications that say you aren't allowed to create a Cloud Trail for an organization. In this lab, you will create a Cloud Trail for the AWS account, blue warning notifications you see as you fill out the CloudTrail creation form can be safely ignored.

In the Trails section, click the Create trail button:

A multi-step form-wizard will load, beginning with the Choose trail attributes step.

In the General details section, enter the following information to complete the form:

Trail name: LambdaS3Trail
Storage location: Select Create new S3 bucket
Trail log bucket and folder: Accept the provided default
Log file SSE-KMS encryption: Uncheck this
Log file validation: Uncheck this

Make a note of the name of the Amazon S3 bucket.

You will use this later in the lab when querying within Amazon Athena.

I recommend opening a notes page and using it to store notes for the duration of this lab.

At the bottom of the page, click Next.
On this page, ensure the only Event type selected is Data events:

6.1. In the Data events section add the first data event type for Lambda. Select Lambda in the Data event type drop-down:

6.2. In the Dataevents section add a second data event type for S3 by clicking the Add data event type button. Select S3 in the Data event type drop-down:
6.2. In the Dataevents section add a second data event type for S3 by clicking the Add data event type button. Select S3 in the Data event type drop-down:

At the bottom of the page, click Next.
Review the settings and click Create trail at the bottom when ready.

You will see your newly created trail listed in the Trails table:

Your LambdaS3Trail Trail has now been created successfully, along with the S3 bucket it will deliver logs to. The path in S3 to a specific CloudTrail object adheres to the following pattern:
bucket_name/prefix_name/AWSLogs/Account ID/CloudTrail/region/YYYY/MM/DD/file_name.json.gz

Click on the name of your Trail. This opens up a Configuration page for your new Trail Your LambdaS3Trail Trail has now been created successfully, along with the S3 bucket it will deliver logs to. The path in S3 to a specific CloudTrail object adheres to the following pattern: bucket_name/prefix_name/AWSLogs/Account ID/CloudTrail/region/YYYY/MM/DD/file_name.json.gz
Click on the name of your Trail. This opens up a Configuration page for your new Trail

Don't change anything just yet, but you should notice the following important points:

Trail logging: This will be green and say Logging, signifying that logging is enabled.
Last log file delivered: This should get updated very shortly after Trail creation. If you don't see a date/timestamp entry, refresh your browser.

Next, you will examine the contents of the Amazon S3 bucket.

Note: Until you see a date/time stamp for Last log file delivered, you will not see any JSON files in the S3 bucket. Refresh your browser a few times over a 2-3 minute period before going to the next instruction. CloudTrail delivers logs approximately every 5 minutes.

In the top-left, right-click the aws icon and open a new browser tab.

A new AWS Management Console page will load in the new browser tab.

In the new browser tab, in the search bar at the top, enter S3, and under Services, click the S3 result:

In the Buckets table, click the name of your CloudTrail bucket:

Continue navigating down the folder prefix/ structure until you see one or more compressed CloudTrail log JSON files (ending with .json.gz).

It may take a few minutes and browser refreshes before you can navigate further down the structure. Eventually, CloudTrail will transfer log files even with little to no use in the Console. (For example, DescribeTrails and ListBuckets events.) Five minutes is the longest you should have to wait.

Look at the name of a JSON log file and notice that the file naming convention includes:

The Account ID
The text CloudTrail
The region
A date/time stamp
A unique string (generated by AWS)
A .json.gz file name extension (JSON file type, compressed via gzip)
Return to the CloudTrail console and setup CloudTrail to publish logs into Athena. 15.1. Select the Event history option in the left-hand side menu:

15.2. In the Event history pane click on the Create Athena table button:

15.3. In the Create a table in Amazon Athena pop-up pane, set the Storage location to use the CloudTrail S3 bucket created earlier:

15.4. Click the Create table button to complete the CloudTrail and Athena integration.

15.5 Confirm that the CloudTrail and Athena integration were completed successfully:

Summary
In this lab step, you learned how to set up CloudTrail to easily and quickly capture and log S3 and Lambda data plane AWS API calls. You then completed the CloudTrail set up by establishing a new Athena database table, configured to read over the newly established CloudTrail logs. Later on in the lab, you'll use Athena to query the data captured in the new CloudTrail logs.
3. Create Lambda Function
In this lab step, you'll deploy a simple Lambda function representing the business process spoken of in the lab introduction. The Lambda function will be configured to use Python 3 for the runtime. The business process implemented within the Lambda function creates randomly named files which are then saved into the provided Business Data S3 bucket. The Lambda Function will be configured to use a pre-provisioned IAM Role that has a relaxed set of permissions for writing files into S3. In the next lab step you'll use Athena to query the CloudTrail logs, allowing you to observe the various AWS API calls collected as a result of the Lambda function's execution. This will inform you as to whether the Lambda's IAM Role can be improved in terms of the permission set associated with it.
Instructions

In the AWS Management Console search bar, enter Lambda, and click the Lambda result under Services:

You will be taken to the Functions list page:

No AWS Lambda functions exist at the moment.

2. Click Create a function to start creating your first AWS Lambda function.

3. In the Create function wizard, ensure Author from scratchis selected and enter the following values in the bottom form:

Name: BusinessWorkflow
Runtime: Python 3.9
Permissions: Click Change default execution role
- Execution Role: Select Use an existing role
- Existing role: Select the role beginning with LambdaExecutionRole1

Click Create function.

You are taken to the function's details page:

Scroll down to the Code source section, double-click the lambda_function.py file on the left, and overwrite the contents of the file with the following code: import boto3 from random import choice from string import ascii_uppercase def lambda_handler(event, context): data = 'business data...' encoded_data = data.encode("utf-8") bucket_name = 'business-data-2668be00' file_name = f"file.{''.join(choice(ascii_uppercase) for i in range(5))}.txt" s3_path = "data/" + file_name s3 = boto3.resource("s3") s3.Bucket(bucket_name).put_object(Key=s3_path, Body=encoded_data) return "Success"

Click Deploy at the top to save and deploy the Lambda function.
Click Test (next to Deploy):

In the Configure test event form, set the Event name to be BusinessDataTestEvent. Leave the remaining settings as their provided defaults and proceed by clicking Save:

Note: In practice, the event body comes from SNS or whatever event source you configure. For now, you will just use Lambda's testing functionality to send in sample event data.

9. The BusinessWorkflow Lambda function is now ready to be executed. Click the Test button (next to the Deploy button) and wait for the execution results to be displayed.

Within a few seconds, you will see the Execution results tab load in the editor.

The BusinessWorkflow Lambda function when executed creates a new file and saves it into the business-data-xxxxxx S3 bucket.

Repeat the same BusinessWorkflow Lambda function execution by clicking the Test button multiple times after each previous execution completes successfully.
Navigate to the S3 console, opens in a new tab and confirm the presence of the new business data files within the business-data-xxxxxx bucket:

Summary

In this lab step, you deployed a Lambda function representing the business process spoken of in the lab introduction. The Lambda function was configured to use Python 3 for the runtime. The business process implemented within the Lambda function creates randomly named files which are then saved into the provided Business Data S3 bucket. You configured the Lambda Function with a pre-provisioned IAM Role that has a relaxed set of permissions for writing files into S3. In the next lab step, you'll use Athena to query the CloudTrail logs, allowing you to observe the various AWS API calls collected as a result of the Lambda function's execution. This will inform you as to whether the Lambda's IAM Role can be improved in terms of the permission set associated with it.

4. **Use Athena to Query CloudTrail Events**

Introduction

In this lab step, you'll learn how to use Athena to query and analyze the CloudTrail logs that you configured earlier. In particular, you'll learn how to write Athena SQL queries that allow you to drill into the AWS API calls made by the deployed Lambda function. The Athena queries you execute will provide various insights into the AWS API calls, their origin, the event data associated with the call, and the date and time of the call - amongst many other attributes. Learning how to use Athena effectively to analyze CloudTrail log files can help to highlight IAM policies that are too permissible etc.

Instructions

In the AWS Management Console search bar, enter Athena, and click the Athena result under Services:

On the Athena landing page, click the Explore the query editor button to open the Editor view:

If the Workgroup primary settings pane is shown, click the Acknowledge button to accept and close:

Change the Athena Query result location to use the lab provided S3 bucket. 4.1. Click on the Settings tab:

4.2. Click on the Manage button with the Settings tab:
4.3. In the Manage settings section, set the Location of query result field to be:
s3://athena-query-results-2668be00/query-results

4.4. Click the Save button to apply the changes. Confirm that the new settings have been successfully applied:

Navigate back to the Editor tab by clicking on it. An empty Query 1 worksheet should be presented:

In the left menu Tables area, click over the

icon next to the cloudtrail_logs_aws_cloudtrail_logs_xxxxxx_xxxxxx table and and select the Preview Table option:

Confirm that the Query 2 worksheet has been opened, and pre-populated with a SQL query that has been executed automatically. The Results section should display the rows returned by the SQL query:

Note: CloudTrail sends new log files approximately every 5 minutes - there might be a delay before the new logging data arrives.

8. Click the + icon to add a worksheet Query 3. In the new worksheet copy and paste the following SQL query and then click the Run button to execute:

SELECT
DISTINCT eventname
FROM "REPLACE_WITH_YOUR_CLOUDTRAIL_TABLE_NAME"
ORDER BY eventname;

Notes:

You need to update the REPLACE_WITH_YOUR_CLOUDTRAIL_TABLE_NAME with the CloudTrail table name specific to your lab environment. This can be copied over from the query in the Query 2 worksheet.
This SQL query displays and orders all distinct AWS API actions that have been collected so far.
CloudTrail sends new log files approximately every 5 minutes - there might be a delay before the new logging data arrives.

9. Click the + icon to add a worksheet Query 4. In the new worksheet copy and paste the following SQL query and then click the Run button to execute:

SELECT
json_extract(json_parse(requestparameters), '$.bucketName') AS bucketName,
json_extract(json_parse(requestparameters), '$.key') AS bucketKey,
*
FROM "REPLACE_WITH_YOUR_CLOUDTRAIL_TABLE_NAME"
where eventname = 'PutObject'
AND eventsource = 's3.amazonaws.com'
AND CAST(json_extract(json_parse(requestparameters), '$.bucketName') AS VARCHAR) = 'business-data-2668be00'

Notes:

You need to update the REPLACE_WITH_YOUR_CLOUDTRAIL_TABLE_NAME with the CloudTrail table name specific to your lab environment. This can be copied over from the query in the Query 2 worksheet.
This SQL query drills into the JSON data embedded within each row and pulls out the S3 bucket name and key for PutObject events on the Business Data s3 bucket (the bucket that the Lambda Function writes to).
CloudTrail sends new log files approximately every 5 minutes - there might be a delay before the new logging data arrives.

10. Click the + icon to add a worksheet Query 5. In the new worksheet copy and paste the following SQL query and then click the Run button to execute:

SELECT
json_extract(json_parse(requestparameters), '$.bucketName') AS bucketName,
json_extract(json_parse(requestparameters), '$.key') AS bucketKey,
useridentity.arn
FROM "REPLACE_WITH_YOUR_CLOUDTRAIL_TABLE_NAME"
where eventname = 'PutObject'
AND eventsource = 's3.amazonaws.com'
AND CAST(json_extract(json_parse(requestparameters), '$.bucketName') AS VARCHAR) = 'business-data-2668be00'

Notes:

You need to update the REPLACE_WITH_YOUR_CLOUDTRAIL_TABLE_NAME with the CloudTrail table name specific to your lab environment. This can be copied over from the query in the Query 2 worksheet.
This SQL query drills into the JSON data embedded within each row and pulls out the S3 bucket name and key for PutObject events on the Business Data s3 bucket (the bucket that the Lambda Function writes to) - it also pulls out the ARN for the caller of the PutObject event.
CloudTrail sends new log files approximately every 5 minutes - there might be a delay before the new logging data arrives.

Summary
In this lab step, you learned how to use Athena to query and analyze CloudTrail logs stored in an S3 bucket. In particular, you learned how to write Athena SQL queries that allowed you to drill into the various AWS API calls made by the deployed Lambda function. The Athena queries you executed provided you with various insights into the AWS API calls, their origin, the event data associated with the call, and the date and time of the call - amongst many other attributes. Specifically, you were able to reveal detailed information about the S3 bucket name and the S3 bucket keys being used to store the business data files generated by the execution of the Lambda function.
5. Review Full IAM Actions List
Introduction
When creating and refining IAM policies, it's useful to access all possible IAM actions in one place, such that you can quickly query and filter over them.
In this lab step, you'll be shown how to easily gather all possible IAM actions from the AWS Policy Generator, opens in a new tab website into a single file which you can then filter over offline using utilities such as grep.
Instructions

Navigate to the Instances, opens in a new tab page, right-click the row of the instance beginning with ops, click Connect, and ensure ec2-user is set as the Username before clicking Connect:

Install the jq utility to support the parsing of JSON data: In the terminal execute the following command: sudo yum install -y jq

Extract the full set of IAM policy actions from the awspolicygen.s3.amazonaws.com, opens in a new tab public website using curl , saving them into the file aws.iam.actions.txt locally. In the terminal execute the following command:

curl --header 'Connection: keep-alive' \
--header 'Pragma: no-cache' \
--header 'Cache-Control: no-cache' \
--header 'Accept: */*' \
--header 'Referer: https://awspolicygen.s3.amazonaws.com/policygen.html' \
--header 'Accept-Language: en-US,en;q=0.9' \
--silent \
--compressed \
'https://awspolicygen.s3.amazonaws.com/js/policies.js' |
cut -d= -f2 |
jq -r '.serviceMap[] | .StringPrefix as $prefix | .Actions[] | "\($prefix):\(.)"' |
sort |
uniq > aws.iam.actions.txt

Examine the count of all IAM actions stored in the aws.iam.actions.txt file. In the terminal execute the following command: cat aws.iam.actions.txt | wc -l

We now have access to all of the available IAM actions - let's perform an example search for all Lambda actions using grep. In the terminal execute the following command: grep ^lambda: aws.iam.actions.txt

Let's try another example - this time let's search for all Lambda and S3 Get actions using grep. In the terminal execute the following command: grep '^lambda:Get\|^s3:Get' aws.iam.actions.txt

Summary

In this lab step, you learned how to easily extract all possible IAM policy actions from the AWS Policy Generator, opens in a new tab website and store them locally into a single file. You then used grep to perform several searches to quickly find various IAM policy actions. Understanding how to navigate and quickly filter of the full set of IAM policy actions is useful when creating and updating IAM policies. In the next lab step, you'll take the insights gathered from the Athena queries and the techniques learned in this lab step to refine the deployed Lambda function's execution IAM role.

6. **Review and Update Lambda Execution Role Policy**

Introduction

In this lab step, you'll leverage the insights that you derived from the Athena SQL queries earlier performed over the collected CloudTrail log files to update the existing IAM Role policy assigned to the BusinessWorkflow Lambda function.

Note: For security reasons, the lab platform prevents you from creating or modifying custom IAM policies, therefore a second IAM Role (with updated policy) has already been created for you for the purposes of completing this lab.

Instructions

In the AWS Management Console search bar, enter IAM, and click the IAM result under Services:

Ignore all permission warnings on the IAM dashboard page (the lab is a controlled environment and many IAM operations are purposely blocked).
Under the left-hand side Access management menu, click the Roles link:

4. In the Roles search field, search for *LambdaExecution*. The search results should contain 2 roles, LambdaExecutionRole1-xxxxxx and ambdaExecutionRole2-xxxxxx.

4.1. The deployed Lambda function is currently configured to execute with the first of the 2 roles. Open the LambdaExecutionRole1-xxxxxx role in a new browser tab and expand the attached S3BucketBusinessData1 inline policy to view its permissions:

4.2. Open the second role cloudacademylabs-LambdaExecutionRole2-xxxxxx role in a new browser tab and expand the attached S3BucketBusinessData2 inline policy to view its permissions. This IAM Role and Policy represents the updates that you as the security reviewer would have created in response to the insights you derived from the Athena SQL queries you previously executed. This IAM Role has been created for you (since the lab platform prevents you from creating/modifying policies).

5. Modify the existing BusinessWorkflowLambda function to use the updated IAM Role (LambdaExecutionRole2-xxxxxx).

5.1. Return to the Lambda console and navigate to the BusinessWorkflow Lambda function. Click on the Configuration tab and select the Permissions option:

5.2. Within the Execution role pane click the Edit button. This will display the Basic settings view for the Lambda function. Under the Existing role option, click the drop-down and select the alternate second role (LambdaExecutionRole2-xxxxxx).

5.3 Click the Save to apply the Lambda function's Execution IAM Role change.

6. The BusinessWorkflow Lambda function is now ready to be executed again with a more secure IAM Role for performing s3:* operations on a narrower set of buckets. Confirm that the BusinessWorkflow Lambda function remains fully functional. Return to the Code tab, and then click the Test button multiple times (next to the Deploy button) and wait for the execution results to be displayed each time.

Within a few seconds, you will see the Execution results tab load in the editor:

Return to the S3 console and navigate to the business-data-2668be00 S3 bucket and navigate into the data folder. Confirm that the updated Lambda function has successfully been able to write into the configured S3 bucket:

8. Bonus step - Return to the Athena console and execute the following SQL query to confirm the presence of new logging data:

Notes:

You need to update the REPLACE_WITH_YOUR_CLOUDTRAIL_TABLE_NAME with the CloudTrail table name specific to your lab environment. This can be copied over from the query in the Query 2 worksheet.
CloudTrail sends new log files approximately every 5 minutes - there might be a delay before the new logging data arrives.

SELECT
json_extract(json_parse(requestparameters), '$.bucketName') AS bucketName,
json_extract(json_parse(requestparameters), '$.key') AS bucketKey,
eventtime,
useridentity.arn,
*
FROM "REPLACE_WITH_YOUR_CLOUDTRAIL_TABLE_NAME"
where eventname = 'PutObject'
AND eventsource = 's3.amazonaws.com'
AND CAST(json_extract(json_parse(requestparameters), '$.bucketName') AS VARCHAR) = 'business-data-2668be00'

Summary

In this lab step, you completed the IAM Role policy security review, applying the insights derived from the Athena SQL queries previously evaluated over the collected CloudTrail data. You then confirmed the BusinessWorkflow Lambda function remained functional after the improved least privilege security updates had been applied.

Conclusion
This lab demonstrated a comprehensive, evidence-based approach to implementing IAM least privilege security policies for AWS Lambda functions through systematic API activity analysis. By establishing a robust observability pipeline using CloudTrail and Athena, you successfully transformed broad, permissive IAM policies into narrowly scoped, security-hardened permissions that precisely match actual operational requirements.
Technical Achievements and Key Outcomes
Throughout this lab scenario, you accomplished several critical security engineering objectives:
1. Established Comprehensive AWS API Auditing Infrastructure
You configured CloudTrail to capture Lambda and S3 data plane events, creating a continuous audit trail of all API operations. This logging infrastructure serves dual purposes: immediate security analysis and long-term compliance auditing. The integration with Athena transformed raw CloudTrail logs into a queryable dataset, enabling SQL-based forensic analysis of AWS API activity. This architecture provides the foundation for ongoing security monitoring, incident investigation, and compliance reporting required in production environments.
2. Implemented Data-Driven Security Policy Analysis
Rather than relying on assumptions or documentation, you employed empirical analysis to understand the Lambda function's actual AWS API usage patterns. The Athena SQL queries you executed revealed precise details about:

Specific S3 operations performed (PutObject)
Target bucket names and object keys
Identity and ARN of the calling principal
Temporal patterns of API invocations
This data-driven methodology eliminates guesswork from IAM policy creation and ensures policies are based on observed behavior rather than projected requirements.
3. Applied Least Privilege Security Principles
The transition from LambdaExecutionRole1 to LambdaExecutionRole2 exemplifies the principle of least privilege in practice. The initial policy granted overly broad S3 permissions (s3:* on * or multiple buckets), creating unnecessary attack surface and violating security best practices. Through CloudTrail analysis, you identified that the Lambda function required only s3:PutObject permissions on a single specific bucket (business-data-2668be00) within a specific prefix (data/*). This reduction in permission scope significantly minimizes:
Blast radius of potential security breaches or compromised credentials
Lateral movement opportunities for attackers
Accidental data exposure or modification risks
Compliance audit findings related to excessive permissions
4. Validated Functional Equivalence Post-Hardening
A critical aspect of security hardening is ensuring operational continuity. You verified that the Lambda function maintained full functionality after the IAM policy restrictions were applied, demonstrating that security improvements need not compromise business operations. This validation step is essential in production environments where availability and reliability requirements must be balanced with security controls.
Security and Compliance Benefits
The methodologies practiced in this lab deliver substantial security and compliance advantages in production AWS environments:
Enhanced Security Posture: By restricting IAM permissions to only those actions and resources demonstrably required, you reduce the attack surface available to malicious actors. If credentials were compromised or the Lambda function contained a vulnerability, the restricted permissions limit what an attacker could access or modify.
Improved Compliance Readiness: Many regulatory frameworks (PCI-DSS, HIPAA, SOC 2, ISO 27001) mandate least privilege access controls. The CloudTrail audit trail provides evidence of API activity for compliance audits, while the refined IAM policies demonstrate adherence to access control requirements.
Operational Transparency: The CloudTrail and Athena pipeline provides complete visibility into Lambda function behavior, enabling security teams to detect anomalies, investigate incidents, and generate compliance reports without requiring access to application logs or code.
Defense in Depth: This approach adds multiple security layers—restrictive IAM policies, comprehensive logging, and queryable audit trails—creating resilience against various attack vectors and failure modes.
Architectural Patterns and Best Practices
This lab reinforced several AWS security architecture patterns applicable to production environments:
Separation of Data and Management Planes: By configuring CloudTrail to capture data events (actual S3 and Lambda operations) rather than only management events (AWS Console or API configuration changes), you gained visibility into the runtime behavior of your application, not just its configuration.
Infrastructure as Code Considerations: In production environments, the IAM role refinement process demonstrated here should be codified in Infrastructure as Code (IaC) tools such as AWS CloudFormation, Terraform, or AWS CDK. This ensures IAM policies remain under version control and can be reviewed, tested, and deployed through CI/CD pipelines.
Iterative Security Hardening: The workflow established—deploy with initial permissions, observe actual behavior, refine policies, validate functionality—represents an iterative security improvement cycle. This pattern should be applied continuously as application requirements evolve, ensuring IAM policies remain aligned with actual operational needs.
Automated Policy Analysis: While this lab used manual Athena queries, production environments can benefit from automated analysis using AWS services like Amazon Detective, AWS Security Hub, or custom Lambda functions that periodically analyze CloudTrail data and recommend IAM policy optimizations.
Ongoing Security Considerations
Implementing least privilege IAM policies is not a one-time activity but an ongoing security practice:
Policy Drift Detection: As application functionality evolves, IAM policies must be reviewed and updated. Regular CloudTrail analysis can identify when Lambda functions begin making API calls not covered by their current policies, signaling either unauthorized activity or the need for policy updates.
Access Denial Monitoring: CloudTrail logs capture both successful and denied API calls. Monitoring for AccessDenied errors can reveal either overly restrictive policies that impede legitimate functionality or potential reconnaissance activities by attackers testing permission boundaries.
Cross-Account and Cross-Service Analysis: In complex AWS environments, Lambda functions may interact with resources across multiple AWS accounts or services. The CloudTrail and Athena analysis techniques demonstrated here can be extended to include cross-account trails and multi-service API analysis, providing comprehensive visibility into distributed application behavior.
Automated Remediation: Advanced implementations can use AWS services like AWS Config Rules, AWS Lambda, and Amazon EventBridge to automatically detect IAM policy violations and either alert security teams or automatically apply corrective actions.
Scalability and Production Considerations
When implementing this approach at scale in production environments, consider:
CloudTrail Log Volume Management: Data events generate significantly higher log volumes than management events. Implement S3 lifecycle policies to archive older logs to lower-cost storage tiers (S3 Glacier) while maintaining recent logs in S3 Standard for Athena queries.
Athena Query Optimization: For large-scale deployments, partition CloudTrail logs by date, region, and service to improve Athena query performance and reduce costs. Use table partitioning and predicate pushdown in SQL queries to minimize data scanned.
Cost Management: CloudTrail data events incur per-event charges. Carefully scope CloudTrail configuration to capture only the events required for security analysis rather than all possible data events across all services.
Integration with SIEM and Security Tools: CloudTrail logs should be integrated with Security Information and Event Management (SIEM) systems, AWS Security Hub, or third-party security platforms to enable real-time threat detection and automated incident response.

Becoming an AWS Community Builder

Wilklins Nyatteng — Wed, 25 Dec 2024 04:47:47 +0000

Becoming an AWS Community Builder is an exciting opportunity for professionals who are passionate about cloud computing and want to share their knowledge and expertise with others. Whether you're interested in security and identity like me or any other area of AWS, being a Community Builder allows you to contribute to the AWS community, collaborate with like-minded individuals, and help others on their cloud journey. In this article, we'll explore the steps to becoming an AWS Community Builder and provide valuable advice to those who aspire to join the program.

1. Understanding the AWS Community Builder Program:
The first step is to familiarize yourself with the AWS Community Builder Program. Visit the official AWS Community Builder website https://aws.amazon.com/developer/community/community-builders/ to learn about its objectives, benefits, and the responsibilities associated with the role. Gain a clear understanding of what it means to be a Community Builder and the expectations that come with it.

2. Develop Your AWS Expertise:
It's crucial to have an understanding of AWS services, features, and best practices. Continue expanding your knowledge by exploring the extensive AWS documentation https://docs.aws.amazon.com/ and studying relevant whitepapers https://aws.amazon.com/whitepapers/. Consider pursuing AWS certifications to showcase your expertise and commitment to AWS. The AWS Training and Certification website https://aws.amazon.com/training/ offers a comprehensive range of resources and courses to help you prepare for certification exams.

3. Engage with the AWS Community:
Active engagement within the AWS community is essential for becoming a Community Builder. Start by attending local AWS user groups, meetups, and events. Participate in online forums, such as the AWS Developer Forums (https://forums.aws.amazon.com/index.jspa), Reddit's /r/aws subreddit (https://www.reddit.com/r/aws/), and the AWS Community Forum (https://forums.aws.amazon.com/forum.jspa?forumID=30), where you can contribute to discussions, ask questions, and provide solutions to fellow community members.

4. Share Your Knowledge:
Demonstrate your expertise and passion for AWS by sharing your knowledge through blog posts, tutorials, or video content. Publish your content on platforms like Medium (https://medium.com/), Dev.to (https://dev.to/), or your personal website. Leverage social media platforms like Twitter and LinkedIn to share your content and engage with the AWS community. Consider writing guest articles for established AWS-focused blogs and publications to increase your visibility.

5. Contribute to Open Source Projects:
Engaging with open source projects related to AWS can be an excellent way to showcase your skills and demonstrate your commitment to the community. Explore projects on GitHub (https://github.com/topics/aws) and actively contribute by submitting pull requests, opening issues, or creating your own projects. Collaborating with other developers on open source projects can help you establish yourself as an active and valuable member of the community.

Apply to Become an AWS Community Builder: Once you have developed a strong AWS skill set, actively engaged with the community, and shared your knowledge, it's time to apply to become an AWS Community Builder. Visit the AWS Community Builder website (https://aws.amazon.com/developer/community/community-builders/) and follow the instructions provided to submit your application. Be prepared to showcase your contributions, share your experiences, and explain how you plan to contribute to the AWS community as a Community Builder.

Conclusion
Becoming an AWS Community Builder is an exciting journey that allows you to connect with a vibrant community of cloud professionals, share your expertise, and contribute to the growth of AWS. By following the steps outlined in this article, including understanding the program, developing your AWS skills, engaging with the community, sharing your knowledge, contributing to open source projects, and applying to become a Community Builder, you can position yourself as a valuable member of the AWS community and make a meaningful impact on the cloud computing industry.

REMEMBER, the AWS Community Builder Program is not limited to security and identity—it encompasses various areas of AWS expertise. Adapt the steps mentioned here to align with your specific interests and specialization. Good luck on your journey to becoming an AWS Community Builder!

IAM for Amazon ECS on AWS Fargate

Wilklins Nyatteng — Thu, 29 Aug 2024 10:37:00 +0000

AWS Identity and Access Management (IAM) helps you securely control access to AWS resources, and Amazon ECS is no exception. IAM controls what can access ECS resources in your AWS accounts. IAM also controls which AWS resources ECS and tasks running in ECS can access. This will be the focus of this lab.

Two types of IAM roles are used by ECS:

ECS task execution role: This role is used by the ECS agent to pull container images and send logs to CloudWatch.
ECS task role: This role is used by the containers to access other AWS services they depend on at runtime.

In this lab, you will learn about the ECS IAM roles first-hand and diagnose and troubleshoot related issues.

Learning objectives

Upon completion, you will be able to:

Explain ECS task execution roles and task roles
Diagnose and debug IAM issues in ECS
Resolve IAM issues in ECS running

Prerequisites

Familiarity with the following topics is required to get the most out of this lab:

AWS Identity and Access Management (IAM) fundamentals (roles and policies)
Amazon Elastic Container Service (ECS) on AWS Fargate fundamentals
Terraform fundamentals, with experience deploying on AWS

Environment Before

ECS cluster that resembles the following diagram.

The ECS cluster contains three services that run a stock charting application:

Frontend: React frontend that displays stock charts.
API: RESTful API that provides stock data. The API is written in Java and uses the Spring Boot framework.
Database: Persistence layer for (simulated) stock data. It is not usually advisable to run a database in a container, but for this lab, it is used to reduce the time needed to provision the lab compared to using RDS.

Each service has an auto-scaling group that maintains a desired task count of containers.

The frontend and API services sit in public subnets behind a public-facing application load balancer (ALB), while the database service resides in a private subnet behind an internal-facing ALB. To access the application, you can navigate to the following ALB public URL once the lab has been setup completely.

The application works fine, but a new feature is being developed that requires the API service to have access to S3. The initial code checks if a given S3 bucket exists and creates it if not. This will be the focus of your investigation into IAM in ECS.

These ECS resources are deployed using Terraform. This lab step will briefly highlight the resource configurations and Java application code related to IAM and will be referenced throughout this lab.

Reviewing the Sample Application Deployed on Amazon ECS With AWS Fargate

Instructions

I opened the lab’s development environment then launched the template.tf file in the editor

# Abbreviated template emphasizing IAM resources

resource "aws_ecs_cluster" "ecs_cluster" {
  name = "lab-cluster"
}

resource "aws_ecs_task_definition" "api_task_definition" {
  family                   = "lab-api"
  execution_role_arn       = aws_iam_role.ecs_task_execution_role.arn
  task_role_arn            = aws_iam_role.ecs_task_role.arn
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  ...

  container_definitions = jsonencode([
    {
      ...
      environment = [
        { name = "BUCKET_NAME", value = "lab-experimental-${data.aws_caller_identity.current.id}" } # e.g. lab-experimental-123456789012
      ]
      ...
    }
  ])
}

# IAM

data "aws_iam_policy_document" "assume_role_policy" {
  statement {
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["ecs-tasks.amazonaws.com"]
    }
  }
}

data "aws_iam_policy_document" "ecs_task_policy" {
  statement {
    effect = "Allow"
    resources = [
      "arn:aws:s3:::${local.bucket_name}",
    ]
    actions = [
      "s3:GetBucketAcl",
    ]
  }
}

data "aws_iam_policy_document" "ecs_task_create_bucket_policy" {
  statement {
    effect = "Allow"
    resources = [
      "arn:aws:s3:::${local.bucket_name}",
    ]
    actions = [
      "s3:CreateBucket",
    ]
  }
}

resource "aws_iam_role" "ecs_task_execution_role" {
  name               = "lab-ecs-task-execution-role"
  assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json
}

resource "aws_iam_role" "ecs_task_role" {
  name               = "lab-ecs-task-role"
  assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json

  inline_policy {
    name   = "task-role-policy"
    policy = data.aws_iam_policy_document.ecs_task_policy.json
  }
}

resource "aws_iam_role_policy_attachment" "ecs_task_execution_role_policy" {
  role       = aws_iam_role.ecs_task_execution_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}

resource "aws_iam_policy" "ecs_task_create_bucket_policy" {
  name        = "lab-ecs-s3-task-policy"
  description = "Allows S3 actions for ECS tasks"
  policy      = data.aws_iam_policy_document.ecs_task_create_bucket_policy.json
}

...

To get an overview of the relevant Terraform resource configurations:

Starting with the aws_ecs_task_definition.api_task_definition on line 7, the two arguments for configuring the roles are execution_role_arn and task_role_arn:

The task_role_arn provides the task's containers access to other AWS services. The execution_role_arn is used by the ECS container agent to pull container images from ECR and send logs to CloudWatch.

On line 19, an environment variable is set to configure the name of the S3 bucket that the API service will use:

The assume role policy, or trust policy, for both task execution and task roles, is configured beginning on line 28:

The trust policy allows the ECS service to assume the role. Notice that both types or roles are assumed by the ecs-tasks.amazonaws.com service principal, so only one trust policy is needed.

Below that, from lines 39-61, are two data IAM policy document sources that store simple single-action policy statements for S3:

The ecs_task_policy grants the s3:GetBucketAcl action on the API's S3 bucket while the ecs_task_create_bucket_policy grants s3:CreateBucket. These two policies allow checking if a bucket exists and creating it if not.

The task execution role (ecs_task_execution_role) and task role (ecs_task_role) are configured on lines 63-76, respectively:

Both roles configure the same trust policy with the assume_role_policy argument. The ecs_task_role also has an inline_policy argument referencing the ecs_task_policy data source. This policy grants the API service initial access to check if S3 buckets exist.

On lines 78-81, the task execution role has an AWS-managed policy attached to it:

This policy grants the ECS container agent access to pull container images from ECR and send logs to CloudWatch. You can view the AWS-managed AmazonECSTaskExecutionRolePolicy here. AWS-managed policies are a convenient way to grant common permissions to a role, but you should use them with caution in production where least-privilege policies are preferred. For example, you may want to specify a specific ECR registry where container images are allowed to be pulled.

Lastly, a custom IAM policy is created using the ecs_task_create_bucket_policy data source policy document for use later on in the lab:

Next we check the java file to view the relevant source code for accessing S3

package com.cloudacademy.stocks.utils;

import com.amazonaws.services.s3.AmazonS3;
import com.amazonaws.services.s3.model.AmazonS3Exception;
import com.amazonaws.services.s3.model.Bucket;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

@Component
public class S3Initializer {

    private final AmazonS3 amazonS3;

    @Autowired
    public S3Initializer(AmazonS3 amazonS3) {
        this.amazonS3 = amazonS3;
    }

    public void init(String bucketName) {
        while (true) {
            try {
                try {
                    if (!amazonS3.doesBucketExistV2(bucketName)) {
                        Bucket bucket = amazonS3.createBucket(bucketName);
                        System.out.println("Bucket created: " + bucketName);
                        break;
                    } else {
                        System.out.println("Bucket already exists: " + bucketName);
                        break;
                    }
                } catch (AmazonS3Exception e) {
                    System.err.println("Error creating bucket: " + e.getMessage());
                } 
                Thread.sleep(5000);
            } catch (InterruptedException ex) {
                Thread.currentThread().interrupt();
                System.err.println("Thread interrupted");
            }
        }
    }
}

The application uses the aws-java-sdk-s3 library to interact with S3
The init method checks if the S3 bucket exists (line 24) and creates it if not (line 25)
- The process is repeated every 5 seconds until the bucket is created or found to exist. This ensures a steady stream of log error messages if there are any IAM permission issues.
- The doesBucketExistV2 uses the getBucketAcl API action as seen in the aws-java-sdk source code on GitHub and also explained in the AWS SDK for Java API Reference.

In practice, it may be preferred to create the bucket using Terraform. However, this application code is a convenient way to demonstrate IAM concepts in ECS on Fargate.

Up next, you will configure AWS credentials in this IDE's terminal to provide access to the AWS CLI used in the next lab step.

So we configure the AWS CLI:

aws configure set aws_access_key_id {REDACTED} &&
aws configure set aws_secret_access_key {REDACTED} &&
aws configure set default.region us-west-2

Detecting the Task's IAM Issue

A solid understanding of the differences between the task execution role and task role is essential to understanding the IAM issue in ECS.

The task execution role grants permissions to the Fargate container agent. Typical examples of what permissions are provided by the task execution role include:

Permission to pull container images from private Amazon Elastic Container Registry (ECR)
Sending logs to Amazon CloudWatch

These two use cases are what the AWS-managed policy AmazonECSTaskExecutionRolePolicy allow. Other use cases may require accessing AWS Secrets Manager, for example. In this case, you must create a custom task execution role with a custom policy attached to it. More details are provided in the official documentation.

The task role is also used by the task's containers to access other AWS services they depend on at runtime, such as Amazon Simple Storage Service (S3), Amazon Relational Database Service (RDS), and Amazon DynamoDB.

This lab step inspects the lab environment to identify an IAM issue.

Instructions

In the AWS Management Console, navigate to the lab's ECS cluster:

All the services should be Active. If not, try periodically refreshing the Services table every minute until they are.

Click api-Service to view the API service's details.
On the Logs tab, note that logs are displayed.

The fact that log messages are present indicates that the task 
execution role allows the creation of CloudWatch log streams and 
putting log events. In fact, insufficient permissions on the task 
execution role often result in the task failing to start.

Click the Deployments and events tab and scroll down to the events table:

In case of task execution role issues, you can click on the task IDs presented in the events table to view error messages in the task overview panel that caused the task to fail.

Return to the API service's Logs tab and observe what log messages are displayed:

The log messages indicate that the application is unable to create the S3 bucket. The message is printed in the application code that catches the AmazonS3Exception within the retry loop. When errors aren't so obvious, you can search for errors directly from the logs view or open the logs in CloudWatch Logs for more advanced search capabilities.

Because the createBucket method is attempted, the doesBucketExistV2 method succeeded and returned false. This confirms that the Task container was successfully authenticated to the S3 service using the task role. Recall the task role initially only has permission to check if the bucket exists.

Observe in the Task column that more than one task ID is displayed:

By default, all task logs are merged and displayed. You can click on one of the task IDs to view the logs for that specific task when needed.

When the logs don't clearly indicate an IAM issue, you can use CloudTrail to identify failed AWS API calls. Note that there can be several minutes delay between a failed API call and when its corresponding event appears in CloudTrail.

Navigate to the CloudTrail event history:

The application code's attempts to create the S3 bucket are visible in the event history. By default, you can't tell from the table view if an API failed. The errorCode field indicates if a failure occurred and its column can be added to the table.

Click the cog to the upper-right of the table:

It brings preferences

Toggle the Error Code column on and click Confirm:

Now the AccessDenied errors are visible in the last column of the table.

You may be wondering why the API calls for checking if the bucket exists are not included in the table. By default, read-only events are excluded, but you can view them by changing the Read-only lookup attribute to true.

In your IDE terminal, enter the following command to view the last event from CloudTrail:

aws cloudtrail lookup-events --max-results 1

In the above example, the last event was a CreateBucket API call. The CloudTrailEvent event field contains the errorCode field, but it cannot be filtered using the AWS CLI alone. You may have CloudTrail configured to send events to other services with more advanced filtering capabilities. If not, you could use jq to filter the JSON output.

You learned how to identify an IAM issue in ECS. You learned how to view logs and events in the ECS console and how to use CloudTrail to identify failed API calls.

Resolving the Task's IAM Issue

To correct the IAM issue causing the application to fail to create the S3 bucket, you will update the task role in this lab step. Recall that an IAM least-privilege policy (lab-ecs-s3-task-policy) with permission to create the lab S3 bucket has already been created in the lab's terraform template.
In your IDE terminal, enter the following to attach the lab-ecs-s3-task-policy to the task role:

account_id=$(aws sts get-caller-identity --query Account --output text)
aws iam attach-role-policy --role-name lab-ecs-task-role --policy-arn arn:aws:iam::$account_id:policy/lab-ecs-s3-task-policy

Similarly, you could use the aws_iam_role_policy_attachment terraform resource to attach the policy to the task role. In practice, you may also consider merging the s3:CreateBucket permission into the existing role policy.

Return to the ECS API service's task role and periodically refresh the logs until you observe the following logs:

It can take a minute or two for the new permissions to propagate to the task's container. Once the permissions have propagated, the first task will successfully create the S3 bucket, and the second task will detect it exists.

You resolved the IAM issue by attaching a policy to the ECS task role.

Environment After

Conclusion
Properly configuring IAM for Amazon ECS on AWS Fargate is crucial for maintaining the security and compliance of your containerized applications.

By carefully defining task execution and task IAM roles, you can grant your containers the necessary permissions to access AWS resources while minimizing exposure.

This article has explored the fundamental concepts of IAM in the context of Fargate, including:

Understanding the difference between task execution and task IAM roles.
Creating IAM policies to grant specific permissions.
Best practices for managing IAM roles and policies.
By following these guidelines and tailoring them to your specific application requirements, you can establish a robust IAM strategy that protects your sensitive data and ensures the security of your containerized workloads on AWS Fargate.

Remember, the principle of least privilege should always guide your IAM decisions. Granting only the necessary permissions to your containers will reduce the potential attack surface and enhance overall security.

Connecting to Private EC2 Instances Using an Amazon EC2 Instance Connect Endpoint

Wilklins Nyatteng — Tue, 13 Aug 2024 10:37:00 +0000

Amazon EC2 Instance Connect (EIC) Endpoints provide a secure and seamless option for connecting to private EC2 instances. EIC endpoints can be configured using identity-based and network-based access controls, which provides more flexibility and control over the security of your VPC resources. These endpoints can also reduce administrative overhead and improve security by removing the need for a bastion host.

In this lab, you will replace a bastion host with an Amazon EC2 Instance Connect Endpoint to access a private EC2 instance. You will connect to the private instance using the AWS Management Console and the AWS CLI.

Learning objectives

Upon completion of this intermediate-level lab, you will be able to:

Configure an Amazon EC2 Instance Connect Endpoint
Access a private instance using an EC2 Instance Connect Endpoint

Familiarity with the following will be beneficial but is not required:

Amazon Virtual Private Cloud (VPC)
Amazon Elastic Compute Cloud (EC2)

Introducing Amazon EC2 Instance Connect Endpoints

Before EC2 Instance Connect Endpoints, you would need to connect to instances using a bastion host with a public IP address that could be accessed from the internet. To accomplish this, the VPC would also require an Internet Gateway (IGW) and the use of port forwarding to reach the private instance.

The diagram below illustrates a typical bastion host configuration and the starting infrastructure of this lab:

A user would connect to the bastion host via the IGW using a terminal or the EC2 Instance Connect service. The bastion host resides in a public subnet and is configured with the SSH keys needed to connect to the private instance. The bastion host would then connect to the private instance using SSH.

Not pictured in the diagram are the security groups that allow these instances to communicate with each other.

A client instance, or separate host machine, would not be able to connect to the private instance without additional configurations and SSH keys.

EC2 Instance Connect Endpoints

EC2 Instance Connect Endpoints offer the following benefits:

No requirement for a Bastion host
IAM-based authentication and authorization
Simplified management and administration
Compatible with existing SSH-based tools and workflows

The EIC endpoint will replace the Bastion Host and allow you to connect to the instance in the private subnet. This lab will demonstrate how to connect to the private instance using the AWS Management Console and the AWS CLI.

The client EC2 instance depicted in the diagrams will simulate a separate host machine with no SSH keys configured. This instance has the latest AWS CLI version installed.

This lab is meant to serve as an introduction to EC2 Instance Connect Endpoints. For additional benefits and configuration options, see the EC2 Instance Connect Endpoint documentation.

Connecting to the Virtual Machine using EC2 Instance Connect

This lab will use the EC2 Instance Connect console to connect to two EC2 instances. Both instances will attempt to connect to a private EC2 instance. Once you have completed this lab step for the bastion instance, repeat the process for the client instance.

In this lab step, you will connect to an EC2 instance using EC2 Instance Connect named bastion and access a shell.
Instructions

In the AWS Management Console search bar, enter EC2, and click the EC2 result under Services:

To see available instances, click Instances in the left-hand menu:

The instances list page will open, and you will see an instance named bastion in the Running state:

If you don't see a running instance then the lab environment is still loading. Wait until the

Instance state is Running

Right-click the bastion instance, and click Connect:

The Connect to your instance form will load.

In the form, ensure the EC2 Instance Connect tab is selected:

You will see the instance's Instance ID and Public IP address displayed.
In the User name textbox, enter ec2-user:

To open a browser-based shell, click Connect:

Accessing Private Instances Using a Bastion Host

In this lab step, you will connect to a private EC2 instance from a bastion host.

Important: Ensure that you have an EC2 Instance Connect session open to both the bastion and client EC2 instances. You will need to switch between these sessions throughout this lab step.

Instructions

In the instance connect window for the bastion EC2 instance, enter the following command to connect to the private instance:

ssh -A ec2-user@10.0.2.40(my instance ips)

Enter yes to the prompt:

The bastion EC2 instance has been configured with the SSH keys needed to connect to the private EC2 instance. The -A flag enables SSH agent forwarding, which allows the bastion EC2 instance to use the SSH keys to connect to the private EC2 instance.

The bastion instance also uses a public IP address, which enables it to be accessed from the internet, and in this case, the EC2 Instance Connect service.

Once a connection is established, you will notice the IP address in the prompt changes to the private IP address of the private EC2 instance:

You can enter exit into the terminal to disconnect from the instance.

You will now attempt to connect to the private EC2 instance from the client EC2 instance.

Switch to the browser tab for the client EC2 instance and enter the following command, then enter yes to the prompt:

aws ec2-instance-connect ssh --instance-id i-0564c1e98b952434d

The client EC2 instance simulates a separate host machine that does not have the SSH keys needed to connect to the private EC2 instance. The aws ec2-instance-connect ssh command attempts to use the EC2 Instance Connect service to establish a connection to the private EC2 instance.

This command is only available in the latest version of the AWS CLI.

The private instance does not have a public IP address, so the connection fails with a There are no available instance connect endpoints. error.

Note: If the error aws: error: argument operation: Invalid choice, valid choices are: send-ssh-public-key appears, ensure that you are accessing the client instance. This error will appear if you are attempting to run the ec2-instance-connect ssh command on the bastion instance.

After you create an endpoint in the next lab step, you will return to this window to attempt a connection again.

We verified that the bastion EC2 instance can connect to the private EC2 instance, but the client EC2 instance cannot.

Creating an Amazon EC2 Instance Connect Endpoint

We will create an Amazon EC2 Instance Connect Endpoint in a VPC and replace the existing bastion host.

Instructions

In the AWS Management Console, in the search bar at the top, enter vpc, and under Services, click the VPC result:

From the VPC dashboard, in the left navigation pane, click Endpoints below Virtual private cloud:

Click Create endpoint:

The Create endpoint wizard will display.
Below Endpoint settings, enter lab-endpoint in the Name tag field:
Select EC2 Instance Connect Endpoint option below Service category:

The form will update with additional options to configure your endpoint.

For the endpoint VPC, select lab-vpc from the dropdown menu:

Client IP preservation allows the endpoint to preserve the IP address of the client when connecting to the instance. This is useful for logging and auditing purposes. Security groups and IAM policies can be configured to allow or deny connections based on the client IP address instead of the endpoint IP address.
Under Security groups, select the endpoint-sg security group:

You can use IAM policies to control which users can connect to instances and security groups to control the traffic that can access the endpoint.

In this example, the endpoint-sg security group allows all outbound traffic to the private-sg security group. The private-sg security group allows inbound traffic from within the VPC CIDR block.

In the Subnet section, select public-subnet from the dropdown menu:

Click Create endpoint:

The endpoint will be created and displayed in the Endpoints list:

It may take up to 5 minutes for the endpoint to become available. The Status will change from Pending to Available when it is ready. After a few minutes, you may need to refresh the page to see the updated status.

We created an Amazon EC2 Instance Connect Endpoint.

Connecting to an Amazon EC2 Instance Connect Endpoint

In this lab step, you will connect to a private instance using an EC2 Instance Connect Endpoint. You will connect to the instance using the EC2 Instance Connect console and the AWS CLI.

Instructions

Return to the EC2 Instances table in the AWS Management Console.

Select the private EC2 instance, then select Connect.

Configure the following connection settings in the EC2 Instance Connect tab:

Connection Type: Select Connect using EC2 Instance Connect Endpoint
EC2 Instance Connect Endpoint: Select the lab-endpoint endpoint from the dropdown menu
Leave the default values of the remaining fields.

The Max tunnel duration field specifies the maximum amount of time that the connection will remain open. The default value is 1 hour. When configuring the IAM policy for the EC2 Instance Connect service, you can apply a condition to only allow connections with a specified maximum duration.

Click Connect:

An instance connect session will open in a new browser tab:

The Last login message at the top of the terminal displays the last connection to the instance, which was from the bastion EC2 instance. Your IP addresses may differ from the example above.

You are now connected to the private instance using the instance connect console.

Return to the client EC2 instance instance connect tab:

Enter the following command to connect to the private instance:

aws ec2-instance-connect ssh --instance-id i-0564c1e98b952434d

The IP address in the prompt changes to the private IP address of the private EC2 instance, indicating that you are connected to the instance.

Summary

By completing this lab, you have:

Configured an Amazon EC2 Instance Connect Endpoint
Accessed a private instance using an EC2 Instance Connect Endpoint
Replaced a bastion host with an EC2 Instance Connect Endpoint

Conclusion
EC2 Instance Connect Endpoint revolutionizes the way we access private EC2 instances. By eliminating the need for public IP addresses, bastion hosts, or agents, it significantly enhances security and simplifies management. This service provides a robust, efficient, and cost-effective solution for securely connecting to your instances. By implementing EC2 Instance Connect Endpoint and adhering to best practices, organizations can strengthen their overall security posture and streamline operations.

Detecting EC2 Threats with Amazon GuardDuty

Wilklins Nyatteng — Tue, 30 Jul 2024 12:35:01 +0000

Amazon GuardDuty continuously monitors and identifies threats by analyzing several types of activity in your AWS account and any invited member accounts that you link to. GuardDuty can notify you of a wide variety of threats including unauthorized access, trojans, communication with Tor anonymizing, or cryptocurrency networks.

GuardDuty uses the following data sources to make its threat findings: VPC Flow Logs, AWS CloudTrail event logs, and DNS logs.

To start using GuardDuty, you must first enable it for your account. You will enable GuardDuty in this lab step. You will enable GuardDuty in a single AWS region. In practice, it is highly recommended that you enable GuardDuty in all supported AWS regions. This allows GuardDuty to generate findings of threats even in regions that you are not actively using.

You will learn how to use Amazon GuardDuty to automatically uncover malicious EC2 activity, and configure threat lists to improve the security of an AWS Lab environment.

Learning Objectives

Upon completion of this lab, we will be able to:

Enable, disable, and suspend Amazon GuardDuty for AWS accounts
Activate threat lists and trusted IP lists, and understand when to use each
Understand the types of security findings GuardDuty can detect
Prioritize and interpret GuardDuty findings in a live environment

You should be familiar with: Core AWS services, particularly EC2, VPC, and S3.

Enabling Amazon GuardDuty
Instructions

In the AWS Management Console search bar, enter GuardDuty, and click the GuardDuty result under Services:

Click Get Started on the welcome page:

Click Enable GuardDuty to have GuardDuty start monitoring your AWS environment:

Enabling GuardDuty automatically creates a service-linked role to allow GuardDuty to gather metadata about EC2 instances in your environment. After you enable GuardDuty, it immediately begins pulling and analyzing streams of data from AWS CloudTrail, VPC Flow Logs, and DNS logs to generate security findings. This all happens automatically behind the scenes. For example, you do not need to create VPC Flow Logs to have GuardDuty monitor network activity in your VPCs.

We have enabled Amazon GuardDuty, so that security findings for your AWS environment can automatically be discovered.

Activating a GuardDuty Threat List

Amazon GuardDuty analyzes its data sources to find potential security threats. You can influence the security findings that GuardDuty reports through trusted IP lists and threat lists. Trusted IP lists whitelist IP addresses from being included in GuardDuty's findings to reduce false positives. Threat lists include known malicious IP addresses. GuardDuty reports additional findings for IP addresses in threat lists.

We will activate a threat list that includes the IP address of an EC2 instance that is part of the Cloud Academy Lab environment. The environment consists of two EC2 instances in different VPCs. The instances are configured to communicate with each other. You will see the findings GuardDuty discovers regarding communicating with malicious instances in a later lab step.
Instructions

Open the EC2 console to view the instances in the Lab environment.

There are two EC2 instances to focus on for this lab: Malicious Instance, and App Server:

I select Malicious Instance and copied its IPv4 Public IP:

The Public IP address is what is needed for GuardDuty's threat list. DNS names and private IP addresses are ignored in threat lists.
Save the IP address in a plain text file named threat-list.txt.

GuardDuty requires a file on Amazon S3 to create a threat list. As an example on Windows, you could use Notepad and the file contents would look similar to the following:

Open the Amazon S3 console

Click on the bucket containing threatlist in the name.
Click Upload to open the S3 upload wizard.
Click Add files and select the threat-list.txt file we created earlier.
Click Upload in the lower-right corner to upload the file with the default S3 file configuration.
Click threat-list.txt to open its details in a new tab, and copy the Object URL in the Object overview panel:

Return to the GuardDuty Console, and select Lists in the left sidebar.

Note: You may already see some Findings in the GuardDuty Console. GuardDuty does not require a threat list to make findings. It will only report additional findings for IP addresses in the threat list.

Click Add a threat IP list to create a threat IP list:

In the Add a threat IP list form, enter the following values and click Add list:

List name: Lab
Location: Paste in the S3 link you copied a few instructions ago
Format: Plaintext (Notice that the drop-down lists other formats that can be used if you have existing threat intelligence services to import threat lists from)
I agree: checked Check the Active checkbox to activate the threat list:

We have activated a threat list in GuardDuty. You began by listing IP addresses in a file. Then you uploaded the file to S3, and created a threat list in GuardDuty. Lastly, you activated the threat list. No new findings related to the threat list will be made unless the threat list is active.

Examining Sample GuardDuty Findings**

To learn about the types of threats that GuardDuty can find, you will generate sample findings in this lab step. The findings are simulated, but allow you to view details and illustrate the three different severity levels in GuardDuty: high, medium, and low. In addition to the sample findings, you can find [descriptions of what each finding relates to in the GuardDuty documentation]

(https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types.html).

Instructions
Click on Settings in the GuardDuty Console sidebar.
You can ignore any error that appears regarding not being authorized to perform IAM requests.
Scroll down to the Sample findings section and click on Generate sample findings:

After a few seconds, a success banner appears:

Click on Findings in the GuardDuty sidebar.
Notice the table is full of various findings that begin with [SAMPLE]:

Read through the different sample findings to see what kind of threats GuardDuty can identify.
Select a few findings and inspect the details panel that appears:

The details are divided into several sections: Summary, Resource affected, Action, Actor, and Additional information.
We have generated and examined sample GuardDuty findings. Although this Lab focuses on EC2 threats, you have also seen in the sample findings that GuardDuty can also identify IAM threats by using CloudTrail logs.

Examining Live Threats in GuardDuty**

Introduction

The EC2 instances in the Cloud Academy lab environment have been communicating with each other since you enabled GuardDuty. The findings related to the instances should appear within 15 minutes. You can read through this lab step without waiting if you prefer. The lab step explains the findings that would eventually appear. If you do wait and no findings are present after 15 minutes ensure the threat IP list is active, The way the two instances communicate with each other is as follows:

The App Server instance simply makes HTTP requests to the Malicious Instance every 15 seconds.
The Malicious Instance sends SSH connection attempts to the App Server instance every 4 seconds. The connection request does not include an SSH key causing the request to always be refused.

The signatures of each of these communication types are recognized by GuardDuty as findings. You will investigate the findings in this lab step.

Instructions

Click on Findings in the GuardDuty Console's sidebar.

Depending on how quickly you arrived at this lab step, you may see the following Finding type row:

Click on the UnauthorizedAccess:EC2/MaliciousIPCaller.Custom finding with a yellow square (medium severity):

This finding indicates outbound TCP communication with an IP address in one of your GuardDuty threat lists. The Threat list name field tells you which list. The medium severity rating is used because it is recommended that you investigate the affected instance at your earliest convenience.

Scroll down the finding details to discover all the details included to help you understand the threat:

For example, in the Resource affected section you can see if the involved instance (the App Server in this case) was in the role of the target or the actor and which port was involved. GuardDuty uses VPC flow logs to make the finding. In previous iterations of GuardDuty a separate SSHBruteForce finding was also reported but it is not treated separately any longer.

Additional Potential Findings

The following findings are not expected to be included in your lab's GuardDuty findings but have been observed when leaving instances open to the Internet for extended periods of time or if an instance is compromised. They can give you additional perspective on what GuardDuty can find.

1. UnauthorizedAccess:EC2/SSHBruteForce (low severity):

The EC2/SSHBruteForce finding indicates an instance was involved in a brute force attack aimed at gaining SSH access using passwords or access keys. In the above image, you can see the description states that an instance is the target of an attack from an IP address. GuardDuty uses VPC flow logs to make this finding. The finding is classified as Low severity meaning that it does not require immediate attention, but is something to address in the future, perhaps by blocking traffic from that IP in your VPC and only allowing SSH access through keys. You can see Location of the attacker's IP address in the Actor section of the finding details.

Note: SSH findings are only reported if SSH is configured on the default port of 22.

Recon:EC2/PortProbeUnprotectedPort (low severity): This finding notifies you that an open port on one of your instances has been probed by known scanners on the internet. The finding is low risk, but you are advised to restrict access to known instances by configuring security groups, access control lists, or host firewalls. The Actor section tells you where the probe originated:

We examined a real EC2 threat finding for the lab environment. You understood the signatures for each finding and actions that can be taken to remedy each.

It is worth noting that GuardDuty findings are event sources in EventBridge. By using EventBridge, it is possible to automatically react to GuardDuty findings.

Disabling Amazon GuardDuty

Amazon GuardDuty incurs costs for analyzing the variety of data sources that it monitors. If you no longer need the proactive threat detection provided by GuardDuty, you can either suspend or disable it to stop accumulating costs. If you disable GuardDuty, any findings that were discovered by GuardDuty will be lost. In practice, you are encouraged to back up any findings you want to preserve before disabling GuardDuty.

In this Lab Step, you will disable GuardDuty because you will not need to preserve any findings or activate GuardDuty later.

Instructions

In the GuardDuty Console, click on Settings in the left sidebar:

Under Disable GuardDuty, click on Disable:

You are presented with the GuardDuty welcome page when the operation is complete.

We disabled GuardDuty to stop accumulating threat analysis costs and to remove any trace of previous findings.
Conclusion
Amazon GuardDuty offers a robust and proactive approach to safeguarding your EC2 instances from a wide range of threats. By continuously monitoring your AWS environment, GuardDuty provides invaluable insights into suspicious activities, enabling you to respond promptly and effectively. Its ability to detect anomalies, unauthorized access, and malicious behaviors is a critical component of a comprehensive security strategy.

Recommendations
To maximize the benefits of Amazon GuardDuty and strengthen your overall security posture, consider the following recommendations:

Develop clear incident response plans to address potential threats identified by GuardDuty. Establish communication channels and roles to ensure efficient coordination.
Combine GuardDuty with other security tools and services to create a layered defense. Utilize tools like AWS Security Hub to centralize and prioritize findings.
Stay informed about emerging threats and vulnerabilities. Incorporate threat intelligence feeds into GuardDuty to enhance detection capabilities.
Continuously review GuardDuty findings and adjust detection filters as needed. This helps optimize the service for your specific environment.
Foster a security-aware culture within your organization. Train users on best practices for handling sensitive information and recognizing potential threats.
GuardDuty is a valuable tool, but it should be part of a broader security strategy. Consider implementing additional safeguards such as strong access controls, network segmentation, and regular vulnerability assessments.

Building with the Cloud: Guide to Becoming an AWS Builder

Wilklins Nyatteng — Tue, 16 Jan 2024 07:49:36 +0000

Introduction
As the cloud computing landscape continues to evolve, professionals and enthusiasts alike seek opportunities to deepen their expertise and contribute to the broader community. One such avenue is the AWS Community Builders Program, a platform designed to bring together AWS enthusiasts, foster collaboration, and amplify the collective knowledge within the Amazon Web Services ecosystem. In this comprehensive technical article, we will delve into the intricacies of the program, covering eligibility criteria, prerequisites, application processes, the diverse categories it encompasses, and the enticing perks that come with being an AWS Community Builder.

What is the AWS Community Builders Program
The AWS Community Builders program offers technical resources, education, and networking opportunities to AWS technical enthusiasts and emerging thought leaders who are passionate about sharing knowledge and connecting with the technical community.

Who Can Apply for the Program?
The AWS Community Builders Program is inclusive and welcomes individuals from various backgrounds and levels of expertise. Whether you are a seasoned cloud architect, a software developer, or a newcomer to the cloud space, if you possess a genuine passion for AWS and a commitment to community engagement, you are a potential candidate for the program. AWS values diversity and actively encourages applicants from different professional and cultural backgrounds.

Prerequisites Needed for the Program
While there are no strict prerequisites for joining the AWS Community Builders Program, having a foundational understanding of AWS services and solutions is beneficial. This understanding could be acquired through professional experience, certifications, or self-directed learning. However, what sets successful applicants apart is not just their technical proficiency but also their enthusiasm for continuous learning, effective communication skills, and a collaborative mindset.

AWS Community Builder Categories
The program is structured around diverse categories to accommodate the varied interests and expertise of its members. These categories include, but are not limited to Containers, Data (databases, analytics, and BI), Developer Tools, Front-End Web and Mobile, Game Tech, Graviton/Arm Development, Cloud Ops, Machine Learning, Network Content & Delivery, Security & Identity, Serverless, and Storage. Each category serves as a thematic hub where community builders can collaborate, share insights, and contribute to the collective knowledge within their specific area of expertise.

Why Should You Join the AWS Community Builders Program?
Networking Opportunities
Being part of the AWS Community Builders Program provides unparalleled networking opportunities. You get to connect with fellow community builders, AWS experts, and industry leaders. Engaging in discussions, attending meetups, and participating in exclusive events organized by AWS foster meaningful connections that can lead to collaborations and knowledge exchange.

Stay Updated on Latest Technologies
AWS is at the forefront of cloud innovation, constantly releasing new services and features. As a community builder, you gain early access to these innovations, allowing you to stay ahead of the curve and contribute valuable insights to the community. This access to cutting-edge technologies enhances your professional development.

Collaboration and Learning
The program encourages a culture of collaboration and continuous learning. By participating in discussions, contributing to open-source projects, and sharing your knowledge through blogs or tutorials, you not only enhance your own understanding but also contribute to the growth of the community. This collaborative environment fosters a sense of shared success among community builders.

How to Get Accepted?
Showcase Your Passion for AWS
Active participation in AWS-related discussions is crucial. Engage in forums, social media, and other community platforms to showcase your passion for AWS. Share your experiences, answer queries, and contribute to discussions. This not only demonstrates your expertise but also highlights your commitment to the community.

Contribute to Open-Source Projects
Contributing to open-source projects related to AWS is a powerful way to demonstrate your skills and commitment. Whether it's fixing bugs, adding features, or creating new projects, your contributions become tangible evidence of your dedication to advancing the AWS ecosystem.

Share Your Expertise
Demonstrate your expertise by creating and sharing content. This could be in the form of blog posts, tutorials, or even speaking at local meetups or conferences. Your ability to articulate complex concepts in a clear and concise manner enhances your credibility within the community.

Engage with the Community
Building relationships within the AWS community is key. Engage with other community builders, attend events, and actively participate in community initiatives. Being an active member showcases your dedication to the community's growth and success.

How to Apply?
The application process for the AWS Community Builders Program is typically conducted online. The application form will require you to provide details about your AWS experience, contributions to the community, and reasons for wanting to join the program. Here are some key steps to consider when applying:

Detail Your AWS Experience
Provide a comprehensive overview of your experience with AWS. This includes any certifications you may have, professional projects you've worked on, and any notable achievements related to AWS.

Highlight Community Contributions
Emphasize your contributions to the AWS community. This could include participation in forums, open-source projects, blog posts, or any other initiatives that showcase your commitment to community engagement.

Articulate Your Motivation
Clearly express why you want to be part of the AWS Community Builders Program. Whether it's for personal development, a desire to contribute to the community, or a specific goal you aim to achieve, articulate your motivations effectively.

Showcase Your Diversity
If applicable, highlight any unique perspectives, experiences, or skills you bring to the community. AWS values diversity and encourages individuals from different backgrounds to contribute to the program.

Perks of Being an AWS Community Builder

Joining the AWS Community Builders Program comes with a host of perks that go beyond the satisfaction of contributing to the community. These perks include:

Exclusive Access to AWS Experts
As a community builder, you gain exclusive access to AWS experts. This access opens up opportunities for mentorship, one-on-one discussions, and valuable insights directly from the minds behind AWS services. Exclusive talks where they teach you how to generate content and share their experiences.

Early Access to Features
Being on the forefront of AWS innovation, community builders often receive early access to upcoming features and services. This not only allows you to explore and experiment with new technologies but also positions you as an early adopter within the community.

Opportunities for Collaboration
The program facilitates collaboration between community builders. Whether it's co-authoring blog posts, working on open-source projects, or organizing events, the collaborative environment fosters collective growth and success. 50% discount for AWS re:Invent ticket and All Builders Welcome Grant program.

Recognition and Visibility
As an AWS Community Builder, you gain visibility within the AWS ecosystem. This recognition can lead to speaking opportunities at AWS events, workshops, and other avenues to showcase your expertise to a broader audience.

AWS Swags
In addition to the intangible benefits, AWS Community Builders are often rewarded with exclusive swag. These can include custom t-shirts, stickers, and other merchandise that serve as a tangible representation of your involvement in the program. There is also $500 AWS Credits for your practice and development, 1-year access to Cloud Academy and one free AWS certification exam voucher per year.

Conclusion
An hour in the trenches of the AWS Community Builders Program is not just an investment in your technical skills but a commitment to a thriving community. By actively participating, contributing, and collaborating, you not only advance your own expertise but also play a pivotal role in shaping the future of the AWS ecosystem. Joining the program is not merely an individual achievement; it is a step towards collective growth, learning, and success within the dynamic realm of cloud computing.

Amazon Q: Your AI Work BFF Debuts at Re:Invent 2023

Wilklins Nyatteng — Mon, 04 Dec 2023 05:46:16 +0000

Las Vegas. November. A sea of techies, fueled by cold brew and ambition, floods the halls of Re:Invent – the annual cloud computing extravaganza hosted by Amazon Web Services. This year, amidst the mind-bending demos and visionary keynotes, a single announcement stole the show: Amazon Q, an AI work assistant so revolutionary it'll make your current to-do list cry in a corner.

Imagine a work bestie who's not just good at coffee runs and pep talks, but a machine-learning marvel that answers any question you throw its way, writes code faster than your keyboard can handle, and even untangles your thorniest tech woes. That's the magic of Q. It's not just Google on steroids, it's your personal knowledge Sherpa, diving deep into your company's data lakes, code repositories, and even enterprise systems to surface the exact insights you need to crush your workday.

Forget drowning in documentation or spamming colleagues for help. Q speaks your language, even if your question sounds like it was written by a particularly creative toddler. Ask it anything, from "What's the global impact of a 10% price hike on our unicorn onesie line?" to "Write me some Python code to automate this soul-sucking report." Q doesn't bat an eye, it just delivers.

But Q is more than just an answer machine. It's your problem-solving superhero. Stuck on a bug that's turning your hair prematurely gray? Q can debug it faster than you can say "Stack Overflow." Need to optimize your cloud infrastructure and make your CFO do a happy dance? Q can analyze your data like a financial Sherlock Holmes and suggest tweaks that'll have your costs singing like Beyoncé. Feeling creatively bankrupt, staring at a blank document like a deer in headlights? Q can brainstorm ideas so brilliant they'll make your marketing team green with envy and your next client presentation the stuff of Silicon Valley legend.

And the best part? Q is your personal AI apprentice. Train it to understand your company's lingo, inside jokes, and even your boss's signature brand of motivational (but slightly awkward) pep talks. Want Q to answer questions with your CEO's dry wit and penchant for inspirational quotes? No problem. Need it to decipher the cryptic engineering acronyms your team throws around like confetti? Easy peasy. Q becomes an extension of your tribe, seamlessly integrating into your existing work environment like a long-lost, super-smart sibling.

But the real game-changer? How Q turbocharges collaboration. Imagine a world where everyone has instant access to your organization's collective brainpower. Q breaks down silos like a digital wrecking ball, fostering information sharing that sparks cross-team innovation like fireworks on the Fourth of July. Suddenly, that marketing whiz can tap into the wisdom of your seasoned engineers to craft campaigns that resonate like a Taylor Swift ballad. Your sales team can close deals based on real-time customer insights gleaned from Q's data analysis. And your designers? They can collaborate with engineers in real-time, sketching prototypes and building masterpieces like a digital Michelangelo and Da Vinci tag team.

Amazon Q is still young, but its potential is bigger than the metaverse and bolder than Elon Musk's Twitter rants. It's not just about replacing your Google searches; it's about redefining how we work. Q empowers us to be more efficient, more creative, and ultimately, more human. So, ditch the endless to-do lists and knowledge-hunting expeditions. With Q by your side, you can finally focus on what you do best: bringing your A-game to work every single day.

So, the next time you feel like your work is a bottomless pit of despair, remember: you're not alone. Q is here, ready to be your AI work BFF, your problem-solving sensei, and your secret weapon for success. Now, who's ready to conquer their to-do list and make Re:Invent 2024 look like a kindergarten finger-painting session?

Let's face it, we all need a little AI magic in our lives. And Q? It's just the spell we've been waiting for.

Securing Your Applications on AWS: Guide to Data Privacy and Protection

Wilklins Nyatteng — Mon, 27 Nov 2023 07:28:57 +0000

In today's data-driven world, businesses are increasingly entrusting sensitive information to cloud platforms like Amazon Web Services (AWS). While AWS offers a robust infrastructure and a multitude of security services, it's crucial for organizations to understand their shared responsibility model and implement appropriate security measures to protect their applications and data.

Understanding Your Role
Imagine you're storing your valuables in a bank. The bank is responsible for securing the building, the vaults, and the overall security infrastructure. However, you, as the owner of the valuables, are still responsible for protecting your specific belongings – your jewelry, cash, and important documents.

In the cloud computing world, Amazon Web Services (AWS) is like the bank. They provide the secure infrastructure, the servers, and the network. But you, as the customer, are still responsible for protecting your applications, data, and the cloud resources you use.

Foundational Security Principles
To effectively secure applications on AWS, it's essential to adhere to fundamental security principles:

Implement robust IAM policies to control user access and permissions, ensuring only authorized individuals have access to sensitive resources.
Grant users the minimum level of access necessary for their roles, minimizing the potential impact of compromised credentials.
Encrypt data at rest and in transit using industry-standard algorithms and encryption keys managed securely by AWS Key Management Service (KMS).
Utilize AWS network security services like VPCs, security groups, and network firewalls to restrict network traffic and protect against unauthorized access.
Regularly scan applications and systems for vulnerabilities and promptly apply patches to address security weaknesses.
Implement continuous monitoring and logging to detect suspicious activity, identify potential threats, and facilitate incident response.

Protecting Your Code
Application security is paramount in protecting against vulnerabilities that could expose sensitive data or compromise system integrity. Employ secure coding practices, conduct thorough code reviews, and implement Web Application Firewalls (WAFs) to filter and block malicious traffic

Safeguarding Sensitive Information
Data privacy is a critical aspect of securing applications on AWS. Implement data masking and anonymization techniques to protect sensitive data during testing and development. Establish data governance policies to manage data access and usage. Comply with applicable data privacy regulations, such as the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA).

Utilizing AWS's Security Arsenal
AWS provides a comprehensive suite of security services to enhance application security and data privacy. Leverage services like AWS CloudTrail to audit API activity, AWS CloudWatch to monitor resource utilization and security events, and AWS CloudFormation to deploy secure infrastructure configurations.

Continuous Security - An Ongoing Process
Security is not a one-time endeavor; it's an ongoing process that requires continuous vigilance and adaptation. Regularly review and update security policies, train employees on security awareness, and conduct periodic security audits to identify and address potential vulnerabilities.

Conclusion
In essence, the comprehensive security measures outlined in this article create a multi-layered defense, transforming your AWS-hosted application into an impregnable fortress. The journey doesn't end here; it's an ongoing commitment to staying ahead of emerging threats, adapting to new challenges, and continually reinforcing the castle walls. By embracing these security principles, you not only protect your application but also contribute to the overall resilience of the digital realm in the face of an ever-evolving cybersecurity landscape.

Securing AWS Environments Against Ransomware

Wilklins Nyatteng — Thu, 23 Nov 2023 07:58:47 +0000

In today's increasingly interconnected world, organizations are turning to cloud platforms like Amazon Web Services (AWS) for their critical data and applications. This shift to the cloud has also introduced new security challenges, including the ever-present threat of ransomware. Ransomware is a type of malware that encrypts a victim's files, making them inaccessible until a ransom is paid. In recent years, ransomware attacks have become more sophisticated and costly, with businesses often facing significant financial losses and reputational damage.

Before delving into specific mitigation strategies, it's crucial to understand AWS's shared responsibility model. AWS is responsible for securing the underlying cloud infrastructure, while customers are responsible for securing their own applications and data running on the platform. This shared responsibility model highlights the importance of implementing comprehensive security measures at both the AWS infrastructure level and the application level.

Common AWS Vulnerabilities Exploited by Ransomware Attacks

Ransomware attackers often exploit specific vulnerabilities in AWS environments to gain access and execute their malicious code. Some of the most common AWS vulnerabilities targeted by ransomware include:

Excessive permissions granted to IAM users or roles can provide attackers with unauthorized access to critical resources.
Publicly accessible S3 buckets can serve as a staging ground for attackers to store and execute malicious code.
Weak passwords and insufficient access controls can make it easier for attackers to compromise user accounts and gain access to sensitive data.
Outdated software running on AWS instances can contain vulnerabilities that attackers can exploit to gain access and execute their payloads.
Inadequate network security controls, such as firewall misconfigurations, can allow attackers to penetrate the AWS environment and spread malware.

Mitigation Strategies to Harden AWS Environments Against Ransomware

To effectively protect against ransomware attacks, organizations should implement a multi-layered approach that encompasses both preventive and reactive measures. Some key mitigation strategies are:

Grant IAM users and roles the minimum permissions necessary to perform their tasks. Regularly review and revoke unused or excessive permissions.
Encrypt all S3 buckets, both at rest and in transit, to protect sensitive data from unauthorized access.
Implement strong password policies that require complex passwords and regular password changes. Consider using multi-factor authentication (MFA) for added security.
Implement a vulnerability management program to identify and patch software vulnerabilities promptly. Use automated patching tools to streamline the process.
Implement network security controls, such as firewalls and intrusion detection systems, to monitor network traffic and block malicious activity.
Regularly back up critical data to a secure location separate from the production environment. Establish a recovery plan to restore data in the event of a ransomware attack.
Perform regular security assessments to identify and remediate vulnerabilities in the AWS environment.

In addition to the aforementioned mitigation strategies, you should also consider:

Providing regular security awareness training to educate employees about ransomware risks and phishing tactics.
Implementing a security incident response plan: Establish a detailed security incident response plan to effectively respond to ransomware attacks and minimize downtime.
Leveraging AWS security services, such as Amazon GuardDuty and Amazon Inspector, to monitor and protect your AWS environment from potential threats.

Conclusion

Securing AWS environments against ransomware requires a comprehensive approach that combines preventive measures, reactive strategies, and continuous monitoring. By implementing the mitigation strategies outlined in this blog and staying vigilant about emerging threats, organizations can significantly reduce their risk of falling victim to ransomware attacks. Remember, security is an ongoing process, not a one-time event. Regularly evaluate and update your security posture to stay ahead of the ever-evolving threat landscape.

Generative AI Security: What It Means for AWS Security

Wilklins Nyatteng — Sun, 12 Nov 2023 12:49:38 +0000

Generative AI is a type of artificial intelligence that can create new content, such as text, code, or images. It's like a creative writing machine, but instead of writing stories, it can write code, generate fake news, or even create deepfakes (videos or audio recordings that have been manipulated to make it look or sound like someone is saying or doing something they never actually said or did).

Generative AI has the potential to be used for a lot of good, like creating new products and services, improving customer experiences, and automating tasks. But it can also be used for a lot of bad, like creating fake news, spam, malware, and deepfakes.

So, what does generative AI security have to do with AWS Security? Well, AWS is a cloud computing platform that provides a variety of services that can be used to build and deploy generative AI applications. So, it's important for AWS users to be aware of the potential security risks associated with generative AI and to take steps to mitigate those risks.

Here are a few of the top generative AI security risks that AWS users need to be aware of:

Misinformation and disinformation: Generative AI can be used to create fake news articles, social media posts, and other types of content that can be used to mislead people and spread disinformation.
Malware: It can be used to create new types of malware that are more difficult to detect and defend against.
Phishing attacks:Creating phishing emails and text messages that are more likely to fool people.
Deepfakes: Generative AI can be used to create deepfakes that can be used to damage reputations, blackmail people, or even interfere with elections.

AWS Security provides a variety of services and tools that can be used to mitigate the risks associated with generative AI. These services and tools include:

Amazon GuardDuty: This is a threat detection service that uses machine learning to analyze your AWS account for malicious activity. GuardDuty can identify suspicious activity related to generative AI workloads, such as the generation of large volumes of text or code, or the use of unusual APIs.
Amazon Macie: It is a data classification and security service that uses machine learning to identify sensitive data in your AWS account. Macie can identify sensitive data that has been generated by generative AI models, such as personally identifiable information (PII) and financial data.
Amazon Inspector: Inspector is a security assessment service that uses machine learning to identify vulnerabilities in your AWS applications. Inspector can identify vulnerabilities in generative AI applications, such as insecure code and misconfigurations.

In addition to these services and tools, AWS Security also provides a number of best practices for securing generative AI workloads. These best practices include:

Use a secure development lifecycle (SDLC) to develop and deploy your generative AI applications. This includes implementing security controls at all stages of the SDLC, from requirements gathering to deployment.
Use a least privilege approach to grant access to generative AI resources. This means only granting users the access they need to perform their job duties.
Monitor your generative AI workloads for suspicious activity. This includes monitoring the volume of traffic to and from your generative AI applications, as well as the types of content that are being generated.
Implement security controls to prevent the misuse of generative AI outputs. This includes preventing generative AI models from generating sensitive data or malicious content.

To sum it up, generative AI is like a double-edged sword, offering incredible possibilities and lurking security challenges. AWS Security steps in as the knight in shining armor, providing the tools needed to defend against the dark side of AI.

Now, speaking of generative AI, here's a little joke for you: Why did the generative AI apply for a job as a stand-up comedian? Because it was great at creating "byte"-sized humor!