Identity and Access Management (IAM).

Dive into AWS IAM and learn why identity and access management is the backbone of secure cloud environments. Not just in AWS, but in almost every IT system today. Controlling who can do what, when, and where is critical to keeping your infrastructure safe and compliant.

Key features include:
👥 Centralized User Management: Manage users, groups, and roles easily
🛡️ Fine-Grained Permissions: Grant exactly the right level of access to resources. No more, no less.
📜 Audit & Compliance: Monitor and log every action to maintain transparency and meet compliance standards.
🔑 Temporary Credentials: Use time-limited access keys to reduce risk and improve security posture.
🔄 Multi-Factor Authentication: Additional protection

Special thanks to Tiexin Guo, Senior DevOps Consultant, Amazon Web Services.

Identity and Access Management (IAM) provides fine-grained access control.

With IAM, you can specify who can access which services and resources, and under which conditions.

Authentication (Authn): Validates the identity of a user. It's typically handled by checking credentials, such as usernames and passwords.

Authorization (Authz): Defines permissions for users and limits access to only the resources permitted for that specific user.

4 Key Entities include Root User, IAM Users, User Groups, and IAM Roles.
These entities detail who a user is and what that user is allowed to do within the environment.

Root User: is the original sign-in identity created with the account, granting unrestricted access to all resources and settings. Note these credentials in a secure location and NEVER USE THIS ACCOUNT.

IAM Users: are separate identities you create to provide individuals or services with long-term credentials for console access or programmatic interactions via the AWS API or CLI.

User Groups: allow you to organize multiple IAM users and assign shared permissions collectively, simplifying management.

IAM Roles: similar to users in that they define permissions, but instead of long-term credentials, they grant temporary security credentials when assumed, enabling secure, time-limited access for trusted AWS users, services, or applications.

> You manage access in AWS by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources.

> A policy is an object in AWS that, when associated with an identity or resource, defines their permissions.

> Permissions in the policies determine whether the request is allowed or denied.

> Most policies are stored in AWS as JSON documents.

Zero Trust: Every user, device, and application must be authenticated and authorized before being granted access to resources.

Least Privilege Access: Grant only the minimum level of access necessary to perform their tasks.

Micro-segmentation: Divide the network into smaller, isolated segments to limit the impact of a potential breach.

Assume Breach: Under the assumption breaches will happen, it is critical to be vigilant and take proactive measures.

Continuous Monitoring: All activities are monitored and logged to detect anomalies and potential security threats.

IAM is complex especially if you are in a big team with many users, groups, and resources. Here are tools to reduce operational overhead and consolidate user identities.

AWS Organizations: Management of multiple AWS accounts and Service Control Policies (SCPs) to set guardrails.

AWS IAM Identity Center (formerly AWS SSO): Centralized authentication and authorization for multiple AWS accounts and third-party apps.

AWS Directory Service: Integrate AWS resources with Microsoft Active Directory.

IAM Roles & Resource-Based Policies: Provide cross-account or federated access without creating separate IAM users.
AWS Control Tower: A framework for setting up and governing a secure multi-account AWS environment.

Automate Everything: This is not an AWS tool but a good principle to follow. Trust me, you don't want to log in to the AWS web console to create every user. Now there are some cases where this is viable (like testing a new account or expirmentation) but for the most part automate this process.

because...

> Automation reduces human errors.

> Automation makes it easy to log, audit, and generate reports on a regular schedule for compliance requirements.
> If you want to automate IAM a good place to start is Terraform.

DO NOT Use Root User: AWS account root user gives full access to all your resources for all AWS services. You cannot reduce the permissions associated with your AWS account root user access key.

> Do not use the root user for your everyday tasks, even the administrative ones. Instead, use your root user credentials only to create your IAM admin user.

> Delete the root user's access key. If you must keep it (which you don't have to) rotate (change) the access key regularly.

Enable Multi-Factor Authentication (MFA): For extra security, it's strongly recommended that you enable MFA for all users in your AWS account.

Use a Strong Password Policy: If you allow users to change their own passwords, create a custom password policy that requires them to create strong passwords and rotate their passwords periodically.

