Lesson 04 — Enterprise Identity Federation, Zero Trust Access & Privileged Access Architecture

Learning Path

☁️ Phase 02 – AWS Cloud Security

📘 Module 12 – AWS Security Architecture

🎯 Lesson Objective

By the end of this lesson, you will be able to:

Explain enterprise identity architecture in AWS.
Differentiate workforce, customer and workload identities.
Design identity federation for a multi-account AWS environment.
Explain AWS IAM Identity Center.
Integrate an external identity provider with AWS.
Explain SAML 2.0 and OpenID Connect federation.
Design permission sets for different enterprise roles.
Apply Role-Based Access Control and Attribute-Based Access Control.
Use IAM roles and temporary AWS credentials.
Explain AWS Security Token Service.
Design secure cross-account access.
Apply Zero Trust principles to identity decisions.
Design just-in-time privileged access.
Establish privileged access management controls.
Design emergency and break-glass access.
Apply permissions boundaries, session policies and Service Control Policies.
Secure workload identities for EC2, containers, Lambda and external systems.
Monitor identity activity using CloudTrail and IAM Access Analyzer.
Conduct enterprise access reviews and identity-security assessments.

📚 Lesson Information

Estimated Time: 7–8 Hours
Difficulty: Advanced
Prerequisites: Lesson 03 — Enterprise Network Segmentation, VPC Design & Secure Connectivity
Hands-on Labs: Yes
Primary Role: AWS Security Architect / Cloud Identity Engineer / IAM Engineer

💼 Business Scenario

CloudNova Technologies now operates:

150 AWS accounts
Multiple AWS Regions
5,000 employees
900 software developers
150 platform engineers
80 security professionals
External contractors
Business partners
Automated CI/CD pipelines
Amazon EC2 workloads
Amazon ECS and Amazon EKS platforms
AWS Lambda applications
Hybrid workloads outside AWS

CloudNova uses Microsoft Entra ID as its corporate identity provider.

The current AWS access model has several weaknesses:

IAM users exist in individual AWS accounts.
Developers maintain long-term access keys.
Shared administrator accounts are still used.
Contractors retain access after projects end.
Production access is granted permanently.
Users have different permissions in different accounts.
Some application roles have wildcard permissions.
Cross-account trust policies are overly broad.
Emergency accounts are not regularly tested.
Privileged sessions are not consistently monitored.
Access reviews are performed manually.
Workloads outside AWS use stored access keys.
No formal privileged access management process exists.

A recent internal investigation discovers that a former contractor still has active access to a development account.

The contractor cannot directly access production, but the development account contains a role that trusts an entire external AWS account.

The CISO asks:

“How can CloudNova ensure that every person and workload receives only the correct access, for the correct reason, for the minimum required time?”

As the AWS Security Architect, you must design CloudNova’s enterprise identity, federation and privileged-access architecture.

Identity Is the New Security Perimeter

Traditional security architectures relied heavily on network boundaries.

Inside Corporate Network

↓

Trusted

Outside Corporate Network

↓

Untrusted

Modern cloud environments cannot rely on network location alone.

Users and workloads may connect from:

Corporate offices
Home networks
Mobile devices
CI/CD platforms
SaaS services
Partner networks
Multiple AWS accounts
Multiple Regions

The modern security decision becomes:

Who is requesting access?

↓

How was the identity verified?

↓

What resource is being requested?

↓

What action is required?

↓

What context applies?

↓

How long should access remain active?

↓

How will the activity be monitored?

Identity therefore becomes a primary security control.

Enterprise Identity Architecture

Enterprise identity architecture defines how identities are:

Created
Verified
Authenticated
Authorised
Provisioned
Monitored
Reviewed
Suspended
Removed

A complete architecture includes:

Identity Source

↓

Authentication

↓

Federation

↓

Authorisation

↓

Temporary Session

↓

Resource Access

↓

Monitoring and Review

CloudNova Identity Reference Architecture

                        CloudNova Employees
                                 │
                                 ▼
                       Microsoft Entra ID
                                 │
                 Authentication, MFA and Lifecycle
                                 │
                                 ▼
                    AWS IAM Identity Center
                                 │
             ┌───────────────────┼───────────────────┐
             │                   │                   │
       Permission Sets      User Attributes      Group Mapping
             │                   │                   │
             └───────────────────┼───────────────────┘
                                 │
                         AWS Organizations
                                 │
       ┌─────────────────────────┼─────────────────────────┐
       │                         │                         │
 Security Accounts       Production Accounts       Development Accounts
       │                         │                         │
       └─────────────────────────┼─────────────────────────┘
                                 │
                            IAM Roles
                                 │
                      AWS STS Temporary Sessions
                                 │
              CloudTrail + Access Analyzer + Security Hub

Identity Types

CloudNova separates identities into three major categories:

Workforce identities
Customer identities
Workload identities

Workforce Identities

Workforce identities represent people working for or supporting the organisation.

Examples:

Employees
Administrators
Developers
Security analysts
Auditors
Contractors
Support engineers
Business partners

Workforce identities should normally originate from a central identity provider.

Corporate Identity Provider

↓

AWS IAM Identity Center

↓

AWS Account Roles

↓

Temporary Credentials

Customer Identities

Customer identities represent users of CloudNova applications.

Examples:

SecurePay customers
Retail users
Mobile application users
External application users
Partner-portal users

Customer identities should not normally be created as IAM users.

Possible customer-identity services include:

Amazon Cognito
External customer identity platforms
OpenID Connect providers
SAML identity providers
Custom identity systems

SecurePay Customer

↓

Customer Identity Service

↓

Application Token

↓

SecurePay Application

↓

Authorised Business Action

Workload Identities

Workload identities represent software, services and machines.

Examples:

EC2 instances
Lambda functions
ECS tasks
EKS workloads
CI/CD pipelines
External servers
Automation tools
SaaS platforms

Workloads should use roles and short-lived credentials wherever possible.

Application Workload

↓

Assigned IAM Role

↓

AWS STS Credentials

↓

Authorised AWS API Request

Human vs Machine Identities

Area	Human Identity	Machine Identity
Example	Developer	Lambda function
Authentication	MFA and federation	Role or workload identity
Session	Interactive	Programmatic
Credentials	Temporary user session	Temporary role credentials
Lifecycle	HR-driven	Deployment-driven
Monitoring	Sign-ins and privileged actions	API activity and behavioural patterns
Common Risk	Account takeover	Credential theft or excessive permissions

Human and machine identities require separate governance processes.

Authentication and Authorisation

Authentication

Authentication answers:

Who are you?

Examples:

Password
MFA
Hardware security key
Certificate
SAML assertion
OIDC token

Authorisation

Authorisation answers:

What are you allowed to do?

Examples:

Read an S3 object
Start an EC2 instance
Assume a production role
View Security Hub findings
Create an IAM policy

Authentication

↓

Identity Verified

↓

Authorisation

↓

Requested Action Evaluated

↓

