IAM

Users

• Each account has it's own root user. This user can do anything in that account and cannot be disabled.

• SCP can be used to deny every call for the root account. While it doesn't disable it and people can still log in, it can't do anything.

• Management account = a root user too

• Best to limit the amount of IAM users because they are usually over permissioned.

• Federated user/SSO: Can be federated with Okta or Entra ID.

CLI/Cloudshell:

aws iam list-users

IAM User Properties:

AWS::IAM::User - AWS CloudFormationAWS CloudFormation

• Groups

  A list of group names to which you want to add the user.

• LoginProfile

  Creates a password for the specified IAM user. A password allows an IAM user to access AWS services through the AWS Management Console.

• ManagedPolicyArns

  A list of Amazon Resource Names (ARNs) of the IAM managed policies that you want to attach to the user.

• Path

  The path for the user name. For more information about paths, see IAM identifiers in the IAM User Guide.

• PermissionsBoundary

  The ARN of the managed policy that is used to set the permissions boundary for the user.

  A permissions boundary policy defines the maximum permissions that identity-based policies can grant to an entity, but does not grant permissions.

• Policies

  Adds or updates an inline policy document that is embedded in the specified IAM user. To view AWS::IAM::User snippets, see Declaring an IAM User Resource.

• Tags

  A list of tags that you want to attach to the new user. Each tag consists of a key name and an associated value. For more information about tagging, see Tagging IAM resources in the IAM User Guide.

• UserName

  The name of the user to create. Do not include the path in this value.

IAM User Groups

• Users can be listed together in IAM User Groups and permissions can be assigned to the group.

CLI/Cloudshell:

aws iam list-groups

AWS::IAM::Group - AWS CloudFormationAWS CloudFormation

Roles

• A role has two major components

  • What the role is allowed to do → (IAM permissions policy)

  • Who is allowed to take on the role → (trust policy)

• Taking a role in AWS is called an AssumeRole action this allows us to temporarily take on a role without needing an IAM user and credentials in the target account

• The service that makes this possible in AWS is Security Token Service (STS).

  • STS gives temporary credentials for a role.

• Cross tenant access

  • Roles can be assumed from a different AWS tenant (attacker > victim).

    • IAM role trust policy allows external user to AssumeRole.

  • Won't detect this in IAM users or IAM policies, because it is defined in the IAM roles.

AssumeRole:

• Provides temporary access key for user to use.

CLI/Cloudshell:

aws sts assume-role --role-arn EXAMPLE --role-session-name EXAMPLE

• Provide credentials to .env variables in AWS CLI to assume role automatically.

Role Chaining

• Roles can also assume other roles which is called role chaining which makes it even more complex to investigate who was ultimately responsible.

Security Token Service (STS)

• Expiration time on tokens is definable.

  • Because sessions for access keys expire; if the TA has extended access, there will be multiple access keys for us to investigate.

• Minimum access key lifetime: 15 mins

Access Analyzer

• Paid service that helps find 'dangerous' roles as well as finding over permissioned roles and potentially roles you don’t need any more.

• External access findings (FREE)

  • Review any IAM roles/policies for Public Access

  • Review any IAM roles/policies for Cross-Account Access

• Unused access findings (PAID)

  • Finds unused roles, access keys, IAM user that are obsolete.

• Takes hour or hours to run.

Policies

• Big 3 policies (seen most often):

  • Identity based

    • Assigned to identities (IAM users, IAM groups)

  • Resource based

    • Assigned to resources (S3s, EC2s, etc).

    • Example: Allow a specific IP to talk to an S3 bucket only.

  • Service Control Policy (SCP)

    • Assigned to organization OUs. Used to set guardrails in AWS.

Policy Examples:

Identity Based

• Effect:

  • Allow or deny (default is deny).

• Action:

  • The specific API calls (Get, Put, Post, etc)

• Resource:

  • Object the policy is applied to.

Resource Based:

• Effect:

  • Allow or deny (default is deny).

• Action:

  • The specific API calls (Get, Put, wildcard *)

• Principal:

  • Allows external accounts to access resource.

• Resource:

  • Resource the policy is applied to.

Service Control Policy:

• Effect:

  • Allow or deny (default is deny).

• Action:

  • The specific API calls (Get, Put, wildcard *)

• Resource:

  • OU the policy is applied to.

  • Applied to all AWS accounts under OU.

• Condition:

  • Boolean conditions that policy abides by.

IR Policies:

Policy Evaluation:

• By default everything is denied, unless there is an allow somewhere along the evaluation.

  • If there is an explicit deny somewhere along the hierarchy, it will be denied.

  • If there is an allow in the hierarchy, it will be allowed. UNLESS there is an explicit deny lower in the chain.

• Organization SCP:

  • If there is a deny at this stage, the evaluation will stop before looking at the lower level policies.

Policy evaluation logic - AWS Identity and Access ManagementAWS Identity and Access Management