DEV Community: Lahiru Hewawasam

I must say that AWS has brought out some really interesting features and announcements in April. Let's take a look at some of the announcements that made my top pick.

1. AWS Config
AWS Config has added support for 35 new resource types within its advanced queries. This brings in the versatility of being able to search the current configuration state of AWS resources either in a single account, region, or even AWS Config aggregator.

Here are some of the newly supported resource types, But take a look at the AWS release notes for the complete list.

AWS::Cognito::UserPoolClient
AWS::Cognito::UserPoolGroup
AWS::Connect::Instance
AWS::Connect::QuickConnect
AWS::EC2::CarrierGateway
AWS::EC2::IPAMPool
AWS::EC2::NetworkInsightsAccessScope
AWS::EC2::NetworkInsightsPath
AWS::EC2::TransitGatewayConnect
AWS::EC2::TransitGatewayMulticastDomain
AWS::ECS::CapacityProvider

2. Amazon Inspector
AWS now lets customers run vulnerability assessments on EC2 instances that do not have the Amazon Inspector agent installed. With the introduction of the agentless vulnerability assessments for Amazon EC2, Amazon Inspector takes a snapshot of the EBS volumes to collect the software inventory where Amazon Inspector will start looking for any known software vulnerabilities.

If you already have the SSM agent installed on your EC2 instances, then Amazon Inspector uses the agent for scanning.

3. AWS Firewall Manager
AWS Firewall Manager enabled customers to manage various policies such as WAF, Shield, and security groups. With this latest update, AWS Firewall Manager now allows customers to manage VPC NACLs with common NACL policies.

This brings an exciting opportunity for customers to implement baselines for protecting their resources such as pre-defined block rules that block certain traffic across multiple accounts. It also enables customers to centrally manage and apply these policies across multiple accounts.

Now customers can also enforce NACLs by configuring automatic remediation to revert unintended or unwanted changes and maintain compliance with the security posture baselines set by the organization.

Wrapping Up

It's truly intriguing to see the innovations and updates set in motion by the team at AWS.

Within this article, I've highlighted some of the major service announcements and feature introductions that were noteworthy. There may have been some announcements that I didn't cover in this month's announcement, therefore feel free to mention what you think was important in the comment section.

Stay Tuned for the next edition of "What's New With AWS Security"!

Thank you for reading. I hope you found this useful.

What's New With AWS Security? | March Edition

Lahiru Hewawasam — Tue, 07 May 2024 17:04:21 +0000

Introduction

