Lesson 02 — Enterprise Identity & Zero Trust Implementation Project

Learning Path

☁️ Phase 02 – AWS Cloud Security

🚀 Enterprise Cloud Security Projects & Capstone Labs

🎯 Lesson Objective

In this project, you will work as CloudNova Technologies’ Lead Cloud Security Engineer and design an enterprise identity and Zero Trust architecture.

You will move beyond creating individual IAM users and policies.

You will build a scalable identity model that supports:

Centralised workforce authentication
Enterprise federation
Multi-account access
Temporary credentials
Role-Based Access Control
Attribute-Based Access Control
Privileged access management
Workload identities
Cross-account access
Emergency access
Identity governance
Continuous access reviews
Zero Trust security principles

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

Explain enterprise identity architecture.
Apply Zero Trust principles to AWS access.
Distinguish human and machine identities.
Design IAM Identity Center architecture.
Integrate an external identity provider.
Design enterprise users and groups.
Create permission-set catalogues.
Implement Role-Based Access Control.
Implement Attribute-Based Access Control.
Design cross-account IAM roles.
Use AWS Security Token Service.
Replace long-term credentials with temporary credentials.
Design privileged access workflows.
Create emergency-access procedures.
Govern joiner, mover and leaver processes.
Design machine identities for AWS workloads.
Configure GitHub Actions access using OpenID Connect.
Apply least privilege.
Review and validate access.
Produce professional enterprise identity documentation.

📚 Lesson Information

Area	Details
Project	CloudNova Enterprise Identity and Zero Trust
Project Type	Identity Architecture, Governance and Implementation
Estimated Time	14–18 Hours
Difficulty	Advanced
Delivery Mode	DIY or Instructor-Led
Primary Services	IAM Identity Center, AWS IAM, AWS STS
Supporting Services	AWS Organizations, CloudTrail, IAM Access Analyzer, AWS Config, EventBridge, SNS
Main Deliverable	Enterprise Identity and Zero Trust Design
Environment	Dedicated training or sandbox AWS environment
Prerequisite	Lesson 01 – Enterprise AWS Landing Zone Project

🏢 Business Scenario

CloudNova Technologies has completed the design of its enterprise AWS landing zone.

The organisation now operates:

A central AWS Organizations structure
Security and infrastructure organisational units
Dedicated production and non-production accounts
Centralised logging
Shared security accounts
An account provisioning process
Multi-account governance

However, identity and access remain inconsistent.

Current challenges include:

Local IAM users exist in many accounts.
Developers have manually created access keys.
Production access is not consistently approved.
Some administrators use permanent credentials.
Access is not removed promptly when employees leave.
Permission models differ between business units.
Security teams cannot easily investigate access across all accounts.
External contractors have excessive permissions.
Cross-account roles are not documented.
Emergency-access procedures are unclear.
Service accounts use long-term access keys.
CI/CD pipelines store credentials in repositories.
Access reviews are conducted manually.
Privileged activity is not centrally monitored.
Identity ownership is unclear.

CloudNova has:

12 business units
500 AWS accounts
8,000 employees
400 developers
150 security engineers
80 network engineers
20 finance users
30 auditors
A 24×7 Security Operations Centre

The Chief Information Security Officer asks:

“How can we provide secure access to hundreds of AWS accounts without relying on permanent credentials, while ensuring least privilege, strong authentication and complete auditability?”

You have been assigned to lead the CloudNova Enterprise Identity and Zero Trust Implementation Project.

🧑‍💼 Your Role

You are working as the:

Lead Cloud Security Engineer

Your responsibilities include:

Gathering identity and access requirements.
Designing enterprise federation.
Configuring IAM Identity Center.
Defining users, groups and permission sets.
Designing role-based access.
Designing attribute-based access.
Establishing privileged-access controls.
Designing cross-account access.
Governing machine identities.
Eliminating unnecessary long-term credentials.
Defining identity lifecycle processes.
Creating access-review procedures.
Building emergency-access processes.
Monitoring identity activity.
Presenting the identity architecture to stakeholders.

1. Enterprise Identity Strategy

Enterprise identity is the foundation of cloud security.

CloudNova must know:

Who is requesting access?
What resource is being accessed?
Why is access required?
From which device and location?
What level of access is appropriate?
How long should access remain active?
Who approved the access?
How will the activity be monitored?
How will the access be removed?

CloudNova’s identity strategy will be based on:

Centralised authentication
Federated access
Strong MFA
Temporary credentials
Least privilege
Separation of duties
Explicit authorisation
Continuous verification
Complete auditability
Automated lifecycle management

2. Zero Trust Security

Zero Trust is a security model based on the principle:

Never trust automatically. Always verify explicitly.

Traditional security models often assume that users inside a trusted network can be trusted.

Zero Trust removes this assumption.

Every access request must be evaluated using identity, context, policy and risk.

Zero Trust Principles

Verify Explicitly

Authenticate and authorise every access request using all available information.

Examples:

User identity
Group membership
Device posture
Location
Requested resource
Requested action
Session age
Authentication method
Risk level

Apply Least Privilege

Grant only the permissions required to perform an approved task.

Assume Breach

Design controls with the assumption that credentials, accounts or workloads may become compromised.

Use Temporary Access

Prefer short-lived sessions instead of long-term credentials.

Continuously Evaluate Access

Access should be reviewed and adjusted as roles, responsibilities and risks change.

3. Enterprise Identity Architecture

CloudNova Workforce

        |

Enterprise Identity Provider

        |

Strong MFA and Conditional Access

        |

AWS IAM Identity Center

        |

Users and Groups

        |

