Identity security & governance for Amazon Web Services
AWS access spans IAM users, cross-account role trust relationships, and workload identities, and overlapping policies hide the true blast radius of every identity. Oleria maps IAM permissions, cross-account trusts, and CloudTrail activity into a continuous identity security graph without storing long-lived credentials.
.png){kind=small}
Key Takeaways
- AWS access spans IAM users, cross-account role trust relationships, and workload identities across multiple accounts, and overlapping permission policies from inline policies, managed policies, and SCPs hide the true blast radius of every identity without graph traversal.
- IAM roles assumable by EC2 instances, Lambda functions, and cross-account principals accumulate permissions through hidden trust chains that no identity provider-level governance tool can inventory or certify.
- Oleria builds a continuous AWS identity security graph from IAM users, roles, policies, cross-account trusts, and CloudTrail activity, showing which permissions are exercised versus which represent dormant standing access without storing long-lived credentials.
- Continuous AWS access certification through Oleria identifies over-privileged IAM roles, unused cross-account trust relationships, public S3 bucket misconfigurations, and service accounts with permissions that exceed documented workload requirements.
This summary was created with AI and reviewed by an editor.
Ask AI to write a summary
Featured event: A CISO’s take
Join Jim Alkove and Ramy Houssaini to learn how forward-thinking security teams are addressing Enterprise AI Copilot risks.
Eliminate standing IAM privilege, untangle assumed roles, and stop S3 leaks
Oleria's Amazon Web Services (AWS) integration gives security teams one view of who and what can access AWS resources, how that access is granted, and whether it is used. It brings AWS identity governance into a continuous, real-time identity security graph, without storing long-lived credentials.
Access in AWS spans IAM users, cross-account trust and workload identities, and overlapping policies hide the true blast radius. Oleria adds CloudTrail activity to show what is really used.
Why is AWS access so hard to govern?
Identity governance and administration (IGA) tools only evaluate identity at the single sign-on (SSO) or identity provider level. They miss how permissions spread across accounts:
- Hidden role chains. Unmonitored trust policies let identities hop across AWS accounts without a central audit trail.
- Unchecked workload identities. EC2 instance profiles, Lambda roles and CI/CD pipelines often run with admin privileges and unrotated access keys.
- Policy overlap. Managed policies, inline policies and permission boundaries combine in ways that obscure true effective access.
- Exposed S3 buckets. Misconfigured bucket policies or access control lists (ACLs) can expose customer data or backups.
What Oleria shows you in AWS
How security teams use Oleria with AWS
- Shrink workload blast radius. Find over-privileged EC2 instance profiles and CI/CD accounts, then enforce least privilege.
- Close public S3 buckets. Inspect bucket policies and ACLs continuously to surface and revoke public access.
- Map cross-account trust. See role assumption paths across all member accounts to block unintended lateral movement.
- Right-size unused privilege. Compare IAM policies with CloudTrail logs and flag permissions unused for 30, 60 or 90 days.
How does Oleria connect to AWS?
Oleria connects in minutes through AWS CloudFormation and cross-account IAM role assumption with purpose-scoped trust policies. No long-lived API keys or credentials are stored. Deploy as a StackSet at the Organization level for multi-account estates, or as a standard template on one account. Oleria runs an initial full inventory scan, then continuous incremental updates.
For step-by-step setup, read the Oleria AWS IAM and S3 integration guide.
AWS identity governance FAQs
What is AWS identity governance?
AWS identity governance is the practice of controlling which people and workloads can access AWS resources, and whether they still need that access. Oleria supports it by calculating effective IAM permissions across every account, then comparing those permissions with CloudTrail activity to find unused, risky or publicly exposed access.
How does Oleria connect to AWS without long-lived keys?
Oleria authenticates to AWS using IAM role assumption (assume-role). You deploy an Oleria-specific IAM role through AWS CloudFormation, and that role grants Oleria temporary, short-lived session access. No long-lived AWS API keys or credentials are stored, and the session access expires on its own.
Does Oleria cover every account in an AWS Organization?
Yes. When the CloudFormation template is deployed as a StackSet at the AWS Organization level, Oleria automatically discovers and governs IAM permissions across all child accounts. Security teams get one view of users, roles and cross-account trust paths across a multi-account AWS estate.
How do you find unused IAM permissions in AWS?
Oleria correlates granted AWS IAM permissions with real-time AWS CloudTrail activity logs. Oleria then surfaces standing privileges that have not been exercised in 30, 60 or 90 days, so security teams can right-size AWS policies to what each identity actually uses.
Can Oleria detect public S3 buckets?
Yes. Oleria maps Amazon S3 bucket policies, ACLs and public block configurations to find buckets exposed to the public or external accounts. Security teams can then revoke public S3 access directly from Oleria, and the action can be reversed if needed.
See who and what can really reach your AWS data. Book a demo.
