IAM Relationship Graph

See how AWS identities, groups, policies, roles and trust relationships connect.

AWS IAM is normally reviewed through separate lists and policy documents. The Relationship Graph changes the investigation from “What objects exist?” to “How are these objects connected?”

Why relationships matter

Consider a developer. The developer has no administrator policy directly attached. Looking only at that user could suggest limited access. But the actual relationship may be:

dev-user
  │
  │ member of
  ▼
Developers
  │
  │ attached policy
  ▼
DeploymentPolicy
  │
  │ permits role assumption
  ▼
ProductionRole

The resulting security context exists across several IAM objects. A relationship view makes that context easier to investigate.

Nodes and relationships

The graph represents AWS security objects as nodes and relationships between them as edges.

Common node types

• User — an IAM user.
• Group — an IAM group.
• Role — an IAM role.
• Policy — a policy participating in the observed identity relationship.
• External principal — a principal outside the local AWS account that participates in a supported trust relationship.
• Resource — a supported AWS resource represented where resource relationships are available.

Not every graph or account will contain every node type.

Common relationship types

Depending on the available assessment evidence, relationships can include concepts such as:

Member of

User → Group

The IAM user belongs to the group.

Attached policy

Role → Policy

or:

Group → Policy

The policy contributes permissions to the identity relationship.

Can assume

Principal → Role

A supported trust relationship indicates that the principal may participate in role assumption, subject to the applicable permission and trust conditions.

Access or escalation relationships

Where supported analysis establishes additional security context, Securitain can correlate relationships with access or privilege-escalation analysis. These relationships should be interpreted together with the supporting evidence rather than as standalone proof of exploitation.

Example: group-based role access

Consider:

dev-user
  │
  │ member of
  ▼
Developers Group
  │
  │ permission source
  ▼
AssumeRole Policy
  │
  │ allows
  ▼
Production Role

Using the graph

Open IAM Analyzer → Graph → Relationships. The graph can be used to investigate IAM connections visually.

Search for an identity

Search for a user, role, group or policy by name — usually the fastest way to start investigating a known identity, for example ProductionDeployRole. The graph can then be used to identify connected objects.

Filter by object type

For large environments, filter the graph to focus on the objects relevant to the investigation. For example, Users + Groups + Policies can help investigate group-derived permissions, while Roles + external principals can help investigate trust relationships where those nodes are present in the current graph.

Select a node

Selecting a node exposes additional context and its connected relationships — which policies are connected to this role, which group is this user a member of, which identities are connected to this policy, and which trust relationships involve this role. Rather than opening several AWS IAM pages separately, the investigator can move through the relationship.

Large AWS environments can contain more IAM objects than are useful to display simultaneously. Securitain can provide a focused view that narrows the graph toward objects carrying security-relevant risk context, useful when the full relationship graph is too large for practical investigation.

Relationship Graph vs Attack Path

These concepts are related, but they are not the same.

User
  ↓
Group
  ↓
Policy

Developer
  ↓
iam:PassRole
  ↓
Privileged Role
  ↓
Lambda
  ↓
Production capability

The graph provides structural context. Privilege-escalation analysis applies additional security reasoning to determine whether relationships may create a meaningful path.

Relationship does not always mean access

AWS authorization may also depend on:

• trust-policy conditions
• identity-policy conditions
• resource restrictions
• permission boundaries
• Service Control Policies
• explicit denies
• request context
• AWS service behavior

For example, Principal → Role may represent a trust relationship. But successful role assumption can still depend on whether the principal has the necessary permission and whether the applicable conditions are satisfied. Securitain's deeper effective-permission and escalation views should be used when determining actual security consequence.

Investigating an unexpected relationship

When you find an unexpected relationship:

1. Identify the starting principal — determine whether the identity is human, workload, federated or external.
2. Follow the relationship — understand whether it comes from group membership, policy attachment, role trust, external trust or another supported authorization relationship.
3. Inspect the permission source — review the policy or trust configuration responsible for the relationship.
4. Check restrictions — look for resource scope, conditions, permission boundaries, SCP restrictions and explicit denies.
5. Investigate consequence — use Effective Permissions, Privilege Escalation, Exposure, Blast Radius and Identity-to-Data to determine what the relationship can ultimately enable.
6. Review associated findings — if Securitain has identified a security condition related to the identity or relationship, review the finding evidence before deciding on remediation.

Example investigation

Suppose the graph shows:

alice
  ↓
Developers
  ↓
DeploymentPolicy

The policy contains permission to assume a deployment role. The investigator can then examine:

alice
  ↓
Developers
  ↓
DeploymentPolicy
  ↓
ProductionDeployRole

The next question should not immediately be:

Is Alice an administrator?

Instead ask:

What can ProductionDeployRole do, and can Alice actually assume it under the applicable AWS authorization controls?

That investigation may continue into Effective Permissions → Escalation → Blast Radius. This is how the graph changes IAM analysis from object inspection into relationship investigation.

Evidence and limitations

The Relationship Graph is generated from the AWS information available to the relevant assessment. Graph results therefore depend on the connected AWS account, enabled assessment capabilities, scan freshness, AWS permissions available to Securitain, supported relationship types, and available resource and trust information.

Related guides