IAM & Identity
Understand AWS identities, credentials, permissions, exposure and the relationships that determine what an identity can ultimately do.
IAM is one of the most important security boundaries in AWS, but IAM risk rarely exists in only one user, role or policy. Securitain brings these objects together so that identity security can be investigated as a connected system.
Why IAM becomes difficult
Consider a user with no directly attached administrator policy. At first glance, the user may appear low risk. But:
User ↓ Member of Group ↓ Group Policy ↓ sts:AssumeRole ↓ Privileged Role ↓ Production
Or:
Developer ↓ iam:PassRole ↓ Privileged Execution Role ↓ AWS Service ↓ Sensitive Capability
The security question therefore is not simply:
Which policies are attached to this user?
It is:
What access can this identity obtain after all relevant permissions, trust relationships and policy layers are considered?
IAM Analyzer
The Securitain IAM Analyzer organizes identity investigation into several areas:
Overview Inventory Credentials Policies
Users Access Keys Analyzer
Groups Root Account Least Privilege
Roles MFA & Passwords Effective Permissions
Policies Sensitive Permissions
Access Keys Boundaries
Permission Sets
Exposure Escalation Graph Governance
Cross-Account Relationships Identity Center
Trust Policies Organizations & SCPs
Resource Policies Remediation
Federation Exceptions
Compliance Mapping
Findings Reports
Overview
Get a high-level view of IAM posture across the selected account scope. Use Overview to identify areas that deserve deeper investigation before moving into individual identities or findings.
Scan Status
Understand the source and freshness of the IAM information currently displayed. Scan Status provides context around connected AWS accounts, recent IAM assessments, scan completion state, assessment errors and data freshness.
Security conclusions should always be interpreted in the context of the assessment that produced them.
Inventory
Inventory provides the underlying AWS identity objects used throughout IAM analysis. Depending on available account information, this includes:
- Users — IAM users discovered in the connected account.
- Groups — IAM groups and their membership relationships.
- Roles — IAM roles, including relevant trust and privilege context.
- Policies — managed and supported inline policy information.
- Access Keys — credential information associated with IAM identities.
- Permission Sets — supported IAM Identity Center permission-set information.
Inventory is the starting point. Securitain's deeper analysis connects these objects to permissions, findings, trust and reachability.
Findings
Findings identify security-relevant conditions discovered during assessment. A finding can include affected entity, AWS account, severity, security category, supporting evidence, explanation, remediation guidance, compliance mappings and lifecycle state.
A finding should not simply tell you that something failed. It should provide enough evidence to understand what was detected and why it matters.
Credentials
Credential analysis focuses on identity authentication and credential hygiene. Areas can include:
Access Keys
Understand active credentials and supported security signals related to their usage or age.
Root Account
Review supported root-account security indicators.
MFA & Passwords
Investigate interactive IAM identity controls such as MFA and supported password/console-access conditions.
Credential risk should be interpreted according to identity type. A human IAM user capable of console login and a workload identity with no interactive login path represent different security situations.
Policies
Policies are the foundation of AWS authorization, but attached policies are only one part of the access decision. Securitain provides several policy-focused views:
- Policy Analyzer — investigate policy characteristics and security-relevant permission patterns.
- Least Privilege — use supported usage and access information to investigate permissions that may be broader than operational requirements.
- Effective Permissions — understand access after considering relevant authorization layers rather than reading attached policies in isolation.
- Sensitive Permissions — focus on permissions that can have a greater security consequence.
- Permission Boundaries — understand how AWS permissions boundaries affect the maximum capabilities available to a principal.
Exposure
Exposure examines how identities and AWS resources can become reachable beyond their expected trust boundary.
- Cross-Account — investigate relationships with other AWS accounts.
- Trust Policies — understand who or what a role trusts.
- Resource Policies — investigate access granted directly through supported AWS resource policies.
- Federation — understand trust involving OIDC, SAML and supported federated identity patterns.
Cross-account access is not automatically a vulnerability. Many enterprise architectures intentionally use central security, deployment, shared-services and vendor accounts. The goal is to distinguish expected trust from risky or overly broad trust.
Escalation
Privilege escalation analysis focuses on situations where a principal may be able to obtain a stronger capability than its initial permissions suggest. Examples of escalation concepts can include passing a privileged role to an AWS service, changing IAM policy configuration, modifying role trust, creating or changing credentials, and chaining permissions into a stronger outcome.
A detected condition should be evaluated together with its policy scope, trust requirements and other restrictions. The presence of one sensitive permission does not automatically prove that an escalation path is executable.
Graph
The IAM Relationship Graph provides a connected view of selected IAM relationships. Instead of browsing separate inventory tables, teams can visually follow relationships such as:
User ↓ member of Group ↓ policy Policy
The graph is particularly useful when investigating identities that participate in several relationships. Read IAM Relationship Graph →
Governance
IAM risk continues after detection. Governance connects technical findings with organizational decisions.
- IAM Identity Center — understand supported enterprise identity assignments and permission sets.
- Organizations & SCPs — review organization and Service Control Policy context where available.
- Remediation — review guidance for resolving supported security findings.
- Exceptions — document approved risk decisions without pretending the underlying technical condition disappeared.
- Compliance Mapping — connect supported findings with relevant security-control frameworks.
Reports
Reports present IAM information for different audiences and security questions, covering areas such as IAM posture, findings, blast radius, least privilege, attack-path analysis and compliance.
Three ways to investigate IAM
There is no single correct entry point.
Start with an identity
Use this when investigating a particular user or role.
Identity → Groups → Policies → Effective access → Roles → Resources → Findings
Start with a finding
Use this when responding to a security alert.
Finding → Evidence → Identity → Permission → Relationships → Consequence → Remediation
Start with a resource
Use this when protecting a sensitive system or data store.
Sensitive Resource ← Resource policy ← Permission ← Role ← Identity
This last approach becomes especially useful when combined with Identity-to-Data Intelligence.
IAM analysis is evidence-dependent
Not every AWS authorization decision can be reduced to a single attached policy. Conditions can depend on factors such as:
- identity policy
- resource policy
- trust policy
- permission boundary
- Service Control Policy
- explicit deny
- request context
- runtime conditions
For this reason, Securitain distinguishes confirmed information from partial or unavailable evaluation.