It's been a while since I've gotten into the latest and greatest releases for AWS security (It's better late than never).

Feel free to check out the previous articles within this series to get yourself updated on what AWS has been up to in terms of security.

Series: What's New With AWS Security?

Let's get stuck into what happened in the month of March!

What's New With AWS Security Now?

Let's take a look at the latest additions to the AWS security services.

Announcement Date: 03/04/2024

AWS WAF enhances rate-based rules to support configurable time windows

Announcement Date: 03/06/2024

Amazon GuardDuty is now available in AWS Canada West (Calgary) Region

Announcement Date: 03/07/2024

AWS X-Ray now supports data events in AWS CloudTrail

Announcement Date: 03/08/2024

Announcement Date: 03/11/2024

Amazon Verified Permissions increases default quotas for authorization APIs

Announcement Date: 03/12/2024

AWS Backup now supports restore testing for Amazon Elastic Block Store (EBS) Snapshots Archive

Announcement Date: 03/14/2024

Amazon Cognito is now available in Europe (Zurich) Region

Announcement Date: 03/18/2024

Announcement Date: 03/25/2024

IAM Roles Anywhere now offers credentials that are valid for up to 12 hours

Announcement Date: 03/29/2024

Amazon GuardDuty EC2 Runtime Monitoring is now generally available

Noteworthy Updates To Services

Let's take a look at some of the announcements that caught my eye!

1. AWS Secrets Manager
AWS Secrets Manager now supports user credential rotation for Amazon Redshift Serverless. Now you can easily create and rotate user credentials and API keys throughout their lifecycle.

These new integrations bring the total count of the AWS Secrets Manager supported services to more than 50!

2. Amazon GuardDuty
Amazon GuardDuty now lets customers monitor and gain visibility into the on-host, operating system–level activities and provides container-level context of detected threats.

This enhances the existing capabilities of GuardDuty which can help detect abnormal and suspicious activities within your AWS accounts and workloads.

Wrapping Up

There have been some major strides taken by the team at AWS to enhance and stay on top of the security game and I can't wait for what is in store for us in the future.

Stay Tuned for the next edition of "What's New With AWS Security"!

Thank you for reading. I hope you found this useful.

What's New With AWS Security? | February Edition

Lahiru Hewawasam — Sat, 09 Mar 2024 03:30:00 +0000

It's that time of the month where we go through the latest and greatest updates to AWS security services.

Feel free to check out the previous articles within this series to get yourself updated on what AWS has been up to in terms of security.

Series: What's New With AWS Security?

What's New With AWS Security Now?

It's not everyday that you get to hear something being updated on AWS security services and it was a case where AWS only announced a handful of updates to its services.

Let's take a look at the latest additions to the AWS security services.

Announcement Date: 01/02/2024

Amazon Cognito adds signing, encryption, and Identity Provider-initiated SSO for SAML federation

Announcement Date: 06/02/2024

AWS WAF announces Captcha improvements

Announcement Date: 09/02/2024

Announcement Date: 13/02/2024

Amazon GuardDuty Runtime Monitoring protects clusters running in shared VPC

Announcement Date: 23/02/2024

Remediating non-compliant resources with AWS Config rules is now available in Canada West (Calgary)

Announcement Date: 29/02/2024

Noteworthy Updates To Services

Like always some of these announcements stood out of the rest of the list, so let's take a look at them!

1. Amazon Cognito

Amazon Cognito now comes with 3 brand new features that SAML federation:

1. IdP-Initiated Login
2. Encrypted SAML assertion/response
3. Signed SAML requests

This video talks in-depth about these new features and how you can also start using it today!

2. Amazon GuardDuty

Now you can run on-demand malware scans on EBS volumes attached to EC2 instances and container workloads that are encrypted by EBS managed keys!

Findings may include information such as Threat, File Name, File Path, EC2 instance ID, Container ID and Container Image used

Amazon GuardDuty Runtime Monitoring can now detect threats running in all supported compute services running in a shared VPC.

3. AWS WAF

AWS WAF introduced support for 8 additional languages within the audio captcha; Newly added languages include Spanish, German, French, Portuguese, Italian, Turkish, Dutch, and Arabic.

The service also introduced a new form of captcha puzzle called Grid Captcha. This improves user pass through rates thus improving the overall user experience.

Admins can now deactivate or rotate any captcha API keys if they suspect any suspicious activity before they can be misused.

Wrapping Up

I must say that the month of February brought some good improvements into the AWS security services arsenal that's definitely going to help organizations stay on top of their security game!

Within this article I've highlighted some of the major service announcements and feature introductions that were noteworthy. There may have been some announcements that I didn't cover in this month's announcement, therefore feel free to mention what you think was important in the comment section.

Stay Tuned for the next edition of "What's New With AWS Security"!

Thank you for reading. I hope you found this useful.

What's New With AWS Security? | January Edition

Lahiru Hewawasam — Thu, 08 Feb 2024 14:51:45 +0000

We're back with the third installment of the series where I walk you through the latest and greatest updates to AWS security services!

Feel free to check out the previous articles within this series to get yourself updated on what AWS has been up to in terms of security.

Series: What's New With AWS Security?

What's New With AWS Security Now?

If you thought December was a silent month for AWS security announcements, then you're not in for a treat cause January didn't see a lot of updates.

However, this being said I am excited for some of the updates that AWS has released since these are some features that I've been eagerly waiting for.

Let's check out the latest additions to the AWS security services.

Announcement Date: 03/01/2024

Amazon Cognito identity pools enhances quota management in AWS Service Quotas

Announcement Date: 04/01/2024

Introducing simplified WordPress setup on Amazon Lightsail

Announcement Date: 10/01/2024

Amazon Route 53 Resolver DNS Firewall now supports query type filtering

Announcement Date: 16/01/2024

AWS Private CA now helps issue ISO/IEC mobile driver’s license certificates

Announcement Date: 18/01/2024

AWS IAM Identity Center is now available in the Middle East (UAE) AWS Region

Announcement Date: 23/01/2024

Amazon Inspector now supports CIS Benchmark assessments for operating systems in EC2 instances

Announcement Date: 24/01/2024

AWS Payment Cryptography launches additional options for importing and exporting keys

Announcement Date: 25/01/2024

Noteworthy Updates To Services

1. Amazon Route 53 Resolver DNS Firewall

With this new release, the DNS firewall supports blocking based on the DNS query type
For example, you can now choose to block outbound queries to TXT records since this is a common approach used for DNS tunneling-based attacks

2. Amazon Inspector

CIS benchmarks are now supported on Amazon EC2 operating systems
This release allows you to benchmark your EC2s against the CIS benchmark without the need for additional third-party services

Wrapping Up

This is probably the shortest installment of the What's New with AWS Security series since there aren't a lot of noteworthy updates coming out in January.

I've highlighted some of the major service announcements and feature introductions that were noteworthy. There may have been some announcements that I didn't cover in this month's announcement, therefore feel free to mention what you think was important in the comment section.

Stay Tuned for the next edition of "What's New With AWS Security"!

Thank you for reading. I hope you found this useful.

What's New With AWS Security? | December Edition

Lahiru Hewawasam — Wed, 03 Jan 2024 05:00:00 +0000

Welcome back to my series where I take you through the latest and greatest updates for AWS security services!

AWS re:Invent 2023

If you haven't been living under a rock for November, you would have probably known that AWS had AWS re:Invent where they unveiled a bunch of new services and functions for all of their users.

It's no surprise that this time the theme was focused predominantly on artificial intelligence, with the folks over at AWS flexing their muscles by showing off what they've come up with and it's safe to say it was a treat with a lot of focus directed at Amazon Q; their latest take on a generative AI assistant that enables users to get faster and accurate answers that are tailored to their businesses.

If you're thinking how that is even possible, then let me give you the short answer. It's all because of its connectors that allow Amazon Q to learn about your business to give customized answers.

Click on the links below to learn more about the services and features announced during this year's re:Invent or to see if you've missed out on some awesome announcements.

What's New With AWS Security Now?

Let's put a pin on the re:Invent talks and dive right into why we're here! and that's to check out what happened in December and all the cool additions that AWS made to their security services!

I must say December was a very quiet month in terms of releases for security services since most of the releases came with re:Invent and within November; which I covered within the November Edition of this series.

So without further ado, let's check out the latest additions to the AWS security services.

Announcement Date: 05/12/2023

AWS Secrets Manager announces 99.99% Service Level Agreement

Announcement Date: 18/12/2023

Announcement Date: 19/12/2023

Announcement Date: 20/12/2023

Announcement Date: 21/12/2023

Announcement Date: 26/12/2023

Announcement Date: 28/12/2023

Noteworthy Updates To Services

1. AWS Secrets Manager

AWS Secrets Manager now maintains an SLA of at least 99.99%; which equates to 52.60 minutes per year or 13.15 minutes per quarter
If these SLAs are not met, you are eligible for service credits according to the AWS Secrets Manager SLA

2. AWS Security Hub

The service also supports additional services such as Amazon FSx and AWS Private CA, while introducing new controls for previously supported services such as Amazon EC2, Amazon EKS, and Amazon S3.
AWS Security Hub introduced 15 new security controls that it can evaluate. You simply need to enable to respective security standard that they belong to and AWS Security Hub will start evaluating them automatically.
If you have already enabled the relevant standard, then AWS Security Hub will automatically evaluate these new controls
List of new security controls:

3. Amazon EKS

You can now use EC2 security groups with Amazon EKS in clusters that use IPv6
Previously administrators were constrained to the limits of IPv6, but NO MORE!
Now you can use Amazon VPC CNI network policies to control the traffic within your cluster and use security groups to control access to AWS services outside the cluster.

Wrapping Up

Stay Tuned for the next edition of "What's New With AWS Security"!

Thank you for reading. I hope you found this useful.

What's New With AWS Security? | November Edition

Lahiru Hewawasam — Mon, 04 Dec 2023 20:42:22 +0000

If you're also like me, then you must have also had a tough time understanding and keeping up with all the new services and updates that AWS provides for its security services.

I am going to be starting this first edition of a series that will focus on consolidating the most important and noteworthy updates in the realm of AWS security so that you have a single place to keep yourself up-to-date.

Without further ado, let's get stuck right into this month's noteworthy updates and releases on AWS security.

Announcement Date: 02/11/2023

Announcement Date: 09/11/2023

Amazon GuardDuty introduces new machine learning capability to enhance threat detection for Amazon EKS detections

Announcement Date: 10/11/2023

Amazon CloudFront announces unified security dashboard

Announcement Date: 14/11/2023

Announcing new dashboards in AWS Web Application Firewall

Announcement Date: 15/11/2023

Announcement Date: 16/11/2023

Announcement Date: 17/11/2023

Announcement Date: 20/11/2023

Announcement Date: 21/11/2023

Amazon Verified Permissions now provides an enhanced visual mode for schema editing

Announcement Date: 26/11/2023

Noteworthy Updates To Services:

1. AWS IAM

AWS IAM now provides last accessed information more an additional 60 services!
AWS IAM expands its policy generation to identify actions of over 200 AWS services!

2. AWS Security Hub

Customize certain specifics such as password policies, retention frequencies and other attributes without abandoning the use of managed controls
Setup delegated administrators for all regions at once and configure CSPM capabilities such as standards and controls on all or some accounts globally without needing to configure them on an account or region basis
Custom dashboard and widget capabilities
New data enrichment adds resource tag, a new application tag, and account name tag into every finding ingested into Security Hub for findings from services such as Amazon GuardDuty, Amazon Inspector, and AWS IAM Access Analyzer.

3. Amazon Inspector

Amazon Inspector enables generative AI powered remediation for findings with automated reasoning
Amazon Inspector now integrates with Jenkins and TeamCity for container image assessments. Once activated Amazon Inspector monitors your environment for known vulnerabilities within EC2 instances, container images in Amazon Elastic Container Registry, CI/CD tools and Lambda functions.
Enable Amazon Inspector hybrid scan mode for agentless vulnerability assessments on your EC2 instances (Preview Feature)

4. Amazon Detective

Group summaries with the use of generative AI to automatically analyze and provide insights into findings in natural language
Amazon Detective integrates with Amazon Security Lake to enable querying and log retrieval from Security Lake. This helps you get additional information from AWS CloudTrails and Amazon VPC Flow logs within the security lake when conducting investigations within Amazon Detective
Automatically investigate AWS IAM entities for IOCs
Amazon Detective now provides enhanced visualization and additional context for Amazon GuardDuty Elastic Container Service Runtime Monitoring findings

5. Amazon GuardDuty

Amazon GuardDuty Introduces new machine learning capabilities to detect threats within Amazon Kubernetes Service clusters
Amazon GuardDuty now supports Amazon Elastic Container Service workloads including AWS Fargate
Amazon GuardDuty now supports runtime monitoring for EC2 workloads while giving visibility into operating system-level activities and container-level context into threats that are detected (Preview Feature)

Wrapping Up

Stay Tuned for the next edition of "What's New With AWS Security?"!

Thank you for reading. I hope you found this useful.

AWS Incident Response: How To Contain An EC2 Instance?

Lahiru Hewawasam — Mon, 31 Oct 2022 16:10:53 +0000

Introduction

In a world where it is a matter of "when" an incident would take place, all organizations must keep a well-thought-out plan to act upon identifying an incident that would possibly cause monetary damage as well as damage to the organization's image.

The humble EC2 instance provided by AWS has quickly become one of AWS's most sought compute services. However, with its wide use, it is equally essential to ensure that administrators know the correct steps to minimize the damage when responding to an EC2 instance.

What Is Incident Response?

Incident response is a structured approach that allows organizations to prepare, detect and respond to security incidents promptly while reducing the impact these incidents may have on the organization.

Understanding and implementing the measures to accommodate for incident response allows organizations to have documented procedures and adequate technical controls to conduct investigations and contain the infection without allowing it to spread across the organizations.

An Incident Response Plan is at the heart of any well-organized incident response as it documents the organization's procedures and responsibilities of each member within the incident response team.

AWS Shared Responsibility Model

Most organizations using cloud infrastructure has a fundamental misconception that security and maintenance become the responsibility of a cloud service provider such as AWS.

However, this is not true since AWS marks the responsibility boundaries of the different components that AWS and the customer are responsible for within its shared responsibility model.

Understanding the shared responsibility model is crucial to determine the controls and responsibilities that need to be undertaken by the customer/user to manage, secure and maintain the cloud services effectively.

Reference: https://aws.amazon.com/compliance/shared-responsibility-model/

According to the AWS shared responsibility model, it is the responsibility of AWS to provide and maintain the following components:

Hardware and infrastructure running the global AWS services
Software that facilitates the compute, storage, database and networking of the global AWS services

Within the constraints of the AWS EC2 service, the shared responsibility model states that it is the responsibility of the customer/user to configure and maintain the following components:

Encryption of traffic and data
Operating system, network and any firewall-related configurations
Applications and IAM
Data hosted on AWS and EC2 instances

It also means that incident response and other security measures related to the operating system or any instance created on AWS must be provided and maintained by the customer.

Incident Response Lifecycle

The NIST incident handling guide highlights the stages that must be looked at during an incident response. These stages entail the different steps necessary to protect resources from attackers and respond to an incident when a resource is compromised.

The typical incident response lifecycle contains the following stages:

Planning
Detection
Analysis
Containment
Eradication
Recovery

Each stage holds a vital function within the incident response lifecycle, ensuring that an organization can best prepare for an incident.

Stage 01: Planning

This stage of the incident response lifecycle associates the necessary planning of documentation and other technical controls.

One of the most critical documents covered during this phase is the incident response playbooks; these playbooks have step-by-step guides and responsibilities mapped out for the entire incident response team. This structured approach ensures that incident response teams are aware of their responsibilities and the approach is taken to respond to a specific type of incident such as malware infection, C2C communication, etc.

This stage will also cover the planning of the necessary technical control to support the protection and incident response of the resources within an organization.

Stage 02 - 03: Detection & Analysis

Detection of malicious activities within the AWS infrastructure could vary depending on the type of monitoring required.

A popular method of monitoring malicious activity within an EC2 instance is using a third-party EDR or XDR solution. However, this requires a separate license and other requirements set by the product manufacturer.

Another popular method of gaining detailed insight into the AWS infrastructure and EC2 instances is a SIEM (Security Information and Event Management) solution that allows collecting and correlating multiple log sources to detect anomalies within the AWS resources.

AWS also provides native solutions such as Amazon GuardDuty and Amazon Inspector to detect and respond to threats effectively by allowing automated responses.

Stage 04: Containment

Containment aims to limit the reachability of an infected resource so that it may not cause any further harm to any other resource within the AWS infrastructure.

In this case, isolating an EC2 instance would provide adequate time for the incident response team to analyze and determine the scope of the infection. It also allows forensic investigators to conduct forensic analysis to determine more detailed information required during the later stages of the incident response lifecycle.

The first approach that most users may take when isolating an EC2 instance is to restrict the network connectivity originating to and from the infected EC2 instance; this ensures that the attackers cannot maintain any existing backdoor communications or establish any further connections. It also ensures that no user or application has access to the infected EC2 instance that could taint any evidence within the EC2 instance or allow it to infect other resources within the AWS infrastructure further.

This article focuses on exploring the different approaches to isolating an EC2 instance.

How to contain an EC2 instance?

Users can use multiple approaches when isolating an EC2 instance. The approach used will depend on the level of isolation required.

The most common methods of isolation are:

Security Groups
NACLs
Route Tables
Internet Gateways

Containing an EC2 Using Security Groups

Security groups are often the most common approach when isolating an EC2 instance due to their ease of use and targeting isolation capabilities.

A security group's default "implicit deny" behaviour makes it a suitable isolation method since a security group without rules will deny all traffic; a security group requires a user to specify rules to allow specific traffic.

However, it is essential to note that adding a security group to an EC2 instance will not restrict traffic, and AWS will grant access to the security group with the most permissive rules.

Therefore to restrict access by using a security group, users must remove all existing security groups from an EC2 instance or remove all the rules from the existing security group.

When using security groups for isolation, it is crucial to consider the connections an EC2 instance may establish via a security group. These types of connections are:

Untracked Connections
Tracked Connections

Untracked Connections

Untracked connections are any connection established from a rule with a "0.0.0.0/0" wildcard. The direction of these connections can be both inbound and outbound.

The significance of these types of connections is that any change to a security group, such as a rule change or security group change, will immediately affect the traffic flow.

Tracked Connections

Tracked connections are any connection established from a rule with a specific IP address or segment, such as rules that allow traffic from "43.101.53.202/32". The direction of these connections can be both inbound and outbound.

Unlike untracked connections, changing a rule within a security group or deleting a security group from an EC2 instance will not immediately affect the traffic flow. This property of tracked connections may allow an attacker to maintain established connections even after the specific rules are removed.

Isolating EC2 instances with Tracked Connections

Users must follow the steps mentioned below to isolate an EC2 instance with a tracked connection:

Create a dedicated isolation security group without any rules
Create a single rule of 0.0.0.0/0 for all traffic in both the inbound and outbound rules
Remove any existing security groups attached to the EC2 instance
Associate the newly created isolation security group to the instance
Delete both the inbound and outbound rules you created for the isolation security group

Following these steps will effectively convert all the existing tracked connections into untracked connections, thus terminating any existing connections.

Planning Ahead With Security Groups

Each second could be the difference between successful isolation or further infection in a time-sensitive operation such as an incident response. Therefore users may keep preconfigured security groups that can be used to perform EC2 isolation.

a. Create a “Step 01” security group with the following rules

b. Create a "Step 02" security group without any rules

After creating these two security groups, users will now be able to swiftly isolate an EC2 instance while eliminating any tracked connections by using the following steps:

Remove all existing security groups or rules within existing security groups
Add the “Step 1” security group to the EC2 instance
Remove the “Step 1” security group from the EC2 instance
Associate the “Step 2” security group to the EC2 instance

Containing an EC2 Using NACLs

NACLs or Network ACLs is the next approach users may use to isolate an EC2 instance. However, NACLs are not targeted; therefore, it is difficult to isolate an individual EC2 instance using an NACL.

A Network ACL relies on rules to allow and deny traffic from subnets; however, unlike security groups, NACLs are stateless, meaning that rules need to be defined for both the request and the response of each connection.

The most significant advantage of using a NACL is that there is no multistage process compared to a security group. A single inbound or outbound rule will deny all traffic towards the respective direction.

However, since NACLs rely on rules based on subnets. Therefore, using NACLs to isolate an EC2 instance will affect all the other instances within the specified subnet.

Users may choose to use an existing NACL for isolation. In this method, users are required to add the deny rule as the first rule of the NACL; if the NACL is full existing rules may need to be removed to make space for the isolation-specific rules at the top of the NACL.

The other approach is to create a new NACL with the deny rules at the start of the NACL and to associate the dedicated isolation NACL to the VPC that hosts the affected EC2 instance.

Containing an EC2 Using Route Tables

Users can use route tables to isolate EC2 instances to move up the isolation spectrum. Route tables are an excellent method of isolating EC2 instances from all external networks, such as Internet Gateways, Direct Connections and VPN connections.

However, it is essential to understand that the route table is associated with the VPC that hosts the EC2 instance and not the EC2 instance itself. Therefore even though using a route table for isolation terminates all connections to all external networks, it will also disrupt any connection flowing through the specific VPC.

Additionally, isolating EC2 instances using route tables will restrict external access to the affected EC2 instance. However, it will still be able to communicate within the subnet and continue to spread to other resources within the same subnet.

Containing EC2 Using Internet Gateways

EC2 Isolation using internet gateways restricts internet connectivity to the VPCs that host the EC2 instances. However, restricting access using internet gateways are not straightforward since AWS will not allow users to remove the internet gateways if any EC2 dependencies within the VPC require the internet gateway.

Users are required to remove all dependencies to isolate an EC2 instance using an internet gateway successfully. However, this is not feasible during an incident response scenario.

Instead, users may obtain the same effect by removing all the internet gateway routes from the routing table or attaching a custom route table with no rules for all subnets.

EC2 Containment Playbook

A well-balanced and practical incident response playbook must cover all possible aspects when containing an affected resource. It must not restrict itself to a network containment approach but explore all possible methods of limiting access to and from the affected EC2 instance.

The following playbook provides a good starting point for organizations to adopt an EC2 containment playbook that covers most basic containment areas.

Tag and detach the EC2 instance from any auto-scaling group
Create a new security group that denies both inbound and outbound traffic (Empty Security Group)
Remove any existing security groups and associate them with the “empty” security group
Remove any IAM roles associated with the instance
Create a snapshot of the root volume
Create an AMI (Amazon Machine Image) of the instance for later analysis

It is also important to tag all entities used for isolation so that the same resources will not be used for any other business operation that can render the isolation ineffective.

Key Takeaways

This article explains the various approaches available for EC2 instance isolation. However, using a single method for isolation may not be sufficient since other factors may force a user to select a combination of these isolation approaches.

Additionally, network containment is only one part of a comprehensive isolation plan. Therefore, users must isolate other aspects, such as additional roles, to ensure comprehensive isolation.

I hope you have found this helpful. Thank you for reading!

Everything You Need To Get Started With AWS IAM

Lahiru Hewawasam — Sun, 09 Oct 2022 15:06:58 +0000

What is IAM on AWS?

Identity and access management is one of AWS's most essential services. IAM lays the foundation for solid identity management, allowing granular access to entities within AWS.

IAM within AWS splits into two main components:

Identities - Takes care of identifying a user within an AWS account. It is essential to understand that AWS requires a unique value for each account, represented by a 12-digit account ID or a unique account alias. Within each AWS account, administrators are only allowed to create 5000 users per AWS account, and each username must be distinctive from one another.
Access Management - Assigns and manages access to the level of access granted to a specific resource within AWS.

IAM Features

AWS IAM provides various features that allow administrators to manage users and access the AWS account.

There are some key IAM components that every administrator must be familiar with:

Users - Individual users created within an AWS account
User Groups - A collection of IAM users; used to specify permissions to a collection of IAM users
Roles - A short-lived credential with specific permissions that entities can assume to gain access
Policies - Object that defined specific permissions within AWS
Identity Providers - Enables administrators to use SAML 2.0 or OpenID connect to integrate a third-party directory service.

Creating and Managing Users on AWS IAM

One of the first steps when configuring an AWS account is to create users within IAM that can be accessed instead of the default root account.

An administrator may specify a unique user name for each user created; however, it is essential to remember the user name contains a 64-character limit.

Next, the administrator must specify the access type for the method of access for each IAM user:

Access Key - Grants programmatic access to the user via AWS API, CLI, SDK, etc.
Password - Grants AWS management console access to the user

Once the required access is selected, the following steps require the necessary permissions for the user. There are multiple methods for granting access to a user, such as adding a user to an existing user group, copying permissions from a current user or attaching a policy directly. However, it is best practice to grant users access by adding them to a user group since it is easily scaled and managed.

Additionally, administrators may specify permission boundaries to restrict the maximum user permissions allowed for a specific user; this prevents unnecessary and overly permissive policies from being granted to a user.

After completing this step, the administrator may choose to assign tags. These tags can help further organize, track and control access.

After completing these steps, the administrator may decide to create the user by reviewing the defined parameters and confirming the action.

Managing Access with IAM User Groups & Roles

One of the best practices used to manage access within IAM is by using user groups and roles. User groups enable administrators to easily control access at scale without manually assigning multiple permissions to a single user.

AWS user groups are a collection of IAM users that require specific access, such as Full access to an S3 bucket. In this instance, the administrator may assign the required policy to the user group and add the users to the user group to gain Full access to the S3 bucket.

However, user groups have default limitations; therefore, it is crucial that administrators plan accordingly and do not exceed these limits:

Maximum of 300 groups per AWS account
- To increase this limit, you'll need to contact AWS support
A user can only be associated with ten user groups
Each user group may only contain ten different policies attached at once

Unlike permissions granted via policies and user groups, IAM roles are issues temporarily. It allows users to assume temporary roles to perform a specific task they would not have been granted access to within their user groups; they can also grant access to users to access services from a different AWS account.

Considering the functionality of the IAM roles, the following entities may use this function:

User in the AWS account
User in a different AWS account
AWS service
Externally federated AWS user account

Managing Permissions using IAM Policies

Policies are the foundation of enabling access within AWS IAM and will be used to grant and even limit the maximum access for a specific entity.

There are four policy categories used within AWS IAM:

Identity-based policies
Resource-based policies
Permission boundaries
Service control policies

Identity-based policies

These policies can be attached to users, user groups or roles within AWS IAM to control each entity's access.

Identity-based policies have two different types:

Managed policies

These policies are stored within the AWS policy library and can be assigned to multiple users, user groups and roles

Inline Policies

These policies are not stored within the AWS policy library. However, they can be assigned to a single user, user group or role. These policies cannot be shared amongst entities.
Using inline policies is not considered best practice since they scale well and must only be used if necessary.

Managed policies are further separated into two categories:

AWS Managed Policies

These policies are predefined by AWS and are available for standard permissions

Customer Managed Policies

These policies are defined by the administrator and saved within the AWS policy library to grant custom permissions

Resource-based policies

These policies are effectively inline policies associated with a resource rather than an identity. For example, resource-based policies grant principles permissions so they can access a particular resource such as AWS S3.

The difference between an identity-based and resource-based policy is that it does not have the "principle" parameter within the policy as it is associated with an identity. On the other hand, resource-based policies must have the "principle" parameter to specify which identity the policy permissions apply.

Permission boundaries

Permission boundaries differ from identity-based and resource-based policies, as permission boundaries do not grant permissions. However, they restrict the maximum permission level for a specific user or role.

These policies can be attached to a user or role but cannot be linked to user groups within IAM. These policies can be AWS-managed policies or customer-managed policies.

These policies build a fence for the maximum permissions granted for a user or role, ensuring that these entities do not obtain excessively permissive access.

Service control policies

These policies are similar to permission boundaries as they define the maximum level of permissions allowed. However, organization service control policies or SCPs, such as AWS accounts or Organizational Units (OUs), restrict access at a much larger scale.

AWS Policy Generator

The AWS policy generator is a quick and easy method to create and define your AWS policies rather than writing all the policies from scratch.

Instead, when creating the new IAM policy, you can use the graphical interface to select the necessary permissions and services that need access and transfer the compiled policy into the AWS IAM console.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1665324279615",
      "Action": "s3:*",
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::firsts####"
    }
  ]
}

Identity Federation with AWS IAM

Identity federation within AWS IAM supports two types of federation:

Web ID federation
- Supports OpenID Connect providers such as Google, Facebook, Amazon, etc.
SAML 2.0-based federation

AWS allows users and accounts from third-party identity providers such as Microsoft Active Directory to use AWS services with the federation. In addition, it will enable organizations that already use identity providers to use the same accounts to grant access to AWS services, thus cutting down the requirement of users needing to have separate AWS IAM accounts.

It also allows you to create seamless single sign-on capabilities within the organization to improve the user experience.

Conclusion

AWS IAM is an integral part of the AWS services and builds the foundational blocks for all user and access management.

This article covered the basics required to understand key features that will allow administrators and users to start their AWS journey.

I hope you have found this helpful. Thank you for reading!