Allow or Deny

Identity Federation

Identity federation allows users authenticated by an external identity system to access AWS without maintaining separate IAM-user credentials.

Employee

↓

Corporate Identity Provider

↓

Federation Assertion

↓

AWS

↓

Temporary Role Session

Benefits include:

Central identity lifecycle
Single sign-on
Central MFA
Temporary credentials
Faster access revocation
Better auditability
Reduced IAM-user usage
Consistent access policies

AWS IAM Identity Center

AWS IAM Identity Center provides centralised workforce access to AWS accounts and supported applications.

It can manage:

Users
Groups
Permission sets
Account assignments
Application access
Multi-account access
Identity-provider integration

CloudNova uses IAM Identity Center to connect its corporate identity provider to AWS Organizations.

IAM Identity Center Architecture

Microsoft Entra ID

↓

AWS IAM Identity Center

↓

CloudNova Groups

↓

Permission Sets

↓

AWS Accounts

↓

IAM Roles and Temporary Sessions

Identity Sources

IAM Identity Center can use an identity source such as:

IAM Identity Center directory
Microsoft Active Directory
External identity provider

CloudNova uses Microsoft Entra ID as the authoritative workforce identity source.

External Identity Provider Integration

The external identity provider performs authentication.

IAM Identity Center provides AWS account and application access.

User Signs In

↓

Microsoft Entra ID Validates User

↓

MFA and Conditional Access Evaluated

↓

Federated Assertion Sent

↓

IAM Identity Center Maps User and Group

↓

Permission Set Applied

↓

Temporary AWS Session Created

Identity Lifecycle Management

Identity lifecycle includes:

Joiner

↓

Employee or Contractor Created

↓

Mover

↓

Role or Department Changes

↓

Leaver

↓

Access Suspended and Removed

CloudNova integrates access lifecycle with:

Human Resources
Contractor management
Identity provider
IAM Identity Center
Access-review processes

Joiner Process

When a new employee joins:

HR creates an approved employee record.
The identity provider creates the identity.
The employee is assigned to approved groups.
IAM Identity Center receives the identity and group membership.
Approved permission sets become available.
MFA registration is completed.
Access is validated.
Activity is monitored.

Mover Process

When an employee changes role:

Old group memberships are reviewed.
Unnecessary access is removed.
New access requires approval.
Conflicting permissions are checked.
Privileged access is reassessed.
Access changes are logged.

Access must not simply accumulate throughout an employee’s career.

Leaver Process

When a person leaves:

Identity-provider access is disabled.
Active sessions are revoked where possible.
Group membership is removed.
Application assignments are removed.
API keys and tokens are reviewed.
Owned resources are transferred.
Privileged activity is reviewed.
Evidence is retained.

SAML 2.0 Federation

Security Assertion Markup Language 2.0 is commonly used for browser-based enterprise federation.

User

↓

Identity Provider

↓

SAML Assertion

↓

AWS Federation Service

↓

AssumeRoleWithSAML

↓

Temporary AWS Credentials

A SAML assertion may include:

User identity
Group membership
Role mapping
Session attributes
Authentication context

SAML Federation Flow

1. User authenticates to Identity Provider
2. Identity Provider verifies MFA and policy
3. Identity Provider generates signed SAML assertion
4. AWS validates assertion
5. AWS role is selected
6. AWS STS issues temporary credentials
7. User accesses authorised AWS resources

OpenID Connect

OpenID Connect is an identity layer built on OAuth 2.0.

OIDC is commonly used for:

Web applications
Mobile applications
CI/CD platforms
Kubernetes workloads
External automation

External Workload

↓

OIDC Provider

↓

Signed Token

↓

AWS STS AssumeRoleWithWebIdentity

↓

Temporary AWS Credentials

SAML vs OIDC

Area	SAML 2.0	OpenID Connect
Common Use	Enterprise workforce federation	Modern applications and workloads
Token Format	XML assertion	JSON Web Token
Typical Access	Browser-based enterprise SSO	Applications, APIs and automation
AWS STS Operation	AssumeRoleWithSAML	AssumeRoleWithWebIdentity
Example	Employee access	GitHub Actions deployment

AWS Security Token Service

AWS Security Token Service issues temporary security credentials.

Temporary credentials include:

Access key ID
Secret access key
Session token
Expiration time

Trusted Identity

↓

AWS STS

↓

Temporary Credentials

↓

Authorised AWS API Access

↓

Automatic Expiration

Why Temporary Credentials Are Safer

Temporary credentials:

Expire automatically
Reduce long-term exposure
Support role assumption
Can use session policies
Improve traceability
Reduce credential-rotation burden
Support federation
Limit access duration

Long-term credentials remain valid until they are rotated, disabled or deleted.

IAM Roles

An IAM role is an AWS identity with permissions that can be assumed by a trusted principal.

A role contains:

Trust policy
Permissions policies
Optional permissions boundary
Session-duration configuration
Tags

Trust Policy

The trust policy defines who or what can assume the role.

Example cross-account trust policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/CloudNovaFederationRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

This is safer than trusting an entire external account without additional restrictions.

Permissions Policy

The permissions policy defines what the role can do after it is assumed.

Example read-only S3 policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::cloudnova-reports",
        "arn:aws:s3:::cloudnova-reports/*"
      ]
    }
  ]
}

Trust vs Permissions

Trust Policy

Who can assume the role?

↓

Role Session Created

↓

Permissions Policy

What can the role do?

Both must be secure.

A restrictive permissions policy cannot prevent an untrusted identity from attempting to assume a poorly configured role.

A restrictive trust policy cannot compensate for excessive permissions after assumption.

Cross-Account Access

Cross-account access allows a principal in one AWS account to assume a role in another account.

Security Engineer

↓

IAM Identity Center

↓

Security Account Role

↓

Assume Cross-Account Role

↓

Production Account

↓

Temporary Read-Only Session

Cross-Account Access Flow

Source Principal

↓

sts:AssumeRole Permission

↓

Target Role Trust Policy

↓

AWS STS Evaluation

↓

Temporary Credentials

↓

Target Account Access

Both sides must permit the action:

The source identity must be permitted to call sts:AssumeRole.
The target role must trust the source principal.

Secure Cross-Account Trust

CloudNova restricts trust using:

Exact principal ARNs
Organisation ID conditions
External IDs
Source identity
Session tags
MFA conditions
Short session duration
Explicit role naming
Access monitoring

AWS Organisation Condition

A resource or trust policy can restrict access to principals from a specific AWS organisation.

Example:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalOrgID": "o-exampleorgid"
    }
  }
}

This condition should be combined with appropriate principal and authorisation controls.

External ID

An external ID helps reduce the confused deputy risk when granting third-party access.

CloudNova

↓

Creates Third-Party Role

↓

Requires Unique External ID

↓

Third Party Assumes Role

↓

AWS Verifies External ID

Example trust condition:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::444455556666:role/PartnerAccessRole"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "cloudnova-securepay-audit-2026"
    }
  }
}

