Identity and Access Management (IAM)

In a nutshell, AWS IAM lets you manage user access to AWS resources by assigning roles and permissions, ensuring secure and controlled access.

Let’s have a deeper look at these services.

AWS Organizations

AWS Organizations is a global service that enables you to manage multiple AWS accounts simultaneously.

Key Concepts:

• Management Account: The primary account that oversees the organization.
• Member Accounts: Accounts that join or are created within the organization.
• Single Organization Rule: Each account can belong to only one organization at a time.

Benefits of AWS Organizations:

1.????? Consolidated Billing

1. All accounts within the organization share a single payment method managed by the management account.
2. This setup simplifies cost management and tracking.

2.????? Cost Savings & Discounts

1. AWS aggregates usage across all accounts, leading to volume-based discounts on services like EC2 and S3.
2. Reserved Instances and Savings Plans can be shared across accounts, allowing unused reservations to be utilized by other accounts, maximizing cost efficiency.

3.????? Automated Account Creation

1. AWS Organizations provides an API to automate new account creation, making it easy to scale your cloud environment.

Organizational Structure:

AWS Organizations allows for a flexible account hierarchy using Organizational Units (OUs):

• The Root OU sits at the top and contains the Management Account.
• Sub-OUs can be created to categorize accounts based on teams, environments, or departments. Example: A Development (Dev) OU containing dev-related member accounts. A Production (Prod) OU with separate OUs for HR, Finance, and other departments.

Organizing Your AWS Organizational Units (OUs)

AWS Organizations allows you to structure your accounts in different ways based on your needs:

1. By Business Unit Example: A Management Account at the top, with separate OUs for Sales, Retail, and Finance, each containing relevant accounts.
2. By Environment Example: Separate OUs for Production (Prod), Testing (Test), and Development (Dev), each containing its own set of accounts.
3. By Project Example: Each project has its own OU, grouping related accounts under it.
4. Hybrid Approach You can mix and match these strategies to create a structure that best fits your organization’s needs.

Advantages of Using AWS Organizations

1. Enhanced Security Using multiple accounts is more secure than a single account with multiple VPCs, as accounts provide better isolation.
2. Standardized Tagging & Centralized Logging Enforce tagging standards for easier cost tracking. Enable CloudTrail across all accounts and send logs to a central S3 bucket. Send CloudWatch logs to a dedicated logging account for better visibility.
3. Centralized Administration Use cross-account roles to manage all member accounts from the Management Account, simplifying administrative tasks.
4. Service Control Policies (SCPs) for Governance SCPs are IAM-like policies applied to specific OUs or accounts to restrict user and role permissions. Important: SCPs do not apply to the Management Account, which always retains full administrative control to prevent accidental lockouts. To ensure permissions work correctly, explicit allows must be defined at every OU level, including the root.

?

?

IAM Conditions and Their Role in Policies

IAM conditions allow you to apply restrictions to policies in AWS Identity and Access Management (IAM). These conditions can be used in:

• IAM policies for users and roles
• Resource policies, such as those for S3 buckets
• Endpoint policies and more

Essentially, IAM conditions can apply to almost any type of policy within AWS.

Example: aws:SourceIP Condition

The aws:SourceIP condition helps restrict API calls based on the client’s IP address.

How it works:

• A Deny rule applies to all actions (*) unless the request comes from a specified IP address range (CIDR).
• If an API call originates from an unauthorized IP, it is automatically denied.

Use Case: This condition is commonly used to limit access to AWS resources only from a company’s internal network, ensuring that external users cannot access critical environments.

?

IAM Condition: aws:RequestedRegion

The aws:RequestedRegion condition allows you to restrict API calls based on the AWS region they are made to.

How It Works:

• This condition is global (since it starts with aws:).
• It can be used to deny access to specific AWS services in certain regions.

Example Use Case:

A policy could deny all actions on EC2, RDS, and DynamoDB if the request is made to eu-central-1 or eu-west-1.

• This ensures that these services cannot be used in restricted regions, enforcing compliance or security policies.

Applying to AWS Organizations (SCPs)

• This condition can be applied at the Service Control Policy (SCP) level.
• Organizations can allow or deny access to specific regions across all accounts under the organization.

?