Permission Sets

        |

AWS Organizations

        |

AWS Accounts

        |

IAM Roles

        |

Temporary AWS Credentials

        |

AWS Resources

4. Human and Machine Identities

CloudNova must separately govern human and machine identities.

Human Identities

Examples:

Developers
Security engineers
SOC analysts
Network engineers
Auditors
Finance users
Contractors
Administrators

Human identities should use:

Enterprise identity provider accounts
IAM Identity Center
MFA
Group-based assignments
Temporary role sessions
Access approval workflows

Machine Identities

Examples:

EC2 applications
Lambda functions
ECS tasks
EKS workloads
CI/CD pipelines
Automation tools
Monitoring agents
Backup services

Machine identities should use:

IAM roles
Service roles
Task roles
Instance profiles
Web identity federation
OpenID Connect
Short-lived credentials
Secrets Manager where credentials cannot be avoided

5. Identity Anti-Patterns

CloudNova must avoid:

Shared administrator accounts
IAM users created in every AWS account
Long-term administrator access keys
Credentials stored in source code
Credentials stored in CI/CD variables without rotation
Shared service-account passwords
Generic roles without ownership
Excessive use of wildcard permissions
Permanent production access
Unmonitored emergency accounts
Access granted directly to individual users
Roles without trust-policy restrictions
Access that is never reviewed
Former employees retaining access

6. IAM Identity Center

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

CloudNova will use IAM Identity Center to:

Connect the enterprise identity provider.
Manage workforce access centrally.
Assign users through groups.
Create permission sets.
Provision roles across AWS accounts.
Issue temporary sessions.
Reduce local IAM users.
Simplify multi-account access.
Centralise access auditing.

7. Enterprise Federation

Federation allows users to authenticate through CloudNova’s existing identity platform and access AWS without separate AWS passwords.

Possible identity providers include:

Microsoft Entra ID
Okta
Google Workspace
Active Directory
Ping Identity
Other SAML-compatible providers

Federation Architecture

Employee

   |

Corporate Identity Provider

   |

Authentication and MFA

   |

SAML Federation

   |

IAM Identity Center

   |

Permission Set

   |

IAM Role in AWS Account

   |

Temporary Credentials

8. SAML, OIDC and SCIM

SAML

Security Assertion Markup Language is commonly used for enterprise workforce federation.

It transfers authentication information from an identity provider to a service provider.

OIDC

OpenID Connect is commonly used for modern applications, workload federation and CI/CD integrations.

Examples:

GitHub Actions to AWS
Kubernetes workload identity
External application authentication

SCIM

System for Cross-domain Identity Management supports automatic user and group provisioning.

SCIM can help:

Create users automatically.
Synchronise group membership.
Update identity attributes.
Disable users after termination.
Reduce manual administration.

9. IAM Identity Center Identity Sources

CloudNova may use:

The IAM Identity Center directory
Active Directory
An external identity provider

For an enterprise with thousands of employees, an external identity provider is generally preferred because it allows CloudNova to maintain one authoritative workforce identity source.

10. Enterprise Group Design

Access should normally be assigned through groups rather than directly to users.

Proposed Groups

AWS-Cloud-Platform-Administrators
AWS-Cloud-Security-Administrators
AWS-SOC-Tier-1-Analysts
AWS-SOC-Tier-2-Analysts
AWS-SOC-Incident-Responders
AWS-Network-Administrators
AWS-DevOps-Engineers
AWS-Developers
AWS-Production-Support
AWS-Database-Administrators
AWS-Internal-Auditors
AWS-External-Auditors
AWS-Finance-Viewers
AWS-ReadOnly-Support
AWS-Contractors
AWS-Emergency-Administrators

11. Group-Naming Standard

CloudNova will use:

AWS-<Function>-<Access-Level>

Examples:

AWS-Developers-PowerUser
AWS-Production-ReadOnly
AWS-Security-Administrator
AWS-Finance-BillingViewer
AWS-Audit-ReadOnly

Group names should indicate:

Platform
Team or function
Environment where relevant
Access level
Special restrictions

12. Permission Sets

A permission set defines the access users receive in assigned AWS accounts.

IAM Identity Center provisions IAM roles based on permission sets.

Proposed Permission-Set Catalogue

Permission Set	Purpose	Session Duration
PlatformAdministrator	Enterprise platform administration	1 hour
SecurityAdministrator	Security-service administration	1 hour
SOCAnalystReadOnly	Investigation and monitoring	4 hours
IncidentResponder	Approved containment actions	1 hour
NetworkAdministrator	Enterprise network administration	1 hour
DeveloperPowerUser	Development deployment access	4 hours
ProductionReadOnly	Production troubleshooting	2 hours
DatabaseAdministrator	Managed database administration	1 hour
AuditorReadOnly	Audit and evidence review	4 hours
BillingViewer	Cost and billing visibility	4 hours
EmergencyAdministrator	Emergency privileged access	30 minutes

13. Permission-Set Design Principles

CloudNova permission sets must:

Use least privilege.
Avoid unnecessary wildcard permissions.
Separate read, write and administrative access.
Use shorter sessions for privileged roles.
Include permission boundaries where required.
Avoid direct access to sensitive accounts unless justified.
Use customer-managed policies where greater control is required.
Be reviewed regularly.
Have a clearly assigned owner.
Include a documented business purpose.

14. Role-Based Access Control

Role-Based Access Control assigns permissions according to a user’s job function.

User

↓

Enterprise Group

↓

Permission Set

↓

AWS Account Assignment

↓

IAM Role

↓

AWS Resources

Example RBAC Matrix