The external ID is not a replacement for a securely designed principal relationship.

Source Identity

Source identity allows an organisation to preserve the original identity across role sessions.

Example:

Rohit.Mahajan

↓

Federated Session

↓

Assumes SecurityAuditRole

↓

CloudTrail Records Source Identity

↓

Investigation Links Activity to Original User

Source identity improves traceability across role chains.

Role Chaining

Role chaining occurs when one assumed role is used to assume another role.

Federated User

↓

Role A

↓

Role B

Role chaining can complicate:

Session duration
Identity traceability
Permission analysis
Troubleshooting
Incident investigation

CloudNova minimises unnecessary role chaining.

Permission Sets

A permission set in IAM Identity Center defines the permissions a user or group receives in assigned AWS accounts.

Examples:

CloudNova-Developer
CloudNova-Production-ReadOnly
CloudNova-Security-Auditor
CloudNova-Billing-Viewer
CloudNova-Network-Administrator
CloudNova-Emergency-Administrator

Permission sets can contain:

AWS-managed policies
Customer-managed policy references
Inline policies
Permissions boundaries
Session-duration settings
Relay-state configuration

CloudNova Permission-Set Design

Permission Set	Assigned Group	Accounts	Session Duration
Developer	Development Teams	Development	8 hours
Production ReadOnly	Engineering Leads	Production	2 hours
Security Auditor	Security Team	All workload accounts	4 hours
Network Administrator	Network Team	Network accounts	1 hour
Incident Responder	Incident Response Team	Approved accounts	1 hour
Emergency Administrator	Break-Glass Team	Restricted accounts	30 minutes

Session durations should reflect risk.

Role-Based Access Control

Role-Based Access Control assigns access according to job function.

User

↓

Job Role

↓

Group

↓

Permission Set

↓

AWS Account Access

Examples:

Business Role	AWS Access
Developer	Development deployment permissions
Security Analyst	Security findings and logs
Auditor	Read-only evidence access
Network Engineer	Network-management permissions
Finance Analyst	Billing and cost reports

RBAC Benefits

Easy to understand
Maps to job functions
Supports access reviews
Simplifies onboarding
Supports separation of duties
Reduces individual policy assignment

RBAC Challenges

Role explosion
Excessive broad roles
Difficult exception handling
Access accumulation
Static permission design

RBAC is often combined with ABAC.

Attribute-Based Access Control

Attribute-Based Access Control uses attributes to make access decisions.

Attributes may include:

Department
Project
Environment
Cost centre
Data classification
Employment type
Region
Application name

Principal Attribute

Project = SecurePay

↓

Resource Tag

Project = SecurePay

↓

Access Permitted

ABAC Example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    }
  ]
}

This allows users to manage resources matching their project attribute.

Session Tags

Session tags can carry attributes into an assumed-role session.

Examples:

Department = Security
Project = SecurePay
Environment = Production
EmploymentType = Employee

Session tags can support:

ABAC
Cost attribution
Audit trails
Conditional access
Resource-policy decisions

RBAC vs ABAC

Area	RBAC	ABAC
Decision Basis	Job role	Attributes
Example	Security Analyst	Project equals SecurePay
Management	Group and role based	Tag and attribute based
Scalability	Can create many roles	Can reduce role count
Complexity	Easier initially	Requires strong attribute governance
Best Use	Stable job functions	Dynamic resource ownership

Permissions Boundaries

A permissions boundary defines the maximum identity-based permissions that an IAM user or role can receive.

Identity Policy

Allows:
Create IAM roles

Permissions Boundary

Allows:
Create only approved application roles

Effective Permission

Intersection of both

A permissions boundary does not grant permissions by itself.

Permissions-Boundary Use Case

CloudNova allows development teams to create workload roles.

Without a boundary:

Developer

↓

Creates Administrator Role

↓

Privilege Escalation

With a boundary:

Developer

↓

Creates Workload Role

↓

Mandatory Permissions Boundary

↓

Role Cannot Exceed Approved Limit

Session Policies

A session policy can restrict permissions for a specific assumed-role session.

Role Permission

Allows:
Read all approved production logs

Session Policy

Allows:
Read logs for Incident INC-204 only

Effective Session

Restricted to incident scope

Session policies cannot grant permissions beyond the role’s existing permissions.

Effective Permissions

Effective access may be influenced by:

Identity-based policy
Resource-based policy
Permissions boundary
Session policy
Service Control Policy
Resource Control Policy where applicable
Explicit deny
AWS service-specific controls

Conceptually:

Requested Action

↓

Identity Policy

↓

Resource Policy

↓

Permissions Boundary

↓

Session Policy

↓

SCP

↓

Explicit Deny Check

↓

Allow or Deny

An explicit deny generally overrides an allow.

Service Control Policies and Identity

Service Control Policies define the maximum available permissions for identities in member accounts.

Example:

IAM Role Allows:
Disable CloudTrail

SCP Denies:
cloudtrail:StopLogging
cloudtrail:DeleteTrail

Result:
Action Denied

SCPs do not grant permissions.

They define organisational boundaries.

Zero Trust Identity Principles

CloudNova applies the following Zero Trust principles:

Verify explicitly.
Use least privilege.
Assume compromise.
Use temporary credentials.
Evaluate context.
Limit session duration.
Require strong authentication.
Record privileged activity.
Continuously review access.
Revoke access quickly.

Zero Trust Access Decision

Access Request

↓

Verify User or Workload Identity

↓

Validate MFA or Workload Token

↓

Check Device and Session Context

↓

Check Role and Attributes

↓

Check Organisation Guardrails

↓

Grant Minimum Required Session

↓

Monitor Behaviour

↓

Revoke When Risk Changes

Context-Aware Access

Access decisions may consider:

User identity
Authentication strength
Device compliance
Geographic location
Network source
Time of request
Requested AWS account
Requested role
Resource sensitivity
Current threat intelligence
Existing incident status

AWS policy conditions can support parts of this decision.

The external identity provider may enforce additional context before issuing federation access.

Multi-Factor Authentication

MFA requires more than one authentication factor.

Factors may include:

Something the user knows
Something the user has
Something the user is
A cryptographic authenticator

CloudNova requires MFA for:

Workforce authentication
Privileged access
Emergency access
Sensitive application access
High-risk changes

MFA Strategy

CloudNova prioritises:

Hardware security keys for highly privileged users
Strong phishing-resistant authentication where supported
Authenticator applications for standard users
Controlled recovery procedures
No shared MFA devices
Regular MFA-registration reviews

Root User Security

Every AWS account contains a root user.

The root user has unrestricted account-level authority.

CloudNova protects root users by:

Using unique email addresses
Enabling MFA
Avoiding routine use
Not creating root access keys
Protecting recovery channels
Monitoring root sign-in
Testing emergency access procedures
Storing credentials securely
Restricting access to authorised custodians

Root User Usage

Root access may be required for a limited number of account-specific tasks.