IAM Conditions: ec2:ResourceTag and aws:PrincipalTag

IAM conditions can also be used to enforce tag-based access control.

1. ec2:ResourceTag

• Since the condition prefix is ec2:, it applies specifically to EC2 resource tags.
• Example: A policy that allows users to start and stop EC2 instances only if the instance has the tag: Key: Project Value: DataAnalytics

This ensures that only EC2 instances tagged with "Project=DataAnalytics" can be managed under this policy.

2. aws:PrincipalTag

• Unlike ec2:ResourceTag, this condition applies to IAM user tags, not EC2 resources.
• Example: The user attempting to start or stop an instance must have the tag: Key: department Value: data

Combined Effect:

• The EC2 instance must be tagged with "Project=DataAnalytics".
• The IAM user must be tagged with "department=data".
• If both conditions are met, the action is permitted.

This approach enhances security by ensuring that only authorized users can perform actions on specific resources.

?

IAM Condition: aws:MultiFactorAuthPresent

The aws:MultiFactorAuthPresent condition ensures that multi-factor authentication (MFA) is used before performing certain actions.

How It Works:

• A policy can be set up so that a user can perform any action on EC2, but with a restriction: they can only stop or terminate EC2 instances if MFA is enabled.
• Specifically, the condition is set to deny these actions unless MFA is present (i.e., the MFA condition is true).

This ensures that sensitive operations like stopping or terminating instances require extra authentication for enhanced security.

?

Differences Between IAM Roles and Resource-Based Policies

When working with cross-account access, such as performing an API call to an S3 bucket in a different account, there are two main options:

1. Using a Resource-Based Policy (e.g., an S3 bucket policy on the target bucket)
2. Using an IAM Role that can access the resource

Let’s break down these two options:

Option 1: Using an IAM Role

In this case, a user in Account A can assume a role in Account B, which has the necessary permissions to access resources (e.g., S3 buckets). When you assume a role, you inherit all the permissions assigned to that role, and your original permissions are temporarily replaced. This means the user is restricted to what the role allows, not what the user was originally permitted to do.

Option 2: Using a Resource-Based Policy

Alternatively, a bucket policy on an S3 bucket in Account B can grant a user in Account A direct access to the bucket, without the need to assume a role. With this option, the user does not lose their original permissions, allowing them to combine tasks. For example, a user in Account A can scan a DynamoDB table in Account A and then write the data to an S3 bucket in Account B.

This flexibility makes resource-based policies more useful in scenarios where you want to maintain access to multiple resources across accounts without switching roles.

Which One to Use?

• IAM Roles are great when you want to explicitly grant full access by assuming a specific role.
• Resource-Based Policies are ideal for granular access control where users can maintain their original permissions while accessing resources in other accounts.

AWS Services with Resource-Based Policies

Many AWS services and resources now support resource-based policies, including:

• S3 buckets
• SNS topics
• SQS queues
• Lambda functions

EventBridge and Permissions

When using Amazon EventBridge to trigger actions, it requires permissions on the target. The choice of whether IAM roles or resource-based policies are used depends on whether the target service supports them:

1. Resource-Based Policies: Services like Lambda, SNS, SQS, S3, and API Gateway support resource-based policies. In this case, EventBridge can directly apply a policy on the target to allow invocations.
2. IAM Roles: If the resource doesn't support resource-based policies (e.g., Kinesis Streams, EC2 Auto Scaling, ECS tasks), EventBridge will use an IAM role to invoke the target.

Note: Even though Kinesis Data Streams supports resource-based policies, EventBridge will still use an IAM role for this service.

How to Determine Which Method Is Used

To determine whether EventBridge will use a resource-based policy or an IAM role, you need to check the EventBridge rule configuration to understand how the permissions are applied for the target service.

?

Understanding IAM Permission Boundaries

IAM Permission Boundaries are an advanced feature used to define the maximum permissions an IAM user or role can have. It's important to note that permission boundaries are only applicable to users and roles, not groups.

How IAM Permission Boundaries Work

·???????? A permission boundary is essentially an IAM policy that sets the limits for what actions a user or role can perform.

·???????? For example, let's say we have a permission boundary attached to a user that allows actions only on S3, CloudWatch, and EC2.