Role	Development	Testing	Production	Security Accounts
Developer	Power User	Read Only	Read Only	No Access
DevOps Engineer	Administrator	Administrator	Deployment Access	No Access
Platform Administrator	Administrator	Administrator	Administrator	Limited
Security Engineer	Security Admin	Security Admin	Security Admin	Administrator
SOC Analyst	Read Only	Read Only	Read Only	Investigation Access
Network Engineer	Network Admin	Network Admin	Network Admin	Limited
Auditor	Read Only	Read Only	Read Only	Read Only
Finance User	Billing View	Billing View	Billing View	No Access

15. Attribute-Based Access Control

Attribute-Based Access Control uses attributes or tags to make authorisation decisions.

CloudNova can define attributes such as:

Department
Business unit
Project
Application
Environment
Cost centre
Data classification
Employment type
Support region

Example Identity Attributes

Department = Finance
BusinessUnit = Payments
Project = MobileBanking
Environment = Production
CostCentre = FIN-220
EmploymentType = Employee

Example Resource Tags

Department = Finance
BusinessUnit = Payments
Project = MobileBanking
Environment = Production
CostCentre = FIN-220

ABAC policies can allow users to manage resources only when their identity attributes match resource tags.

16. Example ABAC Policy

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

Test ABAC policies carefully because missing or inconsistent tags may deny legitimate access or create unintended permissions.

17. RBAC and ABAC Together

CloudNova will use a hybrid model.

RBAC will define the broad job function.

ABAC will restrict access to the correct projects, applications and environments.

Example:

Developer Role

+

Project = MobileBanking

+

Environment = Development

=

Developer can manage only MobileBanking development resources

18. Temporary Credentials

Temporary credentials are issued by AWS Security Token Service.

They include:

Access key ID
Secret access key
Session token
Expiration time

Temporary credentials reduce risk because they expire automatically.

They should be preferred for:

Workforce access
Cross-account access
CI/CD pipelines
EC2 workloads
Containers
Lambda functions
External applications
Emergency sessions

19. AWS Security Token Service

AWS STS supports temporary access through operations such as:

AssumeRole
AssumeRoleWithSAML
AssumeRoleWithWebIdentity
GetSessionToken
GetFederationToken

Example AssumeRole Workflow

Security Engineer

↓

Authenticates through IAM Identity Center

↓

Receives Security Administrator Role

↓

Assumes Incident Response Role

↓

Receives Temporary Credentials

↓

Performs Approved Response Action

20. Cross-Account Access

CloudNova security, network and platform teams require access across multiple accounts.

Cross-account access should use IAM roles rather than duplicate IAM users.

Example Security Access Architecture

Security Tooling Account

        |

Security Engineer Role

        |

AWS STS AssumeRole

        |

Production Account

        |

IncidentResponseRole

        |

Approved Investigation and Containment Actions

21. Cross-Account Role Components

A cross-account role requires:

A trust policy
A permissions policy
An authorised source principal
Optional external ID
Optional session tags
Optional MFA condition
Optional source-account restrictions
CloudTrail logging

22. Example Cross-Account Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSecurityAccountIncidentResponders",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/CloudNovaIncidentResponder"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

23. Example Incident Response Permissions

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadInvestigationData",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "iam:Get*",
        "iam:List*",
        "cloudtrail:LookupEvents",
        "guardduty:GetFindings",
        "securityhub:GetFindings"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ContainCompromisedInstances",
      "Effect": "Allow",
      "Action": [
        "ec2:ModifyInstanceAttribute",
        "ec2:ModifyNetworkInterfaceAttribute",
        "ec2:CreateSnapshot",
        "ec2:CreateTags"
      ],
      "Resource": "*"
    }
  ]
}

24. External ID

An external ID helps protect cross-account roles when third parties require access.

It can help reduce confused-deputy risks.

CloudNova must use:

A unique external ID for each third party.
A documented owner.
Formal approval.
Restricted permissions.
Short session duration.
Regular access reviews.
CloudTrail monitoring.

25. Privileged Access Management

Privileged access includes permissions that can materially affect CloudNova’s environment.

Examples:

Organisation administration
IAM administration
KMS administration
Network administration
Security-service administration
Production changes
Logging changes
Incident containment
Billing administration

Privileged access must be:

Approved
Time-bound
Strongly authenticated
Monitored
Logged
Reviewed
Revocable

26. Just-in-Time Access

Just-in-Time access grants privileged permissions only when required.

Example Workflow

Engineer Requests Production Administrator Access

↓

Business Justification Submitted

↓

Manager Approval

↓

Security Approval

↓

Temporary Group Membership

↓

One-Hour Session

↓

CloudTrail Monitoring

↓

Access Automatically Removed

↓

Review and Closure

27. Emergency Access

Emergency access is used when normal identity systems are unavailable or during a critical incident.

CloudNova will maintain a controlled break-glass process.

Emergency Access Requirements

Dedicated emergency role or identity
Strong MFA
Credentials stored securely
Access restricted to named responders
Formal invocation criteria
Immediate notification
Complete logging
Post-use credential rotation
Mandatory post-incident review
Regular testing

28. Emergency Access Workflow

Critical Incident

↓

Normal Access Unavailable or Insufficient

↓

Incident Commander Approval

↓

Emergency Access Activated

↓

SOC and Management Notified

↓

Privileged Session Monitored

↓

Incident Action Completed

↓

Access Revoked

↓

Credentials Rotated

↓

Post-Incident Review

29. Example Emergency Role Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EmergencyAdministration",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/CloudNovaEmergencyAccessBroker"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "NumericLessThanEquals": {
          "sts:DurationSeconds": "1800"
        }
      }
    }
  ]
}

