Lesson A12.2
Cloud identity design determines which people and workloads can reach which services, with what privilege, for how long, under whose approval, and with what evidence.
This lesson uses fictional identities, role records, access reviews, and audit evidence only. It does not involve signing in to, testing, or modifying any real cloud identity system.
Lesson Progress
High School Advanced • A12: Cloud Security Architecture • Lesson 2 of 10
Readiness Check
0/4 ready
Professional Hook
A team can have strong authentication and still have weak identity architecture if roles are too broad, guests never expire, service accounts have no owners, workloads use human credentials, or administrators keep permanent privilege.
IAM architecture asks a bigger question: can every access path explain who or what is acting, why the access exists, what it can reach, who approved it, and when it should end?
Identity is a lifecycle, not a login event.
Learning Objectives
Explain cloud IAM architecture as the design of identities, roles, trust relationships, privilege, lifecycle, and evidence rather than simply a list of user accounts.
Distinguish workforce identities, privileged identities, service identities, workload identities, temporary identities, and external identities by purpose, trust, and lifecycle.
Evaluate role design, least privilege, separation of duties, access reviews, session context, approval paths, and environment boundaries using fictional cloud evidence.
Identify IAM architecture gaps such as shared credentials, stale access, overbroad roles, missing ownership, weak workload identity, and unreviewed external access.
Build a Cloud IAM Architecture Matrix that becomes the second artifact in the A12 Cloud Security Architecture Assessment.
Identity Types
One of the most important architecture habits is to separate human and non-human identities by purpose. Their lifecycle, privilege, authentication, ownership, and evidence needs are different.
Represents an employee or approved staff member who needs access to cloud consoles, applications, dashboards, or operational workflows.
Architecture questions
How is the person verified? Which roles are assigned? Who approves access? What happens when the person changes jobs or leaves?
Evidence
Directory lifecycle record, role assignment, approval, access review, authentication policy.
Represents a human identity with authority to change sensitive configuration, identity, data access, release state, or security controls.
Architecture questions
Is privileged access separate from daily access? Is stronger authentication required? Are approvals and audit records present?
Evidence
Privileged role record, approval, session/audit evidence, review cadence, emergency-access policy.
Represents an application, service, automation, function, job, or other non-human workload that needs to call another service.
Architecture questions
Can the workload use an identity rather than a long-lived shared credential? What exact resource and action does it require?
Evidence
Workload identity record, service-to-service authorization, environment scope, owner, rotation or federation metadata.
A non-human account used by an application, service, automation process, or integration.
Architecture questions
Is the account uniquely owned? Is it still needed? Does it have excessive privilege? Could a more modern workload identity reduce secret dependency?
Evidence
Service-account inventory, owner, purpose, permissions, last-use metadata, credential lifecycle.
Provides short-lived access for a project, incident, migration, contractor period, or limited administrative task.
Architecture questions
When does access expire? Who approved it? Is the role narrower than permanent administration?
Evidence
Approval, start/end date, temporary role, expiration control, closure evidence.
Represents a partner, vendor, guest, contractor, or other person whose primary identity belongs outside the organization.
Architecture questions
Who sponsors the identity? Which data and services can it reach? How is access revoked when the relationship ends?
Evidence
Sponsor record, federation or guest identity record, role assignment, review, expiration, contract or business owner.
Access Models
Idea
Permissions are grouped into roles associated with job or workload responsibilities.
Strength
Makes common access patterns understandable and easier to review when roles remain narrow and well-defined.
Risk
Role sprawl or broad catch-all roles can make least privilege difficult to maintain.
Idea
Access decisions consider attributes such as department, assignment, environment, sensitivity, device state, or workload metadata.
Strength
Can express context and dynamic policy more precisely than static role membership alone.
Risk
Poorly governed attributes, stale data, or overly complex conditions can make decisions hard to explain.
Idea
Permissions are granted directly or indirectly to a specific resource or resource group.
Strength
Can keep access narrow when the resource set is clearly defined.
Risk
Large numbers of direct grants become difficult to inventory and review.
Idea
High-impact permissions are activated only when needed and for a limited period.
Strength
Reduces standing administrative privilege and creates explicit activation evidence.
Risk
Weak approval or expiration controls can turn temporary access into permanent privilege.
Idea
Applications authenticate to each other using platform or federated workload identities instead of copied human credentials.
Strength
Improves ownership, scoping, rotation, and auditability while reducing dependence on shared secrets.
Risk
Overbroad identity bindings or cross-environment trust can still create excessive privilege.
Architecture Principles
Grant only the actions and resources required for the approved purpose.
Review: Compare assigned permissions to actual business or workload need.
High-impact workflows should not depend on one identity having unchecked authority across approval, execution, and review.
Review: Look for independent approval, role separation, and auditable handoffs.
Access should change when people join, change jobs, leave, finish projects, or when workloads are retired.
Review: Check provisioning, role changes, expiration, disablement, and closure evidence.
Authentication strength should match the sensitivity and privilege of the access path.
Review: Look for stronger controls around privileged, remote, sensitive, or externally federated access.
Every role, privileged path, service identity, and external identity should have an accountable owner.
Review: Unowned identities and roles are architecture debt.
Development, test, and production identities and privileges should not casually cross boundaries.
Review: Confirm environment-specific roles, workload identities, and approvals.
IAM design should be explainable enough that another reviewer can understand who can do what and why.
Review: Avoid opaque role chains and undocumented inherited access.
Access evidence must match the current people, workloads, roles, resources, and architecture.
Review: Stale access reviews or old role inventories should not be treated as current proof.
Vocabulary
The architecture, policy, processes, and technology used to establish identities and control what they can access.
A human or non-human identity that can be authenticated and authorized to perform actions.
A named collection of permissions or access expectations associated with a responsibility or workload purpose.
The authority to perform an action or access a resource, especially when the action can change sensitive state or security controls.
Permission that remains continuously available to an identity rather than being activated only when needed.
Temporary permission activated for a limited purpose and period, usually with approval and audit evidence.
A non-human identity representing an application, service, automation, or job.
A trust relationship that allows one identity system to authenticate users or workloads for another service.
A periodic or event-driven check that confirms identities still need their current roles and permissions.
Dividing sensitive responsibilities among different identities or roles to reduce unchecked authority.
Highly controlled emergency access intended for exceptional recovery situations and subject to strict ownership and review.
A specific permission, role membership, resource grant, or access capability assigned to an identity.
Fictional IAM Matrix
Use the student-support application
Environment
Production
Role
CounselorAppUser
Scope
Application only
Approval
Department manager + application owner
Review
Quarterly
Owner
Identity Platform Team
Architecture concern
Application authorization still depends on current student-assignment data.
Administer shared cloud platform services
Environment
Production
Role
PlatformAdmin-JIT
Scope
Shared platform resources
Approval
Privileged access workflow
Review
Monthly + per activation
Owner
Platform Engineering Manager
Architecture concern
One emergency activation did not include a linked post-use review record.
Read/write application database through approved service path
Environment
Production
Role
PortalDatabaseClient
Scope
Student-support database only
Approval
Application + Data Platform
Review
On architecture change
Owner
Application Team
Architecture concern
No direct access to analytics or backup storage.
Send approved notifications
Environment
Production
Role
NotificationQueueConsumer
Scope
Notification queue and provider integration
Approval
Notification service owner
Review
Quarterly
Owner
Notification Team
Architecture concern
Candidate migration may replace one long-lived integration credential with workload federation.
Legacy scheduled report task
Environment
Production
Role
LegacyReportWriter
Scope
Report storage + scheduling job
Approval
Historical
Review
Overdue
Owner
Unknown
Architecture concern
Ownership and current business need are not established.
Assist with approved scheduling integration support
Environment
Support tenant
Role
VendorSupportReadOnly
Scope
Integration health metadata only
Approval
Integration owner
Review
Every 30 days
Owner
Integration Owner
Architecture concern
Guest expiration is current, but sponsor review is due in 8 days.
Run approved data migration workflow
Environment
Staging only
Role
MigrationOperator
Scope
Migration staging resources
Approval
Change owner + data owner
Review
Expires automatically
Owner
Migration Project Owner
Architecture concern
Must not be promoted into production or converted into permanent access.
Fake Dashboard
Fictional identity governance metrics
Tracked principals
148
Workforce, privileged, workload, service, temporary, and guest identities
Owned identities
145 / 148
Three legacy service identities still need ownership resolution
Standing privileged roles
4
Target is to reduce two remaining broad standing assignments
Access reviews current
96%
One legacy service account and two guest reviews are overdue
Fake SOC Alert
Source: Fictional IAM Governance Review • Time: 09:52
Access Review
Access review is not just a list of accounts with Approve buttons. A useful review compares current privilege to current purpose, environment, ownership, use, and organizational change.
The account or workforce record is disabled or absent.
Review action: Remove access and investigate why entitlement cleanup did not happen automatically.
The person's current responsibilities differ from the role's original purpose.
Review action: Reapprove, reduce, or remove access.
The identity has not used an entitlement for an extended period.
Review action: Review whether access is still required rather than assuming inactivity alone proves it is unnecessary.
No accountable person or team can explain why the identity or role exists.
Review action: Treat as a governance gap and block expansion until ownership is resolved.
A test or staging identity appears in production scope.
Review action: Investigate and restore environment separation.
A role or entitlement now has broader authority than at the previous review.
Review action: Require explicit justification, approval, and renewed risk review.
Fake Log Panel
[08:22] IAM-01 counselor-group review=CURRENT owner=IdentityPlatform [08:41] IAM-02 platform-admin activation=EMERGENCY post-review=MISSING [09:03] IAM-03 portal-workload scope=student-db-only status=CONFIRMED [09:24] IAM-04 notification-worker federation-migration=PLANNED [09:52] IAM-05 report-maintenance owner=UNKNOWN review=OVERDUE status=BLOCKED [10:16] IAM-06 vendor-guest sponsor-review=8d status=CONDITIONAL [10:44] IAM-07 migration-operator env=STAGING expiry=AUTOMATIC status=CONFIRMED
Training note: this is fake data for defensive analysis practice only.
Analyze the Evidence
IAM Anti-Patterns
Why it fails: Multiple people use one identity, weakening accountability and making offboarding or review difficult.
Better approach: Use named identities with separate privileged activation and audit evidence.
Why it fails: Standing access keeps high-impact authority available even when it is rarely needed.
Better approach: Use narrower permanent roles and time-bounded privileged activation where appropriate.
Why it fails: Applications inherit the lifecycle and exposure problems of a human password or token.
Better approach: Prefer workload identity or narrowly scoped managed service credentials.
Why it fails: Names like PowerUser or FullAccess do not explain why access exists or which business function needs it.
Better approach: Tie roles to clear purpose, resources, actions, owner, and review trigger.
Why it fails: Access can outlive the business relationship because no internal owner is accountable.
Better approach: Require sponsorship, expiration, role scope, and recurring review.
Why it fails: Lower-environment accounts can bypass normal production lifecycle and ownership expectations.
Better approach: Maintain environment-specific identities and prohibit casual cross-environment reuse.
Why it fails: Reviewers approve everything without comparing access to current purpose, use, or role.
Better approach: Review purpose, privilege, owner, use, environment, and change since the last review.
Why it fails: Nested groups and indirect grants can create permissions that neither the user nor owner realizes are present.
Better approach: Preserve explainable entitlement paths and simplify unnecessary inheritance.
Human vs. Workload Identity
A human identity and an application identity should not be treated as interchangeable. Humans have job changes, managers, employment lifecycle, and interactive authentication. Workloads have service owners, deployment environments, runtime purpose, and service-to-service authorization.
| Dimension | Human identity | Workload identity |
|---|---|---|
| Purpose | Job or approved human task | Application or automation function |
| Lifecycle | Join, move, leave, contract end | Deploy, change, retire |
| Owner | Manager + identity/application owner | Service or application owner |
| Authentication | Interactive sign-in and strong authentication | Platform/federated workload authentication |
| Privilege review | Job need and role review | Service purpose and resource scope review |
| Environment | User may access approved environments by role | Should be environment-specific |
| Secrets | Human credentials should not be embedded in applications | Prefer managed workload identity where possible |
| Evidence | Access review, role assignment, sign-in/audit evidence | Identity binding, service authorization, deployment metadata |
Scenario Decision Lab
A production service account runs an old report job. No current owner can explain why the account still exists, and its access review is overdue.
Scenario Decision Lab
A scheduling vendor needs limited access to integration health metadata for support. Northbridge can provide a guest identity with a read-only role and 30-day expiration.
Safe Fictional Lab
Use fictional users, roles, workloads, services, and resources only. Do not sign in to or inspect any real cloud identity environment.
Create at least ten fictional IAM records.
Include workforce, privileged, workload, service, temporary, and external identities.
Give each identity a stable ID.
State the identity purpose.
Identify environment.
List assigned role or entitlement.
Describe resource and action scope.
Record approval path.
Record review cadence or expiration.
Assign accountable owner.
Record evidence supporting the access.
Classify status as Confirmed, Conditional, Unknown, Blocked, or Retired.
Identify at least two least-privilege gaps.
Identify at least one separation-of-duties concern.
Identify at least one workload identity that could replace a long-lived credential.
Add lifecycle and change triggers.
Lab boundary
This is an architecture and governance exercise. Use synthetic identities and permissions only.
Analyze the Evidence
Advanced Challenge
A fictional cloud team currently uses one broad PlatformAdmin role for identity changes, network changes, storage policy, deployment, and logging configuration. Redesign the architecture to reduce unchecked privilege while keeping operations practical.
Separate role purposes
Daily-access vs. privileged-access identities
Just-in-time activation
Approval path
Separation of duties
Emergency access
Environment boundaries
Logging and audit evidence
Access review cadence
Owner for each role
Expiration or deactivation rules
Change triggers
A strong redesign does not simply create more roles. It creates clearer authority boundaries that are understandable, reviewable, and connected to real responsibilities.
Defender Habits
Skill Check
Check Your Understanding
Choose your answers first. Explanations appear only after submission.
Portfolio Prompt
Create the second artifact for your A12 Cloud Security Architecture Assessment: a fictional Cloud IAM Architecture Matrix with at least ten identity records. Include identity ID, type, purpose, environment, role or entitlement, resource/action scope, approval path, owner, review cadence or expiration, authentication context, evidence, status, risk concern, next action, and change trigger.
Confidence / Readiness Reflection
A12.3 moves into Storage Security and Data Exposure. Before continuing, make sure you can explain how identity design controls which humans and workloads can reach cloud data.
I can distinguish workforce, privileged, workload, service, temporary, and external identities.
I can explain least privilege and separation of duties in cloud IAM.
I can identify why workload identity is different from human credentials.
I can evaluate access-review evidence and lifecycle gaps.
I can keep stale, unowned, or overbroad identities visible as architecture risk.
Portfolio Build Guide
Make workforce, privileged, workload, service, temporary, and external identities visually distinct.
A reviewer should understand why the identity exists before seeing what it can access.
Avoid vague terms like broad access. State what resource class and action the role actually needs.
Include review cadence, expiration, disablement, project end, or service retirement.
Every role and identity should have an accountable owner and a clear approval path.
Mark missing review evidence, stale approvals, and unowned identities clearly.
Highlight JIT access, narrower roles, workload identity, and removal of shared accounts.
Make the IAM matrix easy to reuse in storage, network, secrets, monitoring, and governance reviews later in A12.
Key Takeaways
Lesson Safety Boundary
Do not use real usernames, cloud accounts, credentials, tenant IDs, role assignments, identity consoles, private access logs, or production systems. All identities and evidence in this lesson are fictional and defensive.
Lesson Complete
You now have an IAM architecture model for human and workload identities, role design, least privilege, privileged access, lifecycle, access reviews, external identities, and ownership. Next, A12.3 focuses on Storage Security and Data Exposure.