> For the complete documentation index, see [llms.txt](https://docs.forestall.io/fsprotect/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/fsprotect/edges/aws/aws_parent_account.md).

# AWS\_PARENT\_ACCOUNT

## Summary

|                        |                                        |
| ---------------------- | -------------------------------------- |
| Forestall ACL Alias    | AWS\_PARENT\_ACCOUNT                   |
| AD Alias               | N/A                                    |
| Affected Object Types  | `Account → IAM User/Role/Group/Policy` |
| Exploitation Certainty | Low                                    |
| AD Attribute           | N/A                                    |
| Attribute GUID         | N/A                                    |
| AD Right               | N/A                                    |

## Description

`AWS_PARENT_ACCOUNT` is a structural edge directed **parent → child** that marks the single AWS account that directly owns an IAM identity:

* `(AWSAccount)-[AWS_PARENT_ACCOUNT]->(AWSIAMUser | AWSIAMRole | AWSIAMGroup | AWSIAMPolicy)`

Every IAM entity is scoped to exactly one account and carries that account's 12-digit ID in its ARN. This edge records that ownership as its own relation, one level of the containment picture rather than the whole chain. It runs parallel to `AWS_PARENT`, which threads the full hierarchy from the organization root down through OUs to the account. Keeping the account-to-identity link on a dedicated label lets a query reach an identity's account without walking that chain.

The account is the isolation boundary in AWS. Which account holds an identity decides whether lateral movement needs a cross-account trust, which Service Control Policies apply, and how far a compromised credential can reach. The edge is not exploitable on its own. Its value is that it lets a query pin an identity to its account in one hop without walking the organization hierarchy.

## Identification

Read the owning account straight from an entity's ARN, or confirm the current caller's account:

```bash
# Account ID from an entity ARN (arn:aws:iam::<account-id>:user/<name>)
aws iam get-user --user-name TargetUser --query 'User.Arn' --output text | cut -d: -f5

# The account behind the current credentials
aws sts get-caller-identity --query Account --output text
```

Forestall ISPM creates this edge during IAM collection by grouping each identity by its account ID and linking it back to the matching `AWSAccount` node.

## Mitigation

* Use separate accounts per environment and workload so the account boundary is a meaningful containment line.
* Apply SCPs at the OU level to hold account-wide guardrails regardless of in-account IAM policy.
* Prefer role assumption or federation over long-lived user access keys in accounts that host sensitive workloads.

## Detection

Account ownership is static and raises no events by itself. Watch for identity lifecycle changes inside accounts where none are expected:

* `CreateUser`, `DeleteUser`
* `CreateRole`, `DeleteRole`
* `CreateGroup`, `DeleteGroup`

## References

* [IAM identifiers / ARNs](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html)
* [STS GetCallerIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html)
* [AWS Organizations: SCP inheritance](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html)
* [MITRE ATT\&CK T1098: Account Manipulation](https://attack.mitre.org/techniques/T1098/)