It must not be used for:

Daily administration
Application deployment
Security monitoring
Developer access
Routine billing work
API automation

Privileged Access

Privileged access allows actions with significant security or operational impact.

Examples:

Modifying IAM policies
Changing SCPs
Disabling logging
Modifying KMS key policies
Changing network routes
Deleting backups
Accessing restricted data
Changing production infrastructure
Disabling security services

Privileged Access Management

Privileged Access Management controls how elevated access is:

Requested
Approved
Granted
Monitored
Revoked
Reviewed

Access Request

↓

Business Justification

↓

Manager or System Owner Approval

↓

Security Approval Where Required

↓

Temporary Privileged Role

↓

Monitored Session

↓

Automatic Expiration

↓

Post-Access Review

Standing vs Just-in-Time Access

Standing Access

The user permanently holds privileged permissions.

Administrator

↓

Administrator Access Available Every Day

Risk:

Credentials may be compromised at any time.
Privilege may be used accidentally.
Access may remain after responsibilities change.

Just-in-Time Access

Access is granted only when required.

Engineer Requests Access

↓

Approval

↓

Temporary Role Assignment

↓

Short Session

↓

Automatic Expiration

Just-in-Time Access Architecture

Engineer

↓

Access Request Portal

↓

Ticket and Business Justification

↓

Approval Workflow

↓

Temporary Group or Role Assignment

↓

IAM Identity Center Permission Set

↓

Short-Lived AWS Session

↓

CloudTrail Monitoring

↓

Automatic Revocation

Just-Enough Access

Just-enough access provides only the permissions required for the approved task.

Example:

Incorrect:

Incident Responder

↓

AdministratorAccess

Preferred:

Incident Responder

↓

View Logs
Isolate EC2 Instance
Revoke Role Session
Capture Evidence

Privileged Role Categories

CloudNova separates privileged roles.

Role	Purpose
Identity Administrator	Manage identity configuration
Security Administrator	Manage security services
Network Administrator	Manage network controls
KMS Administrator	Manage encryption keys
Incident Responder	Contain and investigate incidents
Production Operator	Perform approved operational actions
Billing Administrator	Manage financial settings
Organisation Administrator	Manage AWS Organizations and SCPs

No single routine role should control every security domain.

Separation of Duties

Separation of duties prevents one individual from completing a sensitive process without oversight.

Example:

Developer

Creates Change

↓

Reviewer

Approves Change

↓

Pipeline

Deploys Change

↓

Security Team

Monitors Result

Another example:

KMS Administrator

Manages Key

But Cannot Decrypt Data

Data Operator

Uses Key

But Cannot Change Key Policy

Toxic Permission Combinations

A toxic combination occurs when separate permissions together allow privilege escalation or control bypass.

Examples:

Create role + attach policy + pass role
Update Lambda code + privileged Lambda execution role
Modify pipeline + production deployment role
Create access key for another user
Modify KMS key policy + access encrypted data
Change CloudTrail configuration + delete audit logs
Modify Security Group + access sensitive workload

Access reviews should evaluate combinations, not only individual permissions.

IAM PassRole

iam:PassRole allows a principal to assign an IAM role to an AWS service.

Example:

Developer

↓

Launches Lambda Function

↓

Passes Execution Role

↓

Lambda Receives Role Permissions

If iam:PassRole is too broad, a user may assign an overly privileged role to a service they control.

Secure PassRole Policy

Restrict:

Which roles may be passed
Which services may receive the role
Which resource path or naming convention is allowed

Example:

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::111122223333:role/application/securepay-*",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "lambda.amazonaws.com"
    }
  }
}

Break-Glass Access

Break-glass access provides emergency access when normal identity systems are unavailable.

Possible scenarios:

Corporate identity provider outage
IAM Identity Center outage or misconfiguration
Federation failure
Emergency security incident
Locked administrative configuration

Break-Glass Architecture

Normal Access Unavailable

↓

Emergency Declared

↓

Authorised Custodians Approve

↓

Break-Glass Credential Retrieved

↓

MFA Required

↓

Emergency Role Used

↓

All Activity Logged and Alerted

↓

Credential Rotated After Use

↓

Formal Post-Incident Review

Break-Glass Controls

CloudNova requires:

Separate emergency identities
Strong MFA
No daily use
Secure credential storage
Dual control where practical
Immediate alerting
Short session duration
Restricted permissions
Regular testing
Credential rotation after use
Formal incident documentation

Break-Glass Anti-Patterns

❌ Shared administrator password in a document.

❌ No MFA.

❌ Permanent access keys.

❌ No monitoring.

❌ No named owner.

❌ Never testing the process.

❌ Using the emergency identity for normal operations.

AWS Account Root vs Break-Glass Role

These are not always the same.

Root User

Account-Level Ultimate Authority

Break-Glass Role

Emergency Administrative Access for Defined Tasks

A break-glass role should be designed with only the required emergency permissions.

Root access should remain protected separately.

Workload Identity for Amazon EC2

EC2 applications should use IAM roles through instance profiles.

EC2 Instance

↓

Instance Profile

↓

IAM Role

↓

Temporary Credentials from Instance Metadata

↓

AWS API

Applications should not store access keys on the instance.

EC2 Metadata Security

CloudNova requires:

Instance Metadata Service Version 2
Restricted metadata access where possible
Least-privilege instance roles
No credentials in user data
Monitoring of metadata-related attacks
Regular role reviews

Workload Identity for AWS Lambda

Lambda functions use execution roles.

Lambda Function

↓

Execution Role

↓

Temporary AWS Credentials

↓

Approved AWS Services

Each function or tightly related function group should use a purpose-specific role.

Avoid one shared Lambda role with broad access.

Workload Identity for Amazon ECS

ECS separates:

Task execution role
Task role

Task Execution Role

Used by ECS for actions such as:

Pulling container images
Sending logs
Retrieving deployment-time configuration

Task Role

Used by the application running inside the container.

ECS Service

├── Execution Role
│   └── Platform Operations
│
└── Task Role
    └── Application Permissions

Workload Identity for Amazon EKS

EKS workloads should not rely on broad worker-node permissions.

Preferred patterns provide workload-specific identity.

Kubernetes Service Account

↓

Workload Identity Association

↓

IAM Role

↓

Temporary Credentials

↓

AWS Service

Benefits include:

Pod-level permissions
Reduced node-role privileges
Better isolation
Better auditability
Least privilege

Workload Identity for CI/CD

CI/CD systems should use federation rather than stored AWS access keys.

Example:

GitHub Actions

↓

GitHub OIDC Token

↓

AWS IAM OIDC Provider

↓

Deployment Role

↓

Temporary STS Credentials

↓

Approved Deployment

Secure CI/CD Trust Policy

The role trust policy should restrict:

Repository
Branch
Environment
Organisation
Audience
Workflow context

Conceptual example:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
    },
    "StringLike": {
      "token.actions.githubusercontent.com:sub": "repo:cloudnova/securepay:ref:refs/heads/main"
    }
  }
}

