In the first part of this series, we explored the foundational elements of AWS Identity and Access Management (IAM): users, groups, roles, and how IAM serves as the security backbone of an AWS environment.
In this second part, we move beyond the basics and examine how AWS enforces permissions, how policies are evaluated, and how advanced access control mechanisms help organizations maintain fine-grained, scalable security in real-world environments.
Understanding IAM Policies at a Deeper Level
At the core of IAM lies the policy evaluation engine. While policies often appear as simple JSON blocks, they collectively form a complex decision system that determines whether a principal (user, role, or service) can perform an action on a resource.
Policy Types You Will Encounter
Identity-based policies
Attached to users, groups, or roles.
These define what the identity can do.Resource-based policies
Attached directly to resources such as S3 buckets, SNS topics, or SQS queues.
These define who can access the resource.Permissions boundaries
Define the maximum permissions an identity-based policy can grant.Service control policies (SCPs)
Used at the AWS Organizations level to enforce global restrictions across accounts.Session policies
Applied during role assumption to provide temporary, scoped permissions.
How AWS Evaluates Permissions
IAM permissions follow a strict evaluation order. No matter how many policies exist, AWS always applies the same logic:
- Explicit Deny → always wins
- Explicit Allow → only if no deny exists
- Implicit Deny → default fallback
A request begins as “denied” by default.
Then IAM looks for explicit allow statements.
If a deny is found at any level, the request is rejected immediately.
This model keeps security predictable and minimizes accidental privilege escalation.
Anatomy of an IAM Policy Statement
A typical policy statement has four key components:
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket/*",
"Condition": {
"IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
}
}
Effect
Determines whether the statement permits or denies access.
Action
Specifies the API operations allowed or denied.
Resource
Defines the ARN of the AWS resource the action applies to.
Condition
Adds contextual constraints such as IP range, MFA usage, encryption settings, VPC endpoint, or time of day.
These four elements allow extremely precise access control.
Condition Keys: The Heart of Fine-Grained Access
While actions and resources define what can be done, condition keys define how, when, or from where an action is permitted.
Common examples:
aws:SourceIp
Restrict from specific IP ranges.aws:MultiFactorAuthPresent
Require MFA for sensitive operations.s3:x-amz-server-side-encryption
Enforce encryption for S3 object uploads.aws:PrincipalTag
Grant permissions based on identity tags.
Condition keys make policies far more expressive and enforce organizational security requirements directly in IAM.
Permission Boundaries: Preventing Privilege Escalation
A permissions boundary sets an upper limit on the permissions a user or role can have. Even if an identity tries to attach an overly permissive policy, the boundary ensures access never exceeds the defined maximum.
Boundaries are essential in situations such as:
- Delegating limited admin capabilities to teams
- Restricting automation tools that create or modify roles
- Ensuring developers cannot grant themselves elevated access
They allow organizations to safely delegate IAM management without risking misconfiguration or privilege abuse.
Using IAM Roles Effectively
IAM roles are central to secure AWS architectures. Beyond the basics, certain patterns are worth highlighting:
1. Service roles
AWS services such as Lambda, ECS, or SageMaker assume these roles to perform actions on your behalf.
2. Cross-account roles
Enable secure access across AWS accounts without sharing long-term credentials.
3. Identity federation roles
Used when integrating SSO, Active Directory, or external identity providers.
A well-structured role strategy significantly reduces operational overhead and improves auditability.
Resource-Based Policies vs Identity-Based Policies
While identity policies define what a principal can do, resource policies define who can access the resource.
Consider an S3 bucket used by multiple accounts. An identity policy alone is insufficient—S3 also requires a bucket policy specifying which external accounts may access it.
Good rule of thumb:
- Identity policies → “What can this identity do?”
- Resource policies → “Who is allowed to interact with this resource?”
Both commonly work together in production systems.
IAM Access Analyzer: Validating Permissions Proactively
IAM Access Analyzer helps detect unintended public or cross-account access.
It uses formal reasoning (automated proofs) to evaluate all policies in your account and highlight risky configurations.
Best Practices for Advanced IAM Usage
- Apply least privilege consistently across all identities and roles
- Use permission boundaries for teams that manage IAM themselves
- Enable MFA for all human users
- Prefer roles over access keys; avoid long-term credentials
- Use tags to drive attribute-based access control (ABAC)
- Regularly review IAM activity using CloudTrail logs
- Monitor policy changes and analyze external access with Access Analyzer
That's it for today peeps! See ya in the next part:)
Top comments (0)