30. Machine Identity Architecture

Machine identities must not use shared human credentials.

Application Workload

↓

AWS-Native Identity Mechanism

↓

IAM Role

↓

Temporary Credentials

↓

Approved AWS Resources

31. EC2 Workload Identity

EC2 applications should use IAM roles attached through instance profiles.

Avoid:

Access keys in configuration files
Access keys in user data
Access keys in environment variables
Shared credentials between instances

32. Lambda Workload Identity

Every Lambda function should use a dedicated execution role.

The execution role should include only the permissions required by the function.

Avoid using one shared Lambda role across unrelated functions.

33. ECS Task Roles

ECS workloads should separate:

Task execution role
Application task role

The task execution role supports ECS operations such as pulling images and writing logs.

The task role provides the application’s AWS permissions.

34. EKS Workload Identity

EKS workloads should use workload-specific identities rather than node-level credentials.

Possible approaches include:

EKS Pod Identity
IAM Roles for Service Accounts
Kubernetes service accounts
OIDC federation

Each workload should receive only the permissions it requires.

35. GitHub Actions and OpenID Connect

CloudNova CI/CD pipelines should use OIDC federation instead of storing long-term AWS access keys in GitHub.

Architecture

GitHub Actions Workflow

↓

GitHub OIDC Token

↓

AWS IAM OIDC Provider

↓

Deployment Role

↓

Temporary AWS Credentials

↓

Approved Deployment Actions

36. Example GitHub OIDC Trust Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowApprovedGitHubRepository",
      "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/security-platform:*"
        }
      }
    }
  ]
}

37. Secrets Management

IAM roles should be used wherever possible.

Where credentials, API keys or passwords are genuinely required, use:

AWS Secrets Manager
AWS Systems Manager Parameter Store
KMS encryption
Automatic rotation
Fine-grained access policies
Access logging
Secret ownership

Never store secrets in:

Source code
Container images
Public repositories
User-data scripts
Shared documents
Unencrypted files
CI/CD logs

38. IAM Policies

CloudNova must understand the policy evaluation model.

Policy types may include:

Identity-based policies
Resource-based policies
Permissions boundaries
Service Control Policies
Session policies
Access Control Lists
Resource Control Policies where applicable

39. Effective Permissions

Effective access depends on the combined result of multiple policy layers.

Organisation Policies

↓

Permissions Boundary

↓

Identity Policy

↓

Resource Policy

↓

Session Policy

↓

Conditions

↓

Explicit Deny Check

↓

Final Authorisation Decision

An explicit deny overrides an allow.

40. Permissions Boundaries

Permissions boundaries define the maximum permissions that an IAM role or user can receive.

CloudNova can use permissions boundaries to allow development teams to create roles without allowing them to create unrestricted administrative roles.

Example Use Case

Developer creates an application role

↓

Permissions boundary applied

↓

Role can access approved application services

↓

Role cannot modify IAM, Organizations, CloudTrail or KMS administration

41. IAM Conditions

Conditions improve policy precision.

Useful condition keys include:

aws:RequestedRegion
aws:PrincipalArn
aws:PrincipalTag
aws:ResourceTag
aws:SourceAccount
aws:SourceArn
aws:MultiFactorAuthPresent
aws:CurrentTime
aws:SecureTransport
sts:ExternalId

42. Identity Threat Model

Threat	Potential Impact	Primary Control
Credential theft	Unauthorised AWS access	MFA and temporary credentials
Password spraying	Account compromise	Identity-provider protections
Access-key exposure	Workload compromise	IAM roles and secret scanning
Privilege escalation	Administrative control	Least privilege and monitoring
Session-token theft	Temporary account takeover	Short sessions and context controls
Rogue administrator	Deliberate misuse	Separation of duties and logging
Cross-account abuse	Production compromise	Restricted trust policies
Contractor over-access	Data exposure	Time-bound assignments
Orphaned identities	Persistent unauthorised access	Automated leaver process
CI/CD credential leak	Deployment compromise	OIDC federation
Role chaining abuse	Privilege expansion	Trust-policy restrictions
Emergency-account misuse	Organisation-wide impact	Strong governance and monitoring

43. Joiner, Mover and Leaver Process

Joiner

When a new employee joins:

Corporate identity is created.
Required MFA is enrolled.
Manager confirms job role.
Group membership is assigned.
IAM Identity Center access is provisioned.
Access is validated.
User receives security training.
Evidence is recorded.

Mover

When an employee changes role:

Existing access is reviewed.
Unnecessary groups are removed.
New groups are approved.
Privileged access is reassessed.
Account assignments are updated.
Access is validated.
Evidence is recorded.

Leaver

When an employee leaves:

Corporate identity is disabled.
Active sessions are revoked where possible.
Group memberships are removed.
AWS assignments are removed.
IAM access keys are disabled and deleted.
Owned service accounts are reassigned.
Emergency access is reviewed.
Evidence is recorded.

44. Contractor Access

Contractor access must include:

Named individual identity
Sponsoring manager
Start and expiry dates
Restricted group membership
Least-privilege permission set
Shorter session duration
No permanent production administration
Regular review
Automatic expiry
Immediate removal when the engagement ends

45. Access Reviews

CloudNova will perform:

Monthly privileged-access reviews
Quarterly production-access reviews
Quarterly cross-account role reviews
Quarterly contractor-access reviews
Six-monthly general workforce reviews
Annual architecture reviews
Immediate reviews after security incidents

Access Review Questions