IAM Roles Anywhere

IAM Roles Anywhere allows workloads outside AWS to obtain temporary AWS credentials using trusted X.509 certificates.

Example:

On-Premises Server

↓

X.509 Certificate

↓

IAM Roles Anywhere

↓

AWS STS Credentials

↓

Approved AWS Service

This can reduce reliance on stored IAM access keys for external workloads.

Service Roles

A service role is assumed by an AWS service to perform actions on behalf of the customer.

Examples:

CloudFormation execution role
CodeBuild service role
Lambda execution role
AWS Backup role

Service roles must be:

Purpose-specific
Least privilege
Protected from unauthorised passing
Monitored
Reviewed

Service-Linked Roles

A service-linked role is associated with a specific AWS service and includes permissions required by that service.

CloudNova should:

Understand why each role exists.
Monitor role creation.
Avoid unnecessary manual modification.
Review service dependencies before deletion.

Long-Term Access Keys

CloudNova prohibits routine long-term access keys for human users.

Where legacy access keys still exist:

Assign an owner.
Document the business justification.
Restrict permissions.
Store securely.
Monitor usage.
Rotate regularly.
Set an expiry and migration plan.
Remove unused keys.

Credential Exposure Risks

Credentials may be exposed through:

Source-code repositories
CI/CD variables
Application logs
Container images
User-data scripts
Shared documents
Developer laptops
Chat platforms
Support tickets
Public code samples

Temporary credentials reduce but do not eliminate exposure risk.

IAM Access Analyzer

IAM Access Analyzer helps identify resource access and validate policies.

Capabilities include:

External-access findings
Internal-access analysis
Unused-access analysis
Policy validation
Custom policy checks
Access previews

External Access Findings

Access Analyzer can identify resources accessible from outside the expected trust boundary.

Examples:

S3 buckets
IAM roles
KMS keys
Lambda functions
SQS queues
Secrets
Resource policies

Resource Policy

↓

Access Analyzer

↓

External Principal Identified

↓

Security Review

↓

Archive, Accept or Remediate

Unused Access Analysis

Unused access analysis may identify:

Unused roles
Unused permissions
Unused access keys
Services not accessed
Actions not used

This supports least-privilege refinement.

Policy Validation

IAM Access Analyzer can identify policy issues such as:

Invalid actions
Overly broad access
Missing conditions
Policy syntax issues
Security warnings
Recommended improvements

IAM Policy Simulation

Policy simulation helps evaluate whether a principal can perform an action.

Example questions:

Can this role delete an S3 bucket?
Can this developer pass an administrator role?
Can this security analyst disable GuardDuty?
Can this pipeline deploy into production?

Simulation supports design and troubleshooting but does not replace real control validation.

Identity Monitoring

CloudNova monitors:

Console sign-ins
Failed authentication
Root-user activity
Role assumptions
Access-key usage
IAM policy changes
Trust-policy changes
Permission-set changes
MFA changes
Identity-provider changes
Privileged API calls
Unusual source locations
Sessions with unexpected duration
Cross-account activity

CloudTrail Identity Events

Important CloudTrail events include:

ConsoleLogin
AssumeRole
AssumeRoleWithSAML
AssumeRoleWithWebIdentity
CreateUser
CreateRole
UpdateAssumeRolePolicy
AttachRolePolicy
PutRolePolicy
CreateAccessKey
DeactivateMFADevice
DeleteTrail
StopLogging

Identity Detection Architecture

AWS Identity Activity

↓

AWS CloudTrail

↓

Central Log Archive

↓

Amazon EventBridge and Detection Rules

↓

Security Hub or SIEM

↓

SOC Investigation

↓

Session Revocation or Account Containment

Identity Threats

CloudNova evaluates threats including:

Credential theft
Session-token theft
MFA fatigue
Phishing
Overprivileged roles
Trust-policy abuse
Cross-account privilege escalation
PassRole abuse
Dormant contractor access
Compromised CI/CD identity
Root-user compromise
Federation misconfiguration
Malicious administrator activity
Workload-role credential theft

Identity Attack Path Example

Developer Credential Compromised

↓

Development Role Assumed

↓

Role Can Pass Privileged Lambda Role

↓

Attacker Deploys Lambda Function

↓

Lambda Assumes Privileged Role

↓

Production Data Accessed

Breaking the Identity Attack Path

Phishing-Resistant MFA

+

Short Session Duration

+

Restricted iam:PassRole

+

Permissions Boundary

+

SCP Guardrail

+

Production Account Isolation

+

CloudTrail Detection

+

Automated Session Revocation

Identity-Based Zero Trust Architecture

                  Corporate Identity Provider

                            │

                 Strong Authentication + MFA

                            │

                  AWS IAM Identity Center

                            │

                  Approved Permission Set

                            │

                    Context Evaluation

                            │

                  Short-Lived STS Session

                            │

               Least-Privilege AWS Account Role

                            │

          CloudTrail + Access Analyzer + Security Hub

                            │

             Continuous Review and Revocation

Access Review Process

CloudNova conducts regular access reviews.

Identity Inventory

↓

Account and Role Assignments

↓

Permission Analysis

↓

Business Owner Review

↓

Remove or Reduce Access

↓

Evidence Recorded

↓

Follow-Up Validation

Access Review Questions

Does the user still work for CloudNova?
Does the user still perform this role?
Is the account assignment still required?
Is production access required?
Is the permission set too broad?
Has the access been used recently?
Are conflicting roles assigned?
Does the user hold emergency access?
Is the contractor end date valid?
Are workload identities still active?

Access Review Frequency

Access Type	Suggested Review
Standard development access	Quarterly
Production read-only access	Quarterly
Privileged administrative access	Monthly
Emergency access	Monthly and after every use
Contractor access	Monthly and at contract milestones
Third-party access	Monthly or contract-defined
Workload roles	Every major release and quarterly
Root-user controls	Monthly verification

Review frequency should reflect organisational risk and compliance obligations.

Identity Governance Metrics

CloudNova tracks:

Metric	Purpose
Active IAM Users	Measure legacy identity usage
Long-Term Access Keys	Identify persistent credentials
Keys Older Than Policy Limit	Detect rotation failures
Privileged Permission Sets	Track elevated access
Standing Production Access	Measure unnecessary privilege
Root-User Events	Identify critical account activity
Dormant Accounts	Detect unused identities
Unused Roles	Reduce attack surface
External Trust Relationships	Review third-party access
Access Review Completion	Measure governance maturity
JIT Access Duration	Confirm temporary privilege
Break-Glass Activations	Detect emergency access
MFA Coverage	Measure authentication strength
Cross-Account Role Assumptions	Monitor organisational access

Identity Architecture Ownership

