6.1.1. Access Control to Assets: Physical and Logical
💡 First Principle: Every identity that exists in a system is an attack surface. An identity that isn't needed today but exists anyway is an attack vector waiting to be exploited. Identity lifecycle management exists to ensure that identities exist only when needed, carry only the access they require, and are promptly removed when the relationship ends.
The identity lifecycle:
| Stage | Activities | Security Implication |
|---|---|---|
| Provisioning | Create account, assign initial role, communicate credentials securely | Principle of least privilege applied at creation; separation from provisioner who shouldn't see credentials |
| Maintenance | Access reviews, role changes, password resets, attribute updates | Cumulative access drift ("privilege creep") grows over time without review |
| Suspension | Temporary disable without deletion (leave of absence, investigation) | Preserves audit history; prevents access; reversible |
| Deprovisioning | Permanent account removal, access revocation, audit record preservation | Must precede or be simultaneous with employment termination notification |
Provisioning approaches:
Manual provisioning — HR or manager submits request; IT fulfills. Simple but slow, error-prone, and inconsistent. Suitable only for small organizations.
Role-based automated provisioning — Job role determines access profile. When HR assigns an employee to a role, the identity management system automatically provisions the correct access. Requires a well-maintained role catalog.
Just-in-time (JIT) provisioning — Account created on first authentication, typically in federated identity scenarios (SAML/OIDC). An employee accessing a SaaS application for the first time gets an account created from their IdP attributes. No manual provisioning required.
Privileged access provisioning — Administrative and privileged accounts require separate workflows: additional approval layers, time-limited access grants, session recording, and just-in-time elevation rather than permanent privileged accounts.
Access reviews (recertification):
- Periodic (quarterly, annual) review of all access rights by account owners
- Managers certify that their team members still need the access they have
- Automated workflows route uncertified access for removal
- Critical for detecting privilege creep — the gradual accumulation of rights as users change roles
Orphaned accounts — accounts belonging to users who have left the organization or systems that have been decommissioned. They retain all access rights but have no active owner. A common attack vector: attacker compromises orphaned service account with domain admin rights assigned years ago. Controls: automated deprovisioning on HR termination events, periodic orphaned account audits.
Shared accounts — multiple people using the same account (e.g., "admin", "root"). Destroy accountability — when something goes wrong, you cannot determine which individual was responsible. Prohibited in most compliance frameworks. Replace with individual accounts plus role-based access or PAM with session recording.
⚠️ Exam Trap: Service accounts — non-human accounts used by applications and automated processes — are the most commonly over-privileged identities in enterprise environments. They often have passwords that never expire, excessive rights assigned years ago "just in case," and no owner who regularly reviews them. Service accounts should follow least privilege, have regularly rotated credentials (or use managed service accounts/workload identity), and have documented owners.
Reflection Question: An organization's quarterly access review shows that 340 of their 2,100 user accounts belong to employees who left in the past 18 months. The accounts were never disabled. What is the immediate security action, what process failure created this situation, and what preventive control would close the gap going forward?