Does the user still require access?
Is the access level appropriate?
Is production access justified?
Is privileged access time-bound?
Is the user still employed?
Is the contractor engagement active?
Are role permissions still used?
Are access keys present?
Are emergency roles tested?
Are any assignments made directly to users?

46. Identity Monitoring

CloudNova will monitor:

Root-user activity
Console sign-ins
Failed authentication attempts
MFA changes
IAM policy changes
Role creation
Trust-policy changes
Access-key creation
AssumeRole events
Permission-set changes
Identity Center assignments
Emergency-access activity
Unusual geographic access
Privilege-escalation attempts

47. Identity Logging Architecture

Corporate Identity Provider Logs

        |

IAM Identity Center Events

        |

AWS CloudTrail

        |

Security Lake

        |

SIEM

        |

SOC Monitoring

        |

Investigation and Response

48. IAM Access Analyzer

IAM Access Analyzer can help identify:

Resources shared externally
Unused access
Public access
Cross-account access
Policy validation issues
Overly broad permissions

CloudNova should use it to support:

Least-privilege reviews
External-access reviews
Policy validation
Role analysis
Access-remediation planning

49. Enterprise Identity Governance

CloudNova must govern:

Identity ownership
Group ownership
Permission-set ownership
Role ownership
Policy approval
Privileged access
Emergency access
External access
Machine identities
Access reviews
Exception management
Identity evidence
Role decommissioning

50. Identity Architecture Review Lifecycle

Identity Requirement

↓

Risk Assessment

↓

Architecture Design

↓

Security Review

↓

Implementation

↓

Validation

↓

Access Monitoring

↓

Periodic Review

↓

Remediation

↓

Continuous Improvement

🛠 Hands-on Project Labs

Lab 01 — Conduct the Enterprise Identity Assessment

Mission

Assess CloudNova’s current human and machine identities.

Student Actions

Create:

02-Enterprise-Identity-Zero-Trust/
└── 01-Assessment/
    └── Current-State-Identity-Assessment.md

Document:

Existing identity providers
IAM users
IAM roles
Access keys
Identity Center status
MFA coverage
Privileged groups
Cross-account roles
CI/CD identities
Service accounts
Contractor identities
Emergency identities
Access-review process
Identity risks

Evidence

Current-state identity diagram
Identity inventory
High-risk findings
Remediation recommendations

Lab 02 — Design IAM Identity Center

Mission

Create CloudNova’s central workforce-access architecture.

Student Actions

Document:

Identity source
Federation protocol
User provisioning
Group synchronisation
MFA ownership
Session durations
Account assignments
Delegated administration
Logging
Business continuity

Required Diagram

Enterprise Identity Provider

↓

IAM Identity Center

↓

Groups

↓

Permission Sets

↓

AWS Accounts

↓

Temporary Role Sessions

Lab 03 — Build the Permission-Set Catalogue

Mission

Create standard enterprise permission sets.

Required Permission Sets

PlatformAdministrator
SecurityAdministrator
SOCAnalystReadOnly
IncidentResponder
NetworkAdministrator
DeveloperPowerUser
ProductionReadOnly
AuditorReadOnly
BillingViewer
EmergencyAdministrator

For every permission set, document:

Business purpose
Target users
Target accounts
Permissions
Session duration
Approval owner
Review frequency
Restrictions

Lab 04 — Build the Enterprise RBAC Matrix

Mission

Map enterprise roles to AWS account access.

Student Actions

Create:

02-Enterprise-Identity-Zero-Trust/
└── 03-RBAC/
    ├── RBAC-Model.md
    └── Account-Assignment-Matrix.md

Include:

Job roles
Enterprise groups
Permission sets
Account types
Access levels
Approval requirements
Session durations

Lab 05 — Design the Enterprise ABAC Model

Mission

Create a tag-based access model.

Required Attributes

Department
BusinessUnit
Project
Application
Environment
CostCentre
DataClassification
EmploymentType

Student Actions

Document:

Identity attributes
Resource tags
Tag ownership
Tag enforcement
Example policies
Missing-tag behaviour
Exception process
Testing approach

Lab 06 — Implement Cross-Account Access

Mission

Design secure cross-account access from the Security Tooling account to a workload account.

Student Actions

Create:

Source role
Destination role
Trust policy
Permissions policy
Session-duration standard
MFA requirement
CloudTrail validation
Role-assumption test

CLI Example

aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/CloudNovaIncidentResponseRole \
  --role-session-name incident-IR-2026-001

Lab 07 — Replace Long-Term CI/CD Credentials

Mission

Design a GitHub Actions OIDC integration.

Student Actions

Document:

OIDC provider
Approved repository
Approved branch or environment
Deployment role
Trust policy
Permissions policy
Session duration
CloudTrail verification
Credential-removal plan

Evidence

Trust-policy file
Deployment-role policy
Workflow architecture
Successful role-assumption evidence

Lab 08 — Build the Privileged-Access Workflow

Mission

Design Just-in-Time access for production administration.

Student Actions

Create a workflow containing:

Access request
Business justification
Manager approval
Security approval
Temporary group assignment
MFA verification
Session monitoring
Automatic expiry
Post-access review

Required Deliverable

Privileged-Access-Runbook.md

Lab 09 — Build the Emergency-Access Procedure

Mission

Create and test the CloudNova break-glass process.

Required Sections

Invocation criteria
Authorised personnel
Credential storage
MFA requirements
Approval process
Notification process
Logging
Credential rotation
Post-incident review
Quarterly test plan

Lab 10 — Conduct the Zero Trust Identity Review

Mission

Present the complete identity architecture to the CloudNova Security Architecture Review Board.

Review Participants