Component	Primary Owner
Corporate Identity Provider	Enterprise Identity Team
IAM Identity Center	Cloud Identity Team
Permission Sets	Cloud Identity and Security Teams
Account Assignments	Business and Platform Owners
Service Control Policies	Cloud Governance Team
Workload Roles	Application and Platform Teams
Privileged Access Workflow	Security and IT Operations
Break-Glass Process	Security Leadership
Access Reviews	Identity Governance and Business Owners
Identity Monitoring	Security Operations Centre
Root Credentials	Authorised Account Custodians

Identity Architecture Decision Records

Important identity decisions should be documented.

Example:

Decision ID:
ADR-IAM-004

Title:
Use Microsoft Entra ID with AWS IAM Identity Center

Business Context:
CloudNova requires central workforce authentication across 150 AWS accounts.

Selected Option:
Use Entra ID as the authoritative identity provider and IAM Identity Center for AWS account assignments.

Security Benefits:
• Central MFA
• Central lifecycle management
• Temporary credentials
• Consistent account access
• Reduced IAM-user usage
• Improved auditability

Residual Risks:
• Identity-provider outage may affect AWS access
• Group misconfiguration may grant excessive access

Additional Controls:
• Break-glass access
• Group-change monitoring
• Regular access reviews
• Privileged group approval

🛠 Lab 01 — Design CloudNova Enterprise Identity Architecture

Objective

Create a high-level identity architecture for CloudNova’s 150 AWS accounts.

Include

Microsoft Entra ID
IAM Identity Center
AWS Organizations
Permission sets
Workforce groups
Production accounts
Development accounts
Security accounts
Temporary credentials
CloudTrail
IAM Access Analyzer
Break-glass process

Deliverables

Identity architecture diagram
Identity ownership matrix
Authentication flow
Authorisation flow
Identity-monitoring design

🛠 Lab 02 — Design Workforce Groups and Permission Sets

Objective

Create a scalable permission-set model.

Required Groups

Cloud Developers
Platform Engineers
Security Analysts
Incident Responders
Network Engineers
Auditors
Billing Analysts
Emergency Administrators

Deliverable

Group	Permission Set	Accounts	Session Duration	Approval Required
Cloud Developers	Developer	Development	8 hours	Standard assignment
Platform Engineers	Production Operator	Production	1 hour	JIT approval
Security Analysts	Security ReadOnly	All accounts	4 hours	Manager approval
Emergency Administrators	Emergency Admin	Restricted accounts	30 minutes	Dual approval

🛠 Lab 03 — Design Cross-Account Access

Objective

Design secure access from the Security Tooling account to production workload accounts.

Requirements

Exact trusted role
Read-only default access
Source identity
Short session duration
CloudTrail logging
Organisation restriction
No wildcard principal
Incident-response elevation process

Deliverables

Source role policy
Target trust policy
Target permissions policy
Role-assumption flow
Monitoring requirements

🛠 Lab 04 — Build a Role Trust Policy

Objective

Create a trust policy for a security-audit role.

Example

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSecurityAuditRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/CloudNovaSecurityFederationRole"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalOrgID": "o-exampleorgid"
        }
      }
    }
  ]
}

Review

Is the trusted principal exact?
Is the organisation restricted?
Is MFA required where appropriate?
Is source identity preserved?
Is the session duration limited?
Is role assumption monitored?

🛠 Lab 05 — Implement an ABAC Design

Objective

Design project-based access using principal and resource tags.

Required Attributes

Project
Environment
Department
DataClassification

Example Rule

Users may start or stop EC2 instances only when:

Principal Project Tag

Matches

Resource Project Tag

Deliverables

Attribute catalogue
Attribute owner
Tagging standard
IAM policy
Exception process
Tag-integrity controls

🛠 Lab 06 — Design Just-in-Time Production Access

Objective

Create a JIT access process for platform engineers.

Required Workflow

Engineer Requests Production Access

↓

Ticket Created

↓

Business Justification Entered

↓

Manager Approval

↓

Application Owner Approval

↓

Temporary Permission-Set Assignment

↓

One-Hour Session

↓

CloudTrail Monitoring

↓

Automatic Revocation

↓

Post-Access Review

Deliverables

Access-request form
Approval matrix
Permission set
Session duration
Monitoring rules
Revocation procedure
Evidence requirements

🛠 Lab 07 — Design Break-Glass Access

Objective

Create an emergency-access procedure.

Include

Emergency role
Authorised custodians
MFA
Dual approval
Credential storage
Alerting
Session monitoring
Automatic expiry
Post-use credential rotation
Post-incident review
Quarterly test

Deliverable

Create a complete break-glass runbook.

🛠 Lab 08 — Secure a CI/CD Workload Identity

Objective

Design OIDC federation for a CI/CD platform.

Requirements

No long-term AWS access key
OIDC provider
Restricted repository
Restricted branch
Restricted audience
Dedicated deployment role
Permissions boundary
Short session
CloudTrail monitoring

Deliverables

OIDC trust policy
Deployment permissions policy
Role-session configuration
Threat model
Incident-response process

🛠 Lab 09 — Review IAM Access Analyzer Findings

Objective

Review external and unused access.

Tasks

Identify:

Roles trusted by external accounts
Public or cross-account resource policies
Unused access keys
Unused IAM roles
Broad wildcard permissions
Roles not used recently
Trust policies without conditions

Deliverable

Finding	Risk	Severity	Recommendation	Owner
Role trusts external account root	Uncontrolled role assumption	High	Trust exact role and require external ID	IAM Team
Access key unused for 120 days	Dormant credential	Medium	Disable and remove key	Application Owner

🛠 Lab 10 — Perform an Enterprise Identity Security Assessment

Objective

Assess the following environment:

150 AWS accounts
300 IAM users
180 long-term access keys
Shared administrator role
No central federation
Permanent production access
Broad cross-account trust
No access reviews
No break-glass testing
Workloads using embedded keys

Deliverables

Current-state assessment
Identity risk register
Target-state architecture
IAM Identity Center migration plan
Privileged access strategy
Workload identity migration plan
Access-review process
Monitoring requirements
Ninety-day remediation plan
Executive summary

💻 AWS Console Walkthrough — Create and Review an IAM Role

Step 1 — Open IAM

Sign in to the AWS Management Console.
Search for IAM.
Open the IAM console.
Select Roles.
Choose Create role.

Step 2 — Select Trusted Entity

Select the appropriate trusted-entity type:

AWS service
AWS account
Web identity
SAML federation
Custom trust policy

For cross-account access, select the approved AWS account or use a carefully reviewed custom trust policy.

Step 3 — Configure Trust

Define:

Exact trusted principal
External ID where required
MFA requirement where required
Organisation conditions
Session-tag controls

Step 4 — Assign Permissions

Attach only the permissions required for the role.

Avoid using:

AdministratorAccess

unless the role has a formally approved emergency or administrative requirement.

Step 5 — Configure Role

Provide:

Role name:
CloudNovaSecurityAuditRole

Description:
Read-only cross-account role for approved CloudNova security analysts

Add ownership and classification tags.

Step 6 — Review the Trust Policy