This policy could look like:

• Allow all actions on S3, CloudWatch, and EC2.

·???????? In addition to the permission boundary, we attach a separate IAM policy to grant specific permissions, such as:

• Allow the action iam:CreateUser on any resource.

How Permissions Work Together

In this case, the resulting permissions are determined by both the permission boundary and the IAM policy.

• Even though the IAM policy allows the user to create IAM users, this action is outside the permission boundary (which only allows actions on S3, CloudWatch, and EC2).
• Therefore, the user will not be allowed to create IAM users, as the action falls outside the defined boundary.

Key Takeaways:

• Permission boundaries restrict what actions an IAM user or role can perform, even if the attached IAM policy allows broader access.
• The final permissions are always constrained by the permission boundary, which acts as an upper limit for access.

?

?AWS IAM Identity Center Overview

The AWS IAM Identity Center is the successor to the AWS Single Sign-On (SSO) service. It provides a single login to access all your AWS accounts within AWS Organizations, along with business cloud applications like Salesforce, Box, and Microsoft 365, as long as those apps support SAML 2.0 integration. Additionally, it allows a single login for access to EC2 Windows Instances, streamlining access across multiple services and applications.

Identity Providers

You can store your user information in the IAM Identity Center's built-in identity store, or you can connect to an external identity provider such as Active Directory (AD), OneLogin, or Okta.

How It Works

• Browser Interface: Users connect to the IAM Identity Center login page to authenticate.
• You integrate the service with various user stores, such as an Active Directory (cloud or on-premises), or the IAM Identity Center's built-in store, where you define users and groups.
• IAM Identity Center integrates with services like SSO for your AWS organization, Windows EC2 instances, business cloud applications, or any custom application with SAML 2.0 support.
• The central benefit is the single login for all of these services, greatly simplifying the user authentication process.

Permissions Management

When you log in, you don’t automatically have access to everything. You need to define permission sets within the Identity Center to specify what users can access.

Example: Permission Set Setup

• You have an organization and you configure IAM Identity Center in the management account.
• Within the organization, you have two OUs (Organizational Units): Development and Production.
• You create a group for developers (e.g., Bob and Alice).
• You then define permission sets like AdminAccess for the Development OU, and assign this permission set to the developers' group.
• Similarly, you could create a ReadOnlyAccess permission set for the Production OU, and assign that to the same group. This way, Bob and Alice can have full access to development accounts and read-only access to production accounts.

Fine-Grained Permissions and Multi-Account Access

You can manage access across multiple AWS accounts using permission sets that define what users and groups can access in each account.

For example:

• Database Admins can have permissions to access RDS and Aurora in both development and production accounts.
• These permissions are automatically reflected in the IAM role assigned to users when they log in via IAM Identity Center. So, when users access the AWS console, they assume the appropriate IAM role, granting them the correct permissions for each account.

Application Assignments

IAM Identity Center also supports application assignments to specify which users or groups can access specific applications. When users log in, they’re provided with the necessary URLs, certificates, and metadata for seamless access to these applications.

Attribute-Based Access Control (ABAC)

A powerful feature of IAM Identity Center is Attribute-Based Access Control (ABAC), which allows you to create fine-grained permissions based on user attributes stored in the IAM Identity Center. These attributes could be tags like cost center, job title, or region.

For example:

• You can assign a user to a cost center or a region and control their access based on these attributes.
• By defining IAM permission sets once, you can leverage these attributes to dynamically control access to AWS resources without the need for constant updates to the permission sets themselves. You simply adjust the attributes, and the permissions automatically update accordingly.

Conclusion

AWS IAM Identity Center simplifies user management and access control across multiple AWS accounts and applications. Its ability to integrate with external identity providers, define fine-grained permissions, and enable Attribute-Based Access Control makes it a powerful tool for managing complex, multi-account environments efficiently.

?

AWS Directory Services

Let's talk about Microsoft Active Directory and AWS Directory Services.

Microsoft Active Directory (AD) is a software available on any Windows Server with Active Directory Domain Services. It serves as a database for objects, such as user accounts, computers, printers, file shares, and security groups. In essence, it's the central management system for users within the Microsoft ecosystem on-premises, enabling centralized security management. Through Active Directory, you can create accounts, assign permissions, and manage various objects, all of which are organized into a tree structure, with multiple trees grouped together in what’s called a "forest."

