> For the complete documentation index, see [llms.txt](https://nk0.gitbook.io/dfir/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nk0.gitbook.io/dfir/enterprise-architecture/the-cloud/aws/fundementals/iam.md).
# 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:**
{% embed url="" %}
* `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](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_Identifiers.html) 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](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html#scenario-iam-user).
* `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](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html) 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
```
{% embed url="" %}
## 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.
### External Access Policies:
* Identity-based policies cannot expose your resources in your AWS account to principals that exist outside of your AWS account.
* If you want to grant a principal outside of your AWS account access to your AWS account, you must use a resource-based policy.
### 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.
{% embed url="" %}