Use IAM roles instead of long-term access keys: For most apps that need access to AWS, the best practice is to configure the program to retrieve temporary security credentials using an IAM role.

Rotate Credentials Regularly: Change your own passwords and access keys regularly, and make sure that all IAM users in your account do as well. This reduces the risks drastically.

Remove Outdated and Unnecessary Credentials: Locate and remove IAM passwords and keys that are idle to increase security. You can find unused passwords or access keys using the console, using the CLI or API, or by downloading the credentials report.

In the real world, you have different teams, and each team requires different permissions and should be allowed to access only certain resources.

Best practice is to create groups and assign permissions. Think of user groups as logical sets of users. This way, we can create multiple groups related to various job functions (Administrator, Security Auditor, etc.) and assign relevant permissions.

In the future, if you need to change access levels for the team then you only need to make a change at the group level.

Use Roles to delegate permissions.

Roles are essentially identities that can be assumed by AWS services or users to access AWS resources.

For example, your writing code and you need to specify a way to access a service. Easy, just hard code the credentials into the code. WRONG! Never put keys into code or instances..

Please do NOT do that. That method is insecure.

A better approach would be to assume a role by using AWS Security Token Service (STS).

Assuming roles are considered more secure because you define who can access the role and how long a token is valid for.

Notes on Roles:

> Using the credentials for one role to assume a different role is called role chaining. When you use role chaining, your new credentials are limited to a maximum duration of one hour.

> The maximum session duration setting does not limit sessions that are assumed by AWS services.

> Amazon EC2 IAM role credentials are not subject to maximum session durations configured in the role.

> To allow users to assume the current role again within a role session, specify the role ARN or AWS account ARN as a principal in the role trust policy.

Policies are documents that define permissions. They specify what actions a user, group, or role can perform on AWS resources. These policies are written in JSON and are essential for controlling access within your environment.

There are 5 main policies.

AWS Managed Policies: Pre-defined policies created and managed by AWS, designed for common use cases.

Customer Managed Policies: You create and manage these policies to fit your specific needs and access control requirements.

Identity-Based Policies: These policies are attached to users, groups, or roles and define permissions based on the identity making the request.

Resource-Based Policies: These policies are attached to AWS resources (like S3 buckets or SNS topics) and define who can access that resource.

Service Control Policies (SCPs): These policies, part of AWS Organizations, control the maximum permissions available to accounts within an organization.

> Note on Policies: Utilize IAM Access Analyzer and CloudTrail logs to check your policy.

Whether it’s a hybrid environment, native cloud, or multi cloud environments; monitoring and auditing are critical components of a secure strategy.

Our goal is to detect unauthorized access, identify suspicious behavior, and adhere to security policies.

"You can’t secure what you’re not tracking"

Monitoring tracks user activity in real time to identify potential security risks, such as multiple failed login attempts or unusual access patterns, allowing for immediate response to threats

Auditing involves reviewing logs to detect anomalies, verify compliance with regulations, and ensure that access controls are correctly configured

Here are 3 strategies to follow.

Schedule Access Audits: The only way to consistently track what access users really need is through regular audits. Create schedule. Reference this article here.

Last Accessed Information: Includes information about the actions that were last accessed for some services, such as Amazon EC2, IAM, Lambda, and Amazon S3. Information is available in AWS Access Advisor.

Monitor Activities: Many AWS services support logging; log files show the time and date of actions, the source IP for an action, which actions were performed. Leverage CloudTrail.
Note: Utilize AWS Config to assess, audit, and evaluate the configurations of your resources.

Note: Utilize AWS GuardDuty, a threat detection service that continuously monitors AWS accounts and workloads for malicious activity.

This should give you a good grasp of IAM as a whole. Whether it be in AWS, Coogle cloud, Azure, or on-prem environments. Use these principles and recommendations to harden your environment.

Article from Tiexin Guo..

AWS document for Security best practices in IAM..

Another AWS article..

Datadog article..

AWS and Terraform..

Hashicorp AWS secrets engine..