For example, if we have a domain controller and create a user account for "John" with the password "Password," all other Windows machines within the network are connected to this domain controller. When John attempts to log in, the system verifies his credentials with the domain controller, allowing him access to any machine on the network. This is the essence of how Active Directory enables centralized user management.

Now, let’s look at AWS Directory Services, which lets you create an Active Directory in AWS. There are three primary options here, each with its own use case.

1.????? AWS Managed Microsoft AD: This option allows you to create your own Active Directory in AWS and manage users locally. It supports multi-factor authentication and offers the flexibility to establish trust relationships with your on-premises Active Directory. With this setup, AWS and your on-premises AD trust each other, meaning users from both environments can be authenticated across both systems. Essentially, this provides a shared user base between your on-premises and AWS AD.

2.????? AD Connector: This option acts as a gateway or proxy to redirect requests to your on-premises Active Directory. It also supports multi-factor authentication, but the key difference is that all user management remains on your on-premises AD. AD Connector merely facilitates authentication by proxying requests back to your on-premises directory, with no user management capabilities in AWS.

3.????? Simple AD: This is an AD-compatible, managed directory on AWS that doesn't use Microsoft AD. It’s best suited for environments where you don’t have an on-premises AD. It’s a standalone solution that lets you create and manage EC2 instances running Windows, and these instances can join the Simple AD domain, sharing credentials and login information.

Now, when integrating AWS IAM Identity Center with Active Directory, things get simpler if you're using a managed Active Directory in AWS, as the integration is straightforward. However, if you manage your Active Directory on-premises, you have two main ways to integrate:

·???????? Two-way trust relationship: You can set up a two-way trust between your on-premises AD and AWS Managed Microsoft AD. This allows seamless integration with IAM Identity Center for single sign-on (SSO).

·???????? AD Connector: This method involves using AD Connector to proxy requests from IAM Identity Center to your self-managed directory. It’s less flexible than the first method since it doesn't allow for user management in the cloud, but it can still be useful for simply proxying requests, albeit with some latency.

In choosing between these two, it depends on whether you need the ability to manage users directly within the cloud (in which case AWS Managed Microsoft AD is the better choice) or if you just need to proxy API calls (AD Connector might be a fit).

?

AWS Control Tower?

Let's dive into AWS Control Tower, a service designed to simplify the setup and management of a secure, compliant multi-account AWS environment based on best practices.

AWS Control Tower makes it easy to create and manage AWS accounts with security and compliance built in. It leverages AWS Organizations to automatically create accounts that adhere to your security and compliance requirements. The main benefits of using Control Tower include quickly setting up your environment with just a few clicks, pre-configuring your desired settings, and automating ongoing policy management. It also allows you to detect and fix policy violations automatically, while providing a comprehensive dashboard for monitoring compliance across all your accounts.

So, what are "guardrails" in this context?

Guardrails are governance controls that allow you to enforce security policies across all accounts in your Control Tower environment. They ensure compliance and provide oversight for your accounts. There are two types of guardrails:

1.????? Preventive Guardrails: These guardrails are designed to prevent certain actions within your accounts by applying restrictions. They rely on Service Control Policies (SCPs) from AWS Organizations. For example, you could create a preventive guardrail to restrict the use of AWS regions, ensuring that all accounts can only operate in specific regions, like us-east-1 or eu-west-2. Control Tower will configure AWS Organizations to enforce these SCPs across all accounts.

2.????? Detective Guardrails: Unlike preventive guardrails, detective guardrails are designed to detect non-compliance, not prevent actions. They use AWS Config, which monitors and tracks resource compliance across all accounts. For instance, a detective guardrail might track untagged resources. Control Tower deploys AWS Config across all member accounts to monitor this compliance. If a resource is found to be untagged, AWS Config triggers an SNS notification, which can notify administrators or even invoke an AWS Lambda function. This Lambda function can then automatically add the missing tags to the untagged resources, ensuring compliance.

In short, AWS Control Tower provides automated, ongoing governance across your AWS accounts, offering a combination of preventive and detective measures to maintain security and compliance.

?

?