Chief Information Security Officer
Identity Architect
Cloud Security Architect
Cloud Platform Lead
SOC Manager
Internal Audit
Human Resources
Compliance Manager
Application Owners

Review Topics

Federation
MFA
Identity lifecycle
Least privilege
RBAC
ABAC
Privileged access
Emergency access
Machine identities
Cross-account access
Monitoring
Compliance
Business continuity
Identity risks

💻 AWS Console Walkthrough

Students should explore or configure:

IAM Identity Center
Identity source
Users
Groups
Permission sets
AWS account assignments
Session durations
IAM roles
IAM policies
Trust policies
IAM Access Analyzer
CloudTrail role-assumption events
IAM credential reports

💻 AWS CLI Exercises

Run these commands only in an authorised training or sandbox environment.

# Display the current identity
aws sts get-caller-identity

# List IAM roles
aws iam list-roles

# List IAM users
aws iam list-users

# List customer-managed IAM policies
aws iam list-policies \
  --scope Local

# List access keys for a user
aws iam list-access-keys \
  --user-name USER_NAME

# Generate an IAM credential report
aws iam generate-credential-report

# Retrieve the IAM credential report
aws iam get-credential-report

# List IAM Identity Center instances
aws sso-admin list-instances

# List permission sets
aws sso-admin list-permission-sets \
  --instance-arn INSTANCE_ARN

# Describe a permission set
aws sso-admin describe-permission-set \
  --instance-arn INSTANCE_ARN \
  --permission-set-arn PERMISSION_SET_ARN

# List AWS accounts
aws organizations list-accounts

# List account assignments
aws sso-admin list-account-assignments \
  --instance-arn INSTANCE_ARN \
  --account-id ACCOUNT_ID \
  --permission-set-arn PERMISSION_SET_ARN

Assume a Cross-Account Role

aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/CloudNovaAuditRole \
  --role-session-name cloudnova-audit-review

Simulate Policy Permissions

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:role/CloudNovaDeveloperRole \
  --action-names s3:GetObject s3:DeleteObject iam:CreateUser

Validate an IAM Policy

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

List External Access Analyzer Findings

aws accessanalyzer list-findings-v2 \
  --analyzer-arn ANALYZER_ARN

✅ Technical Verification Checklist

Federation

Enterprise identity source is documented.
Federation protocol is defined.
MFA ownership is defined.
User and group provisioning is documented.
Identity-provider failure procedures exist.

IAM Identity Center

IAM Identity Center architecture is documented.
Enterprise groups are defined.
Permission sets are documented.
Account assignments are approved.
Session durations are appropriate.
Direct user assignments are minimised.

RBAC and ABAC

RBAC matrix is complete.
ABAC attributes are documented.
Resource-tag standards are defined.
Missing-tag behaviour is documented.
Tag ownership is assigned.
Policies have been tested.

Privileged Access

Privileged roles are identified.
Just-in-Time workflow is documented.
Production access requires approval.
Emergency access is documented.
Emergency access is regularly tested.
Privileged sessions are monitored.

Machine Identities

EC2 workloads use IAM roles.
Lambda functions use dedicated execution roles.
ECS tasks use task roles.
EKS workloads use workload identities.
CI/CD uses temporary credentials.
Long-term keys have documented exceptions.

Governance

Joiner process is documented.
Mover process is documented.
Leaver process is documented.
Contractor access has expiry dates.
Access-review schedule exists.
Role ownership is recorded.
Policy exceptions are documented.

Monitoring

CloudTrail captures IAM activity.
Identity-provider events are monitored.
AssumeRole events are reviewed.
Root-user activity is monitored.
Access-key creation is monitored.
Permission changes generate alerts.

🔧 Troubleshooting Guide

Issue 1 — User Cannot Access an Assigned AWS Account

Possible causes:

User is not in the correct identity-provider group.
Group synchronisation has not completed.
Account assignment is missing.
Permission set has not been provisioned.
User session is stale.

Resolution:

Verify the user’s group membership.
Confirm SCIM synchronisation.
Review the AWS account assignment.
Reprovision the permission set.
Ask the user to sign out and begin a new session.
Review CloudTrail and IAM Identity Center events.

Issue 2 — AssumeRole Returns Access Denied

Possible causes:

Source principal is not trusted.
Permissions do not allow sts:AssumeRole.
MFA condition is not satisfied.
External ID is incorrect.
SCP blocks the action.
Permissions boundary limits access.

Resolution:

Review the destination trust policy.
Review the source-role permissions.
Verify MFA.
Confirm the external ID.
Review SCPs.
Review permissions boundaries.
Check CloudTrail for the denial context.

Issue 3 — ABAC Policy Does Not Allow Access

Possible causes:

Principal tag is missing.
Resource tag is missing.
Tag values do not match.
Incorrect condition operator.
Session tags were not passed.
Explicit deny applies.

Resolution:

Inspect principal tags.
Inspect resource tags.
Confirm exact tag spelling and case.
Review policy conditions.
Validate session-tag configuration.
Use policy simulation.

Issue 4 — GitHub OIDC Role Assumption Fails

Possible causes:

OIDC provider is missing.
Audience condition is incorrect.
Repository subject condition is incorrect.
Workflow lacks token permission.
Role trust policy is too restrictive.
Branch or environment does not match.

Resolution:

Confirm the IAM OIDC provider.
Review the token audience.
Review the subject claim.
Confirm workflow permissions.
Review repository, branch and environment restrictions.
Review CloudTrail role-assumption events.

Issue 5 — Access Remains After Employee Departure

Possible causes:

Corporate identity was not disabled.
SCIM synchronisation failed.
Direct account assignment remains.
Local IAM user exists.
Access key remains active.
Emergency group membership was not removed.