Confirm:

No unnecessary wildcard principals
Correct account IDs
Correct role ARN
Required conditions
No external account root unless explicitly justified

Step 7 — Review Maximum Session Duration

Set the shortest practical session duration.

Example:

Security audit:
4 hours

Production operations:
1 hour

Emergency administration:
30 minutes

💻 AWS Console Walkthrough — Review IAM Identity Center

Step 1 — Open IAM Identity Center

Search for IAM Identity Center.
Confirm the Region where IAM Identity Center is configured.
Review the current identity source.

Step 2 — Review Users and Groups

Review:

User status
Group membership
Privileged groups
Contractor identities
Dormant accounts
Duplicate accounts

Step 3 — Review Permission Sets

For each permission set, confirm:

Business purpose
Attached policies
Inline policy
Permissions boundary
Session duration
Account assignments
Named owner

Step 4 — Review AWS Account Assignments

Confirm that:

Development groups access development accounts.
Production access is restricted.
Security teams have appropriate read-only access.
Privileged assignments require approval.
Contractors have defined end dates.
Emergency roles are tightly controlled.

💻 AWS CLI Lab

Verify Current Identity

Run in Git Bash or PowerShell:

aws sts get-caller-identity

List IAM Users

aws iam list-users

List IAM Roles

aws iam list-roles

Get a Role

aws iam get-role \
  --role-name CloudNovaSecurityAuditRole

Review a Role Trust Policy

aws iam get-role \
  --role-name CloudNovaSecurityAuditRole \
  --query 'Role.AssumeRolePolicyDocument'

List Policies Attached to a Role

aws iam list-attached-role-policies \
  --role-name CloudNovaSecurityAuditRole

List Inline Role Policies

aws iam list-role-policies \
  --role-name CloudNovaSecurityAuditRole

Create a Trust Policy File

Create:

trust-policy.json

Add:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/CloudNovaSecurityFederationRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Create an IAM Role

aws iam create-role \
  --role-name CloudNovaSecurityAuditRole \
  --assume-role-policy-document file://trust-policy.json \
  --description "Cross-account security audit role"

Attach a Read-Only Policy

aws iam attach-role-policy \
  --role-name CloudNovaSecurityAuditRole \
  --policy-arn arn:aws:iam::aws:policy/SecurityAudit

Assume the Role

aws sts assume-role \
  --role-arn arn:aws:iam::TARGET_ACCOUNT_ID:role/CloudNovaSecurityAuditRole \
  --role-session-name cloudnova-security-review \
  --source-identity USER_ID

Record:

AccessKeyId
SecretAccessKey
SessionToken
Expiration

Do not store these credentials in source code or permanent files.

Assume Role with External ID

aws sts assume-role \
  --role-arn arn:aws:iam::TARGET_ACCOUNT_ID:role/CloudNovaPartnerAuditRole \
  --role-session-name partner-audit-session \
  --external-id cloudnova-securepay-audit-2026

List Access Keys

aws iam list-access-keys \
  --user-name IAM_USER_NAME

Get Access-Key Last-Used Information

aws iam get-access-key-last-used \
  --access-key-id ACCESS_KEY_ID

List MFA Devices

aws iam list-mfa-devices \
  --user-name IAM_USER_NAME

Generate a Credential Report

aws iam generate-credential-report

Retrieve the Credential Report

aws iam get-credential-report \
  --output text \
  --query Content

The returned content is encoded and may require decoding before review.

Simulate a Principal Policy

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::ACCOUNT_ID:role/CloudNovaSecurityAuditRole \
  --action-names \
  s3:GetObject \
  iam:CreateUser \
  cloudtrail:StopLogging

List IAM Identity Center Instances

aws sso-admin list-instances

Record the:

Instance ARN
Identity store ID

List Permission Sets

aws sso-admin list-permission-sets \
  --instance-arn IAM_IDENTITY_CENTER_INSTANCE_ARN

Describe a Permission Set

aws sso-admin describe-permission-set \
  --instance-arn IAM_IDENTITY_CENTER_INSTANCE_ARN \
  --permission-set-arn PERMISSION_SET_ARN

List AWS Account Assignments

aws sso-admin list-account-assignments \
  --instance-arn IAM_IDENTITY_CENTER_INSTANCE_ARN \
  --account-id AWS_ACCOUNT_ID \
  --permission-set-arn PERMISSION_SET_ARN

List Access Analyzer Analyzers

aws accessanalyzer list-analyzers

List Active Access Analyzer Findings

aws accessanalyzer list-findings-v2 \
  --analyzer-arn ANALYZER_ARN \
  --filter '{"status":{"eq":["ACTIVE"]}}'

Validate an IAM Policy

Create:

policy.json

Then run:

aws accessanalyzer validate-policy \
  --policy-document file://policy.json \
  --policy-type IDENTITY_POLICY

Review Recent AssumeRole Events

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=root

CloudTrail event availability depends on the configured Region, event history and logging architecture.

✅ Verification Checklist

Verify that you can:

🔍 Troubleshooting

Problem — User Cannot Access an AWS Account Through IAM Identity Center

Review:

User status in the identity provider
User provisioning
Group membership
IAM Identity Center identity source
Permission-set assignment
AWS account assignment
Permission-set provisioning status
Session expiration
Browser or cached session

Problem — AssumeRole Returns Access Denied

Review both sides of the relationship.

Source Side

Confirm that the source principal can call:

sts:AssumeRole

against the target role ARN.

Target Side

Confirm that the role trust policy trusts the source principal.

Also review:

SCPs
Permissions boundaries
Session policies
MFA conditions
External ID
Organisation ID
Source identity requirements
Role ARN
AWS account ID

Run:

aws sts get-caller-identity

Problem — Access Is Allowed Despite Restrictive Identity Policy

Review:

Resource-based policy
Role session
Group policies
Managed policies
Inline policies
Permission-set policies
Resource ownership
Service-specific authorisation behaviour

Do not assume that only one policy affects the request.

Problem — Access Is Denied Despite an Allow Policy

Review:

Explicit deny
SCP
Permissions boundary
Session policy
Resource policy
KMS key policy
VPC endpoint policy
AWS service-specific controls
Region restrictions
Requested resource ARN

Problem — Federated User Has the Wrong Permissions

Review:

Identity-provider group
Group-to-permission-set mapping
Account assignment
Permission-set policy
Attribute mapping
Session tags
Provisioning status
Cached session

The user may need to start a new session after access changes.

Problem — OIDC Workload Cannot Assume Role

Review:

OIDC provider ARN
Token issuer
Token audience
Subject claim
Repository or branch condition
Trust-policy syntax
Token expiration
STS action
AWS Region
Role ARN

Problem — Access Analyzer Reports External Access

Review:

External principal
Resource policy
Trust boundary
Organisation ID
Public access
Business justification
Existing compensating controls

Do not archive the finding without recording why the access is expected.

Problem — Permission Boundary Blocks a Required Action

Review:

Identity policy
Permissions boundary
Resource policy
Required action
Resource ARN
Condition keys

Do not remove the boundary simply to resolve the issue.

Update the approved boundary only after security review.

Problem — Break-Glass Access Does Not Work

Review:

Credential availability
MFA device
Role trust policy
SCP restrictions
Account recovery process
Session duration
Emergency documentation
Responsible custodians

Break-glass access should be tested before an actual emergency.

🏢 Enterprise Best Practices

CloudNova’s identity standards include:

Use a central corporate identity provider.
Use IAM Identity Center for workforce access.
Avoid IAM users for normal human access.
Require MFA for all workforce access.
Use phishing-resistant authentication for privileged users where supported.
Use temporary credentials.
Use exact principals in trust policies.
Restrict external trust using conditions.
Use external IDs for approved third-party access.
Preserve source identity across role sessions.
Use permission sets aligned with business roles.
Apply RBAC for stable job functions.
Apply ABAC for dynamic project and resource access.
Govern principal and resource attributes.
Use permissions boundaries for delegated role creation.
Restrict session duration according to risk.
Use just-in-time access for production.
Use just-enough permissions for privileged tasks.
Separate identity, security, network and key-management duties.
Restrict iam:PassRole.
Protect every AWS account root user.
Maintain tested break-glass procedures.
Use workload roles instead of embedded credentials.
Use OIDC federation for CI/CD systems.
Use workload-specific roles for containers and serverless functions.
Review external and unused access continuously.
Centralise identity logs.
Monitor role assumptions and policy changes.
Conduct regular access reviews.
Remove dormant identities and credentials.
Document every privileged-access exception.

🚫 Common Mistakes

❌ Creating IAM users in every AWS account.

❌ Using long-term access keys for employees.

❌ Sharing administrator accounts.

❌ Granting permanent production access.

❌ Trusting an entire external AWS account unnecessarily.

❌ Using wildcard principals without restrictive conditions.

❌ Assigning AdministratorAccess for convenience.

❌ Using one permission set for all teams.

❌ Failing to remove access when users change roles.

❌ Allowing contractor access without an expiry date.

❌ Ignoring source identity.

❌ Allowing long role sessions for privileged work.

❌ Using network location as proof of identity.

❌ Treating MFA as optional for administrators.

❌ Creating broad permissions boundaries.

❌ Assuming a permissions boundary grants access.

❌ Failing to restrict iam:PassRole.

❌ Giving EC2 applications embedded access keys.

❌ Giving every EKS workload the worker-node role.

❌ Storing CI/CD access keys in repository secrets.

❌ Failing to monitor trust-policy changes.

❌ Archiving Access Analyzer findings without investigation.

❌ Creating break-glass credentials but never testing them.

❌ Using the root user for daily administration.

🧪 DIY Enterprise Challenge

CloudNova is redesigning identity access across 500 AWS accounts.

The organisation has:

12,000 employees
2,500 developers
300 contractors
Multiple business units
Microsoft Entra ID
Global AWS operations
PCI DSS workloads
Financial applications
Central security operations
External audit partners
CI/CD systems
On-premises workloads

Design an enterprise identity architecture that includes:

Identity-source architecture
IAM Identity Center design
Workforce group model
Permission-set catalogue
AWS account-assignment strategy
RBAC model
ABAC model
Attribute-governance standard
Cross-account trust standard
External third-party access standard
AWS STS session strategy
MFA and authentication standard
Privileged access management process
Just-in-time production access
Break-glass architecture
Root-user protection standard
Workload identity strategy
CI/CD OIDC federation
IAM Roles Anywhere design
Access Analyzer architecture
Identity-monitoring rules
Access-review process
Joiner, mover and leaver process
Identity risk register
Executive identity-security summary

📊 Knowledge Check

Why is identity considered a primary cloud-security perimeter?
What is the difference between authentication and authorisation?
What are workforce identities?
What are customer identities?
What are workload identities?
What is identity federation?
What is AWS IAM Identity Center?
What role does an external identity provider perform?
What is SAML 2.0?
What is OpenID Connect?
How does SAML differ from OIDC?
What is AWS Security Token Service?
Why are temporary credentials preferred?
What is an IAM role?
What is a role trust policy?
What is a role permissions policy?
What must be configured on both sides of cross-account access?
What is an external ID?
What is source identity?
What is role chaining?
What is a permission set?
What is Role-Based Access Control?
What is Attribute-Based Access Control?
What are session tags?
How does RBAC differ from ABAC?
What is a permissions boundary?
Does a permissions boundary grant permissions?
What is a session policy?
How do SCPs affect IAM roles?
What does explicit deny mean?
What are the core Zero Trust identity principles?
Why should privileged sessions be shorter than normal sessions?
What is standing privileged access?
What is just-in-time access?
What is just-enough access?
Why is separation of duties important?
What is a toxic permission combination?
Why is iam:PassRole sensitive?
What is break-glass access?
Why must break-glass procedures be tested?
How should EC2 workloads obtain AWS credentials?
What is the difference between an ECS execution role and task role?
Why should EKS workloads avoid broad node-role permissions?
How can CI/CD systems access AWS without stored access keys?
What is IAM Roles Anywhere?
What is IAM Access Analyzer?
What is unused-access analysis?
Which identity events should be monitored in CloudTrail?
What should an enterprise access review evaluate?
How does identity segmentation reduce blast radius?

💡 Key Takeaways

After completing this lesson, you should understand:

Identity is a primary control plane for AWS security and must not depend solely on network location.
Workforce, customer and workload identities require different authentication, authorisation and lifecycle controls.
Enterprise workforce access should use a central identity provider, IAM Identity Center and temporary AWS sessions.
Federation reduces the need for separate IAM users and long-term credentials across AWS accounts.
IAM roles require both a secure trust policy and a least-privilege permissions policy.
AWS STS provides temporary credentials for federated users, cross-account access and workload identities.
Permission sets provide consistent workforce access across AWS Organizations.
RBAC maps access to job functions, while ABAC uses governed attributes to make dynamic access decisions.
Permissions boundaries, session policies and SCPs limit permissions but do not grant access independently.
Zero Trust access verifies identity explicitly, evaluates context and provides minimum required access for a limited duration.
Privileged access should use just-in-time and just-enough access rather than permanent administrator permissions.
Break-glass access must be separate, strongly protected, monitored, tested and reviewed after use.
Workloads should use purpose-specific roles instead of embedded AWS access keys.
OIDC federation allows CI/CD platforms and external workloads to obtain temporary AWS credentials.
IAM Access Analyzer, CloudTrail and access reviews are essential for identifying external, excessive and unused access.
Identity architecture must include strong lifecycle management so that access is adjusted when people join, change roles or leave.
Every privileged identity, role, permission set, trust relationship and exception must have a named owner and documented business purpose.

🚀 Next Lesson

➡️ Lesson 05 — Enterprise Data Protection, Encryption Architecture & AWS KMS Design