Resolution:

Disable the enterprise identity.
Remove group memberships.
Remove direct assignments.
Review local IAM users.
Disable and delete access keys.
Revoke active sessions where possible.
Run a complete leaver-access review.

Issue 6 — Privileged Role Has Excessive Permissions

Possible causes:

AWS-managed administrator policy was used.
Custom policy contains wildcards.
Permission boundary is absent.
Role accumulated permissions over time.
Access requirements were not reviewed.

Resolution:

Analyse CloudTrail usage.
Use IAM Access Analyzer.
Create a least-privilege policy.
Add a permissions boundary.
Remove unused permissions.
Perform a peer review.
Document approved exceptions.

🏢 Enterprise Best Practices

CloudNova identity standards:

Use IAM Identity Center for workforce access.
Integrate with the enterprise identity provider.
Require strong MFA.
Use temporary credentials.
Avoid IAM users wherever possible.
Never share identities.
Assign access through groups.
Use separate permission sets for separate duties.
Keep privileged sessions short.
Apply least privilege.
Use RBAC and ABAC together.
Use dedicated workload roles.
Use OIDC for CI/CD systems.
Avoid storing AWS access keys.
Restrict cross-account trust policies.
Require approval for production access.
Use Just-in-Time privileged access.
Maintain emergency-access procedures.
Monitor all role assumptions.
Review access regularly.
Remove access immediately when no longer required.
Assign owners to all roles and permission sets.
Use IAM Access Analyzer.
Validate IAM policies before deployment.
Record and review identity exceptions.

🚫 Common Mistakes

Creating IAM users in every AWS account.
Using permanent administrator access keys.
Assigning access directly to individual users.
Reusing one role for unrelated teams.
Granting production administrator access permanently.
Using shared service accounts.
Failing to require MFA.
Using broad wildcard permissions.
Ignoring trust-policy security.
Allowing external access without an external ID.
Storing AWS keys in GitHub.
Giving all EKS pods the node role.
Sharing one Lambda execution role.
Failing to remove former employees.
Not expiring contractor access.
Treating Zero Trust as a product rather than an operating model.
Relying only on network location.
Failing to monitor role assumptions.
Not testing emergency access.
Leaving unused roles and policies active.
Ignoring permission-set session duration.
Using tags without governance.
Applying ABAC without mandatory tagging.
Failing to document identity ownership.

📦 Required Project Deliverables

Students must create the following project files:

CloudNova-Enterprise-Security/

└── 02-Enterprise-Identity-Zero-Trust/
    ├── README.md
    ├── 01-Assessment/
    │   ├── Current-State-Identity-Assessment.md
    │   ├── Identity-Inventory.md
    │   └── Identity-Risk-Assessment.md
    ├── 02-Architecture/
    │   ├── Enterprise-Identity-Architecture.md
    │   ├── IAM-Identity-Center-Design.md
    │   ├── Federation-Design.md
    │   └── Zero-Trust-Architecture.md
    ├── 03-RBAC/
    │   ├── RBAC-Model.md
    │   ├── Group-Catalogue.md
    │   ├── Permission-Set-Catalogue.md
    │   └── Account-Assignment-Matrix.md
    ├── 04-ABAC/
    │   ├── ABAC-Design.md
    │   ├── Identity-Attributes.md
    │   ├── Resource-Tagging-Model.md
    │   └── Example-Policies/
    ├── 05-Privileged-Access/
    │   ├── Privileged-Access-Policy.md
    │   ├── Just-in-Time-Access-Workflow.md
    │   ├── Emergency-Access-Runbook.md
    │   └── Privileged-Access-Review.md
    ├── 06-Machine-Identity/
    │   ├── Workload-Identity-Standard.md
    │   ├── EC2-and-Lambda-Roles.md
    │   ├── EKS-Identity-Design.md
    │   └── GitHub-OIDC-Design.md
    ├── 07-Cross-Account/
    │   ├── Cross-Account-Access-Model.md
    │   ├── Trust-Policy-Standards.md
    │   └── Cross-Account-Access-Matrix.md
    ├── 08-Governance/
    │   ├── Joiner-Mover-Leaver-Process.md
    │   ├── Contractor-Access-Standard.md
    │   ├── Access-Review-Procedure.md
    │   ├── Identity-Exception-Process.md
    │   └── Role-Ownership-Register.md
    ├── 09-Monitoring/
    │   ├── Identity-Monitoring-Strategy.md
    │   ├── Identity-Alert-Catalogue.md
    │   └── Identity-Investigation-Runbook.md
    ├── 10-Evidence/
    │   ├── Screenshots/
    │   ├── CLI-Outputs/
    │   ├── Policy-Validation/
    │   └── Verification-Checklist.md
    └── 11-Reports/
        ├── Identity-Architecture-Review.md
        ├── Executive-Identity-Strategy.md
        ├── Risk-Register.md
        └── Lessons-Learned.md

🧪 DIY Enterprise Challenge

CloudNova acquires a financial-technology company called SecurePay Systems.

SecurePay currently has:

40 AWS accounts
600 employees
120 IAM users
75 active access keys
Local administrator users in production accounts
Several shared service accounts
GitHub pipelines using permanent AWS credentials
No IAM Identity Center
No central MFA standard
Contractors with permanent production access
Undocumented cross-account roles
No formal access-review process
No emergency-access procedure
Multiple workloads using administrator roles

Design a complete identity migration and Zero Trust implementation plan.

Your submission must include:

Current-state identity assessment
IAM user and access-key remediation plan
Identity-provider integration design
IAM Identity Center design
Group catalogue
Permission-set catalogue
RBAC matrix
ABAC design
Production-access workflow
Contractor-access remediation
GitHub OIDC migration
Machine-identity standard
Cross-account access review
Emergency-access procedure
Joiner, mover and leaver process
Access-review schedule
Identity threat model
Migration sequence
Rollback plan
Executive summary

📊 Knowledge Check

Question 1

What is the primary objective of Zero Trust?

Answer:
To verify every access request explicitly, apply least privilege and avoid automatically trusting users or devices based only on location.

Question 2

Why should enterprise users access AWS through IAM Identity Center?

Answer:
It centralises workforce access, supports federation, uses temporary sessions and simplifies access across multiple AWS accounts.

Question 3

What is the difference between RBAC and ABAC?

Answer:
RBAC grants access based on job roles, while ABAC uses identity and resource attributes such as department, project and environment.

Question 4

Why should RBAC and ABAC be used together?

Answer:
RBAC establishes broad job-function permissions, while ABAC restricts those permissions to the correct applications, projects or environments.

Question 5

Why are temporary credentials safer than long-term access keys?

Answer:
Temporary credentials expire automatically and reduce the period during which stolen credentials can be abused.

Question 6

What service issues temporary AWS credentials?

Answer:
AWS Security Token Service.

Question 7

What is the purpose of an IAM role trust policy?

Answer:
It defines which principals are allowed to assume the role and under which conditions.

Question 8

What is a permission set?

Answer:
A permission set defines the permissions and session settings that IAM Identity Center provisions as a role in assigned AWS accounts.

Question 9

Why should access be assigned through groups?

Answer:
Group-based access is easier to govern, review and remove than direct assignments to individual users.

Question 10

What is Just-in-Time access?

Answer:
It provides privileged permissions only when required, usually after approval and for a limited duration.

Question 11

What is emergency or break-glass access?

Answer:
It is tightly controlled privileged access used when normal access mechanisms are unavailable or insufficient during a critical incident.

Question 12

What should happen after emergency access is used?

Answer:
The session should be reviewed, credentials rotated, evidence preserved and a post-incident review completed.

Question 13

How should EC2 applications receive AWS permissions?

Answer:
Through an IAM role attached to the EC2 instance using an instance profile.

Question 14

How should GitHub Actions access AWS?

Answer:
Through OIDC federation and a restricted IAM role that issues temporary credentials.

Question 15

What is the purpose of SCIM?

Answer:
SCIM automates user and group provisioning, updates and deactivation between identity systems.

Question 16

What is the purpose of an external ID?

Answer:
It helps protect cross-account roles used by third parties from confused-deputy risks.

Question 17

What is an IAM permissions boundary?

Answer:
It defines the maximum permissions an IAM user or role can receive, even if broader permissions are attached.

Question 18

What happens when an explicit deny and an allow both apply?

Answer:
The explicit deny overrides the allow.

Question 19

Why must production access be reviewed regularly?

Answer:
Roles and responsibilities change, so previously justified access may become excessive or unnecessary.

Question 20

What is the purpose of the joiner, mover and leaver process?

Answer:
It ensures access is correctly granted, changed and removed throughout an individual’s employment lifecycle.

Question 21

Why should contractors have expiry dates?

Answer:
Automatic expiry reduces the risk of contractor access remaining active after the engagement ends.

Question 22

Why should separate Lambda functions use separate execution roles?

Answer:
Dedicated roles reduce blast radius and allow each function to receive only the permissions it requires.

Question 23

Why should EKS workloads avoid using node-role permissions?

Answer:
Node-role credentials may give multiple workloads excessive access. Workload-specific identities provide stronger isolation.

Question 24

How can IAM Access Analyzer support least privilege?

Answer:
It can identify external access, unused permissions, public sharing and policy-validation issues.

Question 25

What is the final outcome of this project?

Answer:
A secure, scalable and auditable enterprise identity architecture based on federation, temporary credentials, least privilege, Zero Trust and continuous governance.

💡 Key Takeaways

After completing this lesson, you should understand that enterprise identity is not limited to creating IAM policies.

A mature identity platform combines:

Enterprise federation
IAM Identity Center
Strong MFA
Temporary credentials
Role-Based Access Control
Attribute-Based Access Control
Cross-account roles
Privileged-access management
Emergency access
Machine identities
Identity monitoring
Access reviews
Automated identity lifecycle management

A strong identity architecture helps CloudNova ensure that the correct person or workload receives the correct access to the correct resource for the correct period of time.

🎓 Project Completion Criteria

You have completed this project when:

The current identity environment has been assessed.
The federation architecture is documented.
IAM Identity Center is designed.
Enterprise groups are defined.
Permission sets are documented.
The RBAC matrix is complete.
The ABAC model is complete.
Cross-account access is documented.
Privileged-access workflows exist.
Emergency access is documented and tested.
Machine-identity standards are complete.
GitHub OIDC integration is designed.
Joiner, mover and leaver processes are documented.
Access-review procedures exist.
Identity monitoring is defined.
The identity threat model is complete.
The architecture review has been conducted.
All evidence is stored in the project repository.
The executive identity strategy is ready for presentation.

🚀 Next Lesson

➡️ Project 03 — Enterprise Network Security Project

In the next lesson, you will design CloudNova’s enterprise network-security architecture using:

Multi-VPC architecture
AWS Transit Gateway
Centralised inspection
AWS Network Firewall
Route 53 Resolver
VPC endpoints
Private connectivity
Hybrid networking
Network segmentation
Controlled internet egress
Network monitoring
Zero Trust network principles